There are 2 parts to getting the -fassociative-math command-line flag translated to LLVM FMF:
1. In the driver/frontend, we accept the flag and its 'no' inverse and deal with the
interactions with other flags like -ffast-math -fno-signed-zeros -fno-trapping-math.
This was mostly already done - we just need to translate the flag as a codegen option.
The test file is complicated because there are many potential combinations of flags here.
Note that we are matching gcc's behavior that requires 'nsz' and no-trapping-math.
2. In codegen, we map the codegen option to FMF in the IR builder. This is simple code and
corresponding test.
For the motivating example from PR27372:
float foo(float a, float x) { return ((a + x) - x); }
$ ./clang -O2 27372.c -S -o - -ffast-math -fno-associative-math -emit-llvm | egrep 'fadd|fsub'
%add = fadd nnan ninf nsz arcp contract float %0, %1
%sub = fsub nnan ninf nsz arcp contract float %add, %2
So 'reassoc' is off as expected (and so is the new 'afn' but that's a different patch).
This case now works as expected end-to-end although the underlying logic is still wrong:
$ ./clang -O2 27372.c -S -o - -ffast-math -fno-associative-math | grep xmm
addss %xmm1, %xmm0
subss %xmm1, %xmm0
We're not done because the case where 'reassoc' is set is ignored by optimizer passes. Example:
$ ./clang -O2 27372.c -S -o - -fassociative-math -fno-signed-zeros -fno-trapping-math -emit-llvm | grep fadd
%add = fadd reassoc float %0, %1
$ ./clang -O2 27372.c -S -o - -fassociative-math -fno-signed-zeros -fno-trapping-math | grep xmm
addss %xmm1, %xmm0
subss %xmm1, %xmm0
Differential Revision: https://reviews.llvm.org/D39812
llvm-svn: 320920
This mimics FileCheck's --check-prefixes option.
The default prefix is "expected". That is, "-verify" is equivalent to
"-verify=expected".
The goal is to permit exercising a single test suite source file with different
compiler options producing different sets of diagnostics. While cpp can be
combined with the existing -verify to accomplish the same goal, source is often
easier to maintain when it's not cluttered with preprocessor directives or
duplicate passages of code. For example, this patch also rewrites some existing
clang tests to demonstrate the benefit of this feature.
Patch by Joel E. Denny, thanks!
Differential Revision: https://reviews.llvm.org/D39694
llvm-svn: 320908
The frontend currently groups diagnostics from the command line according to
diagnostic level, but that places all notes last. Fix that by emitting such
diagnostics in the order they were generated.
Patch by Joel E. Denny, thanks!
Differential Revision: https://reviews.llvm.org/D40995
llvm-svn: 320904
This patch introduces a specialized way to lower overflow-checked
multiplications with mixed-sign operands. This fixes link failures and
ICEs on code like this:
void mul(int64_t a, uint64_t b) {
int64_t res;
__builtin_mul_overflow(a, b, &res);
}
The generic checked-binop irgen would use a 65-bit multiplication
intrinsic here, which requires runtime support for _muloti4 (128-bit
multiplication), and therefore fails to link on i386. To get an ICE
on x86_64, change the example to use __int128_t / __uint128_t.
Adding runtime and backend support for 65-bit or 129-bit checked
multiplication on all of our supported targets is infeasible.
This patch solves the problem by using simpler, specialized irgen for
the mixed-sign case.
llvm.org/PR34920, rdar://34963321
Testing: Apart from check-clang, I compared the output from this fairly
comprehensive test driver using unpatched & patched clangs:
https://gist.github.com/vedantk/3eb9c88f82e5c32f2e590555b4af5081
Differential Revision: https://reviews.llvm.org/D41149
llvm-svn: 320902
This ensures that when compiling for "arm64" __is_target_arch will succeed for
both "arm64" and "aarch64".
Thanks to Bob Wilson who pointed this out!
llvm-svn: 320853
Previously the attributes were emitted only for function definitions.
Patch adds emission of the attributes for function declarations.
llvm-svn: 320826
The initializeLocal function of UnaryTransformTypeLoc missed
the UnderlyingTInfo member. This caused a null-dereference
issue, as reported in PR23421. This patch correctly initializss
the UnderlyingTInfo.
llvm-svn: 320765
Summary:
In D41064, I proposed adding `#pragma clang diagnostic ignored
"-Wuser-defined-literals"` to some of libc++'s headers, since these
warnings are now triggered by clang's new `-std=gnu++14` default:
```
$ cat test.cpp
#include <string>
$ clang -std=c++14 -Wsystem-headers -Wall -Wextra -c test.cpp
In file included from test.cpp:1:
In file included from /usr/include/c++/v1/string:470:
/usr/include/c++/v1/string_view:763:29: warning: user-defined literal suffixes not starting with '_' are reserved [-Wuser-defined-literals]
basic_string_view<char> operator "" sv(const char *__str, size_t __len)
^
/usr/include/c++/v1/string_view:769:32: warning: user-defined literal suffixes not starting with '_' are reserved [-Wuser-defined-literals]
basic_string_view<wchar_t> operator "" sv(const wchar_t *__str, size_t __len)
^
/usr/include/c++/v1/string_view:775:33: warning: user-defined literal suffixes not starting with '_' are reserved [-Wuser-defined-literals]
basic_string_view<char16_t> operator "" sv(const char16_t *__str, size_t __len)
^
/usr/include/c++/v1/string_view:781:33: warning: user-defined literal suffixes not starting with '_' are reserved [-Wuser-defined-literals]
basic_string_view<char32_t> operator "" sv(const char32_t *__str, size_t __len)
^
In file included from test.cpp:1:
/usr/include/c++/v1/string:4012:24: warning: user-defined literal suffixes not starting with '_' are reserved [-Wuser-defined-literals]
basic_string<char> operator "" s( const char *__str, size_t __len )
^
/usr/include/c++/v1/string:4018:27: warning: user-defined literal suffixes not starting with '_' are reserved [-Wuser-defined-literals]
basic_string<wchar_t> operator "" s( const wchar_t *__str, size_t __len )
^
/usr/include/c++/v1/string:4024:28: warning: user-defined literal suffixes not starting with '_' are reserved [-Wuser-defined-literals]
basic_string<char16_t> operator "" s( const char16_t *__str, size_t __len )
^
/usr/include/c++/v1/string:4030:28: warning: user-defined literal suffixes not starting with '_' are reserved [-Wuser-defined-literals]
basic_string<char32_t> operator "" s( const char32_t *__str, size_t __len )
^
8 warnings generated.
```
Both @aaron.ballman and @mclow.lists felt that adding this workaround to
the libc++ headers was the wrong way, and it should be fixed in clang
instead.
Here is a proposal to do just that. I verified that this suppresses the
warning, even when -Wsystem-headers is used, and that the warning is
still emitted for a declaration outside of system headers.
Reviewers: aaron.ballman, mclow.lists, rsmith
Reviewed By: aaron.ballman
Subscribers: mclow.lists, aaron.ballman, andrew, emaste, cfe-commits
Differential Revision: https://reviews.llvm.org/D41080
llvm-svn: 320755
There are many more expr types that can be a capability expr, like
CXXThisExpr, CallExpr, MemberExpr. Instead of enumerating all of them,
just check typeHasCapability for any type given.
Also add & and * operators to allowed unary operators.
Differential Revision: https://reviews.llvm.org/D41224
llvm-svn: 320753
Summary:
Now that r320495, "[debuginfo-tests] Support moving
debuginfo-tests to llvm/projects," has landed, remove temporary FIXME
that supported the old mechanism.
Reviewers: zturner, aprantl
Reviewed By: aprantl
Subscribers: JDevlieghere, cfe-commits
Differential Revision: https://reviews.llvm.org/D41259
llvm-svn: 320751
This patch allows checking whether a C++ record declaration is abstract through
libclang and clang.cindex (Python).
Patch by Johann Klähn!
Differential Revision: https://reviews.llvm.org/D36952
llvm-svn: 320748
Summary:
InterlockedCompareExchange128 is a bit more complicated than the other
InterlockedCompareExchange functions, so it requires a bit more work. It
doesn't directly refer to 128bit ints, instead it takes pointers to
64bit ints for Destination and ComparandResult, and exchange is taken as
two 64bit ints (high & low). The previous value is written to
ComparandResult, and success is returned. This implementation does the
following in order to produce a cmpxchg instruction:
1. Cast everything to 128bit ints or int pointers, and glues together
the Exchange values
2. Reads from CompareandResult to get the comparand
3. Calls cmpxchg volatile (on X86 this will produce a lock cmpxchg16b
instruction)
1. Result 0 (previous value) is written back to ComparandResult
2. Result 1 (success bool) is zext'ed to a uchar and returned
Resolves bug https://llvm.org/PR35251
Patch by Colden Cullen!
Reviewers: rnk, agutowski
Reviewed By: rnk
Subscribers: majnemer, cfe-commits
Differential Revision: https://reviews.llvm.org/D41032
llvm-svn: 320730
update the type from the definition even if we didn't instantiate a definition.
We may have instantiated the definition in an earlier stage of semantic
analysis, after creating the DeclRefExpr but before we reach a point where a
complete expression type is required.
llvm-svn: 320709
Adding the new enumerator forced a bunch more changes into this patch than I
would have liked. The -Wtautological-compare warning was extended to properly
check the new comparison operator, clang-format needed updating because it uses
precedence levels as weights for determining where to break lines (and several
operators increased their precedence levels with this change), thread-safety
analysis needed changes to build its own IL properly for the new operator.
All "real" semantic checking for this operator has been deferred to a future
patch. For now, we use the relational comparison rules and arbitrarily give
the builtin form of the operator a return type of 'void'.
llvm-svn: 320707
Specifically, warn if:
* we find a character that the language standard says we must treat as an
identifier, and
* that character is not reasonably an identifier character (it's a punctuation
character or similar), and
* it renders identically to a valid non-identifier character in common
fixed-width fonts.
Some tools "helpfully" substitute the surprising characters for the expected
characters, and replacing semicolons with Greek question marks is a common
"prank".
llvm-svn: 320697
Summary:
This fixes an invalid warning about missing definition of a function when
parsing with SkipFunctionBodies=true
Reviewers: bkramer, sepavloff
Reviewed By: sepavloff
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D41189
llvm-svn: 320696
Under the Microsoft ABI, it is possible for an object not to have
a virtual table pointer of its own if all of its virtual functions
were introduced by virtual bases. In that case, we need to load the
vtable pointer from one of the virtual bases and perform the type
check using its type.
Differential Revision: https://reviews.llvm.org/D41036
llvm-svn: 320638
Summary:
The backend should only emit data sharing code for the cases where it is needed.
A new function attribute is used by Clang to enable data sharing only for the cases where OpenMP semantics require it and there are variables that need to be shared.
Reviewers: hfinkel, Hahnfeld, ABataev, carlo.bertolli, caomhin
Reviewed By: ABataev
Subscribers: cfe-commits, jholewinski
Differential Revision: https://reviews.llvm.org/D41123
llvm-svn: 320527
This patch is to add diagnose when a function name is
specified on the link clause. According to the OpenMP
spec, only the list items that exclude the function
name are allowed on the link clause.
Differential Revision: https://reviews.llvm.org/D40968
llvm-svn: 320521
unexpected error messages for incompatibility between the
default SM level and the support in the installed toolkit.
Differential Revision: https://reviews.llvm.org/D40996
llvm-svn: 320506
Summary:
The new version of debuginfo-tests will have it's own
lit.cfg.py file which is incompatible with the one in clang/test.
This change supports both the old and new versions, and can be used
until the bots actually move debuginfo-tests to either clang/test or
the monorepo.
This is a prerequisite for D40971.
Reviewers: zturner, aprantl
Subscribers: mgorny, JDevlieghere, llvm-commits, cfe-commits
Differential Revision: https://reviews.llvm.org/D41055
llvm-svn: 320494
The new check introduced in r318705 is useful, but suffers from a particular
class of false positives, namely, it does not account for
dispatch_barrier_sync() API which allows one to ensure that the asyncronously
executed block that captures a pointer to a local variable does not actually
outlive that variable.
The new check is split into a separate checker, under the name of
alpha.core.StackAddressAsyncEscape, which is likely to get enabled by default
again once these positives are fixed. The rest of the StackAddressEscapeChecker
is still enabled by default.
Differential Revision: https://reviews.llvm.org/D41042
llvm-svn: 320455
This adds a new command line option -mprefer-vector-width to specify a preferred vector width for the vectorizers. Valid values are 'none' and unsigned integers. The driver will check that it meets those constraints. Specific supported integers will be managed by the targets in the backend.
Clang will take the value and add it as a new function attribute during CodeGen.
This represents the alternate direction proposed by Sanjay in this RFC: http://lists.llvm.org/pipermail/llvm-dev/2017-November/118734.html
The syntax here matches gcc, though gcc treats it as an x86 specific command line argument. gcc only allows values of 128, 256, and 512. I'm not having clang check any values.
Differential Revision: https://reviews.llvm.org/D40230
llvm-svn: 320419
The two asserts are too aggressive. In C++ mode, an
enum is NOT considered an integral type, but an enum value
is allowed to be an enum. This patch relaxes the two asserts
to allow the enum value as well (as typechecking does).
llvm-svn: 320411
Summary:
This is a side-effect brought in by p0620r0, which allows other placeholder types (derived from `auto` and `decltype(auto)`) to be usable in a `new` expression with a single-clause //braced-init-list// as its initializer (8.3.4 [expr.new]/2). N3922 defined its semantics.
References:
http://wg21.link/p0620r0http://wg21.link/n3922
Reviewers: rsmith, aaron.ballman
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D39451
llvm-svn: 320401
Summary:
Clang was crashing when diagnosing an unused-lambda-capture for a VLA because
From.getVariable() is null for the capture of a VLA bound.
Warning about the VLA bound capture is not helpful, so only warn for the VLA
itself.
Fixes: PR35555
Reviewers: aaron.ballman, dim, rsmith
Reviewed By: aaron.ballman, dim
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D41016
llvm-svn: 320396
As reported in llvm bugzilla 32377.
Here’s a patch to add preinclude of stdc-predef.h.
The gcc documentation says “On GNU/Linux, <stdc-predef.h> is pre-included.” See https://gcc.gnu.org/gcc-4.8/porting_to.html;
The preinclude is inhibited with –ffreestanding.
Basically I fixed the failing test cases by adding –ffreestanding which inhibits this behavior.
I fixed all the failing tests, including some in extra/test, there's a separate patch for that which is linked here
Note: this is a recommit after a test failure took down the original (r318669)
Patch By: mibintc
Differential Revision: https://reviews.llvm.org/D34158
llvm-svn: 320391
The simulator variant of Darwin's platforms is removed in favor of a new
environment field.
The code that selects the platform and the version is split into 4 different
functions instead of being all in one function.
This is an NFC commit, although it slightly improves the
"invalid version number" diagnostic by displaying the environment variable
instead of -m<os>-version-min if the OS version was derived from the
environment.
rdar://35813850
Differential Revision: https://reviews.llvm.org/D41035
llvm-svn: 320235
Sanjay Patel