Re: [Mingw-users] [Mingw-cross-env-list] Re: [patch] [ginclude] cooperation between gcc's and mingw's float.h

[Doug Semler <dougsemler at gmail dot com>]

On Sun, Jun 20, 2010 at 8:00 AM, Paolo Bonzini <bonzini@gnu.org> wrote:
> On 06/20/2010 01:50 PM, Volker Grabsch wrote:
>>
>> Paolo Bonzini<bonzini@gnu.org> ?schrieb:
>>>
>>> On 06/19/2010 04:23 PM, Manuel López-Ibáñez wrote:
>>>>
>>>> On 9 June 2010 13:59, Chris Sutcliffe<ir0nh34d@gmail.com> ? wrote:
>>>>>
>>>>> On 7 June 2010 13:10, Volker Grabsch wrote:
>>>>>>
>>>>>> To the GCC maintainers: Would you accept the patch if MinGW-RT
>>>>>> ? ? ? ? ? ? ? ? ? ? ? ? includes the other patch?
>>>>>>
>>>>
>>>> Perhaps the decision takers for this patch have not been specified
>>>> with sufficient clarity. It seems a build issue, so CCing a build
>>>> maintainer.
>>>
>>> What patch? ?Archive link, please. :)
>>
>> Start of discussion in the GCC mailing list:
>> http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00387.html
>>
>> Start of discussion in the MinGW bugtracker:
>>
>> http://sourceforge.net/tracker/?func=detail&atid=302435&aid=3011968&group_id=2435
>>
>> Corresponding changeset in Mingw-cross-env:
>> http://hg.savannah.gnu.org/hgweb/mingw-cross-env/rev/682d860fa4e9
>
> This is not really a GCC build machinery patch (more of a C front-end patch,
> or something like that), so I wouldn't approve it. ?However, to understand
> the issue better, is there a place where I can see the full MinGW float.h?
>
> It seems to me like a better way to fix this might be to rely on
> fixincludes.
>

Mingw 64's float.h adds extensions to float.h for MS compatibility.  I
don't know about float.h from mingw.org but I believe it's similar
Unfortunately the fixincludes route doesn't work, because GCC's
float.h is included first, before the fixincludes headers so you run
into the exact same issue --- the runtime's float.h isn't ever
included.

So, either USER_H needs to be overriden in the gcc config/i386/t-*
makefile frags to prevent gcc from installing the float.h header, so
that mingw's float.h is used, or gcc's float.h needs to be changed so
that it include_next's mingw's float.h.  There is a third messy
method, which is employed by gcc's stdint.h header which does some
things based on the target.  (there is one more method, below).

The drawback to the USER_H method is the requirement that the runtime
maintain a copy of float.h that is pretty a copy of gcc's.  That leads
to one licensing issue that I can think of, and that is that the
runtime may only be compiled by gcc itself...and it also requires the
runtime to track the header for changes.  I vaguely recall that idea
being discussed at one point...

The only other method (mentioned above) that I can really think of
would be a hack to the CPP specs to -include _mingw.h, which would say
have the file included always, and then have that file include the
mingw specific extensions.  That seems to me to be a nasty hack,
though.

(Note that for mingw-64, this issue is also in stddef.h and stdarg.h.
However, stddef.h actually should probably have mingw-64's changes
incorporated into gcc's stddef.h since they are type sizing and
declarations that are specific for the architecture, like wint_t being
unsigned short not unsigned int, etc)