[llvm-bugs] [Bug 28834] @llvm.objectsize treats allocsize differently than allocas.

via llvm-bugs llvm-bugs at lists.llvm.org
Wed Aug 3 21:02:43 PDT 2016


https://llvm.org/bugs/show_bug.cgi?id=28834

George Burgess <george.burgess.iv at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #1 from George Burgess <george.burgess.iv at gmail.com> ---
So, this is a kind-of dup of PR23301. Moreover, if we actually use `p` and `v`
in the initial repro (so InstCombine doesn't remove them before inlining
happens), we get accurate results for `objectsize`.

The most straightforward way to fix this seems to be "keep the unused
malloc/new/whatever calls around until we *can* get accurate results." I'm not
entirely thrilled with that idea, mostly because I can't think of a real-world
use for a best-effort objectsize of an unused allocation.

Note that the following variant of the repro *does* give us accurate results:

```
void *malloc2(int n) __attribute((alloc_size(1)));

void allocsize(void *p, void *v) {
  g0 = __builtin_object_size(p, 0);
  g1 = __builtin_object_size(v, 1);
}

void allocsize1() {
  allocsize(malloc2(5), malloc2(8));
}
```

So, I'm marking this WONTFIX. I'm happy to revisit this if someone believes
that giving more accurate results in this case would be useful.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160804/b61f599c/attachment.html>


More information about the llvm-bugs mailing list