For what it's worth, I will be at the social tonight, and am happy to discuss this paper. I'm a co-author and the instigator the work here to clarify the spec and allow a large number of exciting optimizations on code that have previously not be employed merely because of the use of malloc rather than (for example) alloca.<div class="gmail_extra">
<br><br><div class="gmail_quote">On Thu, Oct 4, 2012 at 4:40 PM, reed kotler <span dir="ltr"><<a href="mailto:rkotler@mips.com" target="_blank">rkotler@mips.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
They have been discussing this for a solid two days on the C committee list with many pro and con opinions, all supported by various parts of the standard or other sources.<br>
<br>
My personal opinion is that it's only a bug if some real program can be made to fail because of this.<br>
<br>
If I were writing this test case for LPT, I would call an external function and pass the value curr to it.<br>
<br>
If I was really paranoid about compiling it with an -O4 compiler, I would write an assembly language program.<br>
<br>
Back in the day, in the ACVS (Ada compiler validation suite), they used to call functions that were noops but that had some complex recursion that no compiler could unwind and realise that it was a noop. So that is probably the safest. I can't remember anymore the exact form of these recursive functions in the suite as it was 28 years ago that I worked with that suite.<br>
<br>
On 10/04/2012 04:21 PM, Ronan Keryell wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, 1 Oct 2012 19:40:58 -0700, Nick Lewycky <<a href="mailto:nlewycky@google.com" target="_blank">nlewycky@google.com</a>> said:<br>
</blockquote></blockquote></blockquote></blockquote></blockquote>
> On 1 October 2012 18:34, reed kotler <<a href="mailto:rkotler@mips.com" target="_blank">rkotler@mips.com</a>> wrote:<br>
> This code is essentially from an LTP test (<br>
> <a href="http://ltp.sourceforge.net/" target="_blank">http://ltp.sourceforge.net/</a> ).<br>
<br>
> #include <stdlib.h><br>
> int main() { void *curr;<br>
> do { curr = malloc(1); } while (curr);<br>
> return 0;<br>
> }<br>
<br>
> If you compile it with no optimization, it will keep the<br>
> malloc calls.<br>
<br>
> If you compile it with -O2, it will create an infinite<br>
> loop, i.e. assuming that malloc always returns a non zero<br>
> result and the result is not used.<br>
<br></div>
Nick> As far as I know, this optimization is legal.<br>
<br>
Well, indeed the result is used by the while and we have a control<br>
dependence on the future execution. The termination or not of the<br>
program is a side effect from the user perspective.<br>
<br>
[...]<br>
<br>
Nick> Oh how people don't appreciate the luxury of having an<br>
Nick> infinite memory machine!<br>
<br>
You have also a potentially infinite loop, which is another kind of<br>
luxury. More boring, especially on the end. :-)<br>
<br>
Even if you have a lazy allocation as with the default libC on Linux<br>
that allocates the memory pages only on demand, the memory will blow<br>
up just because the malloc() library itself has to track the allocations<br>
for a potential future free(). Of course, if you have an infinite<br>
memory, you can avoid implementing free() or your interprocedural<br>
analysis may prove you do not call free() in your program. :-)<br>
<br>
This makes me feel uncomfortable to have this kind of optimizations with<br>
too many hypothesis on the run-time, even if it addresses domains not<br>
well captured by the norm...<br>
<br>
How to know about the real target? It may be another allocation library,<br>
some LD_PRELOAD hack to insert memory verification code or at the end<br>
the code is to be run inside a tool like valgrind to track this very<br>
malloc() bug that would be hidden by this optimization... :-(<br>
<br>
Just to give an example from another compiler, in the PIPS<br>
source-to-source compiler the side effect of malloc() is taken into<br>
account by registering a write effect on an abstract location which is<br>
tested later by some optimization phases to avoid too much liberal<br>
optimizations, like the one above.<br>
<br>
Anyway, this is an interesting limit case to discuss tonight at the LLVM<br>
Bay-area Social. :-)<br>
</blockquote><div class="HOEnZb"><div class="h5">
<br>
______________________________<u></u>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br></div>