ENUMERATOR declarations are checking for conflicts between new
enumerator names and names in both the local scope and scopes
that contain it. ENUMERATOR declarations belong to the local
scope and so only a conflict with a name therein is an error.
(In short, use FindInScope rather than FindSymbol.)
Differential Revision: https://reviews.llvm.org/D142773
Test flang/test/Semantics/select-rank02.f90 has an unresolved
failure when built with MSVC on an x86 Windows buildbot, but it passes
on an Arm Windows buildbot. Change XFAIL to UNSUPPORTED to dodge
an XPASS buildbot complaint on the Arm Windows buildbot.
A test program shouldn't be able to crash the compiler by getting it to
fold REPEAT() with an absurdly large repetition count.
Differential Revision: https://reviews.llvm.org/D142770
Semantics crashes when emitting runtime derived type information tables
for a type that has user-defined I/O procedures declared outside the
type with explicit INTERFACE blocks (as opposed to a GENERIC binding
within the type). This is due to the runtime table constructor
adding a table entry for each specific procedure of any explicit interface
of the right kind (e.g., READ(UNFORMATTED)) that it found, rather than
just the ones that pertain to the derived type in question. But
semantics also wasn't checking such interfaces for distinguishable
specific procedures, either.
Clean these up, improve the spelling of defined I/O procedure kinds
in error messages ("read(formatted)" rather than "READFORMATTED"),
and make error messages stemming from macro expansions only have
one "error:" prefix on the original message so that a new test
would work.
Differential Revision: https://reviews.llvm.org/D142769
Array references like A(1) are commonly misparsed as function references,
since the parser has almost no semantic context, and the parse tree is
fixed up later by semantics once it can be disambiguated. In a case
like A(I=1), however, the presence of an argument keyword must prevent
conversion into an array reference. (It might still also be a structure
constructor.)
Differential Revision: https://reviews.llvm.org/D142765
f18 current ignores attempts to initialize (with =expr) things
that are not objects, or allows meaningless initializations of
things that have mistakenly been promoted to be objects.
Fix by refusing to promote to objects names that have any
attributes that cannot be applied to objects, and then catch
data initializations of symbols that are not objects.
Differential Revision: https://reviews.llvm.org/D142766
Semantics can catch out-of-range subscript values already when they
appear in DATA statement objects and constant folding of name constant
array indexing; this patch fills the gap by checking known constant
subscript values in other contexts.
Differential Revision: https://reviews.llvm.org/D142764
This enables conversion of OpenMP Target Data, Enter Data and Exit Data from FIR Dialect to LLVM IR Dialect.
Differential Revision: https://reviews.llvm.org/D142629
A fixed form continuation line should not be the first line of a statement;
emit a warning if it looks like one is so that the programmer can look
for a missing card.
Differential Revision: https://reviews.llvm.org/D142763
A function in a defined operator generic interface will syntactically
have one or two arguments. If a defined operator includes a specific
function with 0 or more than 2 dummy arguments, there's no way that it
could be invoked by way of the interface. Emit a warning.
Differential Revision: https://reviews.llvm.org/D142762
A dummy argument that appears only in ENTRY statements may
not be used in the executable part prior to its first ENTRY
statement.
Differential Revision: https://reviews.llvm.org/D142758
When folding the intrinsic functions CHAR and ACHAR, emit an
error message if the argument is out of the valid range for the
kind of the result.
Differential Revision: https://reviews.llvm.org/D142754
The standard's specification for the ASSOCIATED() intrinsic function
describes its optional second argument (TARGET=) as being required
to be a valid target for a pointer assignment statement in which the
first argument (POINTER=) was the left-hand side. Some Fortran compilers
apparently interpret this text as a requirement that the POINTER= argument
actually be a valid left-hand side to a pointer assignment statement,
and emit an error if it is not so. This particularly affects the
use of an explicit NULL pointer as the first argument.
Such usage is well-defined, benign, useful, and supported by at least
two other compilers, so we should continue to accept it. This patch
adds a portability warning and some documentation.
In order to implement the portability warning in the best way, the
special checks on calls to the ASSOCIATED() intrinsic function have
been moved from intrinsic processing to Semantics/check-calls.cpp,
whence they have access to semantics' toolchest. Special checks for
other intrinsic functions might also migrate in the future in order
to keep them all in one place.
Differential Revision: https://reviews.llvm.org/D142768
In free form, don't silently skip over an invalid space between
an underscore and a kind parameter.
Differential Revision: https://reviews.llvm.org/D142760
Fix a subtle bug in procedure compatibility checking with base
derived types vs. their extensions to ensure that a procedure
expecting an extended type cannot be associated with a pointer
(or dummy procedure) to a procedure expecting a base type.
subroutine s1(base); ... subroutine s2(extended)
procedure(s1), pointer :: p
p => s2 ! <- must be caught as an error
Differential Revision: https://reviews.llvm.org/D142753
A semantic constraint on assignments in PURE subprograms (C1594) applies
only to an intrinsic assignment and should not be checked in the case of
a defined assignment.
Differential Revision: https://reviews.llvm.org/D142748
A subroutine that implements a defined assignment cannot have
a dummy argument for its second operand (the RHS of the assignment)
with the POINTER or ALLOCATABLE attributes, since the RHS of
an assignment is always an expression. This problem is flagged
as a fatal error in other compilers, so let's make it fatal here
as well.
Differential Revision: https://reviews.llvm.org/D142752
More generally, don't return a successful result from
Fortran::evaluate::DynamicType::MeasureSizeInBytes() when the
type is polymorphic.
Differential Revision: https://reviews.llvm.org/D142772
This patch adds a simplfiied version of count for the simplify intrinsics pass, allowing the function to be inlined.
This was done specifically to help improve performance for exchange2, and provides a ~12% performance increase.
Reviewed By: vzakhari, Leporacanthicus
Differential Revision: https://reviews.llvm.org/D142209
The scalar must be placed in memory before creating descriptors and
calling the runtime assignment API.
Differential Revision: https://reviews.llvm.org/D142698
CheckDoConcurrentClauseRestriction and CheckTileClauseRestriction expect
that the construct has associated DoConstruct, while it is not set
when the do-loop has no loop control. The change is to skip the clauses
checks, when the do-loop does not have the loop control.
An alternative fix would be to associate the DoConstruct even when
the do-loop has no loop control and let Check*ClauseRestriction run their
checks, but I am not sure if associating invalid DoConstruct is a good idea.
This fixes failure in Semantics/OpenACC/acc-canonicalization-validity.f90
reported in D142279.
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D142652
This patch adds Fortran Lowering support for the OpenMP Target Data, Target Exit Data and Target Enter Data constructs.
operation.
Differential Revision: https://reviews.llvm.org/D142357
Currently `PassManager` defaults to being anchored on `builtin.module`.
Switching the default makes `PassManager` consistent with
`OpPassManager` and avoids the implicit dependency on `builtin.module`.
Specifying the anchor op type isn't strictly necessary when using
explicit nesting (existing pipelines will continue to work), but I've
updated most call sites to specify the anchor since it allows for better
error-checking during pipeline construction.
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D137731
Derived type default initialization was not taking the step into
consideration.
```
module dt_init
type p1
integer :: a
end type
type, extends(p1) :: p2
integer :: b = 10
end type
contains
subroutine init_dt(z)
class(p1), intent(out) :: z(:)
select type(z)
type is (p2)
print*,z
end select
end subroutine
end module
program test
use dt_init
type(p2) :: t(6) = [ p2(1,2),p2(3,4),p2(5,6),p2(7,8),p2(9,10),p2(11,12) ]
print*,t
call init_dt(t(::2))
print*,t
end program
```
Without the fix, the three first elements are initialized
```
1 2 3 4 5 6 7 8 9 10 11 12
1 10 5 10 9 10
1 10 3 10 5 10 7 8 9 10 11 12
```
Where it should be element number 1,3,5
```
1 2 3 4 5 6 7 8 9 10 11 12
1 10 5 10 9 10
1 10 3 4 5 10 7 8 9 10 11 12
```
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D142527
This ensures that functions in included files have the correct path
in their file metadata.
Note: This patch also sets all locations to have the full path names.
Reviewed By: vzakhari, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D142263
Use runtime Assign to deal with the copy (and the temporary creation, so
that this code can deal with polymorphic temps without any change).
Using Assign for the copy is desired here since the copy happens when
the data is not contiguous, and it happens inside an if/then which
makes it hard to optimize.
See 2b60ed405b
for more details (note that, contrary to this last commit, the code at
hand is only dealing with copy-in/copy-out, it is not intended to deal
with preparing VALUE arguments).
Differential Revision: https://reviews.llvm.org/D142475
These operations implement the optional copy of a non contiguous
variable into a temporary before a call, and the copy back from the
temporary after the call.
Differential Revision: https://reviews.llvm.org/D142342
`PointerAssociateRemapping` expect a descriptor holding
a newRank x 2 array of int64. The previous lowering was wrong.
Adapt the lowering to fit the expectation of the runtime.
Use the `bounds` to get the rank.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D142487
When referencing a single component from a polymorphic array in an expression,
the rebox operation should output a boxed array of that component type and
not a polymorphic boxed array as it was done.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D142462
When emboxing to a polymorphic entity without a type source box,
the type desc address must be retrived from the input type and
not from the box type.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D142435
Only updates the assert to check where the box is a BaseBoxType
instead of a BoxType since ClassType are also valid in that case.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D142442
When `ARRAY` is polymorphic, the result needs to carry over
the dynamic type information. This patch updates the lowering
to make the result polymorphic when needed.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D142432
Add free functions llvm::CodeGenOpt::{getLevel,getID,parseLevel} to
provide common implementations for functionality that has been
duplicated in many places across the codebase.
Differential Revision: https://reviews.llvm.org/D141968
Assume no conflict between pointer arrays and arrays without the target
attribute, if the fact of an array not having the target attribute
can be reliably computed.
This change speeds up SPEC CPU2017/527.cam from 2.5k seconds to 880 seconds
on Icelake, and makes further performance investigation easier.
Differential Revision: https://reviews.llvm.org/D142273
Make sure the source passed to an intrinsic is still polymorphic when
it is an element of a polymorphic array. This was not handled properly
before.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D142380
When a `!fir.box<>` is passed as an actual argument to an optional
`!fir.class<>` dummy it needs a `fir.rebox` in order to propagate
the dynamic type information.
The `fir.rebox` needs to happen only on present argument.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D142340
NULL() passed as actual argument to a procedure with an optional
dummy argument is represented with `fir.box<none>` type. When the dummy
argument is polymoprhic or unlimited polymorphic, the SelectOp will complain
if the types of the two arguments are not identical. Add a conversion from
`fir.box<none>` to `fir.class<none>` in that case.
Other situations with optional will require a fir.rebox and will be done in
a follow up patch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D142203
