Distinguish between copyin and copyin with the readonly modifier.
Depends on D157121
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D157125
This patch also adds a LIT test for the vec_cvf intrinsic that
can be affected by the option.
Co-authored-by: Mark Danial <Mark.Danial@ibm.com>
Co-authored-by: Daniel Chen <cdchen@ca.ibm.com>
Differential Revision: https://reviews.llvm.org/D155852
F18 produce a module file with a declaration part. This patch
propagates the OpenACC declare information in the module file along the variable
declaration.
Depends on D157042
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D157121
Flags were not correctly set for symbols appearing in the OpenACC declare
directive in module declaration part.
Also some missing flags for OpenACC are added. This makes the Flags enum
> 64 and then the implementation switch to std::bitset as defined in
`flang/include/flang/Common/enum-set.h`. Therefore, `constexpr` cannot be
used for set of flags in `flang/lib/Semantics/resolve-directives.cpp`.
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D157042
The assignments inside where/elsewhere may affect variables participating
in the mask expression, but execution of the assignments must not affect
the established control mask(s) (F'18 10.2.3.2 p. 13).
The following example must print all 42's:
```
program test
integer c(3)
logical :: mask(3) = .true.
where (mask)
c = f()
end where
print *, c
contains
integer function f()
mask = .false.
f = 42
end function f
end program test
```
Reviewed By: tblah
Differential Revision: https://reviews.llvm.org/D156959
This patch adds support for matching multiple OpenMP `if` clauses to their
specified directive in a combined construct. It also enables this clause to be
attached by name to `simd` and `teams` directives, in addition to the others
that were already supported.
This patch on its own cannot yet be tested because there is currently no
lowering to MLIR support for any combined construct containing two or more
OpenMP directives that can have an `if` clause attached.
Depends on D155981.
Differential Revision: https://reviews.llvm.org/D156313
The following restrictions for USE_DEVICE_PTR and USE_DEVICE_ADDR clauses on OMP TARGET DATA directive are implemented in this patch.
- A list item may not be specified more than once in use_device_ptr clauses that appear on the directive.
- A list item may not be specified more than once in use_device_addr clauses that appear on the directive.
- A list item may not be specified in both a use_device_addr clause and a use_device_ptr clause on the directive.
- A list item that appears in a use_device_ptr or use_device_addr clause must not be a structure element.
- A list item that appears in a use_device_ptr must be of type C_PTR.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D155133
The copyprivate clause is not yet implemented. Provide a TODO
error message when this clause is seen.
Reviewed By: NimishMishra
Differential Revision: https://reviews.llvm.org/D155596
Convert the elementTypeAttr of AtomicRead Op for LLVMConversion.
This is required when the elementType is non-integer, non-real.
Reviewed By: NimishMishra
Differential Revision: https://reviews.llvm.org/D155817
Enforce the following restriction specified in 2.13
A var may appear at most once in all the clauses of declare directives for a
function, subroutine, program, or module.
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D156945
Lower the copyout clause for the OpenACC declare directive
Depends on D156738
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D156824
The OpenACC 3.3 specification does not allow the `zero` modifier
on the `copyout` clause used with the declare directive.
This is similar to D156703 for the create clause.
This might be missing piece in the spec but we disallow it until proven otherwise.
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D156825
We currently spell check options that are listed as unsupported, but
this doesn't make much sense. If an option is explicitly unsupported
why would one that's spelled similarly be useful?
It looks like the reason this was added was that we explicitly mark
all `--something` flags as Unsupported rather than just leaving them
undefined and treating them as unknown. Drop that handling so that we
don't regress on things like misspelling `--help`.
Differential Revision: https://reviews.llvm.org/D156925
This patch applies the semantic checks for executable allocation directives to the new allocators construct. It also introduces a new check that ensures all items in the list appear in the corresponding Fortran allocate statement.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D150428
For character type with unknown length we end up generating
a GEP with the base type `llvm.ptr<i[width]>`. The GEP produces
the address of the first element of the slice, and it should be
using the offset computed in the number of characters, while we were
providing the offset in bytes.
Simple reproducer fails with and w/o HLFIR:
```
program test
integer,parameter :: ck = 4
character(:,ck),allocatable :: res(:,:)
allocate(character(3,ck) :: res(2,2))
res(1,1) = ck_'111'
res(1,2) = ck_'222'
res(2,1) = ck_'333'
res(2,2) = ck_'444'
call check(res)
contains
subroutine check(res)
character(:,ck),allocatable :: res(:,:)
print *, res(2,:)
end subroutine check
end program test
```
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D156849
A section of a parameter array may be non-contiguous,
so the current !IsVariable(expr) check is too optimistic
to claim contiguity.
This patch fixes issues with incorrect hlfir.designate op generated
during lowering: the lowering queries IsContiguous to decide whether
to use fir.box<fir.array> or plain fir.ref<fir.array> to represent
the designator result.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D156494
Both LLVM and SPIR-V have some form of "is this float a NaN/Inf"
operation (though LLVM's uses the rather opaque "is.fpclass"
intrinsic), which is not exposed in MLIR.
This has lead to awkward workarounds in -arith-expands-ops where a NaN
test was performed by comparing an operation to itself. This commit
resolves that issue.
Reviewed By: dcaballe, kuhar
Differential Revision: https://reviews.llvm.org/D156169
Temporaries created to store worksharing loop index values were
using different types than that of the original index variables.
This caused invalid IR to be produced when an index variable was
used in binary operations which expected its original type.
Fix this by creating temporaries with the types of their original
variables and converting the loop values, that continue to use
the types that OpenMP runtime expects, to them.
Fixes https://github.com/llvm/llvm-project/issues/60870
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D156803
This patch permits map operands to be not specified for the target
data operation. Also emit an error if none of the map, use_device_addr,
or use_device_ptr operands are specified.
Reviewed By: TIFitis
Differential Revision: https://reviews.llvm.org/D156170
Lower the present clause on the OpenACC declare construct in
function/subroutine.
Depends on D156572
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D156721
Lower the create clause on the OpenACC declare construct in
function/subroutine.
Depends on D156568
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D156572
This patch adds lowering for the exit part of the OpenACC declare construct
in function/subroutine.
Depends on D156560
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D156568
This patch adds lowering for the entry part of the OpenACC declare construct
in function/subroutine. The exit part will come as a follow up patch.
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D156560
When a FINAL subroutine is being invoked for a discontiguous array, which can
happen for INTENT(OUT) dummy arguments and for some left-hand side variables
in intrinsic assignment statements, it may be the case that the subroutine
being called was defined with a dummy argument that requires contiguous data.
Extend the derived type descriptions used by the runtime to signify when
a special procedure binding requires contiguity; set the flags accordingly;
check them in the runtime support library, and, when necessary, use a
temporary shallow copy of the finalized array data in the call to the
final subroutine.
Differential Revision: https://reviews.llvm.org/D156760
Check for cases of storage sequence association in which an element or
substring is an actual argument associated with a dummy argument array
that can be detected as being larger than the remaining elements or characters
in the actual argument's storage sequence.
Differential Revision: https://reviews.llvm.org/D156757
The exit code for -### is inconsistent. Unrecognized options lead to
exit code 1, as expected. However, most others errors (including invalid
option value) lead to exit code 0, differing from GCC and most utilities.
This is a longstanding quirk of -###, and we didn't fix it because many
driver tests need adjustment.
Change -### to be similar to -fdriver-only -v and exit with code 1.
This requires fixing many driver tests, but the end result gives us
stronger tests.
* Existing `RUN: %clang -### ...` tests usually don't use `CHECK-NOT: error:` or `--implicit-check-not=error:`.
If a change introduces an error, such a change usually cannot be detected.
* Many folks contributing new tests don't know `-fdriver-only -v`.
To test no driver error/warning for new tests, they can use the familiar `-### -Werror`
instead of `-fdriver-only -v -Werror`.
An incomplete list of prerequisite test improvement:
* 2f79bb10461d114783a1548201928549ace09755: add -nogpulib to some AMDGPU tests
* 9155e517e6e1cda474d0d0fa82f71696c325bc10: add --cuda-path= (test w/ and w/o /usr/local/cuda)
* 80765ede5bbcca1364c2d4ae06127011eaba6389: -mcpu=native may return either 0 or 1, depending on whether `--target=` specifies a native target
* abae53f43f0d1da8d8e421f4a628d7ec64d6e365: fix -fuse-ld=lld misuses (test w/o and w/o /usr/local/bin/ld.lld)
* ab68df505e5bb8808ee44f53044b50ca7575098e: add -resource-dir= and -fvisibility=hidden
to some -fsanitize=cfi tests
* d5ca1602f64114f612ad5630f04e4aa90591c78d: --rtlib=platform without --unwindlib= may fail if CLANG_DEFAULT_UNWINDLIB=unwindlib
Reviewed By: jhuber6, yaxunl, dblaikie
Differential Revision: https://reviews.llvm.org/D156363
Folding of LBOUND/UBOUND on assumed-rank arrays could lead to bogus errors
later. This is a regression from a recent change intended to ensure that
patently bad DIM= arguments were caught even in the case of assumed-rank.
Rearrange the order of checks so that those bad DIM= argument values are
caught but otherwise defer LBOUND/UBOUND of assumed-rank arguments to
run time. (It was tempting to always fold LBOUND(ar,DIM=n) to 1, but
that would obscure the run time error required when 'n' is out of bounds,
including the case of a scalar 'ar'.)
Differential Revision: https://reviews.llvm.org/D156755
I believe the help text for the flag `--offload-host-device` is wrong. Currently, the help text says "Only compile for the offloading host." but the flag alias with `--cuda-compile-host-device` which
has the help text "Compile CUDA code for both host and device (default). Has no effect on non-CUDA compilations."
Fixes https://github.com/llvm/llvm-project/issues/64243
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D156641
Work through several issues with LBOUND() and UBOUND() of ASSOCIATE
construct entities that have been associated with named constants or
subobjects of named constants that are sporting non-default lower bounds.
Sometimes the non-default lower bounds matter, sometimes they don't.
Add a fairly exhaustive test to work through the possibilities.
Differential Revision: https://reviews.llvm.org/D156756
DPROD(x,y) is defined as DBLE(x)*DBLE(y) and that's exactly how
the implementation of its rewriting and possible folding should
be implemented, instead of the current code that only works when
both arguments are scalar and crashes otherwise.
Fixes https://github.com/llvm/llvm-project/issues/63991.
Differential Revision: https://reviews.llvm.org/D156754
An implied DO loop in an array constructor may not have a type (explicit
or otherwise) with a character length that depends on a value of an
implied DO index or a non-constant expression if the implied DO loop
executes no iterations. When the iteration count can be known to be
zero at compilation time, catch the case of a non-constant length
expression correctly.
Differential Revision: https://reviews.llvm.org/D156753
Loop index variables are privatised for a worksharing loop.
The alloca ops of the privatised index are hoisted to the
entry block of the outlineable region or parent function.
With HLFIR, the hlfir.declare should be created in the same
place as the alloca op. To achieve this the alloc and the
hflir.declare should be created in the same place. A new
function is created in OpenMP.cpp for this purpose.
Reviewed By: tblah
Differential Revision: https://reviews.llvm.org/D156719
The OpenACC 3.3 specification does not allow the `zero` modifier
on the `create` clause used with the declare directive.
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D156703
The prescanner performs implicit line continuation when it looks
like the parenthesized arguments of a call to a function-like macro
may span multiple lines. In an attempt to work more like a
Fortran-oblivious C preprocessor, the prescanner will act as if
the following lines had been continuations so that the function-like
macro could be invoked.
This still seems like a good idea, but a recent bug report on
LLVM's GitHub issue tracker shows one way in which it could trigger
inadvertently and mess up a program. So this patch makes the
conditions for implicit line continuation much more strict.
First, the leading parenthesis has to have been preceded by an
identifier that's known to be a macro name. (It doesn't have to
be a function-like macro, since it's possible for a keyword-like
macro to expand to the name of a function-like macro.) Second,
no macro definition can ever have had unbalanced parentheses in
its replacement text.
Also cleans up some parenthesis recognition code to fix some
issues found in testing, so that a token with leading or trailing
spaces can still be recognized as a parenthesis or comma.
Fixes https://github.com/llvm/llvm-project/issues/63844.
Differential Revision: https://reviews.llvm.org/D155499
This patch provides support for usage of common block
in private/firstprivate and lastprivate clauses.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D156120
This supports the common block in OpenMP privat clause by making
each common block member host-associated privatization and
adds the test case.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D127215
Fix the value of the structured attribute for entry operation in the
global constructor noted in D156353.
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D156481
Use `AddAllArgs` to keep the implementation succinct. Also adds missing
'-flang-experimental-hlfir` in "frontend-forwarding.f90"
Differential Revision: https://reviews.llvm.org/D156524
