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 99DBE3858438; Wed, 21 Feb 2024 09:56:48 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 99DBE3858438
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1708509408;
	bh=esKHN3NoeK+q7CcVAUCK3HerHnOwXutTAj/x9IrTf6s=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=MMb9eXM+jmtz4eIEnN1pf82/OsX1bSnmdvk/OtrJbltzRu5rFIjz6a8R/MrtQFOjJ
	 zakkgCFvV3TAwODEvIbMZo/YNekp+sKayv4LVrC4TT7/kR1eGFxgUrgpsxsv0B4bey
	 3NoN46nqYSgzoeD7JPn3vfwWD+GD3QiQ3JXSLtY4=
From: "ro at CeBiTec dot Uni-Bielefeld.DE" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/113450] [14 Regression]
 std/format/functions/format.cc FAILs
Date: Wed, 21 Feb 2024 09:56:47 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 14.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ro at CeBiTec dot Uni-Bielefeld.DE
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: FIXED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 14.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-113450-4-nIG9bDQGRQ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-113450-4@http.gcc.gnu.org/bugzilla/>
References: <bug-113450-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=3D113450

--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot =
Uni-Bielefeld.DE> ---
> --- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot
> Uni-Bielefeld.DE> ---
>> --- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
>> (In reply to Jonathan Wakely from comment #1)
>>> I assume that int8_t is char on Solaris, rather than signed char?
>>
>> This actually violates the C and C++ standards, which require that intN_=
t is a
>> signed integer type, and C 6.2.5 says "There are five standard signed in=
teger
>> types, designated as signed char, short int, int, long int, and long lon=
g int."
>> So char isn't allowed, it should be signed char.
>
> I've done some digging now: <inttypes.h>/<sys/int_types.h> were
> introduced into Solaris 2.6 (the file dates from Jul 16 1997), way
> before the C99 standard was finalized.

Further research has uncovered some interesting facts:

* Neither the SysV SPARC psABI (3rd Edition, 1996) nor the original i386
  psABI (4th Edition, 1997) specify int8_t at all.  Actually no wonder
  because both predate C99.

  However, even the current Intel386 psABI 1.1 (2015) has nothing here,
  nor does the AMD64 psABI 1.0 (2024).

  To my astonishment however, the SPARC Compliance Definition 2.4.1
  (1999), defacto if not in name the SPARC V9 psABI, lists in Figure
  6-140: <inttypes.h>, p.6P-13:

  typedef signed char int8_t;

  So it seems at least Solaris/SPARCV9 violates its own ABI ;-(

* When checking clang, there were more surprises:

#define __INT8_TYPE__ signed char

  With very few exceptions, clang uses the default definitions of the
  intN_t types everywhere.

  However, the question remains how much that counts: given clang/llvm
  has seen years of neglect on Solaris, I wonder how much actual code is
  really built with it on Solaris.

* The Oracle Studio 12.6 cc has no definition of __INT8_TYPE__ at all
  AFAICT.  If that's true, one could change the type's definition simply
  by adjusting <sys/int_types.h>, which would be nice and easy.=