Subject: Re: Comments on the yacc file in 1.37

From: Zheng Gengbing <[email-masked]>
Date: Tue, 23 Apr 1996 09:13:35 +0800 (EAT)

On Mon, 22 Apr 1996, Zheng Qiang wrote:

> > 	since the sequence is reverse of PROG_HEDR , our parser cannot
> > accept .
> >
> 
>     Yes, you are right, Lxy is modifying this. Thanks. 
>

	Ok , I am waiting her result of change .

> > 
> > > (2) "where_stmt_begin" is added.
> > >  We think it is not necessary. And we suggest to modified it to
> > >
> > >   where_stmt
> > >     :   WHERE LEFTBRACKET mask_expr RIGHTBRACKET
> > >         assignment_stmt
> > >     ;
> > >
> > >   , so does forall_stmt and if_stmt
> > >
> > >   forall_stmt
> > >     :   FORALL LEFTBRACKET forall_control
> > >         RIGHTBRACKET forall_assignment
> > >     ;
> > >
> > > (3) I want to come up with the "if_stmt_begin" added by PKU specially.This
> > > is a dangerous action,because it caused the conflict between the
> > > " if_stmt" and " arithmetic_if_stmt " .So I said it should be the same as
> > > where_stmt and forall_stmt in (2).
> > 
> > 
> > 	These are the same problem as above .
> > 	the AST will be
> >             ASSGN_STAT
> >                |
> >             CONTRO_END
> >                |
> > 	    LOGIF_STMT
> > 
> > 	the LOGIF is wrong placed .
> 
>     I am wondering about this, in my computer( not modifying the rules), the 
> list of bfnd (linked by thread) is (1) assgn_stat (2) logif_stmt (3) 
> control_end, which is a little different from others. But it doesn't 
> matter. See the blob list and you will find the relation between the 
> control parent and the children is correct. That means the AST is correct.
>

	Yes , that's my mistake to draw the AST above wronngly. 
        I am  sorry that it do affect us . We use thread link to travel 
the bfnd, so I add some new rules to correct the sequence. If it don't 
matter , please accept my change .
And I think the reverse sequnce of these structure 
also affect the appearence of the contents of dep produced by dumpdep.

>    Further more, I find I can make the action in forall_stmt same as if_stmt 
> since the structure is the same. And where_stmt.
> 
> > 
> > 	But your parse can not parse
> > 	do 10
> >      10 enddo
> > 	only 10 continue is allowed .
> > 
>     Yes, you are right, we considerd it a useless statement and this kind 
> of things are a little subtle. Could you tell me which kind of structure 
> should it be ? Non_label do construction or label do construction ?
> 

	Useless ? What do you mean ? If it is correct , it should be 
parsed by our parser. It sure be a label do construction ,since label 10
appear in label_do_stmt .

	It do is trouble , so I try to add a new rule label_end_do_stmt. I
donot know if my change will be accpeted by you .

	Same problem exist in your if_construct and case_struct rules.
you never consider the endif or end case statement can carry a label.

>     In a mail you sent here, you said that your co-worker find a lot of 
> bugs in the i/o part. Would you please tell me the detail about those 
> bugs if they are not about the wrongly use of the "strcpy()" or 
> "strcat()" ? Thanks.

	She will contact you immemdiately.

***************************************************************************
*     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: Tue, 23 Apr 1996 18:18:58 +0800 (EAT)

On Mon, 22 Apr 1996, Zheng Qiang wrote:

> 
>     I made some modifications in the file f90.y and exec_part.c in order 
> to do check label mismatch and label missing in the label do 
> construction better. The files were put in the directory 
> /pub/usr/zq/tozgs. You can fetch them. 

	I have got the files. I update your changes about assign_label_stmt,
I am now trying to merge your checking on the do_label . 
 
	Here ,I want to declare a principle of our change of f90.y .

	If we still change f90.y separately , we will again go  away 
futher and further . The result will be that we must merge our work again and
again .  
        My suggestion is that if we all notice  a bug ,do not change that 
in a hurry . Please check if the other side have changed the same thing .

   Since the output of your parse is the input of our program , we certainly 
assume that our change is to be accepted with higher priory by you . 
	Please try your bugs on our merged version first, that is important !
If the sample can pass , do not do the repeat change . This will save our
work of merge . And try to do your work on the merged version ,so that I
can find your change easily by using diff .