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 E29263858C66; Wed, 26 Jul 2023 05:11:43 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E29263858C66
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1690348303;
	bh=AXFI/Mobc8/mpdB27d80HxeMzSKNdpLTkcuIrpLpQv4=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=XU5kSeeR5vcKNKS0Ho5R/E7b9HMDV5blmKqceLKVVGK+9Wi0QJJsd9NQ41ca2q2TE
	 Q6hzqTvHGQjyenoOQY+1MmWG2TSihkt/cvi817skLDp3Rt77TtKlAVqSVHT3njE2y9
	 mG8Wbz6m5TFJDHatpRdvozxEX3HTO+YYVCR4g458=
From: "13958014620 at 139 dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: =?UTF-8?B?W0J1ZyBjKysvMTEwNzk4XSBbMTIgUmVncmVzc2lvbl0gVGhlIHJl?=
 =?UTF-8?B?dXN1bHQgb2Ygc2l6ZW9mIG9wZXJhdG9yIGZvbGxvd2VkIHdpdGggYW4gJ3Vu?=
 =?UTF-8?B?c2lnbmVkIHR5cGVkZWYtZWQgZ2VuZXJpYyBpbnRlZ2VyJyB0eXBlIGlzIGFs?=
 =?UTF-8?B?d2F5IDQgYnl0ZXPvvIhleGNlcHQgY2hhcu+8iQ==?=
Date: Wed, 26 Jul 2023 05:11:43 +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.3.1
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: 13958014620 at 139 dot com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: DUPLICATE
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 12.4
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-110798-4-PA2burKdTe@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-110798-4@http.gcc.gnu.org/bugzilla/>
References: <bug-110798-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=3D110798

--- Comment #5 from miles <13958014620 at 139 dot com> ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to Andrew Pinski from comment #1)
> > I almost positive this was fixed by r14-159-g03cebd304955a6 which was
> > backported to GCC 13 branch r13-7277-ga713aa4f47ac1e (for 13.2.0) .
>=20
> Yes, bisection confirms it. So this is a dup.
>=20
> Aside: I'm not sure I'd call this a wrong-code bug. The testcase would be
> simpler if it used static_assert instead of assert, which would make it
> accepts-invalid / rejects-valid instead.
>=20
> *** This bug has been marked as a duplicate of bug 108099 ***


> Aside: I'm not sure I'd call this a wrong-code bug.
Yep, the "unsigned" keyword qualifies an typedef-ed type is illegal accordi=
ng
to ISO_14882. It's acceptable that the compiler reports a failure, at least=
 a
warning.

>The testcase would be simpler if it used static_assert instead of assert, =
which would make itaccepts-invalid / rejects-valid instead.
Thanks a lot for your suggestion!

The experience of discovering this issue is very interesting.
I wrote a macro function to show the attributes of fundamental type for my =
son,
he's currently learning c++ language.

#define PRINT_TYPE_ATTRIBUTES(T)  \
    cout << "typeid(" << O_YELLOW(#T) << ").name(): " <<
O_RED(typeid(T).name()) <<endl \
    << "    demangling name: " << O_GREEN(abi::__cxa_demangle(typeid(T).nam=
e(),
0, 0, &status))<< endl \
    << "    sizeof(" << #T << "): " << O_BLUE(sizeof(T) << " bytes")<< endl=
 \
    << "    sizeof( unsigned " << #T << "): " << O_BLUE(sizeof(unsigned T) =
<< "
bytes")<< endl;

PRINT_TYPE_ATTRIBUTES(char);
PRINT_TYPE_ATTRIBUTES(int);
PRINT_TYPE_ATTRIBUTES(long);

these statements worked correctly;

my son puts uint8_t and uint64_t into the macro function. At first I though=
t he
would make a mistake ,but the compiler passed and the results are both 4. I=
t's
confusing to us. I don't know how to explain to him at that time.

That's the whole story :)=