'R' An address that can be sued in a non-macro load or store.
Including missing positive test case and fixed typo for r176453.
Thanks to Richard Smith for catching this!
Jack
llvm-svn: 176506
- Generate atomicrmw operations in most of the cases when it's sensible to do
so.
- Don't crash in several common cases (and hopefully don't crash in more of
them).
- Add some better tests.
We now generate significantly better code for things like:
_Atomic(int) x;
...
x++;
On MIPS, this now generates a 4-instruction ll/sc loop, where previously it
generated about 30 instructions in two nested loops. On x86-64, we generate a
single lock incl, instead of a lock cmpxchgl loop (one instruction instead of
ten).
llvm-svn: 176420
These are two related changes (one in llvm, one in clang).
LLVM:
- rename address_safety => sanitize_address (the enum value is the same, so we preserve binary compatibility with old bitcode)
- rename thread_safety => sanitize_thread
- rename no_uninitialized_checks -> sanitize_memory
CLANG:
- add __attribute__((no_sanitize_address)) as a synonym for __attribute__((no_address_safety_analysis))
- add __attribute__((no_sanitize_thread))
- add __attribute__((no_sanitize_memory))
for S in address thread memory
If -fsanitize=S is present and __attribute__((no_sanitize_S)) is not
set llvm attribute sanitize_S
llvm-svn: 176076
My previous attempt was extremely deficient, allowing more volatiles
to be introduced and not even checking all of the ones that are
present.
This attempt doesn't try to keep track of the values stored or offsets
within particular objects, just that the correct objects are accessed
in a correctly volatile manner throughout.
llvm-svn: 174700
AArch64 handles aggFct's return struct slightly differently, leading
to an extra memcpy. This test is fortunately only concerned about
volatile copies, so we can modify the grep text to filter it.
llvm-svn: 174621
Only some ABIs require the "signext" attribute on parameters. On most
platforms, however, it's a useful test so it's best not to limit it to some
random arbitrary platform.
llvm-svn: 174619
This addresses several (not all) debug info tests that use explicit metadata
numbers. Wherever the same number appeared more than once in a test I used
a named match to ensure the same number appeared in all those cases (this may
still be overly constraining test cases as they may not have actually cared
about that relationship). For one-off numbers I just replaced them with an
unnamed regex.
This may underconstrain poorly written test cases that were interested in
checking that certain metadata nodes were related but didn't actually match
on all the related nodes numbers.
llvm-svn: 174247
Prior to the patch, Clang does not properly promote types when a complex
integer operand is combined with an integer via a binary operator, or when
one is assigned to the other in either order. This patch detects when
promotion is needed (and permissible) and generates the necessary code.
The test assmes no target has the same size operands for "char" and
"long long," and that no target performs arithmetic on char operands without
extending them to a larger format first. If there are any targets for
which this is not the case, they should be XFAILed.
llvm-svn: 174181
Introduces these negation forms explicitly and uses them to control a new
"altivec" target feature for PowerPC. This allows avoiding generating
Altivec instructions on processors that support Altivec.
The new test case verifies that the Altivec "lvx" instruction is not
used when -fno-altivec is present on the command line.
llvm-svn: 174140
In cooperation with the LLVM patch, this should implement all scalar front-end
parts of the C and C++ ABIs for AArch64.
This patch excludes the NEON support also reviewed due to an outbreak of
batshit insanity in our legal department. That will be committed soon bringing
the changes to precisely what has been approved.
Further reviews would be gratefully received.
llvm-svn: 174055
Indents were given the color blue when outputting with color.
AST dumping now looks like this:
Node
|-Node
| `-Node
`-Node
`-Node
Compared to the previous:
(Node
(Node
(Node))
(Node
(Node)))
llvm-svn: 174022
implementation; this is much more inline with the original implementation
(i.e., pre-ubsan) and does not require run-time library support.
The trapping implementation can be invoked using either '-fcatch-undefined-behavior'
or '-fsanitize=undefined-trap -fsanitize-undefined-trap-on-error', with the latter
being preferred. Eventually, the -fcatch-undefined-behavior' flag will be removed.
llvm-svn: 173848
One of the gotchas (see changes to CodeGenFunction) was due to the fix in
r139416 (for PR10829). This only worked previously because the top level
lexical block would set the location to the end of the function, the debug
location would be updated (as per r139416), the location would be set to
the end of the function again (but that would no-op, since it was the same
as the previous location), then the return instruction would be emitted using
the debug location.
Once the top level lexical block was no longer emitted, the end-of-function
location change was causing the debug loc to be updated, regressing that bug.
llvm-svn: 173593
Title: [PR9027] volatile struct bug: member is not loaded at -O;
This is caused by last flag passed to @llvm.memcpy being false,
not honoring that aggregate has at least one 'volatile' data member
(even though aggregate itself has not been qualified as 'volatile'.
As a result, optimization optimizes away the memcpy altogether.
Patch review by John MaCall (I still need to fix up a test though).
llvm-svn: 173535
This is a missing piece for C99 conformance.
This patch handles UCNs by adding a '\\' case to LexTokenInternal and
LexIdentifier -- if we see a backslash, we tentatively try to read in a UCN.
If the UCN is not syntactically well-formed, we fall back to the old
treatment: a backslash followed by an identifier beginning with 'u' (or 'U').
Because the spelling of an identifier with UCNs still has the UCN in it, we
need to convert that to UTF-8 in Preprocessor::LookUpIdentifierInfo.
Of course, valid code that does *not* use UCNs will see only a very minimal
performance hit (checks after each identifier for non-ASCII characters,
checks when converting raw_identifiers to identifiers that they do not
contain UCNs, and checks when getting the spelling of an identifier that it
does not contain a UCN).
This patch also adds basic support for actual UTF-8 in the source. This is
treated almost exactly the same as UCNs except that we consider stray
Unicode characters to be mistakes and offer a fixit to remove them.
llvm-svn: 173369
the 64-bit PowerPC ELF ABI.
The ABI requires that the real and imaginary parts of a complex argument
each occupy their own doubleword. Arguments smaller than 8 bytes are
right-adjusted within the doubleword.
Clang expects EmitVAARG() to return a pointer to a structure in which
the real and imaginary parts are packed adjacently in memory. To accomplish
this, we generate code to load the code appropriately from the varargs
location and pack the values into a temporary variable in the form Clang
expects, returning a pointer to that structure.
The test case demonstrates correct code generation for all "small" complex
types on PPC64: int, short, char, and float.
llvm-svn: 172438
with respect to the lower "left-hand-side bitwidth" bits, even when negative);
see OpenCL spec 6.3j. This patch both implements this behaviour in the code
generator and "constant folding" bits of Sema, and also prevents tests
to detect undefinedness in terms of the weaker C99 or C++ specifications
from being applied.
llvm-svn: 171755
When we are visiting the extern declaration of 'i' in
static int i = 99;
int foo() {
extern int i;
return i;
}
We should not try to handle it as if it was an function static. That is, we
must consider the written storage class.
Fixing this then exposes that the assert in EmitGlobalVarDeclLValue and the
if leading to its call are not completely accurate. They were passing before
because the second decl was marked as having external storage. I changed them
to check the linkage, which I find easier to understand.
Last but not least, there is something strange going on with cuda and opencl.
My guess is that the linkage computation for these languages needs to be
audited, but I didn't want to change that in this patch so I just updated
the storage classes to keep the current behavior.
Thanks to Reed Kotler for reporting this.
llvm-svn: 170827
Reed Kotler