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]

Re: h8300, m32c and PRIuPTR



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?

I don't care about the form of the solution, only that it works. :)
>
> Corinna
>

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Attachment: f.c
Description: Text document

Attachment: j
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]