On Mon, Nov 10, 2025 at 03:48:01PM +0530, Jason Merrill wrote: > On 11/10/25 12:06 PM, Jakub Jelinek wrote: > > Trivial relocation was voted out of C++26, the following patch > > removes it (note, the libstdc++ part was still waiting for patch review > > and so doesn't need to be removed). > > > > This isn't a mere revert of r16-2206; I've kept -Wc++26-compat option, > > from earlier patches the non-terminal stays to be class-property-specifier, > > and I had to partially revert also various follow-up changes, e.g. for > > modules to handle the new flags and test them, for -Wkeyword-macro > > etc. to diagnose the conditional keywords or the feature test macro > > etc. > > > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? > > I think I would prefer to just remove it from -std=c++26, it's expected to > come back in C++29. Maybe give it a -ftrivial-relocation for now?
Is it worth that though, especially because it is incomplete, as opposed to just starting from the revert commit again when something is agreed for C++29? The point is that the libstdc++ part has not been reviewed ( https://gcc.gnu.org/pipermail/libstdc++/2025-September/063523.html is the latest version), so all we have on the compiler side is: 1) __cpp_trivial_relocation predefined macro 2) parsing the {trivially_relocatable,replaceable}_if_eligible conditional keywords for C++26 3) parsing the __{trivially_relocatable,replaceable}_if_eligible conditional keywords 4) the builtin traits (__builtin_is_*) So, users can use the keywords but I think we don't want to encourage them to use the __builtin_is_* functions directly. I think at least 2) shouldn't be done for -std=c++26 (or if we really want -ftrivial-relocation), similarly the pedantic -Wkeyword-macro etc. stuff. Jakub
