[flang] Handle "defined" in macro expansions (#114844)

The preprocessor implements "defined(X)" and "defined X" in if/elif
directive expressions in such a way that they only work at the top
level,

[flang] Handle "defined" in macro expansions (#114844)

The preprocessor implements "defined(X)" and "defined X" in if/elif
directive expressions in such a way that they only work at the top
level, not when they appear in macro expansions. Fix that, which is a
little tricky due to the need to detect the "defined" keyword before
applying any macro expansion to its argument, and add a bunch of tests.

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

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][preprocessor] Change handling of macros in text from Fortran … (#108113)

…INCLUDE lines

The compiler current treats an INCLUDE line as essentially a synonym for
a preprocessing #include

[flang][preprocessor] Change handling of macros in text from Fortran … (#108113)

…INCLUDE lines

The compiler current treats an INCLUDE line as essentially a synonym for
a preprocessing #include directive. The causes macros that have been
defined at the point where the INCLUDE line is processed to be replaced
within the text of the included file.

This behavior is surprising to users who expect an INCLUDE line to be
expanded into its contents *after* preprocessing has been applied to the
original source file, with no further macro expansion.

Change INCLUDE line processing to use a fresh instance of Preprocessor
containing no macro definitions except _CUDA in CUDA Fortran
compilations and, if the original file was being preprocessed, the
standard definitions of __FILE__, __LINE__, and so forth.

show more ...

[flang][preprocessor] Support __TIMESTAMP__ (#98057)

Support the predefined macro __TIMESTAMP__ as interpreted by GCC. It
expands to a character literal with the time of last modification of the
t

[flang][preprocessor] Support __TIMESTAMP__ (#98057)

Support the predefined macro __TIMESTAMP__ as interpreted by GCC. It
expands to a character literal with the time of last modification of the
top-level source file in asctime(3) format, e.g. "Tue Jul 4 10:18:05
1776".

show more ...

[flang][preprocessing] Handle #include after & line continuation (#93382)

Some applications like to use a CPP-style #include directive to pull in
a common list of arguments, dummy arguments, or COM

[flang][preprocessing] Handle #include after & line continuation (#93382)

Some applications like to use a CPP-style #include directive to pull in
a common list of arguments, dummy arguments, or COMMON block variables
after a free-form & line continuation marker. This works naturally with
compilers that run an actual cpp pass over the input before doing
anything specific to Fortran, but it's a case that I missed with this
integrated preprocessor.

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][Frontend] Implement printing defined macros via -dM (#87627)

This should work the same way as in clang.

[flang] Resolve "possible performance problem" issue spam (#79769)

Four "issues" on GitHub report possible performance problems, likely
detected by static analysis. None of them would ever make a m

[flang] Resolve "possible performance problem" issue spam (#79769)

Four "issues" on GitHub report possible performance problems, likely
detected by static analysis. None of them would ever make a measureable
difference in compilation time, but I'm resolving them to clean up the
open issues list.

Fixes https://github.com/llvm/llvm-project/issues/79703, .../79705,
.../79706, & .../79707.

show more ...

[flang] Simplify a string comparison (NFC)

[flang][preprocessor] Replace macros in some #include directives (#80039)

Ensure that #include FOO undergoes macro replacement. But, as is the
case with C/C++, continue to not perform macro replace

[flang][preprocessor] Replace macros in some #include directives (#80039)

Ensure that #include FOO undergoes macro replacement. But, as is the
case with C/C++, continue to not perform macro replacement in a #include
directive with <angled brackets>.

show more ...

[flang] Handle preprocessor macro expansion edge case (#73835)

When a reference to a function-like macro begins during the rescanning
of the expansion of another macro but is not completed by the e

[flang] Handle preprocessor macro expansion edge case (#73835)

When a reference to a function-like macro begins during the rescanning
of the expansion of another macro but is not completed by the end of
that expansion, it is necessary to abort that rescanning of that
expansion and try again when more tokens can be acquired. (See the new
unclosed-FLM.F90 test case.) All other Fortran preprocessors to which I
have access can handle this situation.

show more ...

[flang][preprocessor] Finesse disabling of function-like macros (#71589)

During function-like macro expansion in a standard C/C++ preprocessor,
the macro being expanded is disabled from recursive m

[flang][preprocessor] Finesse disabling of function-like macros (#71589)

During function-like macro expansion in a standard C/C++ preprocessor,
the macro being expanded is disabled from recursive macro expansion. The
implementation in this compiler's preprocessor, however, was too broad;
the macro expansion needs to be disabled for the "rescanning" phase
only, not for actual argument expansion.

(Also corrects an obsolete comment elsewhere that was noticed during
reduction of an original test case.)

show more ...

[flang] Fix crash from empty -DMACRO= (bug #64837)

Some vector indexing code in the preprocessor fails with empty
tokens or token sequences in predefined macros.

Fixes https://github.com/llvm/llvm-

[flang] Fix crash from empty -DMACRO= (bug #64837)

Some vector indexing code in the preprocessor fails with empty
tokens or token sequences in predefined macros.

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

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

show more ...

[flang][Preprocessor] Constrain a bit more implicit continuations

D155499 fixed an issue with implicit continuations. The fixes included a
nested parenthesis check during definition of a macro which

[flang][Preprocessor] Constrain a bit more implicit continuations

D155499 fixed an issue with implicit continuations. The fixes included a
nested parenthesis check during definition of a macro which is then
carried over in the scanner state.

This leads to the following corner case to fail:

subroutine foo(a, d)
implicit none
integer :: a
integer :: d

! An implicit continuation won't be considered unless
! the definition of "bar" above is removed/commented
call sub(1,
2)
end subroutine foo

The definition of bar is indeed unbalanced but it is not even used in
the code, so it should not impact whether we apply implicit continuation
in the expansion of sub.

This change aims at addressing this issue by removing the balance check
and constraining a bit more when we consider implicit continuations:
only when we see a left parenthesis after a function-like macro, not a
object-like macro. In this case I think it is OK to (unconditionally)
implicitly continue to the next line in search of the corresponding
right parenthesis. This is, to my understanding, similar to what the C
preprocessor would do according to the description in [1].

[1] https://www.spinellis.gr/blog/20060626/

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

show more ...

[flang] Stricter "implicit continuation" in preprocessing

The prescanner performs implicit line continuation when it looks
like the parenthesized arguments of a call to a function-like macro
may spa

[flang] Stricter "implicit continuation" in preprocessing

The prescanner performs implicit line continuation when it looks
like the parenthesized arguments of a call to a function-like macro
may span multiple lines. In an attempt to work more like a
Fortran-oblivious C preprocessor, the prescanner will act as if
the following lines had been continuations so that the function-like
macro could be invoked.

This still seems like a good idea, but a recent bug report on
LLVM's GitHub issue tracker shows one way in which it could trigger
inadvertently and mess up a program. So this patch makes the
conditions for implicit line continuation much more strict.

First, the leading parenthesis has to have been preceded by an
identifier that's known to be a macro name. (It doesn't have to
be a function-like macro, since it's possible for a keyword-like
macro to expand to the name of a function-like macro.) Second,
no macro definition can ever have had unbalanced parentheses in
its replacement text.

Also cleans up some parenthesis recognition code to fix some
issues found in testing, so that a token with leading or trailing
spaces can still be recognized as a parenthesis or comma.

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

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

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] 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][preprocessing] Allow keyword macro to rename a function-like macro

#define FOO(x) ((x)+1)
#define BAR FOO
print *, BAR(1)

should work as one would expect.

Fixes https://github.com/llvm/

[flang][preprocessing] Allow keyword macro to rename a function-like macro

#define FOO(x) ((x)+1)
#define BAR FOO
print *, BAR(1)

should work as one would expect.

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

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

show more ...

[flang] Remove macro replacement in angular bracket includes

Addresses Github issue [[ https://github.com/llvm/llvm-project/issues/60317 | #60317 ]].

Reviewed By: klausler

Differential Revision: h

[flang] Remove macro replacement in angular bracket includes

Addresses Github issue [[ https://github.com/llvm/llvm-project/issues/60317 | #60317 ]].

Reviewed By: klausler

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

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] 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 '#'

[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

show more ...

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

[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

show more ...

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

[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

show more ...

[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

[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

show more ...

Revert "[flang] Search for #include "file" in right directory"

This reverts commit d987b61b1dce9948801ac37704477e7c257100b1.

As pointed out in https://reviews.llvm.org/D95388, the reverted commit
c

Revert "[flang] Search for #include "file" in right directory"

This reverts commit d987b61b1dce9948801ac37704477e7c257100b1.

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.

show more ...