bug in -O -finline-functions Solaris 2.6 egcs1.1b g++

[andtheworldandtheworld]

The version of egcs I'm using is 

egcs version

/egcs-2.91.57/specs
gcc version egcs-2.91.57 19980901 (egcs-1.1 release)

--------------------------------------------
How installed :: standard install

./configure
make bootstrap
make install

--------------------------------------------

	I believe I have found a bug in a mixture of -O and
-finline-functions w/ the egcs 1.1b g++ compiler. This did not
show up w/ egcs1.02 

	I've attached a Makefile and the source code and some
parameter files for the code in tar.gz form.

	The program will untar itself in sgb2/. The makefile 
make all will create the executable in that directory. 

--- Running the program-------------------------------

To run the program set the environmental variable Sgb_Dir to
the directory that directory

i.e 

export Sgb_Dir=~/sgb2

and to run it 

./sgbmain

----

	THe problem occurs in line 2537 of the code. (I merged
the entire code into one for ease for sending).

inside_mike_beachy=0;

for(j=0;0 == inside_mike_beachy;j++)
    {                           //  loop over neighbors
    printf("THis is a line\n");
    printf("This is another line\n");
    printf("Ho hum\n");
    printf("THe inside on the outside is %d\n",inside_mike_beachy);


What happens is that inside_mike_beachy gets assigned to the value
1 during the comparision statement of the for loop. The disassembly
of the code yields the following ::


Using -g and ddd data display debugger.

Dump of assembler code from 0x8055b00 to 0x8055c00:
    0x8055b00 <check_set_point+12>:	movl   $0x0,0xffffff90(%ebp)
    0x8055b07 <check_set_point+19>:	movl $0x40f86a00,0xffffff94(%ebp)
    0x8055b0e <check_set_point+26>:	movl   $0x0,0xffffff88(%ebp)
    0x8055b15 <check_set_point+33>:	movl $0x3ff00000,0xffffff8c(%ebp)
    0x8055b1c <check_set_point+40>:	movl   $0x0,0xffffff98(%ebp)
    0x8055b23 <check_set_point+47>:	xorl   %edi,%edi
    0x8055b25 <check_set_point+49>:	movl   $0x0,0xffffff80(%ebp)
    0x8055b2c <check_set_point+56>:	testl  %edi,%edi
    0x8055b2e <check_set_point+58>:	jne    0x8055e9c <check_set_point+936>
    0x8055b34 <check_set_point+64>:	leal   0xffffff98(%ebp),%eax
    0x8055b37 <check_set_point+67>:	movl   %eax,0xffffff7c(%ebp)
    0x8055b3d <check_set_point+73>:	leal   0xffffff90(%ebp),%ecx
    0x8055b40 <check_set_point+76>:	movl   %ecx,0xffffff78(%ebp)
    0x8055b46 <check_set_point+82>:	leal   0xffffff88(%ebp),%eax
    0x8055b49 <check_set_point+85>:	movl   %eax,0xffffff74(%ebp)
    0x8055b4f <check_set_point+91>:	leal   0xffffff84(%ebp),%ecx
    0x8055b52 <check_set_point+94>:	movl   %ecx,0xffffff70(%ebp)
    0x8055b58 <check_set_point+100>:	movl   $0x1,%edi
    0x8055b5d <check_set_point+105>:	nop    
    0x8055b5e <check_set_point+106>:	nop    


This is the dump of that particular routine sua_t::check_set_point up to  
and including the for statement. The last instruction at 0x8055b5d before
the nops is the one that is  assigning the value of inside_mike_beachy to
be 1.

	I hope this is enough information but let me know if you would
like anything else w/ regard to this problem ..Or if it is
patchable/fixable :)


	-me