Bug 90926 - [10 Regression] member char array with string literal initializer causes = {} to fail
Summary: [10 Regression] member char array with string literal initializer causes = {}...
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 7.4.0
: P2 normal
Target Milestone: 10.5
Assignee: Not yet assigned to anyone
Keywords: rejects-valid
Depends on:
Reported: 2019-06-19 10:27 UTC by thomgree
Modified: 2022-06-28 10:37 UTC (History)
3 users (show)

See Also:
Known to work: 5.1.0
Known to fail: 10.0, 5.4.0, 6.1.0, 6.5.0, 7.4.0, 8.3.0, 9.1.0
Last reconfirmed: 2019-06-19 00:00:00


Note You need to log in before you can comment on or make changes to this bug.
Description thomgree 2019-06-19 10:27:54 UTC
minimal example program:

int main()
  struct thing
    char str[100] = "foo";
    //char str[100] = {'f', 'o', 'o', '\0'}; // this is fine though

  thing foo;
  foo = {}; // clang will compile this, but gcc won't

gcc ./test.cpp -Wall -Wextra -Wpedantic

./test.cpp: In function ‘int main()’:
./test.cpp:11:10: error: no match for ‘operator=’ (operand types are ‘main()::thing’ and ‘<brace-enclosed initializer list>’)
   foo = {}; // clang will compile this, but gcc won't
./test.cpp:4:10: note: candidate: constexpr main()::thing& main()::thing::operator=(const main()::thing&)
   struct thing
./test.cpp:4:10: note:   no known conversion for argument 1 from ‘<brace-enclosed initializer list>’ to ‘const main()::thing&’
./test.cpp:4:10: note: candidate: constexpr main()::thing& main()::thing::operator=(main()::thing&&)
./test.cpp:4:10: note:   no known conversion for argument 1 from ‘<brace-enclosed initializer list>’ to ‘main()::thing&&’

According to https://godbolt.org/ this happens on all versions of GCC when -std=c++14 is used (but not -std=c++11).
Comment 1 Jonathan Wakely 2019-06-19 10:49:39 UTC
This started to be rejected with r233947:

            * call.c (build_aggr_conv): Use get_nsdmi.

I'm going to call it a regression, because it used to compile with GCC 5.3 (with any -std option).
Comment 2 Richard Biener 2019-11-14 07:49:01 UTC
The GCC 7 branch is being closed, re-targeting to GCC 8.4.
Comment 3 Jakub Jelinek 2019-11-23 10:37:12 UTC
Seems when init is a STRING_CST (or that with location wrapper around it), we don't call can_convert_array (which only handles initialization of vars with ARRAY_TYPE from CONSTRUCTORs), and can_convert_arg doesn't handle that.
So, shall can_convert_arg handle that special case, initializing of ARRAY_TYPE from STRING_CST, or shall we call can_convert_array in that case which ought to have this as a special case, something else?
Comment 4 Jakub Jelinek 2020-03-04 09:31:27 UTC
GCC 8.4.0 has been released, adjusting target milestone.
Comment 5 thomgree 2021-01-05 11:15:46 UTC
I made a fix for this bug here: https://gcc.gnu.org/pipermail/gcc-patches/2020-December/562259.html
Comment 6 CVS Commits 2021-02-04 15:46:55 UTC
The master branch has been updated by Jason Merrill <jason@gcc.gnu.org>:


commit r11-7102-ge6cc142ad99ab8d28581f4ce61056c9cce74dba3
Author: Tom Greenslade (thomgree) <thomgree@cisco.com>
Date:   Wed Feb 3 11:31:53 2021 +0000

    c++: fix string literal member initializer bug [PR90926]
    build_aggr_conv did not correctly handle string literal member initializers.
    Extended can_convert_array to handle this case. For the additional check of
    compatibility of character types, factored out code from digest_init_r into
    a new function.
            PR c++/90926
            * call.c (can_convert_array): Extend to handle all valid aggregate
            initializers of an array; including by string literals, not just by
            (build_aggr_conv): Call can_convert_array more often, not just in
            brace-init-list case.
            * typeck2.c (array_string_literal_compatible_p): New function.
            (digest_init_r): call array_string_literal_compatible_p
            * cp-tree.h: (array_string_literal_compatible_p): Declare.
            PR c++/90926
            * g++.dg/cpp1y/nsdmi-aggr12.C: New test.
Comment 7 Jason Merrill 2021-02-04 16:39:33 UTC
Fixed on trunk so far.
Comment 8 Jakub Jelinek 2021-05-14 09:51:51 UTC
GCC 8 branch is being closed.
Comment 9 Richard Biener 2021-06-01 08:14:37 UTC
GCC 9.4 is being released, retargeting bugs to GCC 9.5.
Comment 10 Richard Biener 2022-05-27 09:41:06 UTC
GCC 9 branch is being closed
Comment 11 Jakub Jelinek 2022-06-28 10:37:51 UTC
GCC 10.4 is being released, retargeting bugs to GCC 10.5.