Replace more parse tree references to "thing" and "value()" with usage of the parser::Unwrap<> template function. Add parser::UnwrapRef<> as an alias for DEREF(Unwrap<>()).
An assignment to a whole polymorphic allocatable changes its dynamic type to the type of the right-hand side expression. But when the assignment is under control of a WHERE statement, or a FORALL / DO CONCURRENT with a mask expression, there is no interpretation of the assignment, as the type of a variable must be the same for all of its elements. There is no restriction in the standard against this usage, and no other Fortran compiler complains about it. But it is not possible to implement it in general, and the behavior produced by other compilers is not reasonable, much less worthy of emulating. It's best to simply disallow it with an error message. Fixes https://github.com/llvm/llvm-project/issues/133669, or more accurately, resolves it.
If a `do concurrent` loop is offloaded then there should be no CUDA data transfer in it. Update the semantic and lowering to take that into account. `AssignmentChecker` has to be put into a separate pass because the checkers in `SemanticsVisitor` cannot have the same `Enter/Leave` functions. The `DoForallChecker` already has `Eneter/Leave` functions for the `DoConstruct`.
This adds another puzzle piece for the support of OpenMP DECLARE REDUCTION functionality. This adds support for operators with derived types, as well as declaring multiple different types with the same name or operator. A new detail class for UserReductionDetials is introduced to hold the list of types supported for a given reduction declaration. Tests for parsing and symbol generation added. Declare reduction is still not supported to lowering, it will generate a "Not yet implemented" fatal error. Fixes #141306 Fixes #97241 Fixes #92832 Fixes #66453 --------- Co-authored-by: Mats Petersson <mats.petersson@arm.com>
An assignment to a whole polymorphic object in a PURE subprogram that is implemented by means of a defined assignment procedure shouldn't be subjected to the same definability checks as it would be for an intrinsic assignment (which would also require it to be allocatable). Fixes https://github.com/llvm/llvm-project/issues/139129.
A object's value can't be copied from another image by means of an intrinsic assignment statement if it has a derived type that contains a pointer subobject ultimate component.
Some data transfer marked as unsupported can actually be deferred to an assignment on the host when the variables involved are unified or managed.
Previous patch was too restrictive and didn't take into account cuf kernels and openacc compute constructs as being device context.
When the LHS is a device variable and the RHS has implicit transfer, this is considered as an illegal transfer according to https://docs.nvidia.com/hpc-sdk/compilers/cuda-fortran-prog-guide/index.html#implicit-data-transfer-in-expressions. Detect this is semantic .
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.