The commit r310291 introduced the failure. r310332 was a test fix commit and
r310300 was a followup commit. I reverted these two to avoid merge conflicts
when reverting.
The 'openmp-offload.c' test is failing on Darwin because the following
run lines:
// RUN: touch %t1.o
// RUN: touch %t2.o
// RUN: %clang -### -no-canonical-prefixes -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda -save-temps -no-canonical-prefixes %t1.o %t2.o 2>&1 \
// RUN: | FileCheck -check-prefix=CHK-TWOCUBIN %s
trigger the following assertion:
Driver.cpp:3418:
assert(CachedResults.find(ActionTC) != CachedResults.end() &&
"Result does not exist??");
llvm-svn: 310345
This commit fixes a bug where clang/llvm doesn't emit an unwind table
for a function when it is marked noexcept. Without this patch, the
following code terminates with an uncaught exception on ARM64:
int foo1() noexcept {
try {
throw 0;
} catch (int i) {
return 0;
}
return 1;
}
int main() {
return foo1();
}
rdar://problem/32411865
Differential Revision: https://reviews.llvm.org/D35693
llvm-svn: 310006
This option when combined with -mgpopt and -membedded-data places all
uninitialized constant variables in the read-only section.
Reviewers: atanasyan, nitesh.jain
Differential Revision: https://reviews.llvm.org/D35917
llvm-svn: 309940
Add support for the -membedded-data option which places constant data in
the .rodata section, rather than the .sdata section.
Reviewers: atanasyan, nitesh.jain
Differential Revision: https://reviews.llvm.org/D35914
llvm-svn: 309935
Add support for -m(no-)extern-data when using -mgpopt in the driver. It is
enabled by default in the backend.
Reviewers: atanasyan, slthakur
Differential Revision: https://reviews.llvm.org/D35550
llvm-svn: 308879
This patch teaches the driver to pass -mgpopt by default to the backend when it
is supported, i.e. we are using -mno-abicalls.
Reviewers: atanasyan, slthakur
Differential Revision: https://reviews.llvm.org/D35548
This version fixes a logic error that generated warnings incorrectly and
gets rid of spurious arguments to the backend when -mgpopt is not used.
llvm-svn: 308619
This patch teaches the driver to pass -mgpopt by default to the backend when it
is supported, i.e. we are using -mno-abicalls.
Reviewers: atanasyan, slthakur
Differential Revision: https://reviews.llvm.org/D35548
This version fixes a logic error that generated warnings incorrectly.
llvm-svn: 308458
This patch teaches the driver to pass -mgpopt by default to the backend when it
is supported, i.e. we are using -mno-abicalls.
Reviewers: atanasyan, slthakur
Differential Revision: https://reviews.llvm.org/D35548
llvm-svn: 308431
Summary: Pass the type of the device offloading when building the tool chain for a particular target architecture. This is required when supporting multiple tool chains that target a single device type. In our particular use case, the OpenMP and CUDA tool chains will use the same ```addClangTargetOptions ``` method. This enables the reuse of common options and ensures control over options only supported by a particular tool chain.
Reviewers: arpith-jacob, caomhin, carlo.bertolli, ABataev, jlebar, hfinkel, tstellar, Hahnfeld
Reviewed By: hfinkel
Subscribers: jgravelle-google, aheejin, rengolin, jfb, dschuff, sbc100, cfe-commits
Differential Revision: https://reviews.llvm.org/D29647
llvm-svn: 307272
-fslp-vectorize-aggressive and -fno-slp-vectorize-aggressive flags back
under this group and test for the warning. Document the future removal
in the ReleaseNotes.
Differential Revision: https://reviews.llvm.org/D34926
llvm-svn: 306965
Summary:
Un-revert https://reviews.llvm.org/D34868, but with a slight tweak to the
documentation to fix an error -- I had used the wrong syntax for a link.
llvm-svn: 306948
Summary:
Depends on https://reviews.llvm.org/D34867.
Add a Clang frontend option to enable optimization remark hotness
thresholds, which were added to LLVM in https://reviews.llvm.org/D34867.
This prevents diagnostics that do not meet a minimum hotness
threshold from being output. When generating optimization remarks for large
codebases with a ton of cold code paths, this option can be used
to limit the optimization remark output at a reasonable size.
Discussion of this change can be read here:
http://lists.llvm.org/pipermail/llvm-dev/2017-June/114377.html
Reviewers: anemet, davidxl, hfinkel
Reviewed By: anemet
Subscribers: fhahn, cfe-commits
Differential Revision: https://reviews.llvm.org/D34868
llvm-svn: 306945
basic block vectorizer. This vectorizer has had no known users for many,
many years and is completely surpassed by the normal
'-fvectorize-slp'-controlled SLP vectorizer in LLVM.
Hal proposed this back in 2014 to no objections:
http://lists.llvm.org/pipermail/llvm-dev/2014-November/079091.html
While this patch completely removes the flag, Joerg is working on
a patch that will add it back in a way that warns users and ignores the
flag in a clear and well factored way (so that we can keep doing this
going forward).
Differential Revision: https://reviews.llvm.org/D34846
llvm-svn: 306786
Summary: The preprocessing and code generation and optimization stages of the compiler are also passed the "-fopenmp-is-device" flag. This is used to trigger machine specific preprocessing and code generation when performing device offloading to an NVIDIA GPU via OpenMP directives.
Reviewers: arpith-jacob, caomhin, carlo.bertolli, Hahnfeld, hfinkel, tstellar
Reviewed By: Hahnfeld
Subscribers: Hahnfeld, rengolin
Differential Revision: https://reviews.llvm.org/D29645
llvm-svn: 306691
Summary: Device offloading requires the specification of an additional flag containing the triple of the //other// architecture the code is being compiled on if such an architecture exists. If compiling for the host, the auxiliary triple flag will contain the triple describing the device and vice versa.
Reviewers: arpith-jacob, sfantao, caomhin, carlo.bertolli, ABataev, Hahnfeld, jlebar, hfinkel, tstellar
Reviewed By: Hahnfeld
Subscribers: rengolin, cfe-commits
Differential Revision: https://reviews.llvm.org/D29339
llvm-svn: 306689
Restore the `-gz` option to the driver with some minor tweaks to handle
the additional case for `-Wa,--compress-debug-sections`.
This intends to make the compression of the debug information
controllable from the driver. The following is the behaviour:
-gz enable compression (ambiguous for format, will default to zlib-gnu)
-gz=none disable compression
-gz=zlib-gnu enable compression (deprecated GNU style zlib compression)
-gz=zlib enable compression (zlib based compression)
Although -Wa,-compress-debug-sections works, it should be discouraged
when using the driver to invoke the assembler. However, we permit the
assembler to accept the GNU as style argument --compress-debug-sections
to maintain compatibility.
Note, -gz/-gz= does *NOT* imply -g. That is, you need to additionally
specific -g for debug information to be generated.
llvm-svn: 306115
This is a patch for bug: https://bugs.llvm.org/show_bug.cgi?id=6817
Warnings should not be emitted with -M and -MM flags, because this mode
is only used for generate MakeFiles.
llvm-svn: 305561
cc1as does not currently access the "--" version of this flag. At the
very least this needs to be fixed and proper test cases need to be
added.
Simple reproducer:
clang -Wa,--compress-debug-sections /tmp/test.cc
Result:
error: unknown argument: '--compress-debug-sections'
llvm-svn: 305182
Split the no-ias tests and give them a target to ensure that they go
down the GNU toolchain path. Adjust the no compression support tests.
llvm-svn: 305167
These options control the behaviour of the compression of debug info
sections on ELF targets. Our behaviour slightly diverges from the
behaviour of GCC. `-gz` maps to the `-compress-debug-sections` rather
than `-compress-debug-sections=zlib` or
`-compress-debug-sections=zlib-gnu`. This small divergence allows us to
be compatible across versions of binutils (=zlib support was introduced
in 2.26, while earlier versions only support =zlib-gnu). This also
allows users to not have to worry about the version of the assembler
they may be using if they are not using the IAS. Previously, users
would have had to go through the internal option
`-compress-debug-sectionss` and pass that through to the assembler,
which is no longer needed.
llvm-svn: 305165
Rather than validating the flags, pass them through without any
validation. Arguments passed via -Wa or -Xassembler are passed directly
to the assembler without validation. The validation was previously
required since we did not provide proper driver level support for
controlling the debug compression on ELF targets. A subsequent change
will add support for the `-gz` and `-gz=` flags which provide proper
driver level control of the ELF compressed debug sections.
llvm-svn: 305164
If specified, when preprocessing, the contents of imported .pcm files will be
included in preprocessed output. The resulting preprocessed file can then be
compiled standalone without the module sources or .pcm files.
llvm-svn: 305116
Since -gsplit-dwarf is specified on a backend compile (in ThinLTO
parlance) it isn't passed during the frontend compile (because no ELF
object/dwo file is produced then), yet the -fno-split-dwarf-inlining
value needs to be encoded in the LLVM DebugInfo metadata to have
effect...
So let it be specified & it'll be silently ignored if -gsplit-dwarf
isn't used in the end, otherwise it'll be used on a per-cu basis
depending on where it's specified in the frontend compile actions.
llvm-svn: 301684
Since Split DWARF needs to name the actual .dwo file that is generated,
it can't be known at the time the llvm::Module is produced as it may be
merged with other Modules before the object is generated and that object
may be generated with any name.
By passing the Split DWARF file name when LLVM is producing object code
the .dwo file name in the object file can match correctly.
The support for Split DWARF for implicit modules remains the same -
using metadata to store the dwo name and dwo id so that potentially
multiple skeleton CUs referring to different dwo files can be generated
from one llvm::Module.
llvm-svn: 301063
This commit teaches Clang to recognize editor placeholders that are produced
when an IDE like Xcode inserts a code-completion result that includes a
placeholder. Now when the lexer sees a placeholder token, it emits an
'editor placeholder in source file' error and creates an identifier token
that represents the placeholder. The parser/sema can now recognize the
placeholders and can suppress the diagnostics related to the placeholders. This
ensures that live issues in an IDE like Xcode won't get spurious diagnostics
related to placeholders.
This commit also adds a new compiler option named '-fallow-editor-placeholders'
that silences the 'editor placeholder in source file' error. This is useful
for an IDE like Xcode as we don't want to display those errors in live issues.
rdar://31581400
Differential Revision: https://reviews.llvm.org/D32081
llvm-svn: 300667
The driver needs to know whether it's building a module interface or
implementation unit because it affects which outputs it produces and how it
builds the command pipeline. But the frontend doesn't need to know and should
not care: all it needs to know is what action it is being asked to perform on
the input.
(This is in preparation for permitting -emit-obj to be used on a module
interface unit to produce object code without going via a "full" PCM file.)
llvm-svn: 300611
This passes an option to the ARM assembly parser to emit build
attributes for the hardware selected by command line options, when
assembling an assembly file.
This is not enabled for C/C++, as this would result in duplicate build
attribute directives being emitted in each inline assembly block, when
emitting assembly.
This also adds an option to allow disabling this behaviour for assembly
files, for users who were relying on the old behaviour.
Differential revision: https://reviews.llvm.org/D31813
llvm-svn: 300550
Summary:
The -fxray-always-instrument= and -fxray-never-instrument= flags take
filenames that are used to imbue the XRay instrumentation attributes
using a whitelist mechanism (similar to the sanitizer special cases
list). We use the same syntax and semantics as the sanitizer blacklists
files in the implementation.
As implemented, we respect the attributes that are already defined in
the source file (i.e. those that have the
[[clang::xray_{always,never}_instrument]] attributes) before applying
the always/never instrument lists.
Reviewers: rsmith, chandlerc
Subscribers: jfb, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30388
llvm-svn: 299041
The alias was only ever used on darwin and had some issues there,
and isn't used in practice much. Also fixes a problem with -mno-altivec
not turning off -maltivec.
Also add a diagnostic for faltivec/fno-altivec that directs users to use
maltivec options and include the altivec.h file explicitly.
llvm-svn: 298449
Summary: We need to be able to disable samplepgo for specific files by supporting -fno-auto-profile and -fno-profile-sample-use
Reviewers: davidxl, dnovillo, echristo
Reviewed By: echristo
Subscribers: echristo, cfe-commits
Differential Revision: https://reviews.llvm.org/D31213
llvm-svn: 298446
Currently the two flags can not work together.
To illustrate the issue, we can have an one line file a.cl contains only an empty function
cat a.cl
void test(){}
Then use
clang -v -save-temps -x cl -Xclang -cl-std=CL2.0 -Xclang -finclude-default-header -target amdgcn -S -c a.cl
we will get redefinition errors for various things.
The reason is that the -finclude-default-header flag is not meant to be on cc1 command other than the preprocessor.
The fix is modeled after the code just below the change to filter the -finclude-default-header flag out when we are not in the preprocess phase.
Differential Revision: https://reviews.llvm.org/D30743
llvm-svn: 297890
The way -ffast-math and the various related options to tweak floating-point
handling are handled is inflexible and rather confusing. This patch restructures
things so that we go through the options adjusting our idea of what's enabled as
we go, instead of trying to figure each individual thing out by working
backwards from the end, as this makes the behaviour of each individual option
more clear.
Doing it this way also means we get gcc-compatible behaviour for when the
__FAST_MATH__ and __FINITE_MATH_ONLY__ macros are defined, as they should depend
on the final set of features that are enabled and not just on -ffast-math and
-ffinite-math-only specifically.
Differential Revision: http://reviews.llvm.org/D30582
llvm-svn: 297837
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)
This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.
There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.
I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.
There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.
Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar
Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D30372
llvm-svn: 297250
Alex Lorenz