Re: h8300, m32c and PRIuPTR

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

On 3/17/2015 4:45 AM, Corinna Vinschen wrote:
> 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.
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?

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

>
> Corinna
>

-- 
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