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 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.

> On a similar note, invalid rtl keeps biting my butt, and has for about
> 5 years.   Would be ok to add checks in gen_rtx_SUBREG to abort on 
> invalid RTL (hard coding the common cases)

I thought about doing this when I was debugging the problem 
yesterday and was frightened by how often I expect it will
trigger.  *sigh*  I suppose it really is necessary.  Do it.

This is gonna be really ugly...


r~


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