Eric Botcazou <botca...@adacore.com> writes: >> It looks like the latter - I've seen no attempt by the original authors to >> make the feature work on more targets than they cared for. > > On the other hand, if you hide the failures, there is essentially zero chance > that architecture maintainers pick up the pieces (I personally implemented > the > SPARC support only because I had ran into the failures in the testsuite). So > doing the inverse filtering sounds quite counterproductive to me and IMO it's > up to the architecture maintainers to decide on a case-by-case basis.
Sorry for the late reply, but +1 FWIW. As Jakub says, this feature doesn't necessarily need work for each target. It doesn't for aarch64, for example, and likely doesn't for several others. But if it does need work, that work requires target-specific knowledge. It isn't reasonable or fair to expect one person to learn enough about each architecture to do the right thing for that architecture. And this isn't new. I've often seen even long-standing GCC developers say things like “I don't know enough about target X to do that. I'll have to leave it to someone who knows about target X”. One of the decisions for maintainers is whether they care about this feature at all. If they don't, they can get GCC to emit a “sorry, not supported”. This decision will be based on maintainer knowledge about how the architecture is used in practice. If maintainers do care, the question then is: which registers should be covered? And what's the best way of zeroing them in the constrained situation that the option is dealing with? (The default does the “obvious” thing in both cases. Intervention is only needed if the default isn't right.) In other words, the ball isn't IMO in the original author's court here. So personally I object to the second patch. I think the first was the right way to go. As it stands we're hiding ICEs through skips rather than xfails, and without a specific list of FIXMEs. Thanks, Richard
