[flang] Better recovery from errors in a loop control (#117025)

When there's an error in a DO statement loop control, error recovery
isn't great. A bare "DO" is a valid statement, so a failure to p

[flang] Better recovery from errors in a loop control (#117025)

When there's an error in a DO statement loop control, error recovery
isn't great. A bare "DO" is a valid statement, so a failure to parse its
loop control doesn't fail on the whole statement. Its partial parse ends
after the keyword, and as some other statement parsers can get further
into the input before failing, errors in the loop control can lead to
confusing error messages about bad pointer assignment statements and
others. So just check that a bare "DO" is followed by the end of the
statement.

show more ...

[flang][cuda] Make launch configuration optional for cuf kernel (#115947)

[flang][parser] Better error recovery for misplaced declaration (#100482)

When a declaration construct appears in the execution part of a block or
subprogram body, report it as such rather than as

[flang][parser] Better error recovery for misplaced declaration (#100482)

When a declaration construct appears in the execution part of a block or
subprogram body, report it as such rather than as a misleading syntax
error on the executable statement that it somehow matched the most.

show more ...

[flang] Add parsing of DO CONCURRENT REDUCE clause (#92518)

Derived from #92480. This PR supports parsing of the DO CONCURRENT
REDUCE clause in Fortran 2023. Following the style of the OpenMP parse

[flang] Add parsing of DO CONCURRENT REDUCE clause (#92518)

Derived from #92480. This PR supports parsing of the DO CONCURRENT
REDUCE clause in Fortran 2023. Following the style of the OpenMP parser
in MLIR, the front end accepts both arbitrary operations and procedures
for the REDUCE clause. But later Semantics can notify type errors and
resolve procedure names.

show more ...

[flang] Parse REDUCE clauses in !$CUF KERNEL DO (#92154)

A !$CUF KERNEL DO directive is allowed to have advisory REDUCE clauses
similar to those in OpenACC and DO CONCURRENT. Parse and represent th

[flang] Parse REDUCE clauses in !$CUF KERNEL DO (#92154)

A !$CUF KERNEL DO directive is allowed to have advisory REDUCE clauses
similar to those in OpenACC and DO CONCURRENT. Parse and represent them.
Semantic validation will follow.

show more ...

[flang] Parse !$CUF KERNEL DO <<< (*) (#85338)

Accept and represent asterisks within the parenthesized grid and block
specification lists.

[flang] Add notify-type and notify-wait-stmt (#76594)

Add `notify-type` to `iso_fortran_env` module. Add `notify-wait-stmt` to
the parser and add checks for constraints on the statement, `C1177` an

[flang] Add notify-type and notify-wait-stmt (#76594)

Add `notify-type` to `iso_fortran_env` module. Add `notify-wait-stmt` to
the parser and add checks for constraints on the statement, `C1177` and
`C1178`, from the Fortran 2023 standard. Add three semantics tests for
`notify-wait-stmt`.

show more ...

[flang] Fix construct names on labeled DO (#67622)

Fortran requires that a DO construct with a construct name end with an
END DO statement bearing the same name. This is true even if the DO
constr

[flang] Fix construct names on labeled DO (#67622)

Fortran requires that a DO construct with a construct name end with an
END DO statement bearing the same name. This is true even if the DO
construct begins with a label DO statement; e.g., "constrName: do 10
j=1,10" must end with "10 end do constrName".

The compiler presently basically ignores construct names that appear on
label DO statements, because only non-label DO statements can be parsed
as DO constructs. This causes us to miss some errors, and (worse) breaks
the usage of the construct name on CYCLE and EXIT statements.

To fix this, this patch changes the parse tree and parser so that a DO
construct name on a putative label DO statement causes it to be parsed
as a "non-label" DO statement... with a label. Only true old-style
labeled DO statements without construct names are now parsed as such.

I did not change the class name NonLabelDoStmt -- it's widely used
across the front-end, and is the name of a production in the standard's
grammar. But now it basically means DoConstructDoStmt.

Fixes https://github.com/llvm/llvm-project/issues/67283.

show more ...

[flang][openacc] Relax rule for end directive on combined construct

Make the keyword `loop` optional for the end driective on combined
construct. This done to extend compatibility with other compile

[flang][openacc] Relax rule for end directive on combined construct

Make the keyword `loop` optional for the end driective on combined
construct. This done to extend compatibility with other compiler that
allow this.

Reviewed By: razvanlupusoru

Differential Revision: https://reviews.llvm.org/D151856

show more ...

[flang] CUDA Fortran - part 1/5: parsing

Begin upstreaming of CUDA Fortran support in LLVM Flang.

This first patch implements parsing for CUDA Fortran syntax,
including:
- a new LanguageFeature en

[flang] CUDA Fortran - part 1/5: parsing

Begin upstreaming of CUDA Fortran support in LLVM Flang.

This first patch implements parsing for CUDA Fortran syntax,
including:
- a new LanguageFeature enum value for CUDA Fortran
- driver change to enable that feature for *.cuf and *.CUF source files
- parse tree representation of CUDA Fortran syntax
- dumping and unparsing of the parse tree
- the actual parsers for CUDA Fortran syntax
- prescanning support for !@CUF and !$CUF
- basic sanity testing via unparsing and parse tree dumps

... along with any minimized changes elsewhere to make these
work, mostly no-op cases in common::visitors instances in
semantics and lowering to allow them to compile in the face
of new types in variant<> instances in the parse tree.

Because CUDA Fortran allows the kernel launch chevron syntax
("call foo<<<blocks, threads>>>()") only on CALL statements and
not on function references, the parse tree nodes for CallStmt,
FunctionReference, and their shared Call were rearranged a bit;
this caused a fair amount of one-line changes in many files.

More patches will follow that implement CUDA Fortran in the symbol
table and name resolution, and then semantic checking.

Differential Revision: https://reviews.llvm.org/D150159

show more ...

[flang] Better error recovery for missing THEN in IF construct

Presented with "IF (...)" with no following tokens in the statement,
diagnose a missing "THEN" instead of complaining about all of the

[flang] Better error recovery for missing THEN in IF construct

Presented with "IF (...)" with no following tokens in the statement,
diagnose a missing "THEN" instead of complaining about all of the
possible action statement initial tokens that could have been there
for a non-construct IF statement.

Fixes https://github.com/llvm/llvm-project/issues/62299.

Differential Revision: https://reviews.llvm.org/D150783

show more ...

[flang] Improve error recovery for bad/missing construct END statements

When a multi-statement construct should end with a particular END statement
like "END SELECT", and that construct's END statem

[flang] Improve error recovery for bad/missing construct END statements

When a multi-statement construct should end with a particular END statement
like "END SELECT", and that construct's END statement is missing or
unrecognizable, the error recovery productions should not misinterpret
a program unit END statement that follows and consume it as a misspelled
construct END statement. Doing so leads to cascading errors or a failed parse.

Differential Revision: https://reviews.llvm.org/D136896

show more ...

[flang] Add explanatory messages to grammar for language extensions

Extend "extension<LanguageFeature>()" to incorporate an explanatory
message better than the current generic "nonstandard usage:".

[flang] Add explanatory messages to grammar for language extensions

Extend "extension<LanguageFeature>()" to incorporate an explanatory
message better than the current generic "nonstandard usage:".

Differential Revision: https://reviews.llvm.org/D122035

show more ...

[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 h

[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

show more ...

[flang][openacc] Handle optional end directive in combined construct

OpenACC combined construct can have an optional end directive. This patch handle this
case in the parsing/unparsing with a canoni

[flang][openacc] Handle optional end directive in combined construct

OpenACC combined construct can have an optional end directive. This patch handle this
case in the parsing/unparsing with a canonicalization step. Unlike OmpEndLoopDirective,
this doesn't need a special treatment in the pre-fir tree as there is no clause attached to
a AccEndCombinedDirective.

Reviewed By: klausler

Differential Revision: https://reviews.llvm.org/D84481

show more ...

[flang][openacc] OpenACC 3.0 parser

Summary:
This patch introduce the parser for OpenACC 3.0 in Flang. It uses the same TableGen mechanism
than OpenMP.

Reviewers: nvdatian, sscalpone, tskeith, klau

[flang][openacc] OpenACC 3.0 parser

Summary:
This patch introduce the parser for OpenACC 3.0 in Flang. It uses the same TableGen mechanism
than OpenMP.

Reviewers: nvdatian, sscalpone, tskeith, klausler, ichoyjx, jdoerfert, DavidTruby

Reviewed By: klausler

Subscribers: MaskRay, SouraVX, mgorny, hiraditya, jfb, sstefan1, llvm-commits

Tags: #llvm, #flang

Differential Revision: https://reviews.llvm.org/D83649

show more ...

Revert "[flang][openacc] OpenACC 3.0 parser"

This reverts commit 65049d16100af360674659fb56e8f9bec96a0836.

Buildbot failure clang-ppc64le-rhel

[flang][openacc] OpenACC 3.0 parser

Summary:
This patch introduce the parser for OpenACC 3.0 in Flang. It uses the same TableGen mechanism
than OpenMP.

Reviewers: nvdatian, sscalpone, tskeith, klau

[flang][openacc] OpenACC 3.0 parser

Summary:
This patch introduce the parser for OpenACC 3.0 in Flang. It uses the same TableGen mechanism
than OpenMP.

Reviewers: nvdatian, sscalpone, tskeith, klausler, ichoyjx, jdoerfert, DavidTruby

Reviewed By: klausler

Subscribers: SouraVX, mgorny, hiraditya, jfb, sstefan1, llvm-commits

Tags: #llvm, #flang

Differential Revision: https://reviews.llvm.org/D83649

show more ...

[flang] Merge flang-compiler/f18

This is the initial merge of flang-compiler, which is done in this way
principally to preserve the history and git-blame, without generating a large
number of commit

[flang] Merge flang-compiler/f18

This is the initial merge of flang-compiler, which is done in this way
principally to preserve the history and git-blame, without generating a large
number of commits on the first-parent history of LLVM.

If you don't care about the flang history during a bisect remember that you can
supply paths to git-bisect, e.g. `git bisect start clang llvm`.

The history of f18 was rewritten to:

* Put the code under /flang/.
* Linearize the history.
* Rewrite commit messages so that issue and PR numbers point to the old repository.

Credit to Peter Waller for writing the flatten and merge script.

Updates: flang-compiler/f18#876 (submission into llvm-project)
Mailing-list: http://lists.llvm.org/pipermail/llvm-dev/2020-January/137989.html ([llvm-dev] Flang landing in the monorepo - next Monday!)
Mailing-list: http://lists.llvm.org/pipermail/llvm-dev/2019-December/137661.html ([llvm-dev] Flang landing in the monorepo)

Co-authored-by: Peter Waller <peter.waller@arm.com>

show more ...

[flang] Reformat with latest clang-format and .clang-format

Original-commit: flang-compiler/f18@9fe84f45d7fd685051004678d6b5775dcc4c6f8f
Reviewed-on: https://github.com/flang-compiler/f18/pull/1094

[flang] [LLVMify F18] Compiler module folders should have capitalised names (flang-compiler/f18#980)

This patch renames the modules in f18 to use a capital letter in the
module name

Signed-off-b

[flang] [LLVMify F18] Compiler module folders should have capitalised names (flang-compiler/f18#980)

This patch renames the modules in f18 to use a capital letter in the
module name

Signed-off-by: Caroline Concatto <caroline.concatto@arm.com>

Original-commit: flang-compiler/f18@d2eb7a1c443d1539ef12b6f027074a0eb15b1ea0
Reviewed-on: https://github.com/flang-compiler/f18/pull/980

show more ...