On Wed, 22 Nov 2023 at 14:50, Jonathan Wakely <jwak...@redhat.com> wrote: > > On Mon, 20 Nov 2023 at 02:56, Jason Merrill wrote: > > > > Tested x86_64-pc-linux-gnu. Are the library bits OK? Any comments before I > > push this? > > The library parts are OK. > > The variable template is_trivially_copyable_v just uses > __is_trivially_copyable so should be just as efficient, and the change > to <bit> is fine. > > The variable template is_trivially_destructible_v instantiates the > is_trivially_destructible type trait, which instantiates > __is_destructible_safe and __is_destructible_impl, which is probably > why we used the built-in directly in <variant>. But that's an > acceptable overhead to avoid using the built-in in a mangled context, > and it would be good to optimize the variable template anyway, as a > separate change.
This actually causes a regression: FAIL: 20_util/variant/87619.cc -std=gnu++20 (test for excess errors) FAIL: 20_util/variant/87619.cc -std=gnu++23 (test for excess errors) FAIL: 20_util/variant/87619.cc -std=gnu++26 (test for excess errors) It's OK for C++17 because the changed code is only used for C++20 and later. That test instantiates a very large variant to check that we don't hit our template instantiation depth limit. Using the variable template (which uses the class template) instead of the built-in causes it to fail now. So optimizing the variable template is now a priority.
