Re: expand_expr sign extension problem.

[Robert Lipe <robertlipe at usa dot net>]

grahams wrote:
> Mark
> 
> Mark Mitchell wrote:
> >
> 
> > Yes.  It's unfortunate, but true -- you really have to use an unsigned
> > int, rather than an enum, for this kind of thing to get portable code.
> > 
> > However, we can probably have our cake and eat it to by using
> > `autoconf' to detect the properties of the host compiler in this
> > respect.  There's no cross-compiler issue; we know what GCC will do,
> > so we're only interested in the compiler used to build stage1.  Sound
> > right?

Sounds believable to me.   

> Interestingly some ports conditionally define INT_ONLY_FIELDS depending
> on if the compiler is GCC (i.e. __GNUC__ is defined) whereas others
> unconditionally always define it.   

True.   But since 
  * the failure case is so non-obvious
  * it can be programmatically detected 
  * GCC itself relies on implementation defined behavior and 
    then dis-es compilers that didn't choose the same implementation
    defined behaviour.

Shouldn't we try to make this less painful for the GCC users?
Personally, I'd move to remove the dependence on this completely. (add
one bit to tree_code or something) My target bootstrapped just fine for
about five years until a type was added that caused it to sign extend.

Looking at the users of it, the boundary case doesn't even seem to be
enum vs. int.  It's whether bitfields by default are signed or unsigned.
For example, I think that tree_decl.mode would have the same potential
sign extension problem even with ONLY_INT_FIELDS.  So if bitfields are
signed, and machine_mode can be > 127, we could get into trouble even
tere.

I can code up an autoconf test and then override it #if __GNUC__ if
that's the direction we want to take.

But it seems like better engineering to me to eliminate the dependency
instead of autoconfiscating a workaround for it.  (And if the comment at
the top of struct tree_common is true, we have a different good practice
being violated. :-)

RJL