bwendling wrote: > > My answer for the question "what's the semantics of GCC's builtin X?" has > > always been "whatever GCC does." It's the best we can rely upon. But then > > we get into situations like this, where you and @nikic have one > > interpretation of their documentation and I have another. I can point to > > their behavior to back up my claim, but in the end it's probably not > > exactly clear even to GCC. > > [@nikic > demonstrated](https://github.com/llvm/llvm-project/pull/78526#issuecomment-1900439850) > that our current behavior is already compatible with GCC's behavior. If > GCC's behavior is the spec, then we are allowed to return 48 rather than only > 40 or -1 (or presumably 0 if `argc` is out of bounds) for the original > example, because in some cases GCC does so.
No, he exposed a fluke in their implementation. I gave examples of where clang gets it wrong, and yet I apparently haven't "proven" anything according to this logic? > > My concern is that we want to use this for code hardening. Without precise > > object sizes, we're hampered in our goal. The unfortunate reality is that > > we can only get that size via these `__builtin_[dynamic_]object_size` > > functions. > > That's a totally understandable desire, but I think it's not realistic to > expect precise _sub_object sizes in the same cases that GCC can provide them, > due to the different architectural choices in the two compilers. If we had a > mid-level IR for Clang that still had frontend information, we could do > better by evaluating BOS there, so maybe that's one long term path forward to > consider. And in the short term, while there are cases where we won't be able > to match GCC, I think Clang should do better than it currently does in the > frontend, We're not talking about something like inline asm, where the internals of their register allocator is more-or-less exposed to the user, and therefore it's next to impossible for us to replicate all of it. This feature is far simpler, and should be something we can determine based on all of the information we're given. > specifically in cases like the one in the bug report where there's an obvious > better answer that doesn't require any sophisticated analysis to discover. What "obvious better answer" is that? https://github.com/llvm/llvm-project/pull/78526 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
