| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[flang] Implement !DIR$ VECTOR ALWAYS (#93830) This patch implements support for the VECTOR ALWAYS directive, which forces vectorization to occurr when possible regardless of a decision by the cost model. This is done by adding an attribute to the branch into the loop in LLVM to indicate that the loop should always be vectorized. This patch only implements this directive on plan structured do loops without labels. Support for unstructured loops and array expressions is planned for future patches. | 2 年前 | |
[flang] Downgrade error message to a portability warning (#98368) f18 current emits an error when an assignment is made to an array section with a vector subscript, and the array is finalized with a non-elemental final subroutine. Some other compilers emit this error because (I think) they want variables to only be finalized in place, not by a subroutine call involving copy-in & copy-out of the finalized elements. Since many other Fortran compilers can handle this case, and there's nothing in the standards to preclude it, let's downgrade this error message to a portability warning. This patch got complicated because the API for the WhyNotDefinable() utility routine was such that it would return a message only in error cases, and there was no provision for returning non-fatal messages. It now returns either nothing, a fatal message, or a non-fatal warning message, and all of its call sites have been modified to cope. | 1 年前 | |
[flang] Fix pointer definition semantic checking via refactoring The infrastructure in semantics that is used to check that the left-hand sides of normal assignment statements are really definable variables was not being used to check whether the LHSs of pointer assignments are modifiable, and so most cases of unmodifiable pointers are left undiagnosed. Rework the semantics checking for pointer assignments, NULLIFY statements, pointer dummy arguments, &c. so that cases of unmodifiable pointers are properly caught. This has been done by extracting all the various definability checking code that has been implemented for different contexts in Fortran into one new facility. The new consolidated definability checking code returns messages meant to be attached as "because: " explanations to context-dependent errors like "left-hand side of assignment is not definable". These new error message texts and their attached explanations affect many existing tests, which have been updated. The testing infrastructure was extended by another patch to properly compare warnings and explanatory messages, which had been ignored until recently. Differential Revision: https://reviews.llvm.org/D136979 | 3 年前 | |
[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][openacc] Support labeled DO loop after acc combined directive (#66296) This patch adds support for labeled do loop after combined directive. It relaxes the initial parser and canonicalize labeled do loop into the OpenACCCombinedConstruct. | 2 年前 | |
[flang][openacc] Semantic checks for OpenACC 3.0 clauses validity Summary: This patch adds semantic checking for the OpenACC 3.0 clauses validity. Reviewers: sscalpone, tskeith, klausler, ichoyjx, DavidTruby, jdoerfert Reviewed By: tskeith, klausler Subscribers: mgorny, llvm-commits Tags: #llvm, #flang Differential Revision: https://reviews.llvm.org/D83807 | 5 年前 | |
[flang] Change vector always errors to warnings (#95908) | 2 年前 | |
[flang] Implement !DIR$ VECTOR ALWAYS (#93830) This patch implements support for the VECTOR ALWAYS directive, which forces vectorization to occurr when possible regardless of a decision by the cost model. This is done by adding an attribute to the branch into the loop in LLVM to indicate that the loop should always be vectorized. This patch only implements this directive on plan structured do loops without labels. Support for unstructured loops and array expressions is planned for future patches. | 2 年前 | |
[flang] Fix construct names on labeled DO (#67622) Fortran requires that a DO construct with a construct name end with an END DO statement bearing the same name. This is true even if the DO construct begins with a label DO statement; e.g., "constrName: do 10 j=1,10" must end with "10 end do constrName". The compiler presently basically ignores construct names that appear on label DO statements, because only non-label DO statements can be parsed as DO constructs. This causes us to miss some errors, and (worse) breaks the usage of the construct name on CYCLE and EXIT statements. To fix this, this patch changes the parse tree and parser so that a DO construct name on a putative label DO statement causes it to be parsed as a "non-label" DO statement... with a label. Only true old-style labeled DO statements without construct names are now parsed as such. I did not change the class name NonLabelDoStmt -- it's widely used across the front-end, and is the name of a production in the standard's grammar. But now it basically means DoConstructDoStmt. Fixes https://github.com/llvm/llvm-project/issues/67283. | 2 年前 | |
[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 年前 | |
Fix warning by removing unused variable (#81604) Apparently, some compilers [correctly] warn that the variable that was created prior to this change is unused. This reemoves the variable. | 2 年前 | |
[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] Switch to common::visit more call sites (#90018) Switch to common::visit more call sites. Test plan: ninja check-all | 2 年前 | |
[flang][openacc] Warn only when the same variable is in the same declare (#70698) A var may appear at most once in all the clauses of declare directives for a function, subroutine, program, or module. We raise an error when a var appears in two different clauses. If it is in the same clauses, we just issue a warning. | 2 年前 | |
[flang] Downgrade error message to a portability warning (#98368) f18 current emits an error when an assignment is made to an array section with a vector subscript, and the array is finalized with a non-elemental final subroutine. Some other compilers emit this error because (I think) they want variables to only be finalized in place, not by a subroutine call involving copy-in & copy-out of the finalized elements. Since many other Fortran compilers can handle this case, and there's nothing in the standards to preclude it, let's downgrade this error message to a portability warning. This patch got complicated because the API for the WhyNotDefinable() utility routine was such that it would return a message only in error cases, and there was no provision for returning non-fatal messages. It now returns either nothing, a fatal message, or a non-fatal warning message, and all of its call sites have been modified to cope. | 1 年前 | |
[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] Finer control over error recovery with GetExpr() Prior to this patch, the semantics utility GetExpr() will crash unconditionally if it encounters a typed expression in the parse tree that has not been set by expression semantics. This is the right behavior when called from lowering, by which time it is known that the program had no fatal user errors, since it signifies a fatal internal error. However, prior to lowering, in the statement semantics checking code, a more nuanced test should be used before crashing -- specifically, we should not crash in the face of a missing typed expression when in error recovery mode. Getting this right requires GetExpr() and its helper class to have access to the semantics context, so that it can check AnyFatalErrors() before crashing. So this patch touches nearly all of its call sites. Differential Revision: https://reviews.llvm.org/D123873 | 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] Downgrade error message to a portability warning (#98368) f18 current emits an error when an assignment is made to an array section with a vector subscript, and the array is finalized with a non-elemental final subroutine. Some other compilers emit this error because (I think) they want variables to only be finalized in place, not by a subroutine call involving copy-in & copy-out of the finalized elements. Since many other Fortran compilers can handle this case, and there's nothing in the standards to preclude it, let's downgrade this error message to a portability warning. This patch got complicated because the API for the WhyNotDefinable() utility routine was such that it would return a message only in error cases, and there was no provision for returning non-fatal messages. It now returns either nothing, a fatal message, or a non-fatal warning message, and all of its call sites have been modified to cope. | 1 年前 | |
[flang] Whether a procedure's interface is explicit or not is not a d… (#82796) …istinguishing characteristic We note whether a procedure's interface is explicit or implicit as an attribute of its characteristics, so that other semantics can be checked appropriately, but this internal attribute should not be used as a distinguishing characteristic in itself. Fixes https://github.com/llvm/llvm-project/issues/81876. | 2 年前 | |
[flang] Ensure all warning/portability messages are guarded by Should… (#90518) …Warn() Many warning messages were being emitted unconditionally. Ensure that all warnings are conditional on a true result from a call to common::LanguageFeatureControl::ShouldWarn() so that it is easy for a driver to disable them all, or, in the future, to provide per-warning control over them. | 2 年前 | |
[flang] Semantics for SELECT CASE Prep for review Respond to review comments Fix first line in new test Original-commit: flang-compiler/f18@12f6f30600db4cb3902677cd42764450ddeda5e0 Reviewed-on: https://github.com/flang-compiler/f18/pull/1089 | 6 年前 | |
[Flang] Switch to common::visit more call sites (#90018) Switch to common::visit more call sites. Test plan: ninja check-all | 2 年前 | |
[flang] Add notify-type and notify-wait-stmt (#76594) Add notify-type to iso_fortran_env module. Add notify-wait-stmt to the parser and add checks for constraints on the statement, C1177 and C1178, from the Fortran 2023 standard. Add three semantics tests for notify-wait-stmt. | 2 年前 | |
[flang][cuda] Do not consider PINNED as device attribute (#95988) PINNED is a CUDA data attribute meant for the host variables. Do not consider it when computing the number of device variables in assignment for the cuda data transfer. | 2 年前 | |
[flang][cuda] Add restriction on implicit data transfer (#87720) In section 3.4.2, some example of illegal data transfer using expression are given. One of it is when multiple device objects are part of an expression in the rhs. Current implementation allow a single device object in such case. This patch adds a similar restriction. | 2 年前 | |
[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] 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 年前 | |
[flang] Downgrade error message to a portability warning (#98368) f18 current emits an error when an assignment is made to an array section with a vector subscript, and the array is finalized with a non-elemental final subroutine. Some other compilers emit this error because (I think) they want variables to only be finalized in place, not by a subroutine call involving copy-in & copy-out of the finalized elements. Since many other Fortran compilers can handle this case, and there's nothing in the standards to preclude it, let's downgrade this error message to a portability warning. This patch got complicated because the API for the WhyNotDefinable() utility routine was such that it would return a message only in error cases, and there was no provision for returning non-fatal messages. It now returns either nothing, a fatal message, or a non-fatal warning message, and all of its call sites have been modified to cope. | 1 年前 | |
[flang] Use definability tests for better PURE constraint checking Many semantic checks for constraints related to PURE subprograms can be implemented in terms of Semantics' "definable.h" utilities, slightly expanded. Replace some particular PURE constraint checks with calls to WhyNotDefinable(), except for cases that had better specific error messages, and start checking some missing constraints with DEALLOCATE statements and local variable declarations. Differential Revision: https://reviews.llvm.org/D147389 | 3 年前 | |
[flang] Accept IGNORE_TKR in separate module procedure interface (#98374) We emit an incorrect error message when !DIR$ IGNORE_TKR appears in a separate module procedure's interface declaration. Fixes https://github.com/llvm/llvm-project/issues/98210. | 1 年前 | |
[flang] Improve initializer semantics, esp. for component default values This patch plugs many holes in static initializer semantics, improves error messages for default initial values and other component properties in parameterized derived type instantiations, and cleans up several small issues noticed during development. We now do proper scalar expansion, folding, and type, rank, and shape conformance checking for component default initializers in derived types and PDT instantiations. The initial values of named constants are now guaranteed to have been folded when installed in the symbol table, and are no longer folded or scalar-expanded at each use in expression folding. Semantics documentation was extended with information about the various kinds of initializations in Fortran and when each of them are processed in the compiler. Some necessary concomitant changes have bulked this patch out a bit: * contextual messages attachments, which are now produced for parameterized derived type instantiations so that the user can figure out which instance caused a problem with a component, have been added as part of ContextualMessages, and their implementation was debugged * several APIs in evaluate::characteristics was changed so that a FoldingContext is passed as an argument rather than just its intrinsic procedure table; this affected client call sites in many files * new tools in Evaluate/check-expression.cpp to determine when an Expr actually is a single constant value and to validate a non-pointer variable initializer or object component default value * shape conformance checking has additional arguments that control whether scalar expansion is allowed * several now-unused functions and data members noticed and removed * several crashes and bogus errors exposed by testing this new code were fixed * a -fdebug-stack-trace option to enable LLVM's stack tracing on a crash, which might be useful in the future TL;DR: Initialization processing does more and takes place at the right times for all of the various kinds of things that can be initialized. Differential Review: https://reviews.llvm.org/D92783 | 5 年前 | |
[flang] Resolve "possible performance problem" issue spam (#79769) Four "issues" on GitHub report possible performance problems, likely detected by static analysis. None of them would ever make a measureable difference in compilation time, but I'm resolving them to clean up the open issues list. Fixes https://github.com/llvm/llvm-project/issues/79703, .../79705, .../79706, & .../79707. | 2 年前 | |
[flang] Downgrade error message to a portability warning (#98368) f18 current emits an error when an assignment is made to an array section with a vector subscript, and the array is finalized with a non-elemental final subroutine. Some other compilers emit this error because (I think) they want variables to only be finalized in place, not by a subroutine call involving copy-in & copy-out of the finalized elements. Since many other Fortran compilers can handle this case, and there's nothing in the standards to preclude it, let's downgrade this error message to a portability warning. This patch got complicated because the API for the WhyNotDefinable() utility routine was such that it would return a message only in error cases, and there was no provision for returning non-fatal messages. It now returns either nothing, a fatal message, or a non-fatal warning message, and all of its call sites have been modified to cope. | 1 年前 | |
[flang] Fix crash on erroneous expressions Summary: If you create an expression with parse errors, the parser::Expr.typedExpr will be empty, which causes a compiler crash. The crash is caused by the check in check-do-forall.cpp that scans all expresssions to see if DO variables are being modified. It turned out that the problem was that I was fetching subexpressions of type parser::Expr, which are not guaranteed to have a non-null typedExpr. I fixed this by only grabbing the top-level expression from which to gather arguments as part of the DO loop analysis. This, in turn, exposed a problem where I wasn't collecting all of the actual arguments in an expression. This was caused by the fact that I wasn't recursing through the rest of the expression after finding an argument. I fixed this by recursing through the argument in the member function in CollectActualArgumentsHelper. Reviewers: klausler, tskeith, DavidTruby Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D81101 | 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] 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] Downgrade error message to a portability warning (#98368) f18 current emits an error when an assignment is made to an array section with a vector subscript, and the array is finalized with a non-elemental final subroutine. Some other compilers emit this error because (I think) they want variables to only be finalized in place, not by a subroutine call involving copy-in & copy-out of the finalized elements. Since many other Fortran compilers can handle this case, and there's nothing in the standards to preclude it, let's downgrade this error message to a portability warning. This patch got complicated because the API for the WhyNotDefinable() utility routine was such that it would return a message only in error cases, and there was no provision for returning non-fatal messages. It now returns either nothing, a fatal message, or a non-fatal warning message, and all of its call sites have been modified to cope. | 1 年前 | |
[flang] Rework handling of non-type-bound user-defined I/O A fairly recent introduction of runtime I/O APIs called OutputDerivedType() and InputDerivedType() didn't cover NAMELIST I/O's need to access non-type-bound generic interfaces for user-defined derived type I/O when those generic interfaces are defined in some scope other than the one that defines the derived type. The patch adds a new data structure shared between lowering and the runtime that can represent all of the cases that can arise with non-type-bound defined I/O. It can represent scopes in which non-type-bound defined I/O generic interfaces are inaccessible, too, due to IMPORT statements. The data structure is now an operand to OutputDerivedType() and InputDerivedType() as well as a data member in the NamelistGroup structure. Differential Revision: https://reviews.llvm.org/D148257 | 3 年前 | |
[flang] More support for assumed-size Cray pointees (#77381) Recognize Cray pointees as such when they are declared as assumed size arrays, and don't emit a bogus error message about implied shape arrays. Fixes https://github.com/llvm/llvm-project/issues/77330. | 2 年前 | |
[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] Downgrade error message to a portability warning (#98368) f18 current emits an error when an assignment is made to an array section with a vector subscript, and the array is finalized with a non-elemental final subroutine. Some other compilers emit this error because (I think) they want variables to only be finalized in place, not by a subroutine call involving copy-in & copy-out of the finalized elements. Since many other Fortran compilers can handle this case, and there's nothing in the standards to preclude it, let's downgrade this error message to a portability warning. This patch got complicated because the API for the WhyNotDefinable() utility routine was such that it would return a message only in error cases, and there was no provision for returning non-fatal messages. It now returns either nothing, a fatal message, or a non-fatal warning message, and all of its call sites have been modified to cope. | 1 年前 | |
[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][OpenMP] Restrict certain loops not allowed in associated loops (#91818) Extends the OmpCycleAndExitChecker to check that associated loops of a loop construct are not DO WHILE or DO without control. OpenMP 5.0 standard clearly mentions this restriction. Later standards enforce this through the definition of associated loops and canonical loop forms. https://www.openmp.org/spec-html/5.0/openmpsu41.html Fixes #81949 | 1 年前 | |
[Flang][OpenMP] Restrict certain loops not allowed in associated loops (#91818) Extends the OmpCycleAndExitChecker to check that associated loops of a loop construct are not DO WHILE or DO without control. OpenMP 5.0 standard clearly mentions this restriction. Later standards enforce this through the definition of associated loops and canonical loop forms. https://www.openmp.org/spec-html/5.0/openmpsu41.html Fixes #81949 | 1 年前 | |
[flang] Fix purity checking for internal subprograms (#91759) ELEMENTAL internal subprograms are pure unless explicitly IMPURE. | 2 年前 | |
[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] Fix semantics check for RETURN statement The RETURN statement is allowed in functions and subroutines, but not in main programs. It is however a common extension, which we also implement, to allow RETURN from main programs -- we only issue a portability warning when -pedantic or -std=f2018 are set. This patch fixes false positives for this portability warning, where it was triggered also when RETURN was present in functions or subroutines. Fixexs #55080 Reviewed By: PeteSteinfeld Differential Revision: https://reviews.llvm.org/D124732 | 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] Correct semantic representation & handling of RANK(*) (#66234) A RANK(*) case in a SELECT RANK construct selects the case of an assumed-rank dummy argument whose effective actual argument is an assumed-size array. In this case, the attributes of the selector are those of a rank-1 assumed-size array, and the selector cannot be allocatable or a pointer. Ensure that the representation of a SELECT RANK construct's per-case AssocEntityDetails can distinguish RANK(n), RANK(*), and RANK DEFAULT, and clean up various code sites and tests where the distinctions matter. | 2 年前 | |
[flang]Semantics for SELECT RANK. Summary: Initially on github I worked on semantic checks.Then I tried some compile-time test of the rank value, they were failing as there were no symbols generated for them inside SELECT RANK's scope.So I went further to add new symbol in each scope, also added the respective 'rank: ' field for a symbol when we dump the symboltable. I added a field to keep track of the rank in AssocEntityDetails class.This caused shape analysis framework to become inconsistent. So shape analysis framework was updated to handle this new representation. * I added more tests for above changes. * On phabricator I addressed some minor changes. * Lastly I worked on review comments. Reviewers: klausler,sscalpone,DavidTruby,kiranchandramohan,tskeith,anchu-rajendran,kiranktp Reviewed By:klausler, DavidTruby, tskeith Subscribers:#flang-commits, #llvm-commits Tags: #flang, #llvm Differential Revision: https://reviews.llvm.org/D78623 | 6 年前 | |
[flang] Rework F'2023 constraint C1167 checking (#83888) The code that verifies that the type in a TYPE IS or CLASS IS clause is a match or an extension of the type of the SELECT TYPE selector needs rework to avoid emitting a bogus error for a test. Fixes https://github.com/llvm/llvm-project/issues/83612. | 2 年前 | |
[flang] Semantics for SELECT TYPE Summary: Added support for all semantic checks except C1157 was previously implemented. Address review comments. Reviewers: PeteSteinfeld, tskeith, klausler, DavidTruby, kiranktp, anchu-rajendran, sscalpone Subscribers: kiranchandramohan, llvm-commits, flang-commits Tags: #llvm, #flang Differential Revision: https://reviews.llvm.org/D79851 | 5 年前 | |
[flang] Finer control over error recovery with GetExpr() Prior to this patch, the semantics utility GetExpr() will crash unconditionally if it encounters a typed expression in the parse tree that has not been set by expression semantics. This is the right behavior when called from lowering, by which time it is known that the program had no fatal user errors, since it signifies a fatal internal error. However, prior to lowering, in the statement semantics checking code, a more nuanced test should be used before crashing -- specifically, we should not crash in the face of a missing typed expression when in error recovery mode. Getting this right requires GetExpr() and its helper class to have access to the semantics context, so that it can check AnyFatalErrors() before crashing. So this patch touches nearly all of its call sites. Differential Revision: https://reviews.llvm.org/D123873 | 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] Move EQUIVALENCE object checking to check-declarations.cpp (#91259) Move EQUIVALENCE object checking from resolve-names-utils.cpp to check-declarations.cpp, where it can work on fully resolved symbols and reduce clutter in name resolution. Add a check for EQUIVALENCE objects that are not ObjectEntityDetails symbols so that attempts to equivalence a procedure are caught. | 2 年前 | |
[flang] Implement STORAGE_SIZE(), SIZEOF(), C_SIZEOF() STORAGE_SIZE() is a standard inquiry intrinsic (size in bits of an array element of the same type as the argument); SIZEOF() is a common extension that returns the size in bytes of its argument; C_SIZEOF() is a renaming of SIZEOF() in module ISO_C_BINDING. STORAGE_SIZE() and SIZEOF() are implemented via rewrites to expressions; these expressions will be constant when the necessary type parameters and bounds are also constant. Code to calculate the sizes of types (with and without alignment) was isolated into Evaluate/type.* and /characteristics.*. Code in Semantics/compute-offsets.* to calculate sizes and alignments of derived types' scopes was exposed so that it can be called at type instantiation time (earlier than before) so that these inquiry intrinsics could be called from specification expressions. Differential Revision: https://reviews.llvm.org/D93322 | 5 年前 | |
[flang] Better error message for RANK(NULL()) (#93577) We currently complain that the argument may not be a procedure, which is confusing. Distinguish the NULL() case from other error cases (which are indeed procedures). And clean up the utility predicates used for these tests -- the current IsProcedure() is really just a test for a procedure designator. | 2 年前 | |
[flang][NFC] Speed up large DATA statement initializations (#67585) To ensure that the map from symbols to their initial images has an entry for a particular symbol, use std::map<>::find() before std::map<>::emplace() to avoid needless memory allocation and deallocation. Also, combine adjacent intervals in the lists of initialized ranges so that contiguous initializations don't require long lists. Fixes https://github.com/llvm/llvm-project/issues/66452. | 2 年前 | |
[flang] ASSOCIATE/SELECT TYPE entities aren't pointer/allocatable (#99364) Fix what seems to be a regression in semantics in definability checking: the construct entities of ASSOCIATE and SELECT TYPE constructs are never pointers or allocatables, even when their selectors are so. SELECT RANK construct entities, however, can be pointers or allocatables. | 1 年前 | |
[flang] Downgrade error message to a portability warning (#98368) f18 current emits an error when an assignment is made to an array section with a vector subscript, and the array is finalized with a non-elemental final subroutine. Some other compilers emit this error because (I think) they want variables to only be finalized in place, not by a subroutine call involving copy-in & copy-out of the finalized elements. Since many other Fortran compilers can handle this case, and there's nothing in the standards to preclude it, let's downgrade this error message to a portability warning. This patch got complicated because the API for the WhyNotDefinable() utility routine was such that it would return a message only in error cases, and there was no provision for returning non-fatal messages. It now returns either nothing, a fatal message, or a non-fatal warning message, and all of its call sites have been modified to cope. | 1 年前 | |
[flang] Check assignment conformance for derived types (#99059) Derived type assignment checking needs to account for the possibility of derived assignment. The implementation was checking compile-time conformance errors only on the path for assignments of intrinsic types. Add a static array conformance check in the derived type flow once it has been established that no defined assignment exists. Fixes https://github.com/llvm/llvm-project/issues/98981. | 1 年前 | |
[flang] Add -fhermetic-module-files (#98083) Module files emitted by this Fortran compiler are valid Fortran source files. Symbols that are USE-associated into modules are represented in their module files with USE statements and special comments with hash codes in them to ensure that those USE statements resolve to the same modules that were used to build the module when its module file was generated. This scheme prevents unchecked module file growth in large applications by not emitting USE-associated symbols redundantly. This problem can be especially bad when derived type definitions must be repeated in the module files of their clients, and the clients of those modules, and so on. However, this scheme has the disadvantage that clients of modules must be compiled with dependent modules in the module search path. This new -fhermetic-module-files option causes module file output to be free of dependences on any non-intrinsic module files; dependent modules are instead emitted as part of the module file, rather than being USE-associated. It is intended for top level library module files that are shipped with binary libraries when it is not convenient to collect and ship their dependent module files as well. Fixes https://github.com/llvm/llvm-project/issues/97398. | 1 年前 | |
[flang] Add -fhermetic-module-files (#98083) Module files emitted by this Fortran compiler are valid Fortran source files. Symbols that are USE-associated into modules are represented in their module files with USE statements and special comments with hash codes in them to ensure that those USE statements resolve to the same modules that were used to build the module when its module file was generated. This scheme prevents unchecked module file growth in large applications by not emitting USE-associated symbols redundantly. This problem can be especially bad when derived type definitions must be repeated in the module files of their clients, and the clients of those modules, and so on. However, this scheme has the disadvantage that clients of modules must be compiled with dependent modules in the module search path. This new -fhermetic-module-files option causes module file output to be free of dependences on any non-intrinsic module files; dependent modules are instead emitted as part of the module file, rather than being USE-associated. It is intended for top level library module files that are shipped with binary libraries when it is not convenient to collect and ship their dependent module files as well. Fixes https://github.com/llvm/llvm-project/issues/97398. | 1 年前 | |
[flang] Downgrade error message to a portability warning (#98368) f18 current emits an error when an assignment is made to an array section with a vector subscript, and the array is finalized with a non-elemental final subroutine. Some other compilers emit this error because (I think) they want variables to only be finalized in place, not by a subroutine call involving copy-in & copy-out of the finalized elements. Since many other Fortran compilers can handle this case, and there's nothing in the standards to preclude it, let's downgrade this error message to a portability warning. This patch got complicated because the API for the WhyNotDefinable() utility routine was such that it would return a message only in error cases, and there was no provision for returning non-fatal messages. It now returns either nothing, a fatal message, or a non-fatal warning message, and all of its call sites have been modified to cope. | 1 年前 | |
[flang] Don't check dummy vs. actual result rank for assumed-rank poi… (#66237) …nters When associating a function result pointer as an actual argument with a dummy pointer that is assumed-rank, don't emit a bogus error. | 2 年前 | |
[flang] Ensure all warning/portability messages are guarded by Should… (#90518) …Warn() Many warning messages were being emitted unconditionally. Ensure that all warnings are conditional on a true result from a call to common::LanguageFeatureControl::ShouldWarn() so that it is easy for a driver to disable them all, or, in the future, to provide per-warning control over them. | 2 年前 | |
[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 年前 | |
| 2 年前 | ||
[flang] Parse REDUCE clauses in !$CUF KERNEL DO (#92154) A !$CUF KERNEL DO directive is allowed to have advisory REDUCE clauses similar to those in OpenACC and DO CONCURRENT. Parse and represent them. Semantic validation will follow. | 2 年前 | |
[flang] Disallow branches into SELECT TYPE/RANK cases (#93893) Ensure that a branch cannot be made into a case of a SELECT TYPE or SELECT RANK construct. | 2 年前 | |
[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] Handle USE-associated symbols in module procedure interface b… (#93616) …lock specification expressions A subroutine or function interface block is of course allowed to USE-associate symbols into its scope and use them for specification expressions. This usage works, but crashes the module file output generator. Fix. Fixes https://github.com/llvm/llvm-project/issues/93413. | 2 年前 | |
[flang] Map symbols in expressions when copying interface symbols Given a MODULE SUBROUTINE or MODULE FUNCTION interface followed later by a corresponding separate module subprogram definition in a MODULE PROCEDURE, the copies of the interface's dummy argument and function result symbols that populate the initial scope of that MODULE PROCEDURE need to have any symbol references in their types or bounds adjusted to point to their new counterparts. Differential Revision: https://reviews.llvm.org/D139200 | 3 年前 | |
[flang] Downgrade error message to a portability warning (#98368) f18 current emits an error when an assignment is made to an array section with a vector subscript, and the array is finalized with a non-elemental final subroutine. Some other compilers emit this error because (I think) they want variables to only be finalized in place, not by a subroutine call involving copy-in & copy-out of the finalized elements. Since many other Fortran compilers can handle this case, and there's nothing in the standards to preclude it, let's downgrade this error message to a portability warning. This patch got complicated because the API for the WhyNotDefinable() utility routine was such that it would return a message only in error cases, and there was no provision for returning non-fatal messages. It now returns either nothing, a fatal message, or a non-fatal warning message, and all of its call sites have been modified to cope. | 1 年前 | |
[flang] Use module file hashes for more checking and disambiguation (#80354) f18's module files are Fortran with a leading header comment containing the module file format version and a hash of the following contents. This hash is currently used only to protect module files against corruption and truncation. Extend the use of these hashes to catch or avoid some error cases. When one module file depends upon another, note its hash in additional module file header comments. This allows the compiler to detect when the module dependency is on a module file that has been updated. Further, it allows the compiler to find the right module file dependency when the same module file name appears in multiple directories on the module search path. The order in which module files are written, when multiple modules appear in a source file, is such that every dependency is written before the module(s) that depend upon it, so that their hashes are known. A warning is emitted when a module file is not the first hit on the module file search path. Further work is needed to add a compiler option that emits (larger) stand-alone module files that incorporate copies of their dependencies rather than relying on search paths. This will be desirable for application libraries that want to ship only "top-level" module files without needing to include their dependencies. Another future work item would be to admit multiple modules in the same compilation with the same name if they have distinct hashes. | 2 年前 | |
[Frontend][OpenMP] introduce OMP.h header file, use it instead of OMP… (#84188) ….h.inc The consumers of OpenMP-related definitions include a TableGen-generated file OMP.h.inc. Having a separate OMP.h allows putting additional declarations in there that are not auto-generated. This patch is NFC. | 2 年前 | |
[Flang][OpenMP][Sema] Add directive rewrite pass to support atomic_default_mem_order REQUIRES clause This patch creates the OmpRewriteMutator pass that runs at the end of RewriteParseTree(). This pass is intended to make OpenMP-specific mutations to the PFT after name resolution. In the case of the atomic_default_mem_order clause of the REQUIRES directive, name resolution results in populating global symbols with information about the REQUIRES clauses that apply to that scope. The new rewrite pass is then able to use this information in order to explicitly set the memory order of ATOMIC constructs for which that is not already specified. Given that this rewrite happens before semantics checks, the check of the order in which ATOMIC constructs without explicit memory order and REQUIRES directives with atomic_default_mem_order appear is moved earlier into the rewrite pass. Otherwise, these problems would not be caught by semantics checks, since the PFT would be modified by that stage. This is patch 4/5 of a series splitting D149337 to simplify review. Depends on D157983. Differential Revision: https://reviews.llvm.org/D158096 | 2 年前 | |
[Flang][OpenMP][Sema] Add directive rewrite pass to support atomic_default_mem_order REQUIRES clause This patch creates the OmpRewriteMutator pass that runs at the end of RewriteParseTree(). This pass is intended to make OpenMP-specific mutations to the PFT after name resolution. In the case of the atomic_default_mem_order clause of the REQUIRES directive, name resolution results in populating global symbols with information about the REQUIRES clauses that apply to that scope. The new rewrite pass is then able to use this information in order to explicitly set the memory order of ATOMIC constructs for which that is not already specified. Given that this rewrite happens before semantics checks, the check of the order in which ATOMIC constructs without explicit memory order and REQUIRES directives with atomic_default_mem_order appear is moved earlier into the rewrite pass. Otherwise, these problems would not be caught by semantics checks, since the PFT would be modified by that stage. This is patch 4/5 of a series splitting D149337 to simplify review. Depends on D157983. Differential Revision: https://reviews.llvm.org/D158096 | 2 年前 | |
[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] harden TypeAndShape for assumed-ranks (#96234) SIZEOF and C_SIZEOF were broken for assumed-ranks because TypeAndShape::MeasureSizeInBytes behaved as a scalar because the TypeAndShape::shape_ member was the same for scalar and assumed-ranks. The easy fix would have been to add special handling in MeasureSizeInBytes for assumed-ranks using the TypeAndShape attributes, but I think this solution would leave TypeAndShape::shape_ manipulation fragile to future developers. Hence, I went for the solution that turn shape_ into a std::optional<Shape>. | 2 年前 | |
[flang] Change argument to const reference (#95048) cppcheck recommends that a std::map being passed by value be changed to a const reference. Fixes https://github.com/llvm/llvm-project/issues/94932. | 2 年前 | |
[flang] Add -fhermetic-module-files (#98083) Module files emitted by this Fortran compiler are valid Fortran source files. Symbols that are USE-associated into modules are represented in their module files with USE statements and special comments with hash codes in them to ensure that those USE statements resolve to the same modules that were used to build the module when its module file was generated. This scheme prevents unchecked module file growth in large applications by not emitting USE-associated symbols redundantly. This problem can be especially bad when derived type definitions must be repeated in the module files of their clients, and the clients of those modules, and so on. However, this scheme has the disadvantage that clients of modules must be compiled with dependent modules in the module search path. This new -fhermetic-module-files option causes module file output to be free of dependences on any non-intrinsic module files; dependent modules are instead emitted as part of the module file, rather than being USE-associated. It is intended for top level library module files that are shipped with binary libraries when it is not convenient to collect and ship their dependent module files as well. Fixes https://github.com/llvm/llvm-project/issues/97398. | 1 年前 | |
[flang] Support BIND(C, NAME="...", CDEFINED) extension (#94402) This CDEFINED keyword extension to a language-binding-spec signifies that static storage for an interoperable variable will be allocated outside of Fortran, probably by a C/C++ external object definition. | 2 年前 | |
[flang] Fix crash in semantics on error case (#91482) An erroneous statement function declaration exposed an unhandled situation in a utility routine in semantics. Patch that hole and add a test. Fixes https://github.com/llvm/llvm-project/issues/91429. | 2 年前 | |
[flang] Silence over-eager warning about interoperable character length (#97353) Make the results of the two IsInteroperableIntrinsicType() utility routines a tri-state std::optional<bool> so that cases where the character length is simply unknown can be distinguished from those cases where the length is known and not acceptable. Use this distinction to not emit a confusing warning about interoperability with C_LOC() arguments when the length is unknown and might well be acceptable during execution. | 1 年前 | |
[flang] New -fdebug-unparse-with-modules option (#91660) This option is a compilation action that parses a source file and performs semantic analysis on it, like the existing -fdebug-unparse option does. Its output, however, is preceded by the effective contents of all of the non-intrinsic modules on which it depends but does not define, transitively preceded by the closure of all of those modules' dependencies. The output from this option is therefore the analyzed parse tree for a source file encapsulated with all of its non-intrinsic module dependencies. This output may be useful for extracting code from large applications for use as an attachment to a bug report, or as input to a test case reduction tool for problem isolation. | 2 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 2 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 5 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 6 年前 | ||
| 2 年前 | ||
| 6 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 6 年前 | ||
| 4 年前 | ||
| 6 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 6 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 4 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 5 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 6 年前 | ||
| 6 年前 | ||
| 6 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 6 年前 | ||
| 1 年前 | ||
| 6 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 6 年前 | ||
| 4 年前 | ||
| 6 年前 | ||
| 2 年前 | ||
| 6 年前 | ||
| 2 年前 | ||
| 5 年前 | ||
| 4 年前 | ||
| 6 年前 | ||
| 2 年前 | ||
| 5 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 6 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 6 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 2 年前 |