| Age | Commit message (Collapse) | Author |
|---|
|
Only add the option processing and store the result. No attributes are
added to FIR yet.
Differential Revision: https://reviews.llvm.org/D137330
|
|
Only add the option processing and store the result. No attributes are
added to FIR yet.
Clang only forwards -mreassociate
if (AssociativeMath && !SignedZeros && !TrappingMath)
Flang doesn't have -f[no-]trapping-math, so this part of the condition
has been omitted. !TrappingMath is the default.
Differential Revision: https://reviews.llvm.org/D137329
|
|
Only add the option processing and store the result. No attributes are
added to FIR yet.
Differential Revision: https://reviews.llvm.org/D137328
|
|
Only add the option processing and store the result. No attributes are
added to FIR yet.
Differential Revision: https://reviews.llvm.org/D137326
|
|
Only add the option processing and store the result. No attributes are
added to FIR yet.
Differential Revision: https://reviews.llvm.org/D137325
|
|
Differential Revision: https://reviews.llvm.org/D137287
|
|
This design document proposes lowering FIR complex number operations
through the MLIR complex dialect.
Differential Revision: https://reviews.llvm.org/D134364
|
|
When the `type(c_ptr/c_funptr)` argument has value attribute in non-BIND(C)
procedure, it is passed by VALUE in gfortran. ifort does not do this. Be
consistent with gfortran.
Fix #58756.
Reviewed By: PeteSteinfeld, jeanPerier
Differential Revision: https://reviews.llvm.org/D137237
|
|
When the function result is `type(c_ptr/c_funptr)`, and the function has
or does not have BIND(C) attribute, the function result is not taken as
the first argument of the function call in other compilers such as
gfortran and ifort. Fix it to be consistent with gfortran/ifort by
changing the abstract result type check.
Fix #58739.
Reviewed By: PeteSteinfeld, jeanPerier
Differential Revision: https://reviews.llvm.org/D137236
|
|
Update the already existing fir.select_type operation to
reflect decisions made in the polymorphic entities design document.
The verifier is updated to check that the select is polymorphic.
The case attributes name are changed and some tests are added.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D137403
|
|
Runtime call to PointerNullifyDerived or AllocatableInitDerived
should only be generated for derived-type allocation of polymorphic entities.
With unlimited polymorphic entities, it is possible that the type spec is not
a derived-type. Avoid failure in that case.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D137353
|
|
After submitting the DataLayout fix, some tests fail when they didn't
before. This has to do with the target essentially being ignored when
these tests were run earlier, as the --target x86-unknown-linux-gnu
only has to be correctly formed to be accepted.
Now the target triple is actually being used to get the targetmachine
earlier - before MLIR is generated - so the test that has a valid target
but not available on the platform fails.
Fix is to require x86 registered target when running those tests.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D137335
|
|
|
|
This will make it easier for me to do reviews.
Differential Revision: https://reviews.llvm.org/D137291
|
|
So far the function argument attributes were only translated
for functions with bodies. This change makes sure that this
happens for functions without bodies (declarations) as well.
This is needed for https://github.com/llvm/llvm-project/issues/58579
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D137047
|
|
In D134622 the printed form of a pass manager is changed to include the
name of the op that the pass manager is anchored on. This updates the
`-pass-pipeline` argument format to include the anchor op as well, so
that the printed form of a pipeline can be directly passed to
`-pass-pipeline`. In most cases this requires updating
`-pass-pipeline='pipeline'` to
`-pass-pipeline='builtin.module(pipeline)'`.
This also fixes an outdated assert that prevented running a
`PassManager` anchored on `'any'`.
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D134900
|
|
The earlier available datalyaout allows MLIR to LLVM-IR transformation
to use the datalayout for decisions, such as comparing sizes for
different types of integers.
This should solve https://github.com/llvm/llvm-project/issues/57230
Reviewed By: awarzynski, vzakhari
Differential Revision: https://reviews.llvm.org/D133568
|
|
Only add the option processing and store the result. No attributes are
added to FIR yet.
This patch follows Clang in forwarding -fno-honor-infinities as
-menable-no-infs.
Reviewed By: kiranchandramohan awarzynski vzakhari
Differential Revision: https://reviews.llvm.org/D137072
|
|
This change-set defines the LoweringOptions the same way
other options are defined in Flang.
Differential Revision: https://reviews.llvm.org/D137207
|
|
This document aims to give insights at the representation of procdure
pointers in FIR.
Reviewed By: PeteSteinfeld, jeanPerier, kiranchandramohan
Differential Revision: https://reviews.llvm.org/D136840
|
|
|
|
Fix path that generates MutableBox for
pointer component.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D137270
|
|
This is required for D126305 code to propagate fastmath attributes
for Arith operations that are converted to LLVM IR intrinsics
operations.
LLVM IR intrinsic operations are using custom assembly format now
to avoid printing {fastmathFlags = #llvm.fastmath<none>}, which
is too verbose.
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D136225
|
|
When a fir.dispatch is done with a NOPASS type-bound
procedure, the object in fir.dispatch is just used to gather the vtable.
Therefore, no transformation is done on it and the original entity
is used. The current code generation didn't expect the entity to be an array.
This patch update the code generation to be able to retrieve the vtable
accordingly.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D137255
|
|
This reverts commit 870fbf8e300f3012470593ac087219a04d52857f.
|
|
Flang build on windows with MSVC environment and clang-cl compiler
requires clang_rt.builtin.${target} library. This patch allows us to
locate and include this link library. This is mostly needed for flang
runtime and associated unittests. Clang implicitly uses this library
while calling lld-link via clang driver however a standalone call to
lld-link doesnt link against clang_rt library on its own.
Differential Revision: https://reviews.llvm.org/D137112
|
|
Use the utility to lower Constant<T> that was split from current lowering
in https://reviews.llvm.org/D136955.
The difference in HLFIR is the addition of a fir.declare on constant
outlined in memory so that all the information about them is available.
Lowering to HLFIR is enabled in Brideg::genExprValue to allow testing
of scalar constant lowering.
Differential Revision: https://reviews.llvm.org/D137084
|
|
Add the atomic subroutine, atomic_or, to the list of
intrinsic subroutines, add its last dummy argument to a check
for a coindexed-object, and update test.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D137097
|
|
This patch forces pointer and allocatable polymorphic entities to be
tracked as descriptor. It also enables the pointer assignment between
polymorphic entities. Pointer association between a non-polymorphic
pointer and a polyrmophic target might require some more work as
per 10.2.2.3 point 1.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D137150
|
|
When a floating-point exception occurs while folding an exponentiation
operation with a host library at compilation time, the warning message
should not say that it was an "intrinsic function".
Differential Revision: https://reviews.llvm.org/D137030
|
|
simd aligned construct is represented as pair of variable which needs
to be aligned and corresponding alignment value.
Added parser, printer and verifier of aligned clause. MLIR tests were
updated to test correctness of MLIR definition of aligned clause.
Differential Revision: https://reviews.llvm.org/D135865
Reviewed By: kiranchandramohan
|
|
Recode a non-short-circuiting conjunction of two Boolean function calls
into separate statements to avoid a warning from clang 16.
|
|
The infrastructure in semantics that is used to check that the
left-hand sides of normal assignment statements are really definable
variables was not being used to check whether the LHSs of pointer assignments
are modifiable, and so most cases of unmodifiable pointers are left
undiagnosed. Rework the semantics checking for pointer assignments,
NULLIFY statements, pointer dummy arguments, &c. so that cases of
unmodifiable pointers are properly caught. This has been done
by extracting all the various definability checking code that has
been implemented for different contexts in Fortran into one new
facility.
The new consolidated definability checking code returns messages
meant to be attached as "because: " explanations to context-dependent
errors like "left-hand side of assignment is not definable".
These new error message texts and their attached explanations
affect many existing tests, which have been updated. The testing
infrastructure was extended by another patch to properly compare
warnings and explanatory messages, which had been ignored until
recently.
Differential Revision: https://reviews.llvm.org/D136979
|
|
Many intrinsic functions in Fortran require that two or more of their
arguments have types that agree in the values of all of their type
parameters, while others only require the same type category and kind
type parameters but not lengths, including the important case of
CHARACTER. The intrinsic procedure tables need to be adjusted in
some cases so that discrepancies in character lengths that are known
at compilation time can be diagnosed as errors where they should be,
as in for example MOVE_ALLOC().
Differential Revision: https://reviews.llvm.org/D137032
|
|
function pointers
There are some exceptional cases where the compiler permits association of
procedure pointers or dummy arguments with slightly incompatible procedure
targets, but they should not override any incompatibilty of function
result types.
(Includes a second fix to resolve the original motivating test failure, in
which a COMPLEX intrinsic function was getting its result kind divided by
two due to an implicit C++ conversion of the kind to a "*kind" parse tree
node, and those legacy "COMPLEX*size" type designators' values are twice
the type kind value.)
Differential Revision: https://reviews.llvm.org/D136964
|
|
Add the atomic subroutine, atomic_and, to the list of
intrinsic subroutines, add its last dummy argument to a check
for coindexed-object, and update test.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D136907
|
|
This patch fix issues found during call to deallocate.
fir.class can be handled the same way as fir.box in fir.store operation
code generation. In MutableBox::createNewFirBox, the fir.class is
also already a boxed entity.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D137079
|
|
This patch moves intrinsic evaluate::Constant<T> lowering into its own
unit outside of ScalarExpr and genarr lowering so that it can
be used by the new lowering without any changes.
DerivedType lowering cannot be shared at that stage because it is too
correlated with the current lowering (requires structure constructor
and designator lowering).
The code had to be refactored quite a bit so that it could be carved
out, but the only "functional" change is that the length of character
arrays lowered by genarr is now `index` instead of `i64` (see test change).
One non-functional benefit of the change is that `toEvExpr` is not
needed anymore and some compile time copies of big constant arrays
that it was causing are removed (see old calls in previous genarr code),
although I am not sure any compile time speed-ups are visible here.
Differential Revision: https://reviews.llvm.org/D136955
|
|
The runtime function `AllocatableDeallocate/PointerDeallocate` is reponsible to
deallocate and finalize it. This patch just adds tests to make sure the correct
runtime function is called.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D137068
|
|
Only add the option processing and store the result. No attributes are
added to FIR yet.
Only the "off" and "fast" options are supported. "fast-honor-pragmas" is not applicable because we do not implement `#pragma clang fp contract()` in Fortran [1]. "on" is not supported because it is unclear how to fuse only within individual statements. gfortran also does not implement "on": treating it as an "off".
Currently the default value is "off" to preserve existing behavior. gfortran uses "fast" by default and that may be the right thing for flang-new after further discussion in the future, but that can be changed separately. gfortran's documentation is available [[ https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html | here ]].
[1] https://clang.llvm.org/docs/LanguageExtensions.html#extensions-to-specify-floating-point-flags
Reviewed By: vzakhari, awarzynski
Differential Revision: https://reviews.llvm.org/D136080
|
|
Fortran standard 7.3.2.3 point 7 mentions that a diassociated
pointer dynamic type is its declared type.
in 9.7.2 note 1, when a NULLIFY statement is applied to a polymorphic pointer,
its dynamic type becomes the same as its declared type.
This patch enforce these standard points by calling the runtime function
`PointerNullifyDerived` with the declared type descriptor.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D136948
|
|
fir.dispatch codegen was done in D136189.
|
|
Previously an error raised during an expansion of response files (including
configuration files) was ignored and only the fact of its presence was
reported to the user with generic error messages. This made it difficult to
analyze problems. For example, if a configuration file tried to read an
inexistent file, the error message said that 'configuration file cannot
be found', which is wrong and misleading.
This change enhances handling errors in the expansion so that users
could get more informative error messages.
Differential Revision: https://reviews.llvm.org/D136090
|
|
call them
A statement function in Fortran may be called, but it may not be the target
of a procedure pointer or passed as an actual argument.
|
|
Some of the circumstances that require that a procedure have an
explicit interface at a point of call due to a characteristic of
a dummy argument apply to dummy procedures, too.
Differential Revision: https://reviews.llvm.org/D136994
|
|
Disable the test that corresponds to a semantic check that was
disabled to work around an MSVC build problem.
|
|
A Fortran program may not specify a particular attribute multiple
times for the same entity in a scope.
Differential Revision: https://reviews.llvm.org/D136991
|
|
When a dummy argument is a procedure pointer without INTENT(IN),
any actual argument must also be a procedure pointer, whether the
dummy procedure pointer's interface is explicit or not.
Differential Revision: https://reviews.llvm.org/D136989
|
|
definition scope
We implemented 19.3.4p1 literally in name resolution:
A component name has the scope of its derived-type definition. Outside the type definition,
it may also appear within a designator of a component of a structure of that type or as a
component keyword in a structure constructor for that type.
and within the derived-type definition would resolve the "bare"
names of components in specification inquiries and other contexts to
those components, not to any symbols in the enclosing scopes.
It turns out that most Fortran compilers resolve only "bare" names thus
when they are type parameters, and the names of data and procedure components
do not shadow exterior symbols. Adjust name resolution to follow that
precedent rather than what seems to be clear language in the standard.
Differential Revision: https://reviews.llvm.org/D136984
|
|
Make a requested change to the wording of a fatal I/O error
message.
Differential Revision: https://reviews.llvm.org/D136984
|
