The HUGE definition collides with the HUGE macro from math.h. Unlike the
fix in 3149c934cb26 (#84478) (largely reverted in f95710c76519), add
another #undef HUGE since there is no practical way to make FreeBSD's
headers not define HUGE and still define XSI interfaces such as isascii
or strnlen.
Update comments above `#undef HUGE` instances to reflect the fact that
all major BSD versions (I checked DragonFly, FreeBSD, NetBSD, and
OpenBSD) leak the HUGE macro from math.h to various degrees.
Fixes#86038
Address TODOs in the intrinsic module ISO_FORTRAN_ENV, and extend the
implementation of NUMERIC_STORAGE_SIZE so that the calculation of its
value is deferred until it is needed so that the effects of
-fdefault-integer-8 or -fdefault-real-8 are reflected. Emit a warning
when NUMERIC_STORAGE_SIZE is used from the module file and the default
integer and real sizes do not match.
Fixes https://github.com/llvm/llvm-project/issues/87476.
Select POSIX 2008 standard to avoid including Darwin extensions.
Otherwise, Darwin's math.h header defines HUGE, which conflicts
with Flang's HUGE function.
This started happening after 4762c6557d15 (#82443), that added the
"utility" include, which seems to include "math.h".
Don't rewrite 0*X to 0 if X is not scalar. Up until now this hasn't
shown up as a bug because a scalar 0 works in nearly all expressions
where an array would be expected. But not in all cases -- this bad
rewrite can cause generic procedure resolution to fail when it causes an
actual argument to have an unsupported rank.
We support specific intrinsic calls like `AMAX0(1.0,2)` that have
heterogeneous argument types as an optional extension in cases where the
specific intrinsic has a related generic intrinsic function capable of
handling the argument types. This feature can't be allowed to apply to
calls where the result of the related generic intrinsic function is not
convertible to the type of the specific intrinsic, as in `AMAX0('a',
'b')`.
Fixes https://github.com/llvm/llvm-project/issues/78932.
PR #68342 causes build breakage on MacOS due to uint64_t being defined
as unsigned long long instead of unsigned long. It leads to type
mismatch in the arguments for std::min.
TotalElementCount() was modified to return std::optional<uint64_t>,
where std::nullopt means overflow occurred. Besides the additional
check in RESHAPE folding, all callers of TotalElementCount() were
changed, to also check for overflows.
Fortran allows an earlier-declared KIND type parameter of a parameterized
derived type to be used in the constant expression defining the integer
kind of a later type parameter.
TYPE :: T(K,L)
INTEGER, KIND :: K
INTEGER(K), LEN :: L
...
END TYPE
Differential Revision: https://reviews.llvm.org/D159044https://reviews.llvm.org/D159044
Generalize FoldMerge() to accommodate derived type arguments and results,
rename it into Folder<T>::MERGE(), and remove it from the various
FoldIntrinsicFunction() routines for intrinsic types.
Fixes llvm-test-suite/Fortran/gfortran/regression/merge_init_expr_2.f90.
Differential Revision: https://reviews.llvm.org/D157345
The folding of conversions of character arrays from one kind to
another was not preserving the value of the character length expression
on the intermediate array constructor, causing spurious errors
when defining named constant arrays of one kind of character with
arrays of another kind.
Fixes llvm-test-suite/Fortran/gfortran/regression/widechar_10.f90.
Differential Revision: https://reviews.llvm.org/D157340
Work through several issues with LBOUND() and UBOUND() of ASSOCIATE
construct entities that have been associated with named constants or
subobjects of named constants that are sporting non-default lower bounds.
Sometimes the non-default lower bounds matter, sometimes they don't.
Add a fairly exhaustive test to work through the possibilities.
Differential Revision: https://reviews.llvm.org/D156756
Expression folding currently unconditionally rewrites "1*j"
to "j", which is wrong when "j" is a variable, as it transforms
an expression into a variable and can lead to incorrect associations
in contexts like an actual argument or an ASSOCIATE selector.
Transform "1*j" to a parenthesized "(j)" when "j" is a variable.
Fixes LLVM bug https://github.com/llvm/llvm-project/issues/63259.
Differential Revision: https://reviews.llvm.org/D153457
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
The semantics of many transformational intrinsic functions, especially
reductions like SUM(), are determined by the static presence or absence
of a DIM= argument. In the case of an actual DIM= argument that is
syntactically present but could be dynamically absent at execution time
(due to being OPTIONAL, POINTER, or ALLOCATABLE), f18 should emit some
kind of diagnostic message.
Other compilers either ignore this possibility or treat it as a hard
error; neither really seems correct, so let's do something more nuanced.
For cases where the dynamic absence of a value for DIM doesn't pose
as much of a risk because it lowering is going to assume that it's
equal to 1 anyway, emit only a portability warning.
For other cases where the generated code or runtime support library
will need the value of DIM= during execution, emit a warning that
the use of an OPTIONAL/POINTER/ALLOCATABLE variable or component
here is dicey and should be reconsidered.
While here, also catch bad constant DIM= values.
Differential Revision: https://reviews.llvm.org/D139155
The internal representation for array constructors in expressions during semantic
analysis needs to be able to accommodate circumstances (e.g. TRIM(), substrings)
in which the length of the elements in the array is either unknown or cannot be
represented as a context-free integer expression.
Differential Revision: https://reviews.llvm.org/D139041
When a scalar expression is not expandable -- i.e., it would have to be
evaluated once and saved in a temporary to avoid changing the semantics
of the program if it were to be evaluated more than once -- it affects
some aspects of folding and expression semantics. In cases where
scalar expansion would not cause multiple evaluations due to the shape
of the result having but a single element, however, these "non-expandable"
scalar expressions can be safely allowed.
Differential Revision: https://reviews.llvm.org/D134476
When a subexpression does not have both constant elements and
a constant shape, folding is rewriting it into a vector of its
elements. This is of course wrong when the shape shows that
the result has rank greater than 1.
Differential Revision: https://reviews.llvm.org/D134392
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
Create a TargetCharacteristics class to centralize the few items of
target specific information that are relevant to semantics. Use the
new class for all target queries, including derived type component layout
modeling.
Future work will initialize this class with target information
provided or forwarded by the drivers, and use it to fold layout-dependent
intrinsic functions like TRANSFER().
Differential Revision: https://reviews.llvm.org/D129018
Updates: Attempts to work around build issues on Windows.
When processing the literal constants of the various kinds of
INTEGER that are too large by 1 (e.g., 2147483648_4) in expression
analysis, emit a portability warning rather than a fatal error if
the literal constant appears as the operand to a unary minus, since
the folded result will be in range. And don't emit any warning if
the negated literal is coming from a module file -- f18 wrote the
module file and the warning would simply be confusing, especially to
the programmer that wrote (-2147483647_4-1) in the first place.
Further, emit portability warnings for the canonical expressions for
infinities and NaN (-1./0., 0./0., & 1./0.), but not when they appear
in a module file, for the same reason. The Fortran language has no
syntax for these special values so we have to emit expressions that
fold to them.
Fixes LLVM bugs https://github.com/llvm/llvm-project/issues/55086 and
https://github.com/llvm/llvm-project/issues/55081.
Differential Revision: https://reviews.llvm.org/D126584
Complex component references (z%RE, z%IM) of complex named constants
should be evaluated at compilation time.
Differential Revision: https://reviews.llvm.org/D125341
The construction of the dimension order vector used to populate the
result array was incorrect, leading to a scrambled-looking result
for rank-3 and higher results. Fix, and extend tests.
Differential Revision: https://reviews.llvm.org/D125113
Adds flang/include/flang/Common/log2-visit.h, which defines
a Fortran::common::visit() template function that is a drop-in
replacement for std::visit(). Modifies most use sites in
the front-end and runtime to use common::visit().
The C++ standard mandates that std::visit() have O(1) execution
time, which forces implementations to build dispatch tables.
This new common::visit() is O(log2 N) in the number of alternatives
in a variant<>, but that N tends to be small and so this change
produces a fairly significant improvement in compiler build
memory requirements, a 5-10% improvement in compiler build time,
and a small improvement in compiler execution time.
Building with -DFLANG_USE_STD_VISIT causes common::visit()
to be an alias for std::visit().
Calls to common::visit() with multiple variant arguments
are referred to std::visit(), pending further work.
This change is enabled only for GCC builds with GCC >= 9;
an earlier attempt (D122441) ran into bugs in some versions of
clang and was reverted rather than simply disabled; and it is
not well tested with MSVC. In non-GCC and older GCC builds,
common::visit() is simply an alias for std::visit().
Adds flang/include/flang/Common/visit.h, which defines
a Fortran::common::visit() template function that is a drop-in
replacement for std::visit(). Modifies most use sites in
the front-end and runtime to use common::visit().
The C++ standard mandates that std::visit() have O(1) execution
time, which forces implementations to build dispatch tables.
This new common::visit() is O(log2 N) in the number of alternatives
in a variant<>, but that N tends to be small and so this change
produces a fairly significant improvement in compiler build
memory requirements, a 5-10% improvement in compiler build time,
and a small improvement in compiler execution time.
Building with -DFLANG_USE_STD_VISIT causes common::visit()
to be an alias for std::visit().
Calls to common::visit() with multiple variant arguments
are referred to std::visit(), pending further work.
Differential Revision: https://reviews.llvm.org/D122441
Using recently established message severity codes, upgrade
non-fatal messages to usage and portability warnings as
appropriate.
Differential Revision: https://reviews.llvm.org/D121246
The index incrementation code used for FINDLOC, MAXLOC, and MINLOC folding
would crash if the array had a zero extent on the dimension selected with
a DIM= argument since the subscript passed to IncrementSubscripts would
have a value less than the lower bound. Fix, and add tests.
Differential Revision: https://reviews.llvm.org/D121125
Character substrings weren't being folded correctly;
add tests and rework the implementation so that substrings
of literals and named constant character scalars & arrays
are properly folded for use in constant expressions.
Differential Revision: https://reviews.llvm.org/D117343
Array constructors with implied DO loops that oversee structure
constructors were being prematurely folded into invalid constants
containing symbolic references to the ac-implied-do indices,
because they are indeed "constant expressions" as that term is
used in the Fortran standard and implemented as IsConstantExpr().
What's actually needed in structure constructor folding is a
test for actual constant values, which is what results from
folding them later with repetition in the context of folding
an ac-implied-do.
Differential Revision: https://reviews.llvm.org/D115470
Complete folding of the intrinsic reduction function COUNT() for all
cases, including partial reductions with DIM= arguments.
Differential Revision: https://reviews.llvm.org/D109911
ApplyElementwise on character operation was always creating a result
ArrayConstructor with the length of the left operand. This is not
correct for concatenation and SetLength operations.
Compute and thread the length to the spot creating the ArrayConstructor
so that the length is correct for those character operations.
Differential Revision: https://reviews.llvm.org/D108711
Implement constant folding for the reduction transformational
intrinsic functions MAXVAL and MINVAL.
In anticipation of more folding work to follow, with (I hope)
some common infrastructure, these two have been implemented in a
new header file.
Differential Revision: https://reviews.llvm.org/D104337
To ensure that errors are emitted by CheckConformance and
its callers in all situations, it's necessary for the returned result
of that function to distinguish between three possible
outcomes: the arrays are known to conform at compilation time,
the arrays are known to not conform (and a message has been
produced), and an indeterminate result in which is not possible
to determine conformance. So convert CheckConformance's
result into an optional<bool>, and convert its confusing
Boolean flag arguments into a bit-set of named flags too.
Differential Revision: https://reviews.llvm.org/D103654
Andrezj W. @ Arm discovered that the runtime derived type table
building code in semantics was detecting fatal errors in the tests
that the f18 driver wasn't printing. This patch fixes f18 so that
these messages are printed; however, the messages were not valid user
errors, and the rest of this patch fixes them up.
There were two sources of the bogus errors. One was that the runtime
derived type information table builder was calculating the shapes of
allocatable and pointer array components in derived types, and then
complaining that they weren't constant or LEN parameter values, which
of course they couldn't be since they have to have deferred shapes
and those bounds were expressions like LBOUND(component,dim=1).
The second was that f18 was forwarding the actual LEN type parameter
expressions of a type instantiation too far into the uses of those
parameters in various expressions in the declarations of components;
when an actual LEN type parameter is not a constant value, it needs
to remain a "bare" type parameter inquiry so that it will be lowered
to a descriptor inquiry and acquire a captured expression value.
Fixing this up properly involved: moving some code into new utility
function templates in Evaluate/tools.h, tweaking the rewriting of
conversions in expression folding to elide needless integer kind
conversions of type parameter inquiries, making type parameter
inquiry folding *not* replace bare LEN type parameters with
non-constant actual parameter values, and cleaning up some
altered test results.
Differential Revision: https://reviews.llvm.org/D101001
Expressions emitted to module files and error messages
sometimes contain conversions of integer results of inquiry
intrinsics; these are usually not needed, and can conflict
with "int" in the user's namespace. Improve folding so that
these conversions don't appear, and do some other clean-up
in adjacent code.
Differential Revision: https://reviews.llvm.org/D95172
Elemental intrinsic function folding was not taking the lower
bounds of constant array arguments into account; these lower bounds
can be distinct from 1 when named constants appear as arguments.
LLVM bugzilla #48437.
Differential Revision: https://reviews.llvm.org/D93321
This patch plugs many holes in static initializer semantics, improves error
messages for default initial values and other component properties in
parameterized derived type instantiations, and cleans up several small
issues noticed during development. We now do proper scalar expansion,
folding, and type, rank, and shape conformance checking for component
default initializers in derived types and PDT instantiations.
The initial values of named constants are now guaranteed to have been folded
when installed in the symbol table, and are no longer folded or
scalar-expanded at each use in expression folding. Semantics documentation
was extended with information about the various kinds of initializations
in Fortran and when each of them are processed in the compiler.
Some necessary concomitant changes have bulked this patch out a bit:
* contextual messages attachments, which are now produced for parameterized
derived type instantiations so that the user can figure out which
instance caused a problem with a component, have been added as part
of ContextualMessages, and their implementation was debugged
* several APIs in evaluate::characteristics was changed so that a FoldingContext
is passed as an argument rather than just its intrinsic procedure table;
this affected client call sites in many files
* new tools in Evaluate/check-expression.cpp to determine when an Expr
actually is a single constant value and to validate a non-pointer
variable initializer or object component default value
* shape conformance checking has additional arguments that control
whether scalar expansion is allowed
* several now-unused functions and data members noticed and removed
* several crashes and bogus errors exposed by testing this new code
were fixed
* a -fdebug-stack-trace option to enable LLVM's stack tracing on
a crash, which might be useful in the future
TL;DR: Initialization processing does more and takes place at the right
times for all of the various kinds of things that can be initialized.
Differential Review: https://reviews.llvm.org/D92783
COMPLEX negation, addition, subtraction, conversions of kind, and
equality/inequality were represented as component-wise REAL
operations. It turns out to be easier for lowering if we
do not split and recombine these COMPLEX operations, and it
avoids a potential problem with COMPLEX valued function calls
in these contexts. So add this suite of operations to the
typed expression representation in place of the component-wise
transformations, and support them in folding.
Differential revision: https://reviews.llvm.org/D91443
When comparing arrays whose shapes do not conform, the contant folding
code ran into problems trying to get the value of an extent that did not
exist. There were actually two problems. First, the routine
"CheckConformance()" was returning "true" when the compiler was unable
to get the extent of an array. Second, the function
"ApplyElementwise()" was calling "CheckConformance()" prior to folding
the elements of two arrays, but it was ignoring the return value.
Differential Revision: https://reviews.llvm.org/D91440
Patch D88695 introduces a new local variable inside a lambda with the same name as a variable outside of it. In some of the if constexpr regions, msvc prioritizes the outer declaration and emits the error.
```
C:\Users\meinersbur\src\llvm-project\flang\lib\Evaluate\fold-implementation.h(1200): error C3493: 'context' cannot be implicitly captured because no default capture mode has been specified
```
This is fixed by giving the inner variable a different name.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D89367
