This is the mail archive of the
mailing list for the GCC project.
Re: [4.5] Ping two patches
- From: Michael Meissner <meissner at linux dot vnet dot ibm dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 24 Nov 2008 18:55:19 -0500
- Subject: Re: [4.5] Ping two patches
- References: <Pine.LNX.email@example.com>
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
> <http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00305.html> (providing
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
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