D67208 added a new test line to wasm-eh.cpp that invokes the LLVM
backend and this test fails on bots that don't have WebAssembly target.
This makes wasm-eh.cpp explicitly require WebAssembly so this will be
skipped on those targets.
llvm-svn: 371711
Summary:
This adds `-fwasm-exceptions` (in similar fashion with
`-fdwarf-exceptions` or `-fsjlj-exceptions`) that turns on everything
with wasm exception handling from the frontend to the backend.
We currently have `-mexception-handling` in clang frontend, but this is
only about the architecture capability and does not turn on other
necessary options such as the exception model in the backend. (This can
be turned on with `llc -exception-model=wasm`, but llc is not invoked
separately as a command line tool, so this option has to be transferred
from clang.)
Turning on `-fwasm-exceptions` in clang also turns on
`-mexception-handling` if not specified, and will error out if
`-mno-exception-handling` is specified.
Reviewers: dschuff, tlively, sbc100
Subscribers: aprantl, jgravelle-google, sunfish, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D67208
llvm-svn: 371708
AVX512 instructions can cause a frequency drop on these CPUs. This
can negate the performance gains from using wider vectors. Enabling
prefer-vector-width=256 will prevent generation of zmm registers
unless explicit 512 bit operations are used in the original source
code.
I believe gcc and icc both do something similar to this by default.
Differential Revision: https://reviews.llvm.org/D67259
llvm-svn: 371694
Part of PR43272, the changes are:
1. Use @ as the sed pattern delimiter instead of : so that the drive
letter in lit substitutions isn't an issue.
2. Use the %/t and %/S substitutions to get paths with forward slashes
to work around string quoting issues in the yaml file.
3. Replace REQUIRES:shell with XFAIL:windows. These tests should pass on
Windows, but do not for reasons that are not yet understood. We would
like to know if they pass unexpectedly.
I was able to remove the XFAILs from two tests, since they already pass
with my sed fix:
clang/test/VFS/module_missing_vfs.m
clang/test/VFS/test_nonmodular.c
Reviewers: amccarth
Differential Revision: https://reviews.llvm.org/D67454
llvm-svn: 371663
At this point the PathDiagnostic, PathDiagnosticLocation, PathDiagnosticPiece
structures no longer rely on anything specific to Static Analyzer, so we can
move them out of it for everybody to use.
PathDiagnosticConsumers are still to be handed off.
Differential Revision: https://reviews.llvm.org/D67419
llvm-svn: 371661
This method of PathDiagnostic is a part of Static Analyzer's particular
path diagnostic construction scheme. As such, it doesn't belong to
the PathDiagnostic class, but to the Analyzer.
Differential Revision: https://reviews.llvm.org/D67418
llvm-svn: 371660
These static functions deal with ExplodedNodes which is something we don't want
the PathDiagnostic interface to know anything about, as it's planned to be
moved out of libStaticAnalyzerCore.
Differential Revision: https://reviews.llvm.org/D67382
llvm-svn: 371659
That's one of the few random entities in the PathDiagnostic interface that
are specific to the Static Analyzer. By moving them out we could let
everybody use path diagnostics without linking against Static Analyzer.
Differential Revision: https://reviews.llvm.org/D67381
llvm-svn: 371658
This commit adds an optimization to clang-scan-deps and clang's preprocessor that skips excluded preprocessor
blocks by bumping the lexer pointer, and not lexing the tokens until reaching appropriate #else/#endif directive.
The skip positions and lexer offsets are computed when the file is minimized, directly from the minimized tokens.
On an 18-core iMacPro with macOS Catalina Beta I got 10-15% speed-up from this optimization when running clang-scan-deps on
the compilation database for a recent LLVM and Clang (3511 files).
Differential Revision: https://reviews.llvm.org/D67127
llvm-svn: 371656
In `DirectoryLookup::LookupFile` parameter `HasBeenMapped` doesn't cover
the case when clang finds a file through a header map but doesn't remap
the lookup filename because the target path is an absolute path. As a
result, -Wnonportable-include-path suppression for header maps
introduced in r301592 wasn't triggered.
Change parameter `HasBeenMapped` to `IsInHeaderMap` and use parameter
`MappedName` to track the filename remapping. This way we can handle
both relative and absolute paths in header maps, and account for their
specific properties, like filename remapping being a property preserved
across lookups in multiple directories.
rdar://problem/39516483
Reviewers: dexonsmith, bruno
Reviewed By: dexonsmith
Subscribers: jkorous, cfe-commits, ributzka
Differential Revision: https://reviews.llvm.org/D58094
llvm-svn: 371655
Summary:
Microsoft seems to do this regardless of the language mode, so we must
also do it in order to be ABI compatible.
Fixes PR36125
Reviewers: thakis
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D47956
llvm-svn: 371642
This patch contains the basic functionality for reporting potentially
incorrect usage of __builtin_expect() by comparing the developer's
annotation against a collected PGO profile. A more detailed proposal and
discussion appears on the CFE-dev mailing list
(http://lists.llvm.org/pipermail/cfe-dev/2019-July/062971.html) and a
prototype of the initial frontend changes appear here in D65300
We revised the work in D65300 by moving the misexpect check into the
LLVM backend, and adding support for IR and sampling based profiles, in
addition to frontend instrumentation.
We add new misexpect metadata tags to those instructions directly
influenced by the llvm.expect intrinsic (branch, switch, and select)
when lowering the intrinsics. The misexpect metadata contains
information about the expected target of the intrinsic so that we can
check against the correct PGO counter when emitting diagnostics, and the
compiler's values for the LikelyBranchWeight and UnlikelyBranchWeight.
We use these branch weight values to determine when to emit the
diagnostic to the user.
A future patch should address the comment at the top of
LowerExpectIntrisic.cpp to hoist the LikelyBranchWeight and
UnlikelyBranchWeight values into a shared space that can be accessed
outside of the LowerExpectIntrinsic pass. Once that is done, the
misexpect metadata can be updated to be smaller.
In the long term, it is possible to reconstruct portions of the
misexpect metadata from the existing profile data. However, we have
avoided this to keep the code simple, and because some kind of metadata
tag will be required to identify which branch/switch/select instructions
are influenced by the use of llvm.expect
Patch By: paulkirth
Differential Revision: https://reviews.llvm.org/D66324
llvm-svn: 371635
Bundler leaks memory if it is called with -type=o but given input isn't an object file (though it has to have a known binary type like IR, archive, etc...). Memory leak is happening when binary object returned by the createBinary(...) call cannot be casted to an ObjectFile type. In this case returned BinaryOrErr object releases ownership of the binary, but no one is taking it (see line 626).
Differential Revision: https://reviews.llvm.org/D67416
llvm-svn: 371633
Chun Chen.
The previous patch (https://reviews.llvm.org/D54441) support the
relational-op != very well for openmp canonical loop form, however,
it didn't update the diagnosis message. So this patch is simply
update the diagnosis message by adding !=, update the test
related to it, and update the section number for canonical loop
form for OpenMP 5.0 in comment.
Differential Revision: https://reviews.llvm.org/D66559
llvm-svn: 371631
This reverts commit r371584. It introduced a dependency from compiler-rt
to llvm/include/ADT, which is problematic for multiple reasons.
One is that it is a novel dependency edge, which needs cross-compliation
machinery for llvm/include/ADT (yes, it is true that right now
compiler-rt included only header-only libraries, however, if we allow
compiler-rt to depend on anything from ADT, other libraries will
eventually get used).
Secondly, depending on ADT from compiler-rt exposes ADT symbols from
compiler-rt, which would cause ODR violations when Clang is built with
the profile library.
llvm-svn: 371598
Submittin in behalf of krisb (Kristina Bessonova) <ch.bessonova@gmail.com>
Summary:
'+crypto' means '+aes' and '+sha2' for arch >= ARMv8 when they were
not disabled explicitly. But this is correctly handled only in case of
'-march' option, though the feature may also be specified through
the '-mcpu' or '-mfpu' options. In the following example:
$ clang -mcpu=cortex-a57 -mfpu=crypto-neon-fp-armv8
'aes' and 'sha2' are disabled that is quite unexpected:
$ clang -cc1 -triple armv8--- -target-cpu cortex-a57
<...> -target-feature -sha2 -target-feature -aes -target-feature +crypto
This exposed by https://reviews.llvm.org/D63936 that makes
the 'aes' and 'sha2' features disabled by default.
So, while handling the 'crypto' feature we need to take into account:
- a CPU name, as it provides the information about architecture
(if no '-march' option specified),
- features, specified by the '-mcpu' and '-mfpu' options.
Reviewers: SjoerdMeijer, ostannard, labrinea, dnsampaio
Reviewed By: dnsampaio
Subscribers: ikudrin, javed.absar, kristof.beyls, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66018
Author: krisb
llvm-svn: 371597
Multi-versioned functions defined by cpu_dispatch and implemented with IFunc
can not be called outside the translation units where they are defined due to
lack of symbols. This patch add function aliases for these functions and thus
make them visible outside.
Differential Revision: https://reviews.llvm.org/D67058
Patch by Senran Zhang
llvm-svn: 371586
This patch contains the basic functionality for reporting potentially
incorrect usage of __builtin_expect() by comparing the developer's
annotation against a collected PGO profile. A more detailed proposal and
discussion appears on the CFE-dev mailing list
(http://lists.llvm.org/pipermail/cfe-dev/2019-July/062971.html) and a
prototype of the initial frontend changes appear here in D65300
We revised the work in D65300 by moving the misexpect check into the
LLVM backend, and adding support for IR and sampling based profiles, in
addition to frontend instrumentation.
We add new misexpect metadata tags to those instructions directly
influenced by the llvm.expect intrinsic (branch, switch, and select)
when lowering the intrinsics. The misexpect metadata contains
information about the expected target of the intrinsic so that we can
check against the correct PGO counter when emitting diagnostics, and the
compiler's values for the LikelyBranchWeight and UnlikelyBranchWeight.
We use these branch weight values to determine when to emit the
diagnostic to the user.
A future patch should address the comment at the top of
LowerExpectIntrisic.cpp to hoist the LikelyBranchWeight and
UnlikelyBranchWeight values into a shared space that can be accessed
outside of the LowerExpectIntrinsic pass. Once that is done, the
misexpect metadata can be updated to be smaller.
In the long term, it is possible to reconstruct portions of the
misexpect metadata from the existing profile data. However, we have
avoided this to keep the code simple, and because some kind of metadata
tag will be required to identify which branch/switch/select instructions
are influenced by the use of llvm.expect
Patch By: paulkirth
Differential Revision: https://reviews.llvm.org/D66324
llvm-svn: 371584
Summary:
The first NFC change is to replace a getCXXABI().isMicrosoft() check
with getTriple().isWindowsMSVCEnvironment(). This code takes effect in
non-C++ compilations, so it doesn't make sense to check the C++ ABI. In
the MS ABI, enums are always considered to be "complete" because the
underlying type of an unfixed enum will always be 'int'. This behavior
was moved from -fms-compatibility to MS ABI back in r249656.
The second change is functional, and it downgrades an error to a warning
when the MS ABI is used rather than only under -fms-compatibility. The
reasoning is that it's unreasonable for the following code to reject the
following code for all MS ABI targets with -fno-ms-compatibility:
enum Foo { Foo_Val = 0xDEADBEEF };
This is valid code for any other target, but in the MS ABI, Foo_Val just
happens to be negative. With this change, clang emits a
-Wmicrosoft-enum-value warning on this code, but compiles it without
error.
Fixes PR38478
Reviewers: hans, rsmith, STL_MSFT
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D67304
llvm-svn: 371581
constant-folding mode regardless of the original evaluation mode.
In order for this to be correct, we need to track whether we're checking
for a potential constant expression or checking for undefined behavior
separately from the evaluation mode enum, since we don't want to clobber
those states when entering constant-folding mode.
llvm-svn: 371557
This reverts r371497 (git commit 3d7e9ab7b9)
Reorder `not` with `env` in these two tests so they pass:
Driver/rewrite-map-in-diagnostics.c
Index/crash-recovery-modules.m.
This will not be necessary after D66531 lands.
llvm-svn: 371552
constant.
If the constexpr variable is partially initialized, the initializer can
be emitted as the structure, not as an array, because of some early
optimizations. The llvm variable gets the type from this constant and,
thus, gets the type which is pointer to struct rather than pointer to an
array. We need to convert this type to be truely array, otherwise it may
lead to the compiler crash when trying to emit array subscript
expression.
llvm-svn: 371548
LLDB reads the various .apple* accelerator tables (and in the near
future: the DWARF 5 accelerator tables) which should make
.gnu_pubnames redundant. This changes the Clang driver to no longer
pass -ggnu-pubnames when tuning for LLDB.
Thanks to David Blaikie for pointing this out!
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20190422/thread.html#646062
rdar://problem/50142073
Differential Revision: https://reviews.llvm.org/D67373
llvm-svn: 371530
When running clang as a native compiler in RISC-V Linux the flag
-mabi=ilp32d / -mabi=lp64d is always mandatory. This change makes it the
default there.
Differential Revision: https://reviews.llvm.org/D65634
llvm-svn: 371494
I plan to reuse it in a later patch.
This is almost NFC except a small change in control flow when diagnosing
+d without +f.
Differential Revision: https://reviews.llvm.org/D66002
llvm-svn: 371492
This patch contains the basic functionality for reporting potentially
incorrect usage of __builtin_expect() by comparing the developer's
annotation against a collected PGO profile. A more detailed proposal and
discussion appears on the CFE-dev mailing list
(http://lists.llvm.org/pipermail/cfe-dev/2019-July/062971.html) and a
prototype of the initial frontend changes appear here in D65300
We revised the work in D65300 by moving the misexpect check into the
LLVM backend, and adding support for IR and sampling based profiles, in
addition to frontend instrumentation.
We add new misexpect metadata tags to those instructions directly
influenced by the llvm.expect intrinsic (branch, switch, and select)
when lowering the intrinsics. The misexpect metadata contains
information about the expected target of the intrinsic so that we can
check against the correct PGO counter when emitting diagnostics, and the
compiler's values for the LikelyBranchWeight and UnlikelyBranchWeight.
We use these branch weight values to determine when to emit the
diagnostic to the user.
A future patch should address the comment at the top of
LowerExpectIntrisic.cpp to hoist the LikelyBranchWeight and
UnlikelyBranchWeight values into a shared space that can be accessed
outside of the LowerExpectIntrinsic pass. Once that is done, the
misexpect metadata can be updated to be smaller.
In the long term, it is possible to reconstruct portions of the
misexpect metadata from the existing profile data. However, we have
avoided this to keep the code simple, and because some kind of metadata
tag will be required to identify which branch/switch/select instructions
are influenced by the use of llvm.expect
Patch By: paulkirth
Differential Revision: https://reviews.llvm.org/D66324
llvm-svn: 371484
I see in the history for some of these tests REQUIRES:shell was used as
a way to disable tests on Windows because they are flaky there. I tried
not to re-enable such tests, but it's possible that I missed some and
this will re-enable flaky tests on Windows. If so, we should disable
them with UNSUPPORTED:system-windows and add a comment that they are
flaky there. So far as I can tell, the lit internal shell is capable of
running all of these tests, and we shouldn't use REQUIRES:shell as a
proxy for Windows.
llvm-svn: 371478
Checkers are now required to specify whether they're creating a
path-sensitive report or a path-insensitive report by constructing an
object of the respective type.
This makes BugReporter more independent from the rest of the Static Analyzer
because all Analyzer-specific code is now in sub-classes.
Differential Revision: https://reviews.llvm.org/D66572
llvm-svn: 371450
Summary:
Appease failed builds (due to -Werror and -Wswitch) where OMPRT_Unknown
is not handled in the switch statement (even though it's handled by the
early exit).
This fixes -Wswitch triggered by r371442.
Reviewers: srhines, danalbert, jdoerfert
Subscribers: guansong, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D67364
llvm-svn: 371444
Heejin Ahn