<div dir="ltr">Yes, fixing these ABI bugs would require an ABI change. I don't know of ABI bugs in standard C++03 components,<div><br></div><div>I'm not sure how many users actually depend on our C++11 extensions in C++03. Or how many of those people mix</div><div>different C++ dialects in the same binary.</div><div><br></div><div>My sense is that having a different ABI between C++11 and C++03 is worse than breaking ABI compatibility once to fix that.</div><div><br></div><div><div>In the case of  `std::function::operator()(...)`, the  C++03 implementation passes rvalues across the type-erasure boundary</div><div>by value, C++11 passes by rvalue reference. If both versions of the vtable appear in your program than you've got problems. </div><div><br></div><div><div>It's less clear if  deleting <__nullptr> emulation is as palatable for all parties. I could imagine a user writing a declaration</div></div></div><div>that contains `std::nullptr_t` in the mangling.</div><div><br></div><div>/Eric</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 10, 2019 at 6:03 PM JF Bastien <<a href="mailto:jfbastien@apple.com">jfbastien@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><br><div><br><blockquote type="cite"><div>On Jun 10, 2019, at 1:37 PM, Eric Fiselier via libcxx-dev <<a href="mailto:libcxx-dev@lists.llvm.org" target="_blank">libcxx-dev@lists.llvm.org</a>> wrote:</div><br class="gmail-m_-1720169299865068893Apple-interchange-newline"><div><div dir="ltr"><div class="gmail-m_-1720169299865068893gmail-gs" style="margin:0px;padding:0px 0px 20px;width:1264px;font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-size:inherit"><div class="gmail-m_-1720169299865068893gmail-"><div id="gmail-m_-1720169299865068893gmail-:178" class="gmail-m_-1720169299865068893gmail-gt gmail-m_-1720169299865068893gmail-ii" style="font-size:12.8px;direction:ltr;margin:8px 0px 0px;padding:0px"><div id="gmail-m_-1720169299865068893gmail-:177" class="gmail-m_-1720169299865068893gmail-a3s gmail-m_-1720169299865068893gmail-aXjCH" style="overflow:hidden;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:small;line-height:1.5;font-family:Arial,Helvetica,sans-serif"><div dir="ltr"><div class="gmail-m_-1720169299865068893gmail-gs" style="margin:0px;padding:0px 0px 20px;width:1272px;font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-size:12px"><div class="gmail-m_-1720169299865068893gmail-"><div id="gmail-m_-1720169299865068893gmail-:11u" class="gmail-m_-1720169299865068893gmail-gt gmail-m_-1720169299865068893gmail-ii" style="font-size:12.8px;direction:ltr;margin:8px 0px 0px;padding:0px"><div id="gmail-m_-1720169299865068893gmail-:11v" class="gmail-m_-1720169299865068893gmail-a3s gmail-m_-1720169299865068893gmail-aXjCH" style="overflow:hidden;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:small;line-height:1.5;font-family:Arial,Helvetica,sans-serif"><div dir="ltr"><div><span style="font-family:"Lucida Grande","Lucida Sans Unicode",Arial,Verdana,Helvetica,sans-serif">Hello,</span></div><div><span style="font-family:"Lucida Grande","Lucida Sans Unicode",Arial,Verdana,Helvetica,sans-serif"><br></span></div><div><span style="font-family:"Lucida Grande","Lucida Sans Unicode",Arial,Verdana,Helvetica,sans-serif">libc++ claims to support GCC with C++03 ("G++03"), and this is a problem for our users.</span></div><div><br></div><div><font face="Lucida Grande, Lucida Sans Unicode, Arial, Verdana, Helvetica, sans-serif">Our C++03 users are all using Clang. They must be.</font><span style="font-family:"Lucida Grande","Lucida Sans Unicode",Arial,Verdana,Helvetica,sans-serif">  Less than 9% of the C++03 tests pass with GCC [1][2]. No non-trivial C++ program could work.</span><br></div><div><br></div><div><span style="font-family:"Lucida Grande","Lucida Sans Unicode",Arial,Verdana,Helvetica,sans-serif">Attempting to support G++03 impacts our QoI considerably. Unlike Clang, G++03 offers almost no C++11 extensions. If we could remove all the fallbacks for G++03, it would mean libc++ could::</span></div><div><span style="font-family:"Lucida Grande","Lucida Sans Unicode",Arial,Verdana,Helvetica,sans-serif"><br></span></div><div><div>* Improve Correctness:</div></div><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div>Every `#ifdef _LIBCPP_HAS_NO_<C++11-feature>` is a bug manifest. It exists to admit for deviant semantics.</div></div><div><br></div></blockquote><div><div>* Achieve ABI stability between C++03 and C++11</div></div><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div>Differences between our C++03 and C++Rest branches contain ABI bugs. For example `std::nullptr_t` and `std::function::operator()(...)` are currently incompatible between C++11 and C++03, but could be fixed.</div></div></blockquote></div></div></div></div></div></div></div></div></div></div></div></div></blockquote><div><br></div><div><br></div><div>Would we break ABI of C++03 using clang as a compiler? Would we only do so for STL features which aren’t actually part of C++03 anyways?</div><div><br></div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail-m_-1720169299865068893gmail-gs" style="margin:0px;padding:0px 0px 20px;width:1264px;font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-size:inherit"><div class="gmail-m_-1720169299865068893gmail-"><div id="gmail-m_-1720169299865068893gmail-:178" class="gmail-m_-1720169299865068893gmail-gt gmail-m_-1720169299865068893gmail-ii" style="font-size:12.8px;direction:ltr;margin:8px 0px 0px;padding:0px"><div id="gmail-m_-1720169299865068893gmail-:177" class="gmail-m_-1720169299865068893gmail-a3s gmail-m_-1720169299865068893gmail-aXjCH" style="overflow:hidden;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:small;line-height:1.5;font-family:Arial,Helvetica,sans-serif"><div dir="ltr"><div class="gmail-m_-1720169299865068893gmail-gs" style="margin:0px;padding:0px 0px 20px;width:1272px;font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-size:12px"><div class="gmail-m_-1720169299865068893gmail-"><div id="gmail-m_-1720169299865068893gmail-:11u" class="gmail-m_-1720169299865068893gmail-gt gmail-m_-1720169299865068893gmail-ii" style="font-size:12.8px;direction:ltr;margin:8px 0px 0px;padding:0px"><div id="gmail-m_-1720169299865068893gmail-:11v" class="gmail-m_-1720169299865068893gmail-a3s gmail-m_-1720169299865068893gmail-aXjCH" style="overflow:hidden;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:small;line-height:1.5;font-family:Arial,Helvetica,sans-serif"><div dir="ltr">* Decrease Compile Times and Memory Usage:<div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><br></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">Writing efficient SFINAE requires C++11. Using alias templates, libc++ could reduce the number of instantiations it produces substantially.<br><br></blockquote>* Decrease Binary Size</div><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><br></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>Similar to the last point, G++03 forces metaprogramming techniques that emit more debug information [3] [4]. Compared to libstdc++, debug information size increases of +10% are not uncommon.</div></blockquote><br></div><div>I would like the communities blessing to officially unsupport GCC in C++03 in the 9.0 release.</div><div><br></div><div>/Eric</div><div><div><div><div><br></div><div>[1] <a href="https://gist.github.com/EricWF/83b352471c999655859f75f60c9061a8" target="_blank">https://gist.github.com/EricWF/83b352471c999655859f75f60c9061a8</a></div></div></div></div><div>[2] Clang and GCC are our only "supported" C++03 compilers. MSVC and XLC don't support C++03, we don't support ILC.</div><div>[3] G++03 disallows default template parameters, so SFINAE must be written as default function parameters. Function parameters create live variables, live variables force debug info emission for their type, which emits debug information for the SFINAE construct.</div><div>[4] Unlike C++03 metafunctions written with normal class templates, C++11 alias templates aren't instantiated at every use.</div></div><div class="gmail-m_-1720169299865068893gmail-yj6qo"></div><div class="gmail-m_-1720169299865068893gmail-adL"></div></div></div><div class="gmail-m_-1720169299865068893gmail-hi" style="border-bottom-left-radius:1px;border-bottom-right-radius:1px;padding:0px;width:auto;background:rgb(242,242,242);margin:0px"></div></div></div><br><br class="gmail-m_-1720169299865068893gmail-Apple-interchange-newline"></div></div></div></div></div></div>
_______________________________________________<br>libcxx-dev mailing list<br><a href="mailto:libcxx-dev@lists.llvm.org" target="_blank">libcxx-dev@lists.llvm.org</a><br><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev</a><br></div></blockquote></div><br></div></blockquote></div>