I noticed that `flang-new` cannot link Fortran executables on Solaris since the runtime libs are missing.
This patch fixes this, following `Gnu.cpp`. The `linker-flags.f90` testcase is augmented to test for this,
renaming the `GNU` label to `UNIX` so it can be reused. Also use the current form `--target=` in the tests
and join the `-l` lines in the test for readibility.
Tested on `amd64-pc-solaris2.11`, `sparcv9-sun-solaris2.11`, and
`x86_64-pc-linux-gnu`.
The ultimate intention is to have this pass enabled by default whenever
we are optimizing for speed. But for now, just add the arguments so this
can be more easily tested.
PR: https://github.com/llvm/llvm-project/pull/68595
Support for vector scale range arguments, for AArch64 scalable vector
extension (SVE) support.
Adds -msve-vector-bits to the flang frontend, and for flang fc1 the
options are -mvscale-min and -mvscale-max (optional). These match the
clang and clang cc1 options for the same purposes.
A further patch will actually USE these arguments.
This reverts commit 6403287eff71a3d6f6c862346d6ed3f0f000eb70.
This is failing on all but 1 of Linaro's flang builders.
CMake Error at /home/tcwg-buildbot/worker/clang-aarch64-full-2stage/llvm/flang-rt/unittests/CMakeLists.txt:37 (message):
Target llvm_gtest not found.
See discourse thread https://discourse.llvm.org/t/rfc-support-cmake-option-to-control-link-type-built-for-flang-runtime-libraries/71602/18 for full details.
Flang-rt is the new library target for the flang runtime libraries. It builds the Flang-rt library (which contains the sources of FortranRuntime and FortranDecimal) and the Fortran_main library. See documentation in this patch for detailed description (flang-rt/docs/GettingStarted.md).
This patch aims to:
- integrate Flang's runtime into existing llvm infrasturcture so that Flang's runtime can be built similarly to other runtimes via the runtimes target or via the llvm target as an enabled runtime
- decouple the FortranDecimal library sources that were used by both compiler and runtime so that different build configurations can be applied for compiler vs runtime
- add support for running flang-rt testsuites, which were created by migrating relevant tests from `flang/test` and `flang/unittest` to `flang-rt/test` and `flang-rt/unittest`, using a new `check-flang-rt` target.
- provide documentation on how to build and use the new FlangRT runtime
Reviewed By: DanielCChen
Differential Revision: https://reviews.llvm.org/D154869
Since the changes to -### to correctly return error codes in D156363,
some additions of the not lit keyword and perhaps some changes to how
fopenmp-targets is handled; the test omp-driver-offload.f90 has become a
little susceptible to what appears to be sporadic failures.
This was because if certain environment variables are set for AMD
devices some of the commands succeed happily and the not check causes
the test to fail. Whereas, if they were not set the tests would fail and
the not test would succeed, allowing the test to pass provided you were
not targeting AMD hardware while running the test.
When the environment variables for AMD hardware are set the compiler
could find the correct offload architecture to compile for, allowing the
command to succeed. However, when not set it'd fail as it can't detect
the offload architecture. The solution to this is to specify an AMD
architecture via --offload-arch so it always passes, the architecture
doesn't really matter, I've chosen to select gfx90a.
The test command which tests offloading to multiple device architectures
expects multiple outputs, however, the test as written with the -o
expects a single output result. This change modifies it to not expect a
single output, which allows the command to succeed and allow the removal
of the not prefix.
This patch moves the group of OpenMP MLIR passes using after lowering of
Fortran to MLIR into a pipeline to be shared by `flang-new` and `bbc`.
Currently, the `bbc` tool does not produce the expected FIR for offloading-
enabled OpenMP codes due to not running these passes.
Unit tests exercising these passes are updated to check `bbc` output as well.
The -fdebug-dump-all flag invokes runtime type information generation
even for a program with fatal semantic errors. This could cause a crash
on a failed CHECK(), since the type information table generator assumes
a correct program. Make it more resilient for a known fatal case. (But
if we hit many more of these, we should look into not generating the
runtime type information tables under this flag.)
This patch supports GNU ld on Solaris in addition to Solaris ld, the
default.
- Linker selection is dynamic: one can switch between Solaris ld and GNU ld
at runtime, with the default selectable with `-DCLANG_DEFAULT_LINKER`.
- Testcases have been adjusted to test both variants in case there are
differences.
- The `compiler-rt/cmake/config-ix.cmake` and
`llvm/cmake/modules/AddLLVM.cmake` changes to restrict the tests to
Solaris ld are necessary because GNU accepts unknown `-z` options, but
warns every time they are used, creating a lot of noise. Since there
seems to be no way to check for those warnings in
`llvm_check_compiler_linker_flag` or `llvm_check_compiler_linker_flag`, I
restrict the cmake tests to Solaris ld in the first place.
- The changes to `clang/test/Driver/hip-link-bundle-archive.hip` and
`flang/test/Driver/linker-flags.f90` are required when LLVM is built with
`-DCLANG_DEFAULT_LINKER=gld` on Solaris: `MSVC.cpp`
`visualstudio::Linker::ConstructJob` ultimately calls
`GetProgramPath("gld")`, resulting in a search for `gld`, which exists in
`/usr/bin/gld` on Solaris. With `-fuse-ld=`, this doesn't happen and the
expected `link` is returned.
- `compiler-rt/test/asan/TestCases/global-location-nodebug.cpp` needs to
enforce the Solaris ld, otherwise the test would `XPASS` with GNU ld
which has the `-S` semantics expected by the test.
Tested on `amd64-pc-solaris2.11` and `sparcv9-sun-solaris2.11` with both
`-DCLANG_DEFAULT_LINKER=gld` and the default, and `x86_64-pc-linux-gnu`.
No regressions in either case.
Differential Revision: https://reviews.llvm.org/D85309
For each R_Group diagnostic produced, this patch gives more
information about it by printing the absolute file path,
the line and column number the pass was applied to and finally
the remark option that was used.
Clang does the same with the exception of printing the relative
path rather than absolute path.
Depends on D159260. That patch adds support for backend passes
while this patch adds remark options to the backend test cases.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D159258
Previously, R_Group options only reported middle-end passes.
This patch allows backend passes to be reported as well.
Depends on D158174. That patch adds backend support to R_Group
options.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D159260
With the R_Group options, invalid values e.g. '-Rpa' will not emit
a warning like clang. This patch enables warning reporting, as
well as suggestions on what option the user intended to select.
Depends on D158174 and D158436. The former, adds backend
support to R_Group options while the latter, implements
regex support with some tests refactoring that cause a merge
conflict.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D158593
Add regex handling for all variations of OPT_R_Joined, i.e.
`-Rpass`, `-Rpass-analysis`, `-Rpass-missed`.
Depends on D158174. That patch implements backend support for
R_Group options.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D158436
Updates optimization-remark.f90. Makes sure that every RUN line:
* discords the actual output of the compilation (we only care about the
optimisation remarks),
* re-uses the same definition of the output (better code re-use),
* doesn't generate object files - no need to use `-c` if `-emit-llvm` is
sufficient.
Differential Revision: https://reviews.llvm.org/D158951
https://reviews.llvm.org/D157151 and https://reviews.llvm.org/D157837
added visibility flags to flang options, hiding options which are
supported only in Clang and not in Flang.
After this change, some negative flags e.g. `-fno-reciprocal-math` no
longer work with flang. These flags are supported in flang (as can be
seen from the support for the positive flags).
I also opted to make sure the clang visibility is the same on these
flags, although I did not look at changing the visibility of non-flang
flags.
Differential Revision: https://reviews.llvm.org/D158612
As discussed on the weekly OpenMP meeting on the second of August 2023, the default version
in the OpenMP documentation shoud be changed from OpenMP 5.0 to 5.1.
Differential Revision: https://reviews.llvm.org/D156901
The option fuse-ld is not visible in Flang. Flang reports
"Unknown argument: '-fuse-ld'" during link stage.
Reviewed By: awarzynski, kiranchandramohan
Differential Revision: https://reviews.llvm.org/D158430
Add a BackendRemarkConsumer class, responsible for handling diagnostics
received from LLVM. The diagnostics being information on middle and
backend passes used or not used.
Clang by default has all remarks ignored but manually sets the severity of
`R_Group` to visible(`clang::diag::clang::Severity::Remark`). This patch does
the same for Flang.
Depends on D157410. That patch adds the R family of options to
`FlangOption` and `FC1Option` in
`clang/include/clang/Driver/Options.td`
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D158174
83a06997c69a17def2f58fd556c094b8f1060b89 broke this test but
we only saw the failure on a subset of the flang bots because
it requires 3 target backends, and most of ours only enable AArch64.
Use %if to run as much of the test as we can with the targets
we have.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D158264
Prior to D157151, there was no mechanism to "disable" unsupported Clang
options in Flang. While the "help" text (`flang-new -help`) was indeed
configured not to display such options, the Flang compiler driver would
happily consume such options and only issue a warning when there was no
logic to parse it:
```
flang-new -fno-experimental-relative-c++-abi-vtables file.f90
flang-new: warning: argument unused during compilation: '-fno-experimental-relative-c++-abi-vtables'
```
D157151 introduces visibility flags. In particular, all Clang options
gain a visibility flag (`ClangOption`) that can be excluded when in
Flang driver mode. This way the above invocation will lead to:
```
flang-new: error: unknown argument '-fno-experimental-relative-c++-abi-vtables'; did you mean '-Xclang -fno-experimental-relative-c++-abi-vtables'?
```
This won't work unless all options/flags supported by Flang have their
visibility flags updated accordingly, hence the changes in Options.td.
Moving forward, this change will allow Flang better control over the
supported options.
Depends on D157151
Differential Revision: https://reviews.llvm.org/D157837
This patch allows propagation of the R family of options to the backend where a separate patch will implement the optimization
remark printing.
This patch was created to address the comment about splitting into smaller patches in https://reviews.llvm.org/D156320.
Reviewed By: awarzynski, tblah, kiranchandramohan
Differential Revision: https://reviews.llvm.org/D157410
This patch also adds a LIT test for the vec_cvf intrinsic that
can be affected by the option.
Co-authored-by: Mark Danial <Mark.Danial@ibm.com>
Co-authored-by: Daniel Chen <cdchen@ca.ibm.com>
Differential Revision: https://reviews.llvm.org/D155852
We currently spell check options that are listed as unsupported, but
this doesn't make much sense. If an option is explicitly unsupported
why would one that's spelled similarly be useful?
It looks like the reason this was added was that we explicitly mark
all `--something` flags as Unsupported rather than just leaving them
undefined and treating them as unknown. Drop that handling so that we
don't regress on things like misspelling `--help`.
Differential Revision: https://reviews.llvm.org/D156925
The exit code for -### is inconsistent. Unrecognized options lead to
exit code 1, as expected. However, most others errors (including invalid
option value) lead to exit code 0, differing from GCC and most utilities.
This is a longstanding quirk of -###, and we didn't fix it because many
driver tests need adjustment.
Change -### to be similar to -fdriver-only -v and exit with code 1.
This requires fixing many driver tests, but the end result gives us
stronger tests.
* Existing `RUN: %clang -### ...` tests usually don't use `CHECK-NOT: error:` or `--implicit-check-not=error:`.
If a change introduces an error, such a change usually cannot be detected.
* Many folks contributing new tests don't know `-fdriver-only -v`.
To test no driver error/warning for new tests, they can use the familiar `-### -Werror`
instead of `-fdriver-only -v -Werror`.
An incomplete list of prerequisite test improvement:
* 2f79bb10461d114783a1548201928549ace09755: add -nogpulib to some AMDGPU tests
* 9155e517e6e1cda474d0d0fa82f71696c325bc10: add --cuda-path= (test w/ and w/o /usr/local/cuda)
* 80765ede5bbcca1364c2d4ae06127011eaba6389: -mcpu=native may return either 0 or 1, depending on whether `--target=` specifies a native target
* abae53f43f0d1da8d8e421f4a628d7ec64d6e365: fix -fuse-ld=lld misuses (test w/o and w/o /usr/local/bin/ld.lld)
* ab68df505e5bb8808ee44f53044b50ca7575098e: add -resource-dir= and -fvisibility=hidden
to some -fsanitize=cfi tests
* d5ca1602f64114f612ad5630f04e4aa90591c78d: --rtlib=platform without --unwindlib= may fail if CLANG_DEFAULT_UNWINDLIB=unwindlib
Reviewed By: jhuber6, yaxunl, dblaikie
Differential Revision: https://reviews.llvm.org/D156363
I believe the help text for the flag `--offload-host-device` is wrong. Currently, the help text says "Only compile for the offloading host." but the flag alias with `--cuda-compile-host-device` which
has the help text "Compile CUDA code for both host and device (default). Has no effect on non-CUDA compilations."
Fixes https://github.com/llvm/llvm-project/issues/64243
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D156641
Use `AddAllArgs` to keep the implementation succinct. Also adds missing
'-flang-experimental-hlfir` in "frontend-forwarding.f90"
Differential Revision: https://reviews.llvm.org/D156524
Add support for generating and saving the optimization record.
Optimization record lists the optimizations performed by LLVM.
This patch enables the flag in Flang. Clang handles this functionality
using the BackendConsumer which Flang doesn't have, hence, was
implemented in CodeGenAction::executeAction
FlangOption added to all variants of fsave-optimization-record in
clang/include/clang/Driver/Options.td . Clang handles it the
same way.
opt_record_file, opt_record_passes and opt_record_format flags
in Options.td were moved out of the group [CC1Option, NoDriverOption]
to allow flang -fc1 support.
The renderRemarksOptions and willEmitRemarks functions in
clang/lib/Driver/ToolChains/Flang.cpp follow same syntax as clang.
In flang/lib/Frontend/CompilerInvocation.cpp we update the field
OptRecordFile with the provided optimization file value. Clang
doesn't do this as it processes the Options.td, mapping the
OptRecordFile earlier on.
Reviewed By: awarzynski, tblah
Differential Revision: https://reviews.llvm.org/D155452
Other compilers include the logical default also with the
default-integer-8 setting. This patch does the same for
flang.
Reviewed By: awarzynski, sscalpone
Differential Revision: https://reviews.llvm.org/D155279
There was a bug with the -funderscoring / -fno-underscoring options from (https://reviews.llvm.org/D140795) that prevented the driver option from controlling the underscoring behaviour and instead the behaviour could only be controlled by the pass option instead of the driver option. The driver test case did not catch the bug and also needed to be updated.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D155042
This patch implements an early outlining transform of omp.target operations in
flang. The pass is needed because optimizations may cross target op region
boundaries, but with the outlining the resulting functions only contain a
single omp.target op plus a func.return, so there should not be any opportunity
to optimize across region boundaries.
The patch also adds an interface to be able to store and retrieve the parent
function name of the original target operation. This is needed to be able to
create correct kernel function names when lowering to LLVM-IR.
Reviewed By: kiranchandramohan, domada
Differential Revision: https://reviews.llvm.org/D154879
This patch renames the `OpenMPIRBuilderConfig` flags to reduce confusion over
their meaning. `IsTargetCodegen` becomes `IsGPU`, whereas `IsEmbedded` becomes
`IsTargetDevice`. The `-fopenmp-is-device` compiler option is also renamed to
`-fopenmp-is-target-device` and the `omp.is_device` MLIR attribute is renamed
to `omp.is_target_device`. Getters and setters of all these renamed properties
are also updated accordingly. Many unit tests have been updated to use the new
names, but an alias for the `-fopenmp-is-device` option is created so that
external programs do not stop working after the name change.
`IsGPU` is set when the target triple is AMDGCN or NVIDIA PTX, and it is only
valid if `IsTargetDevice` is specified as well. `IsTargetDevice` is set by the
`-fopenmp-is-target-device` compiler frontend option, which is only added to
the OpenMP device invocation for offloading-enabled programs.
Differential Revision: https://reviews.llvm.org/D154591
Extend the SourceFile class to take account of #line directives
when computing source file positions for error messages.
Adjust the output of #line directives to -E output so that they
reflect any #line directives that were in the input.
Differential Revision: https://reviews.llvm.org/D153910
This flag enables Fortran 2003 polymorphism. It is marked experimental
and not included in --help.
Reviewed By: tblah, awarzynski
Differential Revision: https://reviews.llvm.org/D153281
OpenMP standard (section 3.3 for OpenMP 5.2) requires that _OPENMP macro
contains release date of given OpenMP standard version.
Differential Revision: https://reviews.llvm.org/D151083
Reviewed By: kiranchandramohan
In review for https://reviews.llvm.org/D146278, @vzakhari asked to
separate -emit-fir and -emit-hlfir. This will allow FIR to be easily
outputted after the HLFIR passes have been run.
The new semantics are as follows:
| Action | -flang-experimental-hlfir? | Result |
| =========== | ========================== | =============================== |
| -emit-hlfir | N | Outputs HLFIR |
| -emit-hlfir | Y | Outputs HLFIR |
| -emit-fir | N | Outputs FIR, using old lowering |
| -emit-fir | Y | Outputs FIR, lowering via HLFIR |
A patch for bbc will follow.
Differential Revision: https://reviews.llvm.org/D151088
This revision implements the Fortran intrinsic procedures COMPILER_VERSION and COMPILER_OPTIONS from the iso_fortran_env module.
To be able to set the COMPILER_OPTIONS string according to the original compiler driver invocation, a string is passed to the frontend driver using the environment variable FLANG_COMPILER_OPTIONS_STRING, for lack of a better mechanism.
Fixes#59233
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D140524
This patch adds flag -fopenmp-version to the Flang frontend and bbc tool.
This flag is lowered to MLIR OpenMP flag attribute.
Differential Revision: https://reviews.llvm.org/D150354
Reviewed By: kiranchandramohan
