[Bug c++/96282] New: internal compiler error: in output_constructor_regular_field

[Bug c++/96282] New: internal compiler error: in output_constructor_regular_field

[terra at gnome dot org]

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

            Bug ID: 96282
           Summary: internal compiler error: in
                    output_constructor_regular_field
           Product: gcc
           Version: 10.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: terra at gnome dot org
  Target Milestone: ---

Created attachment 48915
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48915&action=edit
shawn.C

With to-be-attached program I get an internal compiler error.

Happens with 32-bit mode as well as 64-bit mode.
Happens only without -O2, but happened also with -O2 before I minimized.
Happens with g++ 10.1.0 and with whatever g++ 7.x that suse ships.


# /usr/local/products/gcc/10.1.0/bin/g++  -D_FILE_OFFSET_BITS=64
-D_LARGEFILE64_SOURCE -pedantic-errors -Wall -Wno-unknown-pragmas -W
-fsigned-char -malign-data=abi -fno-semantic-interposition -gz=zlib-gnu -c
-march=westmere -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -mno-sse4a -mcx16
-msahf -mno-movbe -mno-aes -mno-sha -mno-pclmul -mpopcnt -mno-abm -mno-lwp
-mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-sgx -mno-bmi2 -mno-tbm -mno-avx
-mno-avx2 -msse4.2 -msse4.1 -mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c
-mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mno-xsave -mno-xsaveopt
-mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1
-mno-clflushopt -mno-xsavec -mno-xsaves -mno-avx512dq -mno-avx512bw
-mno-avx512vl -mno-avx512ifma -mno-avx512vbmi -mno-avx5124fmaps
-mno-avx5124vnniw -mno-clwb -mno-mwaitx -mno-clzero -mno-pku -mno-rdpid --param
"l1-cache-size=32" --param "l1-cache-line-size=64" --param
"l2-cache-size=12288" -mtune=westmere -std=gnu++17 -Wrestrict -Wdangling-else
-Wno-placement-new -Wno-deprecated-declarations -fno-strict-overflow
-Wsuggest-override -Wzero-as-null-pointer-constant -Wwrite-strings
-Wno-ignored-qualifiers -Wno-array-bounds -Wdeprecated-copy
-Wdeprecated-copy-dtor -Wredundant-move -m32 -mfpmath=sse -Woverloaded-virtual
-g -o shawn.o shawn.C
shawn.C:29:1: internal compiler error: in output_constructor_regular_field, at
varasm.c:5250
   29 | }
      | ^
0x66674d output_constructor_regular_field
        ../../../gcc-10.1.0/gcc/varasm.c:5250
0x66674d output_constructor
        ../../../gcc-10.1.0/gcc/varasm.c:5556
0xf2124a output_constant
        ../../../gcc-10.1.0/gcc/varasm.c:4908
0xf2124a output_constructor_regular_field
        ../../../gcc-10.1.0/gcc/varasm.c:5289
0xf2124a output_constructor
        ../../../gcc-10.1.0/gcc/varasm.c:5556
0xf2124a output_constant
        ../../../gcc-10.1.0/gcc/varasm.c:4908
0xf2124a output_constructor_regular_field
        ../../../gcc-10.1.0/gcc/varasm.c:5289
0xf2124a output_constructor
        ../../../gcc-10.1.0/gcc/varasm.c:5556
0xf21de5 output_constant
        ../../../gcc-10.1.0/gcc/varasm.c:4908
0xf21de5 assemble_variable_contents
        ../../../gcc-10.1.0/gcc/varasm.c:2148
0xf27c71 assemble_variable(tree_node*, int, int, int)
        ../../../gcc-10.1.0/gcc/varasm.c:2327
0xf2a61a varpool_node::assemble_decl()
        ../../../gcc-10.1.0/gcc/varpool.c:587
0xf2a61a varpool_node::assemble_decl()
        ../../../gcc-10.1.0/gcc/varpool.c:555
0x8e488c output_in_order
        ../../../gcc-10.1.0/gcc/cgraphunit.c:2582
0x8e488c symbol_table::compile()
        ../../../gcc-10.1.0/gcc/cgraphunit.c:2819
0x8e68cc symbol_table::compile()
        ../../../gcc-10.1.0/gcc/cgraphunit.c:2735
0x8e68cc symbol_table::finalize_compilation_unit()
        ../../../gcc-10.1.0/gcc/cgraphunit.c:3002
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.


# /usr/local/products/gcc/10.1.0/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/usr/local/products/gcc/10.1.0/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/products/gcc/10.1.0/lib/gcc/x86_64-suse-linux/10.1.0/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../../gcc-10.1.0/configure --enable-languages=c,c++,fortran
--enable-targets=x86_64-suse-linux,i686-suse-linux
--prefix=/usr/local/products/gcc/10.1.0 --with-gnu-as
--with-as=/usr/local/products/gcc/binutils-2.32/bin/as --with-gnu-ld
--with-ld=/usr/local/products/gcc/binutils-2.32/bin/ld --enable-threads=posix
--enable-shared --enable-__cxa_atexit --enable-libstdcxx-allocator=pool
x86_64-suse-linux
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.1.0 (GCC) 


# uname -a
Linux monsterd09 5.0.13-1-default #1 SMP Sun May 5 15:48:04 UTC 2019 (b11e2d7)
x86_64 x86_64 x86_64 GNU/Linux

[Bug c++/96282] internal compiler error: in output_constructor_regular_field

[terra at gnome dot org]

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

--- Comment #1 from M Welinder <terra at gnome dot org> ---
Created attachment 48916
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48916&action=edit
preprocessed test program

[Bug c++/96282] [8/9/10/11 Regression] internal compiler error: in output_constructor_regular_field

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2020-07-22
      Known to work|                            |7.3.0
            Summary|internal compiler error: in |[8/9/10/11 Regression]
                   |output_constructor_regular_ |internal compiler error: in
                   |field                       |output_constructor_regular_
                   |                            |field
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
      Known to fail|                            |10.1.0, 7.4.0
   Target Milestone|---                         |8.5
           Keywords|                            |ice-on-valid-code,
                   |                            |needs-bisection,
                   |                            |needs-reduction
           Priority|P3                          |P2

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Needs -std=c++14, works with 7.3, ICEs with 7.4.

[Bug c++/96282] [8/9/10/11 Regression] internal compiler error: in output_constructor_regular_field

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Started with r257580.

[Bug c++/96282] [8/9/10/11 Regression] internal compiler error: in output_constructor_regular_field

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|needs-bisection,            |
                   |needs-reduction             |
                 CC|                            |marxin at gcc dot gnu.org

--- Comment #4 from Martin Liška <marxin at gcc dot gnu.org> ---
Reduced test-case:

#include <array>

template <typename T, typename Ix, Ix Size>
class Pen : std::array<T, Size> {
  typedef std::array<T, Size> arr;
public:
  // Removing either "constexpr" or ": arr()" from the following
  // line seems to work around the problem.
  constexpr Pen() : arr() { }
};

class Farm {
public:
  enum Sheep { BAA, ZZZ };

  template<typename T>
  using SheepPen = Pen<T, Sheep, ZZZ>;
};

class Fence {
public:
  constexpr Fence() { length = 12; }
  int length = 0;
};

void
cull() {
  static Farm::SheepPen<Fence> s;
}

Will you look at it Richi?

[Bug c++/96282] [8/9/10/11 Regression] internal compiler error: in output_constructor_regular_field

[ppalka at gcc dot gnu.org]

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

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
                 CC|                            |ppalka at gcc dot gnu.org

--- Comment #5 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Investigating.

[Bug c++/96282] [8/9/10/11 Regression] internal compiler error: in output_constructor_regular_field

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 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:d21252de6c81ed236d8981d47b9a57dc4f1c6d57

commit r11-2580-gd21252de6c81ed236d8981d47b9a57dc4f1c6d57
Author: Patrick Palka <ppalka@redhat.com>
Date:   Wed Aug 5 15:05:30 2020 -0400

    c++: cxx_eval_vec_init after zero-initialization [PR96282]

    In the first testcase below, expand_aggr_init_1 sets up t's default
    constructor such that the ctor first zero-initializes the entire base b,
    followed by calling b's default constructor, the latter of which just
    default-initializes the array member b::m via a VEC_INIT_EXPR.

    So upon constexpr evaluation of this latter VEC_INIT_EXPR, ctx->ctor is
    nonempty due to the prior zero-initialization, and we proceed in
    cxx_eval_vec_init to append new constructor_elts to the end of ctx->ctor
    without first checking if a matching constructor_elt already exists.
    This leads to ctx->ctor having two matching constructor_elts for each
    index.

    This patch fixes this issue by truncating a zero-initialized array
    CONSTRUCTOR in cxx_eval_vec_init_1 before we begin appending array
    elements to it.  We propagate its zeroed out state during evaluation by
    clearing CONSTRUCTOR_NO_CLEARING on each new appended aggregate element.

    gcc/cp/ChangeLog:

            PR c++/96282
            * constexpr.c (cxx_eval_vec_init_1): Truncate ctx->ctor and
            then clear CONSTRUCTOR_NO_CLEARING on each appended element
            initializer if we're initializing a previously zero-initialized
            array object.

    gcc/testsuite/ChangeLog:

            PR c++/96282
            * g++.dg/cpp0x/constexpr-array26.C: New test.
            * g++.dg/cpp0x/constexpr-array27.C: New test.
            * g++.dg/cpp2a/constexpr-init18.C: New test.

    Co-authored-by: Jason Merrill <jason@redhat.com>

[Bug c++/96282] [8/9/10 Regression] internal compiler error: in output_constructor_regular_field

[ppalka at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[8/9/10/11 Regression]      |[8/9/10 Regression]
                   |internal compiler error: in |internal compiler error: in
                   |output_constructor_regular_ |output_constructor_regular_
                   |field                       |field

--- Comment #7 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Fixed for GCC 11 so far.

[Bug c++/96282] [8/9/10 Regression] internal compiler error: in output_constructor_regular_field

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-9331-gf426e4f63451e937c943606d3142b1ac6b70467a
Author: Patrick Palka <ppalka@redhat.com>
Date:   Wed Aug 5 15:05:30 2020 -0400

    c++: cxx_eval_vec_init after zero-initialization [PR96282]

    In the first testcase below, expand_aggr_init_1 sets up t's default
    constructor such that the ctor first zero-initializes the entire base b,
    followed by calling b's default constructor, the latter of which just
    default-initializes the array member b::m via a VEC_INIT_EXPR.

    So upon constexpr evaluation of this latter VEC_INIT_EXPR, ctx->ctor is
    nonempty due to the prior zero-initialization, and we proceed in
    cxx_eval_vec_init to append new constructor_elts to the end of ctx->ctor
    without first checking if a matching constructor_elt already exists.
    This leads to ctx->ctor having two matching constructor_elts for each
    index.

    This patch fixes this issue by truncating a zero-initialized array
    CONSTRUCTOR in cxx_eval_vec_init_1 before we begin appending array
    elements to it.  We propagate its zeroed out state during evaluation by
    clearing CONSTRUCTOR_NO_CLEARING on each new appended aggregate element.

    gcc/cp/ChangeLog:

            PR c++/96282
            * constexpr.c (cxx_eval_vec_init_1): Truncate ctx->ctor and
            then clear CONSTRUCTOR_NO_CLEARING on each appended element
            initializer if we're initializing a previously zero-initialized
            array object.

    gcc/testsuite/ChangeLog:

            PR c++/96282
            * g++.dg/cpp0x/constexpr-array26.C: New test.
            * g++.dg/cpp0x/constexpr-array27.C: New test.
            * g++.dg/cpp2a/constexpr-init18.C: New test.

    Co-authored-by: Jason Merrill <jason@redhat.com>
    (cherry picked from commit d21252de6c81ed236d8981d47b9a57dc4f1c6d57)

[Bug c++/96282] [8/9 Regression] internal compiler error: in output_constructor_regular_field

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r9-9455-gfef6ee0790de58f16128a0de87571ba7e04b8320
Author: Patrick Palka <ppalka@redhat.com>
Date:   Wed Aug 5 15:05:30 2020 -0400

    c++: cxx_eval_vec_init after zero-initialization [PR96282]

    In the first testcase below, expand_aggr_init_1 sets up t's default
    constructor such that the ctor first zero-initializes the entire base b,
    followed by calling b's default constructor, the latter of which just
    default-initializes the array member b::m via a VEC_INIT_EXPR.

    So upon constexpr evaluation of this latter VEC_INIT_EXPR, ctx->ctor is
    nonempty due to the prior zero-initialization, and we proceed in
    cxx_eval_vec_init to append new constructor_elts to the end of ctx->ctor
    without first checking if a matching constructor_elt already exists.
    This leads to ctx->ctor having two matching constructor_elts for each
    index.

    This patch fixes this issue by truncating a zero-initialized array
    CONSTRUCTOR in cxx_eval_vec_init_1 before we begin appending array
    elements to it.  We propagate its zeroed out state during evaluation by
    clearing CONSTRUCTOR_NO_CLEARING on each new appended aggregate element.

    gcc/cp/ChangeLog:

            PR c++/96282
            * constexpr.c (cxx_eval_vec_init_1): Truncate ctx->ctor and
            then clear CONSTRUCTOR_NO_CLEARING on each appended element
            initializer if we're initializing a previously zero-initialized
            array object.

    gcc/testsuite/ChangeLog:

            PR c++/96282
            * g++.dg/cpp0x/constexpr-array26.C: New test.
            * g++.dg/cpp0x/constexpr-array27.C: New test.

    Co-authored-by: Jason Merrill <jason@redhat.com>
    (cherry picked from commit d21252de6c81ed236d8981d47b9a57dc4f1c6d57)

[Bug c++/96282] [8 Regression] internal compiler error: in output_constructor_regular_field

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|8.5                         |9.4

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The GCC 8 branch is being closed, fixed in GCC 9.4.