5 parts of memory read test optimized out by gcc

[Alexey Kopytov]

Reported by Tomas Vondra here: http://sourceforge.net/tracker/?func=detail&atid=631676&aid=3557367&group_id=102348

When the package is compiled with optimizations enabled (e.g. -01 or higher), parts of the memory_execute_request function are optimized out, rendering the test unusable. For example this block

case SB_MEM_OP_READ:
if (buf >= end)
printf("error\n");
for (; buf < end; buf++)
tmp = *buf;
break;

is optimized so that it behaves like this

case SB_MEM_OP_READ:
if (buf >= end)
printf("error\n");
break;

i.e. the actual testing loop does not execute at all, and the reported results are garbage (with large block sizes it usually reaches TB/s). This was verified using gdb.

I've noticed this with default distribution packages in ScientificLinux 6.2/6.x, when using gcc 4.4.6, more precisely

gcc (GCC) 4.4.6 20120305 (Red Hat 4.4.6-4)
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

How to reproduce:

$ ./configure CFLAGS="-O1" ; make clean; make
$ sysbench --test=memory --memory-oper=read --memory-block-size=10240000 run

This reports 26486520.31 MB/sec (i.e. 26 TB/s) - I'd love to have such HW but I don't. With -O0 I do get 4539.11 MB/sec which seems reasonable.