https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113377
--- Comment #5 from Mikael Morin <mikael at gcc dot gnu.org> --- (In reply to anlauf from comment #2) > Note that adding a scalar call in function one: > > r(1) = two (i(1), j) > > generates sane code: > > *((integer(kind=4) *) __result.0 + (sizetype) ((offset.1 + NON_LVALUE_EXPR > <stride.0>) * 4)) = two (&(*i)[0], j != 0B ? *j : 0, j != 0B); > > (...) > > There is another observation: using the value attribute for j also in one, > the scalar call from above becomes a straight > > *((integer(kind=4) *) __result.0 + (sizetype) ((offset.1 + NON_LVALUE_EXPR > <stride.0>) * 4)) = two (&(*i)[0], j, .j); > > while the scalarizer produces: > > integer(kind=4) * D.4340; > ... > D.4340 = &j; > ... > *((integer(kind=4) *) __result.0 + (sizetype) ((S.3 * D.4342 + > D.4339) * 4)) = two (&(*i)[S.3 + -1], *D.4340); > > which looks more complicated (besides being wrong...) Wrong I agree, but is it really more complicated? (In reply to anlauf from comment #3) > Created attachment 57108 [details] > Patch to play with > > This is a first attempt to outline code for handling scalar dummies with the > VALUE attribute. > > This fixes the following variants of the declaration of dummy argument j > in function one: > > integer, value, optional :: j > integer, intent(in), optional :: j > integer, intent(in), optional :: j(4) > integer, intent(in), optional :: j(:) > Looks promising, maybe push a fix for just these cases as a first step? > However, > > integer, allocatable,optional :: j > Allocatable AND optional? The standard seems to accept those, but do we support them? ... (searches) ... Alright, we have some in the testsuite. ... (searches) ... The argument passing convention is a double pointer in this case. > still does not work: the code *in* the generated loop looks fine to me, but > the scalarizer dereferences j before the loop. > > I think that this is correct F2018+, as ifx handles it fine. > Not sure how to proceed here. > > > Furthermore, the patch tries to cope (= prevent an ICE) with > > integer, allocatable,optional :: j(:) > > which I think might be invalid. At least it also crashed with ifx... > There is an error to report if it's invalid, but I doubt it is.
