This patch adds logic in the InputOutputTestAction frontend action for
reading input from stdin. Without this patch the following fails:
```
flang-new -fc1 -test-io -
```
The implementation of `InputOutputTestAction` is cleaned-up and a test
for reading from stdin is added.
Note that there's a difference between `-test-io` and e.g. `-E` in terms
of file I/O. The frontend action for the former handles all file I/O on
it's own. Conversely, the action corresponding to -E relies on the
prescanner API to handle this.
Currently we can't test reading from stdin for `flang-new -`. In this
case `libclangDriver` assumes `-x -c`. This in turn leads to `flang-new
-cc1`, which is not supported.
Add support for option -J/-module-dir in the new Flang driver. This
will allow for including module files in other directories, as the
default search path is currently the working folder. This also provides
an option of storing the output module in the specified folder.
Differential Revision: https://reviews.llvm.org/D95448
Add support for the following layout options:
* -ffree-form
* -ffixed-form
- -ffixed-line-length=n (alias -ffixed-line-length-n)
Additionally remove options `-fno-free-form` and `-fno-fixed-form` as they were initially added to forward to gfortran but gfortran does not support these flags.
This patch adds the flag FlangOnlyOption to the existing options `-ffixed-form`, `-ffree-form` and `-ffree-line-length-` in Options.td. As of commit 6a75496836, these flags are not currently forwarded to gfortran anyway.
The default fixed line length in FrontendOptions is 72, based off the current default in Fortran::parser::Options. The line length cannot be set to a negative integer, or a positive integer less than 7 excluding 0, consistent with the behaviour of gfortran.
This patch does not add `-ffree-line-length-n` as Fortran::parser::Options does not have a variable for free form columns.
Whilst the `fixedFormColumns` variable is used in f18 for `-ffree-line-length-n`, f18 only allows `-ffree-line-length-none`/`-ffree-line-length-0` and not a user-specified value. `fixedFormcolumns` cannot be used in the new driver as it is ignored in the frontend when dealing with free form files.
Summary of changes:
- Remove -fno-fixed-form and -fno-free-form from Options.td
- Make -ffixed-form, -ffree-form and -ffree-line-length-n FlangOnlyOption in Options.td
- Create AddFortranDialectOptions method in Flang.cpp
- Create FortranForm enum in FrontendOptions.h
- Add fortranForm_ and fixedFormColumns_ to Fortran::frontend::FrontendOptions
- Update fixed-form-test.f so that it guarantees that it fails when forced as a free form file to better facilitate testing.
Differential Revision: https://reviews.llvm.org/D95460
Constant folding for calls to LBOUND() was not working when the lower bound of
a constant array was not 1.
I fixed this and re-enabled the test in Evaluate/folding16.f90 that previously
was silently failing. I slightly changed the test to parenthesize the first
argument to exercise all of the new code.
Differential Revision: https://reviews.llvm.org/D95894
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
Implement IEEE_SUPPORT_DATATYPE() and other inquiry intrinisic
functions from the intrinsic module IEEE_ARITHMETIC, folding all of
their results to .TRUE.
Differential Revision: https://reviews.llvm.org/D95830
This patch adds a check that verifies that the input file used when
calling the frontend driver (i.e. `flang-new -fc1`) actually exists.
This was not required for the compiler driver, `flang-new`, as that's
already handled in libclangDriver.
Once all input/output file management is moved to the driver, we should
also check that for input from `stdin` the corresponding file descriptor
was successfully acquired.
This patch also makes sure that the default action in the frontend is
`ParseSyntaxOnly`. This is consistent with Clang. Before this change
`flang-new -fc1` would do nothing, which makes testing changes like the
one introduced here a bit tricky.
Reviewed By: SouraVX
Differential Revision: https://reviews.llvm.org/D95127
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
There were two problems with constant arrays whose lower bound is not 1.
First, when folding the arrays, we were creating the folded array to have lower
bounds of 1 but, we were not re-adjusting their lower bounds to the
declared values. Second, we were not calculating the extents correctly.
Both of these problems led to bogus error messages.
I fixed the first problem by adjusting the lower bounds in
NonPointerInitializationExpr() in Evaluate/check-expression.cpp. I wrote the
class ArrayConstantBoundChanger, which is similar to the existing class
ScalarConstantExpander. In the process of implementing and testing it, I found
a bug that I fixed in ScalarConstantExpander which caused it to infinitely
recurse on parenthesized expressions. I also removed the unrelated class
ScalarExpansionVisitor, which was not used.
I fixed the second problem by changing the formula that calculates upper bounds
in in the function ComputeUpperBound() in Evaluate/shape.cpp.
I added tests that trigger the bogus error messages mentioned above along with
a constant folding tests that uses array operands with shapes that conform but
have different bounds.
In the process of adding tests, I discovered that tests in
Evaluate/folding09.f90 and folding16.f90 were written incorrectly, and I
fixed them. This also revealed a bug in contant folding of the
intrinsic "lbounds" which I plan to fix in a later change.
Differential Revision: https://reviews.llvm.org/D95449
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
kernels loop and enter data had a too restrictive constraint for the wait clause.
The wait clause is allowed multiple times and not only once. This patch fix this problem.
Reviewed By: SouraVX
Differential Revision: https://reviews.llvm.org/D95469
Restriction on clauses for the EXIT DATA directive were not fully correct.
This patch fixes the situation. The async, if and finalize clauses are allowed
only once.
Reviewed By: SouraVX
Differential Revision: https://reviews.llvm.org/D95470
Restriction on clauses for the HOST_DATA directive were not fully correct.
This patch fixes the situation. The if and if_present clauses are allowed
only once.
Reviewed By: SouraVX
Differential Revision: https://reviews.llvm.org/D95473
Ensure diagnostics from the prescanner are reported when running `flang-new -fsyntax-only` (i.e. only syntax parsing).
This keeps the diagnostics output of flang-new consistent with `f18 -fparse-only` when running the syntax parsing action, ParseSyntaxOnlyAction.
Summary of changes:
- Modify ParseSyntaxOnlyAction::ExecuteAction to report diagnostics
Differential Revision: https://reviews.llvm.org/D95220
Split the tests from acc-clause-validity.f90 in dedicated files by directives.
The file acc-clause-validity.f90 was getting too big to be correctly maintained.
Tests are identical.
Reviewed By: SouraVX
Differential Revision: https://reviews.llvm.org/D95328
Update the preprocessor regression tests to use the new driver if the new driver is built (FLANG_BUILD_NEW_DRIVER=On), otherwise the tests will still run using f18.
Summary of changes:
- Introduce %flang to the regression tests, which points to the new driver if it is built or otherwise points to f18
- Update all tests in flang/test/Preprocessing/ to use %flang
Differential Revision: https://reviews.llvm.org/D94805
Expressions emitted to module files and error messages
sometimes contain conversions of integer results of inquiry
intrinsics; these are usually not needed, and can conflict
with "int" in the user's namespace. Improve folding so that
these conversions don't appear, and do some other clean-up
in adjacent code.
Differential Revision: https://reviews.llvm.org/D95172
This patch makes sure that diagnostics from the prescanner are reported
when running `flang-new -E` (i.e. only the preprocessor phase is
requested). More specifically, the `PrintPreprocessedAction` action is
updated.
With this patch we make sure that the `f18` and `flang-new` provide
identical output when running the preprocessor and the prescanner
generates diagnostics.
Differential Revision: https://reviews.llvm.org/D94782
It's possible to declare deferred shape array using the POINTER
statement, for example:
POINTER :: var(:)
When analyzing POINTER declarations, we were not capturing the array
specification information, if present. I fixed this by changing the
"Post" function for "parser::PointerDecl" to check to see if the
declaration contained a "DeferredShapeSpecList". In such cases, I
analyzed the shape and used to information to declare an "ObjectEntity"
that contains the shape information rather than an "UnknownEntity".
I also added a couple of small tests that fail to compile without these
changes.
Differential Revision: https://reviews.llvm.org/D95080
* IsArrayElement() needs another option to control whether it
should ignore trailing component references.
* Add IsObjectPointer().
* Add const Scope& variants of IsFunction() and IsProcedure().
* Make TypeAndShape::Characterize() work with procedure bindings.
* Handle CHARACTER length in MeasureSizeInBytes().
* Fine-tune FindExternallyVisibleObject()'s handling of dummy arguments
to conform with Fortran 2018: only INTENT(IN) and dummy pointers
in pure functions signify; update two tests accordingly.
Also: resolve some stylistic inconsistencies and add a missing
"const" in the expression traversal template framework.
Differential Revision: https://reviews.llvm.org/D95011
F18 Clause 19.4p9 says:
The associate names of an ASSOCIATE construct have the scope of the
block.
Clause 11.3.1p1 says the ASSOCIATE statement is not itself in the block:
R1102 associate-construct is: associate-stmt block end-associate-stmt
Associate statement associations are currently fully processed from left
to right, incorrectly interposing associating entities earlier in the
list on same-named entities in the host scope.
1 program p
2 logical :: a = .false.
3 real :: b = 9.73
4 associate (b => a, a => b)
5 print*, a, b
6 end associate
7 print*, a, b
8 end
Associating names 'a' and 'b' at line 4 in this code are now both
aliased to logical host entity 'a' at line 2. This happens because the
reference to 'b' in the second association incorrectly resolves 'b' to
the entity in line 4 (already associated to 'a' at line 2), rather than
the 'b' at line 3. With bridge code to process these associations,
f18 output is:
F F
F 9.73
It should be:
9.73 F
F 9.73
To fix this, names in right-hand side selector variables/expressions
must all be resolved before any left-hand side entities are resolved.
This is done by maintaining a stack of lists of associations, rather
than a stack of associations. Each ASSOCIATE statement's list of
assocations is then visited once for right-hand side processing, and
once for left-hand side processing.
Note that other construct associations do not have this problem.
SELECT RANK and SELECT TYPE each have a single assocation, not a list.
Constraint C1113 prohibits the right-hand side of a CHANGE TEAM
association from referencing any left-hand side entity.
Differential Revision: https://reviews.llvm.org/D95010
The utility routine WhyNotModifiable() needed to become more
aware of the use of pointers in data-refs; the targets of
pointer components are sometimes modifiable even when the
leftmost ("base") symbol of a data-ref is not.
Added a new unit test for WhyNotModifiable() that uses internal
READ statements (mostly), since I/O semantic checking uses
WhyNotModifiable() for all its definability checking.
Differential Revision: https://reviews.llvm.org/D94849
Add Semantic checks for OpenMP 4.5 - 2.7.4 Workshare Construct.
- The structured block in a workshare construct may consist of only
scalar or array assignments, forall or where statements,
forall, where, atomic, critical or parallel constructs.
- All array assignments, scalar assignments, and masked array
assignments must be intrinsic assignments.
- The construct must not contain any user defined function calls unless
the function is ELEMENTAL.
Test cases : omp-workshare03.f90, omp-workshare04.f90, omp-workshare05.f90
Resolve test cases (omp-workshare01.f90 and omp-workshare02.f90) marked as XFAIL
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D93091
Add the following standard predefinitions that f18 supports:
* `__flang__`,
* `__flang_major__`,
* `__flang_minor__`,
* `__flang_patchlevel__`
Summary of changes:
- Populate Fortran::parser::Options#predefinitions with the default
supported predefinitions
Differential Revision: https://reviews.llvm.org/D94516
Currently the new flang driver always runs in free form mode. This patch
adds support for fixed form mode detection based on the file extensions.
Like `f18`, `flang-new` will treat files ending with ".f", ".F" and
".ff" as fixed form. Additionally, ".for", ".FOR", ".fpp" and ".FPP"
file extensions are recognised as fixed form files. This is consistent
with gfortran [1]. In summary, files with the following extensions are
treated as fixed-form:
* ".f", ".F", ".ff", ".for", ".FOR", ".fpp", ".FPP"
For consistency with flang/test/lit.cfg.py and f18, this patch also adds
support for the following file extensions:
* ".ff", ".FOR", ".for", ".ff90", ".fpp", ".FPP"
This is added in flang/lib/Frontend/FrontendOptions.cpp. Additionally,
the following extensions are included:
* ".f03", ".F03", ".f08", ".F08"
This is for compatibility with gfortran [1] and other popular Fortran
compilers [2].
NOTE: internally Flang will only differentiate between fixed and free
form files. Currently Flang does not support switching between language
standards, so in this regard file extensions are irrelevant. More
specifically, both `file.f03` and `file.f18` are represented with
`Language::Fortran` (as opposed to e.g. `Language::Fortran03`).
Summary of changes:
- Set Fortran::parser::Options::sFixedForm according to the file type
- Add isFixedFormSuffix and isFreeFormSuffix helper functions to
FrontendTool/Utils.h
- Change FrontendOptions::GetInputKindForExtension to support the missing
file extensions that f18 supports and some additional ones
- FrontendActionTest.cpp is updated to make sure that the test input is
treated as free-form
[1] https://gcc.gnu.org/onlinedocs/gfortran/GNU-Fortran-and-GCC.html
[2] https://github.com/llvm/llvm-project/blob/master/flang/docs/OptionComparison.md#notes
Differential Revision: https://reviews.llvm.org/D94228
Add support for option -I in the new Flang driver. This will allow for
included headers and module files in other directories, as the default
search path is currently the working folder. The behaviour of this is
consistent with the current f18 driver, where the current folder (i.e.
".") has the highest priority followed by the order of '-I's taking
priority from first to last.
Summary of changes:
- Add SearchDirectoriesFromDashI to PreprocessorOptions, to be forwarded
into the parser's searchDirectories
- Add header files and non-functional module files to be used in
regression tests. The module files are just text files and are used to
demonstrated that paths specified with `-I` are taken into account when
searching for .mod files.
Differential Revision: https://reviews.llvm.org/D93453
When a reference to a generic interface occurs in a specification
expression that must be emitted to a module file, we have a problem
when the generic resolves to a function whose name is inaccessible
due to being PRIVATE or due to a conflict with another use of the
same name in the scope. In these cases, construct a new name for
the specific procedure and emit a renaming USE to the module file.
Also, relax enforcement of PRIVATE when analyzing module files.
Differential Revision: https://reviews.llvm.org/D94815
The following driver invocation will generate an output file
in the same directory as the input file:
```
flang-new -fc1 -test-io test-input.f90
```
This is the desired behaviour. However, when testing we need to make
sure that we don't pollute the source directory. To this end, copy the
input file into a temporary directory before testing.
This is similar to https://reviews.llvm.org/D94243.
C843 states that "An entity with the INTENT attribute shall be a dummy
data object or a dummy procedure pointer." This change enforces that
and fixes some tests that erroneously violated this rule.
Differential Revision: https://reviews.llvm.org/D94781
Semantic checks added to check the worksharing 'single' region closely nested inside a worksharing 'do' region. And also to check whether the 'do' iteration variable is a variable in 'Firstprivate' clause.
Files:
check-directive-structure.h
check-omp-structure.h
check-omp-structure.cpp
Testcases:
omp-do01-positivecase.f90
omp-do01.f90
omp-do05-positivecase.f90
omp-do05.f90
Reviewed by: Kiran Chandramohan @kiranchandramohan , Valentin Clement @clementval
Differential Revision: https://reviews.llvm.org/D93205
When a use-associated procedure was included in a generic, we weren't
correctly recording that fact. The ultimate symbol was added rather than
the local symbol.
Also, improve the message emitted for the specific procedure by
mentioning the module it came from.
This fixes one of the problems in https://bugs.llvm.org/show_bug.cgi?id=48648.
Differential Revision: https://reviews.llvm.org/D94696
Generic type-bound interfaces for user-defined operators need to be formatted
as "OPERATOR(.op.)", not just ".op."
PRIVATE generics need to be marked as such.
Declaration ordering: when a generic interface shadows a
derived type of the same name, it needs to be emitted to the
module file at the point of definition of the derived type;
otherwise, the derived type's definition may appear after its
first use.
The module symbol for a module read from a module file needs
to be marked as coming from a module file before semantic
processing is performed on the contents of the module so that
any special handling for declarations in module files can be
properly activated.
IMPORT statements were sometimes missing for use-associated
symbols in surrounding scopes; fine-tune NeedImport().
Differential Revision: https://reviews.llvm.org/D94636
It's possible to declare an external procedure and then pass it as an
actual argument to a subprogram expecting a procedure argument. I added
tests for this and added an error message to distinguish passing an
actual argument with an implicit interface from passing an argument with
a mismatched explicit interface.
Differential Revision: https://reviews.llvm.org/D94505
If a module specifies default private accessibility, names that have
been use-associated are private by default. This was not reflected in
.mod files.
Differential Revision: https://reviews.llvm.org/D94602
In some contexts, including the motivating case of determining whether
the expressions that define the shape of a variable are "constant expressions"
in the sense of the Fortran standard, expression rewriting via Fold()
is not necessary, and should not be required. The inquiry intrinsics LBOUND,
UBOUND, and SIZE work correctly now in specification expressions and are
classified correctly as being constant expressions (or not). Getting this right
led to a fair amount of API clean-up as a consequence, including the
folding of shapes and TypeAndShape objects, and new APIs for shapes
that do not fold for those cases where folding isn't needed. Further,
the symbol-testing predicate APIs in Evaluate/tools.h now all resolve any
associations of their symbols and work transparently on use-, host-, and
construct-association symbols; the tools used to resolve those associations have
been defined and documented more precisely, and their clients adjusted as needed.
Differential Revision: https://reviews.llvm.org/D94561
`CheckNoBranching` is currently handling only illegal branching out for constructs
with `Parser::Name` in them.
Extend the same for handling illegal branching out caused by `Parser::Label` based statements.
This patch could possibly solve one of the issues(typically branching out) mentioned in D92735.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D93447
Remove duplicated function to check for required clauses on a directive. This was
still there from the merging of OpenACC and OpenMP common semantic checks and it can now be
removed so we use only one function.
Reviewed By: sameeranjoshi
Differential Revision: https://reviews.llvm.org/D93575
The following frontend driver invocation will generate 2 output files
in the same directory as the input files:
```
flang-new -fc1 input-1.f input-2.f
```
This is the desired behaviour. However, when testing we need to make
sure that we don't pollute the source directory. To this end, copy test
input files into a temporary directory.
Differential Revision: https://reviews.llvm.org/D94243
Internal subprograms have explicit interfaces. If an internal subprogram has
an alternate return, we check its explicit interface. But we were not
putting the label values of alternate returns into the actual argument.
I fixed this by changing the definition of actual arguments to be able
to contain a common::Label and putting the label for an alternate return
into the actual argument.
I also verified that we were already doing all of the semantic checking
required for alternate returns and removed a "TODO" for this.
I also added the test altreturn06.f90.
Differential Revision: https://reviews.llvm.org/D94017
Add semantic check for most of the restrictions for the declare directive.
Reviewed By: kiranktp
Differential Revision: https://reviews.llvm.org/D92741
This patch adds a frontend action for emitting object files. While Flang
does not support code-generation, this action remains a placeholder.
This patch simply provides glue-code to connect the compiler driver
with the appropriate frontend action.
The new action is triggered with the `-c` compiler driver flag, i.e.
`flang-new -c`. This is then translated to `flang-new -fc1 -emit-obj`,
so `-emit-obj` has to be marked as supported as well.
As code-generation is not available yet, `flang-new -c` results in a
driver error:
```
error: code-generation is not available yet
```
Hopefully this will help communicating the level of available
functionality within Flang.
The definition of `emit-obj` is updated so that it can be shared between
Clang and Flang. As the original definition was enclosed within a
Clang-specific TableGen `let` statement, it is extracted into a new `let`
statement. That felt like the cleanest option.
I also commented out `-triple` in Flang::ConstructJob and updated some
comments there. This is similar to https://reviews.llvm.org/D93027. I
wanted to make sure that it's clear that we can't support `-triple`
until we have code-generation. However, once code-generation is
available we _will need_ `-triple`.
As this patch adds `-emit-obj`, the emit-obj.f90 becomes irrelevant and
is deleted. Instead, phases.f90 is added to demonstrate that users can
control compilation phases (indeed, `-c` is a phase control flag).
Reviewed By: SouraVX, clementval
Differential Revision: https://reviews.llvm.org/D93301
This patch adds some positive and failure tests for init and shutdown directives.
Reviewed By: kiranktp
Differential Revision: https://reviews.llvm.org/D90786
Eric Schweitz