| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[flang] Fix minor nits with INCLUDE line recognition Fix some problems with INCLUDE line recognition pointed out by some recently-added tests to the LLVM test suite. Differential Revision: https://reviews.llvm.org/D155497 | 3 年前 | |
[flang][OpenMP] Better diagnostics for invalid or misplaced directives (#168885) Add two more AST nodes, one for a misplaced end-directive, and one for an invalid string following the OpenMP sentinel (e.g. "!$OMP XYZ"). Emit error messages when either node is encountered in semantic analysis. | 8 个月前 | |
[flang][openacc] Make OpenACC block construct parse errors less verbose. (#131042) This PR does reduces the verbosity of parser errors for OpenACC block constructs that do not parse correctly because they are missing their trailing end block directive by: - Removing the redundant error messages created by parsing 3 different styles of directive tokens. - Providing a general mechanism of configuring the max number of contexts printed for every syntax error. - Not printing less specific contexts that are at the same location. Prior to the changes: $ flang -fc1 -fopenacc -fsyntax-only flang/test/Parser/acc-data-statement.f90 2>&1 | tee acc-data-statement.prior.log | wc -l 262 [acc-data-statement.prior.log](https://github.com/user-attachments/files/19298165/acc-data-statement.prior.log) $ flang -fc1 -fopenacc -fsyntax-only flang/test/Parser/acc-data-statement.f90 2>&1 | tee acc-data-statement.prior.log | wc -l 73 [acc-data-statement.post.log](https://github.com/user-attachments/files/19298181/acc-data-statement.post.log) | 1 年前 | |
[flang] Main program symbol no longer conflicts with the other symbols (#149169) The following code is now accepted: module m end program m use m end The PROGRAM name doesn't really have an effect on the compilation result, so it shouldn't result in symbol name conflicts. This change makes the main program symbol name all uppercase in the cooked character stream. This makes it distinct from all other symbol names that are all lowercase in cooked character stream. Modified the tests that were checking for lower case main program name. | 1 年前 | |
[flang][openacc] Make OpenACC block construct parse errors less verbose. (#131042) This PR does reduces the verbosity of parser errors for OpenACC block constructs that do not parse correctly because they are missing their trailing end block directive by: - Removing the redundant error messages created by parsing 3 different styles of directive tokens. - Providing a general mechanism of configuring the max number of contexts printed for every syntax error. - Not printing less specific contexts that are at the same location. Prior to the changes: $ flang -fc1 -fopenacc -fsyntax-only flang/test/Parser/acc-data-statement.f90 2>&1 | tee acc-data-statement.prior.log | wc -l 262 [acc-data-statement.prior.log](https://github.com/user-attachments/files/19298165/acc-data-statement.prior.log) $ flang -fc1 -fopenacc -fsyntax-only flang/test/Parser/acc-data-statement.f90 2>&1 | tee acc-data-statement.prior.log | wc -l 73 [acc-data-statement.post.log](https://github.com/user-attachments/files/19298181/acc-data-statement.post.log) | 1 年前 | |
[Flang] Add support for assume_aligned directive (#81747) This adds the parsing (and unparse) of the compiler drective assume_aligned. The compiler will issue a warning that the directive is ignored. | 2 年前 | |
[flang] More graceful parse failures at EOF (#159834) Rather than admit complete confusion with a "FAIL" message when parsing runs into the end of the source file unexpectedly, deal better with missing or garbled END statements through the use of consumedAllInput in end-of-line and end-of-statement parsers and error recovery. Adds a new test (the original motivation) and updates the expected results in two extant tests that were failing before. | 10 个月前 | |
[flang] Handle @PROCESS directive Treat lines that start with @process as a comment line. The directive is accepted and ignored. Differential Revision: https://reviews.llvm.org/D150883 | 3 年前 | |
[flang] Emit portability warning for extension f18 accepts statement labels in fixed form source even if they follow a semicolon -- i.e., they're not in the fixed form's label field. Emit a warning for such usage. Differential Revision: https://reviews.llvm.org/D143817 | 3 年前 | |
[flang][parser] Diagnose an invalid space In free form, don't silently skip over an invalid space between an underscore and a kind parameter. Differential Revision: https://reviews.llvm.org/D142760 | 3 年前 | |
[flang] Ensure that portability warnings are conditional (#71857) Before emitting a warning message, code should check that the usage in question should be diagnosed by calling ShouldWarn(). A fair number of sites in the code do not, and can emit portability warnings unconditionally, which can confuse a user that hasn't asked for them (-pedantic) and isn't terribly concerned about portability *to* other compilers. Add calls to ShouldWarn() or IsEnabled() around messages that need them, and add -pedantic to tests that now require it to test their portability messages, and add more expected message lines to those tests when -pedantic causes other diagnostics to fire. | 2 年前 | |
[flang] More graceful parse failures at EOF (#159834) Rather than admit complete confusion with a "FAIL" message when parsing runs into the end of the source file unexpectedly, deal better with missing or garbled END statements through the use of consumedAllInput in end-of-line and end-of-statement parsers and error recovery. Adds a new test (the original motivation) and updates the expected results in two extant tests that were failing before. | 10 个月前 | |
[flang] Implement !DIR$ IVDEP directive (#133728) This directive tells the compiler to ignore vector dependencies in the following loop and it must be placed before a do loop. Sometimes the compiler may not have sufficient information to decide whether a particular loop is vectorizable due to potential dependencies between iterations and the directive is here to tell to the compiler that vectorization is safe with parallelAccesses metadata. This directive is also equivalent to #pragma clang loop assume(safety) in C++ | 8 个月前 | |
[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] Further refinement of OpenMP !$ lines in -E mode (#138956) Address failing Fujitsu test suite cases that were broken by the patch to defer the handling of !$ lines in -fopenmp vs. normal compilation to actual compilation rather than processing them immediately in -E mode. Tested on the samples in the bug report as well as all of the Fujitsu tests that I could find that use !$ lines. Fixes https://github.com/llvm/llvm-project/issues/136845. | 1 年前 | |
[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] Handle continuation line edge case (#74751) For a character literal that is split over more than one source line with free form line continuation using '&' at the end of one line but missing the standard-required '&' on the continuation line, also handle the case of spaces at the beginning of the continuation line. For example, PRINT *, 'don'& 't poke the bear' now prints "don't poke the bear", like nearly all other Fortran compilers do. This is not strictly standard conforming behavior, and the compiler emits a portability warning with -pedantic. Fixes llvm-test-suite/Fortran/gfortran/regression/continuation_1.f90, .../continuation_12.f90, and .../continuation_13.f90. | 2 年前 | |
[flang][cuda] Accept scalar expression for bytes in kernel call (#165040) | 9 个月前 | |
[flang][cuda] Accept scalar expression for bytes in kernel call (#165040) | 9 个月前 | |
[flang][cuda] Define _CUDA only when preprocessor is enabled (#155913) From the CUDA Fortran programming guide: > If CUDA Fortran is enabled in compilation, either by specifying -cuda on the command line, and pre-processing is enabled by either the -Mpreprocess compiler option or by using capital letters in the filename extension (.CUF, .F90, etc.) then the _CUDA macro is defined. Move the definition of _CUDA to the compiler invocation. | 11 个月前 | |
[flang] Extension: accept "var*length(bounds)" (#117399) A character length specifier in an entity declaration or a component declaration is required by the standard to follow any array bounds or coarray bounds that are present. Several Fortran compilers allow the character length specifier to follow the name and appear before the bounds. Fixes https://github.com/llvm/llvm-project/issues/117372. | 1 年前 | |
[flang] Don't mistakenly tokenize a Hollerith literal from "DO 100 H=..." (bug #58732) After tokenizing an identifier, don't allow the next token to be a Hollerith literal. Fixes https://github.com/llvm/llvm-project/issues/58732. Differential Revision: https://reviews.llvm.org/D150406 | 3 年前 | |
[flang] Improve syntax error messages by fixing withMessage() parser combinator The parser combinator withMessage("error message"_err_en_US, PARSER) is meant to run the parser PARSER and, if it fails, override its error messages if it failed silently or it was unable to recognize any tokens at all. This gives the parser a way to avoid emitting some confusing or missing error messages. Unfortunately, the implementation could sometimes lose track of whether any tokens had been recognized, leading to problems with outer usage of withMessage() and also -- more seriously -- with ParseState::CombineFailedParses(). That's a utility that determines which error messages to retain when two or more parsers have been attempted at the same starting point and none of them succceed. Its policy is to retain the state from the parser that consumed the most input text before failing, so long as it had recognized at least one token. So anyway, fix up withMessage(), adjust the tests, and add a test of the original motivating confusing error situation, in which a syntax error in a COMMON statement was being diagnosed as a problem with a statement function definition because withMessage() had lost the fact that the parse of the COMMON statement had recognized some tokens, and the last attempted parse later was a failed attempt to parse a statement function. Differential Revision: https://reviews.llvm.org/D135216 | 3 年前 | |
[flang] Better error recovery for missing THEN in ELSE IF The THEN keyword in the "ELSE IF (test) THEN" statement is useless syntactically, and to omit it is a common error (at least for me!) that has poor error recovery. This patch changes the parser to cough up a simple "expected 'THEN'" and still recognize the rest of the IF construct. Differential Revision: https://reviews.llvm.org/D110952 | 4 年前 | |
[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 | 4 年前 | |
[flang] Ensure that portability warnings are conditional (#71857) Before emitting a warning message, code should check that the usage in question should be diagnosed by calling ShouldWarn(). A fair number of sites in the code do not, and can emit portability warnings unconditionally, which can confuse a user that hasn't asked for them (-pedantic) and isn't terribly concerned about portability *to* other compilers. Add calls to ShouldWarn() or IsEnabled() around messages that need them, and add -pedantic to tests that now require it to test their portability messages, and add more expected message lines to those tests when -pedantic causes other diagnostics to fire. | 2 年前 | |
[flang] Accept useless label on top-level FUNCTION (#129603) The look-ahead parser for function program units didn't allow for a useless label on the statement. Fixes https://github.com/llvm/llvm-project/issues/129456. | 1 年前 | |
[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. | 1 年前 | |
| 9 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
[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] Handle substring in data statement constant (#120130) The case of a constant substring wasn't handled in the parser for data statement constants. Fixes https://github.com/llvm/llvm-project/issues/119005. | 1 年前 | |
[flang] Warn on missing colons (C768) In a derived type definition, a type bound procedure declaration statement with neither interface nor attributes is required by constraint C768 to have the optional "::" between the PROCEDURE keyword and the bindings if any binding has a renaming with "=>". The colons are not actually necessary for a correct and unambiguous parse, so emit a warning when they are missing. Differential Revision: https://reviews.llvm.org/D139065 | 3 年前 | |
[flang] Better error recovery for missing THEN in IF construct Presented with "IF (...)" with no following tokens in the statement, diagnose a missing "THEN" instead of complaining about all of the possible action statement initial tokens that could have been there for a non-construct IF statement. Fixes https://github.com/llvm/llvm-project/issues/62299. Differential Revision: https://reviews.llvm.org/D150783 | 3 年前 | |
[flang] Accept a non-breaking space character in source (#106611) Accept non-breaking space characters (Latin-1 '\xa0', UTF-8 '\xc2' '\xa0') in source code, converting them into regular spaces in the cooked character stream when not in character literals. | 1 年前 | |
[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] Add parser support for prefetch directive (#139702) Implementation details: * Recognize prefetch directive in the parser as !dir$ prefetch ... * Unparse the prefetch directive * Add required tests Details on the prefetch directive: !dir$ prefetch designator[, designator]..., where the designator list can be a variable or an array reference. This directive is used to insert a hint to the code generator to prefetch instructions for memory references. | 8 个月前 | |
[flang] Improve error recovery in tricky situation (#95168) When the very first statement of the executable part has syntax errors, it's not at all obvious whether the error messages that are reported to the user should be those from its failure to be the last statement of the specification part or its failure to be the first executable statement when both failures are at the same character in the cooked character stream. Fortran makes this problem more exciting by allowing statement function definitions look a lot like several executable statements. The current error recovery scheme for declaration constructs depends on a look-ahead test to see whether the failed construct is actually the first executable statement. This works fine when the first executable statement is not in error, but should also allow for some error cases that begin with the tokens of an executable statement. This can obviously still go wrong for declaration constructs that are unparseable and also have ambiguity in their leading tokens with executable statements, but that seems to be a less likely case. Also improves error recovery for parenthesized items. | 2 年前 | |
[flang] Improve error recovery in tricky situation (#95168) When the very first statement of the executable part has syntax errors, it's not at all obvious whether the error messages that are reported to the user should be those from its failure to be the last statement of the specification part or its failure to be the first executable statement when both failures are at the same character in the cooked character stream. Fortran makes this problem more exciting by allowing statement function definitions look a lot like several executable statements. The current error recovery scheme for declaration constructs depends on a look-ahead test to see whether the failed construct is actually the first executable statement. This works fine when the first executable statement is not in error, but should also allow for some error cases that begin with the tokens of an executable statement. This can obviously still go wrong for declaration constructs that are unparseable and also have ambiguity in their leading tokens with executable statements, but that seems to be a less likely case. Also improves error recovery for parenthesized items. | 2 年前 | |
[flang][parser] Better error recovery for misplaced declaration (#100482) When a declaration construct appears in the execution part of a block or subprogram body, report it as such rather than as a misleading syntax error on the executable statement that it somehow matched the most. | 1 年前 | |
[flang][parser] Better error recovery for SUBROUTINE/FUNCTION statements (#100664) When there's an error in a SUBROUTINE or FUNCTION statement, errors cascade quickly because the body of the subprogram or interface isn't in the right context. So, if a SUBROUTINE or FUNCTION statement is expected, and contains a SUBROUTINE or FUNCTION keyword, it counts as one -- retain and emit any errors pertaining to the arguments or suffix, recover to the end of the line if needed, and proceed. | 1 年前 | |
[flang] Fix parser crash (#105875) The production for a bare file unit number in an I/O statement checks that the scalar integer expression isn't followed by "=", in order to disambiguate FLUSHN from FLUSHN=1, and to not treat a control specifier keyword as an integer expression. The implementation of this check used !"="_tok, which has the side effect of producing no error message; this can lead to a parsing crash later when a failed parse of an erroneous program is found to have produced no errors. Rewrite as a lookAhead call for those characters that acually can follow a bare unit number. Fixes https://github.com/llvm/llvm-project/issues/105779. | 1 年前 | |
[flang] Improve error recovery for bad statement after CONTAINS (#109698) After a CONTAINS statement in a program unit, a statement that cannot begin a subprogram will trigger catastrophic error recovery. But the compiler is presently emitting multiple errors for the same location about expected variations of END statements. Emit fewer messages. Fixes https://github.com/llvm/llvm-project/issues/109609. | 1 年前 | |
[flang] Better recovery from errors in a loop control (#117025) When there's an error in a DO statement loop control, error recovery isn't great. A bare "DO" is a valid statement, so a failure to parse its loop control doesn't fail on the whole statement. Its partial parse ends after the keyword, and as some other statement parsers can get further into the input before failing, errors in the loop control can lead to confusing error messages about bad pointer assignment statements and others. So just check that a bare "DO" is followed by the end of the statement. | 1 年前 | |
[flang] Improve presentation of errors after last source line (#161391) We don't emit source file names or line numbers for error messages at EOF. Detect these and handle them a little better, pointing at the newline at the end of the last source line instead. | 10 个月前 | |
[flang] Fix fixed-form continuations of !$ OpenMP conditional lines (#135852) I broke fixed-form line continuation (without !$) for OpenMP !$ conditional compilation lines. Fix it. | 1 年前 | |
[flang] More graceful parse failures at EOF (#159834) Rather than admit complete confusion with a "FAIL" message when parsing runs into the end of the source file unexpectedly, deal better with missing or garbled END statements through the use of consumedAllInput in end-of-line and end-of-statement parsers and error recovery. Adds a new test (the original motivation) and updates the expected results in two extant tests that were failing before. | 10 个月前 | |
[flang] Accept and ignore compiler directives between internal subpro… (#89810) …grams The parser only recognizes compiler directives that appear within internal / module subprograms, not those that might appear between them. Extend to allow them between subprograms as well. | 2 年前 | |
[flang] Fix UTF-8 minimality checks (#159142) UTF-8 encodings are required to be minimal, but the checks for minimality of 3-byte and 4-byte sequences were incorrect. Fix. | 10 个月前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 3 年前 | ||
| 8 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 10 个月前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 10 个月前 | ||
| 8 个月前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 5 年前 | ||
| 2 年前 | ||
| 9 个月前 | ||
| 9 个月前 | ||
| 11 个月前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 9 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 5 年前 | ||
| 8 个月前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 10 个月前 | ||
| 1 年前 | ||
| 10 个月前 | ||
| 2 年前 | ||
| 10 个月前 |