[Fortran, Patch] PR60334 - Segmentation fault on character pointer assignments
Tobias Burnus
tobias.burnus@physik.fu-berlin.de
Wed Jan 14 14:17:00 GMT 2015
Hi Paul and Andre, hi all,
Paul Richard Thomas wrote:
...
[From Andre's patch]
> + is a pointer to the variable holding the length. Therefore
> + remove the deref on call. */
> + parmse.string_length = TREE_OPERAND (parmse.string_length, 0);
> This is OK but I would use instead:
...
+ parmse.string_length = build_fold_indirect_ref (parmse.string_length);
That doesn't match the comment: TREE_OPERAND(..., 0) removes the dereference,
yielding a pointer, while your suggestion adds another deref.
The opposite to dereferrencing is to take the address, i.e. using
gfc_build_addr_expr (NULL_TREE, ...)
> If you look in ~/gcc/fold-const.c:15751, you will see that
> TREE_OPERAND (parmse.string_length, 0) but that it is preceded by
> cleaning up of NOOPS and, in any case, its usage will preserve the
> standard API.... just in case the internals change :-)
I think using TREE_OPERAND directly should be fine. The condition
if (INDIRECT_REF_P (parmse.string_length))
is only true if the last operator is an indirect ref; in that case, the object
must be a pointer.
Thus, I think TREE_OPERAND is better than gfc_build_addr_expr.
The only potential issue would be that one has the wrong type; but I think that
this is not possible in this case - and for function argument passing, using
the wrong type would be already wrong even for pass by value (instead of by
reference). [For value passing, one could use a cast/fold_convert(), for by
ref not; however, there isn't one as INDIRECT_REF_P is the outermost operator.]
Tobias
PS: I haven't looked closer at the rest of the patch.
More information about the Gcc-patches
mailing list