https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106692
--- Comment #9 from anlauf at gcc dot gnu.org ---
(In reply to Paul Thomas from comment #8)
> Following your remarks, I tried setting the pointer decl tree static. That
> resulted in the test succeeding for -O but it crashed at higher levels of
> optimization.
>
> Treating the pointer as if it were volatile; ie.
> diff --git a/gcc/fortran/trans-decl.cc b/gcc/fortran/trans-decl.cc
> index 0b1474d7559..faa0e703321 100644
> --- a/gcc/fortran/trans-decl.cc
> +++ b/gcc/fortran/trans-decl.cc
> @@ -747,7 +747,8 @@ gfc_finish_var_decl (tree decl, gfc_symbol * sym)
> TREE_STATIC (decl) = 1;
>
> /* Treat asynchronous variables the same as volatile, for now. */
> - if (sym->attr.volatile_ || sym->attr.asynchronous)
> + if (sym->attr.volatile_ || sym->attr.asynchronous
> + || (sym->attr.cray_pointer && !sym->attr.in_common))
> {
> TREE_THIS_VOLATILE (decl) = 1;
> TREE_SIDE_EFFECTS (decl) = 1;
>
> does the job at all levels of optimization. However, it does cause
> regressions in analyzer/malloc.f90 and analyzer/malloc_example.f90. The
> latter is interesting because the analyzer detects leaks, whereas valgrind
> says that the runtime is OK.
Hi Paul,
it appears more than sufficient to set TREE_THIS_VOLATILE; e.g.
if (sym->attr.cray_pointer && !sym->attr.in_common)
TREE_THIS_VOLATILE (decl) = 1;
to suppress the undesired optimization. However, I think this is not the
right way to fix it: the pointer cannot change under our feet, only the
pointee. And the performance might suffer significantly for code using
Cray pointers.
The optimized tree changes a lot between -Og and -O1 without the above change,
see comment#1. I also cannot figure out which optimization is active in
eliminating the cray pointer comparison with 0. And commenting out the
match.pd part in r238754 does not help, as Marek already noted, so I suspect
it was a different commit that started the regression.
(Regarding the analyzer: of course there is no new memory leak in the
testcases. But the analyzer will see a volatile pointer and probably
must report a possible leak.)
> Do we want to fix this, given Jakub and Tobias's remarks?
I have no stock in Cray pointers. If there were a simple fix, then we
just do it. But the above doesn't look right to me. As the problem
is in the comparison of the Cray pointer with an integer, could it be
an option to cast the pointer to an integer just for that purpose?
> Paul
