[Bug middle-end/17126] [3.5 Regression] ICE in GC with non-unit-at-a-time

["bommar33 at msu dot edu" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From bommar33 at msu dot edu  2004-08-20 23:51 -------
(In reply to comment #3)
> I can't seem to get anything off this darn testcase. I'll attach it 
> at least without the line indicators. The ICE is a regression from 3.4, 
> btw. 
>  
> W. 

Took a break for a meal and sat back down to look at this, and I noticed one
difference between your testcase and the kernel source.  It struck me as
peculiar when I was testing the 2.6.8.1 release that both the inode.c from
2.6.8.1 and 2.6.8.1-mm3, although they fail in different functions,
(usbfs_add_device for vanilla and usbfs_remove_device in -mm3, adjacent in the
source) they generate the exact same assembly source.  

Both assembly sources fail after this block:
.L330:
	movl	$.LC9, 4(%esp)
	movl	$.LC25, (%esp)
	call	printk
	addl	$44, %esp
	popl	%ebx
	popl	%esi
	popl	%edi
	popl	%ebp
	ret
	.size	usbfs_add_device, .-usbfs_add_device

Upon further investigation, the following becomes apparent:

$] gcc -E -fno-unit-at-a-time -fomit-frame-pointer -O3 -march=athlon-xp inode.i
SUCCEEDS


$] gcc -S -fno-unit-at-a-time -fomit-frame-pointer -O3 -march=athlon-xp inode.i
FAILS

Therefore, we know the segfault occurs past preprocessing.

Now, to determine where which flags truly trigger the segfault.

$] gcc -S -fno-unit-at-a-time -fomit-frame-pointer -O3 -march=athlon-xp inode.i
FAILS

$] gcc -S -fno-unit-at-a-time -fomit-frame-pointer -O2 -march=athlon-xp inode.i
SUCCEEDS

$] gcc -S -fno-unit-at-a-time -fomit-frame-pointer -O3 inode.i
FAILS

$] gcc -S -fomit-frame-pointer -O3 inode.i
SUCCEEDS

$] gcc -S -fno-unit-at-a-time -O3 inode.i
FAILS

$] gcc -S -fno-unit-at-a-time -O2 inode.i
SUCCEEDS

By a rather ugly process of elimination, this "narrows" the problem down to the
code handling the third level of optimization and its interaction with
-fno-unit-at-a-time.  Hope this helps someone with more knowledge of the real
internals save a few minutes and get to the problem at hand.

-- 


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