This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: h8300, m32c and PRIuPTR
- From: Joel Sherrill <joel dot sherrill at oarcorp dot com>
- To: Joseph Myers <joseph at codesourcery dot com>, "newlib at sourceware dot org" <newlib at sourceware dot org>
- Date: Tue, 17 Mar 2015 11:16:52 -0500
- Subject: Re: h8300, m32c and PRIuPTR
- Authentication-results: sourceware.org; auth=none
- References: <20150316150842 dot GI6096 at calimero dot vinschen dot de> <5506FCAA dot 8030403 at oarcorp dot com> <20150316161732 dot GJ6096 at calimero dot vinschen dot de> <55070486 dot 8060503 at oarcorp dot com> <20150316164918 dot GK6096 at calimero dot vinschen dot de> <55071AC5 dot 40104 at oarcorp dot com> <1426533957 dot 8104 dot 52 dot camel at redhat dot com> <55072FBB dot 8080107 at oarcorp dot com> <1426535357 dot 8104 dot 60 dot camel at redhat dot com> <55073603 dot 6070403 at oarcorp dot com> <20150317094510 dot GN6096 at calimero dot vinschen dot de> <alpine dot DEB dot 2 dot 10 dot 1503171606520 dot 15889 at digraph dot polyomino dot org dot uk>
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
- References:
- Re: h8300, m32c and PRIuPTR
- Re: h8300, m32c and PRIuPTR
- Re: h8300, m32c and PRIuPTR
- Re: h8300, m32c and PRIuPTR
- Re: h8300, m32c and PRIuPTR
- Re: h8300, m32c and PRIuPTR
- Re: h8300, m32c and PRIuPTR
- Re: h8300, m32c and PRIuPTR
- Re: h8300, m32c and PRIuPTR
- Re: h8300, m32c and PRIuPTR
- Re: h8300, m32c and PRIuPTR
- Re: h8300, m32c and PRIuPTR