On Mon, Jun 17, 2013 at 4:02 PM, Richard Smith <[email protected]> wrote: > 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.
Sickening workaround hack deployed in r184395. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
