[Bug 2038] C99 integer type mismatch in GCC and Newlib

[bugzilla-daemon at rtems.org]

https://www.rtems.org/bugzilla/show_bug.cgi?id=2038

--- Comment #18 from Ralf Corsepius <ralf.corsepius at rtems.org> 2012-04-02 12:30:57 CDT ---
I realized, I missed answer this (I am short on time these days).

(In reply to comment #12)
> (In reply to comment #11)
> > (In reply to comment #10)
> > > Just so I understand.
> > > 
> > > 1. GCC tests generated warnings because the stdint.h in newlib did not match up
> > > with what gcc says it needs.
> > 
> > Mostly. GCC generates warnings, when it detects type mismatches. Inside of
> > GCC's testsuite, these are raised to errors due to the testsuites using
> > -Werror.
> > 
> > > 2. The solution is to switch to GCC and so the warnings have gone.
> > 
> > If you want to express it this way, yes.
> > 
> 
> On the surface this appears the situation. If there are other issues present I
> have not seen any specific reference about them, no PR, nothing.

Well, rest assured, there have been many such issues. 
E.g. all "GCC emits duplicate fprintf warnings" and most of the newlib patches
RTEMS GCC/newlib has beeen carrying around have their origin in these issue.

> I feel just rm'ing the newlib header in your spec file is not a great solution.

Agreed. As I wrote earlier, it's a short-cut.

> It would seem fragile.
I don't see anything fragile in an rm.

> What about newlib ? There must be others in the newlib
> community who have a similar issue.
I don't know - AFAICT, similar to RTEMS, many newlib based toolchains use
customized stdint.h's.


> > What I am trying now, is to escape this "never-ending" struggle with conflicts
> > between the POSIX stdint.h types vs. GCC's internal types, by switching to
> > GCC's stdint.h.
> 
> I do not follow. By GCC internal types do mean what it uses internally for an
> int or long and how that maps to the POSIX types of uint32_t etc ?
Not quite.

GCC internally has built-in types for fixed-size types.

It uses them internally for compile-time operations which apply fixed-size
types (e.g. fprintf format string checking).

> If so does
> this mean newlib is drifting from gcc ?
Well, I would not call it "drifting from", I would call it "evolving works".


> Again would this be a concern to the
> newlib community in general ?
Hmm, no. It's just that newer GCCs provide further, different options for
approaches to old problems.

In other words, modern GCCs are equipped with the tooling, which render the
approach to stdint.h, I had introduce to newlib years ago, obsolete.

> Why is the tools repo for HEAD the place you implement this ?

The RTEMS-master/HEAD is RTEMS "unstable, experimental, testing" branch. Its
purpose is user-testing.

Apart of this, this step is much less risky than upgrading gcc to a new
gcc-release.

> If a regression
> appears any user is stuck until the fix is found or you unwind the repo.
Exactly. I am surprized you are asking, because this step is not really
different from what I have been doing with newlib/gcc many times for many
years.


> > ATM, my plan is to gradually address these issues, when gradually address the
> > outstanding issues blocking targets from upgrading to GCC-4.7.0.
> 
> Ok. Any chance you might share these plans in detail ?

The plan is quite simple: Upgrade all rtems-4.11 toolchains to gcc-4.7.0 and
improve to stdint-changes related integration.

Unfortunatly, I regret having to say this, from an RTEMS focused perspective,
GCC-4.7.0 appears to be a classical "dot NULL" release.

-- 
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.