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
|