On 3/14/19 7:47 PM, Martin Sebor wrote: > To copy type attributes from struct A, the copy attribute (new > in GCC 9) accepts a pointer argument such as (struct A*)0, but > it isn't prepared for anything much more complicated than that. > So for example when it's passed something like (struct A*)(0, 1) > as the test case in PR 89685 does (a P1 regression), it fails > with an ICE. > > The attached patch makes this handling more robust by letting > it accept all forms of type and member references. > > Tested on x86_64-linux. > > Martin > > gcc-89685.diff > > PR c/89685 - ICE on attribute copy with a compound expression > > gcc/c-family/ChangeLog: > > PR c/89685 > * c-attribs.c (handle_copy_attribute): Handle references and > non-constant expressions. > > gcc/testsuite/ChangeLog: > > PR c/89685 > * gcc.dg/attr-copy-8.c: New test. > * g++.dg/ext/attr-copy-2.C: New test. So after further review of the patch, the associated documentation and discussions, I'm going to ACK this for the trunk.
The documentation on this is reasonably clear in specifying how it applies to expressions (by digging through the expression's type). It doesn't in any way imply the attribute is associated with the expression. Things like front-end folding of constant expressions and potentially array decaying could result in inconsistencies. I think we can reasonably address these if they turn out to be an issue in practice. Note I think the decision here impacts the decision around builtin_has_attribute. Martin has an update for that on the immediate horizon -- my inclination is to go forward with that, perhaps after some documentation clarifications. Jeff