On Mon, Jun 17, 2013 at 2:37 PM, Sebastian Redl <[email protected]> wrote: > > On 17.06.2013, at 21:42, Richard Smith wrote: > >> On Mon, Jun 17, 2013 at 12:23 PM, Jordan Rose <[email protected]> wrote: >>> >>> On Jun 17, 2013, at 12:20 , Nico Weber <[email protected]> wrote: >>> >>> On Mon, Jun 17, 2013 at 9:38 AM, Jordan Rose <[email protected]> wrote: >>>> >>>> *sigh* I can't say this is the wrong thing to do—in fact, it's the kind of >>>> restriction I usually like—but for the record this breaks OS X's (ancient) >>>> libstdc++ implementation of <tr1/unordered_map> when compiling under >>>> -std=c++11. I don't think that's such an important configuration, though. >>> >>> >>> That means it breaks all programs that try to build in C++11 mode but still >>> need to ship to 10.6 (like, say, Chromium). Can this be worked around >>> somehow? >>> >>> >>> Will that still be true by the next Xcode release? It's not in 4.6.2, and I >>> can watch to make sure it stays out of Xcode 5. Do you really need to build >>> your 10.6-compatible binary with trunk Clang in C++11 mode? >>> >>> Richard, I suppose you could make it a warning... >> >> That's actually pretty tricky, due to its effects on SFINAE, overload >> resolution, and so on. But we should be able to add a more limited >> workaround which suffices for this specific libstdc++ issue. > > We had workarounds of the type "make this an error in SFINAE context and a > warning otherwise" before.
This is a much harder case, though, because of the effect on overload resolution (and more generally because the point where an error is detected can be distant from the point where we make the decision). If we only want to work around this one libstdc++ bug, we can just detect the case where a return statement's expression is the 'false' literal. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
