#28 Patch for GCC float.h

[Ivan Maidanski]

Without this patch, I have to set c_include_path=/cygdrive/C/x86mingw32ce/i386-mingw32ce/include.
The same problem exists in mingw-w64 project, see: https://sourceforge.net/tracker/index.php?func=detail&aid=2363741&group_id=
202880&atid=983354

The patch should be really sent to GCC but I'd like to know your opinion.

I use __MINGW32__ to identify toolchains that have MS-specific float.h (i.e., for CeGCC toolchains, they are mingw32ce and x86mingw32ce but not cegcc). Should be correct, right?

[Ivan Maidanski]

proposed patch

[Danny Backx]

You're saying that the gcc float.h overrides the mingw one. Yes that does make sense.
Also yes sending it to GCC makes sense.
I'm not sure why you define the _NEXT_FLOAT_H_ macro though.
Your proposed use of __MINGW32__ looks right. __MINGW32__ is indeed defined by both {arm,i386}-mingw32ce-gcc . arm-cegcc-gcc doesn't appear to have this situation and it doesn't define __MINGW32__.

[Ivan Maidanski]

> Also yes sending it to GCC makes sense.
Unfortunately, it seems it doesn't... See this post: https://sourceforge.net/tracker/?func=detail&aid=2896485&group_id=202880&atid=983356
This post also suggests another solution - copy the contents of gcc float.h into the specific mingw one and remove the gcc one.

> I'm not sure why you define the _NEXT_FLOAT_H_ macro though.
This is just a guard against infinite recursion between a specific float.h and a gcc one (they may both do include_next each other (before checking for _FLOAT_H) in some toolchains).
_NEXT_FLOAT_H_ is not used anywhere else (and is unique as reported by google codesearch).

[Paul Sokolovsky]

Thanks for your bug report!

To ease maintenance of the project, we are migrating bug tracking facilities to Trac. We would appreciate if you re-posted this bug on Trac via https://sourceforge.net/apps/trac/cegcc/newticket . Please include link to this bug for reference.