This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: h8300, m32c and PRIuPTR
- From: Yaakov Selkowitz <yselkowi at redhat dot com>
- To: newlib at sourceware dot org
- Date: Tue, 17 Mar 2015 10:43:47 -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> <5508412E dot 40801 at oarcorp dot com>
On Tue, 2015-03-17 at 09:58 -0500, Joel Sherrill wrote:
> On 3/17/2015 4:45 AM, Corinna Vinschen wrote:
> > Anyway. Aren't we moving away from the original problem? The original
> > problem was, afaics, related to target multilibs which produce uintptr_t
> > types different from the ones configured.
> I thought we also had to replace the configure.in logic that determined if
> uintptr_t was "long unsigned int" or just "unsigned int". That check
> only produces the correct result with the type of uintptr_t doesn't
> change by multilib.
> > Why is that so? Shouldn't the configury have catched that for each
> > multilib? If not, why not, and how do we fix that?
> I think that since there is only one config.h generated and installed,
> it may work
> out ok for building (not sure) but once installed, only one answer is
> available.
> > Do we really gain anything by introducing a massive ifdef mentioning
> > all targets out there? This looks like overkill.
> One approach is to leave the configure logic and add exceptions in
> inttypes.h
> (or sys/config.h) for the targets which have variations in uintptr_t
> definition
> based on multilib. The static configure.in check gets all but 2?
> targets right.
>
> Yaakov.. are m32c and h8300 the only cases where inttypes_t varies based
> on multilib settings?
I don't have m32c atm (PR64403), but aarch64{,_be}, h8300, msp430, and
sh64 all had different results for certain multilibs.
> If that's the case, we could probably get by with something like this
> in either sys/config.h:
>
> #if m32c || h8300
> #undef setting from configure.in
> logic to set appropriate cpp macro from configure.in correctly
> #endif
configure is run for every single multilib separately, so why would this
be necessary?
--
Yaakov Selkowitz
Associate Software Engineer, ARM
Red Hat, Inc.
- 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