Summary:
Similar to rL248426 (which was a followup to rL248379 and rL248424), add the
required libraries for OpenMP on the linker command line, and update the test
case.
Reviewers: emaste, theraven, joerg
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D13822
llvm-svn: 250657
This recommits r250398 with fixes to the tests for bot failures.
Add "-target x86_64-unknown-linux" to the clang invocations that
check for the gold plugin.
llvm-svn: 250455
Rolling this back for now since there are a couple of bot failures on
the new tests I added, and I won't have a chance to look at them in detail
until later this afternoon. I think the new tests need some restrictions on
having the gold plugin available.
This reverts commit r250398.
llvm-svn: 250402
Summary:
Add clang support for -flto=thin option, which is used to set the
EmitFunctionSummary code gen option on compiles.
Add -flto=full as an alias to the existing -flto.
Add tests to check for proper overriding of -flto variants on the
command line, and convert grep tests to FileCheck.
Reviewers: dexonsmith, joker.eph
Subscribers: davidxl, cfe-commits
Differential Revision: http://reviews.llvm.org/D11908
llvm-svn: 250398
There was a minor problem with a test. Sorry for the noise yesterday.
This patch adds missing pieces to clang, including the PS4 toolchain
definition, added warnings, PS4 defaults, and Driver changes needed for
our compiler.
A patch by Filipe Cabecinhas, Pierre Gousseau and Katya Romanova!
Differential Revision: http://reviews.llvm.org/D13482
llvm-svn: 250293
Resubmitting the patch.
This patch adds missing pieces to clang, including the PS4 toolchain
definition, added warnings, PS4 defaults, and Driver changes needed for
our compiler.
A patch by Filipe Cabecinhas, Pierre Gousseau and Katya Romanova!
Differential Revision: http://reviews.llvm.org/D13482
llvm-svn: 250262
definition, added warnings, PS4 defaults, and Driver changes needed for
our compiler.
A patch by Filipe Cabecinhas, Pierre Gousseau and Katya Romanova!
Differential Revision: http://reviews.llvm.org/D13482
llvm-svn: 250252
Add support for the `-fdebug-prefix-map=` option as in GCC. The syntax is
`-fdebug-prefix-map=OLD=NEW`. When compiling files from a path beginning with
OLD, change the debug info to indicate the path as start with NEW. This is
particularly helpful if you are preprocessing in one path and compiling in
another (e.g. for a build cluster with distcc).
Note that the linearity of the implementation is not as terrible as it may seem.
This is normally done once per file with an expectation that the map will be
small (1-2) entries, making this roughly linear in the number of input paths.
Addresses PR24619.
llvm-svn: 250094
C++ exceptions are still off by default, which is similar to how C++
cleanups are off by default in MSVC.
If you use clang instead of clang-cl, exceptions are also still off by
default. In the future, when C++ EH is proven to be stable, we may flip
the default for that driver to be consistent with other platforms.
llvm-svn: 249704
With this change, most 'g' options are rejected by CompilerInvocation.
They remain only as Driver options. The new way to request debug info
from cc1 is with "-debug-info-kind={line-tables-only|limited|standalone}"
and "-dwarf-version={2|3|4}". In the absence of a command-line option
to specify Dwarf version, the Toolchain decides it, rather than placing
Toolchain-specific logic in CompilerInvocation.
Also fix a bug in the Windows compatibility argument parsing
in which the "rightmost argument wins" principle failed.
Differential Revision: http://reviews.llvm.org/D13221
llvm-svn: 249655
r249137 added support for the new mips-mti-linux toolchain. However,
the new tests of that commit, broke some buildbots because they didn't use
the correct regular expressions to capture the filename of Clang & LLD.
This commit re-applies the changes of r249137 and fixes the tests in
r249137 in order to match the filenames of the Clang and LLD executable.
llvm-svn: 249294
In versions of clang prior to r238238, __declspec was recognized as a keyword in
all modes. It was then changed to only be enabled when Microsoft or Borland
extensions were enabled (and for CUDA, as a temporary measure). There is a
desire to support __declspec in Playstation code, and possibly other
environments. This commit adds a command-line switch to allow explicit
enabling/disabling of the recognition of __declspec as a keyword. Recognition
is enabled by default in Microsoft, Borland, CUDA, and PS4 environments, and
disabled in all other environments.
Patch by Warren Ristow!
llvm-svn: 249279
The Windows on ARM ABI recommends that FPO be disabled. This is since the
Windows on ARM ABI uses the FP for fast stack walking. By paying the slight
cost of the loss of registers, a much faster backtrace is possible by using the
frame pointer since the pdata need not be consulted. Furthermore, even if pdata
is not available, you can still more easily reconstruct the stack.
llvm-svn: 249227
Reapply r248935.
Usually, when using LTO with a clang installation newer than the
system's one, there's a libLTO.dylib version mismatch and LTO fails. One
solution to this is to make ld point to the right libLTO.dylib by
changing DYLD_LIBRARY_PATH.
However, ld64 supports specifying the complete path to the desired
libLTO.dylib through the -lto_library option. This commit adds support
for the clang driver to use this option whenever it's capable of finding
a libLTO.dylib in clang's installed library directory. This way, we
don't need to rely on DYLD_LIBRARY_PATH nor get caught by version
mismatches.
Differential Revision: http://reviews.llvm.org/D13117
rdar://problem/7363476
llvm-svn: 249143
Summary:
This new toolchain uses primarily LLVM-based tools, eg. compiler-rt, lld,
libcxx, etc. Because of this, it doesn't require neither an existing GCC
installation nor a GNU environment. Ideally, in a follow-up patch we
would like to add a new --{llvm|clang}-toolchain option (similar to
--gcc-toolchain) in order to allow the use of this toolchain with
independent Clang builds. For the time being, we use the --sysroot
option just to test the correctness of the paths generated by the
driver.
Reviewers: atanasyan, dsanders, rsmith
Subscribers: jfb, tberghammer, danalbert, srhines, dschuff, cfe-commits
Differential Revision: http://reviews.llvm.org/D13340
llvm-svn: 249137
Summary:
This patch moves getCompilerRT() from the clang::driver::tools namespace to
the ToolChain class. This is needed for multilib toolchains that need to
place their libraries in Clang's resource directory with a layout that is
different from the default one.
Reviewers: atanasyan, rsmith
Subscribers: tberghammer, danalbert, srhines, cfe-commits
Differential Revision: http://reviews.llvm.org/D13339
llvm-svn: 249030
Usually, when using LTO with a clang installation newer than the
system's one, there's a libLTO.dylib version mismatch and LTO fails. One
solution to this is to make ld point to the right libLTO.dylib by
changing DYLD_LIBRARY_PATH.
However, ld64 supports specifying the complete path to the desired
libLTO.dylib through the -lto_library option. This commit adds support
for the clang driver to use this option whenever it's capable of finding
a libLTO.dylib in clang's installed library directory. This way, we
don't need to rely on DYLD_LIBRARY_PATH nor get caught by version
mismatches.
Differential Revision: http://reviews.llvm.org/D13117
rdar://problem/7363476
llvm-svn: 248932
ARM EABI adds target attributes to the object file. Amongst the attributes that
are emitted is the VFP argument passing (Hard vs Soft). The linker is
responsible for checking these attributes and erroring on mismatches. This
causes problems for the compiler-rt builtins when targeting both hard and
soft. Because both of these options name the builtins compiler-rt component
the same (libclang_rt.builtins-arm.a or libclang_rt.builtins-arm-android). GCC
is able to get away with this as it does one target per toolchain. This
changes the naming convention for the ARM compiler-rt builtins to differentiate
between HF and Soft. Although this means that compiler-rt may be duplicated, it
enables supporting both variants from a single toolchain. A similar approach is
taken by the Darwin toolchain, naming the library to differentiate between the
calling conventions.
llvm-svn: 248649
definition, added warnings, PS4 defaults, and Driver changes needed for
our compiler.
A patch by Filipe Cabecinhas, Pierre Gousseau and Katya Romanova!
Differential Revision: http://reviews.llvm.org/D11279
llvm-svn: 248546
StringRefs always point to immutable memory so the const doesn't add value
here. Also quiets clang's -Wrange-loop-analysis which warns about the implicit
copying.
llvm-svn: 248496
Summary:
Strictly speaking, the MIPS*R2 ISA's should not permit -mnan=2008 since this
feature was added in MIPS*R3. However, other toolchains permit this and we
should do the same.
Reviewers: atanasyan
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D13057
llvm-svn: 248481
Fix of dangling StringRef after temporary std::string is destroyed
Follow-up to: http://reviews.llvm.org/rL248479
Reviewers: alexfh
Subscribers: cfe-commits
llvm-svn: 248480
Fix of dangling StringRef after temporary std::string is destroyed
Follow-up to: http://reviews.llvm.org/rL248370
Reviewers: alexfh
Subscribers: cfe-commits
llvm-svn: 248479
This translates to -load name.so in the cc1 command. We can't name the driver
option -load, as that means "link against oad", so instead we follow GCC's lead
and name the option -fplugin.
llvm-svn: 248378
An assertion hit has been fixed for cmdlines like
$ clang --target=arm-linux-gnueabi -mcpu=generic hello.c
Related to: http://reviews.llvm.org/rL245445
Reviewers: rengolin
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D13013
llvm-svn: 248370
This changes getARMFloatABI to use the ToolChain and Args instead of Driver,
Args, Triple. Although this pushes the Triple calculation/parsing into the
function itself, it enables the use of the function for a future change. The
reason to sink the triple calculation here is to avoid threading the Triple
through multiple layers in a future change.
llvm-svn: 248095
Rather than using re-calculating the effective triple, thread the already
calculated value down into AddARMTargetArgs. This avoids both recreating the
triple, as well as re-parsing the triple as it was already done in the previous
frame.
llvm-svn: 248094
Use an enumeration for the Floating Point ABIs supported on MIPS. This is
replicating the ARM change to avoid string based tracking of the floating point
ABI. NFC.
llvm-svn: 248083
Use an enumeration and change the use of the FloatABI from a string to the
enumeration. This avoids the use of string values to represent an enumeration.
NFC.
llvm-svn: 247967
There is no __cxa_finalize symbol available on recent Solaris OS
versions, so we need this flag to make non trivial C++ programs run.
Also stop looking for cxa_finalize.o, since it won't be there.
Patch by Xan López!
llvm-svn: 247634
This is actually needed, otherwise libc won't be added at all. For
instance when building libclang.so all the libc symbols won't be
found, with ld warning about libc being an "implicit dependency".
Patch by Xan López!
llvm-svn: 247603
-force-align-stack.
Also, make changes to the driver so that -mno-stack-realign is no longer
an option exposed to the end-user that disallows stack realignment in
the backend.
Differential Revision: http://reviews.llvm.org/D11815
llvm-svn: 247451
Summary:
With Visual Studio 2015 release, a part of runtime library was extracted
and now comes with Windows Kits. This patch enables clang to use
Universal CRT library if %INCLUDE or %LIB environment varaibles are not
specified.
See also https://llvm.org/bugs/show_bug.cgi?id=24741
Patch by Igor Kudrin
Reviewers: zturner, hans, rnk
Subscribers: ruiu, cfe-commits
Differential Revision: http://reviews.llvm.org/D12695
llvm-svn: 247362
If target supports TLS all threadprivates are generated as TLS. If target does not support TLS, use runtime calls for proper codegen of threadprivate variables.
llvm-svn: 247273
This implements basic support for compiling (though not yet assembling
or linking) for a WebAssembly target. Note that ABI details are not yet
finalized, and may change.
Differential Revision: http://reviews.llvm.org/D12002
llvm-svn: 246814
Summary: The command line options for these are -Wa,--trap and -Wa,--break.
Patch by Scott Egerton.
Reviewers: vkalintiris, dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11676
llvm-svn: 246765
The ACLE (ARM C Language Extensions) 2.0 allows the __fp16 type to be
used as a functon argument or return type (ACLE 1.1 did not).
The current public release of the AAPCS (2.09) states that __fp16 values
should be converted to single-precision before being passed or returned,
but AAPCS 2.10 (to be released shortly) changes this, so that they are
passed in the least-significant 16 bits of either a GPR (for base AAPCS)
or a single-precision register (for AAPCS-VFP). This does not change how
arguments are passed if they get passed on the stack.
This patch brings clang up to compliance with the latest versions of
both of these specs.
We can now set the __ARM_FP16_ARGS ACLE predefine, and we have always
been able to set the __ARM_FP16_FORMAT_IEEE predefine (we do not support
the alternative format).
llvm-svn: 246764
Original commit message:
[ARM] Allow passing/returning of __fp16 arguments
The ACLE (ARM C Language Extensions) 2.0 allows the __fp16 type to be
used as a functon argument or return type (ACLE 1.1 did not).
The current public release of the AAPCS (2.09) states that __fp16 values
should be converted to single-precision before being passed or returned,
but AAPCS 2.10 (to be released shortly) changes this, so that they are
passed in the least-significant 16 bits of either a GPR (for base AAPCS)
or a single-precision register (for AAPCS-VFP). This does not change how
arguments are passed if they get passed on the stack.
This patch brings clang up to compliance with the latest versions of
both of these specs.
We can now set the __ARM_FP16_ARGS ACLE predefine, and we have always
been able to set the __ARM_FP16_FORMAT_IEEE predefine (we do not support
the alternative format).
llvm-svn: 246760
The ACLE (ARM C Language Extensions) 2.0 allows the __fp16 type to be
used as a functon argument or return type (ACLE 1.1 did not).
The current public release of the AAPCS (2.09) states that __fp16 values
should be converted to single-precision before being passed or returned,
but AAPCS 2.10 (to be released shortly) changes this, so that they are
passed in the least-significant 16 bits of either a GPR (for base AAPCS)
or a single-precision register (for AAPCS-VFP). This does not change how
arguments are passed if they get passed on the stack.
This patch brings clang up to compliance with the latest versions of
both of these specs.
We can now set the __ARM_FP16_ARGS ACLE predefine, and we have always
been able to set the __ARM_FP16_FORMAT_IEEE predefine (we do not support
the alternative format).
llvm-svn: 246755
This patch refactors the code to use the GCC installation detector
(modified so that it works in Solaris), and uses
ToolChain::GetFilePath everywhere once it works.
Patch by Xan López <xan@igalia.com>!
llvm-svn: 246473
const char pointers. In turn, push this through Clang APIs as well,
simplifying a number of bits of code that was handling the oddities of
nullptrs.
llvm-svn: 246375
to enable the use of external type references in the debug info
(a.k.a. module debugging).
The driver expands -gmodules to "-g -fmodule-format=obj -dwarf-ext-refs"
and passes that to cc1. All this does at the moment is set a flag
codegenopts.
http://reviews.llvm.org/D11958
llvm-svn: 246192
Error out if -mfloat-abi=hard or -mhard-float is specified on the command
line and the target ABI is APCS. Previously clang issued no warnings or
errors and just passed the option to the backend, which had no effect on
code generation for targets using APCS.
This commit corrects the patch commited in r245866, which didn't take into
account the fact that not all darwin targets use APCS.
rdar://problem/22257950
http://reviews.llvm.org/D12344
llvm-svn: 246054
Error out if the user tries to use float-abi="hard" since it isn't
supported on darwin platforms. Previously clang issued no warnings or
erros and just passed the option to the backend, which had no effect on
code generation for targets using apcs.
rdar://problem/22257950
Differential Revision: http://reviews.llvm.org/D12155
llvm-svn: 245866
For some reason, clang had been treating a command like:
clang -static -fPIC foo.c
as if it should be compiled without the PIC relocation model.
This was incorrect: -static should be affecting only the linking
model, and -fPIC only the compilation.
This new behavior also matches GCC.
This is a follow-up from a review comment on r245447.
Differential Revision: http://reviews.llvm.org/D12208
llvm-svn: 245667
doing assembly-only, and unify the Driver's PIC argument parsing.
On a few architectures, parsing of assembly files annoyingly depends
on whether PIC is enabled or not. This was handled for external 'as'
already (passing -KPIC), but was missed for calls to the standalone
internal assembler.
The integrated-as.s test needed to be modified to not expect
-fsanitize=address to be unused, as now fsanitize *IS* used for
assembly, since -fsanitize=memory can sometimes imply -fPIE, which the
assembler needs to know (gack!!).
Differential Revision: http://reviews.llvm.org/D11845
llvm-svn: 245447
"generic" cpu was wrongly handled as exact real CPU name of ARMv8.1A architecture.
This has been fixed, now it is abstract name, suitable for any arch.
Reviewers: rengolin
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D11640
llvm-svn: 245445
Adds libomp.lib for -fopenmp=libomp and libiomp5md.lib for -fopenmp=libiomp5 on Windows
Differential Revision: http://reviews.llvm.org/D11932
llvm-svn: 245414
-mkernel enables -fno-builtin and -fno-common by default, but allows -fbuiltin
and -fcommon to override that. However "-fbuiltin -fno-builtin" is treated the
same as "-fbuiltin" which is wrong, so fix that. Also fixes similar behaviour
when -fno-common is default.
Differential Revision: http://reviews.llvm.org/D11459
llvm-svn: 244437
Implemented in MinGW::Linker::AddLibGCC since AddLibgcc is a logic puzzle even
before adding one more boolean. A first step towards simplification of AddLibgcc
would be to factor out the Android AddLibgcc code into its own routine.
llvm-svn: 244407
This patch adds flags -fno-profile-instr-generate and
-fno-profile-instr-use, and the GCC aliases -fno-profile-generate and
-fno-profile-use.
These flags are used in situations where users need to disable profile
generation or use for specific files in a build, without affecting other
files.
llvm-svn: 244153
Summary:
By default, 'clang' emits dwarf and 'clang-cl' emits codeview. You can
force emission of one or both by passing -gcodeview and -gdwarf to
either driver.
Reviewers: dblaikie, hans
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D11742
llvm-svn: 244097
This seems preferable to printing two warnings per unsupported option-
one warning about not supporting it, and one about not using it.
It also makes the '-Wno-' option do what you mean.
Differential Revision: http://reviews.llvm.org/D11766
llvm-svn: 244079
It doesn't make any sense to enable -gmlt with -gsplit-dwarf, since
-gmlt is designed for on-line symbolication (and -gsplit-dwarf normally
emits all the -gmlt data into the .o anyway - so there's nothing to
split out except redundant/duplicate info).
With this change they override each other, -gmlt -gsplit-dwarf is the
same as -gsplit-dwarf and -gsplit-dwarf -gmlt is the same as -gmlt.
llvm-svn: 243694
Copying the already existing code for x86 to ARM to set the correct CPU
features when using -mcpu=native. We can already detect the CPU name
but we were not setting the correct feature bits.
Moving fpu/hwdiv down to make sure they override whatever we set the
default to be.
No tests because this is native detection, and not all ARM-enabled builds
will hapen at a specific CPU, or even ARM. I have tested locally and it
works as expected.
Fixes PR12794.
llvm-svn: 243656
The z13 vector facility has an associated language extension,
closely modeled on AltiVec/VSX. The main differences are:
- vector long, vector float and vector pixel are not supported
- vector long long and vector double are supported (like VSX)
- comparison operators return a vector rather than a scalar integer
- shift operators behave like the OpenCL shift operators
- vector bool is only supported as argument to certain operators;
some operators allow mixing a bool with a non-bool vector
This patch adds clang support for the extension. It is closely modelled
on the AltiVec support. Similarly to the -faltivec option, there's a
new -fzvector option to enable the extensions (as well as an -mzvector
alias for compatibility with GCC). There's also a separate LangOpt.
The extension as implemented here is intended to be compatible with
the -mzvector extension recently implemented by GCC.
Based on a patch by Richard Sandiford.
Differential Revision: http://reviews.llvm.org/D11001
llvm-svn: 243642
Dimitry Andric