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: Yaakov Selkowitz <yselkowi at redhat dot com>,"newlib at sourceware dot org" <newlib at sourceware dot org>
- Date: Tue, 17 Mar 2015 17:33:17 -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> <55085374 dot 1090707 at oarcorp dot com> <alpine dot DEB dot 2 dot 10 dot 1503171618250 dot 15889 at digraph dot polyomino dot org dot uk> <55085C4D dot 3090108 at oarcorp dot com> <1426621348 dot 12464 dot 34 dot camel at redhat dot com>
On March 17, 2015 2:42:28 PM CDT, Yaakov Selkowitz <yselkowi@redhat.com> wrote:
>On Tue, 2015-03-17 at 11:54 -0500, Joel Sherrill wrote:
>> On 3/17/2015 11:22 AM, Joseph Myers wrote:
>> > On Tue, 17 Mar 2015, Joel Sherrill wrote:
>> >> 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.
>> > My proposed logic would go in an architecture-independent installed
>
>> > header, so I don't see the issue.
>> >
>> I remember you proposing this but not why it wasn't pursued. Anyway,
>> I through it into the test case and it did work for my cases.
>>
>> Yaakov, does it work for all your configurations?
>
>Yes, that f.c produces zero type mismatches.
Awesome!
I will propose a patch removing the probe from configure.in and adding this to sys/config.h including the push/pop suggestion.
--joel
- 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
- Re: h8300, m32c and PRIuPTR
- Re: h8300, m32c and PRIuPTR
- Re: h8300, m32c and PRIuPTR
- Re: h8300, m32c and PRIuPTR