<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 16 January 2018 at 12:12, Friedman, Eli via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><div><div class="h5">
<div class="m_-3320024986354150438moz-cite-prefix">On 1/16/2018 11:26 AM, Gabriel Charette
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr"><br>
<br>
<div class="gmail_quote">
<div dir="ltr">On Tue, Jan 16, 2018 at 8:00 PM Richard Smith
<<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On 16 January 2018 at 10:43,
Friedman, Eli via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" class="m_-3320024986354150438cremed" target="_blank">cfe-dev@lists.llvm.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_-3320024986354150438m_-3430430873447914162gmail-">On 1/16/2018
4:14 AM, Gabriel Charette via cfe-dev wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I would indeed expect, like Primiano, that
-Wglobal-constructors would only warn about
*con*structors (one can decide to mitigate
global *de*structors another way, e.g. by
invoking _exit() before end of main()).<br>
</blockquote>
</span>
The point of -Wglobal-constructors is to avoid code
which runs at process startup. Due to the way the
C++ ABI works, a global destructor involves emitting
a call to __cxa_atexit which runs at startup, so we
warn.<br>
</blockquote>
<div><br>
</div>
</div>
</div>
</div>
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>Well, there are (at least) four distinct problems
here:</div>
<div><br>
</div>
<div> 1) Code running at process startup (a
performance problem)</div>
<div> 2) Code running at process termination (a
performance problem)</div>
<div> 3) Global variables with non-constant
initialization resulting in buggy program startup
(called the "initialization order fiasco" by some)</div>
<div> 4) Global variables with non-trivial destruction
resulting in buggy program shutdown, particularly in
multithreaded code (if you have non-trivial global
dtors, multiple threads, and you call exit, you
typically have a bug)</div>
<div><br>
</div>
<div>It makes sense to request warnings about #3
without requesting the more general warnings about
#1; as such, ignoring destructors in the
-Wglobal-constructors warning would seem reasonable
to me. (That allows all four problems to be detected
by some combination of the two warning flags.)</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Yes, precisely.</div>
<div><br>
</div>
<div>A program can decide to mitigate against 2/4 by
atomically exiting with _exit() before the end of main() and
hence truly only want to be warned by 1/3.</div>
<div><br>
</div>
</div>
</div>
</blockquote>
</div></div><p>I'm not sure (3) is a problem this warning solves well; there are
a lot of classes with constructors which aren't constexpr, but
don't have relevant side-effects (for example, std::vector).</p></div></blockquote><div>Yes, but it depends on how you try to solve (3). If you allow dynamically-initialized globals, but only if they don't reference other dynamically-initialized globals, you're right that this is pretty far from ideal. But that approach is fraught with peril, since even innocuous-seeming changes become wrong if you happen to be changing code that's reachable from a dynamically-initialized global. A more reliable (but obviously more restrictlve) approach is to avoid dynamically-initialized globals altogether, which this warning does help with :) Given the ongoing expansion of the powers of constexpr evaluation, the more restrictive approach is likely to become appropriate for more projects over time.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><p>But
I guess we could introduce a new warning flag. (We probably don't
want to change the meaning of the current warning flag for the
sake of compatibility with existing build systems.)<br>
</p>
<p>On a side-note, it would be nice if the following worked to
suppress global destructors:<br>
</p>
<p>struct A { ~A(); };<br>
template<typename T> union NoDestroy {<br>
T t;<br>
constexpr NoDestroy():t{} {}<br>
constexpr ~NoDestroy() {}<br>
};<br>
NoDestroy<A> x;</p></div></blockquote><div>This already suppresses the global dtor when compiled with optimization enabled (and the 'constexpr' on the destructor removed): we optimize out __cxa_atexit calls registering empty functions, IIRC. Support for constexpr destructors is working its way through the C++ committee right now, and that should behave as you expect on the above example (removing the global dtor).</div></div></div></div>