h8300, m32c and PRIuPTR

[Yaakov Selkowitz]

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.