<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">I'll be at the social tonight wearing
my black Institute of Martial Arts t-shirt.<br>
<br>
On 10/04/2012 05:11 PM, Chandler Carruth wrote:<br>
</div>
<blockquote
cite="mid:CAGCO0Kj33=BT3FvBNoQEbpcns7YLKNXAfwGejWAjnycrmTtiFw@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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
moz-do-not-send="true" href="mailto:rkotler@mips.com"
target="_blank">rkotler@mips.com</a>> wrote:<br>
> This code is essentially from an LTP test
(<br>
> <a moz-do-not-send="true"
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>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a moz-do-not-send="true"
href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>
<a moz-do-not-send="true"
href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a moz-do-not-send="true"
href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev"
target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>