mstorsjo wrote: > 2. I think the Clang Area Team should evaluate the complexity this PR > introduces to Clang, as it's not just a driver option.
Sure, whether the complexity introduced is acceptable clearly is something that needs to be evaluated, and if the complexity is high it can be reasonable to defer to the Clang Area Team. > arm64ec is indeed designed for compatibility and consistency, but not with > MinGW, rather, with MSVC. Well when Microsoft designed arm64ec, they obviously didn't care think about mingw interop, nobody claims that. But if you are building code with an arm64ec mingw target triple, the assumption is that it is binary compatible with x86_64 mingw. There is generally limited ability for interop between mingw and msvc object files/DLLs anyway - the C++ ABIs are entirely different, there are various nuances elsewhere that differ (e.g. the `-export:` embedded COFF directives for i386 differ in whether the leading underscore is implicit or explicit), the C runtimes have implemented things differently with what's done inline in headers vs statically linked in the import libraries. Interop between MSVC and mingw works across DLL boundaries, with C-only APIs. Linking object files or static libraries from one environment in the other environment is not assumed to work (and if it does, that's a lucky coincidence). > If a program is difficult to port to aarch64 so arm64ec is needed, you can > almost assume it lacks good cross-platform design and relies on MSVC. If it > can be compiled with MinGW, it’s hard to imagine why it couldn’t be ported to > aarch64. This doesn't have anything to do with the matter at hand. Yes if you can rebuild everything for aarch64, that's great. But you may also wish to load a binary x86_64 plugin DLL, or you may wish to provide an arm64ec plugin to a host x86_64 executable, etc. The use case for arm64ec is indeed mostly quite niche, and if most people don't need to use it, that's best. But if you do build for an arm64ec target, the architecture of arm64ec is such that you can mix and match arm64ec and x86_64 object files as you wish, even within one single DLL. > If we truly care about consistency and compatibility, then rather than create > new consistency and compatibility issue to address existing one, we should > address all consistency and compatibility issues at once. This PR does not create a new consistency issue. There is no implied compatibility across arm64ec mingw vs msvc as things stand. > I used an LLM to generate a table to show the differences between the two > methods: As one who has spent a significant amount of work in this area, I would love if x86_64 (and i386) wouldn't use the 80 bit long doubles. But I'm not willing to put in the effort to try to change the whole mingw ecosystem (including changing defaults across GCC, and/or possibly for all relevant downstream distributors) on x86 to a different form of long doubles. https://github.com/llvm/llvm-project/pull/237057 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
