[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