https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107729
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 seems 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
void f() {
decltype(&F_::operator()) p;
__asm__ __volatile__("__compnerd_was_here__" : [output] "=r" (p) : [input]
"r" (&F_::operator()));
}
auto L = [](){};
template void f();
```
When built with (x86_64) `-momit-leaf-frame-pointer -std=c++11 -g0
-fno-exceptions -fno-unwind-tables` the interesting (undecorated) output is:
```asm
void f():
.LFB4:
movl$L::{lambda()#1}::operator()() const, %eax; note truncation
of `ptr`
movl$0, %edx ; note truncation
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 pointer
truncation:
```asm
void f():
.LFB4:
movqL::{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 destructure
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 constraint
for a PMF is unreasonable as per the ABI. I don't think that there is a good
reason to permit that in the first place, but definitely not with the inability
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.
