Quantcast

[ cegcc-Bugs (use Trac instead)-2896500 ] Patch for GCC float.h

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[ cegcc-Bugs (use Trac instead)-2896500 ] Patch for GCC float.h

SourceForge.net
Bugs (use Trac instead) item #2896500, was opened at 2009-11-12 01:35
Message generated for change (Comment added) made by pfalcon
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=865514&aid=2896500&group_id=173455

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Ivan Maidanski (ivmai)
Assigned to: Danny Backx (dannybackx)
Summary: Patch for GCC float.h

Initial Comment:
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?


----------------------------------------------------------------------

>Comment By: Paul Sokolovsky (pfalcon)
Date: 2011-02-05 07:10

Message:
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.


----------------------------------------------------------------------

Comment By: Ivan Maidanski (ivmai)
Date: 2009-11-14 08:33

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


----------------------------------------------------------------------

Comment By: Danny Backx (dannybackx)
Date: 2009-11-13 23:22

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

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=865514&aid=2896500&group_id=173455

------------------------------------------------------------------------------
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world?
http://p.sf.net/sfu/oracle-sfdevnlfb
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Loading...