On Tue, Mar 21, 2017 at 11:08 AM, Martin Sebor <mse...@gmail.com> wrote: > On 03/20/2017 10:27 PM, Jason Merrill wrote: >> >> On Mon, Mar 20, 2017 at 7:58 PM, Martin Sebor <mse...@gmail.com> wrote: >>> >>> On 03/20/2017 05:51 PM, Jason Merrill wrote: >>>> >>>> On Mon, Mar 20, 2017 at 7:04 PM, Martin Sebor <mse...@gmail.com> wrote: >>>>> >>>>> >>>>> Attached is a minimal patch to avoid an ICE in CHKP upon >>>>> encountering one form of an initializer for a flexible array >>>>> member, specifically the empty string: >>>>> >>>>> int f () >>>>> { >>>>> struct B { int n; char a[]; }; >>>>> >>>>> return ((struct B){ 1, "" }).a[0]; >>>>> } >>>>> >>>>> Although GCC accepts (and doesn't ICE on) non-empty initializers >>>>> for flexible array members, such as >>>>> >>>>> (struct B){ 1, "123" } >>>> >>>> How do you mean? When I compile this with the C front end, I get >>>> >>>> error: non-static initialization of a flexible array member >>> >>> I meant that G++ accepts it, doesn't ICE, but emits wrong code. >>> (it's consistently rejected by the C front end). Sorry for not >>> being clear about it. >> >> Ah, OK. It seems to me that the wrong code bug is worth addressing; >> why does rejecting the code seem risky to you? > > I have a few reasons: First, it's not a regression (I raised > bug 69696 for it in early 2016) so strictly it's out of scope > for this stage. Second, there are a number of bugs related > to the initialization of flexible array members so the fixes > are probably not going to be contained to a single function > or file. Third, the flexible member array changes I made in > the past were not trivial, took time to develop, and the two > of us iterated over some of them for weeks. Despite your > careful review and my extensive testing some of them > introduced regressions that are still being patched up. > Fourth, making a change to reject code this close to a release > runs the risk of breaking code that has successfully compiled > in mass rebuilds and others' tests with the new compiler. > While that could be viewed as a good change for invalid code > that's exercised at run time, it could also break programs > where the bad code is never exercised.
Fair enough. But I think the ICE is preferable to wrong code. Jason