If the procedure pointer has an explicit interface, its characteristics must
equal the characteristics of its target, except that the target may be pure or
elemental also when the pointer is not (cf. F2018 10.2.2.4(3)). In the semantics
check for assignment of procedure pointers, the attributes of the procedures
were not checked correctly due to a typo. This caused some illegal
pointer-target-combinations to pass without raising an error. Fix this, and
expand the test case to improve the coverage of procedure pointer assignment
checks.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D113368
Add conversion pattern for the `fir.convert` operation.
This patch is part of the upstreaming effort from fir-dev branch.
This patch was previously landed with a truncated version that
was failing the windows buildbot.
Reviewed By: rovka, awarzynski
Differential Revision: https://reviews.llvm.org/D113469
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Add conversion pattern for the `fir.convert` operation.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: rovka, awarzynski
Differential Revision: https://reviews.llvm.org/D113469
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This patch add conversion for primitive operations on complex types.
- fir.addc
- fir.subc
- fir.mulc
- fir.divc
- fir.negc
This adds also the type conversion for !fir.complex<KIND> type.
This patch is part of the upstreaming effort from fir-dev branch.
This patch was updated to avoid failure on windows buildbot.
Flang codegen does not support windows target so we force the test
to use a known target instead.
Reviewed By: kiranchandramohan, rovka
Differential Revision: https://reviews.llvm.org/D113434
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This patch add conversion for primitive operations on complex types.
- fir.addc
- fir.subc
- fir.mulc
- fir.divc
- fir.negc
This adds also the type conversion for !fir.complex<KIND> type.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: rovka
Differential Revision: https://reviews.llvm.org/D113434
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Rewrite function signatures and calls to functions that accept or return
COMPLEX values.
Also teach insert_value and extract_value about the MLIR ComplexType, by
adding AnyComplex to AnyCompositeLike.
This patch is part of the effort for upstreaming the fir-dev branch.
Differential Revision: https://reviews.llvm.org/D113273
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Kiran Chandramohan <kiran.chandramohan@arm.com>
Co-authored-by: Tim Keith <tkeith@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
This patch adds the basic infrastructure for the TargetRewrite pass,
which rewrites certain FIR dialect operations into target specific
forms. In particular, it converts boxchar function parameters, call
arguments and return values. Other convertions will be included in
future patches.
This patch is part of the effort for upstreaming the fir-dev branch.
Differential Revision: https://reviews.llvm.org/D112910
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Kiran Chandramohan <kiran.chandramohan@arm.com>
Co-authored-by: Tim Keith <tkeith@nvidia.com>
When an array's shape involves references to symbols that are not
invariant in a scope -- the classic example being a dummy array
with an explicit shape involving other dummy arguments -- the
compiler was creating shape expressions that referenced those
symbols. This might be valid if those symbols are somehow
captured and copied at each entry point to a subprogram, and
the copies referenced in the shapes instead, but that's not
the case.
This patch introduces a new expression predicate IsScopeInvariantExpr(),
which defines a class of expressions that contains constant expressions
(in the sense that the standard uses that term) as well as references
to items that may be safely accessed in a context-free way throughout
their scopes. This includes dummy arguments that are INTENT(IN)
and not VALUE, descriptor inquiries into descriptors that cannot
change, and bare LEN type parameters within the definitions of
derived types. The new predicate is then used in shape analysis
to winnow out results that would have otherwise been contextual.
Differential Revision: https://reviews.llvm.org/D113309
Previously, jumps to labels in constructs from exterior statements
would elicit only a warning. Upgrade these to errors unless the
branch into the construct would enter into only DO, IF, and SELECT CASE
constructs, whose interiors don't scope variables or have other
set-up/tear-down semantics. Branches into these "safe" constructs
are still errors if they're nested in an unsafe construct that doesn't
also enclose the exterior branch statement.
Differential Revision: https://reviews.llvm.org/D113310
The value of EPSILON() was off by one power of two due to my
misreading of the standard; this patch corrects it.
Confirmed by checking other Fortran compilers, which all agree.
Differential Revision: https://reviews.llvm.org/D113308
Add conversion from !fir.logical types to LLVM IR Dialect types.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D113405
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This patch add the `!fir.box` type conversion to llvm.
`fir.box` is converted to the descriptor as defined in the ISO_Fortran_binding.h
and the addendum defined in descriptor.h.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D113288
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
This patch extends the `FIRToLLVMLowering` pass in Flang by adding a
hook to transform `fir.call` to `llvm.call`.
This is part of the upstreaming effort from the `fir-dev` branch in [1].
[1] https://github.com/flang-compiler/f18-llvm-project
Patch originally written by:
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Differential Revision: https://reviews.llvm.org/D113278
Add a separate file to test FIR types conversion to LLVM types.
Conversion comes from `flang/lib/Optimizer/CodeGen/TypeConverter.h`
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: kiranchandramohan, awarzynski
Differential Revision: https://reviews.llvm.org/D113283
This patch add the conversion pattern for fir.extract_value
and fir.insert_value. fir.extract_value is lowered to llvm.extractvalue
anf fir.insert_value is lowered to llvm.insertvalue.
This patch also adds the type conversion for the BoxType and RecordType
needed to have some comprehensive tests.
This patch is part of the upstreaming effort from fir-dev branch.
This patch was landed and reverted once.
TypeBuilderFunc getModel<Fortran::ISO::CFI_index_t>() was clashing
with getModel<long long> on windows since they both are 64 bits
signed interger. On linux CFI_index_t is long. Change CFI_index_t
to getModel<long>.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D112961
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This patch add the conversion pattern for fir.extract_value
and fir.insert_value. fir.extract_value is lowered to llvm.extractvalue
anf fir.insert_value is lowered to llvm.insertvalue.
This patch also adds the type conversion for the BoxType and RecordType
needed to have some comprehensive tests.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D112961
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
The `fir.select` and `fir.select_rank` are lowered to llvm.switch.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D113089
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
The IsPointer check currently fails for host-associated symbols in OpenMP
regions. This causes some failures in semantic checks for pointer association
in an OpenMP region. Fix is to use the ultimate symbol in the call to the
IsPointer function in CheckPointerAssignment function in
lib/Semantics/pointer-assignment.cpp.
Reviewed By: klausler, peixin
Differential Revision: https://reviews.llvm.org/D112876
In a "Worksharing-loop construct", one can add a nowait clause at the end
of the loop (i.e. at the loop tail). This clause wasn't associated with
the corresponding loop when originally worked on in flang-omp-report.
Note that this refers to parsing and parse-tree generation. To work
around it, it was needed to track such clauses and the loops.
This should no longer be required (and in fact no longer works) and so
was removed. This results in 'curLoopLogRecord' and 'loopLogRecordStack' and
all references to them being removed. This also allows for
'constructClauses' to be swapped from std::deque to llvm::SmallVector.
Lastly a new test has been added testing the "nowait" clauses in a
variety of ways.
Reviewed By: awarzynski, kiranchandramohan
Differential Revision: https://reviews.llvm.org/D112217
This patch removes unnecessary comments in the flang-omp-report
plugin tests which can be implied from the file name and run command.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D112817
Convert fir.insert_on_range operation to corresponding
llvm.insertvalue operations.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D112896
Sequence type had no restriction on the insert_on_range operation.
This patch adds a restriction for the type to have constant shape
and size.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D113092
This patch adds the substring information to the fircg.ext_embox and
fircg.ext_rebox operations.
Substring is used for CHARACTER types.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D112807
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This patch extends the `FIRToLLVMLowering` pass in Flang by adding a
hook to transform `fir.unreachable` to `llvm.unreachable`.
This is part of the upstreaming effort from the `fir-dev` branch in [1].
[1] https://github.com/flang-compiler/f18-llvm-project
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Differential Revision: https://reviews.llvm.org/D113023
This patch adds the ZeroOpConversion pattern to LLVM IR dialect.
Conversion of aggregate types is not implemented yet and will trigger a
failure to legalize the operation. This is tested in the
convert-to-llvm-invalid.fir test file.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D113014
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This patch adds the base of the FIR to LLVM IR Dialect conversion pass.
It currently can convert the following operations:
- fir.global
- fir.has_value
- fir.address_of
- fir.undefined
This patch is part of the upstreaming effort from fir-dev branch. It does not
cover all FIR operations in order to have small patches. Several patches will
follow to convert other operations.
Reviewed By: schweitz
Differential Revision: https://reviews.llvm.org/D112845
The tests for folding these intrinsics neglected to name the
logical scalars with a leading "test_", so test failures caused
by recent work to implement a combined constant folding facility
for these intrinsics wasn't catching some bugs. This patch fixes
the tests and the bugs.
Differential Revision: https://reviews.llvm.org/D112741
While "null()" is accepted as a data statement constant when it
corresponds to a pointer object, "null(mold=p)" and "null(p)"
are not allowed. The current error messages simply complain
that null is not an array. This patch adds a context-sensitive
message to the effect that a data statement constant followed
by non-empty parentheses must be an array or structure constructor.
(Note that f18 can't simply special-case the name "null" when parsing
data statement constants, since programs are free to repurpose that
name as an array or derived type.)
Differential Revision: https://reviews.llvm.org/D112740
Check that when a procedure pointer is initialised or assigned with an intrinsic
function, or when its interface is being defined by one, that intrinsic function
is unrestricted specific (listed in Table 16.2 of F'2018).
Mark intrinsics LGE, LGT, LLE, and LLT as restricted specific. Getting their
classifications right helps in designing the tests.
Differential Revision: https://reviews.llvm.org/D112381
Substring information on slice operation has been added in D112441.
The operations fir.array_load, fir.array_coor and fir.array_merge_store can take
a slice but not with a substring. This patch add this check in their verifier.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: schweitz
Differential Revision: https://reviews.llvm.org/D112568
This patch adds the substriing information to the fir.slice
operation. This will be used by character operations in later
upstreaming patches.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D112441
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Allocatable dummy arguments can be used to distinguish
two specific procedures in a generic interface when
it is the case that exactly one of them is polymorphic
or exactly one of them is unlimited polymorphic. The
standard requires that an actual argument corresponding
to an (unlimited) polymorphic allocatable dummy argument
must also be an (unlimited) polymorphic allocatable, so an
actual argument that's acceptable to one procedure must
necessarily be a bad match for the other.
Differential Revision: https://reviews.llvm.org/D112237
A reference to an allocatable or pointer component must be applied
to a scalar base object. (This is the second part of constraint C919;
the first part is already checked.)
Differential Revision: https://reviews.llvm.org/D112241
Negative shift counts are of course valid for ISHFT when
shifting to the right. This patch decouples the folding of
ISHFT from that of SHIFTA/L/R and adds tests.
Differential Revision: https://reviews.llvm.org/D112244
```
[5.1] 2.21.2 THREADPRIVATE Directive
A variable that appears in a threadprivate directive must be declared in
the scope of a module or have the SAVE attribute, either explicitly or
implicitly.
A variable that appears in a threadprivate directive must not be an
element of a common block or appear in an EQUIVALENCE statement.
```
This patch supports the following checks for DECLARE TARGET Directive:
```
[5.1] 2.14.7 Declare Target Directive
A variable that is part of another variable (as an array, structure
element or type parameter inquiry) cannot appear in a declare
target directive.
A variable that appears in a declare target directive must be declared
in the scope of a module or have the SAVE attribute, either explicitly
or implicitly.
A variable that appears in a declare target directive must not be an
element of a common block or appear in an EQUIVALENCE statement.
```
As Fortran 2018 standard [8.5.16] states, a variable, common block, or
procedure pointer declared in the scoping unit of a main program,
module, or submodule implicitly has the SAVE attribute, which may be
confirmed by explicit specification.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D109864
Semantics is rejecting valid programs with NULL() actual arguments
to generic interfaces, including user-defined operators. Subclause
16.9.144(para 6) makes clear that NULL() can be a valid actual
argument to a generic interface so long as it does not produce
ambiguity. This patch handles those cases, revises existing
tests, and adjust an error message about NULL() operands to
appear less like a blanket prohibition.
Differential Revision: https://reviews.llvm.org/D111850
Fold the legacy intrinsic functions LGE, LGT, LLE, & LLT
by rewriting them into character relational expressions and
then folding those. Also fix folding of comparisons of
character values of distinct lengths: the shorter value must
be padded with blanks. (This fix exposed some bad test cases,
which are also fixed.)
Differential Revision: https://reviews.llvm.org/D111843
Semantics refuses valid ELEMENTAL subprograms without dummy arguments,
but there's no such constraint in the standard; indeed, subclause
15.8.2 discusses the meaning of calls to ELEMENTAL functions with
arguments. Remove the check and its test.
Differential Revision: https://reviews.llvm.org/D111832
Precursor: https://reviews.llvm.org/D110200
Removed redundant ops from the standard dialect that were moved to the
`arith` or `math` dialects.
Renamed all instances of operations in the codebase and in tests.
Reviewed By: rriddle, jpienaar
Differential Revision: https://reviews.llvm.org/D110797
This patch upstream the cfg conversion pass. This pass
rewrite FIR loop-like operation to a CFG.
This patch is part of the upstreaming effort from fir-dev branch.
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Co-authored-by: Valentin Clement <clementval@gmail.com>
Reviewed By: schweitz
Differential Revision: https://reviews.llvm.org/D111095
As reported in https://bugs.llvm.org/show_bug.cgi?id=48145, name resolution for omp critical construct was failing. This patch adds functionality to help that name resolution as well as implementation to catch name mismatches.
The following semantic restrictions are therefore handled here:
- If a name is specified on a critical directive, the same name must also be specified on the end critical directive
- If no name appears on the critical directive, no name can appear on the end critical directive
- If a name appears on either the start critical directive or the end critical directive
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D110502
Parallel sections directive borrows the semantic checks from both sections directive and parallel directive. Semantic checks for both are merged in main branch; this test case is added to make sure correct semantic checks upon merging the two.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D111438
Add rewrite patterns for fir.convert op canonicalization.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D111537
Co-authored-by: Valentin Clement <clementval@gmail.com>
This patch adds a new abstract class for frontend actions:
`PrescanAndSemaDebugAction`. It's almost identical to
`PrescanAndSemaAction`, but in the presence of semantic errors it does
not skip the corresponding `ExecuteAction` specialisation. Instead, it
runs it as if there were no semantic errors. This class is for developer
actions only (i.e. front-end driver options).
The new behaviour does not affect the return code from `flang-new -fc1`
when the input file is semantically incorrect. The return code is
inferred from the number of driver diagnostics generated in
`CompilerInstance::ExecuteAction` and this patch does not change that.
More specifically, the semantic errors are still reported and hence the
driver is able to correctly report that the compilation has failed (with
a non-zero return code).
This new base class is meant for debug actions only and
`DebugDumpAllAction` is updated to demonstrate the new behaviour. With
this change, `flang-new -fc1 -fdebug-dump-all` dumps the parse tree and
symbols for all input files, regardless of whether any semantic errors
were found.
This patch addresses https://bugs.llvm.org/show_bug.cgi?id=52097.
Differential Revision: https://reviews.llvm.org/D111308
Add pass that convert abstract result to function argument.
This pass is needed before the conversion to LLVM IR.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: schweitz
Differential Revision: https://reviews.llvm.org/D111146
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Upstream the character conversion pass.
Translates entities of one CHARACTER KIND to another.
By default the translation is to naively zero-extend or truncate a code
point to fit the destination size.
This patch is part of the upstreaming effort from fir-dev branch.
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Valentin Clement <clementval@gmail.com>
Reviewed By: schweitz
Differential Revision: https://reviews.llvm.org/D111405
Add affine demotion pass.
Affine dialect's default lowering for loads and stores is different from
fir as it uses the `memref` type. The `memref` type is not compatible with
the Fortran runtime. Therefore, conversion of memory operations back to
`fir.load` and `fir.store` with `!fir.ref<?>` types is required.
This patch is part of the upstreaming effort from fir-dev branch.
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Co-authored-by: Rajan Walia <walrajan@gmail.com>
Co-authored-by: Sourabh Singh Tomar <SourabhSingh.Tomar@amd.com>
Co-authored-by: Valentin Clement <clementval@gmail.com>
Reviewed By: schweitz
Differential Revision: https://reviews.llvm.org/D111257
Convert fir operations which satisfy affine constraints to the affine
dialect.
This patch is part of the upstreaming effort from fir-dev branch.
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Co-authored-by: Rajan Walia <walrajan@gmail.com>
Co-authored-by: Sourabh Singh Tomar <SourabhSingh.Tomar@amd.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Valentin Clement <clementval@gmail.com>
Reviewed By: schweitz, awarzynski
Differential Revision: https://reviews.llvm.org/D111155
Source lines with mismatched parentheses are hard cases for error
recovery in parsing, and the best error message (viz.,
"here's an unmatched parenthesis") can be emitted from the
prescanner.
Differential Revision: https://reviews.llvm.org/D111254#3046173
Add the external name conversion pass needed for compiler
interoperability. This pass convert the Flang internal symbol name to
the common gfortran convention.
Clean up old passes without implementation in the Passes.ts file so
the project and fir-opt can build correctly.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: schweitz
Differential Revision: https://reviews.llvm.org/D111057
fir.array_update is only handling intrinsic assignments.
They are two big differences with user defined assignments:
1. The LHS and RHS types may not match, this does not play well
with fir.array_update that relies on both the merge and the
updated element to have the same type.
2. user defined assignment has a call semantics, with potential
side effects. So if a fir.array_update can hide a call, it traits
would need to be updated.
Instead of hiding more semantic in the fir.array_update, introduce
a new fir.array_modify op that allows de-correlating indicating that
an array value element is modified, and how it is modified.
This allow the ArrayValueCopy pass to still perform copy elision
while not having to implement the call itself, and could in general
be used for all kind of assignments (e.g. character assignment).
Update the alias analysis to not rely on the merge arguments (since
fir.array_modify has none).
Instead, analyze what is done with the element address.
This implies adding the ability to follow the users of fir.array_modify,
as well as being able to go through fir.store that may be generated to
store the RHS value in order to pass it to a user define routine.
This is done by adding a ReachCollector class to gather all array
accesses.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: schweitz
Differential Revision: https://reviews.llvm.org/D110928
Co-authored-by: Valentin Clement <clementval@gmail.com>
The THEN keyword in the "ELSE IF (test) THEN" statement is useless
syntactically, and to omit it is a common error (at least for me!)
that has poor error recovery. This patch changes the parser to
cough up a simple "expected 'THEN'" and still recognize the rest of
the IF construct.
Differential Revision: https://reviews.llvm.org/D110952
According to OpenMP 5.0 spec document, the following semantic restrictions have been dealt with in this patch.
1. [sections construct] Orphaned section directives are prohibited. That is, the section directives must appear within the sections construct and must not be encountered elsewhere in the sections region.
Semantic checks for the following are not necessary, since use of orphaned section construct (i.e. without an enclosing sections directive) throws parser errors and control flow never reaches the semantic checking phase. Added a test case for the same.
2. [sections construct] Must be a structured block
Added test case and made changes to branching logic
3. [simd construct] Must be a structured block / A program that branches in or out of a function with declare simd is non conforming
4. Fixed !$omp do's handling of unlabeled CYCLEs
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D108904
fir.negf op is replaced by mlir.negf and
fir.modf is just deleted.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D110932
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Valentin Clement <clementval@gmail.com>
Add the fir-char_convert op.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D110818
Co-authored-by: Valentin Clement <clementval@gmail.com>
Fold the transformational intrinsic function FINDLOC() for
all combinations of optional arguments and data types.
Differential Revision: https://reviews.llvm.org/D110757
The algorithm used to fold SQRT has some holes that
led to test failures; debug and add more tests.
Differential Revision: https://reviews.llvm.org/D110744
Move coor operand from variadic values to ArrayAttr.
Update assembly format.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D110652
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Valentin Clement <clementval@gmail.com>
Rearrange the contents of __builtin_* module files a little and
make sure that semantics implicitly USEs the module __Fortran_builtins
before processing each source file. This ensures that the special derived
types for TEAM_TYPE, EVENT_TYPE, LOCK_TYPE, &c. exist in the symbol table
where they will be available for use in coarray intrinsic function
processing.
Update IsTeamType() to exploit access to the __Fortran_builtins
module rather than applying ad hoc name tests. Move it and some
other utilities from Semantics/tools.* to Evaluate/tools.* to make
them available to intrinsics processing.
Add/correct the intrinsic table definitions for GET_TEAM, TEAM_NUMBER,
and THIS_IMAGE to exercise the built-in TEAM_TYPE as an argument and
as a result.
Add/correct/extend tests accordingly.
Differential Revision: https://reviews.llvm.org/D110356
The updated tests were originally added in
https://reviews.llvm.org/D109890 and are currently causing some
buildbots to fail.
This patch:
* adds missing items in the `REQUIRERS` list in tests
* adds `flangOmpReport` (the plugin library added in D109890) as a CMake
dependency for tests (only when examples are enabled)
Differential Revision: https://reviews.llvm.org/D110682
This plugin parses Fortran files and creates a
YAML report with all the OpenMP constructs and
clauses seen in the file.
The following tests have been modified to be
compatible for testing the plugin, hence why
they are not reused from another directory:
- omp-atomic.f90
- omp-declarative-directive.f90
- omp-device-constructs.f90
The plugin outputs a single file in the same
directory as the source file in the following format:
`<source-file-name>.yaml`
Building the plugin:
`ninja flangOmpReport`
Running the plugin:
`./bin/flang-new -fc1 -load lib/flangOmpReport.so -plugin flang-omp-report -fopenmp <source_file.f90>`
Co-authored-by: Kiran Chandramohan <kiran.chandramohan@arm.com>
Co-authored-by: Stuart Ellis <stuart.ellis@arm.com>
Reviewed By: awarzynski, kiranchandramohan
Differential Revision: https://reviews.llvm.org/D109890
Recommit https://reviews.llvm.org/D109813 and
https://reviews.llvm.org/D109814.
This implements the second and final entry point for GET_COMMAND_ARGUMENT,
handling the VALUE, STATUS and ERRMSG parameters.
It has a small fix in that we're now using memcpy instead of strncpy
(which was a bad idea to begin with, since we're not actually interested
in a string copy).
This reverts commit 0446f1299f and
df6302311f.
There's a warning on flang-aarch64-latest-gcc related to strncpy using
the result of strlen as a bound. I'll recommit with a fix.
Add the fir.save_result operation. It is use to save an
array, box, or record function result SSA-value to a memory location
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D110407
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Valentin Clement <clementval@gmail.com>
Update the fir.insert_on_range operation. Add a better description,
builder and verifier.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D110389
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Valentin Clement <clementval@gmail.com>
Partial implementation for the second entry point for
GET_COMMAND_ARGUMENT. It handles the VALUE and STATUS arguments, and
doesn't touch ERRMSG.
Differential Revision: https://reviews.llvm.org/D109813
Implement the ArgumentLength entry point of GET_COMMAND_ARGUMENT. Also
introduce a fixture for the tests.
Note that this also changes the interface for ArgumentLength from
returning a 4-byte integer to returning an 8-byte integer.
Differential Revision: https://reviews.llvm.org/D109227
Enforce constraints C1034 & C1038, which disallow the use
of otherwise valid statements as branch targets when they
appear in FORALL &/or WHERE constructs. (And make the
diagnostic message somewhat more user-friendly.)
Differential Revision: https://reviews.llvm.org/D109936
A defined assignment subroutine invoked in the context of a WHERE
statement or construct must necessarily be elemental (C1032).
Differential Revision: https://reviews.llvm.org/D109932
The strongly typed expression representation classes supported
a representation of parentheses only around intrinsic types
with specific kinds. Parentheses around derived type variables
must also be preserved so that expressions may be distinguished
from variables; this distinction matters for actual arguments &
construct associations.
Differential Revision: https://reviews.llvm.org/D110355
fir.cmpf op is not necessary anymore as it is replaced by mlir.cmpf.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D110327
Co-authored-by: schweitzpgi
Co-authored-by: jeanPerier
A pointer with subscripts, substring indices, or components cannot
be initialized by a DATA statement (although of course a whole pointer
can be so). Catch the missing cases.
Differential Revision: https://reviews.llvm.org/D109931
Catch additional missing error cases for typed and untyped
NULL actual arguments to non-intrinsic procedures in cases
of explicit and implicit interfaces.
Differential Revision: https://reviews.llvm.org/D110003
A function can't be a specification function if it has a dummy procedure
argument, even if it's optional and unused. So don't check the reference
for actual procedure arguments, but rather the characteristics of the
function.
Differential Revision: https://reviews.llvm.org/D109935
From subclause 6.3.3.5: a program unit END statement cannot be
continued in fixed form, and other statements cannot have initial
lines that look like program unit END statements. I think this
is to avoid violating assumptions that are important to legacy
compilers' statement classification routines.
Differential Revision: https://reviews.llvm.org/D109933
Catch invalid attempts to extract the unknowable extent of the last
dimension of an assumed-size array dummy argument, and clean up
problems with assumed-rank arguments in similar circumstances
exposed by testing the fix.
Differential Revision: https://reviews.llvm.org/D109918
A procedure actual argument to a PURE procedure should be required
to have an explicit interface. Implicit-interface actual arguments
to non-PURE procedures remain a warning.
Differential Revision: https://reviews.llvm.org/D109926
The intrinsic inquiry functions SIZE and UBOUND -- but not LBOUND --
require a DIM= argument if their first argument is an assumed-size
array. The intrinsic SHAPE must not be used with an assumed-size
array.
Differential Revision: https://reviews.llvm.org/D109912
Validation of the optional generic-spec on an END INTERFACE statement
was missing many possible error cases; reimplement it.
Differential Revision: https://reviews.llvm.org/D109910
This patch implements the following semantic checks according to
OpenMP Version 5.1 Ordered construct restriction:
```
At most one threads clause can appear on an ordered construct; At most
one simd clause can appear on an ordered construct; At most one
depend(source) clause can appear on an ordered construct; Either
depend(sink:vec) clauses or depend(source) clauses may appear on an
ordered construct, but not both.
```
This patch also implements the following semantic checks according to
the syntax and descriptions in OpenMP Version 5.1 Ordered construct:
```
The dependence types of sink or source are only allowed on an ordered
construct. The depend(*) clauses are not allowed when ordered construct
is a block construct with an ordered region. The threads or simd clauses
are not allowed when the ordered construct is a standalone construct
with no ordered region.
```
Co-authored-by: Sameeran Joshi <sameeranjayant.joshi@amd.com>
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D108512
Added 'this_image()' to the list of functions that are evaluated as intrinsic.
Added IsCoarray functions to determine if an expression is a coarray (corank > 1).
Added save attribute to coarray variables in test file, this_image.f90.
reviewers: klausler, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D108059
Complete folding of the intrinsic reduction function COUNT() for all
cases, including partial reductions with DIM= arguments.
Differential Revision: https://reviews.llvm.org/D109911
When the shapes of actual arguments to ELEMENTAL procedures are
sufficiently well known during semantics, require them to conform.
Differential Revision: https://reviews.llvm.org/D109909
Improve checking for NULL() and NULL(MOLD=) when used as
variables and expressions outside the few contexts where
a disassociated pointer can be valid. There were both
inappropriate errors and missing checks.
Differential Revision: https://reviews.llvm.org/D109905
This reverts commit 81f8ad1769.
This seems to break the shared libs build
(linaro-flang-aarch64-sharedlibs bot) with:
undefined reference to `Fortran::semantics::IsCoarray(Fortran::semantics::Symbol const&)
(from tools/flang/lib/Evaluate/CMakeFiles/obj.FortranEvaluate.dir/tools.cpp.o)
When linking lib/libFortranEvaluate.so.14git
Added 'this_image()' to the list of functions that are evaluated as intrinsic.
Added IsCoarray functions to determine if an expression is a coarray (corank > 1).
Added save attribute to coarray variables in test file, this_image.f90.
reviewers: klausler, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D108059
This patch implements the following check for THREADPRIVATE construct:
```
A variable that is part of another variable (as an array, structure
element or type parameter inquiry) cannot appear in a threadprivate
directive.
```
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D109685
This patch adds parsing support for the nontemporal clause. Also adds a couple of test cases.
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D106896
When nonexistent linker inputs are passed to the driver, the linker
now errors out, instead of the compiler. If the linker does not run,
clang now emits a "warning: linker input unused" instead of an error
for nonexistent files.
The motivation for this change is that I noticed that
`clang-cl /winsysroot sysroot main.cc ole32.lib` emitted a
"ole32.lib not found" error, even though the linker finds it just fine when
I run `clang-cl /winsysroot sysroot main.cc /link ole32.lib`.
The same problem occurs if running `clang-cl main.cc ole32.lib` in a
non-MSVC shell.
The problem is that DiagnoseInputExistence() only looked for libs in %LIB%,
but MSVCToolChain uses much more involved techniques.
For this particular problem, we could make DiagnoseInputExistence() ask
the toolchain to see if it can find a .lib file, but in general the
driver can't know what the linker will do to find files, so it shouldn't
try. For example, if we implement PR24616, lld-link will look in the
registry to determine a good default for %LIB% if it isn't set.
This is less or a problem for the gcc driver, since .a paths there are
either passed via -l flags (which honor -L), or via a qualified path
(that doesn't honor -L) -- but for example ld.lld's --chroot flag
can also trigger this problem. Without this patch,
`clang -fuse-ld=lld -Wl,--chroot,some/dir /file.o` will complain that
`/file.o` doesn't exist, even though
`clang -fuse-ld=lld -Wl,--chroot,some/dir -Wl,/file.o` succeeds just fine.
This implements rnk's suggestion on the old bug PR27234.
Differential Revision: https://reviews.llvm.org/D109624
https://reviews.llvm.org/D109156 did not properly update the case where
the equivalence symbol appearing in the common statement is the
"base symbol of an equivalence group" (this was the only case that previously
worked ok, and the patch broke it).
Fix this and add a test that actually uses this code path.
Differential Revision: https://reviews.llvm.org/D109439
Adds missing semantic checks for ELEMENTAL functions and subroutines,
their dummy arguments, and their results from F'2018 15.8.1 C15100-15102.
Differential Revision: https://reviews.llvm.org/D109380
Implement IEEE Real::SQRT() operation, then use it to
also implement Real::HYPOT(), which can then be used directly
to implement Complex::ABS().
Differential Revision: https://reviews.llvm.org/D109250
To enable Flang testing on Windows, shell scripts have
to be ported to Python. The following changes have been made:
"test_modfile.sh" has been ported to Python, and
the relevant tests relying on it.
Reviewed By: Meinersbur
Differential Revision: https://reviews.llvm.org/D107956
To enable Flang testing on Windows,
shells scripts have to be ported to Python.
The following changes have been made:
Ported `test_folding.sh` to Python;
Additional changes to the tests themselves
to use the new script.
LIBPGMATH support for testing
not available at this point.
Reviewed By: Meinersbur
Differential Revision: https://reviews.llvm.org/D108217
To enable Flang testing on Windows, shell scripts have to be ported to Python. In this patch the "test_errors.sh" script is ported to python ("test_errors.py"). The RUN line of existing tests was changed to make use of the python script.
Used python regex in place of awk/sed.
Reviewed By: Meinersbur
Differential Revision: https://reviews.llvm.org/D107575
Move the closure of the subset of flang/runtime/*.h header files that
are referenced by source files outside flang/runtime (apart from unit tests)
into a new directory (flang/include/flang/Runtime) so that relative
include paths into ../runtime need not be used.
flang/runtime/pgmath.h.inc is moved to flang/include/flang/Evaluate;
it's not used by the runtime.
Differential Revision: https://reviews.llvm.org/D109107
DialectAsmParser::parseKeyword is rejecting `'i' digit+` while it is
a valid identifier according to mlir/docs/LangRef.md.
Integer types actually used to be TOK_KEYWORD a while back before the
change: 6af866c58d.
This patch Modifies `isCurrentTokenAKeyword` to return true for tokens that
match integer types too.
The motivation for this change is the parsing of `!fir.type<{` `component-name: component-type,`+ `}>`
type in FIR that represent Fortran derived types. The component-names are
parsed as keywords, and can very well be i32 or any ixxx (which are
valid Fortran derived type component names).
The Quant dialect type parser had to be modified since it relied on `iw` not
being parsed as keywords.
Differential Revision: https://reviews.llvm.org/D108913
The size of common block should be extended to cover any storage
sequence that are storage associated with the common block via
equivalences (8.10.2.2 point 1 (2)).
In symbol size and offset computation, the size of the common block
was not always extended to cover storage association. It was only done
if the "base symbol of an equivalence group"(*) appeared in a common block
statement. Correct this to cover all cases where a symbol appearing in a
common block statement is storage associated.
(*) the base symbol of an equivalence group is the symbol whose storage
starts first in a storage association (if several symbols starts first,
the base symbol is the last one visited by the algorithm going through
the equivalence sets).
Differential Revision: https://reviews.llvm.org/D109156
Don't create new symbols in FORALL, implied DO, or other
construct scopes when an undeclared name appears; use the
innermost enclosing program unit's scope. This clears up
a pending TODO in name resolution, and also exposes (& fixes)
an unnoticed name resolution problem in a module file test.
Differential Revision: https://reviews.llvm.org/D109095
The combined initializers constructed from DATA statements and explicit
static initialization in declarations needs to include derived type
component default initializations, overriding those default values
without complaint with values from explicit DATA statement or declaration
initializations when they overlap. This also has to work for objects
with storage association due to EQUIVALENCE. When storage association causes
default component initializations to overlap, emit errors if and only
if the values differ (See Fortran 2018 subclause 19.5.3, esp. paragraph
10).
The f18 front-end has a module that analyzes and converts DATA statements
into equivalent static initializers for objects. For storage-associated
objects, compiler-generated objects are created that overlay the entire
association and fill it with a combined initializer. This "data-to-inits"
module already exists, and this patch is essentially extension and
clean-up of its machinery to complete the job.
Also: emit EQUIVALENCE to module files; mark compiler-created symbols
and *don't* emit those to module files; check non-static EQUIVALENCE
sets for conflicting default component initializations, so lowering
doesn't have to check them or emit diagnostics.
Differential Revision: https://reviews.llvm.org/D109022
Due to how the LIT deals with module files,
this change stores and runs the scripts in
their own temporary directory to prevent
interference in-between different tests.
It also makes ``test_symbols.py`` be more
consistent with the other scripts.
Reviewed By: Meinersbur, awarzynski
Differential Revision: https://reviews.llvm.org/D107953
It may not be great practice to pass a procedure (or procedure pointer)
with an implicit interface as an actual argument to correspond with
a dummy procedure (pointer), but it's not an error. Change to a
warning, and modify tests accordingly.
Differential Revision: https://reviews.llvm.org/D108932
The double precision KindCode was ignored when building the interface
of specific intrinsic procedures leading to bad semantics checks.
Differential Revision: https://reviews.llvm.org/D108828
ApplyElementwise on character operation was always creating a result
ArrayConstructor with the length of the left operand. This is not
correct for concatenation and SetLength operations.
Compute and thread the length to the spot creating the ArrayConstructor
so that the length is correct for those character operations.
Differential Revision: https://reviews.llvm.org/D108711
Use gettimeofday and localtime_r to implement DATE_AND_TIME intrinsic.
The Windows version fallbacks to the "no date and time information
available" defined by the standard (strings set to blanks and values to
-HUGE).
The implementation uses an ifdef between windows and the rest because
from my tests, the SFINAE approach leads to undeclared name bogus errors
with clang 8 that seems to ignore failure to instantiate is not an error
for the function names (i.e., it understands it should not instantiate
the version using gettimeofday if it is not there, but still yields an
error that it is not declared on the spot where it is called in the
uninstantiated version).
Differential Revision: https://reviews.llvm.org/D108622
The index of an implied DO loop in a DATA statement or array
constructor is defined by Fortran 2018 to have scope over its
implied DO loop. This definition is unfortunate, because it
requires the implied DO loop's bounds expressions to be in the
scope of the index variable. Consequently, in code like
integer, parameter :: j = 5
real, save :: a(5) = [(j, j=1, j)]
the upper bound of the loop is a reference to the index variable,
not the parameter in the enclosing scope.
This patch limits the scope of the index variable to the "body"
of the implied DO loop as one would naturally expect, with a warning.
I would have preferred to make this a hard error, but most Fortran
compilers treat this case as f18 now does. If the standard
were to be fixed, the warning could be made optional.
Differential Revision: https://reviews.llvm.org/D108595
This patch cleans-up the file generation code in Flang's frontend
driver. It improves the layering between
`CompilerInstance::CreateDefaultOutputFile`,
`CompilerInstance::CreateOutputFile` and their various clients.
* Rename `CreateOutputFile` as `CreateOutputFileImpl` and make it
private. This method is an implementation detail.
* Instead of passing an `std::error_code` out parameter into
`CreateOutputFileImpl`, have it return Expected<>. This is a bit shorter
and idiomatic LLVM.
* Make `CreateDefaultOutputFile` (which calls `CreateOutputFileImpl`)
issue an error when file creation fails. The error code from
`CreateOutputFileImpl` is used to generate a meaningful diagnostic
message.
* Remove error reporting from `PrintPreprocessedAction::ExecuteAction`.
This is only for cases when output file generation fails. This is
handled in `CreateDefaultOutputFile` instead (see the previous point).
* Inline `AddOutputFile` into its only caller,
`CreateDefaultOutputFile`.
* Switch from `lvm::buffer_ostream` to `llvm::buffer_unique_ostream>`
for non-seekable output streams. This simplifies the logic in the driver
and was introduced for this very reason in [1]
* Moke sure that the diagnostics from the prescanner when running `-E`
(`PrintPreprocessedAction::ExecuteAction`) are printed before the actual
output is generated.
* Update comments, add test.
NOTE: This patch relands [2]. As suggested by Michael Kruse in the
post-commit/post-revert review, I've added the following:
```
config.errc_messages = "@LLVM_LIT_ERRC_MESSAGES@"
```
in Flang's `lit.site.cfg.py.in`. This way, `%errc_ENOENT` in
output-paths.f90 gets the correct value on Windows as well as on Linux.
[1] https://reviews.llvm.org/D93260
[2] fd21d1e198
Reviewed By: ashermancinelli
Differential Revision: https://reviews.llvm.org/D108390
We currently feed full files to Python's unified_diff.
It's not quite what we want though -
line-by-line comparison makes more sense
(we want to be able to identify missing/unnecessary lines)
and is also easier to parse for humans.
This patch makes sure that we compare one line at a time.
This change pretties up the output formatting in the script.
Output before:
```
!DEF:/m/s/xINTENT(IN)(Implicit)ObjectEntityREAL(4)
!DEF:/m/s/yINTENT(INOUT)(Implicit)ObjectEntityREAL(4)
-!-D-E-F-:-f-o-o-b-a-r-
puresubroutines(x,y)bind(c)
!REF:/m/s/x
intent(in)::x
```
Proposed output after:
```
!DEF:/m/s/xINTENT(IN)(Implicit)ObjectEntityREAL(4)
!DEF:/m/s/yINTENT(INOUT)(Implicit)ObjectEntityREAL(4)
-!DEF:foobar
puresubroutines(x,y)bind(c)
!REF:/m/s/x
intent(in)::x
```
Reviewed By: Meinersbur, awarzynski
Differential Revision: https://reviews.llvm.org/D107954
This reverts commit fd21d1e198.
The test added in this patch [1] is failing on Windows and causing the
Windows BuildBot [2] to fail. I don't see any obvious way to fix this,
so reverting in order to investigate.
[1] llvm-project/flang/test/Driver/output-paths.f90
[2] https://lab.llvm.org/buildbot/#/builders/172/builds/2077
This patch refactors the file generation API in Flang's frontend driver.
It improves the layering between `CreateDefaultOutputFile`,
`CreateOutputFile` (`CompilerInstance` methods) and their various
clients.
List of changes:
* Rename `CreateOutputFile` as `CreateOutputFileImpl` and make it
private. This method is an implementation detail.
* Instead of passing an `std::error_code` out parameter into
`CreateOutputFileImpl`, have it return Expected<>. This is a bit shorter
and more idiomatic LLVM.
* Make `CreateDefaultOutputFile` (which calls `CreateOutputFileImpl`)
issue an error when file creation fails. The error code from
`CreateOutputFileImpl` is used to generate a meaningful diagnostic
message.
* Remove error reporting from `PrintPreprocessedAction::ExecuteAction`.
This is only for cases when output file generation fails. This is
handled in `CreateDefaultOutputFile` instead (see the previous point).
* Inline `AddOutputFile` into its only caller,
`CreateDefaultOutputFile`.
* Switch from `lvm::buffer_ostream` to `llvm::buffer_unique_ostream>`
for non-seekable output streams. This simplifies the logic in the driver
and was introduced for this very reason in [1]
* Moke sure that the diagnostics from the prescanner when running `-E`
(`PrintPreprocessedAction::ExecuteAction`) are printed before the actual
output is generated.
* Update comments, add test.
[1] https://reviews.llvm.org/D93260
Differential Revision: https://reviews.llvm.org/D108390
Currently, `printHelp` behaves differently for options that:
* do not define `HelpText` (such options _are not printed_), and
* define its `HelpText` as `HelpText<"">` (such options _are printed_).
In practice, both approaches lead to no help text and `printHelp` should
treat them consistently. This patch addresses that by making
`printHelpt` check the length of the help text to be printed.
All affected tests have been updated accordingly. The option definitions
for llvm-cvtres have been updated with a short description or "Not
implemented" for options that are ignored by the tool.
Differential Revision: https://reviews.llvm.org/D107557
Replacing Hello World example Plugin with one that counts and prints the names of
functions and subroutines.
This involves changing the `PluginParseTreeAction` Plugin base class to
inherit from `PrescanAndSemaAction` class to get access to the Parse Tree
so that the Plugin can walk it.
Additionally, there are tests of this new Plugin to check it prints the correct
things in different circumstances.
Depends on: D106137
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D107089
This patch implements the following check for TARGET construct:
```
OpenMP Version 5.0 Target construct restriction: If a target update,
target data, target enter data, or target exit data construct is
encountered during execution of a target region, the behavior is
unspecified.
```
Also add one test case for the check.
Reviewed By: kiranchandramohan, clementval
Differential Revision: https://reviews.llvm.org/D106165
This patch implements the following check for TEAMS construct:
```
OpenMP Version 5.0 Teams construct restriction: A teams region can
only be strictly nested within the implicit parallel region or a target
region. If a teams construct is nested within a target construct, that
target construct must contain no statements, declarations or directives
outside of the teams construct.
```
Also add one test case for the check.
Reviewed By: kiranchandramohan, clementval
Differential Revision: https://reviews.llvm.org/D106335
This patch implements the following semantic checks for cancellation constructs:
```
OpenMP Version 5.0 Section 2.18.1: CANCEL construct restriction:
If construct-type-clause is taskgroup, the cancel construct must be
closely nested inside a task or a taskloop construct and the cancel
region must be closely nested inside a taskgroup region. If
construct-type-clause is sections, the cancel construct must be closely
nested inside a sections or section construct. Otherwise, the cancel
construct must be closely nested inside an OpenMP construct that matches
the type specified in construct-type-clause of the cancel construct.
OpenMP Version 5.0 Section 2.18.2: CANCELLATION POINT restriction:
A cancellation point construct for which construct-type-clause is
taskgroup must be closely nested inside a task or taskloop construct,
and the cancellation point region must be closely nested inside a
taskgroup region. A cancellation point construct for which
construct-type-clause is sections must be closely nested inside a
sections or section construct. A cancellation point construct for which
construct-type-clause is neither sections nor taskgroup must be closely
nested inside an OpenMP construct that matches the type specified in
construct-type-clause.
```
Also add test cases for the check.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D106538
https://reviews.llvm.org/D106137 added support for plugins in Flang. The
CMake configuration for plugins requires some LLVM variables that are
not available in out-of-tree builds (e.g. `LLVM_SHLIB_OUTPUT_INTDIR`).
This has caused the out-of-tree BuildBot worker to start failing:
* https://lab.llvm.org/buildbot/#/builders/175
This patch effectively disables plugins in out-of-tree builds and fixes
the configuration error. In order to support plugins in out-of-tree
builds, we would have to find a way to access the missing CMake
variables from LLVM. This could be implemented at a later time.
Differential Revision: https://reviews.llvm.org/D107973
Recent work in runtime assignments failed an assertion in fir-dev
while running tests (flang/test/Semantics/defined-ops.f90). This
test didn't fail in llvm-project/main because only the "new" Arm
driver is used now, and that only builds runtime derived type information
tables when some debug dumping options are enabled.
So add a reproducing test case to another test that is run with
-fdebug-dump-symbols, and fix the crash by emitting special procedure
binding information only for type-bound generic ASSIGNMENT(=) bindings
that are relevant to the runtime support library for use in intrinsic
assignment of derived types.
Differential Revision: https://reviews.llvm.org/D107918
Introducing a plugin API and a simple HelloWorld Plugin example.
This patch adds the `-load` and `-plugin` flags to frontend driver and
the code around using custom frontend actions from within a plugin
shared library object.
It also adds to the Driver-help test to check the help option with the
updated driver flags.
Additionally, the patch creates a plugin-example test to check the
HelloWorld plugin example runs correctly. As part of this, a new CMake
flag (`FLANG_BUILD_EXAMPLES`) is added to allow the example to be built
and for the test to run.
This Plugin API has only been tested on Linux.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D106137
When the upper bound is less than the lower bound, the extent is zero. This is
specified in section 8.5.8.2, paragraph 3.
Note that similar problems exist in the lowering code. This change only fixes
the problem for the front end.
I also added a test.
Differential Revision: https://reviews.llvm.org/D107832
https://reviews.llvm.org/D105464 did not correctly cover the case
where the symbol from the host procedure is use associated. Outside
of the mis-parsed ArrayRef case, flang was also creating a symbol with
HostAssociated details inside the internal procedure (pointing to the
use associated symbol in the host). That is what lowering expects.
This patch ensures the same logic is applied in the mis-parsed array-ref name
resolution (and the pointer target name resolution).
Differential Revision: https://reviews.llvm.org/D107759
Define an API for, and implement, runtime support for arbitrary
assignment of one descriptor's data to another, with full support for
(re)allocation of allocatables with finalization when necessary,
user-defined derived type assignment TBP calls, and intrinsic (default)
componentwise assignment of derived type instances with allocation of
automatic components. Also clean up API and implementation of
finalization/destruction using knowledge gained while studying
edge cases for assignment in the 2018 standard.
The look-up procedure for special procedure bindings in derived
types has been optimized from O(N) to O(1) since it will probably
matter more. This required some analysis in runtime derived type
description table construction in semantics and some changes to the
table schemata.
Executable Fortran tests have been developed; they'll be added
to the test base once they can be lowered and run by f18.
Differential Revision: https://reviews.llvm.org/D107678
Due to unavailability of Flang testing on Windows, the shell scripts
are being ported to Python. The following changes are being made in
this patch: removed test_symbols.sh and common.sh, and ported them
to Python. Changes to the tests themselves so that they use the
python scripts instead of the shell script.
Reviewed By: Meinersbur, awarzynski, kiranchandramohan
Differential Revision: https://reviews.llvm.org/D107041
This patch removes `f18`, a.k.a. the old driver. It is being replaced
with the new driver, `flang-new`, which has reached feature parity with
`f18` a while ago. This was discussed in [1] and also in [2].
With this change, `FLANG_BUILD_NEW_DRIVER` is no longer needed and is
also deleted. This means that we are making the dependency on Clang permanent
(i.e. it cannot be disabled with a CMake flag).
LIT set-up is updated accordingly. All references to `f18` or `f18.cpp`
are either updated or removed.
The `F18_FC` variable from the `flang` bash script is replaced with
`FLANG_FC`. The former is still supported for backwards compatibility.
[1] https://lists.llvm.org/pipermail/flang-dev/2021-June/000742.html
[2] https://reviews.llvm.org/D103177
Differential Revision: https://reviews.llvm.org/D105811
For boolean options, e.g. `-fxor-operator`/`-fno-xor-operator`, we ought
to be using TableGen multi-classes. This way, we only have to write one
definition to have both forms auto-generated. This patch refactors all
of Flang's boolean options to use two new multi-classes:
`OptInFC1FFOption` and `OptOutFC1FFOption`. These multi-classes are
based on `OptInFFOption`/`OptOutFFOption`, respectively. I've also
simplified the processing of the updated options in
CompilerInvocation.cpp.
With the new approach, "empty" help text (i.e. no `HelpText`) is now
replaced with an empty string (i.e. HelpText<"">). When running
flang-new --help, that's considered as non-empty help messages, which is
then printed (that's controlled by `printHelp` from
llvm/lib/Option/OptTable.cpp). This means that with this patch,
flang-new --help will start printing e.g. -fno-backslash, even though
there is no actual help text to print for this option (apart from the
empty string ""). Tests are updated accordingly.
Note that with this patch, both `-fxor-operator` and `-fno-xor-operator`
(and other boolean options refactored here) remain available in
`flang-new` and `flang-new -fc1`. In this respect, nothing changes. In a
forthcoming patch, I will refine this so that `flang-new -fc1` only
accepts `-ffoo` (`OptInFC1FFOption`) or `-fno-foo` (`OptOutCC1FFOption`).
For clarity, `OptInFFOption`/`OptOutFFOption` are renamed as
`OptInCC1FFOption`/`OptOutCC1FFOption`, respectively. Otherwise, this is
an NFC from Clang's perspective.
Differential Revision: https://reviews.llvm.org/D105881
Like the similar legacy extension FLOAT(), DFLOAT() represents a
conversion from default integer to DOUBLE PRECISION. Rewrite
into a conversion operation.
Differential Revision: https://reviews.llvm.org/D107489
Dummy procedures can be defined as subprograms with explicit
interfaces, e.g.
subroutine subr(dummy)
interface
subroutine dummy(x)
real :: x
end subroutine
end interface
! ...
end subroutine
but the symbol table had no means of marking such symbols as dummy
arguments, so predicates like IsDummy(dummy) would fail. Add an
isDummy_ flag to SubprogramNameDetails, analogous to the corresponding
flag in EntityDetails, and set/test it as needed.
Differential Revision: https://reviews.llvm.org/D106697
Rename the current -E option to "-E -Xflang -fno-reformat".
Add a new Parsing::EmitPreprocessedSource() routine to convert the
cooked character stream output of the prescanner back to something
more closely resembling output from a traditional preprocessor;
call this new routine when -E appears.
The new -E output is suitable for use as fixed form Fortran source to
compilation by (one hopes) any Fortran compiler. If the original
top-level source file had been free form source, the output will be
suitable for use as free form source as well; otherwise there may be
diagnostics about missing spaces if they were indeed absent in the
original fixed form source.
Unless the -P option appears, #line directives are interspersed
with the output (but be advised, f18 will ignore these if presented
with them in a later compilation).
An effort has been made to preserve original alphabetic character case
and source indentation.
Add -P and -fno-reformat to the new drivers.
Tweak test options to avoid confusion with prior -E output; use
-fno-reformat where needed, but prefer to keep -E, sometimes
in concert with -P, on most, updating expected results accordingly.
Differential Revision: https://reviews.llvm.org/D106727
Historically the builtin dialect has had an empty namespace. This has unfortunately created a very awkward situation, where many utilities either have to special case the empty namespace, or just don't work at all right now. This revision adds a namespace to the builtin dialect, and starts to cleanup some of the utilities to no longer handle empty namespaces. For now, the assembly form of builtin operations does not require the `builtin.` prefix. (This should likely be re-evaluated though)
Differential Revision: https://reviews.llvm.org/D105149
According to C7109, "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." This change
enforces that constraint for output list items.
I also added a general interface to determine if an expression is a BOZ
literal constant and changed all of the places I could find where it
could be used.
I also added a test.
This change stemmed from the following issue --
https://gitlab-master.nvidia.com/fortran/f18-stage/issues/108
Differential Revision: https://reviews.llvm.org/D106893
Since BOZ literal arguments are typeless, we cannot know how to pass them as
actual arguments to procedures with implicit interfaces. This change avoids
the problem by emitting an error message in such situations.
This change stemmed from the following issue --
https://github.com/flang-compiler/f18-llvm-project/issues/794
Differential Revision: https://reviews.llvm.org/D106831
Use derived type information tables to drive default component
initialization (when needed), component destruction, and calls to
final subroutines. Perform these operations automatically for
ALLOCATE()/DEALLOCATE() APIs for allocatables, automatics, and
pointers. Add APIs for use in lowering to perform these operations
for non-allocatable/automatic non-pointer variables.
Data pointer component initialization supports arbitrary constant
designators, a F'2008 feature, which may be a first for Fortran
implementations.
Differential Revision: https://reviews.llvm.org/D106297
The following semantic check is removed in OpenMP Version 5.0:
```
Taskloop simd construct restrictions: No reduction clause can be specified.
```
Also fix several typos.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D105874
Name resolution is always creating symbols with HostAssocDetails
for host variable names inside internal procedures. This helps lowering
identifying and dealing with such variables inside internal procedures.
However, the case where the variable appears in an ArrayRef mis-parsed
as a FunctionRef goes through a different name resolution path that did
not create such HostAssocDetails when needed. Pointer assignment RHS
are also skipping this path.
Add the logic to create HostAssocDetails for host symbols inisde internal
procedures that appear in mis-parsed ArrayRef or in pointer assignment RHS.
Differential Revision: https://reviews.llvm.org/D105464
With derived type description tables now available to the
runtime library, it is possible to implement the concept
of "child" I/O statements in the runtime and use them to
convert instances of derived type I/O data transfers into
calls to user-defined subroutines when they have been specified
for a type. (See Fortran 2018, subclauses 12.6.4.8 & 13.7.6).
- Support formatted, list-directed, and NAMELIST
transfers to internal parent units; support these, and unformatted
transfers, for external parent units.
- Support nested child defined derived type I/O.
- Parse DT'foo'(v-list) FORMAT data edit descriptors and passes
their strings &/or v-list values as arguments to the defined
formatted I/O routines.
- Fix problems with this feature encountered in semantics and
FORMAT valiation during development and end-to-end testing.
- Convert typeInfo::SpecialBinding from a struct to a class
after adding a member function.
Differential Revision: https://reviews.llvm.org/D104930
There are situations where the arguments of intrinsics must be
conformable, which is defined in section 3.36. This means they must
have "the same shape, or one being an array and the other being scalar".
But the check we were actually making was that their ranks were the same.
This change fixes that and adds a test for the UNPACK intrinsic, where
the FIELD argument "shall be conformable with MASK".
Differential Revision: https://reviews.llvm.org/D104936
This patch adds a new option for the new Flang driver:
`-fno-analyzed-objects-for-unparse`. The semantics are similar to
`-funparse-typed-exprs-to-f18-fc` from `f18`. For consistency, the
latter is replaced with `-fno-analyzed-objects-for-unparse`.
The new option controls the behaviour of the unparser (i.e. the action
corresponding to `-fdebug-unparse`). The default behaviour is to use the
analyzed objects when unparsing. The new flag can be used to turn this
off, so that the original parse-tree objects are used. The analyzed
objects are generated during the semantic checks [1].
This patch also updates the semantics of
`-fno-analyzed-objects-for-unparse`/`-funparse-typed-exprs-to-f18-fc`
in `f18`, so that this flag is always taken into account when `Unparse`
is used (this way the semantics in `f18` and `flang-new` are identical).
The added test file is based on example from Peter Steinfeld.
[1]
https://github.com/llvm/llvm-project/blob/main/flang/docs/Semantics.md
Differential Revision: https://reviews.llvm.org/D103612
Refactor the recently-implemented MAXVAL/MINVAL folding so
that the parts that can be used to implement other reduction
transformational intrinsic function folding are exposed.
Use them to implement folding of IALL, IANY, IPARITY,
SUM. and PRODUCT. Replace the folding of ALL & ANY to
use the new infrastructure and become able to handle DIM=
arguments.
Differential Revision: https://reviews.llvm.org/D104562
This patch adds the following nesting check for `barrier` constructs:
```
A barrier region may not be closely nested inside a worksharing, loop, task, taskloop, critical, ordered, atomic, or master region.
```
Also adds a test case for the check,
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D99888
This is *not* user-defined derived type I/O, but rather Fortran's
built-in capabilities for using derived type data in I/O lists
and NAMELIST groups.
This feature depends on having the derived type description tables
that are created by Semantics available, passed through compilation
as initialized static objects to which pointers can be targeted
in the descriptors of I/O list items and NAMELIST groups.
NAMELIST processing now handles component references on input
(e.g., "&GROUP x%component = 123 /").
The C++ perspectives of the derived type information records
were transformed into proper classes when it was necessary to add
member functions to them.
The code in Semantics that generates derived type information
was changed to emit derived type components in component order,
not alphabetic order.
Differential Revision: https://reviews.llvm.org/D104485
When a function is called in a specification expression, it must be
sufficiently defined, and cannot be a recursive call (10.1.11(5)).
The best fix for this is to change the contract for the procedure
characterization infrastructure to catch and report such errors,
and to guarantee that it does emit errors on failed characterizations.
Some call sites were adjusted to avoid cascades.
Differential Revision: https://reviews.llvm.org/D104330
Implement constant folding for the reduction transformational
intrinsic functions MAXVAL and MINVAL.
In anticipation of more folding work to follow, with (I hope)
some common infrastructure, these two have been implemented in a
new header file.
Differential Revision: https://reviews.llvm.org/D104337
The test added in https://reviews.llvm.org/D104305 will only work with
the new driver and should be marked as such.
Sending this without a review as it's fairly straightforward and fixes
test failures for developers that don't want to build the new driver.
When a program attempts to put something like a subprogram
into an array constructor, emit an error rather than crashing.
Differential Revision: https://reviews.llvm.org/D104336
Add a test to make sure the flang runtime doesn't pull in the C++
runtime libraries.
This is achieved by adding a C file that calls some functions from the
runtime (currently only CpuTime, but we should probably add anything
complicated enough, e.g. IO-related things). We force the C compiler to
use -std=c90 to make sure it's really in C mode (we don't really care
which version of the standard, this one is probably more widely
available). We only enable this test if CMAKE_C_COMPILER is set to
something (which is probably always true in practice).
This is a recommit of 7ddbf26, with 2 fixes:
* Replace C++ comments with C comments
* Only enable the test if libFortranRuntime.a exists (this might not be
the case if e.g. BUILD_SHARED_LIBS=On)
Differential Revision: https://reviews.llvm.org/D104290
Add a test to make sure the flang runtime doesn't pull in the C++
runtime libraries.
This is achieved by adding a C file that calls some functions from the
runtime (currently only CpuTime, but we should probably add anything
complicated enough, e.g. IO-related things). We force the C compiler to
use -std=c90 to make sure it's really in C mode (we don't really care
which version of the standard, this one is probably more widely
available). We only enable this test if CMAKE_C_COMPILER is set to
something (which is probably always true in practice).
Differential Revision: https://reviews.llvm.org/D104290
The new option will run the semantic checks and then dump the parse tree
and all the symbols. This is equivalent to running the driver twice,
once with `-fdebug-dump-parse-tree` and then with
the `-fdebug-dump-symbols` action flag.
Currently we wouldn't be able to achieve the same by simply running:
```
flang-new -fc1 -fdebug-dump-parse-tree -fdebug-dump-symbols <input-file>
```
That's because the new driver will only run one frontend action per
invocation (both of the flags used here are action flags). Diverging
from this design would lead to costly compromises and it's best avoided.
We may want to consider re-designing our debugging actions (and action
options) in the future so that there's more code re-use. For now, I'm
focusing on making sure that we support all the major cases requested by
our users.
Differential Revision: https://reviews.llvm.org/D104305
I added the only check that wasn't already tested along with tests for
many valid and invalid arguments.
Differential Revision: https://reviews.llvm.org/D104318
This patch adds the 4th Fortran specific semantic check for the OpenMP
allocate directive: "If a list item has the SAVE attribute, is a common
block name, or is declared in the scope of a module, then only predefined
memory allocator parameters can be used in the allocator clause".
Code in this patch was based on code from https://reviews.llvm.org/D93549/new/.
Differential Revision: https://reviews.llvm.org/D102400
It's possible to have several USE statements for the same module that
have different mixes of rename clauses and ONLY clauses. The presence
of a rename cause has the effect of hiding a previously associated name,
and the presence of an ONLY clause forces the name to be visible even in
the presence of a rename.
I fixed this by keeping track of the names that appear on rename and ONLY
clauses. Then, when processing the USE association of a name, I check to see
if it previously appeared in a rename clause and not in a USE clause. If so, I
remove its USE associated symbol. Also, when USE associating all of the names
in a module, I do not USE associate names that have appeared in rename clauses.
I also added a test.
Differential Revision: https://reviews.llvm.org/D104130
Allow the lit test suite to run under Windows. This encompasses the following changes:
* Define `lit_tools_dir` for flang's test configuration
* Replace `(<command> || true)` idiom with `not <command>`
* Add `REQUIRES: shell` on tests that invoke a shell script
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D89368
Adding the `-init-only` option and corresponding frontend action to
generate a diagnostic.
`-init-only` vs `-test-io`:
`-init-only` ignores the input (it never calls the prescanner)
`-test-io` is similar to `-init-only`, but does read and print the input
without calling the prescanner.
This patch also adds a Driver test to check this action.
Reviewed By: awarzynski, AMDChirag
Differential Revision: https://reviews.llvm.org/D102849
It's possible to specify refer to an undefined derived type as the type of a
component of another derived type and then never define the type of the
component. We were not detecting this situation. To fix this, I
changed the value of isForwardReferenced_ in the symbol's
DerivedTypeDetails and checked for it when performing other derived type
checks.
I also had to record the fact that error messages were previously
emitted for the same problem in some cases so that I could avoid
duplicate messages.
I also added a test.
Differential Revision: https://reviews.llvm.org/D103714
Implement the following semantic check:
"A list item may not appear in a linear clause, unless it is the loop iteration variable."
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D100224
With this patch, the following invocation of the frontend driver will
return an error:
```
flang-new -fc1 input-file.f90 -o
```
Similar logic applies to other options that require arguments.
Similar checks are already available in the compiler driver, flang-new
(that's implemented in clangDriver).
Differential Revision: https://reviews.llvm.org/D103554
This option is supported in `f18`, but not yet available in `flang-new`.
It is required in order to call `flang-new` from the `flang` bash
script.
Differential Revision: https://reviews.llvm.org/D103613
A recent change was made in https://reviews.llvm.org/D101482 to cope
with kind parameters. It had the side effect of generating some type
info symbols inside derived type scopes. Derived type scope symbols
are meant for components, and other/later compilation phases might
choke when finding compiler generated symbols there that are not
components.
This patch preserves the fix from D101482 while still generating the
symbols outside of derived type scopes.
Differential Revision: https://reviews.llvm.org/D103621
When a procedure pointer with no interface is called by a
function reference, complain about the lack.
Differential Revision: https://reviews.llvm.org/D103573
The constexpr-capable class evaluate::DynamicType represented
CHARACTER length only with a nullable pointer into the declared
parameters of types in the symbol table, which works fine for
anything with a declaration but turns out to not suffice to
describe the results of the ACHAR() and CHAR() intrinsic
functions. So extend DynamicType to also accommodate known
constant CHARACTER lengths, too; use them for ACHAR & CHAR;
clean up several use sites and fix regressions found in test.
Differential Revision: https://reviews.llvm.org/D103571
It's possible to specify defined input/output procedures either as a
type-bound procedure of a derived type or as a defined-io-generic-spec. This
means that you can specify the same procedure in both mechanisms, which does
not cause problems. Alternatively, you can specify two different procedures to
be the defined input/output procedure for the same derived type. This is an
error. This change catches this error. The situation is slightly complicated
by parameterized derived types. Types with the same value for a KIND parameter
are treated as the same type while types with different KIND parameters are
treated as different types.
I implemented this check by adding a vector to keep track of which defined
input/output procedures had been seen for which derived types along with the
kind of procedure (read vs write and formatted vs unformatted). I also added
tests for non-parameterized types and types parameterized by KIND and LEN type
parameters.
I also removed an erroneous check from the code that creates runtime type
information.
Differential Revision: https://reviews.llvm.org/D103560
Each var argument to an attach or detach clause must be a
Fortran variable or array with the pointer or allocatable attribute.
This patch enforce this restruction.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D103279
This patch adds the following Fortran specific semantic checks for the OpenMP
Allocate directive.
1) A type parameter inquiry cannot appear in an ALLOCATE directive.
2) List items specified in the ALLOCATE directive must not have the ALLOCATABLE
attribute unless the directive is associated with an ALLOCATE statement.
Co-authored-by: Irina Dobrescu <irina.dobrescu@arm.com>
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D102061
Defined input/output procedures are specified in 12.6.4.8. There are different
versions for read versus write and formatted versus unformatted, but they all
share the same basic set of dummy arguments.
I added several checking functions to check-declarations.cpp along with a test.
In the process of implementing this, I noticed and fixed a typo in
.../lib/Evaluate/characteristics.cpp.
Differential Revision: https://reviews.llvm.org/D103045
Dummy arguments of ENTRY statements in execution parts were
not being created as objects, nor were they being implicitly
typed.
When the symbol corresponding to an alternate ENTRY point
already exists (by that name) due to having been referenced
in an earlier call, name resolution used to delete the extant
symbol. This isn't the right thing to do -- the extant
symbol will be pointed to by parser::Name nodes in the parse
tree while no longer being part of any Scope.
Differential Review: https://reviews.llvm.org/D102948
- Replace class(*) member by a c_ptr member to avoid having to handle
polymorphic components in the type info table generation. Polymorphic
entity handling will require these very tables to be lowered properly.
Note: keep the init as NullPointer/Designators. This is technically
invalid Fortran, the init should have c_ptr type. But wrapping this
in a C_LOC intrinsic call would make runtime generation and lowering
more complex with no real benefits.
- ComponentIterator is crashing when used on the generated derived
types in GetScope. This patch makes GetScope more robust, but it
is not entirely clear to me why this is only happening with the
generated derived types.
- The type of generated character globals was incorrect because
Scope::FindType was matching character types with different
length. Add a CharacterTypeSpec == operator to fix this.
Differential Revision: https://reviews.llvm.org/D102768
This patch implements the following semantic check:
```
A master region may not be closely nested inside a work-sharing, loop, atomic, task, or taskloop region.
```
Adds a test case and also modifies a couple of existing test cases to include the check.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D100228
We sometimes unroll an ac-implied-do of an array constructor into a flat list
of values. We then re-analyze the array constructor that contains the
resulting list of expressions. Such a list may or may not contain errors.
But when processing an array constructor with an unrolled ac-implied-do, the
compiler was building an expression to represent the extent of the resulting
array constructor containing the list of values. The number of operands
in this extent expression was based on the number of elements in the
unrolled list of values. For very large lists, this created an
expression so large that it could not be evaluated by the compiler
without overflowing the stack.
I fixed this by continuously folding the extent expression as each operand is
added to it. I added the test .../flang/test/Semantics/array-constr-big.f90
that will cause the compiler to seg fault without this change.
Also, when the unrolled ac-implied-do expression contains errors, we were
repeating the same error message referencing the same source line for every
instance of the erroneous expression in the unrolled list. This potentially
resulted in a very long list of messages for a single error in the source code.
I fixed this by comparing the message being emitted to the previously emitted
message. If they are the same, I do not emit the message. This change is also
tested by the new test array-constr-big.f90.
Several of the existing tests had duplicate error messages for the same source
line, and this change caused differences in their output. So I adjusted the
tests to match the new message emitting behavior.
Differential Revision: https://reviews.llvm.org/D102210
`%f18` was originally introduced to represent the old Flang driver,
`f18`. With the introduction of the new driver, `flang-new`, we have
been switching to `%flang` (compiler driver) and `%flang_fc1` (frontend
driver) as more generic alternatives.
As most tests have been portend to use the new LIT variables instead of
`%f18`, this is good time to remove it from lit.cfg.py. There's only one
test left that requires the old driver to run. It's updated with:
```
! REQUIRES: old-flang-driver
```
This way we preserve its semantics while reducing the number of
variables in LIT configuration.
Differential Revision: https://reviews.llvm.org/D101281
When producing the runtime type information for a component of a derived type
that had a LEN type parameter, we were not allowing a KIND parameter of the
derived type. This was causing one of the NAG correctness tests to fail
(.../hibiya/d5.f90).
I added a test to our own test suite to check for this.
Also, I fixed a typo in .../module/__fortran_type_info.f90.
I allowed KIND type parameters to be used for the declarations of components
that use LEN parameters by constant folding the value of the LEN parameter. To
make the constant folding work, I had to put the semantics::DerivedTypeSpec of
the associated derived type into the folding context. To get this
semantics::DerivedTypeSpec, I changed the value of the semantics::Scope object
that was passed to DescribeComponent() to be the derived type scope rather than
the containing non-derived type scope.
This scope change, in turn, caused differences in the symbol table output that
is checked in typeinfo01.f90. Most of these differences were in the order that
the symbols appeared in the dump. But one of them changed one of the values
from "CHARACTER(2_8,1)" to "CHARACTER(1_8,1)". I'm not sure if these changes
are significant. Please verify that the results of this test are still valid.
Also, I wonder if there are other situations in this code where we should be
folding constants. For example, what if the field of a component has a
component whose type is a PDT with a LEN type parameter, and the component's
declaration depends on the KIND type parameter of the current PDT. Here's an
example:
type string(stringkind)
integer,kind :: stringkind
character(stringkind) :: value
end type string
type outer(kindparam)
integer,kind :: kindparam
type(string(kindparam)) :: field
end type outer
I don't understand the code or what it's trying to accomplish well enough to
figure out if such cases are correctly handled by my new code.
Differential Revision: https://reviews.llvm.org/D101482
We were not correctly handling structure constructors that had forward
references to parameterized derived types. I harvested the code that checks
for forward references that was used during analysis of function call
expressions and called it from there and also called it during the
analysis of structure constructors.
I also added a test that will produce an internal error without this change.
Differential Revision: https://reviews.llvm.org/D101330
We were not checking that attributes that are supposed to be specific to
dummy arguments were not being used for local entities. I added the checks
along with tests for them.
After implementing these new checks, I found that one of the tests in
separate-mp02.f90 was erroneous, and I fixed it.
Differential Revision: https://reviews.llvm.org/D101126
When generating output for `-fdebug-dump-symbols`, make sure that
BuildRuntimeDerivedTypeTables is also run. This change is needed in
order to make the implementation of `-fdebug-dump-symbols` in
`flang-new` consistent with `f18`. It also allows us to port more tests
to use the new driver whenever it is enabled.
Differential Revision: https://reviews.llvm.org/D100649
This patch updates the final test that can be shared between the old and
the new Flang drivers and that has not been ported yet. %f18 (always
expanded as `f18`) is replaced with %flang_fc1 (expanded as either `f18`
or `flang-new -fc1`, depending on `FLANG_BUILD_NEW_DRIVER`).
This test should've been updated in https://reviews.llvm.org/D100309,
but I missed it then. That's because this test contains non-ascii
characters and `grep -I %f18` (as well as other grep-like tools) skips
it because it's interpreted as a data/binary file. In fact, it's just a
text file with non-ascii chars.
Since this is an obvious omission from D100309 (reviewed, accepted and
merged), I'm sending this without a review to reduce the noise on
Phabricator.
Switching from `%f18` to `%flang_fc1` in LIT tests added in
https://reviews.llvm.org/D91159. This way these tests are run with the
new driver, `flang-new`, when enabled (i.e. when
`FLANG_BUILD_NEW_DRIVER` is set).
Differential Revision: https://reviews.llvm.org/D101078
Andrezj W. @ Arm discovered that the runtime derived type table
building code in semantics was detecting fatal errors in the tests
that the f18 driver wasn't printing. This patch fixes f18 so that
these messages are printed; however, the messages were not valid user
errors, and the rest of this patch fixes them up.
There were two sources of the bogus errors. One was that the runtime
derived type information table builder was calculating the shapes of
allocatable and pointer array components in derived types, and then
complaining that they weren't constant or LEN parameter values, which
of course they couldn't be since they have to have deferred shapes
and those bounds were expressions like LBOUND(component,dim=1).
The second was that f18 was forwarding the actual LEN type parameter
expressions of a type instantiation too far into the uses of those
parameters in various expressions in the declarations of components;
when an actual LEN type parameter is not a constant value, it needs
to remain a "bare" type parameter inquiry so that it will be lowered
to a descriptor inquiry and acquire a captured expression value.
Fixing this up properly involved: moving some code into new utility
function templates in Evaluate/tools.h, tweaking the rewriting of
conversions in expression folding to elide needless integer kind
conversions of type parameter inquiries, making type parameter
inquiry folding *not* replace bare LEN type parameters with
non-constant actual parameter values, and cleaning up some
altered test results.
Differential Revision: https://reviews.llvm.org/D101001
This patch adds semantic checks for the General Restrictions of the
Allocate Directive.
Since the requires directive is not yet implemented in Flang, the
restriction:
```
allocate directives that appear in a target region must
specify an allocator clause unless a requires directive with the
dynamic_allocators clause is present in the same compilation unit
```
will need to be updated at a later time.
A different patch will be made with the Fortran specific restrictions of
this directive.
I have used the code from https://reviews.llvm.org/D89395 for the
CheckObjectListStructure function.
Co-authored-by: Isaac Perry <isaac.perry@arm.com>
Reviewed By: clementval, kiranchandramohan
Differential Revision: https://reviews.llvm.org/D91159
We were erroneously not taking into account the constant values of LEN type
parameters of parameterized derived types when checking for argument
compatibility. The required checks are identical to those for assignment
compatibility. Since argument compatibility is checked in .../lib/Evaluate and
assignment compatibility is checked in .../lib/Semantics, I moved the common
code into .../lib/Evaluate/tools.cpp and changed the assignment compatibility
checking code to call it.
After implementing these new checks, tests in resolve53.f90 were failing
because the tests were erroneous. I fixed these tests and added new tests
to call03.f90 to test argument passing of parameterized derived types more
completely.
Differential Revision: https://reviews.llvm.org/D100989
This patch adds `-fget-definition` to `flang-new`. The semantics of this
option are identical in both drivers. The error message in the
"throwaway" driver is updated so that it matches the one from
`flang-new` (which is auto-generated and cannot be changed easily).
Tests are updated accordingly. A dedicated test for error handling was
added: get-definition.f90 (for the sake of simplicity,
getdefinition01.f90 no longer tests for errors).
The `ParseFrontendArgs` function is updated so that it can return
errors. This change is required in order to report invalid values
following `-fget-definition`.
The actual implementation of `GetDefinitionAction::ExecuteAction()` was
extracted from f18.cpp (i.e. the bit that deals with
`-fget-definition`).
Depends on: https://reviews.llvm.org/D100556
Differential Revision: https://reviews.llvm.org/D100558
We were erroneously emitting error messages for assignments of derived types
where the associated objects were instantiated with non-constant LEN type
parameters.
I fixed this by adding the member function MightBeAssignmentCompatibleWith() to
the class DerivedTypeSpec and calling it to determine whether it's possible
that objects of parameterized derived types can be assigned to each other. Its
implementation first compares the uninstantiated values of the types. If they
are equal, it then compares the values of the constant instantiated type
parameters.
I added tests to assign04.f90 to exercise this new code.
Differential Revision: https://reviews.llvm.org/D100868
This is similar to https://reviews.llvm.org/D100309, i.e. `%f18` is
replaced with `%flang_new`.
resolve105.f90 wasn't in tree when D100309 was worked on, so it's
updated here instead.
label14.f90 requires `-fsyntax-only`. I didn't notice that when
submitting D100309, hence updating it now instead. `-fsyntax-only` is
required to prevent `%f18` from calling an external compiler (which then
fails and returns a non-zero exit code).
Differential Revision: https://reviews.llvm.org/D100655
This patch updates most of the remaining regression tests (~400) to use
`flang-new` rather then `f18` when `FLANG_BUILD_NEW_DRIVER` is set.
This allows us to share more Flang regression tests between `f18` and
`flang-new`. A handful of tests have not been ported yet - these are
currently either failing or not supported by the new driver.
Summary of changes:
* RUN lines in tests are updated to use `%flang_fc1` instead of `%f18`
* option spellings in tests are updated to forms accepted by both `f18` and
`flang-new`
* variables in Bash scripts are renamed (e.g. F18 --> FLANG_FC1)
The updated tests will now be run with the new driver, `flang-new`,
whenever it is enabled (i.e when `FLANG_BUILD_NEW_DRIVER` is set).
Although this patch touches many files, vast majority of the changes are
automatic:
```
grep -IEZlr "%f18" flang/test/ | xargs -0 -l sed -i 's/%f18/%flang_fc1/g
```
Differential Revision: https://reviews.llvm.org/D100309
We were not instantiating procedure pointer components. If the instantiation
contained errors, we were not reporting them. This resulted in internal errors
in later processing.
I fixed this by adding code in .../lib/Semantics/type.cpp in
InstantiateComponent() to handle a component with ProcEntityDetails. I also
added several tests for various good and bad instantiations of procedure
pointer components.
Differential Revision: https://reviews.llvm.org/D100341
`%flang-new` was introduced in the early days of the new driver to make
a clear distinction between the tests for the current and the new
driver. We have since introduced `%flang` (compiler driver) and
`%flang_fc1` (frontend driver) as the long term solution. This has allowed
us to share tests between `flang-new` and `f18`. This patch replaces
all uses of `%flang-new` with `%flang` and `%flang_fc1`.
Some tests are reformatted so that all tests look uniform and are easier
to follow. Where possible, `! REQUIRES: new-flang-driver` is deleted so
that more tests can be shared with `f18`. To facilitate this,
`f{no-}implicit-none` are introduced in `f18` with semantics identical
to `flang-new`.
Two tests are deleted rather than updated:
* flang/test/Frontend/print-preprocess-C-file.f90
* flang/test/Frontend/print-preprocessed-file.f90
Instead, there is plenty of preprocessor tests in
flang/test/Preprocessing/.
Differential Revision: https://reviews.llvm.org/D100174
With the typo ($S instead of %s), the driver was expecting
input from stdin. In such cases, it prints:
```
Enter Fortran source
Use EOF character (^D) to end file
```
This was piped to FileCheck. Together with the available `CHECK-NOT`
statement, this was sufficient for the test to pass (incorrectly).
This patch makes sure that the provided input file is used instead of
stdin.
Differential Revision: https://reviews.llvm.org/D100301
F18 supports the standard intrinsic function SELECTED_REAL_KIND
but not its synonym in the standard module IEEE_ARITHMETIC
named IEEE_SELECTED_REAL_KIND until this patch.
Differential Revision: https://reviews.llvm.org/D100066
Check for two or more symbols that define a data object or entry point
with the same interoperable BIND(C) name.
Differential Revision: https://reviews.llvm.org/D100067
This patch adds two debugging options in the new Flang driver
(flang-new):
*fdebug-unparse-no-sema
*fdebug-dump-parse-tree-no-sema
Each of these options combines two options from the "throwaway" driver
(left: f18, right: flang-new):
* `-fdebug-uparse -fdebug-no-semantics` --> `-fdebug-unparse-no-sema`
* `-fdebug-dump-parse-tree -fdebug-no-semantics` -->
`-fdebug-dump-parse-tree-no-sema`
There are no plans to implement `-fdebug-no-semantics` in the new
driver. Such option would be too powerful. Also, it would only make
sense when combined with specific frontend actions (`-fdebug-unparse`
and `-fdebug-dump-parse-tree`). Instead, this patch adds 2 specialised
options listed above. Each of these is implemented through a dedicated
FrontendAction (also added).
The new frontend actions are implemented in terms of a new abstract base
action: `PrescanAndSemaAction`. This new base class was required so that
we can have finer control over what steps within the frontend are
executed:
* `PrescanAction`: run the _prescanner_
* `PrescanAndSemaAction`: run the _prescanner_ and the _parser_ (new
in this patch)
* `PrescanAndSemaAction`: run the _prescanner_, _parser_ and run the
_semantic checks_
This patch introduces `PrescanAndParseAction::BeginSourceFileAction`.
Apart from the semantic checks removed at the end, it is similar to
`PrescanAndSemaAction::BeginSourceFileAction`.
Differential Revision: https://reviews.llvm.org/D99645
The -fdebug-dump-provenance flag is meant to be used with
needProvenanceRangeToCharBlockMappings set to true. This way, extra
mapping is generated that allows e.g. IDEs to retrieve symbol's scope
(offset into cooked character stream) based on symbol's source code
location. This patch makes sure that this option is set when using
-fdebug-dump-provenance.
With this patch, the implementation of -fdebug-dump-provenance in
`flang-new -fc1` becomes consistent with `f18`. The corresponding LIT
test is updated so that it can be shared with `f18`. I refined it a bit
so that:
* it becomes a frontend-only test
* it's stricter about the expected output
Differential Revision: https://reviews.llvm.org/D98847
This patch adds support for the `-cpp` and `-nocpp` flags. The
implemented semantics match f18 (i.e. the "throwaway" driver), but are
different to gfortran. In Flang the preprocessor is always run. Instead,
`-cpp/-nocpp` are used to control whether predefined and command-line
preprocessor macro definitions are enabled or not. In practice this is
sufficient to model gfortran`s `-cpp/-nocpp`.
In the absence of `-cpp/-nocpp`, the driver will use the extension of
the input file to decide whether to include the standard macro
predefinitions. gfortran's documentation [1] was used to decide which
file extension to use for this.
The logic mentioned above was added in FrontendAction::BeginSourceFile.
That's relatively late in the driver set-up, but this roughly where the
name of the input file becomes available. The logic for deciding between
fixed and free form works in a similar way and was also moved to
FrontendAction::BeginSourceFile for consistency (and to reduce
code-duplication).
The `-cpp/-nocpp` flags are respected also when the input is read from
stdin. This is different to:
* gfortran (behaves as if `-cpp` was used)
* f18 (behaves as if `-nocpp` was used)
Starting with this patch, file extensions are significant and some test
files had to be renamed to reflect that. Where possible, preprocessor
tests were updated so that they can be shared between `f18` and
`flang-new`. This was implemented on top of adding new test for
`-cpp/-nocpp`.
[1] https://gcc.gnu.org/onlinedocs/gcc/Overall-Options.html
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D99292
We were not folding type parameter inquiries for the form 'var%typeParam'
where 'typeParam' was a KIND or LEN type parameter of a derived type and 'var'
was a designator of the derived type. I fixed this by adding code to the
function 'FoldOperation()' for 'TypeParamInquiry's to handle this case. I also
cleaned up the code for the case where there is no designator.
In order to make the error messages correctly refer to both the points of
declaration and instantiation, I needed to add an argument to the function
'InstantiateIntrinsicType()' for the location of the instantiation.
I also changed the formatting of 'TypeParamInquiry' to correctly format this
case. I also added tests for both KIND and LEN type parameter inquiries in
resolve104.f90.
Making these changes revealed an error in resolve89.f90 and caused one of the
error messages in assign04.f90 to be different.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D99892
We were not folding type parameter inquiries for the form 'var%typeParam'
where 'typeParam' was a KIND or LEN type parameter of a derived type and 'var'
was a designator of the derived type. I fixed this by adding code to the
function 'FoldOperation()' for 'TypeParamInquiry's to handle this case. I also
cleaned up the code for the case where there is no designator.
In order to make the error messages correctly refer to both the points of
declaration and instantiation, I needed to add an argument to the function
'InstantiateIntrinsicType()' for the location of the instantiation.
I also changed the formatting of 'TypeParamInquiry' to correctly format this
case. I also added tests for both KIND and LEN type parameter inquiries in
resolve104.f90.
Making these changes revealed an error in resolve89.f90 and caused one of the
error messages in assign04.f90 to be different.
Differential Revision: https://reviews.llvm.org/D99892
f18 was emitting a bogus error message about the lack of a TARGET
attribute when a pointer was initialized with a component of a
variable that was a legitimate TARGET.
Differential Revision: https://reviews.llvm.org/D99665
When writing tests for a previous problem, I ran across situations where the
compiler was failing calls to CHECK(). In these situations, the compiler had
inconsistent semantic information because the programs were erroneous. This
inconsistent information was causing the calls to CHECK().
I fixed this by avoiding the code that ended up making the failed calls to
CHECK() and making sure that we were only avoiding these situations when the
associated symbols were erroneous.
I also added tests that would cause the calls to CHECK() without these changes.
Differential Revision: https://reviews.llvm.org/D99342
Folding of LOGICAL intrinsic procedure was missing in the front-end causing
crash when using it in parameter expressions.
Simply fold LOGICAL calls to evaluate::Convert<T>.
Differential Revision: https://reviews.llvm.org/D99346
Before the conversion to LLVM-IR dialect and ultimately LLVM IR, FIR is
partially rewritten into a codegen form. This patch adds that pass, the
fircg dialect, and the small set of Ops in the fircg (sub) dialect.
Fircg is not part of the FIR dialect and should never be used outside of
the (closed) conversion to LLVM IR.
Authors: Eric Schweitz, Jean Perier, Rajan Walia, et.al.
Differential Revision: https://reviews.llvm.org/D98063
Binding labels start as expressions but they have to evaluate to
constant character of default kind, so they can be represented as an
std::string. Leading and trailing blanks have to be removed, so the
folded expression isn't exactly right anyway.
So all BIND(C) symbols now have a string binding label, either the
default or user-supplied one. This is recorded in the .mod file.
Add WithBindName mix-in for details classes that can have a binding
label so that they are all consistent. Add GetBindName() and
SetBindName() member functions to Symbol.
Add tests that verifies that leading and trailing blanks are ignored
in binding labels and that the default label is folded to lower case.
Differential Revision: https://reviews.llvm.org/D99208
Binding labels start as expressions but they have to evaluate to
constant character of default kind, so they can be represented as an
std::string. Leading and trailing blanks have to be removed, so the
folded expression isn't exactly right anyway.
So all BIND(C) symbols now have a string binding label, either the
default or user-supplied one. This is recorded in the .mod file.
Add WithBindName mix-in for details classes that can have a binding
label so that they are all consistent. Add GetBindName() and
SetBindName() member functions to Symbol.
Add tests that verifies that leading and trailing blanks are ignored
in binding labels and that the default label is folded to lower case.
Differential Revision: https://reviews.llvm.org/D99208
When writing tests for a previous problem, I ran across situations where we
were not producing error messages for declarations of specific procedures of
generic interfaces where every other compiler I tested (except nvfotran) did.
I added a check to CheckExtantExternal() and renamed it since it now checks for
erroneous extant symbols generally.
I also removed a call to this function from processing for ENTRY statements,
since it seemed unnecessary and its presence caused bogus error messages.
I also added some tests for erroneous declarations where we were not producing
error messages.
Differential Revision: https://reviews.llvm.org/D99111
If you specify a specific procedure of a generic interface that has the same
name as both the generic interface and a preceding derived type, the compiler
would fail an internal call to CHECK(). I fixed this by testing for this
situation when processing specific procedures. I also added a test that will
cause the call to CHECK() to fail without this new code.
Differential Revision: https://reviews.llvm.org/D99085
This patch fixes a bug to allow ordered construct within a non-worksharing loop, also adds more sema checks.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D98733
Replace semantics::SymbolSet with alternatives that clarify
whether the set should order its contents by source position
or not. This matters because positionally-ordered sets must
not be used for Symbols that might be subjected to name
replacement during name resolution, and address-ordered
sets must not be used (without sorting) in circumstances
where the order of their contents affects the output of the
compiler.
All set<> and map<> instances in the compiler that are keyed
by Symbols now have explicit Compare types in their template
instantiations. Symbol::operator< is no more.
Differential Revision: https://reviews.llvm.org/D98878
Adds support for `-fget-symbols-sources` in the new Flang driver. All
relevant tests are updated to use the new driver when
`FLANG_BUILD_NEW_DRIVER` is set.
`RUN` lines in tests are updated so `-fsyntax-only`
comes before `-fget-symbols-sources`. That's because:
* both `-fsyntax-only` and `-fget-symbols-sources` are
action flags, and
* the new driver, flang-new, will only consider the right-most
action flag.
In other words, this change is needed so that the tests work with both
`f18` (requires both flags) and `flang-new` (only considers the last
action flag).
Differential Revision: https://reviews.llvm.org/D98191
In parser::AllCookedSources, implement a map from CharBlocks to
the CookedSource instances that they cover. This permits a fast
Find() operation based on std::map::equal_range to map a CharBlock
to its enclosing CookedSource instance.
Add a creation order number to each CookedSource. This allows
AllCookedSources to provide a Precedes(x,y) predicate that is a
true source stream ordering between two CharBlocks -- x is less
than y if it is in an earlier CookedSource, or in the same
CookedSource at an earlier position.
Add a reference to the singleton SemanticsContext to each Scope.
All of this allows operator< to be implemented on Symbols by
means of a true source ordering. From a Symbol, we get to
its Scope, then to the SemanticsContext, and then use its
AllCookedSources reference to call Precedes().
Differential Revision: https://reviews.llvm.org/D98743
Implement INDEX in the runtime, reusing some infrastructure
(with generalization and renaming as needed) put into place
for its cousins SCAN and VERIFY.
I did not implement full Boyer-Moore substring searching
for the forward case, but did accelerate some advancement on
mismatches.
I (re)implemented unit testing for INDEX in the new gtest
framework, combining it with the tests that have recently
been ported to gtest for SCAN and VERIFY.
Differential Revision: https://reviews.llvm.org/D98553
The build was putting .mod files for intrinsic modules in
tools/flang/include/flang but the install puts them in include/flang,
as does the out-of-tree build. This confused things for the driver.
This change makes the build consistent with the install and simplifies
the flang script accordingly.
Also, clean up the cmake commands for building the .mod files.
Differential Revision: https://reviews.llvm.org/D98522
Fortran permits a reference to a function whose result is a pointer
to be used as a definable variable in any context where a
designator could appear. This patch wrings out remaining bugs
with such usage and adds more testing.
The utility predicate IsProcedurePointer(expr) had a misleading
name which has been corrected to IsProcedurePointerTarget(expr).
Differential Revision: https://reviews.llvm.org/D98555
If you specify a type-bound procedure with an alternate return, there
will be no symbol associated with that dummy argument. In such cases,
the compiler's list of dummy arguments will contain a nullptr. In our
analysis of the PASS arguments of type-bound procedures, we were
assuming that all dummy arguments had non-null symbols associated with
them and were using that assumption to get the name of the dummy
argument. This caused the compiler to try to dereference a nullptr.
I fixed this by explicitly checking for a nullptr and, in such cases, emitting
an error message. I also added tests that contain type-bound procedures with
alternate returns in both legal and illegal constructs to ensure that semantic
analysis is working for them.
Differential Revision: https://reviews.llvm.org/D98430
You can define a base type with a type-bound procedure which is erroneously
missing a NOPASS attribute and then define another type that extends the base
type and overrides the erroneous procedure. In this case, when we perform
semantic checking on the overriding procedure, we verify the "pass index" of
the overriding procedure. The attempt to get the procedure's pass index fails
a call to CHECK().
I fixed this by calling SetError() on the symbol of the overridden procedure in
the base type. Then, I check HasError() before executing the code that invokes
the failing call to CHECK(). I also added a test that will cause the compiler
to fail the call to CHECK() without this change.
Differential Revision: https://reviews.llvm.org/D98355
In https://reviews.llvm.org/D98283, the RUN line in pre-fir-tree04.f90
was updated to use `%flang_fc1` instead of `%f18` (so that the test is
shared between the old and the new driver). Unfortunately, the new
driver does not know yet how to find standard intrinsics modules. As a
result, the test fails when `FLANG_BUILD_NEW_DRIVER` is set to On.
I'm restoring the original RUN line. This is rather straightforward, so
sending without a review. This should make Flang builders happy.
The PFT has been updated to support Fortran 77.
clang-tidy cleanup.
Authors: Val Donaldson, Jean Perier, Eric Schweitz, et.al.
Differential Revision: https://reviews.llvm.org/D98283
This patch adds `-fdebug-dump-parsing-log` in the new driver. This option is
semantically identical to `-fdebug-instrumented-parse` in `f18` (the
former is added as an alias in `f18`).
As dumping the parsing log makes only sense for instrumented parses, we
set Fortran::parser::Options::instrumentedParse to `True` when
`-fdebug-dump-parsing-log` is used. This is consistent with `f18`.
To facilitate tweaking the configuration of the frontend based on the
action being requested, `setUpFrontendBasedOnAction` is introduced in
CompilerInvocation.cpp.
Differential Revision: https://reviews.llvm.org/D97457
Until now we've been maintaining 2 test directories for Flang's drivers:
* test/Driver for `f18` (the current driver)
* test/Flang-Driver for `flang-new` (the new driver)
As we have started sharing tests between the drivers, this separation is
no longer required. This patch merges the two test directories. As
suggested in the review, moving forward we'll avoid having tests
specifically for the old driver.
A few notable changes:
* Driver/version-test.f90 and Driver/no-files.f90 are deleted. The
versions for the new driver are more robust, but tricky to share.
* Driver/write-module.f90 is deleted in favour of
Flang-Driver/write-module.f90 (see https://reviews.llvm.org/D97197
for more context)
Differential Revision: https://reviews.llvm.org/D98257
We have a "<" operator defined on the type semantics::Symbol that's based on
the symbols' locations in the cooked character stream. This is potentially
problematic when comparing symbols from .mod files when the cooked character
streams themselves might be allocated to varying memory locations.
This change fixes that by using the order in which symbols are created as the
basis for the "<" operator. Thanks to Tim and Peter for consultation on the
necessity of doing this and the idea for what to use as the basis of the sort.
This change in the "<" operator changed the expected results for three of the
tests. I manually inspected the new results, and they look OK to me. The
differences in data05.f90 and typeinfo01.f90 are entirely the order, offsets,
and sizes of the derived type components. The changes in resolve102.f90 are
due to the new, different "<" operator used for sorting.
Differential Revision: https://reviews.llvm.org/D98225
This patch refactors include-module.f90:
* rename the test file as use-module.f90 to better highlight which
driver feature is being tested
* move tests for diagnostics to use-module-error.f90 (it tests that
`-J/-module-dir` can only be used once)
* make sure that `f18` is tested when `FLANG_BUILD_NEW_DRIVER` is
set to `Off`
* add tests for when all module files are successfully discovered and
loaded
With this patch, there should be a clear separation into 3 scenarios in
use-module.f90:
* Everything is OK
* One module file wasn't found (missing include path for
basictestingmoduletwo.mod)
* Two module files are found, but the test requires
`basictestingmoduleone.mod` from both `Inputs` and `Inputs/module-dir`.
Only the latter is found.
Reviewed By: tskeith
Differential Revision: https://reviews.llvm.org/D97197
When we have a subprogram that has been determined to contain errors, we do not
perform name resolution on its execution part. In this case, if the subprogram
contains a NULLIFY statement, the parser::Name of a pointer object in a NULLIFY
statement will not have had name resolution performed on it. Thus, its symbol
will not have been set. Later, however, we do semantic checking on the NULLIFY
statement. The code that did this assumed that the parser::Name of the
pointer object was non-null.
I fixed this by just removing the null pointer check for the "symbol" member of
the "parser::Name" of the pointer object when doing semantic checking for
NULLIFY statements. I also added a test that will make the compiler crash
without this change.
Differential Revision: https://reviews.llvm.org/D98184
Add diagnostic tests with fir-opt for the diagnostics emitted by the ops verifier
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D97996
Add support for the following Fortran dialect options:
- -default*
- -flarge-sizes
It also adds two test cases:
# For checking whether `flang-new` is passing options correctly to `flang-new -fc1`.
# For checking if `fdefault-` arguments are processed properly.
Also moves the Dialect related option parsing to a dedicated function
and adds a member `defaultKinds()` to `CompilerInvocation`
Depends on: D96032
Differential Revision: https://reviews.llvm.org/D96344
We were allowing procedures with the MODULE prefix to be declared at the global
scope. This is prohibited by C1547 and was causing an internal check of the
compiler to fail.
I fixed this by adding a check. I also added a test that would trigger a crash
without this change.
Differential Revision: https://reviews.llvm.org/D97875
It's possible to define a procedure whose interface depends on a procedure
which has an interface that depends on the original procedure. Such a circular
definition was causing the compiler to fall into an infinite loop when
resolving the name of the second procedure. It's also possible to create
circular dependency chains of more than two procedures.
I fixed this by adding the function HasCycle() to the class DeclarationVisitor
and calling it from DeclareProcEntity() to detect procedures with such
circularly defined interfaces. I marked the associated symbols of such
procedures by calling SetError() on them. When processing subsequent
procedures, I called HasError() before attempting to analyze their interfaces.
Unfortunately, this did not work.
With help from Tim, we determined that the SymbolSet used to track the
erroneous symbols was instantiated using a "<" operator which was defined using
the location of the name of the procedure. But the location of the procedure
name was being changed by a call to ReplaceName() between the times that the
calls to SetError() and HasError() were made. This caused HasError() to
incorrectly report that a symbol was not in the set of erroneous symbols.
I fixed this by changing SymbolSet to be an unordered set that uses the
contents of the name of the symbol as the basis for its hash function. This
works because the contents of the name of the symbol is preserved by
ReplaceName() even though its location changes.
I also fixed the error message used when reporting recursively defined
dummy procedure arguments by removing extra apostrophes and sorting the
list of symbols.
I also added tests that will crash the compiler without this change.
Note that the "<" operator is used in other contexts, for example, in the map
of characterized procedures, maps of items in equivalence sets, maps of
structure constructor values, ... All of these situations happen after name
resolution has been completed and all calls to ReplaceName() have already
happened and thus are not subject to the problem I ran into when ReplaceName()
was called when processing procedure entities.
Note also that the implementation of the "<" operator uses the relative
location in the cooked character stream as the basis of its implementation.
This is potentially problematic when symbols from diffent compilation units
(for example symbols originating in .mod files) are put into the same map since
their names will appear in two different source streams which may not be
allocated in the same relative positions in memory. But I was unable to create
a test that caused a problem. Using a direct comparison of the content of the
name of the symbol in the "<" operator has problems. Symbols in enclosing or
parallel scopes can have the same name. Also using the location of the symbol
in the cooked character stream has the advantage that it preserves the the
order of the symbols in a structure constructor constant, which makes matching
the values with the symbols relatively easy.
This patch supersedes D97749.
Differential Revision: https://reviews.llvm.org/D97774
It's possible to define a procedure whose interface depends on a procedure
which has an interface that depends on the original procedure. Such a circular
definition was causing the compiler to fall into an infinite loop when
resolving the name of the second procedure. It's also possible to create
circular dependency chains of more than two procedures.
I fixed this by adding the function HasCycle() to the class DeclarationVisitor
and calling it from DeclareProcEntity() to detect procedures with such
circularly defined interfaces. I marked the associated symbols of such
procedures by calling SetError() on them. When processing subsequent
procedures, I called HasError() before attempting to analyze their interfaces.
Unfortunately, this did not work.
With help from Tim, we determined that the SymbolSet used to track the
erroneous symbols was instantiated using a "<" operator which was defined using
the location of the name of the procedure. But the location of the procedure
name was being changed by a call to ReplaceName() between the times that the
calls to SetError() and HasError() were made. This caused HasError() to
incorrectly report that a symbol was not in the set of erroneous symbols.
I fixed this by changing SymbolSet to be an unordered set that uses the
contents of the name of the symbol as the basis for its hash function. This
works because the contents of the name of the symbol is preserved by
ReplaceName() even though its location changes.
I also fixed the error message used when reporting recursively defined dummy
procedure arguments.
I also added tests that will crash the compiler without this change.
Note that the "<" operator is used in other contexts, for example, in the map
of characterized procedures, maps of items in equivalence sets, maps of
structure constructor values, ... All of these situations happen after name
resolution has been completed and all calls to ReplaceName() have already
happened and thus are not subject to the problem I ran into when ReplaceName()
was called when processing procedure entities.
Note also that the implementation of the "<" operator uses the relative
location in the cooked character stream as the basis of its implementation.
This is potentially problematic when symbols from diffent compilation units
(for example symbols originating in .mod files) are put into the same map since
their names will appear in two different source streams which may not be
allocated in the same relative positions in memory. But I was unable to create
a test that caused a problem. Using a direct comparison of the content of the
name of the symbol in the "<" operator has problems. Symbols in enclosing or
parallel scopes can have the same name. Also using the location of the symbol
in the cooked character stream has the advantage that it preserves the the
order of the symbols in a structure constructor constant, which makes matching
the values with the symbols relatively easy.
This change supersedes D97201.
Differential Revision: https://reviews.llvm.org/D97749
Semantic checks for the following OpenMP 4.5 clauses.
1. 2.15.4.2 - Copyprivate clause
2. 2.15.3.4 - Firstprivate clause
3. 2.15.3.5 - Lastprivate clause
Add related test cases and resolve test cases marked as XFAIL.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D91920
This reverts commit 07de0846a5.
The original patch has caused 6 out 8 of Flang's public buildbots to
fail. As I'm not sure what the fix should be, I'm reverting this for
now. Please see https://reviews.llvm.org/D97201 for more context and
discussion.
- add ops: rebox, insert_on_range, absent, is_present
- embox, coordinate_of: replace old hand-written parser/pretty-printer with assembly format
- remove dead floating point ops, since buitlins work for all types
- update call op
- update documentation
- misc. NFC to formatting
- add op round trip tests
Authors: Eric Schweitz, Jean Perier, Zachary Selk, Kiran Chandramohan, et.al.
Differential Revision: https://reviews.llvm.org/D97500
It's possible to define a procedure whose interface depends on a procedure
which has an interface that depends on the original procedure. Such a circular
definition was causing the compiler to fall into an infinite loop when
resolving the name of the second procedure. It's also possible to create
circular dependency chains of more than two procedures.
I fixed this by adding the function HasCycle() to the class DeclarationVisitor
and calling it from DeclareProcEntity() to detect procedures with such
circularly defined interfaces. I marked the associated symbols of such
procedures by calling SetError() on them. When processing subsequent
procedures, I called HasError() before attempting to analyze their interfaces.
Unfortunately, this did not work.
With help from Tim, we determined that the SymbolSet used to track the
erroneous symbols was instantiated using a "<" operator which was
defined using the name of the procedure. But the procedure name was
being changed by a call to ReplaceName() between the times that the
calls to SetError() and HasError() were made. This caused HasError() to
incorrectly report that a symbol was not in the set of erroneous
symbols. I fixed this by making SymbolSet be an ordered set, which does
not use the "<" operator.
I also added tests that will crash the compiler without this change.
And I fixed the formatting on an error message from a previous update.
Differential Revision: https://reviews.llvm.org/D97201
We lower expressions with rank > 0 to a set of high-level array operations.
These operations are then analyzed and refined to more primitve
operations in subsequent pass(es).
This patch upstreams these array operations and some other helper ops.
Authors: Eric Schweitz, Rajan Walia, Kiran Chandramohan, et.al.
https://github.com/flang-compiler/f18-llvm-project/pull/565
Differential Revision: https://reviews.llvm.org/D97421
This patch makes sure that for the following invocation of the new Flang
driver, clangDriver sets the input type to Fortran:
```
flang-new -E -
```
This change does not affect `clang`, i.e. for the following invocation
the input type is set to C:
```
clang -E -
```
This change leverages the fact that for `flang-new` the driver is in
Flang mode.
Differential Revision: https://reviews.llvm.org/D96777
This patch adds the new zero_bits operation and upstrams other changes
including the following:
- update tablegen syntax to newer forms
- update memory effects annotations
- update documentation [NFC]
- other NFC, such as whitespace and formatting
Differential revision: https://reviews.llvm.org/D97331
Originally, when we added the new driver, we created dedicated test
directories for `flang-new`. This way we separated the tests for the
`throwaway` and the new driver.
As we are increasing test coverage and starting to share tests between
the two drivers, it makes sense to share all directories and instead
rely on:
```
! REQUIRES: new-flang-driver
```
to mark tests as exclusively for the new driver.
Differential Revision: https://reviews.llvm.org/D97207
Add -J to the f18 driver for compatibility with gfortran.
Add -module-dir for compatibility with the new flang driver.
They both set the output directory for .mod files and add the
directory to the search list. -module still only does the former.
Clean up the new driver test to match.
Differential Revision: https://reviews.llvm.org/D97164
This patch adds support for `-Xflang` in `flang-new`. The semantics are
identical to `-Xclang`.
With the addition of `-Xflang`, we can modify `-test-io` to be a
compiler-frontend only flag. This makes more sense, this flag is:
* very frontend specific
* to be used for development and testing only
* not to be exposed to the end user
Originally we added it to the compiler driver, `flang-new`, in order to
facilitate testing. With `-Xflang` this is no longer needed. Tests are
updated accordingly.
Differential Revision: https://reviews.llvm.org/D96864
Add the following options:
* -fdebug-measure-parse-tree
* -fdebug-pre-fir-tree
Summary of changes:
- Add 2 new frontend actions: DebugMeasureParseTreeAction and DebugPreFIRTreeAction
- Add MeasurementVisitor to FrontendActions.h
- Make reportFatalSemanticErrors return true if there are any fatal errors
- Port most of the `-fdebug-pre-fir-tree` tests to use the new driver if built, otherwise use f18.
Differential Revision: https://reviews.llvm.org/D96884
Most Fortran compilers accept the following benign extension,
and it appears in some applications:
SUBROUTINE FOO(A,N)
IMPLICIT NONE
REAL A(N) ! N is used before being typed
INTEGER N
END
Allow it in f18 only for default integer scalar dummy arguments.
Differential Revesion: https://reviews.llvm.org/D96982
Add the following options:
* -fdebug-dump-symbols
* -fdebug-dump-parse-tree
* -fdebug-dump-provenance
Summary of changes:
- Add 3 new frontend actions: DebugDumpSymbolsAction, DebugDumpParseTreeAction and DebugDumpProvenanceAction
- Add a unique pointer to the Semantics instance created in PrescanAndSemaAction
- Move fatal semantic error reporting to its own method, FrontendActions#reportFatalSemanticErrors
- Port most tests using `-fdebug-dump-symbols` and `-fdebug-dump-parse-tree` to the new driver if built, otherwise default to f18
Differential Revision: https://reviews.llvm.org/D96716
Fortran 2018 explicitly permits an ignored type declaration
for the result of a generic intrinsic function. See the comment
added to Semantics/expression.cpp for an explanation of why this
is somewhat dangerous and worthy of a warning.
Differential Revision: https://reviews.llvm.org/D96879
The intrinsic procedure table properly classify the various
intrinsics, but the PURE and ELEMENTAL attributes that these
classifications imply don't always make it to the utility
predicates that test symbols for them, leading to spurious
error messages in some contexts. So set those attribute flags
as appropriate in name resolution, using a new function to
isolate the tests.
An alternate solution, in which the predicates would query
the intrinsic procedure table for these attributes on demand,
was something I also tried, so that this information could
come directly from an authoritative source; but it would have
required references to the intrinsic table to be passed along
on too many seemingly unrelated APIs and ended up looking messy.
Several symbol table tests needed to have their expected outputs
augmented with the PURE and ELEMENTAL flags. Some bogus messages
that were flagged as such in test/Semantics/doconcurrent01.f90 were
removed, since they are now correctly not emitted.
Differential Revision: https://reviews.llvm.org/D96878
It's possible to define a procedure that has a procedure dummy argument which
names the procedure that contains it. This was causing the compiler to fall
into an infinite loop when characterizing a call to the procedure.
Following a suggestion from Peter, I fixed this be maintaining a set of
procedure symbols that had already been seen while characterizing a procedure.
This required passing a new parameter to the functions that characterized a
Procedure, a DummyArgument, and a DummyProcedure.
I also added several tests that will crash the compiler without this change.
Differential Revision: https://reviews.llvm.org/D96631
This patch introduce the fir-opt tool. Similar to mlir-opt for FIR.
It will be used in following patches to test fir opt and round-trip.
Reviewed By: schweitz, mehdi_amini
Differential Revision: https://reviews.llvm.org/D96535
Add the following options:
* -fimplicit-none and -fno-implicit-none
* -fbackslash and -fno-backslash
* -flogical-abbreviations and -fno-logical-abbreviations
* -fxor-operator and -fno-xor-operator
* -falternative-parameter-statement
* -finput-charset=<value>
Summary of changes:
- Enable extensions in CompilerInvocation#ParseFrontendArgs
- Add encoding_ to Fortran::frontend::FrontendOptions
- Add encoding to Fortran::parser::Options
Differential Revision: https://reviews.llvm.org/D96407
This patch adds the following compiler frontend driver options:
* -fdebug-unparse (f18 spelling: -funparse)
* -fdebug-unparse-with-symbols (f18 spelling: -funparse-with-symbols)
The new driver will only accept the new spelling. `f18` will accept both
the original and the new spelling.
A new base class for frontend actions is added: `PrescanAndSemaAction`.
This is added to reduce code duplication that otherwise these new
options would lead to. Implementation from
* `ParseSyntaxOnlyAction::ExecutionAction`
is moved to:
* `PrescanAndSemaAction::BeginSourceFileAction`
This implementation is now shared between:
* PrescanAndSemaAction
* ParseSyntaxOnlyAction
* DebugUnparseAction
* DebugUnparseWithSymbolsAction
All tests that don't require other yet unimplemented options are
updated. This way `flang-new -fc1` is used instead of `f18` when
`FLANG_BUILD_NEW_DRIVER` is set to `On`. In order to facilitate this,
`%flang_fc1` is added in the LIT configuration (lit.cfg.py).
`asFortran` from f18.cpp is duplicated as `getBasicAsFortran` in
FrontendOptions.cpp. At this stage it's hard to find a good place to
share this method. I suggest that we revisit this once a switch from
`f18` to `flang-new` is complete.
Differential Revision: https://reviews.llvm.org/D96483
The following _action_ options are always used with `-fsyntax-only`
(also an _action_ option):
* -fdebug-dump-symbols
* -fdebug-dump-parse-tree
This patch makes the above options imply `-fsyntax-only`.
From the perspective of `f18` this change saves typing and is otherwise
a non-functional change. But it will simplify things in the new driver,
`flang-new`, in which only the last action option is taken into account
and executed. In other words, the following would only run
`-fsyntax-only`:
```
flang-new -fdebug-dump-symbols -fsyntax-only <input>
```
whereas this would only run `-fdebug-dump-symbols`:
```
flang-new -fsyntax-only -fdebug-dump-symbols <input>
```
Differential Revision: https://reviews.llvm.org/D96528
Implementation of Do loop iteration variable check, Do while loop check, Do loop cycle restrictions.
Also to check whether the ordered clause is present on the loop construct if any ordered region ever
binds to a loop region arising from the loop construct.
Files:
check-omp-structure.h
check-omp-structure.cpp
resolve-directives.cpp
Testcases:
omp-do06-positivecases.f90
omp-do06.f90
omp-do08.f90
omp-do09.f90
omp-do10.f90
omp-do11.f90
omp-do12.f90
omp-do13.f90
omp-do14.f90
omp-do15.f90
omp-do16.f90
omp-do17.f90
Reviewed by: Kiran Chandramohan @kiranchandramohan , Valentin Clement @clementval
Differential Revision: https://reviews.llvm.org/D92732
This patch introduce the fir-opt tool. Similar to mlir-opt for FIR.
It will be used in following patches to test fir opt and round-trip.
Reviewed By: schweitz, mehdi_amini
Differential Revision: https://reviews.llvm.org/D96535
Instead of using a message attachment with further details,
emit the details as part of a single message.
Differential Revision: https://reviews.llvm.org/D96465
Most components required for this are already there.
Build and Testing clean.
ninja check-flang
Reviewed By: clementval, tskeith
Differential Revision: https://reviews.llvm.org/D96411
Some state in name resolution is stored in the DeclarationVisitor
instance and processed at the end of the specification part.
This state needs to accommodate nested specification parts, namely
the ones that can be nested in a subroutine or function interface
body.
Differential Revision: https://reviews.llvm.org/D96466
Add support for the following options:
* -fopenmp
* -fopenacc
Update OpenMP and OpenACC semantics tests to use the new driver if it is built, otherwise use f18.
OpenMP tests that include `use omp_lib` or run `test_symbols.sh` have not been updated as they require options `-intrinsic-module-directory` and `-funparse-with-symbols` which are currently not implemented in the new driver.
Similarly OpenACC tests that run `test_symbols.sh` have not been updated.
This patch also moves semanticsContext to CompilerInvocation and creates it in CompilerInvocation#setSemanticsOpts so that the semantics context can use Fortran::parser::Options#features.
Summary of changes:
- Move semanticsContext to CompilerInvocation.h
- Update OpenMP and OpenACC semantics tests that do not rely on `-intrinsic-module-directory` and `-funparse-with-symbols` to use %flang
Differential Revision: https://reviews.llvm.org/D96032
This patch adds logic in the InputOutputTestAction frontend action for
reading input from stdin. Without this patch the following fails:
```
flang-new -fc1 -test-io -
```
The implementation of `InputOutputTestAction` is cleaned-up and a test
for reading from stdin is added.
Note that there's a difference between `-test-io` and e.g. `-E` in terms
of file I/O. The frontend action for the former handles all file I/O on
it's own. Conversely, the action corresponding to -E relies on the
prescanner API to handle this.
Currently we can't test reading from stdin for `flang-new -`. In this
case `libclangDriver` assumes `-x -c`. This in turn leads to `flang-new
-cc1`, which is not supported.
Add support for option -J/-module-dir in the new Flang driver. This
will allow for including module files in other directories, as the
default search path is currently the working folder. This also provides
an option of storing the output module in the specified folder.
Differential Revision: https://reviews.llvm.org/D95448
Add support for the following layout options:
* -ffree-form
* -ffixed-form
- -ffixed-line-length=n (alias -ffixed-line-length-n)
Additionally remove options `-fno-free-form` and `-fno-fixed-form` as they were initially added to forward to gfortran but gfortran does not support these flags.
This patch adds the flag FlangOnlyOption to the existing options `-ffixed-form`, `-ffree-form` and `-ffree-line-length-` in Options.td. As of commit 6a75496836, these flags are not currently forwarded to gfortran anyway.
The default fixed line length in FrontendOptions is 72, based off the current default in Fortran::parser::Options. The line length cannot be set to a negative integer, or a positive integer less than 7 excluding 0, consistent with the behaviour of gfortran.
This patch does not add `-ffree-line-length-n` as Fortran::parser::Options does not have a variable for free form columns.
Whilst the `fixedFormColumns` variable is used in f18 for `-ffree-line-length-n`, f18 only allows `-ffree-line-length-none`/`-ffree-line-length-0` and not a user-specified value. `fixedFormcolumns` cannot be used in the new driver as it is ignored in the frontend when dealing with free form files.
Summary of changes:
- Remove -fno-fixed-form and -fno-free-form from Options.td
- Make -ffixed-form, -ffree-form and -ffree-line-length-n FlangOnlyOption in Options.td
- Create AddFortranDialectOptions method in Flang.cpp
- Create FortranForm enum in FrontendOptions.h
- Add fortranForm_ and fixedFormColumns_ to Fortran::frontend::FrontendOptions
- Update fixed-form-test.f so that it guarantees that it fails when forced as a free form file to better facilitate testing.
Differential Revision: https://reviews.llvm.org/D95460
Constant folding for calls to LBOUND() was not working when the lower bound of
a constant array was not 1.
I fixed this and re-enabled the test in Evaluate/folding16.f90 that previously
was silently failing. I slightly changed the test to parenthesize the first
argument to exercise all of the new code.
Differential Revision: https://reviews.llvm.org/D95894
Now that semantics is working, the standard -fsyntax-only option of
GNU and Clang should be used as the name of the option that causes
f18 to just run the front-end. Support both options in f18, silently
accepting the old option as a synonym for the new one (as
preferred by the code owner), and replace all instances of the
old -fparse-only option with -fsyntax-only throughout the source base.
Differential Revision: https://reviews.llvm.org/D95887
Implement IEEE_SUPPORT_DATATYPE() and other inquiry intrinisic
functions from the intrinsic module IEEE_ARITHMETIC, folding all of
their results to .TRUE.
Differential Revision: https://reviews.llvm.org/D95830
This patch adds a check that verifies that the input file used when
calling the frontend driver (i.e. `flang-new -fc1`) actually exists.
This was not required for the compiler driver, `flang-new`, as that's
already handled in libclangDriver.
Once all input/output file management is moved to the driver, we should
also check that for input from `stdin` the corresponding file descriptor
was successfully acquired.
This patch also makes sure that the default action in the frontend is
`ParseSyntaxOnly`. This is consistent with Clang. Before this change
`flang-new -fc1` would do nothing, which makes testing changes like the
one introduced here a bit tricky.
Reviewed By: SouraVX
Differential Revision: https://reviews.llvm.org/D95127
Legacy Fortran implementations support an alternative form of the
PARAMETER statement; it differs syntactically from the standard's
PARAMETER statement by lacking parentheses, and semantically by
using the type and shape of the initialization expression to define
the attributes of the named constant. (GNU Fortran gets that part
wrong; Intel Fortran and nvfortran have full support.)
This patch disables the old style PARAMETER statement by default, as
it is syntactically ambiguous with conforming assignment statements;
adds a new "-falternative-parameter-statement" option to enable it;
and implements it correctly when enabled.
Fixes https://bugs.llvm.org/show_bug.cgi?id=48774, in which a user
tripped over the syntactic ambiguity.
Differential Revision: https://reviews.llvm.org/D95697
There were two problems with constant arrays whose lower bound is not 1.
First, when folding the arrays, we were creating the folded array to have lower
bounds of 1 but, we were not re-adjusting their lower bounds to the
declared values. Second, we were not calculating the extents correctly.
Both of these problems led to bogus error messages.
I fixed the first problem by adjusting the lower bounds in
NonPointerInitializationExpr() in Evaluate/check-expression.cpp. I wrote the
class ArrayConstantBoundChanger, which is similar to the existing class
ScalarConstantExpander. In the process of implementing and testing it, I found
a bug that I fixed in ScalarConstantExpander which caused it to infinitely
recurse on parenthesized expressions. I also removed the unrelated class
ScalarExpansionVisitor, which was not used.
I fixed the second problem by changing the formula that calculates upper bounds
in in the function ComputeUpperBound() in Evaluate/shape.cpp.
I added tests that trigger the bogus error messages mentioned above along with
a constant folding tests that uses array operands with shapes that conform but
have different bounds.
In the process of adding tests, I discovered that tests in
Evaluate/folding09.f90 and folding16.f90 were written incorrectly, and I
fixed them. This also revealed a bug in contant folding of the
intrinsic "lbounds" which I plan to fix in a later change.
Differential Revision: https://reviews.llvm.org/D95449
Make the #include "file" preprocessing directive begin its
search in the same directory as the file containing the directive,
as other preprocessors and our Fortran INCLUDE statement do.
Avoid current working directory for all source files except the original.
Resolve tests.
Differential Revision: https://reviews.llvm.org/D95481
kernels loop and enter data had a too restrictive constraint for the wait clause.
The wait clause is allowed multiple times and not only once. This patch fix this problem.
Reviewed By: SouraVX
Differential Revision: https://reviews.llvm.org/D95469
Restriction on clauses for the EXIT DATA directive were not fully correct.
This patch fixes the situation. The async, if and finalize clauses are allowed
only once.
Reviewed By: SouraVX
Differential Revision: https://reviews.llvm.org/D95470
Restriction on clauses for the HOST_DATA directive were not fully correct.
This patch fixes the situation. The if and if_present clauses are allowed
only once.
Reviewed By: SouraVX
Differential Revision: https://reviews.llvm.org/D95473
Ensure diagnostics from the prescanner are reported when running `flang-new -fsyntax-only` (i.e. only syntax parsing).
This keeps the diagnostics output of flang-new consistent with `f18 -fparse-only` when running the syntax parsing action, ParseSyntaxOnlyAction.
Summary of changes:
- Modify ParseSyntaxOnlyAction::ExecuteAction to report diagnostics
Differential Revision: https://reviews.llvm.org/D95220
Split the tests from acc-clause-validity.f90 in dedicated files by directives.
The file acc-clause-validity.f90 was getting too big to be correctly maintained.
Tests are identical.
Reviewed By: SouraVX
Differential Revision: https://reviews.llvm.org/D95328
Update the preprocessor regression tests to use the new driver if the new driver is built (FLANG_BUILD_NEW_DRIVER=On), otherwise the tests will still run using f18.
Summary of changes:
- Introduce %flang to the regression tests, which points to the new driver if it is built or otherwise points to f18
- Update all tests in flang/test/Preprocessing/ to use %flang
Differential Revision: https://reviews.llvm.org/D94805
Expressions emitted to module files and error messages
sometimes contain conversions of integer results of inquiry
intrinsics; these are usually not needed, and can conflict
with "int" in the user's namespace. Improve folding so that
these conversions don't appear, and do some other clean-up
in adjacent code.
Differential Revision: https://reviews.llvm.org/D95172
This patch makes sure that diagnostics from the prescanner are reported
when running `flang-new -E` (i.e. only the preprocessor phase is
requested). More specifically, the `PrintPreprocessedAction` action is
updated.
With this patch we make sure that the `f18` and `flang-new` provide
identical output when running the preprocessor and the prescanner
generates diagnostics.
Differential Revision: https://reviews.llvm.org/D94782
It's possible to declare deferred shape array using the POINTER
statement, for example:
POINTER :: var(:)
When analyzing POINTER declarations, we were not capturing the array
specification information, if present. I fixed this by changing the
"Post" function for "parser::PointerDecl" to check to see if the
declaration contained a "DeferredShapeSpecList". In such cases, I
analyzed the shape and used to information to declare an "ObjectEntity"
that contains the shape information rather than an "UnknownEntity".
I also added a couple of small tests that fail to compile without these
changes.
Differential Revision: https://reviews.llvm.org/D95080
* IsArrayElement() needs another option to control whether it
should ignore trailing component references.
* Add IsObjectPointer().
* Add const Scope& variants of IsFunction() and IsProcedure().
* Make TypeAndShape::Characterize() work with procedure bindings.
* Handle CHARACTER length in MeasureSizeInBytes().
* Fine-tune FindExternallyVisibleObject()'s handling of dummy arguments
to conform with Fortran 2018: only INTENT(IN) and dummy pointers
in pure functions signify; update two tests accordingly.
Also: resolve some stylistic inconsistencies and add a missing
"const" in the expression traversal template framework.
Differential Revision: https://reviews.llvm.org/D95011
F18 Clause 19.4p9 says:
The associate names of an ASSOCIATE construct have the scope of the
block.
Clause 11.3.1p1 says the ASSOCIATE statement is not itself in the block:
R1102 associate-construct is: associate-stmt block end-associate-stmt
Associate statement associations are currently fully processed from left
to right, incorrectly interposing associating entities earlier in the
list on same-named entities in the host scope.
1 program p
2 logical :: a = .false.
3 real :: b = 9.73
4 associate (b => a, a => b)
5 print*, a, b
6 end associate
7 print*, a, b
8 end
Associating names 'a' and 'b' at line 4 in this code are now both
aliased to logical host entity 'a' at line 2. This happens because the
reference to 'b' in the second association incorrectly resolves 'b' to
the entity in line 4 (already associated to 'a' at line 2), rather than
the 'b' at line 3. With bridge code to process these associations,
f18 output is:
F F
F 9.73
It should be:
9.73 F
F 9.73
To fix this, names in right-hand side selector variables/expressions
must all be resolved before any left-hand side entities are resolved.
This is done by maintaining a stack of lists of associations, rather
than a stack of associations. Each ASSOCIATE statement's list of
assocations is then visited once for right-hand side processing, and
once for left-hand side processing.
Note that other construct associations do not have this problem.
SELECT RANK and SELECT TYPE each have a single assocation, not a list.
Constraint C1113 prohibits the right-hand side of a CHANGE TEAM
association from referencing any left-hand side entity.
Differential Revision: https://reviews.llvm.org/D95010
The utility routine WhyNotModifiable() needed to become more
aware of the use of pointers in data-refs; the targets of
pointer components are sometimes modifiable even when the
leftmost ("base") symbol of a data-ref is not.
Added a new unit test for WhyNotModifiable() that uses internal
READ statements (mostly), since I/O semantic checking uses
WhyNotModifiable() for all its definability checking.
Differential Revision: https://reviews.llvm.org/D94849
Add Semantic checks for OpenMP 4.5 - 2.7.4 Workshare Construct.
- The structured block in a workshare construct may consist of only
scalar or array assignments, forall or where statements,
forall, where, atomic, critical or parallel constructs.
- All array assignments, scalar assignments, and masked array
assignments must be intrinsic assignments.
- The construct must not contain any user defined function calls unless
the function is ELEMENTAL.
Test cases : omp-workshare03.f90, omp-workshare04.f90, omp-workshare05.f90
Resolve test cases (omp-workshare01.f90 and omp-workshare02.f90) marked as XFAIL
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D93091
Add the following standard predefinitions that f18 supports:
* `__flang__`,
* `__flang_major__`,
* `__flang_minor__`,
* `__flang_patchlevel__`
Summary of changes:
- Populate Fortran::parser::Options#predefinitions with the default
supported predefinitions
Differential Revision: https://reviews.llvm.org/D94516
Currently the new flang driver always runs in free form mode. This patch
adds support for fixed form mode detection based on the file extensions.
Like `f18`, `flang-new` will treat files ending with ".f", ".F" and
".ff" as fixed form. Additionally, ".for", ".FOR", ".fpp" and ".FPP"
file extensions are recognised as fixed form files. This is consistent
with gfortran [1]. In summary, files with the following extensions are
treated as fixed-form:
* ".f", ".F", ".ff", ".for", ".FOR", ".fpp", ".FPP"
For consistency with flang/test/lit.cfg.py and f18, this patch also adds
support for the following file extensions:
* ".ff", ".FOR", ".for", ".ff90", ".fpp", ".FPP"
This is added in flang/lib/Frontend/FrontendOptions.cpp. Additionally,
the following extensions are included:
* ".f03", ".F03", ".f08", ".F08"
This is for compatibility with gfortran [1] and other popular Fortran
compilers [2].
NOTE: internally Flang will only differentiate between fixed and free
form files. Currently Flang does not support switching between language
standards, so in this regard file extensions are irrelevant. More
specifically, both `file.f03` and `file.f18` are represented with
`Language::Fortran` (as opposed to e.g. `Language::Fortran03`).
Summary of changes:
- Set Fortran::parser::Options::sFixedForm according to the file type
- Add isFixedFormSuffix and isFreeFormSuffix helper functions to
FrontendTool/Utils.h
- Change FrontendOptions::GetInputKindForExtension to support the missing
file extensions that f18 supports and some additional ones
- FrontendActionTest.cpp is updated to make sure that the test input is
treated as free-form
[1] https://gcc.gnu.org/onlinedocs/gfortran/GNU-Fortran-and-GCC.html
[2] https://github.com/llvm/llvm-project/blob/master/flang/docs/OptionComparison.md#notes
Differential Revision: https://reviews.llvm.org/D94228
Add support for option -I in the new Flang driver. This will allow for
included headers and module files in other directories, as the default
search path is currently the working folder. The behaviour of this is
consistent with the current f18 driver, where the current folder (i.e.
".") has the highest priority followed by the order of '-I's taking
priority from first to last.
Summary of changes:
- Add SearchDirectoriesFromDashI to PreprocessorOptions, to be forwarded
into the parser's searchDirectories
- Add header files and non-functional module files to be used in
regression tests. The module files are just text files and are used to
demonstrated that paths specified with `-I` are taken into account when
searching for .mod files.
Differential Revision: https://reviews.llvm.org/D93453
When a reference to a generic interface occurs in a specification
expression that must be emitted to a module file, we have a problem
when the generic resolves to a function whose name is inaccessible
due to being PRIVATE or due to a conflict with another use of the
same name in the scope. In these cases, construct a new name for
the specific procedure and emit a renaming USE to the module file.
Also, relax enforcement of PRIVATE when analyzing module files.
Differential Revision: https://reviews.llvm.org/D94815
The following driver invocation will generate an output file
in the same directory as the input file:
```
flang-new -fc1 -test-io test-input.f90
```
This is the desired behaviour. However, when testing we need to make
sure that we don't pollute the source directory. To this end, copy the
input file into a temporary directory before testing.
This is similar to https://reviews.llvm.org/D94243.
C843 states that "An entity with the INTENT attribute shall be a dummy
data object or a dummy procedure pointer." This change enforces that
and fixes some tests that erroneously violated this rule.
Differential Revision: https://reviews.llvm.org/D94781
Semantic checks added to check the worksharing 'single' region closely nested inside a worksharing 'do' region. And also to check whether the 'do' iteration variable is a variable in 'Firstprivate' clause.
Files:
check-directive-structure.h
check-omp-structure.h
check-omp-structure.cpp
Testcases:
omp-do01-positivecase.f90
omp-do01.f90
omp-do05-positivecase.f90
omp-do05.f90
Reviewed by: Kiran Chandramohan @kiranchandramohan , Valentin Clement @clementval
Differential Revision: https://reviews.llvm.org/D93205
When a use-associated procedure was included in a generic, we weren't
correctly recording that fact. The ultimate symbol was added rather than
the local symbol.
Also, improve the message emitted for the specific procedure by
mentioning the module it came from.
This fixes one of the problems in https://bugs.llvm.org/show_bug.cgi?id=48648.
Differential Revision: https://reviews.llvm.org/D94696
Generic type-bound interfaces for user-defined operators need to be formatted
as "OPERATOR(.op.)", not just ".op."
PRIVATE generics need to be marked as such.
Declaration ordering: when a generic interface shadows a
derived type of the same name, it needs to be emitted to the
module file at the point of definition of the derived type;
otherwise, the derived type's definition may appear after its
first use.
The module symbol for a module read from a module file needs
to be marked as coming from a module file before semantic
processing is performed on the contents of the module so that
any special handling for declarations in module files can be
properly activated.
IMPORT statements were sometimes missing for use-associated
symbols in surrounding scopes; fine-tune NeedImport().
Differential Revision: https://reviews.llvm.org/D94636
It's possible to declare an external procedure and then pass it as an
actual argument to a subprogram expecting a procedure argument. I added
tests for this and added an error message to distinguish passing an
actual argument with an implicit interface from passing an argument with
a mismatched explicit interface.
Differential Revision: https://reviews.llvm.org/D94505
If a module specifies default private accessibility, names that have
been use-associated are private by default. This was not reflected in
.mod files.
Differential Revision: https://reviews.llvm.org/D94602
In some contexts, including the motivating case of determining whether
the expressions that define the shape of a variable are "constant expressions"
in the sense of the Fortran standard, expression rewriting via Fold()
is not necessary, and should not be required. The inquiry intrinsics LBOUND,
UBOUND, and SIZE work correctly now in specification expressions and are
classified correctly as being constant expressions (or not). Getting this right
led to a fair amount of API clean-up as a consequence, including the
folding of shapes and TypeAndShape objects, and new APIs for shapes
that do not fold for those cases where folding isn't needed. Further,
the symbol-testing predicate APIs in Evaluate/tools.h now all resolve any
associations of their symbols and work transparently on use-, host-, and
construct-association symbols; the tools used to resolve those associations have
been defined and documented more precisely, and their clients adjusted as needed.
Differential Revision: https://reviews.llvm.org/D94561
`CheckNoBranching` is currently handling only illegal branching out for constructs
with `Parser::Name` in them.
Extend the same for handling illegal branching out caused by `Parser::Label` based statements.
This patch could possibly solve one of the issues(typically branching out) mentioned in D92735.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D93447
Remove duplicated function to check for required clauses on a directive. This was
still there from the merging of OpenACC and OpenMP common semantic checks and it can now be
removed so we use only one function.
Reviewed By: sameeranjoshi
Differential Revision: https://reviews.llvm.org/D93575
The following frontend driver invocation will generate 2 output files
in the same directory as the input files:
```
flang-new -fc1 input-1.f input-2.f
```
This is the desired behaviour. However, when testing we need to make
sure that we don't pollute the source directory. To this end, copy test
input files into a temporary directory.
Differential Revision: https://reviews.llvm.org/D94243
Internal subprograms have explicit interfaces. If an internal subprogram has
an alternate return, we check its explicit interface. But we were not
putting the label values of alternate returns into the actual argument.
I fixed this by changing the definition of actual arguments to be able
to contain a common::Label and putting the label for an alternate return
into the actual argument.
I also verified that we were already doing all of the semantic checking
required for alternate returns and removed a "TODO" for this.
I also added the test altreturn06.f90.
Differential Revision: https://reviews.llvm.org/D94017
Add semantic check for most of the restrictions for the declare directive.
Reviewed By: kiranktp
Differential Revision: https://reviews.llvm.org/D92741
This patch adds a frontend action for emitting object files. While Flang
does not support code-generation, this action remains a placeholder.
This patch simply provides glue-code to connect the compiler driver
with the appropriate frontend action.
The new action is triggered with the `-c` compiler driver flag, i.e.
`flang-new -c`. This is then translated to `flang-new -fc1 -emit-obj`,
so `-emit-obj` has to be marked as supported as well.
As code-generation is not available yet, `flang-new -c` results in a
driver error:
```
error: code-generation is not available yet
```
Hopefully this will help communicating the level of available
functionality within Flang.
The definition of `emit-obj` is updated so that it can be shared between
Clang and Flang. As the original definition was enclosed within a
Clang-specific TableGen `let` statement, it is extracted into a new `let`
statement. That felt like the cleanest option.
I also commented out `-triple` in Flang::ConstructJob and updated some
comments there. This is similar to https://reviews.llvm.org/D93027. I
wanted to make sure that it's clear that we can't support `-triple`
until we have code-generation. However, once code-generation is
available we _will need_ `-triple`.
As this patch adds `-emit-obj`, the emit-obj.f90 becomes irrelevant and
is deleted. Instead, phases.f90 is added to demonstrate that users can
control compilation phases (indeed, `-c` is a phase control flag).
Reviewed By: SouraVX, clementval
Differential Revision: https://reviews.llvm.org/D93301
This patch adds some positive and failure tests for init and shutdown directives.
Reviewed By: kiranktp
Differential Revision: https://reviews.llvm.org/D90786
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
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
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 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
Update the allowed clauses for the SERIAL construct for the new OpenACC 3.1
specification.
Reviewed By: sameeranjoshi
Differential Revision: https://reviews.llvm.org/D92123
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
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
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 clause validity tests for the data construct. The default clause can appear only once
and this was not enforce in the ACC.td.
Reviewed By: sameeranjoshi
Differential Revision: https://reviews.llvm.org/D91888
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
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
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
Add some clause validity tests for the host_data directive to avoid future regressions.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D91889
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
When doing out-of-tree builds, FIR tests were failing. I made a change
similar to the one by @jurahul to fix this.
Differential Revision: https://reviews.llvm.org/D91654
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
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
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
`-###` has always been supported in the new flang driver. This patch
merely makes sure that it's included when printing the help screen (i.e.
`flang-new -help`).
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
This patch add some parsing and clause validity tests for the set directive.
It makes use of the possibility introduces in patch D90770 to check the restriction
were one of the default_async, device_num and device_type clauses is required but also
not more than once on the set directive.
Reviewed By: sameeranjoshi
Differential Revision: https://reviews.llvm.org/D90771
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
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
Use `--match-full-lines` to make sure that FileCheck doesn't match the
output against the `CHECK` lines (which, like other comments, are also
printed).
More specifically, we want to make sure that the following `check` in the
input file:
```
! CHECK: <some-fortran-input>
```
is matched by FileCheck with `<some-fortran-input>` in the generated
output. Without `--match-full-lines`, that check-line will be matched
with `!CHECK: <some-fortran-input>` instead (which is also
printed together with other contents of the file).
Adding `--match-full-lines` makes the tests stricter and this change
revealed that some `check`s were passing only because that flag was
missing. These are updated accordingly.
Reviewed By: CarolineConcatto, sameeranjoshi
Differential Revision: https://reviews.llvm.org/D90306
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
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
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
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
- 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
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
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
Emil Kieri