[Bug java/49847] New: m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL)

[Bug java/49847] New: m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL)

[tg at mirbsd dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847

           Summary: m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 ==
                    NULL)
           Product: gcc
           Version: 4.6.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: java
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: tg@mirbsd.org


Forwarding from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633754

Trying to bootstrap gcj-4.6 on Debian/m68k (gcj-4.4 and gcc-4.6 work fine).
Reproducible ICE trying to build the runtime library, after bootstrapping
passed:

/bin/bash ./libtool --tag=GCJ   --mode=compile
/tmp/buildd/gcj-4.6-4.6.1/build/./gcc/gcj
-B/tmp/buildd/gcj-4.6-4.6.1/build/m68k-linux-gnu/m68040/libjava/
-B/tmp/buildd/gcj-4.6-4.6.1/build/m68k-linux-gnu/m68040/libjava/
-B/tmp/buildd/gcj-4.6-4.6.1/build/./gcc/ -B/usr/m68k-linux-gnu/bin/
-B/usr/m68k-linux-gnu/lib/ -isystem /usr/m68k-linux-gnu/include -isystem
/usr/m68k-linux-gnu/sys-include  -m68040 -fclasspath=
-fbootclasspath=../../../../src/libjava/classpath/lib --encoding=UTF-8
-Wno-deprecated -fbootstrap-classes -g -O2  -m68040  -c -o java/util.lo
-fsource-filename=/tmp/buildd/gcj-4.6-4.6.1/build/m68k-linux-gnu/m68040/libjava/classpath/lib/classes
-MT java/util.lo -MD -MP -MF java/util.deps @java/util.list

/tmp/buildd/gcj-4.6-4.6.1/src/libjava/classpath/java/util/Random.java:427:0:
internal compiler error: Segmentation fault

This is still a cc0 architecture, as the problem is:

Program received signal SIGSEGV, Segmentation fault.
equiv_constant (x=0x0) at ../../src/gcc/cse.c:3812
3812      if (REG_P (x)
(gdb) bt
#0  equiv_constant (x=0x0) at ../../src/gcc/cse.c:3812
#1  0x804b0542 in fold_rtx (x=0xc83cb5f4, insn=0xc83cc1c0) at
../../src/gcc/cse.c:3274
#2  0x804b05fe in fold_rtx (x=0xc83c4f30, insn=0xc83cc1c0) at
../../src/gcc/cse.c:3279
#3  0x804b35ec in cse_insn (insn=0xc83cc1c0) at ../../src/gcc/cse.c:4511
[…]
(gdb) frame 1
#1  0x804b0542 in fold_rtx (x=0xc83cb5f4, insn=0xc83cc1c0) at
../../src/gcc/cse.c:3274
3274                const_arg = equiv_constant (folded_arg);
(gdb) list
3269
3270    #ifdef HAVE_cc0
3271              case CC0:
3272                folded_arg = prev_insn_cc0;
3273                mode_arg = prev_insn_cc0_mode;
3274                const_arg = equiv_constant (folded_arg);
3275                break;
3276    #endif
3277
3278              default:
(gdb) print folded_arg
$1 = (rtx) 0x0
(gdb) print prev_insn_cc0
$2 = (rtx) 0x0
(gdb) print prev_insn_cc0_mode
$3 = VOIDmode

More information in the linked bug report.

[Bug java/49847] m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL)

[tg at mirbsd dot org]

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.

[Bug java/49847] m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL)

[mikpe at it dot uu.se]

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.

[Bug rtl-optimization/49847] [4.6/4.7 Regression] m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL)

[pinskia at gcc dot gnu.org]

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

[Bug rtl-optimization/49847] [4.6/4.7 Regression] m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL)

[jakub at gcc dot gnu.org]

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

[Bug rtl-optimization/49847] [4.6/4.7 Regression] m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL)

[mikpe at it dot uu.se]

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.

[Bug rtl-optimization/49847] [4.6/4.7 Regression] m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL)

[tg at mirbsd dot org]

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.

[Bug rtl-optimization/49847] [4.6/4.7 Regression] m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL)

[mikpe at it dot uu.se]

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.

[Bug rtl-optimization/49847] [4.6/4.7 Regression] m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL)

[schwab@linux-m68k.org]

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.

[Bug rtl-optimization/49847] [4.6/4.7 Regression] m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL)

[schwab@linux-m68k.org]

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.

[Bug rtl-optimization/49847] [4.6/4.7 Regression] m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL)

[schwab@linux-m68k.org]

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.

[Bug rtl-optimization/49847] [4.6/4.7 Regression] m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL)

[mikpe at it dot uu.se]

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.

[Bug rtl-optimization/49847] [4.6/4.7 Regression] m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL)

[schwab@linux-m68k.org]

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.

[Bug rtl-optimization/49847] [4.6/4.7 Regression] m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL)

[schwab@linux-m68k.org]

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.

[Bug rtl-optimization/49847] [4.7 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)

[schwab@linux-m68k.org]

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.

[Bug rtl-optimization/49847] [4.7 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)

[schwab@linux-m68k.org]

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 (...) {}
}

[Bug rtl-optimization/49847] [4.7 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)

[mikpe at it dot uu.se]

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.

[Bug rtl-optimization/49847] [4.7 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)

[mikpe at it dot uu.se]

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.

[Bug rtl-optimization/49847] [4.7 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)

[mikpe at it dot uu.se]

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.

[Bug rtl-optimization/49847] [4.7 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)

[mikpe at it dot uu.se]

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.

[Bug rtl-optimization/49847] [4.7/4.8 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)

[rguenth at gcc dot gnu.org]

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.

[Bug rtl-optimization/49847] [4.7/4.8 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)

[rguenth at gcc dot gnu.org]

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.

[Bug rtl-optimization/49847] [4.7/4.8 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)

[jakub at gcc dot gnu.org]

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.

[Bug rtl-optimization/49847] [4.7/4.8/4.9 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)

[rguenth at gcc dot gnu.org]

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.

[Bug rtl-optimization/49847] [4.7/4.8/4.9 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)

[schwab@linux-m68k.org]

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. ***

[Bug rtl-optimization/49847] [4.7/4.8/4.9 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)

[tg at mirbsd dot org]

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).

[Bug rtl-optimization/49847] [4.7/4.8/4.9 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)

[law at redhat dot com]

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.

[Bug rtl-optimization/49847] [4.7/4.8/4.9 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)

[law at redhat dot com]

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.

[Bug rtl-optimization/49847] [4.7/4.8/4.9 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)

[steven at gcc dot gnu.org]

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?

[Bug rtl-optimization/49847] [4.7/4.8/4.9 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)

[schwab@linux-m68k.org]

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.

[Bug rtl-optimization/49847] [4.7/4.8/4.9 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)

[rguenther at suse dot de]

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?

[Bug rtl-optimization/49847] [4.7/4.8/4.9 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)

[jackie.rosen at hushmail dot com]

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.

[Bug rtl-optimization/49847] [4.7/4.8/4.9 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)

[rguenther at suse dot de]

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)

[Bug rtl-optimization/49847] [4.7/4.8/4.9 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)

[law at redhat dot com]

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.

[Bug rtl-optimization/49847] [4.7/4.8/4.9 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)

[rguenther at suse dot de]

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 ...

[Bug rtl-optimization/49847] [4.7/4.8/4.9 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)

[law at gcc dot gnu.org]

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

[Bug rtl-optimization/49847] [4.7/4.8 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)

[rguenth at gcc dot gnu.org]

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.

[Bug rtl-optimization/49847] [4.8 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)

[jakub at gcc dot gnu.org]

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.

[Bug rtl-optimization/49847] [4.8 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)

[law at redhat dot com]

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.

[Bug rtl-optimization/49847] [4.8 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)

[rguenth at gcc dot gnu.org]

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