This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/45596] Implement simple static points-to analysis in Fortran FE
- From: "mikael at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 10 Sep 2010 16:11:47 -0000
- Subject: [Bug fortran/45596] Implement simple static points-to analysis in Fortran FE
- References: <bug-45596-87@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #8 from mikael at gcc dot gnu dot org 2010-09-10 16:11 -------
In the patch there is a small mistake :
+ if (symtree->n.sym->attr.flavor == FL_PARAMETER
+ && symtree->n.sym->attr.intent != INTENT_OUT)
+ symtree->n.sym->points_to = &gfc_pt_dummy;
Parameters in the fortran jargon are named constants.
It should probably be `symtree->n.sym->attr.dummy' instead of
`symtree->n.sym->attr.flavor == FL_PARAMETER'
(In reply to comment #7)
> For the interprocedural analysis I believe static points-to is the only
> reasonable thing to do, anything else would have too big complexity (both space
> and time). Within one function, sure, you have the code, but not in a form
> which makes it very easy to do such analysis (e.g. SSA form is much more
> suitable for that), and you need to understand many different constructs (IF,
> loops, GOTO, CYCLE, BREAK, OpenMP constructs, ...) and handle propagating the
> information through the callgraph (which isn't built). I think reimplementing
> many middle-end passes on the Front-end trees is not the right way to go, and I
> hope the static points-to analysis should catch most of the interesting cases
> in real-world code.
>
I see.
Given my knowledge of the middle-end, I have nothing to oppose.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45596