Re: Your change to function.c

[Jeffrey A Law <law at cygnus dot com>]

  In message <199810051132.EAA01633@dm.cobaltmicro.com>you write:
  > 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).
But why would we ever want to get something like the above -- addressof is
an address right?  Why would we ever look at it in a mode like QImode?

What am I missing?

  > 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.
I tend to feel this way myself, but without specific reasons.  A general 
"don't screw with floats" mentality :-)

jeff