h8300, m32c and PRIuPTR

[Corinna Vinschen]

Hi Joel,

On Mar 16 14:58, Joel Sherrill wrote:
> On 3/16/2015 2:49 PM, Yaakov Selkowitz wrote:
> > On Mon, 2015-03-16 at 14:32 -0500, Joel Sherrill wrote:
> >> On 3/16/2015 2:25 PM, Yaakov Selkowitz wrote:
> >>> On Mon, 2015-03-16 at 13:02 -0500, Joel Sherrill wrote:
> >>>> But remember, not every newlib target is an RTEMS target.  This balance
> >>>> could shift based on the other bare machine targets.  Does someone
> >>>> have *-elf targets handy for targets that do not have RTEMS to test using
> >>>> my script and test case?
> >>> Attached are what I ended up with after fixing the warnings.
> >>>
> >> Thanks!!! Can you add a unique #warning to each #define case and
> >> see what the distribution is?
> >>
> >> I hacked on my version and ended up with this:
> >>
> >>       2     #warning "CASE: 1 long long only"
> >>       8      #warning "CASE: 2 long but use int"
> >>       7      #warning "CASE: 3 long use long"
> >>       4      #warning "CASE: 4 int use int"
> > 11 CASE: 1
> > 147 CASE: 2
> > 88 CASE: 3
> > 11 CASE: 4
> Were you testing all the multilb flags to get that many combinations?
> 
> Hmmm.. Corinna any thoughts now on how you want case 2 and 3 structured?

I don't quite follow your testcase.  By checking for
__SIZEOF_LONG_LONG__ == __SIZEOF_PTRDIFF_T__ first, you're
catching all targets with sizeof(long)==siezof(long long) as well in
this case.  However, practically all these targets will use long as
type for pointer arithmetic, which makes them equivalent to case 3
if the evaluation order would have been turned around.
Are there any targets at all which would use long long in this case?
Except for LLP64 Windows, which we don't support?

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.

Why is that so?  Shouldn't the configury have catched that for each
multilib?  If not, why not, and how do we fix that?

Do we really gain anything by introducing a massive ifdef mentioning
all targets out there?  This looks like overkill.


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/29e7d776/attachment.sig>