public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
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 [thread overview] Message-ID: <bug-107729-4@http.gcc.gnu.org/bugzilla/> (raw) 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 <typename F_> void f() { decltype(&F_::operator()) p; __asm__ __volatile__("__compnerd_was_here__" : [output] "=r" (p) : [input] "r" (&F_::operator())); } auto L = [](){}; template void f<decltype(L)>(); ``` 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<L::{lambda()#1}>(): .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<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 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.
next reply other threads:[~2022-11-16 22:23 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-11-16 22:23 compnerd at compnerd dot org [this message] 2022-11-16 22:27 ` [Bug c++/107729] " pinskia at gcc dot gnu.org 2022-11-16 22:28 ` pinskia at gcc dot gnu.org 2022-11-16 22:31 ` compnerd at compnerd dot org 2022-11-16 22:33 ` pinskia at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-107729-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).