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 4A3E43853D5C; Wed, 14 Dec 2022 19:20:51 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4A3E43853D5C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1671045651;
	bh=NZjdUopzQtvwwvw8kz4hXpGEfy8q3WhcRgMYGBE1rJ8=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=UaXWWR1OXR8yuGiNwv4HFeSu7qAfGlIl8GlgDdieUboqzV2Lb9EbOIKgikHntlbHF
	 8eHs7+sTc9kghGXKd4Lcj9cn5n4mj5zTiT9+9RltOGBTq+vef2YMfP6B6lrtHf4a3+
	 edU0558/vItnt1BqlzWQKWSJfp9ov75bEc6XA8BQ=
From: "jakub 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: Wed, 14 Dec 2022 19:20:50 +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: jakub at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 11.4
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-108099-4-EjkdR23W94@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 #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Another question is what with this tolerated extension happens when the typ=
edef
is unsigned.

// PR c++/108099
// { dg-do compile { target c++11 } }
// { dg-options "" }

typedef unsigned long long t64;
using u64 =3D unsigned t64;
using s64 =3D signed t64;
template <typename T, T v> struct integral_constant {
  static constexpr T value =3D v;
};
typedef integral_constant <bool, false> false_type;
typedef integral_constant <bool, true> true_type;
template <class T, class U>
struct is_same : false_type {};
template <class T>
struct is_same <T, T> : true_type {};
static_assert (is_same <long long, s64>::value, "");
static_assert (is_same <signed long long, s64>::value, "");
static_assert (is_same <unsigned long long, u64>::value, "");
static_assert (sizeof (s64) =3D=3D sizeof (long long), "");
static_assert (sizeof (u64) =3D=3D sizeof (unsigned long long), "");
static_assert (s64(-1) < 0, "");
static_assert (u64(-1) > 0, "");

shows 3 assertion failures, the 2 s64 is_same ones and s64(-1) < 0, so s64
was actually unsigned despite the signed keyword.
Trunk with the above patch shows 5 assertion failures, all 3 is_same, sizeof
(u64) and s64(-1) < 0.
If we don't want to error right away, either we should keep the gcc 11 and
earlier weirdo behavior, or better fix it such that with signed keyword and
unsigned typedef
we actually get corresponding unsigned type.  But in neither case using just
int/unsigned int if the type is wider or narrower.=