h8300, m32c and PRIuPTR
Joel Sherrill
joel.sherrill@oarcorp.com
Mon Mar 16 16:42:00 GMT 2015
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
-------------- next part --------------
#include <stdio.h>
#include <inttypes.h>
#if (__SIZEOF_LONG_LONG__ == __SIZEOF_PTRDIFF_T__)
#if \
defined(__sparc_v9__)
#define __myPRIPTR(x) __STRINGIFY(l##x)
#else
#define __myPRIPTR(x) __STRINGIFY(ll##x)
#endif
#elif (__SIZEOF_LONG__ == __SIZEOF_PTRDIFF_T__)
#if \
defined(__arm__) || \
defined(__lm32__) || \
defined(__mips__) || \
defined(__nios2__) || \
defined(__PPC__) || \
defined(__sh__) || \
defined(__sparc__) || \
defined(__v850__)
#define __myPRIPTR(x) __STRINGIFY(x)
#else
#define __myPRIPTR(x) __STRINGIFY(l##x)
#endif
#else
#define __myPRIPTR(x) __STRINGIFY(x)
#endif
#define myPRIuPTR __myPRIPTR(u)
void f( uintptr_t x)
{
printf( "%" myPRIuPTR "\n", x );
}
-------------- next part --------------
# moxie-rtems4.11
#
testit()
{
echo === ${*}
${*} -dM -E - </dev/null | grep UINTPTR_TYPE
${*} -Wall -Wextra -c f.c
}
for t in arm-rtems4.11 avr-rtems4.11 bfin-rtems4.11 h8300-rtems4.11 \
i386-rtems4.11 lm32-rtems4.11 m32c-rtems4.11 m32r-rtems4.11 \
m68k-rtems4.11 mips-rtems4.11 nios2-rtems4.11 \
powerpc-rtems4.11 sh-rtems4.11 sparc64-rtems4.11 sparc-rtems4.11 \
v850-rtems4.11
do
testit ${t}-gcc
done
for t in "h8300-rtems4.11-gcc -mh -mint32" \
"h8300-rtems4.11-gcc -msx " \
"m32c-rtems4.11-gcc -mcpu=m32cm" \
"m32c-rtems4.11-gcc -mcpu=r8c" \
"m32c-rtems4.11-gcc -mcpu=m16c"
do
testit ${t}
done
More information about the Newlib
mailing list