From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id E560A3854144; Tue,  2 May 2023 20:25:52 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E560A3854144
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1683059152;
	bh=c0l4leYSABrzRN3acQWp+AhPi8PROdb6IATdPZjWE34=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=c58VxLWSbgBPQKItzYKfcgTlcnWzzMSftqQLMyRin7G4i6o9gvRVQtRCBKRlvUPG+
	 aozQjI9Kt27t+2TCiKTfD0zaS9Cj8d2W192xVhYQbhLBj99zqWCDvesLFRdiGB//Yu
	 E13g07xSj91H8yvOEmJCSfqmaTu1rK8rA6BHjYZ0=
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/108099] [12/13 Regression] ICE with type alias with `signed
 __int128_t`
Date: Tue, 02 May 2023 20:25:52 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 12.2.0
X-Bugzilla-Keywords: ice-on-invalid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: cvs-commit at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: jason at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 12.3
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-108099-4-SZnPbiZwA3@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-108099-4@http.gcc.gnu.org/bugzilla/>
References: <bug-108099-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108099

--- Comment #27 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Jason Merrill
<jason@gcc.gnu.org>:

https://gcc.gnu.org/g:a713aa4f47ac1efbfe2338790b0b5e94a233fb99

commit r13-7277-ga713aa4f47ac1efbfe2338790b0b5e94a233fb99
Author: Jason Merrill <jason@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 ins=
tead
    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 somet=
hing
    sensible, and previously we didn't.  Now that we do, it exposes a bug in
the
    __max_diff_type::operator>>=3D handling of sign extension: when we eval=
uate
    -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-8.C: New test.
            * g++.dg/ext/unsigned-typedef2.C: New test.
            * g++.dg/ext/unsigned-typedef3.C: New test.=