[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 #12 from Chris Johns <chrisj at rtems.org> 2012-03-29 16:49:50 CDT ---
(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.

> > What about newlib ? Is newlib all ok and passing all its tests with these
> > changes across all architectures.
> Newlib is supposed to be OK. ATM, I am not aware of any regression.

Do you think "supposed to be OK" is good enough ?

Are there newlib tests that should have been run before pushing these changes ?

I feel just rm'ing the newlib header in your spec file is not a great solution.
It would seem fragile. What about newlib ? There must be others in the newlib
community who have a similar issue. Has this been raised and discussed with
them ?

> 
> > If they are the same why change them ?
> >
> > What was different that caused these warnings ?
> Let me try to elaborate:
> 
> RTEMS-newlib's stdint.h initially applied checks on GCC's internal types's
> _sizes_ to derive POSIX _types_ (int32_t, intptr_t etc.) and POSIX defines
> (INT32_C, etc.). E.g. it tries to typedef int32_t to "int" or "long" if the
> size of "int" or "long" matches 32 bit, but it doesn't know whether GCC is
> using "int" or "long" for its internal int32_t type.  This works, as long as
> GCC internal types and newlib's choice are compatible.
> 
> However, over the years, GCC was added type-checks (notably fprintf format
> checks/-Wformat), which furtherly tightened the constraints on _types_. This
> made closer matching of the _types_ being used in typedefs in stdint.h and
> GCC's internal _types_ necessary, which had caused newlib's stdint.h to
> gradually getting cluttered with further GCC-specific preprocessor magic.
> 
> At the same time, GCC had been gradually extended with the capability to
> directly provide a stdint.h.
> 
> In this context, the test failures Sebastian tripped over, are caused by GCC
> having furtherly extended its internal types (In particuliar, they added
> __INTPTR_TYPE__) and changed other internal types.

Sebastian just ran the gcc testsuite. Maybe this is what ours tools should do
before being pushed ?

> 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 ? If so does
this mean newlib is drifting from gcc ? Again would this be a concern to the
newlib community in general ?

> 
> Finally note, the current implementation is only an initial step, I have been
> testing by compile-tests (e.g. I compiled all RTEMS multilibs) and some other
> tests (I have a testsuite aiming at  stdint types). However, it definitely
> needs more testing, as well as does the implementation need improvements.
> 

Why is the tools repo for HEAD the place you implement this ? If a regression
appears any user is stuck until the fix is found or you unwind the repo.

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

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