[cfe-dev] MinGW(-w64) fixes to InitHeaderSearch.cpp and float.h

[Douglas Gregor]

On Jul 2, 2011, at 6:08 AM, Ruben Van Boxem wrote:

> 2011/6/27 Ruben Van Boxem <vanboxem.ruben at gmail.com>:
>> Op 27 jun. 2011 17:51 schreef "Douglas Gregor" <dgregor at apple.com> het volgende:
>>> 
>>> On Jun 25, 2011, at 7:51 AM, Ruben Van Boxem wrote:
>>> 
>>>> Hi,
>>>> 
>>>> I bring fixes for MinGW(-w64) Clang users:
>>>> 
>>>> 1. InitHeaderSearch.cpp: add a HeaderSearchOptions argument to
>>>> AddDefaultCXXIncludePaths (AddDefaultCIncludePaths already had this,
>>>> seems only logical to have it here) and use ResourceDir to find the
>>>> sysroot of where Clang.exe is located. From there, add the
>>>> x86_64-w64-mingw32 and i686-w64-mingw32 include paths for C and C++.
>>>> All mingw-w64 toolchains are built --with-sysroot, and thus
>>>> relocatable, so this change will always find the accompanying headers.
>>> 
>>> I've committed this part as r133911.
>>> 
>>>> 2. float.h: MinGW needs an #include_next, because as described on this
>>>> page (http://msdn.microsoft.com/en-us/library/y0ybw9fy.aspx) there are
>>>> non-standard extensions to float.h which are expected on Windows, and
>>>> MinGW provides these declarations in their system header. GCC's
>>>> float.h is "fixinclude"d to include_next the system header. Note that
>>>> a trivial change is needed in mingw-w64's float.h, and that change
>>>> will be committed as soon as Clang's header does what it's supposed to
>>>> do.
>>> 
>>> 
>>> If we're including MinGW's float.h first, then our own definitions of all of the standard float.h macros are going to stomp on the ones that come from MinGW's float.h. I think that's a reasonable thing to do, but if that's the intent, I'd prefer to have #undef's in our own float.h to make it explicit that this is what we're doing (and so that our own headers don't generate warnings, even if they're suppressed).
>> 
>> I just copied that behavior (and the comment) from <stdint.h>, but I
>> know that mingw-w64's float.h header does #undef everything it
>> redefines, so it would perhaps be better if the #include_next in
>> Clang's float.h came at the end. Then nothing else needs to change
>> much.
>> 
>> Ruben
>> 
> 
> I have attached a new patch with two new GCC versions for the include
> paths, and I moved the #include_next <float.h> to the end. My previous
> testing proved this would work if the mingw-w64 headers is adapted to
> detect Clang as well (will happen as soon as Clang's header is
> patched). If someone would be so kind to apply these minor changes,
> I'd be very happy.

My suggestion would have been to #include_next <float.h> at the beginning, then #undef everything that Clang's <float.h> is going to define, so that Clang is guaranteed to get its own definitions of the standard macros. Did this not work?

The patch you attached is something different (a CMake change for TableGen). Is that change still necessary?

	- Doug

> Thanks!
> 
> Ruben
> 
> PS: And once these changes are in, you can expect a CLang package to
> be provided by me here for use with mingw-w64:
> http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/rubenvb/
> <mingw.patch>