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
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
Summary:
There is no such library on NetBSD, the corresponding functions like dlopen(3) are in libc.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, vitalybuka, eugenis
Reviewed By: vitalybuka
Subscribers: dberris, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D41021
llvm-svn: 320220
This is a follow-on to D40724 (Wasm entrypoint changes #1,
add `--undefined` argument to LLD).
Patch by Nicholas Wilson
Differential Revision: https://reviews.llvm.org/D40739
llvm-svn: 319623
To be compatible with GCC if soft floating point is in effect any FPU
specified is effectively ignored, eg,
-mfloat-abi=soft -fpu=neon
If any floating point features which require FPU hardware are enabled
they must be disable.
There was some support for doing this for NEON, but it did not handle
VFP, nor did it prevent the backend from emitting the build attribute
Tag_FP_arch describing the generated code as using the floating point
hardware if a FPU was specified (even though soft float does not use
the FPU).
Disabling the hardware floating point features for targets which are
compiling for soft float has meant that some tests which were incorrectly
checking for hardware support also needed to be updated. In such cases,
where appropriate the tests have been updated to check compiling for
soft float and a non-soft float variant (usually softfp). This was
usually because the target specified in the test defaulted to soft float.
Differential Revision: https://reviews.llvm.org/D40256
llvm-svn: 319420
Summary:
The -fxray-always-emit-customevents flag instructs clang to always emit
the LLVM IR for calls to the `__xray_customevent(...)` built-in
function. The default behaviour currently respects whether the function
has an `[[clang::xray_never_instrument]]` attribute, and thus not lower
the appropriate IR code for the custom event built-in.
This change allows users calling through to the
`__xray_customevent(...)` built-in to always see those calls lowered to
the corresponding LLVM IR to lay down instrumentation points for these
custom event calls.
Using this flag enables us to emit even just the user-provided custom
events even while never instrumenting the start/end of the function
where they appear. This is useful in cases where "phase markers" using
__xray_customevent(...) can have very few instructions, must never be
instrumented when entered/exited.
Reviewers: rnk, dblaikie, kpw
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D40601
llvm-svn: 319388
../tools/clang/lib/Driver/ToolChains/Cuda.cpp:80:18: error: reference to non-static member function must be called; did you mean to call it with no arguments?
if (Distro(D.getVFS).IsDebian())
~~^~~~~~
()
llvm-svn: 319322
This is a re-apply of r319294.
adds -fseh-exceptions and -fdwarf-exceptions flags
clang will check if the user has specified an exception model flag,
in the absense of specifying the exception model clang will then check
the driver default and append the model flag for that target to cc1
-fno-exceptions has a higher priority then specifying the model
move __SEH__ macro definitions out of Targets into InitPreprocessor
behind the -fseh-exceptions flag
move __ARM_DWARF_EH__ macrodefinitions out of verious targets and into
InitPreprocessor behind the -fdwarf-exceptions flag and arm|thumb check
remove unused USESEHExceptions from the MinGW Driver
fold USESjLjExceptions into a new GetExceptionModel function that
gives the toolchain classes more flexibility with eh models
Reviewers: rnk, mstorsjo
Differential Revision: https://reviews.llvm.org/D39673
llvm-svn: 319297
adds -fseh-exceptions and -fdwarf-exceptions flags
clang will check if the user has specified an exception model flag,
in the absense of specifying the exception model clang will then check
the driver default and append the model flag for that target to cc1
clang cc1 assumes dwarf is the default if none is passed
and -fno-exceptions has a higher priority then specifying the model
move __SEH__ macro definitions out of Targets into InitPreprocessor
behind the -fseh-exceptions flag
move __ARM_DWARF_EH__ macrodefinitions out of verious targets and into
InitPreprocessor behind the -fdwarf-exceptions flag and arm|thumb check
remove unused USESEHExceptions from the MinGW Driver
fold USESjLjExceptions into a new GetExceptionModel function that
gives the toolchain classes more flexibility with eh models
Reviewers: rnk, mstorsjo
Differential Revision: https://reviews.llvm.org/D39673
llvm-svn: 319294
The WebAssembly standard does not yet have threads, and while it's in the
process of being standardized, it'll take some time for it to make it
through and be available in all popular implementations. With increasing
numbers of people using the LLVM wasm backend through LLVM directly rather
than through Emscripten, it's increasingly important to have friendly
defaults.
See also https://bugs.llvm.org/show_bug.cgi?id=35411
llvm-svn: 319101
Summary:
Switch CPU names not recognized by GNU assembler to a close CPU that it
does recognize. In this patch, kryo, falkor and saphira all get
replaced by cortex-a57 when invoking the assembler. In addition, krait
was already being replaced by cortex-a15.
Reviewers: weimingz
Subscribers: srhines, cfe-commits
Differential Revision: https://reviews.llvm.org/D40476
llvm-svn: 319077
Summary:
Enable for x86_64:
- ESan,
- KASan,
- MSan.
Enable for x86_64 and i386:
- Scudo.
These features are under active development and in various level of completeness.
Sponsored by <The NetBSD Foundation>
Reviewers: dvyukov, joerg, vitalybuka, eugenis
Reviewed By: eugenis
Subscribers: llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D40456
llvm-svn: 319007
The support for relax relocations is dependent on the linker and
different toolchains within the same compiler can be using different
linkers some of which may or may not support relax relocations.
Give toolchains the option to control whether they want to use relax
relocations in addition to the existing (global) build system option.
Differential Revision: https://reviews.llvm.org/D39831
llvm-svn: 318816
This is an instrumentation flag that's similar to
-finstrument-functions, but it only inserts calls on function entry, the
calls are inserted post-inlining, and they don't take any arugments.
This is intended for users who want to instrument function entry with
minimal overhead.
(-pg would be another alternative, but forces frame pointer emission and
affects link flags, so is probably best left alone to be used for
generating gcov data.)
Differential revision: https://reviews.llvm.org/D40276
llvm-svn: 318785
This was previously done in some places, but for example not for
bundling so that single object compilation with -c failed. In
addition cubin was used for all file types during unbundling which
is incorrect for assembly files that are passed to ptxas.
Tighten up the tests so that we can't regress in that area.
Differential Revision: https://reviews.llvm.org/D40250
llvm-svn: 318763
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
Patch By: mibintc
Differential Revision: https://reviews.llvm.org/D34158
llvm-svn: 318669
The Unified Arm Assembler Language is designed so that the majority of
assembler files can be assembled for both Arm and Thumb with the choice
made as a compilation option.
The way this is done in gcc is to pass -mthumb to the assembler with either
-Wa,-mthumb or -Xassembler -mthumb. This change adds support for these
options to clang. There is no assembler equivalent of -mno-thumb, -marm or
-mno-arm so we don't need to recognize these.
Ideally we would do all of the processing in
CollectArgsForIntegratedAssembler(). Unfortunately we need to change the
triple and at that point it is too late. Instead we look for the option
earlier in ComputeLLVMTriple().
Fixes PR34519
Differential Revision: https://reviews.llvm.org/D40127
llvm-svn: 318647
set -pie as default for musl linux targets
add detection of alpine linux
append appropriate compile flags for alpine
Reviewers: rnk
Differential Revision: https://reviews.llvm.org/D39588
llvm-svn: 318608
This updates -mcount to use the new attribute names (LLVM r318195), and
switches over -finstrument-functions to also use these attributes rather
than inserting instrumentation in the frontend.
It also adds a new flag, -finstrument-functions-after-inlining, which
makes the cygprofile instrumentation get inserted after inlining rather
than before.
Differential Revision: https://reviews.llvm.org/D39331
llvm-svn: 318199
llvm-objcopy is getting to where it can be used in non-trivial ways
(such as for dwarf fission in clang). It now supports dwarf fission but
this feature hasn't been thoroughly tested yet. This change allows
people to optionally build clang to use llvm-objcopy rather than GNU
objcopy. By default GNU objcopy is still used so nothing should change.
Differential Revision: https://reviews.llvm.org/D39029
llvm-svn: 317960
Summary:
This change implements the changes required in both clang and
compiler-rt to allow building XRay-instrumented binaries in Darwin. For
now we limit this to x86_64. We also start building the XRay runtime
library in compiler-rt for osx.
A caveat to this is that we don't have the tests set up and running
yet, which we'll do in a set of follow-on changes.
This patch uses the monorepo layout for the coordinated change across
multiple projects.
Reviewers: kubamracek
Subscribers: mgorny, cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D39114
llvm-svn: 317875
Summary:
This is basically reverting r261774 with a tweak for clang-cl. UNIX
standard states:
When c99 encounters a compilation error that causes an object file not
to be created, it shall write a diagnostic to standard error and
continue to compile other source code operands, but it shall not perform
the link phase and it shall return a non-zero exit status
The same goes for c89 or cc. And they are all alias or shims pointing to
clang on Darwin.
The original commit was intended for CUDA so the error message doesn't
get emit twice for both host and device. It seems that the clang driver
has been changed to model the CUDA dependency differently. Now the
driver behaves the same without this commit.
rdar://problem/32223263
Reviewers: thakis, dexonsmith, tra
Reviewed By: tra
Subscribers: jlebar, cfe-commits
Differential Revision: https://reviews.llvm.org/D39502
llvm-svn: 317860
Summary:
This change allows binutils to be used for linking with MSVC. Currently, when
using an MSVC target and `-fuse-ld=bfd`, the driver produces an invalid linker
invocation.
Reviewers: rnk, compnerd
Reviewed By: compnerd
Subscribers: smeenai, cfe-commits
Differential Revision: https://reviews.llvm.org/D39509
llvm-svn: 317511
This is a re-apply of rL313082 which was reverted in rL313088
In rL289668 the ability to specify the default linker at compile time
was added but because the MinGW driver used custom detection we could
not take advantage of this new CMAKE flag CLANG_DEFAULT_LINKER.
rL289668 added no test cases and the mingw driver was either overlooked
or purposefully skipped because it has some custom linker tests
Removing them here because they are covered by the generic case.
Reviewers: rnk
Differntial Revision: https://reviews.llvm.org/D37727
llvm-svn: 317397
Summary:
This change adds Scudo as a possible Sanitizer option via -fsanitize=.
This allows for easier static & shared linking of the Scudo library, it allows
us to enforce PIE (otherwise the security of the allocator is moot), and check
for incompatible Sanitizers combo.
In its current form, Scudo is not compatible with any other Sanitizer, but the
plan is to make it work in conjunction with UBsan (-fsanitize=scudo,undefined),
which will require additional work outside of the scope of this change.
Reviewers: eugenis, kcc, alekseyshl
Reviewed By: eugenis, alekseyshl
Subscribers: llvm-commits, srhines
Differential Revision: https://reviews.llvm.org/D39334
llvm-svn: 317337
Summary:
CUDA doesn't support errno at all, so this is the right thing -- or at
least, in the right direction.
But also, this unbreaks the CUDA test-suite math tests [0] after D39481.
__cuda_cmath.h forwards nexttoward() to __builtin_nexttoward, which,
after that patch, was lowering to a libcall that doesn't exist in NVPTX.
[0] http://lab.llvm.org:8011/builders/clang-cuda-build/builds/14999
Reviewers: tra
Subscribers: sanjoy, cfe-commits
Differential Revision: https://reviews.llvm.org/D39586
llvm-svn: 317297
Added support for regcall as default calling convention. Also added code to
exclude main when applying default calling conventions.
Patch-By: eandrews
Differential Revision: https://reviews.llvm.org/D39210
llvm-svn: 317268
Summary:
This change allows generalizing pointers in type signatures used for
cfi-icall by enabling the -fsanitize-cfi-icall-generalize-pointers flag.
This works by 1) emitting an additional generalized type signature
metadata node for functions and 2) llvm.type.test()ing for the
generalized type for translation units with the flag specified.
This flag is incompatible with -fsanitize-cfi-cross-dso because it would
require emitting twice as many type hashes which would increase artifact
size.
Reviewers: pcc, eugenis
Reviewed By: pcc
Subscribers: kcc
Differential Revision: https://reviews.llvm.org/D39358
llvm-svn: 317044
AAPCS and AAPCS64 mandate that `wchar_t` with `-fno-short-wchar` is an
`unsigned int` rather than a `signed int`. Ensure that the driver does
not flip the signedness of `wchar_t` for those targets.
Add additional tests to ensure that this does not regress.
llvm-svn: 316858
Also, for OS unknown targets like wasm, don't include
'unknown' in the library path. This is a fix for rL316719.
Differential Revision: https://reviews.llvm.org/D39354
llvm-svn: 316777
clang currently uses .init_array instead of .ctors on Linux if it detects gcc
4.7+. Make it so that it also uses .init_array if no gcc installation is found
at all – if there's no old gcc, there's nothing we need to be compatible with.
icecc for example runs clang in a very small chroot, so before this change
clang would use .ctors if run under icecc. And lld currently silently mislinks
inputs with .ctors sections, so before this clang + icecc + lld would produce
broken binaries. (But this seems like a good change independent of that lld
bug.)
https://reviews.llvm.org/D39317
llvm-svn: 316713
Summary:
CUDA 9's minimum sm is sm_30.
Ideally we should also make sm_30 the default when compiling with CUDA
9, but that seems harder than it should be.
Subscribers: sanjoy
Differential Revision: https://reviews.llvm.org/D39109
llvm-svn: 316611
Summary:
Also enable -no-pie on Gnu toolchain (previously available on Darwin only).
Non-PIE executables won't even start on recent Android, and DT_RPATH is ignored by the loader.
Reviewers: srhines, danalbert
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D38430
llvm-svn: 316606
When -mtune is used on AArch64 the -target-cpu is passed the value of the
cpu given to -mtune. As well as setting micro-architectural features of the
-mtune cpu, this will also add the architectural features such as support
for instructions. This can result in the backend using instructions that
are supported in the -mtune cpu but not supported in the target
architecture. For example use of the v8.1-a LSE extensions with -march=v8.
This change removes the setting of -target-cpu for -mtune, the -mcpu must
be used to set -target-cpu. This has the effect of removing all non-hard
coded benefits of mtune but it does produce correct output when -mtune cpu
with a later architecture than v8 is used.
Fixes PR34625
Differential Revision: https://reviews.llvm.org/D39179
llvm-svn: 316424
Passing a flavor to LLD requires command line argument, but if these
are being passed through a response file, this will fail because LLD
needs to know which driver to use before processing the response file.
Use ld.lld directly instead to avoid this issue.
Differential Revision: https://reviews.llvm.org/D39176
llvm-svn: 316379
GCC tries to shorten system headers in depfiles using its real path
(resolving components like ".." and following symlinks). Mimic this
feature to ensure that the Ninja build tool detects the correct
dependencies when a symlink changes directory levels, see
https://github.com/ninja-build/ninja/issues/1330
An option to disable this feature is added in case "these changed header
paths may conflict with some compilation environments", see
https://gcc.gnu.org/ml/gcc-patches/2012-09/msg00287.html
Note that the original feature request for GCC
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52974) also included paths
preprocessed output (-E) and diagnostics. That is not implemented now
since I am not sure if it breaks something else.
Differential Revision: https://reviews.llvm.org/D37954
llvm-svn: 316193
This patch has the following changes
A new flag "-mhvx-length={64B|128B}" is introduced to specify the length of the vector.
Previously we have used "-mhvx-double" for 128 Bytes. This adds the target-feature "+hvx-length{64|128}b"
The "-mhvx" flag must be provided on command line to enable HVX for Hexagon. If no -mhvx-length flag
is specified, a default length is picked from the arch mentioned in this priority order from either -mhvx=vxx
or -mcpu. For v60 and v62 the default length is 64 Byte. For unknown versions, the length is 128 Byte. The
-mhvx flag adds the target-feature "+hvxv{hvx_version}"
The 64 Byte mode is soon going to be deprecated. A warning is emitted if 64 Byte is enabled. A warning is
still emitted for the default 64 Byte as well. This warning can be suppressed with a -Wno flag.
The "-mhvx-double" and "-mno-hvx-double" flags are deprecated. A warning is emitted if the driver sees
them on commandline. "-mhvx-double" is an alias to "-mhvx-length=128B"
The compilation will error out if -mhvx-length is specified with out an -mhvx/-mhvx= flag
The macro HVX_LENGTH is defined and is set to the length of the vector.
Eg: #define HVX_LENGTH 64
The macro HVX_ARCH is defined and is set to the version of the HVX.
Eg: #define HVX_ARCH 62
Differential Revision: https://reviews.llvm.org/D38852
llvm-svn: 316102
For the shuffle instructions in reductions we need at least sm_30
but the user may want to customize the default architecture.
Differential Revision: https://reviews.llvm.org/D38883
llvm-svn: 315996
Summary:
The OS provides cross-dso CFI support starting with Android O.
Trapping mode does not require any runtime at all, and diagnostic mode
requires just ubsan-standalone.
Reviewers: pcc
Subscribers: srhines, cfe-commits
Differential Revision: https://reviews.llvm.org/D38908
llvm-svn: 315921
Currently all the consecutive bitfields are wrapped as a large integer unless there is unamed zero sized bitfield in between. The patch provides an alternative manner which makes the bitfield to be accessed as separate memory location if it has legal integer width and is naturally aligned. Such separate bitfield may split the original consecutive bitfields into subgroups of consecutive bitfields, and each subgroup will be wrapped as an integer. Now This is all controlled by an option -ffine-grained-bitfield-accesses. The alternative of bitfield access manner can improve the access efficiency of those bitfields with legal width and being aligned, but may reduce the chance of load/store combining of other bitfields, so it depends on how the bitfields are defined and actually accessed to choose when to use the option. For now the option is off by default.
Differential revision: https://reviews.llvm.org/D36562
llvm-svn: 315915
If the user passes -nocudalib, we can live without it being present.
Simplify the code by just checking whether LibDeviceMap is empty.
Differential Revision: https://reviews.llvm.org/D38901
llvm-svn: 315902
When using lld on macOS the current level of detection between ld and
ld64 forces us to rename lld to ld.
For ELF targets we have the ld.lld alias so for MACHO we should have
ld64.lld so we can use lld without replacing the system compiler.
This also solves the additional issue of cross compiling for MACHO
where renaming lld to ld with only target ELF.
This is the clang driver component change to use this new alias.
Reviewers: ruiu, rnk
Differential Revision: https://reviews.llvm.org/D38290
llvm-svn: 315867
This reverts commit 4e4ee1c507e2707bb3c208e1e1b6551c3015cbf5.
This is failing due to some code that isn't built on MSVC
so I didn't catch. Not immediately obvious how to fix this
at first glance, so I'm reverting for now.
llvm-svn: 315536
There's a lot of misuse of Twine scattered around LLVM. This
ranges in severity from benign (returning a Twine from a function
by value that is just a string literal) to pretty sketchy (storing
a Twine by value in a class). While there are some uses for
copying Twines, most of the very compelling ones are confined
to the Twine class implementation itself, and other uses are
either dubious or easily worked around.
This patch makes Twine's copy constructor private, and fixes up
all callsites.
Differential Revision: https://reviews.llvm.org/D38767
llvm-svn: 315530
Apple's API verification tool (tapi) checks that the symbols exported
from a program match a whitelist. When the program uses the profile
runtime, some additional symbols which are typically not part of the
regular whitelist must be exported.
If we're using symbol export directives along with the profile runtime
on Darwin, the driver needs to export the additional symbols to avoid
verification failures.
rdar://problem/30067753
llvm-svn: 315518
Move the logic for determining the `wchar_t` type information into the
driver. Rather than passing the single bit of information of
`-fshort-wchar` indicate to the frontend the desired type of `wchar_t`
through a new `-cc1` option of `-fwchar-type` and indicate the
signedness through `-f{,no-}signed-wchar`. This replicates the current
logic which was spread throughout Basic into the
`RenderCharacterOptions`.
Most of the changes to the tests are to ensure that the frontend uses
the correct type. Add a new test set under `test/Driver/wchar_t.c` to
ensure that we calculate the proper types for the various cases.
llvm-svn: 315126
Summary:
This raises our default past 1900, which controls whether char16_t is a
builtin type or not.
Implements PR34243
Reviewers: hans
Subscribers: STL_MSFT, rsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D38646
llvm-svn: 315107
Summary:
* Rename -shared-libasan to -shared-libsan, keeping the old name as alias.
* Add -static-libsan for targets that default to shared.
* Remove an Android special case. It is now possible (but untested) to use static compiler-rt libraries there.
* Support libclang_rt.ubsan_standalone as a shared library.
Unlike GCC, this change applies -shared-libsan / -static-libsan to all sanitizers.
I don't see a point in multiple flags like -shared-libubsan, considering that most sanitizers
are not compatible with each other, and each link has basically a single shared/static choice.
Reviewers: vitalybuka, kcc, rsmith
Subscribers: srhines, cfe-commits
Differential Revision: https://reviews.llvm.org/D38525
llvm-svn: 315015
Passes 'new-pass-manager' option to the linker plugin when the new pass
manager is enabled.
Patch by Graham Yiu.
Differential Revision: https://reviews.llvm.org/D38517
llvm-svn: 314964
The recent fix in D38258 was wrong: getAuxTriple() only returns
non-null values for the CUDA toolchain. That is why the now added
test for PPC and X86 failed.
Differential Revision: https://reviews.llvm.org/D38372
llvm-svn: 314902
to have child entries describing the template parameters. This will
be on by default for SCE tuning.
Differential Revision: https://reviews.llvm.org/D14358
llvm-svn: 314444
ToolChain::TranslateArgs() returns nullptr if no changes are performed.
This would currently mean that OpenMPArgs are lost. Patch fixes this
by falling back to simply using OpenMPArgs in that case.
Differential Revision: https://reviews.llvm.org/D38259
llvm-svn: 314330
AuxTriple is not set if host and device share a toolchain. Also,
removing an argument modifies the DAL which needs to be returned
for future use.
(Move tests back to offload-openmp.c as they are not related to GPUs.)
Differential Revision: https://reviews.llvm.org/D38258
llvm-svn: 314329
Parsing the argument after -Xopenmp-target allocates memory that needs
to be freed. Associate it with the final DerivedArgList after we know
which one will be used.
Differential Revision: https://reviews.llvm.org/D38257
llvm-svn: 314328
Summary: If we only use the compiler front-end, do not throw an error about the cuda device library not being found. This allows the front-end to be run on systems where no Cuda installation is found.
Reviewers: Hahnfeld, ABataev, carlo.bertolli, caomhin, tra
Reviewed By: tra
Subscribers: hfinkel, tra, cfe-commits
Differential Revision: https://reviews.llvm.org/D37914
llvm-svn: 314217
Summary:
This change ensures that we don't link in the XRay runtime when building
shared libraries with clang. This doesn't prevent us from building
shared libraris tht have XRay instrumentation sleds, but it does prevent
us from linking in the static XRay runtime into a shared library.
The XRay runtime currently doesn't support dynamic registration of
instrumentation sleds in shared objects, which we'll start enabling in
the future. That work has to happen in the back-end and in the runtime.
Reviewers: rnk, pelikan
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D38226
llvm-svn: 314188
Summary:
This change ensures that we don't link in the XRay runtime when building
shared libraries with clang. This doesn't prevent us from building
shared libraris tht have XRay instrumentation sleds, but it does prevent
us from linking in the static XRay runtime into a shared library.
The XRay runtime currently doesn't support dynamic registration of
instrumentation sleds in shared objects, which we'll start enabling in
the future. That work has to happen in the back-end and in the runtime.
Reviewers: rnk, pelikan
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D38226
llvm-svn: 314177
Summary: Enable the -nocudalib flag for the OpenMP device offloading toolchain as well. Currently it can only be used for the CUDA toolchain.
Reviewers: Hahnfeld, ABataev, carlo.bertolli, caomhin, hfinkel, tra
Reviewed By: tra
Subscribers: hfinkel, cfe-commits
Differential Revision: https://reviews.llvm.org/D37913
llvm-svn: 314164
Summary: When composing the output file name, the path to the file is being dropped. The full path is required.
Reviewers: Hahnfeld, ABataev, caomhin, carlo.bertolli, hfinkel, tra
Reviewed By: tra
Subscribers: hfinkel, tra, cfe-commits
Differential Revision: https://reviews.llvm.org/D37912
llvm-svn: 314156
Summary: If we only use the compiler front-end, do not throw an error about the cuda device library not being found. This allows the front-end to be run on systems where no Cuda installation is found.
Reviewers: Hahnfeld, ABataev, carlo.bertolli, caomhin, tra
Reviewed By: tra
Subscribers: hfinkel, tra, cfe-commits
Differential Revision: https://reviews.llvm.org/D37914
llvm-svn: 314150
These arguments don't (not yet at least) make sense for
the wasm lld port.
Subscribers: jfb, dschuff, jgravelle-google, aheejin
Differential Revision: https://reviews.llvm.org/D36595
llvm-svn: 313299
This reverts rL313102 because it still fails some build bot tests.
On many linux bots it fails with the following error.
error: invalid linker name in argument '-fuse-ld=lld'
and on some windows bots also because there is no ld.lld.exe
lld-link.exe: warning: ignoring unknown argument: -fuse-ld=lld
llvm-svn: 313104
In rL289668 the ability to specify the default linker at compile time
was added but because the MinGW driver used custom detection we could
not take advantage of this new CMAKE flag CLANG_DEFAULT_LINKER.
This is a re-apply of rL313082 which was reverted in rL313088
due to failing buildbot tests.
Differential Revision: https://reviews.llvm.org/D37727
llvm-svn: 313102
We make the same decision when compiling the kernel or kexts -- we
should do this in -ffreestanding mode as well to avoid size regressions
in a potentially large set of firmware projects.
It's still possible to get uwtable information in -ffreestanding mode by
compiling with -funwind-tables (I expect this to be a rare case: I
certainly haven't seen any projects like that).
Context: -munwind-tables was enabled by default for some arm targets in
r310006.
Testing: check-clang
rdar://problem/33934446
Differential Revision: https://reviews.llvm.org/D37777
llvm-svn: 313087
In rL289668 the ability to specify the default linker at compile time
was added but because the MinGW driver used custom detection we could
not take advantage of this new CMAKE flag CLANG_DEFAULT_LINKER.
llvm-svn: 313082
While building a project with code coverage enabled, we can link in
dependencies which export a weak definition of __llvm_profile_filename.
After r306710, linking in the profiling runtime could pull in a weak
definition of this symbol from a dependency, instead of from within the
runtime's archive.
This inconsistency causes issues during API verification, and is also a
practical problem (the symbol would go missing were the dependent dylib
to be switched out). Introduce a LinkFirst runtime link option to make
sure we always search the profiling runtime for this symbol first.
rdar://problem/33271080
Differential Revision: https://reviews.llvm.org/D35385
llvm-svn: 313065
This regressed for x86-64 in r307856 because it's no longer inherited
from Generic_GCC. We'd never noticed that it was missing other
targets (i.e. aarch64), but Fuchsia is uniform across all machines.
Patch by Roland McGrath
Differential Revision: https://reviews.llvm.org/D37723
llvm-svn: 312989
This primarily impacts the Windows MSVC and Windows itanium
environments. Windows MSVC does not use `__cxa_atexit` and Itanium
follows suit. Simplify the logic for the default value calculation and
blanket the Windows environments to default to off for use of
`__cxa_atexit`.
llvm-svn: 312941
The ToolChain class validates the -mthread-model flag in the constructor which
doesn't work correctly since the thread model methods are virtual methods. The
check is moved into Clang::ConstructJob() when constructing the internal
command line.
https://reviews.llvm.org/D37496
Patch by: Ian Tessier!
llvm-svn: 312748
For now CUDA-9 is not included in the list of CUDA versions clang
searches for, so the path to CUDA-9 must be explicitly passed
via --cuda-path=.
On LLVM side NVPTX added sm_70 GPU type which bumps required
PTX version to 6.0, but otherwise is equivalent to sm_62 at the moment.
Differential Revision: https://reviews.llvm.org/D37576
llvm-svn: 312734
The new bare metal support only supports the single thread model. This causes
the builtin atomic functions (e.g.: __atomic_fetch_add) to not generate
thread-safe assembly for these operations, which breaks our firmware. We target
bare metal, and need to atomically modify variables in our interrupt routines,
and task threads.
Internally, the -mthread-model flag determines whether to lower or expand
atomic operations (see D4984).
This change removes the overridden thread model methods, and instead relies on
the base ToolChain class to validate the thread model (which already includes
logic to validate single thread model support). If the single thread model is
required, the -mthread-model flag will have to be provided.
As a workaround "-mthread-model posix" could be provided, but it only works due
to a bug in the validation of the -mthread-model flag (separate patch coming to
fix this).
https://reviews.llvm.org/D37493
Patch by: Ian Tessier!
llvm-svn: 312651
This code has been `#if 0`'ed out for a very long time. After speaking
with Duncan, opt to remove it even if it is something which should be
fixed. If the underlying issue is still valid, this can be restored
with proper explanation and tests.
llvm-svn: 312618
Summary:
Currently clang segfaults when invoked with `clang --autocomplete=`.
This patch adds the necessary boundary checks and some tests for corner cases like this.
Reviewers: yamaguchi
Reviewed By: yamaguchi
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D37465
llvm-svn: 312533
In current OpenCL implementation some options are set in OpenCL RT/Driver, which causes discrepancy between online and offline paths.
Implement infrastructure to move options from OpenCL RT/Driver to AMDGPUToolChain using overloaded TranslateArgs() method.
Create map for default options values, as Options.td doesn't support default values (in contrast with OPTIONS.def).
Add two driver options: -On and -mNN (like -O3, -m64).
Some minor formatting changes to follow the clang-format style.
Differential Revision: https://reviews.llvm.org/D37386
llvm-svn: 312524
Extract the target specific option application. This is a huge switch
which was inlined into the `ConstructJob` option which adds a large
amount of code to the already large function. Extract it to simply
reduce the line count. NFC
llvm-svn: 312436
Out-of-line the logic for selecting the debug information handling.
This is still split across the new function and partially inline in the
job construction. This is needed since the split portion attempts to
record the "-cc1" arguments. This needs to be the very last item to
ensure that all the flags are recorded. NFC.
llvm-svn: 312435
Extract the handling of the `-fbuiltin` family of flags to the driver.
This centralises the handling of those options, keeping the long
standing `#if 0`'ed block of code. This requires some additional code
archaeology to determine if we need to enable this functionality.
llvm-svn: 312392
Extract the logic for the floating point handling into its own function.
None of this information is needed for calculating the remainder of the
arguments to the frontend. NFC
llvm-svn: 312385
Extract a function to render the diagnostics options to the clang
frontend. This continues the simplification of the clang cc1 command
line invocation generation. NFC
llvm-svn: 312351
Extract the ObjC option rendering for the frontend. This localises the
option translation. It augments the existing `AddRuntimeObjCOptions`
which handles the runtime/ABI versioning flags only. This new function
handles the non-runtime selecting flags. This logic was previously
inlined into the `ConstructJob` function.
Minor change to the flag ordering to group the blocks related flags
together.
llvm-svn: 312344
Extract a function to render the options related to modules. This
reduces the cyclomatic complexity of the `ConstructJob` function. NFC.
llvm-svn: 312330
Summary:
Currently object format is taken from the default target triple. For toolchains with a non-COFF default target this may result in an object format inappropriate for pc-windows and lead to compilation issues.
For example, the default triple `aarch64-linux-elf` may produce something like `aarch64-pc-windows-msvc19.0.24215-elf` in CL mode. Clang creates `MicrosoftARM64TargetInfo` for such triple with data layout `e-m:w-p:64:64-i32:32-i64:64-i128:128-n32:64-S128`. On the other hand, the AArch64 backend in `computeDataLayout` detects a non-COFF target and selects `e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128` as data layout for little endian. Different layouts used by clang and the backend cause an error:
```
error: backend data layout 'e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128'
does not match expected target description 'e-m:w-p:64:64-i32:32-i64:64-i128:128-n32:64-S128'
```
This can be observed on the clang's Driver/cl-pch.c test with AArch64 as a default target.
This patch enforces COFF in CL mode.
Reviewers: hans
Reviewed By: hans
Subscribers: cfe-commits, aemerson, asl, kristof.beyls
Differential Revision: https://reviews.llvm.org/D37336
llvm-svn: 312275
Extract the ARC migration tool flag handling into its own function.
This simplifies the flow of the clang frontend command line construction
function. NFC.
llvm-svn: 312244
Extend the -fmodule-file option to support the [<name>=]<file> value format.
If the name is omitted, then the old semantics is preserved (the module file
is loaded whether needed or not). If the name is specified, then the mapping
is treated as just another prebuilt module search mechanism, similar to
-fprebuilt-module-path, and the module file is only loaded if actually used
(e.g., via import). With one exception: this mapping also overrides module
file references embedded in other modules (which can be useful if module files
are moved/renamed as often happens during remote compilation).
This override semantics requires some extra work: we now store the module name
in addition to the file name in the serialized AST representation.
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D35020
llvm-svn: 312220
Extract the analyzer flag handling into its own function to reduce the
overall complexity of the construction of the clang compiler arguments.
NFC.
llvm-svn: 312124
Extend the -fmodule-file option to support the [<name>=]<file> value format.
If the name is omitted, then the old semantics is preserved (the module file
is loaded whether needed or not). If the name is specified, then the mapping
is treated as just another prebuilt module search mechanism, similar to
-fprebuilt-module-path, and the module file is only loaded if actually used
(e.g., via import). With one exception: this mapping also overrides module
file references embedded in other modules (which can be useful if module files
are moved/renamed as often happens during remote compilation).
This override semantics requires some extra work: we now store the module name
in addition to the file name in the serialized AST representation.
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D35020
llvm-svn: 312105
Out-of-line the SSP argument handling for the sake of readability. Pass
along some state information to avoid re-computing the command line
flags.
llvm-svn: 312084
Extract the argument forwarding for OpenCL arguments. Make this more
data driven as we are just repeating the argument name and spelling.
This costs a slight bit more memory due to the string duplication, but
makes it easier to follow. It should be possible to forward the
internal string representation from the TableGen data to avoid this.
But, this makes the code simpler to follow for now.
llvm-svn: 312083
Summary:
Recent changes canonicalized clang_rt library names to refer to
"i386" on all x86 targets. Android historically uses i686.
This change adds a special case to keep i686 in all clang_rt
libraries when targeting Android.
Reviewers: hans, mgorny, beanz
Subscribers: srhines, cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D37278
llvm-svn: 312048
Summary:
An implementation of ubsan runtime library suitable for use in production.
Minimal attack surface.
* No stack traces.
* Definitely no C++ demangling.
* No UBSAN_OPTIONS=log_file=/path (very suid-unfriendly). And no UBSAN_OPTIONS in general.
* as simple as possible
Minimal CPU and RAM overhead.
* Source locations unnecessary in the presence of (split) debug info.
* Values and types (as in A+B overflows T) can be reconstructed from register/stack dumps, once you know what type of error you are looking at.
* above two items save 3% binary size.
When UBSan is used with -ftrap-function=abort, sometimes it is hard to reason about failures. This library replaces abort with a slightly more informative message without much extra overhead. Since ubsan interface in not stable, this code must reside in compiler-rt.
Reviewers: pcc, kcc
Subscribers: srhines, mgorny, aprantl, krytarowski, llvm-commits
Differential Revision: https://reviews.llvm.org/D36810
llvm-svn: 312029
Summary:
We wrote many codes in HandleImediateArgs, so I've refactored it into
handleAutocompletions.
Reviewers: v.g.vassilev, teemperor
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D37249
llvm-svn: 312018
Information about clang executable name components, such as target and
driver mode, was passes in std::pair. With this change it is passed in
a special structure. It improves readability and makes access to this
information more convenient.
NFC.
Differential Revision: https://reviews.llvm.org/D36057
llvm-svn: 311981
This reverts commit 7c46b80c022e18d43c1fdafb117b0c409c5a6d1e.
r311552 broke lld buildbot because I've changed OptionInfos type from
ArrayRef to vector. However the bug is fixed, so I'll commit this again.
llvm-svn: 311958
Use llvm::Triple::getArchTypeName() when looking for compiler-rt
libraries, rather than the exact arch string from the triple. This is
more correct as it matches the values used when building compiler-rt
(builtin-config-ix.cmake) which are the subset of the values allowed
in triples.
For example, this fixes an issue when the compiler set for
i686-pc-linux-gnu triple would not find an i386 compiler-rt library,
while this is the exact arch that is detected by compiler-rt. The same
applies to any other i?86 variant allowed by LLVM.
This also makes the special case for MSVC unnecessary, since now i386
will be used reliably for all 32-bit x86 variants.
Differential Revision: https://reviews.llvm.org/D26796
llvm-svn: 311923
Use llvm::Triple::getArchTypeName() when looking for compiler-rt
libraries, rather than the exact arch string from the triple. This is
more correct as it matches the values used when building compiler-rt
(builtin-config-ix.cmake) which are the subset of the values allowed
in triples.
For example, this fixes an issue when the compiler set for
i686-pc-linux-gnu triple would not find an i386 compiler-rt library,
while this is the exact arch that is detected by compiler-rt. The same
applies to any other i?86 variant allowed by LLVM.
This also makes the special case for MSVC unnecessary, since now i386
will be used reliably for all 32-bit x86 variants.
Differential Revision: https://reviews.llvm.org/D26796
llvm-svn: 311836
This patch adds a flag -fclang-abi-compat that can be used to request that
Clang attempts to be ABI-compatible with some older version of itself.
This is provided on a best-effort basis; right now, this can be used to undo
the ABI change in r310401, reverting Clang to its prior C++ ABI for pass/return
by value of class types affected by that change, and to undo the ABI change in
r262688, reverting Clang to using integer registers rather than SSE registers
for passing <1 x long long> vectors. The intent is that we will maintain this
backwards compatibility path as we make ABI-breaking fixes in future.
The reversion to the old behavior for r310401 is also applied to the PS4 target
since that change is not part of its platform ABI (which is essentially to do
whatever Clang 3.2 did).
llvm-svn: 311823
Summary: With accurate sample profile, we can do more aggressive size optimization. For some size-critical application, this can reduce the text size by 20%
Reviewers: davidxl, rsmith
Reviewed By: davidxl, rsmith
Subscribers: mehdi_amini, eraman, sanjoy, cfe-commits
Differential Revision: https://reviews.llvm.org/D37091
llvm-svn: 311707
In patch r205628 using abs.[ds] instruction is forced, as they should behave
in accordance with flags Has2008 and ABS2008. Unfortunately for revisions
prior mips32r6 and mips64r6, abs.[ds] is not generating correct result when
working with NaNs. To generate a sequence which always produce a correct
result but also to allow user more control on how his code is compiled,
option -mabs is added where user can choose legacy or 2008.
By default legacy mode is used on revisions prior R6. Mips32r6 and mips64r6
use abs2008 mode by default.
Patch by Aleksandar Beserminji
Differential Revision: https://reviews.llvm.org/D35982
llvm-svn: 311669
Summary:
This is a patch for clang autocomplete feature.
It will collect values which -analyzer-checker takes, which is defined in
clang/StaticAnalyzer/Checkers/Checkers.inc, dynamically.
First, from ValuesCode class in Options.td, TableGen will generate C++
code in Options.inc. Options.inc will be included in DriverOptions.cpp, and
calls OptTable's addValues function. addValues function will add second
argument to Option's Values class. Values contains string like "foo,bar,.."
which is handed to Values class
in OptTable.
Reviewers: v.g.vassilev, teemperor, ruiu
Subscribers: hiraditya, cfe-commits
Differential Revision: https://reviews.llvm.org/D36782
llvm-svn: 311552
Rename the function getSupportedNanEncoding() to getIEEE754Standard(), since
this function will be used for non-nan related features.
Patch by Aleksandar Beserminji.
Differential Revision: https://reviews.llvm.org/D36824
llvm-svn: 311454
supplied.
With this change, -fno-exceptions disables unwind tables unless
-funwind-tables is supplied too or the target is x86-64 (x86-64 requires
emitting unwind tables).
rdar://problem/33934446
llvm-svn: 311397
This is a reasonably non-intrusive change, which I've verified
works for both x86 and x64 DevDiv-internal builds.
The idea is to change `bool IsVS2017OrNewer` into a 3-state
`ToolsetLayout VSLayout`. Either a build is DevDiv-internal,
released VS 2017 or newer, or released VS 2015 or older. When looking at
the directory structure, if instead of `"VC"` we see `"x86ret"`, `"x86chk"`,
`"amd64ret"`, or `"amd64chk"`, we recognize this as a DevDiv-internal build.
After we get past the directory structure validation, we use this knowledge
to regenerate paths appropriately. `llvmArchToDevDivInternalArch()` knows how
we use `"i386"` subdirectories, and `MSVCToolChain::getSubDirectoryPath()`
uses that. It also knows that DevDiv-internal builds have an `"inc"`
subdirectory instead of `"include"`.
This may still not be the "right" fix in any sense, but I believe that it's
non-intrusive in the sense that if the special directory names aren't found,
no codepaths are affected. (`ToolsetLayout::OlderVS` and
`ToolsetLayout::VS2017OrNewer` correspond to `IsVS2017OrNewer` being `false`
or `true`, respectively.) I searched for all references to `IsVS2017OrNewer`,
which are places where Clang cares about VS's directory structure, and the
only one that isn't being patched is some logic to deal with
cross-compilation. I'm fine with that not working for DevDiv-internal builds
for the moment (we typically test the native compilers), so I added a comment.
Fixes D36860.
llvm-svn: 311391
Summary:
Augment SanitizerCoverage to insert maximum stack depth tracing for
use by libFuzzer. The new instrumentation is enabled by the flag
-fsanitize-coverage=stack-depth and is compatible with the existing
trace-pc-guard coverage. The user must also declare the following
global variable in their code:
thread_local uintptr_t __sancov_lowest_stack
https://bugs.llvm.org/show_bug.cgi?id=33857
Reviewers: vitalybuka, kcc
Reviewed By: vitalybuka
Subscribers: kubamracek, hiraditya, cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D36839
llvm-svn: 311186
If a struct would end up half in GPRs and half on SP the ABI says it should
actually go entirely on the stack. We were getting this wrong in GlobalISel
before, causing compatibility issues.
llvm-svn: 311137
Using Output.getFilename() to construct the file name used for optimization
recording in Clang::ConstructJob, when -c is provided, does not work correctly
if we're not using the integrated assembler. With -no-integrated-as (or
-save-temps) Output.getFilename() gives the name of the temporary assembly
file, not the final output file. Instead, use the final output (as provided by
-o). If this is not available, then fall back to using a name based on the
input file.
Fixes PR31532.
llvm-svn: 311041
Summary:
Relanding https://reviews.llvm.org/D35739 which was reverted because
it broke the tests on non-Linux. The tests have been fixed to be
platform agnostic, and additional tests have been added to make sure
that the plugin has the correct extension on each platform
(%pluginext doesn't work in CHECK lines).
Reviewers: srhines, pirama
Reviewed By: srhines
Subscribers: emaste, mehdi_amini, eraman, cfe-commits
Differential Revision: https://reviews.llvm.org/D36769
llvm-svn: 310960
Summary:
It's only named LLVMgold.so on Linux. Fix the name for Windows and
Darwin.
Also fix the path for Windows so binutils doesn't have to.
Reviewers: srhines, pirama
Reviewed By: srhines
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D35739
llvm-svn: 310895
rL310433 introduced a code path where DAL is not returned and must be freed.
This change allows to run openmp-offload.c when Clang is built with ASan.
llvm-svn: 310817
The flag will perform instrumentation necessary to the fuzzing,
but will NOT link libLLVMFuzzer.a library.
Necessary when modifying CFLAGS for projects which may produce
executables as well as a fuzzable target.
Differential Revision: https://reviews.llvm.org/D36600
llvm-svn: 310733
Create a separate test file to contain all tests for OpenMP
offloading to GPUs.
Make libdevice checking more robust by accounting for
the case in which no libdevice is found.
This changes are in connrection with diff: D29660
llvm-svn: 310718
As clang defaults to -mno-abicalls when using -fno-pic for N64, implicitly use
-mgpopt in that case.
Reviewers: atanasyan
Differential Revision: https://reviews.llvm.org/D36315
llvm-svn: 310714
While we do not support `-mshared / -mno-shared` properly, show warning
and ignore `-mlong-calls` option in case of implicitly or explicitly
provided `-mabicalls` option.
Differential revision: https://reviews.llvm.org/D36551
llvm-svn: 310614
The -mabicalls option does not make sense in the case of non position
independent code for the N64 ABI. After this change the driver shows a
warning that -mabicalls is ignored in that case.
Differential revision: https://reviews.llvm.org/D36550
llvm-svn: 310613
This makes it possible to print the name of compiler-rt libraries
by using simply clang -print-file-name=libclang_rt.${runtime}-${arch}.so
same as other libraries, without having to know the details of the
resource directory organization.
Differential Revision: https://reviews.llvm.org/D35820
llvm-svn: 310548
Summary: Invoking the compiler inside a script causes the clang-offload-bundler executable to not be found. This patch enables the lookup for executables in the driver directory where the clang-offload-bundler resides.
Reviewers: hfinkel, carlo.bertolli, arpith-jacob, ABataev, caomhin
Reviewed By: hfinkel
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D36537
llvm-svn: 310513
Summary:
This flag "--fopenmp-ptx=" enables the overwriting of the default PTX version used for GPU offloaded OpenMP target regions: "+ptx42".
Reviewers: arpith-jacob, caomhin, carlo.bertolli, ABataev, Hahnfeld, jlebar, hfinkel, tstellar
Reviewed By: ABataev
Subscribers: rengolin, cfe-commits
Differential Revision: https://reviews.llvm.org/D29660
llvm-svn: 310489
Summary: Previously we have added the "-c" flag which gets passed to PTXAS by default to generate relocatable OpenMP target code by default. This set of flags exposes control over this behaviour.
Reviewers: arpith-jacob, caomhin, carlo.bertolli, ABataev, Hahnfeld, jlebar, hfinkel, tstellar
Reviewed By: ABataev
Subscribers: Hahnfeld, rengolin, cfe-commits
Differential Revision: https://reviews.llvm.org/D29659
llvm-svn: 310484
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
Summary: When device offloading is enabled and the device is an NVIDIA GPU, OpenMP target regions must be compiled with relocation enabled by passing the "-c" flag to the PTXAS invocation.
Reviewers: arpith-jacob, caomhin, carlo.bertolli, ABataev, Hahnfeld, jlebar, hfinkel, tstellar
Reviewed By: Hahnfeld
Subscribers: Hahnfeld, rengolin, mkuron, cfe-commits
Differential Revision: https://reviews.llvm.org/D29642
llvm-svn: 310300
Summary: When compiling code being offloaded by OpenMP to an NVIDIA GPU, pass the -v to PTXAS if it was passed to the CLANG driver.
Reviewers: arpith-jacob, caomhin, carlo.bertolli, ABataev, jlebar, hfinkel, tstellar
Reviewed By: jlebar
Subscribers: Hahnfeld, rengolin, cfe-commits
Differential Revision: https://reviews.llvm.org/D29644
llvm-svn: 310295
Summary:
OpenMP has the ability to offload target regions to devices which may have different architectures.
A new -fopenmp-target-arch flag is introduced to specify the device architecture.
In this patch I use the new flag to specify the compute capability of the underlying NVIDIA architecture for the OpenMP offloading CUDA tool chain.
Only a host-offloading test is provided since full device offloading capability will only be available when [[ https://reviews.llvm.org/D29654 | D29654 ]] lands.
Reviewers: hfinkel, Hahnfeld, carlo.bertolli, caomhin, ABataev
Reviewed By: hfinkel
Subscribers: guansong, cfe-commits
Tags: #openmp
Differential Revision: https://reviews.llvm.org/D34784
llvm-svn: 310263
Summary:
Verified to work and useful to run check-asan, as this target tests 32-bit and 64-bit execution.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, filcab, dim, vitalybuka
Reviewed By: vitalybuka
Subscribers: #sanitizers, cfe-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D36378
llvm-svn: 310245
This is causing failures when compiling clang with -O3
as one of the structures used by clang is passed by
value and uses the fastcc calling convention.
Faliures manifest for stage2 mips build.
llvm-svn: 310057
Summary:
M-class profiles do not support ARM execution mode, so providing
-marm/-mno-thumb does not make sense in combination with -mcpu/-march
options that support the M-profile.
This is a follow-up patch to D35569 and it seemed pretty clear that we
should emit an error in the driver in this case.
We probably also should warn/error if the provided -mcpu/-march options
do not match, e.g. -mcpu=cortex-m0 -march=armv8-a is invalid, as
cortex-m0 does not support armv8-a. But that should be a separate patch
I think.
Reviewers: echristo, richard.barton.arm, rengolin, labrinea, charles.baylis
Reviewed By: rengolin
Subscribers: aemerson, javed.absar, kristof.beyls, cfe-commits
Differential Revision: https://reviews.llvm.org/D35826
llvm-svn: 310047
The .gnu_hash format is superior, and all versions of the Fuchsia
dynamic linker support it.
Differential Revision: https://reviews.llvm.org/D36254
llvm-svn: 310017
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
Summary:
This is to provide a default blacklist filename for UBSan.
While UBSan is turned on, it's better that clang pick up a blacklist file (when exists), just as what ASan / MSan does, so we do not end up adding the "-fsanitize-blacklist" option to every command line.
Reviewers: chandlerc, echristo, vsk, eugenis
Reviewed By: vsk, eugenis
Subscribers: vsk, eugenis, echristo, cfe-commits
Differential Revision: https://reviews.llvm.org/D35849
llvm-svn: 309873
In r309007, I made -fsanitize=null a hard prerequisite for -fsanitize=vptr. I
did not see the need for the two checks to have separate null checking logic
for the same pointer. I expected the two checks to either always be enabled
together, or to be mutually compatible.
In the mailing list discussion re: r309007 it became clear that that isn't the
case. If a codebase is -fsanitize=vptr clean but not -fsanitize=null clean,
it's useful to have -fsanitize=vptr emit its own null check. That's what this
patch does: with it, -fsanitize=vptr can be used without -fsanitize=null.
Differential Revision: https://reviews.llvm.org/D36112
llvm-svn: 309846
This just adds the CPU to a list of commands passed to GAS when not using the
integrated assembler.
Differential Revision: https://reviews.llvm.org/D33820
llvm-svn: 309256
Summary:
`clang --autocomplete=-std` will show
```
-std: Language standard to compile for
-std= Language standard to compile for
-stdlib= C++ standard library to use
```
after this change.
However, showing HelpText with completion in bash seems super tricky, so
this feature will be used in other shells (fish, zsh...).
Reviewers: v.g.vassilev, teemperor, ruiu
Subscribers: cfe-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D35759
llvm-svn: 309113
The instrumentation generated by -fsanitize=vptr does not null check a
user pointer before loading from it. This causes crashes in the face of
UB member calls (this=nullptr), i.e it's causing user programs to crash
only after UBSan is turned on.
The fix is to make run-time null checking a prerequisite for enabling
-fsanitize=vptr, and to then teach UBSan to reuse these run-time null
checks to make -fsanitize=vptr safe.
Testing: check-clang, check-ubsan, a stage2 ubsan-enabled build
Differential Revision: https://reviews.llvm.org/D35735https://bugs.llvm.org/show_bug.cgi?id=33881
llvm-svn: 309007
Projects that want to statically link their own C++ standard library currently
need to pass -nostdlib or -nodefaultlibs, which also disables linking of the
builtins library, -lm, and so on. Alternatively, they could use `clang` instead
of `clang++`, but that already disables implicit addition of -lm on some
toolchains.
Add a dedicated flag -nostdlib++ that disables just linking of libc++ /
libstdc++. This is analogous to -nostdinc++.
https://reviews.llvm.org/D35780
llvm-svn: 308997
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
All but one place are checking options::OPT_nostdlib instead of looking at
this field, so convert that one other place to doing that as well.
No behavior change.
llvm-svn: 308848
The driver ignores -fsanitize-coverage=... flags when also given
-fsanitize=... flags for sanitizer flavors that don't support the
coverage runtime. This logic failed to account for subsequent
-fno-sanitize=... flags that disable the sanitizer flavors that
conflict with -fsanitize-coverage=... flags.
Patch by Roland McGrath
Differential Revision: https://reviews.llvm.org/D35603
llvm-svn: 308707
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
allocation functions.
This changes the error message Sema prints when an unavailable C++17
aligned allocation function is selected.
Original message: "... possibly unavailable on x86_64-apple-macos10.12"
New message: "... only available on macOS 10.13 or newer"
This is a follow-up to r306722.
rdar://problem/32664169
Differential Revision: https://reviews.llvm.org/D35520
llvm-svn: 308496
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
platforms.
Set the target OS based on -target if it is present on the command
line and -arch is not.
With this commit, "-target x86_64-apple-ios8.0" does the same thing as
"-arch x86_64 -mios-version-min=8.0".
rdar://problem/21012522
llvm-svn: 307982
Several improvements to the Fuchsia driver:
* Search for C++ library headers and libraries in directories that
are part of the toolchain distribution rather than sysroot.
* Use LLVM support utlities to construct paths to make sure the driver
is also usable on Windows for cross-compiling.
* Change the driver to inherit directly from ToolChain rather than
Generic_GCC since we don't need any of the GCC related multilib logic.
Differential Revision: https://reviews.llvm.org/D35328
llvm-svn: 307856
Several improvements to the Fuchsia driver:
* Search for C++ library headers and libraries in directories that
are part of the toolchain distribution rather than sysroot.
* Use LLVM support utlities to construct paths to make sure the driver
is also usable on Windows for cross-compiling.
* Change the driver to inherit directly from ToolChain rather than
Generic_GCC since we don't need any of the GCC related multilib logic.
Differential Revision: https://reviews.llvm.org/D32613
llvm-svn: 307830
Summary:
We don't want to autocomplete flags whose Flags class has `NoDriverOption` when argv[1] is not `-cc1`.
Another idea for this implementation is to make --autocomplete a cc1
option and handle it in clang Frontend, by porting --autocomplete
handler from Driver to Frontend, so that we can handle Driver options
and CC1 options in unified manner.
Differential Revision: https://reviews.llvm.org/D34770
llvm-svn: 307479
deployment target if the SDK is newer than the system
This commit reverts the revert commit r305891. Now the change from r305678
should be correct because `llvm::sys::getProcessTriple` now returns the correct
macOS version of the system after the LLVM change r307372.
Original commit message:
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: 307388
Check the `-mlong-calls` command line option and pass the `long-calls`
feature flag to the backend. Handling of this feature flag in the backend
needs to be implemented by a separate commit.
llvm-svn: 307386
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
Summary:
Enable LLVM asan sanitizer for NetBSD/amd64.
Don't generate -ldl for dlopen(3)-like functions on NetBSD.
These features are available in libc on NetBSD.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, eugenis, kcc, dim
Reviewed By: dim
Subscribers: #clang, #sanitizers
Tags: #clang, #sanitizers
Differential Revision: https://reviews.llvm.org/D34960
llvm-svn: 307104
-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
the target is 32-bit.
The following changes are made to the driver since 32-bit apps do not
run on iOS 11 or later:
- If the deployment target is set explicitly, either with a command-line
option or an environment variable, the driver should report an error
if the version is greater than iOS 10.
- In the case where the deployment target is not set explicitly and the
default is inferred from the target triple or SDK version, it should
use a maximum default of iOS 10.99.99.
rdar://problem/32230613
Differential Revision: https://reviews.llvm.org/D34529
llvm-svn: 306922
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
This is a more principled version of r303756. That change was both very
brittle about the state of the Diags object going into the driver and
also broke tooling in funny ways.
In particular it prevented tools from capturing diagnostics properly and
made the compilation database logic fail to provide arguments to the
tool, falling back to scanning directories for JSON files.
llvm-svn: 306822
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
This check currently isn't able to diagnose any issues at -O0, not is it
likely to [1]. Disabling the check at -O0 leads to substantial compile
time and binary size savings.
[1] [cfe-dev] Disabling ubsan's object size check at -O0
Differential Revision: https://reviews.llvm.org/D34563
llvm-svn: 306181
Currently, autocompleted options are displayed in the same order as we
wrote them in .td files. This patch sort them out in clang so that they
are sorted alphabetically. This should improve usability.
Differential Revision: https://reviews.llvm.org/D34557
llvm-svn: 306116
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
This is patch for GSoC project, bash-completion for clang.
To use this on bash, please run `source clang/utils/bash-autocomplete.sh`.
bash-autocomplete.sh is code for bash-completion.
In this patch, Options.td was mainly changed in order to add value class
in Options.inc.
llvm-svn: 305805
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
Summary:
In D33900, I added printing of the registered targets in clang's
`PrintVersion` function, which is not only used for `--version` output,
but also for `-v` (verbose mode) and `-###`. Especially the latter
seems to trip up some test cases, so it is probably better to only print
the registered targets for `--version`.
Reviewers: nemanjai, mehdi_amini
Reviewed By: nemanjai
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D33981
llvm-svn: 304899
Summary:
Other llvm tools display their registered targets when showing version
information, but for some reason clang has never done this.
To support this, D33899 adds the llvm parts, which make it possible to
print version information to arbitrary raw_ostreams. This change adds
a call to printRegisteredTargetsForVersion in clang's PrintVersion, and
adds a raw_ostream parameter to two other PrintVersion functions.
Reviewers: beanz, chandlerc, dberris, mehdi_amini, zturner
Reviewed By: mehdi_amini
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D33900
llvm-svn: 304836
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
This is recommit of r302775, reverted in r302777 due to a fail in
clang-tidy. Original mesage is below.
Now if clang driver is given wrong arguments, in some cases it
continues execution and returns zero code. This change fixes this
behavior.
The fix revealed some errors in clang test set.
File test/Driver/gfortran.f90 added in r118203 checks forwarding
gfortran flags to GCC. Now driver reports error on this file, because
the option -working-directory implemented in clang differs from the
option with the same name implemented in gfortran, in clang the option
requires argument, in gfortran does not.
In the file test/Driver/arm-darwin-builtin.c clang is called with
options -fbuiltin-strcat and -fbuiltin-strcpy. These option were removed
in r191435 and now clang reports error on this test.
File arm-default-build-attributes.s uses option -verify, which is not
supported by driver, it is cc1 option.
Similarly, the file split-debug.h uses options -fmodules-embed-all-files
and -fmodule-format=obj, which are not supported by driver.
Other revealed errors are mainly mistypes.
Differential Revision: https://reviews.llvm.org/D33013
llvm-svn: 303756
Summary:
This is a first patch for GSoC project, bash-completion for clang.
To use this on bash, please run `source clang/utils/bash-autocomplete.sh`.
bash-autocomplete.sh is code for bash-completion.
Simple flag completion and path completion is available in this patch.
Reviewers: teemperor, v.g.vassilev, ruiu, Bigcheese, efriedma
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D33237
llvm-svn: 303670
Now if clang driver is given wrong arguments, in some cases it
continues execution and returns zero code. This change fixes this
behavior.
The fix revealed some errors in clang test set.
File test/Driver/gfortran.f90 added in r118203 checks forwarding
gfortran flags to GCC. Now driver reports error on this file, because
the option -working-directory implemented in clang differs from the
option with the same name implemented in gfortran, in clang the option
requires argument, in gfortran does not.
In the file test/Driver/arm-darwin-builtin.c clang is called with
options -fbuiltin-strcat and -fbuiltin-strcpy. These option were removed
in r191435 and now clang reports error on this test.
File arm-default-build-attributes.s uses option -verify, which is not
supported by driver, it is cc1 option.
Similarly, the file split-debug.h uses options -fmodules-embed-all-files
and -fmodule-format=obj, which are not supported by driver.
Other revealed errors are mainly mistypes.
Differential Revision: https://reviews.llvm.org/D33013
llvm-svn: 302775
This feature is subtly broken when the linker is gold 2.26 or
earlier. See the following bug for details:
https://sourceware.org/bugzilla/show_bug.cgi?id=19002
Since the decision needs to be made at compilation time, we can not
test the linker version. The flag is off by default on ELF targets,
and on otherwise.
llvm-svn: 302591
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
When enabling any sanitizer, -fsanitize-use-after-scope is enabled by
default. This doesn't actually turn ASan on, because we've been getting
lucky and there are extra checks in BackendUtil that stop this from
happening.
However, this has been causing a behavior change: extra lifetime markers
are emitted in some cases where they aren't needed or expected.
llvm-svn: 302468
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
One way to currently test the reproducers is to setup
"FORCE_CLANG_DIAGNOSTICS_CRASH=1" before invoking clang. This simulates
a crash and produces the same contents needed by the reproducers. The
reproducers are specially useful when triaging Modules issues, not only
on crashes, but also for reproducing misleading warnings, errors, etc.
Add a '-gen-reproducer' driver option to clang (or any similar name) and
give users a flag option.
Note that clang already has a -fno-crash-diagnostics, which disables the
crash reproducers. I've decided not to propose "-fcrash-diagnostics"
since it doesn't convey the ideia of reproduction despite a crash.
rdar://problem/24114619
Differential Revision: https://reviews.llvm.org/D27604
llvm-svn: 300109
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
The commit yesterday (r299473) to add the `-print-resource-dir`
option was supposed to emit a newline after the resource dir.
Differential Revision: https://reviews.llvm.org/D31447
llvm-svn: 299597
This patch adds the option -print-resource-dir. It simply
prints the resource directory. This information will eventually
be used in compiler-rt to setup COMPILER_RT_LIBRARY_INSTALL_DIR.
Patch by Catherine Moore!
Differential Revision: https://reviews.llvm.org/D31447
llvm-svn: 299473
Summary:
The refactoring introduced a regression in the flag processing for
-fxray-instruction-threshold which causes it to not get passed properly.
This change should restore the previous behaviour.
Reviewers: rnk, pelikan
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D31491
llvm-svn: 299126
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
Teach UBSan to detect when a value with the _Nonnull type annotation
assumes a null value. Call expressions, initializers, assignments, and
return statements are all checked.
Because _Nonnull does not affect IRGen, the new checks are disabled by
default. The new driver flags are:
-fsanitize=nullability-arg (_Nonnull violation in call)
-fsanitize=nullability-assign (_Nonnull violation in assignment)
-fsanitize=nullability-return (_Nonnull violation in return stmt)
-fsanitize=nullability (all of the above)
This patch builds on top of UBSan's existing support for detecting
violations of the nonnull attributes ('nonnull' and 'returns_nonnull'),
and relies on the compiler-rt support for those checks. Eventually we
will need to update the diagnostic messages in compiler-rt (there are
FIXME's for this, which will be addressed in a follow-up).
One point of note is that the nullability-return check is only allowed
to kick in if all arguments to the function satisfy their nullability
preconditions. This makes it necessary to emit some null checks in the
function body itself.
Testing: check-clang and check-ubsan. I also built some Apple ObjC
frameworks with an asserts-enabled compiler, and verified that we get
valid reports.
Differential Revision: https://reviews.llvm.org/D30762
llvm-svn: 297700
- 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
Craig Topper