https://github.com/bwendling closed
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
zygoloid wrote:
It might be academic at this point, but for what it's worth,
`__builtin_dynamic_object_size` is not a GCC builtin that clang copied, it's [a
clang builtin](https://reviews.llvm.org/D56760) that GCC copied.
https://github.com/llvm/llvm-project/pull/78526
efriedma-quic wrote:
> ```c
> struct x {
> int a;
> char foo[2][40];
> int b;
> int c;
> };
>
> size_t f(struct x *p, int idx) {
> return __builtin_dynamic_object_size(>foo[idx], 1);
> }
> ```
If I'm following correctly, the return here is 0, 40, or 80, depending on the
efriedma-quic wrote:
> maybe we could add the subtype as part of the llvm.objectsize intrinsic and
> use that instead of grappling with the whole object's type
I'm not sure I follow; if you know the object's type, doesn't that mean you
also know its size?
>(I don't readily know of any
zygoloid 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.
zygoloid wrote:
> > But mode 0 and 1 are in general asking for an upper bound on the accessible
> > bytes (that is, an N so any.access beyond N bytes is definitely out of
> > bounds), so it seems to me that returning -1 is strictly worse than
> > returning 48.
>
> It's the second bit that
bwendling wrote:
> @bwendling I think you are reading the GCC docs too pedantically. In
> particular, they also say
> > If there are multiple objects ptr can point to and all of them are known at
> > compile time, the returned number is the maximum of remaining byte counts
> > in those
nikic wrote:
@bwendling I think you are reading the GCC docs too pedantically. In
particular, they also say
> If there are multiple objects ptr can point to and all of them are known at
> compile time, the returned number is the maximum of remaining byte counts in
> those objects if type & 2
zygoloid wrote:
> When you say that we can't detect what the front-end considers the "closest
> surrounding subobject" to be, is that mostly due to corner cases or is it a
> more general concern?
It's a more general concern: LLVM simply has no idea what the frontend
considers to be a
https://github.com/nikic requested changes to this pull request.
Using anything but the size and alignment of the alloca type in a way that
affects program semantics is illegal.
https://github.com/llvm/llvm-project/pull/78526
___
cfe-commits mailing
10 matches
Mail list logo
