Bug 58340 - [4.9 regression] gcc/cp/pt.c:7064:1: internal compiler error: in propagate_threaded_block_debug_into, at tree-ssa-threadedge.c:623
Summary: [4.9 regression] gcc/cp/pt.c:7064:1: internal compiler error: in propagate_th...
Alias: None
Product: gcc
Classification: Unclassified
Component: bootstrap (show other bugs)
Version: 4.9.0
: P3 blocker
Target Milestone: 4.9.0
Assignee: Not yet assigned to anyone
: 58342 (view as bug list)
Depends on:
Blocks: 58342
  Show dependency treegraph
Reported: 2013-09-06 20:04 UTC by Gerald Pfeifer
Modified: 2013-09-16 19:34 UTC (History)
9 users (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed: 2013-09-06 00:00:00

Preprocessed source file (201.29 KB, application/x-bzip)
2013-09-06 20:04 UTC, Gerald Pfeifer
Assembly file (65.17 KB, application/x-bzip)
2013-09-06 20:05 UTC, Gerald Pfeifer

Note You need to log in before you can comment on or make changes to this bug.
Description Gerald Pfeifer 2013-09-06 20:04:17 UTC
Created attachment 30756 [details]
Preprocessed source file

I started to see a new failure on my nightly amd64-unknown-freebsd8.0 tester:

/scratch/tmp/gerald/gcc-HEAD/gcc/cp/pt.c: In function ‘tree_node* maybe_get_template_decl_from_type_decl(tree)’:
/scratch/tmp/gerald/gcc-HEAD/gcc/cp/pt.c:7064:1: internal compiler error: in propagate_threaded_block_debug_into, at tree-ssa-threadedge.c:623
 maybe_get_template_decl_from_type_decl (tree decl)

This happens in stage3-bubble.

/scratch/tmp/gerald/OBJ-0906-1848/./prev-gcc/xg++ -B/scratch/tmp/gerald/OBJ-0906-1848/./prev-gcc/ -B/scratch/tmp/gerald/gcc-ref8-amd64/x86_64-unknown-freebsd8.4/bin/ -nostdinc++ -B/scratch/tmp/gerald/OBJ-0906-1848/prev-x86_64-unknown-freebsd8.4/libstdc++-v3/src/.libs -B/scratch/tmp/gerald/OBJ-0906-1848/prev-x86_64-unknown-freebsd8.4/libstdc++-v3/libsupc++/.libs -I/scratch/tmp/gerald/OBJ-0906-1848/prev-x86_64-unknown-freebsd8.4/libstdc++-v3/include/x86_64-unknown-freebsd8.4 -I/scratch/tmp/gerald/OBJ-0906-1848/prev-x86_64-unknown-freebsd8.4/libstdc++-v3/include -I/scratch/tmp/gerald/gcc-HEAD/libstdc++-v3/libsupc++ -L/scratch/tmp/gerald/OBJ-0906-1848/prev-x86_64-unknown-freebsd8.4/libstdc++-v3/src/.libs -L/scratch/tmp/gerald/OBJ-0906-1848/prev-x86_64-unknown-freebsd8.4/libstdc++-v3/libsupc++/.libs -c  -DIN_GCC_FRONTEND -g -O2 -DIN_GCC   -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H -I. -Icp -I/scratch/tmp/gerald/gcc-HEAD/gcc -I/scratch/tmp/gerald/gcc-HEAD/gcc/cp -I/scratch/tmp/gerald/gcc-HEAD/gcc/../include -I/scratch/tmp/gerald/gcc-HEAD/gcc/../libcpp/include -I/home/gerald/8-amd64/include  -I/scratch/tmp/gerald/gcc-HEAD/gcc/../libdecnumber -I/scratch/tmp/gerald/gcc-HEAD/gcc/../libdecnumber/dpd -I../libdecnumber -I/scratch/tmp/gerald/gcc-HEAD/gcc/../libbacktrace    /scratch/tmp/gerald/gcc-HEAD/gcc/cp/pt.c -o cp/pt.o
Comment 1 Gerald Pfeifer 2013-09-06 20:05:41 UTC
Created attachment 30757 [details]
Assembly file
Comment 2 Marc Glisse 2013-09-06 23:37:33 UTC
I am seeing exactly the same on x86_64-unknown-linux-gnu (using --disable-libvtv since that is broken too).
Comment 3 Jeffrey A. Law 2013-09-07 02:56:36 UTC
Just to be sure, what version of the trunk are both of you using?
Comment 4 Zhendong Su 2013-09-07 03:28:42 UTC
I wasn't able to reproduce the ICE using the given testcase (pt.ii) with trunk revision 202308, but I encountered an ICE (at -O2 and -O3 with -g) in the same source location. It's reported as 58342 with the following small reduced test: 


int a, b, c, d;

int foo (int x, int y)
  return y == 0 ? x : 1 % y;

int main ()
  c = 0 || a;

  for (;;)
    b = foo (d, c) && 1;

  return 0;
Comment 5 Marc Glisse 2013-09-07 06:35:25 UTC
(In reply to Jeffrey A. Law from comment #3)
> Just to be sure, what version of the trunk are both of you using?

202346 for me. Configured with --prefix=... --with-system-zlib --disable-nls --enable-libstdcxx-time=yes --disable-libvtv, built with make -j 6, on an up-to-date debian testing.
Comment 6 Eric Botcazou 2013-09-07 09:01:07 UTC
It comes from:

2013-09-06  Jeff Law  <law@redhat.com>

        * tree-ssa-dom.c (cprop_into_successor_phis): Also propagate
        edge implied equivalences into successor phis.
Comment 7 Andreas Schwab 2013-09-07 09:12:05 UTC
It's also causing miscompare on ia64.
Comment 8 Dominique d'Humieres 2013-09-07 10:22:17 UTC
Also seen on x86_64-apple-darwin10.
Comment 9 Gerald Pfeifer 2013-09-07 13:31:47 UTC
(In reply to Jeffrey A. Law from comment #3)
> Just to be sure, what version of the trunk are both of you using?

Comment 10 Jeffrey A. Law 2013-09-07 18:10:08 UTC
Zhengong's testcase fails for me, so I'll work with that first.
Comment 11 Jeffrey A. Law 2013-09-07 20:13:55 UTC
I've found a minor error in the tree-ssa-threadedge.c changes.  I can easily see how it affects Zhengong's testcase and I can speculate how it might be triggering the ia64 failure.

I'm testing it on x86_64-unknown-linux-gnu at the moment.  I'll spin up a test on ia64 at some point over the weekend as well.
Comment 12 Jan Hubicka 2013-09-08 14:13:38 UTC
I am now seeing this ICE (in the same file) on x86_64-linux, too.
Comment 13 Paolo Carlini 2013-09-08 14:17:19 UTC
Yeah Honza, all of us :(
Comment 14 Jan Hubicka 2013-09-08 14:25:15 UTC
I use the following workaround for time being.


Index: tree-ssa-threadedge.c
--- tree-ssa-threadedge.c	(revision 202364)
+++ tree-ssa-threadedge.c	(working copy)
@@ -1015,8 +1015,9 @@ thread_across_edge (gimple dummy_cond,
 	    tmp = find_edge (taken_edge->src, path[path.length () - 1]->dest);
 	    if (!tmp || phi_args_equal_on_edges (tmp, path[path.length () - 1]))
-		propagate_threaded_block_debug_into (path[path.length () - 1]->dest,
-						     taken_edge->dest);
+		if (path[path.length () - 1]->dest != taken_edge->dest)
+		  propagate_threaded_block_debug_into (path[path.length () - 1]->dest,
+						       taken_edge->dest);
 		register_jump_thread (path, true);
Comment 15 Paolo Carlini 2013-09-08 14:34:36 UTC
Thanks Honza, I simply reverted Jeff' commit in my tree.
Comment 16 Jeffrey A. Law 2013-09-08 16:34:46 UTC
Jan's patch papers over the problem of incorrect initialization of "found".  I expect to be able to run through the formalities necessary to install the fix tonight.  

Reverting until I take care of things tonight is the better option.
Comment 17 Jeffrey A. Law 2013-09-09 13:11:31 UTC
*** Bug 58342 has been marked as a duplicate of this bug. ***
Comment 18 Jeffrey A. Law 2013-09-09 18:25:03 UTC
I'm seeing ia64 fail with an insn does not match constraints failure when the stage2 compiler builds the stage2 C++ runtime.  And that's *with* the fix I checked in last night.  That smells like stage1 mis-compiled stage2.

So I'm going to keep this open while I track down that regression.

There's another ICE I'm aware of (pr58343), but I don't see the root cause of that PR causing a mis-compilation, just ICEs for certain degenerate cases.
Comment 19 Jeffrey A. Law 2013-09-11 02:32:24 UTC
Fixed on trunk by fix for 58380.
Comment 20 Andreas Schwab 2013-09-12 07:42:32 UTC
The bootstrap comparison failure on ia64 remains.
Comment 21 Jeffrey A. Law 2013-09-12 16:35:26 UTC

ia64 is bootstrapping fine for me.  I did one immediately before installing the patch to fix this PR and just did another one (r202530 of the trunk on ia64-unknown-linux-gnu)

I'm going to need more information to be able to proceed any further with your ia64 issues.
Comment 22 Andreas Schwab 2013-09-12 17:00:31 UTC
Just tell me what you need.
Comment 23 Jeffrey A. Law 2013-09-12 17:46:50 UTC
Obviously in a bootstrap comparison failure we have a situation where the compiler has mis-compiled itself or something similar.  Ultimately I need to be able to reproduce the failure.  So far I've been unable to do so on the ia64 boxes I have direct access to.  Note I'm just doing a "configure; make", so if you're using different options, I'd need to know about those.

Alternate approaches would be for you to make a box available which exhibits the problem or for you to help more with the debugging by identifying what file/module is getting mis-compiled.  As you probably know, it's rarely the file showing the comparison failure.
Comment 24 H.J. Lu 2013-09-12 21:22:22 UTC
r202345 also caused PR58387, which has a very small testcase.
Comment 25 Jeffrey A. Law 2013-09-16 19:34:50 UTC
Closing this as resolved via the reversion.