#
d732c86c |
| 27-Jan-2025 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Don't take corank from actual intrinsic argument (#124029)
When constructing the characteristics of a particular reference to an
intrinsic procedure that was passed a non-coindexed referenc
[flang] Don't take corank from actual intrinsic argument (#124029)
When constructing the characteristics of a particular reference to an
intrinsic procedure that was passed a non-coindexed reference to local
coarray data as an actual argument, don't add the corank of the actual
argument to those characteristics.
Also clean up the TypeAndShape characteristics class a little; the
Attr::Coarray is redundant since the corank() accessor can be used to
the same effect.
show more ...
|
#
1e9b60cf |
| 27-Jan-2025 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Recognize and check EVENT_QUERY (#123429)
Recognize the intrinsic subroutine EVENT_QUERY and enforce semantic
requirements on calls to it.
|
#
b0fab14e |
| 27-Jan-2025 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Fix spurious error in character sequence association (#124204)
When an allocatable or pointer was being associated as a storage
sequence with a dummy argument, the checks were using the act
[flang] Fix spurious error in character sequence association (#124204)
When an allocatable or pointer was being associated as a storage
sequence with a dummy argument, the checks were using the actual storage
size of the allocatable or pointer's descriptor, not the size of the
storage that it references.
Fixes https://github.com/llvm/llvm-project/issues/123807.
show more ...
|
#
b16c9896 |
| 27-Jan-2025 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Fix check for coarray actual passed to implicit interface (#123836)
The check for a coarray actual argument being passed to a procedure with
an implicit interface was incorrect, yielding fa
[flang] Fix check for coarray actual passed to implicit interface (#123836)
The check for a coarray actual argument being passed to a procedure with
an implicit interface was incorrect, yielding false positives for
coindexed objects. Fix.
show more ...
|
#
3a8a52f4 |
| 08-Jan-2025 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Make IsCoarray() more accurate (#121415)
A designator without cosubscripts can have subscripts, component
references, substrings, &c. and still have corank. The current
IsCoarray() predica
[flang] Make IsCoarray() more accurate (#121415)
A designator without cosubscripts can have subscripts, component
references, substrings, &c. and still have corank. The current
IsCoarray() predicate only seems to work for whole variable/component
references. This was breaking some cases of THIS_IMAGE().
show more ...
|
#
510285cd |
| 08-Jan-2025 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Fix allocatable coarray INTENT(OUT) check (#121528)
An allocatable coarray being argument associated with a non-allocatable
INTENT(OUT) dummy argument is not an error.
|
#
07b3bba9 |
| 08-Jan-2025 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Allow LOCK_TYPE & al. to associate with INTENT(IN OUT) (#121413)
We're emitting a bogus semantic error message about an actual argument
being undefinable when associating LOCK_TYPE, EVENT_T
[flang] Allow LOCK_TYPE & al. to associate with INTENT(IN OUT) (#121413)
We're emitting a bogus semantic error message about an actual argument
being undefinable when associating LOCK_TYPE, EVENT_TYPE, and someday
NOTIFY_TYPE with an INTENT(IN OUT) dummy argument. These types indeed
make many definition contexts invalid, and the actual argument
associated with an INTENT(IN OUT) dummy argument must indeed be
definable, but the argument association itself is not a problem.
show more ...
|
#
aa68dd57 |
| 14-Nov-2024 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Disable extension by default (#114875)
f18 allows, as an extension, an assumed-rank array to be associated with
a dummy argument that is not assumed-rank. This usage is non-conforming
and
[flang] Disable extension by default (#114875)
f18 allows, as an extension, an assumed-rank array to be associated with
a dummy argument that is not assumed-rank. This usage is non-conforming
and supported by only one other compiler, perhaps unintentionally.
Disable the extension by default, but also make it controllable so that
we can turn it back on later if it's really needed. (If it turns out to
not appear in applications after more exposure, I'll remove it
entirely.)
Fixes https://github.com/llvm/llvm-project/issues/114080.
show more ...
|
#
30d80009 |
| 07-Nov-2024 |
Valentin Clement (バレンタイン クレメン) <clementval@gmail.com> |
[flang][cuda] Allow SHARED actual to DEVICE dummy (#115215)
Update the compatibility rules to allow SHARED actual argument passed to
DEVICE dummy argument. Emit a warning in that case.
|
#
70cbedcd |
| 07-Oct-2024 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Catch errors with INTENT(OUT) assumed rank dummy arguments (#111204)
Emit an error when an actual argument with potentially unknown size
(assumed size, or non-pointer non-allocatable assume
[flang] Catch errors with INTENT(OUT) assumed rank dummy arguments (#111204)
Emit an error when an actual argument with potentially unknown size
(assumed size, or non-pointer non-allocatable assumed rank) with any
risk of needing initialization, finalization, or destruction is
associated with an INTENT(OUT) dummy argument with assumed rank.
Emit an optional portability warning for cases where the type is known
to be safe from needing initialization, finalization, or destruction,
since it's not conforming and might elicit an error from other
compilers.
Fixes https://github.com/llvm/llvm-project/issues/111120.
show more ...
|
#
8882d591 |
| 07-Oct-2024 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Fix typo in warning message text (#110888)
I accidentally deleted a space character; put it back.
|
#
0f973ac7 |
| 02-Oct-2024 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Tag warnings with LanguageFeature or UsageWarning (#110304)
(This is a big patch, but it's nearly an NFC. No test results have
changed and all Fortran tests in the LLVM test suites work as
[flang] Tag warnings with LanguageFeature or UsageWarning (#110304)
(This is a big patch, but it's nearly an NFC. No test results have
changed and all Fortran tests in the LLVM test suites work as expected.)
Allow a parser::Message for a warning to be marked with the
common::LanguageFeature or common::UsageWarning that controls it. This
will allow a later patch to add hooks whereby a driver will be able to
decorate warning messages with the names of its options that enable each
particular warning, and to add hooks whereby a driver can map those
enumerators by name to command-line options that enable/disable the
language feature and enable/disable the messages.
The default settings in the constructor for LanguageFeatureControl were
moved from its header file into its C++ source file.
Hooks for a driver to use to map the name of a feature or warning to its
enumerator were also added.
To simplify the tagging of warnings with their corresponding language
feature or usage warning, to ensure that they are properly controlled by
ShouldWarn(), and to ensure that warnings never issue at code sites in
module files, two new Warn() member function templates were added to
SemanticsContext and other contextual frameworks. Warn() can't be used
before source locations can be mapped to scopes, but the bulk of
existing code blocks testing ShouldWarn() and FindModuleFile() before
calling Say() were convertible into calls to Warn(). The ones that were
not convertible were extended with explicit calls to
Message::set_languageFeature() and set_usageWarning().
show more ...
|
#
856c38d5 |
| 02-Oct-2024 |
David Truby <david.truby@arm.com> |
[flang] Implement GETUID and GETGID intrinsics (#110679)
GETUID and GETGID are non-standard intrinsics supported by a number of
other Fortran compilers. On supported platforms these intrinsics simp
[flang] Implement GETUID and GETGID intrinsics (#110679)
GETUID and GETGID are non-standard intrinsics supported by a number of
other Fortran compilers. On supported platforms these intrinsics simply
call the POSIX getuid() and getgid() functions and return the result.
The only platform we support that does not have these is Windows.
Windows does not have the same concept of UIDs and GIDs, so on Windows
we issue a warning indicating this and return 1 from both functions.
Co-authored-by: Yi Wu <yi.wu2@arm.com>
show more ...
|
#
78ccffc0 |
| 30-Sep-2024 |
David Truby <david.truby@arm.com> |
[flang] Add MALLOC and FREE intrinsics for Cray pointers (#110018)
MALLOC and FREE are extensions provided by gfortran, Intel Fortran and
classic flang to allocate memory for Cray pointers. These a
[flang] Add MALLOC and FREE intrinsics for Cray pointers (#110018)
MALLOC and FREE are extensions provided by gfortran, Intel Fortran and
classic flang to allocate memory for Cray pointers. These are used in
some legacy codes such as libexodus.
All the above compilers accept using MALLOC and FREE with integers as
well, despite that this will often signify a bug in user code. We should
accept the same as the other compilers for compatibility.
show more ...
|
#
7a0a7947 |
| 30-Sep-2024 |
David Truby <david.truby@arm.com> |
Revert "[flang] Implement GETUID and GETGID intrinsics" (#110531)
Reverts llvm/llvm-project#108017
|
#
054eadcb |
| 30-Sep-2024 |
David Truby <david.truby@arm.com> |
[flang] Implement GETUID and GETGID intrinsics (#108017)
GETUID and GETGID are non-standard intrinsics supported by a number of
other Fortran compilers. On supported platforms these intrinsics simp
[flang] Implement GETUID and GETGID intrinsics (#108017)
GETUID and GETGID are non-standard intrinsics supported by a number of
other Fortran compilers. On supported platforms these intrinsics simply
call the POSIX getuid() and getgid() functions and return the result.
The only platform we support that does not have these is Windows.
Windows does not have the same concept of UIDs and GIDs, so on Windows
we issue a warning indicating this and return 1 from both functions.
Co-authored-by: Yi Wu <yi.wu2@arm.com>
---------
Co-authored-by: Yi Wu <yi.wu2@arm.com>
show more ...
|
#
1595ca43 |
| 12-Sep-2024 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Catch whole assumed-size array passed to elemental (#108239)
A whole assumed-size array is not a valid argument to an elemental
procedure (intrinsic or otherwise).
|
#
b52728d8 |
| 26-Aug-2024 |
Peter Klausler <35819229+klausler@users.noreply.github.com> |
[flang] Silence warning when inappropriate (#105867)
When a function returns an array, using an element of that array is an
actual argument in a procedure reference with an implicit interface
shou
[flang] Silence warning when inappropriate (#105867)
When a function returns an array, using an element of that array is an
actual argument in a procedure reference with an implicit interface
should suffice to avoid a warning about an undefined function result.
show more ...
|
#
062e69a6 |
| 15-Aug-2024 |
Leandro Lupori <leandro.lupori@linaro.org> |
[flang][OpenMP] Fix 2 more regressions after #101009 (#101538)
PR #101009 exposed a semantic check issue with OPTIONAL dummy
arguments.
Another issue occurred when using %{re,im,len,kind}, as thes
[flang][OpenMP] Fix 2 more regressions after #101009 (#101538)
PR #101009 exposed a semantic check issue with OPTIONAL dummy
arguments.
Another issue occurred when using %{re,im,len,kind}, as these also
need to be skipped when handling variables with implicitly defined
DSAs.
These issues were found by Fujitsu testsuite.
show more ...
|
#
33c27f28 |
| 30-Jul-2024 |
Peter Klausler <35819229+klausler@users.noreply.github.com> |
[flang] Warn about undefined function results (#99533)
When the result of a function never appears in a variable definition
context, emit a warning.
If the function has multiple result variables
[flang] Warn about undefined function results (#99533)
When the result of a function never appears in a variable definition
context, emit a warning.
If the function has multiple result variables due to alternate ENTRY
statements, any definition will suffice.
The implementation of this check is tied to the general variable
definability checking utility in semantics. Every variable definition
context uses it to ensure that no undefinable variable is being defined.
A set of defined variables is maintained in the SemanticsContext and,
when the warning is enabled and no fatal error has been reported, the
scope tree is traversed and all the function subprograms' results are
tested for membership in that set.
show more ...
|
#
d5285fef |
| 11-Jul-2024 |
Peter Klausler <35819229+klausler@users.noreply.github.com> |
[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
[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.
show more ...
|
#
9ab292d7 |
| 24-Jun-2024 |
Peter Klausler <35819229+klausler@users.noreply.github.com> |
[flang] Add/fix some semantic checks for assumed-rank (#96194)
Catch some cases where assumed rank dummy arguments are not allowed.
|
#
73cf0142 |
| 24-Jun-2024 |
jeanPerier <jperier@nvidia.com> |
[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::s
[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>`.
show more ...
|
#
6ac5047a |
| 04-Jun-2024 |
Leandro Lupori <leandro.lupori@linaro.org> |
[flang] Escape '%' in %VAL/%REF messages (#94331)
flang/test/Semantics/call40.f90 was failing on Darwin:
actual at 27: VAL or REF are not allowed for dummy argument 'a='
that must be passed by m
[flang] Escape '%' in %VAL/%REF messages (#94331)
flang/test/Semantics/call40.f90 was failing on Darwin:
actual at 27: VAL or REF are not allowed for dummy argument 'a='
that must be passed by means of a descriptor
expect at 27: %VAL or %REF are not allowed for dummy argument 'a='
that must be passed by means of a descriptor
When messages.Say() is called with more arguments than just the
fixed text message, the message is treated as a format string,
passed to vsnprintf. Therefore, the '%' chars in it must be
escaped.
Note that no conversion happens when there is only a fixed text
message. Escaping '%' in this case causes "%%" to be outputted.
This can be confusing for someone expecting printf-like behavior.
Processing these text messages with snprintf could solve this,
as a future improvement.
show more ...
|
#
858a79eb |
| 04-Jun-2024 |
jeanPerier <jperier@nvidia.com> |
[flang] relax ASSOCIATED checks for assumed-ranks (#94277)
Nothing in the standard actually prevents TARGET from being an
assumed-rank if the POINTER is. The only rank related constraints says:
"P
[flang] relax ASSOCIATED checks for assumed-ranks (#94277)
Nothing in the standard actually prevents TARGET from being an
assumed-rank if the POINTER is. The only rank related constraints says:
"POINTER is not assumed-rank, TARGET shall have the same rank as
POINTER.".
show more ...
|