nsw is now added to do-variable increment when -fno-wrapv is enabled as
GFortran seems to do.
That means the option introduced by #91579 isn't necessary any more.
Note that the feature of -flang-experimental-integer-overflow is enabled
by default.
The underlying issue was caused by a file included in two different
places which resulted in duplicate definition errors when linking
individual shared libraries. This was fixed in c3201ddaeac02a2c86a38b
[#109874].
This does a global rename from `flang-new` to `flang`. I also
removed/changed any TODOs that I found related to making this change.
---------
Co-authored-by: H. Vetinari <h.vetinari@gmx.com>
Co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com>
Add support for -fdiagnostics-color and -fdiagnostics-color=. Add
documentation for -fdiagnostics-color= which should also be visible in
clang.
Partially addresses requests in #89888
Add support for the -frecord-command-line option that will produce the
llvm.commandline metadata which will eventually be saved in the object
file. This behavior is also supported in clang. Some refactoring of the
code in flang to handle these command line options was carried out. The
corresponding -grecord-command-line option which saves the command line
in the debug information has not yet been enabled for flang.
This patch modifies the flang driver to introduce the `-fopenmp-targets`
option to the frontend compiler invocations corresponding to the OpenMP
host device on offloading-enabled compilations.
This option holds the list of offloading triples associated to the
compilation and is used by clang to determine whether offloading calls
should be generated for the host.
Flang-new needs to add `mlink-builtin-bitcode` objects to properly
support offload code generation for AMD GPUs (for example, math
functions).
Both Flang-new and Clang rely on `mlink-builtin-bitcode` flags. These
flags are added by the `AMDGPUOpenMPToolchain::addClangTargetOptions`
function. Now, both compilers reuse the same function.
Flang-new tests for AMDGPU were updated by adding the `-nogpulib` flag.
This flag allows running AMDGPU tests on machines without the ROCm stack.
Module files emitted by this Fortran compiler are valid Fortran source
files. Symbols that are USE-associated into modules are represented in
their module files with USE statements and special comments with hash
codes in them to ensure that those USE statements resolve to the same
modules that were used to build the module when its module file was
generated.
This scheme prevents unchecked module file growth in large applications
by not emitting USE-associated symbols redundantly. This problem can be
especially bad when derived type definitions must be repeated in the
module files of their clients, and the clients of those modules, and so
on. However, this scheme has the disadvantage that clients of modules
must be compiled with dependent modules in the module search path.
This new -fhermetic-module-files option causes module file output to be
free of dependences on any non-intrinsic module files; dependent modules
are instead emitted as part of the module file, rather than being
USE-associated. It is intended for top level library module files that
are shipped with binary libraries when it is not convenient to collect
and ship their dependent module files as well.
Fixes https://github.com/llvm/llvm-project/issues/97398.
This patch implements the -mcmodel flag from clang, allowing the Code
Model to be changed for the LLVM module. The same set of mcmodel
flags are accepted as in clang and the same Code Model attributes are
added to the LLVM module for those flags.
Also add `-mlarge-data-threshold` for x86-64, which is automatically set
by the shared command-line code (see below). This is also added as an
attribute into the LLVM module and on the target machine.
A function is created for `addMCModel` that is copied out of clang's
argument handling so that it can be shared with flang.
---------
Co-authored-by: Mats Petersson <mats.petersson@arm.com>
This PR adds -mtune as a valid flang flag and passes the information
through to LLVM IR as an attribute on all functions. No specific
architecture optimizations are added at this time.
This patch enables the `-fopenmp-force-usm` option to be passed to the
flang driver, which forwards it to the compiler frontend. This flag,
when set, results in the introduction of the `unified_shared_memory` bit
to the `omp.requires` attribute of the top-level module operation.
This is later combined with any other target device-related REQUIRES
clauses that may have been explicitly set in the compilation unit.
I'm planning to remove StringRef::equals in favor of
StringRef::operator==.
- StringRef::operator==/!= outnumber StringRef::equals by a factor of
13 under clang/ in terms of their usage.
- The elimination of StringRef::equals brings StringRef closer to
std::string_view, which has operator== but not equals.
- S == "foo" is more readable than S.equals("foo"), especially for
!Long.Expression.equals("str") vs Long.Expression != "str".
Add support for the -w option to switch OFF all Flang
warnings. This patch only supports switching OFF the
frontend warnings.
TODO : Support for MLIR, LLVM and Driver warnings.
TODO : Support interactions between -w, -pedantic, -Wall
This patch changes the behaviour for flang to only create and link to a
`main` entry point when the Fortran code has a program statement in it.
This means that flang-new can be used to link even when the program is
a mixed C/Fortran code with `main` present in C and no entry point
present in Fortran.
This also removes the `-fno-fortran-main` flag as this no longer has any
functionality.
This introduces a new file, RISCVISAUtils.cpp and moves the rest of
RISCVISAInfo to the TargetParser library.
This will allow us to generate part of RISCVISAInfo.cpp using tablegen.
Currently, -g defaults to line tables only. This PR changes that to full
debug information. This will allow us to test/use the upcoming debug
info changes.
frtlib-add-rpath option is used by clang and should also be visible in
flang. It is already handled by the toolchains used by both clang and
flang.
Reported issue: https://github.com/llvm/llvm-project/issues/82553
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.
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.
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.
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 replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.
I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.
This PR adds the `-fno-fortran-main` command line option to remove
`Fortran_main.a` from the link and to allow for linking Fortran code w/o
program unit with C/C++ translation units that provide the `main()`
entrypoint.
When linking Fortran code with C/C++ code (Fortran calling into C/C++),
PR #73124 introduced a proper error message that would prevent
successful linkage, if there was a program unit from Fortran *and*
`main()` function coming from C/C++. Alas, this caused some breakage of
code that would call Fortran code from C/C++ and rightfully provided the
`main()` entrypoint. Classic Flang had the command-line option
`-fno-fortran-main` to then remove the entrypoints for the Fortran
program unit from the linker stage.
This PR is related to PR #74120 and (merged) PR #73124.
---------
Co-authored-by: Andrzej Warzyński <andrzej.warzynski@gmail.com>
Now that tbaa tags pass is enabled by default, I would like to remove
these flags. `-fno-alias-analysis` was originally intended to be useful
for debugging, but as it also disables tbaa tag generation in codegen,
it turned out to be too noisy.
@banach-space expressed that these flags felt too non-standard.
The tbaa tags pass can be toggled using `-mllvm
-disable-fir-alias-tags=0`
Enable by default for optimization levels higher than 0 (same behavior
as clang).
For simplicity, only forward the flag to the frontend driver when it
contradicts what is implied by the optimization level.
This was first landed in
https://github.com/llvm/llvm-project/pull/73111 but was later reverted
due to a performance regression. That regression was fixed by
https://github.com/llvm/llvm-project/pull/74065.
Information about code object version can be configured by the user for
AMD GPU target and it needs to be placed in LLVM IR generated by Flang.
Information about code object version in MLIR generated by the parser
can be reused by other tools. There is no need to specify extra flags if
we want to invoke MLIR tools (like fir-opt) separately.
Changes in comparison to a8ac93:
* added information about required targets for test
flang/test/Driver/driver-help.f90
Information about code object version can be configured by the user for
AMD GPU target and it needs to be placed in LLVM IR generated by Flang.
Information about code object version in MLIR generated by the parser
can be reused by other tools. There is no need to specify extra flags if
we want to invoke MLIR tools (like fir-opt) separately.
Enable by default for optimization levels higher than 0 (same behavior
as clang).
For simplicity, only forward the flag to the frontend driver when it
contradicts what is implied by the optimization level.
Since https://github.com/llvm/llvm-project/pull/72903 there are now no
known performance regressions.
This patch uses the added --dependent-lib support to add the relevant
runtimes on MSVC targets as `/DEFAULTLIB:` sections in the object file
rather than on the link line. This should help CMake support for flang
on Windows.
Fixes#63741Fixes#68017
-fveclib= allows users to choose a vectorized libm so that loops
containing math functions are vectorized.
This is implemented as much as possible in the same way as in clang. The
driver test in veclib.f90 is copied from the clang test.
