> On 03/01/2014 03:52 AM, Jan Hubicka wrote:
> >>a hidden function. We don't do that for user-defined virtual
> >>functions because the user controls whether or not they are defined
> >>in the header, and we don't devirtualize if no definition is
> >>available, but implicitly-declared functions ar
On 03/01/2014 03:52 AM, Jan Hubicka wrote:
a hidden function. We don't do that for user-defined virtual
functions because the user controls whether or not they are defined
in the header, and we don't devirtualize if no definition is
available, but implicitly-declared functions are different beca
> On 02/28/2014 03:56 PM, Jan Hubicka wrote:
> >I think we can safely test here DECL_ARTIFICIAL && (DECL_EXTERNAL ||
> >DECL_COMDAT). If the dtor is going to be output anyway, we are safe to use
> >it.
>
> We already skipped DECL_EXTERNAL decls, and artificial members are
> always DECL_COMDAT, b
I went ahead and checked in my patch so that the regression is fixed
over the weekend.
Jason
On 02/28/2014 03:56 PM, Jan Hubicka wrote:
I think we can safely test here DECL_ARTIFICIAL && (DECL_EXTERNAL ||
DECL_COMDAT). If the dtor is going to be output anyway, we are safe to use it.
We already skipped DECL_EXTERNAL decls, and artificial members are
always DECL_COMDAT, but I'll add th
> Multiple large C++ projects (KDE and libreoffice, at least) have
> been breaking when GCC speculatively devirtualizes a call to an
> implicitly-declared virtual destructor, because this leads to
> references to base destructors and vtables that might be hidden in
> another DSO. This patch avoids
Multiple large C++ projects (KDE and libreoffice, at least) have been
breaking when GCC speculatively devirtualizes a call to an
implicitly-declared virtual destructor, because this leads to references
to base destructors and vtables that might be hidden in another DSO.
This patch avoids this p
