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