https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80108
--- Comment #7 from kelvin at gcc dot gnu.org --- I'll pursue the recommendations offered by Michael and Bill. Aside: as I read the existing implementation, I believe the more "consistent" behavior would be to behave as suggested in my original "proposal". I don't feel strongly about this, and I may have misunderstood some of the existing code. Here is my current understanding of how this behaves in general: 1. If someone specifies a particular CPU option (e.g. -mcpu=405), this has the effect of setting a bunch of target options "implicitly". 2. If someone specifies a particular target option explicitly (-mpower9-minmax), this has the effect of setting a bunch of additional target options on which this option depends, and marking all of these dependent target options as explicit, UNLESS any of the dependent target options have been "explicitly" disabled, in which case we issue an error message and quit. Feel free to correct my understanding if I'm still confused about this. If we feel that -mcpu=405 -mpower9-minmax should be an error, there are probably a bunch of other option combinations that we should probably treat as errors as well, whereas today we may be "fixing up the inconsistencies" silently. In terms of "fixing this mess", I've been thinking the "right way" to handle all the target options would be to "auto-generate" rs6000_option_override_internal from tables that describe in a more manageable way the lattice of dependencies between all of the different target options. That would be the best way to enforce consistent handling of everything. But it would require some "effort" and would probably break existing behavior... :(
