From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 995FC3858C41; Mon, 28 Aug 2023 15:26:23 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 995FC3858C41 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1693236383; bh=ViQIvANRUEYOWAY6gCnhY6o8wkPLpAekTtf6lSTADR4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=APUCul+AXA+QLKoaJEw3RQ8tMXWRlS+uZ4E4rDFTxmUAYRAm2UioSLdkQN9KgwsQk bWcJAveiy3PPLGD+n+/j++Qb+Mf7GUJeHSIsHHqMoxYLUi1OgwRf/Iw6JJ3c8qnEVM gx4kDWa2yaEdoGTtLvduGYfDO/KCdVm0xsvfQ0p8= From: "ubizjak at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc Date: Mon, 28 Aug 2023 15:26:23 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 13.2.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: ubizjak at gmail dot com X-Bugzilla-Status: WAITING X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 13.3 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: 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: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D111165 Uro=C5=A1 Bizjak changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hjl.tools at gmail dot com --- Comment #14 from Uro=C5=A1 Bizjak --- (In reply to Thorsten Glaser from comment #13) > The interesting part is around the occurrence of=E2=80=A6 >=20 > # eval.c:399: sp =3D cstrchr(sp, '\0') + 1; >=20 > =E2=80=A6 in the .s files (it occurs thrice, the first is the beginning o= f the setup > part, the second and third surround the strlen call, so they=E2=80=99re a= ll within a > bunch of lines). Unfortunately, the runtime bug requires test that fails at runtime; the attached dumps are not that usable. The fact that the compiler fails for no= t so common target makes things even harder. I think that the best way forward is to create a minimized standalone testc= ase (From Comment #11 it looks that the issue is independent of dietlibc) that = can be compiled with -mx32 in a kind of cross-compiler fashion. You can use -maddress-mode=3Dlong with -mx32 to create a .s assembly file that is compa= tible with x86_64, as far as stack handling is concerned. The resulting .s assembly can then be compiled and linked with a C wrapper,= so a testcase that eventually fails on x86_64 can be produced. IOW, does the testcase fail when -maddress-mode=3Dlong is used?=