h8300, m32c and PRIuPTR
Tue Mar 17 16:54:00 GMT 2015
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: not available
More information about the Newlib