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 EB63A3858407; Wed,  7 Feb 2024 10:55:33 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EB63A3858407
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1707303333;
	bh=3urb1iFOykeG9c3iB654tS1+d/ejr579RuEWAGgOl8E=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=Oik8ZDKvgVtGanAP1Dk+lsGC44YULmgZIqZDjdYdpjy1c9K8zjxihmF2MDVv12f2x
	 w0GTUSuj2TDRIXgxWy+mWJyBd/sCko7cXiIc876tZxlQPAnUim/qaj7k4fqykCWviL
	 pDgqplqe0wuu+9W2mBOhgzqV1qGviRqfL89wjj70=
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/87744] Some valid instantiations of
 linear_congruential_engine produce compiler errors when __int128 isn't
 available
Date: Wed, 07 Feb 2024 10:55:32 +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: 7.3.0
X-Bugzilla-Keywords: rejects-valid
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi at gcc dot gnu.org
X-Bugzilla-Status: NEW
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-87744-4-5taSUi8zWn@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-87744-4@http.gcc.gnu.org/bugzilla/>
References: <bug-87744-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=3D87744

--- Comment #14 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Lewis Fox from comment #12)
> (In reply to Jonathan Wakely from comment #2)
>=20
> My original comment about libc++ was in reference to the LLVM bugzilla
> report #27839: https://bugs.llvm.org/show_bug.cgi?id=3D27839

Thanks, that got copied to github as
https://github.com/llvm/llvm-project/issues/28213

> It looks like the issue you discovered is LLVM bugzilla report #34206:
> https://bugs.llvm.org/show_bug.cgi?id=3D34206

And that is now https://github.com/llvm/llvm-project/issues/33554

> It seems like since I made that comment here, libc++ has updated to fix t=
he
> misuse of Schrage's algorithm (though, looking at the current source code,
> it still looks wrong to me), so it does mean my initial comment is a litt=
le
> out of date.

Unsurprising when it took me more than 5 years to look into it properly ;-)

> This is a bit of an edge case that I don't think most users will encounte=
r,
> so performance is probably less important here than accuracy.

100% agreed

> I'd personally
> prioritize minimizing branches (i.e. improving simplicity) than optimizing
> the operand sizes for performance, but that's just my opinion.

Agreed again, for although as I said in comment 13 I think the extra branch=
 in
operator% might be worthwhile. Maybe with __builtin_expect(__l._M_hi =3D=3D=
 0, 0))
as a branch prediction hint.=