aaron.ballman added a comment. In D146973#4225645 <https://reviews.llvm.org/D146973#4225645>, @jhuber6 wrote:
> In D146973#4225641 <https://reviews.llvm.org/D146973#4225641>, @aaron.ballman > wrote: > >>> This lets offloading languages such as OpenMP use the system string.h when >>> compiling for the host and then the LLVM libc string.h when targeting the >>> GPU. >> >> How do we avoid ABI issues when the two headers get sufficiently out of >> sync? (In general, I'm pretty surprised to hear we would want different >> headers for the GPU and the system -- does this affect conformance >> requirements from the C standard?) > > I'm not entirely sure if there's a good method. I think no matter what we do > we'll need to implement some kind of 'glue'. I think most should be fine if > we go by the C-standard. We expect pointer sizes and everything to be > compatible at least. Hmmm, I've had experience with SYCL as to how it goes when you have difference between host and device; those kinds of bugs are incredibly hard to track down. Pointer sizes being compatible is a good start, but you need integer widths, floating point formats, structure layout decisions, macro definitions, etc to all be the same as well. Having only one set of headers that can be used helps users avoid these sort of problems. >> Excuse my ignorance on this point, but is llvm-libc intended to work with >> any compiler other than Clang? (e.g., will other compilers need to do this >> dance as well?) > > Right now the GPU target I'm working on can only be built with `clang` and it > will be that way for the foreseeable future. So we're comfortable painting ourselves into a corner where llvm-libc is only usable with Clang, depending on the target? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D146973/new/ https://reviews.llvm.org/D146973 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
