Update the folder titles for targets in the monorepository that have not
seen taken care of for some time. These are the folders that targets are
organized in Visual Studio and XCode (`set_property(TARGET <target>
PROPERTY FOLDER "<title>")`) when using the respective CMake's IDE
generator.
* Ensure that every target is in a folder
* Use a folder hierarchy with each LLVM subproject as a top-level folder
* Use consistent folder names between subprojects
* When using target-creating functions from AddLLVM.cmake, automatically
deduce the folder. This reduces the number of
`set_property`/`set_target_property`, but are still necessary when
`add_custom_target`, `add_executable`, `add_library`, etc. are used. A
LLVM_SUBPROJECT_TITLE definition is used for that in each subproject's
root CMakeLists.txt.
https://github.com/llvm/llvm-project/pull/93106 introduced some
necessary fixes to module file generation, but has also caused a
regression. The module file output can include bogus attempts to
USE-associate symbols local to derived type scopes, like components and
bindings. Fix, and extend a test.
Remove this test since it is marked as XFAIL and has some
non-deterministic behaviour which causes it to spuriously pass on
out-of-tree builds.
Capturing this in https://github.com/llvm/llvm-project/issues/93342 to
make a proper fix and a test later.
A NULL(without MOLD=) actual argument can be associated with an OPTIONAL
assumed-rank non-allocatable non-pointer dummy argument; it simply
signifies that the corresponding actual argument is absent, and thus
none of its dynamic attributes, including rank, are meaningful.
This PR adds the type conversion support for fixed size arrays. Mostly
mechanical changes converting dimension values to subrange fields. A
limitation is that lower bound is always one for the moment as that
information is missing in `SequenceType`.
With this change in place, I can evaluate fixed size arrays in debugger.
```
(gdb) p x
$1 = ((2, 3, 4, 5) (3, 4, 5, 6) (4, 5, 6, 7) (5, 6, 7, 8) (6, 7, 8, 9))
(gdb) ptype x
type = integer (4,5)
```
---------
Co-authored-by: Tom Eccles <t@freedommail.info>
… with monomorphic dummy
The relevant standard requires (F'2023 15.5.2.6 p2) that when a pointer
or allocatable actual argument is associated with an
identically-attributed dummy argument, either both are polymorphic or
neither is. We already relax this requirement in the case of an
INTENT(IN) dummy argument, since a change of type cannot occur. Further,
like other compilers do, we can also relax this requirement in the case
of a limited polymorphic actual argument being associated with a
monomorphic dummy, as our implementation always passes a reference to
the actual descriptor, where any change of type that occurs during the
call due to reallocation will be properly recorded.
Two checks related to BIND(C) vs non-BIND(C) entry points with the same
dummy argument added by https://github.com/llvm/llvm-project/pull/92474
have turned out to be unnecessary. Revert them and adjust the tests.
When a symbol from one module is used in another without an explicit USE
association, the module file output code may need to use another name
for it -- either with a name that is already available via USE
association with renaming, or by means of a new private USE association,
possibly with renaming to avoid a clash.
Module file output was dealing properly with names of derived types, but
wasn't accounting for symbols that appear in expressions other than
initializations. This was specifically a problem with an application
module that had a call to a NOPASS type-bound procedure in an array
bound specification expression, which semantics had resolved to the name
of a private module function.
This patch implements renaming, when necessary, for all symbols
appearing in expressions and type names, and replaces the previous
implementation of derived type renaming. It also gets a little smarter
about avoiding the creation of compiler-generated names when a name from
another module has been brought into scope already by means of USE
association with renaming.
The type of "[lo:hi:str]" is being forced to INTEGER(8), ignoring the
types of the operands to the triplet. The type of a triplet should be
whatever the type of "lo+hi+str" would be.
(Array constructor triplets are a syntactic sugar extension for an
implied DO loop.)
Shape analysis for the results of SHAPE, LBOUND, and UBOUND (without
DIM=) needs to account for an assumed-rank dummy argument, and return a
shape vector with a single unknown element.
I modified declaration checking for interoperable objects to buffer its
generated messages as I had previously done for derived types and
procedure interfaces, but failed to modify all of the message creation
statements to use the new buffer, so some are now escaping when a module
file is being compiled. Fix to ensure that the new buffer is always
used.
When reading variable-length unformatted records, the external I/O
library frames the input buffer so that the footer of the previous
record remains in frame. This is done so that a BACKSPACE doesn't have
to do an extra read to get the length of the previous record before
repositioning over it.
When switching from input to output to overwrite or append new records
after reading any, it is necessary to undo this framing of the last word
in the previous record, since the new output isn't going to define it in
the buffer and it'll be overwritten in the filesystem with garbage.
A type-bound procedure that's bound to a name that isn't a procedure is
caught as an error, but can also lead to a crash in compatibility
checking later. Make that code more robust to failure.
Fixes https://github.com/llvm/llvm-project/issues/92678.
When a symbol appears in a specification expression in a subprogram
contained in a host program unit, semantics may have to create a symbol
in the host and use host association to it. This shouldn't happen for
nested subprograms that can't import such a symbol, such as interface
blocks by default. Further, when host association fails, semantics
shouldn't crash.
Fixes https://github.com/llvm/llvm-project/issues/92647.
EQUIVALENCE set processing assumes that any arrays have explicit shape
and constant lower bounds. When an erroneous program violates those
assumptions, the compiler crashes. Fix.
Fixes https://github.com/llvm/llvm-project/issues/92636.
This helps reducing the compilation time spent by the device
compiler optimizer and then the code generator. Since F18 RT
is going to be distributed as LLVM BC for some targets
(same way as LLVM liboffload device library is distributed)
and linked to the user offload code, the compilation time
of the produced LLVM BC will be critical.
This tries to fix all of the places where a diagnostic message starts
with a capital letter (other than acroynyms or proper nouns) or ends
with punctuation (other than a question mark).
This is in support of a planned change to tablegen to start diagnosing
incorrect diagnostic message styles.
This PR adds supports for conversion of complex type to corresponding
DITypeAttr. Both fir and mlir types are supported.
Apart from lit testing, I have also tested the types in debugger and
they work correctly. An exception is 128 bit complex which somehow
requires that its name be different from `complex`. I am going to open a
separate PR to add (kind=n) in the type names similar to what gfortran
does.
The pass constructor can be generated automatically.
This pass is module-level and then runs on all relevant intrinsic
operations inside of the module, no matter what top level operation they
are inside of.
Named location attribute added to `tgt_offload_entry` shall be used by
runtime calls like `ompx_dump_mapping_tables` to print the information
of variables that are mapped to the device. `ompx_dump_mapping_tables`
was printing the wrong location information and this change fixes it.
A sample execution of example before the change:
```
omptarget device 0 info: OpenMP Host-Device pointer mappings after block at libomptarget:0:0:
omptarget device 0 info: Host Ptr Target Ptr Size (B) DynRefCount HoldRefCount Declaration
omptarget device 0 info: 0x0000000000206df0 0x00007f02cdc00000 20000000 1 0 <program-file-loc> at unknown:18:35
```
The change replaces unknown to the mapped symbol and location to the
declaration location.
Runtime support has been added in
https://github.com/llvm/llvm-project/pull/89691. This patch adds
lowering in a similar way than `selected_int_kind`, `selected_real_kind`
and `selected_logical_kind` added in #93091.
Some gfortran tests can be enabled after this patch is landed.
- `Fortran/gfortran/regression/selected_char_kind_1.f90`
- `Fortran/gfortran/regression/selected_char_kind_4.f90`
Remove an extra '-D' in the call to add_compile_definitions. The extra
-D causes -D-DFLANG_RUNTIME_F128_MATH_LIB=libquadmath to appear in
compile options which results in a compilation failure. This occurs only
on systems using cmake versions 3.22.1 or 3.24.3. Using cmake 3.28.1
seems to automatically remove the duplicate -D.
Fixes https://github.com/llvm/llvm-project/pull/81971
`SelectCaseOp::getCompareOperands` may return an empty range for the
"default" case. Do not dereference the range until it is expected to be
non-empty.
This was detected by address-sanitizer.
This pass is module-level and then runs on all operations implementing
the ordered assignment interface. It should not matter which top-level
operation the assignment is inside of.
This commit removes some unnecessary boilerplate that we can generate
automatically with tablegen.
This means that this pass will also run on hlfir elemental operations
which are not inside of functions.
See RFC:
https://discourse.llvm.org/t/rfc-add-an-interface-for-top-level-container-operations
Some of the changes are from moving the declaration and definition of
the constructor into tablegen (as requested during code review of
another pass).
This PR add debug info for module variables. The module variables are
added as global variables but their scope is set to module instead of
compile unit. The scope of function declared inside a module is also set
accordingly.
After this patch, a module variable could be evaluated in the GDB as `p
helper::gli` where helper is name of the module and gli is the name of
the variable. A future patch will add the import module functionality
which will remove the need to prefix the name with helper::.
The line number where is module is declared is a best guess at the
moment as this information is not part of the GlobalOp.
Assignment of a constant (host) to a device variable is a special case
that can be further lowered to `cudaMemset` or similar functions. This
patch update the lowering to avoid the creation of a temporary when we
assign a constant to a device variable.
The memory side effects on the `cuf.data_transfer` operation were
swapped between the src and dst operands. We read from source and write
to destination not the opposite.
When lowering IfConstruct, CaseConstruct, and SelectTypeConstruct, emit
branches that exit the construct in each block that is still
unterminated after the FIR has been generated in it.
The same thing may be needed for SelectRankConstruct, once it's
supported.
This eliminates the need for inserting branches in `genFIR(Evaluation)`.
Follow-up to PR https://github.com/llvm/llvm-project/pull/91614.
This means that this pass will also run on hlfir elemental operations
which are not inside of functions.
See RFC:
https://discourse.llvm.org/t/rfc-add-an-interface-for-top-level-container-operations
Some of the changes are from moving the declaration and definition of
the constructor into tablegen (as requested during code review of
another pass).
While I was updating the tests I noticed that the optimized
bufferization pass and some cse were missing from the optimized pipeline
in flang/test/Driver/mlir-pass-pipeline.f90. I fixed this in this
commit.
omp masked directive in OpenMP 5.2 allows to specify code regions which
are expected to be executed by thread ids specified by the programmer.
Filter clause of the directive allows to specify the thread id. This
change adds the parsing support for the directive
