Re: h8300, m32c and PRIuPTR

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

On 3/17/2015 10:43 AM, Yaakov Selkowitz wrote:
> On Tue, 2015-03-17 at 09:58 -0500, Joel Sherrill wrote:
>> On 3/17/2015 4:45 AM, Corinna Vinschen wrote:
>>> 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?
> I don't have m32c atm (PR64403), but aarch64{,_be}, h8300, msp430, and
> sh64 all had different results for certain multilibs.  
>
>> 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
> configure is run for every single multilib separately, so why would this
> be necessary?
>
Because each installation of newlib include files only gets one
newlib.h. It is
only correct for one of the multilibs.

The build tree has many newlib.h instances - one for each multilib.

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