dblaikie added a comment. In D85802#3880078 <https://reviews.llvm.org/D85802#3880078>, @mcgrathr wrote:
> In D85802#3879950 <https://reviews.llvm.org/D85802#3879950>, @dblaikie wrote: > >> In D85802#3879888 <https://reviews.llvm.org/D85802#3879888>, @mcgrathr wrote: >> >>> In D85802#3876106 <https://reviews.llvm.org/D85802#3876106>, @dblaikie >>> wrote: >>> >>>>> The C++ ABI is not part of the Fuchsia system ABI, nor what we call the >>>>> "Fuchsia compiler ABI". Different users of C++ are free to use whatever >>>>> C++ ABI they like. Only the backend ABI independent of language-specific >>>>> issues is necessary to interoperate with other code on Fuchsia. >>>> >>>> Sure enough - but I'm still sort of confused by why the Fuschia Clang >>>> target/compiler needs more than one C++ ABI. What is it interoperating >>>> with? (GCC doesn't have a Fuschia target implemented, does it? So what's >>>> it mean to target the GCC C++ ABI? what is compiling the code that Fuschia >>>> is trying to interoperate with when Clang targets Fuschia with a >>>> non-default C++ ABI?) >>> >>> When we use GCC we're using the generic ELF targets. I think it's >>> sufficient for us to tell you that indeed we do want the option of multiple >>> C++ ABIs to select from without justifying everything about our work to a >>> Clang reviewer before we can proceed with meeting the requirements of our >>> system. >> >> Would the generic ELF target support in Clang be adequate to meet that >> requirement, then? (so Fuschia target could be the custom C++ ABI (& custom >> C ABI if you likee) and a generic ELF target could be used for GCC ELF >> compatibility) - then we wouldn't need any C++ ABI customizability? > > No. All the aspects of the Fuchsia target not specific to C++ we still want > done the same way when interoperating with this code. What sort of aspects does that include? Those aspects wouldn't be respected by the other side of that ABI boundary, built with GCC, right? > We're quite confident that what we want is a Fuchsia target with multiple > options for the C++ ABI. If you don't want that flexibility to be available > to other targets, then fine (though I think that's a poor choice, > personally). Second-guessing everything about how we're organized our system > and build is not a very helpful tactic in compiler reviews. It would be much > appreciated if this review were constrained to how the compiler should work > rather than what we should want to do. LLVM reviews do include design discussions about what's appropriate to include and support in the LLVM project. It's not about second guessing your choices, but about understanding them & discussing how they best fit (or don't) in the LLVM project. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D85802/new/ https://reviews.llvm.org/D85802 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
