[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