On Linux, PowerPC defines `int_fast16_t` and `int_fast32_t` as `long`.
Need to update the corresponding type, `c_int_fast16_t` and
`c_int_fast32_t` in `iso_c_binding` module so they are interoparable.
Follow-up to #81037.
ToolChain::LibraryPaths holds the new compiler-rt library directory
(e.g. `/tmp/Debug/lib/clang/19/lib/x86_64-unknown-linux-gnu`). However,
it might be empty when the directory does not exist (due to the `if
(getVFS().exists(P))` change in https://reviews.llvm.org/D158475).
If neither the old/new compiler-rt library directories exists, we would
suggest the undesired old compiler-rt file name:
```
% /tmp/Debug/bin/clang++ a.cc -fsanitize=memory -o a
ld.lld: error: cannot open /tmp/Debug/lib/clang/19/lib/linux/libclang_rt.msan-x86_64.a: No such file or directory
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
```
With this change, we will correctly suggest the new compiler-rt file name.
Fix#87150
Pull Request: https://github.com/llvm/llvm-project/pull/87866
This enables the -fopenmp=<library> option to the set of options
supported by flang.
The generated arguments for the FC1 compilation will appear in a
slightly different order, so one test had to be updated to be less
sensitive to order of the arguments.
And use it to print the correct default OpenMP version for flang and
flang -fc1.
This change adds an optional `HelpTextsForVariants` to options. This
allows you to change the help text that gets shown in documentation and
`--help` based on the program its being generated for.
As `OptTable` needs to be constexpr compatible, I have used a std::array
of help text variants. Each entry is:
(list of visibilities) - > help text string
So for the OpenMP version we have (flang, fc1) -> "OpenMP version for
flang is...".
So you can have multiple visibilities use the same string. The number of
entries is currently set to 1, and the number of visibilities per entry
is 2, because that's the maximum we need for now. The code is written so
we can increase these numbers later, and the unused elements will be initialised.
I have not applied this to group descriptions just because I don't know
of one that needs changing. It could easily be enabled for those too if
needed. There are minor changes to them just to get it all to compile.
This approach of storing many help strings per option in the 1 driver
library seemed preferable to making a whole new library for Flang (even
if that would mostly be including stuff from Clang).
The `--gcc-toolchain` and `--gcc-install-dir` option were previously only visible to the Clang driver, but not Flang. These determine which assembler, linker, and libraries to use, e.g. for cross-compiling, and therefore are relevant for Flang as well.
Tests are implemented using a mock GCC installation in `basic_cross_linux_tree` copied over from Clang's tests. The Clang driver already contains tests with `--driver-mode=flang` but `flang-new` is an entirely different executable (containing the `-fc1` stage) that should be tested as well. While not all files in `basic_cross_linux_tree` are strictly needed for testing those two driver flags, they will be necessarily needed for future added flags such as `--rtlib`.
Also remove the entry `*.o` in flang's `.gitignore` since `crt*.o` files are needed in the GCC mock installation.
Fixes#86729
This PR changes the build system to use use the sources for the module
`omp_lib` and the `omp_lib.h` include file from the `openmp` runtime
project and not from a separate copy of these files. This will greatly
reduce potential for inconsistencies when adding features to the OpenMP
runtime implementation.
When the OpenMP subproject is not configured, this PR also disables the
corresponding LIT tests with a "REQUIRES" directive at the beginning of
the OpenMP test files.
---------
Co-authored-by: Valentin Clement (バレンタイン クレメン) <clementval@gmail.com>
Most FIR passes only look for FIR operations inside of functions (either
because they run only on func.func or they run on the module but iterate
over functions internally). But there can also be FIR operations inside
of fir.global, some OpenMP and OpenACC container operations.
This has worked so far for fir.global and OpenMP reductions because they
only contained very simple FIR code which doesn't need most passes to be
lowered into LLVM IR. I am not sure how OpenACC works.
In the long run, I hope to see a more systematic approach to making sure
that every pass runs on all of these container operations. I will write
an RFC for this soon.
In the meantime, this pass duplicates the CFG conversion pass to also
run on omp reduction operations. This is similar to how the
AbstractResult pass is already duplicated for fir.global operations.
OpenMP array reductions 2/6
Previous PR: https://github.com/llvm/llvm-project/pull/84952
Next PR: https://github.com/llvm/llvm-project/pull/84954
---------
Co-authored-by: Mats Petersson <mats.petersson@arm.com>
On Darwin, -isysroot is needed and is automatically appended to
%flang and %flang_fc1, so use %flang_fc1 instead to have both -fc1
and -isysroot in the expected positions and avoid errors.
Polymorphic entity lowering status is good. The main remaining TODO is
to allow lowering of vector subscripted polymorphic entity, but this
does not deserve blocking all application using polymorphism.
Remove experimental option and enable lowering of polymorphic entity by
default.
Preliminary patch for https://github.com/llvm/llvm-project/pull/83285 to
turn polymorphism on by default.
Will give a few days warning for people to remove the flag from their
workflow using flang-new.
Also easier to revert if issues with the gfortran test suites.
The motivation here was a suggestion over in Compiler Explorer. You can
use `-mllvm` already to do this but since gfortran supports `-masm`, I
figured I'd try to add it.
This is done by flang expanding `-masm` into `-mllvm x86-asm-syntax=`,
then passing that to fc1. Which then collects all the `-mllvm` options
and forwards them on.
The code to expand it comes from clang `Clang::AddX86TargetArgs` (there
are some other places doing the same thing too). However I've removed
the `-inline-asm` that clang adds, as fortran doesn't have inline
assembly.
So `-masm` for flang purely changes the style of assembly output.
```
$ ./bin/flang-new /tmp/test.f90 -o - -S -target x86_64-linux-gnu
<...>
pushq %rbp
$ ./bin/flang-new /tmp/test.f90 -o - -S -target x86_64-linux-gnu -masm=att
<...>
pushq %rbp
$ ./bin/flang-new /tmp/test.f90 -o - -S -target x86_64-linux-gnu -masm=intel
<...>
push rbp
```
The test is adapted from `clang/test/Driver/masm.c` by removing the
clang-cl related lines and changing the 32 bit triples to 64 bit triples
since flang doesn't support 32 bit targets.
The implemented logic matches the logic used for Clang in emitting these
attributes. Although it's hoped that function attributes won't be needed
in the future (vs using fast math flags in individual IR instructions),
there are codegen differences currently with/without these attributes,
as can be seen in issues like #79257 or by hacking Clang to avoid
producing these attributes and observing codegen changes.
Ensure that #include FOO undergoes macro replacement. But, as is the
case with C/C++, continue to not perform macro replacement in a #include
directive with <angled brackets>.
This patch forwards the target CPU and features information from the
Flang frontend to MLIR func.func operation attributes, which are later
used to populate the target_cpu and target_features llvm.func
attributes.
This is achieved in two stages:
1. Introduce the `fir.target_cpu` and `fir.target_features` module
attributes with information from the target machine immediately after
the initial creation of the MLIR module in the lowering bridge.
2. Update the target rewrite flang pass to get this information from the
module and pass it along to all func.func MLIR operations, respectively
as attributes named `target_cpu` and `target_features`. These attributes
will be automatically picked up during Func to LLVM dialect lowering and
used to initialize the corresponding llvm.func named attributes.
The target rewrite and FIR to LLVM lowering passes are updated with the
ability to override these module attributes, and the `CodeGenSpecifics`
optimizer class is augmented to make this information available to
target-specific MLIR transformations.
This completes a full flow by which target CPU and features make it all
the way from compiler options to LLVM IR function attributes.
Intended to warn users of the 18.x release not to do this.
A better solution should be found for the 19.x release. See discussion
in https://github.com/llvm/llvm-project/pull/78152.
Unfortunately there is no warning on Windows currently. I am rushing to
get this landed before 18.x branches.
Currently there are several bits of code in the AArch64 driver which
attempt to enforce dependencies between optional features in the -march=
and -mcpu= options. However, these are based on the list of feature
names being enabled/disabled, so they have a lot of logic to consider
the order in which features were turned on and off, which doesn't scale
well as dependency chains get longer.
This patch moves the code handling these dependencies to TargetParser,
and changes them to use a Bitset of enabled features. This makes it easy
to check which features are enabled, and is converted back to a list of
LLVM feature names once all of the command-line options are parsed.
The motivating example for this was the -mcpu=cortex-r82+nofp option.
Previously, the code handling the dependency between the fp16 and
fp16fml extensions did not consider the nofp modifier, so it added
+fullfp16 to the feature list. This should have been disabled by the
+nofp modifier, and also the backend did follow the dependency between
fullfp16 and fp, resulting in fp being turned back on in the backend.
Most of the dependencies added to AArch64TargetParser.h weren't known
about by clang before, I built that list by checking what the backend
thinks the dependencies between SubtargetFeatures are.
The -pthread option seems to be extensively tested for various platforms by
clang. Since flang uses those parts of the clang driver, the only test added
is to ensure that the option is recognized by the frontend.
Make sure that `-mvscale-max` and `-mvscale-min` are only available for
targets that are known to support vscale and scalable vectors.
Also fix capitalization of function variables.
The linker name is different if the `lld` project is enabled
`-DLLVM_ENABLE_PROJECTS="...;lld"`.
---------
Co-authored-by: Leandro Lupori <leandro.lupori@gmail.com>
If DEFAULT_SYSROOT is not specfied when building flang, then the
-isysroot flag is needed to link binaries against system libraries
on Darwin. It's also needed when linking against a non-default
sysroot.
This patch adds support for the -mrvv-vector-bits flag in the Flang
driver, and
translates them to -mvscale-min/-mvscale-max.
The code was copied from the Clang toolchain (similarly to what was done
for
AArch64's -msve-vector-bits flag) so it also supports the same
-mrvv-vector-bits=zvl mode.
Note that Flang doesn't yet define the __riscv_v_fixed_vlen macro, so
the help
text has been updated to highlight that it's only defined for Clang.
If -nogpulib option is passed by the user, then the OpenMP device
runtime is not used and we should not emit globals to configure
debugging at compile-time for the device runtime.
Link to -nogpulib flag implementation for Clang:
https://reviews.llvm.org/D125314
This patch seeks to add the -gpulibc and -nogpulibc for Flang, which
allows the linking of the GPU libc library, this allows the use of
memcpy and other useful library functions for GPU.
In particular, this allows the Fortran runtime (written in C++) to be
compiled for offload and then linked against the GPU LIBC library via
this option to resolve memcpy and other C library functions that the
fortran runtime depends on for AMD GPU devices (and likely other GPU
devices).
This is the current method I've tested and found to be able to utilise
the Fortran runtime when compiled for AMD GPU, albeit it requires
compiling libc for GPU and then the Fortran runtime for GPU, so not
particularly straight forward or user friendly yet.
Activating this option will allow the subset of C functions to also be
utilised for GPU in other C/C++ based Fortran libraries if any are made
when linking against GPU libc.
At present, when building static or shared libraries, Flang adds
`-lFortran_main.a` (or `/WHOLEARCHIVE:Fortran.*.lib` pon Windows) to the
link line. This leads to the problem that `_QQmain` and
`_QQEnvironmentDefaults` (as of the time of this PR) are symbols marked
as used, while `main` is being defined. This should not happen and this
PR fixes this by detecting if `-shared` or `-static` is used on the
Flang command line and removing the static `Fortran_main` library.
---------
Co-authored-by: kkwli <kkwli@users.noreply.github.com>
The AIX linker does not support the `--whole-archive` option, removing
the option if the OS is AIX.
---------
Co-authored-by: Mark Danial <mark.danial@ibm.com>
