Subject: Re: 1.46

From: Zheng Gengbing <[email-masked]>
Date: Sun, 5 May 1996 09:56:58 +0800 (EAT)

On Sat, 4 May 1996, Guansong Zhang wrote:

> The following is my step to update 1.45 to 1.46
> 
> 1. configure:
> 
> in config a Makefile is added, this is used for us to create new configure and
> config.h.in from configure.in.
> 
> I moved the configure.in to config dir, and move the Makefile.in back to top
> dir.
>

	This will cause trouble , now config.h can not be generated .
In fact , it is a convention that  Gnu put configure.in in project root .
 Place in config will cause configure can not find the config.h.in,
the AC_CONFIG_AUX_DIR and AC_CONFIG_HEADER can not work well togather . 
so I suggest we put configure.in in project root also.

	Also you cannot delete config.h.in , because if the user have no
autoconf , he can not generate this file . So configure.in ,config.h.in
must be saved . autoconf is used for us developer .

	I added acconfig.h in project root dir . That is for autoheader 
to generate defintions not recognized by it . So I add WANT_LIST again .
We can add other AC_DEFINE easily then.
Agian acconfig.h must be placed in same dir with configure.in in 
project root .Every gnu software do so , do not change that again .

> configure.in was change in two position:
> 
> a. init postion is pointed to configure.in
> b. WANT_LIST is commented out, so we won't need more file to generate
> config.h.in form configure.in. I will take care of this Macro later.
> 
> Makefile.in was changed a little:
> 
> a. make distclean should not include uninstall. Only when we installed to
> default postition, that is our project dir, uninstall is necessary. I don't
> know how to do this yet. We can discuss this later.
> 
> b. I don't know how to use recheck previously in pku's version. So I don't add
> this. Zheng Gengbing please help me on this to add it back if you think it is
> necessary.
> 
> Through we don't need configuraton for the demo, I hope from this version on,
> we have a fram work of that. We may improve the configure.in gradually.
> 
> 
> 4. src/hpf2dep
> 
> In this dir, I change the following thing in 1.45:
> 
> a, Makefile.in: LEX and SLIBS, since we still have to use lex, flex can not do
> the job at present time.
> 
> b, I delete the WANT_LIST checked by hpf2dep.c
> 
> 5. src/hpfcc
> 
> Same as 1.45
> 
> 6. src/tools/dumpdep,
> 
> This dir is same as 1.42 now. compared with 1.41, only dumpnodes.c a little
> difference.
> 
> 126c126
> <         static char   *string[] = {"<A HREF=\"#------ ----",
> ---
> >         char   *string[] = {"<A HREF=\"#------ ----",
> 129c129
> <         static char   *string1[] = {" ","  ","   "};
> ---
> >         char   *string1[] = {" ","  ","   "};
> 657,659d656
> <                                       /* add by zheng.gb */
> <           case (ERR_LABEL):
> <           case (END_LABEL):
> 
> 
> I don't know why pku change the sting* var to auto ones. Tell HIT if you can.
> 

	We change from auto ones to static because our compiler can not pass.

***************************************************************************
*     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: Sun, 5 May 1996 16:30:14 +0800 (EAT)

> I don't know why pku change the sting* var to auto ones. Tell HIT if you can.

	These tow tags should be handled as LABEL_REF , otherwise it will
core dump.

> 7. src/tools/unpares,
> 
> This include my today's work. Here I want ask a question about ENDDO_STMT:
> 
> 
> On May 4,  7:31pm, Zheng Gengbing wrote:
> >
> >
> > 	Ok, I have completely solved the Do construct problems.
> > That's to say all kinds of do_construct can be passed now.
> >
> > 	What I change is :
> >
> > 	replace block_do_construct like nonblock_do_construct :
> >
> > block_do_construct
> >     :  nonlabel_do_stmt {
> >         }
> >     ;
> >
> > add new tag ENDDO_STMT  to replace  CONTROL_END , because sometime unparse
> > can not know if CONTROL_END is a enddo statement .
> >
> > Now add end_do_stmt to  executable ,
> > and rewrite end_do_stmt .
> >
> > So what unparse do  is to add  ENDDO_STMT now.
> > Note , ENDDO_STMT may carray a label .
> >
> >
> >-- End of excerpt from Zheng Gengbing
> 
> 
> But see this program:
> 
> ++++++++++++++++++++++++++++++++++++++
> 
>  program try
> 
> 30    goto 40
> 
>    do1: DO 40 , while(LOCATION + 5)
>       LOCATION = I
>  40     enddo do1
> 
>  end
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>       program try
> 30      goto 40
>       do while (LOCATION+5)
>          LOCATION = I
> 40      enddo
>       enddo
>       end
> 
> ======================================
> 
> And its dumpdep results:
> 
>   4-B 174   2-B  --  ----  ----    5-E   ----    6-E   --   --   ----   2   6
>    5     1-F     5-B DO_WHILE_NODE
>                5-B     6-B     7-B    --
>               --
>          decl_specs(bits set)=
>   5-B 111   4-B  --  ----  ----    7-E    8-E   ----   --   --   ----  --   7
>    6     1-F     6-B  ASSIGN_STAT
>               --
>               --
>          decl_specs(bits set)=
>   6-B 194   4-B  --  ----   4-S   ----   ----   ----   --   --    2-L  --   8
>    7     1-F     7-B   ENDDO_STMT
>               --
>               --
>          decl_specs(bits set)=
>   7-B 104   4-B  --  ----  ----   ----   ----   ----   --   --   ----  --   8
>    7     1-F     8-B  CONTROL_END
>               --
>               --
>          decl_specs(bits set)=
> 
> Here we can see in 1.45 control_end is not replaced by enddo_stmt, but an
> enddo_stmt is added inside do construct.
>
> I am not sure here, pku intend to define so or a mistake in implementation,
> because from whay you say, you want to replace, right?
> 
> If the definition is this, this is a def bug, unparse won't know when to
> unparse control_end when to neglect. I try to us a flag, but failed. So I hope
> PKU can consider this again.
> 
> Now I am sending 1.46 to both of you.
>

	I am not intend to replace CONTROL_END by ENDDO_STMT .Control_end
means nothing to unparser , just a flag of the end of the construct , but 
CONTROL_END means something to hpfcc, we will find the last statement .
It is also a convention that there should always be a CONTROL_END at last
BFND . So you can always neglect CONTROL_END in do_construct .