Bug 71482 - Add -Wglobal-constructors warning option
Summary: Add -Wglobal-constructors warning option
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 7.0
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: diagnostic, patch
Depends on:
Blocks: new-warning, new_warning
  Show dependency treegraph
 
Reported: 2016-06-09 20:14 UTC by Eric Gallager
Modified: 2024-05-06 00:58 UTC (History)
5 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2016-06-10 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Gallager 2016-06-09 20:14:15 UTC
Apple's gcc 4.2 has a warning flag called -Wglobal-constructors that they describe in their invoke.texi like this:

    @c APPLE LOCAL begin Wglobal-constructors 6324584
    @item -Wglobal-constructors
    @opindex Wglobal-constructors
    Warn about namespace scope data that requires construction or
    destruction, or functions that use the constructor attribute or the
    destructor attribute.  Additionally warn if the Objective-C GNU
    runtime is used to initialize various metadata.
    @c APPLE LOCAL end Wglobal-constructors 6324584

In their c.opt it says:

    ; APPLE LOCAL begin Wglobal-constructors 6324584
    Wglobal-constructors
    C ObjC C++ ObjC++ Var(warn_global_constructors)
    Warn when global (namespace scope) objects require runtime
    construction or destruction or when functions that use attribute
    constructor or destructor are used.  This is useful to help maintain
    fast program startup and end times.
    ; APPLE LOCAL end Wglobal-constructors 6324584

Apparently this option has been carried forward to clang, as pointed out in bug 71456. It would be useful for FSF GCC to have this warning option, too.
Comment 1 Richard Biener 2016-06-10 07:19:52 UTC
Confirmed.
Comment 2 Marek Polacek 2019-05-30 16:38:39 UTC
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-05/msg01860.html
Comment 3 Eric Gallager 2019-05-31 13:47:12 UTC
(In reply to Marek Polacek from comment #2)
> Patch: https://gcc.gnu.org/ml/gcc-patches/2019-05/msg01860.html

Does Sean have a bugzilla account?
Comment 4 Marek Polacek 2019-05-31 13:52:34 UTC
(In reply to Eric Gallager from comment #3)
> (In reply to Marek Polacek from comment #2)
> > Patch: https://gcc.gnu.org/ml/gcc-patches/2019-05/msg01860.html
> 
> Does Sean have a bugzilla account?

I don't see it.  Probably not yet.
Comment 5 Fangrui Song 2021-07-24 21:54:49 UTC
Still wanted.

In llvm-project, compiler-rt is using -Wglobal-constructors. llvm/lib/Support will use it as well.
Comment 6 Eric Gallager 2024-04-03 12:10:45 UTC
Another reason this warning might be wanted: name mangling and demangling of global constructors has been buggy for awhile now; see bug 54254
Comment 7 Eric Gallager 2024-05-04 07:35:44 UTC
(In reply to Eric Gallager from comment #6)
> Another reason this warning might be wanted: name mangling and demangling of
> global constructors has been buggy for awhile now; see bug 54254

Some more bugs about global constructors/destructors that might lead one to want this warning: bug 2474 and bug 56009
Comment 8 Jonathan Wakely 2024-05-04 10:55:04 UTC
(In reply to Eric Gallager from comment #6)
> Another reason this warning might be wanted: name mangling and demangling of
> global constructors has been buggy for awhile now; see bug 54254

Looks like that's just a problem demangling the symbol name to print it in a human-readable form. What's buggy about the mangling?
Comment 9 Eric Gallager 2024-05-06 00:58:00 UTC
(In reply to Jonathan Wakely from comment #8)
> (In reply to Eric Gallager from comment #6)
> > Another reason this warning might be wanted: name mangling and demangling of
> > global constructors has been buggy for awhile now; see bug 54254
> 
> Looks like that's just a problem demangling the symbol name to print it in a
> human-readable form. What's buggy about the mangling?

Well, I guess I was just remembering that "mangler dogfooding" proposal that would have added a checking option to ensure that every mangling of a symbol name that the mangler emits can also be demangled by the demangler... that didn't go in, did it? If it had, this would be an example of something that might trip it up...