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 Mon, 24 Nov 2008, Michael Meissner wrote:

> 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.

GCC generally assumes two's complement.

> 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.

??? is not a trigraph.

> 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.

Back ends are free to override the macros - but where a system already has 
a <stdint.h> header that defines an ABI (including the choice of type 
amongst multiple types with a given width, which affects C++ name 
mangling) it's desirable to match.  Even when using the GCC-provided 
header only for freestanding compiles, some users probably do such 
compiles and link against libc, and any use for the Fortran bindings 
requires that the compiler's internal knowledge of the types match the 
types used for hosted compiles.

> 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). 

As above, the types need to match the libc headers (in this case newlib 
headers) - including as to choice between different types with the same 
mode (so if long and int are the same width, you can't choose 
automatically between them); see the comment

+/* Newlib uses the unsigned type corresponding to ptrdiff_t for
+   uintptr_t; this is the same as size_t for most newlib-using
+   targets.  */

and the definitions for those targets are for cases using newlib that do 
not have ptrdiff_t and size_t corresponding types.  It may be that the 
m32c and score ports should change to use corresponding types - but the 
peculiarities of m32c may mean using types that don't correspond is 
deliberate, and I don't think there's been any sign of work on converting 
score to IRA so it may be removed anyway.

> 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'm not convinced treating this as different from all the other tm_file 
handling is a good idea - it is simply another header defining target 
macros that can be overridden like the rest of the target macros.  Most of 
the glibc-stdint changes are replacing "linux.h" by "linux.h 
glibc-stdint.h" - then those targets not using linux.h need glibc-stdint.h 
inserted somewhere as well.

Actually there's probably a lot of scope for cleaning up the various 
headers that go into tm.h and how they relate to each other - I just don't 
think putting glibc-stdint.h in a special case at the end is a good start.  
Better might be to have separate variables for the three classes of header 
in tm_file, as described in the comments at the top, with the "generic 
headers" part set up as far as possible in generic cases not matching on 
CPU type, and put them together at the end - but that would clearly need a 
lot of work sorting out the targets that don't presently conform to the 
preferred order described in that comment.

Joseph S. Myers

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