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 3F59D3858D33; Thu, 28 Mar 2024 21:06:37 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3F59D3858D33
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1711659997;
	bh=Gj8jSn+ddfEHI8WGVACaCZ71pqJjlLFlqrcQM6BbGmM=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=c+FNzitDlr0TY1lpzIjxjJC12HBLDL/D2s5PHjXKViX+5avRGXkr/QGDCB97NooyZ
	 juvFF2i5rLaGnDgW4i2D2Sl/I+OuMOaiPj9oXL97rwAoJobvuKBzRnEj+NYaAmt0QB
	 v2phIhcYyRwmqNsX2dzGekFJ3TKVzTfmOhikqWlg=
From: "jemarch at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/114523] bpf: unverifable code due to subreg usage
Date: Thu, 28 Mar 2024 21:06:36 +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: 14.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jemarch 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-114523-4-CDsfEp8Las@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-114523-4@http.gcc.gnu.org/bugzilla/>
References: <bug-114523-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=3D114523

--- Comment #13 from Jose E. Marchesi <jemarch at gcc dot gnu.org> ---
Thanks.  The new title is way better.  And thank you for the further analys=
is
and the reproducer that also makes clang to generate the no-verifiable code!

I wonder, is the issue also there when -mno-alu32 is used?  In that case the
generated code doesn't involve "subregs" (or 32-bit operations in assembly-=
like
syntax):

        .file   "foo.c"
        .text
        .align  3
        .global foo
        .type   foo, @function
foo:
        call    bar
        lddw    %r1,baz
        mov     %r0,%r0
        and     %r0,0xffffffff
        ldxw    %r2,[%r1+0]
        add     %r0,-1
        neg     %r2
        xor     %r0,%r2
        rsh     %r0,63
        exit
        .size   foo, .-foo
        .global baz
        .type   baz, @object
        .lcomm  baz,4,4
        .ident  "GCC: (GNU) 14.0.1 20240226 (experimental)"

Cuper, is the verifier able to track proper values through the xor in this
case?=