This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Fortran, Patch] PR60334 - Segmentation fault on character pointer assignments


Hi Tobias, hi Paul, hi all,

sorry, for the mess. I did not understand the meaning of
build_fold_indirect_ref in the circumstances Paul pointed out. So if no
objections exist, I like to propose the previous patch from:

https://gcc.gnu.org/ml/fortran/2015-01/msg00056.html

to address the issue in pr60334. This resolves the issue.

Regards,
	Andre

On Wed, 14 Jan 2015 14:57:57 +0100
Tobias Burnus <tobias.burnus@physik.fu-berlin.de> wrote:

> 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.


-- 
Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen
Tel.: +49 241 9291018 * Email: vehre@gmx.de 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]