This changes CrossWindows to look for -nostdinc instead of -nostdlibinc.
In addition, fixes a bug where -isystem-after options would be dropped
when called with -nostdinc.
Patch by Dave Lee!
llvm-svn: 306829
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
a c++17 aligned allocation/deallocation function that is unavailable in
the standard library on Apple platforms.
The aligned functions are implemented only in the following versions or
later versions of the OSes, so clang issues diagnostics if the deployment
target being targeted is older than these:
macosx: 10.13
ios: 11.0
tvos: 11.0
watchos: 4.0
The diagnostics are issued whenever the aligned functions are selected
except when the selected function has a definition in the same file.
If there is a user-defined function available somewhere else, option
-Wno-aligned-allocation-unavailable can be used to silence the
diagnostics.
rdar://problem/32664169
Differential Revision: https://reviews.llvm.org/D34574
llvm-svn: 306722
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
IAS is already used for MIPS64 in majority of Android projects.
Android MIPS64 uses N64 ABI. Set IAS as a default now.
Differential Revision: https://reviews.llvm.org/D34514
llvm-svn: 306280
Ananas is a home-brew operating system, mainly for amd64 machines. After
using GCC for quite some time, it has switched to clang and never looked
back - yet, having to manually patch things is annoying, so it'd be much
nicer if this was in the official tree.
More information:
https://github.com/zhmu/ananas/https://rink.nu/projects/ananas.html
Submitted by: Rink Springer
Differential Revision: https://reviews.llvm.org/D32936
llvm-svn: 306239
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
Also, don't use the outdated lib32/lib64 naming of files
within the sysroot. The more modern/flexible approach
IIUC is to use seperate sysroots or /lib/<target-tripple>
and /include/<target-tripple>.
Differential Revision: https://reviews.llvm.org/D33565
llvm-svn: 306074
deployment target if the SDK is newer than the system
This commit also reverts follow-up commits r305680 and r305685 that have
buildbot fixes.
The change in r305678 wasn't correct because it relied on
`llvm::sys::getProcessTriple`, which uses a pre-configured OS version. We should
lookup the actual macOS version of the system on which the compiler is running.
llvm-svn: 305891
That commit failed on non-macOS buildbots as I've forgotten to make sure that
the system on which Clang is running on is actually macOS.
llvm-svn: 305680
if the SDK is newer than the system
This commit improves the driver by making sure that it picks the system version
for the deployment target when the version of the macOS SDK is newer than the
system version.
rdar://29449467
Differential Revision: https://reviews.llvm.org/D34175
llvm-svn: 305678
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
The test in r304929 broke multiple buildbots as it expected mips target to
be registered and available (which is not necessarily true). Updating the
test with this condition.
Original commit:
[mips] Add runtime options to enable/disable madd.fmt and msub.fmt
Add options to clang: -mmadd4 and -mno-madd4, use it to enable or disable
generation of madd.fmt and similar instructions respectively, as per GCC.
Patch by Stefan Maksimovic.
llvm-svn: 304953
Revert r304929 since the test broke buildbots.
Original commit:
[mips] Add runtime options to enable/disable madd.fmt and msub.fmt
Add options to clang: -mmadd4 and -mno-madd4, use it to enable or disable
generation of madd.fmt and similar instructions respectively, as per GCC.
Patch by Stefan Maksimovic.
llvm-svn: 304935
Add options to clang: -mmadd4 and -mno-madd4, use it to enable or disable
generation of madd.fmt and similar instructions respectively, as per GCC.
Patch by Stefan Maksimovic.
Differential Revision: https://reviews.llvm.org/D33401
llvm-svn: 304929
When cross-compiling to Windows using lld, we want the driver to invoke
it as lld-link rather than lld-link.exe. On Windows, the LLVM fs
functions take care of adding the .exe suffix where necessary, so we can
just drop the addition in the toolchain entirely.
Differential Revision: https://reviews.llvm.org/D33923
llvm-svn: 304761
separate section, by Sergey Dmitriev
Linker script that is generated by the clang driver for creating fat binary puts target binaries for all offload targets into a single ELF section .omp_offloading. This is not convenient because it greatly complicates operations with the final fat binary once it is linked. For example extracting target binary for a particular target from such fat executable would not be an easy task if you have more than one offload target.
Attached patch changes clang driver to put target binary for each
offload target into a separate ELF section .omp_offloading.<target
triple>.
Differential Revision: https://reviews.llvm.org/D33254
llvm-svn: 304229
Also comes with a cmake cache for building the runtime bits:
$ cmake <normal cmake flags> \
-DBAREMETAL_ARMV6M_SYSROOT=/path/to/sysroot \
-DBAREMETAL_ARMV7M_SYSROOT=/path/to/sysroot \
-DBAREMETAL_ARMV7EM_SYSROOT=/path/to/sysroot \
-C /path/to/clang/cmake/caches/BaremetalARM.cmake \
/path/to/llvm
https://reviews.llvm.org/D33259
llvm-svn: 303873
Add the toolchain installation directory to the program
path so that lld can be found.
Change -flavor to wasm. Although this new flavor hasn't
yet landed in upstream lld yet there are no point in
passing wasm objects the gnu flavor.
Differential Revision: https://reviews.llvm.org/D32976
llvm-svn: 302558
This is because -print-multi-lib depends on them being flags for correctness.
Fixes a case of this in the arm-android multilib selection logic.
llvm-svn: 302207
When building with libc++ don't bother with injecting the libstdc++
search paths into the linker search path. This will make it easier to
switch between ld and lld.
llvm-svn: 302184
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
Previously, adding libfuzzer to a project was a multi-step procedure,
involving libfuzzer compilation, linking the library, and specifying
coverage flags.
With this change,libfuzzer can be enabled by adding a single
-fsanitize=fuzzer flag instead.
llvm-svn: 301212
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
Summary:
Support for leak sanitizer on darwin has been added to
compiler-rt, this patch adds compiler support.
Reviewers: dexonsmith, compnerd
Subscribers: alekseyshl, kubamracek, cfe-commits
Differential Revision: https://reviews.llvm.org/D32192
llvm-svn: 300894
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
The config-*triple* file handling isn't tolerant of
leading/trailing whitespace, making it not terribly
obvious when a single extraneous tab/space/etc will
cause the override to be ignored. This patch simply
trims the lines to ensure that it is tolerant of
whitespace.
llvm-svn: 300328
Remove "REQUIRES: long_tests" from test/Driver/response-file.c since it is now about 10x faster. (We can add that back if it's still too slow for some buildbot.)
llvm-svn: 300136
crtbegin is not really a proper windows support thing. This was
duplicated when the toolchain was initially built. If the injection of
crtbegin is needed, it can be done via the `/include` directive.
Furthermore, since `-fPIC` doesnt make sense on PE/COFF, crtbegin and
crtbeginS dont really need to be different.
llvm-svn: 299800
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
Summary:
This change depends on D31381 where we change the implementation to use
sanitizer_common provided atomic operations library.
Fixes http://llvm.org/PR32274.
Reviewers: pelikan, dblaikie
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D31382
llvm-svn: 298835
Summary:
Now that XRay doesn't require a runtime dependency on a C++ standard
library, we remove that dependency from the clang linker flags.
Reviewers: saugustine, pelikan
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D31313
llvm-svn: 298670
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
clang-cl works best when the user runs vcvarsall to set up
an environment before running, but even this is not enough
on VC 2017 when cross compiling (e.g. using an x64 toolchain
to target x86, or vice versa).
The reason is that although clang-cl itself will have a
valid environment, it will shell out to other tools (such
as link.exe) which may not. Generally we solve this through
adding the appropriate linker flags, but this is not enough
in VC 2017.
The cross-linker and the regular linker both link against
some common DLLs, but these DLLs live in the binary directory
of the native linker. When setting up a cross-compilation
environment through vcvarsall, it will add *both* directories
to %PATH%, so that when cl shells out to any of the associated
tools, those tools will be able to find all of the dependencies
that it links against. If you don't do this, link.exe will
fail to run because the loader won't be able to find all of
the required DLLs that it links against.
To solve this we teach the driver how to spawn a process with
an explicitly specified environment. Then we modify the
PATH before shelling out to subtools and run with the modified
PATH.
Patch by Hamza Sood
Differential Revision: https://reviews.llvm.org/D30991
llvm-svn: 298098
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
-m(i|tv|watch)os-simulator-version-min is on the command line.
Previously the driver would treat -m(i|tv|watch)os-simulator-version-min
as an alias of -m(i|tv|watch)os-version-min. This no longer works since
we now need to distinguish between the two options (the latter is used
for iOS running in a VM, for example).
This commit stops making the simulator options the aliases of the OS
options and defines a macro to differentiate between the two groups of
options.
rdar://problem/28872911
llvm-svn: 297866
2017 changes the way you find an installed copy of
Visual Studio as well as its internal directory layout.
As a result, clang-cl was unable to find VS2017 even
when you had run vcvarsall to set up a toolchain
environment. This patch updates everything for 2017
and cleans up the way we handle a tiered search a la
environment -> installation -> PATH for which copy
of Visual Studio to bind to.
Patch originally by Hamza Sood, with some fixups for landing.
Differential Revision: https://reviews.llvm.org/D30758
llvm-svn: 297851
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 patch adds -f[no-]rtlib-add-rpath, which if enabled, embeds the
arch-specific subdirectory in resource directory using -rpath (instead
of doing so only during native compilation).
This patch also re-enables test arch-specific-libdir.c which was
silently unsupported because of the REQUIRES tag 'linux'.
Reviewers: bkramer, rnk, mgorny
Subscribers: srhines, cfe-commits
Differential Revision: https://reviews.llvm.org/D30700
llvm-svn: 297751
- Mips is architecture, not a toolchain
- Might help eliminate the confusion in the future by not having header files with the same name
Differential Revision: https://reviews.llvm.org/D30753
llvm-svn: 297312
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
Saleem Abdulrasool