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
-mbranch-likely and -mno-branch-likely are used in some build systems for
some MIPS targets. Accept these options but ignore them as they are an
(de)optimiztion hint, and that branch likely instructions were deprecated
but not removed from MIPS32 and MIPS64 ISAs.
Reviewers: atanasyan, nitesh.jain
Differential Revision: https://reviews.llvm.org/D38168
llvm-svn: 314213
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
When clang is called as 'target-clang', put deduced target option at
the start of argument list so that option '--target=' specified in command
line could override it.
This change fixes PR34671.
llvm-svn: 313760
Summary: This test should have been updated in r313299
Subscribers: jfb, dschuff, jgravelle-google, aheejin
Differential Revision: https://reviews.llvm.org/D37873
llvm-svn: 313307
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
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
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 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
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:
Add support for autocompleting values of -std= by including
LangStandards.def. This patch relies on D36782, and is using two-stage
code generation.
Reviewers: v.g.vassilev, teemperor, ruiu
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D36820
llvm-svn: 311971
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
As before, not every platform supports LTO. Make sure the platform
we're targeting is one that supports it (regardless of the *host*
platform).
llvm-svn: 311488
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
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
-no-integrated-as is not supported on some targets (e.g.,
x86_64-pc-windows-msvc). Testing using -save-temps is good enough to cover the
relevant logic, and that should work everywhere.
llvm-svn: 311043
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
Not all targets will use -plugin with -flto. Pick a fixed target so
this works regardless of the default target (regardless of host OS,
the toolchain should be picking the correct LTO plugin for a target
that supports it).
llvm-svn: 310966
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
The %T lit expansion expands to a common directory shared between all the tests in the same directory, which is unexpected and unintuitive, and more importantly, it's been a source of subtle race conditions and flaky tests. In https://reviews.llvm.org/D35396, it was agreed that it would be best to simply ban %T and only keep %t, which is unique to each test. When a test needs a temporary directory, it can just create one using mkdir %t.
This patch removes %T in clang.
Differential Revision: https://reviews.llvm.org/D36437
llvm-svn: 310950
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
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:
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
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
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
Summary:
clang/test/Driver/autocomplete.c is a test for --autocomplete, and this
test might break if people add/modify flags or HelpText. So I've add
comment for future developers so that they can fix this file according
to the change they had made.
Reviewers: v.g.vassilev, teemperor, ruiu
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D36209
llvm-svn: 309794
On some targets, passing zero to the clz() or ctz() builtins has undefined
behavior. I ran into this issue while debugging UB in __hash_table from libcxx:
the bug I was seeing manifested itself differently under -O0 vs -Os, due to a
UB call to clz() (see: libcxx/r304617).
This patch introduces a check which can detect UB calls to builtins.
llvm.org/PR26979
Differential Revision: https://reviews.llvm.org/D34590
llvm-svn: 309459
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
Summary: -Wno-<warning> was autocompleted as -Wno<warning>, so fixed this typo.
Differential Revision: https://reviews.llvm.org/D35762
llvm-svn: 308824
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
This patch teaches the driver to pass -mgpopt by default to the backend when it
is supported, i.e. we are using -mno-abicalls.
Reviewers: atanasyan, slthakur
Differential Revision: https://reviews.llvm.org/D35548
This version fixes a logic error that generated warnings incorrectly.
llvm-svn: 308458
This patch teaches the driver to pass -mgpopt by default to the backend when it
is supported, i.e. we are using -mno-abicalls.
Reviewers: atanasyan, slthakur
Differential Revision: https://reviews.llvm.org/D35548
llvm-svn: 308431
Summary:
For example, this option is expected by ghc (haskell compiler). Currently, building with ghc will fail with:
```
clang: error: unknown argument: '-no-pie'
`gcc' failed in phase `Linker'. (Exit code: 1)
. /usr/share/haskell-devscripts/Dh_Haskell.sh && \
configure_recipe
```
This won't do anything (but won't fail with an error)
Reviewers: rafael, joerg
Reviewed By: joerg
Subscribers: joerg, cfe-commits
Differential Revision: https://reviews.llvm.org/D35462
llvm-svn: 308268
This patch series adds support for the IBM z14 processor. This part includes:
- Basic support for the new processor and its features.
- Support for low-level builtins mapped to new LLVM intrinsics.
Support for the -fzvector extension to vector float and the new
high-level vector intrinsics is provided by separate patches.
llvm-svn: 308197
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
-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
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
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
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
Summary:
Add value completion support for options which are defined in
CC1Options.td, because we only handled options in Options.td.
Reviewers: ruiu, v.g.vassilev, teemperor
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34558
llvm-svn: 306127
Add missing -### to the driver to ensure that we dont try to run the
actual command. The host may not support the IAS. Should fix the SCEI
buildbots.
llvm-svn: 306123
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
If we want to make sure that a particular string is not in an output,
the regular way of doing it is to add `-NOT` prefix instead of checking
if FileCheck resulted in an error.
Differential Revision: https://reviews.llvm.org/D34435
llvm-svn: 305930
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
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
This commit adds a testcase for uncovered code paths in LSan options parsing logic in driver.
Differential Revision: https://reviews.llvm.org/D33941
llvm-svn: 304880
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
The baremetal test (r303873) has been added with expectance of very
specific -resource-dir. However, the test itself nor the BareMetal
driver does not enforce any specific -resource-dir, making this
constraint invalid. It already has been altered twice -- in r303910 for
Windows compatibility, and in r304085 for systems using lib64. To
account for even more systems, just use [[RESOURCE_DIR]] like a number
of other tests do. This is needed for Gentoo where RESOURCE_DIR starts
with ../ (uses relative path to a parent directory).
Differential Revision: https://reviews.llvm.org/D33877
llvm-svn: 304715
Check pointer arithmetic for overflow.
For some more background on this check, see:
https://wdtz.org/catching-pointer-overflow-bugs.htmlhttps://reviews.llvm.org/D20322
Patch by Will Dietz and John Regehr!
This version of the patch is different from the original in a few ways:
- It introduces the EmitCheckedInBoundsGEP utility which inserts
checks when the pointer overflow check is enabled.
- It does some constant-folding to reduce instrumentation overhead.
- It does not check some GEPs in CGExprCXX. I'm not sure that
inserting checks here, or in CGClass, would catch many bugs.
Possible future directions for this check:
- Introduce CGF.EmitCheckedStructGEP, to detect overflows when
accessing structures.
Testing: Apart from the added lit test, I ran check-llvm and check-clang
with a stage2, ubsan-instrumented clang. Will and John have also done
extensive testing on numerous open source projects.
Differential Revision: https://reviews.llvm.org/D33305
llvm-svn: 304459
Jonas Hahnfeld