[[gnu::used]] unsupported. Breaks many "inline static" use cases including P0424R0.

[Quuxplusone]

Bugzilla Link	PR46059
Status	NEW
Importance	P normal
Reported by	David Simmons (dsim@smallscript.com)
Reported on	2020-05-24 13:27:43 -0700
Last modified on	2020-05-26 16:36:11 -0700
Version	trunk
Hardware	All All
CC	blitzrakete@gmail.com, erik.pilkington@gmail.com, llvm-bugs@lists.llvm.org, richard-llvm@metafoo.co.uk
Fixed by commit(s)
Attachments
Blocks
Blocked by
See also

NEVER FIXED: https://bugs.llvm.org/show_bug.cgi?id=19923

Breaks patterns for creating self registering code modules; which happens to
also go hand in hand with pattern use cases for P0424R0/P0424R1.

Using "inline static" will not ensure the static variable is defined.

In fact, the compiler will analyze and remove the static if it thinks it is
unreachable.

This creates the need to do horrible things like declare static extern export
functions that reference the "inline static" to ensure it is not elided. Which
is total crap and pollution of the COFF/ELF/PE exports!

struct Base {
  inline static Base* pHead = nullptr;
  static void DoRuntimeActions() {
    for(auto p = pHead; p; p = p->pPrev) p->onRuntimeAction();
  }
  Base* pPrev;
  Base() { pPrev = pHead; pHead = this; }
  virtual void onRuntimeAction() = 0;
}
struct Foo : Base {
  [[gnu::used]] /* NO SUPPORTED IN CLANG!!!! */
  inline static Foo s; // SO, no way to guarantee it will exist
  /* leverage static singleton registration pattern BROKEN */
  virtual void onRuntimeAction() { /* do something useful */ }
}

[Quuxplusone]

A prevalent use for this is to manage runtime initialization reliably.

I happen to build dynamic language engines; like JavaScript, Smalltalk, TCL etc.

One goal of which is to have very fast startup and shutdown times. Another is to allow re-use of the runtime-engine within a process. I.e., to create a pool of worker processes where the language engine (service) can be started up, shutdown, restarted. Where components can be loaded and unloaded as self describing modules.

Encapsulation is broken, and redundant declarations (outside the header) have to be done to ensure that "inline statics" don't get elided. Which is really dumb since the entire purpose of "inline statics" was to avoid this very pattern.

It is great to have the compiler optimize away unused types and their "inline statics" if they are not using a self-registration pattern; but not being able to use a self-registration pattern is against the intention of "inline statics" and the model C++ has been driving towards with eliminating the need to multiply declare statics in headers, and implementation etc.

[Quuxplusone]

See: https://docs.microsoft.com/en-us/cpp/cpp/using-dllimport-and-dllexport-in-
cpp-classes?view=vs-2019

Declaring struct Foo using: "__declspec( dllexport )"

struct __declspec( dllexport ) Foo : Base {
  [[gnu::used]] /* NO SUPPORTED IN CLANG!!!! */
  inline static Foo s; // SO, no way to guarantee it will exist
  /* leverage static singleton registration pattern BROKEN */
  virtual void onRuntimeAction() { /* do something useful */ }
}

Will give ensure the "inline static" is referenced and constructed. But, as
mentioned, it generates excessive COFF entries. It also is not at all what the
intention is; which is to declare the static ONCE in a header and be guaranteed
the compiler will NOT elide it.

[Quuxplusone]

Actually, turns out that "declspec( dllexport )" is not reliable, working perhaps for CRTP forms, but not the example I posed above. Even if it contains an static function (which is bug for maintaining Microsoft Compatibility with "declspec( dllexport )").

I am also not sure if some of this is the result of c++2a work on modules.

Which complicates things since Visual Studio 2019 CRT std libs do not work with clang c++2a mode. Only Visual Studio 2017 CRT std libs do.

[Quuxplusone]

I think this bug is independent of PR19923. (That bug is about whether [[gnu::used]] members of a class template are instantiated with the class or only when used; this bug is -- if I understand your report -- about whether [[gnu::used]] static data members are emitted even if unused.)

Most likely this is an oversight in the handling for inline variables. A similar problem exists with both global inline variables and class-static inlines. This testcase:

[[gnu::used]] inline int x; struct A { [[gnu::used]] static inline int x; };

... does not result in either 'x' or 'A::x' being emitted (with GCC or Clang), but does with ICC:

https://godbolt.org/z/zKnr6s

I think the ICC behavior is correct. Marking the variable 'used' indicates that it might be referenced from (eg) inline assembly, so we are obliged emit it even if we can't see a use in the source.

(If a non-trivial initializer is added, GCC and Clang do emit the variable.)

However, it's not entirely clear whether the above is a description of the problem you're reporting. Your testcase is invalid:

// ... struct Foo : Base { [[gnu::used]] / NO SUPPORTED IN CLANG!!!! / inline static Foo s; // SO, no way to guarantee it will exist // ...

is ill-formed, because the type 'Foo' of 's' is incomplete at the point where it's defined here. If you can provide a small, self-contained, compilable testcase that demonstrates the problem, that would be very useful.

[Quuxplusone]

I received the email response to my bug.

Thank you for replying so quickly!

I have some code deliverables today and tomorrow. But I will add a complete repro example after that.