[Top][All Lists]
[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
- Compiler optimization and ebx register cause wrong behaviour,
Jasper Taylor <=