User account creation filtered due to spam.

Bug 29267 - different length non-constant strings in array constructors ICE
Summary: different length non-constant strings in array constructors ICE
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.2.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-on-invalid-code
Depends on: 27998
Blocks:
  Show dependency treegraph
 
Reported: 2006-09-28 10:12 UTC by Daniel Franke
Modified: 2007-12-07 22:43 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2006-10-06 21:42:33


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Franke 2006-09-28 10:12:41 UTC
$> cat ice.f90
PROGRAM test_ice
  CHARACTER(len=255), DIMENSION(1,2)  :: a
  a = reshape((/ "x", to_string(1.0) /), (/ 1, 2 /))

  CONTAINS
    CHARACTER(32) FUNCTION to_string(x)
      REAL, INTENT(in) :: x
      WRITE(to_string, FMT="(F6.3)") x
    END FUNCTION
END PROGRAM

$> gfortran-4.2 -g -Wall ice.f90
ice.f90: In function ‘MAIN__’:
ice.f90:3: internal compiler error: in operand_subword_force, at emit-rtl.c:1353
Please submit a full bug report,

$> gfortran -v 
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/daniel/nfs/packages/i686-pc-linux-gnu/gcc-4.2-svn --enable-threads=posix --enable-shared --with-system-zlib --enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.2.0 20060914 (experimental)

Initially reported here:
http://gcc.gnu.org/ml/fortran/2006-09/msg00335.html
(the testcase above is a reduced version of that posted to the ML)
Comment 1 Richard Biener 2006-09-28 13:09:57 UTC
Confirmed.

(gdb) bt
#0  fancy_abort (
    file=0xc80d78 "/space/rguenther/src/svn/trunk/gcc/emit-rtl.c", line=1353, 
    function=0xc80ef0 "operand_subword_force")
    at /space/rguenther/src/svn/trunk/gcc/diagnostic.c:642
#1  0x000000000061cc08 in operand_subword_force (op=0x2b22e2375be0, offset=0, 
    mode=QImode) at /space/rguenther/src/svn/trunk/gcc/emit-rtl.c:1353
#2  0x00000000006351a6 in store_bit_field (str_rtx=0x2b22e2375ba0, 
    bitsize=256, bitnum=0, fieldmode=QImode, value=0x2b22e2362f40)
    at /space/rguenther/src/svn/trunk/gcc/expmed.c:582
#3  0x000000000065441b in store_field (target=0x2b22e2375ba0, bitsize=256, 
    bitpos=0, mode=BLKmode, exp=0x2b22e23639a0, type=0x2b22e2359d10, 
    alias_set=0) at /space/rguenther/src/svn/trunk/gcc/expr.c:5591
#4  0x000000000064d0e2 in expand_assignment (to=0x2b22e235a300, 
    from=0x2b22e23639a0) at /space/rguenther/src/svn/trunk/gcc/expr.c:4141
#5  0x000000000066d9cf in expand_expr_real_1 (exp=0x2b22e235b870, target=0x0, 
    tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
    at /space/rguenther/src/svn/trunk/gcc/expr.c:8603
#6  0x000000000065a675 in expand_expr_real (exp=0x2b22e235b870, 
    target=0x2b22e2284400, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
    at /space/rguenther/src/svn/trunk/gcc/expr.c:6700
(gdb) up
#1  0x000000000061cc08 in operand_subword_force (op=0x2b22e2375be0, offset=0, 
    mode=QImode) at /space/rguenther/src/svn/trunk/gcc/emit-rtl.c:1353
1353      gcc_assert (result);
(gdb) list
1348          else
1349            op = force_reg (mode, op);
1350        }
1351
1352      result = operand_subword (op, offset, 1, mode);
1353      gcc_assert (result);
1354
1355      return result;
1356    }
1357    ^L

We're asking for a QImode subword at offset 0 of
(mem/s/j:BLK (plus:DI (reg:DI 112)
        (reg:DI 96 [ D.1297 ])) [0 S32 A8])

in expansion of

(*D.1297)[S.20D.1298] = D.1302


4.0 fails differently:

gcc40-g/gcc> ./f951 -quiet ../../gcc41-g/gcc/t.f90 
../../gcc41-g/gcc/t.f90: In function 'MAIN__':
../../gcc41-g/gcc/t.f90:8: internal compiler error: in gfc_conv_function_call, at fortran/trans-expr.c:1108
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
Comment 2 Francois-Xavier Coudert 2006-10-04 06:59:59 UTC
I think this code is valid. Changing to ice-on-valid-code.
Comment 3 Tobias Schlüter 2006-10-06 20:36:25 UTC
Slightly reduced testcase, gives the same ice:
 implicit character*32 (a-z)                                                    
  CHARACTER(len=255), DIMENSION(1,2)  :: a                                      
  a = reshape((/ "x", to_string(1.0) /), (/ 1, 2 /))                            
END PROGRAM                                                                     
           
Comment 4 Tobias Schlüter 2006-10-06 20:37:32 UTC
Another interesting variation:
schluter@pcl247:~/src/pr/29267> cat t.f90
 implicit character*32 (a-z)
  CHARACTER(len=255), DIMENSION(1,2)  :: a
  a = reshape((/ to_string(1.0) /), (/ 1, 2 /))
END PROGRAM
schluter@pcl247:~/src/pr/29267> ~/src/gcc/build/gcc/f951 t.f90
 MAIN__
t.f90:1: fatal error: gfc_todo: Not Implemented: complex character array constructors
compilation terminated.
schluter@pcl247:~/src/pr/29267> 
Comment 5 Tobias Schlüter 2006-10-06 21:01:15 UTC
Actually this is invalid code.  The string lengths in the constructor are different, even though they have to be the same.  See 4.5 in the F95 standard.
Comment 6 Daniel Franke 2006-10-07 07:09:07 UTC
Tobi,
> Actually this is invalid code.  The string lengths in the constructor are
> different, even though they have to be the same.  
please try the testcase in the orignal PR with idental string lengths. It will crash gfortran as well.

OTOH, 
  a(1,1) = "x"
  a(1,2) = to_string(1.0)
should work even if 
  CHARACTER(len=255), DIMENSION(1,2) :: a
and
  CHARACTER(len=32) FUNCTION to_string(x),
so, why is an equivalent assignment through the array constructor invalid?
Comment 7 Tobias Schlüter 2006-10-09 11:14:59 UTC
(In reply to comment #6)
> please try the testcase in the orignal PR with idental string lengths. It will
> crash gfortran as well.

Works for me.  Please provide a testcase.
schluter@pcl247:~/src/pr/29267> cat t.f90
! implicit character*32 (b-z)
  CHARACTER(len=255), DIMENSION(2)  :: a
  a = reshape((/ "12345678901234567890123456789012", to_string(1.0) /), shape(a))
  print *, a
  CONTAINS
    CHARACTER(32) FUNCTION to_string(x)
      REAL, INTENT(in) :: x
      WRITE(to_string, FMT="(F6.3)") x
    END FUNCTION
END PROGRAM
schluter@pcl247:~/src/pr/29267> ~/src/gcc/build/gcc/f951 t.f90
 MAIN__ to_string
Execution times (seconds)
 parser                :   0.01 (100%) usr   0.00 ( 0%) sys   0.01 (100%) wall     132 kB (18%) ggc
 TOTAL                 :   0.01             0.00             0.01                740 kB
Extra diagnostic checks enabled; compiler may run slowly.
Configure with --disable-checking to disable checks.
schluter@pcl247:~/src/pr/29267> 

> so, why is an equivalent assignment through the array constructor invalid?

Because the standard says so, I already quoted the relevant part.
Comment 8 Daniel Franke 2006-10-13 15:54:26 UTC
As requested in comment #7, a testcase for equal string lengths (identical to original PR but to_string() returns CHARACTER(len=255) instead of CHARACTER(len=32)):

$> cat cat pr29267.f90
PROGRAM test_ice
  CHARACTER(len=255), DIMENSION(1,2)  :: a
  a = reshape((/ "x", to_string(1.0) /), (/ 1, 2 /))

  CONTAINS
    CHARACTER(len=255) FUNCTION to_string(x)
      REAL, INTENT(in) :: x
      WRITE(to_string, FMT="(F6.3)") x
    END FUNCTION
END PROGRAM

$> gfortran-4.2 -g -Wall pr29267.f90
pr29267.f90: In function 'MAIN__':
pr29267.f90:3: internal compiler error: in operand_subword_force, at emit-rtl.c:1353

$> gfortran-4.2 -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --prefix=$mylocalprefix --enable-bootstrap --enable-threads=posix --enable-shared --with-system-zlib --enable-languages=c,fortran --disable-nls --program-suffix=-4.2
Thread model: posix
gcc version 4.2.0 20061013 (experimental)

Comment 9 Tobias Schlüter 2006-10-13 19:19:10 UTC
Subject: Re:  ICE in operand_subword_force, at
	emit-rtl.c:1353

franke dot daniel at gmail dot com <gcc-bugzilla@gcc.gnu.org> wrote on  
Fri, 13 Oct 2006:

> As requested in comment #7, a testcase for equal string lengths (identical to
> original PR but to_string() returns CHARACTER(len=255) instead of
> CHARACTER(len=32)):

Oh, that's what you meant with equal lengths  :-)  This is indeed not  
required by the standard.

And indeed, this triggers the same bug: the ICE has nothing to do with  
the assignment, it is the code dealing with the array constructor that  
is making us ICE.

Thanks!

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.


Comment 10 Daniel Franke 2006-10-14 08:46:23 UTC
Don't know whether it makes any difference - but if it is the array constructor that crashes because of unequal string lengths within its arguments, why is there no problem with this code?

PROGRAM test_constructor
  CHARACTER(len=32), DIMENSION(1,2)  :: a
  a = reshape((/ "one arg", "another arg" /), (/ 1, 2 /))
END PROGRAM

(Also compare with #3)
Comment 11 Tobias Schlüter 2006-10-16 10:52:03 UTC
Subject: Re:  ICE in operand_subword_force, at
	emit-rtl.c:1353

franke dot daniel at gmail dot com <gcc-bugzilla@gcc.gnu.org> wrote on  
Sat, 14 Oct 2006:
> Don't know whether it makes any difference - but if it is the array   
> constructor
> that crashes because of unequal string lengths within its arguments, why is
> there no problem with this code?
>
> PROGRAM test_constructor
>   CHARACTER(len=32), DIMENSION(1,2)  :: a
>   a = reshape((/ "one arg", "another arg" /), (/ 1, 2 /))
> END PROGRAM

Because this doesn't trigger the buggy codepath :-)  Sometime in the  
past someone went to some lengths to support this kind of invalid  
code.  Had they read the standard closely, they could have saved  
themselves some work.

> (Also compare with #3)

I don't see the relation.

Cheers,
- Tobi

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.


Comment 12 tobias.burnus 2006-10-26 20:29:31 UTC
> > why is there no problem with this code?
> >
> > PROGRAM test_constructor
> >   CHARACTER(len=32), DIMENSION(1,2)  :: a
> >   a = reshape((/ "one arg", "another arg" /), (/ 1, 2 /))
> > END PROGRAM
> 
> Because this doesn't trigger the buggy codepath :-) Sometime in the  
> past someone went to some lengths to support this kind of invalid  
> code.  Had they read the standard closely, they could have saved  
> themselves some work.

The question is whether one wants to support such code or not?

NAG f95 gives an error even with -dusty. sunf95 gives an error. g95 and ifort compile by default, but with -std=f95 / -stand f95 the give an error / warning (respectively).
gfortran does not give such warning/error.
See also: bug 27998
Comment 13 Tobias Schlüter 2006-10-27 13:33:17 UTC
Thanks for the pointer to the other PR.  Do g95 and ifort also compile the original testcase and do The Right Thing?

I didn't have time to fix this after I assigned myself to it, so unassigining.

Comment 14 tobias.burnus 2006-10-28 13:09:25 UTC
> Do g95 and ifort also compile the original testcase and do The Right Thing?

No. g95 has a run-time error, ifort garbage at the beginning (but no crash); f95 and sunf95 don't compile.

gfortran: ICE for "x", for "x    ": compiles, but garbage (extra 1.000) at run time, for "x"//31characters: ok like all the other compilers


> g95 ice29267.f90
> ./a.out
Fortran runtime error: Inconsistent string size in array constructor

> ifort ice4.f90
> ./a.out # with print *, a:
 xw~D#&#65533;*'@x$&#65533;
  1.000

NAGf95:
Array constructor values have differing CHARACTER lengths (1 and 32)
sunf95:
Line = 3, Column = 23: ERROR: Array constructor values of type character must all have the same length.
Comment 15 Volker Reichelt 2007-12-07 22:12:18 UTC
Btw, the original testcase started compiling on mainline between 2007-07-16 and 2007-08-15. It now compiles and runs without error.
Comment 16 Tobias Burnus 2007-12-07 22:43:11 UTC
> Btw, the original testcase started compiling on mainline between 2007-07-16 and
> 2007-08-15. It now compiles and runs without error.

Cool. And for -std=f95/f2003 the invalid code is rejected.
=> CLOSE. I think (hope?) thate the testsuite covers this PR..