Re: Compiler optimization and ebx register cause wrong behaviour

Hi Jasper

here is a smaller example:

bug :-
	( catch(X is a, _, fail)
	;
	  dummy(_,s(_)),
	  X=0
	),
	dummy(X).

dummy(_).
dummy(_,_).

test_bug :- (bug -> write('OK!\n') ; write('BUGGY!!!\n')).

:- initialization(test_bug).


This should display OK!, but provides BUGGY! instead.

I have localized the bug, it is due to gcc's optimization which removes 
an assignment done to ebx (but the optimizer removes it, thinking it is 
a local variable).

I will inform gcc's team and also find a way to fix it.

As said a workaround consists in removing ebx (--disable-regs) which 
provides a faster code than no optimization at all.

Best regards

> 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
<

-- 
Ce message a ete verifie par MailScanner
pour des virus ou des polluriels et rien de
suspect n'a ete trouve.