Re: Your change to function.c

["David S. Miller" <davem at dm dot cobaltmicro dot com>]

   Date: Mon, 5 Oct 1998 00:24:38 -0700
   From: Richard Henderson <rth@cygnus.com>

   > Remember, not all subregging is safe, particularly when dealing
   > with floating point modes.

   Well, do you think this isn't?  I think it is, but am willing to be
   convinced.  I suppose there could be aliasing issues, though I'm
   not sure how go about forceing one to be sure.

   It's slightly annoying that I committed the change a few minutes
   before your responce, based on a note from Mark.

As I've told Richard in private email this whole situation _is_ bogus
and the problem is even more pronounced on big endian systems.

For big endian, say purge_addressof_1 sees:

   (set (reg:QI) (addressof:SI (reg:SF xxx)))

or something like this and Richards changes run.  This gets passed in
to extract_bit_field() which does big endian correction so it wants to
access byte 3 in the SFmode MEM.  This falls down further to call
extract_fixed_bit_field() which does a word sized load of the MEM,
then tries to shift it.  The shift gen attempt fails because shifts
are never valid on floating mode objects (you gave the bit field
routine a SFmode MEM so it loaded it into an SFmode pseudo, and this
SFmode pseudo is what the shift gen routines are given to work on).

This is never noticed on little endian because a gen_lowpart will
usually do the trick all by itself, which is what creates the subregs
which combine is barfing on here.

I think passing float mode objects of any type to the bit field
expmed.c routines is a huge mistake and were never expected nor
designed to work.

If you want to fixup the expmed.c routines so they can handle all of
these cases, and all the code in the rest of the compiler which
subsequently will need to look at these weird subregs and deal with
them properly, feel free.  But for now put something in there so we
get a bootstrappable compiler, and this means going to the stack when
we see a float mode object, which is what my change installed
yesterday in fact does.

Later,
David S. Miller
davem@dm.cobaltmicro.com