rsmith added a comment. In D67678#1836668 <https://reviews.llvm.org/D67678#1836668>, @dexonsmith wrote:
> In D67678#1836628 <https://reviews.llvm.org/D67678#1836628>, @steven_wu wrote: > > > In D67678#1834957 <https://reviews.llvm.org/D67678#1834957>, @rsmith wrote: > > > > > In D67678#1834542 <https://reviews.llvm.org/D67678#1834542>, @steven_wu > > > wrote: > > > > > > > @rsmith This also breaks macOS SDK. Can we revert this as we discuss a > > > > less aggressive option? > > > > > > > > > Do you have a timeline for how long it would take to fix the MacOS SDK? > > > Is this something we could realistically aim to do in Clang 11 instead? I > > > would really prefer for us to not have different defaults for Darwin > > > versus everywhere else, so if waiting one release cycle is enough, that > > > seems fine. > > > > > > I am also not sure if we have rules about SDK compatibility for releases > > and I can't say macOS SDK can definitely be fixed before clang 11 release. > > @dexonsmith @arphaman might have more info. > > > We can't comment on future releases. > > That said, if this is urgent, let @arphaman know and we can try to qualify > internally sometime in the next few months and we can report back what issues > we find. Understood. The current situation is deeply unpalatable (the conversions we allow by default that this patch would have disabled are *evil* and have never been supported by GCC; it looks like Clang only ever allowed them as a bug, and we really need to turn them off by default for safety as much as for GCC compatibility). But this isn't a regression, at least, so I don't think this is especially urgent. (I was working on this because Agner Fog made an impassioned plea that we fix this, and I think our community owes Agner a favor or two...) If there's no timeline to update the macOS SDK, then perhaps we could add a hack to Clang to allow these conversions only in limited contexts (the specific parts of the macOS SDK that are relying on them). Do you know how many such places there might be? If it's just a few functions, we could match against the function names, or depending on what `SIMD_CFUNC` expands to, perhaps we could match that. Failing that, we could set a platform-specific default or similar. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D67678/new/ https://reviews.llvm.org/D67678 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
