h8300, m32c and PRIuPTR

Corinna Vinschen vinschen@redhat.com
Mon Mar 16 17:03:00 GMT 2015


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20150316/8b82d8c4/attachment.sig>


More information about the Newlib mailing list