public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/103843] New: Direct call to Desctructor is optimized out
@ 2021-12-27  9:21 georgii.shagov@be-tse.de
  2021-12-27  9:33 ` [Bug c++/103843] " georgii.shagov@be-tse.de
                   ` (7 more replies)
  0 siblings, 8 replies; 9+ messages in thread
From: georgii.shagov@be-tse.de @ 2021-12-27  9:21 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 103843
           Summary: Direct call to Desctructor is optimized out
           Product: gcc
           Version: 10.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: georgii.shagov@be-tse.de
  Target Milestone: ---

cat ./d.cpp
#include <iostream>

class S {
public:
   S() = default;
   ~S() { i=10; }
   void foo() { this->~S(); }
   int getI() const { return i; }
private:
   int i{0};
};

int main()
{
   S s;
   do {
      std::cout << "Before foo: " << s.getI();
      s.foo();
      std::cout << "; After: " << s.getI() << std::endl;
   } while (false);
   return 0;
}

g++ -O0 ./d.cpp 
$./a.out 
Before foo: 0; After: 10

g++ -O3 ./d.cpp 
georgii@ltgscosvm:~/prj/test$./a.out 
Before foo: 0; After: 0

gcc --version
gcc (GCC) 10.2.1 20210130 (Red Hat 10.2.1-11)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

hostnamectl
   Static hostname: ltgscosvm.be-tse01.de
         Icon name: computer-vm
           Chassis: vm
        Machine ID: fb944a0ffb46449f9b639e589d00b598
           Boot ID: 433e59a4db5c419a9081cc6968e4e590
    Virtualization: microsoft
  Operating System: CentOS Linux 7 (Core)
       CPE OS Name: cpe:/o:centos:centos:7
            Kernel: Linux 3.10.0-1160.45.1.el7.x86_64
      Architecture: x86-64

uname -a
Linux ltgscosvm.be-tse01.de 3.10.0-1160.45.1.el7.x86_64 #1 SMP Wed Oct 13
17:20:51 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug c++/103843] Direct call to Desctructor is optimized out
  2021-12-27  9:21 [Bug c++/103843] New: Direct call to Desctructor is optimized out georgii.shagov@be-tse.de
@ 2021-12-27  9:33 ` georgii.shagov@be-tse.de
  2021-12-27  9:38 ` pinskia at gcc dot gnu.org
                   ` (6 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: georgii.shagov@be-tse.de @ 2021-12-27  9:33 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #1 from Georgii.Shagov <georgii.shagov@be-tse.de> ---
>From experiments, I would guess that in case of -O3 the call to destructor was
substituted by initializer:

This works fine:

cat ./d.cpp
#include <iostream>

class S {
public:
   S() : i{1} {}
   ~S() { i=0; }
   void foo() { this->~S(); }
   int getI() const { return i; }
private:
   int i{0};
};

int main()
{
   S s;
   do {
      std::cout << "Before foo: " << s.getI();
      s.foo();
      std::cout << "; After: " << s.getI() << std::endl;
   } while (false);
   return 0;
}


g++ ./d.cpp 
$./a.out 
Before foo: 1; After: 0
$g++ -O3 ./d.cpp 
$./a.out 
Before foo: 1; After: 0
g++ --version
g++ (GCC) 10.2.1 20210130 (Red Hat 10.2.1-11)

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug c++/103843] Direct call to Desctructor is optimized out
  2021-12-27  9:21 [Bug c++/103843] New: Direct call to Desctructor is optimized out georgii.shagov@be-tse.de
  2021-12-27  9:33 ` [Bug c++/103843] " georgii.shagov@be-tse.de
@ 2021-12-27  9:38 ` pinskia at gcc dot gnu.org
  2021-12-27  9:44 ` georgii.shagov@be-tse.de
                   ` (5 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-12-27  9:38 UTC (permalink / raw)
  To: gcc-bugs

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This is undefined code. The object is officially not live after you call the
deconstructor so GCC is able to remove the store from the deconstructor as
being dead.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug c++/103843] Direct call to Desctructor is optimized out
  2021-12-27  9:21 [Bug c++/103843] New: Direct call to Desctructor is optimized out georgii.shagov@be-tse.de
  2021-12-27  9:33 ` [Bug c++/103843] " georgii.shagov@be-tse.de
  2021-12-27  9:38 ` pinskia at gcc dot gnu.org
@ 2021-12-27  9:44 ` georgii.shagov@be-tse.de
  2021-12-27  9:51 ` pinskia at gcc dot gnu.org
                   ` (4 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: georgii.shagov@be-tse.de @ 2021-12-27  9:44 UTC (permalink / raw)
  To: gcc-bugs

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

Georgii.Shagov <georgii.shagov@be-tse.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |FIXED

--- Comment #3 from Georgii.Shagov <georgii.shagov@be-tse.de> ---
(In reply to Andrew Pinski from comment #2)
> This is undefined code. The object is officially not live after you call the
> deconstructor so GCC is able to remove the store from the deconstructor as
> being dead.

I appreciate your reply. But this is confusing. The object was NOT released
(de-allocated). In essence Destructor is just a function. Why the content of
the class had been re-initialized?
IMU: there should be not such obvious difference between optimized and
non-optimized code

thnx in advance.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug c++/103843] Direct call to Desctructor is optimized out
  2021-12-27  9:21 [Bug c++/103843] New: Direct call to Desctructor is optimized out georgii.shagov@be-tse.de
                   ` (2 preceding siblings ...)
  2021-12-27  9:44 ` georgii.shagov@be-tse.de
@ 2021-12-27  9:51 ` pinskia at gcc dot gnu.org
  2021-12-27 12:03 ` georgii.shagov@be-tse.de
                   ` (3 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-12-27  9:51 UTC (permalink / raw)
  To: gcc-bugs

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|FIXED                       |INVALID

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Georgii.Shagov from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > This is undefined code. The object is officially not live after you call the
> > deconstructor so GCC is able to remove the store from the deconstructor as
> > being dead.
> 
> I appreciate your reply. But this is confusing. The object was NOT released
> (de-allocated). In essence Destructor is just a function. 

No, the destructor is not just a function in C++, it terminates the object
being alive (not de-allocated though). You can then reuse the space for another
object, either the same type or a different type by using the inplacement new.

> Why the content of the class had been re-initialized?

It was not re-initialized rather the store was removed.

> IMU: there should be not such obvious difference between optimized and
> non-optimized code

why not, it is undefined code.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug c++/103843] Direct call to Desctructor is optimized out
  2021-12-27  9:21 [Bug c++/103843] New: Direct call to Desctructor is optimized out georgii.shagov@be-tse.de
                   ` (3 preceding siblings ...)
  2021-12-27  9:51 ` pinskia at gcc dot gnu.org
@ 2021-12-27 12:03 ` georgii.shagov@be-tse.de
  2021-12-27 12:08 ` jakub at gcc dot gnu.org
                   ` (2 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: georgii.shagov@be-tse.de @ 2021-12-27 12:03 UTC (permalink / raw)
  To: gcc-bugs

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

Georgii.Shagov <georgii.shagov@be-tse.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |FIXED

--- Comment #5 from Georgii.Shagov <georgii.shagov@be-tse.de> ---

> No, the destructor is not just a function in C++, it terminates the object
> being alive (not de-allocated though). You can then reuse the space for
> another object, either the same type or a different type by using the
> inplacement new.
> 
> > Why the content of the class had been re-initialized?
> 
> It was not re-initialized rather the store was removed.
> 
> > IMU: there should be not such obvious difference between optimized and
> > non-optimized code
> 
> why not, it is undefined code.

I really appreciate and value your Reply, Andrew.

I have modified the code a little bit:

#include <iostream>

class S {
public:
   S() = default;
   ~S() { i=10; }
   void foo() { this->~S(); }
   int getI() const { return i; }
private:
   int i{100};
};

int main()
{
   S s;
   do {
      std::cout << "Before foo: " << s.getI();
      s.foo();
      std::cout << "; After: " << s.getI() << std::endl;
   } while (false);
   return 0;
}

$g++ -O3 ./d.cpp 
$./a.out 
Before foo: 100; After: 0
$g++ -O0 ./d.cpp 
$./a.out 
Before foo: 100; After: 10

> No, the destructor is not just a function in C++, it terminates the object
> being alive (not de-allocated though). 

I do understand your point, yet I would not feel comfortable in sharing one.

- It is not clear: what function/code has reset S::i value to 0 after a Direct
call to Destructor?
- Why 0? :-?
- In order to avoid misleading I have allocated the object on the stack as you
can see. So, no-memory mgmt is not involved
- Does it mean gcc implants some code, being called after Destructor call,
resetting the content of the class Instance to 0? ::memset??
- Is there any agreement unto this? I would be happy to learn more about this.


Thnx in advance,
Yours truly, George

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug c++/103843] Direct call to Desctructor is optimized out
  2021-12-27  9:21 [Bug c++/103843] New: Direct call to Desctructor is optimized out georgii.shagov@be-tse.de
                   ` (4 preceding siblings ...)
  2021-12-27 12:03 ` georgii.shagov@be-tse.de
@ 2021-12-27 12:08 ` jakub at gcc dot gnu.org
  2021-12-27 16:38 ` redi at gcc dot gnu.org
  2021-12-27 16:41 ` redi at gcc dot gnu.org
  7 siblings, 0 replies; 9+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-12-27 12:08 UTC (permalink / raw)
  To: gcc-bugs

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|FIXED                       |INVALID
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Accessing the member after the containing variable has been destructed is
undefined behavior in C++, so when you do it, anything can happen, it can
format your disk, do nothing, crash, ...

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug c++/103843] Direct call to Desctructor is optimized out
  2021-12-27  9:21 [Bug c++/103843] New: Direct call to Desctructor is optimized out georgii.shagov@be-tse.de
                   ` (5 preceding siblings ...)
  2021-12-27 12:08 ` jakub at gcc dot gnu.org
@ 2021-12-27 16:38 ` redi at gcc dot gnu.org
  2021-12-27 16:41 ` redi at gcc dot gnu.org
  7 siblings, 0 replies; 9+ messages in thread
From: redi at gcc dot gnu.org @ 2021-12-27 16:38 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Also, this is an automatic (i.e. stack) variable, so the destructor will run at
the end of the block, meaning it will be settled twice. So another form of
undefined behaviour. The program is just broken, in multiple ways. You cannot
expect sensible behaviour from garbage code.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug c++/103843] Direct call to Desctructor is optimized out
  2021-12-27  9:21 [Bug c++/103843] New: Direct call to Desctructor is optimized out georgii.shagov@be-tse.de
                   ` (6 preceding siblings ...)
  2021-12-27 16:38 ` redi at gcc dot gnu.org
@ 2021-12-27 16:41 ` redi at gcc dot gnu.org
  7 siblings, 0 replies; 9+ messages in thread
From: redi at gcc dot gnu.org @ 2021-12-27 16:41 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #7)
> Also, this is an automatic (i.e. stack) variable, so the destructor will run
> at the end of the block, meaning it will be settled twice. 

Sorry, auto-correct changed "destroyed" to "settled"

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2021-12-27 16:41 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-12-27  9:21 [Bug c++/103843] New: Direct call to Desctructor is optimized out georgii.shagov@be-tse.de
2021-12-27  9:33 ` [Bug c++/103843] " georgii.shagov@be-tse.de
2021-12-27  9:38 ` pinskia at gcc dot gnu.org
2021-12-27  9:44 ` georgii.shagov@be-tse.de
2021-12-27  9:51 ` pinskia at gcc dot gnu.org
2021-12-27 12:03 ` georgii.shagov@be-tse.de
2021-12-27 12:08 ` jakub at gcc dot gnu.org
2021-12-27 16:38 ` redi at gcc dot gnu.org
2021-12-27 16:41 ` redi at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).