This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: "new" warnings on alphaev6-unknown-linux-gnu
- To: kenner at vlsi1 dot ultra dot nyu dot edu
- Subject: Re: "new" warnings on alphaev6-unknown-linux-gnu
- From: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Date: Sat, 14 Apr 2001 10:54:09 -0400 (EDT)
- Cc: gcc at gcc dot gnu dot org, jsm28 at cam dot ac dot uk, lucier at math dot purdue dot edu
> From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
>
> > > 1339 passing arg ??? of \`???' with different width due to
> > > prototype
>
> Richard, what is the nature of the spurious warnings you noted?
>
> Exactly those.
>
> For example:
>
> ../../egcs/gcc/gcc.c: In function `init_gcc_specs':
> ../../egcs/gcc/gcc.c:1319: warning: passing arg 3 of `memcpy' with different width due to prototype
> ../../egcs/gcc/gcc.c:1322: warning: passing arg 3 of `memcpy' with different width due to prototype
> ../../egcs/gcc/gcc.c:1327: warning: passing arg 3 of `memcpy' with different width due to prototype
> ../../egcs/gcc/gcc.c:1332: warning: passing arg 3 of `memcpy' with different width due to prototype
> [...]
Ok, these don't appear to be glibc related, but instead involve
converting size_t to int (or vice versa) when sizeof(size_t) >
sizeof(int). So the __extension__ block change won't fix it.
I did a bootstrap on x86-linux-gnu and saw ~250 extra warnings, not
the 1300 Brad saw on alpha-linux-gnu. So I suspect the majority of
his problems as with Richard's stem from real size issues, not the
glibc macros.
The problem is the warning is entirely correct here, however it is
unlikely that a system where size_t and int are not the same size that
it would ever have a K&R compiler. So the warning is correct only in
a pedantic sense and may be called spurious in a practical sense.
I'll have to think about this a bit more. It may be that I disable
the width checks and only do the fixed<->floating point checks when
using -Wtraditional.
--Kaveh
PS: why doesn't -pedantic warn about _Bool used with ISO C prototypes
& traditional func definition as it would with a char?
E.g. hash.c:hash_lookup.
Since our backup definition for _Bool in system.h is a char, won't
that cause strict ISO C89 compilers to choke on stage1?
--
Kaveh R. Ghazi Engagement Manager / Project Services
ghazi@caip.rutgers.edu Qwest Internet Solutions