llc miscompiles Obsequi on x86

[Quuxplusone]

Bugzilla Link	PR338
Status	RESOLVED INVALID
Importance	P normal
Reported by	John T. Criswell (jtcriswel@gmail.com)
Reported on	2004-05-11 11:48:45 -0700
Last modified on	2010-02-22 12:41:18 -0800
Version	trunk
Hardware	PC Linux
CC	llvm-bugs@lists.llvm.org
Fixed by commit(s)
Attachments	bugpoint.test.ll (24770 bytes, text/plain) bugpoint.safe.ll (463480 bytes, text/plain)
Blocks
Blocked by
See also

The llc program miscompiles the LLVM bytecode generated from Obsequi.  Bugpoint
has reduced the miscompilation to the l377__2E_score_move_8 function.

I will attach the LLVM assembly that is being miscompiled at the LLVM bytecode
that bugpoint considers to be safe.

FYI, the output from bugpoint:
*** The following function is being miscompiled:  l377__2E_score_move_8
<cbe><gcc>You can reproduce the problem with the command line:
  llc bugpoint.test.bc -o bugpoint.test.bc.s
  gcc ./bugpoint.safe.bc.cbe.c.so bugpoint.test.bc.s -o bugpoint.test.bc.exe -Wl,-R.
  bugpoint.test.bc.exe
The shared object was created with:
  llc -march=c bugpoint.safe.bc -o temporary.c
  gcc -xc temporary.c -O2 -o ./bugpoint.safe.bc.cbe.c.so -shared
-fno-strict-aliasing

[Quuxplusone]

Attached bugpoint.test.ll (24770 bytes, text/plain): LLVM assembly code that is miscompiled.

[Quuxplusone]

Attached bugpoint.safe.ll (463480 bytes, text/plain): LLVM Assembly compiled correctly

[Quuxplusone]

cool, I'll take a look. Thanks John!

-Chris

[Quuxplusone]

The program requires the following input on stdin:

solve rows 8 cols 8 V

Be sure to include a carriage return at the end of the line.

[Quuxplusone]

I still can't run it:

$ echo "solve rows 8 cols 8 V" | ./t

This causes the program to print out a bunch of stuff, but the program doesn't exit.

-Chris

[Quuxplusone]

I found and downloaded the program for myself, and it looks like there are
memory issues in the program:

==6953== Conditional jump or move depends on uninitialised value(s)
==6953==    at 0x804FEC5: hashlookup (hash.c:103)
==6953==    by 0x804C333: negamax (negamax.c:379)
==6953==    by 0x804B148: search_for_move (negamax.c:201)
==6953==    by 0x8048CA3: main (obsequi.c:102)
==6953==    by 0x4026A54C: __libc_start_main (in /lib/libc-2.3.2.so)
==6953==    by 0x8048B70: (within
/home/vadve/lattner/tmp/PR338/o/bullock.obsequi/obsequi/Obsequi)

I'll dig into it to see if I can fix this.

-Chris

[Quuxplusone]

Obsequi is works a bit better if you change the malloc in "initialize_solver" to
a calloc call.  I'm still verifying that this fixes it entirely though.

[Quuxplusone]

When I run the native version of the program, it'll stop for about 7-10 seconds
and then finish execution.  You might want to wait a bit and see if it finishes.

[Quuxplusone]

Yup, changing the malloc to a calloc magically fixes it, with the native
compiler, with LLVM, and with Valgrind.

Could you add this program into the test suite John?  It looks like it should be
easy to do and could be an interesting one for the memory work I'm doing.  :)

Thanks!

-Chris