[Bug c++/91434] gcc optimization behaviour is inconsistent with -O2 with 4.1.2 and 4.9.4

marxin at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Wed Aug 14 08:42:00 GMT 2019


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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #4 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Rajabharathi s from comment #3)
>  (In reply to Jonathan Wakely from comment #2)
> > This code has undefined behaviour:
> > 
> > int main()
> > {
> >   FSPI pi;
> >   FSPG* pg = new FSPG();
> >   new (&pi.m_a) FSPGI(pg);
> >   pi.m_a.~FSPGI();
> >   return 0;
> > }
> > 
> > pi.m_a is part of an object on the stack, so its destructor will run
> > automatically. If you invoke it explicitly as pi.m_a.~FSPGI() then you cause
> > the same object to be destroyed twice. This is undefined. You need to fix
> > your code.
> 
> 
> Thanks for your reply. I understand this.
> But since m_a is member variable of other object FSPI, this memory exists in
> stack until its destruction.

It violates C++ standard, where lifetime of an object is undefined after
destruction.

> 
> m_g is set to NULL in destructor part when called for first time.
> So second time, this if condition should be false.
> If -fno-tree-dse option is used, then this if condition is false and works
> fine in 4.9.4.

Following should help in your case:
-flifetime-dse=0

> 
>   ~FSPGI()
>       {cout << "FSPGI dtor\n";
> 
>          if(NULL != m_g)
>          {
>           cout << "m_g is not NULL\n";
>           delete m_g;
>           m_g = NULL;
>          }
>       }
> 
>  class  FSPI
>       {
> 
>       public:
>       FSPI()
>       {
>         cout << "FSPI ctor\n";
>       }
>       ~FSPI()
>       {
>         cout << "FSPI dtor \n";
>       }
>       FSPGI m_a;
>       };


More information about the Gcc-bugs mailing list