On 9/14/20 7:17 PM, Marek Polacek via Gcc-patches wrote: > On Mon, Sep 14, 2020 at 11:13:18AM -0400, Jason Merrill via Gcc-patches wrote: >> On Mon, Jun 29, 2020 at 1:25 PM Martin Liška wrote: >>> On 6/29/20 4:57 PM, Marek Polacek wrote: >>>> On Mon, Jun 29, 2020 at 09:51:57AM +0200, Martin Liška wrote: >>>>> On 6/26/20 9:34 PM, Marek Polacek via Gcc-patches wrote: >>>>>> As discussed last month: >>>>>> >>>>>> it's time to change the C++ default to gnu++17. I've committed the patch after >>>>>> testing x86_64-pc-linux-gnu and powerpc64le-unknown-linux-gnu. Brace yourselves! >>>>>> >>>>>> Marek >>>>>> >>>>> Just a small note that 510.parest_r SPEC 2017 benchmark can't be built now >>>>> with default changed to -std=c++17. The spec config needs to be adjusted. >>>> Interesting, do you know why? Does it use the register keyword? >>> Apparently it needs -fno-new-ttp-matching for successful compilation. >>> There's a reduced test-case I made: >>> >>> cat fe.ii >>> template class FiniteElement; >>> template class DoFHandler; >>> class FETools { >>> template >>> void back_interpolate(const DoFHandler &, const InVector &, >>> const FiniteElement &, OutVector &); >>> template class DH, class InVector, class OutVector, >>> int spacedim> >>> void back_interpolate(const DH &, InVector, >>> const FiniteElement &, OutVector); >>> }; >>> template class DoFHandler; >>> template class FiniteElement; >>> template >>> void FETools::back_interpolate(const DoFHandler &, >>> const InVector &, >>> const FiniteElement &, >>> OutVector &) {} >>> template void FETools::back_interpolate(const DoFHandler<3> &, const float &, >>> const FiniteElement<3> &, float &); >> Hmm, looks like I never sent this. >> >> Further reduced: >> >> template class A; >> template void fn(A &) {} >> template class TT> void fn(TT &); >> template void fn(A<3> &); >> >> This breaks due to the C++17 changes to template template parameters >> causing A to now be considered a valid argument for TT; with that >> change both function templates are valid candidates, and neither is >> more specialized than the other, so it's ambiguous. >> >> There are still some open core issues around these changes. > Thanks. I just pushed a patch to introduce GCC 11 porting_to: > and documented this change. > > Let me know if you have any comments. And I just pushed a placeholder into that file for a few other things I've seen during Fedora testing.  I thought I'd pushed my initial gcc-11 porting_to a month or so ago.  Apparently not :( jeff