Your change to function.c
Jeffrey A Law
Mon Oct 5 09:06:00 GMT 1998
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 :-)
More information about the Gcc-patches