dblaikie added a comment. In D102568#2769395 <https://reviews.llvm.org/D102568#2769395>, @MaskRay wrote:
> In D102568#2769389 <https://reviews.llvm.org/D102568#2769389>, @dblaikie > wrote: > >> In D102568#2769341 <https://reviews.llvm.org/D102568#2769341>, @MaskRay >> wrote: >> >>> I think libvpx's ASFLAGS usage is about GNU as, not the driver option. >>> >>> In D102568#2769296 <https://reviews.llvm.org/D102568#2769296>, @dblaikie >>> wrote: >>> >>>>> I think "waiting for a few releases" is too much and doesn't improve >>>>> things (they will notice issues until you remove the option). I can >>>>> accept "waiting for one major release". >>>> >>>> Having fairly broad windows of not breaking backwards compatibility is a >>>> fairly reasonable request. Take LLVM itself, for instance - which supports >>>> building with Clang back as far as 3.5. (not suggesting we need to have a >>>> window that large for every feature/piece of surface area - but that there >>>> is scope for fairly wide windows) >>> >>> I understand the broad Windows and I also strive for this portability. >>> >>> However, reverting this patch is now a trade-off. It would make >>> x264/openh264's mingw build happy but break musl's arm build (2018-09 ~ ). >>> There can be other projects doing detection on both -mimplicit-it and >>> -Wa,-mimplicit-it and will be broken by reverting this patch. >> >> Not sure I follow - presumably musl's arm build wasn't working with clang >> before this patch? Or something changed there after this patch landed? > > musl's arm build has always been working with clang. It stopped working after > the driver option -mimplicit-it= was added earlier this year. > This patch dropped the driver option/fixed the musl build but broke some > mingw arm projects. Ah, thanks for the history. Yeah, still not sure those bugs are on equal footing - if the patch had been in for a few months before musl was fixed (If they're interested in building from LLVM head - wonder why it took so long & if they aren't, then it doesn't seem like we need to rush to fix this/keep the fix in tree if backing it out and considering how to support both new-ish (self-imposed due to the -mimplicit-it= change) and existing (mingw arm) use cases can be handled gracefully and have it in the next LLVM release or the like). But sounds like there's some possible both-use-cases-work path forward, which is good to see. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D102568/new/ https://reviews.llvm.org/D102568 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
