public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Anton Staaf <anton@socialhacker.com>
To: Klaus Rudolph <lts-rudolph@gmx.de>
Cc: "Peter Sommerlad (C++)" <peter.cpp@sommerlad.ch>,
	"gcc-help@gcc.gnu.org" <gcc-help@gcc.gnu.org>,
	avr-gcc-list@nongnu.org
Subject: Re: static class member as interrupt handler works, but not if class is templated
Date: Mon, 12 Apr 2021 07:25:55 -0700	[thread overview]
Message-ID: <CAHaghrL1y2ufVwCn8Y_hAynSy+r878Ysx_e6sbFCFwXnDqveJA@mail.gmail.com> (raw)
In-Reply-To: <ee737385-6d00-787e-de33-189bae56920e@gmx.de>

Klaus, I'm not sure if my previous answer didn't make it through or was
just missed, but I believe your problem is related to this GCC bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70435

-Anton


On Mon, Apr 12, 2021 at 5:14 AM Klaus Rudolph <lts-rudolph@gmx.de> wrote:

> Am 12.04.21 um 13:53 schrieb Matthijs Kooijman:
> >>> - figure out, where the special handling of the __vector_10 seems to
> >>> happen, and why it is not happening in the class template case. This
> >>> might help diagnose if and where to fix it within the compiler.
> >>
> >> That is compiler internals... yes, if it is a compiler bug, it is the
> >> way to have a solution. But in that case, it seems to be a generic
> >> problem for gcc as attributes are not assigned to any templated class
> >> member functions. No idea if this is related to the target ( avr ) or
> >> generic for all platforms. But I never did any change inside the
> >> compiler. Any help is welcome!
> >
> > My suspiciou would be that this is a generic gcc problem, where the
> > "asm" attribute is not honoured for template functions. It probably also
> > makes some sense, since a template is intended to be instantiated
> > multiple times, and each instantiation gets a name that is generated
> > based on (I believe) the template arguments passed, so I suspect that
> > the "generate a name for this template instantiation" code doesn't look
> > at the asm attribute.
> >
> > Also note that *if* it would, then each instantiation would use the same
> > name and multiple instanations would result in duplicate symbols. If you
> > would bring this up as a gcc bug, I wouldn't be surprised that it would
> > be closed as wontfix for this reason.
>
> I disagree as a template "always" would be instantiated multiple times.
> And even if it would be, the linker will fire a error message, as it
> sees multiple definitions. So there is no "general" problem in
> "renaming" a templated function. It simply *can* work.
>
> But it looks that not only the "renaming" stuff did not work, all the
> flags are not handled with the templated function. Looks like that the
> asm declaration did not find its target :-)
>
> >
> > Another workaround that I think hasn't been suggested yet, would be to
> > just define a global `__vector_10` function and from that just call your
> > templated static member.
>
> That is the classical way "we" all work. And it optimizes well in that
> case as the code from the static templated member is fully inlined. But
> it is still a workaround and it simply breaks standard c++ coding. Yes,
> we can write C with classes, but I simply dislike :-)
>
> > Combined with the `always_inline` attribute,
> > you can ensure that the call is inlined and there is no runtime overhead
> > (with LTO, this probably already happens when there's just a single call
> > to the member).
>
> It already optimizes well in O2 if templated member function and free
> handler definition is in same translation unit.
>
> Klaus
>
>
>

  parent reply	other threads:[~2021-04-12 14:26 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-10 13:33 Klaus Rudolph
2021-04-10 15:26 ` Jonathan Wakely
2021-04-10 19:36   ` Trampas Stern
2021-04-10 20:11   ` Klaus
2021-04-11 12:21     ` David Brown
2021-04-11 23:33       ` Trampas Stern
2021-04-12  9:20 ` Peter Sommerlad (C++)
2021-04-12 11:16   ` Klaus Rudolph
2021-04-12 11:53     ` Matthijs Kooijman
2021-04-12 12:12       ` Klaus Rudolph
2021-04-12 13:46         ` David Brown
2021-04-12 14:56           ` Klaus Rudolph
2021-04-12 14:25         ` Anton Staaf [this message]
2021-04-12 15:06           ` Klaus Rudolph

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=CAHaghrL1y2ufVwCn8Y_hAynSy+r878Ysx_e6sbFCFwXnDqveJA@mail.gmail.com \
    --to=anton@socialhacker.com \
    --cc=avr-gcc-list@nongnu.org \
    --cc=gcc-help@gcc.gnu.org \
    --cc=lts-rudolph@gmx.de \
    --cc=peter.cpp@sommerlad.ch \
    /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: link
Be 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).