h8300, m32c and PRIuPTR
Tue Mar 17 15:43:00 GMT 2015
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
> 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
(or sys/config.h) for the targets which have variations in uintptr_t
based on multilib. The static configure.in check gets all but 2?
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
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
More information about the Newlib