Fixes an issue introduced by
9fb2db1e1f42 [flang] Retain spaces when preprocessing fixed-form source
Where flang -fc1 fails to parse preprocessor output because it now
remains in fixed form.
Column info is important for sampling PGO to generate/load profile file.
On windows, it will be automatically added when using -gdwarf to
generate
profile file. It should also be generated when fprofile-sample-use= is
used.
setBaseArg, only used by -XArch_* options, are called in BuildJobs.
When processing --config and CL /clang:, BaseArg is always nullptr.
The unneeded parameter was introduced in https://reviews.llvm.org/D24933
If we create a cross toolchain with a ${triple}-ld.lld symlink, clang
finds that symlink and when it uses it, it's not recognized as "lld".
Let's resolve that symlink and consider it when determining lld-ness.
For example, clang provides hexagon-link specific link arguments such as
`-mcpu=hexagonv65` and `-march=hexagon` when
hexagon-unknown-linux-musl-ld.lld is found. lld rejects this with the
following error:
hexagon-unknown-linux-musl-ld.lld: error: unknown emulation:
cpu=hexagonv65
Fixes: https://github.com/llvm/llvm-project/issues/116278
This change updates clang to report unsupported option errors regardless
of the command line argument order.
When clang is invoked with a source file and without `-c` it will both
compile and link. When an unsupported option is also part of the command
line clang should generated an error. However, if the source file name
comes before an object file, eg: `-lc`, the error is ignored.
```
$ clang --target=x86_64 -lc hello.c -mhtm
clang: error: unsupported option '-mhtm' for target 'x86_64'
$ echo $?
1
```
but if `-lc` comes after `hello.c` the error is dropped
```
$ clang --target=x86_64 hello.c -mhtm -lc
$ echo $?
0
```
after this change clang will report the error regardless of the command
line argument order.
This patch:
- Supports both the passing and returning of BIND(C) type parameters.
- Adds `mabi` check for LoongArch64. Currently, flang only supports
`mabi=` option
set to `lp64d` in LoongArch64, other ABIs will report an error and may
be supported
in the future.
Reference ABI:
https://github.com/loongson/la-abi-specs/blob/release/lapcs.adoc#subroutine-calling-sequence
Two options for clang
-mdiv32: Use div.w[u] and mod.w[u] instructions with input not
sign-extended.
-mno-div32: Do not use div.w[u] and mod.w[u] instructions with input not
sign-extended.
The default is -mno-div32.
SLEEF math vector library now supports RISC-V target.
Commit: https://github.com/shibatch/sleef/pull/477
This patch enables the use of auto-vectorization with
subsequent replacement by the corresponding SLEEF function.
When linking programs with `eld`, we get a link error like below:
Error:
/inst/clang+llvm-19.1.0-cross-hexagon-unknown-linux-musl/x86_64-linux-gnu/bin/../target/hexagon-unknown-linux-musl//usr/lib/libc.a(scalbn.lo)(.text.scalbn+0x3c):
undefined reference to `__hexagon_muldf3'
libc has references to the clang_rt builtins library, so the order of
the libraries should be reversed.
The aliases are -mcpu=help and -mtune=help. There is still an issue with
the output which prints an example line that references clang. That is
not fixed here because it is printed in llvm/MC/SubtargetInfo.cpp. Some
more thought is needed to determine how best to handle this.
Fixes#117010
We do not have support for the threadsafe statics on the GPU side.
However, we do sometimes end up with empty local static initializers,
and those happen to trigger calls to `__cxa_guard*`, which breaks
compilation.
Partially addresses https://github.com/llvm/llvm-project/issues/117023
Two options for clang
-mld-seq-sa: Do not generate load-load barrier instructions (dbar 0x700)
-mno-ld-seq-sa: Generate load-load barrier instructions (dbar 0x700)
The default is -mno-ld-seq-sa
We are currently getting:
`clang: error: invalid argument '-fsanitize-minimal-runtime' not allowed
with '-fsanitize=implicit-conversion'`
when running
`-fsanitize=implicit-conversion -fsanitize-minimal-runtime`
because `implicit-conversion` now includes
`implicit-bitfield-conversion` which is not included in the `integer`
check. The `integer` check includes the `implicit-integer-conversion`
checks and is supported by the trapping option and because of that
compatible with the minimal runtime. It is thus reasonable to make
`implicit-bitfield-conversion` compatible with the minimal runtime.
The Flag form options are accepted and silently ignored, which can be
surprising. The Eq form is supposed to be used instead, e.g.
-fprofile-sample-use=a.afdo.
Since we does not intend to support GCC's "fbaata.afdo" filename, just
remove the two options. While here, clean up code as -fauto-profile= is
an alias.
Pull Request: https://github.com/llvm/llvm-project/pull/113528
Introduces the SYCL based toolchain and initial toolchain construction
when using the '-fsycl' option. This option will enable SYCL based
offloading, creating a SPIR-V based IR file packaged into the compiled
host object.
This includes early support for creating the host/device object using
the new offloading model. The device object is created using the
spir64-unknown-unknown target triple.
New/Updated Options:
-fsycl Enables SYCL offloading for host and device
-fsycl-device-only
Enables device only compilation for SYCL
-fsycl-host-only
Enables host only compilation for SYCL
RFC Reference:
https://discourse.llvm.org/t/rfc-sycl-driver-enhancements/74092
Until now, these have been hardcoded as a downstream patches in lld. Add
them to the driver so that the private patches can be removed.
PS5 only. On PS4, the equivalent hardcoded configuration will remain in
the proprietary linker.
SIE tracker: TOOLCHAIN-16704
Two features (i.e. `frecipe` and `lam-bh`) are added to
`sys.getHostCPUFeatures`. More features will be added in future.
In addition, this patch adds the features returned by
`sys.getHostCPUFeature` when `-march=native`.
Summary:
This was done a long time ago for OpenMP, but it seems HIP was never
updated. This patch rectifies that. The default for the LLVM backend is
5 so this is probably required for some stuff.
The -time option prints timing information for the subcommands
(compiler, linker) in a format similar to that used by gcc/gfortran.
This partially addresses requests from #89888
This implements
https://discourse.llvm.org/t/rfc-add-support-for-controlling-diagnostics-severities-at-file-level-granularity-through-command-line/81292.
Users now can suppress warnings for certain headers by providing a
mapping with globs, a sample file looks like:
```
[unused]
src:*
src:*clang/*=emit
```
This will suppress warnings from `-Wunused` group in all files that
aren't under `clang/` directory. This mapping file can be passed to
clang via `--warning-suppression-mappings=foo.txt`.
At a high level, mapping file is stored in DiagnosticOptions and then
processed with rest of the warning flags when creating a
DiagnosticsEngine. This is a functor that uses SpecialCaseLists
underneath to match against globs coming from the mappings file.
This implies processing warning options now performs IO, relevant
interfaces are updated to take in a VFS, falling back to RealFileSystem
when one is not available.
This patch implements support for `-fxray-shared` on AArch64 and fixes a
remaining issue in the previous PR #114431.
A bug in the XRay `CMakeLists.txt` caused the XRay assembly sources to
be built for every architecture in `XRAY_DSO_SUPPORTED_ARCH` on Apple.
This led to the compiler trying to compile AArch64 assembly for X86
targets and vice versa.
This is addressed here by ensuring that assembly sources are only built
for the matching architecture (see fixup commit).
**Original PR description:**
This patch adds support for `-fxray-shared` on AArch64. This feature,
introduced in #113548 for x86_64, enables the instrumentation of shared
libraries with XRay.
Changes:
- Adds AArch64 to the list of targets supporting `-fxray-shared`
- Introduces PIC versions of the AArch64 XRay trampolines
- Adjusts relevant XRay tests
`--whole-archive` is passed to the linker to have it consume all objects
within the SIE Just My Code library, rather than just those that fulfil
outstanding references.
Prior to this change, `--no-whole-archive` was used to reset the
associated archive handling state in the linker, under the assumption
that `--whole-archive` wasn't already in effect. But that assumption may
be incorrect. So use `--push/pop-state` to restore the previous state,
whatever that may be.
Given the position of these switches on the link line, the problem
described with the outgoing code is unlikely to cause an issue in
practice. But push/pop protect against accidents due to future additions
to and reorderings of arguments.
PS5 only. The proprietary PS4 linker doesn't support `--push/pop-state`,
or an equivalent.
SIE tracker: TOOLCHAIN-16704.
When linking with other runtimes (OpenMP, sanitizers), the
addArchSpecificRPath() is being called. The same thing should happen
when linking with the Fortran runtime, this will improve user experience
massively.
Finish hooking up ClangIR code gen into the Clang control flow,
initializing enough that basic code gen is possible.
Add an almost empty `cir.func` op to the ClangIR dialect. Currently the
only property of the function is its name. Add the code necessary to
code gen a cir.func op.
Create essentially empty files
clang/lib/CIR/Dialect/IR/{CIRAttrs.cpp,CIRTypes.cpp}. These will be
filled in later as attributes and types are defined in the ClangIR
dialect.
(Part of upstreaming the ClangIR incubator project into LLVM.)
Until now, suppression of `DT_DEBUG` has been hardcoded as a downstream
patch in lld. This can instead be achieved by passing `-z rodynamic`.
Have the driver do this so that the private patch can be removed.
If the scope of lld's `-z rodynamic` is broadened (within reason) to do
more in future, that's likely to be fine as `PT_DYNAMIC` isn't writable
on PlayStation.
PS5 only. On PS4, the equivalent hardcoded configuration will remain in
the proprietary linker.
SIE tracker: TOOLCHAIN-16704
Executing `clang -Wp,` without any argument value causes Undefined
Behavior due to accessing a SmallVector without elements
Executing clang in debug mode raises an assert and Valgrind complains as
follow:
```
$ valgrind bin/clang -Wp,
==18620== Memcheck, a memory error detector
==18620== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==18620== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
==18620== Command: bin/clang -Wp,
==18620==
==18620== Conditional jump or move depends on uninitialised value(s)
==18620== at 0x44F215B: clang::driver::Driver::TranslateInputArgs(llvm::opt::InputArgList const&) const (in /home/jaime/devel/llvm-project/build/bin/clang-20)
==18620== by 0x4515831: clang::driver::Driver::BuildCompilation(llvm::ArrayRef<char const*>) (in /home/jaime/devel/llvm-project/build/bin/clang-20)
==18620== by 0x10B3435: clang_main(int, char**, llvm::ToolContext const&) (in /home/jaime/devel/llvm-project/build/bin/clang-20)
==18620== by 0xF78F99: main (in /home/jaime/devel/llvm-project/build/bin/clang-20)
==18620==
...
```
This removes the temporary ban on mixing AMDGCN flavoured SPIR-V and
concrete targets (e.g. `gfx900`) in the same HIPAMD compilation. This is
done primarily by tweaking the effective / observable triple when the
target is `amdgcnspirv`, which seamlessly composes with the existing
infra. The test is stolen from #75357.
