[Bug c++/64884] [5 Regression] FAIL: g++.dg/tm/pr47573.C -std=gnu++98 (test for excess errors) on x86_64-apple-darwin*

[rth at gcc dot gnu.org]

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?