[Flang] Revert "Allow Intrinsic simpification with min/maxloc dim
and…scalar result (#76194)"
This reverts commit 9b7cf5bfb08b6e506216ef354dfd61adb15acbff.
See merge request #76194.
This change was causing several failures in our internal tests. I'm
reverting now and will work on creating a test that David Green can use
to reproduce the problem.
Add `notify-type` to `iso_fortran_env` module. Add `notify-wait-stmt` to
the parser and add checks for constraints on the statement, `C1177` and
`C1178`, from the Fortran 2023 standard. Add three semantics tests for
`notify-wait-stmt`.
When an input data-list has more items than can be read by a format from
the input record (e.g., "(4I5)" reading "1 2"), don't return false from
EditIntegerInput() just because nothing was read -- that will prevent
later items from being set to zero, as they should be. Return true
unless nothing was read and there is some kind of error pending.
Fixes llvm-error-tests/Fortran/gfortran/regression/pr478478.f90.
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.
The code to fold NEAREST would return a value that's too large when
transitioning from a normal number to a subnormal.
Fixes llvm-test-suite/Fortran/gfortran/regression/nearest_1.f90.
Fortran 2023 subclause 13.7.2.3.8 discusses input rounding only in the
context of decimal-to-binary conversion. There is no mention of rounding
for hexadecimal floating-point input conversion. At least one Fortran
compiler seems to have interpreted this silence as implying no rounding.
(Note that this is not the same thing as rounding to zero (RZ), which
would return +/-HUGE() for overflow.)
Nearly every Fortran compiler supports the extension of NAMELIST input
into a storage sequence identified by its initial scalar array element.
For example,
&GROUP A(1) = 1. 2. 3. /
should be processed as if the input had been
&GROUP A(1:) = 1. 2. 3. /
Fixes llvm-test-suite/Fortran/gfortran/regression/namelist_24.f90.
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.
The compiler requires that a Cray pointee have a SEQUENCE type, but a
recent bug report points out that a BIND(C) type should also be
accepted.
Fixes https://github.com/llvm/llvm-project/issues/76529.
When parsing a deeply-nested expression like
A1(A2(A3(A4(A5(A6(...A99(i)...))))))
the parser can get into an exponential state due to the need to consider
the possibility that each "An(...)" might be the beginning of a
reference to a procedure component ("An(...)%PROC(...)") so that
alternative has to be attempted first before proceeding to try parsing
"An(...)" as a function reference or as an array element designator. The
parser for a structure component, which is used by the procedure
designator parser, was not protected with the usual failure memoization
technique, leading to exponentially bad behavior parsing a deeply-nested
expression. Fix by exploiting the instrumented() parser combinator so
that failed structure component parsers aren't repeated.
Fixes https://github.com/llvm/llvm-project/issues/76477.
Initializers in entity-decls don't need to have their expressions
analyzed immediately in name resolution unless of course they are
defining the values of named constants. By deferring the expression
analysis, the compiler can better handle references to module and
internal procedures that might appear in structure constructors; at
present, these are typically rejected as being forward references (which
they can be) to subprogram names that can't yet be checked for
compatibility with the characteristics of the corresponding procedure
component.
This makes an adjustment to the existing fir minloc/maxloc generation
code to handle functions with a dim=1 that produce a scalar result. This
should allow us to get the same benefits as the existing generated
minmax reductions.
This is a recommit of #75820 with the typename added to the generated
function.
Shift the data from lower to higher order bits when memcpy the value in
the namelist in the big endian environment
---------
Co-authored-by: Mark Danial <mark.danial@ibm.com>
Co-authored-by: Kelvin Li <kli@ca.ibm.com>
The compiler doesn't USE-associate names of intrinsic procedures from
modules (in the absence of ONLY:), so that the associating scope doesn't
get populated with names of intrinsics that were used only in
declarations (e.g., SELECTED_REAL_KIND). A recent bug report (below)
shows that we should modify that policy in the case of names that appear
in explicit INTRINSIC attribute statements. The behaviors of other
Fortran compilers are not consistent and the requirements of the
standard are not clear; this fix follows the precedent set by gfortran
and nvfortran.
Fixes https://github.com/llvm/llvm-project/issues/72084.
When rounding what otherwise would have been a result that underflowed
to zero up (RU) or down (RD) to the least magnitude nonzero subnormal
number, ensure that the original exponent value doesn't perturb the
result.
The Fortran standard says that overflow input cases in some rounding
modes (RZ, RD, RU) should round to a "representable" number. Some
Fortran compilers interpret this to mean +/-HUGE(), some as +/-Inf.
Follow the precedent of gfortran and the Intel compilers.
If list-directed input contains a repeated item ("20*123.0") that is not
fully consumed by the READ statement's data item list, the end of that
READ statement was repositioning the input to the repeated value
("123.0"), leading to later confusion. Cancel the input item repetition
during EndIoStatement() processing to prevent this misbehavior.
Fixes llvm-test-suite/Fortran/gfortran/regression/list_read_4.f90.
When the result of NEAREST() has an exponent less than that of the
argument (e.g., NEAREST(1.,-1.) and NEAREST(-1.,1.)), the result was
wrong, because the increment value uses the result of SPACING() in terms
of the argument. Fix by just calling into the C runtime routine
std::nextafter().
When generalized numeric output editing of real data maps to Fw.d output
editing, either two or four trailing blanks are emitted depending on the
presence and value of 'e'. The code that detects field width overflow
didn't take these trailing blanks into account, and sometimes the field
width adjustment was producing an F0.d output edit descriptor (no fixed
field width). Fix by retaining the original field width, but requiring
it to also accommodate the trailing blanks.
Fixes llvm-test-suite/Fortran/gfortran/regression/fmt_g.f.
When FINDLOC() can't find its target value among the unmasked array
elements, it must return a zero result. Its implementation doesn't
sufficiently distinguish a zero result from a hit in an array with lower
bound(s) less than one. Fix by adding a flag to distinguish the case
with no hits from cases with hits.
Fixes llvm-test-suite/Fortran/gfortran/regression/findloc_6.f90.
It would surprise me if this case ever arose outside a couple of tests
in llvm-test-suite/Fortran/gfortran/regression (namely
cshift_large_1.f90 and eoshift_large_1.f90), but now at least those
tests will pass.
A zero 'd' digit count in EX output editing has a meaning that's
distinct from other numeric output editing descriptors, and I missed
this in my initial implementation of the feature. d==0 means that the
runtime should emit hexadecimal digits after the (hexa)decimal point
until all of the rest of them would be zero.
At present, when building static or shared libraries, Flang adds
`-lFortran_main.a` (or `/WHOLEARCHIVE:Fortran.*.lib` pon Windows) to the
link line. This leads to the problem that `_QQmain` and
`_QQEnvironmentDefaults` (as of the time of this PR) are symbols marked
as used, while `main` is being defined. This should not happen and this
PR fixes this by detecting if `-shared` or `-static` is used on the
Flang command line and removing the static `Fortran_main` library.
---------
Co-authored-by: kkwli <kkwli@users.noreply.github.com>
Emits MLIR op corresponding to `!$omp target update` directive. So far,
only motion types: `to` and `from` are supported. Motion modifiers:
`present`, `mapper`, and `iterator` are not supported yet.
This is a follow up to #75047 & #75159, only the last commit is relevant
to this PR.
C_FUNLOC was not handling procedure pointer argument correctly, the
issue lied in `hlfir::convertToBox` that did not handle procedure
pointers.
I modified the interface of `hlfir::convertToXXX` to take values on the
way because hlfir::Entity are fundamentally an mlir::Value with type
guarantees, so they should be dealt with by value as mlir::Value are
(they are very small).
This is a lot less complex than the data case where the shape has to be
accounted for, so the implementation is done inline.
One corner case will not be supported correctly for now: the case where
POINTER and TARGET points to the same internal procedure may return
false because lowering is creating fir.embox_proc each time the address
of an internal procedure is taken, so different thunk for the same
internal procedure/host link may be created and compare to false. This
will be fixed in a later patch that moves creating of internal procedure
fir.embox_proc in the host so that the addresses are the same when the
host link is the same. This change is required to properly support the
required lifetime of internal procedure addresses anyway (should be the
always be the lifetime of the host, even when the address is taken in an
internal procedure).
… scalar result. (#75820)"
This reverts commit 701f64790520790f75b1f948a752472d421ddaa3.
The commit breaks some uses of the 'maxloc' intrinsic.
See PR #75820
This patch fixes:
flang/lib/Optimizer/Transforms/StackArrays.cpp:452:7: error:
ignoring return value of function declared with 'nodiscard'
attribute [-Werror,-Wunused-result]
The AIX linker does not support the `--whole-archive` option, removing
the option if the OS is AIX.
---------
Co-authored-by: Mark Danial <mark.danial@ibm.com>
Add a new test for no-cpp-dep on AIX as it requires 64 bit OBJECT_MODE
since only 64-bit AIX is supported. AIX does not allow `-o /dev/null`
and requires `-lpthread` flag to be added.
---------
Co-authored-by: Mark Danial <mark.danial@ibm.com>
Re-land PR after being reverted because of buildbot failures.
This patch adds representation for `device_type` clause information on
compute construct (parallel, kernels, serial).
The `device_type` clause on compute construct impacts clauses that
appear after it. The values impacted by `device_type` are now tied with
an attribute array that represent the device_type associated with them.
`DeviceType::None` is used to represent the value produced by a clause
before any `device_type`. The operands and the attribute information are
parser/printed together.
This is an example with `vector_length` clause. The first value (64) is
not impacted by `device_type` so it will be represented with
DeviceType::None. None is not printed. The second value (128) is tied
with the `device_type(multicore)` clause.
```
!$acc parallel vector_length(64) device_type(multicore) vector_length(256)
```
```
acc.parallel vector_length(%c64 : i32, %c128 : i32 [#acc.device_type<multicore>]) {
}
```
When multiple values can be produced for a single clause like
`num_gangs` and `wait`, an extra attribute describe the number of values
belonging to each `device_type`. Values and attributes are
parsed/printed together.
```
acc.parallel num_gangs({%c2 : i32, %c4 : i32}, {%c4 : i32} [#acc.device_type<nvidia>])
```
While preparing this patch I noticed that the wait devnum is not part of
the operations and is not lowered. It will be added in a follow up
patch.
This patch adds representation for `device_type` clause information on
compute construct (parallel, kernels, serial).
The `device_type` clause on compute construct impacts clauses that
appear after it. The values impacted by `device_type` are now tied with
an attribute array that represent the device_type associated with them.
`DeviceType::None` is used to represent the value produced by a clause
before any `device_type`. The operands and the attribute information are
parser/printed together.
This is an example with `vector_length` clause. The first value (64) is
not impacted by `device_type` so it will be represented with
DeviceType::None. None is not printed. The second value (128) is tied
with the `device_type(multicore)` clause.
```
!$acc parallel vector_length(64) device_type(multicore) vector_length(256)
```
```
acc.parallel vector_length(%c64 : i32, %c128 : i32 [#acc.device_type<multicore>]) {
}
```
When multiple values can be produced for a single clause like
`num_gangs` and `wait`, an extra attribute describe the number of values
belonging to each `device_type`. Values and attributes are
parsed/printed together.
```
acc.parallel num_gangs({%c2 : i32, %c4 : i32}, {%c4 : i32} [#acc.device_type<nvidia>])
```
While preparing this patch I noticed that the wait devnum is not part of
the operations and is not lowered. It will be added in a follow up
patch.
