simon_tatham added a comment. I can't shed as much light as you might hope, I'm afraid, but in D62998 <https://reviews.llvm.org/D62998> my intention was not to make `-mcpu=anything` win over `-mfpu=anything`. It was to make an //explicit// request to enable a feature win over an //implicit// request to disable it. It so happened in my example that the explicit request was in the `-mcpu` option.
In the case you describe here, `-mcpu=cortex-a73 -mfpu=crypto-neon-fp-armv8`, the explicitness goes the other way round. Cortex-A73 might be listed in the CPU table without crypto, but that's not because it //can't// have crypto; it's because the cryptographic extension is an optional feature of the Cortex-A73, so it's just that it //need not// have crypto. So `-mcpu=cortex-a73` doesn't mean "definitely no crypto", it means "I haven't said whether I want crypto yet". And then the FPU specification asks for crypto (and in this case, crypto is even mentioned in the text of the FPU name). So here, it's the FPU specification that is (semi-)explicitly turning the feature //on//. So if a human user had written that command line, I would expect that then they surely //did// want crypto, and would be surprised not to get it. But that's the kind of messy human reasoning you'd like to avoid implementing in software. I don't have a simple, consistent, general rule that gives the right answer to all these fiddly cases. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D63936/new/ https://reviews.llvm.org/D63936 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
