`FlangFrontendTests` depends on libclangFrontend (it uses
DiagnosticConsumer classes from there). This patch adds the missing
dependency in CMake.
The missing dependency manifests itself only with BUILD_SHARED_LIBS=ON.
This symbol is linked in statically with libflangFrontend when
BUILD_SHARED_LIBS=OFF.
`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.
1. Section 2.5 : Parallel Construct
2. Section 2.7.1 : Loop Construct
3. Section 2.7.2 : Sections Construct
4. Section 2.7.3 : Single Construct
5. Section 2.7.4 : Workshare Construct
6. Section 2.8.1 : Simd Construct
7. Section 2.8.3 : Loop Simd Construct
8. Section 2.9.1 : Task Construct
9. Section 2.9.2 : Taskloop Construct
10. Section 2.9.3 : Taskloop Simd Construct
Most of the test cases added as part of this change contains semantic errors except few cases which are semantically correct but thrown a semantic error.
Currently flang is not throwing the errors for these cases and throwing semantic errors for the following correct test cases
{omp-do03.f90 , omp-loop-simd01.f90 , omp-simd02.f90 , omp-taskloop01.f90}
Hence, all the test cases are marked as XFAIL.
Reviewed By: DavidTruby
Differential Revision: https://reviews.llvm.org/D87908
The Flang driver depends on libclangBasic. This means, among other
things, that some of the tablegen files (e.g. diagnostic definitions)
need to be generated before various libclangBasic header files can be
included (e.g. DiagnosticIDs.h). If we are lucky, libclangBasic is
indeed built before various flang driver libraries that depend on it
are. This patch makes sure that this is deterministic - i.e.
libclangBasic is built before the Flang driver libraries are.
Differential Revision: https://reviews.llvm.org/D88110
In the frontend driver we should be using FC1Option (frontend driver
options) instead of FlangOption (flang driver options).
Differential Revision: https://reviews.llvm.org/D88108
These tests aren't adding much value and consensus has been reached for
there removal.
For more context, please refer to discussion in this revision:
https://reviews.llvm.org/D87846
Fortran 2018 15.4.2.2(4)(c) says nonassumed or explicit non-constant
length parameter require explicit interface. The "nonassumed" part was
missing in f18 characteristic analysis causing CanBeCalledViaImplicitInterface
to return false for `CHARACTER(*) function foo()` like interfaces.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D88075
The Microsoft compiler seems to have difficulties to decide between a const/non-const method of a captured object context in a closure. The error message is:
```
symbol.cpp(261): error C2668: 'Fortran::semantics::Symbol::detailsIf': ambiguous call to overloaded function
symbol.h(535): note: could be 'const D *Fortran::semantics::Symbol::detailsIf<Fortran::semantics::DerivedTypeDetails>(void) const'
symbol.h(534): note: or 'D *Fortran::semantics::Symbol::detailsIf<Fortran::semantics::DerivedTypeDetails>(void)'
symbol.cpp(261): note: while trying to match the argument list '()'
```
Explicitly using the this-pointer resolves this problem.
This patch is part of the series to make flang compilable with MS Visual Studio <http://lists.llvm.org/pipermail/flang-dev/2020-July/000448.html>.
Reviewed By: DavidTruby
Differential Revision: https://reviews.llvm.org/D88052
Like in D87961, msvc has difficulties deducing the template argument. The error message is:
```
expr-parsers.cpp(383): error C2672: 'applyLambda': no matching overloaded function found
```
Explicitly pass the first template argument to help it.
This patch is part of the series to make flang compilable with MS Visual Studio <http://lists.llvm.org/pipermail/flang-dev/2020-July/000448.html>.
Reviewed By: DavidTruby
Differential Revision: https://reviews.llvm.org/D88001
Msvc has difficulties deducing the template argument here. The error message is:
```
basic-parsers.h(790,12): error C2672: 'applyFunction': no matching overloaded function found
```
Explicitly pass the first template argument to help it.
This patch is part of the series to make flang compilable with MS Visual Studio <http://lists.llvm.org/pipermail/flang-dev/2020-July/000448.html>.
Reviewed By: DavidTruby
Differential Revision: https://reviews.llvm.org/D87961
Configure default value of `LLVM_ENABLE_WARNINGS` in `HandleLLVMOptions.cmake`.
`LLVM_ENABLE_WARNINGS` is documented as ON by default, but `HandleLLVMOptions` assumes the default has been set somewhere else. If it has not been explicitly set, then `HandleLLVMOptions` implicitly uses OFF as a default.
This removes the various `option()` declarations in favor of a single declaration in `HandleLLVMOptions`. This will prevent the unwanted use of `-w` that is mentioned in a couple of the comments.
Reviewed By: DavidTruby, #libunwind, JDevlieghere, compnerd
Differential Revision: https://reviews.llvm.org/D87243
Hew more closely to the C17 standard; perform macro replacement
of arguments to function-like macros unless they're being stringified
or pasted. Test with a model "assert" macro idiom that exposed
the problem.
Differential Revision: https://reviews.llvm.org/D87650
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
According to section 9.4.1, paragraph 3,
If the starting point is greater than the ending point, the substring has
length zero
But the compilers code for substring processing was failing a call to `CHECK()`
in this case. I fixed this by just setting the number of items in the
resulting string to 0 for this situation.
Differential Revision: https://reviews.llvm.org/D87799
MSVC tries to expand templates that are in the false-branch of a `if constexpr` construct. In this case, the condition checks whether a tuple has at least one element and then is trying to access it using `std::get<0>`, which fails when the tuple has 0 elements.
The workaround is to extract that case into a separate method.
This patch is part of the series to make flang compilable with MS Visual Studio <http://lists.llvm.org/pipermail/flang-dev/2020-July/000448.html>.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D87728
Adds a new GettingInvolved page to documentation which provides details about
mailing list, chats and calls.
Adds a sidebar page which provides common links on
all documentation pages.
The links include:
- Getting Started
- Getting Involved
- Github Repository
- Bug Reports
- Code Review
Depends on https://reviews.llvm.org/D87242
Reviewed By: richard.barton.arm
Differential Revision: https://reviews.llvm.org/D87270
The Fortran standard discusses BZ mode (treat blanks as zero digits)
explicitly in its effect on the editing of the digits prior to the
exponent part, but doesn't mention it in description of the
exponent part. Other compilers honor BZ mode in the exponent,
so we should do so too. So "1 e 1 " is 1.E11 in BZ mode.
Differential Revision: https://reviews.llvm.org/D87653
C-style /*comments*/ are removed during preprocessing directive
tokenization, but Fortran !comments need to be specifically
allowed.
Fixes LLVM bugzilla 47466.
Differential Revision: https://reviews.llvm.org/D87638
A type name in an IMPLICIT declaration that was later used in a PARAMETER
statement caused problems because the default symbol scope had not yet been
initialized. I avoided dereferencing in the situation where the default scope
was uninitialized and added a test that triggers the problem.
Also, once I corrected the bad dereference, the compiler was putting out
misleading error messages. The underlying error us due to violating section
7.5.10, paragraph 4, which states:
A structure constructor shall not appear before the referenced type is
defined.
I fixed this by testing to see if a type that is used in a structure
constructor is forward referenced.
Differential Revision: https://reviews.llvm.org/D87535
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
Now backends spell out which namespace they want to be in, instead of relying on
clients #including them inside already-opened namespaces. This also means that
cppNamespaces should be fully qualified, and there's no implicit "::mlir::"
prepended to them anymore.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D86811
Change the analyzed form of type-bound assignment to match that of call
statements. Resolve the binding name to a specific subprogram when
possible by using `GetBindingResolution`. Otherwise leave it as a
type-bound procedure call.
Differential Revision: https://reviews.llvm.org/D87541
Integer case values were being compared as unsigned by operator<
on evaluate::value::Integer. Change that to signed so that overlap
can be detected correctly.
Explicit CompareUnsigned and BLT are still available if unsigned
comparison is needed.
Fixes https://bugs.llvm.org/show_bug.cgi?id=47309
Differential Revision: https://reviews.llvm.org/D87595
A type name in an IMPLICIT declaration that was later used in a PARAMETER
statement caused problems because the default symbol scope had not yet been
initialized. I avoided dereferencing in the situation where the default scope
was uninitialized and added a test that triggers the problem.
Differential Revision: https://reviews.llvm.org/D87535
Define Fortran::Semantics::Scope::GetName in the header so it is available
to Fortran::Evaluate::Tool::AttachDeclaration without a circular dependency
introduced in 82edd42.
Reviewed By: tskeith
Differential Revision: https://reviews.llvm.org/D87505
Add a new index page to be the Flang documentation mainpage instead of
Overview.md, which jumps straight into the compiler Design. The index file
needs to be in .rst format to use the toctree directive to create table of
contents.
Also use the sphinx_markdown_tables extension to generate html tables form
markdown.
A number of additional style changes to the existing docs were needed to make
this work well:
* Convert all headings to the # style, which works better with toctree's
titlesonly option. Ensure that there is only one top-level heading per
document.
* Add a title to documents that don't have one for rendering on the index.
* Convert the grammar docs from .txt to .md. for better rendering
* Fixed broken link to a section in another document - sphinx does not seem to
support anchor links in markdown files.
Depends on D87226
Reviewed By: sameeranjoshi
Differential Revision: https://reviews.llvm.org/D87242
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
When we define a derived type that extends another derived type, we can then
create a structure constructor that contains values for the fields of both the
child type and its parent. The compiler's internal representation of that
value contains the name of the parent type where a component name would
normally appear. This caused an assert during contant folding.
There are three cases for components that appear in structure constructors.
The first is the normal case of a component appearing in a structure
constructor for its type.
The second is a component of the parent (or grandparent) type appearing in a
structure constructor for the child type.
The third is the parent type component, which can appear in the structure
constructor of its child.
There are also cases where the component can be arrays.
I created the test case folding12.f90 that covers all of these cases and
modified the code to handle them.
Most of my changes were to the "Find()" method of the type
"StructureConstructor" where I added code to cover the second and third cases
described above. To handle these cases, I needed to create a
"StructureConstructor" for the parent type component and return it. To handle
returning a newly created "StructureConstructor", I changed the return type of
"Find()" to be "std::optional" rather than an ordinary pointer.
This change supersedes D86172.
Differential Revision: https://reviews.llvm.org/D87151
Change how generic operators and assignments are checked for
distinguishable procedures. Because of how they are invoked, available
type-bound generics and normal generics all have to be considered
together. This is different from how generic names are checked.
Move common part of checking into DistinguishabilityHelper so that it
can be used in both cases after the appropriate procedures have been
added.
Cache result of Procedure::Characterize(Symbol) in a map in
CheckHelper so that we don't have to worry about passing the
characterized Procedures around or the cost of recomputing them.
Add MakeOpName() to construct names for defined operators and assignment
for using in error messages. This eliminates the need for different
messages in those cases.
When the procedures for a defined operator or assignment are undistinguishable,
include the type name in the error message, otherwise it may be ambiguous.
Add missing check that procedures for defined operators are functions
and that their dummy arguments are INTENT(IN) or VALUE.
Differential Revision: https://reviews.llvm.org/D87341
For out of tree builds, the user generally needs to specify LLVM_DIR and
MLIR_DIR on the command line so that the correct LLVM and MLIR
installations are picked up.
If the provided paths are absolute, everything works fine, however for
buildbots it is customary to work with relative paths, and that makes it
difficult for CMake to find the right modules to include.
This patch changes CMakeLists.txt to convert LLVM_DIR and MLIR_DIR to
absolute paths before adding them to CMAKE_MODULE_PATH. The inputs are
assumed to be relative to the source directory (llvm-project/flang).
Differential Revision: https://reviews.llvm.org/D87083
Msvc crashes with "INTERNAL COMPILER ERROR" when iterating over an `std::initializer_list` in a constexpr constructor. Explicitly use the iterator instead.
This patch is part of the series to [[ http://lists.llvm.org/pipermail/flang-dev/2020-July/000448.html | make flang compilable with MS Visual Studio ]].
Reviewed By: isuruf
Differential Revision: https://reviews.llvm.org/D86425
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
The DumpSymbolsSources() routine ordered its output by the addresses
of the names of the symbols, and was susceptible to variation across
environments. Fixed by using a multimap using the values of the names.
Differential Revision: https://reviews.llvm.org/D87035
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
Andrzej Warzynski