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

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

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64884

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-01-31
     Ever confirmed|0                           |1

--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
See https://gcc.gnu.org/ml/gcc-testresults/2015-01/msg03581.html.

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

[danglin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64884

John David Anglin <danglin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |danglin at gcc dot gnu.org

--- Comment #2 from John David Anglin <danglin at gcc dot gnu.org> ---
Also seen on hppa2.0w-hp-hpux11.11.

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

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64884

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |5.0

[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
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |rth at gcc dot gnu.org

--- Comment #3 from Richard Henderson <rth at gcc dot gnu.org> ---
Mine.  A brief glance suggests the test case is bogus.
Digging into it further...

[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?

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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64884

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
We don't have an effective target for comdat support, but we e.g. have
comdat_group.  That is supposedly a strict subset of comdat support, perhaps
that would be good enough?

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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64884

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.

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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64884

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Thu Feb 12 21:33:37 2015
New Revision: 220664

URL: https://gcc.gnu.org/viewcvs?rev=220664&root=gcc&view=rev
Log:
    PR c++/64884
    * g++.dg/tm/pr47573.C: Only run on comdat_group effective targets.

Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/g++.dg/tm/pr47573.C