Following the conclusion of the
[RFC](https://discourse.llvm.org/t/rfc-names-for-flang-rt-libraries/84321),
rename Flang's runtime libraries as follows:
* libFortranRuntime.(a|so) to libflang_rt.runtime.(a|so)
* libFortranFloat128Math.a to libflang_rt.quadmath.a
* libCufRuntime_cuda_${CUDAToolkit_VERSION_MAJOR}.(a|so) to
libflang_rt.cuda_${CUDAToolkit_VERSION_MAJOR}.(a|so)
This follows the same naming scheme as Compiler-RT libraries
(`libclang_rt.${component}.(a|so)`). It provides some consistency
between Flang's runtime libraries for current and potential future
library components.
Avoid using the same library for runtime and compiler. `FortranDecimal`
was used in two ways:
1. As an auxiliary library needed for `libFortranRuntime.a`. This patch
adds the two source files of FortranDecimal directly into
FortranRuntime, so `FortranRuntime` is not used anymore.
2. As a library used by the Flang compiler. As the only remaining use of
the library, extra CMake code to make it compatible with the runtime can
be removed.
Before this PR, `enable_cuda_compilation` is applied to `FortranDecimal`
which causes everything that links to it, including flang (the
compiler), to depend on libcudart when CUDA support is enabled.
Having two runtime library just makes everything more complicated while
the user ideally should not be concerned with how the runtime is
structured internally. Some logic was copied for FortranDecimal because
of this, such as the ability to be compiled out-of tree
(b75a3c9f31c1ffdc9856aee32991d8129b372ee7) which is undocumented, the
logic to link against the various versions of Microsofts runtime library
(#70833), and avoiding dependency on the C++ runtime
(7783bba22c7add678d796741d30669c73159b3d8).
In the discussion around #116792, @rjmccall mentioned that ARCMigrate
has been obsoleted and that we could go ahead and remove it from Clang,
so this patch does just that.
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>
Remove flang/include/flang/Tools/CLOptions.inc - which was included as
is in - several places. Move the code in it to header and source files
which are used used in the "standard" way. Some minor cleanup such as
removing trailing whitespace and excessive newlines and reordering
entries alphabetically for files that were modified along the way.
Update the documentation that referenced CLOptions.inc.
This change inserts a few extension point callbacks in the
DefaultFIROptimizerPassPipeline. As an example usage of callbacks in the
FIR optimizer pipeline, the FIRInlinerCallback is now used to register
the default MLIR inliner pass in flang-new, tco, and bbc compilation
flows. Other compilation flows can use these callbacks to add extra
passes at different points of the pass pipeline.
---------
Co-authored-by: Vijay Kandiah <vkandiah@sky6.pgi.net>
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.
It seems like the `flang-to-external-fc` tool is no longer needed,
because Flang is now a full compiler in its own right. After PR #85249
has landed, this tool will not be able to pick up the `.f18.mod` files.
These are several fixes for the flang site. The look has been changed to
match clang since flang, like clang, is a frontend. Some broken links
were removed. Most fixes are to secton titles so the table of contents
is generated correctly. A minor typo has been fixed.
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.
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>
This is a big refactor of the clang driver's option handling to use
the Visibility flags introduced in https://reviews.llvm.org/D157149.
There are a few distinct parts, but they can't really be split into
separate commits and still be made to compile.
1. We split out some of the flags in ClangFlags to ClangVisibility.
Note that this does not include any subtractive flags.
2. We update the Flag definitions and OptIn/OptOut constructs in
Options.td by hand.
3. We introduce and use a script, update_options_td_flags, to ease
migration of flag definitions in Options.td, and we run that on
Options.td. I intend to remove this later, but I'm committing it so
that downstream forks can use the script to simplify merging.
4. We update calls to OptTable in the clang driver, cc1as, flang, and
clangd to use the visibility APIs instead of Include/Exclude flags.
5. We deprecate the Include/Exclude APIs and add a release note.
*if you are running into conflicts with this change:*
Note that https://reviews.llvm.org/D157150 may also be the culprit and
if so it should be handled first.
The script in `clang/utils/update_options_td_flags.py` can help. Take
the downstream side of all conflicts and then run the following:
```
% cd clang/include/clang/Driver
% ../../../utils/update_options_td_flags.py Options.td > Options.td.new
% mv Options.td.new Options.td
```
This will hopefully be sufficient, please take a look at the diff.
Differential Revision: https://reviews.llvm.org/D157151
This reverts commit 876df74dd47196a9ca3b4fff21ffb5441491a0a0.
My understanding (based on https://reviews.llvm.org/D149429) is that
this patch has caused all of Flang's buildbots to fail. I'm not really
able to verify 100% as the buildbot UI is incredibly slow ATM. I am
reverting either way so that we can discuss the right solution offline.
Add --undefined=_QQmain to the link line, so that a Fortran main program
will be included in the link job even if it is in an archive (unless we
are building a shared object). For now, this is only applied to the Gnu
toolchain.
We also add a section on the linker invocation to docs/FlangDriver.md.
The new tests require llvm-ar to construct an archive we can include in
the link job. This is a new dependency for flang/test (which already
depends on similar tools such as llvm-objdump).
See discussions in
https://github.com/llvm/llvm-project/issues/54787
which this patch fixes.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D134821
Without this change the problem is that flangOmpReport and
flangPrintFunctionNames libraries are not built under 'all',
but they are imported targets via LLVMExports.cmake so that
any out-of-tree build that configures upon LLVM+Flang package
will get this CMake error:
```
The imported target "flangPrintFunctionNames" references the file
".../lib/flangPrintFunctionNames.so"
but this file does not exist.
```
flang-aarch64-out-of-tree buildbot (https://lab.llvm.org/buildbot/#/builders/175)
does not catch this issue, because it does not enable Flang on the first stage.
This change gets rid of FLANG_BUILD_EXAMPLES in favor of LLVM_BUILD_EXAMPLES
and uses available LLVM CMake macros to add example executables/libraries.
Differential Revision: https://reviews.llvm.org/D145992
This PR makes flang emit a warning when the user passes an unsupported gfortran warning flag in as a CLI arg. This PR also checks each `-W` argument instead of just looking at the last one passed in.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D143301
The implementation of -fstack-arrays was added in
https://reviews.llvm.org/D140415
The new macro BoolOptionWithoutMarshalling in Options.td avoids
generating code to store the flags in clang data structures. For
example, writing something like
defm stack_arrays : BoolOption<"f", "stack-arrays",
CodeGenOpts<"StackArrays">, [...]
Would generate code referring to `clang::CodeGenOpts::StackArrays`, which
does not exist.
Differential Revision: https://reviews.llvm.org/D140972
clang -cc1 accepts -Ofast. I did not add it to flang -fc1 because this
seems redundant because the compiler driver will always resolve -Ofast
into -O3 -ffast-math (I added a test for this).
-menable-infs is removed from the frontend-forwarding test because if
all of the fast-math component flags are present, these will be resolved
into the fast-math flag. Instead -menable-infs is tested in the
fast-math test.
Specifying -ffast-math to the compiler driver causes linker invocations
to include crtfastmath.o.
RFC: https://discourse.llvm.org/t/rfc-the-meaning-of-ofast/66554
Differential Revision: https://reviews.llvm.org/D138675
Pass plugins are compiled and linked dynamically by default. Setting
`LLVM_${NAME}_LINK_INTO_TOOLS` to `ON` turns the project into a
statically linked extension. Projects like Polly can be used this way by
adding `-DLLVM_POLLY_LINK_INTO_TOOLS=ON` to the `cmake` command.
The changes in this patch makes the PassBuilder in Flang aware of
statically linked pass plugins, see the documentation for more details:
https://github.com/llvm/llvm-project/blob/main/llvm/docs/WritingAnLLVMNewPMPass.rst#id21
Differential Revision: https://reviews.llvm.org/D137673
Change-Id: Id1aa501dcb4821d0ec779f375cc8e8d6b0b92fce
This patch adds the -fpass-plugin option to flang which dynamically loads LLVM
passes from the shared object passed as the argument to the flag. The behavior
of the option is designed to replicate that of the same option in clang and
thus has the same capabilities and limitations.
Features:
Multiple instances of -fpass-plugin=path-to-file can be specified and each
of the files will be loaded in that order.
The flag can be passed to both flang-new and flang-new -fc1.
The flag will be listed when the -help flag is passed to both flang-new and
flang-new -fc1. It will also be listed when the --help-hidden flag is passed.
Limitations:
Dynamically loaded plugins are not supported in clang on Windows and are not
supported in flang either.
Addenda:
Some minor stylistic changes are made in the files that were modified to
enable this functionality. Those changes make the naming of functions more
consistent, but do not change any functionality that is not directly
related to enabling -fpass-plugin.
Differential Revision: https://reviews.llvm.org/D129156
This reverts commit 43fe6f7cc35ded691bbc2fa844086d321e705d46.
Reverting this as CI breaks.
To reproduce, run check-flang, and it will fail with an error saying
.../lib/Bye.so not found in pass-plugin.f90
Add the -fpass-plugin option to flang which dynamically loads LLVM passes from the
shared object passed as the argument to the flag. The behavior of the option is
designed to replicate that of the same option in clang and thus has the same
capabilities and limitations.
- Multiple instances of -fpass-plugin=path-to-file can be specified and each of the
files will be loaded in that order.
- The flag can be passed to both flang-new and flang-new -fc1.
Differential Revision: https://reviews.llvm.org/D129156
This is a follow-up of https://reviews.llvm.org/D125832
(see also https://reviews.llvm.org/D125788 for more context). It simply
removes any remaining references to the `flang` bash script. Note that
that `flang-to-external-fc` remains intact.
This felt worthwhile mentioning in the release notes, which have not
been updated since LLVM 12 (we are approaching LLVM 15 now). I took the
liberty of removing all of the out-dated content and added a note about
the renaming.
Differential Revision: https://reviews.llvm.org/D127094
This patch adds a few new member methods in the `PluginParseTreeAction`
frontend action base class. With these new methods, the plugin API
becomes independent of the driver internals. In particular, plugin
writers no longer require the `CompilerInstance.h` header file to access
various driver data structures (instead, they can use newly added
hooks).
This change is desirable as `CompilerInstance.h` includes various
headers from Clang (both explicitly and implicitly). Some of these
header files are generated at build time (through TableGen) and
including them creates a dependency on some of Clang's build targets.
However, plugins in Flang should not depend on Clang build targets.
Note that plugins might still work fine most of the time, even without
this change and without adding Clang build targets as dependency in
plugin's CMake definition. Indeed, these Clang build targets are often
generated early in the build process. However, that's not guaranteed and
we did notice that on occasions plugins would fail to build.
Differential Revision: https://reviews.llvm.org/D120999
Please note that the updated documentation reflects the design that we are
working towards, but haven't implemented competely yet. We took this approach
in order to provide a more holisitic and complete overview of the design.
In particular, this document assumes that Flang's frontend and compiler
driver can already generate code. This is still work-in-progress and is
being developed on the `fir-dev` branch in the F18 repository [1].
[1] https://github.com/flang-compiler/f18-llvm-project/tree/fir-dev
Differential Revision: https://reviews.llvm.org/D111573
