Re: PING [PATCH] accept flexible arrays in struct in unions (c++/71912 - [6/7 regression])
On 10/12/2016 07:43 AM, Jason Merrill wrote: On Tue, Oct 11, 2016 at 9:45 PM, Martin Seborwrote: Are there any other changes you want me to make to the patch? I leave this weekend for the WG14 meeting and would like to get this change finalized and hopefully committed before then. https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00410.html OK, thanks. Sorry I overlooked your earlier mail. I forgot to also request approval to backport it to the 6 branch. Are you fine with that as well? Thanks Martin
Re: PING [PATCH] accept flexible arrays in struct in unions (c++/71912 - [6/7 regression])
On Tue, Oct 11, 2016 at 9:45 PM, Martin Seborwrote: > Are there any other changes you want me to make to the patch? > I leave this weekend for the WG14 meeting and would like to > get this change finalized and hopefully committed before then. > > https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00410.html OK, thanks. Sorry I overlooked your earlier mail. Jason
PING [PATCH] accept flexible arrays in struct in unions (c++/71912 - [6/7 regression])
Jason, Are there any other changes you want me to make to the patch? I leave this weekend for the WG14 meeting and would like to get this change finalized and hopefully committed before then. https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00410.html Thanks Martin On 10/06/2016 02:29 PM, Martin Sebor wrote: I'm asking you to clarify the logic. It seems that your change to fldtype affects these two tests: if (eltype == fldtype || TYPE_UNNAMED_P (eltype)) if (TREE_CODE (fldtype) != ARRAY_TYPE) ...but this is extremely subtle. It would be a lot clearer to check fld for FIELD_DECL or TYPE_DECL explicitly rather than relying on these places that treat fldtype as a type to do the right thing because you've obfuscated it. But I'm tired of going back and forth on this, so here's a patch. And now that I notice it, there seems to be no reason to handle typedefs deep in the code for handling fields, it's simpler to handle them up top. I'm sorry you're frustrated. I have no problem changing the code to the way you wrote it. I agree it's more streamlined though I would be hard pressed to consider the improvement to be worth the time and effort we both put into it. I'm also not sure I see how someone can be expected to write the code exactly the way you want based on little more than questions about why the code does what it does. I had no idea what your expectation was for the fldtype variable for instance. Attached is the integrated patch. Martin