dexonsmith added a comment. In D67678#1836922 <https://reviews.llvm.org/D67678#1836922>, @rsmith wrote:
> 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...) Yeah, it definitely seems like a good change. > 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. A hack like this sounds pragmatic to me. An initial look suggests it's a small number of frameworks; I suspect many functions, but we could potentially match on partial file path or `SIMD_CFUNC`. We need a deeper audit across our internal stack to be sure, though. I don't think we'll have bandwidth for that until ~late February. 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
