[Bug libstdc++/64828] [5 Regression] libstdc++-v3/libsupc++/del_opvs.cc:30:1: warning: ‘void operator delete [](void*, std::size_t)’ is a usual (non-placement) deallocation function in C++14 (or with -fsized-deallocation) [-Wc++14-compat]

["ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #4 from Uroš Bizjak <ubizjak at gmail dot com> ---
BTW: These warnings also appear in libsanitizer:

/home/uros/gcc-svn/trunk/libsanitizer/asan/asan_new_delete.cc:107:6: warning:
‘void operator delete(void*, size_t)’ is a usual (non-placement) deallocation
function in C++14 (or with -fsized-deallocation) [-Wc++14-compat]
/home/uros/gcc-svn/trunk/libsanitizer/asan/asan_new_delete.cc:112:6: warning:
‘void operator delete [](void*, size_t)’ is a usual (non-placement)
deallocation function in C++14 (or with -fsized-deallocation) [-Wc++14-compat]
/home/uros/gcc-svn/trunk/libsanitizer/asan/asan_new_delete.cc:107:6: warning:
‘void operator delete(void*, size_t)’ is a usual (non-placement) deallocation
function in C++14 (or with -fsized-deallocation) [-Wc++14-compat]
/home/uros/gcc-svn/trunk/libsanitizer/asan/asan_new_delete.cc:112:6: warning:
‘void operator delete [](void*, size_t)’ is a usual (non-placement)
deallocation function in C++14 (or with -fsized-deallocation) [-Wc++14-compat]
>From gcc-bugs-return-475228-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jan 28 12:19:25 2015
Return-Path: <gcc-bugs-return-475228-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 8284 invoked by alias); 28 Jan 2015 12:19:24 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 8123 invoked by uid 48); 28 Jan 2015 12:19:17 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/64830] g++ generating segfaulting binaries
Date: Wed, 28 Jan 2015 12:19:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.9.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution
Message-ID: <bug-64830-4-MJhJJHMqY9@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64830-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64830-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-01/txt/msg03222.txt.bz2
Content-length: 1712

https://gcc.gnu.org/bugzilla/show_bug.cgi?idd830

Jonathan Wakely <redi at gcc dot gnu.org> changed:

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

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
This is not a bug in GCC.

tl;dr https://isocpp.org/wiki/faq/ctors#static-init-order


The segfault is due to dereferencing default_instance_ here:

inline const ::BundleConfigInfo& ConfigInfo::bundle() const {
  return bundle_ != NULL ? *bundle_ : *default_instance_->bundle_;
}

That is supposed to be initialized by protobuf_AddDesc_testcase_2eproto() which
gets called from:

// Force AddDescriptors() to be called at static initialization time.
struct StaticDescriptorInitializer_testcase_2eproto {
  StaticDescriptorInitializer_testcase_2eproto() {
    protobuf_AddDesc_testcase_2eproto();
  }
} static_descriptor_initializer_testcase_2eproto_;

Which is a global object in testcase.pb.cc

Your testcase.cc also has a global object:

namespace ConfigHelper
{
    Config defaultConfig; // causes segfault
}

The order of initialization of globals is undefined in separate translation
units, so you are wrong to assume that the protobuf global will be initialized
before your global.

I was able to avoid the segfault by simply reordering the files passed to the
linker, so that testcase.pb.o comes before testcase.o, but that is still
relying on something that is not guaranteed.

Either protobuf should find a better way to initialize its defaults or you
should not use it from globals.