Patch: Change from configure time to compile time probe for intptr_t, definition.
Mon Mar 23 13:54:00 GMT 2015
On 03/23/2015 05:17 AM, Corinna Vinschen wrote:
> Hi Joel,
> The patch looks good... almost. No worries, it's my fault:
Great. This patch seems to take care of the issue pretty
I spent a lot of time building over the past few days and this
patch really helped reduce the warnings in the RTEMS tests.
We are almost to 0 warnings across the targets except m32c
which ICEs so much building RTEMS with "make -k" that I
can't tell much of anything.
>> diff --git a/newlib/libc/include/sys/config.h b/newlib/libc/include/sys/config.h
>> index 5297bef..a5a57c9 100644
>> --- a/newlib/libc/include/sys/config.h
>> +++ b/newlib/libc/include/sys/config.h
>> @@ -287,4 +287,27 @@
>> #define _MB_EXTENDED_CHARSETS_WINDOWS 1
>> +/* Determine how uintptr_t is defined by gcc for this target. This
>> + is used to determine the correct printf() constant in inttypes.h */
>> +#pragma push_macro("signed")
>> +#pragma push_macro("int")
>> +#pragma push_macro("long")
>> +#undef signed
>> +#undef int
>> +#undef long
>> +#define signed +0
>> +#define int +0
>> +#define long +1
>> +#if __INTPTR_TYPE__ == 2
>> +#define _UINTPTR_EQ_ULONGLONG
>> +#elif __INTPTR_TYPE__ == 1
>> +#define _UINTPTR_EQ_ULONG
>> +#elif __INTPTR_TYPE__ == 0
>> +/* Nothing to define because intptr_t is safe to print as an int. */
>> +#error "Unable to determine type definition of uintptr_t"
> It occured to me that this is not without danger. Assuming you're using
> a compiler ignoring the push_macro/pop_macro pragmas, then the above
> macro definitions of signed, int and long will prevail from this point
> on. Therefore, to be really sure, another set of #undef's should be
> inserted here:
> #undef signed
> #undef int
> #undef long
OK. I will update the patch.
I also noticed that newlib.hin didn't get updated. What's the
magic for that?
>> +#pragma pop_macro("signed")
>> +#pragma pop_macro("int")
>> +#pragma pop_macro("long")
>> #endif /* __SYS_CONFIG_H__ */
> With that change, ok to push.
My first newlib git push. :)
Is there any guidance for the commit message? I think binutils/gdb
has been doing something like this:
Is that OK?
-- 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
More information about the Newlib