jhuber6 added a comment. In D146973#4227433 <https://reviews.llvm.org/D146973#4227433>, @aaron.ballman wrote:
> I am not asking you to implement a library based off another implementation's > specification. I am relaying implementation experience with the design you've > chosen for your implementation and how well it's worked in other, related > projects. Given that two different technologies have both run into this same > problem, I think the llvm-libc folks should carefully consider the design > decisions here. If it turns out this is the best way forward, that's fine. Sorry, that was more directed at Johannes, This is definitely a hard problem. Each approach has certain benefits, but I think keeping the headers synced like we do in OpenMP has mainly worked thus far because we don't have any actual implementations of most of it. If we want to provide a library I don't think there's a reasonable way to implement it as a unified header unless we control the system header as well. I'm hoping that `libc` offers a sufficiently small surface that we should be able to provide functionality that's expected for both. And in some cases it should be fine to share existing headers, but it shouldn't be the expected route it all I'm saying. > I'm not asking you to copy other libc headers. I'm pointing out that having > two separate headers, one for host and one for device, is a recipe for > problems in practice because these two will invariably get out of sync in > really fascinating ways that are extremely hard for people to debug. But > maybe there's a misunderstanding here: I am assuming we consider it to be > unsupported to use glibc/musl/etc on the host and llvm-libc on the device, > but maybe that's a faulty assumption. We can't do that for the time being, since LLVM's `libc` is still in development. It's not a sufficient replacement for the host `libc` at this point. It may be an interesting point to get to in the future, it would make it much easier to keep things in sync for sure. It may be easier to stipulate something like that with `libc++` when we get to that point since `libc++` is more complete as far as I'm aware. 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
