https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64884
Richard Henderson <rth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target|x86_64-apple-darwin* |x86_64-apple-darwin*,
| |hppa2.0w-hp-hpux11.11
CC| |mikestump at comcast dot net
Host|x86_64-apple-darwin* |
Build|x86_64-apple-darwin* |
--- Comment #4 from Richard Henderson <rth at gcc dot gnu.org> ---
If the target supports comdat functions, then despite the
extern template class allocator<char>;
we still see the implementation
allocator() { }
and so can prove to ourselves that the called function is
transaction safe. But if the target doesn't support comdat,
then the extern template tells us to rely on there being an
external copy of that function, and so we don't emit the
constructor (way back from the front end), so we can't
analyze it during IPA etc.
[ Interestingly, this also means we can't inline the function
either. And considering that we can see that it's an empty
function, that's probably bad.
Long term we ought to think about passing along these inline
function bodies for IPA analysis, but marked so that they'll
never be emitted as separate functions. Like the old extern
__gnu_inline__ semantics, really.
]
All that said, there's a question of what to do about the
testcase. Given that the original concerned an ICE, I'm loathe
to adjust it too much. I don't suppose we have a dg-require
tag for comdat functions? I don't see one off-hand...
Alternately, #c1 blames r218640, which does concern how we mark
up constructors. Perhaps there's a better way to do this, Honza?
