https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79814
--- Comment #3 from rguenther at suse dot de <rguenther at suse dot de> --- On March 4, 2017 12:30:21 AM GMT+01:00, "dmalcolm at gcc dot gnu.org" <gcc-bugzi...@gcc.gnu.org> wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79814 > >--- Comment #2 from David Malcolm <dmalcolm at gcc dot gnu.org> --- >The code in question is: > do { ((void)(!( > __null >== pass_warn_unused_result_1) ? fancy_abort ("./pass-instances.def", >36, >__FUNCTION__), 0 : 0)); if ((1) == 1) pass_warn_unused_result_1 = >make_pass_warn_unused_result (m_ctxt); else { >((void)(!(pass_warn_unused_result_1) ? fancy_abort >("./pass-instances.def", 36, >__FUNCTION__), 0 : 0)); pass_warn_unused_result_1 = >pass_warn_unused_result_1->clone (); } p = next_pass_1 (p, >pass_warn_unused_result_1, pass_warn_unused_result_1); } while (0); > >i.e. it's complaining about this assertion: > > gcc_assert (NULL == PASS ## _ ## NUM); \ > >within the definition of NEXT_PASS(PASS, NUM) supplied within the >pass_manager >ctor: it's asserting that a pointer field within the object is NULL. > >pass_manager::operator new ensures that the underlying memory of the >pass >manager is zero-initialized, but clearly the warning has no knowledge >of this. Well, the C++ frontend inserts CLOBBERs at the beginning of constructors so either this zeroing is pointless (and likely optimized out) or the frontend produces wrong-code in doing so. >Eliminating the assertion fixes the warning, FWIW.
