public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
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:05:29 +0000	[thread overview]
Message-ID: <bug-108099-4-cH0IPPXZjt@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-108099-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Though, on
// PR c++/108099
// { dg-do compile { target c++11 } }
// { dg-options "" }

using u128 = unsigned __int128_t;
using s128 = signed __int128_t;
template <typename T, T v> struct integral_constant {
  static constexpr T value = 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 <__int128, s128>::value, "");
static_assert (is_same <signed __int128, s128>::value, "");
static_assert (is_same <__int128_t, s128>::value, "");
static_assert (is_same <unsigned __int128, u128>::value, "");
static_assert (is_same <__uint128_t, u128>::value, "");
static_assert (sizeof (s128) == sizeof (__int128), "");
static_assert (sizeof (u128) == sizeof (unsigned __int128), "");
static_assert (s128(-1) < 0, "");
static_assert (u128(-1) > 0, "");

in GCC 11 2 assertions failed (is_same with u128), while in trunk with the
above patch 3 assertions fail (also the
sizeof (u128) - u128 is then unsigned int rather than unsigned __int128.
No idea what we want for the is_same assertions, but I bet if we just pedwarn
on unsigned __int128_t and don't reject it, users would expect at least some
128-bit unsigned type.

Though, even on:
// PR c++/108099
// { dg-do compile { target c++11 } }
// { dg-options "" }

typedef long long t64;
using u64 = unsigned t64;
using s64 = signed t64;
template <typename T, T v> struct integral_constant {
  static constexpr T value = 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) == sizeof (long long), "");
static_assert (sizeof (u64) == sizeof (unsigned long long), "");
static_assert (s64(-1) < 0, "");
static_assert (u64(-1) > 0, "");

in GCC 11 only one assertion failed (is_same for u64), while in GCC 12 and
unpatched or patched trunk
2 of them fail (also the sizeof (u64) one).
So, it seems the r12-8173 change behavior not just for the builtin types, but
also for any other typedefs
(in the unsigned case).

  parent reply	other threads:[~2022-12-14 19:05 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-14 11:52 [Bug c++/108099] New: ICE when parsing signed __int128_t typedef moritz.klammler at cetitec dot com
2022-12-14 12:20 ` [Bug c++/108099] " redi at gcc dot gnu.org
2022-12-14 12:23 ` redi at gcc dot gnu.org
2022-12-14 12:26 ` redi at gcc dot gnu.org
2022-12-14 13:12 ` moritz.klammler at cetitec dot com
2022-12-14 17:46 ` [Bug c++/108099] ICE with type alias with `signed __int_128_t` pinskia at gcc dot gnu.org
2022-12-14 17:54 ` [Bug c++/108099] ICE with type alias with `signed __int128_t` pinskia at gcc dot gnu.org
2022-12-14 17:58 ` [Bug c++/108099] [12/13 Regression] " pinskia at gcc dot gnu.org
2022-12-14 18:18 ` jakub at gcc dot gnu.org
2022-12-14 19:05 ` jakub at gcc dot gnu.org [this message]
2022-12-14 19:20 ` jakub at gcc dot gnu.org
2022-12-21 12:37 ` rguenth at gcc dot gnu.org
2022-12-21 18:14 ` ville.voutilainen at gmail dot com
2023-01-31 16:00 ` pinskia at gcc dot gnu.org
2023-02-01  0:51 ` pinskia at gcc dot gnu.org
2023-02-01 11:59 ` redi at gcc dot gnu.org
2023-02-01 19:07 ` pinskia at gcc dot gnu.org
2023-02-01 19:17 ` jakub at gcc dot gnu.org
2023-03-09 22:25 ` jason at gcc dot gnu.org
2023-03-10  3:57 ` cvs-commit at gcc dot gnu.org
2023-03-10  3:59 ` [Bug c++/108099] [12 " jason at gcc dot gnu.org
2023-03-10 10:33 ` jakub at gcc dot gnu.org
2023-04-18 20:45 ` cvs-commit at gcc dot gnu.org
2023-04-19 15:23 ` cvs-commit at gcc dot gnu.org
2023-04-19 16:53 ` cvs-commit at gcc dot gnu.org
2023-04-19 16:59 ` [Bug c++/108099] [12/13/14 " jason at gcc dot gnu.org
2023-04-20  7:44 ` cvs-commit at gcc dot gnu.org
2023-04-20  7:48 ` cvs-commit at gcc dot gnu.org
2023-04-21 19:33 ` cvs-commit at gcc dot gnu.org
2023-05-02 20:25 ` [Bug c++/108099] [12/13 " cvs-commit at gcc dot gnu.org
2023-05-08 12:26 ` rguenth at gcc dot gnu.org
2023-07-25 10:50 ` [Bug c++/108099] [12 " redi at gcc dot gnu.org
2023-08-11 21:21 ` cvs-commit at gcc dot gnu.org
2023-12-19 21:50 ` jason at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-108099-4-cH0IPPXZjt@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).