Commit Graph

120 Commits

Author SHA1 Message Date
Peter Klausler 52a1346b78 [flang] Distinguish intrinsic from non-intrinsic modules
For "USE, INTRINSIC", search only for intrinsic modules;
for "USE, NON_INTRINSIC", do not recognize intrinsic modules.
Allow modules of both kinds with the same name to be used in
the same source file (but not in the same scoping unit, a
constraint of the standard that is now enforced).

The symbol table's scope tree now has a single instance of
a scope with a new kind, IntrinsicModules, whose children are
the USE'd intrinsic modules (explicit or not).  This separate
"top-level" scope is a child of the single global scope and
it allows both intrinsic and non-intrinsic modules of the same
name to exist in the symbol table.  Intrinsic modules' scopes'
symbols now have the INTRINSIC attribute set.

The search path directories need to make a distinction between
regular directories and the one(s) that point(s) to intrinsic
modules.  I allow for multiple intrinsic module directories in
the second search path, although only one is needed today.

Differential Revision: https://reviews.llvm.org/D118631
2022-01-31 13:31:27 -08:00
Peter Klausler c14cf92b5a [flang] Implement semantics for DEC STRUCTURE/RECORD
Implements part of the legacy "DEC structures" feature from
VMS Fortran.  STRUCTUREs are processed as if they were derived
types with SEQUENCE.  DATA-like object entity initialization
is supported as well (e.g., INTEGER FOO/666/) since it was used
for default component initialization in structures.  Anonymous
components (named %FILL) are also supported.

These features, and UNION/MAP, were already being parsed.
An omission in the collection of structure field names in the
case of nested structures with entity declarations was fixed
in the parser.

Structures are supported in modules, but this is mostly for
testing purposes.  The names of fields in structures accessed
via USE association cannot appear with dot notation in client
code (at least not yet).  DEC structures antedate Fortran 90,
so their actual use in applications should not involve modules.

This patch does not implement UNION/MAP, since that feature
would impose difficulties later in lowering them to MLIR types.
In the meantime, if they appear, semantics will issue a
"not yet implemented" error message.

Differential Revision: https://reviews.llvm.org/D117151
2022-01-13 13:17:13 -08:00
Peter Klausler 0e811d3b66 [flang] Fix handling of space between # and name in preprocessor stringification
When preprocessing "# ARG" in function-like macro expansion,
the preprocessor needs to pop the previously-pushed '#' token
from the end of the resulting token sequence after detecting the
argument name.  The code to do this was just wrong in a couple of
ways.

Differential Revision: https://reviews.llvm.org/D117148
2022-01-12 16:02:17 -08:00
Nimish Mishra fe2d053c45 Added OpenMP 5.0 specification based semantic checks for CRITICAL construct name resolution
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
2021-10-12 22:18:24 +05:30
peter klausler 094b380c21 [flang] Catch mismatched parentheses in prescanner
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
2021-10-06 14:00:15 -07:00
peter klausler 0061e681a3 [flang] Better error recovery for missing THEN in ELSE IF
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
2021-10-04 09:37:53 -07:00
peter klausler 5a6c38fbef [flang] Fix build
An unused variable declaration from a recent change is eliciting
a fatal warning; remove it.
2021-09-17 12:39:38 -07:00
peter klausler f6ddfac401 [flang] Enforce fixed form rules about END continuation
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
2021-09-17 10:59:17 -07:00
Arnamoy Bhattacharyya b9a8f34d47 [flang][OpenMP] Add parsing support for nontemporal clause.
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
2021-09-13 15:25:47 -04:00
peter klausler f411be0d24 [flang] NFC: change non-nullable pointer arguments to references
Ticking off a Parser TODO: Preprocessor::Directive()'s Prescanner
argument should be a reference, not a pointer.

Differential Revision: https://reviews.llvm.org/D109094
2021-09-02 14:15:27 -07:00
Ivan Zhechev 35249cb7b1 [Flang] Fix error messages on Windows.
Flang uses positional arguments for `messages::say()`, such as "%1$s" which is only supported in MS Compilers with the `_*printf_p` form of the function. This uses a conditional macro to convert the existing `vsnprintf` used to the one needed in MS-World.

7 tests in D107575 rely on this change.

Reviewed By: Meinersbur

Differential Revision: https://reviews.llvm.org/D107654
2021-08-12 18:35:54 +01:00
peter klausler 3338ef93b0 [flang] Produce proper "preprocessor output" for -E option
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
2021-07-30 15:13:56 -07:00
Peter Steinfeld 5a9497d689 [flang] Allow large and erroneous ac-implied-do's
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
2021-05-11 10:04:18 -07:00
peter klausler 0eb3299d28 [flang] Fix crash from -DMACRO= with empty replacement
Such macros were exposing some edge cases in the preprocessor
regarding empty tokens.

Differential Revision: https://reviews.llvm.org/D101207
2021-04-24 10:56:25 -07:00
peter klausler 0d8331c06b [flang] Refine symbol sorting
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
2021-03-18 11:18:14 -07:00
peter klausler 46ade6d0ef [flang] Order Symbols by source provenance
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
2021-03-16 15:25:15 -07:00
Jean Perier 92d27b969a [flang] Save AllocateObject and PointerObject analyzed expression
`parser::AllocateObject` and `parser::PointerObject` can be represented
as typed expressions once analyzed. This simplifies the work for parse-tree
consumers that work with typed expressions to deal with allocatable and
pointer objects such as lowering.

This change also makes it easier to add typedExpr in the future by
automatically handling nodes that have this member when possible.

Changes:

- Add a `mutable TypedExpr typedExpr` field to `parser::PointerObject` and `parser::AllocateObject`.
- Add a `parser::HasTypedExpr<T>` helper to better share code relating to typedExpr in the parse tree.
- Add hooks in `semantics::ExprChecker` for AllocateObject and PointerObject nodes, and use
  ExprOrVariable on it to analyze and set the tyedExpr field during
  expression analysis. This required adding overloads for `AssumedTypeDummy`.
- Update check-nullify.cpp and check-deallocate.cpp to not re-analyze the StructureComponent but to
  use the typedExpr field instead.
- Update dump/unparse to use HasTypedExpr and use the typedExpr when there is one.

Differential Revision: https://reviews.llvm.org/D98256
2021-03-16 10:27:45 +01:00
Andrzej Warzynski 96d229c9ab [flang][driver] Add options for unparsing
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
2021-02-16 09:32:51 +00:00
peter klausler 8880a63a15 [flang] Don't perform macro replacement unless *.F, *.F90, &c.
Avoid spurious and confusing macro replacements from things like
-DPIC on Fortran source files whose suffixes indicate that preprocessing
is not expected.

Add gfortran-like "-cpp" and "-nocpp" flags to f18 to force predefinition
of macros independent of the source file suffix.

Differential Revision: https://reviews.llvm.org/D96464
2021-02-11 11:25:41 -08:00
peter klausler f0ffc690d5 [flang] Fix parsing of WRITE(I+J) with more accurate look-ahead
The parsing of I/O units uses look-ahead to discriminate between
keywords, variables and expressions as part of distinguishing internal
from external I/O.  The look-ahead was inaccurate for variables that
appear as the initial parts of expressions.

Differential Revision: https://reviews.llvm.org/D95743
2021-02-01 09:07:40 -08:00
peter klausler 6110e7716c [flang] Search for #include "file" in right directory (take 2)
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
2021-01-27 15:41:29 -08:00
Andrzej Warzynski e878589098 Revert "[flang] Search for #include "file" in right directory"
This reverts commit d987b61b1d.

As pointed out in https://reviews.llvm.org/D95388, the reverted commit
causes build failures in the following Flang buildbots:
  * http://lab.llvm.org:8011/#/builders/32/builds/2642
  * http://lab.llvm.org:8011/#/builders/33/builds/2131
  * http://lab.llvm.org:8011/#/builders/135/builds/1473
  * http://lab.llvm.org:8011/#/builders/66/builds/1559
  * http://lab.llvm.org:8011/#/builders/134/builds/1409
  * http://lab.llvm.org:8011/#/builders/132/builds/1817
I'm guessing that the patch was only tested with
`FLANG_BUILD_NEW_DRIVER=Off` (i.e. the default). The builders listed
above set `FLANG_BUILD_NEW_DRIVER` to `On`.

Although fixing the build is relatively easy, the reverted patch
modifies the behaviour of the frontend, which breaks driver tests. In
particular, in https://reviews.llvm.org/D93453 support for `-I` was
added that depends on the current behaviour. The reverted patch
changes that behaviour. Either the tests have to be updated or the
change fine-tuned.
2021-01-26 13:07:14 +00:00
peter klausler d987b61b1d [flang] Search for #include "file" in right directory
Make the #include "file" preprocessing directive begin its
search in the same directory as the file containing the directive,
as other preprocessors and our Fortran INCLUDE statement do.

Avoid current working directory for all source files after the original.

Differential Revision: https://reviews.llvm.org/D95388
2021-01-25 13:39:37 -08:00
Valentin Clement 6bd0a4451c [flang][directive] Get rid of flangClassValue in TableGen
The TableGen emitter for directives has two slots for flangClass information and this was mainly
to be able to keep up with the legacy openmp parser at the time. Now that all clauses are encapsulated in
AccClause or OmpClause, these two strings are not necessary anymore and were the the source of couple
of problem while working with the generic structure checker for OpenMP.
This patch remove the flangClassValue string from DirectiveBase.td and use the string flangClass as the
placeholder for the encapsulated class.

Reviewed By: sameeranjoshi

Differential Revision: https://reviews.llvm.org/D94821
2021-01-19 10:28:46 -05:00
Valentin Clement ca98baa042 [openacc] Rename generated file from ACC.cpp.inc to ACC.inc to match D92955
This patch rename the tablegen generated file ACC.cpp.inc to ACC.inc in order
to match what was done in D92955. This file is included in header file as well as .cpp
file so it make more sense.

Reviewed By: sameeranjoshi

Differential Revision: https://reviews.llvm.org/D93485
2021-01-14 14:19:53 -05:00
Valentin Clement 4d0aad96e4 [flang][openmp] Make Reduction clause part of OmpClause
After discussion in D93105 we found that the reduction clause was not following
the common OmpClause convention. This patch makes reduction clause part of OmpClause
with a value of OmpReductionClause in a similar way than task_reduction.
The unparse function for OmpReductionClause is adapted since the keyword and parenthesis
are issued by the corresponding unparse function for parser::OmpClause::Reduction.

Reviewed By: sameeranjoshi

Differential Revision: https://reviews.llvm.org/D93482
2021-01-04 15:19:00 -05:00
sameeran joshi 6280bc1cc3 [Flang][openmp][5.0] Add task_reduction clause.
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>
2021-01-04 08:48:11 +05:30
sameeran joshi 1aa10ab2e1 Revert "[Flang][openmp][5.0] Add task_reduction clause."
This reverts commit 9a7895dc20.
Reverting due to missing Co-author attribution.

https://reviews.llvm.org/D93105
2020-12-22 23:53:51 +05:30
sameeran joshi 9a7895dc20 [Flang][openmp][5.0] Add task_reduction clause.
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
2020-12-22 22:34:38 +05:30
sameeran joshi 1a6f43991f [Flang][openmp][5/5] Make dist_schedule clause part of OmpClause
After discussion in `D93482` we found that the some of the clauses were not
following the common OmpClause convention.

The benefits of using OmpClause:
- Functionalities from structure checker are mostly aligned to work with
  `llvm::omp::Clause`.
- The unparsing as well can take advantage.
- Homogeneity with OpenACC and rest of the clauses in OpenMP.
- Could even generate the parser with TableGen, when there is homogeneity.
- It becomes confusing when to use `flangClass` and `flangClassValue` inside
  TableGen, if incase we generate parser using TableGen we could have only a
  single `let expression`.

This patch makes `OmpDistScheduleClause` clause part of `OmpClause`.
The unparse function for `OmpDistScheduleClause` is adapted since the keyword
and parenthesis are issued by the corresponding unparse function for
`parser::OmpClause::DistSchedule`.

Reviewed By: clementval, kiranktp

Differential Revision: https://reviews.llvm.org/D93644
2020-12-22 14:32:33 +05:30
sameeran joshi e282ae57da [Flang][openmp][4/5] Make nowait clause part of OmpClause
After discussion in `D93482` we found that the some of the clauses were not
following the common OmpClause convention.

The benefits of using OmpClause:
- Functionalities from structure checker are mostly aligned to work with
  `llvm::omp::Clause`.
- The unparsing as well can take advantage.
- Homogeneity with OpenACC and rest of the clauses in OpenMP.
- Could even generate the parser with TableGen, when there is homogeneity.
- It becomes confusing when to use `flangClass` and `flangClassValue` inside
  TableGen, if incase we generate parser using TableGen we could have only a
  single `let expression`.

This patch makes `OmpNoWait` clause part of `OmpClause`.

Reviewed By: clementval, kiranktp

Differential Revision: https://reviews.llvm.org/D93643
2020-12-22 14:02:19 +05:30
sameeran joshi 34958d11c3 [Flang][openmp][3/5] Make ProcBind clause part of OmpClause
After discussion in `D93482` we found that the some of the clauses were not
following the common OmpClause convention.

The benefits of using OmpClause:
- Functionalities from structure checker are mostly aligned to work with
  `llvm::omp::Clause`.
- The unparsing as well can take advantage.
- Homogeneity with OpenACC and rest of the clauses in OpenMP.
- Could even generate the parser with TableGen, when there is homogeneity.
- It becomes confusing when to use `flangClass` and `flangClassValue` inside
  TableGen, if incase we generate parser using TableGen we could have only a
  single `let expression`.

This patch makes `OmpProcBindClause` clause part of `OmpClause`.
The unparse function is dropped as the unparsing is done by `WALK_NESTED_ENUM`
for `OmpProcBindClause`.

Reviewed By: clementval, kiranktp

Differential Revision: https://reviews.llvm.org/D93642
2020-12-22 13:40:38 +05:30
sameeran joshi f72c384b5b [Flang][openmp][2/5] Make Default clause part of OmpClause
After discussion in `D93482` we found that the some of the clauses were not
following the common OmpClause convention.

The benefits of using OmpClause:
- Functionalities from structure checker are mostly aligned to work with
  `llvm::omp::Clause`.
- The unparsing as well can take advantage.
- Homogeneity with OpenACC and rest of the clauses in OpenMP.
- Could even generate the parser with TableGen, when there is homogeneity.
- It becomes confusing when to use `flangClass` and `flangClassValue` inside
  TableGen, if incase we generate parser using TableGen we could have only a
  single `let expression`.

This patch makes `OmpDefaultClause` clause part of `OmpClause`.
The unparse function is dropped as the unparsing is done by `WALK_NESTED_ENUM`
for `OmpDefaultClause`.

Reviewed By: clementval, kiranktp

Differential Revision: https://reviews.llvm.org/D93641
2020-12-22 13:17:44 +05:30
sameeran joshi 442aac5da6 [Flang][openmp][1/5] Make Allocate clause part of OmpClause
After discussion in `D93482` we found that the some of the clauses were not
following the common OmpClause convention.

The benefits of using OmpClause:
- Functionalities from structure checker are mostly aligned to work with
  `llvm::omp::Clause`.
- The unparsing as well can take advantage.
- Homogeneity with OpenACC and rest of the clauses in OpenMP.
- Could even generate the parser with TableGen, when there is homogeneity.
- It becomes confusing when to use `flangClass` and `flangClassValue` inside
  TableGen, if incase we generate parser using TableGen we could have only a
  single `let expression`.

This patch makes `allocate` clause part of `OmpClause`.The unparse function for
`OmpAllocateClause` is adapted since the keyword and parenthesis are issued by
the corresponding unparse function for `parser::OmpClause::Allocate`.

Reviewed By: clementval

Differential Revision: https://reviews.llvm.org/D93640
2020-12-22 12:53:34 +05:30
Valentin Clement 8f933a4e93 [openacc] Use TableGen enum for default clause value
Use the TableGen feature to have enum values for clauses.
Next step will be to extend the MLIR part used currently by OpenMP
to use the same enum on the dialect side.

This patch also add function that convert the enum to StringRef to be
used on the dump-parse-tree from flang.

Reviewed By: jdoerfert

Differential Revision: https://reviews.llvm.org/D93576
2020-12-21 15:07:27 -05:00
Valentin Clement f4c8b80318 [openmp] Remove clause from OMPKinds.def and use OMP.td info
Remove the OpenMP clause information from the OMPKinds.def file and use the
information from the new OMP.td file. There is now a single source of truth for the
directives and clauses.

To avoid generate lots of specific small code from tablegen, the macros previously
used in OMPKinds.def are generated almost as identical. This can be polished and
possibly removed in a further patch.

Reviewed By: jdoerfert

Differential Revision: https://reviews.llvm.org/D92955
2020-12-17 14:08:12 -05:00
Valentin Clement 71699a998d [flang][openacc] Enforce restriction on routine directive and clauses
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
2020-12-17 11:33:34 -05:00
peter klausler 9a883bfa11 [flang] Clean up TODO comments and fix one (DATA constant ambiguity)
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
2020-12-15 13:36:07 -08:00
sameeran joshi f1569b1ece [Flang][OpenMP-5.0] Semantic checks for flush construct.
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
2020-12-14 13:30:48 +05:30
sameeran joshi e43b3b08cc [Flang][OpenMP] Semantic checks for Atomic construct.
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
2020-12-14 13:03:57 +05:30
Irina Dobrescu c9e967af3f [flang]Add Parser Support for Allocate Directive
Differential Revision: https://reviews.llvm.org/D89562
2020-12-10 16:21:19 +00:00
Valentin Clement d553243fe4 [flang][openacc] Update reference to OpenACC 3.1 specification
Update all reference from the specification to the new OpenACC 3.1
document.

Reviewed By: SouraVX

Differential Revision: https://reviews.llvm.org/D92120
2020-12-08 14:36:38 -05:00
Valentin Clement 1dd24e6ab7 [flang][openacc] Add clause validity tests for the update directive
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
2020-12-08 10:47:06 -05:00
peter klausler 641ede93ef [flang] Improve initializer semantics, esp. for component default values
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
2020-12-07 14:40:41 -08:00
clementval 952c9d3a91 [NFC] Fix typo in atomic 2020-11-21 14:32:31 -05:00
Valentin Clement aa179d8099 [flang][openmp] Separate memory-order-clause parser creating OmpClause node
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
2020-11-21 14:31:33 -05:00
sameeran joshi 42ecf188b5 [flang][openmp] Fix bug in `OmpClause::Hint` clause which was missing to generate inside in OMP.cpp.inc file.
Before this patch "Hint" isn't found inside the generated file.
./bin/llvm-tblgen --gen-directive-gen ../llvm-project/llvm/include/llvm/Frontend/OpenMP/OMP.td -I ../llvm-project/llvm/include/ > OMP.cpp.in

Reviewed By: clementval

Differential Revision: https://reviews.llvm.org/D91909
2020-11-21 19:02:34 +05:30
peter klausler 5349f99114 [flang] Correct handling of null pointer initializers
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
2020-11-18 13:57:25 -08:00
peter klausler 6c516cda39 [flang] Recognize END FILE as ENDFILE in free form source
The ENDFILE statement may be spelled as two words.

Differential revision: https://reviews.llvm.org/D91377
2020-11-12 12:46:04 -08:00
peter klausler cc575dd2ce [flang][MSVC] Use list<Message> rather than forward_list<> in Messages
The implementation of Messages with forward_list<> makes some
nonstandard assumptions about the validity of iterators that don't
hold up with MSVC's implementation.  Use list<> instead.  The
measured performance is comparable.

This change obviated a distinction between two member functions
of Messages, and the uses of one have been replaced with calls
to the other.

Similar usage in CharBuffer was also replaced for consistency.

Differential revision: https://reviews.llvm.org/D91210
2020-11-11 16:38:38 -08:00