Compiler optimization and ebx register cause wrong behaviour

Jasper Taylor <[email protected]> Fri, 19 Sep 2008 13:20:39 +0100
Newsgroups gmane.comp.gnu.prolog.bugs
Message-ID <[email protected]>
OK, let's raise the stakes a bit. I have isolated a snippet of code that 
produces the wrong result, even without tracing, if gprolog is compiled 
with the default options, but produces the right result if either 
--without-c-flags or --disable-regs is specified when configuring 
gprolog. If you trace it, it segfaults in the default build. This is 
serious, because the precompiled packages, including those available on 
the Ubuntu and Fedora repositories, all have the bug. Here's the snippet 
-- I can't make it much simpler and keep the buggy behaviour:


make_intermediates(Source) :-
	(Source = makearray(Element, Dim); Source = soloarr(Element), Dim=1),
	((catch(DimVal is Dim, _, fail),
	  integer(DimVal);
	 member(Dim, [count(V)]),
		% Bug only happens if member predicate used!!
	  DimVal = 94);
	    throw(bad_index_number(Dim, makearray))),
	(\+ number(DimVal); DimVal > 1; Source = soloarr(_)).

/* Test command is:
  make_intermediates(makearray(33,count(parm1))).
*/


If you run the test command on a buggy gprolog build, you get:

uncaught exception: bad_index_number(count(parm1),makearray)

...whereas the call should actually succeed. Results are the same 
whether the file is consulted from the command line or compiled with gplc.

Please tell me if I can do anything else to help fix this. Also, if you 
need to specify either no registers or no optimization when building 
gprolog, which option will produce the fastest compiled Prolog code?
	--Jasper