[Bug c++/97681] New: noinline attribute ignored on constexpr function

[Bug c++/97681] New: noinline attribute ignored on constexpr function

[ldalessandro at gmail dot com]

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

            Bug ID: 97681
           Summary: noinline attribute ignored on constexpr function
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ldalessandro at gmail dot com
  Target Milestone: ---

GCC inlines function marked noinline when the function is marked as
`constexpr`, even if it is not used in `constexpr` context.
https://godbolt.org/z/b94Kje

```
[[gnu::noinline]] constexpr auto a() { return 1; }
[[gnu::noinline]] auto b() { return 2; }

int main() {
    int i = a();
    int j = b();
    return i + j;
}
```

```
b():
        mov     eax, 2
        ret
main:
        call    b()
        add     eax, 1
        ret
```

[Bug c++/97681] noinline attribute ignored on constexpr function

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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.

[Bug c++/97681] noinline attribute ignored on constexpr function

[ldalessandro at gmail dot com]

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

--- Comment #2 from Luke Dalessandro <ldalessandro at gmail dot com> ---
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

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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

[ldalessandro at gmail dot com]

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

--- Comment #4 from Luke Dalessandro <ldalessandro at gmail dot com> ---
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

[ldalessandro at gmail dot com]

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

--- Comment #5 from Luke Dalessandro <ldalessandro at gmail dot com> ---
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

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2020-11-03
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
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

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Guess that particular spot could be changed with:
--- gcc/cp/typeck2.c    2020-09-12 13:36:42.500499341 +0200
+++ gcc/cp/typeck2.c    2020-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

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> 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 <pinskia at gcc dot gnu.org> ---
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.