History log of /llvm-project/flang/lib/Parser/parsing.cpp (Results 1 – 25 of 27)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6
# 3c3094b6 16-Dec-2024 macurtis-amd <macurtis@amd.com>

[flang] Ensure directive sentinels are in cols 1-5 in pp output (#119406)

Preprocessor output is intended to be valid fixed form.


Revision tags: llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3
# 9fb2db1e 15-Oct-2024 Peter Klausler <pklausler@nvidia.com>

[flang] Retain spaces when preprocessing fixed-form source (#112417)

When running fixed-form source through the compiler under -E, don't
aggressively remove space characters, since the parser won't

[flang] Retain spaces when preprocessing fixed-form source (#112417)

When running fixed-form source through the compiler under -E, don't
aggressively remove space characters, since the parser won't be parsing
the result and some tools might need to see the spaces in the -E
preprocessed output.

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

show more ...


Revision tags: llvmorg-19.1.2, llvmorg-19.1.1
# 4dfed691 30-Sep-2024 Peter Klausler <pklausler@nvidia.com>

[flang][preprocessor] Don't expand INCLUDE under -E by default (#110333)

Fortran INCLUDE lines have (until now) been treated like #include
directives. This isn't how things work with other Fortran

[flang][preprocessor] Don't expand INCLUDE under -E by default (#110333)

Fortran INCLUDE lines have (until now) been treated like #include
directives. This isn't how things work with other Fortran compilers when
running under the -E option for preprocessing only, so stop doing it by
default, and add -fpreprocess-include-lines to turn it back on when
desired.

show more ...


# 84d7f294 18-Sep-2024 Youngsuk Kim <youngsuk.kim@hpe.com>

[flang] Tidy uses of raw_string_ostream (NFC)

As specified in the docs,
1) raw_string_ostream is always unbuffered and
2) the underlying buffer may be used directly

( 65b13610a5226b84889b923bae884b

[flang] Tidy uses of raw_string_ostream (NFC)

As specified in the docs,
1) raw_string_ostream is always unbuffered and
2) the underlying buffer may be used directly

( 65b13610a5226b84889b923bae884ba395ad084d for further reference )

Avoid unneeded calls to raw_string_ostream::str(), to avoid excess indirection.

show more ...


Revision tags: llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4
# 7d60232b 10-Apr-2024 Krzysztof Parzyszek <Krzysztof.Parzyszek@amd.com>

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

This should work the same way as in clang.


Revision tags: llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init
# e12ffe6a 23-Jun-2023 Peter Klausler <pklausler@nvidia.com>

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


Revision tags: llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4
# 4ad72793 06-May-2023 Peter Klausler <pklausler@nvidia.com>

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


Revision tags: llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1
# 8df63a23 27-Jul-2022 Peixin Qiao <qiaopeixin@huawei.com>

[flang] Support the color diagnostics on scanning, parsing, and semantics

The options -f{no-}color-diagnostics have been supported in driver. This
supports the behaviors in scanning, parsing, and se

[flang] Support the color diagnostics on scanning, parsing, and semantics

The options -f{no-}color-diagnostics have been supported in driver. This
supports the behaviors in scanning, parsing, and semantics, and the
behaviors are exactly the same as the driver.

To illustrate the added behaviour, consider the following input file:
```! file.f90
program m
integer :: i = k
end
```
In the following invocations, "error: Must be a constant value" _will be_
formatted:
```
$ flang-new file.f90
error: Semantic errors in file.f90
./file.f90:2:18: error: Must be a constant value
integer :: i = k
```
Note that "error: Semantic errors in file.f90" is also formatted, which
is supported in https://reviews.llvm.org/D126164.

Also note that only "error", "warning" and "portability" are formatted.
Check the following input file:
```! file2.f90
program m
integer :: i =
end
```
```
$ flang-new test2.f90
error: Could not parse test2.f90
./test2.f90:2:11: error: expected '('
integer :: i =
^
./test2.f90:2:3: in the context: statement function definition
integer :: i =
^
...
```
The "error: Could not parse test2.f90" and "error: expected '('" are
formatted. Others such as "in the context" are not formatted yet, which
may or may not be supported.

Reviewed By: awarzynski

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

show more ...


Revision tags: llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5
# 15faac90 30-May-2022 Peter Klausler <pklausler@nvidia.com>

[flang] Distinguish intrinsic module USE in module files; correct search paths

In the USE statements that f18 emits to module files, ensure that symbols
from intrinsic modules are marked as such on

[flang] Distinguish intrinsic module USE in module files; correct search paths

In the USE statements that f18 emits to module files, ensure that symbols
from intrinsic modules are marked as such on their USE statements. And
ensure that the current working directory (".") cannot override the intrinsic
module search path when trying to locate an intrinsic module.

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

show more ...


# 889c7c8e 27-May-2022 Daniil Dudkin <d.dudkin@partner.samsung.com>

[flang] Support correct continuations for compiler directives

If a line is over 72 characters long, flang's preprocessor cuts it there
and continues on the next line.
For this purpose it uses the st

[flang] Support correct continuations for compiler directives

If a line is over 72 characters long, flang's preprocessor cuts it there
and continues on the next line.
For this purpose it uses the standard way of continuing line with & on each line.
However, it doesn't work with long compiler directives, like OpenMP or OpenACC ones.
The line that continues the directive also has to
contain the corresponding sentinel at the beginning.

This change implements the described functionality.
Also, some code was refactored in order to simplify and reuse existing code.

Reviewed By: klausler

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

show more ...


Revision tags: llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init
# 52a1346b 26-Jan-2022 Peter Klausler <pklausler@nvidia.com>

[flang] Distinguish intrinsic from non-intrinsic modules

For "USE, INTRINSIC", search only for intrinsic modules;
for "USE, NON_INTRINSIC", do not recognize intrinsic modules.
Allow modules of both

[flang] Distinguish intrinsic from non-intrinsic modules

For "USE, INTRINSIC", search only for intrinsic modules;
for "USE, NON_INTRINSIC", do not recognize intrinsic modules.
Allow modules of both kinds with the same name to be used in
the same source file (but not in the same scoping unit, a
constraint of the standard that is now enforced).

The symbol table's scope tree now has a single instance of
a scope with a new kind, IntrinsicModules, whose children are
the USE'd intrinsic modules (explicit or not). This separate
"top-level" scope is a child of the single global scope and
it allows both intrinsic and non-intrinsic modules of the same
name to exist in the symbol table. Intrinsic modules' scopes'
symbols now have the INTRINSIC attribute set.

The search path directories need to make a distinction between
regular directories and the one(s) that point(s) to intrinsic
modules. I allow for multiple intrinsic module directories in
the second search path, although only one is needed today.

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

show more ...


Revision tags: llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init
# 3338ef93 23-Jul-2021 peter klausler <pklausler@nvidia.com>

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


Revision tags: llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4
# 46ade6d0 16-Mar-2021 peter klausler <pklausler@nvidia.com>

[flang] Order Symbols by source provenance

In parser::AllCookedSources, implement a map from CharBlocks to
the CookedSource instances that they cover. This permits a fast
Find() operation based on

[flang] Order Symbols by source provenance

In parser::AllCookedSources, implement a map from CharBlocks to
the CookedSource instances that they cover. This permits a fast
Find() operation based on std::map::equal_range to map a CharBlock
to its enclosing CookedSource instance.

Add a creation order number to each CookedSource. This allows
AllCookedSources to provide a Precedes(x,y) predicate that is a
true source stream ordering between two CharBlocks -- x is less
than y if it is in an earlier CookedSource, or in the same
CookedSource at an earlier position.

Add a reference to the singleton SemanticsContext to each Scope.

All of this allows operator< to be implemented on Symbols by
means of a true source ordering. From a Symbol, we get to
its Scope, then to the SemanticsContext, and then use its
AllCookedSources reference to call Precedes().

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

show more ...


Revision tags: llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2
# 8880a63a 11-Feb-2021 peter klausler <pklausler@nvidia.com>

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


Revision tags: llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init
# 6110e771 26-Jan-2021 peter klausler <pklausler@nvidia.com>

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


# e8785890 26-Jan-2021 Andrzej Warzynski <andrzej.warzynski@arm.com>

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


# d987b61b 25-Jan-2021 peter klausler <pklausler@nvidia.com>

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

Make the #include "file" preprocessing directive begin its
search in the same directory as the file containing the directive,
as other preproces

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

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 after the original.

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

show more ...


Revision tags: llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3
# 01def7f7 17-Sep-2020 peter klausler <pklausler@nvidia.com>

[flang] Rework preprocessing of stringification

Hew more closely to the C17 standard; perform macro replacement
of arguments to function-like macros unless they're being stringified
or pasted. Test

[flang] Rework preprocessing of stringification

Hew more closely to the C17 standard; perform macro replacement
of arguments to function-like macros unless they're being stringified
or pasted. Test with a model "assert" macro idiom that exposed
the problem.

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

show more ...


# 92a54197 31-Aug-2020 peter klausler <pklausler@nvidia.com>

[flang] Support multiple CookedSource instances

These are owned by an instance of a new class AllCookedSources.

This removes the need for a Scope to own a string containing
a module's cooked source

[flang] Support multiple CookedSource instances

These are owned by an instance of a new class AllCookedSources.

This removes the need for a Scope to own a string containing
a module's cooked source stream, and will enable errors to be
emitted when parsing module files in the future.

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

show more ...


Revision tags: llvmorg-11.0.0-rc2
# 4ac617f4 07-Aug-2020 peter klausler <pklausler@nvidia.com>

[flang] Handle DATA initialization of EQUIVALENCE'd objects

Objects that are storage associated by EQUIVALENCE and
initialized with DATA are initialized by creating a
compiler temporary data object

[flang] Handle DATA initialization of EQUIVALENCE'd objects

Objects that are storage associated by EQUIVALENCE and
initialized with DATA are initialized by creating a
compiler temporary data object in the same scope,
assigning it an offset, type, and size that covers the
transitive closure of the associated initialized original
symbols, and combining their initializers into one common
initializer for the temporary.

Some problems with offset assignment of EQUIVALENCE'd objects
in COMMON were exposed and corrected, and some more error
cases are checked.

Remove obsolete function.
Small bugfix (nested implied dos).
Add a test.
Fix struct/class warning.

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

show more ...


Revision tags: llvmorg-11.0.0-rc1, llvmorg-12-init
# 0a90ffa7 14-Jul-2020 Valentin Clement <clementval@gmail.com>

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


# f06ad913 14-Jul-2020 Valentin Clement <clementval@gmail.com>

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

This reverts commit 65049d16100af360674659fb56e8f9bec96a0836.

Buildbot failure clang-ppc64le-rhel


# 65049d16 14-Jul-2020 Valentin Clement <clementval@gmail.com>

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


Revision tags: llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1
# b98ad941 09-Apr-2020 David Truby <david.truby@arm.com>

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


# 1f879005 29-Mar-2020 Tim Keith <tkeith@nvidia.com>

[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


12