Bug 107938 - [11/12 Regression] ICE directly returning `this` of `extern` variable in template since r11-557
Summary: [11/12 Regression] ICE directly returning `this` of `extern` variable in temp...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 13.0
: P2 normal
Target Milestone: 11.4
Assignee: Marek Polacek
URL:
Keywords: ice-on-valid-code, patch
Depends on:
Blocks: constexpr
  Show dependency treegraph
 
Reported: 2022-11-30 19:09 UTC by Johel Ernesto Guerrero Peña
Modified: 2023-03-04 18:24 UTC (History)
6 users (show)

See Also:
Host:
Target:
Build:
Known to work: 10.4.0
Known to fail: 11.1.0
Last reconfirmed: 2022-11-30 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Johel Ernesto Guerrero Peña 2022-11-30 19:09:10 UTC
See https://compiler-explorer.com/z/4d1esaber.

```C++
struct Q {
  int n;
  constexpr const Q* operator()(auto) const { return this; }
};

extern const Q q;

template<int>
constexpr const Q* p = q(0);
```

```
<source>:9:27: internal compiler error: Segmentation fault
    9 | constexpr const Q* p = q(0);
      |                           ^
0x22e3a9e internal_error(char const*, ...)
	???:0
0xce2006 convert_for_initialization(tree_node*, tree_node*, tree_node*, int, impl_conv_rhs, tree_node*, int, int)
	???:0
0xced3f0 store_init_value(tree_node*, tree_node*, vec<tree_node*, va_gc, vl_embed>**, int)
	???:0
0xb22845 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
	???:0
0xc20997 c_parse_file()
	???:0
0xd5b949 c_common_parse_file()
	???:0
Please submit a full bug report, with preprocessed source (by using -freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
Compiler returned: 1
```

Being less direct works: https://compiler-explorer.com/z/jn99aG36e.
Comment 1 Andrew Pinski 2022-11-30 19:23:03 UTC
Confirmed. A regression from GCC 10.4.0.

A C++14 testcase (removing the auto from the operator()):
```
struct Q {
  int n;
  constexpr const Q* operator()(int) const { return this; }
};

extern const Q q;

template<int>
constexpr const Q* p = q(0);
```
Comment 2 Andrew Pinski 2022-11-30 19:30:16 UTC
Hmm, the following slightly modified testcase works in GCC 8.5.0 but started to ICE in GCC 9.1.0:
```
struct Q {
  int n;
  constexpr const Q* operator()(int) const { return this; }
};

constexpr Q q{};

template<int>
constexpr const Q* p = q(0);
```

It is still a regression though.
Comment 3 Jakub Jelinek 2022-12-02 14:52:05 UTC
This also started with r11-557-gbeb019d346b903c16b9fd349937de444b6a8b6c0
Comment 4 Marek Polacek 2023-02-23 23:52:50 UTC
Patch posted: <https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612700.html>
Comment 5 GCC Commits 2023-02-28 15:10:59 UTC
The trunk branch has been updated by Marek Polacek <mpolacek@gcc.gnu.org>:

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

commit r13-6376-gea718febab2a1f6e58806738abf70f1c73c6a308
Author: Marek Polacek <polacek@redhat.com>
Date:   Thu Feb 23 17:54:47 2023 -0500

    c++: ICE with constexpr variable template [PR107938]
    
    Since r11-557, cp_finish_decl can call check_initializer even in
    a template for a constexpr initializer.  That ultimately leads to
    convert_for_assignment and check_address_or_pointer_of_packed_member,
    where we crash, because it doesn't expect that the CALL_EXPR is
    a function object.  Q has a constexpr operator(), but since we're
    in a template, q(0) is a CALL_EXPR whose CALL_EXPR_FN is just
    a VAR_DECL; it hasn't been converted to Q::operator<int>(&q, 0) yet.
    I propose to robustify check_address_or_pointer_of_packed_member.
    
    var-templ74.C has an XFAIL, subject to 107939.
    
    I noticed that our -Waddress-of-packed-member tests weren't testing
    member functions, added thus.  (I was tempted to check
    FUNCTION_POINTER_TYPE_P but that doesn't include METHOD_TYPE.)
    
            PR c++/107938
    
    gcc/c-family/ChangeLog:
    
            * c-warn.cc (check_address_or_pointer_of_packed_member): Check
            POINTER_TYPE_P.
    
    gcc/testsuite/ChangeLog:
    
            * g++.dg/cpp1y/var-templ73.C: New test.
            * g++.dg/cpp1y/var-templ74.C: New test.
            * g++.dg/warn/Waddress-of-packed-member3.C: New test.
Comment 6 GCC Commits 2023-03-04 17:43:46 UTC
The releases/gcc-12 branch has been updated by Marek Polacek <mpolacek@gcc.gnu.org>:

https://gcc.gnu.org/g:445082ff3cb7f9d30021adf338e9ab6038c3e412

commit r12-9215-g445082ff3cb7f9d30021adf338e9ab6038c3e412
Author: Marek Polacek <polacek@redhat.com>
Date:   Thu Feb 23 17:54:47 2023 -0500

    c++: ICE with constexpr variable template [PR107938]
    
    Since r11-557, cp_finish_decl can call check_initializer even in
    a template for a constexpr initializer.  That ultimately leads to
    convert_for_assignment and check_address_or_pointer_of_packed_member,
    where we crash, because it doesn't expect that the CALL_EXPR is
    a function object.  Q has a constexpr operator(), but since we're
    in a template, q(0) is a CALL_EXPR whose CALL_EXPR_FN is just
    a VAR_DECL; it hasn't been converted to Q::operator<int>(&q, 0) yet.
    I propose to robustify check_address_or_pointer_of_packed_member.
    
    var-templ74.C has an XFAIL, subject to 107939.
    
    I noticed that our -Waddress-of-packed-member tests weren't testing
    member functions, added thus.  (I was tempted to check
    FUNCTION_POINTER_TYPE_P but that doesn't include METHOD_TYPE.)
    
            PR c++/107938
    
    gcc/c-family/ChangeLog:
    
            * c-warn.cc (check_address_or_pointer_of_packed_member): Check
            POINTER_TYPE_P.
    
    gcc/testsuite/ChangeLog:
    
            * g++.dg/cpp1y/var-templ73.C: New test.
            * g++.dg/cpp1y/var-templ74.C: New test.
            * g++.dg/warn/Waddress-of-packed-member3.C: New test.
    
    (cherry picked from commit ea718febab2a1f6e58806738abf70f1c73c6a308)
Comment 7 Marek Polacek 2023-03-04 18:24:11 UTC
Fixed.