This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [4.5] Ping two patches

On Sat, Nov 15, 2008 at 08:14:19PM +0000, Joseph S. Myers wrote:
> The following are currently pending review for 4.5:
> * All the non-front-end, non-fixincludes parts of 
> <> (providing 
> <stdint.h>).

I took a look at this, and mostly like the contents.

I will note that the min macros which are constructred by -max - 1 will only
work on 2's complement machines.  I don't think it is a problem unless the old
DEC-10 gcc is resurected, but I think such a machine would have many more
problems with the GCC infrastructure.

I noticed in one place you use ??? in a comment, talking about chars not being
signed or unsigned ints.  I'm wondering whether some compiler out there would
warn about using a trigraph.  It isn't a big deal one way or another, just
something I noticed.

Getting into more substantive changes, I really think backends should be given
the chance to override the FAST macros.  For example, on the original alpha you
only have 32 and 64 bit types, and you would not want FAST8 being a char or
FAST16 being a short.  I suspect given the nature of the x86 internal
architectures, it may be better to declare FAST8/16 to use 32-bit ints.  I
realize there may not be many ports that would use this, but the FAST macros
were added to give the programmer a fighting chance of optimizing for speed
over size.

I notice that you go through some ports setting the pointer size ints.  I
suspect it may be better to set the pointer size ints from what Pmode expands
to, possibly having a target hook to override it (or let the first port that
needs to override the default, add the hook). 

In looking at the configure changes, there are a lot of repetitive changes.  I
know from experience, that it is easy to get such things wrong, particularly in
obscure ports.  I'm wondering whether it would be better to move most of the
*linux* *bsd*, etc. changes down to the bottom for common code.

I will note that the problem of targeting glibc/newlib, etc. is that they
change, just like the compiler does, and that the fixinclude code 

Michael Meissner, IBM
4 Technology Place Drive, MS 2203A, Westford, MA, 01886, USA

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]