bug-prolog
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Compiler optimization and ebx register cause wrong behaviour


From: Jasper Taylor
Subject: Compiler optimization and ebx register cause wrong behaviour
Date: Fri, 19 Sep 2008 13:20:39 +0100
User-agent: Thunderbird 2.0.0.16 (X11/20080724)

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




reply via email to

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