[hjl@gnu-6 build]$ cat x.c struct foo { char x[128]; unsigned* i; }; struct foo x = { i: 0 }; [hjl@gnu-6 build]$ gcc -S x.c [hjl@gnu-6 build]$ g++ -S x.c x.c:7:1: sorry, unimplemented: non-trivial designated initializers not supported [hjl@gnu-6 build]$
So? Do we have a plan of filing a PR for each sorry message?
why does struct foo x = { i: 0 }; work?
BTW, clang works fine: [hjl@gnu-6 tmp]$ /opt/llvm.old/bin/clang -c i.c i.c:6:5: warning: use of GNU old-style field designator extension [-Wgnu-designator] i: 0 ^~ .i = 1 warning generated. [hjl@gnu-6 tmp]$
[hjl@gnu-6 tmp]$ cat i.cc struct foo { char x[128]; unsigned* i; }; struct foo x = { .i = 0 }; [hjl@gnu-6 tmp]$ /opt/llvm.old/bin/clang -c i.cc [hjl@gnu-6 tmp]$ g++ -c i.cc i.cc:7:1: sorry, unimplemented: non-trivial designated initializers not supported [hjl@gnu-6 tmp]$
This works: [hjl@gnu-6 tmp]$ cat i.cc struct foo { char x[128]; unsigned* i; }; struct foo x = { "foo", .i = 0 }; [hjl@gnu-6 tmp]$ g++ -c i.cc [hjl@gnu-6 tmp]$
I'm not saying that some work should not be done, I'm saying that sorry message normally correspond to *known* issues, we don't need PRs for those, more or less by definition. But what can I tell you, if you like to have a PR for this, let's have it.
Confirmed.
This is being proposed for C++14: https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/IgDFqKjKlRs http://htmlpreview.github.io/?https://raw.github.com/CTMacUser/multiarray-iso-proposal/master/designation-proposal.html
A similar test case not involving arrays: $ cat z.c && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -S -Wall -Wextra -o/dev/null -xc++ z.c typedef struct A { int i; struct { int a, b; } s; } A; A a = { 1, .s = { 2, 3 } }; A b = { .i = 1, .s = { 2, 3 } }; A c = { .s = { 2, 3 }, .i = 1 }; z.c:8:31: sorry, unimplemented: non-trivial designated initializers not supported A c = { .s = { 2, 3 }, .i = 1 }; ^ z.c:8:31: sorry, unimplemented: non-trivial designated initializers not supported
*** Bug 77547 has been marked as a duplicate of this bug. ***
This now works with gcc 8. I haven't tried other versions.
(In reply to Martin Sebor from comment #9) > A similar test case not involving arrays: > > $ cat z.c && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -S > -Wall -Wextra -o/dev/null -xc++ z.c > typedef struct A { > int i; > struct { int a, b; } s; > } A; > > A a = { 1, .s = { 2, 3 } }; > A b = { .i = 1, .s = { 2, 3 } }; > A c = { .s = { 2, 3 }, .i = 1 }; > z.c:8:31: sorry, unimplemented: non-trivial designated initializers not > supported > A c = { .s = { 2, 3 }, .i = 1 }; > ^ > > z.c:8:31: sorry, unimplemented: non-trivial designated initializers not > supported This fails differently: b.cc:8:31: error: designator order for field 'A::i' does not match declaration order in 'A' A c = { .s = { 2, 3 }, .i = 1 }; ^ But commenting out that line makes the rest work fine.
C++20 added this support, G++ supports mixing styles by default but not out of order. It was explicitly decided not support out of order. So closing as fixed for GCC 8.