[RFC] Hack for PRs 43996,45081, 58027, 59910, and 60993

[RFC] Hack for PRs 43996,45081, 58027, 59910, and 60993

[Dominique d'Humières]

Compiling PRs 43996,45081, 58027, 59910, and 60993 gives the ICE

internal compiler error: in gfc_conv_array_initializer, at fortran/trans-array.c:5703

Compiling these PRs with  '-fno-range-check -fmax-array-constructor=1000000' succeeds except PR45081 (note that the output for pr 60993 does not seem to be the one expected by the reporter).

I have played with the following patch which gives the error

Fatal Error: A problem with BOZ and/or PARAMETER occurred at (1), try to compile with -fnorange-check and/or to increase the allowed 65535 upper limit for the '-fmax-array-constructor’ option

Is there a (simple) way to distinguish between the cases compiling with -fnorange-check and those requiring an increase of the default value for -fmax-array-constructor?

Indeed I know that the problem should be fixed upstream, but would it be acceptable to apply this kind of patch meanwhile?

Cheers,

Dominique

--- ../_clean/gcc/fortran/trans-array.c	2015-11-11 15:23:35.000000000 +0100
+++ gcc/fortran/trans-array.c	2015-11-14 22:02:20.000000000 +0100
@@ -5699,7 +5699,21 @@ gfc_conv_array_initializer (tree type, g
     case EXPR_NULL:
       return gfc_build_null_descriptor (type);
 
+    case EXPR_FUNCTION:
+      /* Problems occur when we get something like
+         integer :: a(lots) = (/(i, i=1, lots)/)  */
+      gfc_fatal_error ("A problem with BOZ and/or PARAMETER occurred "
+		       "at %L, try to compile with -fnorange-check and/or "
+		       "to increase the allowed %d upper limit for the "
+		       "%<-fmax-array-constructor%> option",
+		       &expr->where, flag_max_array_constructor);
+      return NULL_TREE;
+      /* int errors;
+      gfc_get_errors (NULL, &errors);
+      gfc_fatal_error ("Something wrong: errors count is %d", errors); */
+
     default:
+      printf ("expr->expr_type is %d\n", expr->expr_type);
       gcc_unreachable ();
     }
 

Re: [RFC] Hack for PRs 43996,45081, 58027, 59910, and 60993

[Steve Kargl]

On Sat, Nov 14, 2015 at 10:21:15PM +0100, Dominique d'Humi??res wrote:
> Compiling PRs 43996,45081, 58027, 59910, and 60993 gives the ICE
> 
> internal compiler error: in gfc_conv_array_initializer, at
> fortran/trans-array.c:5703
> 
> Compiling these PRs with  '-fno-range-check -fmax-array-constructor=1000000' succeeds except PR45081 (note that the output for pr 60993 does not seem to be the one expected by the reporter).
> 
> I have played with the following patch which gives the error
> 
> Fatal Error: A problem with BOZ and/or PARAMETER occurred at (1), try to compile with -fnorange-check and/or to increase the allowed 65535 upper limit for the '-fmax-array-constructor??? option
> 
> Is there a (simple) way to distinguish between the cases compiling with -fnorange-check and those requiring an increase of the default value for -fmax-array-constructor?
> 
> Indeed I know that the problem should be fixed upstream, but would it be acceptable to apply this kind of patch meanwhile?
> 

I looked at this a bit.  The comment above gfc_conv_array_initializer is

/* Create an array constructor from an initialization expression.
   We assume the frontend already did any expansions and conversions.  */

If this is indeed an initialization expression, it should be reduced.
It seems that the insertion of __convert_i8_i4 occurs after any previous
reduction.  So, I purpose the following

% svn diff trans-array.c
Index: trans-array.c
===================================================================
--- trans-array.c       (revision 230371)
+++ trans-array.c       (working copy)
@@ -5600,6 +5603,12 @@ gfc_conv_array_initializer (tree type, g
       && expr->symtree->n.sym->value)
     expr = expr->symtree->n.sym->value;
 
+  /* expr should be an initialization expression.  For BOZ entities, a
+     conversion may have been inserted but not reduced.  Do that here.  */
+  if (expr->expr_type == EXPR_FUNCTION
+      && strncmp (expr->symtree->name, "__", 2) == 0)
+    gfc_reduce_init_expr (expr);
+
   switch (expr->expr_type)
     {
     case EXPR_CONSTANT:

With the

  integer, parameter :: isclass(1) = (/ z'ff800000' /)
  print *, isclass
  end

I get

laptop-kargl:kargl[254] gfc -c u1.f90
u1.f90:1:37:

 integer, parameter :: isclass(1) = (/ z'ff800000' /)
                                     1

Error: Arithmetic overflow converting INTEGER(8) to INTEGER(4) at (1). This check can be disabled with the option '-fno-range-check'
u1.f90:1:37:

 integer, parameter :: isclass(1) = (/ z'ff800000' /)
                                     1

Error: Arithmetic overflow converting INTEGER(8) to INTEGER(4) at (1). This check can be disabled with the option '-fno-range-check'
u1.f90:1:37:

 integer, parameter :: isclass(1) = (/ z'ff800000' /)
                                     1

Error: Arithmetic overflow converting INTEGER(8) to INTEGER(4) at (1). This check can be disabled with the option '-fno-range-check'
u1.f90:1:37:

 integer, parameter :: isclass(1) = (/ z'ff800000' /)
                                     1

Error: Arithmetic overflow converting INTEGER(8) to INTEGER(4) at (1). This check can be disabled with the option '-fno-range-check'

No, I don't know why I get 4 errors instead of 1.  So, I suspect 
we need to do the reduction earlier.

-- 
Steve

Re: [RFC] Hack for PRs 43996,45081, 58027, 59910, and 60993

[Steve Kargl]

On Sat, Nov 14, 2015 at 10:21:15PM +0100, Dominique d'Humi??res wrote:
> Compiling PRs 43996,45081, 58027, 59910, and 60993 gives the ICE
> 

I have a patch that fixes 58027 and 60993.  45081 was fixed
long ago.  I'll need to defer working on 43996 and 59910
for another day.

-- 
Steve