[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] Accept a compiler directive sentinel after a semicolon (#96966)

Don't treat !DIR$ or an active !$ACC, !$OMP, &c. as a comment when they
appear after a semicolon, but instead treat them as a

[flang] Accept a compiler directive sentinel after a semicolon (#96966)

Don't treat !DIR$ or an active !$ACC, !$OMP, &c. as a comment when they
appear after a semicolon, but instead treat them as a compiler directive
sentinel.

show more ...

[flang][preprocessor] Fixed-form continuation across preprocessing di… (#95332)

…rective

Implement fixed-form line continuation when the continuation line is the
result of text produced by an #i

[flang][preprocessor] Fixed-form continuation across preprocessing di… (#95332)

…rective

Implement fixed-form line continuation when the continuation line is the
result of text produced by an #include or other preprocessing directive.
This accommodates the somewhat common practice of putting dummy or
actual arguments into a header file and #including it into several code
sites.

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

show more ...

[flang] Disable Fortran free form line continuation in non-source lin… (#94663)

…e produced by keyword macro replacement

When later initial keyword macro replacement will yield a line that is
no

[flang] Disable Fortran free form line continuation in non-source lin… (#94663)

…e produced by keyword macro replacement

When later initial keyword macro replacement will yield a line that is
not Fortran source, don't interpret "&" as a Fortran source line
continuation marker during tokenization of the line.

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

show more ...

[flang][Frontend] Implement printing defined macros via -dM (#87627)

This should work the same way as in clang.

[flang] Avoid forming a reference from null pointer (#84787)

Doing so is an undefined behavior.

This was detected by the undefined behavior sanitizer.

[flang] Accept directive sentinels in macro-replaced source better (#70699)

At present, the prescanner emits an error if a source line or compiler
directive, after macro replacement or not, contain

[flang] Accept directive sentinels in macro-replaced source better (#70699)

At present, the prescanner emits an error if a source line or compiler
directive, after macro replacement or not, contains a token with a
non-Fortran character. In the particular case of the '!' character, the
code that checks for bad character will accept the '!' if it appears
after a ';', since the '!' might begin a compiler directive.

This current implementation fails when a compiler directive appears
after some other character that might (by means of further source
processing not visible to the prescanner) be replaced with a ';' or
newline.

Extend the bad character check for '!' to actually check for a compiler
directive sentinel instead.

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] Fix character initialization after continuation

The insertion of a space on a line continuation right before
a character literal was confusing TokenSequence::ToLowerCase(),
that was unable t

[flang] Fix character initialization after continuation

The insertion of a space on a line continuation right before
a character literal was confusing TokenSequence::ToLowerCase(),
that was unable to identify the character literal as such,
causing it to be converted to lower case.

Fix this by skipping spaces in the beginning and end of each
token, before testing for token type.

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

Reviewed By: klausler

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

show more ...

[flang] Allow compiler directives in macros

Modify the prescanner to allow compiler directives to appear in
macro expansions, and adjust the parser to accept a semicolon
as a directive terminator.

[flang] Allow compiler directives in macros

Modify the prescanner to allow compiler directives to appear in
macro expansions, and adjust the parser to accept a semicolon
as a directive terminator.

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

show more ...

[flang] Fix new assertion failure

Don't compute the address of element [0] of a vector when the vector
is empty, even if the address is not used.

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

[flang] Fix new assertion failure

Don't compute the address of element [0] of a vector when the vector
is empty, even if the address is not used.

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

show more ...

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

[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

show more ...

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

[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

show more ...

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

[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

show more ...

Do not dereference an array out of bound just to take its address

This is UB by the standard, and caught by the libstdc++ asserts

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

[flang] Improve error handling for bad characters in source

When an illegal character appears in Fortran source (after
preprocessing), catch and report it in the prescanning phase
rather than leavin

[flang] Improve error handling for bad characters in source

When an illegal character appears in Fortran source (after
preprocessing), catch and report it in the prescanning phase
rather than leaving it for the parser to cope with.

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

show more ...

[flang] Allow ! and // comments after some preprocessing directives

Old-style C /*comments*/ are omitted from preprocessor directive
token sequences by the prescanner, but line-ending C++ and Fortra

[flang] Allow ! and // comments after some preprocessing directives

Old-style C /*comments*/ are omitted from preprocessor directive
token sequences by the prescanner, but line-ending C++ and Fortran
free-form comments are not since their handling might depend on
the directive. Add code to skip these line-ending comments as
appropriate in place of existing code that just skipped blanks.

Reviewed By: sscalpone

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

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] Replace the use std::ostream with LLVM streams llvm::ostream

This patch replaces the occurrence of std::ostream by llvm::raw_ostream.
In LLVM Coding Standards[1] "All new code

[flang] [LLVMify F18] Replace the use std::ostream with LLVM streams llvm::ostream

This patch replaces the occurrence of std::ostream by llvm::raw_ostream.
In LLVM Coding Standards[1] "All new code should use raw_ostream
instead of ostream".[1]

As a consequence, this patch also replaces the use of:
std::stringstream by llvm::raw_string_ostream or llvm::raw_ostream*
std::ofstream by llvm::raw_fd_ostream
std::endl by '\n' and flush()[2]
std::cout by llvm::outs() and
std::cerr by llvm::errs()

It also replaces std::strerro by llvm::sys::StrError** , but NOT in Fortran
runtime libraries

*std::stringstream were replaced by llvm::raw_ostream in all methods that
used std::stringstream as a parameter. Moreover, it removes the pointers to
these streams.

[1]https://llvm.org/docs/CodingStandards.html
[2]https://releases.llvm.org/2.5/docs/CodingStandards.html#ll_avoidendl

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

Running clang-format-7

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

Removing residue of ostream library

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

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

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