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/17/2015 11:09 AM, Joseph Myers wrote:
> On Tue, 17 Mar 2015, Corinna Vinschen wrote:
>
>> Do we really gain anything by introducing a massive ifdef mentioning
>> all targets out there?  This looks like overkill.
> Was there some problem with the logic I suggested in 
> <https://sourceware.org/ml/newlib/2014/msg00421.html> to determine the 
> type used for intptr_t without any per-architecture conditionals or 
> configure tests being needed?  (It's true that if some architecture 
> decides to use e.g. __int24 for intptr_t, additional cases would be 
> needed, but that logic should cover all architectures where int, long or 
> long long are used.)
That works except in cases where the definition of uintptr_t varies based
on the multilib. 

As I mentioned earlier, there is indeed a newlib.h in the build tree for
each
multilib variant [1] but only version is installed. So even if we get
the answer
right in each newlib.h in the build tree, the user is stuck with one answer
for ${target} when there should be a separate one for each multilib.

It seems that if we could rely on gcc provided information directly
and not have any intermediate logic, it would be simpler.

[1] I have not checked if all the various newlib.h files in the build tree
get the right answer all the time.

-- 
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


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