The MOLD= argument to NULL() is allowed to be a null pointer itself --
for example, NULL(MOLD=NULL(MOLD=...)) should not raise spurious semantic
errors.
Differential Revision: https://reviews.llvm.org/D132166
Emit a "Assignment to procedure 'foo' is not allowed" error message
for more cases of 'foo' than just declaraed subprograms, rather than
assuming that those additional cases were named constants.
Differential Revision: https://reviews.llvm.org/D132165
f18 unconditionally uses a scaling algorithm for complex/complex division
that avoids needless overflows and underflows when computing the sum of
the squares of the components of the denominator -- but testing has shown
some 1 ULP differences relative to the naive calculation due to the
extra operations and roundings. So use the scaling algorithm only when
the naive calculation actually would overflow or underflow.
Differential Revision: https://reviews.llvm.org/D132164
When a particular module name has been brought into a compilation
as an intrinsic module via USE,INTRINSIC, perhaps indirectly via
an enclosing USE statement, f18 will resolve later USE statements
to it unless they are USE,NON_INTRINSIC. This is not entirely
correct -- a bare USE statement for a module name that happens to
match that of an intrinsic module should still search the search
paths for a non-intrinsic module file of the same name.
Differential Revision: https://reviews.llvm.org/D132163
When checking function interface compatibility for procedure pointer
assignment/initialization or actual/dummy procedure association, don't
emit a diagnositic about function result shape incompatibility unless
the interfaces differ in rank or have distinct constant extents on a
dimension. Function results whose dimensions are determined by dummy
arguments or host-associated variables are not necessarily incompatible.
Differential Revision: https://reviews.llvm.org/D132162
Assignment statements need to check for array shape conformance
errors that are discernable at compilation time.
Differential Revision: https://reviews.llvm.org/D132161
In the case of a data transfer I/O statement with an illegal unit number and
error recovery, ensure that data transfer API calls don't raise internal
errors due to the I/O statement representation unexpectedly being something
other than a data transfer statement.
Differential Revision: https://reviews.llvm.org/D132160
A literal % character in an error message needs to be doubled
so that it appears in the output of snprintf().
Differential Revision: https://reviews.llvm.org/D132158
While a NAMELIST input group item for an array can have fewer
values than expected, or none, an input group item for a scalar
must have a value.
Differential Revision: https://reviews.llvm.org/D132157
CharacterExtremumAccumulator::GetResult() needs to use byte counts, not wide
character counts, when calling memcpy() & memset().
Differential Revision: https://reviews.llvm.org/D132156
The intrinsic function SPACING() was being folded to the smallest
normal number (TINY(x)) rather than to a smaller subnormal result
when that result really was subnormal.
Differential Revision: https://reviews.llvm.org/D132155
Support these legacy extension intrinsic functions with unambiguous
semantics in those existing compilers that support them by means
of recognizing them as aliases for standard intrinsics (IMAG) or
with simple rewrites (IZEXT, JZEXT). Note that ZEXT has different
semantics in different existing compilers, so we will not support it
due to lack of a broad unambiguous precedent.
Differential Revision: https://reviews.llvm.org/D132154
We held off on this before as `LLVM_LIBDIR_SUFFIX` conflicted with it.
Now we return this.
`LLVM_LIBDIR_SUFFIX` is kept as a deprecated way to set
`CMAKE_INSTALL_LIBDIR`. The other `*_LIBDIR_SUFFIX` are just removed
entirely.
I imagine this is too potentially-breaking to make LLVM 15. That's fine.
I have a more minimal version of this in the disto (NixOS) patches for
LLVM 15 (like previous versions). This more expansive version I will
test harder after the release is cut.
Reviewed By: sebastian-ne, ldionne, #libc, #libc_abi
Differential Revision: https://reviews.llvm.org/D130586
to match the emitted warning, which has changed. I push this without
review as it is a one-line NFC. I have discussed it in D130386, which
altered the warning in question.
Function returning CHARACTER with adjustable length or dynamic arrays
can have negative length or extents passed to them. This patch makes sure
any negative inputs is rounded to 0.
Reviewed By: vdonaldson
Differential Revision: https://reviews.llvm.org/D132139
The TargetRewrite pass can change the number of argument of a function.
An extra llvm.nest attribute is added and was not set at the correct position
if an extra argument was inserted before.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D132113
Make tests expect the (correctly) emitted warnings using the WARNING
directive. This directive is non-functional now, but will be recognised
by test_errors.py when D125804 is landed. This patch is a preparation
for D125804.
For most tests, we add missing WARNING directives for emitted warnings,
but there are exceptions:
- for int-literals.f90 and resolve31.f90 we pass -pedantic to the
frontend driver, so that the expected warnings are actually emitted.
- for block-data01.f90 and resolve42.f90 we change the tests so that
warnings, which appear unintentional, are not emitted. While testing
the warning in question (padding added for alignment in common block)
would be desired, that is beyond the scope of this patch. This
warning is target-dependent.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D131987
The code generated for this version of the intrinsic is broken. I'm
marking it as a "TODO" for now so that people don't get unannounce bad
results.
Differential Revision: https://reviews.llvm.org/D132082
Add a proper TODO for the REDUCE instrinsic instead of crashing.
Reviewed By: PeteSteinfeld, vdonaldson
Differential Revision: https://reviews.llvm.org/D132020
The current code may not always work correctly, e.g.:
https://github.com/llvm/llvm-project/issues/57201
I added 'enable-experimental' pass option so that SUM simplification
may be enabled in LIT tests, but it is not enabled when the pass
is added to the passes pipeline.
Differential Revision: https://reviews.llvm.org/D131640
Flang supports lowering collapse clause to MLIR for worksharing loops
and simd loops. Simd collapse clause is represented in MLIR code as a
simd-loop having a list of indices, bounds and steps where the size of the list
is equal to the collapse value.
Support for simd collapse clause was added by several patches:
https://reviews.llvm.org/D118065 -> basic support for simd-loop in MLIR.
Loop collapsing is done in the same way as
for worksharing loops:
https://reviews.llvm.org/D105706https://reviews.llvm.org/D125282 -> support for lowering simd clause from
Fortran into MLIR
https://reviews.llvm.org/D125302 -> lowering collapse clause from Fortran to
MLIR. Lowering collapse clause is done
before simd-specific function is called.
https://reviews.llvm.org/D128338 -> modified the MLIR representation of
collapse clause. Removed collapse keyword
in OpenMP MLIR dialect. Use loop list to
represent collapse clause. This loop list
is created by changes from patch:
https://reviews.llvm.org/D125302 and it is
passed to function responsible for lowering
of simd directive which was implemented in
patch: https://reviews.llvm.org/D125282
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D132023
Signed-off-by: Dominik Adamski <dominik.adamski@amd.com>
Fix one encountered (issue #57072) and two potential scenarios where the
code would ask for an operand that isn't there.
Add test for the encountered case.
Reviewed By: vzakhari
Differential Revision: https://reviews.llvm.org/D131671
When testing LLVM 15.0.0 rc1 on Solaris, I found that 50+ flang tests
`FAIL`ed with
error:
/vol/llvm/src/llvm-project/local/flang/lib/Optimizer/CodeGen/Target.cpp:310:
not yet implemented: target not implemented
This patch fixes that for Solaris/x86, where the fix is trivial (just
handling it like the other x86 OSes).
Tested on `amd64-pc-solaris2.11`; only a single failure remains now.
Differential Revision: https://reviews.llvm.org/D131054
This document aims to give insights at the representation of polymorphic
entities in FIR and how polymorphic related constructs and features are lowered
to FIR.
Reviewed By: klausler, razvanlupusoru
Differential Revision: https://reviews.llvm.org/D131515
Fortran runtime supports mixed types by casting the loaded values
to the result type, so DOT_PRODUCT simplification has to do the same.
Differential Revision: https://reviews.llvm.org/D131726
This patch adds tests for the handling of array sections for
arrays with the ALLOCATABLE or POINTER attribute.
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D131885
Make sure that FortranDecimal, FortranRuntime and Fortran_main are
installed/packaged even when LLVM_INSTALL_TOOLCHAIN_ONLY is enabled.
They are used by flang to link executables, so they should be provided
even with minimal installs.
Differential Revision: https://reviews.llvm.org/D131670
This patch lowers correctly operands with array section
and derived-type component.
Depends on D131764
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D131765
This reland includes changes to the Python bindings.
Switch variadic operand and result segment size attributes to use the
dense i32 array. Dense integer arrays were introduced primarily to
represent index lists. They are a better fit for segment sizes than
dense elements attrs.
Depends on D131801
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D131803
The SemanticsContext is needed to analyze expression later in the
lowering for directive languages. This patch allows to keep a reference of
the SemanticsContext in the LoweringBridge.
Building block for D131765
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D131764
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: peixin
Differential Revision: https://reviews.llvm.org/D123930
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: peixin
Differential Revision: https://reviews.llvm.org/D123930
Switch variadic operand and result segment size attributes to use the
dense i32 array. Dense integer arrays were introduced primarily to
represent index lists. They are a better fit for segment sizes than
dense elements attrs.
Depends on D131738
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D131702
Location information was not correctly propagated when creating OpenACC
operations. This patch propagate the correct location information from
the parse tree nodes to OpenACC MLIR operations.
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D131659
This patch "modernizes" the LLVM `insertvalue` and `extractvalue`
operations to use DenseI64ArrayAttr, since they only require an array of
indices and previously there was confusion about whether to use i32 or
i64 arrays, and to use assembly format.
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D131537
I would like to add DOT_PRODUCT support in this pass, so this restructuring
is the first step to allow some code reuse inside getOrCreateFunction().
Differential Revision: https://reviews.llvm.org/D131530
Flang was not able to convert simd directive which contains nested
Fortran loops. The nested Fortran loops inside SIMD directive
are modelled as FIR loops and they need to be translated into LLVM
MLIR dialect.
Differential Revision: https://reviews.llvm.org/D131402
Reviewed by: peixin
Signed-off-by: Dominik Adamski <dominik.adamski@amd.com>
Adds support for reduction of multiplcation
by extending OpenMP.cpp::genOpenMPReduction()
and altering the identity constant emitted in
OpenMP.cpp::createReductionDelc()
This patch builds D130077 and as such,
only supports reductions for interger types in
worksharping loops.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D130767
Procedure bindings with explicit interfaces don't work when the
interface is shadowed by a generic interface of the same name,
and can produce spurious semantic error messages. Extend the
characterization and checking code for such things, and the utility
functionns on which they depend, to dig through generics when they
occlude interface-defining subprograms. This is done on demand in
checking code, not once during name resolution, because the
procedures in question may also be forward-referenced.
Differential Revision: https://reviews.llvm.org/D131105
diff --git a/flang/include/flang/Semantics/symbol.h b/flang/include/flang/Semantics/symbol.h
index e79f8ab6503e..0b03bf06eb73 100644
--- a/flang/include/flang/Semantics/symbol.h
Remove a lambda capture of "[this]" in two cases where it
is no longer required. Will be pushed without waiting for
review if CI is successful in order to resolve a sad build bot.
Differential Revision: https://reviews.llvm.org/D131506
Intrinsic procedures in intrinsic modules that have (or better, *are*) generic interfaces
must not have specific procedures with the same name according to the Fortran
standard (17.11.1); i.e., a user program is allowed to define a procedure
of the same name as one of these generic interfaces, even when the generic is
in scope.
Differential Revision: https://reviews.llvm.org/D131108
Allow internal I/O to support non-default kinds of CHARACTER.
The I/O runtime design anticipated this standard feature, but
this patch is somewhat larger than I thought it would be because
many code sites had to have assumptions about units (characters
vs. bytes) brought into harmony, and some encoding utilities
had to be pulled out of IoStatementState and templatized into
their own new header file so that they are available to formatted
output code without having to "thread" an IoStatementState reference
through many call chains.
Differential Revision: https://reviews.llvm.org/D131107
When a procedure pointer references a function as its interface, don't
apply semantic checks to the specification expressions that appear in
the declaration of the function's result -- this can lead to bogus
error messages as those specification expressions are being examined
out of their proper context.
Differential Revision: https://reviews.llvm.org/D131106
Type-bound procedure bindings that specify intrinsic procedures as their
interfaces should not acquire the ELEMENTAL attribute from the purposes
of compatibility checking between inherited bindings and their overrides
in extended derived types.
Differential Revision: https://reviews.llvm.org/D131104
Defined generic procedure interfaces are allowed to shadow non-generic
procedures of the same name in the same scope (whether or not
that non-generic procedure is a specific procedure of the generic).
When making a copy of a generic interface symbol so that it can
be locally modified or be merged with another generic, don't forget
about the homonymous non-generic procedure that it might shadow.
Differential Revision: https://reviews.llvm.org/D131103
Inaccessible components -- those declared PRIVATE in another module -- should
be allowed to be redeclared in extended types, and should be ignored if
they appear as keywords in structure constructors.
Differential Revision: https://reviews.llvm.org/D131102
The newly added AlgebraicSimplification pass is triggering the
greedy pattern rewriter. Since we define a specific config in the
flang pipeline, this patch adds the ability to pass the config
to the pass directly.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D131474
This utility routine in constant folding should return false when
a DIM= actual argument to a reduction intrinsic function has a
value that prevents folding, and true when folding can proceed.
The implementation was returning true in cases where a DIM=
argument was present but not constant.
Clarify the code and add commentary: a true result means that
there is no DIM= actual argument present, or that a DIM= argument
exists, is constant, and has a value that is in range.
Differential Revision: https://reviews.llvm.org/D131101
When a procedure pointer component has an interface that is a forward
reference to a procedure, syntax errors can be emitted if there is
a structure constructor that tries to initialize that component,
since its characteristics are not yet known; however, when the
initializer is a bare NULL(with no mold), those characteristics
don't matter. Make the characterization of the procedure pointer
component take place only when needed.
Differential Revision: https://reviews.llvm.org/D131100
The suffix is only added then the path the (lld-)link.exe is fully
resolved. Otherwise it may stay "link" or "lld-link".
On non-Windows platforms, lld-link also exists as a symbolic link to
lld, such that the full the path to lld-link might also be resolved
without .exe suffix in this case.
Note that CLANG_DEFAULT_LINKER could be set to other linkers such as
mold, in which case the test may still fail. This also applies to the
non-Windows tests that require "ld" in the linker name.
Fixes issue #56955
With this change all supported pgmath functions for non-complex
data types are replaced with either libm calls or MLIR operations,
except for MOD and some flavors of POW, which are going to be addressed
by other commits.
At the current stage a few math intrinsics are lowered into libm calls
always. When appropriate MLIR operation are available, the table can be
updated to generate them.
This patch serves two main purposes:
Firstly, to split some of the logic into a seperate method
to try and improve readability
On top of this, it aims to make creating the reductions more generic.
That way, subsequent patches adding reductions shouldn't need
to add a significant amount of extra logic checks, such as checking
for specific operators.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D131161
The implementations of folding for the intrinsic functions SCALE and SET_EXPONENT
do not cope correctly with numbers in the subnormal range. Fix SCALE,
then modify SET_EXPONENT to be a special case of SCALE.
Differential Revision: https://reviews.llvm.org/D131099
We need to distinguish BLOCK host association from subprogram host
association when checking assignments in PURE subprograms.
The specific case that is not allowed is an assignment to a variable
from the scope around the PURE subprogram.
Differential Revision: https://reviews.llvm.org/D131098
When an I/O statement contains a function call that attempts
to perform I/O on the same unit, detect the recursive I/O
and terminate with a useful message rather than deadlocking in
the threading library.
Differential Revision: https://reviews.llvm.org/D131097
F18 disallows function references and coarray references from
appearing in scalar expressions that are to be expanded into
arrays to conform with other operands or actual arguments in
an elemental expression. This is too strong, as pure procedures
can be safely used.
Differential Revision: https://reviews.llvm.org/D131096
This change removes dependency on pgmath mod, and also allows
Fortran runtime to issue a diagnostic message in case of zero
denominator.
Differential Revision: https://reviews.llvm.org/D131192
This commit addresses concerns raised in D129497.
Propagate lowering options from driver to expressions lowering
via AbstractConverter instance. A single use case so far is
using optimized TRANSPOSE lowering with O1/O2/O3.
bbc does not support optimization level switches, so it uses
default LoweringOptions (e.g. optimized TRANSPOSE lowering
is enabled by default, but an engineering -opt-transpose=false
option can still override this).
Differential Revision: https://reviews.llvm.org/D130204
Find calls to FortranASum{Real8,Integer4}, check for dim and mask
arguments being absent - then produce an inlineable simple
version of the sum function.
(No longer a prototype, please review for push to llvm/main - not sure how to make Phabricator update the review with actual commit message)
Reviewed By: peixin, awarzynski
Differential Revision: https://reviews.llvm.org/D125407
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
This patch fixes:
llvm-project/flang/lib/Semantics/expression.cpp:405:12: error:
moving a local object in a return statement prevents copy elision
[-Werror,-Wpessimizing-move]
The code that copies data from a constant source array into a character
array constant result was failing to copy its last element if it was
only partially defined due to misalignment.
Differential Revision: https://reviews.llvm.org/D130376
A type-param-inquiry of %KIND or %LEN applies to a designator, and
so must also be allowed for a substring. F18 presently (mis)parses
instances of a type-param-inquiry as structure component references
and then fixes them in expression semantics when types are known and
we can distinguish them. But when the base of a type-param-inquiry is
a substring of an array element, as in "charArray(i)(j:k)%len",
parsing fails.
Adjust the grammar to parse these cases, and extend expression semantics
to process the new production.
Differential Revision: https://reviews.llvm.org/D130375
Fortran specifically allows character-valued I/O specifiers
to have trailing blanks, e.g. OPEN(666,STATUS='SCRATCH ').
The runtime I/O library already handles them, but the I/O
static checks in semantics do not.
Differential Revision: https://reviews.llvm.org/D130381
This patch aims to create a webpage to document
Flang's command line options on https://flang.llvm.org/docs/
in a similar way to Clang's
https://clang.llvm.org/docs/ClangCommandLineReference.html
This is done by using clang_tablegen to generate an .rst
file from Options.td (which is current shared with Clang)
For this to work, ClangOptionDocEmitter.cpp was updated
to allow specific Flang flags to be included,
rather than bulk excluding clang flags.
Note:
Some headings in the generated documentation will incorrectly
contain references to Clang, e.g.
"Flags controlling the behaviour of Clang during compilation"
This is because Options.td (Which is shared between both Clang and Flang)
contains hard-coded DocBrief sections. I couldn't find a non-intrusive way
to make this target-dependant, as such I've left this as is, and it will need revisiting later.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D129864
This commit changes how math intrinsics are lowered: we, first,
try to lower them into MLIR operations or libm calls via
mathOperations table and only then fallback to pgmath runtime calls.
The pgmath fallback is needed, because mathOperations does not
support all intrinsics that pgmath supports. The main purpose
of this change is to get rid of llvmIntrinsics table so that
we do not have to update both llvmIntrinsics and mathOperations
when adding new intrinsic support.
mathOperations lowering should phase out pgmath lowering, when
more operations are available (e.g. power operations being
added in D129809 and D129811; complex type operations from
Complex dialect).
Differential Revision: https://reviews.llvm.org/D130129
Convert arith.cmpi to the canonical form with constants on the right side
to simplify further optimizations and open more opportunities for CSE.
Differential Revision: https://reviews.llvm.org/D129929
Lower F08 shift (shiftl, shiftr, shifta) and combined shift (dshiftl, dshiftr)
intrinsics. The combined shift intrinsics are implemented using the
definitions of shiftl and shiftr as described by the standard.
For non-conformant arguments to the shift intrinsics, the implementation tries
to replicate the behavior of other compilers if most of the other behave
consistently.
Differential Revision: https://reviews.llvm.org/D129316
Lower F08 bit population count intrinsics popcnt, poppar, leadz and trailz. popcnt, leadz and trailz are implemented using the corresponding MLIR math intrinsics. poppar is implemented in terms of popcnt.
Differential Revision: https://reviews.llvm.org/D129584
First of all, `LLVM_TOOLS_INSTALL_DIR` put there breaks our NixOS
builds, because `LLVM_TOOLS_INSTALL_DIR` defined the same as
`CMAKE_INSTALL_BINDIR` becomes an *absolute* path, and then when
downstream projects try to install there too this breaks because our
builds always install to fresh directories for isolation's sake.
Second of all, note that `LLVM_TOOLS_INSTALL_DIR` stands out against the
other specially crafted `LLVM_CONFIG_*` variables substituted in
`llvm/cmake/modules/LLVMConfig.cmake.in`.
@beanz added it in d0e1c2a550 to fix a
dangling reference in `AddLLVM`, but I am suspicious of how this
variable doesn't follow the pattern.
Those other ones are carefully made to be build-time vs install-time
variables depending on which `LLVMConfig.cmake` is being generated, are
carefully made relative as appropriate, etc. etc. For my NixOS use-case
they are also fine because they are never used as downstream install
variables, only for reading not writing.
To avoid the problems I face, and restore symmetry, I deleted the
exported and arranged to have many `${project}_TOOLS_INSTALL_DIR`s.
`AddLLVM` now instead expects each project to define its own, and they
do so based on `CMAKE_INSTALL_BINDIR`. `LLVMConfig` still exports
`LLVM_TOOLS_BINARY_DIR` which is the location for the tools defined in
the usual way, matching the other remaining exported variables.
For the `AddLLVM` changes, I tried to copy the existing pattern of
internal vs non-internal or for LLVM vs for downstream function/macro
names, but it would good to confirm I did that correctly.
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D117977
Try 2 to merge 4fbd1d6c87.
Flang algebraic simplification pass will run algebraic simplification
rewrite patterns for Math/Complex/etc. dialects. It is enabled
under opt-for-speed optimization levels (i.e. for O1/O2/O3; Os/Oz will not
enable it).
With this change the FIR/MLIR optimization pipeline becomes affected
by the -O* optimization level switches. Until now these switches
only affected the middle-end and back-end.
Differential Revision: https://reviews.llvm.org/D130035
This patch aims to create a webpage to document
Flang's command line options on https://flang.llvm.org/docs/
in a similar way to Clang's
https://clang.llvm.org/docs/ClangCommandLineReference.html
This is done by using clang_tablegen to generate an .rst
file from Options.td (which is current shared with Clang)
For this to work, ClangOptionDocEmitter.cpp was updated
to allow specific Flang flags to be included,
rather than bulk excluding clang flags.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D129864
Tests that use `--mlir-pass-statistics-display=` from MLIR require the
following condition to hold: (extracted from LLVM's Statistics.h):
```
#define LLVM_ENABLE_STATS 1
```
This is normally enforced with `REQUIRES: asserts`. This patch updates
relevant Flang tests accordingly.
For "Release" builds (with assertions disabled), the affected tests will
be failing without this change.
Differential Revision: https://reviews.llvm.org/D130185
Flang algebraic simplification pass will run algebraic simplification
rewrite patterns for Math/Complex/etc. dialects. It is enabled
under opt-for-speed optimization levels (i.e. for O1/O2/O3; Os/Oz will not
enable it).
With this change the FIR/MLIR optimization pipeline becomes affected
by the -O* optimization level switches. Until now these switches
only affected the middle-end and back-end.
Differential Revision: https://reviews.llvm.org/D130035
Flang C++ Style Guide tells us to use x.value() when no presence test
is obviously protecting the reference. Since assert can be disabled,
I don't count it as "protection" here.
Differential Revision: https://reviews.llvm.org/D130144
This update makes sure that `flang-new -O2 -O0` will run at `-O0` rather
than `-O2`.
This bug was identified and originally fixed by Vyacheslav Zakharin in
https://reviews.llvm.org/D130035. I've extracted the fix into a separate
patch.
co-authored by: Vyacheslav Zakharin <vyacheslav.p.zakharin@intel.com>
Differential Revision: https://reviews.llvm.org/D130104
mathOperations should now support all intrinsics that are handled
by the llvmIntrinsics table + `tan` lowered as Math dialect operation +
f128 flavor of abs.
I am going to flip the default to late math lowering after this change,
but still keep the fallback via pgmath. This will allow getting rid
of the llvmIntrinsics table and continue populating
only the mathOperations table, otherwise, updating both tables
seems to be inconvenient.
Differential Revision: https://reviews.llvm.org/D130048
This patch implements lowering for the F08 bitwise comparison intrinsics
(BGE, BGT, BLE and BLT).
This does not create any runtime functions since the functionality is
simple enough to carry out in IR.
The existing semantic check has been changed because it unconditionally
converted the arguments to the largest possible integer type. This
resulted in the argument with the smaller bit-size being sign-extended.
However, the standard requires the argument with the smaller bit-size to
be zero-extended.
Reviewed By: klausler, jeanPerier
Differential Revision: https://reviews.llvm.org/D127805
`AbstractResultOptions` is obsolete structure because `newArg` is used
only in `ReturnOpConversion`.
This change removes this struct, making dependencies of conversions more
straight-forward.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D129485
This patch introduce an automatic generation of the clause parser from the TableGen
information.
New information can be stored directly in the TableGen file:
- The different aliases that a clause support.
- prefix before a value.
- whether a prefix is optional or not.
Makes it easier to add new clauses and also avoid some error (`write` clause incorrect until now).
This patch is updating only the OpenACC part. A patch with a modification of the OpenMP clause parser will follow.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D106968
Evaluations for the Where and Forall constructs previously did
not have their constructExit field fixed up. This could lead to
falling through to subsequent case blocks in select case
statements if either a Where or Forall construct was the final part
of one case block. Setting the constructExit field results in the
proper branching behavior.
Fixes issue: https://github.com/llvm/llvm-project/issues/56500
Differential Revision: https://reviews.llvm.org/D129879
Change-Id: Ia868df12084520a935f087524e118bcdf47f6d7a
Add the collective subroutine, co_sum, to the list of intrinsics.
In accordance with 16.9.50 and 16.9.137, add a check for and an
error if coindexed objects are being passed to certain arguments
in co_sum and in move_alloc. Add a semantics test to check that
this error is successfully caught in calls to move_alloc. Remove
the XFAIL directive, update the ERROR directives and add both
standard-conforming and non-standard conforming calls to the
semantics test for co_sum.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D114134
This patch improves semantic checks for hint clause.
It checks "hint-expression is a constant expression
that evaluates to a scalar value with kind
`omp_sync_hint_kind` and a value that is a valid
synchronization hint."
Reviewed By: peixin
Differential Revision: https://reviews.llvm.org/D127615
This patch adds lowering support for atomic update construct. A region
is associated with every `omp.atomic.update` operation wherein resides:
(1) the evaluation of the expression on the RHS of the atomic assignment
statement, and (2) a `omp.yield` operation that yields the extended value
of expression evaluated in (1).
Reviewed By: peixin
Differential Revision: https://reviews.llvm.org/D125668
Fortran permits forward references to derived types in contexts that don't
require knowledge of the derived type definition for semantic analysis,
such as in the declaration of a pointer or allocatable variable or component.
But when the forward-referenced derived type is used later for a component
reference, it is possible for the DerivedTypeSpec in he base variable or component
declaration to still have a null scope pointer even if the type has been defined,
since DerivedTypeSpec and TypeSpec objects are created in scopes of use
rather than in scopes of definition. The fix is to call
DerivedTypeSpec::Instantiate() in the name resolution of each component
name so that the scope gets filled in if it is still null.
Differential Revision: https://reviews.llvm.org/D129681
When MOLD= is an array and there is no SIZE= in a call to TRANSFER(),
the size of an element of the MOLD= is used as the denominator in a
division to establish the extent of the vector result. When the
total storage size of the SOURCE= is known to be zero, the result is
empty and no division is needed.
To avoid a division by zero at runtime, we need to check for a zero-sized
MOLD= element type when the storage size of SOURCE= is nonzero and there
is no SIZE=. Further, in the compilation-time rewriting of calls to
SHAPE(TRANSFER(...)) and SIZE(TRANSFER(...)) for constant folding and
simplification purposes, we can't replace the call with an arithmetic
element count expression when the storage size of SOURCE= is not known
to be zero and the element size of MOLD= is not known to be nonzero at
compilation time.
These changes mostly affect tests using a MOLD= argument that is an
assumed-length character.
Differential Revision: https://reviews.llvm.org/D129680
Most of the infrastructure for DECIMAL='COMMA' mode was in place
in the I/O runtime support library, but I dropped the ball for
list-directed character input, which has its own detection of
input separators. Finish the job.
Differential Revision: https://reviews.llvm.org/D129679
Most modern Fortran programs declare procedure pointers with a
procedure-declaration-stmt, but it's also possible to declare one
with a type-declaration-stmt with a POINTER attribute. In this
case, e.g. "real, external, pointer :: p => null()" the initializer
is required to be a null-init. The parse tree traversal in name
resolution would visit the null-init if the symbol were an object
pointer only, leading to a crash in the case of a procedure pointer.
That explanation of the bug is longer than the fix. In short,
ensure that a null-init in an entity-decl is visited for both
species of pointers.
Differential Revision: https://reviews.llvm.org/D129676
When the I/O runtime is truncating an external file due to an
implied ENDFILE or explicit ENDFILE, ensure that the unit's frame
buffer for the file discards any data that have become obsolete.
This bug caused trouble with ACCESS='STREAM' I/O using POS= on
a WRITE, but it may have not been limited to that scenario.
Differential Revision: https://reviews.llvm.org/D129673
The rule used by list-directed REAL output editing to select
between Ew.d and Fw.d output editing breaks down for 16-bit
floating-point data, since the number of significant decimal
digits is so low that Ew,d output editing is nearly always selected.
Cap the test so that five-digit values will be output with Fw.d
editing.
Differential Revision: https://reviews.llvm.org/D129672
Some procedure pointers and EXTERNAL procedures have neither
explicit interfaces nor result types; these procedures are obviously
not known to be functions, but they could be, so semantics must not
assume that they are necessarily subroutines. Refine the procedure
pointer / dummy procedure compatibility check to handle these more
ambiguous cases and not elicit inappropriate error messages.
Differential Revision: https://reviews.llvm.org/D129674
Describe the built-in integer, real, complex and logical
types implemented in flang, capturing the as-implemented
characteristics.
Differential Revision: https://reviews.llvm.org/D129658
In D129186, CreateFIRLangRef.py was created to help fix
formatting problems with FIRLangRef.md.
However, due to an error while rebasing, the last edit was lost,
as such the current path variables are Unix-style.
This patch addresses what was discussed in the previous patch and
now uses os.path.join instead.
Differential Revision: https://reviews.llvm.org/D129644
Calling runtime TRANSPOSE requires a temporary array for the result,
and, sometimes, a temporary array for the argument. Lowering it inline
should provide faster code.
I added -opt-transpose control just for debugging purposes temporary.
I am going to make driver changes that will disable inline lowering
for -O0. For the time being I would like to enable it by default
to expose the code to more tests.
Differential Revision: https://reviews.llvm.org/D129497
When computing the base addresses of an array slice to make a
descriptor, codegen generated two LLVM GEPs. The first to compute
the address of the base character element, and a second one to
compute the substring base inside that element.
The previous code did not care about getting the result of the first
GEP right: it used the base array LLVM type as the result type.
This used to work when opaque pointer were not enabled (the actual GEP
result type was probably applied in some later pass). But with opaque
pointers, the second GEP ends-up computing an offset of len*<LLVM array
type> instead of len*<character width>. A previous attempt to fix the
issue was done in D129079, but it does not cover the cases where the
array slice contains subcomponents before the substring
(e.g: array(:)%char_field(5:10)).
This patch fix the issue by computing the actual GEP result type in
codegen. There is also enough knowledge now so that a single GEP can be
generated instead of two.
Differential Revision: https://reviews.llvm.org/D129481
FirOpBuilder takes a fir::KindMapping reference. When the getKindMapping()
call is made inside the ctor call, the lifetime of this reference may
be as short as the ctor call (at least with when building flang in
release mode with clang 8). This can cause segfaults when later using
the FirOpBuilder.
Ensure the kindMap passed to the FirOpBuilder ctor is the same as the
FirOpBuilder.
Differential Revision: https://reviews.llvm.org/D129494
Previously, FIRLangRef.md was incorrectly formatted.
This was due to how FIRLangRef.md had no page header,
and so the first entry would render incorrectly.
This patch introduces a header file, which is prepended to the FIRLangRef
before it becomes a HTML file. The header is currently brief
but can be expanded upon at a later date if required.
This formatting fix also means the index page
can correctly generate a link to FIRLangRef.html and as such,
this patch also removes FIRLangRef from the sidebar and adds it to the main list of links.
Depends on D128650
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D129186
The Fortran Language Reference is currently generated via tablegen,
however isn't present on flang.llvm.org/docs/
This patch adds FIRLangRef.md to the flang/docs directoy,
and adds a link to the generated HTML file in sidebar
under the 'Documentation' heading.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D128650
Add a semantics test for the intrinsic function image_status. Add
a check and restriction on the image argument in image_status,
ensuring that it is a positive value. Add same check on the
size argument of the intrinsic ishftc. Add another check on
the shift argument of ishftc, ensuring that it is less than or
equal to the size argument. Add a short semantics test checking
these restrictions in ishftc function calls.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D128009
In case where the bound(s) of a workshare loop use(s) firstprivate var(s), currently, that use is not updated with the created clone. It still uses the shared variable. This patch fixes that.
Reviewed By: peixin
Differential Revision: https://reviews.llvm.org/D127137
Flang C++ Style Guide tells us to avoid .has_value() in the predicate
expressions of control flow statements. I am treating ternary
expressions as control flow statements for the purpose of this patch.
Differential Revision: https://reviews.llvm.org/D128622
This required changing a bit of how attributes/types are parsed. A new
`KeywordSwitch` class was added to AsmParser that provides a StringSwitch
like API for parsing keywords with a set of potential matches. It intends to
both provide a cleaner API, and enable injection for code completion. This
required changing the API of `generated(Attr|Type)Parser` to handle the
parsing of the keyword, instead of having the user do it. Most upstream
dialects use the autogenerated handling and didn't require a direct update.
Differential Revision: https://reviews.llvm.org/D129267
Peter Klausler