When an assembly file is passed to the Flang driver, it currently fails
with a confusing internal error mentioning the unsupported `-cc1as`
tool.
This update detects assembly inputs early in the driver and emits a
clear, user-facing diagnostic explaining that Flang does not support
assembly files as input. The logic is implemented in a small helper
function and is intentionally temporary, so it can be removed once Flang
gains support for assembling inputs.
Fixes: #173528
This PR makes a couple of minor tweaks to the lowering for
declare_mapper operations:
1) Add declare_mapper operations to the list of global operations to
have optimisation passes
executed on them. Primarily just to make sure we keep it inline with
other global operations
that contain regions. Prevents oddities where we embed FIR/HLFIR into
the mapper that needs
lowered before being converted to LLVM-IR. One example that springs to
mind is if we ever
decide to remove the single block condition on the operation to allow
conditional checks
for mapped data.
2) Add a CodeGenOpenMP.cpp conversion for DeclareMapperOp to make sure
we convert the return
type correctly from a BoxType to a struct type rather than an opaque
pointer when lowering.
Currently, I've left out the block argument types from being converted
as they're wrapped
in a fir.ref and would be opauqe pointers in either case.
So some minor additions to keep declare_mapper a little more inline with
the rest of the OpenMP operations.
Driver/compiler option plumbing to get -f(no-)protect-parens supported
on flang. (This option was already supported in clang, so extended the
option config to enable it in flang.)
In the compiler, support it in code gen options and in lowering options.
Hooked up lowering options with the code by @alexey-bataev that turns
off reassociation transformations.
Co-authored-by: Alexey Bataev <a.bataev@outlook.com>
We should not allow `-wavefrontsize32` and `-wavefrontsize64` to be
specified at the same time. We should also not allow `-wavefrontsize32`
on a target that only supports `wavefrontsize32`, and the vice versa.
Currently, the DIFile debuginfo nodes use "standard input" as the file
name when compiling with -g and reading input from stdin. This has been
changed to "<stdin>" for consistency with clang and gfortran.
Fixes#60288
Reserve "-funsafe-cray-pointers" (with "f") for the driver. In the
fir-alias-analysis use "-unsafe-cray-pointers" (without "f").
This prevents conflicts with how certain kinds of tools use the "unsafe
Cray pointers" options.
A character in a fixed-form source line (as opposed to a comment or
compiler directive) can't have a non-digit in its label field, columns 1
through 5. The prescanner presently emits only a warning for this case.
Retain the warning for -E output, but otherwise diagnose an error.
(This change affected a number of tests that relied on this situation
being a warning just so that they could test prescanner warnings, and
those tests were adjusted to use another warning.)
Fixes https://github.com/llvm/llvm-project/issues/50563.
This ensures that both the midend and backend see consistent values for
VecLib, so that for example frem can be selected correctly.
The test involves running the front-end, midend (to vectorize) and
backend to prove it can lower the vector frem call.
Fixes#172483
- Pass plugins can use LLVM options, matching #173287.
- Pass plugins can run a hook before codegen, matching #171872.
- Pass plugins are now tested whenever they can be built, matching
#171998.
Plugins currently don't work on AIX, tracked in #172203.
This reverts commit ccfb97b42174eab118a4e4222c25e986db876563.
This was reverted due to the unfortunate reliance on external device
library installations, which ship the last rocm released bitcode. The
last attempt was 8 months ago, so hopefully the buildbots are now caught
up to a more recent build that no longer needs the old control library.
Add a requested warning for completely unused local variables. The
implementation runs a scan over typed expressions during the existing
expression semantics pass to detect variable uses, and a routine at the
end of semantics to take a pass over the symbol tables to find unused
locals.
The new infrastructure needed to detect variable uses, and the existing
infrastructure that detects potential variable definitions, then makes
it easy to detect variables that are used without any possible
initialization or definition, so I did that too.
The warning for unused locals is off by default -- they might indicate a
misspelling (that IMPLICIT NONE would have caught), but seem otherwise
generally benign. The warning for uses of completely uninitialized and
undefined variables, however, is enabled by default, since that's likely
to indicate a program bug that should be investigated.
This patch touches a lot of files lightly. Many of these files are tests
that would have produced needless warning noise; one new test was added.
Fixes https://github.com/llvm/llvm-project/issues/173276.
The shell feature only implies that we are not running on Windows now
that the internal shell feature is available everywhere. Replace it with
UNSUPPORTED: system-windows on non-portable tests so we can eventually
get rid of the feature.
If `-funsafe-cray-pointers` is passed to flang driver, pass `-mmlir
-funsafe-cray-pointers` to the compiler. This should make it easier to
work with the code that relies on behavior before
https://github.com/llvm/llvm-project/pull/170908
These options are supported by the Intel compiler. There are similar
options in the IBM compiler as well. Each of the options can be provided
more than once. In that case, the last occurence of -fdefault-real-*
(respectively -fdefault-integer-*) is used if both -fdefault-real-4 and
-fdefault-real-8 are specified. The fdefault.f90 test file was
extensively modified. Testing handling of the options by the driver was
removed since testing handling of the options by -fc1 is sufficient.
Fixes#160252
The following tests converted:
Driver/compiler-options.f90
Driver/frontend-forwarding.f90
Driver/optimization-remark.f90
HLFIR/hlfir-flags.f90
Lower/achar.f90
Depends upon https://github.com/llvm/llvm-project/pull/170900
Re-land https://github.com/llvm/llvm-project/pull/169544
Previously we were less specific for POINTER/TARGET: encoding that they
could alias with (almost) anything.
In the new system, the "target data" tree is now a sibling of the other
trees (e.g. "global data"). POITNTER variables go at the root of the
"target data" tree, whereas TARGET variables get their own nodes under
that tree. For example,
```
integer, pointer :: ip
real, pointer :: rp
integer, target :: it
integer, target :: it2(:)
real, target :: rt
integer :: i
real :: r
```
- `ip` and `rp` may alias with any variable except `i` and `r`.
- `it`, `it2`, and `rt` may alias only with `ip` or `rp`.
- `i` and `r` cannot alias with any other variable.
Fortran 2023 15.5.2.14 gives restrictions on entities associated with
dummy arguments. These do not allow non-target globals to be modified
through dummy arguments and therefore I don't think we need to make all
globals alias with dummy arguments.
I haven't implemented it in this patch, but I wonder whether it is ever
possible for `ip` to alias with `rt`.
While I was updating the tests I fixed up some tests that still assumed
that local alloc tbaa wasn't the default.
Cray pointers/pointees are (optionally) modelled as aliasing with all
non-descriptor data. This is not enabled by default.
I found no functional regressions in the gfortran test suite.
Reapplication of #137828, changes:
* Workaround CMAKE_Fortran_PREPROCESS_SOURCE issue for CMake < 2.24: The
issue is that `try_compile` does not forward manually-defined compiler
flang variables to the test build environment; instead of just a
negative test result, it aborts the configuration step itself. To be
fair, manually defining these variables is deprecated since at least
CMake 3.6.
* Missing flang cmd line flags for CMake < 3.28 `-target=`, `-O2`, `-O3`
* It is now possible to set FLANG_RT_ENABLED_STATIC=OFF and
FLANG_RT_ENABLE_SHARED=OFF at the same and is the default for amdgpu and
nvptx targets. In this mode, only the .mod files are compiled --
necessary for module files in
lib/clang/22/finclude/flang/(nvptx64-nvidia-cuda|amdgpu-amd-amdhsa)/*.mod
to be available.
* For compiling omp_lib.mod for nvptx and amdgpu, the module build
functionality must be hoisted out if openmp's runtime/ directory which
is only included for host targets. This PR now requires #169909.
Move building the .mod files from openmp/flang to openmp/flang-rt using
a shared mechanism. Motivations to do so are:
1. Most modules are target-dependent and need to be re-compiled for each
target separately, which is something the LLVM_ENABLE_RUNTIMES system
already does. Prime example is `iso_c_binding.mod` which encodes the
target's ABI. Constants such as [`c_long_double` also have different
values](d748c81218/flang-rt/lib/runtime/iso_c_binding.f90 (L77-L81)).
Most other modules have `#ifdef`-enclosed code as well. For instance
this caused offload targets nvptx64-nvidia-cuda/amdgpu-amd-amdhsa to use
the modules files compiled for the host which may contrain uses of the
types REAL(10) or REAL(16) not available for nvptx/amdgpu.
#146876#128015#129742#158790
3. CMake has support for Fortran that we should use. Among other things,
it automatically determines module dependencies so there is no need to
hardcode them in the CMakeLists.txt.
4. It allows using Fortran itself to implement Flang-RT. Currently, only
`iso_fortran_env_impl.f90` emits object files that are needed by Fortran
applications (#89403). The workaround of #95388 could be reverted (PR
#169525).
If using Flang for cross-compilation or target-offloading, flang-rt must
now be compiled for each target not only for the library, but also to
get the target-specific module files. For instance in a bootstrapping
runtime build, this can be done by adding:
`-DLLVM_RUNTIME_TARGETS=default;nvptx64-nvidia-cuda;amdgpu-amd-amdhsa`.
Some new dependencies come into play:
* openmp depends on flang-rt for building `lib_omp.mod` and
`lib_omp_kinds.mod`. Currently, if flang-rt is not found then the
modules are not built.
* check-flang depends on flang-rt: If not found, the majority of tests
are disabled. If not building in a bootstrpping build, the location of
the module files can be pointed to using
`-DFLANG_INTRINSIC_MODULES_DIR=<path>`, e.g. in a flang-standalone
build. Alternatively, the test needing any of the intrinsic modules
could be marked with `REQUIRES: flangrt-modules`.
* check-flang depends on openmp: Not a change; tests requiring
`lib_omp.mod` and `lib_omp_kinds.mod` those are already marked with
`openmp_runtime`.
As intrinsic are now specific to the target, their location is moved
from `include/flang` to `<resource-dir>/finclude/flang/<triple>`. The
mechnism to compute the location have been moved from flang-rt
(previously used to compute the location of `libflang_rt.*.a`) to common
locations in `cmake/GetToolchainDirs.cmake` and
`runtimes/CMakeLists.txt` so they can be used by both, openmp and
flang-rt. Potentially the mechnism could also be shared by other
libraries such as compiler-rt.
`finclude` was chosen because `gfortran` uses it as well and avoids
misuse such as `#include <flang/iso_c_binding.mod>`. The search location
is now determined by `ToolChain` in the driver, instead of by the
frontend. Another subdirectory `flang` avoids accidental inclusion of
gfortran-modules which due to compression would result in
user-unfriendly errors. Now the driver adds `-fintrinsic-module-path`
for that location to the frontend call (Just like gfortran does).
`-fintrinsic-module-path` had to be fixed for this because ironically it
was only added to `searchDirectories`, but not
`intrinsicModuleDirectories_`. Since the driver determines the location,
tests invoking `flang -fc1` and `bbc` must also be passed the location
by llvm-lit. This works like llvm-lit does for finding the include dirs
for Clang using `-print-file-name=...`.
Enable the clang_ignored_gcc_optimization_f_group in flang. These
options are accepted by clang, but ignored after emitting a warning
message. flang's behavior now mirrors both clang and gfortran.
Fixes#158436
Previously we were less specific for POINTER/TARGET: encoding that they
could alias with (almost) anything.
In the new system, the "target data" tree is now a sibling of the other
trees (e.g. "global data"). POITNTER variables go at the root of the
"target data" tree, whereas TARGET variables get their own nodes under
that tree. For example,
```
integer, pointer :: ip
real, pointer :: rp
integer, target :: it
integer, target :: it2(:)
real, target :: rt
integer :: i
real :: r
```
- `ip` and `rp` may alias with any variable except `i` and `r`.
- `it`, `it2`, and `rt` may alias only with `ip` or `rp`.
- `i` and `r` cannot alias with any other variable.
Fortran 2023 15.5.2.14 gives restrictions on entities associated with
dummy arguments. These do not allow non-target globals to be modified
through dummy arguments and therefore I don't think we need to make all
globals alias with dummy arguments.
I haven't implemented it in this patch, but I wonder whether it is ever
possible for `ip` to alias with `rt` or even `it2`.
While I was updating the tests I fixed up some tests that still assumed
that local alloc tbaa wasn't the default.
I found no functional regressions in the gfortran test suite, fujitsu
test suite, spec2017, or a selection of HPC apps we test internally.
Move building the .mod files from openmp/flang to openmp/flang-rt using
a shared mechanism. Motivations to do so are:
1. Most modules are target-dependent and need to be re-compiled for each
target separately, which is something the LLVM_ENABLE_RUNTIMES system
already does. Prime example is `iso_c_binding.mod` which encodes the
target's ABI. Most other modules have `#ifdef`-enclosed code as well.
2. CMake has support for Fortran that we should use. Among other things,
it automatically determines module dependencies so there is no need to
hardcode them in the CMakeLists.txt.
3. It allows using Fortran itself to implement Flang-RT. Currently, only
`iso_fortran_env_impl.f90` emits object files that are needed by Fortran
applications (#89403). The workaround of #95388 could be reverted.
Some new dependencies come into play:
* openmp depends on flang-rt for building `lib_omp.mod` and
`lib_omp_kinds.mod`. Currently, if flang-rt is not found then the
modules are not built.
* check-flang depends on flang-rt: If not found, the majority of tests
are disabled. If not building in a bootstrpping build, the location of
the module files can be pointed to using
`-DFLANG_INTRINSIC_MODULES_DIR=<path>`, e.g. in a flang-standalone
build. Alternatively, the test needing any of the intrinsic modules
could be marked with `REQUIRES: flangrt-modules`.
* check-flang depends on openmp: Not a change; tests requiring
`lib_omp.mod` and `lib_omp_kinds.mod` those are already marked with
`openmp_runtime`.
As intrinsic are now specific to the target, their location is moved
from `include/flang` to `<resource-dir>/finclude/flang/<triple>`. The
mechnism to compute the location have been moved from flang-rt
(previously used to compute the location of `libflang_rt.*.a`) to common
locations in `cmake/GetToolchainDirs.cmake` and
`runtimes/CMakeLists.txt` so they can be used by both, openmp and
flang-rt. Potentially the mechnism could also be shared by other
libraries such as compiler-rt.
`finclude` was chosen because `gfortran` uses it as well and avoids
misuse such as `#include <flang/iso_c_binding.mod>`. The search location
is now determined by `ToolChain` in the driver, instead of by the
frontend. Now the driver adds `-fintrinsic-module-path` for that
location to the frontend call (Just like gfortran does).
`-fintrinsic-module-path` had to be fixed for this because ironically it
was only added to `searchDirectories`, but not
`intrinsicModuleDirectories_`. Since the driver determines the location,
tests invoking `flang -fc1` and `bbc` must also be passed the location
by llvm-lit. This works like llvm-lit does for finding the include dirs
for Clang using `-print-file-name=...`.
It turns out that having `-ffast-math` as the only option to control
optimizations for MOD for REAL kinds (PR #160660) is too coarse-grained
for some applications. Thus, this PR adds back `-ffast-real-mod` to have
more control over the optimization. The `-ffast-math` flag will still
enable the optimization, and `-fno-fast-real-mod` allows one to disable
it.
This patch adds a new `FramePointerKind::NonLeafNoReserve` and makes it
the default for `-momit-leaf-frame-pointer`.
It also adds a new commandline option `-m[no-]reserve-frame-pointer-reg`.
This should fix#154379, the main impact of this patch can be found in
`clang/lib/Driver/ToolChains/CommonArgs.cpp`.
Flang alias analysis used to find allocation site by pattern matching
allocation ops in mainly FIR dialect. This MR extends the
characterization to instead characterize based on whether the result of
an op has MemAlloc effect.
When there are multiple gcc versions installed, we want `flang` to be
able
to find the right one based on the triple. Here's `flang` selecting an
unwanted `gcc` candidate installation, namely
`/usr/lib/gcc/x86_64-linux-gnu/15`:
```
~/src/llvm-project/main/build-RelWithDebInfo > ./bin/flang -v
flang version 22.0.0custombuild
Target: x86_64-redhat-linux-gnu
Thread model: posix
InstalledDir: /home/fedora/src/llvm-project/main/build-RelWithDebInfo/bin
System configuration file directory: /etc/clang/
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/15
Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/15
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/15
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64
```
When passing `--gcc-triple=x86_64-redhat-linux` we get the desired gcc
candidate installation:
```
~/src/llvm-project/main/build-RelWithDebInfo > ./bin/flang --gcc-triple=x86_64-redhat-linux -v
flang version 22.0.0custombuild
Target: x86_64-redhat-linux-gnu
Thread model: posix
InstalledDir: /home/fedora/src/llvm-project/main/build-RelWithDebInfo/bin
System configuration file directory: /etc/clang/
Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/15
Selected GCC installation: /usr/lib/gcc/x86_64-redhat-linux/15
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64
```
* Test: `LIT_FILTER="Flang :: Driver/gcc-triple.f90" ninja check-flang`
* Copied `flang/test/Driver/Inputs/fedora_39_tree` from
`clang/test/Driver/Inputs/fedora_39_tree`.
* Testing what default triple is selected when two are possible.
* Testing that we can select an existing triple.
* Testing that triple is not selected if it doesn't exist.
Passing -pie to flang will pass the flag on to the linker. Passing
-no-pie will ensure that -pie is *not* passed to the linker. This
behavior is consistent with both clang and gfortran.
Fixes#159970
When an option that is only available in `flang -fc1` is provided to
`flang`, emit a diagnostic with a suggestion containing "did you mean
-Xflang '-foo'".
Partially addresses #163550.
The options -fbuiltin and -fno-builtin are not valid for Fortran. However, they
are accepted by gfortran which emits a warning message but continues to compile
the code. Both -fbuiltin and -fno-builtin have been enabled for flang.
Specifying either will result in a warning message being shown but no other
effects. Compilation will proceed normally after these warnings are shown. This
brings flang's behavior in line with gfortran for these options.
Fixes#164766
This PR enables module summary for Full LTO. Module summaries are
enabled by default for Full LTO in clang, this change makes the flang
behaviour consistent. Reference PR: https://reviews.llvm.org/D34156
Support for multi-image features has begun to be integrated into LLVM. A
new dialect which simplifies lowering to PRIF wil be proposed in this
PR.
The initial definition of this dialect (MIF) is based only on operations
already upstreamed in LLVM and the current lowering will be moved to
this dialect.
---------
Co-authored-by: Dan Bonachea <dobonachea@lbl.gov>
Co-authored-by: Valentin Clement (バレンタイン クレメン) <clementval@gmail.com>
Summary:
This tool is pretty much a generic interface into creating and managing
the offloading binary format. The binary format itself is just a fat
binary block used to create heterogeneous objects. This should be made
more general than just `clang` since it's likely going to be used for
larger offloading projects and is the expected way to extract
heterogeneous objects from offloading code.
Relatively straightforward rename, a few tweaks and documentation
changes. Kept in `clang-offload-packager` for legacy compatibility as we
looked this tool up by name in places, will probably delete it next
release.
This patch adds direct code-gen support for a faster MOD intrinsic for
REAL types. Flang has maintained and keeps maintaining a high-precision
implementation of the MOD intrinsic as part of the Fortran runtime. With
the -ffast-real-mod flag, users can opt to avoid calling into the
Fortran runtime, but instead trigger code-gen that produces faster code
by avoiding the runtime call, at the expense of potentially risking bit
cancelation by having the compiler use the MOD formula a specified by
ISO Fortran.
This patch accelerates complex division by passing
`-complex-range=basic` to the frontend when the `-ffast-math` option is
specified. This behavior is the same as `-fcomplex-arithmetic=basic`. A
warning is issued if a different value is specified for
`-fcomplex-arithmetic=`. The warning conditions will be unified with
clang.
This flags enables the compiler to generate most of the debug
information in a separate file which can be useful for executable size
and link times. Clang already supports this flag.
I have tried to follow the logic of the clang implementation where
possible. Some functions were moved where they could be used by both
clang and flang. The `addOtherOptions` was renamed to `addDebugOptions`
to better reflect its purpose.
Clang also set the `splitDebugFilename` field of the `DICompileUnit` in
the IR when this option is present. That part is currently missing from
this patch and will come in a follow-up PR.
Because character comparison appends spaces to the shorter character,
calls to trim() that are used only in the comparison can be eliminated.
Example:
`trim(x) == trim(y)`
can be simplified to
`x == y`
This makes 527.cam4_r about 3% faster, measured on Neoverse V2.
This patch implements the optimization above in a new pass:
ExpressionSimplification. Although no other expression simplifications
are planned at the moment, they could be easily added to the new pass.
The ExpressionSimplification pass runs early in the HLFIR pipeline, to
make it easy to identify expressions before any transformations occur.
After recent addition of -gdwarf-N options in flang, I saw that newly
added tests failing on AIX bot. The gdwarf-5 option is not supported on
that platform. Disabling the dwarf-5 tests on AIX for now.
This PR introduces a new `ConvertComplexPow` pass for Flang that handles
complex power operations. The change forces lowering to complex.pow
operations when `--math-runtime=precise` is not used, then uses the
`ConvertComplexPow` pass to convert these operations back to library
calls.
- Adds a new `ConvertComplexPow` pass that converts complex.pow ops to
appropriate runtime library calls
- Updates complex power lowering to use `complex.pow` operations by
default instead of direct library calls
#158722 Adds a new `complex.powi` op enabling algebraic optimisations.
