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

Ruben Van Boxem vanboxem.ruben at gmail.com
Tue Jul 5 09:18:58 PDT 2011


2011/7/5 Douglas Gregor <dgregor at apple.com>:
>
> On Jul 5, 2011, at 9:07 AM, Ruben Van Boxem wrote:
>
>> 2011/7/5 Ruben Van Boxem <vanboxem.ruben at gmail.com>:
>>> 2011/7/5 Douglas Gregor <dgregor at apple.com>:
>>>>
>>>> On Jul 4, 2011, at 12:30 PM, Ruben Van Boxem wrote:
>>>>
>>>>> 2011/7/2 Ruben Van Boxem <vanboxem.ruben at gmail.com>:
>>>>>> 2011/7/2 Douglas Gregor <dgregor at apple.com>:
>>>>>>>
>>>>>>> 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?
>>>>>>
>>>>>> It does, I just tested it. Attached is your change.
>>>>>>
>>>>>>>
>>>>>>> The patch you attached is something different (a CMake change for TableGen). Is that change still necessary?
>>>>>>
>>>>>> Yes, terribly sorry for the bad attachment, I took the LLVM directory
>>>>>> instead of LLVM/tools/clang directory. Should have double-checked.
>>>>>>
>>>>>> Ruben
>>>>>>
>>>>>
>>>>> Sorry to be such a pain in the *ss, but I'd really like this patch in.
>>>>> Then I can build/release a mingw-w64 Clang build and you'll have a lot
>>>>> more testers for that platform (I hope).
>>>>
>>>> It *is* a holiday weekend in the United States, where most of the code owners are located.
>>>
>>> So it is :) must have forgotten about that :s At least I know I'm a
>>> pain in the *ss. Thanks *very* much!
>>>
>>> Ruben
>>>
>>
>> I just noticed the new float.h undef's everything twice if __MINGW32__
>> is defined. I assume it was the idea to remove the undef's outside of
>> the __MINGW32__ ifdef?
>
> Please "svn revert" your float.h; I moved the undefs inside of the __MINGW32__ ifdef.
>
>        - Doug
>

I see, sorry for the noise.




More information about the cfe-dev mailing list