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
These are already wired up to work in the MSVC toolchain header search
code. However, they were unreachable from clang-cl. A user attempted to
use them in https://bugs.llvm.org/show_bug.cgi?id=33205, so let's expose
them.
llvm-svn: 304345
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
Amongst other, this will help LTO to correctly handle/honor files
compiled with O0, helping debugging failures.
It also seems in line with how we handle other options, like how
-fnoinline adds the appropriate attribute as well.
Differential Revision: https://reviews.llvm.org/D28404
llvm-svn: 304127
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
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
"-mmacosx_version_min"
The option -mmacosx_version_min will still be the canonical option for now, but
in the future we will switch over to -mmacos_version_min and make
-mmacosx_version_min an alias instead.
rdar://27043820
Differential Revision: https://reviews.llvm.org/D32796
llvm-svn: 302240
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
A bot had "-LTO" in its working directory, which matched the regex used in this
test. Since the arg is quoted, we can exploit that instead. Still broken if
there's a path with a quote in, but I think that's pretty niche.
llvm-svn: 302066
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
Don't list deprecated -std= values (c++0x etc). Only produce one line of output
per standard, even if we know it by multiple names.
In passing, add missing -std=gnu++03 alias (supported by GCC), and add new
spelling '-std=cl1.0' for OpenCL 1.0 for consistency with the other values,
with the same meaning as the preexisting '-std=cl'.
llvm-svn: 301507
We already prohibited this in most cases (in r130710), but had some bugs in our
enforcement of this rule. Specifically, this prevents the following
combinations:
* -x c -std=clN.M, which would previously effectively act as if -x cl were
used, despite the input being a C source file. (-x cl -std=cNN continues
to be disallowed.)
* -x c++ -std=cuda, which would previously select C++98 + CUDA, despite that
not being a C++ standard. (-x cuda -std=c++NN is still permitted, and
selects CUDA with the given C++ standard as its base language.
-x cuda -std=cuda is still supported with the meaning of CUDA + C++98.)
* -x renderscript -std=c++NN, which would previously form a hybrid "C++ with
RenderScript extensions" language. We could support such a thing, but
shouldn't do so by accident.
llvm-svn: 301497
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
This switches from the prototype syntax in P0273R0 ('module' and 'module
implementation') to the consensus syntax 'export module' and 'module'.
In passing, drop the "module declaration must be first" enforcement, since EWG
seems to have changed its mind on that.
llvm-svn: 301056
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
It sounds like MSVC is adding support for two-phase name lookup in a
future version, enabled by this flag (see bug).
Differential Revision: https://reviews.llvm.org/D32138
llvm-svn: 300501
Adding RUN lines with %clang_cl was causing these tests to fail on Mac
because absolute paths there tend to start with "/User/", which is
recognized as the "/U" flag.
Re-lands r300122
llvm-svn: 300209
This test has apparently been broken for years, but we never noticed before
because it's a long test and long tests approximately never get run.
llvm-svn: 300151
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
Summary:
Use a tablegen let {} block so that new sanitizer flags are available by
default in all driver modes. This should cut down on time wasted with
bugs like http://crbug.com/710928.
Reviewers: vitalybuka, hans
Subscribers: kcc, llvm-commits
Differential Revision: https://reviews.llvm.org/D31988
llvm-svn: 300122
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
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
AddressSanitizer has an optional compile-time flag, -fsanitize-address-use-after-scope, which enables detection of use-after-scope bugs. We'd like to have this feature on by default, because it is already very well tested, it's used in several projects already (LLVM automatically enables it when using -DLLVM_USE_SANITIZER=Address), it's low overhead and there are no known issues or incompatibilities.
This patch enables use-after-scope by default via the Clang driver, where we set true as the default value for AsanUseAfterScope. This also causes the lifetime markers to be generated whenever fsanitize=address is used. This has some nice consequences, e.g. we now have line numbers for all local variables.
Differential Revision: https://reviews.llvm.org/D31479
llvm-svn: 299174
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
a) avoid actually compiling anything
b) avoid depositing files in the test directory
c) use a check line to make sure that we're looking for the correct behavior
llvm-svn: 297917
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: Fix the test by adding missing -target flags with a 'linux' triple.
Reviewers: rnk, srhines
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D30947
llvm-svn: 297754
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
Summary: This fails on Windows due to dependence on path separators.
Reviewers: rnk, srhines
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D30595
llvm-svn: 296929
Summary:
This change adds an arch-specific subdirectory in <ResourceDir>/lib/<OS>
to the linker search path. This path also gets added as '-rpath' for
native compilation if a runtime is linked in as a shared object. This
allows arch-specific libraries to be installed alongside clang.
Reviewers: danalbert, cbergstrom, javed.absar
Subscribers: srhines
Differential Revision: https://reviews.llvm.org/D30015
llvm-svn: 296927
As is the case on platforms like Mips, X86 and SystemZ, the -fomit-frame-pointer
should be enabled by default on PPC when optimizing at -O1 and above. This
brings the behaviour of LLVM on PPC in line with GCC.
Committing on behalf of Hiroshi Inoue.
Differential Revision: https://reviews.llvm.org/D29750
llvm-svn: 296861
Previously, VC++ has always set _MSC_VER to a four-digit value with the two least significant digits set to zero. Visual Studio 2017, however, sets _MSC_VER=1910, and we expect to update the least significant digit as we release major updates for VS 2017. This patch fixes the msc-version.c test to handle non-zero values in the two least significant digits of _MSC_VER.
llvm-svn: 296843
The option -mexecute-only is translated into the backend option
-arm-execute-only. But this option only makes sense for the compiler and
the assembler does not recognize it. This patch stops clang from passing
this option to the assembler.
Change-Id: I4f4cb1162c13cfd50a0a36702a4ecab1bc0324ba
Review: https://reviews.llvm.org/D30414
llvm-svn: 296454
Summary: This enables LTO to be used with the clang-cl frontend.
Reviewers: rnk, hans
Reviewed By: hans
Subscribers: pcc, cfe-commits, mehdi_amini, Prazek
Differential Revision: https://reviews.llvm.org/D30239
llvm-svn: 296373
The runtime support is provided directly by the Fuchsia system C
library.
Patch by Roland McGrath
Differential Revision: https://reviews.llvm.org/D30238
llvm-svn: 296082
In case user did not provide valid standard name for -std option, available
values (with short description) will be reported.
Patch by Paweł Żukowski!
llvm-svn: 295113
1. Adds the command line flag for clzero.
2. Includes the clzero flag under znver1.
3. Defines the macro for clzero.
4. Adds a new file which has the intrinsic definition for clzero instruction.
Patch by Ganesh Gopalasubramanian with some additional tests from me.
Differential revision: https://reviews.llvm.org/D29386
llvm-svn: 294559
GCC does not generate `__unix` nor `unix` macros. The latter already
intrudes into the user's namespace and should be avoided. Use the
canonical spelling of `__unix__` across all the targets.
llvm-svn: 294148
While there is nothing to do at link time to get pthreads support on
darwin, specifying the argument is fine and we should not warn about
unused arguments.
llvm-svn: 294065
I modify clang driver for windows to include:
"-wholearchive:asan_dynamic_runtime_thunk", so all object files in the
static library: asan_dynamic_runtime_thunk are considered by the linker.
This is necessary, because some object files only include linker pragmas,
and doesn't resolve any symbol. If we don't include that flag, the
linker will ignore them, and won't read the linker pragmas.
Differential Revision: https://reviews.llvm.org/D29159
llvm-svn: 293420
In r279546 I disabled all frame pointer elimination at the front-end on
ARM-Darwin (and warned about it) because before that the backend had been
silently ignoring these options. It turns out we didn't ignore
-momit-leaf-frame-pointer though, just the more general -fomit-frame-pointer.
So this re-enables passing that down to CodeGen so that everything really does
continue working as before (with better diagnostics).
llvm-svn: 293311
Both on Mac and Windows, it's common to have a 'Users' directory in the
root of the filesystem, so one might specify a filename as
'/Users/me/myfile.c'. clang-cl (as well as MSVC's cl.exe) will interpret
that as invoking the '/U' option, which is probably not what the user
wanted. Add a warning about this.
Differential Revision: https://reviews.llvm.org/D29198
llvm-svn: 293305
The patch teaches the Clang driver how to handle the N64 static
relocation model properly. It enforces the correct target feature
(+noabicalls) when -fno-pic is used. This is required as non-pic
N64 code as the abi extension to call PIC code (CPIC) is unsupported.
Make PIC the default for mips64 and mips64el, this affects both N32
& N64 ABIs, to better match GCC.
As part of this effort, clean up the assembler invocation command
builder, so the correct flags are used.
This and r293279 in LLVM resolves PR/23485.
Thanks to Brooks Davis for reporting the issue!
Reviewers: slthakur, seanbruno
Differential Revision: https://reviews.llvm.org/D29031
llvm-svn: 293285
Summary: This enables the test to run on systems where output cannot be written.
Reviewers: compnerd
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D29123
llvm-svn: 293051
Sometime clang would be supplied -fobjc-arc -f(no)objc-arc-exceptions
and then later disable ARC with -fno-objc-arc, which only negate first
option, but not the latter, resulting usused argument warning. Silence
this warning only when -fno-objc-arc option is present.
Patch by Onha Choe!
llvm-svn: 293014
Summary:
It seems that rL292518 introduced a RUN: false, but the continuation rL292545
forgot to remove it back.
This has flown under the radar, because it's a long test and doesn't get
executed by default during sanity testing.
To test:
$ cd llvm_build
$ ./bin/llvm-lit --param run_long_tests=true tools/clang/test/Driver/response-file.c
@rsmith: have a look if this change is OK please.
Reviewers: bkramer
Reviewed By: bkramer
Subscribers: cfe-commits, rsmith
Differential Revision: https://reviews.llvm.org/D28941
llvm-svn: 292600
Under this defect resolution, the injected-class-name of a class or class
template cannot be used except in very limited circumstances (when declaring a
constructor, in a nested-name-specifier, in a base-specifier, or in an
elaborated-type-specifier). This is apparently done to make parsing easier, but
it's a pain for us since we don't know whether a template-id using the
injected-class-name is valid at the point when we annotate it (we don't yet
know whether the template-id will become part of an elaborated-type-specifier).
As a tentative resolution to a perceived language defect, mem-initializer-ids
are added to the list of exceptions here (they generally follow the same rules
as base-specifiers).
When the reference to the injected-class-name uses the 'typename' or 'template'
keywords, we permit it to be used to name a type or template as an extension;
other compilers also accept some cases in this area. There are also a couple of
corner cases with dependent template names that we do not yet diagnose, but
which will also get this treatment.
llvm-svn: 292518
Summary:
SamplePGO uses profile with debug info to collect profile. Unlike the traditional debugging purpose, sample pgo needs more accurate debug info to represent the profile. We add -femit-accurate-debug-info for this purpose. It can be combined with all debugging modes (-g, -gmlt, etc). It makes sure that the following pieces of info is always emitted:
* start line of all subprograms
* linkage name of all subprograms
* standalone subprograms (functions that has neither inlined nor been inlined)
The impact on speccpu2006 binary size (size increase comparing with -g0 binary, also includes data for -g binary, which does not change with this patch):
-gmlt(orig) -gmlt(patched) -g
433.milc 4.68% 5.40% 19.73%
444.namd 8.45% 8.93% 45.99%
447.dealII 97.43% 115.21% 374.89%
450.soplex 27.75% 31.88% 126.04%
453.povray 21.81% 26.16% 92.03%
470.lbm 0.60% 0.67% 1.96%
482.sphinx3 5.77% 6.47% 26.17%
400.perlbench 17.81% 19.43% 73.08%
401.bzip2 3.73% 3.92% 12.18%
403.gcc 31.75% 34.48% 122.75%
429.mcf 0.78% 0.88% 3.89%
445.gobmk 6.08% 7.92% 42.27%
456.hmmer 10.36% 11.25% 35.23%
458.sjeng 5.08% 5.42% 14.36%
462.libquantum 1.71% 1.96% 6.36%
464.h264ref 15.61% 16.56% 43.92%
471.omnetpp 11.93% 15.84% 60.09%
473.astar 3.11% 3.69% 14.18%
483.xalancbmk 56.29% 81.63% 353.22%
geomean 15.60% 18.30% 57.81%
Debug info size change for -gmlt binary with this patch:
433.milc 13.46%
444.namd 5.35%
447.dealII 18.21%
450.soplex 14.68%
453.povray 19.65%
470.lbm 6.03%
482.sphinx3 11.21%
400.perlbench 8.91%
401.bzip2 4.41%
403.gcc 8.56%
429.mcf 8.24%
445.gobmk 29.47%
456.hmmer 8.19%
458.sjeng 6.05%
462.libquantum 11.23%
464.h264ref 5.93%
471.omnetpp 31.89%
473.astar 16.20%
483.xalancbmk 44.62%
geomean 16.83%
Reviewers: davidxl, andreadb, rob.lougher, dblaikie, echristo
Reviewed By: dblaikie, echristo
Subscribers: hfinkel, rob.lougher, andreadb, gbedwell, cfe-commits, probinson, llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D25435
llvm-svn: 292458
In ThinLTO mode, type metadata will require the module to be written as a
multi-module bitcode file, which is currently incompatible with the Darwin
linker. It is also useful to be able to enable or disable multi-module bitcode
for testing purposes. This introduces a cc1-level flag, -f{,no-}lto-unit,
which is used by the driver to enable multi-module bitcode on all but
Darwin+ThinLTO, and can also be used to enable/disable the feature manually.
Differential Revision: https://reviews.llvm.org/D28877
llvm-svn: 292448
-mglobal-merge is translated to the appropriate backend option in
the driver. r277322 changed the AArch64 option name in the backend,
but the driver was never updated.
llvm-svn: 292192
- Don't break using '-mllvm -disable-llvm-optzns' (yet).
- Don't add support for '-mllvm -disable-llvm-passes'.
This is important for LLVM 4 as we haven't yet really told folks this is
coming. I'll add release notes about this.
I've also added some explicit testing of this so its more obvious what
is happening here.
llvm-svn: 291850
Summary:
openSuse has AArch64 support, with images running on the Raspberry Pi 3.
The libraries and headers live under the aarch64-suse-linux subdirectory,
which is currently not in the AArch64 triples list. Address this by adding
the corresponding string to AArch64Triples.
Reviewers: chandlerc, bruno, bkramer, rengolin
Subscribers: aemerson, rengolin, cfe-commits
Differential Revision: https://reviews.llvm.org/D28238
llvm-svn: 291598
Summary:
This patch enables the following
1. AMD family 17h architecture using "znver1" tune flag (-march, -mcpu).
2. ISAs that are enabled for "znver1" architecture.
3. Checks ADX isa from cpuid to identify "znver1" flag when -march=native is used.
4. ISAs FMA4, XOP are disabled as they are dropped from amdfam17.
5. For the time being, it uses the btver2 scheduler model.
6. Test file is updated to check this flag.
This is linked to llvm review item https://reviews.llvm.org/D28017
Patch by Ganesh Gopalasubramanian. Additional test cases added by Craig Topper.
Reviewers: RKSimon, craig.topper
Subscribers: cfe-commits, RKSimon, ashutosh.nema, llvm-commits
Differential Revision: https://reviews.llvm.org/D28018
llvm-svn: 291544
I originally requested this to be tested in D25263 but in the end
forgot to make sure that it was done.
Differential Revision: https://reviews.llvm.org/D28289
llvm-svn: 291389
It passes --sysroot for the Linux CUDA installation. To make this test
pass when targetting Windows, you would need to pass
--sysroot=Inputs/CUDA-windows.
llvm-svn: 291255
Summary:
For the most part this is straightforward: Just add a CudaInstallation
object to the MSVC and MinGW toolchains.
CudaToolChain has to override computeMSVCVersion so that
Clang::constructJob passes the right version flag to cc1. We have to
modify IsWindowsMSVC and friends in Clang::constructJob to be true when
compiling CUDA device code on Windows for the same reason.
Depends on: D28319
Reviewers: tra
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D28320
llvm-svn: 291131
Summary:
Authored by Senthil Kumar Selvaraj
This patch adds barebones support in Clang for the (experimental) AVR target. It uses the integrated assembler for assembly, and the GNU linker for linking, as lld doesn't know about the target yet.
The DataLayout string is the same as the one in AVRTargetMachine.cpp. The alignment specs look wrong to me, as it's an 8 bit target and all types only need 8 bit alignment. Clang failed with a datalayout mismatch error when I tried to change it, so I left it that way for now.
Reviewers: rsmith, dylanmckay, cfe-commits, rengolin
Subscribers: rengolin, jroelofs, wdng
Differential Revision: https://reviews.llvm.org/D27123
llvm-svn: 291082
Summary:
This change adds support for the -fno-delayed-template-parsing option in
clang-cl.exe. This allows developers using clang-cl.exe to opt out of
emulation of MSVC's non-conformant template instantiation implementation
while continuing to use clang-cl.exe for its emulation of cl.exe
command-line options. The default behavior of clang-cl.exe
(-fdelayed-template-parsing) is unchanged.
The MSVC Standard Library implementation uses clang-cl.exe with this
switch in its tests to ensure that the library headers work on compilers
with the conformant two-phase-lookup behavior.
Reviewers: majnemer, cfe-commits, DaveBartolomeo
Differential Revision: https://reviews.llvm.org/D22275
llvm-svn: 290990
in non-void functions that fall off at the end without returning a value when
compiling C++.
Clang uses the new compiler flag to determine when it should treat control flow
paths that fall off the end of a non-void function as unreachable. If
-fno-strict-return is on, the code generator emits the ureachable and trap
IR only when the function returns either a record type with a non-trivial
destructor or another non-trivially copyable type.
The primary goal of this flag is to avoid treating falling off the end of a
non-void function as undefined behaviour. The burden of undefined behaviour
is placed on the caller instead: if the caller ignores the returned value then
the undefined behaviour is avoided. This kind of behaviour is useful in
several cases, e.g. when compiling C code in C++ mode.
rdar://13102603
Differential Revision: https://reviews.llvm.org/D27163
llvm-svn: 290960
Windows uses PE/COFF which is inherently position independent. The use
of the PIC model is unnecessary. In fact, we would generate invalid
code using the ELF PIC model when PIC was enabled previously. Now that
we no longer accept -fPIC and -fpoc, this switches the internal
representation to the static model to permit us to make PIC modules
invalid when targeting Windows. This should not change the code
generation, only the internal state management.
llvm-svn: 290569
Use of these flags would result in the use of ELF-style PIE/PIC code
which is incorrect on Windows. Windows is inherently PIC by means of
the DLL slide that occurs at load. This also mirrors the behaviour on
GCC for MinGW. Currently, the Windows x86_64 forces the relocation
model to PIC (Level 2). This is unchanged for now, though we should
remove any assumptions on that and change it to a static relocation
model.
llvm-svn: 290533
manager, and a code path to use it.
The option is actually a top-level option but does contain
'experimental' in the name. This is the compromise suggested by Richard
in discussions. We expect this option will be around long enough and
have enough users towards the end that it merits not being relegated to
CC1, but it still needs to be clear that this option will go away at
some point.
The backend code is a fresh codepath dedicated to handling the flow with
the new pass manager. This was also Richard's suggested code structuring
to essentially leave a clean path for development rather than carrying
complexity or idiosyncracies of how we do things just to share code with
the parts of this in common with the legacy pass manager. And it turns
out, not much is really in common even though we use the legacy pass
manager for codegen at this point.
I've switched a couple of tests to run with the new pass manager, and
they appear to work. There are still plenty of bugs that need squashing
(just with basic experiments I've found two already!) but they aren't in
this code, and the whole point is to expose the necessary hooks to start
experimenting with the pass manager in more realistic scenarios.
That said, I want to *strongly caution* anyone itching to play with
this: it is still *very shaky*. Several large components have not yet
been shaken down. For example I have bugs in both the always inliner and
inliner that I have already spotted and will be fixing independently.
Still, this is a fun milestone. =D
One thing not in this patch (but that might be very reasonable to add)
is some level of support for raw textual pass pipelines such as what
Sean had a patch for some time ago. I'm mostly interested in the more
traditional flow of getting the IR out of Clang and then running it
through opt, but I can see other use cases so someone may want to add
it.
And of course, *many* features are not yet supported!
- O1 is currently more like O2
- None of the sanitizers are wired up
- ObjC ARC optimizer isn't wired up
- ...
So plenty of stuff still lef to do!
Differential Revision: https://reviews.llvm.org/D28077
llvm-svn: 290450
-fno-inline-functions, -O0, and optnone.
These were really, really tangled together:
- We used the noinline LLVM attribute for -fno-inline
- But not for -fno-inline-functions (breaking LTO)
- But we did use it for -finline-hint-functions (yay, LTO is happy!)
- But we didn't for -O0 (LTO is sad yet again...)
- We had weird structuring of CodeGenOpts with both an inlining
enumeration and a boolean. They interacted in weird ways and
needlessly.
- A *lot* of set smashing went on with setting these, and then got worse
when we considered optnone and other inlining-effecting attributes.
- A bunch of inline affecting attributes were managed in a completely
different place from -fno-inline.
- Even with -fno-inline we failed to put the LLVM noinline attribute
onto many generated function definitions because they didn't show up
as AST-level functions.
- If you passed -O0 but -finline-functions we would run the normal
inliner pass in LLVM despite it being in the O0 pipeline, which really
doesn't make much sense.
- Lastly, we used things like '-fno-inline' to manipulate the pass
pipeline which forced the pass pipeline to be much more
parameterizable than it really needs to be. Instead we can *just* use
the optimization level to select a pipeline and control the rest via
attributes.
Sadly, this causes a bunch of churn in tests because we don't run the
optimizer in the tests and check the contents of attribute sets. It
would be awesome if attribute sets were a bit more FileCheck friendly,
but oh well.
I think this is a significant improvement and should remove the semantic
need to change what inliner pass we run in order to comply with the
requested inlining semantics by relying completely on attributes. It
also cleans up tho optnone and related handling a bit.
One unfortunate aspect of this is that for generating alwaysinline
routines like those in OpenMP we end up removing noinline and then
adding alwaysinline. I tried a bunch of other approaches, but because we
recompute function attributes from scratch and don't have a declaration
here I couldn't find anything substantially cleaner than this.
Differential Revision: https://reviews.llvm.org/D28053
llvm-svn: 290398
Much to my surprise, '-disable-llvm-optzns' which I thought was the
magical flag I wanted to get at the raw LLVM IR coming out of Clang
deosn't do that. It still runs some passes over the IR. I don't want
that, I really want the *raw* IR coming out of Clang and I strongly
suspect everyone else using it is in the same camp.
There is actually a flag that does what I want that I didn't know about
called '-disable-llvm-passes'. I suspect many others don't know about it
either. It both does what I want and is much simpler.
This removes the confusing version and makes that spelling of the flag
an alias for '-disable-llvm-passes'. I've also moved everything in Clang
to use the 'passes' spelling as it seems both more accurate (*all* LLVM
passes are disabled, not just optimizations) and much easier to remember
and spell correctly.
This is part of simplifying how Clang drives LLVM to make it cleaner to
wire up to the new pass manager.
Differential Revision: https://reviews.llvm.org/D28047
llvm-svn: 290392
gtest is a widely-used unit-testing API. It provides macros for unit test
assertions:
ASSERT_TRUE(p != nullptr);
that expand into an if statement that constructs an object representing
the result of the assertion and returns when the assertion is false:
if (AssertionResult gtest_ar_ = AssertionResult(p == nullptr))
;
else
return ...;
Unfortunately, the analyzer does not model the effect of the constructor
precisely because (1) the copy constructor implementation is missing from the
the header (so it can't be inlined) and (2) the boolean-argument constructor
is constructed into a temporary (so the analyzer decides not to inline it since
it doesn't reliably call temporary destructors right now).
This results in false positives because the analyzer does not realize that the
the assertion must hold along the non-return path.
This commit addresses the false positives by explicitly modeling the effects
of the two un-inlined constructors on the AssertionResult state.
I've added a new package, "apiModeling", for these kinds of checkers that
model APIs but don't emit any diagnostics. I envision all the checkers in
this package always being on by default.
This addresses the false positives reported in PR30936.
Differential Revision: https://reviews.llvm.org/D27773
rdar://problem/22705813
llvm-svn: 290143
Summary:
This lets you build with one CUDA installation but use ptxas from
another install.
This is useful e.g. if you want to avoid bugs in an old ptxas without
actually upgrading wholesale to a newer CUDA version.
Reviewers: tra
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D27788
llvm-svn: 289847
Summary:
This implements execute-only support for ARM code generation, which
prevents the compiler from generating data accesses to code sections.
The following changes are involved:
* Add the CodeGen option "-arm-execute-only" to the ARM code generator.
* Add the clang flag "-mexecute-only" as well as the GCC-compatible
alias "-mpure-code" to enable this option.
* When enabled, literal pools are replaced with MOVW/MOVT instructions,
with VMOV used in addition for floating-point literals. As the MOVT
instruction is required, execute-only support is only available in
Thumb mode for targets supporting ARMv8-M baseline or Thumb2.
* Jump tables are placed in data sections when in execute-only mode.
* The execute-only text section is assigned section ID 0, and is
marked as unreadable with the SHF_ARM_PURECODE flag with symbol 'y'.
This also overrides selection of ELF sections for globals.
Reviewers: t.p.northover, rengolin
Subscribers: llvm-commits, aemerson
Differential Revision: https://reviews.llvm.org/D27450
llvm-svn: 289786
Most of the PowerPC64 code generation already creates PIC access. This
changes to a full PIC default, similar to what GCC is doing.
Overall, a monolithic clang binary shrinks by 600KB (about 1%). This can
be a slight regression for TLS access and will use the TOC more
aggressively instead of synthesizing immediates. It is expected to be
performance neutral.
Differential Revision: https://reviews.llvm.org/D26564
llvm-svn: 289744
The driver passes flags to cc1 that enable various checkers based on
the target triple. This commit adds tests for these flags on Darwin, Linux,
and Windows.
This is a test-only change.
llvm-svn: 289685
Fix the gcc-config code to support multilib gcc installs properly. This
solves two problems: -mx32 using the 64-bit gcc directory (due to matching
installation triple), and -m32 not respecting gcc-config at all (due to
mismatched installation triple).
In order to fix the former issue, split the multilib scan out of
Generic_GCC::GCCInstallationDetector::ScanLibDirForGCCTriple() (the code
is otherwise unchanged), and call it for each installation found via
gcc-config.
In order to fix the latter issue, split the gcc-config processing out of
Generic_GCC::GCCInstallationDetector::init() and repeat it for all
triples, including extra and biarch triples. The only change
in the gcc-config code itself is adding the call to multilib scan.
Convert the gentoo_linux_gcc_multi_version_tree test input to multilib
x86_64+32+x32 install, and add appropriate tests to linux-header-search
and linux-ld.
Differential Revision: https://reviews.llvm.org/D26887
llvm-svn: 289436
This allows us to negate preceding --cuda-gpu-arch=X.
This comes handy when user needs to override default
flags set for them by the build system.
Differential Revision: https://reviews.llvm.org/D27631
llvm-svn: 289287
Summary:
On actual Windows hosts :-) , this could report something other than the
fallback, with a non-zero minor/build number.
Reviewers: rnk, llvm-commits
Differential Revision: https://reviews.llvm.org/D27554
llvm-svn: 289011
Currently -fstack-protector is on by default when using -ffreestanding.
Change the default behavior to have it off when using -ffreestanding.
rdar://problem/14089363
llvm-svn: 289005
Summary:
This change adds more test cases for the default MSVC compatibility version:
1. When -fms-extensions is supplied, but -fmsc-version and
-fms-compatibility-version are not.
2. With the target triple specifies an MSVC environment, but no other
-fms* flags.
Reviewers: rnk, llvm-commits
Subscribers: hans, compnerd, amccarth
Differential Revision: https://reviews.llvm.org/D27498
llvm-svn: 288997
Summary:
Write output from compilation database test to %T rather than the working dir.
Sometimes CWD isn't writable!
Also specify no-canonical-prefixes so that clang has 'clang' in the name.
Reviewers: bkramer
Subscribers: joerg, cfe-commits
Differential Revision: https://reviews.llvm.org/D27504
llvm-svn: 288892
As a first step toward removing Objective-C garbage collection from
Clang, remove support from the driver. I'm hoping this will flush out
any expected bots/configurations/whatever that might rely on it.
I've left the options behind temporarily in -cc1 to keep tests passing.
I'll kill them off entirely in a follow up when I've had a chance to
update/delete the rest of Clang.
llvm-svn: 288872
"-mlinker-version=264.3.102" automatically. Wiring down a target on the
other hand is problematic as this actually needs to run codegen and
doesn't work with -###.
llvm-svn: 288827
When integrating compilation database output into existing build
systems, two approaches dominate so far. Ad-hoc implementation of the
JSON output rules or using compiler wrappers. This patch adds a new
option "-MJ foo.json" which gives a slightly cleaned up compilation
record. The output is a fragment, i.e. you still need to add the array
markers, but it allows multiple files to be easy merged.
This way the only change in a build system is adding the option with
potentially a per-target output file and merging the files with
something like
(echo '['; cat *.o.json; echo ']' > compilation_database.json
or some additional filtering to remove the trailing comma for strict
JSON compliance.
Differential Revision: https://reviews.llvm.org/D27140
llvm-svn: 288821
This is to match the behavior of non-LTO;
when -fsave-optimization-record is passed and PGO is available we enable
the generation of hotness information in the optimization records.
Differential Revision: https://reviews.llvm.org/D27332
llvm-svn: 288520
Summary:
The test introduced by rL288448 is currently failing because
unimportant but unexpected errors appear as output from a test compile
line. This patch looks for a more specific error message, in order to
avoid false positives.
Reviewers: jlebar
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D27328
Switch to more specific error
llvm-svn: 288453
This fixes a bug that was introduced in rL287285. The bug made it
illegal to pass -fsanitize=address during CUDA compilation because the
CudaToolChain class was switched from deriving from the Linux toolchain
class to deriving directly from the ToolChain toolchain class. When
CudaToolChain derived from Linux, it used Linux's getSupportedSanitizers
method, and that method allowed ASAN, but when it switched to deriving
directly from ToolChain, it inherited a getSupportedSanitizers method
that didn't allow for ASAN.
This patch fixes that bug by creating a getSupportedSanitizers method
for CudaToolChain that supports ASAN.
This patch also fixes the test that checks that -fsanitize=address is
passed correctly for CUDA builds. That test didn't used to notice if an
error message was emitted, and that's why it didn't catch this bug when
it was first introduced. With the fix from this patch, that test will
now catch any similar bug in the future.
llvm-svn: 288448
Summary: This patch adds a check and an error message to gnutools::Linker::ConstructJob in case the architecture is not supported. For most other operating systems, the error message is created in lib/Basic/Targets.cpp:AllocateTarget, but when construction the linker arguments for the gnutools linker a supported architecture is required.
Reviewers: rafael, joerg, echristo
Subscribers: mehdi_amini, joerg, dschuff, cfe-commits
Differential Revision: https://reviews.llvm.org/D27066
llvm-svn: 288327
Summary: Makes -fprofile-instr-generate and -fprofile-instr-use work
with clang-cl so that profile-guided optimization can be used.
Differential Revision: https://reviews.llvm.org/D27086
llvm-svn: 288230
https://reviews.llvm.org/D25932 made it so that clang always checks if
libLTO.dylib is present on disk, even if -flto is not being used. The
motivation for that change was that if a dependency happens to contain bitcode,
ld64 will try to load libLTO without -flto explicitly being enabled. However,
the change had the undesirable side effect of warning if libLTO.dylib doesn't
exist even if it isn't needed.
Change things so that -lto_library is always passes, independent of if it
exists or not. ld64 only looks at this flag if it uses LTO. If the dylib
exists, all is well. If it doesn't, and LTO is not being used, all is well too.
If ld64 does end up using LTO and the dylib does not exist, ld64 will print
something like
ld: could not process llvm bitcode object file, because foo/libLTO.dylib could not be loaded file 'test.o' for architecture x86_64
https://reviews.llvm.org/D26984
llvm-svn: 287685
Summary:
Compiling CUDA device code requires us to know the host toolchain,
because CUDA device-side compiles pull in e.g. host headers.
When we only supported Linux compilation, this worked because
CudaToolChain, which is responsible for device-side CUDA compilation,
inherited from the Linux toolchain. But in order to support MacOS,
CudaToolChain needs to take a HostToolChain pointer.
Because a CUDA toolchain now requires a host TC, we no longer will
create a CUDA toolchain from Driver::getToolChain -- you have to go
through CreateOffloadingDeviceToolChains. I am *pretty* sure this is
correct, and that previously any attempt to create a CUDA toolchain
through getToolChain() would eventually have resulted in us throwing
"error: unsupported use of NVPTX for host compilation".
In any case hacking getToolChain to create a CUDA+host toolchain would
be wrong, because a Driver can be reused for multiple compilations,
potentially with different host TCs, and getToolChain will cache the
result, causing us to potentially use a stale host TC.
So that's the main change in this patch.
In addition, we have to pull CudaInstallationDetector out of Generic_GCC
and into a top-level class. It's now used by the Generic_GCC and MachO
toolchains.
Reviewers: tra
Subscribers: rryan, hfinkel, sfantao
Differential Revision: https://reviews.llvm.org/D26774
llvm-svn: 287285
In addition to the preprocessed sources file and reproducer script, also
point to the .crash diagnostic files on Darwin. Example:
PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-4.0: note: diagnostic msg: /var/folders/bk/1hj20g8j4xvdj5gd25ywhd3m0000gq/T/RegAllocGreedy-238f28.cpp
clang-4.0: note: diagnostic msg: /var/folders/bk/1hj20g8j4xvdj5gd25ywhd3m0000gq/T/RegAllocGreedy-238f28.cache
clang-4.0: note: diagnostic msg: /var/folders/bk/1hj20g8j4xvdj5gd25ywhd3m0000gq/T/RegAllocGreedy-238f28.sh
clang-4.0: note: diagnostic msg: /var/folders/bk/1hj20g8j4xvdj5gd25ywhd3m0000gq/T/RegAllocGreedy-238f28.crash
When no match is found for the .crash, point the user to a directory
where those can be found. Example:
clang-4.0: note: diagnostic msg: Crash backtrace is located in
clang-4.0: note: diagnostic msg: /Users/bruno/Library/Logs/DiagnosticReports/clang-4.0_<YYYY-MM-DD-HHMMSS>_<hostname>.crash
clang-4.0: note: diagnostic msg: (choose the .crash file that corresponds to your crash)
rdar://problem/27286266
llvm-svn: 287262
Summary:
-fembed-bitcode infers -bitcode_bundle to ld64 but it is not correctly
passed when using LTO. LTO is a special case of -fembed-bitcode which
it doesn't require embed the bitcode in a special section in the object
file but it requires linker to save that as part of the final executable.
rdar://problem/29274226
Reviewers: mehdi_amini
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D26690
llvm-svn: 287084
Summary:
Bug: https://llvm.org/bugs/show_bug.cgi?id=30940
This macro (along with __ANDROID__) should always be defined for Android
targets. We set it to the major (only) version of the Android API being
compiled for. The Android version is able to be set as an integer suffix
for any valid Android target.
Reviewers: danalbert, eugenis
Subscribers: cfe-commits, pirama, eugenis, tberghammer, danalbert
Differential Revision: https://reviews.llvm.org/D26385
llvm-svn: 286295
For compatibility with other compilers on the platform, allow specifying
levels of the z/Architecture instead of model names with -march. In
particular, the following aliases are now supported:
-march=arch8 equals -march=z10
-march=arch9 equals -march=z196
-march=arch10 equals -march=zEC12
-march=arch11 equals -march=z13
This parallels the equivalent (and prerequisite) LLVM change in r285577.
llvm-svn: 285578
Summary:
This patch adds the support to create jobs for the `OffloadBundlingAction` which will invoke the `clang-offload-bundler` tool to unbundle input files.
Unlike other actions, unbundling actions have multiple outputs. Therefore, this patch adds the required changes to have a variant of `Tool::ConstructJob` with multiple outputs.
The way the naming of the results is implemented is also slightly modified so that the same action can use a different offloading prefix for each use by the different offloading actions.
With this patch, it is possible to compile a functional OpenMP binary with offloading support, even with separate compilation.
Reviewers: echristo, tra, jlebar, ABataev, hfinkel
Subscribers: mkuron, whchung, mehdi_amini, cfe-commits, Hahnfeld, andreybokhanko, arpith-jacob, carlo.bertolli, caomhin
Differential Revision: https://reviews.llvm.org/D21857
llvm-svn: 285326
Summary: This patch adds the support to create a job for the `OffloadBundlingAction` which will invoke the `clang-offload-bundler` tool.
Reviewers: echristo, tra, jlebar, ABataev, hfinkel
Subscribers: whchung, mehdi_amini, cfe-commits, Hahnfeld, andreybokhanko, arpith-jacob, carlo.bertolli, caomhin
Differential Revision: https://reviews.llvm.org/D21856
llvm-svn: 285325
Summary:
Each time that offloading support is requested by the user and the input file is not a source file, an action `OffloadUnbundlingAction` is created to signal that the input file may contain bundles, so that the proper tool is then invoked to attempt to extract the components of the bundle. This patch adds the logic to create that action in offload action builder.
The job creation for the new action will be proposed in a separate patch.
Reviewers: echristo, tra, jlebar, ABataev, hfinkel
Subscribers: whchung, mehdi_amini, cfe-commits, Hahnfeld, andreybokhanko, arpith-jacob, carlo.bertolli, caomhin
Differential Revision: https://reviews.llvm.org/D21853
llvm-svn: 285324
Summary:
In order to save the user from dealing with multiple output files (for host and device) while using separate compilation, a new action `OffloadBundlingAction` is used when the last phase is not linking. This action will then result in a job that uses the proposed bundling tool to create a single preprocessed/IR/ASM/Object file from multiple ones.
The job creation for the new action will be proposed in a separate patch.
Reviewers: echristo, tra, jlebar, ABataev, hfinkel
Subscribers: whchung, mehdi_amini, cfe-commits, Hahnfeld, andreybokhanko, arpith-jacob, carlo.bertolli, caomhin
Differential Revision: https://reviews.llvm.org/D21852
llvm-svn: 285323
Summary:
This patch includes support for argument translation that is specific of a given offloading kind. Additionally, it implements the translation for OpenMP device kinds in the gcc tool chain.
With this patch, it is possible to compile a functional OpenMP application with offloading capabilities with no separate compilation.
Reviewers: echristo, tra, jlebar, rsmith, ABataev, hfinkel
Subscribers: whchung, mehdi_amini, cfe-commits, Hahnfeld, andreybokhanko, arpith-jacob, carlo.bertolli, caomhin
Differential Revision: https://reviews.llvm.org/D21848
llvm-svn: 285320
Summary:
This patch adds logic to create jobs for OpenMP offloading actions by:
- tuning the jobs result information to use the offloading prefix even for (device) linking actions.
- replacing the device inputs of the host linking jobs by a linker script that embed them in the right sections.
Reviewers: echristo, tra, jlebar, rsmith, ABataev, hfinkel
Subscribers: mkuron, whchung, mehdi_amini, cfe-commits, Hahnfeld, andreybokhanko, arpith-jacob, carlo.bertolli, caomhin
Differential Revision: https://reviews.llvm.org/D21847
llvm-svn: 285319
Summary:
This patch adds a new specialized action builder to create OpenMP offloading actions. The specialized builder is added to the action builder already containing the CUDA specialized builder.
OpenMP offloading dependences between host and device actions (expressed with OffloadActions) are different that what is used for CUDA:
- Device compile action depends on the host compile action - the device frontend extracts the information about the declarations that have to be emitted by looking into the metadata produced by the host frontend.
- The host link action depends on the device link actions - the device images are embedded in the host binary at link time.
Reviewers: echristo, tra, rsmith, jlebar, ABataev, hfinkel
Subscribers: mkuron, whchung, mehdi_amini, cfe-commits, Hahnfeld, andreybokhanko, arpith-jacob, carlo.bertolli, caomhin
Differential Revision: https://reviews.llvm.org/D21845
llvm-svn: 285314
Summary: This patch adds new logic to create the necessary tool chains to support offloading for OpenMP. The OpenMP related options are checked and the tool chains created accordingly. Diagnostics are emitted in case the options are illegal or express unknown targets.
Reviewers: echristo, tra, jlebar, rsmith, ABataev, hfinkel
Subscribers: whchung, mkuron, mehdi_amini, cfe-commits, Hahnfeld, arpith-jacob, carlo.bertolli, caomhin
Differential Revision: https://reviews.llvm.org/D21843
llvm-svn: 285311
Summary:
Added the code which explicitly emits an error in Clang in case
`-fxray-instrument` is passed, but XRay is not supported for the
selected target.
Reviewers: rsmith, aaron.ballman, rnk, dberris
Differential Revision: https://reviews.llvm.org/D24799
llvm-svn: 285266
In this case the device code is not injected into an host action and therefore the
user should get an error as -o can't be used when generating two outputs.
llvm-svn: 285263
We're only doing it with -flto currently, however it never "hurt"
to pass it, and users that are linking without -flto can get in
trouble if one of the dependency (a static library for instance)
contains bitcode.
Differential Revision: https://reviews.llvm.org/D25932
llvm-svn: 285254
Summary:
This is only forced on if there is no non-Cortex-A53 CPU specified as
well. Android's platform and NDK builds need to assume that the code can
be run on Cortex-A53 devices, so we always enable the fix unless we know
specifically that the code is only running on a different kind of CPU.
Reviewers: cfe-commits
Subscribers: aemerson, rengolin, tberghammer, pirama, danalbert
Differential Revision: https://reviews.llvm.org/D25761
llvm-svn: 285127
Support using gcc-config to determine the correct GCC toolchain location
on Gentoo. In order to do that, attempt to read gcc-config configuration
form [[sysroot]]/etc/env.d/gcc, if no custom toolchain location is
provided.
Differential Revision: https://reviews.llvm.org/D25661
llvm-svn: 285074
Recent versions of ld64 run a deduplicate pass, which is on by default.
Disable the pass by using -no_deduplicate in certain condition and
enhance total compile time.
rdar://problem/25455336
llvm-svn: 284798
Tests fall into one of the following categories:
- The requirement was unnecessary
- Additional quoting was required for backslashes in paths (see "sed -e
's/\\/\\\\/g'") in the sanitizer tests.
- OpenMP used 'REQUIRES: shell' as a proxy for the test failing on
Windows. Those tests fail there reliably, so use XFAIL instead.
I tried not to remove shell requirements that were added to suppress
flaky test failures, but if I screwed up, we can add it back as needed.
llvm-svn: 284793
The clang-cl test required x86-registered-target but it defaulted to the
host's triple and AArch64 still doesn't support COFF, so the test failed.
The triple was "aarch64-pc-windows-msvc18.0.0" with ObjectFormat equals
llvm::Triple::COFF, failing assertion:
Assertion `(TT.isOSBinFormatELF() || TT.isOSBinFormatMachO()) &&
"Only expect Darwin and ELF targets"
in AArch64MCTargetDesc.cpp:78.
Making the test only run on Windows hosts obviously fixes the problem.
llvm-svn: 284749
System utilities such as atos only support DWARF 4 on OS X 10.11+ and
iOS 9+. We thus want to enable DWARF 4 only if the deployment target
has a recent enough operating system version and use DWARF 2 for older
systems.
<rdar://problem/28766743>
llvm-svn: 284416
Git does not store empty subdirectories (while SVN does). Git clone of
the clang repository did not create the fake Hexagon installation tree
used for testing the driver. This only became evident after a change
in the Hexagon toolchain that started checking for existence of certain
directories.
llvm-svn: 284402
Summary:
These options need to be passed to the plugin in order to have
an effect on LTO/ThinLTO compiles.
Reviewers: mehdi_amini, pcc
Subscribers: jfb, dschuff, mehdi_amini, cfe-commits
Differential Revision: https://reviews.llvm.org/D24644
llvm-svn: 284140
Reapply r283827 by fixing the tests to not be target specific
Currently, driver level warnings do not show option names (e.g. warning:
complain about foo [-Woption-name]) in a diagnostic unless
-fdiagnostics-show-option is explictly specified. OTOH, the driver by
default turn this option on for CC1. Change the logic to show option
names by default in the driver as well.
Differential Revision: https://reviews.llvm.org/D24516
rdar://problem/27300909
llvm-svn: 283913
The backend now has the capability to save information from optimizations, the
same information that can be used to generate optimization diagnostics but in
machine-consumable form, into an output file. This can be enabled when using
opt (see r282539), and this change enables it when using clang. The idea is
that other tools will be able to consume these files, and perhaps in
combination with the original source code, produce various kinds of
optimization reports for users (and for compiler developers).
We now have at-least two tools that can consume these files:
* tools/llvm-opt-report
* utils/opt-viewer
Using the flag -fsave-optimization-record will cause the YAML file to be
generated; the file name will be based on the output file name (if we're using
-c or -S and have an output name), or the input file name. When we're using
CUDA, or some other offloading mechanism, separate files are generated for each
backend target. The output file name can be specified by the user using
-foptimization-record-file=filename.
Differential Revision: https://reviews.llvm.org/D25225
llvm-svn: 283834
Currently, driver level warnings do not show option names (e.g. warning:
complain about foo [-Woption-name]) in a diagnostic unless
-fdiagnostics-show-option is explictly specified. OTOH, the driver by
default turn this option on for CC1. Change the logic to show option
names by default in the driver as well.
Differential Revision: https://reviews.llvm.org/D24516
rdar://problem/27300909
llvm-svn: 283827
The -gmodules option is all about putting debug type info into clang
modules and for line tables the type information is irrelevant, so
combining these two options makes no sense.
This commmit fixes the behavior to match the one documented on the
clang man page: the last -g... option wins.
<rdar://problem/27059770>
llvm-svn: 283810
Make the -print-libgcc-file-name option print an appropriate compiler
runtime library, that is libgcc.a if gcc runtime is used
and an appropriate compiler-rt library if that runtime is used.
The main use for this is to allow linking executables built with
-nodefaultlibs (e.g. to avoid linking to the standard C++ library) to
the compiler runtime library, e.g. using:
clang++ ... -nodefaultlibs $(clang++ ... -print-libgcc-file-name)
in which case currently a program built like this linked to the gcc
runtime unconditionally. The patch fixes it to use compiler-rt libraries
instead when compiler-rt is the active runtime.
Differential Revision: https://reviews.llvm.org/D25338
llvm-svn: 283746
We have a loop-rerolling optimization which can be enabled by using
-freroll-loops. While sometimes loops are hand-unrolled for performance
reasons, when optimizing for size, we should always undo this manual
optimization to produce smaller code (our optimizer's unroller will still
unroll the rerolled loops if it thinks that is a good idea).
llvm-svn: 283685
Revert the -print-libgcc-file-name change as the new test fails
on Darwin. It needs to be updated to run the libgcc part only on systems
supporting that rtlib.
llvm-svn: 283586
Make the -print-libgcc-file-name option print an appropriate compiler
runtime library, that is libgcc.a if gcc runtime is used
and an appropriate compiler-rt library if that runtime is used.
The main use for this is to allow linking executables built with
-nodefaultlibs (e.g. to avoid linking to the standard C++ library) to
the compiler runtime library, e.g. using:
clang++ ... -nodefaultlibs $(clang++ ... -print-libgcc-file-name)
in which case currently a program built like this linked to the gcc
runtime unconditionally. The patch fixes it to use compiler-rt libraries
instead when compiler-rt is the active runtime.
Differential Revision: https://reviews.llvm.org/D25338
llvm-svn: 283572
Provide toolchain and tool support for Fuchsia operating system.
Fuchsia uses compiler-rt as the runtime library and libc++, libc++abi
and libunwind as the C++ standard library. lld is used as a default
linker.
Differential Revision: https://reviews.llvm.org/D25117
llvm-svn: 283420
We could hook up /GL as an alias for -flto, but that might be
confusing, as clang-cl in that mode would not be drop-in compatible
with cl.exe /GL, as it requires the linker to be lld.
Exposing -flto seems like a less confusing way to expose this
functionality.
llvm-svn: 283255
Added the code which explicitly emits an error in Clang in case
`-fxray-instrument` is passed, but XRay is not supported for the
selected target.
Author: rSerge
Reviewers: dberris, rsmith, aaron.ballman, rnk
Subscribers: cfe-commits, iid_iunknown
Differential Revision: https://reviews.llvm.org/D24799
llvm-svn: 283193
Summary:
Also makes -fcoroutines_ts to be both a Driver and CC1 flag.
Patch mostly by EricWF.
Reviewers: rnk, cfe-commits, rsmith, EricWF
Subscribers: mehdi_amini
Differential Revision: https://reviews.llvm.org/D25130
llvm-svn: 283064
Enable soft-float support on PPC64, as the backend now supports it. Also, the
backend now uses -hard-float instead of +soft-float, so set the target features
accordingly.
Fixes PR26970.
llvm-svn: 283061
Summary:
This patch proposes a new class to generate and record action dependences related with offloading. The builder provides three main functionalities:
- Add device dependences to host actions.
- Add host dependence to device actions.
- Register device top-level actions.
The constructor of the builder detect the programming models that should be supported, and generates a specialized builder for each. If a new programming model is to be added in the future, only a new specialized builder has to be implemented.
When the specialized builder is generated, it produces programming-model-specific diagnostics.
A CUDA specialized builder is proposed in the patch that mostly consists of the partition of the current `buildCudaAction` by the three different functionalities.
Reviewers: tra, echristo, ABataev, jlebar, hfinkel
Subscribers: Hahnfeld, whchung, guansong, jlebar, mehdi_amini, andreybokhanko, tcramer, mkuron, cfe-commits, arpith-jacob, carlo.bertolli, caomhin
Differential Revision: https://reviews.llvm.org/D18172
llvm-svn: 282865
This patch corresponds to review:
https://reviews.llvm.org/D24397
It adds the __POWER9_VECTOR__ macro and the -mpower9-vector option along with
a number of altivec.h functions (refer to the code review for a list).
llvm-svn: 282481
This option behaves in a similar spirit as -save-temps and writes
internal llvm statistics in json format to a file.
Differential Revision: https://reviews.llvm.org/D24820
llvm-svn: 282426
Avoid failing in the backend when the rewrite map does not exist. Rather check
that the map exists in the frontend before handing it off to the backend. Add
the missing rewrite maps that the tests were referencing.
llvm-svn: 282379
Summary:
Currently, a linker option must be used to control the backend
parallelism of ThinLTO. The linker option varies depending on the
linker (e.g. gold vs ld64). Add a new clang option -flto-jobs=N
to control this.
I've added in the wiring to pass this to the gold plugin. I also
added in the logic to pass this down in the form I understand that
ld64 uses on MacOS, for the darwin target.
Reviewers: mehdi_amini, dexonsmith
Subscribers: mehdi_amini, cfe-commits
Differential Revision: https://reviews.llvm.org/D24826
llvm-svn: 282291
Clang has the default FP contraction setting of “-ffp-contract=on”, which
doesn't really mean “on” in the conventional sense of the word, but rather
really means “according to the per-statement effective value of the relevant
pragma”.
Before this patch, Clang has that pragma defaulting to “off”. Since the
“-ffp-contract=on” mode is really an AND of two booleans and the second of them
defaults to “off”, the whole thing effectively defaults to “off”. This patch
changes the default value of the pragma to “on”, thus making the default pair of
booleans (on, on) rather than (on, off). This makes FP optimization slightly
more aggressive than before when not using either “-Ofast”, “-ffast-math”, or
“-ffp-contract=fast”. Even with this patch the compiler still respects
“-ffp-contract=off”.
As per a suggestion by Steve Canon, the added code does _not_ require “-O3” or
higher. This is so as to try our best to preserve identical floating-point
results for unchanged source code compiling for an unchanged target when only
changing from any optimization level in the set (“-O0”, “-O1”, “-O2”, “-O3”) to
any other optimization level in that set. “-Os” and “-Oz” seem to be behaving
identically, i.e. should probably be considered a part of the aforementioned
set, but I have not reviewed this rigorously. “-Ofast” is explicitly _not_ a
member of that set.
Patch authored by Abe Skolnik [a.skolnik@samsung.com] and Stephen Canon [scanon@apple.com].
Differential Revision: https://reviews.llvm.org/D24481
llvm-svn: 282259
It was trying to check that things behave correctly when a
non-existant folder was specified for -isysroot. Incidentally,
I have a folder named FOO in the root of my drive, so this test
was failing. Make this impossible by using %T to refer to a
definitely non-existant folder.:
llvm-svn: 281998
Summary:
Sanitizers aren't supported on NVPTX -- don't try to run them.
This lets you e.g. pass -fsanitize=address and get asan on your host
code.
Reviewers: kcc
Subscribers: cfe-commits, tra, jhen
Differential Revision: https://reviews.llvm.org/D24640
llvm-svn: 281680
Renato Golin