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

proposed patch

• assigned_to: nobody --> dannybackx
• status: open --> open-accepted

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__.

> 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).

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.