Rafael Ávila de Espíndola <[EMAIL PROTECTED]> writes:
> Em Sun 12 Jun 2005 23:58, James A. Morrison escreveu:
> > Was there anything in particular that you found hard to understand in the
> > treelang frontend. It is supposed to be the example/tutorial front-end.
> One thing is that the parser is very big and mixed with C code. I find it
> easier to read a parser without side effects that just builds a abstract
> syntax tree ("Modern compiler implementation in ML" influence...). Just
> moving some of the C code to auxiliary functions in parse-aux.c would be very
> helpfull (are you interested in this patch(s)?).
Yup, I'd be willing to take the patches. If you are going to do this stuff
and other cleanup (which I do hope you do ;) then you should get a copyright
assignment on file with the FSF.
> > I suppose I should update this howto for gcc4.
> That would be wonderfull!!!
> > Perhaps, but the implementation may be the same because of how the
> > callbacks used to be implemented. With the langhooks it should be easy for
> > any frontend to use the default implementation of a calback.
> Convert is called directly and not through langhooks. Why?
> Some call backs don't have a default: LANG_HOOKS_BUILTIN_FUNCTION for example.
Right, convert probably should be turned into a langhook so we can find uses
of convert in the middle end that should call fold_convert instead. Also,
a patch to make a default for LANG_HOOKS_BUILTIN_FUNCTION would probably be
a good cleanup patch.
> > Where? I build NOP_EXPRs around the use of variables, in the treelang
> > frontend so I can get accurate source locations for where variables are
> > used.
> at build_string_literal in hello1.c (copied from builtins.c). This looks like
> a lot of work to build a string. I tried to use something similar to
> gfc_build_string_const (fortran/trans-const.c) but failed.
Ahh, treelang does have strings. I may take a look at your strings to see
how I can add them to treelang. Treelang probably should have strings.
> > function_end_locus is part of the function struct, which in treelang there
> > is only cfun at any given time.
> >
>
> > The answer is in tree.h:833,
> > In a FUNCTION_DECL, nonzero if function has been defined.
> but in tree.h:2092
tree.h:2115 in the cvs copy I have.
> /* In a VAR_DECL or FUNCTION_DECL,
> nonzero means external reference:
> do not allocate storage, and refer to a definition elsewhere. */
>
> So a function can be defined and have a "definition elsewhere" at the same
> time? Isn't it true that
> DECL_EXTERNAL(n) != TREE_STATIC(n) for all n?
No, TREE_STATIC for FUNCTION_DECLs only says if a function has been defined
or not.
--
Thanks,
Jim
http://www.csclub.uwaterloo.ca/~ja2morri/
http://phython.blogspot.com
http://open.nit.ca/wiki/?page=jim
