[Bug c++/97681] noinline attribute ignored on constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97681 Andrew Pinski changed: What|Removed |Added Keywords||wrong-debug See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=93008 --- Comment #8 from Andrew Pinski --- Plus newer versions of C++ are relaxing constexpr even more and GCC added -fimplicit-constexpr which enables implicit constexpr for inline functions. Also constexpr have an implicit inline too, see PR 93008.
[Bug c++/97681] noinline attribute ignored on constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97681 --- Comment #7 from Jakub Jelinek --- Guess that particular spot could be changed with: --- gcc/cp/typeck2.c2020-09-12 13:36:42.500499341 +0200 +++ gcc/cp/typeck2.c2020-11-03 10:44:10.257021110 +0100 @@ -935,9 +935,11 @@ store_init_value (tree decl, tree init, } /* Don't fold initializers of automatic variables in constexpr functions, that might fold away something that needs to be diagnosed at constexpr - evaluation time. */ + evaluation time. Don't fold initializers of automatic variables + with -O0 either. */ if (!current_function_decl - || !DECL_DECLARED_CONSTEXPR_P (current_function_decl) + || (!DECL_DECLARED_CONSTEXPR_P (current_function_decl) + && optimize) || TREE_STATIC (decl)) value = cp_fully_fold_init (value); but we have dozens if not hundreds of other places. And, just disabling constant evaluation at -O0 except in manifestly constant contexts can't really work, e.g. many of the warnings heavily relies on the foldings being possible.
[Bug c++/97681] noinline attribute ignored on constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97681 Richard Biener changed: What|Removed |Added Last reconfirmed||2020-11-03 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #6 from Richard Biener --- I think at -O0 we should only consteval what is needed to (I agree gnu::noinline has nothing to do with constexpr evaluation)
[Bug c++/97681] noinline attribute ignored on constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97681
--- Comment #5 from Luke Dalessandro ---
The more I think about this the more it bothers me.
I recognize that it might be very difficult to implement in gcc's
infrastructure, but I think the design decision that "if it _can_ be constant
evaluated it _will_ be constant evaluated" is too aggressive.
Consider https://godbolt.org/z/cTYPaK.
```
[[gnu::noinline]]
constexpr int a(int x) {
return x + 1;
}
int main() {
int i = a(1);
return i;
}
```
1. The function is marked noinline.
2. The code is compile with "-O0 -g".
3. The calling context is not explicitly `constexpr`.
The fact that gcc _still_ chooses to constant evaluate `a` at best violates the
principle of least surprise, and at worst makes it impractical to use gcc to
debug more complex codebases. Honestly, the `noinline` annotation shouldn't
even be necessary, `a` should simply not be constant evaluated with `-O0`. It's
not practical to find all of the uses of `a` and modify their call sites.
>From a software engineering perspective I believe that gcc must provide some
way to disable this behavior.
[Bug c++/97681] noinline attribute ignored on constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97681 --- Comment #4 from Luke Dalessandro --- There are other occurrences of `a` that _are_ in `constexpr` context, it is used in both contexts within the application thus the keyword is necessary. This report came from a testcase reduction, so I'll have to look into what's going on in the real calling context (presumably it's *already* not `constexpr` there so it might not be an issue in practice in that context). I'd still suggest that a user that explicitly asks for `noinline`, even for a `constexpr` function, would expect `noinline` to take precedence over constant expression propagation, as the clang results provide. Perhaps some diagnostic warning can be manifested if constant expression evaluation is overriding the attribute? Thanks for the explanation.
[Bug c++/97681] noinline attribute ignored on constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97681 --- Comment #3 from Jakub Jelinek --- Don't mark it constexpr. Or, if it has any arguments, don't call it with constant arguments, but call it with non-constant ones.
[Bug c++/97681] noinline attribute ignored on constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97681 --- Comment #2 from Luke Dalessandro --- Okay, how would one constrain such inlining in order to retain a symbol and stack frame for debugging purposes?
[Bug c++/97681] noinline attribute ignored on constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97681 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- That is not inlining, but just constant expression evaluation. Attempting to constant evaluate initializers etc. even outside of constant expression is very important optimization, and noinline attribute has nothing to do with that.
