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.
Line ending policies were changed in the parent, dccebddb3b. To make
it easier to resolve downstream merge conflicts after line-ending
policies are adjusted this is a separate whitespace-only commit. If you
have merge conflicts as a result, you can simply `git add --renormalize
-u && git merge --continue` or `git add --renormalize -u && git rebase
--continue` - depending on your workflow.
Currently when using OpenMP atomics we depend on some symbols from
libatomic. These symbols are provided in a separate library for the
libgcc runtime, so we should link to that when rtlib=libgcc.
For the compiler-rt case, the presence and location of the symbols is
dependent on how compiler-rt itself was built so we cannot make that
decision for the user. As such no extra flags are added in that case.
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 c3201ddaea
[#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>
The option provides the search prefix for executables, libraries and
data files.
The option is implemented in the common portion of the Driver and only
needs to be enabled in Flang. Test added is a copy of the relevant test
in Clang.
The -Xoffload-linker command allows forwarding of linker commands to the
clang-linker-wrapper used for linking offload libraries into the
resulting offload binaries amongst other tasks. This is a rather useful
command to have to support the offloading programming models flang-new
currently aims to support (OpenMP/OpenACC).
Currently this flag is utilised in the check-offload tests after a
recent addition and is used in conjunction with the Fortran OpenMP test
suite there, which fails at the moment due to flang-new not recognizing
the command, this fixes the issue. The alternative to this would of
course be to setup the test config to avoid using this flag with
Fortran, but I believe adding support of the flag to flang-new has more
merit as having the same compatability/communication capabilities as
Clang to the clang-linker-wrapper is important as it's a critical
component of the offload pipeline, and the command will likely see more
use in the near future.
There are autoconf-configured projects for which the generated Makefile
is invoking flang with more than one -J option, each one specifying the
same directory. Although only one module directory should be specified
(by either -J or -module-dir), it should not really matter how many
times this same directory has been specified.
Apparently, other compilers understand it that way, hence autoconf's
configure script may generate a Makefile with the repetitive -J's.
For example, when trying to build the ABINIT [1] project (which can be
configured by either CMake or the configure script) when configured by
autoconf, it fails to build as such:
```
make[3]: Entering directory 'src/98_main'
mpifort -DHAVE_CONFIG_H -I. -I../../../src/98_main -I../.. -I../../src/incs -I../../../src/incs -Ifallbacks/exports/include -Jbuild/mods -Jbuild/mods -c -o abinit-abinit.o `test -f 'abinit.F90' || echo '../../../src/98_main/'`abinit.F90
error: Only one '-module-dir/-J' option allowed
make[3]: *** [Makefile:3961: abinit-abinit.o] Error 1
```
This patch solves the problem.
[1] https://github.com/abinit/abinit.git
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
The `-m[no-]evex512` are nontrivial options which are used to control
vector size of other AVX512 features. Hence we expose both to flang for
Fortran users.
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.
…INCLUDE lines
The compiler current treats an INCLUDE line as essentially a synonym for
a preprocessing #include directive. The causes macros that have been
defined at the point where the INCLUDE line is processed to be replaced
within the text of the included file.
This behavior is surprising to users who expect an INCLUDE line to be
expanded into its contents *after* preprocessing has been applied to the
original source file, with no further macro expansion.
Change INCLUDE line processing to use a fresh instance of Preprocessor
containing no macro definitions except _CUDA in CUDA Fortran
compilations and, if the original file was being preprocessed, the
standard definitions of __FILE__, __LINE__, and so forth.
Because of the way visibility is implemented in Options.td, options that
are aliases do not inherit the visibility of the option being aliased.
Therefore, explicitly set the visibility of the alias to be the same as
the aliased option.
This partially addresses
https://github.com/llvm/llvm-project/issues/89888
When using `--save-temps`, flang-new emits (among other things) an
`<input>.i` file. These `.i` files are pre-processed Fortran files
containing information about the modules referenced by the input source
(these files are emitted by: `Parsing::EmitPreprocessedSource`).
This diff allows `.i` files emitted by flang-new to be treated as valid
files in the pre-processing phase. This, in turn, allows flang-new to
add pre-processing options (e.g. `-I`) when launching compilation jobs
for these files.
This solves a bug when using `--save-temps` with source files that
include modules from non-standard directories, for example:
```
flang-new -c --save-temps -I/tmp/module_dir -fno-integrated-as \
/tmp/ModuleUser.f90
```
The problem was that `.i` files were treated as "binary" files and
therefore the return value for `types::getPreprocessedType(InputType)`
in `Flang::ConstructJob(...)` was `types::TY_INVALID`.
The behavior deliberately mimics that of clang. Ideally, -print-pipeline-passes
should be a first-class driver option. Notes to this effect have been added in
the appropriate places in both flang and clang.
---------
Co-authored-by: Tarun Prabhu <tarun.prabhu@gmail.com>
The verification pass is run right after lowering with its own pass
manager by flang driver, but the mlir command line options were not
applied to this pass manager.
This prevented options like `-mmlir
--mlir-pass-pipeline-crash-reproducer="crash.fir"` or `-mmlir
--mlir-print-ir-after-failure` to work when a verifier error was hit
right after lowering, while these options are useful to
investigate/reproduce internal errors.
Note that the change in the pipeline tests is not showing a new pass
being run: the pass was already run, but `-mmlir --mlir-pass-statistics`
was not applied when the initial verification pass was run.
Note that when we deal with compiler performance, we will probably want
to run the verification pass only once after the initial lowering (this
patch shows that it is called twice in a raw: once after the initial
lowering, once at the beginning of FIR to LLVM IR lowering).
This change addresses more "issues" as the one resolved in #71338.
Some targets (e.g. NVPTX) do not accept global names containing
`.`. In particular, the global variables created to represent
the runtime information of derived types use `.` in their names.
A derived type's descriptor object may be used in the device code,
e.g. to initialize a descriptor of a variable of this type.
Thus, the runtime type info objects may need to be compiled
for the device.
Moreover, at least the derived types' descriptor objects
may need to be registered (think of `omp declare target`)
for the host-device association so that the addendum pointer
can be properly mapped to the device for descriptors using
a derived type's descriptor as their addendum pointer.
The registration implies knowing the name of the global variable
in the device image so that proper host code can be created.
So it is better to name the globals the same way for the host
and the device.
CompilerGeneratedNamesConversion pass renames all uniqued globals
such that the special symbols (currently `.`) are replaced
with `X`. The pass is supposed to be run for the host and the device.
An option is added to FIR-to-LLVM conversion pass to indicate
whether the new pass has been run before or not. This setting
affects how the codegen computes the names of the derived types'
descriptors for FIR derived types.
fir::NameUniquer now allows `X` to be part of a name, because
the name deconstruction may be applied to the mangled names
after CompilerGeneratedNamesConversion pass.
The test initially worked on ArmPL but this was changed during code
review and I neglected to fix this comment.
Thanks for pointing this out @banach-space
Flang is switch to cc1 when we use `-x cuda`. Make sure we can use fc1
with cuda fortran input.
The current pipeline will fail at MLIR level for the moment.
Flang is switch to cc1 when we use `-x cuda`. Make sure we can use fc1
with cuda fortran input.
The current pipeline will fail at MLIR level for the moment.
Flang is switch to cc1 when we use `-x cuda`. Make sure we can use fc1
with cuda fortran input.
The current pipeline will fail at MLIR level for the moment.
#104483
`Flang :: Driver/fveclib-codegen.f90` currently `FAIL`s on SPARC, both
Solaris/sparcv9 and Linux/sparc64:
```
bin/flang-new -S -Ofast -fveclib=LIBMVEC -o - /vol/llvm/src/llvm-project/local/flang/test/Driver/fveclib-codegen.f90
flang/test/Driver/fveclib-codegen.f90:11:10: error: CHECK: expected string not found in input
! CHECK: _ZGVbN4vv_powf
^
```
The code in question only contains calls to `powf`. Given that `glibc`
only supports `libmvec` on `aarch64` and `x86_64`, this test targets
only those if possible.
Tested on `sparcv9-sun-solaris2.11`, `sparc64-unknown-linux-gnu`,
`amd64-pc-solaris2.11`, and `x86_64-pc-linux-gnu`.
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.
Config files provide a facility to invoke the compiler with a predefined
set of options. The patch only enables these options in the flang
driver. Functionality was always there.
Summary:
These tests were removed in a previous patch.
The linker wrapper now just extracts the device inputs and forwards them
directly to the device's link job. This is the job that occurs when you
do `clang --target=amdgcn-amd-amdhsa foo.o` or similar. Because this can
handle LTO we no longer do LTO in the linker wrapper. This has some
fallout, because we now require `ld.lld` to be built with a compatible
version, but I think we always expected that.
I made the decision to remove this `libc-gpu.a` library because it was
unnecessary and complicated things. Now I simply have the link job
implicitly link `-lc` if it exists. Users can also now pass
`-Xoffload-linker=amdgcn-amd-amdhsa -lc` or similar to pass it. Because
of this, these tests need to be removed. I forgot that Fortran also had
these.
This patch allows the -rtlib flag with flang-new to select between the
libgcc_s and compiler-rt runtimes. The behaviour is identical to the
same flag with clang.
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>
The default visibility of `m_x86_Features_Group` is `ClangOption,
CLOption`. For x86, we expose `-march` to flang but not `-m<cpuid>`.
`apxf` is special b/c it contains several independent features like
`egpr, ndd, ppx, push2pop2, ccmp, nf, cf` and `zu`.
Users may would like to turn on part of features in different cases
1. enable `ndd` only when writing a code-size sensitive library
2. disable `ccmp`, `cf` when building component has strong security
request on caches
Hence, we expose `-mapx-features=` to flang for Fortran users.
This PR re-enables the command line option `-print-resources-dir` after
PR #96557 has reverted the changes made.
The way this works now, is that it simply prints the current resource
dir, which points to clang/$version.
This introduces the new `--print-enabled-extensions` command line option
to AArch64, which prints the list of extensions that are enabled for the
target specified by the combination of `--target`/`-march`/`-mcpu`
values.
The goal of the this option is both to enable the manual inspection of
the enabled extensions by users and to enhance the testability of
architecture versions and CPU targets implemented in the compiler.
As part of this change, a new field for `FEAT_*` architecture feature
names was added to the TableGen entries. The output of the existing
`--print-supported-extensions` option was updated accordingly to show
these in a separate column.
This introduces the new `--print-enabled-extensions` command line option
to AArch64, which prints the list of extensions that are enabled for the
target specified by the combination of `--target`/`-march`/`-mcpu`
values.
The goal of the this option is both to enable the manual inspection of
the enabled extensions by users and to enhance the testability of
architecture versions and CPU targets implemented in the compiler.
As part of this change, a new field for `FEAT_*` architecture feature
names was added to the TableGen entries. The output of the existing
`--print-supported-extensions` option was updated accordingly to show
these in a separate column.
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.
