Re: h8300, m32c and PRIuPTR

[Joel Sherrill <joel dot sherrill at oarcorp dot com>]

On March 16, 2015 5:22:35 AM CDT, Corinna Vinschen <vinschen@redhat.com> wrote:
>On Mar 15 17:02, Joel Sherrill wrote:
>> Hi
>> 
>> Fighting through more printf() format warnings. This code
>> compiles without warning on all 18 RTEMS targets with
>> default arguments but has warnings on a h8300 and m32c
>> when certain CPU model CFLAGS are added. From a quick
>> check of the impact of adding the -mcpu=m32cm argument,
>> it is changing the sizeof(ptr) from 2 to 4 bytes.
>> 
>> 
>> ==================
>> #include <stdio.h>
>> #include <inttypes.h>
>> 
>> void f( uintptr_t x)
>> {
>>   printf( "%" PRIuPTR "\n", x );
>> }
>> ==================
>> 
>> The warning is:
>> 
>> f.c:6:3: warning: format '%u' expects argument of type 'unsigned
>int', but
>> argument 2 has type 'uintptr_t' [-Wformat=]
>>    printf( "%" PRIuPTR "\n", x );
>>    ^
>> 
>> Various compiler options that trigger the warning:
>> 
>> 
>> h8300-rtems4.11-gcc  -Wall -c f.c <== no warning
>> 
>> h8300-rtems4.11-gcc -mh -mint32 -Wall -c f.c <== warning
>> 
>> h8300-rtems4.11-gcc -msx  -Wall -c f.c <== warning
>> 
>> m32c-rtems4.11-gcc  -Wall -c f.c <== no warning
>> 
>> m32c-rtems4.11-gcc -mcpu=m32cm  -Wall -c f.c <== warning
>> 
>> Any ideas on how to address this?
>
>The m32r target requires building with multilibs, it seems.  The fact
>that the type doesn't match shows that configure didn't catch the right
>base types for PRIuPTR and friends.  For some cases it might be
>necessary to set _UINTPTR_EQ_ULONG or _UINTPTR_EQ_ULONGLONG.  Afaics,
>this configure tests are yours.

Yeah. I wrote the configure magic based on suggestions from the first round of discussions on how to solve this. 

It looks like h8300 and m32c can't be detected at configure time. Should I add logic to inttypes.h to check for them first before using the information from configure that is correct for the other targets?

>
>Corinna

--joel