| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
1st alloca.
llvm-svn: 218647
|
| |
|
|
|
|
|
| |
There are two GEP's in the function, and it seems the X64 CHECK
was matching the wrong one.
llvm-svn: 218645
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MS-compatibility mode
Clang warns (treated as error by default, but still ignored in system headers)
when passing non-POD arguments to variadic functions, and generates a trap
instruction to crash the program if that code is ever run.
Unfortunately, MSVC happily generates code for such calls without a warning,
and there is code in system headers that use it.
This makes Clang not insert the trap instruction when in -fms-compatibility
mode, while still generating the warning/error message.
Differential Revision: http://reviews.llvm.org/D5492
llvm-svn: 218640
|
| |
|
|
|
|
|
|
|
|
|
|
| |
As PR20495 demonstrates, Clang currenlty infers the CUDA target (host/device,
etc) for implicit members (constructors, etc.) incorrectly. This causes errors
and even assertions in Clang when compiling code (assertions in C++11 mode where
implicit move constructors are added into the mix).
Fix the problem by inferring the target from the methods the implicit member
should call (depending on its base classes and fields).
llvm-svn: 218624
|
| |
|
|
|
|
| |
warn_property_types_are_incompatible. rdar://18487506
llvm-svn: 218621
|
| |
|
|
|
|
|
|
| |
Fixes incorrect codegen when devirtualization is aborted due to covariant return types.
Differential Revision: http://reviews.llvm.org/D5321
llvm-svn: 218602
|
| |
|
|
| |
llvm-svn: 218591
|
| |
|
|
|
|
| |
dependent scopes.
llvm-svn: 218590
|
| |
|
|
| |
llvm-svn: 218587
|
| |
|
|
| |
llvm-svn: 218580
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clang uses two types to talk about a C++ class, the
NonVirtualBaseLLVMType and the LLVMType. Previously, we would allow one
of these to be packed and the other not.
This is problematic. If both don't agree on a common subset of fields,
then routines like getLLVMFieldNo will point to the wrong field. Solve
this by copying the 'packed'-ness of the complete type to the
non-virtual subobject. For this to work, we need to take into account
the non-virtual subobject's size and alignment when we are computing the
layout of the complete object.
This fixes PR21089.
llvm-svn: 218577
|
| |
|
|
| |
llvm-svn: 218556
|
| |
|
|
|
|
|
|
|
|
|
| |
It makes no sense to link in sanitizer runtimes in this case: the user
probably doesn't want to see any system/toolchain libs in his link if he
provides these flags, and the link will most likely fail anyway - as sanitizer
runtimes depend on libpthread, libdl, libc etc.
Also, see discussion in https://code.google.com/p/address-sanitizer/issues/detail?id=344
llvm-svn: 218541
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a base class declares a destructor, we will add the implicit
destructor for the subclass in
ActOnFields -> AddImplicitlyDeclaredMembersToClass
But in Objective C++, we did not compute whether we have a trivial
destructor until after that in
CXXRecordDecl::completeDefinition()
This was leading to a mismatch between the class, which thought it had
no trivial destructor, and the CXXDestructorDecl, which considered
itself trivial. It turns out the reason we delayed setting this until
completeDefinition() was for a warning that has since been removed as
part of -Warc-abi, so we just do it eagerly now.
llvm-svn: 218520
|
| |
|
|
| |
llvm-svn: 218507
|
| |
|
|
|
|
|
|
| |
(clang crashed in CodeGen in llvm::Module::getNamedValue on
thread_local std::unique_ptr<int>).
Differential Revision: http://reviews.llvm.org/D5353
llvm-svn: 218503
|
| |
|
|
|
|
|
|
|
| |
In addition to __builtin_assume_aligned, GCC also supports an assume_aligned
attribute which specifies the alignment (and optional offset) of a function's
return value. Here we implement support for the assume_aligned attribute by making
use of the @llvm.assume intrinsic.
llvm-svn: 218500
|
| |
|
|
|
|
|
|
| |
AFAICT the semantics of frem match libm's fmod.
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewed-by: Tom Stellard <tom@stellard.net>
llvm-svn: 218488
|
| |
|
|
|
|
| |
http://reviews.llvm.org/D5298
llvm-svn: 218482
|
| |
|
|
| |
llvm-svn: 218468
|
| |
|
|
|
|
|
|
|
| |
DefineImplicit*
This fixes an assertion failure in CodeGen where we were not resolving
an exception specification.
llvm-svn: 218466
|
| |
|
|
|
|
| |
uninitialized checkers that did not have them before.
llvm-svn: 218435
|
| |
|
|
|
|
|
|
|
|
|
| |
we were failing to find that bit-field when performing integer promotions. This
brings us closer to following the standard, and closer to GCC.
In C, this change is technically a regression: we get bit-field promotions
completely wrong in C, promoting cases that are categorically not bit-field
designators. This change makes us do so slightly more consistently, though.
llvm-svn: 218428
|
| |
|
|
|
|
|
|
| |
Use the same environment when invoking llvm-config from lit.cfg as
will be used when running tests, so that ASAN_OPTIONS, INCLUDE, etc.
are present.
llvm-svn: 218404
|
| |
|
|
|
|
|
| |
This reverts bits of r218166 that are no longer necessary now that r218394 made
-Wmissing-prototype-for-cc a regular warning.
llvm-svn: 218400
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes PR21027. The MIDL compiler produces code that does this.
If we wanted to improve the warning, I think we could do this:
void __stdcall f(); // Don't warn without -Wstrict-prototypes.
void g() {
f(); // Might warn, the user probably meant for f to take no args.
f(1, 2, 3); // Warn, we have no idea what args f takes.
f(1); // Error, this is insane, one of these calls is broken.
}
Reviewers: thakis
Differential Revision: http://reviews.llvm.org/D5481
llvm-svn: 218394
|
| |
|
|
|
|
|
|
|
| |
ABI
when under -fms-extensions. Reviewed by John McCall.
//rdar://17784718
llvm-svn: 218384
|
| |
|
|
|
|
|
|
| |
A record which contains a flexible array member is itself a flexible
array member. A struct which contains such a record should also
consider itself to be a flexible array member.
llvm-svn: 218378
|
| |
|
|
|
|
|
|
|
|
| |
_addcarryx_u64
_addcarry_u64
_subborrow_u64
Thanks Pasi Parviainen for notice.
llvm-svn: 218376
|
| |
|
|
|
|
|
| |
memccpy_check should have source and dest size at arg 3 and 4
rdar://18431336
llvm-svn: 218367
|
| |
|
|
|
|
| |
the other visitors as well.
llvm-svn: 218366
|
| |
|
|
|
|
|
|
|
| |
r218292 reverted r197496 because it broke things. In addition to breaking
things, r197496 also made all traits starting with __is_ revertible.
Reinstantiate that part of r197496 because code out there (e.g. libc++) depends
on this behavior. Fixes PR21045.
llvm-svn: 218365
|
| |
|
|
|
|
|
|
|
|
|
| |
Usually, overriding a virtual function defined in a virtual base
required emission of a vtordisp slot in the record. However no vtordisp
is needed if the overriding function is pure; it should be impossible to
observe the pure virtual method.
This fixes PR21046.
llvm-svn: 218340
|
| |
|
|
|
|
|
| |
lists. Since the fields are inititalized one at a time, using a field with
lower index to initialize a higher indexed field should not be warned on.
llvm-svn: 218339
|
| |
|
|
|
|
|
|
|
| |
lexer, add the token buffer underneath the caching lexer where possible and
push the tokens directly into the caching lexer otherwise. We previously
put the lexer into a corrupted state where we could not guarantee to provide
the tokens in the right order and would sometimes assert.
llvm-svn: 218333
|
| |
|
|
|
|
|
|
|
| |
that function, and apart from being slow, this is unnecessary: ADL can trigger
instantiations that are not permitted here. The standard isn't *completely*
clear here, but this seems like the intent, and in any case this approach is
permitted by [temp.inst]p7.
llvm-svn: 218330
|
| |
|
|
|
|
|
|
|
| |
On further investigation, COMDATs should work with .ctors, and the issue
I was hitting probably reproduces with .init_array.
This reverts commit r218287.
llvm-svn: 218313
|
| |
|
|
| |
llvm-svn: 218299
|
| |
|
|
| |
llvm-svn: 218298
|
| |
|
|
|
|
|
|
|
|
|
| |
Don't mangle all casts in expressions as "cv", use the appropriate
encoding which corresponds to a specific cast.
This fixes PR21034.
Differential Revision: http://reviews.llvm.org/D5453
llvm-svn: 218293
|
| |
|
|
|
|
| |
Also add a test to make sure that this doesn't break again. Fixes PR21036.
llvm-svn: 218292
|
| |
|
|
|
|
| |
The type of size_t varies between targets.
llvm-svn: 218288
|
| |
|
|
|
|
|
|
|
| |
In particular, pre-.init_array ELF uses the .ctors section mechanism.
MinGW COFF also uses .ctors, now that I think about it. Therefore,
restrict this optimization to the two platforms that are currently known
to work: ELF with .init_array and COFF with .CRT$XCU.
llvm-svn: 218287
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We need to walk the class hierarchy twice: once in depth-first base
specifier order for mangling and again in depth-first layout order for
vftable layout.
Vftable layout seems to depend on the full path from the most derived
class to the base containing the vfptr.
Fixes PR21031.
llvm-svn: 218285
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: This is a test for this patch: http://reviews.llvm.org/D5445.
Reviewers: rnk
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D5446
llvm-svn: 218271
|
| |
|
|
|
|
|
| |
Only tests under test/Driver should use %clang, and test/CodeGen in
particular must always use %clang_cc1.
llvm-svn: 218260
|
| |
|
|
|
|
|
| |
'type' argument when it cannot be determined which objects ptr
points to at compile time. rdar://18334276
llvm-svn: 218258
|
| |
|
|
| |
llvm-svn: 218256
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Vectors are normally 16-byte aligned, however the O32 ABI enforces a
maximum alignment of 8-bytes since the base of the stack is 8-byte aligned.
Previously, this was enforced on the caller side, but not on the callee side.
This fixes the output of OpenCL's printf when given vectors.
Reviewers: atanasyan
Reviewed By: atanasyan
Subscribers: llvm-commits, pekka.jaaskelainen
Differential Revision: http://reviews.llvm.org/D5433
llvm-svn: 218248
|
| |
|
|
|
|
|
|
|
|
|
| |
This patch adds codegen for constructs:
#pragma omp critical [name]
<body>
It generates global variable ".gomp_critical_user_[name].var" of type int32[8]. Then it generates library call "kmpc_critical(loc, gtid, .gomp_critical_user_[name].var)", code for <body> statement and final call "kmpc_end_critical(loc, gtid, .gomp_critical_user_[name].var)".
Differential Revision: http://reviews.llvm.org/D5202
llvm-svn: 218239
|