This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: h8300, m32c and PRIuPTR
- From: Joel Sherrill <joel dot sherrill at oarcorp dot com>
- To: Yaakov Selkowitz <yselkowi at redhat dot com>, "newlib at sourceware dot org" <newlib at sourceware dot org>
- Date: Tue, 17 Mar 2015 10:52:38 -0500
- Subject: Re: h8300, m32c and PRIuPTR
- Authentication-results: sourceware.org; auth=none
- References: <20150316150842 dot GI6096 at calimero dot vinschen dot de> <5506FCAA dot 8030403 at oarcorp dot com> <20150316161732 dot GJ6096 at calimero dot vinschen dot de> <55070486 dot 8060503 at oarcorp dot com> <20150316164918 dot GK6096 at calimero dot vinschen dot de> <55071AC5 dot 40104 at oarcorp dot com> <1426533957 dot 8104 dot 52 dot camel at redhat dot com> <55072FBB dot 8080107 at oarcorp dot com> <1426535357 dot 8104 dot 60 dot camel at redhat dot com> <55073603 dot 6070403 at oarcorp dot com> <20150317094510 dot GN6096 at calimero dot vinschen dot de> <5508412E dot 40801 at oarcorp dot com> <1426607027 dot 12464 dot 26 dot camel at redhat 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
- References:
- Re: h8300, m32c and PRIuPTR
- Re: h8300, m32c and PRIuPTR
- Re: h8300, m32c and PRIuPTR
- Re: h8300, m32c and PRIuPTR
- Re: h8300, m32c and PRIuPTR
- Re: h8300, m32c and PRIuPTR
- Re: h8300, m32c and PRIuPTR
- Re: h8300, m32c and PRIuPTR
- Re: h8300, m32c and PRIuPTR
- Re: h8300, m32c and PRIuPTR
- Re: h8300, m32c and PRIuPTR
- Re: h8300, m32c and PRIuPTR
- Re: h8300, m32c and PRIuPTR