Hi Janus,
thanks for the quick response. Please see my answers inline.
On Sat, 3 Jan 2015 13:12:28 +0100
Janus Weil <ja...@gcc.gnu.org> wrote:
<snipp>
> > I started with the initializer for the _len component and ran into "Pointer
> > assignment target is neither TARGET nor POINTER at %L" errors
> > (expr.c:3714). I tracked this back to the constructor resolve of the class
> > type. Resolving the constructor somehow concludes, that something needs to
> > be done for the constant initializer although it is marked artificial. I
> > could not track down the location that is causing this behavior, or if I
> > need to set a flag in the class itself to get through with it. I am hoping,
> > that either some fortran guru says "You just need to do xyz to get it
> > running." or that we conclude to remove the TODO and the commented
> > instructions (setting a zero value for _len is done where needed
> > (gfc_conv_structure trans-expr.c:6540)).
>
> I can reproduce the "pointer assignment ..." error, but I'm not sure
> if there is any good way to get rid of it.
> I'm not even sure if it is a good idea to add an initializer for the
> _len component at all, since neither _data nor _vptr have one.
> So, I'm fine with just removing the commented code and the TODO
> marker, as long as everything works and you make sure the _len
> component is properly initialized before it is accessed.
Removed it.
> >> For the
> >> second one (in gfc_conv_expr), I don't directly see how it's related
> >> to deferred char-len. Why is this change needed?
> >
> > That change is needed, because in some rare case where an associated
> > variable in a "select type ()" is used, then the type and f90_type match
> > the condition while them not really being in a bind_c context. Therefore I
> > have added the check for bind_c. Btw, I now have removed the TODO, because
> > that case is covered by the regression tests.
>
> I don't understand how f90_type can be BT_VOID without being in a
> BIND_C context, but I'm not really a ISO_C_BINDING expert. Which test
> case is the one that triggered this?
This case is triggered by the test-case in the patch, where in the select type
(w => arg) in module m routine bar the w meets the criteria to make the
condition become true. The type of w is then "fixed" and gfortran would
terminate, because the type of w would be set be and BT_INTEGER. I tried to
backtrace where this is coming from, but to no success. In the resolve () of
the select type it looks all quite ok, but in the trans stage the criteria are
met. Most intriguing to me is, that in the condition we are talking about the
type of w and f90_type of the derived class' ts
(expr->ts.u.derived->ts.f90_type) of w is examined. But expr->ts.u.derived->ts
does not describe the type of w, but of the class w is associate with __STAR...
So I am not quite sure how to fix this, if this really needs fixing. When I
understand you right, then f90_type should only be set in a bind_c context, so
adding that check wouldn't hurt, right?
<snipp>
> >> 3) The function 'gfc_get_len_component' that you're introducing is
> >> only called in a single place. Do you expect this to be useful in
> >> other places in the future, or could one remove the function and
> >> insert the code inline?
> >
> > In one of the first versions it was uses from two locations. But I had to
> > remove one call site again. I am currently not sure, if I will be using it
> > in the patch for allocatable components when deferred char arrays are
> > handled. So what I do I do now? Inline it and when needed make it explicit
> > again in a future patch?
>
> I leave that up to you. In principle I'm fine with keeping it as it
> is. The only problem I see is that the function name sounds rather
> general, but it apparently expects the expression to be an ASSOCIATE
> symbol.
I am nearly finished with the patch on allocatable scalar components and I don't
need the code there. Therefore I have inlined the routine.
So, what do we do about the bind_c issue above? Is some bind_c guru available
to have a look at this? It would be very much appreciated.
Regards,
Andre
--
Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen
Tel.: +49 241 9291018 * Email: ve...@gmx.de
