[Bug middle-end/52306] ICE in cselib_record_set, at cselib.c:2158
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306 --- Comment #23 from Andreas Schwab sch...@linux-m68k.org --- *** Bug 59536 has been marked as a duplicate of this bug. ***
[Bug middle-end/52306] ICE in cselib_record_set, at cselib.c:2158
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306 --- Comment #24 from Mikael Pettersson mikpelinux at gmail dot com --- So where does that leave us? Disable -fauto-inc-dec by default, or try to make m68k work with LRA (which hopefully should avoid this reload bug)?
[Bug middle-end/52306] ICE in cselib_record_set, at cselib.c:2158
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306 Thorsten Glaser tg at mirbsd dot org changed: What|Removed |Added Known to fail||4.8.1 --- Comment #22 from Thorsten Glaser tg at mirbsd dot org --- The Debian GCC maintainer refuses to accept my workaround patch. I’m not sure whether he’d accept a patch to always disable -fauto-inc-dec on m68k. A “proper” fix would be welcome as lots of software, most prominently anything Qt (both 4 and 5), FTBFS without this.
[Bug middle-end/52306] ICE in cselib_record_set, at cselib.c:2158
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306 --- Comment #19 from Thorsten Glaser tg at mirbsd dot org --- Created attachment 30668 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30668action=edit Testcase from qtbase-opensource-src_5.1.0+dfsg-4 and g++ 4.8.1 This issue still appears with GCC 4.8 In GCC 4.6 in Debian/m68k I eventually applied a patch that simply retries the build with -O1 then -O0 to mask this issue, but the underlying issue is still unfixed. This occurs in 4.8 now too, so I guess (from a distro PoV) I need to port said patch, until someone finds out what precisely is going on here. g++ -c x.cc -std=c++0x -fno-exceptions ⇒ compiles fine g++ -c x.cc -std=c++0x -fno-exceptions -O2 ⇒ ICEs: In file included from ../../../include/QtCore/qlist.h:1:0, from ../../../include/QtCore/../../src/corelib/tools/qhash.h:47, from ../../../include/QtCore/qhash.h:1, from ../../../include/QtCore/../../src/corelib/io/qdebug.h:46, from ../../../include/QtCore/qdebug.h:1, from ditaxmlgenerator.cpp:46: ../../../include/QtCore/../../src/corelib/tools/qlist.h: In member function ‘void QListT::append(const T) [with T = Section]’: ../../../include/QtCore/../../src/corelib/tools/qlist.h:521:1: internal compiler error: in cselib_record_set, at cselib.c:2373 Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.8/README.Bugs for instructions. Preprocessed source stored into /tmp/ccUYfyzd.out file, please attach this to your bugreport.
[Bug middle-end/52306] ICE in cselib_record_set, at cselib.c:2158
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306 --- Comment #20 from Mikael Pettersson mikpe at it dot uu.se --- (In reply to Thorsten Glaser from comment #19) Created attachment 30668 [details] Testcase from qtbase-opensource-src_5.1.0+dfsg-4 and g++ 4.8.1 This issue still appears with GCC 4.8 In GCC 4.6 in Debian/m68k I eventually applied a patch that simply retries the build with -O1 then -O0 to mask this issue, but the underlying issue is still unfixed. This occurs in 4.8 now too, so I guess (from a distro PoV) I need to port said patch, until someone finds out what precisely is going on here. Please try compiling with -O2 -fno-auto-inc-dec before dropping to -O1 or -O0.
[Bug middle-end/52306] ICE in cselib_record_set, at cselib.c:2158
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306 --- Comment #21 from Thorsten Glaser tg at mirbsd dot org --- -fno-auto-inc-dec helps, thanks!
[Bug middle-end/52306] ICE in cselib_record_set, at cselib.c:2158
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||uweigand at gcc dot gnu.org --- Comment #18 from Jakub Jelinek jakub at gcc dot gnu.org 2013-02-07 08:13:03 UTC --- That sounds like reload bug then. It should either not reload the destination to the same register used in POST_INC, or change the POST_INC into non-autoinc form.
[Bug middle-end/52306] ICE in cselib_record_set, at cselib.c:2158
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306
--- Comment #17 from Mikael Pettersson mikpe at it dot uu.se 2013-02-06
23:23:58 UTC ---
Created attachment 29376
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29376
reduced test case
Please disregard my last two comments, I misread the insn dump and mistook a
note for the invalid concurrent modification of a register.
Thorsten's initial xslt test case, attachment 27325, ICEs 4.6 and 4.7 -with -O2
-fPIC, and 4.8 with just -O2. This new test case is substantially reduced from
the initial one, but it only ICEs 4.8. The ICE occurs when cselib processes
insn 67.
IRA produced
(insn 67 66 69 10 (set (reg/f:SI 52 [ D.1521 ])
(mem/f:SI (post_inc:SI (reg:SI 59 [ ivtmp.11 ])) [3 MEM[base: 0B,
index: ivtmp.11_66, offset: 0B]+0 S4 A16])) pr52306-4.c:44 38 {*movsi_m68k2}
(expr_list:REG_INC (reg:SI 59 [ ivtmp.11 ])
(nil)))
with, if I read the dump correctly, reg 52 mapped to %a1 and reg 59 spilled.
Reload then sees fit to reload reg 59 into %a1, resulting in
(insn 67 253 69 10 (set (reg:SI 9 %a1)
(mem/f:SI (post_inc:SI (reg:SI 9 %a1)) [3 MEM[base: 0B, index:
ivtmp.11_66, offset: 0B]+0 S4 A16])) pr52306-4.c:44 38 {*movsi_m68k2}
(expr_list:REG_INC (reg:SI 9 %a1)
(nil)))
which uses %a1 both as an auto-inc source pointer and as the dest of the load,
causing the assertion failure in cselib.
The post_inc of reg 59 (%a1) is actually dead, reload added insns to load %a1
from reg 59's spill slot and to increment that memory cell directly. I'm
guessing either reload should not have coalesced reg 59 with reg 52 (due to the
post_inc on reg 59), or it should have cancelled the post_inc when it added the
new insn to increment the spill slot directly.
[Bug middle-end/52306] ICE in cselib_record_set, at cselib.c:2158
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306
--- Comment #15 from Mikael Pettersson mikpe at it dot uu.se 2013-01-30
17:34:11 UTC ---
(In reply to comment #1)
The bug, duplicated by compiling attachment 26150 [details], from bug 43437
comment 16,
with a cross-compiler to m68k-elf with -O -c, exposes a reload problem.
Before
reload, we have this insn:
(insn 288 287 290 40 (set (reg/f:SI 124 [ D.1788 ])
(mem/f:SI (post_inc:SI (reg:SI 145 [ ivtmp.76 ])) [5 MEM[base:
D.1889_285, offset: 0B]+0 S4 A16])) pr52306.c:278 37 {*movsi_m68k2}
(expr_list:REG_INC (reg:SI 145 [ ivtmp.76 ])
(nil)))
But isn't this already invalid, as it has both a post_inc and a REG_INC of the
same (reg:SI 145 [ ivtmp.76 ]) operand?
This is produced by the auto_inc_dec pass. Before that we have (175r.fwprop2):
(insn 188 187 190 22 (set (reg/v:SI 76 [ i ])
(plus:SI (reg/v:SI 76 [ i ])
(const_int 1 [0x1]))) pr43437-2.c:222 132 {*addsi3_internal}
(nil))
(insn 190 188 191 22 (set (cc0)
(compare (reg/v:SI 76 [ i ])
(reg/v:SI 68 [ n ]))) pr43437-2.c:222 14 {*m68k.md:486}
(nil))
which auto_inc_dec turns into (176r.auto_inc_dec):
289 r145:SI=r145:SI+0x4
288 r124:SI=[r145:SI]
288 r124:SI=[r145:SI]
found mem(288) *(r[145]+0)
289 r145:SI=r145:SI+0x4
found post inc(289) r[145]+=4
trying SIMPLE_POST_INC
rescanning insn with uid = 288.
deleting insn with uid = 288.
deleting insn with uid = 289.
success 288 r124:SI=[r145:SI++]
REG_INC: r145:SI
...
288 r124:SI=[r145:SI++]
REG_INC: r145:SI
...
(insn 288 287 290 41 (set (reg/f:SI 124 [ D.1812 ])
(mem/f:SI (post_inc:SI (reg:SI 145 [ ivtmp.80 ])) [5 MEM[base:
D.1914_291, offset: 0B]+0 S4 A16])) pr43437-2.c:278 37 {*movsi_m68k2}
(expr_list:REG_INC (reg:SI 145 [ ivtmp.80 ])
(nil)))
Is this valid?
[Bug middle-end/52306] ICE in cselib_record_set, at cselib.c:2158
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306
--- Comment #16 from Mikael Pettersson mikpe at it dot uu.se 2013-01-30
17:50:07 UTC ---
Sorry I quoted the wrong fragment from 175r.fwprop, the correct fragment is:
(insn 288 287 289 41 (set (reg/f:SI 124 [ D.1812 ])
(mem/f:SI (reg:SI 145 [ ivtmp.80 ]) [5 MEM[base: D.1914_291, offset:
0B]+0 S4 A16])) pr43437-2.c:278 37 {*movsi_m68k2}
(nil))
(insn 289 288 290 41 (set (reg:SI 145 [ ivtmp.80 ])
(plus:SI (reg:SI 145 [ ivtmp.80 ])
(const_int 4 [0x4]))) pr43437-2.c:278 132 {*addsi3_internal}
(nil))
[Bug middle-end/52306] ICE in cselib_record_set, at cselib.c:2158
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306 Thorsten Glaser tg at mirbsd dot org changed: What|Removed |Added Summary|ICE in CSE |ICE in cselib_record_set, ||at cselib.c:2158 --- Comment #12 from Thorsten Glaser tg at mirbsd dot org 2013-01-29 21:17:04 UTC --- # cat /usr/bin/g++ #!/bin/mksh-static /usr/bin/g++-4.6 $@ exit 0 /usr/bin/g++-4.6 $@ -O1 exit 0 exec /usr/bin/g++-4.6 $@ -O0 Has anyone thought of making GCC do that automatically? It already retries on ICEs to weed out possibly bad memory… if we have an ICE like this specific case, where we *know* optimisation makes a difference and it’s a bug in the compiler, we could just retry lowering the optimisation level each time. (My shell script is very suboptimal as it always retries twice. I’m using it only for the second time now, and both times only during the build, after all configury has been run. Some C++ code seems to exercise PR52306 more than, say, libvirt which has only one occurrence (times two)…)
[Bug middle-end/52306] ICE in cselib_record_set, at cselib.c:2158
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306 --- Comment #13 from Thorsten Glaser tg at mirbsd dot org 2013-01-29 21:25:58 UTC --- … oh, sorry, the automatic retry is apparently Debian/Feodora specific. Still… in this very case… this ICE in CSE is hitting us often enough…
[Bug middle-end/52306] ICE in cselib_record_set, at cselib.c:2158
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306
--- Comment #14 from Thorsten Glaser tg at mirbsd dot org 2013-01-29 23:29:54
UTC ---
just don’t hit me… I’m trying this now, until someone fixes this PR:
# DP: retry a known ICE with -O1 then -O0 in case it gets better
--- a/src/gcc/diagnostic.c
+++ b/src/gcc/diagnostic.c
@@ -242,6 +242,12 @@ diagnostic_action_after_output (diagnost
See %s for instructions.\n, bug_report_url);
exit (ICE_EXIT_CODE);
+case DK_TGV:
+ fnotice (stderr, Retrying with lowered optimisation,\n
+ this is a known bug, do not worry. If it'll\n
+ still fail, just fail the package build.\n);
+ exit (TGV_EXIT_CODE);
+
case DK_FATAL:
if (context-abort_on_error)
real_abort ();
@@ -426,7 +432,7 @@ diagnostic_report_diagnostic (diagnostic
/* If we're reporting an ICE in the middle of some other error,
try to flush out the previous error, then let this one
through. Don't do this more than once. */
- if (diagnostic-kind == DK_ICE context-lock == 1)
+ if ((diagnostic-kind == DK_ICE || diagnostic-kind == DK_TGV)
context-lock == 1)
pp_flush (context-printer);
else
error_recursion (context);
@@ -494,7 +500,7 @@ diagnostic_report_diagnostic (diagnostic
context-lock++;
- if (diagnostic-kind == DK_ICE)
+ if (diagnostic-kind == DK_ICE || diagnostic-kind == DK_TGV)
{
#ifndef ENABLE_CHECKING
/* When not checking, ICEs are converted to fatal errors when an
@@ -507,7 +513,7 @@ diagnostic_report_diagnostic (diagnostic
expanded_location s = expand_location (diagnostic-location);
fnotice (stderr, %s:%d: confused by earlier errors, bailing out\n,
s.file, s.line);
- exit (ICE_EXIT_CODE);
+ exit (diagnostic-kind == DK_TGV ? TGV_EXIT_CODE : ICE_EXIT_CODE);
}
#endif
if (context-internal_error)
@@ -902,3 +908,17 @@ real_abort (void)
{
abort ();
}
+
+void
+tgv_abort (const char *gmsgid, ...)
+{
+ diagnostic_info diagnostic;
+ va_list ap;
+
+ va_start (ap, gmsgid);
+ diagnostic_set_info (diagnostic, gmsgid, ap, input_location, DK_TGV);
+ report_diagnostic (diagnostic);
+ va_end (ap);
+
+ gcc_unreachable ();
+}
--- a/src/gcc/diagnostic.def
+++ b/src/gcc/diagnostic.def
@@ -43,3 +43,4 @@ prefix does not matter. */
DEFINE_DIAGNOSTIC_KIND (DK_PEDWARN, pedwarn: )
DEFINE_DIAGNOSTIC_KIND (DK_PERMERROR, permerror: )
+DEFINE_DIAGNOSTIC_KIND (DK_TGV, internal compiler error: )
--- a/src/gcc/system.h
+++ b/src/gcc/system.h
@@ -235,6 +235,7 @@ extern int errno;
#endif
#define ICE_EXIT_CODE 4
+#define TGV_EXIT_CODE 23
#ifdef HAVE_UNISTD_H
# include unistd.h
@@ -642,6 +643,15 @@ extern void fancy_abort (const char *, i
#define gcc_assert(EXPR) ((void)(0 (EXPR)))
#endif
+extern void tgv_abort (const char *, ...) ATTRIBUTE_NORETURN;
+#if ENABLE_ASSERT_CHECKING
+#define gcc_assert_and_retry_with_lowered_optimisation_level(EXPR) \
+ ((void)(!(EXPR) ? tgv_abort (in %s, at %s:%d, __FUNCTION__, trim_filename
(__FILE__), __LINE__), 0 : 0))
+#else
+#define gcc_assert_and_retry_with_lowered_optimisation_level(EXPR)\
+ gcc_assert (EXPR)
+#endif
+
#ifdef ENABLE_CHECKING
#define gcc_checking_assert(EXPR) gcc_assert (EXPR)
#else
--- a/src/gcc/gcc.c
+++ b/src/gcc/gcc.c
@@ -253,6 +253,7 @@ static const char *convert_filename (con
#if !(defined (__MSDOS__) || defined (OS2) || defined (VMS))
static void retry_ice (const char *prog, const char **argv);
#endif
+static const char **tgv_argv(const char **);
static const char *getenv_spec_function (int, const char **);
static const char *if_exists_spec_function (int, const char **);
@@ -2464,6 +2465,7 @@ execute (void)
{
int i;
int n_commands;/* # of command. */
+ int retry_tgv = 0;
char *string;
struct pex_obj *pex;
struct command
@@ -2529,7 +2531,8 @@ execute (void)
/* If -v, print what we are about to do, and maybe query. */
- if (verbose_flag)
+ do {
+ if (verbose_flag || retry_tgv)
{
/* For help listings, put a blank line between sub-processes. */
if (print_help_list)
@@ -2659,13 +2662,12 @@ execute (void)
pfatal_with_name (errmsg);
}
}
-
- if (i string != commands[i].prog)
-free (CONST_CAST (char *, string));
}
execution_count++;
+ retry_tgv = ~0x80;
+
/* Wait for all the subprocesses to finish. */
{
@@ -2717,6 +2719,26 @@ execute (void)
/* For ICEs in cc1, cc1obj, cc1plus see if it is
reproducible or not. */
const char *p;
+if (WEXITSTATUS (status) == TGV_EXIT_CODE
+ i == 0
+ (p = strrchr (commands[0].argv[0], DIR_SEPARATOR))
+ ! strncmp (p + 1, cc1, 3)) {
+ if (retry_tgv == 0) {
+commands[0].argv = tgv_argv(commands[0].argv);
+retry_tgv = 0x81;
+goto foo_tgv;
+ }
+ if (retry_tgv == 1) {
+size_t qqq = 0;
+
+while
