From: SourceForge.net <no...@so...> - 2009-01-29 23:04:12
|
Bugs item #2546981, was opened at 2009-01-29 23:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101176&aid=2546981&group_id=1176 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compiler Group: wrong answer Status: Open Resolution: None Priority: 5 Private: No Submitted By: C. R. Ramakrishnan (crram) Assigned to: Nobody/Anonymous (nobody) Summary: Compiler bug in register allocation? Initial Comment: Here is a relatively simple program that tickles a compiler bug. I suspect it is due to incorrect register allocation. The following program has two versions of the "same" predicate (note the change in variable names). One would expect both to give the same result. But, ok([1],X) returns correctly with X=[1,1], but bug([1],X) will return with X=[[],1]. It looks like it confuses X with Xs in bug/2. If I add a writeln before either recursive call in bug/2, this bug disappears and the program computes correctly. ok([], []). ok([X|Xs], Zs) :- (X < 0 -> Zs = [X|Vs], ok(Xs, Vs) ; Zs = [X,X|Ws], ok(Xs, Ws) ). bug([], []). bug([X|Xs], Zs) :- (X < 0 -> Zs = [X|Ws], bug(Xs, Ws) ; Zs = [X,X|Ws], writeln(X,Xs),bug(Xs, Ws) ). I noticed this bug when running the attached merge/3 predicate. Compile with specialization on (default) and try merge([a,c],[b],X). It will create a cyclic term! Trace the evaluation to see the incorrect call. Try the same goal after compiling without specialization. The bug is not in specialization itself, but is triggered by the kind of rules that result from specialization. Note: versions as far back as 2.7.1 exhibit this bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101176&aid=2546981&group_id=1176 |