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 6DA45385E021; Fri, 21 Jul 2023 23:53:48 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6DA45385E021
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1689983628;
	bh=BOHMv2i+O62Jpbjm0zOFE6pkOEXBz1HC+pxsSSM0e1A=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=mGUP/zpLYlnaSWa1D6IkShmzpG+1bL+D4IkbrrdA5OAvDGuwnTuvEoGNpp2ejXwFp
	 llDXSBDTApygGQfqmH8+NN0yFVbJAmNZBeBj4BLiWz7msyTXHl8TZZtuqI5x7lQxno
	 0kDIa3Lw+GsVZAj5O0sxRK6+JXUh5lE8eeHP6yG0=
From: "pinskia at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/110772] strange code generated for bit-field access
Date: Fri, 21 Jul 2023 23:53:48 +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: 10.5.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: pinskia at gcc dot gnu.org
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-110772-4-PCNQL0Wskx@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-110772-4@http.gcc.gnu.org/bugzilla/>
References: <bug-110772-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=3D110772

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I am trying to understand what you think is wrong here?

lsrs    r3, r3, #7

means logical shift right by 7 and compare against 0.

Also this is big-endian arm so the order of bit fields will be different th=
an
little-endian.

This is extracting one bit from the whole byte.

x86 has an instruction (testb) which does the testing that way.
arm does not.
powerpc does not either.
aarch64 has an instruction too.


I don't see anything wrong with the code generation here at all.=20

Take:
```
struct t
{
  _Bool a0:1;
  _Bool a1:1;
  _Bool a2:1;
  _Bool a3:1;
  _Bool a4:1;
  _Bool a5:1;
  _Bool a6:1;
  _Bool a7:1;
};

int g(); int h();
int f(struct t *a)
{
  if(a->a0) return g();
  return h();
}
int f1(struct t *a)
{
  if(a->a7) return g();
  return h();
}
int f2(_Bool *a)
{
  if(*a) return g();
  return h();
}
```

I don't see anything wrong with the above code generation for either arm or
x86_64 (or powerpc).=