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 9D9423857C76; Wed, 26 Aug 2020 18:47:03 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9D9423857C76
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
 s=default; t=1598467623;
 bh=J14ARFyoHlTnZDxqUWdWW8CTWJT0p6CVVJkzxCXBD9o=;
 h=From:To:Subject:Date:In-Reply-To:References:From;
 b=sseE4+xiAvmNROBCeld61gwiwLVc4QK9U4VfdEh1V0otZ+bwfc75BaoOk7vtKK1i2
 b+1ShN7d3oH7XuKXvAagBM+e04oSwKs4RgQlOqP114qY9y8Q7eQermTKIG26YEH2ig
 Ue22D7nJmsJoIIWBIlOc8OEuZ/g5nwcEHdwwa2Ek=
From: "richard-gccbugzilla at metafoo dot co.uk" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/96788] "integer constant is so large that it is unsigned"
 warning is incorrect
Date: Wed, 26 Aug 2020 18:47:03 +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: 11.0
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: richard-gccbugzilla at metafoo dot co.uk
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-96788-4-f8GTskfqpn@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-96788-4@http.gcc.gnu.org/bugzilla/>
References: <bug-96788-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
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Aug 2020 18:47:03 -0000

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

--- Comment #3 from Richard Smith <richard-gccbugzilla at metafoo dot co.uk=
> ---
In the mean time, what is GCC's intent here? Clang is following the behavior
described by GCC's diagnostic text, treating decimal integer literals that
don't fit in 'long long' but do fit in 'unsigned long long' as the latter t=
ype
(I've not checked back far enough to tell if this is what GCC ever actually
did, or if we got this by looking at the diagnostics and didn't check the
behavior). If that's not what GCC intends to do any more, that'd be useful =
for
us to know, and we can switch to following GCC's actual behavior. (It'd also
make sense to update the diagnostic text in that case!)

It looks like both the Clang behavior (treat the literal as 'unsigned long
long') and the GCC behavior (treat the literal as '__int128' where available
and 'long long' otherwise) are conforming extensions in both C and C++, even
though __int128 isn't (yet) an extended integer type: such a literal "has no
type" in C, which presumably results in undefined behavior, and makes the
program ill-formed in C++, so it seems there is room for a vendor extension=
 in
both languages.=