llvm-svn: 193254

llvm-svn: 193253

Per Nadav's review comments for r192866.

llvm-svn: 193252

 Major steps include:
 1). introduces a not-addr-taken bit-field in GlobalVariable
 2). GlobalOpt pass sets "not-address-taken" if it proves a global varirable 
    dosen't have its address taken.
 3). AA use this info for disambiguation. 

llvm-svn: 193251

llvm-svn: 193250

Pacifies GCC's -Wstrict-prototypes.

llvm-svn: 193249

llvm-svn: 193248

llvm-svn: 193247

A prior commit of this patch was reverted because it was within the blamelist's purview of a failing test.  The failure of that test has been addressed here: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20131021/091546.html.  Therefore I am recommitting this patch (all tests pass on windows, except for the usual modules & index suspects that never pass on my box).

Some background: Both Doug and Richard had asked me in Chicago to remove the circular reference in CXXRecordDecl to LambdaExpr by factoring out and storing the needed information from LambdaExpr directly into CXXRecordDecl.
 
In addition, I have added an IsGenericLambda flag - this makes life a little easier when we implement capturing, and are Sema-analyzing the body of a lambda (and the calloperator hasn't been wired to the closure class yet). Any inner lambdas can have potential captures that could require walking up the scope chain and checking if any generic lambdas are capture-ready. This 'bit' makes some of that checking easier. 

No change in functionality.

This patch was approved by Doug with minor modifications (comments were cleaned up, and all data members were converted from bool/enum to unsigned, as requested): 
http://llvm-reviews.chandlerc.com/D1856

Thanks!

llvm-svn: 193246

llvm-svn: 193245

llvm-svn: 193244

llvm-svn: 193243

Some versions of the GNU MIPS toolchain generate 64-Bit DWARF (even though
it isn't really necessary).  This change adds support for the 64-Bit DWARF
format, but is not actually tested with >4GB of debug data.

Similar changes are in progress for llvm's version of DWARFDebugLine, in
review D1988.

llvm-svn: 193242

llvm-svn: 193241

llvm-svn: 193240

llvm-svn: 193239

llvm-svn: 193238

Unlike the previously added intrinsics, these do not map to a single instruction
on MIPS32. They are provided for regularity (to round out the .[bhw] variants
of the same operation) and compatibility with GCC.

Includes:
  copy_[us].d, fill.d, insert.d, insve.d

llvm-svn: 193237

llvm-svn: 193236

llvm-svn: 193235

the file references non-existent arguments and breaks build

llvm-svn: 193234

This provides rudimentary testing of the llvm-c api.

The following commands are implemented:

  * --module-dump
    Read bytecode from stdin - print ir

  * --module-list-functions
    Read bytecode from stdin - list summary of functions

  * --module-list-globals
    Read bytecode from stdin - list summary of globals

  * --targets-list
    List available targets

  * --object-list-sections
    Read object file from stdin - list sections

  * --object-list-symbols
    Read object file from stdin - list symbols (like nm)

  * --disassemble
    Read lines of triple, hex ascii machine code from stdin - print disassembly

  * --calc
    Read lines of name, rpn from stdin - print generated module ir

Differential-Revision: http://llvm-reviews.chandlerc.com/D1776
llvm-svn: 193233

llvm-svn: 193232

__sanitizer_report_error_summary to ReportErrorSummary.

llvm-svn: 193231

A previous attempt http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130930/090049.html resulted in PR 17476, and was reverted,

The original TransformLambdaExpr (pre generic-lambdas) transformed the TypeSourceInfo of the Call operator in its own instantiation scope via TransformType.  This resulted in the parameters of the call operator being mapped to their transformed counterparts in an instantiation scope that would get popped off.
Then a call to TransformFunctionParameters would add the parameters and their transformed mappings (but newly created ones!) to the current instantiation scope. This would result in a disconnect between the new call operator's TSI parameters and those used to construct the call operator declaration. This was ok in the non-generic lambda world - but would cause issues with nested transformations (when non-generic and generics were interleaved) in the generic lambda world - that I somewhat kludged around initially - but this resulted in PR17476.

The new approach seems cleaner. We only do the transformation of the TypeSourceInfo - but we make sure to do it in the current instantiation scope so we don't lose the untransformed to transformed mappings of the ParmVarDecls when they get created.   

Another attempt caused a test to fail (http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20131021/091533.html) and also had to be reverted - my apologies - in my haste, i did not run all the tests - argh!

Now all the tests seem to pass - but a Fixme has been added - since I suspect Richard will find the fix a little inelegant ;) I shall try and work on a more elegant fix once I have had a chance to discuss with Richard or Doug at a later date.

Hopefully the third time;s a charm *fingers crossed*

This does not yet include capturing.

Please see test file for examples.

This patch was LGTM'd by Doug:
http://llvm-reviews.chandlerc.com/D1784

llvm-svn: 193230

llvm-svn: 193229

llvm-svn: 193228

Mark seed_seq default constructor and size() as noexcept. This is implied, but not required by LWG issue 2180

llvm-svn: 193227

They were causing CodeGenCXX/mangle-exprs.cpp to fail.

Revert "Remove the circular reference to LambdaExpr in CXXRecordDecl."

Revert "Again: Teach TreeTransform and family how to transform generic lambdas nested within templates and themselves."

llvm-svn: 193226

ffs(x) broke the mingw buildbot.

llvm-svn: 193225

llvm-svn: 193224

Both Doug and Richard had asked me to remove the circular reference in CXXRecordDecl to LambdaExpr by factoring out and storing the needed information from LambdaExpr directly into CXXRecordDecl.

No change in functionality. 

In addition, I have added an IsGenericLambda flag - this makes life a little easier when we implement capturing, and are Sema-analyzing the body of a lambda (and the calloperator hasn't been wired to the closure class yet). Any inner lambdas can have potential captures that could require walking up the scope chain and checking if any generic lambdas are capture-ready. This 'bit' makes some of that checking easier. 

This patch was approved by Doug with minor modifications (comments were cleaned up, and all data members were converted from bool/enum to unsigned, as requested): 
http://llvm-reviews.chandlerc.com/D1856

Thanks!

llvm-svn: 193223

This fixes piglit:
- shaders/glsl-fs-texture2d-masked
- shaders/glsl-fs-texture2d-masked-4

Patch by: Marek Olšák

Signed-off-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 193222

Patch by: Jeroen Ketema

llvm-svn: 193221

The C++ compiler used to build prepare-builtins
may differ from the llvm/clang for which we are
building libclc.

Use 'clang++' as the default compiler.

Patch by: Jeroen Ketema

llvm-svn: 193220

modules.

With this fixed, I no longer see any test regressions in the libc++ test suite
when enabling a single-module module.map for libc++ (other than issues with my
system headers).

llvm-svn: 193219

One should actually not do one-line printing of nested aggregates even if they are not the base class
This check was overly strict. Relax it.
While one could conceivably want nested one-lining:
(Foo) aFoo = (x = 1, y = (t = 3, q = “Hello), z = 3.14)
the spirit of this feature is mostly to make *SMALL LINEAR* structs come out more compact.
Aggregates with children and no summary for now just disable the one-lining. Define a one-liner summary to override :)

llvm-svn: 193218

llvm-svn: 193217

lambdas nested within templates and themselves.

A previous attempt http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130930/090049.html resulted in PR 17476, and was reverted,


The original TransformLambdaExpr (pre generic-lambdas) transformed the TypeSourceInfo of the Call operator in its own instantiation scope via TransformType.  This resulted in the parameters of the call operator being mapped to their transformed counterparts in an instantiation scope that would get popped off.
Then a call to TransformFunctionParameters would add the parameters and their transformed mappings (but newly created ones!) to the current instantiation scope. This would result in a disconnect between the new call operator's TSI parameters and those used to construct the call operator declaration. This was ok in the non-generic lambda world - but would cause issues with nested transformations (when non-generic and generics were interleaved) in the generic lambda world - that I somewhat kludged around initially - but this resulted in PR17476.

The new approach seems cleaner. We only do the transformation of the TypeSourceInfo - but we make sure to do it in the current instantiation scope so we don't lose the untransformed to transformed mappings of the ParmVarDecls when they get created.   

This does not yet include capturing.

Please see test file for examples.

This patch was LGTM'd by Doug:
http://llvm-reviews.chandlerc.com/D1784

llvm-svn: 193216

The SelectionDAGBuilder was promoting vector kernel arguments to legal
types, but this won't work for R600 and SI since kernel arguments are
stored in memory and can't be promoted.  In order to handle vector
arguments correctly we need to look at the original types from the LLVM IR
function.

llvm-svn: 193215