This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: subreg fixing (extract_bit_field or simplify_subreg)


On Thu, Oct 28, 2004 at 11:03:57AM -0700, Richard Henderson wrote:
> On Thu, Oct 28, 2004 at 01:53:21PM -0400, Aldy Hernandez wrote:
> > Yay.  More subreg stupidity.
> > 
> > On the following testcase, we call extract_bit_field trying to extract
> > a DF out of a memory block:
> > 
> > 	struct __attribute__ ((packed)) W { double l; } sW;
> > 	double dd;
> > 	testW () { dd = sW.l; }
> > 
> > We first call operand_subword with wordnum=1, and somewhere down the call
> > chain, simplify_gen_subreg calls simplify_subreg, which returns 0.
> > This causes simplify_gen_subreg to force creation of the subreg
> > with gen_rtx_SUBREG.
> > 
> > ...this creates invalid rtl: (subreg:SI (reg:DF 118) 4).
> > 
> > What is advisable?
> > 
> > Would it be ok to modify simplify_gen_subreg to return NULL_RTX for
> > class incompatabilities, or is the problem further up?  (Obviously,
> > I'd have to change operand_subword to operand_subword_force).
> 
> The problem is farther up.  In places, I know it's broken all
> the way back up to extract_bit_field.

Argh.... Are you looking into this (the extract_bit_field problem)?
If not, any pointers on where to look to fix this?

Cheers.
Aldy


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]