This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Add and use __INTTYPES_EXP()


On 11/22/2012 11:40 AM, Sebastian Huber wrote:
On 11/22/2012 11:27 AM, Ralf Corsepius wrote:
On 11/22/2012 10:37 AM, Sebastian Huber wrote:

introduces __STDINT_EXP() in inttypes.h.  If we use the GCC provided
stdint.h, then this results in:

inttypes.h:245:32: error: missing binary operator before token "("
inttypes.h:248:34: error: missing binary operator before token "("

reproducer?

I tried to use the current Newlib HEAD.



RTEMS has been using the GCC provided stdint.h combined with a different patch
to newlib's inttypes.h applied[1] with none such error having been reported by
anybody anywhere.



That said, as this patch has not seen wider exposure to the public, this patch
is too intruse to allow it letting it into newlib without further _extensive_
testing in and outside of RTEMS.


Note: I did not say your patch is wrong. I only said it needs more testing (== time).
As far as I am concerned, this at least means me to rebuild all RTEMS toolchains with your patch applied, to rebuild all of RTEMS with the resulting toolchains and to compare the results of the different versions of the toolchains with my inttypes/stdint-testsuite.


This means several weeks of (spare-time) work for me.

Ralf

[1] These patches were not submitted because they are hacks and because there
are other issues inside of newlib when being used with GCC's stdint.h.



Ok, this means that current Newlib + GCC provided stdint.h is broken at the moment?


Correct. Most critical issue is newlib's stdint.h is conflicting with the GCC generated one during bootstrapping the GCC/newlib.

ATM, the only known work-around to this issue is to physically remove newlib's stdint.h from the source-tree, before building (So far, this has been scripted in my buildscripts (the rpm.specs) and will likely do so in the next generation of the rtems-newlib-patches).

I already was inclined to propose to let newlib drop providing stdint.h and to change all newlib based GCC's to use the GCC-provided stdint.h, but I don't think this proposal would have any chance to be accepted. Unfortunately, I haven't found a better solution, yet.

Ralf


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]