This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RE: [PATCH, FORTRAN] Fix PR fortran/60718
- From: Bernd Edlinger <bernd dot edlinger at hotmail dot de>
- To: Tobias Burnus <tobias dot burnus at physik dot fu-berlin dot de>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, "fortran at gcc dot gnu dot org" <fortran at gcc dot gnu dot org>
- Date: Fri, 11 Apr 2014 14:39:57 +0200
- Subject: RE: [PATCH, FORTRAN] Fix PR fortran/60718
- Authentication-results: sourceware.org; auth=none
- References: <20140411113733 dot GA7852 at physik dot fu-berlin dot de>
Hi Tobias,
On Fri, 11 Apr 2014 13:37:46, Tobias Burnus wrote:
>
> Hi Bernd,
>
> Bernd Edlinger wrote:
>> It was caused by a strict aliasing violation, when passing a value of the type
>> "class(x),pointer" to a formal procedure parameter of the type "class(x),target".
>
> I assume a VIEW_CONVERT_EXPR is directly on the argument is insufficient? Otherwise,
> I think I would prefer that:
>
> + gfc_conv_expr (&parmse, e);
> + parmse.expr = fold_build1_loc (input_location,
> + VIEW_CONVERT_EXPR,
> + type, parmse.expr));
> + parmse.expr = gfc_build_addr_expr (parmse.expr)
>
>
> Otherwise, the approach of using a temporary is okay, but I believe the condition
>
Yes, I tried that qickly, but this does not fix the test case.
>> + else if (e->ts.type == BT_CLASS && fsym
>> + && fsym->ts.type == BT_CLASS
>> + && fsym->attr.target)
>
> is wrong. What you intent to do is independent of the target attribute (~ restrict
> qualifier).
>
Hmm,
I was hoping somehow that only that test case is broken,
and needs to be fixed. The target attribute is somehow simple,
it implies intent(in) and the actual value will in most cases
be a pointer, as in the example.
>
> We have three different cases:
>
> * Allocatable
> * Pointer
> * Nonalloc/nonpointer
>
> Besides staying in one's own group, one can do:
>
> Pointer -> Nonalloc
> Allocatable -> Noalloc
> Nonallocatable*/Allocatable* -> Pointer with intent(in)
>
> * = must have the target attribute
>
Well, this approach does not handle intent(inout) at all.
If that is possible, the changed value must be written back again.
Are there any test cases for these conversions?
> Thus, you need to handle those; gfc_expr_attr(e) should give you
> information about the expression. Or one could always check against
> gfc_typenode_for_spec (&fsym->ts);
> of both fsym and e.
>
I am not sure, does gfc_typenode_for_spec always allocate new nodes?
Thanks
Bernd.
> Tobias