Subject: Re: New version

From: Zheng Gengbing <[email-masked]>
Date: Fri, 29 Mar 1996 09:10:39 +0800 (EAT)

Hi,

	I feel so puzzled that I have no idea about this condition now . I'v 
compiled all source codes include tools (except unparse) on both HP9000 &
RS6000 , using both cc and gcc . All are running well , even Vdumpdep .
I 'v tested z?.f g?.f b?.f thoroughly  , no core dump occured . 

	Please give me some information about the core dump . You can also
try to comment some lines in the sample files , and find which statement 
causes the core dump. Or please tell me in which line of the hpfcc source
codes the hpfcc causes memory fault using core file .

	I suspect that your machine cannot support these lines ,

	{
	PTR_TYPE  type;

	call_or_func(&type);          // pointer 'type' not be allocated place  
                     ^^^^^
	func->type = type;
	}

   the definition of call_or_func is:

	int     call_or_func(func_type)
        PTR_TYPE        *func_type;

   I'v changed some places like that , and you can re-get the *.c in 
~/NPAC/hpfFrontEnd1.2/src/hpfcc/*.c  and  try.

Regards,

Zheng Gengbin

---

From: Zheng Gengbing <[email-masked]>
Date: Fri, 29 Mar 1996 11:01:24 +0800 (EAT)

On Thu, 28 Mar 1996, Guansong Zhang wrote:

> Hi,
> 
> I just make the new 1.2, and tested the hpfcc with b?.f, g?.f and z?.f,
> unfortrunatly we still have the following program cause memory fault:
> 
> b1, b4, b8, g3, g4, g6, g9, z1, z2, z4, z7, z9
> 
> if I use gcc to compile the hpfcc then:
> 
> b1, b4, b8, g2, g3, g6, g9, z1, z2, z4, z7, z9 will cause memory fault. (Please
> note that the two list is little different.)
> 

    In our HP9000 & RS6000 , no memory fault ever occured of these files .
    I have to do some guesses , 
    I noticed the common statements appeared in these files , and I have 
done some changes to the /hpfcc which I mentioned in my last letter .

> and the semantics checks information is also different, for example, b5.f
> 
> if compiled by cc, we got the following:
> 
> hpfcc: line 9 error 541:can not find the special name of generic ABS
> hpfcc: line 10 error 541:can not find the special name of generic all
> hpfcc: line 10 error 107:Llnd variant 856 Must have a  type !
> hpfcc: line 10 error 148:Type not match in assignment.
> hpfcc: line 12 error 541:can not find the special name of generic acos
> 
> if compiled by gcc, we got the following:
> 
> hpfcc: line 9 error 541:can not find the special name of generic ABS
> hpfcc: line 9 error 148:Type not match in assignment.
> hpfcc: line 10 error 541:can not find the special name of generic all
> hpfcc: line 10 error 107:Llnd variant 856 Must have a  type !
> hpfcc: line 10 error 148:Type not match in assignment.
> hpfcc: line 12 error 541:can not find the special name of generic acos
> hpfcc: line 12 error 107:Llnd variant 856 Must have a  type !
> hpfcc: line 12 error 148:Type not match in assignment.
> 
> 
> Do you have the same problem on your HP?
> 

     No , both in HP9000 and RS6000 . From the outcome of b5 ,You seemed 
using the different versions of hpfcc  .  Make sure the path of the hpfcc is 
correct !
     In /src/hpfcc , there is a file 'intrinsic.f' written in HPF , this 
file contains all the intrinsic procedures' definition , though it is 
incomplete now. Dont 't forget to run Configure before compilation , 
otherwise hpfcc cannot open the right  'intrinsic.dep' . When make in 
/hpfcc , it will compile intrinsic.f by using intr_make (which is compiled 
in /hpf2dep) automaticlly. 

> On Mar 28,  6:05pm, Zheng Gengbing wrote:
> 
> >   After I  successfully compiled hpfcc codes using  gcc , I test the sample
> > files in hpfcc/Testsuite ,include  z?.f  g?.f  b?.f . The execution of
> > hpfcc is good , except that it is  fragile to the pointer errors compared to
> > the old one we compiled using cc on HP. I'v modified some source codes of
> > hpfcc.
> 
> If the program I listed above can be check by hpfcc without memory fault?

	No , I'v tested all samples ,on both machines .

> 
> >  So, please re-get the hpfFrontEnd-1.2.tar.gz  and try on your machine .
> > If that isn't effective too , please let me login to your machine and check
> > what on earch is wrong .
> 
> To do remote debug is not practical, you will find the speed is too slow.
> 

  Slow is better than  sit and guess foolishly .

Regards,

***************************************************************************
*     Zheng Gengbin                 *                                     *
*                                   *                                     *
*  Dept. of Computer Science        *  Phone:  86-10-2585088              *
*         & Technology              *  Email:                             *
*                                   *      [email-masked]   *
*  Peking University P.R.China      *  Mail:                              *
*                                   *      Room 1077 ,Building 47,        *
*                                   *      Peking University, P.R.China   *
***************************************************************************