Re: h8300, m32c and PRIuPTR

[Joel Sherrill <joel dot sherrill at oarcorp dot com>]

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?

Which cpus used case 3 for you? I have

bfin, i386, m32r, m68k, or1k, and some m32c and some h8300
>> 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.
>> 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.
> I see you mentioned m32c earlier, do you have a patch for gcc-4.9.2?
>
RTEMS is stuck at 4.8.3 also.

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985