Some applications have alignment directives for members inside types.
This allows those to be present, but generally getting ignored [with a warning]
later on in the processing. This is just to allow the compilation to complete.
This PR changes the build system to use use the sources for the module
`omp_lib` and the `omp_lib.h` include file from the `openmp` runtime
project and not from a separate copy of these files. This will greatly
reduce potential for inconsistencies when adding features to the OpenMP
runtime implementation.
When the OpenMP subproject is not configured, this PR also disables the
corresponding LIT tests with a "REQUIRES" directive at the beginning of
the OpenMP test files.
---------
Co-authored-by: Valentin Clement (バレンタイン クレメン) <clementval@gmail.com>
The prescanner allows multiple spaces within a compiler directive, but
not between the directive's sentinel (e.g., !DIR$) and the directive's
first token.
Fixes https://github.com/llvm/llvm-project/issues/76537.
For a character literal that is split over more than one source line
with free form line continuation using '&'
at the end of one line but missing the standard-required '&' on the
continuation line, also handle the case of spaces at the beginning of
the continuation line.
For example,
PRINT *, 'don'&
't poke the bear'
now prints "don't poke the bear", like nearly all other Fortran
compilers do.
This is not strictly standard conforming behavior, and the compiler
emits a portability warning with -pedantic.
Fixes llvm-test-suite/Fortran/gfortran/regression/continuation_1.f90,
.../continuation_12.f90, and .../continuation_13.f90.
This patch adds the following check from OpenMP 5.2.
```
If the directive has a clause, it must contain at least one enter clause
or at least one link clause.
```
Also added a warning for the deprication of `TO` clause on `DECLARE
TARGET` construct.
```
The clause-name to may be used as a synonym for the clause-name enter.
This use has been deprecated.
```
Based on the tests for to clause, the tests for enter clause are added.
This patch does not add tests where both to and enter clause are used together.
Before emitting a warning message, code should check that the usage in
question should be diagnosed by calling ShouldWarn(). A fair number of
sites in the code do not, and can emit portability warnings
unconditionally, which can confuse a user that hasn't asked for them
(-pedantic) and isn't terribly concerned about portability *to* other
compilers.
Add calls to ShouldWarn() or IsEnabled() around messages that need them,
and add -pedantic to tests that now require it to test their portability
messages, and add more expected message lines to those tests when
-pedantic causes other diagnostics to fire.
This patch adds the following semantic check for target update
```
At least one motion-clause must be specified.
```
A motion clause is either a `to` or a `from` clause.
This patch also adds a test for the following semantic check which was
already supported.
```
At most one nowait clause can appear on the directive.
```
unparsing for the bind clause was adding extra
parenthesis. This patch fixes that.
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D158210
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
A quotation mark can appear in a Fortran character literal by doubling
it; for example, PRINT *, "'""'" prints '"'. When those doubled
quotation marks are split by a free form line continuation, the
continuation line should have an ampersand before the second quotation
mark. But most compilers, including this one, allow the second
quotation mark to appear as the first character on the continuation
line, too.
So this works:
print *, "'"&
"'"
but it really should be written as:
print *, "'"&
&"'"
Emit a portability warning and document that we support this near-universal
extension.
Differential Revision: https://reviews.llvm.org/D155973
Fix some problems with INCLUDE line recognition pointed out by some
recently-added tests to the LLVM test suite.
Differential Revision: https://reviews.llvm.org/D155497
Extend the SourceFile class to take account of #line directives
when computing source file positions for error messages.
Adjust the output of #line directives to -E output so that they
reflect any #line directives that were in the input.
Differential Revision: https://reviews.llvm.org/D153910
Add parsing supprot for dim in gang clause
Depends on D151971
Reviewed By: razvanlupusoru, jeanPerier
Differential Revision: https://reviews.llvm.org/D151972
This patch adds parser support for the force modifier on the collapse clause
introduced in OpenACC 3.3.
Lowering will currently hit a TODO as the MLIR representation of the acc.loop
might need some update.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D151974
The insertion of a space on a line continuation right before
a character literal was confusing TokenSequence::ToLowerCase(),
that was unable to identify the character literal as such,
causing it to be converted to lower case.
Fix this by skipping spaces in the beginning and end of each
token, before testing for token type.
Fixes https://github.com/llvm/llvm-project/issues/62039
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D151885
Add representations of CUDA Fortran data and subprogram attributes
to the symbol table and scopes of semantics. Set them in name
resolution, and emit them to module files.
Depends on https://reviews.llvm.org/D150159.
Differential Revision: https://reviews.llvm.org/D150161
Begin upstreaming of CUDA Fortran support in LLVM Flang.
This first patch implements parsing for CUDA Fortran syntax,
including:
- a new LanguageFeature enum value for CUDA Fortran
- driver change to enable that feature for *.cuf and *.CUF source files
- parse tree representation of CUDA Fortran syntax
- dumping and unparsing of the parse tree
- the actual parsers for CUDA Fortran syntax
- prescanning support for !@CUF and !$CUF
- basic sanity testing via unparsing and parse tree dumps
... along with any minimized changes elsewhere to make these
work, mostly no-op cases in common::visitors instances in
semantics and lowering to allow them to compile in the face
of new types in variant<> instances in the parse tree.
Because CUDA Fortran allows the kernel launch chevron syntax
("call foo<<<blocks, threads>>>()") only on CALL statements and
not on function references, the parse tree nodes for CallStmt,
FunctionReference, and their shared Call were rearranged a bit;
this caused a fair amount of one-line changes in many files.
More patches will follow that implement CUDA Fortran in the symbol
table and name resolution, and then semantic checking.
Differential Revision: https://reviews.llvm.org/D150159
Presented with "IF (...)" with no following tokens in the statement,
diagnose a missing "THEN" instead of complaining about all of the
possible action statement initial tokens that could have been there
for a non-construct IF statement.
Fixes https://github.com/llvm/llvm-project/issues/62299.
Differential Revision: https://reviews.llvm.org/D150783
Modify the prescanner to allow compiler directives to appear in
macro expansions, and adjust the parser to accept a semicolon
as a directive terminator.
Differential Revision: https://reviews.llvm.org/D150780
Addresses the same issue as the following abandoned revision: D104391.
Rewrite leading declarative allocations so they are nested within their respective executable allocate directive
Original:
ExecutionPartConstruct -> OpenMPDeclarativeAllocate
ExecutionPartConstruct -> OpenMPDeclarativeAllocate
ExecutionPartConstruct -> OpenMPExecutableAllocate
After rewriting:
ExecutionPartConstruct -> OpenMPExecutableAllocate
| ExecutionPartConstruct -> OpenMPDeclarativeAllocate
| ExecutionPartConstruct -> OpenMPDeclarativeAllocate
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D148409
Co-authored-by: Isaac Perry <isaac.perry@arm.com>
Addresses the same issue as the following abandoned revision: D104391.
Rewrite leading declarative allocations so they are nested within their respective executable allocate directive
Original:
```
ExecutionPartConstruct -> OpenMPDeclarativeAllocate
ExecutionPartConstruct -> OpenMPDeclarativeAllocate
ExecutionPartConstruct -> OpenMPExecutableAllocate
```
After rewriting:
```
ExecutionPartConstruct -> OpenMPExecutableAllocate
| ExecutionPartConstruct -> OpenMPDeclarativeAllocate
| ExecutionPartConstruct -> OpenMPDeclarativeAllocate
```
Co-authored-by: Isaac Perry <isaac.perry@arm.com>
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D148409
This reverts commit 5faf45a3d2.
Once again arcanist stripped the co-author metadata. I'm going to add it to the revision description and try one last time.
Addresses the same issue as the following abandoned revision: D104391.
Rewrite leading declarative allocations so they are nested within their respective executable allocate directive
Original:
```
ExecutionPartConstruct -> OpenMPDeclarativeAllocate
ExecutionPartConstruct -> OpenMPDeclarativeAllocate
ExecutionPartConstruct -> OpenMPExecutableAllocate
```
After rewriting:
```
ExecutionPartConstruct -> OpenMPExecutableAllocate
| ExecutionPartConstruct -> OpenMPDeclarativeAllocate
| ExecutionPartConstruct -> OpenMPDeclarativeAllocate
```
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D148409
Addresses the same issue as the following abandoned revision: D104391.
Rewrite leading declarative allocations so they are nested within their respective executable allocate directive
Original:
```
ExecutionPartConstruct -> OpenMPDeclarativeAllocate
ExecutionPartConstruct -> OpenMPDeclarativeAllocate
ExecutionPartConstruct -> OpenMPExecutableAllocate
```
After rewriting:
```
ExecutionPartConstruct -> OpenMPExecutableAllocate
| ExecutionPartConstruct -> OpenMPDeclarativeAllocate
| ExecutionPartConstruct -> OpenMPDeclarativeAllocate
```
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D148409
This patch adds parser suppert for the device_type clause used by the Declare Target directive.
Differential Revision: https://reviews.llvm.org/D143671
f18 accepts statement labels in fixed form source even if they follow
a semicolon -- i.e., they're not in the fixed form's label field.
Emit a warning for such usage.
Differential Revision: https://reviews.llvm.org/D143817
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
In a derived type definition, a type bound procedure declaration
statement with neither interface nor attributes is required by constraint
C768 to have the optional "::" between the PROCEDURE keyword and the
bindings if any binding has a renaming with "=>". The colons are
not actually necessary for a correct and unambiguous parse, so
emit a warning when they are missing.
Differential Revision: https://reviews.llvm.org/D139065
