This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
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
joseph@codesourcery.com