Re: UltraSPARC 16-bit assignments severely broken [analysis]

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

   Date: Wed, 26 Jul 2000 06:58:00 -0400 (EDT)
   From: Todd Vierling <tv@pobox.com>

   On Tue, 25 Jul 2000, David S. Miller wrote:

   :    Code inspection suggests that this particular bug is still present in
   :    2.96, so `upgrading' is not going to me help me either.
   : 
   : Build the cross compiler with -DHOST_WIDE_INT="long long" in the
   : CFLAGS and the bug will go away.

   That's not really a fix, considering that this is not done by the default
   gcc configuration procedure....

It is for him, because he has mentioned that updating to the latest
tree (where it is almost certainly fixed) is not an option, and we've
also mentioned repeatedly that 2.95.2 isn't to be expected to work for
this target.

I've given him a method by which he can make it work.  If that isn't
the definition of a "fix" I don't know what is.

   If this is `normal procedure', then gcc should default to a 64-bit native
   integer type, where available, when targeting a 64-bit target.  Defaulting
   to 32-bit HOST_WIDE_INT when it's _known_ [by Cygnus/Redhat] to break is
   bogus.

Using 2.95.2 for the sparc64 target is not "normal" procedure.

You have to use hacks to get it to work for that target, which is why
it is not supported out of the box by that version of the compiler and
the gcc team made this pretty clear in the release notes for that
version.

Later,
David S. Miller
davem@redhat.com