https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45596
Thomas Koenig changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
--- Comment #11 from jakub at gcc dot gnu dot org 2010-09-15 08:37 ---
You're right, it doesn't call compute_spt_expr on all the actual arguments's
->expr. If/when it will use a generic walker, that will be fixed
automatically, but I'll fix it in the meantime as well.
--
http://gcc
--- Comment #10 from tkoenig at gcc dot gnu dot org 2010-09-15 05:01
---
One point:
As far as I can see, you are calling compute_spt_call on functions in
'naked' expressions, as in
a = f(x)
but you are not following array or substring references, as in
a(f(x)) = g(f(y))
where the d
--- Comment #9 from jakub at gcc dot gnu dot org 2010-09-13 15:36 ---
Created an attachment (id=21785)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21785&action=view)
gcc46-pr45596.patch
Updated patch. This one should handle the case where pointer assigment just
points into some
--- 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 fortr
--- Comment #7 from jakub at gcc dot gnu dot org 2010-09-10 14:40 ---
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
--- Comment #6 from tkoenig at gcc dot gnu dot org 2010-09-10 09:15 ---
(In reply to comment #5)
> I agree that the front-end is missing a statement walker to infer information
> out of the code.
I have a patch for a more general statement walker, which I will probably
submit after the
--- Comment #5 from mikael at gcc dot gnu dot org 2010-09-10 00:32 ---
I agree that the front-end is missing a statement walker to infer information
out of the code.
However, if find the static points-to approach a bit too "static".
For example, consider a case like this:
!
ptr =>
--- Comment #4 from tkoenig at gcc dot gnu dot org 2010-09-08 19:30 ---
This makes a ton of sense to do.
We should also convert the frontend passes to a general expression
walker, as you indicated in one comment.
--
tkoenig at gcc dot gnu dot org changed:
What|Remove
--- Comment #3 from jakub at gcc dot gnu dot org 2010-09-08 12:08 ---
Created an attachment (id=21737)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21737&action=view)
tonto2.f90
Modified testcase from tonto (well, in particular from richi's testcase in one
of the tonto PRs), wher
--- Comment #2 from jakub at gcc dot gnu dot org 2010-09-08 12:05 ---
Created an attachment (id=21736)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21736&action=view)
uu.f90
One testcase I've been playing with. The patch allows optimizing away
temporaries on 3 of the 4 p? = a +
--- Comment #1 from jakub at gcc dot gnu dot org 2010-09-08 12:01 ---
Created an attachment (id=21735)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21735&action=view)
gcc46-pr45596.patch
WIP patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45596
12 matches
Mail list logo