Check the impact of -fimplicit-constexpr

[fwyzard]

From the GCC 12 manual:

-fimplicit-constexpr

Make inline functions implicitly constexpr, if they satisfy the requirements for a constexpr function. This option can be used in C++14 mode or later. This can result in initialization changing from dynamic to static and other optimizations.

We could try using in CMSSW 🤷🏻

[fwyzard]

assign core

[cmsbuild]

New categories assigned: core

@Dr15Jones,@makortel,@smuzaffar you have been requested to review this Pull request/Issue and eventually sign? Thanks

[cmsbuild]

cms-bot internal usage

[cmsbuild]

A new Issue was created by @fwyzard.

@Dr15Jones, @antoniovilela, @makortel, @mandrenguyen, @rappoccio, @sextonkennedy, @smuzaffar can you please review it and eventually sign/assign? Thanks.

cms-bot commands are listed here

[makortel]

Found this https://www.mail-archive.com/[email protected]/msg274264.html as more background (in short, the writer foresees constexpr to have similar fate as the register keyword).

Found also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110127 that reports "extremely slow and memory intensive compilation". IIUC the problem is fixed in 13.3, but apparently 12.X (at least X=1, 3) would be impacted.

[fwyzard]

Thanks for digging !

the writer foresees constexpr to have similar fate as the register keyword

I kind of agree.
Can one even have non-inline constexpr functions?
Maybe they could be used by the LTO ?
Anyway.

IIUC the problem is fixed in 13.3, but apparently 12.X (at least X=1, 3) would be impacted.

Good catch.
I guess we can give it a try in the GCC 13 builds, then.

[makortel]

Can one even have non-inline constexpr functions?

No, from https://en.cppreference.com/w/cpp/language/constexpr

A constexpr specifier used in the first declaration of a function (or static data member(since C++17)) implies inline.

[fwyzard]

OK, and a constexpr function cannot just be declared (and defined in a different translation unit):

error: ‘constexpr int f()’ used before its definition