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 195FD385800C; Wed, 18 Jan 2023 21:16:20 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 195FD385800C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1674076580;
	bh=36jnHNqC/AvdzsYV+wp/Jasa7cv9MywGhp2+ju2hOU0=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=w8Qdpmye6mB6D8Wg8TqA6AUay5gy1OF2nIvrsNI0sTxEh7FXvLInMgad9082+17lH
	 /wMyeFmWpYRXTLp4LXvkeyJu8viGfvce0RTpx2VxbwAlRMlYqTg7e8+bv2ij0nmveg
	 e6/wMZg9sx9u8in0vV1Ar5OHC4PCXmAPwlxQN6B8=
From: "david.faust at oracle dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/107844] error: argument is not a field access for
 __builtin_preserve_field_info
Date: Wed, 18 Jan 2023 21:16:19 +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.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: david.faust at oracle dot com
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-107844-4-1XiuhQnQQy@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-107844-4@http.gcc.gnu.org/bugzilla/>
References: <bug-107844-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=3D107844

--- Comment #5 from David Faust <david.faust at oracle dot com> ---
(In reply to Andrew Pinski from comment #4)
> (In reply to David Faust from comment #3)
> > Thanks for the info Andrew. I'll look at __builtin_offsetof.
> >=20
> > As for the implementation in clang, I can point to some bits relevant to
> > the builtin itself:
> > llvm-project/clang/lib/CodeGen/CGBuiltin.cpp
> >   CodeGenFunction::EmitBPFBuiltinExpr ()
> >=20
> > llvm-project/llvm/lib/Target/BPF/BPFAbstractMemberAccess.cpp
> >   BPFAbstractMemberAccess::GetFieldInfo ()
> >=20
> > But I am less familiar with the surrounding machinery such as their
> > parsing and type systems..
>=20
> So I looked (First off I am shocked they don't have target functions to
> handle the builtins and every target builtin is handled in that file seems
> wrong), and you are handed the AST before folding. This is different from
> GCC where it is you are handed it after folding.

Aha! I had never realized this difference until now. Thanks for pointing
that out!

>=20
> So I think we need some special handling in the c (and C++) parser to han=
dle
> this. I suspect we want to do the full handling of the builtin
> (bpf_core_field_exists) in the parser rather than the macro expanded view=
 of
> it too. Similar to how offsetof is handled ...
> Of course this will need some modifications to the bpf headers too. And t=
hat
> solves some other issues too.

Yes, I see. I'll have to study the parser a little since I have not touched
it before, but the approach makes sense.

I wonder if it would be feasible and/or worthwhile to add some sort of
TARGET_PARSE_BUILTIN hook to enable this sort of handling for any other
targets which may want it..? Maybe that can wait.

In any case, thank you very much for the suggestions.=