Add stopped_images to the list of intrinsic functions. Add a
semantics test for stopped_images.
Reviewed By: klausler, ngeorge1098
Differential Revision: https://reviews.llvm.org/D129513
This supports checks in C1801-C1805 for derived type with BIND attribute.
The other compilers such as 'gfortran' and 'ifort' do not report error
for C1802 and C1805, so emit warnings for them.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D130438
The semantic checks and runtime have been supported. This supports the
lowering of intrinsic ABORT.
`gfortran` prints a backtrace before abort, unless `-fno-backtrace` is
given. This is good to use. The intrinsic BACKTRACE is not supported
yet, so add TODO in the runtime.
This extention is needed in SPEC2017 521.wrf_r in
https://github.com/llvm/llvm-project/issues/55955.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D130439
As Fortran 2018 18.2.3.6, the intrinsic `c_loc(x)` gets the C address
of argument `x`. It returns the scalar of type C_PTR. As defined in
iso_c_binding in `flang/module/__fortran_builtins.f90`, C_PTR is the
derived type with only one component of integer 64.
This supports the lowering of intrinsic module procedure `c_loc` by
converting the address of argument into integer 64, where the argument
is lowered as Box and the address is generated using fir.box_addr.
The lowering of intrinsic `c_funloc` has the similar characteristic and
will be supported later.
The execution tests for various data types are in issue
https://github.com/llvm/llvm-project/issues/56552.
Reviewed By: Jean Perier
Differential Revision: https://reviews.llvm.org/D129659
Currently, FlangOptionsDocs.td doesn't specify `ExcludedFlags` which
means that in the generated documentation file we expose flags that:
* we don't necessarily won't to advertise to our users (e.g. hidden flags), or
* are not supported altogether (e.g. CL options).
This patch defines `ExcludeFlags` to fix that. The definition of
`ExcludeFlags` was copied from Clang so that LLVM frontends have
consistent documentation.
It might be a bit counter-intuitive that IncludeFlags alone is not
sufficient here. However, the current logic in ClangOptionDocEmitter.cpp
will parse IncludeFlags and print all options that contains one of the
included flags, as well as their aliases. So, for example, for -fopenmp
(which is a supported Flang option), one would also get /fopenmp (i.e.
CL mode equivalent for -fopenmp). By adding ExcludeFlags, we make sure
that such aliases are excluded.
I've also taken the liberty and moved FlangOptionsDocs.td. Originally it
was located in Flang's "flang/include" directory, but there shouldn't be
any implementation/documentation files there. Instead, I'm moving it to
the "flang/docs" directory.
Differential Revision: https://reviews.llvm.org/D130558
When the mlir-tblgen tool is set up, the `MLIR_TABLEGEN_EXE` variable
is set, which either points to the mlir-tblgen tool built in the current
cmake build, or points to one built in a nested cmake build (if cross
conpiling, or if building with e.g. `LLVM_OPTIMIZED_TABLEGEN`.
The `MLIR_TABLEGEN_EXE` variable is only set within the scope of the
mlir/CMakeLists.txt file, so it's unavailable in sibling level projects
such as flang.
Set the `MLIR_TABLEGEN_EXE` and the `MLIR_TABLEGEN_TARGET` variables
as global, so that flang can use them properly without guessing.
Differential Revision: https://reviews.llvm.org/D130350
If CMAKE_CROSSCOMPILING, then the newly built flang-new executable was
cross compiled and thus can't be executed on the build system, and thus
can't be used for generating module files.
Differential Revision: https://reviews.llvm.org/D130349
GCC and that specific build bot issued warnings turned errors, due to a narrowing conversion from `unsigned` to `int32_t`. Silence these via a static_cast.
This is the follow up on https://reviews.llvm.org/D130730 which goes through upstream code and removes creating constant values in favour of using the constant indices in GEP directly. This leads to less and more readable code and more compact IR as well.
Differential Revision: https://reviews.llvm.org/D130731
When an array is defined with "unknown" size, such as fir.array<2x?x5xi32>,
it should be converted to llvm.array<10 x i32>. The code so far has
been converting it to llvm.ptr<i32>.
Using a different function to check the if there starting are constant
dimensions, rather than if ALL dimensions are constant, it now produces
the correct array form.
Some tests has been updated, so they are now checking the new behaviour
rather than the old behaviour - so there's no need to add further tests
for this particular scenario.
This was originally found when compiling Spec 17 code, where an assert
in a GepOP was hit. That is bug #56141, which this change fixes.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D129196
This supports lowering from parse-tree to MLIR and translation from
MLIR to LLVM IR using OMPIRBuilder for OpenMP simdlen clause in SIMD
construct.
Reviewed By: shraiysh, peixin, arnamoy10
Differential Revision: https://reviews.llvm.org/D130195
This patch adds support for AsmPrinter `-mmlir` options to the Flang driver.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D130598
The options -f{no-}color-diagnostics have been supported in driver. This
supports the behaviors in scanning, parsing, and semantics, and the
behaviors are exactly the same as the driver.
To illustrate the added behaviour, consider the following input file:
```! file.f90
program m
integer :: i = k
end
```
In the following invocations, "error: Must be a constant value" _will be_
formatted:
```
$ flang-new file.f90
error: Semantic errors in file.f90
./file.f90:2:18: error: Must be a constant value
integer :: i = k
```
Note that "error: Semantic errors in file.f90" is also formatted, which
is supported in https://reviews.llvm.org/D126164.
Also note that only "error", "warning" and "portability" are formatted.
Check the following input file:
```! file2.f90
program m
integer :: i =
end
```
```
$ flang-new test2.f90
error: Could not parse test2.f90
./test2.f90:2:11: error: expected '('
integer :: i =
^
./test2.f90:2:3: in the context: statement function definition
integer :: i =
^
...
```
The "error: Could not parse test2.f90" and "error: expected '('" are
formatted. Others such as "in the context" are not formatted yet, which
may or may not be supported.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D126166
There is post comment of adding TODO/FIXME for privatization of loop
bounds in D127137. D127137 fixes the bug in OpenMP firstprivate clause,
which should be refactored later according to the post comment. Add
FIXME for it.
Differential Revision: https://reviews.llvm.org/D130625
The header file OpenMPDialect.h is added in Bridge.cpp in D130027,
but it is unused. Remove it.
Differential Revision: https://reviews.llvm.org/D130625
We have seen the llvm test fail every so often on our bots:
https://lab.llvm.org/buildbot/#/builders/173/builds/6711
This happens because `flang-new -fc1 -S` does not wait for the
pipe to finish being written to/does not read out all the content.
You can see this in the output, cat comes after flang:
+ /home/tcwg-buildbot/worker/flang-aarch64-release/build/bin/not /home/tcwg-buildbot/worker/flang-aarch64-release/build/bin/flang-new -fc1 -S - -o -
+ cat /home/tcwg-buildbot/worker/flang-aarch64-release/llvm-project/flang/test/Driver/input-from-stdin-llvm.ll
error: Invalid input type - expecting a Fortran file
This means that cat gets SIGPIPE which causes it to exit with
code 141 and that's the final result due to pipefail.
flang isn't wrong to exit early (I think some modes of grep also do this)
and we only care about flang's exit code. So disable pipefail for
the stdin testing.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D130619
This patch refactors the runtime support for GET_COMMAND_ARGUMENT to
have a single entry point instead of 2. It also updates lowering
accordingly.
This makes it easier to handle dynamically optional arguments. See also
https://reviews.llvm.org/D118777
Differential Revision: https://reviews.llvm.org/D130475
Now the prefixes have the same length
and they'll be easier to distinguish when
`GlobalOp` tests will be added
Depends on D129778
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D130087
This change decouples common functionality for convering abstract
results, so it can be reused later.
Depends on D129485
Reviewed By: clementval, jeanPerier
Differential Revision: https://reviews.llvm.org/D129778
The fp128 in llvm.round and llvm.trunc is not supported in X86_64 for
now. Revert the support. To support quad precision for llvm.round and
llvm.trunc, it may should be supported using runtime.
Reviewed By: Jean Perier
Differential Revision: https://reviews.llvm.org/D130556
Fixes a regression from D117973, that used CMAKE_BINARY_DIR instead of
LLVM_BINARY_DIR in some places.
Differential Revision: https://reviews.llvm.org/D130555
This patch adds lowering support for default clause.
1. During symbol resolution in semantics, should the enclosing context have
a default data sharing clause defined and a `parser::Name` is not attached
to an explicit data sharing clause, the
`semantics::Symbol::Flag::OmpPrivate` flag (in case of `default(private)`)
and `semantics::Symbol::Flag::OmpFirstprivate` flag (in case of
`default(firstprivate)`) is added to the symbol.
2. During lowering, all symbols having either
`semantics::Symbol::Flag::OmpPrivate` or
`semantics::Symbol::Flag::OmpFirstprivate` flag are collected and
privatised appropriately.
Co-authored-by: Peixin Qiao <qiaopeixin@huawei.com>
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D123930
Use pertinent names instead of numbered values, to make it easier to
update the test in future patches.
Differential Revision: https://reviews.llvm.org/D130474
This patch replaces x.getValue() with *x if the reference is obviously
protected by a presence check. Otherwise, it replaces x.getValue()
with x.value().
This patch adds an initial support to the lastprivate clause for worksharing loop. The patch creates necessary control flow to guarantee the store of the value from the logical last iteration of the workshare loop.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D130027
Firstly, we we make an additional GNUInstallDirs-style variable. With
NixOS, for example, this is crucial as we want those to go in
`${dev}/lib/cmake` not `${out}/lib/cmake` as that would a cmake subdir
of the "regular" libdir, which is installed even when no one needs to do
any development.
Secondly, we make *Config.cmake robust to absolute package install
paths. We for NixOS will in fact be passing them absolute paths to make
the `${dev}` vs `${out}` distinction mentioned above, and the
GNUInstallDirs-style variables are suposed to support absolute paths in
general so it's good practice besides the NixOS use-case.
Thirdly, we make `${project}_INSTALL_PACKAGE_DIR` CACHE PATHs like other
install dirs are.
Reviewed By: sebastian-ne
Differential Revision: https://reviews.llvm.org/D117973
The predicate "CanBeCalledViaImplicitInterface()" was returning false for
restricted specific intrinsic functions (e.g., SIN) because their procedure
characteristics have the elemental attribute; this leads to a bogus semantic
error when one attempts to use them as proc-targets in procedure pointer
assignment statements when the left-hand side of the assignment is a procedure
pointer with an implicit interface. However, these restricted specific intrinsic
functions have always been allowed as special cases for such usage -- it is
as if they are elemental when it is necessary for them to be so, but not
when it's a problem.
Differential Revision: https://reviews.llvm.org/D130386
An OPEN statement that implies closing a connection must invalidate
the unit's frame buffer so as to prevent stale data from the old
connection from being read into the newly-connected unit.
Differential Revision: https://reviews.llvm.org/D130430
Lower the Flang parse-tree containing OpenMP reductions to the OpenMP
dialect. The OpenMP dialect models reductions with,
1) A reduction declaration operation that specifies how to initialize, combine,
and atomically combine private reduction variables.
2) The OpenMP operation (like wsloop) that supports reductions has an array of
reduction accumulator variables (operands) and an array attribute of the same
size that points to the reduction declaration to be used for the reduction
accumulation.
3) The OpenMP reduction operation that takes a value and an accumulator.
This operation replaces the original reduction operation in the source.
(1) is implemented by the `createReductionDecl` in OpenMP.cpp,
(2) is implemented while creating the OpenMP operation,
(3) is implemented by the `genOpenMPReduction` function in OpenMP.cpp, and
called from Bridge.cpp. The implementation of (3) is not very robust.
NOTE 1: The patch currently supports only reductions for integer type addition.
NOTE 2: Only supports reduction in the worksharing loop.
NOTE 3: Does not generate atomic combination region.
NOTE 4: Other options for creating the reduction operation include
a) having the reduction operation as a construct containing an assignment
and then handling it appropriately in the Bridge.
b) we can modify `genAssignment` or `genFIR(AssignmentStmt)` in the Bridge to
handle OpenMP reduction but so far we have tried not to mix OpenMP
and non-OpenMP code and this will break that.
I will try (b) in a separate patch.
NOTE 5: OpenMP dialect gained support for reduction with the patches:
D105358, D107343. See https://discourse.llvm.org/t/rfc-openmp-reduction-support/3367
for more details.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D130077
Co-authored-by: Peixin-Qiao <qiaopeixin@huawei.com>
When a procedure pointer is associated with a procedure target, f18
will emit hard error messages if the pointer is incompatible with the
target in a way that would cause the program to not work if the
procedure pointer were actually called. However, in the context of
the ASSOCIATED() intrinsic, the compiler should not consider a query
to be a compilation-time error if the pointer and the target are
incompatible. The standard gives us sufficient wiggle room here
to treat these cases as warnings.
Attempts to use ASSOCIATED to test whether a procedure pointer is
associated with a data object, or vice versa, remain errors.
Differential Revision: https://reviews.llvm.org/D130384
In flang pipeline, the inliner calls createCanonicalizerPass with the region
simplification disabled. The inliner pass does canonicalization even if
no inlining happens. After canonicalization, FIR lite region simplification
must be called to get rid of unreachable regions.
This code exposes the need to run SimplifyRegionLitePass after the inliner is
called with FIR pipeline.
Differential Revision: https://reviews.llvm.org/D130484
f18 intentionally does not support the spottily-implemented language extension
in which one can pass NULL() for an allocatable dummy argument. This is perhaps
a sanctioned side effect in other compilers of the fact that they pass distinct
"base address" and "descriptor address" physical arguments.
Make the error message in this case more specific to the circumstances, and
add a note to Extensions.md to clarify that this behavior is intended.
(We could, with some effort in lowering, support passing NULL for an INTENT(IN)
allocatable dummy, but let's see whether such nonconforming usage appears
in a real application before spending any more time on it.)
Differential Revision: https://reviews.llvm.org/D130380
As Fortran 2018 16.9.169, the argument of selected_int_kind is integer
scalar, and result is default integer scalar. The constant expression in
this intrinsic has been supported by folding the constant expression.
This supports lowering and runtime for variables in this intrinsic.
Reviewed By: Jean Perier
Differential Revision: https://reviews.llvm.org/D129959
This change is required for release builds - see
https://reviews.llvm.org/D130185 for more context.
I'm sending this without a review as this is rather straightforward and
identical to the changes from https://reviews.llvm.org/D130185 (the test
updated in this patch wasn't yet in-tree when D130185 landed).
As Fortran 2018 16.9.170, the argument of `selected_real_kind` is integer
scalar, and result is default integer scalar. The constant expression in
this intrinsic has been supported by folding the constant expression.
This supports lowering this intrinsic for variables using runtime.
Reviewed By: Jean Perier
Differential Revision: https://reviews.llvm.org/D130183
Flang C++ Style Guide tells us to use *X when the reference is
protected by a presense test. However, (*X).foo() is a little harder
to read, especially when X is a complicated expression.
This patch slightly deviates from the guide (but retains the spirit)
by using X->foo() instead.
Differential Revision: https://reviews.llvm.org/D130413
Flang C++ Style Guide tells us to use x.value() when no presence test
is obviously protecting the reference. Since a failure in EXPECT_TRUE
doesn't terminate a given test, I don't count it as "protection" here.
Differential Revision: https://reviews.llvm.org/D130410
The predicate IsHostAssocited() was implemented in a way that would
return true only for cases of host association into a module or inner
subprogram. Technically, the use of a name in a BLOCK construct
that is not declared therein is considered in the Fortran standard
to also be a form of host association, and this matters when doing
error checking on DATA statements.
Differential Revision: https://reviews.llvm.org/D130388
When a procedure pointer with no interface is associated with
an EXTERNAL name with no interface information, but it is later
inferred that the procedure pointer must be a subroutine because it
appears in a CALL statement, don't complain that the EXTERNAL name
is not also known to be a subroutine.
Subroutine vs. function errors are still caught in procedure pointer
assignment compatibility checking; this fix simply ensures that those
more nuanced tests are not overridded by the attribute set equality test.
Also, leave in some code for dumping the differing attributes in legitimate
error cases that was added in the coures of debugging the specific problem.
Differential Revision: https://reviews.llvm.org/D130385
In some contexts the code looks cleaner if we fold zero-length substring
references into empty character constants, but those don't work in
variable definition contexts and can lead to bogus semantic error
messages.
Differential Revision: https://reviews.llvm.org/D130383
For aint/anint, LLVM conversion operations llvm.trunc and llvm.round
can support the edge case of aint(-0.) and anint(-0.). The output is -0.
and it is the same of `gfortran` and `classic flang`, while the output
of `ifort` is 0.. The `real(10)/real(16)` is not supported before.
Support it and remove the runtime functions for aint/anint.
For nint, `gfortran`, `ifort`, and LLVM Flang using llvm.lround have
different results when the magnitude of argument is more than the max of
result value range. So delay its support in lowering after more
investigations.
Reviewed By: vzakhari
Differential Revision: https://reviews.llvm.org/D130024
The integer arithmetic template supports ISHFTC() but the
integer intrinsic folding code had yet to call it; finish
the job.
Differential Revision: https://reviews.llvm.org/D130379