h8300, m32c and PRIuPTR

[Yaakov Selkowitz]

On Mon, 2015-03-16 at 14:58 -0500, 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?

Yes, I used `$t-gcc -print-multi-lib` in a nested for loop to test all
multilibs.

> Which cpus used case 3 for you? I have
> 
> bfin, i386, m32r, m68k, or1k, and some m32c and some h8300

I have those, plus aarch64{,_be} -mabi=ilp32, cris, epiphany, fido,
msp430 -mlarge, nds32{b,l}e, rx, sh64 (except for -m5-64media*), and
spu.

(BTW, why isn't BE just a multilib for aarch64 and arm instead of a
separate target?  And why isn't nds32 a single target, as both nds32le
and nds32be support the other endianness as multilibs??)

> >> I could fold the two cases in the "long long" block into one. Maybe
> >> you have a target that uses the second case.
> > None of my targets used __STRINGIFY(ll##x).
> Then my local change to just use Case 1 with no if inside seems OK.
> There is no reason to keep that path.

Maybe leave an #error FIXME just in case?

> >> That will let us know how the if/else should go.  Of course, one
> >> school of thought is that **ALL** targets should be listed and
> >> you get an error otherwise. That ensures that no one misses
> >> a spot where a porter should look.
> > Note that I'm still missing (at least) the following newlib targets:
> >
> > avr-elf: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64401
> > cr16-elf: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64424
> > iq2000-elf: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64400
> > m32c-elf: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64403
> > mep-elf: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64402
> > or1k-elf: requires GCC 5.0
> > xstormy16-elf: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64407
> We have or1k based on the external repository. I forgot to include it in the
> script. It is Case 3.
> 
> avr is case 4. We have tools based on 4.9.2 for rtems.

Right, my issue is that libgcc's crtbegin.o does not compile for
avr-elf, and that file is skipped on avr-rtems.

> > I see you mentioned m32c earlier, do you have a patch for gcc-4.9.2?
> >
> RTEMS is stuck at 4.8.3 also.

Too bad. :-(  Are any of the other broken targets working in 4.8?

-- 
Yaakov Selkowitz
Associate Software Engineer, ARM
Red Hat, Inc.