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 D93983857C4B; Tue, 13 Feb 2024 19:43:02 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D93983857C4B
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1707853382;
	bh=25UcieRbkd6GvHVLOOIonf2oEs6o0tGbnHA/z7uHQqU=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=fDCgxK301yJRxY6l1x6j2YqKGEmFlAR69/MUCegUfzm/XXImOYLU+6pUJsr1/d65T
	 dfM0/yt/lDNJMWn1+G2a+3nm1S3cIsXq9mfOVwCXaTm4zN+9f1FNVGo6O4OWjQgVTm
	 8FkSVueKY3xqiJFpmmH8aDQfhcX5HUojVNrHkSa8=
From: "jens.gustedt at inria dot fr" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/113887] no support for %w128 length modifiers
Date: Tue, 13 Feb 2024 19:43:01 +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: 14.0
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jens.gustedt at inria dot fr
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-113887-4-oVuTMy8h21@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-113887-4@http.gcc.gnu.org/bugzilla/>
References: <bug-113887-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=3D113887

--- Comment #6 from Jens Gustedt <jens.gustedt at inria dot fr> ---
(In reply to Joseph S. Myers from comment #5)
> Compiler and library are not in practice independent for this issue ...

For this particular issue they are indeed independent. As said, I have proo=
f of
concept that it works with patches for musl, only gcc is whining because it
doesn't understand the `w128` flag. Otherwise, it is fully functional.

Again, I am not asking that gcc implements full support for the `int128_t` =
type
alias. I am only asking that `w128` is recognized if and only if the compil=
er
has `__int128` and if so, does the right diagnosis for the argument type. A=
nd
this has nothing to do with free standing, only with hosted environments.

This is not enabling `int128_t` but enabling C libraries to provide `int128=
_t`
on top of `__int128` if they are able to fill in the gaps.

And indeed, once there is `_BitInt(128)` in the compiler and then the libra=
ry
provides the `w128` an `wf128` flags, everything is indeed easily filled. F=
or
freestanding which doesn't need <stdio.h> things are even simpler, they only
need `_BitInt(128)` to provide the `.._C` macros if they know that they have
`__int128`.=