Bug 19636 - [4.2 regression] Can't compile large switch statement
Summary: [4.2 regression] Can't compile large switch statement
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 4.0.0
: P4 normal
Target Milestone: 4.3.0
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-on-valid-code
Depends on:
Blocks: 24894
  Show dependency treegraph
 
Reported: 2005-01-26 10:59 UTC by dieter meier
Modified: 2009-03-30 16:05 UTC (History)
5 users (show)

See Also:
Host: i386
Target: avr
Build:
Known to work: 3.3.2 3.4.3 4.3.0
Known to fail: 4.0.0 4.0.2 4.0.4 4.1.1 4.1.2 4.2.0 4.2.5
Last reconfirmed: 2007-04-09 22:14:02


Attachments
usart.i (5.98 KB, text/plain)
2005-01-26 11:00 UTC, dieter meier
Details

Note You need to log in before you can comment on or make changes to this bug.
Description dieter meier 2005-01-26 10:59:14 UTC
Hi, I'm testing gcc version 4.0.0 20050123:

avr-gcc -c  -Os  usart.i

usart.c: In function 'UsartIOCtl':
usart.c:821: error: unable to find a register to spill in class 
'BASE_POINTER_REGS'
usart.c:821: error: this is the insn:
(insn 653 159 160 14 (set (mem:HI (plus:HI (reg/f:HI 28 r28)
                (const_int 1 [0x1])) [32 S2 A8])
        (reg:HI 24 r24)) 12 {*movhi} (nil)
    (nil))
usart.c:821: internal compiler error: in spill_failure, at reload1.c:1872



Maybe, PR12017 is related to this PR?
Comment 1 dieter meier 2005-01-26 11:00:16 UTC
Created attachment 8073 [details]
usart.i
Comment 2 Eric Weddington 2005-02-10 18:59:24 UTC
The testcase compiles successfully with avr-gcc on 3.3.2, and 3.4.3, using
-mmcu=atmega128.
Could someone with sufficient permissions please set the "Known To Work" field.

Dieter, could you confirm which device you're compiling for?
Comment 3 Eric Weddington 2005-02-10 19:43:49 UTC
Dieter, could you please try this out with a more recent snapshot?
Comment 4 dieter meier 2005-02-10 21:44:17 UTC
It still fails with  4.0.0 20050209.
BTW, it only fails with -Os. (-O0 to -O3 are OK)
3_4 branch is OK, too.
Comment 5 Eric Weddington 2005-02-10 21:48:23 UTC
Subject: Re:  Can't compile ethernut OS (avr-gcc)

dieterbmeier at yahoo dot com wrote:

>------- Additional Comments From dieterbmeier at yahoo dot com  2005-02-10 21:44 -------
>It still fails with  4.0.0 20050209.
>BTW, it only fails with -Os. (-O0 to -O3 are OK)
>3_4 branch is OK, too.
>
>  
>
Which device are you compiling for? (-mmcu=?)
Comment 6 dieter meier 2005-02-10 22:04:28 UTC
>Which device are you compiling for? (-mmcu=?)

atmega128
Comment 7 andy hutchinson 2005-02-13 02:07:41 UTC
Try patch attached to PR 18251. Good chance it will fix.
If not, pass me the source for a llok at.


Comment 8 dieter meier 2005-02-22 10:41:04 UTC
>Try patch attached to PR 18251. Good chance it will fix.

I still fails. (18251.patch.bz2 applied)

>If not, pass me the source for a llok at.


Its already attached to this pr.

http://gcc.gnu.org/bugzilla/attachment.cgi?id=8073&action=view
Comment 9 berndtrog 2005-04-30 17:41:42 UTC
I can confirm this bug for 4_0 and head (using -Os).

Note:
gcc-head-2004-12-07 compiles usart.i OK.
gcc-head-2004-12-29 fails with:

usart.c: In function 'UsartIOCtl':
usart.c:821: error: unable to find a register to spill in class 'BASE_POINTER_REGS'
usart.c:821: error: this is the insn:
(insn 653 159 160 14 (set (mem:HI (plus:HI (reg/f:HI 28 r28)
                (const_int 1 [0x1])) [32 S2 A8])
        (reg:HI 24 r24)) 12 {*movhi} (nil)
    (nil))
usart.c:821: internal compiler error: in spill_failure, at reload1.c:1873
Comment 10 Eric Weddington 2005-05-05 18:09:01 UTC
Will someone with the requisite permissions please set this bug to NEW? This has
been confirmed.

Thanks
Eric
Comment 11 berndtrog 2005-12-05 18:34:22 UTC
Compiling of usart.i still fails:

usart.c: In function 'UsartIOCtl':
usart.c:821: error: unable to find a register to spill in class 'BASE_POINTER_REGS'
usart.c:821: error: this is the insn:
(insn 663 162 163 14 (set (mem:HI (plus:HI (reg/f:HI 28 r28)
                (const_int 1 [0x1])) [31 S2 A8])
        (reg:HI 24 r24)) 12 {*movhi} (nil)
    (nil))
usart.c:821: confused by earlier errors, bailing out

Tested with: 4.0.3 20051123, 4.1.0 20051202, 4.2.0 20051202

It compiles OK with 3.4.5 
Comment 12 plessl 2006-10-11 08:44:48 UTC
I can confirm that this bug still exists on with avr-gcc (GCC) 4.0.2 (running on Mac OS X 10.4.8/PPC, installed via Macports)

avr-gcc -Os ~/Documents/Downloads/usart.iusart.c: In function ‘UsartIOCtl’:
usart.c:821: error: unable to find a register to spill in class ‘BASE_POINTER_REGS’
usart.c:821: error: this is the insn:
(insn 663 162 163 14 (set (mem:HI (plus:HI (reg/f:HI 28 r28)
                (const_int 1 [0x1])) [31 S2 A8])
        (reg:HI 24 r24)) 12 {*movhi} (nil)
    (nil))
usart.c:821: confused by earlier errors, bailing out


Is there any news on this bug? 
Comment 13 Eric Weddington 2006-10-11 17:05:33 UTC
(In reply to comment #12)
> I can confirm that this bug still exists on with avr-gcc (GCC) 4.0.2 (running
> on Mac OS X 10.4.8/PPC, installed via Macports)
<snip>
> Is there any news on this bug? 

Sorry, no. Your comment has been the latest news.

Can you try using GCC 4.1.1 and see if you can still reproduce this bug? That would be very informative.

Comment 14 plessl 2006-10-17 14:43:10 UTC
(In reply to comment #13)
> Can you try using GCC 4.1.1 and see if you can still reproduce this bug? That
> would be very informative.

Yes, the bug is still present in gcc-4.1.1, see below. I also had problems building gcc-4.1.1 for avr. libssp doesn't compile for this target, hence I had to disable it  by passing --disable-libssp to configure.

usart.c: In function ‘UsartIOCtl’:
usart.c:821: error: unable to find a register to spill in class ‘BASE_POINTER_REGS’
usart.c:821: error: this is the insn:
(insn 663 162 163 14 (set (mem/c:HI (plus:HI (reg/f:HI 28 r28)
                (const_int 1 [0x1])) [27 S2 A8])
        (reg:HI 24 r24)) 12 {*movhi} (nil)
    (nil))
usart.c:821: confused by earlier errors, bailing out


Comment 15 Mustafa Yuecel 2006-10-27 10:31:06 UTC
Found an important hint:

If the switch instruction is replaced with else ifs, the file is also compilable with the -Os option. It seems that the avr-gcc >4.0 can only optimize a limited number of cases (the file usart.i has 33 cases in one switch statement).
Comment 16 Eric Weddington 2007-05-21 17:03:05 UTC
Fails with 4.1.2.
Comment 17 Eric Weddington 2007-05-21 17:09:51 UTC
Fails on 4.2.0.
Comment 18 Eric Weddington 2007-05-21 17:17:42 UTC
Using the target specific option -mno-tablejump fixes the bug for 4.1.2 and 4.2.0.
Comment 19 Eric Weddington 2007-05-30 18:59:41 UTC
Testcase succeeds with 4.3-20070525, with all -O settings. Changing target milestone to 4.3.0, lowering priority.
Comment 20 Joseph S. Myers 2008-03-15 00:39:36 UTC
Update milestone after 4.3.0 release.
Comment 21 Joseph S. Myers 2008-05-19 20:22:33 UTC
4.2.4 is being released, changing milestones to 4.2.5.
Comment 22 Joseph S. Myers 2008-07-04 22:45:20 UTC
Closing 4.1 branch.
Comment 23 aesok 2008-09-14 12:51:48 UTC
Subject: Bug 19636

Author: aesok
Date: Sun Sep 14 12:50:10 2008
New Revision: 140360

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140360
Log:
	PR target/19636
	PR target/24894
	PR target/31644
	PR target/31786
	* config/avr/avr.c (legitimate_address_p): Fix problem where subreg
	is not recognized as a valid register usage. Allow REG_X to be used
	as a base pointer.
	* config/avr/avr.h (LEGITIMIZE_RELOAD_ADDRESS): Remove code that
	forces a reload when using a base register.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/avr/avr.c
    trunk/gcc/config/avr/avr.h

Comment 24 Joseph S. Myers 2009-03-30 15:39:23 UTC
Closing 4.2 branch, reported as working with 4.3.