* [Bug java/49847] m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL)
2011-07-25 21:07 [Bug java/49847] New: m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL) tg at mirbsd dot org
@ 2011-09-03 19:32 ` tg at mirbsd dot org
2011-12-12 10:02 ` mikpe at it dot uu.se
` (37 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: tg at mirbsd dot org @ 2011-09-03 19:32 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847
Thorsten Glaser <tg at mirbsd dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |critical
--- Comment #1 from Thorsten Glaser <tg at mirbsd dot org> 2011-09-03 19:32:10 UTC ---
Raising importance; this bug prevents 4.6 from being switched to in Debian.
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug java/49847] m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL)
2011-07-25 21:07 [Bug java/49847] New: m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL) tg at mirbsd dot org
2011-09-03 19:32 ` [Bug java/49847] " tg at mirbsd dot org
@ 2011-12-12 10:02 ` mikpe at it dot uu.se
2011-12-15 21:01 ` [Bug rtl-optimization/49847] [4.6/4.7 Regression] " pinskia at gcc dot gnu.org
` (36 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: mikpe at it dot uu.se @ 2011-12-12 10:02 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847
Mikael Pettersson <mikpe at it dot uu.se> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mikpe at it dot uu.se
--- Comment #2 from Mikael Pettersson <mikpe at it dot uu.se> 2011-12-12 09:40:52 UTC ---
Looking into it.
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug rtl-optimization/49847] [4.6/4.7 Regression] m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL)
2011-07-25 21:07 [Bug java/49847] New: m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL) tg at mirbsd dot org
2011-09-03 19:32 ` [Bug java/49847] " tg at mirbsd dot org
2011-12-12 10:02 ` mikpe at it dot uu.se
@ 2011-12-15 21:01 ` pinskia at gcc dot gnu.org
2011-12-16 9:18 ` jakub at gcc dot gnu.org
` (35 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: pinskia at gcc dot gnu.org @ 2011-12-15 21:01 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |ice-on-valid-code
Component|java |rtl-optimization
Known to work| |4.4.0
Target Milestone|--- |4.6.3
Summary|m68k gcj-4.6 NULL deref in |[4.6/4.7 Regression] m68k
|fold_rtx (prev_insn_cc0 == |gcj-4.6 NULL deref in
|NULL) |fold_rtx (prev_insn_cc0 ==
| |NULL)
Known to fail| |4.6.1
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug rtl-optimization/49847] [4.6/4.7 Regression] m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL)
2011-07-25 21:07 [Bug java/49847] New: m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL) tg at mirbsd dot org
` (2 preceding siblings ...)
2011-12-15 21:01 ` [Bug rtl-optimization/49847] [4.6/4.7 Regression] " pinskia at gcc dot gnu.org
@ 2011-12-16 9:18 ` jakub at gcc dot gnu.org
2012-01-20 22:07 ` mikpe at it dot uu.se
` (34 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: jakub at gcc dot gnu.org @ 2011-12-16 9:18 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P4
CC| |jakub at gcc dot gnu.org
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug rtl-optimization/49847] [4.6/4.7 Regression] m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL)
2011-07-25 21:07 [Bug java/49847] New: m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL) tg at mirbsd dot org
` (3 preceding siblings ...)
2011-12-16 9:18 ` jakub at gcc dot gnu.org
@ 2012-01-20 22:07 ` mikpe at it dot uu.se
2012-01-21 16:13 ` tg at mirbsd dot org
` (33 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: mikpe at it dot uu.se @ 2012-01-20 22:07 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847
--- Comment #3 from Mikael Pettersson <mikpe at it dot uu.se> 2012-01-20 21:51:12 UTC ---
It's triggered by Joseph Myers' "Table-based default_options_optimization"
change in r165823:
http://gcc.gnu.org/ml/gcc-cvs/2010-10/msg01009.html
http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01849.html
Lots of targets were updated there, but not m68k. I'll investigate tomorrow.
There were other build problems that prevented me from finding this sooner.
First it appears that the jar script that gcc provides if there's no fastjar or
gjar in $PATH is broken: in my native m68k environment it produces bogus zip
files that cause null pointer exceptions way later in the libjava build. Fixed
by building fastjar. Has anyone else seen this issue?
When I found the above rev. I wanted to check current trunk with a cross, and
then it turns out that 4.7 has broken cross builds of libjava, at least for
m68k; libtool-driven compilation attempts in ../native/fdlibm/ fail with some
libtool message about not being configured to build any library, whatever that
means. So now I'm bisecting that mess as well.
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug rtl-optimization/49847] [4.6/4.7 Regression] m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL)
2011-07-25 21:07 [Bug java/49847] New: m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL) tg at mirbsd dot org
` (4 preceding siblings ...)
2012-01-20 22:07 ` mikpe at it dot uu.se
@ 2012-01-21 16:13 ` tg at mirbsd dot org
2012-01-22 2:16 ` mikpe at it dot uu.se
` (32 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: tg at mirbsd dot org @ 2012-01-21 16:13 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847
--- Comment #4 from Thorsten Glaser <tg at mirbsd dot org> 2012-01-21 16:04:41 UTC ---
Mikael, you are amazing! I’m sort of sorry that I’ve led you to so much
effort and fighting against bugs and build system issues.
I’ve only ever built gcj with fastjar, even in the gcc 3.4 times on MirBSD.
I didn’t even know it could generate a wrapper script… Looking at it, I
guess that your zip (Info-ZIP) may be broken, as it merely uses that.
Do you still have the jar file that generates an NPE lying around? If so,
mail it to me privately, and I can have a look at that when I’m back from
vacation.
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug rtl-optimization/49847] [4.6/4.7 Regression] m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL)
2011-07-25 21:07 [Bug java/49847] New: m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL) tg at mirbsd dot org
` (5 preceding siblings ...)
2012-01-21 16:13 ` tg at mirbsd dot org
@ 2012-01-22 2:16 ` mikpe at it dot uu.se
2012-01-22 10:33 ` schwab@linux-m68k.org
` (31 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: mikpe at it dot uu.se @ 2012-01-22 2:16 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847
--- Comment #5 from Mikael Pettersson <mikpe at it dot uu.se> 2012-01-22 00:46:53 UTC ---
(In reply to comment #3)
> It's triggered by Joseph Myers' "Table-based default_options_optimization"
> change in r165823:
> http://gcc.gnu.org/ml/gcc-cvs/2010-10/msg01009.html
> http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01849.html
Before this change, flag_trapping_math was 1 when compiling C and C++ code but
0 when compiling java .class files, and things worked. After this change,
flag_trapping_math remains set to 1 when compiling java .class files, and gcc
ICEs compiling java.util.Random.nextGaussian() for m68k. Force-disabling
flag_trapping_math at the end of opts.c:default_options_optimization() allows
the java classes to be compiled ok and the build to complete. I'm not yet sure
if this is an m68k backend regression or a java frontend regression from
r165823.
You don't need a native environment to reproduce this problem, a simple cross
to m68k-linux suffices.
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug rtl-optimization/49847] [4.6/4.7 Regression] m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL)
2011-07-25 21:07 [Bug java/49847] New: m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL) tg at mirbsd dot org
` (6 preceding siblings ...)
2012-01-22 2:16 ` mikpe at it dot uu.se
@ 2012-01-22 10:33 ` schwab@linux-m68k.org
2012-01-22 12:29 ` schwab@linux-m68k.org
` (30 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: schwab@linux-m68k.org @ 2012-01-22 10:33 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847
--- Comment #6 from Andreas Schwab <schwab@linux-m68k.org> 2012-01-22 09:00:52 UTC ---
flag_trapping_math is supposed to be set to 0 by java_init_options_struct,
which is called after init_options_struct in toplev_main. But
java_init_options_struct does not set frontend_set_flag_trapping_math.
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug rtl-optimization/49847] [4.6/4.7 Regression] m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL)
2011-07-25 21:07 [Bug java/49847] New: m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL) tg at mirbsd dot org
` (7 preceding siblings ...)
2012-01-22 10:33 ` schwab@linux-m68k.org
@ 2012-01-22 12:29 ` schwab@linux-m68k.org
2012-01-22 13:02 ` schwab@linux-m68k.org
` (29 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: schwab@linux-m68k.org @ 2012-01-22 12:29 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847
Andreas Schwab <schwab@linux-m68k.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2012-01-22
Ever Confirmed|0 |1
--- Comment #7 from Andreas Schwab <schwab@linux-m68k.org> 2012-01-22 10:34:24 UTC ---
Previously set_fast_math_flags was only called if -Ofast was enabled, now it is
called unconditionally (with set=0/1 according to -Ofast), which clobbers
flag_trapping_math unless frontend_set_flag_trapping_math is set. The
frontends need to be updated to properly set the frontend_set_... flags.
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug rtl-optimization/49847] [4.6/4.7 Regression] m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL)
2011-07-25 21:07 [Bug java/49847] New: m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL) tg at mirbsd dot org
` (8 preceding siblings ...)
2012-01-22 12:29 ` schwab@linux-m68k.org
@ 2012-01-22 13:02 ` schwab@linux-m68k.org
2012-01-22 13:39 ` mikpe at it dot uu.se
` (28 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: schwab@linux-m68k.org @ 2012-01-22 13:02 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847
--- Comment #8 from Andreas Schwab <schwab@linux-m68k.org> 2012-01-22 12:12:07 UTC ---
Note that this ICE also happens in cc1plus when compiling libjava/interpret.cc,
so the java frontend bug isn't the real cause.
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug rtl-optimization/49847] [4.6/4.7 Regression] m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL)
2011-07-25 21:07 [Bug java/49847] New: m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL) tg at mirbsd dot org
` (9 preceding siblings ...)
2012-01-22 13:02 ` schwab@linux-m68k.org
@ 2012-01-22 13:39 ` mikpe at it dot uu.se
2012-01-22 14:36 ` schwab@linux-m68k.org
` (27 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: mikpe at it dot uu.se @ 2012-01-22 13:39 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847
--- Comment #9 from Mikael Pettersson <mikpe at it dot uu.se> 2012-01-22 12:29:21 UTC ---
(In reply to comment #8)
> Note that this ICE also happens in cc1plus when compiling libjava/interpret.cc,
> so the java frontend bug isn't the real cause.
Is that with 4.7 or 4.6? Native or cross? I get no ICE when compiling
libjava/interpret.cc with vanilla gcc-4.6.
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug rtl-optimization/49847] [4.6/4.7 Regression] m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL)
2011-07-25 21:07 [Bug java/49847] New: m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL) tg at mirbsd dot org
` (10 preceding siblings ...)
2012-01-22 13:39 ` mikpe at it dot uu.se
@ 2012-01-22 14:36 ` schwab@linux-m68k.org
2012-01-23 13:41 ` schwab@linux-m68k.org
` (26 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: schwab@linux-m68k.org @ 2012-01-22 14:36 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847
--- Comment #10 from Andreas Schwab <schwab@linux-m68k.org> 2012-01-22 12:45:56 UTC ---
In 4.7. Ada is also affected.
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug rtl-optimization/49847] [4.6/4.7 Regression] m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL)
2011-07-25 21:07 [Bug java/49847] New: m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL) tg at mirbsd dot org
` (11 preceding siblings ...)
2012-01-22 14:36 ` schwab@linux-m68k.org
@ 2012-01-23 13:41 ` schwab@linux-m68k.org
2012-01-23 16:37 ` [Bug rtl-optimization/49847] [4.7 Regression] " schwab@linux-m68k.org
` (25 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: schwab@linux-m68k.org @ 2012-01-23 13:41 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847
--- Comment #11 from Andreas Schwab <schwab@linux-m68k.org> 2012-01-23 13:05:35 UTC ---
After r183426 this is now dormant on the 4.6 branch again.
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug rtl-optimization/49847] [4.7 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)
2011-07-25 21:07 [Bug java/49847] New: m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL) tg at mirbsd dot org
` (12 preceding siblings ...)
2012-01-23 13:41 ` schwab@linux-m68k.org
@ 2012-01-23 16:37 ` schwab@linux-m68k.org
2012-01-23 20:22 ` schwab@linux-m68k.org
` (24 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: schwab@linux-m68k.org @ 2012-01-23 16:37 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847
Andreas Schwab <schwab@linux-m68k.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |build
Version|4.6.1 |4.7.0
Target Milestone|4.6.3 |4.7.0
Summary|[4.6/4.7 Regression] m68k |[4.7 Regression] NULL deref
|gcj-4.6 NULL deref in |in fold_rtx (prev_insn_cc0
|fold_rtx (prev_insn_cc0 == |== NULL)
|NULL) |
--- Comment #12 from Andreas Schwab <schwab@linux-m68k.org> 2012-01-23 16:03:21 UTC ---
The problem appears to be due to the exception region on a cc0 setter, which
separates it from the cc0 consumer:
(insn 4013 4012 8164 949 (set (cc0)
(compare (reg:SF 912 [ D.26269 ])
(const_double:SF -2147483648 [0x80000000] 2.147483648e+9
[0x0.8p+32]))) ../../../gcc/libjava/interpret.cc:131 -1
(expr_list:REG_EH_REGION (const_int 4 [0x4])
(nil)))
(note 8164 4013 4014 950 [bb 950] NOTE_INSN_BASIC_BLOCK)
(insn 4014 8164 4015 950 (set (reg:QI 2121)
(ge:QI (cc0)
(const_int 0 [0]))) ../../../gcc/libjava/interpret.cc:131 -1
(nil))
Happens in trunk since r180192.
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug rtl-optimization/49847] [4.7 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)
2011-07-25 21:07 [Bug java/49847] New: m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL) tg at mirbsd dot org
` (13 preceding siblings ...)
2012-01-23 16:37 ` [Bug rtl-optimization/49847] [4.7 Regression] " schwab@linux-m68k.org
@ 2012-01-23 20:22 ` schwab@linux-m68k.org
2012-02-05 21:57 ` mikpe at it dot uu.se
` (23 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: schwab@linux-m68k.org @ 2012-01-23 20:22 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847
--- Comment #13 from Andreas Schwab <schwab@linux-m68k.org> 2012-01-23 19:51:48 UTC ---
Reduced testcase, to be compiled with -O -fnon-call-exceptions.
int f (float g)
{
try { return g >= 0; }
catch (...) {}
}
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug rtl-optimization/49847] [4.7 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)
2011-07-25 21:07 [Bug java/49847] New: m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL) tg at mirbsd dot org
` (14 preceding siblings ...)
2012-01-23 20:22 ` schwab@linux-m68k.org
@ 2012-02-05 21:57 ` mikpe at it dot uu.se
2012-02-07 15:50 ` mikpe at it dot uu.se
` (22 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: mikpe at it dot uu.se @ 2012-02-05 21:57 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847
--- Comment #14 from Mikael Pettersson <mikpe at it dot uu.se> 2012-02-05 21:56:47 UTC ---
(In reply to comment #10)
> In 4.7. Ada is also affected.
Yeah, I got this same ICE in my latest attempt to natively bootstrap 4.7 with
Ada enabled and my patch for the Ada FP bug PR51483 applied. Happened in
a-calfor.adb sometime in or after stage 3.
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug rtl-optimization/49847] [4.7 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)
2011-07-25 21:07 [Bug java/49847] New: m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL) tg at mirbsd dot org
` (15 preceding siblings ...)
2012-02-05 21:57 ` mikpe at it dot uu.se
@ 2012-02-07 15:50 ` mikpe at it dot uu.se
2012-02-26 22:37 ` mikpe at it dot uu.se
` (21 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: mikpe at it dot uu.se @ 2012-02-07 15:50 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847
--- Comment #15 from Mikael Pettersson <mikpe at it dot uu.se> 2012-02-07 15:48:22 UTC ---
(In reply to comment #12)
> The problem appears to be due to the exception region on a cc0 setter, which
> separates it from the cc0 consumer:
>
> (insn 4013 4012 8164 949 (set (cc0)
> (compare (reg:SF 912 [ D.26269 ])
> (const_double:SF -2147483648 [0x80000000] 2.147483648e+9
> [0x0.8p+32]))) ../../../gcc/libjava/interpret.cc:131 -1
> (expr_list:REG_EH_REGION (const_int 4 [0x4])
> (nil)))
>
> (note 8164 4013 4014 950 [bb 950] NOTE_INSN_BASIC_BLOCK)
>
> (insn 4014 8164 4015 950 (set (reg:QI 2121)
> (ge:QI (cc0)
> (const_int 0 [0]))) ../../../gcc/libjava/interpret.cc:131 -1
> (nil))
>
> Happens in trunk since r180192.
r180192 contains two changes: it's the tree-eh.c change that triggers the ICE,
the other tree-ssa-forwprop.c change makes no difference to this PR.
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug rtl-optimization/49847] [4.7 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)
2011-07-25 21:07 [Bug java/49847] New: m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL) tg at mirbsd dot org
` (16 preceding siblings ...)
2012-02-07 15:50 ` mikpe at it dot uu.se
@ 2012-02-26 22:37 ` mikpe at it dot uu.se
2012-02-29 19:19 ` mikpe at it dot uu.se
` (20 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: mikpe at it dot uu.se @ 2012-02-26 22:37 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847
--- Comment #16 from Mikael Pettersson <mikpe at it dot uu.se> 2012-02-26 18:25:36 UTC ---
Created attachment 26757
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26757
make fold_rtx handle prev_insn_cc0 == NULL
The effect of Richard Guenther's r180192 patch to tree-eh.c is that "g >= 0.0"
(or its gimple equivalent) is recognized as potentially trapping, which causes
the cc0 setter and user to be put in separate BBs. That's usually a no-no, but
in the case of EH I'm not sure it can be avoided. Then as fold_rtx processes
the cc0 user at the start of the second BB, prev_insn_cc0 is NULL causing
equiv_constant to crash.
With the attached patch fold_rtx simply doesn't try to fold the current rtx
when prev_insn_cc0 is NULL. A build of 4.7-20120225 as a cross to m68k-linux
with java enabled succeeded with this patch applied, and it handled Andreas'
c++ test case too. I'm currently attempting a native bootstrap with both java
and ada enabled.
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug rtl-optimization/49847] [4.7 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)
2011-07-25 21:07 [Bug java/49847] New: m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL) tg at mirbsd dot org
` (17 preceding siblings ...)
2012-02-26 22:37 ` mikpe at it dot uu.se
@ 2012-02-29 19:19 ` mikpe at it dot uu.se
2012-03-22 8:43 ` [Bug rtl-optimization/49847] [4.7/4.8 " rguenth at gcc dot gnu.org
` (19 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: mikpe at it dot uu.se @ 2012-02-29 19:19 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847
--- Comment #17 from Mikael Pettersson <mikpe at it dot uu.se> 2012-02-29 19:13:12 UTC ---
(In reply to comment #16)
> Created attachment 26757 [details]
> make fold_rtx handle prev_insn_cc0 == NULL
>
> The effect of Richard Guenther's r180192 patch to tree-eh.c is that "g >= 0.0"
> (or its gimple equivalent) is recognized as potentially trapping, which causes
> the cc0 setter and user to be put in separate BBs. That's usually a no-no, but
> in the case of EH I'm not sure it can be avoided. Then as fold_rtx processes
> the cc0 user at the start of the second BB, prev_insn_cc0 is NULL causing
> equiv_constant to crash.
>
> With the attached patch fold_rtx simply doesn't try to fold the current rtx
> when prev_insn_cc0 is NULL. A build of 4.7-20120225 as a cross to m68k-linux
> with java enabled succeeded with this patch applied, and it handled Andreas'
> c++ test case too. I'm currently attempting a native bootstrap with both java
> and ada enabled.
The native bootstrap succeeded.
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug rtl-optimization/49847] [4.7/4.8 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)
2011-07-25 21:07 [Bug java/49847] New: m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL) tg at mirbsd dot org
` (18 preceding siblings ...)
2012-02-29 19:19 ` mikpe at it dot uu.se
@ 2012-03-22 8:43 ` rguenth at gcc dot gnu.org
2012-06-14 8:22 ` rguenth at gcc dot gnu.org
` (18 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: rguenth at gcc dot gnu.org @ 2012-03-22 8:43 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847
Richard Guenther <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|4.7.0 |4.7.1
--- Comment #18 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-03-22 08:26:29 UTC ---
GCC 4.7.0 is being released, adjusting target milestone.
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug rtl-optimization/49847] [4.7/4.8 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)
2011-07-25 21:07 [Bug java/49847] New: m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL) tg at mirbsd dot org
` (19 preceding siblings ...)
2012-03-22 8:43 ` [Bug rtl-optimization/49847] [4.7/4.8 " rguenth at gcc dot gnu.org
@ 2012-06-14 8:22 ` rguenth at gcc dot gnu.org
2012-09-20 10:18 ` jakub at gcc dot gnu.org
` (17 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: rguenth at gcc dot gnu.org @ 2012-06-14 8:22 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847
Richard Guenther <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|4.7.1 |4.7.2
--- Comment #19 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-06-14 08:21:52 UTC ---
GCC 4.7.1 is being released, adjusting target milestone.
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug rtl-optimization/49847] [4.7/4.8 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)
2011-07-25 21:07 [Bug java/49847] New: m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL) tg at mirbsd dot org
` (20 preceding siblings ...)
2012-06-14 8:22 ` rguenth at gcc dot gnu.org
@ 2012-09-20 10:18 ` jakub at gcc dot gnu.org
2013-04-11 8:00 ` [Bug rtl-optimization/49847] [4.7/4.8/4.9 " rguenth at gcc dot gnu.org
` (16 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: jakub at gcc dot gnu.org @ 2012-09-20 10:18 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|4.7.2 |4.7.3
--- Comment #20 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-09-20 10:16:25 UTC ---
GCC 4.7.2 has been released.
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug rtl-optimization/49847] [4.7/4.8/4.9 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)
2011-07-25 21:07 [Bug java/49847] New: m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL) tg at mirbsd dot org
` (21 preceding siblings ...)
2012-09-20 10:18 ` jakub at gcc dot gnu.org
@ 2013-04-11 8:00 ` rguenth at gcc dot gnu.org
2013-07-19 13:26 ` schwab@linux-m68k.org
` (15 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-04-11 8:00 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|4.7.3 |4.7.4
--- Comment #21 from Richard Biener <rguenth at gcc dot gnu.org> 2013-04-11 07:59:14 UTC ---
GCC 4.7.3 is being released, adjusting target milestone.
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug rtl-optimization/49847] [4.7/4.8/4.9 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)
2011-07-25 21:07 [Bug java/49847] New: m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL) tg at mirbsd dot org
` (22 preceding siblings ...)
2013-04-11 8:00 ` [Bug rtl-optimization/49847] [4.7/4.8/4.9 " rguenth at gcc dot gnu.org
@ 2013-07-19 13:26 ` schwab@linux-m68k.org
2013-07-29 20:57 ` tg at mirbsd dot org
` (14 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: schwab@linux-m68k.org @ 2013-07-19 13:26 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847
--- Comment #22 from Andreas Schwab <schwab@linux-m68k.org> ---
*** Bug 57929 has been marked as a duplicate of this bug. ***
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug rtl-optimization/49847] [4.7/4.8/4.9 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)
2011-07-25 21:07 [Bug java/49847] New: m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL) tg at mirbsd dot org
` (23 preceding siblings ...)
2013-07-19 13:26 ` schwab@linux-m68k.org
@ 2013-07-29 20:57 ` tg at mirbsd dot org
2014-02-07 22:58 ` law at redhat dot com
` (13 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: tg at mirbsd dot org @ 2013-07-29 20:57 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847
Thorsten Glaser <tg at mirbsd dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tg at mirbsd dot org
--- Comment #23 from Thorsten Glaser <tg at mirbsd dot org> ---
Can this please be committed, it definitely fixes gcc-4.8 on Debian/m68k
(applied it locally for now and asked the maintainer to include it in the
source package).
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug rtl-optimization/49847] [4.7/4.8/4.9 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)
2011-07-25 21:07 [Bug java/49847] New: m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL) tg at mirbsd dot org
` (24 preceding siblings ...)
2013-07-29 20:57 ` tg at mirbsd dot org
@ 2014-02-07 22:58 ` law at redhat dot com
2014-02-14 18:39 ` law at redhat dot com
` (12 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: law at redhat dot com @ 2014-02-07 22:58 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847
Jeffrey A. Law <law at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |law at redhat dot com,
| |richard.guenther at gmail dot com
--- Comment #24 from Jeffrey A. Law <law at redhat dot com> ---
This is a mess.
As noted in the other comments, we're considering a cc0-setter as a potentially
trapping insn. As a result the cc0-setter and cc0-consumer end up in different
blocks.
That's bad on so many levels and "fixing" it by hacking up fold_rtx like this
just papers over the fundamental problem (though I must admit from a pragmatic
standpoint, it's pretty effective).
One could argue that the CFG building code could be tweaked so that a
cc0-setter is never considered the end of a block. The downside of that is
we're lying to the compiler about the true nature of the CFG. But that little
white lie may be acceptable. I haven't looked into how ugly that would be to
implement.
One could also argue that this is an inherent flaw in cc0 targets and that any
unconverted backend should be converted to deprecated. There are certainly
better mechanisms for dealing with condition codes than the old cc0 nonsense.
But I have neither the time nor the interest in converting the m68k backend.
If we went this route it's a good bet the m68k backend would be deprecated.
In the end I'm at a loss about the best direction to take. Adding Richi on cc
for his thoughts.
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug rtl-optimization/49847] [4.7/4.8/4.9 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)
2011-07-25 21:07 [Bug java/49847] New: m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL) tg at mirbsd dot org
` (25 preceding siblings ...)
2014-02-07 22:58 ` law at redhat dot com
@ 2014-02-14 18:39 ` law at redhat dot com
2014-02-15 13:13 ` steven at gcc dot gnu.org
` (11 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: law at redhat dot com @ 2014-02-14 18:39 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847
--- Comment #26 from Jeffrey A. Law <law at redhat dot com> ---
I'd pondered the emit-the-condition twice, one marked as NOTHROW and it may
ultimately be the best short term solution. I just don't have enough
background on the original change which resulted in this problem to evaluate if
other solutions might be viable.
FWIW, at one time we did (or considered) a vaguely similar trick to deal with
reloads of float point condition codes. IIRC, the target had multiple FP
condition code registers, so we wanted to use pseudos and allocate them like
any other register. Of course that leads to the potential problem that you can
run out and may need to spill them, but the only way to set the hard registers
was by doing comparisons, so reloading them after spilling was, umm,
nontrivial. Not sure what ever happened with that.
FWIW, this potentially affects the m68k, vax, v850, pdp11, h8300, cris, avr and
cr16. Of those, I think only the m68k has an FPU, so the impact may be very
very small right now.
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug rtl-optimization/49847] [4.7/4.8/4.9 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)
2011-07-25 21:07 [Bug java/49847] New: m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL) tg at mirbsd dot org
` (26 preceding siblings ...)
2014-02-14 18:39 ` law at redhat dot com
@ 2014-02-15 13:13 ` steven at gcc dot gnu.org
2014-02-15 14:22 ` schwab@linux-m68k.org
` (10 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: steven at gcc dot gnu.org @ 2014-02-15 13:13 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847
Steven Bosscher <steven at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |steven at gcc dot gnu.org
--- Comment #28 from Steven Bosscher <steven at gcc dot gnu.org> ---
(In reply to Jeffrey A. Law from comment #24)
> One could argue that the CFG building code could be tweaked so that a
> cc0-setter is never considered the end of a block.
The CFG is built too early (on gimple) to know what may end up a cc0
setter. It'd take more than a few CFG fixup hacks after expanding to
RTL to get the cc0-setter and cc0-consumer back together in the same
basic block.
How did this work (i.e. what did the CFG look like) before tree-ssa,
e.g. in gcc 3.4?
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug rtl-optimization/49847] [4.7/4.8/4.9 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)
2011-07-25 21:07 [Bug java/49847] New: m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL) tg at mirbsd dot org
` (27 preceding siblings ...)
2014-02-15 13:13 ` steven at gcc dot gnu.org
@ 2014-02-15 14:22 ` schwab@linux-m68k.org
2014-02-15 18:59 ` rguenther at suse dot de
` (9 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: schwab@linux-m68k.org @ 2014-02-15 14:22 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847
--- Comment #29 from Andreas Schwab <schwab@linux-m68k.org> ---
In gcc <= 4.6 I'm unable to tell the compiler to consider the fp compare
trapping even with -ftrapping-math.
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug rtl-optimization/49847] [4.7/4.8/4.9 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)
2011-07-25 21:07 [Bug java/49847] New: m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL) tg at mirbsd dot org
` (28 preceding siblings ...)
2014-02-15 14:22 ` schwab@linux-m68k.org
@ 2014-02-15 18:59 ` rguenther at suse dot de
2014-02-16 13:17 ` jackie.rosen at hushmail dot com
` (8 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: rguenther at suse dot de @ 2014-02-15 18:59 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847
--- Comment #30 from rguenther at suse dot de <rguenther at suse dot de> ---
On February 15, 2014 3:22:54 PM GMT+01:00, "schwab@linux-m68k.org"
<gcc-bugzilla@gcc.gnu.org> wrote:
>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847
>
>--- Comment #29 from Andreas Schwab <schwab@linux-m68k.org> ---
>In gcc <= 4.6 I'm unable to tell the compiler to consider the fp
>compare
>trapping even with -ftrapping-math.
And before the rev. Cited we failed to create eh edges / info. And if we'd have
eh edges out of the gimple_cond then we'd generate wrong unwind info.
Spilling cc0 by rematerializing the compare seems to be the only way out.
Unless the target can avoid iceing. Cc0 should be live on the fallthru edge -
so what _is_ exactly the problem we are facing?
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug rtl-optimization/49847] [4.7/4.8/4.9 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)
2011-07-25 21:07 [Bug java/49847] New: m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL) tg at mirbsd dot org
` (29 preceding siblings ...)
2014-02-15 18:59 ` rguenther at suse dot de
@ 2014-02-16 13:17 ` jackie.rosen at hushmail dot com
2014-02-17 10:01 ` rguenther at suse dot de
` (7 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: jackie.rosen at hushmail dot com @ 2014-02-16 13:17 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847
Jackie Rosen <jackie.rosen at hushmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jackie.rosen at hushmail dot com
--- Comment #31 from Jackie Rosen <jackie.rosen at hushmail dot com> ---
*** Bug 260998 has been marked as a duplicate of this bug. ***
Seen from the domain http://volichat.com
Page where seen: http://volichat.com/adult-chat-rooms
Marked for reference. Resolved as fixed @bugzilla.
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug rtl-optimization/49847] [4.7/4.8/4.9 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)
2011-07-25 21:07 [Bug java/49847] New: m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL) tg at mirbsd dot org
` (30 preceding siblings ...)
2014-02-16 13:17 ` jackie.rosen at hushmail dot com
@ 2014-02-17 10:01 ` rguenther at suse dot de
2014-02-25 6:14 ` law at redhat dot com
` (6 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: rguenther at suse dot de @ 2014-02-17 10:01 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847
--- Comment #33 from rguenther at suse dot de <rguenther at suse dot de> ---
On Sun, 16 Feb 2014, law at redhat dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847
>
> --- Comment #32 from Jeffrey A. Law <law at redhat dot com> ---
> The problem we're seeing is with the cc0-setter and cc0-user in different
> blocks, they're separated by a NOTE_BASIC_BLOCK.
>
> That causes CSE to blow up because it expects that the cc0-setter and
> cc0-user are always consecutive. While we're just seeing the failure in
> CSE right now, I'm sure there's a ton of places that assume the
> setter/user are inseparable as that has been the documented form for ~20
> years.
>
> From rtl.texi:
>
> The instruction setting the
> condition code must be adjacent to the instruction using the condition
> code; only @code{note} insns may separate them.
>
>
> We either need to relax that and audit all the HAVE_cc0 code to ensure it
> doesn't make that assumption, or we need to somehow restore the property that
> the setter and user are inseparable.
I think relaxing this constraint and allowing the cc0-setter and
cc0-user be separated by a fallthru-edge should be allowed
(and make sure that bb-reorder later doesn't separate the BBs)
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug rtl-optimization/49847] [4.7/4.8/4.9 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)
2011-07-25 21:07 [Bug java/49847] New: m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL) tg at mirbsd dot org
` (31 preceding siblings ...)
2014-02-17 10:01 ` rguenther at suse dot de
@ 2014-02-25 6:14 ` law at redhat dot com
2014-02-25 8:41 ` rguenther at suse dot de
` (5 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: law at redhat dot com @ 2014-02-25 6:14 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847
--- Comment #34 from Jeffrey A. Law <law at redhat dot com> ---
OK. Then I suggest two immediate things to do.
1. Fix the documentation for cc0 targets to indicate that the setter/user no
longer have to be consecutive, particularly in the presence of
flag_trapping_math.
2. Fault in fixes. While a review of every bit of HAVE_cc0 code is warranted,
I'm not terribly inclined as HAVE_cc0 targets simply aren't that important
anymore.
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug rtl-optimization/49847] [4.7/4.8/4.9 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)
2011-07-25 21:07 [Bug java/49847] New: m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL) tg at mirbsd dot org
` (32 preceding siblings ...)
2014-02-25 6:14 ` law at redhat dot com
@ 2014-02-25 8:41 ` rguenther at suse dot de
2014-02-27 19:03 ` law at gcc dot gnu.org
` (4 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: rguenther at suse dot de @ 2014-02-25 8:41 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847
--- Comment #35 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 25 Feb 2014, law at redhat dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847
>
> --- Comment #34 from Jeffrey A. Law <law at redhat dot com> ---
> OK. Then I suggest two immediate things to do.
>
> 1. Fix the documentation for cc0 targets to indicate that the setter/user no
> longer have to be consecutive, particularly in the presence of
> flag_trapping_math.
Sounds good. I'd document that they still should be consecutive
instructions (if interpreting 'consecutive' as following a
fallthru path). And say the cc0 setter may be the source of
EH edges.
> 2. Fault in fixes. While a review of every bit of HAVE_cc0 code is warranted,
> I'm not terribly inclined as HAVE_cc0 targets simply aren't that important
> anymore.
I suppose fixing things as they arise is good enough. But yes, HAVE_cc0
should be phased out - but I suppose it's unlikely to get existing ports
to convert ...
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug rtl-optimization/49847] [4.7/4.8/4.9 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)
2011-07-25 21:07 [Bug java/49847] New: m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL) tg at mirbsd dot org
` (33 preceding siblings ...)
2014-02-25 8:41 ` rguenther at suse dot de
@ 2014-02-27 19:03 ` law at gcc dot gnu.org
2014-06-12 13:43 ` [Bug rtl-optimization/49847] [4.7/4.8 " rguenth at gcc dot gnu.org
` (3 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: law at gcc dot gnu.org @ 2014-02-27 19:03 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847
--- Comment #36 from Jeffrey A. Law <law at gcc dot gnu.org> ---
Author: law
Date: Thu Feb 27 19:02:18 2014
New Revision: 208203
URL: http://gcc.gnu.org/viewcvs?rev=208203&root=gcc&view=rev
Log:
PR rtl-optimization/49847
* cse.c (fold_rtx) Handle case where cc0 setter and cc0 user
are in different blocks.
* doc/tm.texi (Condition Code Status): Update documention for
relative locations of cc0-setter and cc0-user.
PR rtl-optimization/49847
* g++.dg/pr49847.C: New test.
Added:
trunk/gcc/testsuite/g++.dg/pr49847.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cse.c
trunk/gcc/doc/tm.texi
trunk/gcc/testsuite/ChangeLog
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug rtl-optimization/49847] [4.7/4.8 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)
2011-07-25 21:07 [Bug java/49847] New: m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL) tg at mirbsd dot org
` (34 preceding siblings ...)
2014-02-27 19:03 ` law at gcc dot gnu.org
@ 2014-06-12 13:43 ` rguenth at gcc dot gnu.org
2014-12-19 13:35 ` [Bug rtl-optimization/49847] [4.8 " jakub at gcc dot gnu.org
` (2 subsequent siblings)
38 siblings, 0 replies; 40+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-06-12 13:43 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|4.7.4 |4.8.4
--- Comment #37 from Richard Biener <rguenth at gcc dot gnu.org> ---
The 4.7 branch is being closed, moving target milestone to 4.8.4.
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug rtl-optimization/49847] [4.8 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)
2011-07-25 21:07 [Bug java/49847] New: m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL) tg at mirbsd dot org
` (35 preceding siblings ...)
2014-06-12 13:43 ` [Bug rtl-optimization/49847] [4.7/4.8 " rguenth at gcc dot gnu.org
@ 2014-12-19 13:35 ` jakub at gcc dot gnu.org
2015-01-19 22:35 ` law at redhat dot com
2015-01-20 8:16 ` rguenth at gcc dot gnu.org
38 siblings, 0 replies; 40+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-12-19 13:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|4.8.4 |4.8.5
--- Comment #38 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.8.4 has been released.
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug rtl-optimization/49847] [4.8 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)
2011-07-25 21:07 [Bug java/49847] New: m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL) tg at mirbsd dot org
` (36 preceding siblings ...)
2014-12-19 13:35 ` [Bug rtl-optimization/49847] [4.8 " jakub at gcc dot gnu.org
@ 2015-01-19 22:35 ` law at redhat dot com
2015-01-20 8:16 ` rguenth at gcc dot gnu.org
38 siblings, 0 replies; 40+ messages in thread
From: law at redhat dot com @ 2015-01-19 22:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847
Jeffrey A. Law <law at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #39 from Jeffrey A. Law <law at redhat dot com> ---
Fixed in 4.9 and on trunk. Not planning to backport fix to 4.8.
^ permalink raw reply [flat|nested] 40+ messages in thread* [Bug rtl-optimization/49847] [4.8 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)
2011-07-25 21:07 [Bug java/49847] New: m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL) tg at mirbsd dot org
` (37 preceding siblings ...)
2015-01-19 22:35 ` law at redhat dot com
@ 2015-01-20 8:16 ` rguenth at gcc dot gnu.org
38 siblings, 0 replies; 40+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-01-20 8:16 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|4.8.5 |4.9.0
^ permalink raw reply [flat|nested] 40+ messages in thread