This patch introduce the fir-opt tool. Similar to mlir-opt for FIR.
It will be used in following patches to test fir opt and round-trip.
Reviewed By: schweitz, mehdi_amini
Differential Revision: https://reviews.llvm.org/D96535
This patch adds the following compiler frontend driver options:
* -fdebug-unparse (f18 spelling: -funparse)
* -fdebug-unparse-with-symbols (f18 spelling: -funparse-with-symbols)
The new driver will only accept the new spelling. `f18` will accept both
the original and the new spelling.
A new base class for frontend actions is added: `PrescanAndSemaAction`.
This is added to reduce code duplication that otherwise these new
options would lead to. Implementation from
* `ParseSyntaxOnlyAction::ExecutionAction`
is moved to:
* `PrescanAndSemaAction::BeginSourceFileAction`
This implementation is now shared between:
* PrescanAndSemaAction
* ParseSyntaxOnlyAction
* DebugUnparseAction
* DebugUnparseWithSymbolsAction
All tests that don't require other yet unimplemented options are
updated. This way `flang-new -fc1` is used instead of `f18` when
`FLANG_BUILD_NEW_DRIVER` is set to `On`. In order to facilitate this,
`%flang_fc1` is added in the LIT configuration (lit.cfg.py).
`asFortran` from f18.cpp is duplicated as `getBasicAsFortran` in
FrontendOptions.cpp. At this stage it's hard to find a good place to
share this method. I suggest that we revisit this once a switch from
`f18` to `flang-new` is complete.
Differential Revision: https://reviews.llvm.org/D96483
The following _action_ options are always used with `-fsyntax-only`
(also an _action_ option):
* -fdebug-dump-symbols
* -fdebug-dump-parse-tree
This patch makes the above options imply `-fsyntax-only`.
From the perspective of `f18` this change saves typing and is otherwise
a non-functional change. But it will simplify things in the new driver,
`flang-new`, in which only the last action option is taken into account
and executed. In other words, the following would only run
`-fsyntax-only`:
```
flang-new -fdebug-dump-symbols -fsyntax-only <input>
```
whereas this would only run `-fdebug-dump-symbols`:
```
flang-new -fsyntax-only -fdebug-dump-symbols <input>
```
Differential Revision: https://reviews.llvm.org/D96528
This patch introduce the fir-opt tool. Similar to mlir-opt for FIR.
It will be used in following patches to test fir opt and round-trip.
Reviewed By: schweitz, mehdi_amini
Differential Revision: https://reviews.llvm.org/D96535
Avoid spurious and confusing macro replacements from things like
-DPIC on Fortran source files whose suffixes indicate that preprocessing
is not expected.
Add gfortran-like "-cpp" and "-nocpp" flags to f18 to force predefinition
of macros independent of the source file suffix.
Differential Revision: https://reviews.llvm.org/D96464
Most components required for this are already there.
Build and Testing clean.
ninja check-flang
Reviewed By: clementval, tskeith
Differential Revision: https://reviews.llvm.org/D96411
MLIRContext allows its users to access directly to the DialectRegistry it
contains. While sometimes useful for registering additional dialects on an
already existing context, this breaks the encapsulation by essentially giving
raw accesses to a part of the context's internal state. Remove this mutable
access and instead provide a method to append a given DialectRegistry to the
one already contained in the context. Also provide a shortcut mechanism to
construct a context from an already existing registry, which seems to be a
common use case in the wild. Keep read-only access to the registry contained in
the context in case it needs to be copied or used for constructing another
context.
With this change, DialectRegistry is no longer concerned with loading the
dialects and deciding whether to invoke delayed interface registration. Loading
is concentrated in the MLIRContext, and the functionality of the registry
better reflects its name.
Depends On D96137
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D96331
Now that semantics is working, the standard -fsyntax-only option of
GNU and Clang should be used as the name of the option that causes
f18 to just run the front-end. Support both options in f18, silently
accepting the old option as a synonym for the new one (as
preferred by the code owner), and replace all instances of the
old -fparse-only option with -fsyntax-only throughout the source base.
Differential Revision: https://reviews.llvm.org/D95887
Legacy Fortran implementations support an alternative form of the
PARAMETER statement; it differs syntactically from the standard's
PARAMETER statement by lacking parentheses, and semantically by
using the type and shape of the initialization expression to define
the attributes of the named constant. (GNU Fortran gets that part
wrong; Intel Fortran and nvfortran have full support.)
This patch disables the old style PARAMETER statement by default, as
it is syntactically ambiguous with conforming assignment statements;
adds a new "-falternative-parameter-statement" option to enable it;
and implements it correctly when enabled.
Fixes https://bugs.llvm.org/show_bug.cgi?id=48774, in which a user
tripped over the syntactic ambiguity.
Differential Revision: https://reviews.llvm.org/D95697
Make the #include "file" preprocessing directive begin its
search in the same directory as the file containing the directive,
as other preprocessors and our Fortran INCLUDE statement do.
Avoid current working directory for all source files except the original.
Resolve tests.
Differential Revision: https://reviews.llvm.org/D95481
Make the #include "file" preprocessing directive begin its
search in the same directory as the file containing the directive,
as other preprocessors and our Fortran INCLUDE statement do.
Avoid current working directory for all source files after the original.
Differential Revision: https://reviews.llvm.org/D95388
* Remove an unimplemented and unused member function declaration
* Remove a misleading comment about an unrelated constraint number
* Fix a comment
* Add f18 crash message to "flang" driver script
Differential Revision: https://reviews.llvm.org/D95180
Flang has two CMake configurable header files that define compiler
version numbers:
* f18_version.h.in - only used in f18.cpp (uses version numbers from
LLVM's macro definitions)
* Version.inc.in - not currently used (uses version numbers hard-coded
in Flang's top CMake script)
Currently only f18_version.h.in provides version numbers consistent with
other subprojects in llvm-project. However, its location and name are
inconsistent with e.g. Clang. This patch merges the two headers
together:
* hard-coded version numbers in Flang's top CMake script are deleted
* Version.inc.in is updated to provide string versions of version
numbers (required by f18.cpp)
* f18_version.h.in is deleted as it's no longer needed
Differential Revision: https://reviews.llvm.org/D94422
As per Flang's coding guidelines
(flang/docs/C++style.md#error-messages):
```
Messages should start with a capital letter.
```
This patch updates error messages in the driver (new and old) so that
they conform with the guideline above.
This change was suggested in one of the recent reviews:
https://reviews.llvm.org/D93712. It felt like this deserved a dedicated
patch, so sending it separately.
The flang wrapper script that was created as bin/flang in an in-tree
build did not have a correct -intrinsic-module-directory option.
It was correct for out-of-tree builds and for both kinds of installs.
The fix is to pick the correct directory based on what exists.
The script is no longer configured by cmake (just copied) so that
mechanism can be deleted from the cmake file.
Differential Revision: https://reviews.llvm.org/D93496
The "flang" script that gets put into "install/bin" had an absolute path
in it. This precuded moving the install directory to a new location.
Differential Revision: https://reviews.llvm.org/D93131
Update all reference from the specification to the new OpenACC 3.1
document.
Reviewed By: SouraVX
Differential Revision: https://reviews.llvm.org/D92120
Define Fortran derived types that describe the characteristics
of derived types, and instantiations of parameterized derived
types, that are of relevance to the runtime language support
library. Define a suite of corresponding C++ structure types
for the runtime library to use to interpret instances of the
descriptions.
Create instances of these description types in Semantics as
static initializers for compiler-created objects in the scopes
that define or instantiate user derived types.
Delete obsolete code from earlier attempts to package runtime
type information.
Differential Revision: https://reviews.llvm.org/D92802
This patch plugs many holes in static initializer semantics, improves error
messages for default initial values and other component properties in
parameterized derived type instantiations, and cleans up several small
issues noticed during development. We now do proper scalar expansion,
folding, and type, rank, and shape conformance checking for component
default initializers in derived types and PDT instantiations.
The initial values of named constants are now guaranteed to have been folded
when installed in the symbol table, and are no longer folded or
scalar-expanded at each use in expression folding. Semantics documentation
was extended with information about the various kinds of initializations
in Fortran and when each of them are processed in the compiler.
Some necessary concomitant changes have bulked this patch out a bit:
* contextual messages attachments, which are now produced for parameterized
derived type instantiations so that the user can figure out which
instance caused a problem with a component, have been added as part
of ContextualMessages, and their implementation was debugged
* several APIs in evaluate::characteristics was changed so that a FoldingContext
is passed as an argument rather than just its intrinsic procedure table;
this affected client call sites in many files
* new tools in Evaluate/check-expression.cpp to determine when an Expr
actually is a single constant value and to validate a non-pointer
variable initializer or object component default value
* shape conformance checking has additional arguments that control
whether scalar expansion is allowed
* several now-unused functions and data members noticed and removed
* several crashes and bogus errors exposed by testing this new code
were fixed
* a -fdebug-stack-trace option to enable LLVM's stack tracing on
a crash, which might be useful in the future
TL;DR: Initialization processing does more and takes place at the right
times for all of the various kinds of things that can be initialized.
Differential Review: https://reviews.llvm.org/D92783
These includes have been deprecated in favor of BuiltinDialect.h, which contains the definitions of ModuleOp and FuncOp.
Differential Revision: https://reviews.llvm.org/D91572
This option doesn't enable any unique feature/code-patch. Also, it is
neither tested nor documented.
Differential Revision: https://reviews.llvm.org/D91537
These options are in practice passes to the external tool (defined with
F18_FC), i.e. fall into "unrecognised" category. No need to keep them
among other options that are actually parsed.
As per point 3 in [1]:
```
Accessor member functions are named with the non-public data member's
name, less the trailing underscore. Mutator member functions are named
set_...
```
Originally we just followed the LLVM's style, which is incompatible with
Flang. This patch renames the accessors and mutators accordingly.
`getDiagnostics` and `GetDiagnostics` are replaced with one accessor:
`diagnostics`. `SetDiagnostics` was neither implemented nor used, so
it's deleted.
[1] https://github.com/llvm/llvm-project/blob/master/flang/docs/C++style.md#naming
Differential Revision: https://reviews.llvm.org/D90300
This patch introduces the dependencies required to read and manage input files
provided by the command line option. It also adds the infrastructure to create
and write to output files. The output is sent to either stdout or a file
(specified with the `-o` flag).
Separately, in order to be able to test the code for file I/O, it adds
infrastructure to create frontend actions. As a basic testable example, it adds
the `InputOutputTest` FrontendAction. The sole purpose of this action is to
read a file from the command line and print it either to stdout or the output
file. This action is run by using the `-test-io` flag also introduced in this
patch (available for `flang-new` and `flang-new -fc1`). With this patch:
```
flang-new -test-io input-file.f90
```
will read input-file.f90 and print it in the output file.
The `InputOutputTest` frontend action has been introduced primarily to
facilitate testing. It is hidden from users (i.e. it's only displayed with
`--help-hidden`). Currently Clang doesn’t have an equivalent action.
`-test-io` is used to trigger the InputOutputTest action in the Flang frontend
driver. This patch makes sure that “flang-new” forwards it to “flang-new -fc1"
by creating a preprocessor job. However, in Flang.cpp, `-test-io` is passed to
“flang-new -fc1” without `-E`. This way we make sure that the preprocessor is
_not_ run in the frontend driver. This is the desired behaviour: `-test-io`
should only read the input file and print it to the output stream.
co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com>
Differential Revision: https://reviews.llvm.org/D87989
Recent patch that improved Flang's compatibility with respect to how LLVM
dynamic libraries should be linked (and specified in CMake recipes),
introduced a bug in the definition of `flang-new`:
* https://reviews.llvm.org/D87893
More specifically, `add_flang_tool` does not support the
`LINK_COMPONENTS` CMake argument. Instead, one should set
`LLVM_LINK_COMPONENTS` before calling `add_flang_tool`.
This patch reverts the change for `flang-new` from
https://reviews.llvm.org/D87893, and instead:
* sets `LLVM_LINK_COMPONENTS`
* calls `clang_target_link_libraries` to add Clang dependencies
Differential Revision: https://reviews.llvm.org/D89403
Harmonize usage of LLVM components througout Flang.
Explicit LLVM Libs where used across several CMakeFIles, which led to
incompatibilities with LLVM shlibs.
Fortunately, the LLVM component system can be relied on to harmoniously handle
both cases.
Differential Revision: https://reviews.llvm.org/D87893
Currently Flang uses TextDiagnostic, TextDiagnosticPrinter &
TestDiagnosticBuffer classes from Clang (more specifically, from
libclangFrontend). This patch introduces simplified equivalents of these
classes in Flang (i.e. it removes the dependency on libclangFrontend).
Flang only needs these diagnostics classes for the compiler driver
diagnostics. This is unlike in Clang in which similar diagnostic classes
are used for e.g. Lexing/Parsing/Sema diagnostics. For this reason, the
implementations introduced here are relatively basic. We can extend them
in the future if this is required.
This patch also enhances how the diagnostics are printed. In particular,
this is the diagnostic that you'd get _before_ the changes introduced here
(no text formatting):
```
$ bin/flang-new
error: no input files
```
This is the diagnostic that you get _after_ the changes introduced here
(in terminals that support it, the text is formatted - bold + red):
```
$ bin/flang-new
flang-new: error: no input files
```
Tests are updated accordingly and options related to enabling/disabling
color diagnostics are flagged as supported by Flang.
Reviewed By: sameeranjoshi, CarolineConcatto
Differential Revision: https://reviews.llvm.org/D87774
`flang-new` depends on libclangFrontend (it uses DiagnosticConsumer
classes from there). This patch adds the missing dependency in CMake.
clang::TextDiagnosticBuffer is only reported as missing when compiling
`flang-new` with BUILD_SHARED_LIBS=ON. This symbol is linked in
statically with libflangFrontend when BUILD_SHARED_LIBS=OFF.
Under current configuration, the permission of `flang` after installation is 700.
This could bring a problem for system administrators who build and install flang
for other users, which only the user who builds LLVM can execute it, and others
can not. In this patch, the explicit permission setting in the `install` command
is removed, and let CMake determine what perssion to be used like other components.
Reviewed By: DavidTruby
Differential Revision: https://reviews.llvm.org/D87783
The std::string holding the content of a CookedSource no longer
needs to be exposed in its API after the recent work that allows
the parsing context to hold multiple instances of a CookedSource.
So clean the API. These changes were extracted from some work in
progress that was made easier by the API changes.
Differential Revision: https://reviews.llvm.org/D87635
Summary:
This is the first patch implementing the new Flang driver as outlined in [1],
[2] & [3]. It creates Flang driver (`flang-new`) and Flang frontend driver
(`flang-new -fc1`). These will be renamed as `flang` and `flang -fc1` once the
current Flang throwaway driver, `flang`, can be replaced with `flang-new`.
Currently only 2 options are supported: `-help` and `--version`.
`flang-new` is implemented in terms of libclangDriver, defaulting the driver
mode to `FlangMode` (added to libclangDriver in [4]). This ensures that the
driver runs in Flang mode regardless of the name of the binary inferred from
argv[0].
The design of the new Flang compiler and frontend drivers is inspired by it
counterparts in Clang [3]. Currently, the new Flang compiler and frontend
drivers re-use Clang libraries: clangBasic, clangDriver and clangFrontend.
To identify Flang options, this patch adds FlangOption/FC1Option enums.
Driver::printHelp is updated so that `flang-new` prints only Flang options.
The new Flang driver is disabled by default. To enable it, set
`-DBUILD_FLANG_NEW_DRIVER=ON` when configuring CMake and add clang to
`LLVM_ENABLE_PROJECTS` (e.g. -DLLVM_ENABLE_PROJECTS=“clang;flang;mlir”).
[1] “RFC: new Flang driver - next steps”
http://lists.llvm.org/pipermail/flang-dev/2020-July/000470.html
[2] “RFC: Adding a fortran mode to the clang driver for flang”
http://lists.llvm.org/pipermail/cfe-dev/2019-June/062669.html
[3] “RFC: refactoring libclangDriver/libclangFrontend to share with Flang”
http://lists.llvm.org/pipermail/cfe-dev/2020-July/066393.html
[4] https://reviews.llvm.org/rG6bf55804924d5a1d902925ad080b1a2b57c5c75c
co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com>
Reviewed By: richard.barton.arm, sameeranjoshi
Differential Revision: https://reviews.llvm.org/D86089
These are owned by an instance of a new class AllCookedSources.
This removes the need for a Scope to own a string containing
a module's cooked source stream, and will enable errors to be
emitted when parsing module files in the future.
Differential Revision: https://reviews.llvm.org/D86891
Fixed some version information in flang/f18:
- fixed the behavior of the -v switch: this flag enables verbosity with used with arguments, but just displays the version when used alone (related to this bug: https://bugs.llvm.org/show_bug.cgi?id=46017)
- added __FLANG, __FLANG_MAJOR__, __FLANG_MINOR__ and __FLANG_PATCHLEVEL__ (similar to their __F18* counterparts) for compatibility purpose
Reviewed By: AlexisPerry, richard.barton.arm, tskeith
Differential Revision: https://reviews.llvm.org/D84334
Fixed some version information in flang/f18:
- fixed the behavior of the -v switch: this flag enables verbosity with used with arguments, but just displays the version when used alone (related to this bug: https://bugs.llvm.org/show_bug.cgi?id=46017)
- added __FLANG, __FLANG_MAJOR__, __FLANG_MINOR__ and __FLANG_PATCHLEVEL__ (similar to their __F18* counterparts) for compatibility purpose
Reviewed By: sscalpone, AlexisPerry, richard.barton.arm, tskeith
Differential Revision: https://reviews.llvm.org/D84334
Add `-fimplicit-none-type-always` to treat each specification-part
like it has `IMPLICIT NONE`. This is helpful for enforcing good Fortran
programming practices. We might consider something similar for
`IMPLICIT NONE(EXTERNAL)` as well.
Add `-fimplicit-none-type-never` to ignore occurrences of `IMPLICIT NONE`
and `IMPLICIT NONE(TYPE)`. This is to handle cases like the one below,
which violates the standard but it accepted by some compilers:
```
subroutine s(a, n)
implicit none
real :: a(n)
integer :: n
end
```
Differential Revision: https://reviews.llvm.org/D85363
Based on https://reviews.llvm.org/D84022 with additional changes to
maintain out-of-tree builds.
Original commit message:
Currently the binaries are output directly into the bin subdirectory of
the build directory. This doesn't work correctly with multi-config
generators which should output the binaries into <CONFIG_NAME>/bin
instead.
The original patch was implemented by David Truby and the additional
changes added here were also proposed by David Truby.
Differential Revision: https://reviews.llvm.org/D85078/
Co-authored-by: David Truby <david.truby@arm.com>
Add a usage string and a defaults section that clarifies:
* If no input files are given, f18 reads from stdin
* If no input files are given, f18 dumps the parse tree.
* The default behaviour is to exec F18_FC.
* The fefault F18_FC setting is 'gfortran'
Adds a simple regression test which tests the top and tail of the help
screen and the exit status.
Depends on D84855
Differential Revision: https://reviews.llvm.org/D84856
When flang is invoked with no files it waits for input on stdin. Make it
print a message saying this to prevent the user being surprised.
Differential Revision: https://reviews.llvm.org/D84855
Summary:
Currently the binaries are output directly into the bin subdirectory of the
build directory. This doesn't work correctly with multi-config generators which
should output the binaries into <CONFIG_NAME>/bin instead.
Reviewers: sscalpone, richard.barton.arm
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D84022
Add SetConvert() to the OPEN statement's runtime API.
Add ByteswapOption() to the main program's runtime API.
Check a $FORT_CONVERT environment variable, too, for
a swapping specifier.
Reviewed By: sscalpone
Differential Revision: https://reviews.llvm.org/D84284
Fix fronted shared library builds by eliminating dependences of
the parser on other component libraries, moving some code around that
wasn't in the right library, and making some dependences
explicit in the CMakeLists.txt files. The lowering library
does not yet build as a shared library due to some undefined
names.
Reviewed By: tskeith
Differential Revision: https://reviews.llvm.org/D83515
Summary:
This patch is removing the custom enumeration for OpenMP Directives and Clauses and replace them
with the newly tablegen generated one from llvm/Frontend. This is a first patch and some will follow to share the same
infrastructure where possible. The next patch should use the clauses allowance defined in the tablegen file.
Reviewers: jdoerfert, DavidTruby, sscalpone, kiranchandramohan, ichoyjx
Reviewed By: DavidTruby, ichoyjx
Subscribers: jholewinski, cfe-commits, dblaikie, MaskRay, ymandel, ichoyjx, mgorny, yaxunl, guansong, jfb, sstefan1, aaron.ballman, llvm-commits
Tags: #llvm, #flang, #clang
Differential Revision: https://reviews.llvm.org/D82906
Summary:
This patch is removing the custom enumeration for OpenMP Directives and Clauses and replace them
with the newly tablegen generated one from llvm/Frontend. This is a first patch and some will follow to share the same
infrastructure where possible. The next patch should use the clauses allowance defined in the tablegen file.
Reviewers: jdoerfert, DavidTruby, sscalpone, kiranchandramohan, ichoyjx
Reviewed By: DavidTruby, ichoyjx
Subscribers: ichoyjx, mgorny, yaxunl, guansong, jfb, sstefan1, aaron.ballman, llvm-commits
Tags: #llvm, #flang
Differential Revision: https://reviews.llvm.org/D82906
structure for upstreaming to llvm-project.
These files have had many changes since they were originally upstreamed.
Some of the changes are cosmetic. Most of the functional changes were
done to support the lowering of control-flow syntax from the front-end
parse trees to the FIR dialect.
This patch is meant to be a reviewable size. The functionality it
provides will be used by code yet to be upstreamed in lowering.
review comments:
[review D80449][NFC] make PFT ParentVariant a ReferenceVariant
ReferenceVariant had to be slightly updated to also support
non constant references (which is required for ParentType).
[review D80449] extend Variable implementation beyond a comment
The following Conversions are affected: LoopToStandard -> SCFToStandard,
LoopsToGPU -> SCFToGPU, VectorToLoops -> VectorToSCF. Full file paths are
affected. Additionally, drop the 'Convert' prefix from filenames living under
lib/Conversion where applicable.
API names and CLI options for pass testing are also renamed when applicable. In
particular, LoopsToGPU contains several passes that apply to different kinds of
loops (`for` or `parallel`), for which the original names are preserved.
Differential Revision: https://reviews.llvm.org/D79940
When I tried Solaris builds with `-DBUILD_SHARED_LIBS=ON`, some commands failed
to link:
[ 94%] Linking CXX executable ../../../../bin/f18
Undefined first referenced
symbol in file
Fortran::common::IntrinsicTypeDefaultKinds::set_sizeIntegerKind(int) CMakeFiles/f18.dir/f18.cpp.o (symbol belongs to implicit dependency /var/llvm/local-amd64-release-shared-gcc8-make/lib/libFortranCommon.so.11git)
Fortran::common::IntrinsicTypeDefaultKinds::set_subscriptIntegerKind(int) CMakeFiles/f18.dir/f18.cpp.o (symbol belongs to implicit dependency /var/llvm/local-amd64-release-shared-gcc8-make/lib/libFortranCommon.so.11git)
Fortran::common::EnumIndexToString[abi:cxx11](int, char const*) CMakeFiles/f18.dir/f18.cpp.o (symbol belongs to implicit dependency /var/llvm/local-amd64-release-shared-gcc8-make/lib/libFortranCommon.so.11git)
Fortran::common::IntrinsicTypeDefaultKinds::set_defaultIntegerKind(int) CMakeFiles/f18.dir/f18.cpp.o (symbol belongs to implicit dependency /var/llvm/local-amd64-release-shared-gcc8-make/lib/libFortranCommon.so.11git)
Fortran::common::IntrinsicTypeDefaultKinds::IntrinsicTypeDefaultKinds() CMakeFiles/f18.dir/f18.cpp.o (symbol belongs to implicit dependency /var/llvm/local-amd64-release-shared-gcc8-make/lib/libFortranCommon.so.11git)
Fortran::common::IntrinsicTypeDefaultKinds::set_defaultRealKind(int) CMakeFiles/f18.dir/f18.cpp.o (symbol belongs to implicit dependency /var/llvm/local-amd64-release-shared-gcc8-make/lib/libFortranCommon.so.11git)
ld: fatal: symbol referencing errors
This patch fixes this by adding explicit dependencies on `libFortranCommon`
to the affected commands.
Tested on `amd64-pc-solaris2.11`, `sparcv9-sun-solaris2.11`, and
`x86-64-pc-linux-gnu`.
Differential Revision: https://reviews.llvm.org/D78761
In general all the basic functionality seems to work and removes some redundancy
and more complicated features in favor of borrowing infrastructure from LLVM
build configurations. Here's a quick summary of details and remaining issues:
* Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and
MacOS/darwin. Architectures include x86_64 and Arm. Without
access to Window nothing has been tested there yet.
* As we change file and directory naming schemes (i.e.,
capitalization) some odd things can occur on MacOS systems with
case preserving but not case senstive file system configurations.
Can be painful and certainly something to watch out for as any
any such changes continue.
* Testing infrastructure still needs to be tuned up and worked on.
Note that there do appear to be cases of some tests hanging (on
MacOS in particular). They appear unrelated to the build
process.
* Shared library configurations need testing (and probably fixing).
* Tested both standalone and 'in-mono repo' builds. Changes for
supporting the mono repo builds will require LLVM-level changes that
are straightforward when the time comes.
* The configuration contains a work-around for LLVM's C++ standard mode
passing down into Flang/F18 builds (i.e., LLVM CMake configuration would
force a -std=c++11 flag to show up in command line arguments. The
current configuration removes that automatically and is more strict in
following new CMake guidelines for enforcing C++17 mode across all the
CMake files.
* Cleaned up a lot of repetition in the command line arguments. It
is likely that more work is still needed to both allow for
customization and working around CMake defailts (or those
inherited from LLVM's configuration files). On some platforms agressive
optimization flags (e.g. -O3) can actually break builds due to the inlining
of templates in .cpp source files that then no longer are available for use
cases outside those source files (shows up as link errors). Sticking at -O2
appears to fix this. Currently this CMake configuration forces this in
release mode but at the cost of stomping on any CMake, or user customized,
settings for the release flags.
* Made the lit tests non-source directory dependent where appropriate. This is
done by configuring certain test shell files to refer to the correct paths
whether an in or out of tree build is being performed. These configured
files are output in the build directory. A %B substitution is introduced in
lit to refer to the build directory, mirroring the %S substitution for the
source directory, so that the tests can refer to the configured shell scripts.
Co-authored-by: David Truby <david.truby@arm.com>
Original-commit: flang-compiler/f18@d1c7184159
Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
This patch replaces the occurrence of std::ostream by llvm::raw_ostream.
In LLVM Coding Standards[1] "All new code should use raw_ostream
instead of ostream".[1]
As a consequence, this patch also replaces the use of:
std::stringstream by llvm::raw_string_ostream or llvm::raw_ostream*
std::ofstream by llvm::raw_fd_ostream
std::endl by '\n' and flush()[2]
std::cout by llvm::outs() and
std::cerr by llvm::errs()
It also replaces std::strerro by llvm::sys::StrError** , but NOT in Fortran
runtime libraries
*std::stringstream were replaced by llvm::raw_ostream in all methods that
used std::stringstream as a parameter. Moreover, it removes the pointers to
these streams.
[1]https://llvm.org/docs/CodingStandards.html
[2]https://releases.llvm.org/2.5/docs/CodingStandards.html#ll_avoidendl
Signed-off-by: Caroline Concatto <caroline.concatto@arm.com>
Running clang-format-7
Signed-off-by: Caroline Concatto <caroline.concatto@arm.com>
Removing residue of ostream library
Signed-off-by: Caroline Concatto <caroline.concatto@arm.com>
Original-commit: flang-compiler/f18@a3507d44b8
Reviewed-on: https://github.com/flang-compiler/f18/pull/1047
Adds FIR library that implements an MLIR dialect to which Fortran
parse-tree will be lowered to.
FIR is defined and documented inside FIROps.td added in this commit.
It is possible to generate a more readable description FIRLangRef.md
from FIROps.td following the related instructions added to the README.md
by this commit.
This patch adds FIR definition and implementation that allow parsing,
printing, and verifying FIR. FIR transformations and lowering to Standard
and LLVM dialects are not part of this patch. The FIR verifiers are verifying
the basic properties of FIR operations in order to provide a sufficient
frame for lowering. Verifiers for more advanced FIR properties can be added
as needed.
Coarrays are not covered by FIR defined in this patch.
This patch also adds tco tool that is meant to process FIR input files and
drives transformations on it. The tco tool is used for testing.
In this patch, it is only used to demonstrate parsing/verifying/
and dumping FIR with round-trip tests.
Note:
This commit does not reflect an actual work log, it is a feature-based split of the
changes done in the FIR experimental branch. The related work log can be found in the
commits between:
742edde572
and
2ff5524212
Changes on top of these original commits were made during this patch review.
Original-commit: flang-compiler/f18@30b428a51e
Reviewed-on: https://github.com/flang-compiler/f18/pull/1035
This re-ordering allows building f18 with shared library using and LLVM build
with static libraries.
This reordering (that also made sens form an alphabetical point of view)
works here to do such "shared+archive" compiling because the current
dependency on LLVM is simple (only one f18 lib + an executable depends on LLVM).
As soon as two f18 libraries will depend on LLVM, one will have to use an LLVM
version built with -DBUILD_SHARED_LIBS=On if one wants to use this option
to compile f18.
Original-commit: flang-compiler/f18@bbbbe9c1aa
Reviewed-on: https://github.com/flang-compiler/f18/pull/994
The Pre-FIR Tree structure is a transient data structure that
is meant to be built from the parse tree just before lowering to
FIR and that will be deleted just afterwards. It is not meant to perfrom
optimization analysis and transformations. It only provides temporary
information, such as label target information or parse tree parent nodes,
that is meant to be used to lower the parse tree structure into
FIR operations.
A PFTBuilder class builds the Pre-Fir Tree from the parse-tree.
A pretty printer is available to visualize this data structure.
- Lit tests are added to:
1. that the PFT tree structure is as expected
2. that the PFT captures all intented nodes
- Cmake changes: Prevent warnings inisde LLVM headers when compiling flang
The issue is that some LLVM headers define functions where the usage of
the parameters depend on environment ifdef. See for instance Size in:
5f940220bf/llvm/include/llvm/Support/Compiler.h (L574)
Because flang is build with -Werror and -Wunused-parameter is default in
clang, this may breaks build in some environments (like with clang9 on macos).
A solution would be to add -Wno-unused-parameter to flang CmakLists.txt,
but it is wished to keep this warning on flang sources for quality purposes.
Fixing LLVM headers is not an easy task and `[[maybe_unused]]` is C++17 and
cannot be used yet in LLVM headers.
Hence, this fix simply silence warnings coming from LLVM headers by telling
CMake they are to be considered as if they were system headers.
- drone.io changes: remove llvm 6.0 from clang config in drone.io and link
flang with libstdc++ instead of libc++
llvm-dev resolved to llvm-6.0 in clang builds on drone.io. llvm 6.0 too old.
LLVM packages are linked with libstdc++ standard library whereas libc++ was
used for flang. This caused link time failure when building clang. Change
frone.io to build flang with libc++.
Note:
This commit does not reflect an actual work log, it is a feature based split of the
changes done in the FIR experimental branch. The related work log can be found in the
commits between:
864898cbe509d032abfe1172ec367dbd3dd92bc1
and
137c23da9c64cf90584cf81fd646053a69e91f63
Other changes come from https://github.com/flang-compiler/f18/pull/959 review.
Original-commit: flang-compiler/f18@edb0943bca
Reviewed-on: https://github.com/flang-compiler/f18/pull/959
Updated CMake files accordingly, using better regex
Updated license headers to match new extension and fit within 80 columns
Updated other comments within files that referred to the old extension
Original-commit: flang-compiler/f18@ae7721e611
Reviewed-on: https://github.com/flang-compiler/f18/pull/958
Have it wrap an optional Assignment so that we can distinguish between
unanalyzed and analyzed with error.
Change analysis of PointerAssignmentStmt to proceed with bounds even
if the DataRef or Expr has an error. Otherwise any bounds expressions
won't be analyzed in that case.
In GetExpr() and GetAssignment() if we get an internal error due to an
unanalyzed expression, dump the parse tree for the expression so we have
some context for the error. They should only be called after the
expression analysis phase. At that point, every expression and assignment
should be analyzed, though some may have resulted in errors(indicated by
returning `nullptr`).
Original-commit: flang-compiler/f18@3b865d7703
Reviewed-on: https://github.com/flang-compiler/f18/pull/944
Tree-same-pre-rewrite: false
back out -Mnolargearray default temporarily
Fix C_F_POINTER(SHAPE=) argument check, it can be any kind of integer
Revert default result kind of SIZE() & al. to standard by default
Remove needless usage of -fdebug-semantics
Original-commit: flang-compiler/f18@57058a5b16
Reviewed-on: https://github.com/flang-compiler/f18/pull/907
Add `typedAssignment` to `PointerAssignmentStmt` parse tree node and
extend `evaluate::Assignment` to include pointer assignment, including
analyzed bounds. Analyze pointer assignments and fill those in.
Emit them in unparsed output and parse tree dump when present.
Change assignment checking to use analyzed expressions and assignments
rather than calling AnalyzeExpr. Check bounds in pointer assignments
for impure function calls in FORALL context.
Add `Fold` convenience function to `ExpressionAnalyzer`.
Original-commit: flang-compiler/f18@140c983423
Reviewed-on: https://github.com/flang-compiler/f18/pull/904
Make compilation of other predefined module files depend on
__fortran_builtins.mod. Currently only iso_c_binding.f90 and
iso_fortran_env.f90 depend on it but others could in the future.
Create the .f18.mod files by copying from the .mod files so that
we don't have to worry about dependencies for those.
Original-commit: flang-compiler/f18@8209ad3d32
Reviewed-on: https://github.com/flang-compiler/f18/pull/899
This changes the license information in many of the flang source files.
- Renamed LICENSE to LICENSE.txt.
- NVIDIA Copyright lines have been removed.
- Initial lines for files follow the LLVM coding convention (file name on the first line; Emacs mode information on the first line).
- License references have been replaced with the abridged LLVM text.
- License information was removed from the test files.
- No file header was placed on test files (these weren't in most LLVM test files).
- License information was added to documentation files where it was missing.
We did not add brief file summaries to the initial line.
See http://llvm.org/docs/DeveloperPolicy.html#new-llvm-project-license-framework
for a description of the new license.
See http://llvm.org/docs/CodingStandards.html#file-headers
for a description of the new LLVM standard file header.
Original-commit: flang-compiler/f18@add6cde724
Reviewed-on: https://github.com/flang-compiler/f18/pull/887
When dumping the parse tree, if there are analyzed expressions,
assignments, or call statements, include the Fortran form of those
in the dump.
This uses the same `AnalyzedObjectsAsFortran` object that unparsing
does so it applies to the same nodes.
We already do something like this for `Name` nodes as well as some
predefined types, so abstract it into an `AsFortran` function which
returns the Fortran source for a node that is to be included in the
dump.
Original-commit: flang-compiler/f18@823b044d2a
Reviewed-on: https://github.com/flang-compiler/f18/pull/878
Tree-same-pre-rewrite: false
Mehdi Chinoune