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

[llvmbot]

Bugzilla Link	46059
Version	trunk
OS	All
Reporter	LLVM Bugzilla Contributor
CC	@zygoloid

Extended Description

NEVER FIXED: #20297

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 */ }
}

[llvmbot]

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.

[llvmbot]

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.

[llvmbot]

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.

[zygoloid]

I think this bug is independent of #20297 . (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.

[llvmbot]

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.

[AaronBallman]

Clang emits the inline variables when marked as used, so I believe this issue can now be closed: https://godbolt.org/z/jde3h7G1q

If the issue continues to persist for you, please reopen with a reproducing example.

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: None (llvmbot)

| | | | --- | --- | | Bugzilla Link | [46059](https://llvm.org/bz46059) | | Version | trunk | | OS | All | | Reporter | LLVM Bugzilla Contributor | | CC | @zygoloid |

Extended Description

NEVER FIXED: llvm/llvm-project#20297

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 */ }
}