Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic

2024-08-19 Thread Sergio Had
Thank you very much!

Sergey
On Aug 19, 2024 at 00:55 +0800, FX Coudert , wrote:
> Thanks Sergey,
>
> I have pushed the patch at 
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=1cfe4a4d0d4447b364815d5e5c889deb2e533669
>
> FX


Re: [Ping x 3, Patch, Fortran, PR84244, v3] Fix ICE in recompute_tree_invariant_for_addr_expr, at tree.c:4535

2024-08-19 Thread Andre Vehreschild
Hi Harald,

thanks for the review. Committed as: gcc-15-3014-g661acde60ef

Regards,
Andre

On Fri, 16 Aug 2024 19:20:58 +0200
Harald Anlauf  wrote:

> Hi Andre,
>
> Am 16.08.24 um 12:05 schrieb Andre Vehreschild:
> > Hi all,
> >
> > any one for a review? This patch is over a month old and starts to rot.
> >
> > Regtests ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline?
>
> this is good to go.
>
> Thanks for the patch!
>
> Harald
>
> > - Andre
> >
> > On Fri, 9 Aug 2024 16:27:42 +0200
> > Andre Vehreschild  wrote:
> >
> >> Ping!
> >>
> >> On Wed, 17 Jul 2024 15:11:33 +0200
> >> Andre Vehreschild  wrote:
> >>
> >>> Hi all,
> >>>
> >>> and the last ping.
> >>>
> >>> Regtests ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline?
> >>>
> >>> Regards,
> >>>   Andre
> >>>
> >>> On Thu, 11 Jul 2024 16:05:09 +0200
> >>> Andre Vehreschild  wrote:
> >>>
>  Hi all,
> 
>  the attached patch fixes a segfault in the compiler, where for pointer
>  components of a derived type the caf_token in the component was not
>  set, when the derived was previously used outside of a coarray.
> 
>  Regtests ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline?
> 
>  Regards,
>   Andre
> >>>
> >>>
> >>> --
> >>> Andre Vehreschild * Email: vehre ad gmx dot de
> >>
> >>
> >> --
> >> Andre Vehreschild * Email: vehre ad gmx dot de
> >
> >
> > --
> > Andre Vehreschild * Email: vehre ad gmx dot de
>


--
Andre Vehreschild * Email: vehre ad gmx dot de


Re: [Fortran, Patch, PR46371, v1] Fix coarrays use in select type

2024-08-19 Thread Andre Vehreschild
Hi Harald,

thanks for the review. Committed as: gcc-15-3020-g8871489c516

I have checked on PR99837 and the code fragments in there work or error out as
expected w/o ICE. So I associate this PR to 46371 and close it.

Thanks again,
Andre

On Fri, 16 Aug 2024 19:06:02 +0200
Harald Anlauf  wrote:

> Hi Andre,
>
> Am 16.08.24 um 14:10 schrieb Andre Vehreschild:
> > Hi all,
> >
> > attached patch is a follow up on the pr110033 patch and fixes two ICEs
> > reported in pr46371. With the patch also pr56496 is fixed, although that
> > could have been fixed by pr110033 already. I just added the testcase from
> > pr56496 here as coarray/select_type_3.f90 (I like it when the name of the
> > test gives a rough idea on what is tested instead of having just the pr#)
> > to have it covered.
> >
> > Bootstraps and regtests ok on x86_64-pc-linux-gnu. Ok for mainline?
>
> this looks good to me.
>
> I think with this patch also pr99837 is resolved.  Can you have a look,
> and if so, close it?
>
> Thanks for the patch!
>
> Harald
>
> > Regards,
> > Andre
> > --
> > Andre Vehreschild * Email: vehre ad gmx dot de
>


--
Andre Vehreschild * Email: vehre ad gmx dot de


Re: [Ping x 3, Fortran, Patch, coarray, PR84246, v2] Fix for [Coarray] ICE in conv_caf_send, at fortran/trans-intrinsic.c:1950

2024-08-19 Thread Andre Vehreschild
Hi all,

another ping on this patch.

Regtests ok on x86_64-pc-linux-gnu on updated master. Ok for mainline?

Regards,
Andre

On Fri, 9 Aug 2024 16:29:08 +0200
Andre Vehreschild  wrote:

> Ping!
>
> On Wed, 17 Jul 2024 15:15:51 +0200
> Andre Vehreschild  wrote:
>
> > Hi all,
> >
> > attached patch fixes an ICE in coarray code, where the coarray expression
> > already was a pointer, which confused the compiler. Furthermore have I
> > removed a rewrite to a caf_send late in the trans-phase. This is now done
> > in the resolve stage to have only a single place for these rewriting
> > actions.
> >
> > Regtests ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline?
> >
> > Regards,
> > Andre
> > --
> > Andre Vehreschild * Email: vehre ad gmx dot de
>
>


--
Andre Vehreschild * Email: vehre ad gmx dot de
From dadd7507001208777d8d10d3653f8678d6c91b53 Mon Sep 17 00:00:00 2001
From: Andre Vehreschild 
Date: Wed, 17 Jul 2024 12:30:52 +0200
Subject: [PATCH] Fortran: Fix [Coarray] ICE in conv_caf_send, at
 fortran/trans-intrinsic.c:1950 [PR84246]

Fix ICE caused by converted expression already being pointer by checking
for its type.  Lift rewrite to caf_send completely into resolve and
prevent more temporary arrays.

	PR fortran/84246

gcc/fortran/ChangeLog:

	* resolve.cc (caf_possible_reallocate): Detect arrays that may
	be reallocated by caf_send.
	(resolve_ordinary_assign): More reliably detect assignments
	where a rewrite to caf_send is needed.
	* trans-expr.cc (gfc_trans_assignment_1): Remove rewrite to
	caf_send, because this is done by resolve now.
	* trans-intrinsic.cc (conv_caf_send): Prevent unneeded temporary
	arrays.

libgfortran/ChangeLog:

	* caf/single.c (send_by_ref): Created array's lbound is now 1
	and the offset set correctly.

gcc/testsuite/ChangeLog:

	* gfortran.dg/coarray_allocate_7.f08: Adapt to array being
	allocate by caf_send.
---
 gcc/fortran/resolve.cc| 18 +++
 gcc/fortran/trans-expr.cc | 23 ---
 gcc/fortran/trans-intrinsic.cc| 17 --
 .../gfortran.dg/coarray_allocate_7.f08|  4 +---
 libgfortran/caf/single.c  |  6 ++---
 5 files changed, 32 insertions(+), 36 deletions(-)

diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 12973c6bc85..5db327cd12b 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -11601,6 +11601,23 @@ gfc_resolve_blocks (gfc_code *b, gfc_namespace *ns)
 }
 }

+bool
+caf_possible_reallocate (gfc_expr *e)
+{
+  symbol_attribute caf_attr;
+  gfc_ref *last_arr_ref = nullptr;
+
+  caf_attr = gfc_caf_attr (e);
+  if (!caf_attr.codimension || !caf_attr.allocatable || !caf_attr.dimension)
+return false;
+
+  /* Only full array refs can indicate a needed reallocation.  */
+  for (gfc_ref *ref = e->ref; ref; ref = ref->next)
+if (ref->type == REF_ARRAY && ref->u.ar.dimen)
+  last_arr_ref = ref;
+
+  return last_arr_ref && last_arr_ref->u.ar.type == AR_FULL;
+}

 /* Does everything to resolve an ordinary assignment.  Returns true
if this is an interface assignment.  */
@@ -11845,6 +11862,7 @@ resolve_ordinary_assign (gfc_code *code, gfc_namespace *ns)

   bool caf_convert_to_send = flag_coarray == GFC_FCOARRAY_LIB
   && (lhs_coindexed
+	  || caf_possible_reallocate (lhs)
 	  || (code->expr2->expr_type == EXPR_FUNCTION
 	  && code->expr2->value.function.isym
 	  && code->expr2->value.function.isym->id == GFC_ISYM_CAF_GET
diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index c11abb07eb6..8801a15c3a8 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -12701,29 +12701,6 @@ gfc_trans_assignment_1 (gfc_expr * expr1, gfc_expr * expr2, bool init_flag,

   expr1->must_finalize = 0;
 }
-  else if (flag_coarray == GFC_FCOARRAY_LIB
-	   && lhs_caf_attr.codimension && rhs_caf_attr.codimension
-	   && ((lhs_caf_attr.allocatable && lhs_refs_comp)
-	   || (rhs_caf_attr.allocatable && rhs_refs_comp)))
-{
-  /* Only detour to caf_send[get][_by_ref] () when the lhs or rhs is an
-	 allocatable component, because those need to be accessed via the
-	 caf-runtime.  No need to check for coindexes here, because resolve
-	 has rewritten those already.  */
-  gfc_code code;
-  gfc_actual_arglist a1, a2;
-  /* Clear the structures to prevent accessing garbage.  */
-  memset (&code, '\0', sizeof (gfc_code));
-  memset (&a1, '\0', sizeof (gfc_actual_arglist));
-  memset (&a2, '\0', sizeof (gfc_actual_arglist));
-  a1.expr = expr1;
-  a1.next = &a2;
-  a2.expr = expr2;
-  a2.next = NULL;
-  code.ext.actual = &a1;
-  code.resolved_isym = gfc_intrinsic_subroutine_by_id (GFC_ISYM_CAF_SEND);
-  tmp = gfc_conv_intrinsic_subroutine (&code);
-}
   else if (!is_poly_assign && expr2->must_finalize
 	   && expr1->ts.type == BT_CLASS
 	   && expr2->ts.type == BT_CLASS)
diff --git a/gcc/fortran/trans-intrins

Re: [Ping x 3, Fortran, Patch, coarray, PR84246, v2] Fix for [Coarray] ICE in conv_caf_send, at fortran/trans-intrinsic.c:1950

2024-08-19 Thread Jerry D

On 8/19/24 4:43 AM, Andre Vehreschild wrote:

Hi all,

another ping on this patch.

Regtests ok on x86_64-pc-linux-gnu on updated master. Ok for mainline?

Regards,
Andre



Looks OK to go ahead Andre.

Thanks,

Jerry


On Fri, 9 Aug 2024 16:29:08 +0200
Andre Vehreschild  wrote:


Ping!

On Wed, 17 Jul 2024 15:15:51 +0200
Andre Vehreschild  wrote:


Hi all,

attached patch fixes an ICE in coarray code, where the coarray expression
already was a pointer, which confused the compiler. Furthermore have I
removed a rewrite to a caf_send late in the trans-phase. This is now done
in the resolve stage to have only a single place for these rewriting
actions.

Regtests ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline?

Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de






--
Andre Vehreschild * Email: vehre ad gmx dot de




Re: [PATCH v2 10/10] fortran: Add -finline-intrinsics flag for MINLOC/MAXLOC [PR90608]

2024-08-19 Thread Harald Anlauf

Hi Mikael,

apart from patch #04/10, which did not apply cleanly here, I was
able to test your patch.  It seems to work with a manual workaround
(-fno-frontend-optimize) to work around this problem.
Might be a local issue...

That said, it works as advertised.  Thanks for separating out the
IEEE-NaN tests.

What I did not fully get is the way you deal with -finline-intrinsics= .
Currently there are only MINLOC and MAXLOC, but in the future there
could be many more intrinsics.  Given that you need 2 bits per
intrinsic in flag_inline_intrinsics, how future-proof is that?

In the documentation, you have:

+The set of intrinsics permitting the choice of implementation variant
through
+@code{-finline-intrinsics} is currently limited to non-scalar
@code{MAXLOC} and
+@code{MINLOC}.

Why do you say "non-scalar"?  The new inlining is done for these
intrinsics when the DIM argument is absent.  The result characteristics
however is:

  "If DIM does not appear, the result is an array of rank one and of
size equal to the rank of ARRAY; ..."

and I thought the implementation does just that and does that right.
(With DIM present, the result is an array of rank rank(arg)-1.)
Can you clarify the wording in a way that is better understandable?

Otherwise the Fortran parts look fine to me.

For the changes to gcc/flag-types.h you might need an OK from the
gcc maintainers.

Thanks,
Harald

Am 16.08.24 um 12:22 schrieb Mikael Morin:

From: Mikael Morin 

This patch is new in the V2 series.

Regression-tested on x86_64-pc-linux-gnu.
OK for master?

-- >8 --

Introduce the -finline-intrinsics flag to control from the command line
whether to generate either inline code or calls to the functions from the
library, for the MINLOC and MAXLOC intrinsics.

The flag allows to specify inlining either independently for each intrinsic
(either MINLOC or MAXLOC), or all together.  For each intrinsic, a default
value is set if none was set.  The default value depends on the optimization
setting: inlining is avoided if not optimizing or if optimizing for size;
otherwise inlining is preferred.

There is no direct support for this behaviour provided by the .opt options
framework.  It is obtained by defining three different variants of the flag
(finline-intrinsics, fno-inline-intrinsics, finline-intrinsics=) all using
the same underlying option variable.  Each enum value (corresponding to an
intrinsic function) uses two identical bits, and the variable is initialized
with alternated bits, so that we can tell whether the value was left
initialized by checking whether the two bits have different values.

PR fortran/90608

gcc/ChangeLog:

* flag-types.h (enum gfc_inlineable_intrinsics): New type.

gcc/fortran/ChangeLog:

* invoke.texi(finline-intrinsics): Document new flag.
* lang.opt (finline-intrinsics, finline-intrinsics=,
fno-inline-intrinsics): New flags.
* options.cc (gfc_post_options): If the option variable controling
the inlining of MAXLOC (respectively MINLOC) has not been set, set
it or clear it depending on the optimization option variables.
* trans-intrinsic.cc (gfc_inline_intrinsic_function_p): Return false
if inlining for the intrinsic is disabled according to the option
variable.

gcc/testsuite/ChangeLog:

* gfortran.dg/minmaxloc_18.f90: New test.
* gfortran.dg/minmaxloc_18a.f90: New test.
* gfortran.dg/minmaxloc_18b.f90: New test.
* gfortran.dg/minmaxloc_18c.f90: New test.
* gfortran.dg/minmaxloc_18d.f90: New test.
---
  gcc/flag-types.h|  30 +
  gcc/fortran/invoke.texi |  24 +
  gcc/fortran/lang.opt|  27 +
  gcc/fortran/options.cc  |  21 +-
  gcc/fortran/trans-intrinsic.cc  |  13 +-
  gcc/testsuite/gfortran.dg/minmaxloc_18.f90  | 772 
  gcc/testsuite/gfortran.dg/minmaxloc_18a.f90 |  10 +
  gcc/testsuite/gfortran.dg/minmaxloc_18b.f90 |  10 +
  gcc/testsuite/gfortran.dg/minmaxloc_18c.f90 |  10 +
  gcc/testsuite/gfortran.dg/minmaxloc_18d.f90 |  10 +
  10 files changed, 922 insertions(+), 5 deletions(-)
  create mode 100644 gcc/testsuite/gfortran.dg/minmaxloc_18.f90
  create mode 100644 gcc/testsuite/gfortran.dg/minmaxloc_18a.f90
  create mode 100644 gcc/testsuite/gfortran.dg/minmaxloc_18b.f90
  create mode 100644 gcc/testsuite/gfortran.dg/minmaxloc_18c.f90
  create mode 100644 gcc/testsuite/gfortran.dg/minmaxloc_18d.f90

diff --git a/gcc/flag-types.h b/gcc/flag-types.h
index 1e497f0bb91..df56337f7e8 100644
--- a/gcc/flag-types.h
+++ b/gcc/flag-types.h
@@ -451,6 +451,36 @@ enum gfc_convert
  };


+/* gfortran -finline-intrinsics= values;
+   We use two identical bits for each value, and initialize with alternated
+   bits, so that we can check whether a value has been set by checking whether
+   the two bits have identical value.  */
+
+#define GFC_INL_INTR_VAL(idx) (3 << (2 * idx))
+#de

Re: New version of unsiged patch

2024-08-19 Thread Steve Kargl


On Sun, Aug 18, 2024 at 12:10:18PM +0200, Thomas Koenig wrote:
> 
> this version of the patch includes DOT_PRODUCT, MATMUL and quite
> a few improvements for simplification.

Thomas,

Your updated patch applied cleanly on top-of-tree gcc.
Bootstrap and regression testing on amd64-*-freebsd
completed without any oddities.

I'll read through the patch over the next few days.

-- 
steve