Re: [patch, libfortran] Fix PR 34980

[Tobias Burnus <burnus at net-b dot de>]

Tobias Burnus wrote:
> > In the PR, there is a comment from Tobias B. with an alternate approach.
> > I was already into testing my patch when I read that comment, which is
> > why I didn't pursue that approach further.  I have to admit that I feel
> > better about adding something that's obviously (to me) correct to a
> > library function than to do this in the front end.
> >     
Now that I have build and regtested it ...

13.7.108 SHAPE (SOURCE [, KIND])
[...]
Result Characteristics. Integer. If KIND is present, the kind type 
parameter is that specified by the value of KIND; otherwise the kind 
type parameter is that of default integer type. The result is an array 
of rank one whose size is equal to the rank of SOURCE.

Result Value. The value of the result is the shape of SOURCE.

Examples. The value of SHAPE (A (2:5, â1:1) ) is [4, 3]. The value of 
SHAPE (3) is the rank-one array of size zero.

(Note: KIND= is part of Fortran 2003 and not yet implemented; see PR29600.)


Thus for scalar expression, expr->rank == 0, simply a size-zero array 
needs to be returned. This is what

+  if (source->rank == 0)
+    return gfc_start_constructor (BT_INTEGER, gfc_default_integer_kind,
+                                 &source->where);


does. The gfc_start_constructor generates a rank-1 array (see array.c):

/* Start an array constructor.  The constructor starts with zero
  elements and should be appended to by gfc_append_constructor().  */

Thus that part of the patch should be OK.

* * *

However, one still needs to fix m4/shape.m4 as gfortran gives the wrong 
result for:

integer :: i,j, a(10,10),res(2)
j = 1
i = 10
res = shape(a(1:1,i:j))
print *, res
end

Namely: "1 -8" instead of "1 0".  (This is without Thomas' patch, but 
should be unaffected by the patch).

* * *

I wonder also whether one should put in a result check like in Thomas' 
patch for such a program:

integer :: i,j, a(10,10),res(2)
j = 1
i = 10
res = [42, 24 ]
res(2:j) = shape(a(1:1,i:j))
print *, res
end

gfortran prints "42 1" whereas the other compilers (g95, ifort, NAG f95) 
print "42 24"; i.e. gfortran does the assignment while the other 
compilers do not modify "res". In any case, the example is invalid as 
one assigns a shape [ 2 ] array to a shape [ 0 ] array. (As also NAG f95 
diagnoses with -C=all.)

I think we should add a run time test for this (-fbounds-check) - which 
could be based on Thomas' patch.

* * *

Back to my  patch:
It [and Paul's for PR 34975] were bootstrapped and regtested (-m32/-m64, 
including libgomp) on x86-64-linux.
Additionally, I rebuild Quantum ESPRESSO [needs Paul's patch], CP2K, 
Fleur, Exciting, Octopus and Abinit without any failures.

OK for the trunk? (It is a regression with respect to 4.2.)

Tobias


2008-01-28  Tobias Burnus  <burnus@net-b.de>

	PR libfortran/34980
	* simplify.c (gfc_simplify_shape): Simplify rank zero arrays.


2008-01-28  Thomas Koenig  <tkoenig@gcc.gnu.org>

	PR libfortran/34980
	* gfortran.dg/shape_3.f90:  New test.

Index: gcc/fortran/simplify.c
===================================================================
--- gcc/fortran/simplify.c      (Revision 131876)
+++ gcc/fortran/simplify.c      (Arbeitskopie)
@@ -3714,7 +3714,11 @@ gfc_simplify_shape (gfc_expr *source)
  int n;
  try t;

-  if (source->rank == 0 || source->expr_type != EXPR_VARIABLE)
+  if (source->rank == 0)
+    return gfc_start_constructor (BT_INTEGER, gfc_default_integer_kind,
+                                 &source->where);
+
+  if (source->expr_type != EXPR_VARIABLE)
    return NULL;

  result = gfc_start_constructor (BT_INTEGER, gfc_default_integer_kind,



! { dg-do run }
! PR 34980 - we got a segfault for calling shape
!            with a scalar.
program main
 integer :: n
 n = 5
 open(10,status="scratch")
 write (10,*) shape(n)
 close(10,status="delete")
end