Bug 96282 - [8 Regression] internal compiler error: in output_constructor_regular_field
Summary: [8 Regression] internal compiler error: in output_constructor_regular_field
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 10.1.0
: P2 normal
Target Milestone: 9.4
Assignee: Patrick Palka
URL:
Keywords: ice-on-valid-code
Depends on:
Blocks:
 
Reported: 2020-07-22 12:13 UTC by M Welinder
Modified: 2021-05-14 14:01 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work: 7.3.0
Known to fail: 10.1.0, 7.4.0
Last reconfirmed: 2020-07-22 00:00:00


Attachments
shawn.C (306 bytes, text/x-csrc)
2020-07-22 12:13 UTC, M Welinder
Details
preprocessed test program (26.42 KB, application/gzip)
2020-07-22 12:14 UTC, M Welinder
Details

Note You need to log in before you can comment on or make changes to this bug.
Description M Welinder 2020-07-22 12:13:35 UTC
Created attachment 48915 [details]
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
Comment 1 M Welinder 2020-07-22 12:14:33 UTC
Created attachment 48916 [details]
preprocessed test program
Comment 2 Richard Biener 2020-07-22 14:13:15 UTC
Needs -std=c++14, works with 7.3, ICEs with 7.4.
Comment 3 Jakub Jelinek 2020-07-22 15:35:34 UTC
Started with r257580.
Comment 4 Martin Liška 2020-07-29 09:07:57 UTC
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?
Comment 5 Patrick Palka 2020-07-31 20:33:08 UTC
Investigating.
Comment 6 CVS Commits 2020-08-05 19:08:22 UTC
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>
Comment 7 Patrick Palka 2020-08-07 12:40:40 UTC
Fixed for GCC 11 so far.
Comment 8 CVS Commits 2021-02-01 13:41:26 UTC
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)
Comment 9 CVS Commits 2021-04-21 21:09:42 UTC
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)
Comment 10 Jakub Jelinek 2021-05-14 14:01:09 UTC
The GCC 8 branch is being closed, fixed in GCC 9.4.