mcgrathr added a comment. You've said you want to avoid expressing the C++ ABI as a generic switch orthogonal to target because people can use it when it's not what they actually want or isn't actually useful to attempt. This is true of all switches affecting ABI and they haven't all been rejected on this basis. But fine, consistency is the hobgoblin of small minds. If the concern there is either user confusion or support burden for configurations nobody wants to test, then both of those are easily addressed by having `-fc++abi=` constrain the settings it allows based on target. For Fuchsia targets, we want to maintain and test both "fuchsia" and "compat" (or "itanium") modes. If for other targets the only setting allowed is the one that's the default, or if using non-default settings generates a scare warning or suchlike, that's fine. That seems to be the natural way to constrain the explicit control of the C++ ABI to the supported cases, while not conflating control of the C++ ABI with the language-independent platform ABI being targeted.
You've said you want to avoid a proliferation of explicit switches for specific per-target C++ ABI selections. This is in fact the original rationale for `-fc++abi=`. Instead you've proposed a proliferation of specific per-target pseudo-tuples. This is exactly equivalent in material effect except that it's more hidden because possible tuples don't appear in `--help` output like separate switches do. It's worse in the abstract sense of correctness and in the self-documenting sense of being misleading and confusing by conflating the language-specific ABI with the platform ABI. You've cited the precedent of the mingw tuples. I'm not sufficiently familiar with the mingw cases to know whether they in fact are about nothing but the language ABI or are in fact actually about properly different platform ABIs in some other sense. If the latter, then your proposal exemplifies and worsens the kind of confusion between platform ABI (which tuples are explicitly about and always have been) with language ABI (which is outside the scope of what tuples were specified to describe) that I'm objecting to. If the former, then this bad precedent is a sign this problem has already caused the confusion I warned about and IMHO a precedent of doing the wrong thing is not a reason to compound the error. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D93668/new/ https://reviews.llvm.org/D93668 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
