|
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init |
|
| #
23c2bedf |
| 01-Jul-2022 |
Peter Klausler <[email protected]> |
[flang] Establish a single source of target information for semantics
Create a TargetCharacteristics class to centralize the few items of target specific information that are relevant to semantics.
[flang] Establish a single source of target information for semantics
Create a TargetCharacteristics class to centralize the few items of target specific information that are relevant to semantics. Use the new class for all target queries, including derived type component layout modeling.
Future work will initialize this class with target information provided or forwarded by the drivers, and use it to fold layout-dependent intrinsic functions like TRANSFER().
Differential Revision: https://reviews.llvm.org/D129018
Updates: Attempts to work around build issues on Windows.
show more ...
|
|
Revision tags: llvmorg-14.0.6, llvmorg-14.0.5 |
|
| #
73506256 |
| 24-May-2022 |
Peter Klausler <[email protected]> |
[flang] Avoid spurious warnings from reading module files
When processing the literal constants of the various kinds of INTEGER that are too large by 1 (e.g., 2147483648_4) in expression analysis, e
[flang] Avoid spurious warnings from reading module files
When processing the literal constants of the various kinds of INTEGER that are too large by 1 (e.g., 2147483648_4) in expression analysis, emit a portability warning rather than a fatal error if the literal constant appears as the operand to a unary minus, since the folded result will be in range. And don't emit any warning if the negated literal is coming from a module file -- f18 wrote the module file and the warning would simply be confusing, especially to the programmer that wrote (-2147483647_4-1) in the first place.
Further, emit portability warnings for the canonical expressions for infinities and NaN (-1./0., 0./0., & 1./0.), but not when they appear in a module file, for the same reason. The Fortran language has no syntax for these special values so we have to emit expressions that fold to them.
Fixes LLVM bugs https://github.com/llvm/llvm-project/issues/55086 and https://github.com/llvm/llvm-project/issues/55081.
Differential Revision: https://reviews.llvm.org/D126584
show more ...
|
|
Revision tags: llvmorg-14.0.4 |
|
| #
2c8cb9ac |
| 29-Apr-2022 |
Jean Perier <[email protected]> |
[flang] Handle common block with different sizes in same file
Semantics is not preventing a named common block to appear with different size in a same file (named common block should always have the
[flang] Handle common block with different sizes in same file
Semantics is not preventing a named common block to appear with different size in a same file (named common block should always have the same storage size (see Fortran 2018 8.10.2.5), but it is a common extension to accept different sizes).
Lowering was not coping with this well, since it just use the first common block appearance, starting with BLOCK DATAs to define common blocks (this also was an issue with the blank common block, which can legally appear with different size in different scoping units).
Semantics is also not preventing named common from being initialized outside of a BLOCK DATA, and lowering was dealing badly with this, since it only gave an initial value to common blocks Globals if the first common block appearance, starting with BLOCK DATAs had an initial value.
Semantics is also allowing blank common to be initialized, while lowering was assuming this would never happen, and was never creating an initial value for it.
Lastly, semantics was not complaining if a COMMON block was initialized in several scoping unit in a same file, while lowering can only generate one of these initial value.
To fix this, add a structure to keep track of COMMON block properties (biggest size, and initial value if any) at the Program level. Once the size of a common block appearance is know, the common block appearance is checked against this information. It allows semantics to emit an error in case of multiple initialization in different scopes of a same common block, and to warn in case named common blocks appears with different sizes. Lastly, this allows lowering to use the Program level info about common blocks to emit the right GlobalOp for a Common Block, regardless of the COMMON Block appearances order: It emits a GlobalOp with the biggest size, whose lowest bytes are initialized with the initial value if any is given in a scope where the common block appears.
Lowering is updated to go emit the common blocks before anything else so that the related GlobalOps are available when lowering the scopes where common block appear. It is also updated to not assume that blank common are never initialized.
Differential Revision: https://reviews.llvm.org/D124622
show more ...
|
|
Revision tags: llvmorg-14.0.3, llvmorg-14.0.2 |
|
| #
f4bb211a |
| 25-Apr-2022 |
Peter Klausler <[email protected]> |
[flang] Fix crash from PDT component init in module file
Semantics now needs to preserve the parse trees from module files, in case they contain parameterized derived type definitions with component
[flang] Fix crash from PDT component init in module file
Semantics now needs to preserve the parse trees from module files, in case they contain parameterized derived type definitions with component initializers that may require re-analysis during PDT instantiation. Save them in the SemanticsContext.
Differential Revision: https://reviews.llvm.org/D124467
show more ...
|
|
Revision tags: llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3 |
|
| #
a53967cd |
| 07-Mar-2022 |
Peter Klausler <[email protected]> |
[flang] Distinguish usage and portability warning messages
Using recently established message severity codes, upgrade non-fatal messages to usage and portability warnings as appropriate.
Differenti
[flang] Distinguish usage and portability warning messages
Using recently established message severity codes, upgrade non-fatal messages to usage and portability warnings as appropriate.
Differential Revision: https://reviews.llvm.org/D121246
show more ...
|
|
Revision tags: llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init |
|
| #
52a1346b |
| 26-Jan-2022 |
Peter Klausler <[email protected]> |
[flang] Distinguish intrinsic from non-intrinsic modules
For "USE, INTRINSIC", search only for intrinsic modules; for "USE, NON_INTRINSIC", do not recognize intrinsic modules. Allow modules of both
[flang] Distinguish intrinsic from non-intrinsic modules
For "USE, INTRINSIC", search only for intrinsic modules; for "USE, NON_INTRINSIC", do not recognize intrinsic modules. Allow modules of both kinds with the same name to be used in the same source file (but not in the same scoping unit, a constraint of the standard that is now enforced).
The symbol table's scope tree now has a single instance of a scope with a new kind, IntrinsicModules, whose children are the USE'd intrinsic modules (explicit or not). This separate "top-level" scope is a child of the single global scope and it allows both intrinsic and non-intrinsic modules of the same name to exist in the symbol table. Intrinsic modules' scopes' symbols now have the INTRINSIC attribute set.
The search path directories need to make a distinction between regular directories and the one(s) that point(s) to intrinsic modules. I allow for multiple intrinsic module directories in the second search path, although only one is needed today.
Differential Revision: https://reviews.llvm.org/D118631
show more ...
|
|
Revision tags: llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2 |
|
| #
00e0de05 |
| 04-Jan-2022 |
Peter Klausler <[email protected]> |
[flang] Extension: initialization of LOGICAL with INTEGER & vice versa
We already accept assignments of INTEGER to LOGICAL (& vice versa) as an extension, but not initialization. Extend initializat
[flang] Extension: initialization of LOGICAL with INTEGER & vice versa
We already accept assignments of INTEGER to LOGICAL (& vice versa) as an extension, but not initialization. Extend initialization to cover those cases.
(Also fix misspelling in nearby comment as suggested by code reviewer.)
Decouple an inadvertent dependence cycle by moving two one-line function definitions into a header file.
Differential Revision: https://reviews.llvm.org/D117159
show more ...
|
| #
c14cf92b |
| 18-Dec-2021 |
Peter Klausler <[email protected]> |
[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.
[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
show more ...
|
|
Revision tags: llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4 |
|
| #
52711fb8 |
| 21-Sep-2021 |
peter klausler <[email protected]> |
[flang] Make builtin types more easily accessible; use them
Rearrange the contents of __builtin_* module files a little and make sure that semantics implicitly USEs the module __Fortran_builtins bef
[flang] Make builtin types more easily accessible; use them
Rearrange the contents of __builtin_* module files a little and make sure that semantics implicitly USEs the module __Fortran_builtins before processing each source file. This ensures that the special derived types for TEAM_TYPE, EVENT_TYPE, LOCK_TYPE, &c. exist in the symbol table where they will be available for use in coarray intrinsic function processing.
Update IsTeamType() to exploit access to the __Fortran_builtins module rather than applying ad hoc name tests. Move it and some other utilities from Semantics/tools.* to Evaluate/tools.* to make them available to intrinsics processing.
Add/correct the intrinsic table definitions for GET_TEAM, TEAM_NUMBER, and THIS_IMAGE to exercise the built-in TEAM_TYPE as an argument and as a result.
Add/correct/extend tests accordingly.
Differential Revision: https://reviews.llvm.org/D110356
show more ...
|
|
Revision tags: llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4 |
|
| #
46ade6d0 |
| 16-Mar-2021 |
peter klausler <[email protected]> |
[flang] Order Symbols by source provenance
In parser::AllCookedSources, implement a map from CharBlocks to the CookedSource instances that they cover. This permits a fast Find() operation based on
[flang] Order Symbols by source provenance
In parser::AllCookedSources, implement a map from CharBlocks to the CookedSource instances that they cover. This permits a fast Find() operation based on std::map::equal_range to map a CharBlock to its enclosing CookedSource instance.
Add a creation order number to each CookedSource. This allows AllCookedSources to provide a Precedes(x,y) predicate that is a true source stream ordering between two CharBlocks -- x is less than y if it is in an earlier CookedSource, or in the same CookedSource at an earlier position.
Add a reference to the singleton SemanticsContext to each Scope.
All of this allows operator< to be implemented on Symbols by means of a true source ordering. From a Symbol, we get to its Scope, then to the SemanticsContext, and then use its AllCookedSources reference to call Precedes().
Differential Revision: https://reviews.llvm.org/D98743
show more ...
|
|
Revision tags: llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2 |
|
| #
1bd083b5 |
| 15-Jan-2021 |
peter klausler <[email protected]> |
[flang] Create names to allow access to inaccessible specifics
When a reference to a generic interface occurs in a specification expression that must be emitted to a module file, we have a problem w
[flang] Create names to allow access to inaccessible specifics
When a reference to a generic interface occurs in a specification expression that must be emitted to a module file, we have a problem when the generic resolves to a function whose name is inaccessible due to being PRIVATE or due to a conflict with another use of the same name in the scope. In these cases, construct a new name for the specific procedure and emit a renaming USE to the module file. Also, relax enforcement of PRIVATE when analyzing module files.
Differential Revision: https://reviews.llvm.org/D94815
show more ...
|
| #
a50bb84e |
| 12-Jan-2021 |
peter klausler <[email protected]> |
[flang] Fix classification of shape inquiries in specification exprs
In some contexts, including the motivating case of determining whether the expressions that define the shape of a variable are "c
[flang] Fix classification of shape inquiries in specification exprs
In some contexts, including the motivating case of determining whether the expressions that define the shape of a variable are "constant expressions" in the sense of the Fortran standard, expression rewriting via Fold() is not necessary, and should not be required. The inquiry intrinsics LBOUND, UBOUND, and SIZE work correctly now in specification expressions and are classified correctly as being constant expressions (or not). Getting this right led to a fair amount of API clean-up as a consequence, including the folding of shapes and TypeAndShape objects, and new APIs for shapes that do not fold for those cases where folding isn't needed. Further, the symbol-testing predicate APIs in Evaluate/tools.h now all resolve any associations of their symbols and work transparently on use-, host-, and construct-association symbols; the tools used to resolve those associations have been defined and documented more precisely, and their clients adjusted as needed.
Differential Revision: https://reviews.llvm.org/D94561
show more ...
|
|
Revision tags: llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2 |
|
| #
6aa3591e |
| 15-Dec-2020 |
peter klausler <[email protected]> |
[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 extens
[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
show more ...
|
| #
4fede8bc |
| 07-Dec-2020 |
peter klausler <[email protected]> |
[flang] Implement derived type description table encoding
Define Fortran derived types that describe the characteristics of derived types, and instantiations of parameterized derived types, that are
[flang] Implement derived type description table encoding
Define Fortran derived types that describe the characteristics of derived types, and instantiations of parameterized derived types, that are of relevance to the runtime language support library. Define a suite of corresponding C++ structure types for the runtime library to use to interpret instances of the descriptions.
Create instances of these description types in Semantics as static initializers for compiler-created objects in the scopes that define or instantiate user derived types.
Delete obsolete code from earlier attempts to package runtime type information.
Differential Revision: https://reviews.llvm.org/D92802
show more ...
|
|
Revision tags: llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3 |
|
| #
92a54197 |
| 31-Aug-2020 |
peter klausler <[email protected]> |
[flang] Support multiple CookedSource instances
These are owned by an instance of a new class AllCookedSources.
This removes the need for a Scope to own a string containing a module's cooked source
[flang] Support multiple CookedSource instances
These are owned by an instance of a new class AllCookedSources.
This removes the need for a Scope to own a string containing a module's cooked source stream, and will enable errors to be emitted when parsing module files in the future.
Differential Revision: https://reviews.llvm.org/D86891
show more ...
|
| #
f80866bd |
| 01-Sep-2020 |
peter klausler <[email protected]> |
[flang] Make -fget-symbols-sources output deterministic
The DumpSymbolsSources() routine ordered its output by the addresses of the names of the symbols, and was susceptible to variation across envi
[flang] Make -fget-symbols-sources output deterministic
The DumpSymbolsSources() routine ordered its output by the addresses of the names of the symbols, and was susceptible to variation across environments. Fixed by using a multimap using the values of the names.
Differential Revision: https://reviews.llvm.org/D87035
show more ...
|
| #
627e9007 |
| 28-Aug-2020 |
Tim Keith <[email protected]> |
[flang][NFC] Change how error symbols are recorded
When an error is associated with a symbol, it was marked with a flag from Symbol::Flag. The problem with that is that you need a mutable symbol to
[flang][NFC] Change how error symbols are recorded
When an error is associated with a symbol, it was marked with a flag from Symbol::Flag. The problem with that is that you need a mutable symbol to do that. Instead, store the set of error symbols in the SemanticsContext. This allows for some const_casts to be eliminated.
Also, improve the internal error that occurs if SetError is called but no fatal error has been reported.
Differential Revision: https://reviews.llvm.org/D86740
show more ...
|
|
Revision tags: llvmorg-11.0.0-rc2 |
|
| #
4ac617f4 |
| 07-Aug-2020 |
peter klausler <[email protected]> |
[flang] Handle DATA initialization of EQUIVALENCE'd objects
Objects that are storage associated by EQUIVALENCE and initialized with DATA are initialized by creating a compiler temporary data object
[flang] Handle DATA initialization of EQUIVALENCE'd objects
Objects that are storage associated by EQUIVALENCE and initialized with DATA are initialized by creating a compiler temporary data object in the same scope, assigning it an offset, type, and size that covers the transitive closure of the associated initialized original symbols, and combining their initializers into one common initializer for the temporary.
Some problems with offset assignment of EQUIVALENCE'd objects in COMMON were exposed and corrected, and some more error cases are checked.
Remove obsolete function. Small bugfix (nested implied dos). Add a test. Fix struct/class warning.
Differential Revision: https://reviews.llvm.org/D85560
show more ...
|
|
Revision tags: llvmorg-11.0.0-rc1, llvmorg-12-init |
|
| #
9aa3dca8 |
| 15-Jul-2020 |
Valentin Clement <[email protected]> |
[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,
[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
show more ...
|
|
Revision tags: llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2 |
|
| #
a20d48d7 |
| 19-Jun-2020 |
peter klausler <[email protected]> |
[flang] DATA stmt processing (part 4/4): Check & convert DATA
Implement rest of DATA statement semantics and conversion of DATA statement initializations into static initializers of objects in their
[flang] DATA stmt processing (part 4/4): Check & convert DATA
Implement rest of DATA statement semantics and conversion of DATA statement initializations into static initializers of objects in their symbol table entries.
Reviewed By: tskeith, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D82207
show more ...
|
|
Revision tags: llvmorg-10.0.1-rc1 |
|
| #
70ad73b6 |
| 19-Apr-2020 |
sameeran joshi <[email protected]> |
[flang] Semantics for SELECT TYPE
Summary: Added support for all semantic checks except C1157 was previously implemented.
Address review comments.
Reviewers: PeteSteinfeld, tsk
[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
show more ...
|
| #
332e6aea |
| 22-Apr-2020 |
sameeran joshi <[email protected]> |
[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 symbo
[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
show more ...
|
| #
54b35c06 |
| 06-May-2020 |
Tim Keith <[email protected]> |
[flang][NFC] Replace "align" with "alignment"
In the places it is used as a noun, replace "align" with "alignment".
Differential Revision: https://reviews.llvm.org/D79520
|
| #
c353ebbf |
| 22-Apr-2020 |
Tim Keith <[email protected]> |
[flang] Compute sizes and offsets for symbols
Summary: Add size and offset properties to symbols, representing their byte size and offset within their enclosing scope.
Add size and align properties
[flang] Compute sizes and offsets for symbols
Summary: Add size and offset properties to symbols, representing their byte size and offset within their enclosing scope.
Add size and align properties to scopes so that they are available for scopes representing derived types.
Add ComputeOffsets pass over the symbol table to fill in those fields.
Compute descriptor size based on rank and length parameters. Extract DerivedTypeSpec::NumLengthParameters from DynamicType::RequiresDescriptor to share the code.
Add Scope::GetSymbols to get symbols in canonical order. compute-offsets.cpp and mod-file.cpp both need to process symbols in the order in which they are declared. Move the collecting of those symbols into Scope so that it can be shared.
Add symbol size and offset to output of `-fdebug-dump-symbols` and use that in some tests.
Still to do: - make size and alignment rules configurable based on target - use offsets to check EQUIVALENCE statements
Differential Revision: https://reviews.llvm.org/D78680
show more ...
|
| #
455ed8de |
| 03-Apr-2020 |
peter klausler <[email protected]> |
[flang] Process names in ASSIGN and assigned GOTO
Allow ASSIGNed integer variables as formats
Address review comment
Original-commit: flang-compiler/f18@361a151508b4a1940fc0669dead180be67964d8d Re
[flang] Process names in ASSIGN and assigned GOTO
Allow ASSIGNed integer variables as formats
Address review comment
Original-commit: flang-compiler/f18@361a151508b4a1940fc0669dead180be67964d8d Reviewed-on: https://github.com/flang-compiler/f18/pull/1099
show more ...
|