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
Add support for options -D and -U in the new Flang driver.
Summary of changes:
- Create PreprocessorOptions, to be used by the driver then translated
into Fortran::parser::Options
- Create CompilerInvocation::setFortranOpts to pass preprocessor
options into the parser options
- Add a dedicated method, Flang::AddPreprocessingOptions, to extract
preprocessing options from the driver arguments into the preprocessor
command arguments
Macros specified like -DName will default to definition 1.
When defining macros, the new driver will drop anything after an
end-of-line character. This is consistent with gfortran and clang, but
different to what currently f18 does. However, flang (which is a bash
wrapper for f18), also drops everything after an end-of-line character.
So gfortran-like behaviour felt like the natural choice. Test is added
to demonstrate this behaviour.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D93401
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.
If either `Prescan` or `Parse` generate any fatal errors, the new driver
will:
* report it (i.e. issue an error diagnostic)
* exit early
* return non-zero exit code
This behaviour is consistent with f18 (i.e. the old driver).
Reviewed By: sameeranjoshi
Differential Revision: https://reviews.llvm.org/D93712
After discussion in D93105 we found that the reduction clause was not following
the common OmpClause convention. This patch makes reduction clause part of OmpClause
with a value of OmpReductionClause in a similar way than task_reduction.
The unparse function for OmpReductionClause is adapted since the keyword and parenthesis
are issued by the corresponding unparse function for parser::OmpClause::Reduction.
Reviewed By: sameeranjoshi
Differential Revision: https://reviews.llvm.org/D93482
See OMP-5.0 2.19.5.5 task_reduction Clause.
To add a positive test case we need `taskgroup` directive which is not added hence skipping the test.
This is a dependency for `taskgroup` construct.
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D93105
Co-authored-by: Valentin Clement <clementval@gmail.com>
When an abstract interface is defined, add the ABSTRACT attribute to
subprogram symbols that define the interface body. Make use of that
when writing .mod files to include "abstract" on the interface statement.
Also, fix a problem with the order of symbols in a .mod file. Sometimes
a name is mentioned before the "real" declaration, e.g. in an access
statement. We want the order to be based on the real definitions. In
these cases we replace the symbol name with an identical name with a
different source location. Then by sorting based on the source location
we get symbols in the right order.
Differential Revision: https://reviews.llvm.org/D93572
OpenMP 4.5 - Variables that appear in expressions for statement function definitions
may not appear in OpenMP Private, Firstprivate or Lastprivate clauses.
Test case : omp-private03.f90
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D93213
See OMP-5.0 2.19.5.5 task_reduction Clause.
To add a positive test case we need `taskgroup` directive which is not added hence skipping the test.
This is a dependency for `taskgroup` construct.
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D93105
After discussion in `D93482` we found that the some of the clauses were not
following the common OmpClause convention.
The benefits of using OmpClause:
- Functionalities from structure checker are mostly aligned to work with
`llvm::omp::Clause`.
- The unparsing as well can take advantage.
- Homogeneity with OpenACC and rest of the clauses in OpenMP.
- Could even generate the parser with TableGen, when there is homogeneity.
- It becomes confusing when to use `flangClass` and `flangClassValue` inside
TableGen, if incase we generate parser using TableGen we could have only a
single `let expression`.
This patch makes `OmpDistScheduleClause` clause part of `OmpClause`.
The unparse function for `OmpDistScheduleClause` is adapted since the keyword
and parenthesis are issued by the corresponding unparse function for
`parser::OmpClause::DistSchedule`.
Reviewed By: clementval, kiranktp
Differential Revision: https://reviews.llvm.org/D93644
After discussion in `D93482` we found that the some of the clauses were not
following the common OmpClause convention.
The benefits of using OmpClause:
- Functionalities from structure checker are mostly aligned to work with
`llvm::omp::Clause`.
- The unparsing as well can take advantage.
- Homogeneity with OpenACC and rest of the clauses in OpenMP.
- Could even generate the parser with TableGen, when there is homogeneity.
- It becomes confusing when to use `flangClass` and `flangClassValue` inside
TableGen, if incase we generate parser using TableGen we could have only a
single `let expression`.
This patch makes `OmpNoWait` clause part of `OmpClause`.
Reviewed By: clementval, kiranktp
Differential Revision: https://reviews.llvm.org/D93643
After discussion in `D93482` we found that the some of the clauses were not
following the common OmpClause convention.
The benefits of using OmpClause:
- Functionalities from structure checker are mostly aligned to work with
`llvm::omp::Clause`.
- The unparsing as well can take advantage.
- Homogeneity with OpenACC and rest of the clauses in OpenMP.
- Could even generate the parser with TableGen, when there is homogeneity.
- It becomes confusing when to use `flangClass` and `flangClassValue` inside
TableGen, if incase we generate parser using TableGen we could have only a
single `let expression`.
This patch makes `OmpProcBindClause` clause part of `OmpClause`.
The unparse function is dropped as the unparsing is done by `WALK_NESTED_ENUM`
for `OmpProcBindClause`.
Reviewed By: clementval, kiranktp
Differential Revision: https://reviews.llvm.org/D93642
After discussion in `D93482` we found that the some of the clauses were not
following the common OmpClause convention.
The benefits of using OmpClause:
- Functionalities from structure checker are mostly aligned to work with
`llvm::omp::Clause`.
- The unparsing as well can take advantage.
- Homogeneity with OpenACC and rest of the clauses in OpenMP.
- Could even generate the parser with TableGen, when there is homogeneity.
- It becomes confusing when to use `flangClass` and `flangClassValue` inside
TableGen, if incase we generate parser using TableGen we could have only a
single `let expression`.
This patch makes `OmpDefaultClause` clause part of `OmpClause`.
The unparse function is dropped as the unparsing is done by `WALK_NESTED_ENUM`
for `OmpDefaultClause`.
Reviewed By: clementval, kiranktp
Differential Revision: https://reviews.llvm.org/D93641
After discussion in `D93482` we found that the some of the clauses were not
following the common OmpClause convention.
The benefits of using OmpClause:
- Functionalities from structure checker are mostly aligned to work with
`llvm::omp::Clause`.
- The unparsing as well can take advantage.
- Homogeneity with OpenACC and rest of the clauses in OpenMP.
- Could even generate the parser with TableGen, when there is homogeneity.
- It becomes confusing when to use `flangClass` and `flangClassValue` inside
TableGen, if incase we generate parser using TableGen we could have only a
single `let expression`.
This patch makes `allocate` clause part of `OmpClause`.The unparse function for
`OmpAllocateClause` is adapted since the keyword and parenthesis are issued by
the corresponding unparse function for `parser::OmpClause::Allocate`.
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D93640
Use the TableGen feature to have enum values for clauses.
Next step will be to extend the MLIR part used currently by OpenMP
to use the same enum on the dialect side.
This patch also add function that convert the enum to StringRef to be
used on the dump-parse-tree from flang.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D93576
We were only checking the restrictions of IMPLICIT NONE(EXTERNAL) when a
procedure name is first encountered. But it can also happen with an
existing symbol, e.g. if an external function's return type is declared
before is it called. This change adds a check in that branch too.
Differential Revision: https://reviews.llvm.org/D93552
The behaviour triggered with this flag is consistent with `-fparse-only`
in `flang` (i.e. the throwaway driver). This new spelling is consistent
with Clang and gfortran, and was proposed and agreed on for the new
driver in [1].
This patch also adds some minimal logic to communicate whether the
semantic checks have failed or not. When semantic checks fail, a
frontend driver error is generated. The return code from the frontend
driver is then determined by checking the driver diagnostics - the
presence of driver errors means that the compilation has failed. This
logic is consistent with `clang -cc1`.
[1] http://lists.llvm.org/pipermail/flang-dev/2020-November/000588.html
Differential Revision: https://reviews.llvm.org/D92854
This class used to serve a few useful purposes:
* Allowed containing a null DictionaryAttr
* Provided some simple mutable API around a DictionaryAttr
The first of which is no longer an issue now that there is much better caching support for attributes in general, and a cache in the context for empty dictionaries. The second results in more trouble than it's worth because it mutates the internal dictionary on every action, leading to a potentially large number of dictionary copies. NamedAttrList is a much better alternative for the second use case, and should be modified as needed to better fit it's usage as a DictionaryAttrBuilder.
Differential Revision: https://reviews.llvm.org/D93442
This better matches the rest of the infrastructure, is much simpler, and makes it easier to move these types to being declaratively specified.
Differential Revision: https://reviews.llvm.org/D93432
Remove the OpenMP clause information from the OMPKinds.def file and use the
information from the new OMP.td file. There is now a single source of truth for the
directives and clauses.
To avoid generate lots of specific small code from tablegen, the macros previously
used in OMPKinds.def are generated almost as identical. This can be polished and
possibly removed in a further patch.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D92955
This patch add some checks for the restriction on the routine directive
and fix several issue at the same time.
Validity tests have been added in a separate file than acc-clause-validity.f90 since this one
became quite large. I plan to split the larger file once on-going review are done.
Reviewed By: sameeranjoshi
Differential Revision: https://reviews.llvm.org/D92672
Names in EQUIVALENCE statements are only allowed to indicate local
objects as per 19.5.1.4, paragraph 2, item (10). Thus, a name appearing
in an EQUIVALENCE statement with no corresponding declaration in the
same scope is an implicit declaration of the name. If that scope
contains an IMPLICIT NONE, it's an error.
I implemented this by adding a state variable to ScopeHandler to
indicate if we're resolving the names in an EQUIVALENCE statement and
then checked this state when resolving names. I also added a test to
the existing tests for EQUIVALENCE statements.
Differential Revision: https://reviews.llvm.org/D93345
Elemental intrinsic function folding was not taking the lower
bounds of constant array arguments into account; these lower bounds
can be distinct from 1 when named constants appear as arguments.
LLVM bugzilla #48437.
Differential Revision: https://reviews.llvm.org/D93321
Some operators have more than one name, e.g. operator(==), operator(.eq).
That was working correctly in generic definitions but they can also
appear in other contexts: USE statements and access statements, for
example.
This changes FindInScope to always look for each of the names for
a symbol. So an operator may be use-associated under one name but
declared private under another name and it will be the same symbol.
This replaces GenericSpecInfo::FindInScope which was only usable in
some cases.
Add a version of FindInScope() that looks in the current scope to
simplify many of the calls.
Differential Revision: https://reviews.llvm.org/D93344
STORAGE_SIZE() is a standard inquiry intrinsic (size in bits
of an array element of the same type as the argument); SIZEOF()
is a common extension that returns the size in bytes of its
argument; C_SIZEOF() is a renaming of SIZEOF() in module ISO_C_BINDING.
STORAGE_SIZE() and SIZEOF() are implemented via rewrites to
expressions; these expressions will be constant when the necessary
type parameters and bounds are also constant.
Code to calculate the sizes of types (with and without alignment)
was isolated into Evaluate/type.* and /characteristics.*.
Code in Semantics/compute-offsets.* to calculate sizes and alignments
of derived types' scopes was exposed so that it can be called at type
instantiation time (earlier than before) so that these inquiry intrinsics
could be called from specification expressions.
Differential Revision: https://reviews.llvm.org/D93322
When merging use associations into a generic, we weren't handling
the case where the name that was use associated was itself a use
association. This is fixed by following that association to its
ultimate symbol (`useUltimate` in `DoAddUse`).
An example of the bug is `m12d` in `resolve17.f90`. `g` is associated
with `gc` in `m12c` which is associated with `gb` in `m12b`. It was that
last association that we weren't correctly following.
Differential Revision: https://reviews.llvm.org/D93343
Remove resolved & moot TODO comments in Common/, Parser/,
and Evaluate/. Address a pending one relating to parsing
ambiguity in DATA statement constants, handling it with
symbol table information in Semantics and adding a test.
Differential Revision: https://reviews.llvm.org/D93323
Before this patch, the Restorer depended on copy elision to happen.
Without copy elision, the function ScopedSet calls the move constructor
before its dtor. The dtor will prematurely restore the reference to the
original value.
Instead of relying the compiler to not use the Restorer's copy
constructor, delete its copy and assign operators. Hence, callers cannot
move or copy a Restorer object anymore, and have to explicitly provide
the reset state. ScopedSet avoids calling move/copy operations by
relying on unnamed return value optimization, which is mandatory in
C++17.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D88797
This bug hasn't affected us yet as our usage is too basic, i.e. we don't
rely on the defaults provided by `SetDefaultFortranOpts` just yet. This
will change shortly.
From OMP 5.0 [2.17.8]
Restriction:
If memory-order-clause is release,acquire, or acq_rel, list items must not be specified on the flush directive.
Reviewed By: kiranchandramohan, clementval
Differential Revision: https://reviews.llvm.org/D89879
Patch implements restrictions from 2.17.7 of OpenMP 5.0 standard for atomic Construct. Tests for the same are added.
One of the restriction
`OpenMP constructs may not be encountered during execution of an atomic region.`
Is mentioned in 5.0 standard to be a semantic restriction, but given the stricter nature of parser in F18 it's caught at parsing itself.
This patch is a next patch in series from D88965.
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D89583
The semantic analysis of index-names of FORALL statements looks up symbols with
the same name as the index-name. This is needed to exclude symbols that are
not objects. But if the symbol found is host-, use-, or construct-associated
with another entity, the check fails.
I fixed this by getting the root symbol of the symbol found and doing the check
on the root symbol. This required creating a non-const version of
"GetAssociationRoot()".
Differential Revision: https://reviews.llvm.org/D92970
Update all reference from the specification to the new OpenACC 3.1
document.
Reviewed By: SouraVX
Differential Revision: https://reviews.llvm.org/D92120
Add restriction on loop construct associated with DO CONCURRENT. Add couple of tests to ensure
clause validity checks.
Reviewed By: sameeranjoshi
Differential Revision: https://reviews.llvm.org/D92533
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
Add couple of clause validity tests for the update directive and check for
the restriction where at least self, host or device clause must appear on the directive.
Reviewed By: sameeranjoshi
Differential Revision: https://reviews.llvm.org/D92447
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
Add couple of clause validity tests for the update directive and check for
the restriction where at least self, host or device clause must appear on the directive.
Reviewed By: sameeranjoshi
Differential Revision: https://reviews.llvm.org/D92447
This is part of a larger refactoring the better congregates the builtin structures under the BuiltinDialect. This also removes the problematic "standard" naming that clashes with the "standard" dialect, which is not defined within IR/. A temporary forward is placed in StandardTypes.h to allow time for downstream users to replaced references.
Differential Revision: https://reviews.llvm.org/D92435
We were keeping the state of parsed equivalence sets in the class
DeclarationVisitor. A problem happened when analyzing the the specification
part of a declaration that contained an EQUIVALENCE statement followed by an
interface block. The same DeclarationVisitor object that was created for the
outer declaration was being used to analyze the specification part
of a procedure body in the interface block. When analyzing the specification
part of the procedure in the interface block, the names in the outer
declaration's EQUIVALENCE statement were erroneously compared with the names in
the arguments of the interface procedure. This resulted in a bogus error
message.
I fixed this by not checking equivalence sets when we're in an interface
block. I also added a test that will produce an error message without
this change.
Differential Revision: https://reviews.llvm.org/D92501
When the same generic name is use-associated from two modules, the
generics are merged into a single one in the current scope. This change
fixes some bugs in that process.
When a generic is merged, it can have two specific procedures with the
same name as the generic (c.f. module m7c in modfile07.f90). We were
disallowing that by checking for duplicate names in the generic rather
than duplicate symbols. Changing `namesSeen` to `symbolsSeen` in
`ResolveSpecificsInGeneric` fixes that.
We weren't including each USE of those generics in the .mod file so in
some cases they were incorrect. Extend GenericDetails to specify all
use-associated symbols that are merged into the generic. This is used to
write out .mod files correctly.
The distinguishability check for specific procedures of a generic
sometimes have to refer to procedures from a use-associated generic in
error messages. In that case we don't have the source location of the
procedure so adapt the message to say where is was use-associated from.
This requires passing the scope through the checks to make that
determination.
Differential Revision: https://reviews.llvm.org/D92492
`GetTopLevelUnitContaining` returns the Scope nested in the global scope
that contains the given Scope or Symbol.
Use "Get" rather than "Find" in the name because "Find" implies it might
not be found, which can't happen. Following that logic, rename
`FindProgramUnitContaining` to `GetProgramUnitContaining` and have it
also return a reference rather that a pointer.
Note that the use of "ProgramUnit" is slightly confusing. In the Fortran
standard, "program-unit" refers to what is called a "TopLevelUnit" here.
What we are calling a "ProgramUnit" (here and in `ProgramTree`) includes
internal subprograms while "TopLevelUnit" does not.
Differential Revision: https://reviews.llvm.org/D92491
Add the semantic checks for the OpenMP 4.5 - 2.15.3.3 Private clause.
1. Pointers with the INTENT(IN) attribute may not appear in a private clause.
2. Variables that appear in namelist statements may not appear in a private clause.
A flag 'InNamelist' is added to the Symbol::Flag to identify the symbols
in Namelist statemnts.
Test cases : omp-private01.f90, omp-private02.f90
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D90210
Add semantic check for the cache directive. According to section 2.10 from the specification:
A var in a cache directive must be a single array element or a simple subarray.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D90184
Semantic check added to check and restrict the value of the parameter in the COLLAPSE or ORDERED clause
if it is larger than the number of nested loops following the construct.
Test Cases:
omp-do-collapse-positivecases.f90
omp-do-collapse.f90
omp-do-ordered-positivecases.f90
omp-do-ordered.f90
Reviewed by: Kiran Chandramohan @kiranchandramohan , Valentin Clement @clementval
Differential Revision: https://reviews.llvm.org/D89860
Semantic check to restrict the appearance of a variable that is part of another variable
(as an array or structure element) in a PRIVATE or SHARED clause.
Test Cases:
omp-parallel-private01.f90
omp-parallel-private02.f90
omp-parallel-private03.f90
omp-parallel-private04.f90
omp-parallel-shared01.f90
omp-parallel-shared02.f90
omp-parallel-shared03.f90
omp-parallel-shared04.f90
Reviewed by: Kiran Chandramohan @kiranchandramohan , Valentin Clement @clementval
Differential Revision: https://reviews.llvm.org/D89395
This patch introduce the separate parser for the memory-order-clause from the general
OmpClauseList. This parser still creates OmpClause node and therefore can use all the feature
from TableGen and the OmpStructureChecker.
This is applied only for the Flush construct in this patch and it should be applied for
atomic as well.
This is the approach we disscussed several time during the weekly call.
Reviewed By: kiranchandramohan, sameeranjoshi
Differential Revision: https://reviews.llvm.org/D91839
`OmpStructureChecker` has too much boilerplate code in source file.
This patch:
1. Use helpers from `check-directive-structure.h` and reduces the boilerplate.
2. Use TableGen infrastructure as much as possible.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D90834
Fortran defines "null-init" null pointer initializers as
being function references, syntactically, that have to resolve
to calls to the intrinsic function NULL() with no actual
arguments.
Differential revision: https://reviews.llvm.org/D91657
When comparing LOGICAL operands using ".eq." or ".ne." we were not
guiding users to the ".eqv." and ".neqv." operations.
Differential Revision: https://reviews.llvm.org/D91736
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
According to section 19.4, paragraph 5, the scope of an ac-implied-do variable
is the enclosing ac-implied-do. But we were not creating new scopes upon
entry to an ac-implied-do. This was causing error messages to be erroneously
emitted.
I fixed, the code, added a test to array-constr-values.f90, added the test
folding15.f90 and corrected the test symbol05.f90.
Differential Revision: https://reviews.llvm.org/D91560
Add the semantic checks for the OpenMP 4.5 - 2.13.9 Depend clause.
1. List items in depend clause should not be zero length array sections.
2. A variable that is part of another variable like structure component
should not be specified on a depend clause.
Test cases : omp-depend01.f90, omp-depend02.f90, omp-depend03.f90
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D89934
COMPLEX negation, addition, subtraction, conversions of kind, and
equality/inequality were represented as component-wise REAL
operations. It turns out to be easier for lowering if we
do not split and recombine these COMPLEX operations, and it
avoids a potential problem with COMPLEX valued function calls
in these contexts. So add this suite of operations to the
typed expression representation in place of the component-wise
transformations, and support them in folding.
Differential revision: https://reviews.llvm.org/D91443
When comparing arrays whose shapes do not conform, the contant folding
code ran into problems trying to get the value of an extent that did not
exist. There were actually two problems. First, the routine
"CheckConformance()" was returning "true" when the compiler was unable
to get the extent of an array. Second, the function
"ApplyElementwise()" was calling "CheckConformance()" prior to folding
the elements of two arrays, but it was ignoring the return value.
Differential Revision: https://reviews.llvm.org/D91440
An io-unit that is an internal-file-variable is syntactically identical
to a file-unit-number expression that is a variable reference. An
ambiguous unit is initially parsed as an internal-file-variable. If
semantic analysis determines that the unit is not of character type,
it is rewritten as an internal-file-variable. This modification must
retain source coordinate information.
Differential revision: https://reviews.llvm.org/D91375
The implementation of Messages with forward_list<> makes some
nonstandard assumptions about the validity of iterators that don't
hold up with MSVC's implementation. Use list<> instead. The
measured performance is comparable.
This change obviated a distinction between two member functions
of Messages, and the uses of one have been replaced with calls
to the other.
Similar usage in CharBuffer was also replaced for consistency.
Differential revision: https://reviews.llvm.org/D91210
Avoid a spurious error message about a dummy procedure reference
in a specification expression by restructuring the handling of
use-associated and host-associated symbols.
Updated to fix a circular dependence between shared library
binaries that was introduced by the original patch.
Differential revision: https://reviews.llvm.org/D91286
F18 clause 5.3.3 explicitly allows labels on program unit END statements.
Label resolution code accounts for this for singleton program units,
but incorrectly generates an error for host subprograms with internal
subprograms.
subroutine s(n)
call s1(n)
if (n == 0) goto 88 ! incorrect error
print*, 's'
contains
subroutine s1(n)
if (n == 0) goto 77 ! ok
print*, 's1'
77 end subroutine s1
88 end
Label resolution code makes a sequential pass over an entire file to
collect label information for all subprograms, followed by a pass through
that information for semantics checks. The problem is that END statements
may be separated from prior subprogram code by internal subprogram
definitions, so an END label can be associated with the wrong subprogram.
There are several ways to fix this. Labels are always local to a
subprogram. So the two separate passes over the entire file could probably
instead be interleaved to perform analysis on a subprogram as soon as the
end of the subprogram is reached, using a small stack. The stack structure
would account for the "split" code case. This might work.
It is possible that there is some not otherwise apparent advantage to
the current full-file pass design. The parse tree has productions that
provide access to a subprogram END statement "in advance". An alternative
is to access this information to solve the problem. This PR implements
this latter option.
Differential revision: https://reviews.llvm.org/D91217
Implicitly typed references to external functions are applying
the IMPLICIT typing rules of the global scope in which their
symbols were created, not the IMPLICIT typing rules in force in
the scope from which they were referenced.
Differential revision: https://reviews.llvm.org/D91214
Avoid a spurious error message about a dummy procedure reference
in a specification expression by restructuring the handling of
use-associated and host-associated symbols.
Differential revision: https://reviews.llvm.org/D91209
The initial approach was to go with changing parser nodes from `std::list<parser::Name>` to `OmpObjectList`, but that might have lead to illegal programs.
Resolving the symbols inside `OmpAttributeVisitor`.
Fix a couple of `XFAIL` tests.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D90538
Add the semantic checks for the OpenMP 4.5 - 2.15.4.1 copyin clause.
Resolve OpenMPThreadprivate directive since the list of items specified
in copyin clause should be threadprivate.
Test cases : omp-copyin01.f90, omp-copyin02.f90, omp-copyin03.f90,
omp-copyin04.f90, omp-copyin05.f90
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D89385
Add explicit member initializers to the declarations of
some constexpr values added in a recent patch to avoid an
apparent problem with gcc 8.2.0 with default initializers.
Differential revision: https://reviews.llvm.org/D90696
`OmpStructureChecker` has too much boilerplate code in source file.
It was not easy to figure out the seperation of clauses inside 'OmpClause' and
the ones which had a seperate node in parse-tree.h.
This patch:
1. Removes the boilerplate by defining a few macros.
2. Makes seperation between constructs, directives and clauses(sub classes are seperated).
3. Macros could have been shared between OMP and OACC, template specilizations might have
been costly hence used macros.
Follows the same strategy used for `AccStructureChecker`.
Next patch in series to simplify OmpStructureChecker would try to simplify
boilerplates inside the functions and either create abstractions or use if
something is available inside check-directive-structure.h
Reviewed By: kiranchandramohan, clementval
Differential Revision: https://reviews.llvm.org/D90324
Ensure that character length is properly calculated for
actual arguments to intrinsics, and that source provenance
information is available when expression analysis calls
folding in cases where the length is invalid.
Differential revision: https://reviews.llvm.org/D90636
When the bounds of an implied DO loop in an array constructor are
constant, the index variable of that loop is considered a constant
expression and can be used as such in the items in the value list
of the implied DO loop. Since the KIND type parameter values of items
in the value list can depend on the various values taken by such an
index, it is not possible to represent those values with a single
typed expression. So implement such loops by taking multiple passes
over the parse tree of the implied DO loop instead.
Differential revision: https://reviews.llvm.org/D90494
This patch implements the first frontend action for the Flang parser (i.e.
Fortran::parser). This action runs the preprocessor and is invoked with the
`-E` flag. (i.e. `flang-new -E <input-file>). The generated output is printed
to either stdout or the output file (specified with `-` or `-o <output-file>`).
Note that currently there is no mechanism to map options for the
frontend driver (i.e. Fortran::frontend::FrontendOptions) to options for
the parser (i.e. Fortran::parser::Options). Instead,
Frotran::parser::options are hard-coded to:
```
std::vector<std::string> searchDirectories{"."s};
searchDirectories = searchDirectories;
isFixedForm = false;
_encoding(Fortran::parser::Encoding::UTF_8);
```
These default settings are compatible with the current Flang driver. Further
work is required in order for CompilerInvocation to read and map
clang::driver::options to Fortran::parser::options.
Co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com>
Differential Revision: https://reviews.llvm.org/D88381
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
Subclause 10.1.12 in F'2018 prohibits forward references from
a specification expression to an object declared later in the
same specification part. Catch this error better and emit
specific error messages about the violation.
Differential revision: https://reviews.llvm.org/D90492
Fortran's FINAL feature is sensitive to object rank.
When an object's rank excludes it from finalization, but
the type has FINAL subroutines for other ranks, emit
a warning. This should be especially helpful in the
case of a scalar FINAL subroutine not being declared
(IMPURE) ELEMENTAL.
Differential revision: https://reviews.llvm.org/D90495
READ(CVAR)[,item-list] with a character variable CVAR
could be parsed as an unformatted READ from an internal
unit or as a formatted READ from the default external unit
with a needlessly parenthesized variable format. We parse
it as the former, but Fortran doesn't have unformatted
internal I/O.
Differential revision: https://reviews.llvm.org/D90493
Some changes introduced in https://reviews.llvm.org/D88655 cause compiler
warnings. Since in Flang warnings are treated as errors (`-Werror` is on by
default), these are in practice compiler errors (verified with clang-10 and
clang-11, gcc-10). This patches fixes these warning/failures.
Warning/error 1:
```
llvm-project/flang/lib/Semantics/check-omp-structure.cpp:107:3: error:
unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
```
Warning/error 2:
```
llvm-project/flang/lib/Semantics/check-directive-structure.h:39:9: error: field
'currentDirective_' will be initialized after field 'upperCaseDirName_'
[-Werror,-Wreorder-ctor]
```
Failing buildbot:
* http://lab.llvm.org:8011/#/builders/33/builds/386
From below mentioned standard references
OpenACC 3.0 Standards document
840 • A program may not branch into or out of an OpenACC parallel construct
OpenMP 5.0 Standards document
A program that branches into or out of a parallel region is non-conforming.
This patch
Resolves the issue of exit out of a parallel region, other branching out issues like goto statements are not handled with this patch.
Moves code from D87906 to be reused by other OpenMP/OpenACC to check-directive-structure.h.
Adds support in OpenMP parallel construct and a test case to verify.
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D88655
Enter data can have the copyin clause and exit data can have the copyout clause.
Both clauses support modifier with other directive but for these two directives no modifier
are supported. This semantic check enforce this rule.
Reviewed By: kiranktp
Differential Revision: https://reviews.llvm.org/D90280
In the OpenACC specification, there are two different self clause. One for the
update directive with a var-list argument. This clause is a synonym of the host clause.
The second self clause is present for most of the compute construct and takes an optional
condition. To solve this ambiguity, the self clause for the update directive is directly
translated to a host clause during the parsing. The self clause in AccClause refers always
to the compute construct clause.
Reviewed By: kiranktp
Differential Revision: https://reviews.llvm.org/D90185
2 Bug fixes:
- Do not resolve procedure as intrinsic if they appeared in an
EXTERNAL attribute statement (one path was not considering this flag)
- Emit an error if a procedure resolved to be an intrinsic function
(resp. subroutine) is used as a subroutine (resp. function).
Lowering was attempted while the evaluate::Expression for the
call was missing without any errors.
1 behavior change:
- Do not implicitly resolve subroutines (resp. functions) as intrinsics
because their name is the name of an intrinsic function (resp.
subroutine). Add justification in documentation.
Reviewed By: klausler, tskeith
Differential Revision: https://reviews.llvm.org/D90049
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
The class IntrinsicProcTable uses the pimpl idiom and manages its own pointer-to-implementation. However, it violates the rule-of-five and does not implement a move-constructor or assignment-operator. Due to differences between compilers in implementation copy elision, these may or may not be used. Due to the missing user implementation for resource handling, using the results in runtime errors.
Fix my using `std::unique_ptr` instead of custom resource management.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D88794
Patch D88695 introduces a new local variable inside a lambda with the same name as a variable outside of it. In some of the if constexpr regions, msvc prioritizes the outer declaration and emits the error.
```
C:\Users\meinersbur\src\llvm-project\flang\lib\Evaluate\fold-implementation.h(1200): error C3493: 'context' cannot be implicitly captured because no default capture mode has been specified
```
This is fixed by giving the inner variable a different name.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D89367
Remove the assumption that the path separator is `/`. Use functions from `llvm::sys::path` instead.
Reviewed By: isuruf, klausler
Differential Revision: https://reviews.llvm.org/D89369
I added a test to verify that the associated symbol did not have errors before
doing the anaylsis of a call to a component ref along with a test that
triggers the original problem.
Differential Revision: https://reviews.llvm.org/D90074
wait and atomic directives are represented by OpenACCWaitConstruct, OpenACCAtmicConstruct in the parser. Those contrsuct were
not taken into account in the semantic check so far.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D88628
In my previous implementation of the semantic checks for ASSOCIATED(), I
had neglected to check the TARGET= argument for objects to ensure that
it has either the POINTER or TARGET attributes.
I added an implementation and a test.
Differential Revision: https://reviews.llvm.org/D89717
When processing declarations in resolve-names.cpp, we were returning a
symbol that had SubprogramName details to PushSubprogramScope(), which
expects a symbol with Subprogram details.
I adjusted the code and added a test.
Differential Revision: https://reviews.llvm.org/D89829
Check INTENT(OUT)/INTENT(INOUT) constraints for actual argument
of intrinsic procedure calls.
- Adding a common::Intent field to the IntrinsicDummyArgument
in the intrinsic table.
- Propagating it to the DummyDataObject intent field so that it can
later be used in CheckExplicitDataArg semantic checks.
- Add related tests.
- Fix regression (C846 false error), C846 INTENT(OUT) rule does
not apply to intrinsic call. Propagate the information that we
are in an intrinsic call up to CheckExplicitDataArg (that is
doing this check). Still enforce C846 on intrinsics other than MOVE_ALLOC (for which
allocatable coarrays are explicitly allowed) since it's not clear it is allowed in all
intrinsics and allowing this would lead to runtime penalties in the intrinsic runtime.
Differential Revision: https://reviews.llvm.org/D89473
Use the Todo.h header file introduce in D88909 to marke part of the lowering that are
not done yet.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D88915
From OpenACC 3.0 Standards document
840 • A program may not branch into or out of an OpenACC parallel construct.
Exits are allowed provided it does not cause an exit outside the parallel region.
Test case exits out of the inner do loop, but it is still inside the parallel region.
Patch tries to extract labels from block attached to a construct,
If the exit is to a label not in the collected list then flags an error.
Reviewed By: tskeith
Differential Revision: https://reviews.llvm.org/D87906
We had neglected to check for name mismatches for procedure definitions that
appear in interfaces.
I also changed label11.f90 to an error test since I think they're better than
"FileCheck" tests.
Differential Revision: https://reviews.llvm.org/D89611
Calling "ASSOCATED(NULL()) was causing an internal check of the compiler to
fail.
I fixed this by changing the entry for "ASSOCIATED" in the intrinsics table to
accept "AnyPointer" which contains a new "KindCode" of "pointerType". I also
changed the function "FromActual()" to return a typeless intrinsic when called
on a pointer, which duplicates its behavior for BOZ literals. This required
changing the analysis of procedure arguments. While testing processing for
procedure arguments, I found another bad call to `CHECK()` which I fixed.
I made several other changes:
-- I implemented constant folding for ASSOCIATED().
-- I fixed handling of NULL() in relational operations.
-- I implemented semantic analysis for ASSOCIATED().
-- I noticed that the semantics for ASSOCIATED() are similar to those for
pointer assignment. So I extracted the code that pointer assignment uses
for procedure pointer compatibility to a place where it could be used by
the semantic analysis for ASSOCIATED().
-- I couldn't figure out how to make the general semantic analysis for
procedure arguments work with ASSOCIATED()'s second argument, which can
be either a pointer or a target. So I stopped using normal semantic
analysis for arguments for ASSOCIATED().
-- I added tests for all of this.
Differential Revision: https://reviews.llvm.org/D88313
The call to the binary->decimal formatter in real.cpp was cheating
by using a reinterpret_cast<> to extract its binary value.
Use a more principled and portable approach by extending the
API of evaluate::Integer<> to include ToUInt<>()/ToSInt<>()
member function templates that do the "right" thing. Retain
ToUInt64()/ToSInt64() for compatibility.
Differential revision: https://reviews.llvm.org/D89435
As usual, it's difficult to handle all different configuration in the first row,
but this one has been extensively tested
Differential Revision: https://reviews.llvm.org/D89452
- Rework the host runtime table so that it is constexpr to avoid
having to construct it and to store/propagate it.
- Make the interface simpler (remove many templates and a file)
- Enable 16bits float folding using 32bits float host runtime
- Move StaticMultimapView into its own header to use it for host
folding
Reviewed By: klausler, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D88981
The OpenMP 5.0 standard restricts nowait clause to appear only once on sections
directive.
See OpenMP 5.0
- 2.8.1
- point 3 in restrictions.
Added a test with fix.
Reviewed By: DavidTruby
Differential Revision: https://reviews.llvm.org/D88556
`OmpStructureChecker` is supposed to work only with `parser::OmpClause`
after tablegen changes for OpenMP and OpenACC were introduced.
Hence `OmpMemoryOrderClause`, `OmpAtomicMemoryOrderClause` and similar ones were failing
to catch semantic errors, inspite of having code for semantic checks.
This patch tries to change parser for `OmpMemoryOrderClause` and similar dependent ones
and use `OmpClauseList` which resides/comes from common tablegen for OpenMP/OpenACC eventually using `parser::OmpClause`.
This patch also tries to :
1. Change `OmpCriticalDirective` in `openmp-parsers.cpp` to support `OmpClauseList`.
2. Check-flang regresses when changes were introduced due to missing semantic checks in OmpCritical, patch implements them at the minimal level to pass the regression.
3. Change tablegen to support Hint clause.
4. Adds missing source locations `CharBlock Source` in each atomic construct.
5. Remove dead code realted to `memory-order-clauses` after moving to `OmpClauseList`.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D88965
The semantics pass currently checks for several constraints
that apply to the use of whole assumed-size arrays in various
contexts, but C1002 wasn't really implemented. This patch
implements C1002 by disallowing the use of whole assumed-size
arrays in expressions and variables unless specifically
allowed by the context. This centralizes the error reporting,
which has been improved with a link to the array's declaration.
Differential revision: https://reviews.llvm.org/D88691
This patch fix the device_num and device_type clauses used in the init clause. device_num was not
spelled correctly in the parser and was to restrictive with scalarIntConstantExpr instead of scalarIntExpr.
device_type is now taking a list of ScalarIntExpr.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D88571
CHARACTER length expressions were not always being
captured or computed as part of procedure "characteristics",
leading to test failures due to an inability to compute
memory size expressions accurately.
Differential revision: https://reviews.llvm.org/D88689
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
This patch fixes one worning. Since Flang sets `-Werror`, that's
sufficient for a build to fail. As per flang/README.md, Clang-10 is one
of the officially supported compilers.
Differential Revision: https://reviews.llvm.org/D88723
A recent MSVC work-around patch is eliciting unused variable
warnings from clang; package the lambda reference arguments
into a struct to avoid the warning.
Differential revision: https://reviews.llvm.org/D88695
Tweak binary->decimal conversions to avoid an integer multiplication
in a hot loop to improve readability and get a minor (~5%) speed-up.
Use native integer division by constants for more readability, too,
since current build compilers seem to optimize it correctly now.
Delete the now needless temporary work-around facility in
Common/unsigned-const-division.h.
Differential revision: https://reviews.llvm.org/D88604
This resolves an issue where the Microsoft compiler 'forgets' symbols when using constexpr in a lambda in a templated function. The symbols are:
1. The implicit lambda captures `context` and `convert`. Fix by making them explicit captures. The error message was:
```
fold-implementation.h(1220): error C2065: 'convert': undeclared identifier
```
2. The function template argument FROMCAT. Fix by storing it in a temporary constexpr variable inside the function. The error message was:
```
fold-implementation.h(1216): error C2065: 'FROMCAT': undeclared identifier
```
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/D88504
Msvc reports the following error when a ReferenceVariantBase is constructed using an r-value reference or instantiated as std::vector template parameter. The error message is:
```
PFTBuilder.h(59,1): error C2665: 'std::variant<...>::variant': none of the 2 overloads could convert all the argument types
variant(1248,1): message : could be 'std::variant<...>::variant(std::variant<...> &&) noexcept(false)'
variant(1248,1): message : or 'std::variant<...>::variant(const std::variant<...> &) noexcept(false)'
PFTBuilder.h(59,1): message : while trying to match the argument list '(common::Reference<lower::pft::ReferenceVariantBase<false,...>>)'
```
Work around the ambiguity by only taking `common::Reference` arguments in the constructor. That is, conversion to common::Reference has to be done be the caller instead of being done inside the ctor. Unfortunately, with this change clang/gcc (but not msvc) insist on that the ReferenceVariantBase is stored in a `std::initializer_list`-initialized variable before being used, like being passed to a function or returned.
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/D88109
Represent FINAL subroutines in the symbol table entries of
derived types. Enforce constraints. Update tests that have
inadvertent violations or modified messages. Added a test.
The specific procedure distinguishability checking code for generics
was used to enforce distinguishability of FINAL procedures.
(Also cleaned up some confusion and redundancy noticed in the
type compatibility infrastructure while digging into that area.)
Differential revision: https://reviews.llvm.org/D88613
SAVE statement, according to 8.6.14, must apply to the same scoping
unit, that excludes nested scoping units. For example, if the SAVE
statement is found in a MODULE, the functions contained in that module
should not inherit the SAVE attribute. I think that the code was doing
this, failing the following source:
```
MODULE pippo
SAVE
CONTAINS
PURE FUNCTION fft_stick_index( )
IMPLICIT NONE
INTEGER :: fft_stick_index
INTEGER :: mc !error: A pure subprogram may not have a variable with the SAVE attribute
END FUNCTION
END MODULE
```
Differential Revision: https://reviews.llvm.org/D88279
After skeleton of the `Parallel Op` is created set the insertion point to start of the block. So that later `CodeGen` can proceed.
Note: This patch reflects the work that can be upstreamed from PR(merged)
PR: https://github.com/flang-compiler/f18-llvm-project/pull/424
Reviewed By: schweitz, kiranchandramohan
Differential Revision: https://reviews.llvm.org/D88221
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
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
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
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
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
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
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
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
Don't use just 128-bit integer as the type for integer
CASE statement constants. Use the actual type of the
literal constants that appeared.
Differential Review: https://reviews.llvm.org/D86875
Conformance checking of the shapes of the operands of
array expressions can't, of course, always be done at
compilation time; but when the shapes are known and
nonconformable, we should catch the errors that we can.
Differential Revision: https://reviews.llvm.org/D86887
Change the expression representation TypeParamInquiry from being
a class that's templatized on the integer KIND of its result into
a monomorphic representation that results in a SubscriptInteger
that can then be converted.
This is a minor simplification, but it's worth doing because
it is believed to also be a work-around for bugs in the MSVC
compiler with overload resolution that affect the expression
traversal framework.
Differential Revision: https://reviews.llvm.org/D86551
Compilation of the following program currently generates a warning message:
i = 1
if (i .eq. 0) then
write(6, 200) i
200 format (I8)
end if
write(6, 200) i
end
x.f90:6:9: Label '200' is not in scope
write(6, 200) i
^^^^^^^^^^^^^^^
Whereas branch targets must conform to the Clause 11.1.2.1 program
requirement "Transfer of control to the interior of a block from
outside the block is prohibited, ...", this doesn't apply to format
statement references.
When an error is associated with a symbol, it was marked with a flag
from Symbol::Flag. The problem with that is that you need a mutable
symbol to do that. Instead, store the set of error symbols in the
SemanticsContext. This allows for some const_casts to be eliminated.
Also, improve the internal error that occurs if SetError is called
but no fatal error has been reported.
Differential Revision: https://reviews.llvm.org/D86740
This patch fix the prasing for the gang-arg values for the gang clause. It also adds
some clause validity tests for the loop construct.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D86584
The tile clause in OpenACC 3.0 imposes some restriction. Element in the tile size list are either * or a
constant positive integer expression. If there are n tile sizes in the list, the loop construct must be immediately
followed by n tightly-nested loops.
This patch implement these restrictions and add some tests.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D86655
A number of I/O syntax rules involve variables that will be written to,
and must therefore be definable. This includes internal file variables,
IOSTAT= and IOMSG= specifiers, most INQUIRE statement specifiers, a few
other specifiers, and input variables. This patch checks for
these violations, and implements several additional I/O TODO constraint
checks.
Differential Revision: https://reviews.llvm.org/D86557
When an illegal character appears in Fortran source (after
preprocessing), catch and report it in the prescanning phase
rather than leaving it for the parser to cope with.
Differential Revision: https://reviews.llvm.org/D86553
Accept and represent "global" compiler directives that appear
before and between program units in a source file.
Differential Revision: https://reviews.llvm.org/D86555
If the label field is empty, and macro replacement occurs,
the rescanned text might be misclassified as a comment card
if it happens to begin with a C or a D. Insert a leading
space into these otherwise empty label fields.
Fixes https://bugs.llvm.org/show_bug.cgi?id=47173
If an error has occurred a symbol may have a DeclTypeSpec but no
valid DynamicType. There is no need to compute the size of erroneous
symbols.
Also, we only need to process object entities and procedure entities.
All other kinds of symbols can be skipped.
This fixes another problem revealed by https://bugs.llvm.org/show_bug.cgi?id=47265
Differential Revision: https://reviews.llvm.org/D86484
A specification expression can reference an implicitly declared variable
in the host procedure. Because we have to process specification parts
before execution parts, this may be the first time we encounter the
variable. We were assuming the variable was implicitly declared in the
scope where it was encountered, leading to an error because local
variables may not be referenced in specification expressions.
The fix is to tentatively create the implicit variable in the host
procedure because that is the only way the specification expression can
be valid. We mark it with the flag `ImplicitOrError` to indicate that
either it must be implicitly defined in the host (by being mentioned in
the execution part) or else its use turned out to be an error.
We need to apply the implicit type rules of the host, which requires
some changes to implicit typing.
Variables in common blocks are allowed to appear in specification expressions
(because they are not locals) but the common block definition may not appear
until after their use. To handle this we create common block symbols and object
entities for each common block object during the `PreSpecificationConstruct`
pass. This allows us to remove the corresponding code in the main visitor and
`commonBlockInfo_.curr`. The change in order of processing causes some
different error messages to be emitted.
Some cleanup is included with this change:
- In `ExpressionAnalyzer`, if an unresolved name is encountered but
no error has been reported, emit an internal error.
- Change `ImplicitRulesVisitor` to hide the `ImplicitRules` object
that implements it. Change the interface to pass in names rather
than having to get the first character of the name.
- Change `DeclareObjectEntity` to have the `attrs` argument default
to an empty set; that is the typical case.
- In `Pre(parser::SpecificationPart)` use "structured bindings" to
give names to the pieces that make up a specification-part.
- Enhance `parser::Unwrap` to unwrap `Statement` and `UnlabeledStatement`
and make use of that in PreSpecificationConstruct.
Differential Revision: https://reviews.llvm.org/D86322
This patch fix the usage of the wait-argument in a clause and add several tests and fix the unparsing of
the wait-argument.
Reviewed By: sscalpone
Differential Revision: https://reviews.llvm.org/D86325
Msvc has trouble defining a struct/class and defining a constexpr symbol in the same declarator. It reports the following error:
```
basic-parsers.h(809): error C2131: expression did not evaluate to a constant
basic-parsers.h(809): note: failure was caused by call of undefined function or one not declared 'constexpr'
basic-parsers.h(809): note: see usage of 'Fortran::parser::OkParser::OkParser'
```
Fix the msvc compilation by splitting the two definitions into two separate declarators.
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: DavidTruby, klausler
Differential Revision: https://reviews.llvm.org/D85937
When we report an error for a bad character kind, don't keep it in the
`DeclTypeSpec`. Otherwise there could be further problems. In this case,
`ComputeOffsets()` got an assertion error because we didn't recognize
`CHARACTER(*,8)` as needing a descriptor because of the bad kind.
Fixes https://bugs.llvm.org/show_bug.cgi?id=47173
Differential Revision: https://reviews.llvm.org/D86357
This greatly simplifies a large portion of the underlying infrastructure, allows for lookups of singleton classes to be much more efficient and always thread-safe(no locking). As a result of this, the dialect symbol registry has been removed as it is no longer necessary.
For users broken by this change, an alert was sent out(https://llvm.discourse.group/t/removing-kinds-from-attributes-and-types) that helps prevent a majority of the breakage surface area. All that should be necessary, if the advice in that alert was followed, is removing the kind passed to the ::get methods.
Differential Revision: https://reviews.llvm.org/D86121
When a procedure name was used on the RHS of an assignment we were not
reporting the error. When one was used in an expression the error
message wasn't very good (e.g. "Operands of + must be numeric; have
INTEGER(4) and untyped").
Detect these cases in ArgumentAnalyzer and emit better messages,
depending on whether the named procedure is a function or subroutine.
Procedure names may appear as actual arguments to function and
subroutine calls so don't report errors in those cases. That is the same
case where assumed type arguments are allowed, so rename `isAssumedType_`
to `isProcedureCall_` and use that to decide if it is an error.
Differential Revision: https://reviews.llvm.org/D86107
Use the TableGen directive back-end to generate code for the clauses unparsing.
Reviewed By: sscalpone, kiranchandramohan
Differential Revision: https://reviews.llvm.org/D85851
As with use-associated symbols, copy the attributes and flags from the
original symbol onto host-associated symbols when they are created.
This was showing up as an error on a deallocate of a host-associated
name. We reported an error because the symbol didn't have the POINTER
or ALLOCATABLE attribute.
Differential Revision: https://reviews.llvm.org/D85763
OpenACC combined construct can have an optional end directive. This patch handle this
case in the parsing/unparsing with a canonicalization step. Unlike OmpEndLoopDirective,
this doesn't need a special treatment in the pre-fir tree as there is no clause attached to
a AccEndCombinedDirective.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D84481
The shape (esp. the size) of the result of a call to TRANSFER
is implemented according to the definition in the standard.
Differential Revision: https://reviews.llvm.org/D85866
Character literal substrings used as arguments were causing asserts. This
happened when the code was trying to get the DynamicType of the substring. We
were only recording the DynamicType of the Designator on which the substring
was based. For character literal substrings, the Designator was a character
literal, and we weren't handling getting its type.
I fixed this by changing the `GetType()` method for `DynamicType` to check to
see if we were getting the type of a `Substring` and calculating the type of
the substring by getting the number of bytes in an element of the string.
I also changed the test `resolve49.f90` with some tests, one of which causes
the original crash.
Differential Revision: https://reviews.llvm.org/D85908
If an unrestricted specific intrinsic function name is first encountered
as an actual argument, it should be interpreted as an object entity,
not a procedure entity.
Fix some tests that depended on the previous interpretation by adding
explicit INTRINSIC statements.
Differential Revision: https://reviews.llvm.org/D85792
Allow compiler directives in the implicit-part and before USE statements
in the specification-part.
Differential Revision: https://reviews.llvm.org/D85693
This patch takes advantage of the directive information and tablegen generation
to replace the clauses class parse tree and in the dump parse tree sections.
Reviewed By: sscalpone
Differential Revision: https://reviews.llvm.org/D85549
This patch takes advantage of the directive information and tablegen generation
to replace the clauses class parse tree and in the dump parse tree sections.
Reviewed By: sscalpone
Differential Revision: https://reviews.llvm.org/D85549
If a bound of a subscript triplet is present but fails to analyze
due to an error, return nullopt rather than returning a Triplet with
that bound missing. This is so we can distinguish an absent bound from
an erroneous one and avoid spurious errors.
Differential Revision: https://reviews.llvm.org/D85672
To prevent mistokenization of CHARACTER*2HXY as a Hollerith
literal constant while allowing it in DATA A/2*2HXY/, there's
a little state that tracks whether a / has been seen earlier
in the same statement. But it was being reset on each line,
not statement, so Hollerith in a DATA statement continuation
line was incorrectly tokenized. Fixed.
Differential Revision: https://reviews.llvm.org/D85571
Objects that are storage associated by EQUIVALENCE and
initialized with DATA are initialized by creating a
compiler temporary data object in the same scope,
assigning it an offset, type, and size that covers the
transitive closure of the associated initialized original
symbols, and combining their initializers into one common
initializer for the temporary.
Some problems with offset assignment of EQUIVALENCE'd objects
in COMMON were exposed and corrected, and some more error
cases are checked.
Remove obsolete function.
Small bugfix (nested implied dos).
Add a test.
Fix struct/class warning.
Differential Revision: https://reviews.llvm.org/D85560
In the example below we were producing the error message
"Assignment to constant 'f' is not allowed":
```
function f() result(r)
f = 1.0
end
```
This changes it to a more helpful message when the LHS is a subprogram
name and also mentions the function result name when it's a function.
Differential Revision: https://reviews.llvm.org/D85483
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
Clang 9 gets the following warning after revision `D85104`.
```
../../flang/lib/Semantics/check-directive-structure.h:36:7: error: 'Fortran::semantics::DirectiveStructureChecker<llvm::omp::Directive, llvm::omp::Clause, Fortran::parser::OmpClause, 77>' has virtual functions but non-virtual destructor [-Werror,-Wnon-virtual-dtor]
```
The fix is the make the destructor virtual. Neither it nor the
constructor need to be public, so make them protected.
Differential Revision: https://reviews.llvm.org/D85383
This patch remove duplicated code between the check-omp-structure and the check-acc-structure
and unify it into a check-directive-structure templated class.
Reviewed By: kiranchandramohan, sscalpone, ichoyjx
Differential Revision: https://reviews.llvm.org/D85104
- Moved TypeRange into its own header/cpp file, and add hashing support.
- Change FunctionType::get() and TupleType::get() to use TypeRange
Differential Revision: https://reviews.llvm.org/D85075
This patch lower `!OMP PARALLEL` construct from PFT to OpenMPDialect operations.
This is first patch in this direction(lowering parallel construct).
OpenMP parallel construct can have multiple clauses and parameters. This patch
only implements lowering of an empty(contains no code in body) parallel construct
without any clauses or parameters.
Patch is carved out of following approved PR:
https://github.com/flang-compiler/f18-llvm-project/pull/322
Reviewed By: kiranchandramohan, DavidTruby
Differential Revision: https://reviews.llvm.org/D84965
1. Annotate the sources with constraint numbers.
2. Add tests for
*C7107 (R765) digit shall have one of the values 0 or 1.
*C7108 (R766) digit shall have one of the values 0 through 7.
*C7109 (R764) A boz-literal-constant shall appear only as a data-stmt-constant in a DATA statement, or where explicitly allowed in 16.9 as an actual argument of an intrinsic procedure.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D84504
CMPLX folding was expecting only one arguments in case X argument
is complex. This is wrong since there is also the optional KIND
argument.
Reviewed By: schweitz
Differential Revision: https://reviews.llvm.org/D84936
I fixed an assert caused by passing an empty array as the source= argument to
RESHAPE(). In the process, I noticed that there were no tests for RESHAPE(),
so I wrote a test that covers all the description in 16.9.163. In the process,
I made the error messages more consistent and descriptive. I also changed the
test to see if a reference to an intrinsic function was a constant to say that
it is a constant if it's a refererence to an invalid intrinsic. This avoids
emitting multiple messages for the same erroneous source.
Differential Revision: https://reviews.llvm.org/D84904
When declaring the same variable twice with an initialization, we were failing
an internal check. I fixed this by checking to see if the associated symbol
already had an error.
I added tests for pointer and non-pointer initialization of duplicate names.
Differential Revision: https://reviews.llvm.org/D84969
To make it easier for lowering to identify which symbols from the host
are captured by internal subprograms, create HostAssocDetails for them.
In particular, if a symbol is referenced and it is contained in a
subprogram or main program that is not the same as the containing
program unit of the reference, a HostAssocDetails symbol is created
in the current scope.
Differential Revision: https://reviews.llvm.org/D84889
The intrinsic lowering facility is based on the generic intrinsic names to avoid
duplicating implementations. Specific intrinsics call are re-written to call to
the generic versions by the front-end but this cannot be done when specific intrinsics
are passed as arguments (the rewrite would give illegal/ambiguous unparsed Fortran).
Solve the issue by making the specific to generic name mapping accessible to lowering
and can be later used to generate the unrestricted intrinsic functions.
Reviewed By: schweitz
Differential Revision: https://reviews.llvm.org/D84842
When an instrinsic function is declared in a type declaration statement
we need to set the INTRINSIC attribute and (per 8.2(3)) ignore the
specified type.
To simplify the check, add IsIntrinsic utility to BaseVisitor.
Also, intrinsics and external procedures were getting assigned a size
and offset and they shouldn't be.
Differential Revision: https://reviews.llvm.org/D84702
Move `ResolveAccParts` and `ResolveOmpParts` from resolve-names.cpp to
resolve-directives.{h,cpp}. Move the implementation in the classes
`DirectiveAttributeVisitor`, `AccAttributeVisitor`, and
`OmpAttributeVisitor` to resolve-directives.cpp as well.
To allow this to happen, move `EvaluateIntExpr` and introduce
`EvaluateInt64` to resolve-names-utils.h. The latter is also useful
elsewhere in resolve-names.cpp for converting an Expr to std::int64_t.
The other problem was that `ResolveDesignator` was called from the code
that was moved. At the moment it doesn't seem to be doing anything so I
removed the calls (and no tests failed). If it proves to be needed, we
can either resolve those designators in resolve-names.cpp or pass the
`ResolveDesignator` function in to the code that needs to call it.
Differential Revision: https://reviews.llvm.org/D84768
If a symbol (that is not a dummy argument) is implicitly declared inside
a statement function, don't create it in the statement function's scope.
Instead, treat statement functions like blocks when finding the inclusive
scope and create the symbol there.
Add a new flag, StmtFunction, to symbols that represent statement functions.
Differential Revision: https://reviews.llvm.org/D84588
The result of a statement function may require an implicit conversion
to match its result type. Add that to the expression that represents
the statement function body in SubprogramDetails.
Extract the analysis of that expression into a separate function.
Dump the statement function expression as part of the dump of
SubprogramDetails.
Differential Revision: https://reviews.llvm.org/D84452
Summary:
Expressions like `iVar==z'fe'` were causing an assertion error because
the `Relate()` function in `Evaluate/tools.cpp` that processes
relational operators didn't deal with BOZ literals, which are typeless.
I fixed this by checking to see if the operands are BOZ literals. If
so, if the other operand is REAL, I convert them to REAL. Otherwise, I convert
them to integers with default kind.
I also added a test to resolve63.f90 that triggers the problem.
Reviewers: tskeith, DavidTruby
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83917
Summary:
This patch fix a problem where clause needed to be in the allowed set even
they were in the required set. A required clause is allowed obvisouly. This allow
to remove the duplicate in OMP.td
Reviewers: kiranchandramohan, DavidTruby, richard.barton.arm, jdoerfert, sscalpone, kiranktp, ichoyjx
Reviewed By: kiranchandramohan
Subscribers: yaxunl, guansong, sstefan1, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D84353
Summary:
When a constant array of empty strings goes through contant folding, the result
is something that contains no bytes. If this array is passed to the intrinsic
function `RESHAPE()`, we were not handling things correctly. I fixed this by
checking for an empty destination when calling the function `CopyFrom()` on an
array of strings.
I also added a test with a couple of different examples that trigger the
problem.
Reviewers: klausler, tskeith, DavidTruby
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D84352
The prescanner looks for implicit continuation lines when
there are unclosed parentheses at the end of a line, so that
source preprocessing macro references with arguments that span
lines are recognized. The condition that determines this
implicit continuation has been put into a predicate member
function and corrected to apply only when the following line
is source (not a preprocessing directive, comment, &c.).
Fixes bugzilla #46768.
Reviewed By: sscalpone
Differential Revision: https://reviews.llvm.org/D84280
In fixed form source, complain when a label digit appears
outside the label field & when a non-digit appears in the label
field.
Reviewed By: sscalpone
Differential Revision: https://reviews.llvm.org/D84283
Accept name=value as part of a !DIR$ compiler directive. These
are currently ignored in semantics, but we should recognize
more directive forms to facilitate testing. In due course,
these placeholding directive parsers will be replaced.
Reviewed By: sscalpone
Differential Revision: https://reviews.llvm.org/D84077
Old-style C /*comments*/ are omitted from preprocessor directive
token sequences by the prescanner, but line-ending C++ and Fortran
free-form comments are not since their handling might depend on
the directive. Add code to skip these line-ending comments as
appropriate in place of existing code that just skipped blanks.
Reviewed By: sscalpone
Differential Revision: https://reviews.llvm.org/D84061
Summary:
These link dependencies are required for shared library builds to
work correctly.
Reviewers: clementval
Reviewed By: clementval
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83938
Summary:
This adds missing definitions for functions in the Lower directory
that were causing failures in shared library builds.
The definitions for these are taken from the fir-dev branch on github.
Reviewers: sscalpone, schweitz, jeanPerier, klausler
Reviewed By: schweitz
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83771
When an intrinsic is referenced in a module scope, a symbol for it is
added. When that module is USEd, the intrinsic should not be included.
Otherwise we can get ambiguous reference errors with the same intrinsic
coming from two difference modules.
Differential Revision: https://reviews.llvm.org/D83905
A SAVE statement with no entity list applies the SAVE attribute only to
the entities that it is allowed on. We were applying it to automatic
data objects and reporting an error that they can't have SAVE.
The fix is to change `DeclarationVisitor::CheckSaveAttr` to check for
automatic objects. That controls both checking and setting the
attribute. This allows us to remove the check from `CheckSpecExpr`
(along with `symbolBeingChecked_`). Also, it was only called on constant
objects so the non-const overload can be eliminated.
The check in `CheckSpecExpr` is replaced by an explicit check for
automatic objects in modules. This caught an error in modfile03.f90 so
that part of the test was eliminated.
Differential Revision: https://reviews.llvm.org/D83899
Summary:
C7113 States that "An ac-value shall not be unlimited polymorphic." We failed
to detect this situation which resulted in a crash when trying to get the
underlying derived type specification of the unlimited polymorphic value.
I added code to avoid the crash, code to emit an error message, and a test.
Reviewers: klausler, tskeith, DavidTruby
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83793
We need to retain carriage return characters in source files
that are not parts of multi-byte line endings; they are
significant in CHARACTER literal constants.
Reviewed By: tskeith
Differential Revision: https://reviews.llvm.org/D83808
Use short division of big-radix values by powers of two when
converting values with negative unbiased exponents rather than
multiplication by smaller powers of five; this reduces the overall
outer iteration count. This change is a win across the entire range
of inputs.
Reviewed By: tskeith
Differential Revision: https://reviews.llvm.org/D83806
Character literals can be formatted using octal or hex escapes for
non-ascii characters. This is so that the program can be unparsed for
either pgf90 or gfortran to compile. But modfiles should not be affected
by that -- they should be consistent.
This changes causes modfiles to always have character literals formatted
with octal escapes.
Differential Revision: https://reviews.llvm.org/D83703
Summary:
This patch is enabling the generation of clauses enum sets for semantics check in Flang through
tablegen. Enum sets and directive - sets map is generated by the new tablegen infrsatructure for OpenMP
and other directive languages.
The semantic checks for OpenMP are modified to use this newly generated map.
Reviewers: DavidTruby, sscalpone, kiranchandramohan, ichoyjx, jdoerfert
Reviewed By: DavidTruby, ichoyjx
Subscribers: mgorny, yaxunl, hiraditya, guansong, sstefan1, aaron.ballman, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83326
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:
When a program unit creates a generic based on one defined in a module, the
function `CopyFrom()` is called to create the `GenericDetails`. This function
copied the `specificProcs_` but failed to copy the `bindingNames_`. If the
function `CheckGeneric()` then gets called, it tries to index into the empty
binding names and causes the crash.
I fixed this by adding code to `CopyFrom()` to copy the binding names.
I also added a test that causes the crash.
Reviewers: klausler, tskeith, DavidTruby
Subscribers: llvm-commits
Tags: #llvm, #flang
Differential Revision: https://reviews.llvm.org/D83491
Summary:
When there are errors in the evaluation of every cosubscript expression in a
coindexed object, the compiler would crash. I fixed this by just checking to
see if there were errors in the evaluation of the cosubscripts before
constructing the `DataRef` for the coindexed object.
Reviewers: klausler, tskeith, DavidTruby
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83410
This module implements the lowering of Fortran intrinsics to the
corresponding calls in support libraries (the Fortran runtime, math
libraries, etc.)
This revision is a tad larger because there are a large number of Fortran
intrinsics and this adds lowering for a fair number of them.
Differential revision: https://reviews.llvm.org/D83355
Summary:
This change implements support for image selectors and image selector
specifications as described in section 9.6.
In check-coarray[.h,cpp] I changed the `Leave()` function for
`parser::ImageSelectorSpec` to take a `parser::ImageSelector`, which
contains a list of image selector specifications. This allows us to
detect when the same specification is used more than once. I also added
code to analyze the expressions for the image selector specifications to
expression.cpp and a test for all of the conditions to check at
compile-time.
Note that we do not check at compile-time to see if the value of the
cosubscripts are within the specified cobounds. We also do not check anything
related to selecting a valid team. We also do not check that the denotation of
the `stat-variable` is not dependent on the evaluation of an entity in the
same statement.
Reviewers: klausler, tskeith, DavidTruby
Subscribers: llvm-commits
Tags: #llvm, #flang
Differential Revision: https://reviews.llvm.org/D83336
Do not rewrite LEN(x) or x%len to the expression that specifies
the length of x when that length is not a constant expression.
Its value may have changed since the value of the expression was
first captured in the definition of the object.
Reviewed By: tskeith, sscalpone
Differential Revision: https://reviews.llvm.org/D83352
I added 'num_images()' to the list of functions that are evaluated as intrinsic. I also added a test file in flang/test/Semantics to test calls to 'num_images()'. There was a call to 'num_images()' in flang/test/Semantics/call10.f90 that expected an error, now it no longer produces an error. So I edited that file accordingly. I also edited the intrinsics unit test to add further testing of 'num_images()'.
Differential Revision: https://reviews.llvm.org/D83142
Summary:
This patch enhances parser support for flush construct to OpenMP 5.0 by including memory-order-clause.
2.18.8 flush Construct
!$omp flush [memory-order-clause] [(list)]
where memory-order-clause is
acq_rel
release
acquire
The patch includes code changes and testcase modifications.
Reviewed By: klausler, kiranchandramohan
Differential Revision: https://reviews.llvm.org/D82177
Summary:
A program may erroneously reference the same name as both a data object
and as a function. Some of these references were causing an internal
error in expression analysis.
It was already the case that a symbol referenced in a parse tree for a
call was changed from an `Entity` to a `ProcEntity`. I added code to
detect when a symbol was referenced in a parse tree as an array element
gets changed from an `Entity` to an `ObjectEntity`. Then, if an
`ObjectEntity` gets called as a function or a `ProcEntity` gets
referenced as a data object, errors get emitted.
This analysis was previously confined to the name resolution of the
specification part of a `ProgramTree`. I added a pass to the execution
part of a `ProgramTree` to catch names declared in blocks.
Reviewers: tskeith, klausler, DavidTruby
Subscribers: llvm-commits
Tags: #llvm, #flang
Differential Revision: https://reviews.llvm.org/D82903
The FIR builder is a helper class that manages the creation of MLIR
operations from the bridge. The focus of the builder is the creation of
Operations, Types, etc.
Differential revision: htps://reviews.llvm.org/D83107
This change prepares usage of lipgmath description in lowering.
- Removes the static variable templates that were used to abstract
libpgmath description
- Move the description to pgmath.h.inc header and rework the macros
so that they can both be used to declare pgmath functions and use
them.
The way they are to be used is left to pgmath.h.inc user that
must define PGMATH_USE_XX macros that will be called for all pgmath
functions in pgmath.h.inc.
- In intrinsic-library.cpp define PGMATH_USE_XX macro callbacks in
order to capture function pointers to pgmath functions as well as
a description of their type. This will be used for constant folding
using pgmath.
- Change atan/atan2 handling to use atan2 instead of atan when there are two
arguments because it is easier to handle in the runtime description.
Also fixes lipgmath linking regression after D78215 cmake changes.
This change is motivated by the need to use a similar pgmath
description in lowering. The difference is that no function pointers will
be taken there, and instead only the function name and type are needed.
Reviewed By: schweitz, sscalpone
Differential Revision: https://reviews.llvm.org/D83051
There were dependences upon LLVM libraries in the Fortran
runtime support library binaries due to some indirect #includes
of llvm/Support/raw_ostream.h, which caused some kind of internal
ABI version consistency checking to get pulled in. Fixed by
cleaning up some includes.
Reviewed By: tskeith, PeteSteinfeld, sscalpone
Differential Revision: https://reviews.llvm.org/D83060
The arguments have been moved out of the analyzer so we can't get the
expected number there. Instead use the argument count from the newly
built callee.
Differential Revision: https://reviews.llvm.org/D83063
This adds a minimalist inliner implementation. Along with the inliner, a
minimum number of support files are also included. These will pave the
way for future diffs to add more transformation passes to flang. A
future diff will add the inline test, which cannot be run successfully
quite yet as some components have not yet been upstreamed.
Differential revision:
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
Add `hasAlternateReturns` to `evaluate::ProcedureRef`.
Add `HasAlternateReturns` to test subprogram symbols.
Fix `label01.F90` test: It was checking that "error: " didn't appear in
the output. But that was erroneously matching a warning that ends
"would be in error:". So change it to check for ": error: " instead.
Differential Revision: https://reviews.llvm.org/D83007
flang/module only contains Fortran files and one is a .h so disable
formatting on that directory.
Differential Revision: https://reviews.llvm.org/D82989
Implement cross-set EQUIVALENCE impossibility checking; fixes
an infinite loop on an erroneous test. Also fix substring
reference offset calculations in EQUIVALENCE discovered to
be incorrect during testing.
Reviewed By: tskeith
Differential Revision: https://reviews.llvm.org/D82993
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
Expression analysis was being invoked on the bodies of statement functions
as they were being encountered during name resolution. This led to failures
on some FCVS tests in cases where those expressions contained implicitly
typed objects. Defer the analysis of statemet function bodies to the end
of the specification part, at which time the symbols of the enclosing scope
will have been typed.
Reviewed By: tskeith
Differential Revision: https://reviews.llvm.org/D82796
Fixed-form line continuation was not working when the
preceding line was a bare label.
Reviewed By: tskeith
Differential Revision: https://reviews.llvm.org/D82687
In order for these files to build properly, this patch rolls up a number of changes that have been made to various files that have been upstreamed.
Implementations for the interfaces included in Bridge.h and IntrinsicCall.h will be included in a future diff.
Differential revision: https://reviews.llvm.org/D82608
This is a set of type building models that is specific to the lowering
process. It provides the mechanism of mapping C(++) header file interfaces
to the MLIR+FIR type system.
It also provides some macros to build a constexpr evaluated table to
runtime functions. This code is used to build the interface tables to
various runtime support libraries.
Differential revision: https://reviews.llvm.org/D82387
Treat function result like dummy argument: a SAVE statement without an
entity-list does not make it saved.
Differential Revision: https://reviews.llvm.org/D82309
Implement shape analysis for the result of the MATMUL
generic transformational intrinsic function, based on
the shapes of its arguments. Correct the names of the
arguments to match the standard, too.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D82250
The bridge uses internal boxes of related ssa-values to track all the
information associated with a Fortran variable. Variables may have a
location and a value, but may also carry other properties such as rank,
shape, LEN parameters, etc. in Fortran.
Differential revision: https://reviews.llvm.org/D82228
Summary:
This patch enhances parser support for flush construct to OpenMP 5.0 by including memory-order-clause.
2.18.8 flush Construct
!$omp flush [memory-order-clause] [(list)]
where memory-order-clause is
acq_rel
release
acquire
The patch includes code changes and testcase modifications.
Reviewed By: klausler, kiranchandramohan
Differential Revision: https://reviews.llvm.org/D82177
Implement rest of DATA statement semantics and conversion of
DATA statement initializations into static initializers of
objects in their symbol table entries.
Reviewed By: tskeith, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D82207
The symbol map is a data structure for tracking variables in a subprogram during the lowering of that subprogram to FIR/MLIR. These data structures will be used by the bridge, which has not been upstreamed yet.
Differential revision: https://reviews.llvm.org/D82140
Rolls up small changes across the frontend to prepare for the large
forthcoming patch (part 4/4) that completes DATA statement processing
via conversion to initializers.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D82137
Summary:
Defines a representation for the initialized memory image of
a variable. This image is populated by DATA statement
processing as designator elements are put into correspondence
with values, then converted into an initializer in the symbol
table so that lowering can pass the initial image to the
code generator.
Reviewers: tskeith, PeteSteinfeld, sscalpone, jdoerfert, DavidTruby
Reviewed By: tskeith
Subscribers: mgorny, llvm-commits, flang-commits
Tags: #flang, #llvm
Differential Revision: https://reviews.llvm.org/D82131
Summary:
Add code to resolve constant Designators at compilation time
into a base Symbol, byte offset, and field size. This is used in
later DATA statement processing to identify the static storage being
initialized by each object in a DATA statement. Also implement
the reverse mapping so that Designators can be reconstructed for
use in error messages about (e.g.) duplicate initializers.
Reviewers: tskeith, PeteSteinfeld, sscalpone, jdoerfert, DavidTruby
Reviewed By: PeteSteinfeld
Subscribers: mgorny, llvm-commits, flang-commits
Tags: #flang, #llvm
Differential Revision: https://reviews.llvm.org/D82125
Summary:
We weren't handling the case of subroutines with alternate returns that
are contained in modules. I changed the code to add an `*` as the name
of the parameter when creating the `.mod` file.
Reviewers: tskeith, klausler, DavidTruby
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D82096
Summary:
This patch changes speficic extremum functions rewrite to generic MIN/MAX.
It applies to AMAX0, AMIN0, AMAX1, AMIN1, MAX0, MIN0, MAX1, MIN1, DMAX1,
and DMIN1.
- Do not re-write specific extremums to MAX/MIN in intrinsic Probe and let
folding rewrite it and introduc the conversion on the MIN/MAX result.
- Also make operand promotion explicit in MIN/MAX folding.
For instance, after this patch:
AMAX0(int8, int4) is rewritten to REAL(MAX(int8, INT(int4, 8)))
All this care is to avoid rewritting it to MAX(REAL(int8), REAL(int4))
that may not always be numerically equivalent to the first rewrite.
Reviewers: klausler, schweitz, sscalpone, jdoerfert, DavidTruby
Reviewed By: klausler, schweitz
Subscribers: llvm-commits, flang-commits
Tags: #flang, #llvm
Differential Revision: https://reviews.llvm.org/D81940
This upstreams the internal name mangling used in the bridge to generate
unique names from symbols.
Replace InternalNamesTest with the actual, functional unittest.
Differential revision: https://reviews.llvm.org/D81764
G++ 10.1 emits inappropriate "use of uninitialized data" warnings when
compiling f18. The warnings stem from two sites in templatized code
whose multiple instantiations magnified the number of warnings.
These changes dodge those warnings by making some innocuous changes to
the code. In the parser, the idiom defaulted(cut >> x), which yields a
parser that always succeeds, has been replaced with a new equivalent
pass<T>() parser that returns a default-constructed value T{} in an
arguably more readable fashion. This idiom was the only attestation of
the basic parser cut, so it has been removed and the remaining code
simplified. In Evaluate/traverse.h, a return {}; was replaced with a
return of a default-constructed member.
Differential Revision: https://reviews.llvm.org/D81747
The complex expression helper class can be used to generate small,
short-lived instances of a "helper" that can be used to aid the
construction of complex expressions in FIR. The helper class bundles
together these functionally related operations.
Included in this diff is the header for the FIR builder. The
implementation has other dependences and will follow.
Differential Revision: https://reviews.llvm.org/D81287
When we encountered a type name in a derived type definition, we were
sometimes finding a component of that name rather than the type from
the enclosing scope. Fix this by introducing `NonDerivedTypeScope()` to
start the search in the right scope.
Differential Revision: https://reviews.llvm.org/D81493
Summary: Apply workaround done in D81179 only for GCC < 8. As @klausler mentioned in D81179 we want to avoid additional checks for other compilers that do not need them.
Reviewers: DavidTruby, klausler, jdoerfert, sscalpone
Reviewed By: klausler, sscalpone
Subscribers: llvm-commits, tskeith, isuruf, klausler
Tags: #flang, #llvm
Differential Revision: https://reviews.llvm.org/D81208
Summary:
The only difference is that LLVM_ENABLE_WERROR is set to OFF
by default, but we enable this in a standalone flang build
This commit fixes some windows issues with the flags
Reviewers: DavidTruby, jdoerfert, sscalpone
Reviewed By: DavidTruby, sscalpone
Subscribers: ormris, richard.barton.arm, mehdi_amini, Meinersbur, ChinouneMehdi, tskeith, mgorny, llvm-commits
Tags: #llvm, #flang
Differential Revision: https://reviews.llvm.org/D78306
Summary:
If you create an expression with parse errors, the `parser::Expr.typedExpr`
will be empty, which causes a compiler crash. The crash is caused by the
check in check-do-forall.cpp that scans all expresssions to see if `DO`
variables are being modified.
It turned out that the problem was that I was fetching subexpressions of type
`parser::Expr`, which are not guaranteed to have a non-null `typedExpr`. I
fixed this by only grabbing the top-level expression from which to gather
arguments as part of the DO loop analysis. This, in turn, exposed a problem
where I wasn't collecting all of the actual arguments in an expression. This
was caused by the fact that I wasn't recursing through the rest of the
expression after finding an argument. I fixed this by recursing through the
argument in the member function in `CollectActualArgumentsHelper`.
Reviewers: klausler, tskeith, DavidTruby
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D81101
Summary:
Using a forward reference to define a `len` parameter causes a crash.
The underlying cause was that a previously declared type had an
erroneous expression for its `LEN` param value. When this expression
was referenced to evaluate a subsequent expression, bad things happened.
I fixed this by putting in code to detect this case.
Reviewers: tskeith, klausler, DavidTruby
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D80593
Part of lowering is to convert the front-end types to their FIR dialect representations. These conversions are done by here in the ConvertType module.
proactively update the code to conform better with LLVM coding conventions
Differential Revision: https://reviews.llvm.org/D81034
Summary:
Fortran::evaluate::IsConstantExpr did not check that the numerator
was a constant expression. This patch fixes the issue.
Reviewers: DavidTruby, klausler, schweitz, PeteSteinfeld, jdoerfert, sscalpone
Reviewed By: klausler, PeteSteinfeld, sscalpone
Subscribers: llvm-commits
Tags: #llvm, #flang
Differential Revision: https://reviews.llvm.org/D81096
Summary
- Implemented C876, C877
- Fixed IsConstantExpr to check C879
- Fixed bugs in few test cases - data01.f90, block-data01.f90,
pre-fir-tree02.f90
- Modified implementation of C8106 to identify all automatic objects
and modified equivalence01.f90 to reflect the changes
Differential Revision: https://reviews.llvm.org/D78424
The lowering bridge will call these lowering hooks to process the Open
MP directives that it iterates over in the PFT. This is a mock
interface without an implementation in this patch.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D80815
Summary:
Some Symbol-related functions used in Evaluate were moved to
Evaluate/tools.h. This includes changing some member functions that were
replaced by non-member functions `IsDummy`, `GetUsedModule`, and
`CountLenParameters`.
Some member functions were made inline in `Scope`, `Symbol`,
`ArraySpec`, and `DeclTypeSpec`. The definitions were preceded by a
comment explaining why they are inline.
`IsConstantShape` was expanded inline in `IsDescriptor` because it isn't
used anywhere else
After this change, at least when compiling with clang on macos,
`libFortranEvaluate.a` has no undefined symbols that are satisfied by
`libFortranSemantics.a`.
Reviewers: klausler, PeteSteinfeld, sscalpone, jdoerfert, DavidTruby
Reviewed By: PeteSteinfeld
Subscribers: llvm-commits
Tags: #flang, #llvm
Differential Revision: https://reviews.llvm.org/D80762
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
Summary:
We were not detecting declaring multiple interfaces to the same procedure.
Also, we were not handling the initialization of entitiies where the associated
Symbol had previously had errors.
I added the function `IsInterfaceSet()` to ProcEntityDetails to see if
the value of `interface_` had been previously set. I then checked this
function before calling set_interface() and emitted an error message if
the interface was already set.
Also, in situations where we were emitting error messages for symbols, I
set the Error flag on the Symbol. Then when performing initialization
on the Symbol, I first check to see if the Symbol had an error.
Reviewers: tskeith, klausler, DavidTruby
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D80453
Summary:
Many of these were already implemented, and I just annotated the tests and/or
the code.
C752 was a simple check to verify that CONTIGUOUS components are arrays with
C754 proved to be virtually identical to C750 that I implemented previously.
This caused me to remove the distinction between specification expressions for
type parameters and bounds expressions that I'd previously created.
the POINTER attribute.
I also changed the error messages to specify that errors in specification
expressions could arise from either bad derived type components or type
parameters.
In cases where we detect a type param that was not declared, I created a symbol
marked as erroneous. That avoids subsequent semantic process for expressions
containing the symbol. This change caused me to adjust tests resolve33.f90 and
resolve34.f90. Also, I avoided putting out error messages for erroneous type
param symbols in `OkToAddComponent()` in resolve-names.cpp and in
`EvaluateParameters()`, type.cpp.
C756 checks that procedure components have the POINTER attribute.
Reviewers: tskeith, klausler, DavidTruby
Subscribers: llvm-commits
Tags: #llvm, #flang
Differential Revision: https://reviews.llvm.org/D79798
Summary:
If the value in the collapse close is negative f18 abort without the correct error message. This PR change the size_t in name resolution to a int64_t and check appropriately for negative or zero before the privatization of induction variable.
The correct error is then catch by the OpenMP structure check.
This diff is migrated from the GitHub pull request https://github.com/flang-compiler/f18/pull/1098
Reviewers: ichoyjx, jdoerfert, sscalpone, DavidTruby
Reviewed By: ichoyjx, sscalpone, DavidTruby
Subscribers: sscalpone, klausler, yaxunl, guansong, llvm-commits
Tags: #llvm, #flang
Differential Revision: https://reviews.llvm.org/D77821
When a module contained an import of a use-association of a
use-association, we weren't recognizing that the symbols was needed.
The fix is the follow all of the use-associations using `GetUltimate()`.
Differential Revision: https://reviews.llvm.org/D79737
When intrinsic types are assigned there are some implicit conversions
that take place. This change make them explicit in the types
representation of assignments.
Differential Revision: https://reviews.llvm.org/D79637
Summary:
Initially on github I worked on semantic checks.Then I tried some compile-time
test of the rank value, they were failing as there were no symbols
generated for them inside SELECT RANK's scope.So I went further to
add new symbol in each scope, also added the respective 'rank: '
field for a symbol when we dump the symboltable. I added a field to
keep track of the rank in AssocEntityDetails class.This caused shape
analysis framework to become inconsistent. So shape analysis framework
was updated to handle this new representation.
* I added more tests for above changes.
* On phabricator I addressed some minor changes.
* Lastly I worked on review comments.
Reviewers: klausler,sscalpone,DavidTruby,kiranchandramohan,tskeith,anchu-rajendran,kiranktp
Reviewed By:klausler, DavidTruby, tskeith
Subscribers:#flang-commits, #llvm-commits
Tags: #flang, #llvm
Differential Revision: https://reviews.llvm.org/D78623
This is a wrapper around vector of NamedAttributes that keeps track of whether sorted and does some minimal effort to remain sorted (doing more, e.g., appending attributes in sorted order, could be done in follow up). It contains whether sorted and if a DictionaryAttr is queried, it caches the returned DictionaryAttr along with whether sorted.
Change MutableDictionaryAttr to always return a non-null Attribute even when empty (reserve null cases for errors). To this end change the getter to take a context as input so that the empty DictionaryAttr could be queried. Also create one instance of the empty dictionary attribute that could be reused without needing to lock context etc.
Update infer type op interface to use DictionaryAttr and use NamedAttrList to avoid incurring multiple conversion costs.
Fix bug in sorting helper function.
Differential Revision: https://reviews.llvm.org/D79463
IsDescriptor was returning false for a component whose shape depended
on a length parameter. Change it to return true for any array with
non-constant bounds.
Differential Revision: https://reviews.llvm.org/D79349
Summary: I updated the code that produces the message and the associated test.
Reviewers: sscalpone, DavidTruby, kiranchandramohan
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D79514
Summary: I updated the code that produces the message and the associated test.
Reviewers: sscalpone, DavidTruby
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D79514
Add a way to get mutable equivalence sets to Scope so that they can
have sizes and offsets assigned to them.
Change CommonBlockDetails to have mutable symbols so that they can have
sizes and offets assigned to them. This also allows the removal of some
`const_cast`s.
Add MutableSymbolRef and MutableSymbolVector as mutable analogs to
SymbolRef and SymbolVector. Replace uses of equivalent types with those
names.
Differential Revision: https://reviews.llvm.org/D79346
Objects in common blocks have offsets relative to the start of the
common block, independent of the enclosing scope, so they are processed
first. Add alignment to CommonBlockDetails to record the required
alignment of the common block.
For equivalence sets, each object depends on the one that is forced to
occur first in memory. The rest are recorded in the dependents_ map and
have offsets assigned after the other symbols are done.
Differential Revision: https://reviews.llvm.org/D79347
Summary:
Most of these checks were already implemented, and I just added references to
them to the code and tests. Also, much of this code was already
reviewed in the old flang/f18 GitHub repository, but I didn't get to
merge it before we switched repositories.
I implemented the check for C747 to not allow coarray components in derived
types that are of type C_PTR, C_FUNPTR, or type TEAM_TYPE.
I implemented the check for C748 that requires a data component whose type has
a coarray ultimate component to be a nonpointer, nonallocatable scalar and not
be a coarray.
I implemented the check for C750 that adds additional restrictions to the
bounds expressions of a derived type component that's an array.
These bounds expressions are sepcification expressions as defined in
10.1.11. There was already code in lib/Evaluate/check-expression.cpp to
check semantics for specification expressions, but it did not check for
the extra requirements of C750.
C750 prohibits specification functions, the intrinsic functions
ALLOCATED, ASSOCIATED, EXTENDS_TYPE_OF, PRESENT, and SAME_TYPE_AS. It
also requires every specification inquiry reference to be a constant
expression, and requires that the value of the bound not depend on the
value of a variable.
To implement these additional checks, I added code to the intrinsic proc
table to get the intrinsic class of a procedure. I also added an
enumeration to distinguish between specification expressions for
derived type component bounds versus for type parameters. I then
changed the code to pass an enumeration value to
"CheckSpecificationExpr()" to indicate that the expression was a bounds
expression and used this value to determine whether to emit an error
message when violations of C750 are found.
I changed the implementation of IsPureProcedure() to handle statement
functions and changed some references in the code that tested for the
PURE attribute to call IsPureProcedure().
I also fixed some unrelated tests that got new errors when I implemented these
new checks.
Reviewers: tskeith, DavidTruby, sscalpone
Subscribers: jfb, llvm-commits
Tags: #llvm, #flang
Differential Revision: https://reviews.llvm.org/D79263
Summary:
Fix decimal formatting of 80-bit x87 values; the calculation ofnearest neighbor values failed to account for the explicitmost significant bit in that format.
Replace MultiplyByRounded with MultiplyBy in binary->decimal conversions,
since rounding won't happen and the name was misleading; then remove
dead code, and migrate LoseLeastSignificantDigit() from one source file
to another where it's still needed.
Reviewers: tskeith, sscalpone, jdoerfert, DavidTruby
Reviewed By: tskeith
Subscribers: llvm-commits, flang-commits
Tags: #flang, #llvm
Differential Revision: https://reviews.llvm.org/D79345
Summary:
I found a small test case that caused a crash when derived type
definitions have parameters without definitions.
Reviewers: tskeith, klausler, DavidTruby
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D79282
This range allows for performing many different operations on successor operands, including erasing/adding/setting. This removes the need for the explicit canEraseSuccessorOperand and eraseSuccessorOperand methods.
Differential Revision: https://reviews.llvm.org/D79077
As we start defining more complex Ops, we increasingly see the need for
Ops-with-regions to be able to construct Ops within their regions in
their ::build methods. However, these methods only have access to
Builder, and not OpBuilder. Creating a local instance of OpBuilder
inside ::build and using it fails to trigger the operation creation
hooks in derived builders (e.g., ConversionPatternRewriter). In this
case, we risk breaking the logic of the derived builder. At the same
time, OpBuilder::create, which is by far the largest user of ::build
already passes "this" as the first argument, so an OpBuilder instance is
already available.
Update all ::build methods in all Ops in MLIR and Flang to take
"OpBuilder &" instead of "Builder *". Note the change from pointer and
to reference to comply with the common style in MLIR, this also ensures
all other users must change their ::build methods.
Differential Revision: https://reviews.llvm.org/D78713
Summary:
This includes a refactor of the existing combined construct checks
that were present, as well as adding the remaining combined constructs
that had not been implemented yet.
Reviewers: jdoerfert
Subscribers: yaxunl, guansong, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D77812
Summary:
Updates recent work on DATA statement semantic checking in
flang/lib/Semantics/check-data.{h,cpp} to use the compiler's
internal representation for typed expressions rather than working
on the raw parse tree. Saves the analyzed expressions for DATA
statement values as parse tree decorations because they'll soon be
needed in lowering. Corrects wording of some error messages.
Fixes a bug in constant expression checking: structure constructors
are not constant expressions if they set an allocatable component
to anything other than NULL.
Includes infrastructure changes to make this work, some renaming
to reflect the fact that the implied DO loop indices tracked by
expression analysis are not (just) from array constructors, remove
some dead code, and improve some comments.
Reviewers: tskeith, sscalpone, jdoerfert, DavidTruby, anchu-rajendran, schweitz
Reviewed By: tskeith, anchu-rajendran, schweitz
Subscribers: llvm-commits, flang-commits
Tags: #flang, #llvm
Differential Revision: https://reviews.llvm.org/D78834
Summary:
Add size and offset properties to symbols, representing their byte size
and offset within their enclosing scope.
Add size and align properties to scopes so that they are available for
scopes representing derived types.
Add ComputeOffsets pass over the symbol table to fill in those fields.
Compute descriptor size based on rank and length parameters. Extract
DerivedTypeSpec::NumLengthParameters from DynamicType::RequiresDescriptor
to share the code.
Add Scope::GetSymbols to get symbols in canonical order.
compute-offsets.cpp and mod-file.cpp both need to process symbols in the
order in which they are declared. Move the collecting of those symbols
into Scope so that it can be shared.
Add symbol size and offset to output of `-fdebug-dump-symbols` and use
that in some tests.
Still to do:
- make size and alignment rules configurable based on target
- use offsets to check EQUIVALENCE statements
Differential Revision: https://reviews.llvm.org/D78680
Valentin Clement