https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86588
Bug ID: 86588 Summary: peculiar build issue using range-v3 Product: gcc Version: 7.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: h2+bugs at fsfe dot org Target Milestone: --- I have attached a code sample below and will provide an intermediate file that shows that various forms of initialisation fail to build, while equivalent (at least some) pass [all that are commented out fail, the last two are the only that pass]. Since range-v3 pulls in a large amount of code the intermediate files are quite large and I have as of yet been unsuccessful in reducing this to something that still fails, but I hope someone with more expertise can track the compiler while it tries/fails to deduce the type. tested versions: g++7 (FreeBSD Ports Collection) 7.3.1 20180712 g++8 (FreeBSD Ports Collection) 8.1.1 20180713 For reference also the issue at range-v3: https://github.com/ericniebler/range-v3/issues/860 std::string vec{"foo\nbar"}; seqan3::detail::view_take_line v1(ranges::view::all(vec)); assert("foo" == std::string(v1)); assert(ranges::BidirectionalRange<decltype(v1)>()); assert(ranges::View<decltype(v1)>()); // auto v2 = v1 | ranges::view::reverse; // #1 // auto v2 = ranges::reverse_view<decltype(v1)>{v1}; // #2 using t = ranges::reverse_view<decltype(v1)>; // auto v2 = t(v1); // #3 // auto v2 = t{v1}; // #3b // t v2 = t(v1); // #4 // t v2 = t{v1}; // #4b // t v2 = v1; // #5 t v2(v1); // #6 t v3{v1}; // #6b assert("oof" == std::string(v2));