The combined initializers constructed from DATA statements and explicit
static initialization in declarations needs to include derived type
component default initializations, overriding those default values
without complaint with values from explicit DATA statement or declaration
initializations when they overlap. This also has to work for objects
with storage association due to EQUIVALENCE. When storage association causes
default component initializations to overlap, emit errors if and only
if the values differ (See Fortran 2018 subclause 19.5.3, esp. paragraph
10).
The f18 front-end has a module that analyzes and converts DATA statements
into equivalent static initializers for objects. For storage-associated
objects, compiler-generated objects are created that overlay the entire
association and fill it with a combined initializer. This "data-to-inits"
module already exists, and this patch is essentially extension and
clean-up of its machinery to complete the job.
Also: emit EQUIVALENCE to module files; mark compiler-created symbols
and *don't* emit those to module files; check non-static EQUIVALENCE
sets for conflicting default component initializations, so lowering
doesn't have to check them or emit diagnostics.
Differential Revision: https://reviews.llvm.org/D109022
This aligns the printer with the parser contract: the operation isn't part of the user-controllable part of the syntax.
Differential Revision: https://reviews.llvm.org/D108804
The StringAttr version doesn't need a context, so we can just use the
existing `SymbolRefAttr::get` form. The StringRef version isn't preferred
so we want to encourage people to use StringAttr.
There is an additional form of getSymbolRefAttr that takes a (SymbolTrait
implementing) operation. This should also be moved, but I'll do that as
a separate patch.
Differential Revision: https://reviews.llvm.org/D108922
This patch cleans-up the file generation code in Flang's frontend
driver. It improves the layering between
`CompilerInstance::CreateDefaultOutputFile`,
`CompilerInstance::CreateOutputFile` and their various clients.
* Rename `CreateOutputFile` as `CreateOutputFileImpl` and make it
private. This method is an implementation detail.
* Instead of passing an `std::error_code` out parameter into
`CreateOutputFileImpl`, have it return Expected<>. This is a bit shorter
and idiomatic LLVM.
* Make `CreateDefaultOutputFile` (which calls `CreateOutputFileImpl`)
issue an error when file creation fails. The error code from
`CreateOutputFileImpl` is used to generate a meaningful diagnostic
message.
* Remove error reporting from `PrintPreprocessedAction::ExecuteAction`.
This is only for cases when output file generation fails. This is
handled in `CreateDefaultOutputFile` instead (see the previous point).
* Inline `AddOutputFile` into its only caller,
`CreateDefaultOutputFile`.
* Switch from `lvm::buffer_ostream` to `llvm::buffer_unique_ostream>`
for non-seekable output streams. This simplifies the logic in the driver
and was introduced for this very reason in [1]
* Moke sure that the diagnostics from the prescanner when running `-E`
(`PrintPreprocessedAction::ExecuteAction`) are printed before the actual
output is generated.
* Update comments, add test.
NOTE: This patch relands [2]. As suggested by Michael Kruse in the
post-commit/post-revert review, I've added the following:
```
config.errc_messages = "@LLVM_LIT_ERRC_MESSAGES@"
```
in Flang's `lit.site.cfg.py.in`. This way, `%errc_ENOENT` in
output-paths.f90 gets the correct value on Windows as well as on Linux.
[1] https://reviews.llvm.org/D93260
[2] fd21d1e198
Reviewed By: ashermancinelli
Differential Revision: https://reviews.llvm.org/D108390
This reverts commit fd21d1e198.
The test added in this patch [1] is failing on Windows and causing the
Windows BuildBot [2] to fail. I don't see any obvious way to fix this,
so reverting in order to investigate.
[1] llvm-project/flang/test/Driver/output-paths.f90
[2] https://lab.llvm.org/buildbot/#/builders/172/builds/2077
This patch refactors the file generation API in Flang's frontend driver.
It improves the layering between `CreateDefaultOutputFile`,
`CreateOutputFile` (`CompilerInstance` methods) and their various
clients.
List of changes:
* Rename `CreateOutputFile` as `CreateOutputFileImpl` and make it
private. This method is an implementation detail.
* Instead of passing an `std::error_code` out parameter into
`CreateOutputFileImpl`, have it return Expected<>. This is a bit shorter
and more idiomatic LLVM.
* Make `CreateDefaultOutputFile` (which calls `CreateOutputFileImpl`)
issue an error when file creation fails. The error code from
`CreateOutputFileImpl` is used to generate a meaningful diagnostic
message.
* Remove error reporting from `PrintPreprocessedAction::ExecuteAction`.
This is only for cases when output file generation fails. This is
handled in `CreateDefaultOutputFile` instead (see the previous point).
* Inline `AddOutputFile` into its only caller,
`CreateDefaultOutputFile`.
* Switch from `lvm::buffer_ostream` to `llvm::buffer_unique_ostream>`
for non-seekable output streams. This simplifies the logic in the driver
and was introduced for this very reason in [1]
* Moke sure that the diagnostics from the prescanner when running `-E`
(`PrintPreprocessedAction::ExecuteAction`) are printed before the actual
output is generated.
* Update comments, add test.
[1] https://reviews.llvm.org/D93260
Differential Revision: https://reviews.llvm.org/D108390
Replacing Hello World example Plugin with one that counts and prints the names of
functions and subroutines.
This involves changing the `PluginParseTreeAction` Plugin base class to
inherit from `PrescanAndSemaAction` class to get access to the Parse Tree
so that the Plugin can walk it.
Additionally, there are tests of this new Plugin to check it prints the correct
things in different circumstances.
Depends on: D106137
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D107089
This patch refactors the `FrontendAction` class. It merely moves code
around so that re-using it is easier. No new functionality is
introduced.
1. Three new member methods are introduced: `RunPrescan`, `RunParse`,
`RunSemanticChecks`.
2. The following free functions are re-implemented as member methods:
* `reportFatalSemanticErrors`
* `reportFatalScanningErrors`
* `reportFatalParsingErrors`
* `reportFatalErrors`
`reportFatalSemanticErrors` is updated to resemble the other error
reporting functions and to make the API more consistent.
3. The `BeginSourceFileAction` methods are simplified and the unused
input argument is deleted.
Differential Revision: https://reviews.llvm.org/D108130
`CompilerInstance` is a more appropriate place for a key component of
the frontend like `Semantics`.
This change opens a path for us to introduce new frontend actions that
will also run semantics, but for which inheriting from
`PrescanAndSemaAction` wouldn't make much sense. For example, for
code-gen actions we plan to introduce a dedicate hierarchy of action
classes.
I've also added a doxyment for `CompilerInstance` to add a bit of
context for this change (and also make future refactoring more informed).
As `CompilerInstance` in Flang has been inspired by its counterpart in
Clang, this comment is roughly a verbatim copy of the comment in Clang
(with some adjustments from me). Credits to Daniel Dunbar for the great
design and the original comment.
Differential Revision: https://reviews.llvm.org/D108035
Recent work in runtime assignments failed an assertion in fir-dev
while running tests (flang/test/Semantics/defined-ops.f90). This
test didn't fail in llvm-project/main because only the "new" Arm
driver is used now, and that only builds runtime derived type information
tables when some debug dumping options are enabled.
So add a reproducing test case to another test that is run with
-fdebug-dump-symbols, and fix the crash by emitting special procedure
binding information only for type-bound generic ASSIGNMENT(=) bindings
that are relevant to the runtime support library for use in intrinsic
assignment of derived types.
Differential Revision: https://reviews.llvm.org/D107918
Introducing a plugin API and a simple HelloWorld Plugin example.
This patch adds the `-load` and `-plugin` flags to frontend driver and
the code around using custom frontend actions from within a plugin
shared library object.
It also adds to the Driver-help test to check the help option with the
updated driver flags.
Additionally, the patch creates a plugin-example test to check the
HelloWorld plugin example runs correctly. As part of this, a new CMake
flag (`FLANG_BUILD_EXAMPLES`) is added to allow the example to be built
and for the test to run.
This Plugin API has only been tested on Linux.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D106137
Define an API for, and implement, runtime support for arbitrary
assignment of one descriptor's data to another, with full support for
(re)allocation of allocatables with finalization when necessary,
user-defined derived type assignment TBP calls, and intrinsic (default)
componentwise assignment of derived type instances with allocation of
automatic components. Also clean up API and implementation of
finalization/destruction using knowledge gained while studying
edge cases for assignment in the 2018 standard.
The look-up procedure for special procedure bindings in derived
types has been optimized from O(N) to O(1) since it will probably
matter more. This required some analysis in runtime derived type
description table construction in semantics and some changes to the
table schemata.
Executable Fortran tests have been developed; they'll be added
to the test base once they can be lowered and run by f18.
Differential Revision: https://reviews.llvm.org/D107678
This patch removes `f18`, a.k.a. the old driver. It is being replaced
with the new driver, `flang-new`, which has reached feature parity with
`f18` a while ago. This was discussed in [1] and also in [2].
With this change, `FLANG_BUILD_NEW_DRIVER` is no longer needed and is
also deleted. This means that we are making the dependency on Clang permanent
(i.e. it cannot be disabled with a CMake flag).
LIT set-up is updated accordingly. All references to `f18` or `f18.cpp`
are either updated or removed.
The `F18_FC` variable from the `flang` bash script is replaced with
`FLANG_FC`. The former is still supported for backwards compatibility.
[1] https://lists.llvm.org/pipermail/flang-dev/2021-June/000742.html
[2] https://reviews.llvm.org/D103177
Differential Revision: https://reviews.llvm.org/D105811
Dummy procedures can be defined as subprograms with explicit
interfaces, e.g.
subroutine subr(dummy)
interface
subroutine dummy(x)
real :: x
end subroutine
end interface
! ...
end subroutine
but the symbol table had no means of marking such symbols as dummy
arguments, so predicates like IsDummy(dummy) would fail. Add an
isDummy_ flag to SubprogramNameDetails, analogous to the corresponding
flag in EntityDetails, and set/test it as needed.
Differential Revision: https://reviews.llvm.org/D106697
Rename the current -E option to "-E -Xflang -fno-reformat".
Add a new Parsing::EmitPreprocessedSource() routine to convert the
cooked character stream output of the prescanner back to something
more closely resembling output from a traditional preprocessor;
call this new routine when -E appears.
The new -E output is suitable for use as fixed form Fortran source to
compilation by (one hopes) any Fortran compiler. If the original
top-level source file had been free form source, the output will be
suitable for use as free form source as well; otherwise there may be
diagnostics about missing spaces if they were indeed absent in the
original fixed form source.
Unless the -P option appears, #line directives are interspersed
with the output (but be advised, f18 will ignore these if presented
with them in a later compilation).
An effort has been made to preserve original alphabetic character case
and source indentation.
Add -P and -fno-reformat to the new drivers.
Tweak test options to avoid confusion with prior -E output; use
-fno-reformat where needed, but prefer to keep -E, sometimes
in concert with -P, on most, updating expected results accordingly.
Differential Revision: https://reviews.llvm.org/D106727
According to C7109, "A boz-literal-constant shall appear only as a
data-stmt-constant in a DATA statement, or where explicitly allowed in
16.9 as an actual argument of an intrinsic procedure." This change
enforces that constraint for output list items.
I also added a general interface to determine if an expression is a BOZ
literal constant and changed all of the places I could find where it
could be used.
I also added a test.
This change stemmed from the following issue --
https://gitlab-master.nvidia.com/fortran/f18-stage/issues/108
Differential Revision: https://reviews.llvm.org/D106893
Use derived type information tables to drive default component
initialization (when needed), component destruction, and calls to
final subroutines. Perform these operations automatically for
ALLOCATE()/DEALLOCATE() APIs for allocatables, automatics, and
pointers. Add APIs for use in lowering to perform these operations
for non-allocatable/automatic non-pointer variables.
Data pointer component initialization supports arbitrary constant
designators, a F'2008 feature, which may be a first for Fortran
implementations.
Differential Revision: https://reviews.llvm.org/D106297
With derived type description tables now available to the
runtime library, it is possible to implement the concept
of "child" I/O statements in the runtime and use them to
convert instances of derived type I/O data transfers into
calls to user-defined subroutines when they have been specified
for a type. (See Fortran 2018, subclauses 12.6.4.8 & 13.7.6).
- Support formatted, list-directed, and NAMELIST
transfers to internal parent units; support these, and unformatted
transfers, for external parent units.
- Support nested child defined derived type I/O.
- Parse DT'foo'(v-list) FORMAT data edit descriptors and passes
their strings &/or v-list values as arguments to the defined
formatted I/O routines.
- Fix problems with this feature encountered in semantics and
FORMAT valiation during development and end-to-end testing.
- Convert typeInfo::SpecialBinding from a struct to a class
after adding a member function.
Differential Revision: https://reviews.llvm.org/D104930
A recent change that extended semantic analysis for actual arguments
that associate with procedure dummy arguments exposed some bugs in
regression test suites due to points of confusion in symbol table
handling in situations where a generic interface contains a specific
procedure of the same name. When passing that name as an actual
argument, for example, it's necessary to take this possibility into
account because the symbol for the generic interface shadows the
symbol of the same name for the specific procedure, which is
what needs to be checked. So add a small utility that bypasses
the symbol for a generic interface in this case, and use it
where needed.
Differential Revision: https://reviews.llvm.org/D104929
This patch adds a new option for the new Flang driver:
`-fno-analyzed-objects-for-unparse`. The semantics are similar to
`-funparse-typed-exprs-to-f18-fc` from `f18`. For consistency, the
latter is replaced with `-fno-analyzed-objects-for-unparse`.
The new option controls the behaviour of the unparser (i.e. the action
corresponding to `-fdebug-unparse`). The default behaviour is to use the
analyzed objects when unparsing. The new flag can be used to turn this
off, so that the original parse-tree objects are used. The analyzed
objects are generated during the semantic checks [1].
This patch also updates the semantics of
`-fno-analyzed-objects-for-unparse`/`-funparse-typed-exprs-to-f18-fc`
in `f18`, so that this flag is always taken into account when `Unparse`
is used (this way the semantics in `f18` and `flang-new` are identical).
The added test file is based on example from Peter Steinfeld.
[1]
https://github.com/llvm/llvm-project/blob/main/flang/docs/Semantics.md
Differential Revision: https://reviews.llvm.org/D103612
This adjusts the workaround from D104731.
The issue lies in libstdc++'s classes, not GCC itself, and manifests
itself in the same way if building e.g. with clang while using
libstdc++ headers from GCC 7 (e.g. if building with Clang on Ubuntu 18.04,
while using the system default C++ library).
Therefore, change the condition to look for the version of libstdc++
instead of the compiler.
Differential Revision: https://reviews.llvm.org/D104779
Work around two problems with GCC 7.3.
One is its inability to implement "constexpr operator=(...) = default;"
in a class with a std::optional<> component; another is a legitimate-
looking warning about an unused variable.
Differential Revision: https://reviews.llvm.org/D104731
Refactor the recently-implemented MAXVAL/MINVAL folding so
that the parts that can be used to implement other reduction
transformational intrinsic function folding are exposed.
Use them to implement folding of IALL, IANY, IPARITY,
SUM. and PRODUCT. Replace the folding of ALL & ANY to
use the new infrastructure and become able to handle DIM=
arguments.
Differential Revision: https://reviews.llvm.org/D104562
This is *not* user-defined derived type I/O, but rather Fortran's
built-in capabilities for using derived type data in I/O lists
and NAMELIST groups.
This feature depends on having the derived type description tables
that are created by Semantics available, passed through compilation
as initialized static objects to which pointers can be targeted
in the descriptors of I/O list items and NAMELIST groups.
NAMELIST processing now handles component references on input
(e.g., "&GROUP x%component = 123 /").
The C++ perspectives of the derived type information records
were transformed into proper classes when it was necessary to add
member functions to them.
The code in Semantics that generates derived type information
was changed to emit derived type components in component order,
not alphabetic order.
Differential Revision: https://reviews.llvm.org/D104485
When a function is called in a specification expression, it must be
sufficiently defined, and cannot be a recursive call (10.1.11(5)).
The best fix for this is to change the contract for the procedure
characterization infrastructure to catch and report such errors,
and to guarantee that it does emit errors on failed characterizations.
Some call sites were adjusted to avoid cascades.
Differential Revision: https://reviews.llvm.org/D104330
Implement constant folding for the reduction transformational
intrinsic functions MAXVAL and MINVAL.
In anticipation of more folding work to follow, with (I hope)
some common infrastructure, these two have been implemented in a
new header file.
Differential Revision: https://reviews.llvm.org/D104337
Flang diverges from the llvm coding style in that it requires braces
around the bodies of if/while/etc statements, even when the body is
a single statement.
This commit adds the readability-braces-around-statements check to
flang's clang-tidy config file. Hopefully the premerge bots will pick it
up and report violations in Phabricator.
We also explicitly disable the check in the directories corresponding to
the Lower and Optimizer libraries, which rely heavily on mlir and llvm
and therefore follow their coding style. Likewise for the tools
directory.
We also fix any outstanding violations in the runtime and in
lib/Semantics.
Differential Revision: https://reviews.llvm.org/D104100
The new option will run the semantic checks and then dump the parse tree
and all the symbols. This is equivalent to running the driver twice,
once with `-fdebug-dump-parse-tree` and then with
the `-fdebug-dump-symbols` action flag.
Currently we wouldn't be able to achieve the same by simply running:
```
flang-new -fc1 -fdebug-dump-parse-tree -fdebug-dump-symbols <input-file>
```
That's because the new driver will only run one frontend action per
invocation (both of the flags used here are action flags). Diverging
from this design would lead to costly compromises and it's best avoided.
We may want to consider re-designing our debugging actions (and action
options) in the future so that there's more code re-use. For now, I'm
focusing on making sure that we support all the major cases requested by
our users.
Differential Revision: https://reviews.llvm.org/D104305
This patch adds the 4th Fortran specific semantic check for the OpenMP
allocate directive: "If a list item has the SAVE attribute, is a common
block name, or is declared in the scope of a module, then only predefined
memory allocator parameters can be used in the allocator clause".
Code in this patch was based on code from https://reviews.llvm.org/D93549/new/.
Differential Revision: https://reviews.llvm.org/D102400
Revision https://reviews.llvm.org/D104190 renamed MemRefDataFlow -> AffineScalarReplacement. After this rename, mlir failed to build. With this change, all of clang, mlir, and flang build and test correctly.
Differential Revision: https://reviews.llvm.org/D104223
In the interests of disabling misc-no-recursion across LLVM (this seems
like a stylistic choice that is not consistent with LLVM's
style/development approach) this NFC preliminary change adjusts all the
.clang-tidy files to inherit from their parents as much as possible.
This change specifically preserves all the quirks of the current configs
in order to make it easier to review as NFC.
I validatad the change is NFC as follows:
for X in `cat ../files.txt`;
do
mkdir -p ../tmp/$(dirname $X)
touch $(dirname $X)/blaikie.cpp
clang-tidy -dump-config $(dirname $X)/blaikie.cpp > ../tmp/$(dirname $X)/after
rm $(dirname $X)/blaikie.cpp
done
(similarly for the "before" state, without this patch applied)
for X in `cat ../files.txt`;
do
echo $X
diff \
../tmp/$(dirname $X)/before \
<(cat ../tmp/$(dirname $X)/after \
| sed -e "s/,readability-identifier-naming\(.*\),-readability-identifier-naming/\1/" \
| sed -e "s/,-llvm-include-order\(.*\),llvm-include-order/\1/" \
| sed -e "s/,-misc-no-recursion\(.*\),misc-no-recursion/\1/" \
| sed -e "s/,-clang-diagnostic-\*\(.*\),clang-diagnostic-\*/\1/")
done
(using sed to strip some add/remove pairs to reduce the diff and make it easier to read)
The resulting report is:
.clang-tidy
clang/.clang-tidy
2c2
< Checks: 'clang-diagnostic-*,clang-analyzer-*,-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes,-readability-identifier-naming,-misc-no-recursion'
---
> Checks: 'clang-diagnostic-*,clang-analyzer-*,-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes,-misc-no-recursion'
compiler-rt/.clang-tidy
2c2
< Checks: 'clang-diagnostic-*,clang-analyzer-*,-*,clang-diagnostic-*,llvm-*,-llvm-header-guard,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes'
---
> Checks: 'clang-diagnostic-*,clang-analyzer-*,-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes,-llvm-header-guard'
flang/.clang-tidy
2c2
< Checks: 'clang-diagnostic-*,clang-analyzer-*,-*,llvm-*,-llvm-include-order,misc-*,-misc-no-recursion,-misc-unused-parameters,-misc-non-private-member-variables-in-classes'
---
> Checks: 'clang-diagnostic-*,clang-analyzer-*,-*,llvm-*,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes,-llvm-include-order,-misc-no-recursion'
flang/include/flang/Lower/.clang-tidy
flang/include/flang/Optimizer/.clang-tidy
flang/lib/Lower/.clang-tidy
flang/lib/Optimizer/.clang-tidy
lld/.clang-tidy
lldb/.clang-tidy
llvm/tools/split-file/.clang-tidy
mlir/.clang-tidy
The `clang/.clang-tidy` change is a no-op, disabling an option that was never enabled.
The compiler-rt and flang changes are no-op reorderings of the same flags.
(side note, the .clang-tidy file in parallel-libs is broken and crashes
clang-tidy because it uses "lowerCase" as the style instead of "lower_case" -
so I'll deal with that separately)
Differential Revision: https://reviews.llvm.org/D103842
Adding the `-init-only` option and corresponding frontend action to
generate a diagnostic.
`-init-only` vs `-test-io`:
`-init-only` ignores the input (it never calls the prescanner)
`-test-io` is similar to `-init-only`, but does read and print the input
without calling the prescanner.
This patch also adds a Driver test to check this action.
Reviewed By: awarzynski, AMDChirag
Differential Revision: https://reviews.llvm.org/D102849
It's possible to specify refer to an undefined derived type as the type of a
component of another derived type and then never define the type of the
component. We were not detecting this situation. To fix this, I
changed the value of isForwardReferenced_ in the symbol's
DerivedTypeDetails and checked for it when performing other derived type
checks.
I also had to record the fact that error messages were previously
emitted for the same problem in some cases so that I could avoid
duplicate messages.
I also added a test.
Differential Revision: https://reviews.llvm.org/D103714
To ensure that errors are emitted by CheckConformance and
its callers in all situations, it's necessary for the returned result
of that function to distinguish between three possible
outcomes: the arrays are known to conform at compilation time,
the arrays are known to not conform (and a message has been
produced), and an indeterminate result in which is not possible
to determine conformance. So convert CheckConformance's
result into an optional<bool>, and convert its confusing
Boolean flag arguments into a bit-set of named flags too.
Differential Revision: https://reviews.llvm.org/D103654
This option is supported in `f18`, but not yet available in `flang-new`.
It is required in order to call `flang-new` from the `flang` bash
script.
Differential Revision: https://reviews.llvm.org/D103613
In something like "ASSOCIATE(X=>T(1))", the "T(1)" is parsed
as a Variable because it looks like a function reference or
array reference; if it turns out to be a structure constructor,
which is something we can't know until we're able to attempt
generic interface resolution in semantics, the parse tree needs
to be fixed up by replacing the Variable with an Expr.
The compiler could already do this for putative function references
encapsulated as Exprs, so this patch moves some code around and
adds parser::Selector to the overloads of expression analysis.
Differential Revision: https://reviews.llvm.org/D103572
The constexpr-capable class evaluate::DynamicType represented
CHARACTER length only with a nullable pointer into the declared
parameters of types in the symbol table, which works fine for
anything with a declaration but turns out to not suffice to
describe the results of the ACHAR() and CHAR() intrinsic
functions. So extend DynamicType to also accommodate known
constant CHARACTER lengths, too; use them for ACHAR & CHAR;
clean up several use sites and fix regressions found in test.
Differential Revision: https://reviews.llvm.org/D103571
As a benign extension common to other Fortran compilers,
accept BOZ literals in array constructors w/o explicit
types, treating them as integers.
Differential Revision: https://reviews.llvm.org/D103569
In error recovery situations, the mappings from source locations
to scopes were failing in a way that tripped some asserts.
Specifically, FindPureProcedureContaining() wasn't coping well
when starting at the global scope. (And since the global scope
no longer has a source range, clean up the Semantics constructor
to avoid confusion.)
Differential Revision: https://reviews.llvm.org/D103567
This patch adds the following Fortran specific semantic checks for the OpenMP
Allocate directive.
1) A type parameter inquiry cannot appear in an ALLOCATE directive.
2) List items specified in the ALLOCATE directive must not have the ALLOCATABLE
attribute unless the directive is associated with an ALLOCATE statement.
Co-authored-by: Irina Dobrescu <irina.dobrescu@arm.com>
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D102061
- Replace class(*) member by a c_ptr member to avoid having to handle
polymorphic components in the type info table generation. Polymorphic
entity handling will require these very tables to be lowered properly.
Note: keep the init as NullPointer/Designators. This is technically
invalid Fortran, the init should have c_ptr type. But wrapping this
in a C_LOC intrinsic call would make runtime generation and lowering
more complex with no real benefits.
- ComponentIterator is crashing when used on the generated derived
types in GetScope. This patch makes GetScope more robust, but it
is not entirely clear to me why this is only happening with the
generated derived types.
- The type of generated character globals was incorrect because
Scope::FindType was matching character types with different
length. Add a CharacterTypeSpec == operator to fix this.
Differential Revision: https://reviews.llvm.org/D102768
