Hi All,
Since the patch for PR102689 was committed, sporadic time outs at -O1 have
been recorded and so I have reverted the patch.
This is a bit awkward because I have yet to see the problem. However, I
will endeavour to understand what went wrong.
Paul
-- Forwarded message -
Fr
v3:
Changes:
(A) The 'ret_code' arguments of omp_get_interop_{int,ptr,str} are
actually 'optional'.
That's something that got lost in at some point between OpenMP 5.2 and
TR13 (I filed OpenMP spec Issue #4165 for it). When adding it, I noticed
that two '…_async' function lacked the '= NULL'
Oh, and I get compile errors:
/mnt/work_store/gcc/gcc.test/libgomp/target.c: In function
'omp_get_interop_type_desc':
/mnt/work_store/gcc/gcc.test/libgomp/target.c:5179:30: error: excess elements
in scalar initializer [-Werror]
5179 | "const char*", /* fr_name *
Hi all,
attached patch fixes an ICE during trans-phase when allocatable components in
derived typed coarrays were nested. I am nearly convinced, that the ICE is
mostly fixed by pr86468, because I get a slightly different ICE. Nevertheless
was the executable crashing with -fcoarray=lib because the
From: Mikael Morin
The documentation in this patch was partly reworded, compared
to the previous version posted at:
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/660607.html
The rest of the patch is unchanged, just rebased to a more recent
master.
Joseph is in CC as I need a ack for the
From: Mikael Morin
Continue the second set of loops where the first one stopped in the
generated inline MINLOC/MAXLOC code in the cases where the generated code
contains two sets of loops. This fixes a regression that was introduced
when enabling the generation of inline MINLOC/MAXLOC code with
From: Mikael Morin
The next patch will need reindenting of the array bound check generation
code. This outlines it to its own function beforehand, reducing the churn
in the next patch.
-- >8 --
gcc/fortran/ChangeLog:
* trans-array.cc (gfc_conv_ss_startstride): Move array bound check
From: Mikael Morin
Add the tests covering the various cases for which we are about to implement
inline expansion of MINLOC and MAXLOC. Those are cases where the DIM
argument is not present.
PR fortran/90608
gcc/testsuite/ChangeLog:
* gfortran.dg/ieee/maxloc_nan_1.f90: New test
From: Mikael Morin
Enable the generation of inline code for MINLOC/MAXLOC when argument ARRAY
is of integral type, DIM is not present, and MASK is present and is scalar
(only absent MASK or rank 1 ARRAY were inlined before).
Scalar masks are implemented with a wrapping condition around the code
From: Mikael Morin
Enable generation of inline code for the MINLOC and MAXLOC intrinsic,
if the ARRAY argument is of integral type and of any rank (only the rank 1
case was previously inlined), and neither DIM nor MASK arguments are
present.
This needs a few adjustments in gfc_conv_intrinsic_min
From: Mikael Morin
Enable inline code generation for the MINLOC and MAXLOC intrinsic, if the
DIM argument is not present and ARRAY has rank 1. This case is similar to
the case where the result is scalar (DIM present and rank 1 ARRAY), which
already supports inline expansion of the intrinsic. Bo
From: Mikael Morin
Enable generation of inline MINLOC/MAXLOC code in the case where DIM
is not present, and either ARRAY is of floating point type or MASK is an
array. Those cases are the remaining bits to fully support inlining of
non-CHARACTER MINLOC/MAXLOC without DIM. They are treated toget
From: Mikael Morin
Remove the frontend pass rewriting calls of MINLOC/MAXLOC without DIM to
calls with one-valued DIM enclosed in an array constructor. This
transformation was circumventing the limitation of inline MINLOC/MAXLOC code
generation to scalar cases only, allowing inline code to be ge
From: Mikael Morin
Hello,
this is the third version of the inline MINLOC/MAXLOC without DIM patchset
whose second version was posted before at:
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/660599.html
Compared to the previous version, it contains a change of wording of the
documentatio
From: Mikael Morin
Disable rewriting of MINLOC/MAXLOC expressions for which inline code
generation is supported. Update the gfc_inline_intrinsic_function_p
predicate (already existing) for that, with the current state of
MINLOC/MAXLOC inlining support, that is only the cases of a scalar
result a
Hi Tobias,
I just had a short look at your PR. Besides that it did not git-am for me (see
below), I have only one question (see also below). Please note, that I have
only user-level experience in OpenMP and can say nothing about completeness or
soundness of your PR. I hope that a first check on ov
On Mon, 8 Apr 2024, Johannes Nendwich via Gcc wrote:
> on https://gcc.gnu.org/onlinedocs/gfortran/Code-Gen-Options.html
> there is at the end the part
>
>-ffrontend-optimize
>
>This option performs front-end optimization, based on manipulating
> parts the Fortran parse tree.
>
> Migh
Hi Steve,
thanks for the ok. Committed as gcc-15-3099-g0636de8c520
Thanks again,
Andre
On Wed, 21 Aug 2024 09:31:55 -0700
Steve Kargl wrote:
> On Wed, Aug 21, 2024 at 12:17:46PM +0200, Andre Vehreschild wrote:
> >
> > attached small patch removes a VIEW_CONVERT that I erroneously inser
18 matches
Mail list logo