Bug 9929 - [3.3/3.4 regression] Can't find spill register in GENERAL_REGS
Summary: [3.3/3.4 regression] Can't find spill register in GENERAL_REGS
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 3.4.0
: P2 critical
Target Milestone: 3.4.0
Assignee: Jan Hubicka
URL:
Keywords: ice-on-valid-code, patch
: 10282 (view as bug list)
Depends on:
Blocks:
 
Reported: 2003-03-04 00:26 UTC by gabor
Modified: 2004-01-17 04:22 UTC (History)
5 users (show)

See Also:
Host:
Target: i686-pc-linux-gnu
Build:
Known to work:
Known to fail:
Last reconfirmed: 2003-12-05 03:39:39


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description gabor 2003-03-04 00:26:00 UTC
When compiling the below self-contained snippet I get

gabor@cantor:~/gd-184/build$ gcc -O2 -fomit-frame-pointer -fno-strict-aliasing -c ICE3.c  -fPIC -DPIC -o .libs/func.lo2

ICE3.c: In function `general_rep_setter_FUN':
ICE3.c:54: error: unable to find a register to spill in class `GENERAL_REGS'
ICE3.c:54: error: this is the insn:
(insn:HI 47 92 49 1 0x4013e318 (set (mem/s:DI (plus:SI (subreg:SI (reg/v:DI 66 [ L_instance ]) 0)
                (subreg:SI (reg/v:DI 67 [ L_posn ]) 4)) [0 S8 A32])
        (reg/v:DI 65 [ L_new_value ])) 60 {*movdi_2} (nil)
    (expr_list:REG_DEAD (reg/v:DI 66 [ L_instance ])
        (expr_list:REG_DEAD (reg/v:DI 67 [ L_posn ])
            (nil))))
ICE3.c:54: internal compiler error: in spill_failure, at reload1.c:1917
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.


The code is coming from a Dylan->C compiler, somewhat simplified here. It is not handwritten code.

------------------------------------------
typedef struct heapobj *heapptr_t;
typedef struct descriptor {
    heapptr_t heapptr;
    union {
        long l;
        float f;
        void *ptr;
    } dataword;
} descriptor_t;

extern descriptor_t find_slot_offset_METH(descriptor_t *orig_sp, heapptr_t A0, heapptr_t A1, heapptr_t A2);

extern void uninitialized_slot_error_FUN(descriptor_t *orig_sp, heapptr_t A0, descriptor_t A1);

extern struct heapobj dylanZempty_list_ROOT;
extern struct heapobj SYM_data_word_HEAP;
extern struct heapobj CLS_integer_HEAP;
extern struct heapobj dylanZstr_ROOT_230;

descriptor_t * general_rep_setter_FUN(descriptor_t *orig_sp, heapptr_t A_self, long A1, heapptr_t A2)
{
    descriptor_t *cluster_0_top;
    void * L_arg_ptr;
    descriptor_t L_new_value;
    descriptor_t L_instance;
    descriptor_t L_posn;
    descriptor_t L_temp;
    descriptor_t L_temp_2;

    L_arg_ptr = ((void *)(orig_sp - 2));
    L_new_value = (((descriptor_t *)L_arg_ptr)[0]);
    L_instance = (((descriptor_t *)L_arg_ptr)[1]);
    orig_sp = L_arg_ptr;

    L_posn = find_slot_offset_METH(orig_sp, (*(heapptr_t *)((char *)L_instance.heapptr + 0)), (*(heapptr_t *)((char *)A_self + 36)), &dylanZempty_list_ROOT);

    if ((&CLS_integer_HEAP == (*(heapptr_t *)((char *)L_posn.heapptr + 0)))) {

        (*(descriptor_t *)((char *)L_instance.heapptr + L_posn.dataword.l)) = L_new_value;
        orig_sp[0] = L_new_value;
        return orig_sp + 1;
    }
    else {
        L_temp.heapptr = &SYM_data_word_HEAP;
        L_temp.dataword.l = 0;
        L_temp_2.heapptr = &dylanZstr_ROOT_230;
        L_temp_2.dataword.l = 0;

        type_error_with_location_FUN(orig_sp, L_temp, &CLS_integer_HEAP, L_temp_2);
        not_reached();
    }
}

Release:
gcc version 3.4 20030303 (experimental)

Environment:
Linux cantor 2.2.20 #1 Sat Apr 20 11:45:28 EST 2002 i686 unknown

How-To-Repeat:
Just compile the snippet.
Comment 1 Wolfgang Bangerth 2003-03-04 15:22:51 UTC
State-Changed-From-To: open->analyzed
State-Changed-Why: Confirmed. Here's a reduced example:
    ---------------------------
    typedef struct X {
        char * ptr;
        int    offset;
    } X_t;
    
    X_t foo(X_t *d1, char * A0);
    
    void bar() {
      X_t l1, l2, l3;
      l3 = foo(&l1, l2.ptr);
      (*(X_t *)(l2.ptr + l3.offset)) = l1;
    }
    -----------------------------
    
    It compiles cleanly with 3.2.2, but fails with 3.3 and
    present mainline when using -O2 -fPIC:
    g/x> /home/bangerth/bin/gcc-3.3-pre/bin/gcc -c -O2 -fPIC x.c
    x.c: In function `bar':
    x.c:12: error: unable to find a register to spill in class `GENERAL_REGS'
    x.c:12: error: this is the insn:
    (insn:HI 18 28 20 0 0x4014f2ec (set (mem/s:DI (plus:SI (subreg:SI (reg/v:DI 60) 0)
                    (subreg:SI (reg/v:DI 61) 4)) [2 S8 A32])
            (reg:DI 63)) 59 {*movdi_2} (insn_list 15 (insn_list 17 (nil)))
        (expr_list:REG_DEAD (reg:DI 63)
            (expr_list:REG_DEAD (reg/v:DI 60)
                (expr_list:REG_DEAD (reg/v:DI 61)
                    (nil)))))
    x.c:12: confused by earlier errors, bailing out
    g/x>
    g/x>
    g/x> /home/bangerth/bin/gcc-3.4-pre/bin/gcc -c -O2 -fPIC x.c
    x.c: In function `bar':
    x.c:12: error: unable to find a register to spill in class `GENERAL_REGS'
    x.c:12: error: this is the insn:
    (insn:HI 18 28 20 0 0x401532c0 (set (mem/s:DI (plus:SI (subreg:SI (reg/v:DI 60 [ l2 ]) 0)
                    (subreg:SI (reg/v:DI 61 [ l3 ]) 4)) [2 S8 A32])
            (reg:DI 63 [ l1 ])) 60 {*movdi_2} (insn_list 15 (insn_list 17 (nil)))
        (expr_list:REG_DEAD (reg:DI 63 [ l1 ])
            (expr_list:REG_DEAD (reg/v:DI 60 [ l2 ])
                (expr_list:REG_DEAD (reg/v:DI 61 [ l3 ])
                    (nil)))))
    x.c:12: internal compiler error: in spill_failure, at reload1.c:1919
    Please submit a full bug report,
    with preprocessed source if appropriate.
    See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
Comment 2 janis187 2003-03-24 14:04:19 UTC
From: Janis Johnson <janis187@us.ibm.com>
To: Steven Bosscher <s.bosscher@student.tudelft.nl>
Cc: gabor@mac.com, gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org,
   nobody@gcc.gnu.org, gcc-prs@gcc.gnu.org, janis187@us.ibm.com, jh@suse.cz
Subject: Re: target/9929: [3.3/3.4 regression] Can't find spill register
Date: Mon, 24 Mar 2003 14:04:19 -0800

 On Mon, Mar 24, 2003 at 09:00:40PM +0100, Steven Bosscher wrote:
 > 
 > Janis, can you hunt this one?
 
 The regression showed up with this patch:
 
 Sat Mar 30 14:08:55 CET 2002  Jan Hubicka  <jh@suse.cz>
 
 	* local-alloc.c (local_alloc): Avoid call of update_equiv_regs
 	when not optimizing.
 
 	* toplev.c (rest_of_compilation): Cann mark_constant_function
 	only when optimizing.
 
 	* flow.c (calculate_global_regs_live): Ensure that all AUX fields
 	are NULL.
 
 	* cfgcleanup.c (bb_flags): Add BB_NONTHREADABLE_BLOCK.
 	(thread_jump): Set BB_NONTHREADABLE_BLOCK, check it.
 	(try_optimize_cfg): clear all AUX fields.
 
 	* i386.c (aligned_operand): Be prepared for SUBREGed registers.
 	(ix86_decompose_address): Use REG_P instead of GET_CODE (...) == REG.
 	(ix86_address_cost): Be prepared for SUBREGed registers.
 	(legitimate_address_p): Accept SUBREGed registers.
 
 The hunt used Wolfgang's reduced test case with "-O -fPIC" on
 i686-pc-linux-gnu.

Comment 3 s.bosscher 2003-03-24 21:00:40 UTC
From: Steven Bosscher <s.bosscher@student.tudelft.nl>
To: gabor@mac.com, gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org,
	nobody@gcc.gnu.org, gcc-prs@gcc.gnu.org, janis187@us.ibm.com
Cc:  
Subject: Re: target/9929: [3.3/3.4 regression] Can't find spill register
Date: Mon, 24 Mar 2003 21:00:40 +0100

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9929
 
 Still there today.
 
 Just -O -fPIC is enough to trigger it on i586.
 
 Janis, can you hunt this one?
 
 Greetz
  Steven
 
     ---------------------------
     typedef struct X {
         char * ptr;
         int    offset;
     } X_t;
     
     X_t foo(X_t *d1, char * A0);
     
     void bar() {
       X_t l1, l2, l3;
       l3 = foo(&l1, l2.ptr);
       (*(X_t *)(l2.ptr + l3.offset)) = l1;
     }
     -----------------------------
 
 
 

Comment 4 Jan Hubicka 2003-03-25 00:06:42 UTC
From: Jan Hubicka <jh@suse.cz>
To: Janis Johnson <janis187@us.ibm.com>
Cc: Steven Bosscher <s.bosscher@student.tudelft.nl>, gabor@mac.com,
	gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org,
	gcc-prs@gcc.gnu.org, jh@suse.cz
Subject: Re: target/9929: [3.3/3.4 regression] Can't find spill register
Date: Tue, 25 Mar 2003 00:06:42 +0100

 > On Mon, Mar 24, 2003 at 09:00:40PM +0100, Steven Bosscher wrote:
 > > 
 > > Janis, can you hunt this one?
 > 
 > The regression showed up with this patch:
 > 
 > Sat Mar 30 14:08:55 CET 2002  Jan Hubicka  <jh@suse.cz>
 > 
 > 	* local-alloc.c (local_alloc): Avoid call of update_equiv_regs
 > 	when not optimizing.
 > 
 > 	* toplev.c (rest_of_compilation): Cann mark_constant_function
 > 	only when optimizing.
 > 
 > 	* flow.c (calculate_global_regs_live): Ensure that all AUX fields
 > 	are NULL.
 > 
 > 	* cfgcleanup.c (bb_flags): Add BB_NONTHREADABLE_BLOCK.
 > 	(thread_jump): Set BB_NONTHREADABLE_BLOCK, check it.
 > 	(try_optimize_cfg): clear all AUX fields.
 > 
 > 	* i386.c (aligned_operand): Be prepared for SUBREGed registers.
 > 	(ix86_decompose_address): Use REG_P instead of GET_CODE (...) == REG.
 > 	(ix86_address_cost): Be prepared for SUBREGed registers.
 > 	(legitimate_address_p): Accept SUBREGed registers.
 > 
 > The hunt used Wolfgang's reduced test case with "-O -fPIC" on
 > i686-pc-linux-gnu.
 
 Tue Mar 25 00:05:27 CET 2003  Jan Hubicka  <jh@suse.cz>
 	* i386.c (legitimate_address_p):  Refuse DImore registers in 32bit compilation.
 Index: i386.c
 ===================================================================
 RCS file: /cvs/gcc/gcc/gcc/config/i386/i386.c,v
 retrieving revision 1.552
 diff -c -3 -p -r1.552 i386.c
 *** i386.c	22 Mar 2003 20:02:22 -0000	1.552
 --- i386.c	24 Mar 2003 23:05:11 -0000
 *************** legitimate_address_p (mode, addr, strict
 *** 5936,5941 ****
 --- 5936,5949 ----
   	  goto report_error;
   	}
   
 +       /* We can run out of registers when we do allow subregs
 +          of DImode regsiters.  */
 +       if (GET_MODE (reg) == DImode && !TARGET_64BIT)
 + 	{
 + 	  reason = "base reg is DImore";
 + 	  goto report_error;
 + 	}
 + 
         if ((strict && ! REG_OK_FOR_BASE_STRICT_P (reg))
   	  || (! strict && ! REG_OK_FOR_BASE_NONSTRICT_P (reg)))
   	{
 *************** legitimate_address_p (mode, addr, strict
 *** 5971,5976 ****
 --- 5979,5993 ----
   	  reason = "index is not in Pmode";
   	  goto report_error;
   	}
 + 
 +       /* We can run out of registers when we do allow subregs
 +          of DImode regsiters.  */
 +       if (GET_MODE (reg) == DImode && !TARGET_64BIT)
 + 	{
 + 	  reason = "index reg is DImore";
 + 	  goto report_error;
 + 	}
 + 
   
         if ((strict && ! REG_OK_FOR_INDEX_STRICT_P (reg))
   	  || (! strict && ! REG_OK_FOR_INDEX_NONSTRICT_P (reg)))

Comment 5 s.bosscher 2003-03-25 09:25:38 UTC
From: Steven Bosscher <s.bosscher@student.tudelft.nl>
To: gabor@mac.com, gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org,
	nobody@gcc.gnu.org, gcc-prs@gcc.gnu.org, janis187@us.ibm.com,
	jh@suse.cz
Cc:  
Subject: Re: target/9929: [3.3/3.4 regression] Can't find spill register in
 GENERAL_REGS
Date: Tue, 25 Mar 2003 09:25:38 +0100

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9929
 
 Hi,
 
 Janis, thanks for identifying the patch that caused
 the PR, I've never seen a patch show up so fast :-)
 
 Unfortunately, maybe the patch you identified only
 uncovers a problem introduced earlier.  PR 10017 is
 another regression where GCC cannot find a spill
 register, and that one fails for all GCCs since 3.0.
 It still fails with Honza's patch applied...
 
 Greetz
 Steven
 

Comment 6 gabor 2003-03-26 21:15:43 UTC
From: Gabor Greif <gabor@mac.com>
To: Steven Bosscher <s.bosscher@student.tudelft.nl>
Cc: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org,
   gcc-prs@gcc.gnu.org, janis187@us.ibm.com, jh@suse.cz
Subject: Re: target/9929: [3.3/3.4 regression] Can't find spill register in GENERAL_REGS
Date: Wed, 26 Mar 2003 21:15:43 +0100

 The patch on mainline seems to work. I did not try gcc3.3.
 
 Thanks to you all for the prompt response,
 
 	Gabor
 
 
 Am Dienstag den, 25. M=E4rz 2003, um 09:25, schrieb Steven Bosscher:
 
 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=3Dview%20audit-
 > trail&database=3Dgcc&pr=3D9929
 >
 > Hi,
 >
 > Janis, thanks for identifying the patch that caused
 > the PR, I've never seen a patch show up so fast :-)
 >
 > Unfortunately, maybe the patch you identified only
 > uncovers a problem introduced earlier.  PR 10017 is
 > another regression where GCC cannot find a spill
 > register, and that one fails for all GCCs since 3.0.
 > It still fails with Honza's patch applied...
 >
 > Greetz
 > Steven
 >
 
Comment 7 Jason Merrill 2003-04-03 21:02:17 UTC
Responsible-Changed-From-To: unassigned->hubicka
Responsible-Changed-Why: Jan's been looking at this bug.  The reduced testcase is still broken in 3.3 and on the trunk.
Comment 8 Dara Hazeghi 2003-07-10 00:48:20 UTC
This bug is still present on mainline. Has there been any progress made 
since this bug was assigned in April? Thanks.
Comment 9 Andrew Pinski 2003-07-13 19:50:21 UTC
From Phil's regression hunter: Search converges between 2002-03-24-trunk (#11) and 
2002-03-31-trunk (#12).
Comment 10 Phil Edwards 2003-07-14 03:02:07 UTC
I filled in the 7-day gap here and re-ran the search:

: Search converges between 2002-03-30-trunk (#43) and 2002-03-31-trunk (#44).

input.c: In function `bar':
input.c:12: unable to find a register to spill in class `GENERAL_REGS'
input.c:12: this is the insn:
(insn 25 37 26 (set (mem/s:DI (plus:SI (subreg:SI (reg/v:DI 60) 0)
                (subreg:SI (reg/v:DI 61) 4)) [0 S8 A32])
        (reg:DI 63)) 83 {*movdi_2} (insn_list 21 (insn_list 24 (nil)))
    (expr_list:REG_DEAD (reg:DI 63)
        (expr_list:REG_DEAD (reg/v:DI 60)
            (expr_list:REG_DEAD (reg/v:DI 61)
                (nil)))))
input.c:12: Internal compiler error in spill_failure, at reload1.c:1908
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Comment 11 janis187 2003-07-15 18:02:23 UTC
The latest search for the introduction or exposure of the bug points to the
patch that was identified in comment #2.
Comment 12 Mark Mitchell 2003-07-23 23:01:18 UTC
Jan has indicated that he will not fix this bug this week, so I have postponed
it until GCC 3.3.2.  At least the failure mode is a crash, and not bad code
generation.

It's very disappointing that this regression -- which was filed in March -- was
not fixed by July.
Comment 13 Jan Hubicka 2003-07-24 00:19:28 UTC
Subject: Re:  [3.3/3.4 regression] Can't find spill register in GENERAL_REGS

> PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9929
> 
> 
> 
> ------- Additional Comments From mmitchel at gcc dot gnu dot org  2003-07-23 23:01 -------
> Jan has indicated that he will not fix this bug this week, so I have postponed
> it until GCC 3.3.2.  At least the failure mode is a crash, and not bad code
> generation.
I didn't mean this particular bug.  I am on the vacation till Friday,
but I am trying to solve the 3.3 issues today.
> 
> It's very disappointing that this regression -- which was filed in March -- was
> not fixed by July.
Quick searching reminded me that except for the rejected patch to work
around at i386 side, there is patch waiting for this particular bug at
http://gcc.gnu.org/ml/gcc-patches/2003-05/msg02107.html
it has been in use at SuSE's Gcc for some time now and seems to be safe.
I verified that the patch still apply and fixes the testcase,
bootstrap/regress is in the progress.
Sorry for the delay.

Honza
> 
> 
> 
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.
Comment 14 Jan Hubicka 2003-07-24 00:21:28 UTC
Subject: Re:  [3.3/3.4 regression] Can't find spill register in GENERAL_REGS

> PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9929
> 
> 
> 
> ------- Additional Comments From mmitchel at gcc dot gnu dot org  2003-07-23 23:01 -------
> Jan has indicated that he will not fix this bug this week, so I have postponed
Also note that I was speaking about the HP-UX bug that is not a
regression and I spent several hours trying to hunt it down already.  I
don't have that much time right now, but will at the flight home.
Just to clarify my schedule :)

Honza
> it until GCC 3.3.2.  At least the failure mode is a crash, and not bad code
> generation.
> 
> It's very disappointing that this regression -- which was filed in March -- was
> not fixed by July.
> 
> 
> 
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.
Comment 15 CVS Commits 2003-08-27 16:41:08 UTC
Subject: Bug 9929

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	hammer-3_3-branch
Changes by:	hubicka@gcc.gnu.org	2003-08-27 16:41:02

Modified files:
	gcc            : ChangeLog.hammer Makefile.in flow.c gccbug.in 
	                 reload.c 
	gcc/config/i386: i386.c i386.h 

Log message:
	Backport from SuSE local:
	Tue Mar 18 19:06:18 CET 2003  Jan Hubicka  <jh@suse.cz>
	* i386.c (use_fast_prologue_epilogue): Remove.
	(machine_function): New fields use_fast_prologue_epilogue;
	use_fast_prologue_epilogue_initialized.
	(ix86_frame): New field save_regs-using_mov;
	(ix86_compute_frame_layout):  Decide on fast prologues;
	allocate saved registers in red zone.
	(ix86_expand_epilogue, ix86_expand_prolgoues): Obey new parameters.
	Mon Mar  3 12:01:16 CET 2003  Jan Hubicka  <jh@suse.cz>
	* i386.c (classify_argument): Obey MUST_PASS_IN_STACK.
	* i386.h (MUST_PASS_IN_STACK): Use default_must_pass_in_stack
	for x86-64.
	
	Mon Apr 21 15:13:51 CEST 2003  Jan Hubicka  <jh@suse.cz>
	* reload.c (find_valid_class):  Allow fixed registers to refuse
	the mode; compute real amount of choices to allocate given register.
	
	Sun Apr  6 17:43:49 CEST 2003  Jan Hubicka  <jh@suse.cz>
	PR target/9929
	* reload.c (find_reloads_toplev):  Remove now redundant alternative
	(find_reloads_address_1): Synchronize handling of subregs with
	find_reloads_toplev;  Always reload whole subreg when the inner
	value requires more registers.
	
	Zdenek Dvorak
	* flow.c (MAX_LIVENESS_ROUNDS): New.
	(calculate_global_regs_live): Guarantee that liveness updating will
	terminate.
	(update_life_info_in_dirty_blocks): Remove hack that masked the bug.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.hammer.diff?cvsroot=gcc&only_with_tag=hammer-3_3-branch&r1=1.1.2.179&r2=1.1.2.180
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/Makefile.in.diff?cvsroot=gcc&only_with_tag=hammer-3_3-branch&r1=1.955.2.24&r2=1.955.2.25
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/flow.c.diff?cvsroot=gcc&only_with_tag=hammer-3_3-branch&r1=1.540.2.5&r2=1.540.2.6
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gccbug.in.diff?cvsroot=gcc&only_with_tag=hammer-3_3-branch&r1=1.15.28.1&r2=1.15.28.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/reload.c.diff?cvsroot=gcc&only_with_tag=hammer-3_3-branch&r1=1.197.2.8&r2=1.197.2.9
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.c.diff?cvsroot=gcc&only_with_tag=hammer-3_3-branch&r1=1.490.2.48&r2=1.490.2.49
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.h.diff?cvsroot=gcc&only_with_tag=hammer-3_3-branch&r1=1.305.2.17&r2=1.305.2.18

Comment 16 Mark Mitchell 2003-10-16 02:45:07 UTC
Postponed until GCC 3.4.

Jan, since you seem to have a patch for this can you get it approved for GCC 3.3.4?
Comment 17 Andrew Pinski 2003-12-05 03:39:39 UTC
Any news of getting this approved?
Comment 18 Andrew Pinski 2003-12-16 23:00:17 UTC
Patch here: <http://gcc.gnu.org/ml/gcc-patches/2003-07/msg02582.html>.
Comment 19 John David Anglin 2003-12-17 05:40:20 UTC
I'm confused.  The patch to pa.h is installed on 3.3 and trunk.
The history linking it to 9929 is tenuous.
Comment 20 Andrew Pinski 2003-12-17 05:44:37 UTC
Man I messed up because Jan had put the wrong subject in the patch.
Comment 21 Andrew Pinski 2003-12-29 17:08:05 UTC
Okay this time it is the right one, patch here: <http://gcc.gnu.org/ml/gcc-patches/2003-12/
msg02204.html>.
Comment 22 Andrew Pinski 2003-12-29 17:08:50 UTC
Okay this time it is the right one really, patch here: <http://gcc.gnu.org/ml/gcc-patches/
2003-12/msg02201.html>.
Comment 23 Jan Hubicka 2004-01-10 11:40:08 UTC
Fixed by Richard's reversal of mine's patch:
        PR opt/12441
        Revert: Sat Mar 30 14:08:55 CET 2002  Jan Hubicka  <jh@suse.cz>
        * i386.c (aligned_operand): Be prepared for SUBREGed registers.
        (ix86_decompose_address): Use REG_P instead of GET_CODE (...) == REG.
        (ix86_address_cost): Be prepared for SUBREGed registers.
        (legitimate_address_p): Accept SUBREGed registers.