| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[flang][driver] Add options for unparsing This patch adds the following compiler frontend driver options: * -fdebug-unparse (f18 spelling: -funparse) * -fdebug-unparse-with-symbols (f18 spelling: -funparse-with-symbols) The new driver will only accept the new spelling. f18 will accept both the original and the new spelling. A new base class for frontend actions is added: PrescanAndSemaAction. This is added to reduce code duplication that otherwise these new options would lead to. Implementation from * ParseSyntaxOnlyAction::ExecutionAction is moved to: * PrescanAndSemaAction::BeginSourceFileAction This implementation is now shared between: * PrescanAndSemaAction * ParseSyntaxOnlyAction * DebugUnparseAction * DebugUnparseWithSymbolsAction All tests that don't require other yet unimplemented options are updated. This way flang-new -fc1 is used instead of f18 when FLANG_BUILD_NEW_DRIVER is set to On. In order to facilitate this, %flang_fc1 is added in the LIT configuration (lit.cfg.py). asFortran from f18.cpp is duplicated as getBasicAsFortran in FrontendOptions.cpp. At this stage it's hard to find a good place to share this method. I suggest that we revisit this once a switch from f18 to flang-new is complete. Differential Revision: https://reviews.llvm.org/D96483 | 5 年前 | |
[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 | 3 年前 | |
[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 | 3 年前 | |
[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 | 6 年前 | |
[flang][MSVC] Use list<Message> rather than forward_list<> in Messages The implementation of Messages with forward_list<> makes some nonstandard assumptions about the validity of iterators that don't hold up with MSVC's implementation. Use list<> instead. The measured performance is comparable. This change obviated a distinction between two member functions of Messages, and the uses of one have been replaced with calls to the other. Similar usage in CharBuffer was also replaced for consistency. Differential revision: https://reviews.llvm.org/D91210 | 5 年前 | |
[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 | 6 年前 | |
[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 | 6 年前 | |
[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 | 5 年前 | |
[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 | 6 年前 | |
[flang][openacc] Relax rule for end directive on combined construct Make the keyword loop optional for the end driective on combined construct. This done to extend compatibility with other compiler that allow this. Reviewed By: razvanlupusoru Differential Revision: https://reviews.llvm.org/D151856 | 3 年前 | |
[flang] Improve error recovery for bad/missing construct END statements When a multi-statement construct should end with a particular END statement like "END SELECT", and that construct's END statement is missing or unrecognizable, the error recovery productions should not misinterpret a program unit END statement that follows and consume it as a misspelled construct END statement. Doing so leads to cascading errors or a failed parse. Differential Revision: https://reviews.llvm.org/D136896 | 3 年前 | |
[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 | 6 年前 | |
[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 | 5 年前 | |
[flang] Emit just one warning for a bad format edit descriptor An attempt to use an edit descriptor (other than A or L) in a FORMAT statement without arequired 'w' width will elicit warnings from both the parser and the I/O checker in semantics. Remove the warning from the parser. Differential Revision: https://reviews.llvm.org/D155977 | 2 年前 | |
[flang] Restore ENUM_CLASS() to be compilation-time code Rework some recent changes to the ENUM_CLASS() macro so that all of the construction of enumerator-to-name string mapping data structures is again performed at compilation time. Differential Revision: https://reviews.llvm.org/D137859 | 3 年前 | |
[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 | 3 年前 | |
[openacc][NFC] Bump parser support number to OpenACC 3.3 Parser support reached OpenACC 3.3 specification. Bump the numbers to reflect the latest specs. Reviewed By: razvanlupusoru, awarzynski Differential Revision: https://reviews.llvm.org/D154249 | 3 年前 | |
[Flang] [OpenMP] [Semantics] Change SIMD ALIGNED clause support from parsing a std::list<Name> to OmpObjectlist This is an assisting patch which is implemented to address review comment to switch std::list<Name> to OmpObjectlist from https://reviews.llvm.org/D142722. Also addressed a semantic check https://github.com/llvm/llvm-project/issues/61161 OpenMP 5.2 standard states that only pointer variables (C_PTR, Cray pointers, POINTER or ALLOCATABLE items) can appear in SIMD aligned clause (section 5.11). And not to allow common block names on an ALIGNED clause. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D152637 | 3 年前 | |
[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 | 3 年前 | |
[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 | 3 年前 | |
[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 | 3 年前 | |
[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 | 3 年前 | |
[flang] Portability warning and documentation for an obscure extension A quotation mark can appear in a Fortran character literal by doubling it; for example, PRINT *, "'""'" prints '"'. When those doubled quotation marks are split by a free form line continuation, the continuation line should have an ampersand before the second quotation mark. But most compilers, including this one, allow the second quotation mark to appear as the first character on the continuation line, too. So this works: print *, "'"& "'" but it really should be written as: print *, "'"& &"'" Emit a portability warning and document that we support this near-universal extension. Differential Revision: https://reviews.llvm.org/D155973 | 2 年前 | |
[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 | 3 年前 | |
[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 | 3 年前 | |
[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 | 3 年前 | |
[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 | 3 年前 | |
[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 | 3 年前 | |
[nfc][flang] Eliminate the dependency on cctype by using characters.h Reviewed By: klausler Differential Revision: https://reviews.llvm.org/D148076 | 3 年前 | |
[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 | 3 年前 | |
[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 | 3 年前 | |
[flang] Add & use a better visit() (take 2) Adds flang/include/flang/Common/log2-visit.h, which defines a Fortran::common::visit() template function that is a drop-in replacement for std::visit(). Modifies most use sites in the front-end and runtime to use common::visit(). The C++ standard mandates that std::visit() have O(1) execution time, which forces implementations to build dispatch tables. This new common::visit() is O(log2 N) in the number of alternatives in a variant<>, but that N tends to be small and so this change produces a fairly significant improvement in compiler build memory requirements, a 5-10% improvement in compiler build time, and a small improvement in compiler execution time. Building with -DFLANG_USE_STD_VISIT causes common::visit() to be an alias for std::visit(). Calls to common::visit() with multiple variant arguments are referred to std::visit(), pending further work. This change is enabled only for GCC builds with GCC >= 9; an earlier attempt (D122441) ran into bugs in some versions of clang and was reverted rather than simply disabled; and it is not well tested with MSVC. In non-GCC and older GCC builds, common::visit() is simply an alias for std::visit(). | 4 年前 | |
[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 | 6 年前 | |
[flang][openacc] Relax rule for end directive on combined construct Make the keyword loop optional for the end driective on combined construct. This done to extend compatibility with other compiler that allow this. Reviewed By: razvanlupusoru Differential Revision: https://reviews.llvm.org/D151856 | 3 年前 | |
[Flang] [OpenMP] [Semantics] Change SIMD ALIGNED clause support from parsing a std::list<Name> to OmpObjectlist This is an assisting patch which is implemented to address review comment to switch std::list<Name> to OmpObjectlist from https://reviews.llvm.org/D142722. Also addressed a semantic check https://github.com/llvm/llvm-project/issues/61161 OpenMP 5.2 standard states that only pointer variables (C_PTR, Cray pointers, POINTER or ALLOCATABLE items) can appear in SIMD aligned clause (section 5.11). And not to allow common block names on an ALIGNED clause. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D152637 | 3 年前 | |
[flang] Implement semantics for DEC STRUCTURE/RECORD Implements part of the legacy "DEC structures" feature from VMS Fortran. STRUCTUREs are processed as if they were derived types with SEQUENCE. DATA-like object entity initialization is supported as well (e.g., INTEGER FOO/666/) since it was used for default component initialization in structures. Anonymous components (named %FILL) are also supported. These features, and UNION/MAP, were already being parsed. An omission in the collection of structure field names in the case of nested structures with entity declarations was fixed in the parser. Structures are supported in modules, but this is mostly for testing purposes. The names of fields in structures accessed via USE association cannot appear with dot notation in client code (at least not yet). DEC structures antedate Fortran 90, so their actual use in applications should not involve modules. This patch does not implement UNION/MAP, since that feature would impose difficulties later in lowering them to MLIR types. In the meantime, if they appear, semantics will issue a "not yet implemented" error message. Differential Revision: https://reviews.llvm.org/D117151 | 4 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 5 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 6 年前 | ||
| 5 年前 | ||
| 6 年前 | ||
| 6 年前 | ||
| 5 年前 | ||
| 6 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 6 年前 | ||
| 5 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 6 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 4 年前 |