The I/O runtime's API allows -1 to be passed for a unit number in a
READ, WRITE, or PRINT statement, where it gets replaced by 5 or 6 as
appropriate. This turns out to have been a bad idea, as it prevents the
I/O runtime from detecting and reporting a program's invalid attempt to
use -1 as an I/O unit number. So just pass 5 or 6 as appropriate.
Patch 2/3 of the transition step 1 described in
https://discourse.llvm.org/t/rfc-enabling-the-hlfir-lowering-by-default/72778/7.
All the modified tests are still here since coverage for the direct
lowering to FIR was still needed while it was default. Some already have
an HLFIR version, some have not and will need to be ported in step 2
described in the RFC.
Note that another 147 lit tests use -emit-fir/-emit-llvm outputs but do
not need a flag since the HLFIR/no HLFIR output is the same for what is
being tested.
Change the separator in the `uniqueCGIdent` method to `X`. This change
is required to enable OpenMP offloading for the NVPTX target, as dots
are not valid identifiers in PTX and `uniqueCGIdent` is used to mangle
some literals. Follow up patches will change the remainder of `.`
appearances in names to `X` and add support for the NVPTX target.
Fixes https://github.com/llvm/llvm-project/issues/67658
The bug was that when instantiating a character array result variable,
the code inserted a cast from the result buffer to the proper array type
if it could see an fir.unboxchar op. But this is wrong for results and
on caller side because the fir.emboxchar is visible so,
charHelper.genUnboxChar() just takes the operand from that instead of
generating an unboxchar.
The fix is simply to move the cast at the place where fir.boxchar<>
argument are dealt with. The cast when creating fir.emboxchar is also
removed: it adds noise and causes constant length result type to be
lowered to fir.char<?>.
The main change from this patch is to deal with the lit test fallout of
this cast move and removal.
When folding a binary operation between two array constructors, it
is necessary to check if each value contained in the left operand
has the same rank and shape as the one on the right.
Otherwise, lowering would end up with an operation between values
of different ranks/shapes, which could result in a crash.
For instance, the following code was crashing the compiler:
integer :: x(4), y(2, 2), z(4)
z = (/x/) + (/y/)
Fixes#60229
Reviewed By: klausler, jeanPerier
Differential Revision: https://reviews.llvm.org/D147181
When generating character assignment operations, the generic code
generates some code to handle truncation and padding when the length
differ at runtime. A bypass already exists when the length are compile
time constant and match, but it was not used for the trivial case where
the RHS and LHS length is the same SSA value. In such case, even though,
the length is not know at compile time, it is known to be the same.
This will simplify the code creating character temporaries from a
variable in HLFIR that will use this assignment code.
Note that this probably has little impact on performance (llvm may be clever enough
to later catch that for us). But it makes the generated IR a lot more readable at
little cost.
Differential Revision: https://reviews.llvm.org/D139330
In order to emit overflow warnings from assignment statements whose
right-hand sides are constants that undergo conversions, run the
right-hand sides of assignments through constant folding after the
conversions have been made explicit in expression analysis.
Differential Revision: https://reviews.llvm.org/D139151
Following RFC at
https://discourse.llvm.org/t/rfc-ffp-contract-default-value/66301
This adds the `fastmath<contract>` attribute to `fir.call` and some
floating point arithmetic operations (hence the many test changes).
Instead of testing for this specific attribute, I am using a regular
expression to match any attributes.
Programmers may use procedure without BIND(C) attribute to interoperate
with C code. For numerical/logical scalar with VALUE attribute, pass the
argument by value so that the behavior is consistent with gfortran or
nvfortran. The argument with the OPTIONAL attribute cannot be passed by
value since the actual argument may be absent.
For the derived type, pass-by-value is not supported yet, so pass the
argument by reference for now.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D136260
This patch creates a temporary of the appropriate length while lowering SetLength.
The corresponding character can be truncated or padded if necessary.
This fix issue with array constructor in argument and also with statement function.
D132464 was fixing the same issue in genval.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D132866
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
Add lowering tests left behind during the upstreaming.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D128721
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Flang is manually mangling names for memset/memcpy/memmove
intrinsics, so we need to update the mangling to use the opaque
pointer format (p0 instead of p0i8).
Follow up of https://reviews.llvm.org/D121488. Ensure lower bounds
are `1` when the related dimension extent is zero. Note that lower
bounds from descriptors are now guaranteed to fulfill this property
after the runtime/codegen patches.
Also fixes explicit shape array extent lowering when instantiating
variables to deal with negative extent cases (issue found while testing
LBOUND edge case). This notably caused allocation crashes when dealing
with automatic arrays with reversed bounds or negative size
specification expression. The standard specifies that the extent of such
arrays is zero. This change has some ripple effect in the current lit
tests.
Add move two helpers as part of this change:
- Add a helper to tell if a fir::ExtendedValue describes an assumed size
array (last dimension extent is unknown to the compiler, both at compile
time and runtime).
- Move and share getIntIfConstant from Character.cpp so that it can be
used elsewhere (NFC).
Differential Revision: https://reviews.llvm.org/D122467
This patch adds more lowering for array expressions.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D121952
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
