Bug 70040 - [5 Regression] ICE in gimplify.c with deferred-length strings
Summary: [5 Regression] ICE in gimplify.c with deferred-length strings
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: unknown
: P4 normal
Target Milestone: 6.2
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-on-valid-code
Depends on:
Blocks: 68241
  Show dependency treegraph
 
Reported: 2016-03-02 10:37 UTC by Martin Reinecke
Modified: 2016-08-08 06:30 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work: 5.3.0
Known to fail: 6.0
Last reconfirmed: 2016-03-02 00:00:00


Attachments
test case (410 bytes, text/plain)
2016-03-02 10:37 UTC, Martin Reinecke
Details
further reduced test case (179 bytes, text/plain)
2016-03-02 10:49 UTC, Martin Reinecke
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Reinecke 2016-03-02 10:37:57 UTC
Created attachment 37841 [details]
test case

Current trunk reports an ICE with the attached test case:

gfortran -v test.f08
Driving: gfortran -v test.f08 -l gfortran -l m -shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/scratch/martin/utrunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /scratch/martin/gccgit/configure --disable-bootstrap --prefix=/scratch/martin/utrunk --enable-languages=c++,fortran --enable-target=all --enable-checking=release
Thread model: posix
gcc version 6.0.0 20160302 (experimental) [trunk revision dd4bd26:0fb01c5:a2cc9e8e2c74db1cdaa9269cde65d0a24f38cabe] (GCC) 
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /scratch/martin/utrunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/f951 test.f08 -quiet -dumpbase test.f08 -mtune=generic -march=x86-64 -auxbase test -version -fintrinsic-modules-path /scratch/martin/utrunk/lib/gcc/x86_64-pc-linux-gnu/6.0.0/finclude -o /tmp/ccL8StDt.s
GNU Fortran (GCC) version 6.0.0 20160302 (experimental) [trunk revision dd4bd26:0fb01c5:a2cc9e8e2c74db1cdaa9269cde65d0a24f38cabe] (x86_64-pc-linux-gnu)
        compiled by GNU C version 5.2.0, GMP version 5.1.3, MPFR version 3.1.3, MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2008 (GCC) version 6.0.0 20160302 (experimental) [trunk revision dd4bd26:0fb01c5:a2cc9e8e2c74db1cdaa9269cde65d0a24f38cabe] (x86_64-pc-linux-gnu)
        compiled by GNU C version 5.2.0, GMP version 5.1.3, MPFR version 3.1.3, MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
test.f08:34:0:

     sourceType(j)%s = sourceType(l-1)%s
 
internal compiler error: in gimplify_expr, at gimplify.c:11098
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
Comment 1 Martin Reinecke 2016-03-02 10:41:01 UTC
I am pretty sure that this used to work on trunk some time ago. Unfortunately I don't have time for a bisection search at the moment ...
Comment 2 Martin Reinecke 2016-03-02 10:49:35 UTC
Created attachment 37842 [details]
further reduced test case
Comment 3 Dominique d'Humieres 2016-03-02 11:43:26 UTC
The tests compile with revision r233722 (2016-02-25) but give an ICE with r233818 (2016-02-29).
Comment 4 Thomas Koenig 2016-03-02 12:32:48 UTC
Could be r233797 .
Comment 5 Dominique d'Humieres 2016-03-02 14:43:05 UTC
> Could be r233797 .

It is.
Comment 6 Thomas Koenig 2016-03-20 13:29:44 UTC
I've been giving this a look, and I have not been able
(in the time that I can currently spend on this) to
get rid of the gimplification error.

There are two possibilities:

a) Revert r233797.  I'd hate to do this, because it removes
(IMHO) a major piece of usability.

b) Fix things some other way.  One possibility would be to still do
the analysis in the front-end pass and mark the expression as needing
a string temporary, with something like this:

Index: frontend-passes.c
===================================================================
--- frontend-passes.c   (Revision 233797)
+++ frontend-passes.c   (Arbeitskopie)
@@ -158,7 +158,6 @@ realloc_string_callback (gfc_code **c, int *walk_s
 {
   gfc_expr *expr1, *expr2;
   gfc_code *co = *c;
-  gfc_expr *n;
 
   if (co->op != EXEC_ASSIGN)
     return 0;
@@ -174,10 +173,9 @@ realloc_string_callback (gfc_code **c, int *walk_s
 
   if (!gfc_check_dependency (expr1, expr2, true))
     return 0;
-  
-  current_code = c;
-  n = create_var (expr2, "trim");
-  co->expr2 = n;
+
+  co->expr2->needs_string_temp = 1;
+
   return 0;
 }
 
Index: gfortran.h
===================================================================
--- gfortran.h  (Revision 233587)
+++ gfortran.h  (Arbeitskopie)
@@ -2020,6 +2020,9 @@ typedef struct gfc_expr
   /* Will require finalization after use.  */
   unsigned int must_finalize : 1;
 
+  /* This needs a string temporary.  */
+  unsigned int needs_string_temp;
+
   /* If an expression comes from a Hollerith constant or compile-time
      evaluation of a transfer statement, it may have a prescribed target-
      memory representation, and these cannot always be backformed from

... and then handle the string generation in gfc_conv_substring_expr.

Problem is, I don't really know how to do the second part.  I can try
to copy some code from gfc_conv_concat_op, but I have never been
comfortable with this part of the compiler.

Paul, maybe you could help?
Comment 7 Jakub Jelinek 2016-04-27 10:58:12 UTC
GCC 6.1 has been released.
Comment 8 Thomas Koenig 2016-08-07 15:27:47 UTC
Works on trunk at least, now.

Test case committed, will check for 6 next.
Comment 9 Thomas Koenig 2016-08-07 15:41:06 UTC
Author: tkoenig
Date: Sun Aug  7 15:40:34 2016
New Revision: 239222

URL: https://gcc.gnu.org/viewcvs?rev=239222&root=gcc&view=rev
Log:
2016-08-07  Thomas Koenig  <tkoenig@gcc.gnu.org>

	PR fortran/70040
	Corrected last ChangeLog entry.


Modified:
    trunk/gcc/testsuite/ChangeLog
Comment 10 Dominique d'Humieres 2016-08-07 15:53:20 UTC
Fixed by revision r238192, r238198, and r238225 for trunk, gcc-6, and gcc-5 respectively?
Comment 11 Thomas Koenig 2016-08-07 15:56:57 UTC
Author: tkoenig
Date: Sun Aug  7 15:56:25 2016
New Revision: 239223

URL: https://gcc.gnu.org/viewcvs?rev=239223&root=gcc&view=rev
Log:
2016-08-07  Thomas Koenig  <tkoenig@gcc.gnu.org>

	PR fortran/70040
	Backport from trunk
	* gfortran.dg/pr70040.f90:  New testcase.


Added:
    branches/gcc-6-branch/gcc/testsuite/gfortran.dg/pr70040.f90
Modified:
    branches/gcc-6-branch/gcc/testsuite/ChangeLog
Comment 12 Thomas Koenig 2016-08-07 16:02:30 UTC
(In reply to Dominique d'Humieres from comment #10)
> Fixed by revision r238192, r238198, and r238225 for trunk, gcc-6, and gcc-5
> respectively?

Probably.

I don't have a gcc 5 tree at the moment (and it will be a
couple of days until I can regenerate it).  So, if somebody
could check that this works, and can also commit the test case,
we can close this as FIXED.
Comment 13 Dominique d'Humieres 2016-08-07 16:12:45 UTC
> I don't have a gcc 5 tree at the moment (and it will be a
> couple of days until I can regenerate it).  So, if somebody
> could check that this works, and can also commit the test case,
> we can close this as FIXED.

Works for me with 5.4.0 and 5.4.1 r238866.
Comment 14 Thomas Koenig 2016-08-08 06:29:48 UTC
Author: tkoenig
Date: Mon Aug  8 06:29:16 2016
New Revision: 239229

URL: https://gcc.gnu.org/viewcvs?rev=239229&root=gcc&view=rev
Log:
2016-08-08  Thomas Koenig  <tkoenig@gcc.gnu.org>

	PR fortran/70040
	Backport from trunk
	* gfortran.dg/pr70040.f90:  New testcase.



Added:
    branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr70040.f90
Modified:
    branches/gcc-5-branch/gcc/testsuite/ChangeLog
Comment 15 Thomas Koenig 2016-08-08 06:30:50 UTC
Test case committed to all affected branches, closing.