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
