[Bug c++/82818] Bad Codegen, delete does not check for nullptrs

[dark_sylinc at yahoo dot com.ar]

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

--- Comment #2 from dark_sylinc at yahoo dot com.ar ---
Created attachment 42540
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42540=edit
Workaround. Uncomment "//a.~FastArray();" to make the crash come back

[Bug c++/82818] Bad Codegen, delete does not check for nullptrs

[dark_sylinc at yahoo dot com.ar]

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

--- Comment #1 from dark_sylinc at yahoo dot com.ar ---
Update:

1. Confirmed to be broken with gcc 7.2
2. When I said fsanitize; I meant fsanitize=undefined
3. When code is slightly modified as in the new attachment, the crash is gone.
But it appears again if after calling a.destroy(); we add a.~FastArray();

[Bug c++/82818] New: Bad Codegen, delete does not check for nullptrs

[dark_sylinc at yahoo dot com.ar]

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

Bug ID: 82818
   Summary: Bad Codegen, delete does not check for nullptrs
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dark_sylinc at yahoo dot com.ar
  Target Milestone: ---

Created attachment 42539
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42539=edit
Simple repro of the problem

The attached file, when compiled and run with the following:
c++ -std=c++11 -Wall -Wextra -O2 -g -DNDEBUG -fno-strict-aliasing main.cpp

will crash complaining about a double free; even though:
 * operator delete is guaranteed to check for nullptrs
 * There's also an explicit check for if( mData ). Trying a boolean instead
results in the same problem. The check is just left out.
 * AFAIK it is legal to call the destructor.

Problem does not reproduce without optimizations, and cannot be reproduced in
Clang or MSVC either.
It seems that GCC optimizer cannot deal with code explicitly calling the
destructor.

Info about me:
g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 6.3.0-12ubuntu2'
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 6.3.0 20170406 (Ubuntu 6.3.0-12ubuntu2)


I heard the report from another guy who has a much newer version of everything
than me; so it's very possible this problem is still present in newer versions
or even latest gcc.

Running with -fsanitize reports nothing, but the program stops crashing.