This is the mail archive of the newlib@sourceware.org mailing list for the newlib 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] |
Hi Top posting because I now have results from testing making the proposed change to gcc's newlib-stdint.h to use the same logic as newlib-glibc.h All the targets that built are now warning free. At the moment, avr, m32c, and nios2 won't build. The gcc patch is attached. I thought we should discuss it here before posting it to gcc. Besides, I can't get to gcc's bugzilla this morning for some reason. --joel On 12/16/2014 09:53 AM, Joel Sherrill wrote:
On December 16, 2014 7:44:39 AM PST, Joseph Myers<joseph@codesourcery.com> wrote:On Tue, 16 Dec 2014, Corinna Vinschen wrote:It is GCC. gcc/config/newlib-stdint.h where GCC defines the types.Ok, I didn't know there's newlib-specific stuff in GCC. I'm just not sure in how far this is newlib's fault. The usage of__INTPTR_TYPE__looks right to me. The gcc/config/newlib-stdint.h file seems to be outdated???newlib-stdint.h is meant to replicate the logic used by all versions of newlib to select these types, including versions predating the addition of macros such as __INTPTR_TYPE__. * The choices of these types are meant to be constant over time. * GCC needs to know them (without reference to the newlib headers when GCC is built) for such purposes as Fortran C bindings. * newlib stdint.h as of 2008/9 was used as the source of truth about these types when writing newlib-stdint.h. * When newlib uses macros such as __INTPTR_TYPE__ it's indirectly using GCC's newlib-stdint.h as a source of truth - but this should never change the choice of types relative to what would be used with older GCC or non-GCC compilers.I.don't disagree with any of that but I wouldn't necessarily treat the old newlib stdint.h as 100% correct. I don't believe that most embedded targets ever gave much thought to this issue and it is propagating into inttypes.h. Other than cygwin, I doubt binary comparability is even an issue as most build from source.. For sure this uses different logic than glic-stdint.h and that results in some targets using int for pointer types while others use long. We can make it consistent in newlib-stdint.h or we have to add target architecture specific conditional logic inttypes.h to make the printf PRIxxx match the type. It is inconsistent now and has to be fixed on one side or the other. I always lean to simple and consistent which makes me want to fix newlib-stdint.h. --joel
Attachment:
0001-newlib-stdint.h-Use-glibc-s-logic-for-uintptr_t-and-.patch
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |