h8300, m32c and PRIuPTR

[Corinna Vinschen]

On Mar 17 10:52, Joel Sherrill wrote:
> On 3/17/2015 10:43 AM, Yaakov Selkowitz wrote:
> > 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.

Oh, sorry, but I really didn't say that.  I was just suggesting to add
the cases where the configury fails to config.h.

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

So each multilib diverging from the default multilib needs handling in
config.h or another header.  In this case I think config.h is the
natural choice, given that variables controlling the behaviour in
inttypes.h are already 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.

Good.  So, let's add the failing cases to sys/config.h.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20150317/2253f095/attachment.sig>