Subject: Re: FUN_NAME Re: New version 1.59

From: Zheng Gengbing <[email-masked]>
Date: Fri, 28 Jun 1996 09:08:00 +0800 (EAT)

On Thu, 27 Jun 1996, Guansong Zhang wrote:

> Please check this:
> 
> if compared with the results obtained from 1.58, I found the following in 1.59
> 
> ...Comparing survey.dep.lnk
> 585c585
> <   192-E   312     9-T    ----   191-E    ----                     EXPR_LIST
> ---
> >   192-E   312    ----    ----   191-E    ----                     EXPR_LIST
> 737,738c737
> <   16-S  509   ----    0   17-S    2-B            abs n_in=    0 n_out=    0
> n_io=    0
> <                                      in_l=   ---- out_l=   ---- sy_l=   ----
> p_hdr=   ----     FUNCTION_NAME
> ---
> >   16-S  503    2-T 536870912   17-S    2-B            abs local= 600 nxt_in=
>  ---- nxt_out=  ----     VARIABLE_NAME
> 
> 
> This is a cut from screen, to make it clear abs was changed from FUNCTIOM_NAME
> to VARIABKE_NAME, I think the FUN_NAME problem still there, hpfsc must omit
> some place when make check.
> 
> Guansong
> 

	This is a rather special condition , I think . This time abs is a
intrinsic function , which mean if completely link , it should point to the
symbol entry of AST of intrinsic library libhpf.sl , which is a separate AST
from this one (remember libhpf.sl is also a dep file , we load it to memory
before we do the semantic checking ). And think about hpfsc , if we 
simply change from VARAIBLE_NAME to FUNCTION_NAME , is it easy to make this 
symbol abs meaningful by adding all the dummy list and type ,scope ... 
to it ? 
	So we let abs untouched , otherwise dumpdep will core dump .What you
should notice is that the llnd node are changed from ARRAY_REF in hpf2dep
to INTRIN_FUNC_CALL after hpfsc , so the symbol entry of abs served only as
a name , not have precise meaning here . The whole information is contained
in the intrinsic libaray .
	In a word , sometimes symbol entry do not play a key role , what is
really important is what the llnd mean .

Gengbin

---

From: Zheng Gengbing <[email-masked]>
Date: Fri, 28 Jun 1996 17:38:40 +0800 (EAT)

On Thu, 27 Jun 1996, Guansong Zhang wrote:

> On Jun 28,  9:08am, Zheng Gengbing wrote:
> > Subject: Re: FUN_NAME Re: New version 1.59
> If we can not provide a complete info for one symbol entry, it is also better
> to have a partial correct one than a wrong one.
> 
> 
> I don't know why this will happen, I guess you can try to prevent it by adding
> NULL in uncertain feilds. Just let dumpdep print ---.
> 
> In fact, here we have a function ref without def.
> 
> Well, it seems this is a little puzzling. Do you mean some times the def of our
> AST and ST are conflicted with each other? and in this time we should omit one
> of them?
> 
> In fact, I don't see we have this kind of definition. The only place I know so
> is that sometimes a symbol entry without rooted on AST may exist in ST, which
> we can omit.
> 

	I don't know how you get that idea and I don't know how to answer this.
I will say in this case , symbol abs only serve a string pointed by the llnd 
node . It have no other meaning .There is no significance  to care for how 
it is represented ,since the llnd already indicate so. The symbol entry is only 
used to make AST complete .

	Anyway, I will end up arguing with you about this trival thing . I 
will change that if I can .

Gengbin