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: unassig...@gcc.gnu.org
ReportedBy: paulo.ma...@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.
