[Bug middle-end/47782] New: Infinite cycle generates segmentation fault in targets without cbranch support

[Bug middle-end/47782] New: Infinite cycle generates segmentation fault in targets without cbranch support

[Paulo.Matos at csr dot com]

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

           Summary: Infinite cycle generates segmentation fault in targets
                    without cbranch support
           Product: gcc
           Version: 4.5.2
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: Paulo.Matos@csr.com


Created attachment 23378
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23378
patch to assert !can_compare_p

I have tested this with gcc 4.5.2. It doesn't happen in 4.4.4. 
There's a possibility for an infinite loop between two dojump.c functions:

do_jump_by_parts_greater_rtx

and

do_compare_rtx_and_jump

One condition needs to be met: !can_compare_p(code, mode, ccp_jump).
As far as I understand from the code this is when the target doesn't implement
cbranch<mode>.

Unfortunately you can't reproduce it straightforwardly with i386 since it
implements cbranch<mode> but by patching gcc with the no-cbranch.patch you can
make gcc think there's no cbranch<mode>.

The minimized and modified testcase is _mulhi3.i.

You'll be able to reproduce this on a 64bit. If you have a 32bit you might
reproduce it without any changes but you can also try (but it is untested) the
substitutions s/DI/SI and s/TI/DI.

Run the line:
<pathtogccbuild>/cc1 -O2 _muldi3.i

I have seen two behaviours... either you get a segmentation fault or an
infinite loop that will eat all your memory if you don't limit it.

In the meantime I am trying to sort out what the problem is.

[Bug middle-end/47782] Infinite cycle generates segmentation fault in targets without cbranch support

[Paulo.Matos at csr dot com]

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

--- Comment #1 from Paulo J. Matos <Paulo.Matos at csr dot com> 2011-02-17 11:55:32 UTC ---
Created attachment 23379
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23379
source code to reproduce bug

[Bug middle-end/47782] Infinite cycle generates segmentation fault in targets without cbranch support

[Paulo.Matos at csr dot com]

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

--- Comment #2 from Paulo J. Matos <Paulo.Matos at csr dot com> 2011-02-17 14:56:45 UTC ---
Just a note to this... this bug assumes that cbranch<mode>4 is _not_
implemented. If cbranch<mode>4 is not an optional standard name to implement
then this bug is invalid, but we should document this requirement somewhere.

I just noticed that optabs.h has the comment before can_compare_p:

/* Nonzero if a compare of mode MODE can be done straightforwardly
   (without splitting it into pieces).  */
extern int can_compare_p (enum rtx_code, enum machine_mode,
              enum can_compare_purpose);

By this I assume that cbranch should be implemented if there is an instruction
that performs a compare and branch in one go without ''splitting it into
pieces''. However, by looking at the vax case (which I think it does not have
such an intruction) cbranch is implemented as:

(define_expand "cbranch<mode>4"
  [(set (cc0)
        (compare (match_operand:VAXint 1 "nonimmediate_operand" "")
                 (match_operand:VAXint 2 "general_operand" "")))
   (set (pc)
        (if_then_else
              (match_operator 0 "ordered_comparison_operator" [(cc0)
                                                               (const_int 0)])
              (label_ref (match_operand 3 "" ""))
              (pc)))]
 "")

which ends up expanding it into multiple insns...

I can do the same on my side. However, that makes cbranch non-optional which is
not-documented and breaks backward compatibility (in the sense that in previous
gcc versions the lack of a cbranch implementation didn't seem to trigger any
strange bug).

[Bug middle-end/47782] Infinite cycle generates segmentation fault in targets without cbranch support

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> 2011-02-17 16:01:49 UTC ---
I think cbranch is required in 4.5 where the cleanup happened.  And yes we
broke backwards compatibility to cleanup the backends.

[Bug middle-end/47782] Infinite cycle generates segmentation fault in targets without cbranch support

[Paulo.Matos at csr dot com]

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

--- Comment #4 from Paulo J. Matos <Paulo.Matos at csr dot com> 2011-02-17 16:04:36 UTC ---
Thanks Andy, was that documented anywhere? It would be interesting for me to
know which other stuff became compulsory to implement in the backend.

[Bug middle-end/47782] Infinite cycle generates segmentation fault in targets without cbranch support

[bonzini at gnu dot org]

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

Paolo Bonzini <bonzini at gnu dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID

--- Comment #5 from Paolo Bonzini <bonzini at gnu dot org> 2011-02-17 16:20:43 UTC ---
You can look in March to May 2009 at patches with a [cond-optab] tag.

Unfortunately "news for developers" have been only introduced in the 4.6
release notes, so it was not written outside the mailing lists.

Just like bCC patterns have been replaced by cbranch, sCC have been replaced by
cstore.  Most conversions should be pretty straightforward:

* if you're using a cmpMM pattern that just saves operands and modes, and your
bCC pattern calls some routine in your backend's .c file, your cbranch patterns
can save the operands and mode, and then call the same routine as your existing
bCC pattern.

* if your cmpMM and bCC patterns are actually define_insns, your cbranch
patterns can be very simple define_expand that generates the same RTL followed
by the RTL for bCC.

In most cases the conversion will have no real change on assembly, and should
cut at least 50-100 lines from your backend (but for some almost 1000 were
removed in the GCC sources!).

If your backend had been in-tree, I would have fixed it for you. :)

[Bug middle-end/47782] Infinite cycle generates segmentation fault in targets without cbranch support

[Paulo.Matos at csr dot com]

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

--- Comment #6 from Paulo J. Matos <Paulo.Matos at csr dot com> 2011-02-17 16:23:47 UTC ---
Thanks Paolo, I will take a look at those patches.