[PATCH, part 2] PR 102458 - issues with simplification of SIZE intrinsic applied to automatic arrays

[Harald Anlauf via Fortran]

Dear Fortranners,

I think I have solved the remaining issue in PR 102458 that prevented the
simplification of an expression involving a static initialization and the
evaluation of the SIZE of an automatic array which has provable constant
size.  My previous related query to the ML has thus become obsolete.

My solution is to attempt the resolution of the array specification
within simplify_size so that the simplification actually works.

Regtested on x86_64-pc-linux-gnu.  OK for mainline and same branches
as the patch for part1?

Thanks,
Harald

Fortran: resolve expressions during SIZE simplification

gcc/fortran/ChangeLog:

	PR fortran/102458
	* simplify.c (simplify_size): Resolve expressions used in array
	specifications so that SIZE can be simplified.

gcc/testsuite/ChangeLog:

	PR fortran/102458
	* gfortran.dg/pr102458b.f90: New test.

diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c
index b46cbfa90ab..f40e4930b58 100644
--- a/gcc/fortran/simplify.c
+++ b/gcc/fortran/simplify.c
@@ -7471,6 +7471,7 @@ simplify_size (gfc_expr *array, gfc_expr *dim, int k)
   mpz_t size;
   gfc_expr *return_value;
   int d;
+  gfc_ref *ref;

   /* For unary operations, the size of the result is given by the size
  of the operand.  For binary ones, it's the size of the first operand
@@ -7527,6 +7528,10 @@ simplify_size (gfc_expr *array, gfc_expr *dim, int k)
   return simplified;
 }

+  for (ref = array->ref; ref; ref = ref->next)
+if (ref->type == REF_ARRAY && ref->u.ar.as)
+  gfc_resolve_array_spec (ref->u.ar.as, 0);
+
   if (dim == NULL)
 {
   if (!gfc_array_size (array, ))
diff --git a/gcc/testsuite/gfortran.dg/pr102458b.f90 b/gcc/testsuite/gfortran.dg/pr102458b.f90
new file mode 100644
index 000..3e1026e635a
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr102458b.f90
@@ -0,0 +1,21 @@
+! { dg-do compile }
+! { dg-options "-fdump-tree-original" }
+! { dg-final { scan-tree-dump-times "_gfortran_stop_numeric" 0 "original" } }
+! PR fortran/102458
+
+subroutine s4
+  integer, parameter :: n = 4
+  integer:: w(transfer(n, n)) = 1
+  integer:: x(transfer(n, n))
+  integer:: y(2*int(n) - n)
+  type t
+ integer :: z(int(n))
+  end type t
+  type(t):: tt, uu(3)
+  integer, parameter :: i = size (w)
+  integer, parameter :: k = size (x)
+  integer, parameter :: m = size (y)
+  integer, parameter :: j = size (tt% z)
+  integer, parameter :: l = size (uu(2)% z)
+  if (i /= n .or. k /= n .or. m /= n .or. j /= n .or. l /= n) stop 1
+end

Re: [Patch] Fortran: Fix same_type_as

[Tobias Burnus]

Early ping ;-)  – but actually I do want to explain some parts of my
patch, what I forgot in my first patch email.

Note that while "class(t)" is of declared type when
unallocated/unassociated, "class(*)" is not. Thus, when
unassociated/unallocated, "same_type_as(class_star, class_star)" is
.false. Code wise, this implies the extra check for class_star._vtab ==
NULL while class_t._vtab is always set and, thus, class._vtab->hash is
always available. (Unchanged in this patch, but probably not obvious
without reading the standard.)

On 28.09.21 18:25, Tobias Burnus wrote:

-  if (UNLIMITED_POLY (a))
+  bool unlimited_poly_a = UNLIMITED_POLY (a);
+  bool unlimited_poly_b = UNLIMITED_POLY (b);

Those variables are needed as we add component refs later, which then
cause UNLIMITED_POLY to evaluate false. UNLIMITED_POLY operates on on
expr->ts – thus, it already caters for derived-type accesses.

+  if (unlimited_poly_a)
  {
-  tmp = gfc_class_vptr_get (a->symtree->n.sym->backend_decl);

This caused the ICE as backend_decl was NULL. Additionally, it assumes
that the sym and not some component of it is the requested
unlimited-polymorphic object. Without the latter issue, a simple
gfc_get_symbol_decl() around the argument would be sufficient.

+  se1.want_pointer = 1;
+  gfc_add_vptr_component (a);


The gfc_add_vptr_component handles expr->ref->type == REF_COMPONENT
properly. As also used for the "else if" branch, DT are handled properly.

I think the rest of the patch is obvious.

Tobias

-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955

Re: Executable on Apple M1 and Apple Intel

[Iain Sandoe]

Hello Heiner.

> On 29 Sep 2021, at 08:04, Heiner Veelken via Fortran  
> wrote:

> This is my first post; kindly inform me, if I did anything wrong :-)
> I am using gfortran (M1) from hpc.sourceforge.net 
>  on my Apple Macbook Pro M1. I just create my 
> executable via:
> 
> gfortran Pmain.f psub.F -o prog_m1
> 
> This only works on my machine. On Apple Intel Macbook Pros the response in 
> the terminal is a.o. "bad cpu type".
> Is there a possibility to create something like a "universal binary" in 
> gfortran, which works as well for M1- and Intel-CPUs? In case of, what would 
> be the option to call the compiler, how would it look like?

Yes it is possible, but I don’t know if any distribution is supplying the 
relevant compiler for gfortran.

Essentially, one needs a [cross]compiler generating Intel (x86_64) code which 
runs on the M1.

then you build your program with the native compiler => m1/my_prog
then you build your program with the cross-compiler => intel/my_prog

then you make a “FAT” version, thus:

lipo m1/my_prog intel/my_prog  -create -output fat/my_prog 

(or however you prefer to layout your work, of course)

so you’d need to see if hpc.sourceforge.net is providing a cross compiler 
targetting intel .. 
if not, then ask back here and perhaps we can suggest an alternative.

Iain.

> Remark: Is there a Fortran-guru here living in Aachen, Germany, too?

Executable on Apple M1 and Apple Intel

[Heiner Veelken via Fortran]

Dear Fortran guys!

This is my first post; kindly inform me, if I did anything wrong :-)
I am using gfortran (M1) from hpc.sourceforge.net  
on my Apple Macbook Pro M1. I just create my executable via:

gfortran Pmain.f psub.F -o prog_m1

This only works on my machine. On Apple Intel Macbook Pros the response in the 
terminal is a.o. "bad cpu type".
Is there a possibility to create something like a "universal binary" in 
gfortran, which works as well for M1- and Intel-CPUs? In case of, what would be 
the option to call the compiler, how would it look like?

Remark: Is there a Fortran-guru here living in Aachen, Germany, too?

Re: DGBSV: incorrect numerical results with -L/usr/lib64/atlas ?

[Thomas Koenig via Fortran]

Hi Jorge,


I do not know if this forum is the most appropriate, but as it based
using gfortran I will try to start here.

I usually build the ATLAS library in some beta version without any
numerical problem that I remember. In a circumstantial way, I have to
use the system ATLAS library and, today, I am getting some incorrect
numerical results with the DGBSV lapack fortran subroutine, which is
described below with a simple test.

Perhaps, I am not using the correct sintaxis in the interface, maybe
in the compiler flags or the link ones? Please, any ideas?
Thanks in advance.


I tried your code against the reference LAPACK and got the result below,
which also has info=1 at the end.  There is no argument mismatch
(at least) in the called routine, I checked that by including the
refblas routine into the source.

So, I don't know what's wrong.  Possibly something with the numerics,
or a wrong size of an argument?  It would be possible to compile the
reference LAPACK and BLAS with debugging and check with a debugger
where the info flag is set.

If I may guess, it's probably an error in one of the array sizes -
LAPACK is notorious that way.  I wish they would use modern Fortran's
array passing mechanism.

Best regards

Thomas