Re: PING [PATCH] accept flexible arrays in struct in unions (c++/71912 - [6/7 regression])

2016-10-13 Thread Martin Sebor 

On 10/12/2016 07:43 AM, Jason Merrill wrote:

On Tue, Oct 11, 2016 at 9:45 PM, Martin Sebor  wrote:

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])

2016-10-12 Thread Jason Merrill 
On Tue, Oct 11, 2016 at 9:45 PM, Martin Sebor  wrote:
> 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])

2016-10-11 Thread Martin Sebor 

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