I have run into what I think is a bug.
The code (sort of)

class A
{
int foo(){...}		// always returns the same number (in this case)
int bar(int i) {...}	// returns a function of only i

int runA()
{
return bar(foo());
}

int runB()
{
int i = foo();
return bar(i);
}


}


void main()
{
A a = new A;
writef(a.runA(), \n);
writef(a.runB(), \n);
}


(This code isn't the code with the bug, that code is 15k+ lines long.)

The bug: A.runA and A.runB return different numbers.
In my actual code storing the function to a temp variable and using that changed
the output.
Any ideas??

This doesn't help much, I tried the following (see below) and it worked fine.
Maybe it's what the function bar is doing in your code ..

Could you try to provide a more specific test case?

This works fine:
----------------------------------------
import std.stdio;

class A
{
    int foo(){ return 5; }
    int bar(int i) { return i + 1; }

    int runA()
    {
        return bar(foo());
    }

    int runB()
    {
        int i = foo();
        return bar(i);
    }
}


void main()
{
    A a = new A;
    writef(a.runA(), \n);
    writef(a.runB(), \n);
}

BCS wrote:
> I have run into what I think is a bug.
> The code (sort of)
> 
> class A
> {
> int foo(){...}		// always returns the same number (in this case)
> int bar(int i) {...}	// returns a function of only i
> 
> int runA()
> {
> return bar(foo());
> }
> 
> int runB()
> {
> int i = foo();
> return bar(i);
> }
> 
> 
> }
> 
> 
> void main()
> {
> A a = new A;
> writef(a.runA(), \n);
> writef(a.runB(), \n);
> }
> 
> 
> (This code isn't the code with the bug, that code is 15k+ lines long.)
> 
> The bug: A.runA and A.runB return different numbers.
> In my actual code storing the function to a temp variable and using that changed
> the output.
> Any ideas??
> 
> 

I'll try to strip it down but don't hold you'r breath. It's quite involved code.


In article <dgci00$1u4p$1@digitaldaemon.com>, Hasan Aljudy says...
>
>This doesn't help much, I tried the following (see below) and it worked
>fine.
>Maybe it's what the function bar is doing in your code ..
>
>Could you try to provide a more specific test case?
>
>This works fine:
>----------------------------------------
>import std.stdio;
>
>class A
>{
>     int foo(){ return 5; }
>     int bar(int i) { return i + 1; }
>
>     int runA()
>     {
>         return bar(foo());
>     }
>
>     int runB()
>     {
>         int i = foo();
>         return bar(i);
>     }
>}
>
>
>void main()
>{
>     A a = new A;
>     writef(a.runA(), \n);
>     writef(a.runB(), \n);
>}
>
>BCS wrote:
>> I have run into what I think is a bug.
>> The code (sort of)
>> 
>> class A
>> {
>> int foo(){...}		// always returns the same number (in this case)
>> int bar(int i) {...}	// returns a function of only i
>> 
>> int runA()
>> {
>> return bar(foo());
>> }
>> 
>> int runB()
>> {
>> int i = foo();
>> return bar(i);
>> }
>> 
>> 
>> }
>> 
>> 
>> void main()
>> {
>> A a = new A;
>> writef(a.runA(), \n);
>> writef(a.runB(), \n);
>> }
>> 
>> 
>> (This code isn't the code with the bug, that code is 15k+ lines long.)
>> 
>> The bug: A.runA and A.runB return different numbers.
>> In my actual code storing the function to a temp variable and using that changed
>> the output.
>> Any ideas??
>> 
>> 

BCS wrote:
<snip>
> (This code isn't the code with the bug, that code is 15k+ lines long.)
<snip>

If this code doesn't have the bug, then why did you post it?

A good idea is to try first to reproduce the bug by writing a short program from scratch.  Then, if that fails, then try trimming your program down.

This might help you:

http://www.physci.org/codes/sscce.jsp

(It's actually aimed at being a technique for isolating bugs in your programs, but many of the points are also applicable to writing compiler bug testcases.)

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

I posted that code because it gives general idea of what the bug is in the hope that someone would recognize it a similar to something they had encountered. I plan to try to strip down the real code but I expect it will not be vary fruitful. My best guess is that it is a compiler bug (or something that will make me feel vary stupid) or some such thing.

Below is a better approximation of the real code. (This actually does a simpler case of  what the real thing does.) In the real thing, on line 6, storing the value of the 2nt argument to a temp variable before the call changes how things run.

This code also doesn’t have the bug. (Sorry)

#import std.math;
#import std.stdio;

#class Taylor
#{
#	void regen(real time)	{n = newInert(n.P(time), n.V(time));}	//line 6
#	real P(real time)	{ return n.P(time); }

#	static Newton newInert(real p, real v)
#				{ return new Newton(p, v, Acc(p), Jrk(p)); }

#	static real Acc(real p)	{ return -p; }
#	static real Jrk(real p) { return -sqrt(1 - p*p); }

#	Newton n;

#}

#class Newton
#{
#	this(real nP, real nV, real nA, real nJ)
#	{
#		p=nP;	v=nV;	a=nA;	j=nJ;
#		writef("%g %g %g %g \n", p, v, a, j);
#	}

#	real P(real time) { return p + v*time + a*(time*time/2) +
j*(time*time*time/6); }
#	real V(real time) { return v + a*time + j*(time*time/2); }

#	real p;
#	real v;
#	real a;
#	real j;
#}

#void main()
#{
#	Taylor t = new Taylor;

#	t.n = Taylor.newInert(.999, 0);
#	for(int i=0; i< 26; i++)
#		t.regen(.1);
#}

One candidate for a cause is that the compiler Is inlineing the calls at line 6 and time is getting changed some where in the first call.



In article <dgf13m$1a2m$1@digitaldaemon.com>, Stewart Gordon says...
>
>If this code doesn't have the bug, then why did you post it?
>
>A good idea is to try first to reproduce the bug by writing a short program from scratch.  Then, if that fails, then try trimming your program down.
>
>This might help you:
>
>http://www.physci.org/codes/sscce.jsp
>
>(It's actually aimed at being a technique for isolating bugs in your programs, but many of the points are also applicable to writing compiler bug testcases.)
>
>Stewart.
>
>-- 
>-----BEGIN GEEK CODE BLOCK-----
>Version: 3.1
>GCS/M d- s:- C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS-
>PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
>------END GEEK CODE BLOCK------
>
>My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.