[LLVMdev] interesting possible compiler bug

[reed kotler]

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.

My personal opinion is that it's only a bug if some real program can be 
made to fail because of this.

If I were writing this test case for LPT, I would call an external 
function and pass the value curr to it.

If I was really paranoid about compiling it with an -O4 compiler, I 
would write an assembly language program.

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.

On 10/04/2012 04:21 PM, Ronan Keryell wrote:
>>>>>> On Mon, 1 Oct 2012 19:40:58 -0700, Nick Lewycky <nlewycky at google.com> said:
>      > On 1 October 2012 18:34, reed kotler <rkotler at mips.com> wrote:
>      >     This code is essentially from an LTP test (
>      > http://ltp.sourceforge.net/ ).
>
>      >     #include <stdlib.h>
>      >     int main() {   void  *curr;
>      >       do {     curr = malloc(1);   } while (curr);
>      >       return 0;
>      >     }
>
>      >     If you compile it with no optimization, it will keep the
>      > malloc calls.
>
>      >     If you compile it with -O2, it will create an infinite
>      > loop, i.e.  assuming that malloc always returns a non zero
>      > result and the result is not used.
>
>      Nick> As far as I know, this optimization is legal.
>
> Well, indeed the result is used by the while and we have a control
> dependence on the future execution. The termination or not of the
> program is a side effect from the user perspective.
>
>     [...]
>
>      Nick> Oh how people don't appreciate the luxury of having an
>      Nick> infinite memory machine!
>
> You have also a potentially infinite loop, which is another kind of
> luxury. More boring, especially on the end. :-)
>
> Even if you have a lazy allocation as with the default libC on Linux
> that allocates the memory pages only on demand, the memory will blow
> up just because the malloc() library itself has to track the allocations
> for a potential future free(). Of course, if you have an infinite
> memory, you can avoid implementing free() or your interprocedural
> analysis may prove you do not call free() in your program. :-)
>
> This makes me feel uncomfortable to have this kind of optimizations with
> too many hypothesis on the run-time, even if it addresses domains not
> well captured by the norm...
>
> How to know about the real target? It may be another allocation library,
> some LD_PRELOAD hack to insert memory verification code or at the end
> the code is to be run inside a tool like valgrind to track this very
> malloc() bug that would be hidden by this optimization... :-(
>
> Just to give an example from another compiler, in the PIPS
> source-to-source compiler the side effect of malloc() is taken into
> account by registering a write effect on an abstract location which is
> tested later by some optimization phases to avoid too much liberal
> optimizations, like the one above.
>
> Anyway, this is an interesting limit case to discuss tonight at the LLVM
> Bay-area Social. :-)