[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 (X11/20071209)

Hi Jasper

here is a smaller example:

bug :-
        ( catch(X is a, _, fail)


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),
     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:

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?

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]