[Bug c++/109506] New: [13 regression] 'error: inlining failed in call to ‘always_inline’ ‘foo<T>::foo() [with T = void]’: function body not available'

[Bug c++/109506] New: [13 regression] 'error: inlining failed in call to ‘always_inline’ ‘foo<T>::foo() [with T = void]’: function body not available'

[sjames at gcc dot gnu.org]

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

            Bug ID: 109506
           Summary: [13 regression] 'error: inlining failed in call to
                    ‘always_inline’ ‘foo<T>::foo() [with T = void]’:
                    function body not available'
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

```
$ cat /tmp/foo.cxx
template <typename T> struct foo {
  __attribute__((__always_inline__)) foo() {};
};
template <typename T> class bar {
  foo<void> alloc_ {};
};
template <typename... A>
void func1(A &&...) {
  bar<void>();
}
void func2() {
  func1();
}

$ g++ -c -std=c++20 /tmp/foo.cxx
/tmp/foo.cxx: In constructor ‘constexpr bar<void>::bar()’:
/tmp/foo.cxx:2:38: error: inlining failed in call to ‘always_inline’
‘foo<T>::foo() [with T = void]’: function body not available
    2 |   __attribute__((__always_inline__)) foo() {};
      |                                      ^~~
/tmp/foo.cxx:4:29: note: called from here
    4 | template <typename T> class bar {
      |                             ^~~

$ g++ --version
g++ (Gentoo Hardened 13.0.1_pre20230409-r4 p9) 13.0.1 20230409 (experimental)
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
```

It compiles if the template on func1 is removed.

This works with 12 and Arsen reports that an earlier 13 is ok, but not had a
chance to bisect yet.

[Bug c++/109506] [13 regression] 'error: inlining failed in call to ‘always_inline’ ‘foo<T>::foo() [with T = void]’: function body not available'

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-04-13
           Keywords|                            |link-failure, rejects-valid
      Known to work|                            |12.2.0
   Target Milestone|---                         |13.0
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed. This is also a link failure issue:
Take:
```
template <int>
struct foo {
  foo() {};
};
template <int> class bar {
  foo<2> alloc_{};
};
template <int>
void func1() {
  bar<1>();
}
void func2() {
  func1<2>();
}
int main()
{
        func2();
}
```
This should link and it currently fails for the same reason as the
always_inline too.

[Bug c++/109506] [13 regression] 'error: inlining failed in call to ‘always_inline’ ‘foo<T>::foo() [with T = void]’: function body not available'

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |accepts-invalid

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Here is an accept invalid testcase:
```
class a
{
  a();
};

template <int>
struct foo {
  //__attribute__((__always_inline__)) 
  foo() {a b; };
};
template <int> class bar {
  foo<2> alloc_{};
};
template <int>
void func1() {
  bar<1>();
}
void func2() {
  func1<2>();
}
```

[Bug c++/109506] [13 regression] 'error: inlining failed in call to ‘always_inline’ ‘foo<T>::foo() [with T = void]’: function body not available'

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

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

--- Comment #3 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
On our box, I bisected this to r251422.  Surely that isn't the real cause of
the problem.

[Bug c++/109506] [13 regression] 'error: inlining failed in call to ‘always_inline’ ‘foo<T>::foo() [with T = void]’: function body not available'

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Marek Polacek from comment #3)
> On our box, I bisected this to r251422.  Surely that isn't the real cause of
> the problem.

It could not be as GCC 12.1.0 definitely works so does GCC 9.1.0.

Ok, this is interesting.

This fails:

/opt/compiler-explorer/gcc-trunk-20230413/bin/../libexec/gcc/x86_64-linux-gnu/13.0.1/cc1plus
-quiet -v -imultiarch x86_64-linux-gnu -iprefix
/opt/compiler-explorer/gcc-trunk-20230413/bin/../lib/gcc/x86_64-linux-gnu/13.0.1/
-D_GNU_SOURCE -isystem /opt/compiler-explorer/libs/boost_1_81_0 <source> -quiet
-dumpdir /app/ -dumpbase output.cpp -dumpbase-ext .cpp -mtune=generic
-march=x86-64 -g -g0 -O0 -version -fdiagnostics-color=always -fdump-passes
-fdump-tree-all -fdump-rtl-all -fdump-ipa-all -o /app/output.s


But this passes:

/opt/compiler-explorer/gcc-trunk-20230413/bin/../libexec/gcc/x86_64-linux-gnu/13.0.1/cc1plus
-quiet -v -imultiarch x86_64-linux-gnu -iprefix
/opt/compiler-explorer/gcc-trunk-20230413/bin/../lib/gcc/x86_64-linux-gnu/13.0.1/
-D_GNU_SOURCE -isystem /opt/compiler-explorer/libs/boost_1_81_0 <source> -quiet
-dumpdir /app/ -dumpbase output.cpp -dumpbase-ext .cpp -mtune=generic
-march=x86-64 -g -g0 -O0 -version -fdiagnostics-color=always -fdump-passes
-fdump-tree-all -fdump-rtl-all -fdump-ipa-all -fchecking -o /app/output.s

[Bug c++/109506] [13 regression] 'error: inlining failed in call to ‘always_inline’ ‘foo<T>::foo() [with T = void]’: function body not available'

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Even that happens locally:
apinski@xeond:~/src/upstream-gcc$ ./gcc/objdir/gcc/cc1plus  t.cc -quiet
t.cc: In constructor ‘constexpr bar<void>::bar()’:
t.cc:3:38: error: inlining failed in call to ‘always_inline’ ‘foo<T>::foo()
[with T = void]’: function body not available
    3 |   __attribute__((__always_inline__)) foo() {};
      |                                      ^~~
t.cc:5:29: note: called from here
    5 | template <typename T> class bar {
      |                             ^~~
apinski@xeond:~/src/upstream-gcc$ ./gcc/objdir/gcc/cc1plus  t.cc -quiet
-fchecking

[Bug c++/109506] [10/11/12/13 regression] -fchecking=2 causes some template constructor not be instantiated when used with NSDMI

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[13 regression] 'error:     |[10/11/12/13 regression]
                   |inlining failed in call to  |-fchecking=2 causes some
                   |‘always_inline’             |template constructor not be
                   |‘foo<T>::foo() [with T =    |instantiated when used with
                   |void]’: function body not   |NSDMI
                   |available'                  |
   Target Milestone|13.0                        |10.5
      Known to fail|                            |12.2.0
      Known to work|12.2.0                      |

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
>On our box, I bisected this to r251422.  Surely that isn't the real cause of the problem.

it is in the end as oh yes adding -fchecking=2 causes the failure in released
versions.

[Bug c++/109506] [10/11/12/13 regression] -fchecking=2 causes some template constructor not be instantiated when used with NSDMI

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
>This works with 12 and Arsen reports that an earlier 13 is ok, but not had a chance to bisect yet.

Just a quick note on why Arsen could not reproduce it in an earlier 13, he was
using --enable-checking=yes .

[Bug c++/109506] [10/11/12/13 regression] -fchecking=2 causes some template constructor not be instantiated when used with NSDMI

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
build_non_dependent_expr has the only code which does: flag_checking > 1

[Bug c++/109506] [10/11/12/13 regression] -fchecking=2 causes some template constructor not be instantiated when used with NSDMI

[sjames at gcc dot gnu.org]

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

--- Comment #9 from Sam James <sjames at gcc dot gnu.org> ---
I violated my own rule, by the way, by not saying the origin. This was found by
sultan in Gentoo when building Chromium (112, I think).

[Bug c++/109506] [10/11/12/13/14 regression] -fchecking=2 causes some template constructor not be instantiated when used with NSDMI

[ppalka at gcc dot gnu.org]

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

Patrick Palka <ppalka at gcc dot gnu.org> changed:

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

--- Comment #10 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Seems the problem is that we instantiate NSDMIs on demand and only once, and so
the instantiation ends up being inadvertently sensitive to whether the
instantiation was first performed from a template context.

In the comment #1 testcase, with -fchecking=2 we end up instantiating the NSDMI
for bar<1>::alloc_ for the first time from the template context func1<N>, via
fold_non_dependent_expr.  During this instantiation we call mark_used for
foo<2>'s default ctor but in_template_function() is true at this point and
mark_used exits early without scheduling the ctor for instantiation.  We never
call mark_used again for foo<2>'s default ctor since we process/instantiate an
NSDMI once.

I guess we need to somehow make sure in_template_function() always returns
false from maybe_instantiate_nsdmi_init and/or synthesized_method_walk..

[Bug c++/109506] [10/11/12/13/14 regression] -fchecking=2 causes some template constructor not be instantiated when used with NSDMI

[ppalka at gcc dot gnu.org]

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

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |ppalka at gcc dot gnu.org

[Bug c++/109506] [10/11/12/13/14 regression] -fchecking=2 causes some template constructor not be instantiated when used with NSDMI

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>:

https://gcc.gnu.org/g:9a9840cedbdc8be8252fd8f2d31d8fbd36632a2e

commit r14-393-g9a9840cedbdc8be8252fd8f2d31d8fbd36632a2e
Author: Patrick Palka <ppalka@redhat.com>
Date:   Tue May 2 08:48:59 2023 -0400

    c++: Add testcase for already fixed PR [PR109506]

    The PR109666 fix r14-386-g07c52d1eec967 incidentally also fixes this PR.

            PR c++/109506

    gcc/testsuite/ChangeLog:

            * g++.dg/cpp0x/nsdmi-template26.C: New test.

[Bug c++/109506] [10/11/12/13 regression] -fchecking=2 causes some template constructor not be instantiated when used with NSDMI

[cvs-commit at gcc dot gnu.org]

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

--- Comment #12 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Patrick Palka
<ppalka@gcc.gnu.org>:

https://gcc.gnu.org/g:f077b784a6e6876682606bd788ac77a698b81016

commit r13-7300-gf077b784a6e6876682606bd788ac77a698b81016
Author: Patrick Palka <ppalka@redhat.com>
Date:   Tue May 2 08:48:59 2023 -0400

    c++: Add testcase for already fixed PR [PR109506]

    The PR109666 fix r14-386-g07c52d1eec967 incidentally also fixes this PR.

            PR c++/109506

    gcc/testsuite/ChangeLog:

            * g++.dg/cpp0x/nsdmi-template26.C: New test.

    (cherry picked from commit 9a9840cedbdc8be8252fd8f2d31d8fbd36632a2e)

[Bug c++/109506] [11/12 regression] -fchecking=2 causes some template constructor not be instantiated when used with NSDMI

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.5                        |11.5

--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 10 branch is being closed.

[Bug c++/109506] [11/12 regression] -fchecking=2 causes some template constructor not be instantiated when used with NSDMI

[jason at gcc dot gnu.org]

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

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu.org
   Target Milestone|11.5                        |13.2
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #14 from Jason Merrill <jason at gcc dot gnu.org> ---
No need to backport fixes for -fchecking mode.