[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Compiler optimization and ebx register cause wrong behaviour
From: |
Daniel Diaz |
Subject: |
Re: Compiler optimization and ebx register cause wrong behaviour |
Date: |
Fri, 19 Sep 2008 18:06:09 +0200 |
User-agent: |
Thunderbird 2.0.0.9 (X11/20071209) |
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.