For `-foo=bar`, getSpelling return `-foo=` which is exactly what we need from
the diagnostic. Drop `-` from the err_drv_unsupported_option_argument template.
This change makes `--` long option diagnostics more convenient.
Reviewed By: lenary
Differential Revision: https://reviews.llvm.org/D137659
This revision fixes typos where there are 2 consecutive words which are
duplicated. There should be no code changes in this revision (only
changes to comments and docs). Do let me know if there are any
undesirable changes in this revision. Thanks.
Clang detects the GCC version from the libdir. However, modern
GCC versions only include the major version in the libdir
(something like lib/gcc/powerpc64le-linux-gnu/12/), not all
version components. For this reason, even though the system has
a supported libstdcxx, it will still fail the check against the
12.1.0 version requirement.
Fix this by doing the same thing we do for patch versions: Assume
that a missing minor version is larger than any specific version.
To allow this to be tested, we need to fix two additional issues:
First, the GCC toolchain directories used for testing need to
contain a crtbegin.o file to be properly detected. The existing
tests actually ended up using a 0.0.0 version, rather the intended
one. Second, we also need to satisfy the glibc version check based
on the dynamic linker. To do so, respect the --dyld-prefix argument
and add the necessary file to the test toolchain directory.
Differential Revision: https://reviews.llvm.org/D136258
We've been working around this for a long time in the Linux kernel; we
bend over backwards to continue to support CC=clang (w/
-fno-integrated-as) for architectures where clang can't yet be used to
assemble the kernel's assembler sources. Supporting debug info for the
combination of CC=clang w/ GNU binutils as "GAS" has been painful.
Fix this in clang so that we can work towards dropping complexity in the
Linux kernel's build system, Kbuild, for supporting this combination of
tools.
GAS added support for -gdwarf-{3|4|5} in 2020 2.35 release via
commit 31bf18645d98 ("Add support for --dwarf-[3|4|5] to assembler command line.")
Refactor code to share logic between integrated-as and non-integrated-as
for determining the implicit default. This change will now always
explicitly pass a -gdwarf-* flag to the GNU assembler when -g is
specified.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D136707
We've been working around this for a long time in the Linux kernel; we
bend over backwards to continue to support CC=clang (w/
-fno-integrated-as) for architectures where clang can't yet be used to
assemble the kernel's assembler sources. Supporting debug info for the
combination of CC=clang w/ GNU binutils as "GAS" has been painful.
Fix this in clang so that we can work towards dropping complexity in the
Linux kernel's build system, Kbuild, for supporting this combination of
tools.
GAS added support for -g in 2004 2.16 release via
commit 329e276daf98 ("Add support for a -g switch to GAS")
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D136309
Previously, OpenMP linking would be done explicitly in a linker stage.
For `x86_64` offloading this would just use the host linker, which could
be the `bfd` linker. This linker had problems linking relocations
against variables with protected visibility so we force `-Bsymbolic`
when linking. After the deprecation of the old offloading driver this
code is no longer used and can be removed.
Reviewed By: tianshilei1992
Differential Revision: https://reviews.llvm.org/D136363
This option specifies a GCC installation directory such as
/usr/lib/gcc/x86_64-linux-gnu/12, /usr/lib/gcc/x86_64-gentoo-linux-musl/11.2.0 .
It is intended to replace --gcc-toolchain=, which specifies a directory where
`lib/gcc{,-cross}` can be found. When --gcc-toolchain= is specified, the
selected `lib/gcc/$triple/$version` installation uses complex logic and the
largest GCC version is picked. There is no way to specify another version in the
presence of multiple GCC versions.
D25661 added gcc-config detection for Gentoo: `ScanGentooConfigs`.
The implementation may be simplified by using --gcc-install-dir=.
Reviewed By: mgorny
Differential Revision: https://reviews.llvm.org/D133329
With the initial support added, clang can compile `helloworld` C
to executable file for loongarch64. For example:
```
$ cat hello.c
int main() {
printf("Hello, world!\n");
return 0;
}
$ clang --target=loongarch64-unknown-linux-gnu --gcc-toolchain=xxx --sysroot=xxx hello.c
```
The output a.out can run within qemu or native machine. For example:
```
$ file ./a.out
./a.out: ELF 64-bit LSB pie executable, LoongArch, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-loongarch-lp64d.so.1, for GNU/Linux 5.19.0, with debug_info, not stripped
$ ./a.out
Hello, world!
```
Currently gcc toolchain and sysroot can be found here:
https://github.com/loongson/build-tools/releases/download/2022.08.11/loongarch64-clfs-5.1-cross-tools-gcc-glibc.tar.xz
Reference: https://github.com/loongson/LoongArch-Documentation
The last commit hash (main branch) is:
99016636af64d02dee05e39974d4c1e55875c45b
Note loongarch32 is not fully tested because there is no reference
gcc toolchain yet.
Differential Revision: https://reviews.llvm.org/D130255
This is the Linux/sparc64 equivalent to D118021
<https://reviews.llvm.org/D118021>, necessary to provide an external
implementation of atomics on 32-bit SPARC which LLVM cannot inline even
with `-mcpu=v9` or an equivalent default.
Tested on `sparc64-unknown-linux-gnu`.
Differential Revision: https://reviews.llvm.org/D130569
Summary:
This is an essential piece of infrastructure for us to be
continuously testing debug info with BOLT. We can't only make changes
to a test repo because we need to change debuginfo tests to call BOLT,
hence, this diff needs to sit in our opensource repo. But when upstreaming
to LLVM, this should be kept BOLT-only outside of LLVM. When upstreaming,
we need to git diff and check all folders that are being modified by our
commits and discard this one (and leave as an internal diff).
To test BOLT in debuginfo tests, configure it with -DLLVM_TEST_BOLT=ON.
Then run check-lldb and check-debuginfo.
Manual rebase conflict history:
https://phabricator.intern.facebook.com/D29205224https://phabricator.intern.facebook.com/D29564078https://phabricator.intern.facebook.com/D33289118https://phabricator.intern.facebook.com/D34957174
Test Plan:
tested locally
Configured with:
-DLLVM_ENABLE_PROJECTS="clang;lld;lldb;compiler-rt;bolt;debuginfo-tests"
-DLLVM_TEST_BOLT=ON
Ran test suite with:
ninja check-debuginfo
ninja check-lldb
Reviewers: #llvm-bolt
Subscribers: ayermolo, phabricatorlinter
Differential Revision: https://phabricator.intern.facebook.com/D35317341
Tasks: T92898286
When linking a Fortran program, we need to add the runtime libraries to
the command line. This is exactly what we do for Linux/Darwin, but the
MSVC interface is slightly different (e.g. -libpath instead of -L).
We also remove oldnames and libcmt, since they're not needed at the
moment and they bring in more dependencies.
We also pass `/subsystem:console` to the linker so it can figure out the
right entry point. This is only needed for MSVC's `link.exe`. For LLD it
is redundant but doesn't hurt.
Differential Revision: https://reviews.llvm.org/D126291
Co-authored-by: Markus Mützel <markus.muetzel@gmx.de>
No behavior change as GNU ld/gold/ld.lld ignore --dynamic-linker in -r mode.
This change makes the intention clearer as we already suppress --dynamic-linker
for -shared, -static, and -static-pie.
GNU ld has a hack that defaults to -X (--discard-locals) in the emulation file
`riscvelf.em`. The recommended way, as gcc/config/arm does, is to let the
compiler driver pass -X to ld.
(The motivation is likely to discard a plethora of `.L` symbols due to linker
relaxation.)
lld default to --discard-none. To make clang+lld match GNU ld's behavior, pass
-X to ld.
Note: GNU ld has a special rule to treat ld -r -s as ld -r -S -x. With -X, driver `-r -Wl,-s`
will behave as ld `-r -S -X`. This removes fewer symbols than `-r -S -x` but is safe.
Differential Revision: https://reviews.llvm.org/D127826
Instead of adding all devtoolset and gcc-toolset prefixes to the list of
prefixes, just scan the /opt/rh/ directory for the one with the highest
version number and only add that one.
Differential Revision: https://reviews.llvm.org/D125862
Currently if `--sysroot /` is passed to the Clang driver, the include paths generated by the Clang driver will start with a double slash: `//usr/include/...`.
If VFS is used to inject files into the include paths (for example, the Swift compiler does this), VFS will get confused and the injected files won't be visible.
This change makes sure that the include paths start with a single slash.
Fixes#28283.
Differential Revision: https://reviews.llvm.org/D126289
This patch basically extends https://reviews.llvm.org/D122008 with
support for MacOSX/Darwin.
To facilitate this, I've added `MacOSX` to the list of supported OSes in
Target.cpp. Flang already supports `Darwin` and it doesn't really do
anything OS-specific there (it could probably safely skip checking the
OS for now).
Note that generating executables remains hidden behind the
`-flang-experimental-exec` flag. Also, we don't need to add `-lm` on
MacOSX as `libm` is effectively included in `libSystem` (which is linked
in unconditionally).
Differential Revision: https://reviews.llvm.org/D125628
This patch allows systems to build the llvm-project with the devtoolset-11
toolchain.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D125499
This patch adds 2 missing items required for `flang-new` to be able to
generate executables:
1. The Fortran_main runtime library, which implements the main entry
point into Fortran's `PROGRAM` in Flang,
2. Extra linker flags to include Fortran runtime libraries (e.g.
Fortran_main).
Fortran_main is the bridge between object files generated by Flang and
the C runtime that takes care of program set-up at system-level. For
every Fortran `PROGRAM`, Flang generates the `_QQmain` function.
Fortran_main implements the C `main` function that simply calls
`_QQmain`.
Additionally, "<driver-path>/../lib" directory is added to the list of
search directories for libraries. This is where the required runtime
libraries are currently located. Note that this the case for the build
directory. We haven't considered installation directories/targets yet.
With this change, you can generate an executable that will print `hello,
world!` as follows:
```bash
$ cat hello.f95
PROGRAM HELLO
write(*, *) "hello, world!"
END PROGRAM HELLO
$ flang-new -flang-experimental-exec hello.f95
./a.out
hello, world!
```
NOTE 1: Fortran_main has to be a static library at all times. It invokes
`_QQmain`, which is the main entry point generated by Flang for the
given input file (you can check this with `flang-new -S hello.f95 -o - |
grep "Qmain"`). This means that Fortran_main has an unresolved
dependency at build time. The linker will allow this for a static
library. However, if Fortran_main was a shared object, then the linker
will produce an error: `undefined symbol: `_QQmain`.
NOTE 2: When Fortran runtime libraries are generated as shared libraries
(excluding Fortran_main, which is always static), you will need to
tell the dynamic linker (by e.g. tweaking LD_LIBRARY_PATH) where to look
for them when invoking the executables. For example:
```bash
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:<flang-build-dir>/lib/ ./a.out
```
NOTE 3: This feature is considered experimental and currently guarded
with a flag: `-flang-experimental-exec`.
Differential Revision: https://reviews.llvm.org/D122008
[1] https://github.com/flang-compiler/f18-llvm-project
CREDITS: Fortran_main was originally written by Eric Schweitz, Jean
Perier, Peter Klausler and Steve Scalpone in the fir-dev` branch in [1].
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Peter Klausler <pklausler@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Steve Scalpone <sscalpone@nvidia.com
In the past, `clang --target=riscv64-unknown-linux-gnu -mno-relax -c hello.s` will assemble hello.s without relaxation, but `clang --target=riscv64-unknown-linux-gnu -mno-relax -fno-integrated-as -c hello.s` doesn't pass the `-mno-relax` option to assembler, and assemble with relaxation
This patch pass the -mno-relax option to assembler when -fno-integrated-as is specified.
Differential Revision: https://reviews.llvm.org/D120639
Add CSKY target toolchains to support csky in linux and elf environment.
It can leverage the basic universal Linux toolchain for linux environment, and only add some compile or link parameters.
For elf environment, add a CSKYToolChain to support compile and link.
Also add some parameters into basic codebase of clang driver.
Differential Revision: https://reviews.llvm.org/D121445
--overlay-platform-toolchain inserts a whole new toolchain path with
higher priority than system default, which could be achieved by
composing smaller options. We need to figure out alternative solution
and what is missing among these basic options.
In some cases, we need to set alternative toolchain path other than the
default with system (headers, libraries, dynamic linker prefix, ld path,
etc.), e.g., to pick up newer components, but keep sysroot at the same
time (to pick up extra packages).
This change introduces a new option --overlay-platform-toolchain to set
up such alternative toolchain path.
Reviewed By: hubert.reinterpretcast
Differential Revision: https://reviews.llvm.org/D121992
GCC's compiled with --enable-version-specific-runtime-libs change the paths where includes and libs are found.
This patch adds support for these cases
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D118700
This patch adds the '-Bsymbolic' flag when we perform linking for the
offloading device. We already pass '-fvisibility=protected' but this is
not properly handled when using the bfd linker as is described in
https://maskray.me/blog/2021-05-16-elf-interposition-and-bsymbolic.
Previously this caused linker errors when creating the shared library.
Reviewed By: JonChesterfield
Differential Revision: https://reviews.llvm.org/D119018
--warn-shared-textrel is ignored in ld.lld and obsoleted in GNU ld
(https://sourceware.org/bugzilla/show_bug.cgi?id=22909).
Note: binutils can be configured with --enable-textrel-check=[yes|error]
to make GNU ld error for text relocations by default, like ld.lld.
Reviewed By: srhines
Differential Revision: https://reviews.llvm.org/D118942
See `gcc -dumpspecs` that -r essentially implies -nostdlib and suppresses
default -l* and crt*.o. The behavior makes sense because otherwise there will be
assuredly conflicting definitions when the relocatable output is linked into the
final executable/shared object.
Reviewed By: thesamesam, phosek
Differential Revision: https://reviews.llvm.org/D116843
ld.lld used by Android ignores .note.GNU-stack and defaults to noexecstack,
so the `-z noexecstack` linker option is unneeded.
The `--noexecstack` assembler option is unneeded because AsmPrinter.cpp
prints `.section .note.GNU-stack,"",@progbits` (when `llvm.init.trampoline` is unused),
so the assembler won't synthesize an executable .note.GNU-stack.
Reviewed By: danalbert
Differential Revision: https://reviews.llvm.org/D113840
Fangrui Song