[flang] Accept CHANGE TEAM/END TEAM as branch target (#123822)

It is valid to jump to a CHANGE TEAM statement from anywhere in the
containing executable part, and valid to jump to an END TEAM state

[flang] Accept CHANGE TEAM/END TEAM as branch target (#123822)

It is valid to jump to a CHANGE TEAM statement from anywhere in the
containing executable part, and valid to jump to an END TEAM statement
from within the construct.

show more ...

[flang] Tag warnings with LanguageFeature or UsageWarning (#110304)

(This is a big patch, but it's nearly an NFC. No test results have
changed and all Fortran tests in the LLVM test suites work as

[flang] Tag warnings with LanguageFeature or UsageWarning (#110304)

(This is a big patch, but it's nearly an NFC. No test results have
changed and all Fortran tests in the LLVM test suites work as expected.)

Allow a parser::Message for a warning to be marked with the
common::LanguageFeature or common::UsageWarning that controls it. This
will allow a later patch to add hooks whereby a driver will be able to
decorate warning messages with the names of its options that enable each
particular warning, and to add hooks whereby a driver can map those
enumerators by name to command-line options that enable/disable the
language feature and enable/disable the messages.

The default settings in the constructor for LanguageFeatureControl were
moved from its header file into its C++ source file.

Hooks for a driver to use to map the name of a feature or warning to its
enumerator were also added.

To simplify the tagging of warnings with their corresponding language
feature or usage warning, to ensure that they are properly controlled by
ShouldWarn(), and to ensure that warnings never issue at code sites in
module files, two new Warn() member function templates were added to
SemanticsContext and other contextual frameworks. Warn() can't be used
before source locations can be mapped to scopes, but the bulk of
existing code blocks testing ShouldWarn() and FindModuleFile() before
calling Say() were convertible into calls to Warn(). The ones that were
not convertible were extended with explicit calls to
Message::set_languageFeature() and set_usageWarning().

show more ...

[flang] Disallow branches into SELECT TYPE/RANK cases (#93893)

Ensure that a branch cannot be made into a case of a SELECT TYPE or
SELECT RANK construct.

[flang] Ensure all warning/portability messages are guarded by Should… (#90518)

…Warn()

Many warning messages were being emitted unconditionally. Ensure that
all warnings are conditional on a tr

[flang] Ensure all warning/portability messages are guarded by Should… (#90518)

…Warn()

Many warning messages were being emitted unconditionally. Ensure that
all warnings are conditional on a true result from a call to
common::LanguageFeatureControl::ShouldWarn() so that it is easy for a
driver to disable them all, or, in the future, to provide per-warning
control over them.

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] Allow GOTO to containing END IF after ELSE

Label resolution gets into an infinite loop trying to emit an inappropriate
error or warning for a GOTO whose target is on an enclosing END IF
stat

[flang] Allow GOTO to containing END IF after ELSE

Label resolution gets into an infinite loop trying to emit an inappropriate
error or warning for a GOTO whose target is on an enclosing END IF
statement with an intervening ELSE or ELSE IF. The scope tracking mechanism
viewed the END IF as being part of the ELSE block's scope.

Fix with the same means that was used to fix a similar bogus error
on GOTOs to END SELECT in SELECT CASE blocks: nest the THEN/ELSE IF/ELSE
blocks one level deeper than before, so that the END IF is in the IF
block but not in any of its parts.

Fixes https://github.com/llvm/llvm-project/issues/64654 for
llvm-test-suite/Fortran/gfortran/regression/goto_5.f90.

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

show more ...

[flang] Finer control over warnings

Establish a set of optional usage warnings, and enable some
only in "-pedantic" mode that, in our subjective experience
with application codes, seem to issue freq

[flang] Finer control over warnings

Establish a set of optional usage warnings, and enable some
only in "-pedantic" mode that, in our subjective experience
with application codes, seem to issue frequently without
indicating usage that really needs to be corrected. By default,
with this patch the compiler should appear to be somewhat less
persnickety but not less informative.

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

show more ...

[nfc][flang] Eliminate the dependency on cctype by using characters.h

Reviewed By: klausler

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

[flang] Add nested scoping to label distinctness checking

Fortran defines derived type definitions and explicit interface
blocks for subroutines and functions to be nestable scopes for
statement lab

[flang] Add nested scoping to label distinctness checking

Fortran defines derived type definitions and explicit interface
blocks for subroutines and functions to be nestable scopes for
statement labels, even though such labels are useless for all
purposes. Handle these scopes in label resolution so that bogus
errors about conflicting labels in "real" code don't come out.

Note that BLOCK constructs could have also been defined as scopes
for statement labeling, but were not.

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

show more ...

[flang] Fix bogus branch target error on END SELECT

The scope model used for branch target checking treats a label
on an END SELECT statement as if it were in the previous CASE block.
This makes it

[flang] Fix bogus branch target error on END SELECT

The scope model used for branch target checking treats a label
on an END SELECT statement as if it were in the previous CASE block.
This makes it illegal to GO TO that label from within any earlier
CASE block in that statement. Fix by treating the CASE blocks as
nested scopes within the scope of the SELECT construct.

Also, add a "warning:" tag to related warning messages.

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

show more ...

[flang] Fix semantic analysis for "forall" targeted by "label"

As Fortran 2018 3.18 states, the branch target statement can be
`forall-construct-stmt`, but cannot be `forall-stmt`. `forall-stmt` is

[flang] Fix semantic analysis for "forall" targeted by "label"

As Fortran 2018 3.18 states, the branch target statement can be
`forall-construct-stmt`, but cannot be `forall-stmt`. `forall-stmt` is
wrapped by `Statement` in `action-stmt` and `action-stmt` can be one
branch target statement. Fix the semantic analysis and add two
regression test cases in lowering.

Reviewed By: Jean Perier

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

show more ...

[flang] Distinguish usage and portability warning messages

Using recently established message severity codes, upgrade
non-fatal messages to usage and portability warnings as
appropriate.

Differenti

[flang] Distinguish usage and portability warning messages

Using recently established message severity codes, upgrade
non-fatal messages to usage and portability warnings as
appropriate.

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

show more ...

[flang] Allow exterior branch to outermost WHERE construct statement

The labels of WHERE constructs were being created within the scope of
the construct, not the scope of its parent, leading to inco

[flang] Allow exterior branch to outermost WHERE construct statement

The labels of WHERE constructs were being created within the scope of
the construct, not the scope of its parent, leading to incorrect error
messages for branches to that label.

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

show more ...

[flang] Distinguish error/warning cases for bad jumps into constructs

Previously, jumps to labels in constructs from exterior statements
would elicit only a warning. Upgrade these to errors unless

[flang] Distinguish error/warning cases for bad jumps into constructs

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

show more ...

[flang] Catch branching into FORALL/WHERE constructs

Enforce constraints C1034 & C1038, which disallow the use
of otherwise valid statements as branch targets when they
appear in FORALL &/or WHERE c

[flang] Catch branching into FORALL/WHERE constructs

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

show more ...

[flang] Revamp C1502 checking of END INTERFACE [generic-spec]

Validation of the optional generic-spec on an END INTERFACE statement
was missing many possible error cases; reimplement it.

Differenti

[flang] Revamp C1502 checking of END INTERFACE [generic-spec]

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

show more ...

[flang] Allow labels on END statements.

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

[flang] Allow labels on END statements.

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

show more ...

[flang] Add name match checks for interface procedures

We had neglected to check for name mismatches for procedure definitions that
appear in interfaces.

I also changed label11.f90 to an error test

[flang] Add name match checks for interface procedures

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

show more ...

[flang] Format label scope is independent of block scope

Compilation of the following program currently generates a warning message:

i = 1
if (i .eq. 0) then
write(6, 200)

[flang] Format label scope is independent of block scope

Compilation of the following program currently generates a warning message:

i = 1
if (i .eq. 0) then
write(6, 200) i
200 format (I8)
end if
write(6, 200) i
end

x.f90:6:9: Label '200' is not in scope
write(6, 200) i
^^^^^^^^^^^^^^^

Whereas branch targets must conform to the Clause 11.1.2.1 program
requirement "Transfer of control to the interior of a block from
outside the block is prohibited, ...", this doesn't apply to format
statement references.

show more ...

[flang] Process names in ASSIGN and assigned GOTO

Allow ASSIGNed integer variables as formats

Address review comment

Original-commit: flang-compiler/f18@361a151508b4a1940fc0669dead180be67964d8d
Re

[flang] Process names in ASSIGN and assigned GOTO

Allow ASSIGNed integer variables as formats

Address review comment

Original-commit: flang-compiler/f18@361a151508b4a1940fc0669dead180be67964d8d
Reviewed-on: https://github.com/flang-compiler/f18/pull/1099

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] Changes to get a clean build of f18 with latest clang

Prep for review

Original-commit: flang-compiler/f18@111f49061e07604670614250197a1064959fd981
Reviewed-on: https://github.com/flang-comp

[flang] Changes to get a clean build of f18 with latest clang

Prep for review

Original-commit: flang-compiler/f18@111f49061e07604670614250197a1064959fd981
Reviewed-on: https://github.com/flang-compiler/f18/pull/1059

show more ...

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