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] |
On Mar 16 11:27, Joel Sherrill wrote: > On 3/16/2015 11:17 AM, Corinna Vinschen wrote: > > On Mar 16 10:54, Joel Sherrill wrote: > >> On 3/16/2015 10:08 AM, Corinna Vinschen wrote: > >>> On Mar 16 09:38, Joel Sherrill wrote: > >>>> I am wondering if when we avoided changing newlib-stdint.h to match the > >>>> logic > >>>> in glibc-stdint.h for uintptr_t by adding configure time logic, we just > >>>> pushed > >>>> off the problem. At this point, all I can see as a solution is something > >>>> like this > >>>> in inttypes.h: > >>>> > >>>> #if defined(__m32c__) || defined(__h8300__) > >>>> /* do whatever is needed */ > >>>> #else > >>>> /* we can rely on the value provided by configure, use current logic */ > >>>> #endif > >>> Did you see my mail mentioning sys/config.h? > >> This one? > >>> Ideally the setting is available via compile time macros and can be used > >>> to set _UINTPTR_EQ_ULONG or _UINTPTR_EQ_ULONGLONG from include/sys/config.h. > >> So remove the configure.in logic and try to do the same thing dynamically > >> with conditionals based on __SIZEOF_PTRDIFF__ and __SIZEOF_LONG_LONG__, > >> __SIZEOF_LONG__, and __SIZEOF_INT__? > >> > >> This will work in some cases but with sizeof(int) == sizeof(long), > >> newlib-stdint.h > >> is inconsistent whether uintptr_t is "unsigned int" or "long unsigned > >> int". > >> And that was the more easily hit inttypes.h problem that added the logic > >> to configure.in. > >>> Again, the size of pointer values as well as the fact what multilib > >>> we're building for should be available from gcc at compile time. This > >>> information should ideally be used to influence the logic of inttypes.h > >>> in sys/config.h. > >>> > >> Can we reliably determine long or int for uintptr_t with cpp conditionals? > > Using m32c as example, if you're building for m32cm, or with flags like > > -mint32, there should be builtin macros showing that. There are already > > similar conditionals in sys/config.h: > > > > #ifdef __m32c__ > > [...] > > #if defined(__r8c_cpu__) || defined(__m16c_cpu__) > > #define _POINTER_INT short > > #else > > #define _POINTER_INT long > > #endif > > [...] > > #endif /* __m32c__ */ > > > > So why not set _UINTPTR_EQ_ULONG or _UINTPTR_EQ_ULONGLONG here, too, > > based on a builtin macro? > I have attached a test program and script that do not produce warnings > for any > of my test cases. And I added r8c and m16c test cases. > > How does that type of logic look for use in inttypes.h or to define > macros in > sys/config.h? Try to rearrange it so that the exceptions are getting special treatment, not the majority. I.e. your #if (__SIZEOF_LONG_LONG__ == __SIZEOF_PTRDIFF_T__) branch will do the wrong thing for all 64 bit LP64 targets which typically have intptr_t == long int. Ideally only those target are handled which actually produce a warning, while the others are left alone. Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat
Attachment:
pgpMF0fXUiwhA.pgp
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |