expand_expr sign extension problem.

[grahams]

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?
> 
> --
> Mark Mitchell                   mark@codesourcery.com
> CodeSourcery, LLC               http://www.codesourcery.com


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.   

I can't think of any reason for unconditionally defining INT_ONLY_FIELDS
it doesn't affect how GCC itself handles enumerated bit fields.

I can think of one good reason why not to define INT_ONLY_FIELDS when
compiling using GCC during bootstrap stages 2 and 3 one loses the
nice ability to see the enum values for code, mode, etc. in GDB.

I think using autoconf would be overkill unless there is already a
autoconf test available. 

Wouldn't it just be simpler just to include something like perhaps
in system.h

	#ifndef __GNUC__
	#define INT_ONLY_FIELDS
	#endif

By do it this way we can eliminate the need for port to be
concerned with this nuisance.

I've just thought of a good reason why stages 2 & 3 might 
need to be built with INT_ONLY_FIELDS defined. What if the
host debugger can't handle enumerated bit fields!

Comments anyone?

Graham