[LLVMdev] interesting possible compiler bug

[Ronan Keryell]

>>>>> 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. :-)
-- 
  Ronan KERYELL                            |\/  Phone:  +1 408 658 9453
  SILKAN Wild Systems                      |/)
  4962 El Camino Real #201                 K    Ronan.Keryell at silkan.com
  Los Altos, CA 94022                      |\   skype:keryell
  USA                                      | \  http://silkan.com