[flang] Fix references to destroyed objects (#111582)

ProgramTree instances are created as the value of a local variable in
the Pre(const parser::ProgramUnit &) member function in name resolution.

[flang] Fix references to destroyed objects (#111582)

ProgramTree instances are created as the value of a local variable in
the Pre(const parser::ProgramUnit &) member function in name resolution.
But references to these ProgramTree instances can persist in
SubprogramNameDetails symbol table entries that might survive that
function call's lifetime, and lead to trouble later when (e.g.)
expression semantics needs to deal with a possible forward reference in
a function reference in an expression being processed later in
expression checking.

So put those ProgramTree instances into a longer-lived linked list
within the SemanticsContext.

Might fix some weird crashes reported on big-endian targets (AIX &
Solaris).

show more ...

[flang][semantics][OpenMP] no privatisation of stmt functions (#106550)

OpenMP prohibits privatisation of variables that appear in expressions
for statement functions.

This is a re-working of an

[flang][semantics][OpenMP] no privatisation of stmt functions (#106550)

OpenMP prohibits privatisation of variables that appear in expressions
for statement functions.

This is a re-working of an old patch https://reviews.llvm.org/D93213 by
@praveen-g-ctt.

The old patch couldn't be landed because of ordering concerns. Statement
functions are rewritten during parse tree rewriting, but this was done
after resolve-directives and so some array expressions were incorrectly
identified as statement functions. For this reason **I have opted to
re-order the semantics driver so that resolve-directives is run after
parse tree rewriting**.

Closes #54677

---------

Co-authored-by: Praveen <praveen@compilertree.com>

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][Semantics] Add LangOptions to SemanticsContext (#110013)

The motivation for this is to make OpenMP settings visible in the
semantic checks (OpenMP version in particular).

[flang] Fix spurious error with separate module procedures (#106768)

When the implementation of one SMP apparently references another in what
might be a specification expression, semantics may need

[flang] Fix spurious error with separate module procedures (#106768)

When the implementation of one SMP apparently references another in what
might be a specification expression, semantics may need to resolve it as
a forward reference, and to allow for the replacement of a
SubprogramNameDetails place-holding symbol with the final
SubprogramDetails symbol. Otherwise, as in the bug report below,
confusing error messages may result.

(The reference in question isn't really in the specification part of a
subprogram, but due to the syntactic ambiguity between the array element
assignment statement and a statement function definition, it appears to
be so at the time that the reference is processed.)

I needed to make DumpSymbols() available via SemanticsContext to analyze
this bug, and left that new API in place to make things easier next
time.

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

show more ...

[flang] Warn on useless IOMSG= (#102250)

An I/O statement with IOMSG= but neither ERR= nor IOSTAT= deserves a
warning to the effect that it's not useful.

[flang] Warn about undefined function results (#99533)

When the result of a function never appears in a variable definition
context, emit a warning.

If the function has multiple result variables

[flang] Warn about undefined function results (#99533)

When the result of a function never appears in a variable definition
context, emit a warning.

If the function has multiple result variables due to alternate ENTRY
statements, any definition will suffice.

The implementation of this check is tied to the general variable
definability checking utility in semantics. Every variable definition
context uses it to ensure that no undefinable variable is being defined.
A set of defined variables is maintained in the SemanticsContext and,
when the warning is enabled and no fatal error has been reported, the
scope tree is traversed and all the function subprograms' results are
tested for membership in that set.

show more ...

[flang] Add -fhermetic-module-files (#98083)

Module files emitted by this Fortran compiler are valid Fortran source
files. Symbols that are USE-associated into modules are represented in
their mod

[flang] Add -fhermetic-module-files (#98083)

Module files emitted by this Fortran compiler are valid Fortran source
files. Symbols that are USE-associated into modules are represented in
their module files with USE statements and special comments with hash
codes in them to ensure that those USE statements resolve to the same
modules that were used to build the module when its module file was
generated.

This scheme prevents unchecked module file growth in large applications
by not emitting USE-associated symbols redundantly. This problem can be
especially bad when derived type definitions must be repeated in the
module files of their clients, and the clients of those modules, and so
on. However, this scheme has the disadvantage that clients of modules
must be compiled with dependent modules in the module search path.

This new -fhermetic-module-files option causes module file output to be
free of dependences on any non-intrinsic module files; dependent modules
are instead emitted as part of the module file, rather than being
USE-associated. It is intended for top level library module files that
are shipped with binary libraries when it is not convenient to collect
and ship their dependent module files as well.

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

show more ...

[flang] Implement !DIR$ VECTOR ALWAYS (#93830)

This patch implements support for the VECTOR ALWAYS directive, which
forces
vectorization to occurr when possible regardless of a decision by the
cost

[flang] Implement !DIR$ VECTOR ALWAYS (#93830)

This patch implements support for the VECTOR ALWAYS directive, which
forces
vectorization to occurr when possible regardless of a decision by the
cost
model. This is done by adding an attribute to the branch into the loop
in LLVM
to indicate that the loop should always be vectorized.

This patch only implements this directive on plan structured do loops
without labels. Support for unstructured loops and array
expressions is planned for future patches.

show more ...

[flang][cuda] Implicitly load cudadevice module in device/global subprogram (#92038)

This is a re-worked version of #91668. It adds the `cudadevice` module
and set the `device` attributes on its fu

[flang][cuda] Implicitly load cudadevice module in device/global subprogram (#92038)

This is a re-worked version of #91668. It adds the `cudadevice` module
and set the `device` attributes on its functions/subroutines so there is
no need for special case in semantic check.
`cudadevice` module is implicitly USE'd in `global`/`device` subprogram.

show more ...

Revert "[flang][cuda] Implicitly load cudadevice module in device/global subprogram" (#91827)

Reverts llvm/llvm-project#91668

[flang][cuda] Implicitly load cudadevice module in device/global subprogram (#91668)

Some functions and subroutines are available in device context
(device/global). These functions have interfaces

[flang][cuda] Implicitly load cudadevice module in device/global subprogram (#91668)

Some functions and subroutines are available in device context
(device/global). These functions have interfaces declared in the
`cudadevice` module.

This patch adds interfaces as `__cuda_device_builtins_<fctname>` in a
builtin module and they are USE'd rename in the `cudadevice` module. The
module is implicitly used in device/global subprograms.

The builtin module only contains procedures from section 3.6.4 for now.

show more ...

[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] Intermix messages from parser and semantic analysis (#90654)

When there are one or more fatal error messages produced by the parser,
semantic analysis is not performed. But when there are m

[flang] Intermix messages from parser and semantic analysis (#90654)

When there are one or more fatal error messages produced by the parser,
semantic analysis is not performed. But when there are messages produced
by the parser and none of them are fatal, those messages are emitted to
the user before compilation continues with semantic analysis, and any
messages produced by semantics are emitted after the messages from
parsing.

This can be confusing for the user, as the messages may no longer all be
in source file location order. It also makes it difficult to write tests
that check for both non-fatal messages from parsing as well as messages
from semantics using inline CHECK: or other expected messages in test
source code.

This patch ensures that if semantic analysis is performed, and non-fatal
messages were produced by the parser, that all the messages will be
combined and emitted in source file order.

show more ...

[flang] Use module file hashes for more checking and disambiguation (#80354)

f18's module files are Fortran with a leading header comment containing
the module file format version and a hash of the

[flang] Use module file hashes for more checking and disambiguation (#80354)

f18's module files are Fortran with a leading header comment containing
the module file format version and a hash of the following contents.
This hash is currently used only to protect module files against
corruption and truncation.

Extend the use of these hashes to catch or avoid some error cases. When
one module file depends upon another, note its hash in additional module
file header comments. This allows the compiler to detect when the module
dependency is on a module file that has been updated. Further, it allows
the compiler to find the right module file dependency when the same
module file name appears in multiple directories on the module search
path.

The order in which module files are written, when multiple modules
appear in a source file, is such that every dependency is written before
the module(s) that depend upon it, so that their hashes are known.

A warning is emitted when a module file is not the first hit on the
module file search path.

Further work is needed to add a compiler option that emits (larger)
stand-alone module files that incorporate copies of their dependencies
rather than relying on search paths. This will be desirable for
application libraries that want to ship only "top-level" module files
without needing to include their dependencies.

Another future work item would be to admit multiple modules in the same
compilation with the same name if they have distinct hashes.

show more ...

[flang] Set KIND in compiler generated COUNT for SIZE(PACK) (#79801)

Compiler was rewriting SIZE(PACK(x, MASK)) to COUNT(MASK). It was
wrapping the COUNT call without a KIND argument (leading to IN

[flang] Set KIND in compiler generated COUNT for SIZE(PACK) (#79801)

Compiler was rewriting SIZE(PACK(x, MASK)) to COUNT(MASK). It was
wrapping the COUNT call without a KIND argument (leading to INTEGER(4)
result in the characteristics) in an Expr<ExtentType> (implying
INTEGER(8) result), this lead to inconsistencies that later hit verifier
errors in lowering.

Set the KIND argument to the KIND of ExtentType to ensure the built
expression is consistent.

This requires giving access to some safe place where the "kind" name can
be saved and turned into a CharBlock (count has a DIM argument that
require using the KIND keyword here). For the FoldingContext that belong
to SemanticsContext, this is the same string set as the one used by
SemanticsContext for similar purposes.

show more ...

[flang] Ensure that portability warnings are conditional (#71857)

Before emitting a warning message, code should check that the usage in
question should be diagnosed by calling ShouldWarn(). A fair

[flang] Ensure that portability warnings are conditional (#71857)

Before emitting a warning message, code should check that the usage in
question should be diagnosed by calling ShouldWarn(). A fair number of
sites in the code do not, and can emit portability warnings
unconditionally, which can confuse a user that hasn't asked for them
(-pedantic) and isn't terribly concerned about portability *to* other
compilers.

Add calls to ShouldWarn() or IsEnabled() around messages that need them,
and add -pedantic to tests that now require it to test their portability
messages, and add more expected message lines to those tests when
-pedantic causes other diagnostics to fire.

show more ...

[flang] Use BIND name, if any, when consolidating common blocks (#65613)

This patch changes how common blocks are aggregated and named in
lowering in order to:

* fix one obvious issue where BIND

[flang] Use BIND name, if any, when consolidating common blocks (#65613)

This patch changes how common blocks are aggregated and named in
lowering in order to:

* fix one obvious issue where BIND(C) and non BIND(C) with the same
Fortran name were "merged"

* go further and deal with a derivative where the BIND(C) C name matches
the assembly name of a Fortran common block. This is a bit unspecified
IMHO, but gfortran, ifort, and nvfortran "merge" the common block
without complaints as a linker would have done. This required getting
rid of all the common block mangling early in FIR (\_QC) instead of
leaving that to the phase that emits LLVM from FIR because BIND(C)
common blocks did not have mangled names. Care has to be taken to deal
with the underscoring option of flang-new.

See added flang/test/Lower/HLFIR/common-block-bindc-conflicts.f90 for an
illustration.

show more ...

[flang] Faster implementation of FindScope()

The utility semantics::SemanticsContext::FindScope() maps a contiguous
range of cooked source characters to the innermost Scope containing
them. Its imp

[flang] Faster implementation of FindScope()

The utility semantics::SemanticsContext::FindScope() maps a contiguous
range of cooked source characters to the innermost Scope containing
them. Its implementation is unacceptably slow on large (tens of
thousands of lines) source files with many program units; it traverses
each level of the scope tree linearly.

Replace this implementation with a single instance of std::multimap<>
used as an index from each Scope's source range back to the Scope.

Compilation time with "-fsyntax-only" on the 50,000-line test case
that motivated this change drops from 4.36s to 3.72s, and FindScope()
no longer stands out egregiously in the profile.

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

show more ...

[flang][openacc] Enforce restriction on declare directive

Enforce the following restriction specified in 2.13
A var may appear at most once in all the clauses of declare directives for a
function, s

[flang][openacc] Enforce restriction on declare directive

Enforce the following restriction specified in 2.13
A var may appear at most once in all the clauses of declare directives for a
function, subroutine, program, or module.

Reviewed By: razvanlupusoru

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

show more ...

[flang] Add a subset of PowerPC MMA (Matrix Multiply Accelerate) intrinsics

This patch includes the a subset of MMA intrinsics that are included in
the mma intrinsic module:

mma_assemble_acc
mma_as

[flang] Add a subset of PowerPC MMA (Matrix Multiply Accelerate) intrinsics

This patch includes the a subset of MMA intrinsics that are included in
the mma intrinsic module:

mma_assemble_acc
mma_assemble_pair
mma_build_acc
mma_disassemble_acc
mma_disassemble_pair

Submit on behalf of Daniel Chen <cdchen@ca.ibm.com>

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

show more ...

[flang] Honor #line and related preprocessing directives

Extend the SourceFile class to take account of #line directives
when computing source file positions for error messages.
Adjust the output of

[flang] Honor #line and related preprocessing directives

Extend the SourceFile class to take account of #line directives
when computing source file positions for error messages.
Adjust the output of #line directives to -E output so that they
reflect any #line directives that were in the input.

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

show more ...

[flang] Rename remaining `__Fortran_PPC_intrinsics` to `__ppc_intrinsics`

Reviewed By: kkwli0

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

[flang] rename PPC specific intrinsic modules (NFC)

[flang] Add PowerPC vec_add, vec_and, vec_mul, vec_sub and vec_xor intrinsics

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