Hi Andre, >> >> 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?
Yes, in principle adding the check for attr.bind_c looks ok to me (alternatively one could also check for attr.unlimited_polymorphic). I think originally BT_VOID was indeed only used in a bind_c context, but recently it has also been 'hijacked' for unlimited polymorphism, e.g. for the STAR symbol and some of the components of the intrinsic vtabs. What I don't really understand is why these problems are triggered by your patch now and have not crept up earlier in other use-cases of CLASS(*). >> >> 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. Ok, good. Could you please post an updated patch? > 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. >From my non-guru POV, it can stay as is. It would be helpful if someone like Paul or Tobias could have a look at the patch before it goes to trunk. I think it's pretty close to being ready for prime-time. Thanks for your work! Cheers, Janus
