| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 367431
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Re-commit r366322 after some fixes
TME is a future architecture technology, documented in
https://developer.arm.com/architectures/cpu-architecture/a-profile/exploration-tools
https://developer.arm.com/docs/ddi0601/a
More about the future architectures:
https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/new-technologies-for-the-arm-a-profile-architecture
This patch adds support for the TME instructions TSTART, TTEST, TCOMMIT, and
TCANCEL and the target feature/arch extension "tme".
It also implements TME builtin functions, defined in ACLE Q2 2019
(https://developer.arm.com/docs/101028/latest)
Differential Revision: https://reviews.llvm.org/D64416
Patch by Javed Absar and Momchil Velikov
llvm-svn: 367428
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This adds the 'f' inline assembly constraint, as supported by GCC. An
'f'-constrained operand is passed in a floating point register. Exactly
which kind of floating-point register (32-bit or 64-bit) is decided
based on the operand type and the available standard extensions (-f and
-d, respectively).
This patch adds support in both the clang frontend, and LLVM itself.
Reviewers: asb, lewis-revill
Reviewed By: asb
Subscribers: hiraditya, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, MaskRay, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, s.egerton, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D65500
llvm-svn: 367403
|
|
|
|
|
|
|
|
|
| |
This adds support for parsing/emitting in IR the floating-point RISC-V
registers in inline assembly clobber lists.
Differential Revision: https://reviews.llvm.org/D64737
llvm-svn: 367399
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we detect a built-in declaration for which we cannot derive a type
matching the pattern in the Builtins.def file, we currently emit a
warning that the respective header is needed. However, this is not
necessarily the behavior we want as it has no connection to the location
of the declaration (which can actually be in the header in question).
Instead, this warning is generated
- if we could not build the type for the pattern on file (for some
reason). Here we should make the reason explicit. The actual problem
is otherwise circumvented as the warning is misleading, see [0] for
an example.
- if we could not build the type for the pattern because we do not
have a type on record, possible since D55483, we should not emit any
warning. See [1] for a legitimate problem.
This patch address both cases. For the "setjmp" family a new warning is
introduced and for built-ins without type on record, so far
"pthread_create", we do not emit the warning anymore.
Also see: PR40692
[0] https://lkml.org/lkml/2019/1/11/718
[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235583
Differential Revision: https://reviews.llvm.org/D58091
llvm-svn: 367387
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: The minimum compilers support all have alignas, and we don't use LLVM_ALIGNAS anywhere anymore. This also removes an MSVC diagnostic which, according to the comment above, isn't relevant anymore.
Reviewers: rnk
Subscribers: mgorny, jkorous, dexonsmith, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D65458
llvm-svn: 367383
|
|
|
|
|
|
|
| |
The reordering of the UID field makes the size of a
FileEntry 8 bytes smaller on 64bit platforms.
llvm-svn: 367371
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instantiation
We were previously just using a specialization in the class template instead of
creating a new specialization in the class instantiation.
Fixes llvm.org/PR42779.
Differential revision: https://reviews.llvm.org/D65359
llvm-svn: 367367
|
|
|
|
|
|
|
| |
This reverts commit d2254dbf21a3243233b75294ef901086199df1b9.
This (unintentionally?) changed behavior, disallowing e.g. -x objective-c++-header
llvm-svn: 367353
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
UBSan-Standalone-x86_64 :: TestCases/TypeCheck/Function/function.cpp currently
FAILs on Solaris/x86_64:
clang-9: error: unsupported option '-fsanitize=function' for target 'x86_64-pc-solaris2.11'
AFAICS, there's nothing more to do then enable that sanitizer in the driver (for x86 only),
which is what this patch does, together with updating another testcase.
Tested on x86_64-pc-solaris2.11.
Differential Revision: https://reviews.llvm.org/D64488
llvm-svn: 367351
|
|
|
|
|
|
|
| |
The previous code detected conflicts through copy-pasta, this versions
uses a 'loop'.
llvm-svn: 367350
|
|
|
|
|
|
| |
Fixes llvm.org/PR42778
llvm-svn: 367346
|
|
|
|
|
|
|
|
|
| |
Dropping the 'u' entry and the entire Flags table from Types.def.
Now it'll be a bit easier to tablegenify this.
Differential Revision: https://reviews.llvm.org/D65308
llvm-svn: 367345
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The cache recorded the wrong expansion location for all but the first
stringization. It seems uncommon to stringize the same macro argument
multiple times, so this cache doesn't seem that important.
Fixes PR39942
Reviewers: vsk, rsmith
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D65428
llvm-svn: 367337
|
|
|
|
|
|
|
|
|
|
| |
In `CodeGenFunction::EmitAArch64BuiltinExpr()`, bulk move all of the aarch64 MSVC-builtin cases to an earlier point in the function (the `// Handle non-overloaded intrinsics first` switch block) in order to avoid an unreachable in `GetNeonType()`. The NEON type-overloading logic is not appropriate for the Windows builtins.
Fixes https://llvm.org/pr42775
Differential Revision: https://reviews.llvm.org/D65403
llvm-svn: 367323
|
|
|
|
|
|
| |
When dumping a desugared QualType and the type is a type alias, also print out the id for the type alias declaration.
llvm-svn: 367312
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
make check-all currently fails on x86_64-pc-solaris2.11 when building with GCC 9:
Undefined first referenced
symbol in file
_ZN11__sanitizer14internal_lseekEimi SANITIZER_TEST_OBJECTS.sanitizer_libc_test.cc.i386.o
_ZN11__sanitizer23MapWritableFileToMemoryEPvmim SANITIZER_TEST_OBJECTS.sanitizer_libc_test.cc.i386.o
ld: fatal: symbol referencing errors
clang-9: error: linker command failed with exit code 1 (use -v to see invocation)
make[3]: *** [projects/compiler-rt/lib/sanitizer_common/tests/CMakeFiles/TSanitizer-i386-Test.dir/build.make:92: projects/compiler-rt/lib/sanitizer_common/tests/Sanitizer-i386-Test] Error 1
While e.g. __sanitizer::internal_lseek is defined in sanitizer_solaris.cc, g++ 9
predefines _FILE_OFFSET_BITS=64 while clang++ currently does not.
This patch resolves this inconsistency by following the gcc lead, which allows
make check-all to finish successfully.
There's one caveat: gcc defines _LARGEFILE_SOURCE and _LARGEFILE64_SOURCE for C++ only, while clang has long been doing it for
all languages. I'd like to keep it this way because those macros do is to make
declarations of fseek/ftello (_LARGEFILE_SOURCE) resp. the 64-bit versions
of largefile functions (*64 with _LARGEFILE64_SOURCE) visible additionally.
However, _FILE_OFFSET_BITS=64 changes all affected functions to be largefile-aware.
I'd like to restrict this to C++, just like gcc does.
To avoid a similar inconsistence with host compilers that don't predefine _FILE_OFFSET_BITS=64
(e.g. clang < 9, gcc < 9), this needs a compantion patch https://reviews.llvm.org/D64483.
Tested on x86_64-pc-solaris2.11.
Differential Revision: https://reviews.llvm.org/D64482
llvm-svn: 367305
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Arm C Language Extensions for SVE document specifies that
__ARM_FEATURE_SVE should be set when the compiler supports SVE and
implements all the extensions described in the document.
This is currently not yet the case, so the feature should be disabled
until the compiler can provide all the extensions as described.
Reviewers: c-rhodes, rengolin, rovka, ktkachov
Reviewed By: rengolin
Differential Revision: https://reviews.llvm.org/D65404
llvm-svn: 367301
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move the platform check out of PPC Linux toolchain code and add platform guards
to the intrinsic headers, since they are supported currently only on 64-bit
PowerPC targets.
Reviewed By: Jinsong Ji
Differential Revision: https://reviews.llvm.org/D64849
llvm-svn: 367281
|
|
|
|
|
|
| |
r367274 broke it
llvm-svn: 367276
|
|
|
|
|
|
| |
As discussed in D65249, don't use AlignedCharArray or std::aligned_storage. Just use alignas(X) char Buf[Size];. This will allow me to remove AlignedCharArray entirely, and works on the current minimum version of Visual Studio.
llvm-svn: 367274
|
|
|
|
|
|
|
|
| |
Make DependencyCollector::maybeAddDependency, just like its other
methods, which I made virtual a while ago. The motivation for this
change is still the LLDB reproducer.
llvm-svn: 367271
|
|
|
|
| |
llvm-svn: 367270
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The `this` parameter of a thunk requires adjustment. Stop emitting an
incorrect dbg.declare pointing to the unadjusted pointer.
We could describe the adjusted value instead, but there may not be much
benefit in doing so as users tend not to debug thunks.
Robert O'Callahan reports that this matches gcc's behavior.
Fixes PR42627.
Differential Revision: https://reviews.llvm.org/D65035
llvm-svn: 367269
|
|
|
|
| |
llvm-svn: 367256
|
|
|
|
|
|
| |
GCC 9 in promoting it to an error by default.
llvm-svn: 367255
|
|
|
|
|
|
|
|
|
|
|
|
| |
check the formal rules rather than seeing if the normal checks produce a
diagnostic.
This fixes the handling of C++2a extensions in lambdas in C++17 mode,
as well as some corner cases in earlier language modes where we issue
diagnostics for things other than not satisfying the formal constexpr
requirements.
llvm-svn: 367254
|
|
|
|
|
|
| |
The as-options.s test writes to the build tree as of r367165. Some build systems configure this to be readonly, so this fails. Explicitly write to the output tree using `%t` to avoid this.
llvm-svn: 367253
|
|
|
|
| |
llvm-svn: 367249
|
|
|
|
|
|
|
|
|
| |
Factor out some of the renames from D63434 and D63442, and generate
half type convert_ builtins.
Patch by Pierre Gondois and Sven van Haastregt.
llvm-svn: 367229
|
|
|
|
| |
llvm-svn: 367225
|
|
|
|
| |
llvm-svn: 367219
|
|
|
|
|
|
|
|
| |
DeclSpec now shows the TypeRep, ExprRep, or DeclRep as appropriate
TemplateName decodes and displays the StorageType
A few minor refinements to other types
llvm-svn: 367199
|
|
|
|
| |
llvm-svn: 367193
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While we implemented taint propagation rules for several
builtin/standard functions, there's a natural desire for users to add
such rules to custom functions.
A series of patches will implement an option that allows users to
annotate their functions with taint propagation rules through a YAML
file. This one adds parsing of the configuration file, which may be
specified in the commands line with the analyzer config:
alpha.security.taint.TaintPropagation:Config. The configuration may
contain propagation rules, filter functions (remove taint) and sink
functions (give a warning if it gets a tainted value).
I also added a new header for future checkers to conveniently read YAML
files as checker options.
Differential Revision: https://reviews.llvm.org/D59555
llvm-svn: 367190
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In D62801, new function attribute `willreturn` was introduced. In short, a function with `willreturn` is guaranteed to come back to the call site(more precise definition is in LangRef).
In this patch, willreturn is annotated for LLVM intrinsics.
Reviewers: jdoerfert
Reviewed By: jdoerfert
Subscribers: jvesely, nhaehnle, sstefan1, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D64904
llvm-svn: 367184
|
|
|
|
|
|
|
|
|
|
|
|
| |
Same kind of fix as in r367176, but for "RUN on line 76"
this time.
I'll ask for a post-commit review, to ensure this
matches the intention with the test added in r367165.
But I think this at least will make the buildbots a
little bit happier.
llvm-svn: 367182
|
|
|
|
|
|
| |
Just a simple fix of Werror problem after r367165.
llvm-svn: 367177
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some people were seeing this failure:
```
: 'RUN: at line 83'; clang -mrelax-all -fno-integrated-as /b/s/w/ir/k/llvm-project/clang/test/Driver/as-options.s -S 2>&1 \
| /FileCheck --check-prefix=WARN --allow-empty clang/test/Driver/as-options.s
--
Exit Code: 1
Command Output (stderr):
--
clang/test/Driver/as-options.s:66:16: error: NOWARN-NOT: excluded string found in input
// NOWARN-NOT: unused
^
<stdin>:1:95: note: found here
clang-10: warning: clang/test/Driver/as-options.s: 'assembler' input unused [-Wunused-command-line-argument]
```
Maybe this helps with that.
llvm-svn: 367176
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is like r305666 (which added support for `if constexpr`) except
that it allows a macro name after the if.
This is slightly tricky for two reasons:
1. r305666 didn't add test coverage for all cases where it added a
kw_constexpr, so I had to figure out what all the added cases were
for. I now added tests for all `if constexpr` bits that didn't have
tests. (This took a while, see e.g. https://reviews.llvm.org/D65223)
2. Parsing `if <ident> (` as an if means that `#if defined(` and
`#if __has_include(` parse as ifs too. Add some special-case code
to prevent this from happening where it's incorrect.
Fixes PR39248.
Differential Revision: https://reviews.llvm.org/D65227
llvm-svn: 367167
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r367119.
This broke several bots:
http://lab.llvm.org:8011/builders/clang-atom-d525-fedora-rel/builds/26891/steps/ninja%20check%201/logs/FAIL%3A%20Clang%3A%3Aexception-alignment.cpp
http://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-incremental/245/consoleFull
llvm-svn: 367166
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
different approach
This morally relands r365703 (and r365714), originally reviewed at
https://reviews.llvm.org/D64527, but with a different implementation.
Relanding the same approach with a fix for the revert reason got a bit
involved (see https://reviews.llvm.org/D65108) so use a simpler approach
with a more localized implementation (that in return duplicates code
a bit more).
This approach also doesn't validate flags for the integrated assembler
if the assembler step doesn't run.
Fixes PR42066.
Differential Revision: https://reviews.llvm.org/D65233
llvm-svn: 367165
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch changes the following tests to run under the new pass manager only:
```
Clang :: CodeGen/avx512-reduceMinMaxIntrin.c (1 of 4)
Clang :: CodeGen/avx512vl-builtins.c (2 of 4)
Clang :: CodeGen/avx512vlbw-builtins.c (3 of 4)
Clang :: CodeGen/avx512f-builtins.c (4 of 4)
```
The new PM added extra bitcasts that weren't checked before. For
reduceMinMaxIntrin.c, the issue was mostly the alloca's being in a different
order. Other changes involved extra bitcasts, and differently ordered loads and
stores, but the logic should still be the same.
Differential revision: https://reviews.llvm.org/D65110
llvm-svn: 367157
|
|
|
|
|
|
| |
This should be fixed properly to not depend on LLVM (so much).
llvm-svn: 367149
|
|
|
|
|
|
|
|
| |
This restores the use of `rm` instead of the non-portable `ln -n`. Such
use being the status quo for the 12-month period between rC334972 and
rC365414.
llvm-svn: 367147
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Do not automatically report self references of structs in statement expression
as warnings. Instead wait for uninitialized cfg analysis.
https://bugs.llvm.org/show_bug.cgi?id=42604
Reviewers: aaron.ballman, rsmith, nickdesaulniers
Reviewed By: aaron.ballman, nickdesaulniers
Subscribers: nathanchance, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D64678
llvm-svn: 367134
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The maximum alignment used by ARM arch
is 64bits, not 128.
This could cause overaligned memory
access for 128 bit neon vector that
have unpredictable behaviour.
This fixes: https://bugs.llvm.org/show_bug.cgi?id=42668
Patch by: Diogo Sampaio(diogo.sampaio@arm.com)
Differential Revision: https://reviews.llvm.org/D65000
Change-Id: I5a62b766491f15dd51e4cfe6625929db897f67e3
llvm-svn: 367119
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Reduction variables are the variables, for which the private copies
must be created in the OpenMP regions. Then they are initialized with
the predefined values depending on the reduction operation. After exit
from the OpenMP region the original variable is updated using the
reduction value and the value of the original reduction variable.
Reviewers: NoQ
Subscribers: guansong, jdoerfert, caomhin, kkwli0, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D65106
llvm-svn: 367116
|
|
|
|
|
|
|
|
|
| |
SPIR targets need to have all functions be SPIR calling convention,
however the CXXABIs were just returning CC_C in all non-'this-CC' cases.
https://reviews.llvm.org/D65294
llvm-svn: 367103
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r365985.
Prior to r365985, clang used to mark C union fields that have
non-trivial ObjC ownership qualifiers as unavailable if the union was
declared in a system header. r365985 stopped doing so, which caused the
swift compiler to crash when it tried to import a non-trivial union.
I have a patch that fixes the crash (https://reviews.llvm.org/D65256),
but I'm temporarily reverting the original patch until we can decide on
whether it's taking the right approach.
llvm-svn: 367076
|