On Tue, Apr 25, 2017 at 5:33 PM, Bruno Cardoso Lopes
<bruno.card...@gmail.com> wrote:
> On Tue, Apr 25, 2017 at 6:29 AM, Aaron Ballman <aa...@aaronballman.com> wrote:
>> On Wed, Dec 7, 2016 at 9:13 PM, Bruno Cardoso Lopes via cfe-commits
>> <cfe-commits@lists.llvm.org> wrote:
>>> Author: bruno
>>> Date: Wed Dec 7 20:13:56 2016
>>> New Revision: 289018
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=289018&view=rev
>>> Log:
>>> [Headers] Enable #include_next<float.h> on Darwin
>>>
>>> Allows darwin targets to provide additional definitions and
>>> implementation specifc values for float.h
>>>
>>> rdar://problem/21961491
>>>
>>> Added:
>>> cfe/trunk/test/Headers/Inputs/usr/
>>> cfe/trunk/test/Headers/Inputs/usr/include/
>>> cfe/trunk/test/Headers/Inputs/usr/include/float.h
>>> cfe/trunk/test/Headers/float-darwin.c
>>> Modified:
>>> cfe/trunk/lib/Headers/float.h
>>
>> This commit appears to have caused a regression:
>> https://bugs.llvm.org//show_bug.cgi?id=31504
>>
>> I am running into this on a Snow Leopard system as well, where the
>> Integration tests are now failing because float.h cannot be found by
>> the system #include_next.
>
> What's actually happening here is that Snow Leopard (or any < 10.7)
> used to ship a /usr/include/float.h, which has by itself another
> include_next (which is the one failing), see:
>
> --
> /* This file exists soley to keep Metrowerks' compilers happy. The version
> used by GCC can be found in /usr/lib/gcc, although it's
> not very informative. */
>
> #ifndef _FLOAT_H_
>
> #if defined(__GNUC__)
> #include_next <float.h>
> --
>
> We don't have any reliable way to check for the SDK version at this
> level, the current macros we have tell a history about deployment
> target, but that won't always solve the issue here. Can you try this
> workaround below and let me know if works?
>
> --
> #if (defined(__APPLE__) || (defined(__MINGW32__) || defined(_MSC_VER))) && \
> __STDC_HOSTED__ && __has_include_next(<float.h>)
>
> #ifdef __APPLE__
> #define _FLOAT_H_ // Avoid #include_next'ing float.h content on MacOSX < 10.7
> #endif
>
> # include_next <float.h>
> --
>
>> I was thinking of modifying lib/Headers/float.h to use the SDK version as
>> mentioned in the bug report, but I share the reporter's question: why was
>> this change needed in the first place? I couldn't find a review for the
>> commit, and don't have access to the rdar link.
>
> We need it to have flexibility to implement additional stuff for
> float.h on future SDKs. There was no good reason for not upstreaming
> it. I never got to the point of dealing with this specific issue
> though, thanks for pinging.
What good timing. I was about to post this as a possible fix:
Index: lib/Headers/float.h
===================================================================
--- lib/Headers/float.h (revision 135915)
+++ lib/Headers/float.h (working copy)
@@ -31 +31 @@
- * Also fall back on Darwin to allow additional definitions and
+ * Also fall back on Darwin 10.7 or later to allow additional definitions and
@@ -34 +34,4 @@
-#if (defined(__APPLE__) || (defined(__MINGW32__) || defined(_MSC_VER))) && \
+#if ((defined(__APPLE__) &&
\
+ defined(__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__) &&
\
+ __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ >= 1070) ||
\
+ (defined(__MINGW32__) || defined(_MSC_VER))) &&
\
Would this be an improvement over your suggestion?
~Aaron
>
> --
> Bruno Cardoso Lopes
> http://www.brunocardoso.cc
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
