[Bug target/113465] New: [mingw-w64] dllexported constexpr (inline) variables not automatically emitted

[Bug target/113465] New: [mingw-w64] dllexported constexpr (inline) variables not automatically emitted

[thiago at kde dot org]

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

            Bug ID: 113465
           Summary: [mingw-w64] dllexported constexpr (inline) variables
                    not automatically emitted
           Product: gcc
           Version: 13.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: thiago at kde dot org
  Target Milestone: ---

Related to explicit instantiation of templates bugs:
Bug 89088, Bug 109380
though I'd argue that since that has a special syntax, it's different.

Testcase:
struct __declspec(dllexport) QLocale
{
    static constexpr int FirstTwoDigitYear = 1900;
};

With GCC, this produces:
        .file   "example.cpp"
        .text
        .ident  "GCC: (MinGW-W64 x86_64-ucrt-mcf-seh, built by Brecht Sanders)
13.1.0"

That is, nothing.

With Clang, that emits (simplified):
        .text
        .section       
.rdata$_ZN7QLocale17FirstTwoDigitYearE,"dr",discard,_ZN7QLocale17FirstTwoDigitYearE
        .globl  _ZN7QLocale17FirstTwoDigitYearE #
@_ZN7QLocale17FirstTwoDigitYearE
        .p2align        2, 0x0
_ZN7QLocale17FirstTwoDigitYearE:
        .long   1900                            # 0x76c

        .section        .drectve,"yni"
        .ascii  " -export:_ZN7QLocale17FirstTwoDigitYearE,data"
        .addrsig

MSVC also emits the variable, though how it causes the export to happen isn't
clear.

https://mingw.godbolt.org/z/ErbfdPaf8

This can be worked around by explicitly declaring the variable as if it were
not inline (before C++17):

constexpr int QLocale::FirstTwoDigitYear;

However, since this isn't required in any other platform and other compilers on
Windows don't require it either, developers are going to forget it. And very
likely, this issue is going to show up only when users compile their code,
depending on varying levels of optimisation and inlining.

[Bug target/113465] [mingw-w64] dllexported constexpr (inline) variables not automatically emitted

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ABI

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
IIRC this is what the IA64 ABI says to do.

clang might be getting it wrong ...

[Bug target/113465] [mingw-w64] dllexported constexpr (inline) variables not automatically emitted

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Plus I think the C++ standard says the definition is still required ...

[Bug target/113465] [mingw-w64] dllexported constexpr (inline) variables not automatically emitted

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
See PR 54483 .

*** This bug has been marked as a duplicate of bug 54483 ***

[Bug target/113465] [mingw-w64] dllexported constexpr (inline) variables not automatically emitted

[thiago at kde dot org]

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

--- Comment #4 from Thiago Macieira <thiago at kde dot org> ---
(In reply to Andrew Pinski from comment #3)
> See PR 54483 .
> 
> *** This bug has been marked as a duplicate of bug 54483 ***

I don't think that's the same. That situation over there is C++11, where the
constexpr variable is *not* static.

I forgot to say that in my case it is inline because it's C++17.

On use, GCC emits a copy of the variable:
struct __declspec(dllimport) QLocale
{
    static constexpr inline int FirstTwoDigitYear = 1900;
};

template<typename T> void f(const T &);
void f() { f(QLocale::FirstTwoDigitYear); }

results in:

_Z1fv:
        movq    __imp__ZN7QLocale17FirstTwoDigitYearE(%rip), %rcx
        jmp     _Z1fIiEvRKT_
_ZN7QLocale17FirstTwoDigitYearE:
        .long   1900

This copy is useless. The equivalent code for ELF and Mach-O ABIs is fine
because the relocation would find it, if the original variable doesn't exist in
the .so. But on Windows, that __imp_ prefix implies it's an import from another
DLL, which *must* have emitted its copy and exported it.

Clang and MSVC also do the import, but don't emit that copy. See
https://mingw.godbolt.org/z/aKsaYKThT.

[Bug target/113465] [mingw-w64] dllexported constexpr (inline) variables not automatically emitted

[thiago at kde dot org]

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

--- Comment #5 from Thiago Macieira <thiago at kde dot org> ---
> I don't think that's the same. That situation over there is C++11, where the
> constexpr variable is *not* static.

I meant not *inline*.

[Bug target/113465] [mingw-w64] dllexported constexpr (inline) variables not automatically emitted

[thiago at kde dot org]

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

--- Comment #6 from Thiago Macieira <thiago at kde dot org> ---
Mind if I ask you reconsider the decision for inline variables (which all
constexpr ones are)?