This fixes an issue when "-gdwarf-N" switch was ignored if it was given
before another debug option.
Differential Revision: https://reviews.llvm.org/D96865
The new spec does not have `exnref` so EH does not have dependency of
the reference types proposal anymore.
Reviewed By: dschuff
Differential Revision: https://reviews.llvm.org/D96903
Drop the `Separate` form of `-fmodule-name X`, `-fprofile-remapping-file X`, and `-frewrite-map-file X`.
To the best of my knowledge they are not used. Their conventional Joined forms (`-fFOO=`) should be used instead.
`-fdebug-compilation-dir X` is used in several places, e.g. chromium/infra/goma.
It is also advertised in http://blog.llvm.org/2019/11/deterministic-builds-with-clang-and-lld.html
So we keep it but make the EQ form canonical and the Separate form an alias.
Differential Revision: https://reviews.llvm.org/D96886
The option was added in D90507 for C/C++ source files. This patch adds
support for assembly files.
Differential Revision: https://reviews.llvm.org/D96783
Add the following options:
* -fimplicit-none and -fno-implicit-none
* -fbackslash and -fno-backslash
* -flogical-abbreviations and -fno-logical-abbreviations
* -fxor-operator and -fno-xor-operator
* -falternative-parameter-statement
* -finput-charset=<value>
Summary of changes:
- Enable extensions in CompilerInvocation#ParseFrontendArgs
- Add encoding_ to Fortran::frontend::FrontendOptions
- Add encoding to Fortran::parser::Options
Differential Revision: https://reviews.llvm.org/D96407
This patch adds 2 new options to control when Clang adds `mustprogress`:
1. -ffinite-loops: assume all loops are finite; mustprogress is added
to all loops, regardless of the selected language standard.
2. -fno-finite-loops: assume no loop is finite; mustprogress is not
added to any loop or function. We could add mustprogress to
functions without loops, but we would have to detect that in Clang,
which is probably not worth it.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D96419
This patch uses the existing logic of CUDA for searching libomptarget
and extracts it to a common method.
Reviewed By: JonChesterfield, tianshilei1992
Differential Revision: https://reviews.llvm.org/D96248
After D93264, using both -fdebug-info-for-profiling and
-fpseudo-probe-for-profiling will cause the compiler to crash.
Diagnose these conflicting options in the driver.
Also, the existing CodeGen test was using the driver when it should be
running cc1.
Differential Revision: https://reviews.llvm.org/D96354
Add support for the following options:
* -fopenmp
* -fopenacc
Update OpenMP and OpenACC semantics tests to use the new driver if it is built, otherwise use f18.
OpenMP tests that include `use omp_lib` or run `test_symbols.sh` have not been updated as they require options `-intrinsic-module-directory` and `-funparse-with-symbols` which are currently not implemented in the new driver.
Similarly OpenACC tests that run `test_symbols.sh` have not been updated.
This patch also moves semanticsContext to CompilerInvocation and creates it in CompilerInvocation#setSemanticsOpts so that the semantics context can use Fortran::parser::Options#features.
Summary of changes:
- Move semanticsContext to CompilerInvocation.h
- Update OpenMP and OpenACC semantics tests that do not rely on `-intrinsic-module-directory` and `-funparse-with-symbols` to use %flang
Differential Revision: https://reviews.llvm.org/D96032
Since ToolChain::GetCXXStdlibType() is a simple getter that might emit
the "invalid library name in argument" warning, it can conceivably be
called several times while initializing the build pipeline.
Before this patch, a simple 'clang++ -stdlib=foo ./test.cpp' would print
the warning twice, -rt=lib=foo would print 6 times.
Change this and always only print the warning once. Keep the rest of the
semantics of the functions.
Differential Revision: https://reviews.llvm.org/D95915
The patch only plumbs through the option necessary for targeting sm_86 GPUs w/o
adding any new functionality.
Differential Revision: https://reviews.llvm.org/D95974
This patch added a distinct CUID for each input file, which is represented by InputAction.
clang initially creates an InputAction for each input file for the host compilation. In CUDA/HIP action
builder, each InputAction is given a CUID and cloned for each GPU arch, and the CUID is also cloned. In this way,
we guarantee the corresponding device and host compilation for the same file shared the
same CUID. On the other hand, different compilation units have different CUID.
-fuse-cuid=random|hash|none is added to control the method to generate CUID. The default
is hash. -cuid=X is also added to specify CUID explicitly, which overrides -fuse-cuid.
Reviewed by: Artem Belevich
Differential Revision: https://reviews.llvm.org/D95007
Currently -fgpu-rdc is not passed to host clang -cc1.
This causes issue because -fgpu-rdc affects shadow
variable linkage in host compilation.
Reviewed by: Artem Belevich
Differential Revision: https://reviews.llvm.org/D96105
This fixes Bugzilla #48894 for Arm, where it
was reported that -Wa,-march was not being handled
by the integrated assembler.
This was previously fixed for -Wa,-mthumb by
parsing the argument in ToolChain::ComputeLLVMTriple
instead of CollectArgsForIntegratedAssembler.
It has to be done in the former because the Triple
is read only by the time we get to the latter.
Previously only mcpu would work via -Wa but only because
"-target-cpu" is it's own option to cc1, which we were
able to modify. Target architecture is part of "-target-triple".
This change applies the same workaround to -march and cleans up
handling of -Wa,-mcpu at the same time. There were some
places where we were not using the last instance of an argument.
The existing -Wa,-mthumb code was doing this correctly,
so I've just added tests to confirm that.
Now the same rules will apply to -Wa,-march/-mcpu as would
if you just passed them to the compiler:
* -Wa/-Xassembler options only apply to assembly files.
* Architecture derived from mcpu beats any march options.
* When there are multiple mcpu or multiple march, the last
one wins.
* If there is a compiler option and an assembler option of
the same type, we prefer the one that fits the input type.
* If there is an applicable mcpu option but it is overruled
by an march, the cpu value is still used for the "-target-cpu"
cc1 option.
Reviewed By: nickdesaulniers
Differential Revision: https://reviews.llvm.org/D95872
Add support for option -J/-module-dir in the new Flang driver. This
will allow for including module files in other directories, as the
default search path is currently the working folder. This also provides
an option of storing the output module in the specified folder.
Differential Revision: https://reviews.llvm.org/D95448
Add support for the following layout options:
* -ffree-form
* -ffixed-form
- -ffixed-line-length=n (alias -ffixed-line-length-n)
Additionally remove options `-fno-free-form` and `-fno-fixed-form` as they were initially added to forward to gfortran but gfortran does not support these flags.
This patch adds the flag FlangOnlyOption to the existing options `-ffixed-form`, `-ffree-form` and `-ffree-line-length-` in Options.td. As of commit 6a75496836ea14bcfd2f4b59d35a1cad4ac58cee, these flags are not currently forwarded to gfortran anyway.
The default fixed line length in FrontendOptions is 72, based off the current default in Fortran::parser::Options. The line length cannot be set to a negative integer, or a positive integer less than 7 excluding 0, consistent with the behaviour of gfortran.
This patch does not add `-ffree-line-length-n` as Fortran::parser::Options does not have a variable for free form columns.
Whilst the `fixedFormColumns` variable is used in f18 for `-ffree-line-length-n`, f18 only allows `-ffree-line-length-none`/`-ffree-line-length-0` and not a user-specified value. `fixedFormcolumns` cannot be used in the new driver as it is ignored in the frontend when dealing with free form files.
Summary of changes:
- Remove -fno-fixed-form and -fno-free-form from Options.td
- Make -ffixed-form, -ffree-form and -ffree-line-length-n FlangOnlyOption in Options.td
- Create AddFortranDialectOptions method in Flang.cpp
- Create FortranForm enum in FrontendOptions.h
- Add fortranForm_ and fixedFormColumns_ to Fortran::frontend::FrontendOptions
- Update fixed-form-test.f so that it guarantees that it fails when forced as a free form file to better facilitate testing.
Differential Revision: https://reviews.llvm.org/D95460
This patch adds AMDGPUOpenMPToolChain for supporting OpenMP
offloading to AMD GPU's.
Originally authored by Greg Rodgers
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D94961
Generate outline atomics if compiling for armv8-a non-LSE AArch64 Linux
(including Android) targets to use LSE instructions, if they are available,
at runtime. Library support is checked by clang driver which doesn't enable
outline atomics if no proper libraries (libgcc >= 9.3.1 or compiler-rt) found.
Differential Revision: https://reviews.llvm.org/D93585
This reverts commit fae16fc0eed7cf60207901818cfe040116f2ef00.
Breaks building compiler-rt android runtimes with trunk clang
but older NDK, see discussion on https://reviews.llvm.org/D95166
clang-cl already defaults to C17 for .c files, but no harm
in accepting these flags. Fixes PR48185.
Differential Revision: https://reviews.llvm.org/D95575
On non-Windows platforms, --sysroot can be used to make the compiler use
a single, hermetic directory for all header and library files.
This is useful, but difficult to do on Windows. After D95472 it's
possible to achieve this with two flags:
out/gn/bin/clang-cl win.c -fuse-ld=lld \
/vctoolsdir path/to/VC/Tools/MSVC/14.26.28801 \
/winsdkdir path/to/win_sdk
But that's still cumbersome: It requires two flags instead of one, and
it requires writing down the (changing) VC/Tools/MSVC version.
This adds a new `/winsysroot <dir>` flag that's effectively an alias to
these two flags. With this, building against a hermetic Windows
toolchain only needs:
out/gn/bin/clang-cl win.c -fuse-ld=lld /winsysroot path
`/winsysroot <dir>` is the same as adding
/vctoolsdir <dir>/VC/Tools/MSVC/<vctoolsver>
/winsdkdir <dir>/Windows Kits/<winsdkmajorversion>
`<vctoolsver>` is taken from `/vctoolsversion` if passed, or else it's
the name of the directory in `<dir>/VC/Tools/MSVC` that's the highest
numeric tuple.
`<winsdkmajorversion>` is the major version in /winsdkversion if passed,
else it's the name of the directory in `<dir>/Windows Kits` that's the
highest number.
So `/winsysroot <path>` requires this subfolder structure:
path/
VC/
Tools/
MSVC/
14.26.28801 (or another number)
include/
...
Windows Kits/
10/
Include/
10.0.19041.0/ (or another number)
um/
...
Lib/
10.0.19041.0/ (or another number)
um/
x64/
...
...
Differential Revision: https://reviews.llvm.org/D95534
/vctoolsdir and /winsdkdir take precedence over the INCLUDE env var,
so they should also take precedence over LIB. It's not quite as neat
since LIB is still read by the linker and the linker just prefers
the -libpath: paths the driver now passes, but as long as all libraries
are present at /vctoolsdir and /winsdkdir, there's no harm in the linker
also looking at LIB later.
This fixes cl-options.c after a5d85cbe on Windows when LIB is set.
Another way to fix the test would be to prefix the clang-cl
line with `env --unset=LIB`, but I think it's better to fix the
flag to work as expected instead of making the test work around
the surprising behavior that LIB being set causes clang-cl to
not pass -libpath: flags to the linker when /vctoolsdir and
/winsdkdir are used.
These do for the Windows SDK path what D85998 did for
%VCToolsInstallDir% with /vctoolsdir: Offer a way to set them with an
explicit commandline switch.
With this (and /vctoolsdir), it's possible to compile and link
against hermetic vctools and winsdk directories with:
out/gn/bin/clang-cl win.c -fuse-ld=lld \
/vctoolsdir path/to/VC/Tools/MSVC/14.26.28801 \
/winsdkdir path/to/win_sdk
compared to a long list of -imsvc and /link /libpath: flags.
While here:
- Change the case of the "Include" folder inside the windows sdk
from "include" to "Include" to match on-disk case. Since the
Windows file system is case-insensitive this isn't a behavior
change, it's just a bit cleaner.
- Add libpath tests to the /vctoolsdir
- Add a FIXME about reading env vars for win sdk and ucrt sdk
if these flags aren't present, to match the VCToolsInstallDir
logic
We should also cache all these computed paths in the driver instead
of computing them every time they're queried, but that's for a future
patch.
It'd also be nice to invent a /winsysroot: flag that sets both
/vctoolsdir: and /winsdkdir: to some well-known subdirectory.
That's for a future patch as well.
Differential Revision: https://reviews.llvm.org/D95472
This change implements support for applying profile instrumentation
only to selected files or functions. The implementation uses the
sanitizer special case list format to select which files and functions
to instrument, and relies on the new noprofile IR attribute to exclude
functions from instrumentation.
Differential Revision: https://reviews.llvm.org/D94820
The unwinder used by the crash handler on versions of Android prior to
API 29 did not correctly handle binaries built with rosegment, which is
enabled by default for LLD. Android only supports LLD, so it's not an
issue that this flag is not accepted by other linkers.
Reviewed By: srhines
Differential Revision: https://reviews.llvm.org/D95166
There are two use cases.
Assembler
We have accrued some code gated on MCAsmInfo::useIntegratedAssembler(). Some
features are supported by latest GNU as, but we have to use
MCAsmInfo::useIntegratedAs() because the newer versions have not been widely
adopted (e.g. SHF_LINK_ORDER 'o' and 'unique' linkage in 2.35, --compress-debug-sections= in 2.26).
Linker
We want to use features supported only by LLD or very new GNU ld, or don't want
to work around older GNU ld. We currently can't represent that "we don't care
about old GNU ld". You can find such workarounds in a few other places, e.g.
Mips/MipsAsmprinter.cpp PowerPC/PPCTOCRegDeps.cpp X86/X86MCInstrLower.cpp
AArch64 TLS workaround for R_AARCH64_TLSLD_MOVW_DTPREL_* (PR ld/18276),
R_AARCH64_TLSLE_LDST8_TPREL_LO12 (https://bugs.llvm.org/show_bug.cgi?id=36727https://sourceware.org/bugzilla/show_bug.cgi?id=22969)
Mixed SHF_LINK_ORDER and non-SHF_LINK_ORDER components (supported by LLD in D84001;
GNU ld feature request https://sourceware.org/bugzilla/show_bug.cgi?id=16833 may take a while before available).
This feature allows to garbage collect some unused sections (e.g. fragmented .gcc_except_table).
This patch adds `-fbinutils-version=` to clang and `-binutils-version` to llc.
It changes one codegen place in SHF_MERGE to demonstrate its usage.
`-fbinutils-version=2.35` means the produced object file does not care about GNU
ld<2.35 compatibility. When `-fno-integrated-as` is specified, the produced
assembly can be consumed by GNU as>=2.35, but older versions may not work.
`-fbinutils-version=none` means that we can use all ELF features, regardless of
GNU as/ld support.
Both clang and llc need `parseBinutilsVersion`. Such command line parsing is
usually implemented in `llvm/lib/CodeGen/CommandFlags.cpp` (LLVMCodeGen),
however, ClangCodeGen does not depend on LLVMCodeGen. So I add
`parseBinutilsVersion` to `llvm/lib/Target/TargetMachine.cpp` (LLVMTarget).
Differential Revision: https://reviews.llvm.org/D85474
This change implements support for applying profile instrumentation
only to selected files or functions. The implementation uses the
sanitizer special case list format to select which files and functions
to instrument, and relies on the new noprofile IR attribute to exclude
functions from instrumentation.
Differential Revision: https://reviews.llvm.org/D94820
From this patch (plus some landed patches), `deviceRTLs` is taken as a regular OpenMP program with just `declare target` regions. In this way, ideally, `deviceRTLs` can be written in OpenMP directly. No CUDA, no HIP anymore. (Well, AMD is still working on getting it work. For now AMDGCN still uses original way to compile) However, some target specific functions are still required, but they're no longer written in target specific language. For example, CUDA parts have all refined by replacing CUDA intrinsic and builtins with LLVM/Clang/NVVM intrinsics.
Here're a list of changes in this patch.
1. For NVPTX, `DEVICE` is defined empty in order to make the common parts still work with AMDGCN. Later once AMDGCN is also available, we will completely remove `DEVICE` or probably some other macros.
2. Shared variable is implemented with OpenMP allocator, which is defined in `allocator.h`. Again, this feature is not available on AMDGCN, so two macros are redefined properly.
3. CUDA header `cuda.h` is dropped in the source code. In order to deal with code difference in various CUDA versions, we build one bitcode library for each supported CUDA version. For each CUDA version, the highest PTX version it supports will be used, just as what we currently use for CUDA compilation.
4. Correspondingly, compiler driver is also updated to support CUDA version encoded in the name of bitcode library. Now the bitcode library for NVPTX is named as `libomptarget-nvptx-cuda_[cuda_version]-sm_[sm_number].bc`, such as `libomptarget-nvptx-cuda_80-sm_20.bc`.
With this change, there are also multiple features to be expected in the near future:
1. CUDA will be completely dropped when compiling OpenMP. By the time, we also build bitcode libraries for all supported SM, multiplied by all supported CUDA version.
2. Atomic operations used in `deviceRTLs` can be replaced by `omp atomic` if OpenMP 5.1 feature is fully supported. For now, the IR generated is totally wrong.
3. Target specific parts will be wrapped into `declare variant` with `isa` selector if it can work properly. No target specific macro is needed anymore.
4. (Maybe more...)
Reviewed By: JonChesterfield
Differential Revision: https://reviews.llvm.org/D94745
The previous implementation required that `-maltivec` be specified when using either `-mabi=vec-extabi` or `-mabi=vec-default`, this patch removes that requirement.
Reviewed By: cebowleratibm
Differential Revision: https://reviews.llvm.org/D94986
We're choosing to take an opt-in approach for landing Relative VTables, so we'll
need asan-equivalent multilibs with relative vtables enabled. Afterwards, we can
just flip the switch in our build.
Differential Revision: https://reviews.llvm.org/D95253
