h8300, m32c and PRIuPTR

[Joel Sherrill]

On 3/16/2015 11:49 AM, Corinna Vinschen wrote:
> 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.
The distribution is not as clean as you might think. When I investigated
long vs int uintptr_t, I was getting a 2/3, 1/3 split across the rtems
targets.

I reduced the long long case to only one result and it works for sparc64 and
my native 64-bit Fedora gcc.  The distribution of paths across my test cases
is now:

      2     #warning "CASE: 1 long long only"
      8      #warning "CASE: 2 long but use int"
      7      #warning "CASE: 3 long use long"
      4      #warning "CASE: 4 int use int"

I could reverse the logic for 2 and 3 but it is 7 vs 8 targets for each
path.
Not much difference really.

But remember, not every newlib target is an RTEMS target.  This balance
could shift based on the other bare machine targets.  Does someone
have *-elf targets handy for targets that do not have RTEMS to test using
my script and test case?

I am happy to adjust for all the targets that we can in this.
>
> 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