On 2/21/19 3:39 PM, Martin Sebor wrote: > On 2/21/19 1:27 PM, Jeff Law wrote: >> On 2/21/19 1:12 PM, Martin Sebor wrote: >>> On 2/21/19 12:08 PM, Jeff Law wrote: >>>> On 2/18/19 7:53 PM, Martin Sebor wrote: >>>>> Please let me know what it will take to get the fix for these two >>>>> issues approved. I've answered the questions so I don't know what >>>>> else I'm expected to do here. >>>>> >>>>> https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00793.html >>>> I think there is still a fundamental disagreement about whether or not >>>> this should be handling expressions. Without an agreement on that it's >>>> hard to see how this could go forward. >>> >>> I think it's wrong to hold up a fix for an ICE because you don't >>> like the current design. The built-in successfully handles common >>> expressions (see c-c++-common/builtin-has-attribute-5.c). It just >>> fails for some of the less common ones. Not fixing those will only >>> penalize users who run into the ICE, and cast a bad light on >>> the quality of the release. Any design questions should be >>> settled separately of these ICEs (should have been when >>> the feature was being reviewed). >>> >>> That said, I have explained the rationale for the current design. >>> Neither you nor Jakub has explained what you find wrong with it or >>> why either of your alternatives is preferable. You said it should >>> be an error to apply the built-in to expressions (why?). Jakub >>> thought there perhaps should be two built-ins, one for expressions >>> and another for decls. His rationale? The current design is not >>> good. Clearly, the two of you don't agree on what you'd like to >>> see; the only thing you agree on is that you don't like what's >>> there now. What do you expect me to do with that, now at the end >>> of stage 4? >> Fix the ice in another way. Handling expressions here seems >> fundamentally wrong. ISTM that making this query on an expression >> should result in an immediate error. > > Sorry but "it seems wrong" is not a compelling argument. You need > to explain what you think is wrong with it. Attributes on expressions seems fundamentally broken. Jakub has raised this issue as well. If you want things to move forward you need to address this fundamental issue.
> > The built-in is modeled on the sizeof, alignof, and typeof operators. > The manual documents like this: Understood, but that makes it rather different from most (all?) other attributes. Attributes apply to decls and types, not expressions. > > bool __builtin_has_attribute (type-or-expression, attribute) > > ...The type-or-expression argument is subject to the same > restrictions as the argument to typeof (see Typeof). > > It was reviewed and approved with no objections to the API. ANd I botched that. Mistakes happen. Jeff
