Given something like:
void *v = (void *)100;
We need to synthesize a ptrtoint operation from 100. During constant
emission, we choose i64 as the type for our constant because it
guaranteed not to drop any bits from our CharUnits representation of the
value. However, this is suboptimal for 32-bit targets: LLVM passes like
GlobalOpt will get confused by these sorts of casts resulting in
pessimization.
Instead, make sure the ptrtoint operand has a pointer-sized integer
type.
llvm-svn: 273020
This mirrors the many other -i*after options to insert a new system search
directory at the end of the search path. This makes it possible to actually
inject a search path after the resource dir. This option is similar in spirit
to the /imsvc option in the clang-cl driver. This is needed to properly use the
driver for Windows targets where the clang headers wrap some of the system
headers.
This concept is actually useful on other targets (e.g. Linux) and would be
really easy to support on the core toolchain.
llvm-svn: 273016
Fix a regression which forbids using -std=cl|CL1.1|CL1.2|CL2.0 in driver.
Allow -std and -cl-std={cl|CL}{|1.1|1.2|2.0}.
Differential Revision: http://reviews.llvm.org/D20630
llvm-svn: 273015
Summary:
Some GCC 5 installations store the libstdc++ includes and GCC-specific files in paths without
the minor part of the version number, such as
/usr/include/c++/5
/usr/lib64/gcc/x86_64-suse-linux/5
Reviewers: cfe-commits, thiagomacieira, jroelofs
Subscribers: tinti, jroelofs
Differential Revision: http://reviews.llvm.org/D14727
llvm-svn: 273012
Reapplying patch in r272777 which was reverted
because the llvm patch which added support
for generating the mcrr/mcrr2 instructions
from the intrinsic was causing an assertion
failure. This has now been fixed in llvm.
llvm-svn: 272983
This patch fixes a bug where we'd segfault (in some cases) if we saw a
variadic function with one or more pass_object_size arguments.
Differential Revision: http://reviews.llvm.org/D17462
llvm-svn: 272971
- In functions with try { } catch { }, only the try block would be
skipped, not the catch blocks
- The template functions would still be parsed.
- The initializers within a constructor would still be parsed.
- The inline functions within class would still be stored, only to be
discared later.
- Invalid code with try would assert (as in "int foo() try assert_here")
This attempt to do even less while skipping function bodies.
Differential Revision: http://reviews.llvm.org/D20821
llvm-svn: 272963
This code should be an error:
void foo(int);
void f3() {
int foo(float);
{
float foo(int); // expected-error {{functions that differ only in their return type cannot be overloaded}}
}
}
the foo(float) function declared at function scope should not hide the float(int)
while trying to redeclare functions.
Differential Revision: http://reviews.llvm.org/D19763
llvm-svn: 272961
Summary:
This patch fixes an issue detected when firstprivate variables are passed to an OpenMP outlined function vararg list. Currently they are not compatible with what the runtime library expects causing malfunction in some targets.
This patch fixes the issue by moving the casting logic already in place for offloading to the common code that creates the outline function and arguments and updates the regression tests accordingly.
Reviewers: hfinkel, arpith-jacob, carlo.bertolli, kkwli0, ABataev
Subscribers: cfe-commits, caomhin
Differential Revision: http://reviews.llvm.org/D21150
llvm-svn: 272900
This is the last patch required to support compilation for Intel MCU target (e.g. Intel(R) Quark(TM) micro controller D 2000).
When IAMCU triple is used:
* Use IAMCU linker output format
* Link with IAMCU crt objects
* Link with IAMCU libraries
Differential Revision: http://reviews.llvm.org/D20675
llvm-svn: 272885
This is the second patch required to support compilation for Intel MCU target (e.g. Intel(R) Quark(TM) micro controller D 2000).
When IAMCU triple is used:
* Recognize and use IAMCU GCC toolchain
* Set up include paths
* Forbid C++
Differential Revision: http://reviews.llvm.org/D19274
llvm-svn: 272883
Parameters and non-static members of aggregates are still excluded,
and probably should remain that way.
Differential Revision: http://reviews.llvm.org/D19754
llvm-svn: 272859
Summary:
Previously if you did e.g.
$ clang -march=haswell -x cuda foo.cu
we would pass "-march=haswell -march=sm_20" down to the ptxas tool.
This causes it to assert, and rightly so!
Reviewers: tra
Subscribers: cfe-commits, echristo
Differential Revision: http://reviews.llvm.org/D21419
llvm-svn: 272857
As noted in the code comment, a potential follow-on would be to remove
the builtins themselves. Other than ord/unord, this already works as
expected. Eg:
typedef float v4sf __attribute__((__vector_size__(16)));
v4sf fcmpgt(v4sf a, v4sf b) { return a > b; }
Differential Revision: http://reviews.llvm.org/D21268
llvm-svn: 272840
llvm statistics are currently printed when the destructor of a "static
ManagedStatic<StatisticInfo> StatInfo" in llvm runs. This destructor
currently runs in each case as part of llvm_shutdown() which is run even
in disable_free mode as part of main(). I assume that this hasn't always
been the case.
Removing the special code here avoids the statistics getting printed
twice.
Differential Revision: http://reviews.llvm.org/D21338
llvm-svn: 272820
When static variables are used in inline functions in header files anything that
uses that function ends up with a reference to the variable. Because
RecursiveASTVisitor uses the inline functions in LambdaCapture that use static
variables any AST plugin that uses RecursiveASTVisitor, such as the
PrintFunctionNames example, ends up with a reference to these variables. This is
bad on Windows when building with MSVC with LLVM_EXPORT_SYMBOLS_FOR_PLUGINS=ON
as variables used across a DLL boundary need to be explicitly dllimported in
the DLL using them.
This patch avoids that by adjusting LambdaCapture to be similar to before
r263921, with a capture of either 'this' or a VLA represented by a null Decl
pointer in DeclAndBits with an extra flag added to the bits to distinguish
between the two. This requires the use of an extra bit, and while Decl does
happen to be sufficiently aligned to allow this it's done in a way that means
PointerIntPair doesn't realise it and gives an assertion failure. Therefore I
also adjust Decl slightly to use LLVM_ALIGNAS to allow this.
Differential Revision: http://reviews.llvm.org/D20732
llvm-svn: 272788
Patch adds intrinsics for mrrc/mrrc2. The
intrinsics for mrrc/mrrc2 return a single
uint64_t to represent two 32 bit values.
The mcrr/mcrr2 intrinsic was changed to
accept a single uint64_t instead of two
32 bit values as the input for consistency.
Differential Revision: http://reviews.llvm.org/D21179
llvm-svn: 272777
Reid Kleckner