https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108099
--- Comment #30 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The releases/gcc-12 branch has been updated by Jason Merrill <ja...@gcc.gnu.org>: https://gcc.gnu.org/g:50812881bbc1a78552682ae3a690bc0f512e762f commit r12-9810-g50812881bbc1a78552682ae3a690bc0f512e762f Author: Jason Merrill <ja...@redhat.com> Date: Tue Apr 18 21:32:07 2023 -0400 c++: fix 'unsigned typedef-name' extension [PR108099] In the comments for PR108099 Jakub provided some testcases that demonstrated that even before the regression noted in the patch we were getting the semantics of this extension wrong: in the unsigned case we weren't producing the corresponding standard unsigned type but another distinct one of the same size, and in the signed case we were just dropping it on the floor and not actually returning a signed type at all. The former issue is fixed by using c_common_signed_or_unsigned_type instead of unsigned_type_for, and the latter issue by adding a (signed_p && typedef_decl) case. This patch introduces a failure on std/ranges/iota/max_size_type.cc due to the latter issue, since the testcase expects 'signed rep_t' to do something sensible, and previously we didn't. Now that we do, it exposes a bug in the __max_diff_type::operator>>= handling of sign extension: when we evaluate -1000 >> 2 in __max_diff_type we keep the MSB set, but leave the second-most-significant bit cleared. PR c++/108099 gcc/cp/ChangeLog: * decl.cc (grokdeclarator): Don't clear typedef_decl after 'unsigned typedef' pedwarn. Use c_common_signed_or_unsigned_type. Also handle 'signed typedef'. gcc/testsuite/ChangeLog: * g++.dg/ext/int128-7.C: New test. * g++.dg/ext/int128-8.C: New test. * g++.dg/ext/unsigned-typedef2.C: New test. * g++.dg/ext/unsigned-typedef3.C: New test.
