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 D18A1382EF3D; Wed, 16 Nov 2022 22:23:05 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D18A1382EF3D
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1668637385;
	bh=lJjX28dvmMH5/Ey366HWaYhRjpgAmZhXu2K2MCZjfLM=;
	h=From:To:Subject:Date:From;
	b=OhiWQ4hp2hnQESYa1usBmk02Pe4wc95BJQ68gN1c1LF5QBDPByNyGCGaH4TVEDlTc
	 9KhTi4pbFqnaMY7PeQpm25ttOo7vEpEEzl+eZY+iP317ErBIo5yn72YStEOaSGIUGt
	 QkBeUGrJu22ZRK6rzKoygUBmtx4OZmqQw2TdRO8A=
From: "compnerd at compnerd dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/107729] New: unhelpful handling for PMF on Itanium ABI for
 inline asm
Date: Wed, 16 Nov 2022 22:23:05 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: compnerd at compnerd dot 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: bug_id short_desc product version bug_status
 bug_severity priority component assigned_to reporter target_milestone
Message-ID: <bug-107729-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=3D107729

            Bug ID: 107729
           Summary: unhelpful handling for PMF on Itanium ABI for inline
                    asm
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: compnerd at compnerd dot org
  Target Milestone: ---

It seems that the GCC handling for inline assembly with PMF references seem=
s to
generate something would possibly work but is not entirely helpful in all
cases.  The correctness of the code is most-definitely questionable at the =
very
least, if not flat out invalid.

Consider the following:
```c++
template <typename F_>
void f() {
  decltype(&F_::operator()) p;
  __asm__ __volatile__("__compnerd_was_here__" : [output] "=3Dr" (p) : [inp=
ut]
"r" (&F_::operator()));
}

auto L =3D [](){};
template void f<decltype(L)>();
```

When built with (x86_64) `-momit-leaf-frame-pointer -std=3Dc++11 -g0
-fno-exceptions -fno-unwind-tables` the interesting (undecorated) output is:

```asm
void f<L::{lambda()#1}>():
.LFB4:
        movl    $L::{lambda()#1}::operator()() const, %eax    ; note trunca=
tion
of `ptr`
        movl    $0, %edx                                      ; note trunca=
tion
of `adj`
        __compnerd_was_here__
        movq    %rax, -24(%rsp)                               ; `ptr``
        movq    %rdx, -16(%rsp)                               ; `adj`
        nop
        ret
.LFE4:
```

Adding in `-fpic` is slightly helpful as it _does_ happen to avoid the poin=
ter
truncation:

```asm
void f<L::{lambda()#1}>():
.LFB4:
        movq    L::{lambda()#1}::operator()() const@GOTPCREL(%rip), %rcx  ;
note not-truncated `ptr`
        movq    %rcx, %rax                                                ;=
 eh?
        movl    $0, %edx                                                  ;
untruncated `adj`
        __compnerd_was_here__
        movq    %rax, -24(%rsp)                                           ;
`ptr`
        movq    %rdx, -16(%rsp)                                           ;
`adj`
        nop
        ret
.LFE4:
```

The secondary one seems nearly correct, however, at that point a secondary
issue is exposed: the register allocation is irretrievable - your parameters
are `%0` and `%1` (or `%[input]` and `%[output]`.  The inability to destruc=
ture
the input and output as well as being unable to name the register pair makes
this rather unhelpful.

In the particular case, the PMF is a lambda without captures and thus is
reasonable as the adjustment is `0` and thus will happen to work.

There is a secondary question of the code quality itself - `r` as a constra=
int
for a PMF is unreasonable as per the ABI.  I don't think that there is a go=
od
reason to permit that in the first place, but definitely not with the inabi=
lity
to de-structure the parameters.

it is interesting to also note that GCC somehow does manage to de-structure=
 and
re-structure the PMF, which is shockingly impressive.=