Subject: New version 1.55

From: Zheng Gengbing <[email-masked]>
Date: Thu, 23 May 1996 18:47:07 +0800 (EAT)

Hi,
 everyone ,

	Now version 1.55 is ready .

	In this version , some bugs in hpf2dep and hpfsc is debugged .
New semantic checkings are added .

	So below are files which have been modified :

	include/
	  defnode.h :   some attributes bit are adjusted .

	basicop/
	  makesymb.c :  make_symb() is improved to support default access
                        attribute (PUBLIC , PRIVATE )
	  makehash.c :  this is new for maintain hash table .

	hpf2dep/
	  makespec.c :  include a bug which will cause computer in stone
                        in lookupSymbModule()
	  f90.y :       the bug of data implied do is eliminated .
	  hpflexer.l :  
                        I found if we comment out the extern char yytext[],
                        the compilation is not influenced .

	hpfsc/

	I also adjusted Makefile.in in some places . Please pay attention
to them.

	you can fetch hpfFrontEnd-1.55.tar.gz now .

PS ,
 Can you give me a list of machines of NAPC which I can rlogin except
nova,mel,kestrel1 ? And what is the configuration of each machine about
lex(flex) , yacc(bison) , cc(gcc) ? I want to do a test of our project .

	Now , I successfully compiled and tested version 1.55 on 
mel.npac.syr . You can copy from there  too.

***************************************************************************
*     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   *
***************************************************************************

---

From: Zheng Gengbing <[email-masked]>
Date: Fri, 24 May 1996 08:22:40 +0800 (EAT)

On Thu, 23 May 1996, Guansong Zhang wrote:

> I just found that I don't update the spec_stmt.c in hpfsc. After doing this the
> following problem is gone.
> 
> But I also find a problem in this file, please check the resurcise prefix, it
> seems this one add one more, while the wrong version do good job.
> 

	I don't quite understand . which resurcise prefix ?

---

From: Zheng Gengbing <[email-masked]>
Date: Fri, 24 May 1996 08:27:58 +0800 (EAT)

On Thu, 23 May 1996, Guansong Zhang wrote:

> In this version I found:
> 
>        interface ~~NULL_HEAD
> 
> in unparse result, and I also remember you told me that some kind of name have
> to be add to datablock when it is null.
> 
> Now can we make some kind of def so when unparse see the special string, it
> won't print it out?

	We have a defintion already in defnodes.h :

	#define  NULL_UNIT_HEAD  "~~NULL_HEAD"

	This string is used in all kinds of program units which have no 
name .

---

From: Zheng Gengbing <[email-masked]>
Date: Fri, 24 May 1996 14:35:39 +0800 (EAT)

On Thu, 23 May 1996, Guansong Zhang wrote:

> When I making the 1.55, I found yacc conflicts is 25, one less than previous
> time.
>

	That because I modified rule of data_implied_do , in 
data_i_do_object_list , I add a COMMA , so perhaps this help to reduce
a conflict . 

> I hope HIT further examine the yacc rules, so we may get rid of the keyword
> limitation. Please provide information about your change on yacc rule to HIT.
> 
> (I remember once you talk about this to me, but at that time, I am too
> concerned about the demo, have no time to let HIT to confirm the changing. Now
> we can discuss a little to make it better.)
>

---

From: Zheng Gengbing <[email-masked]>
Date: Mon, 27 May 1996 11:02:34 +0800 (EAT)

On Sat, 25 May 1996, Guansong Zhang wrote:

> On May 24,  8:22am, Zheng Gengbing wrote:
> > Subject: Re: New version 1.55
> >-- End of excerpt from Zheng Gengbing
> 
> sorry for misspell. I mean recursive.
> 
> You can do this way in testsuite/syntax:
> 
> % grep recursive *.src
> test1.dep.src:      recusive recursive function fun14 (dum10, dum11, dum12,
> dum13, dum&
> test1.dep.src:      recusive recursive function fun26 () result(res3)
> test1.dep.src:      recusive recursive integer  function fun17 (dum23)
> test1.dep.src:      recusive integer  recursive function fun27 ()
> test1.dep.src:      recusive recursive subroutine sub8(*)
> test1.dep.src:      recusive recursive subroutine sub12()
> test1.dep.src:      recusive recursive subroutine sub14()
> testh.dep.src:      integer  recursive pure function fun1 (dum1, dum2, dum3,
> dum4) res&
> 
> And you can see some recursive is repeated in one statement. But before hpfsc,
> the resulte is:
> 
> 
> test1.dep.src:      recursive function fun14 (dum10, dum11, dum12, dum13,
> dum14, dum15&
> test1.dep.src:      recursive function fun26 () result(res3)
> test1.dep.src:      recursive integer  function fun17 (dum23)
> test1.dep.src:      integer  recursive function fun27 ()
> test1.dep.src:      recursive subroutine sub8(*)
> test1.dep.src:      recursive subroutine sub12()
> test1.dep.src:      recursive subroutine sub14()
> testh.dep.src:      integer  recursive pure function fun1 (dum1, dum2, dum3,
> dum4) res&
> 
> 

	It seems the bug of unparser . unparse check the attributes of the
function name and find RECURSIVE_BIT and print , while parse the llnd tree 
find the PREFIX_RECURSIVE llnd and print out a recursive . 
	After I deleted the code of assigning the RECURSIVE_BIT to function
name symbol in hpfsc , the unparser result is correct , this proved what I
guessed above .
but I donot know why testh.f print out the correct result . Note that pure
present in testh.f while not in test1.f . 

	Please check it again . And I found in version 1.52 , 1.53 this 
problem already existed .

Zheng

---

From: Zheng Gengbing <[email-masked]>
Date: Tue, 28 May 1996 08:53:41 +0800 (EAT)

On Mon, 27 May 1996, Guansong Zhang wrote:

> 
> Yes, you maybe right. It seems unparse use both the old and new def to print
> out recursive, so one of them is redundant. (As to the correct one in testh.f,
> I am not sure about it either. But I'd say the unparse which I changed do not
> deal with attribute bits, except for interface statement so far. The old one
> may don't understand the attribute bits well.)
> 
> I checked the code in unparse, there do is another place to print out
> "recursive", if the RECURSIVE_BIT is on, so I just comment it out. (Without
> understanding the code.) I need you update on f90.y which will allow hpfsc pass
> the test1.f to test.
> 
> In fact, you can test it on your machine. Just comment out two if statements in
> db_unp.c (use "grep recursive db_unp.c", you will find where.) If that doesn't
> work, I will check further.
> 

	After I commented the two place , it's ok now .