| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
Like on other 64-bit platforms, Int64Type should be SignedLong
on SystemZ, not SignedLongLong as per default. This could cause
ABI incompatibilities in certain cases (e.g. name mangling).
llvm-svn: 233544
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Running the GCC's inter-compiler ABI compatibility test suite uncovered
a couple of errors in clang's SystemZ ABI implementation. These all
affect only rare corner cases:
- Short vector types
GCC synthetic vector types defined with __attribute__ ((vector_size ...))
are always passed and returned by reference. (This is not documented in
the official ABI document, but is the de-facto ABI implemented by GCC.)
clang would do that only for vector sizes >= 16 bytes, but not for shorter
vector types.
- Float-like aggregates and empty bitfields
clang would consider any aggregate containing an empty bitfield as
first element to be a float-like aggregate. That's obviously wrong.
According to the ABI doc, the presence of an empty bitfield makes
an aggregate to be *not* float-like. However, due to a bug in GCC,
empty bitfields are ignored in C++; this patch changes clang to be
compatible with this "feature" of GCC.
- Float-like aggregates and va_arg
The va_arg implementation would mis-detect some aggregates as float-like
that aren't actually passed as such. This applies to aggregates that
have only a single element of type float or double, but using an aligned
attribute that increases the total struct size to more than 8 bytes.
This error occurred because the va_arg implement used to have an copy
of the float-like aggregate detection logic (i.e. it would call the
isFPArgumentType routine, but not perform the size check).
To simplify the logic, this patch removes the duplicated logic and
instead simply checks the (possibly coerced) LLVM argument type as
already determined by classifyArgumentType.
llvm-svn: 233543
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Also add tests for 'R' and 'm'.
Reviewers: atanasyan
Reviewed By: atanasyan
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D8449
llvm-svn: 233542
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
goog.scope(function() {
// test
var x = 0;
// test
});
After:
goog.scope(function() {
// test
var x = 0;
// test
});
llvm-svn: 233530
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds atomic update codegen for the following forms of expressions:
x binop= expr;
x++;
++x;
x--;
--x;
x = x binop expr;
x = expr binop x;
If x and expr are integer and binop is associative or x is a LHS in a RHS of the assignment expression, and atomics are allowed for type of x on the target platform atomicrmw instruction is emitted.
Otherwise compare-and-swap sequence is emitted:
bb:
...
atomic load <x>
cont:
<expected> = phi [ <x>, label %bb ], [ <new_failed>, %cont ]
<desired> = <expected> binop <expr>
<res> = cmpxchg atomic &<x>, desired, expected
<new_failed> = <res>.field1;
br <res>field2, label %exit, label %cont
exit:
...
Differential Revision: http://reviews.llvm.org/D8536
llvm-svn: 233513
|
| |
|
|
|
|
|
| |
Replace boolean IsExplicit parameter of OpenMPRuntime::emitBarrierCall() method by OpenMPDirectiveKind Kind for better compatibility with the runtime library. Also add processing of 'nowait' clause on worksharing directives.
Differential Revision: http://reviews.llvm.org/D8659
llvm-svn: 233511
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Method CXXMethodDecl::isStaticOverloadedOperator expects Operator field
from the struct OperatorFunctionId, which is a member of the union in
the class UnqualifiedId. If the kind of UnqualifiedId is not checked,
there is no guarantee that the value that this method receives will be
correct, because it can be the value of another union member and not
OperatorFunctionId.
This bug manifests itself when running make check-all on mips64 BE.
This fix resolves the following regression tests:
Clang :: CXX/special/class.dtor/p9.cpp
Clang :: CodeGenCXX/2006-09-12-OpaqueStructCrash.cpp
Clang :: CodeGenCXX/ctor-dtor-alias.cpp
Clang :: CodeGenCXX/debug-info-windows-dtor.cpp
Clang :: CodeGenCXX/dllexport-members.cpp
Clang :: CodeGenCXX/dllexport.cpp
Patch by Violeta Vukobrat.
Differential Revision: http://reviews.llvm.org/D8437
llvm-svn: 233508
|
| |
|
|
|
|
|
|
|
|
| |
Utilizing IMAGEREL relocations for synthetic IR constructs isn't
valuable, just clutter. While we are here, simplify HandlerType names
by making the numeric value for the 'adjective' part of the mangled name
instead of appending '.const', etc. The old scheme made for very long
global names and leads to wordy things like '.std_bad_alloc'
llvm-svn: 233503
|
| |
|
|
|
|
|
|
| |
attributes.
Found by afl-fuzz.
llvm-svn: 233499
|
| |
|
|
|
|
|
|
|
|
|
| |
directive
ExpandBuiltinMacro would strip the identifier and downstream users crash
when they encounter an identifier token with nullptr identifier info.
Found by afl-fuzz.
llvm-svn: 233497
|
| |
|
|
|
|
|
| |
The buffer is guaranteed to be zero-terminated so we can just
circumvent the check. Found by afl-fuzz.
llvm-svn: 233496
|
| |
|
|
|
|
|
| |
Otherwise it stays uninitialized with potentially catastrophic results.
Found by afl-fuzz.
llvm-svn: 233494
|
| |
|
|
|
|
| |
It will crash downstream somewhere. Found by afl-fuzz.
llvm-svn: 233493
|
| |
|
|
|
|
| |
Found by clang-fuzz.
llvm-svn: 233492
|
| |
|
|
|
|
|
|
|
| |
While dereferencing ThisTokEnd is fine and we know that it's not in
[a-zA-Z0-9_.], ThisTokEnd[1] is really past the end.
Found by asan and with a little help from clang-fuzz.
llvm-svn: 233491
|
| |
|
|
|
|
|
| |
We know that the last accessible char is not in [a-zA-Z0-9_.] so we can
happily scan on as long as it is. No functionality change.
llvm-svn: 233490
|
| |
|
|
|
|
| |
Do not fail when "" is one of the compilation arguments.
llvm-svn: 233465
|
| |
|
|
|
|
|
|
|
| |
Notably, this prevents us from doing *tons* of work to compute the
modules hash, including trying to read a darwin specific plist file off
of the system. There is a lot that needs cleaning up below this layer
too.
llvm-svn: 233462
|
| |
|
|
|
|
| |
Going through the driver is too slow.
llvm-svn: 233459
|
| |
|
|
|
|
|
|
| |
integral promotion only if it converts to the underlying type or its promoted
type, not if it converts to the promoted type that the bitfield would have it
if were of the underlying type.
llvm-svn: 233457
|
| |
|
|
| |
llvm-svn: 233455
|
| |
|
|
|
|
|
|
|
|
| |
An upcoming LLVM commit will make calling
`DIBuilder::retainType(nullptr)` illegal (actually, it already was, but
it wasn't verified). Check for null before calling.
This triggered in test/CodeGenObjC/debug-info-block-helper.m.
llvm-svn: 233443
|
| |
|
|
|
|
| |
not visible definition of the same template.
llvm-svn: 233430
|
| |
|
|
|
|
|
|
|
|
| |
I again added the "reasonable" assertions and they again fired during
a modules self-host.
This hopefully will un-break the self-host build bot. No test case handy
and adding one seems to have little or no value really.
llvm-svn: 233426
|
| |
|
|
| |
llvm-svn: 233425
|
| |
|
|
|
|
|
|
| |
if the merged definition is visible, and perform lookups into all merged copies
of the definition (not just for special members) so that we can complete the
redecl chains for members of the class.
llvm-svn: 233420
|
| |
|
|
| |
llvm-svn: 233407
|
| |
|
|
|
|
| |
This reverts commit r233393 while a debug a bot failure.
llvm-svn: 233398
|
| |
|
|
|
|
|
| |
This saves some IO and ccache space by not creating long section names. It
should work with every ELF linker.
llvm-svn: 233393
|
| |
|
|
| |
llvm-svn: 233391
|
| |
|
|
| |
llvm-svn: 233387
|
| |
|
|
|
|
|
|
| |
clang-cl driver too
Reviewed at http://reviews.llvm.org/D8663
llvm-svn: 233384
|
| |
|
|
|
|
| |
[dcl.fct.default]p3.
llvm-svn: 233379
|
| |
|
|
|
|
|
|
| |
A parameter pack after a default argument is now valid.
PR23029.
llvm-svn: 233377
|
| |
|
|
|
|
|
|
| |
This is ill-formed (and cannot be used anyways).
PR23028.
llvm-svn: 233376
|
| |
|
|
|
|
|
|
|
|
|
|
| |
declaration name so that we mark declarations for emission in
a deterministic order (and in turn give them deterministic IDs).
This is the last for loop or data structure I can find by inspection of
the AST writer which doesn't use a deterministic order.
Found by inspection, no test case.
llvm-svn: 233348
|
| |
|
|
|
|
|
|
|
|
| |
Previously, if the expr list parsed fine but the expr to the left of the
open parenthesis was invalid (when parsing the suffix of a
postfix-expression), the parsed expr list was just ignored.
Fixes PR23005.
llvm-svn: 233347
|
| |
|
|
|
|
| |
top of an existing imported-but-not-visible definition.
llvm-svn: 233345
|
| |
|
|
|
|
|
|
|
|
|
| |
order based on order of insertion.
This should cause both our warnings about these and the modules
serialization to be deterministic as a consequence.
Found by inspection.
llvm-svn: 233343
|
| |
|
|
|
|
|
|
|
|
| |
a deterministic order.
This uses a MapVector to track the insertion order of selectors.
Found by inspection.
llvm-svn: 233342
|
| |
|
|
|
|
| |
imported-but-not-visible definition.
llvm-svn: 233341
|
| |
|
|
|
|
|
|
|
|
|
| |
DeclIDs so that in addition to be grouped by file, the order of these
groups is stable.
Found by inspection, no test case. Not sure this can be observed without
a randomized seed for the hash table, but we shouldn't be relying on the
hash table layout under any circumstances.
llvm-svn: 233339
|
| |
|
|
|
|
|
|
| |
writing a module to be a set-vector to preserve insertion order.
No test case, found by inspection.
llvm-svn: 233335
|
| |
|
|
|
|
| |
SmallSetVector provides directly.
llvm-svn: 233334
|
| |
|
|
|
|
|
|
|
|
|
|
| |
rewritten decls for Objective-C modules.
Found by inspection and completely obvious, so no test case. Many of the
remaining determinism fixes won't have precise test cases at this point,
but these are the kinds of things we wouldn't ask for a specific test of
during code review but ask authors to fix. The functionality isn't
changing, and should (he he!) already be tested.
llvm-svn: 233333
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
traversing the identifier table.
No easy test case as this table is somewhere between hard and impossible
to observe as non-deterministically ordered. The table is a hash table
but we hash the string contents and never remove entries from the table
so the growth pattern, etc, is all completely fixed. However, relying on
the hash function being deterministic is specifically against the
long-term direction of LLVM's hashing datastructures, which are intended
to provide *no* ordering guarantees. As such, this defends against these
things by sorting the identifiers. Sorting identifiers right before we
emit them to a serialized form seems a low cost for predictability here.
llvm-svn: 233332
|
| |
|
|
|
|
|
|
|
|
|
| |
logic removed.
This logic was both inserting all builtins into the identifier table and
ensuring they would get serialized. The first happens unconditionally
now, and we always write out the entire identifier table. This code can
simply go away.
llvm-svn: 233331
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
constructors in the current lexical context even though name lookup
found them via some other context merged into the redecl chain.
This can only happen for implicit constructors which can only have the
name of the type of the current context, so we can fix this by simply
*always* merging those names first. This also has the advantage of
removing the walk of the current lexical context from the common case
when this is the only constructor name we need to deal with (implicit or
otherwise).
I've enhanced the tests to cover this case (and uncovered an unrelated
bug which I fixed in r233325).
llvm-svn: 233327
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
deserializing an inherited constructor.
This is the exact same logic we use when deserializing method overrides
for the same reason: the canonical decl may end up pinned to a different
decl when we are improting modules, we need to re-pin to the canonical
one during reading.
My test case for this will come in a subsequent commit. I was trying to
test a more tricky bug fix and the test case happened to tickle this bug
as well.
llvm-svn: 233325
|
| |
|
|
|
|
|
| |
modules, and allow sub-modules of a module with a use-declaration to make use
of the nominated modules.
llvm-svn: 233323
|