Hi Tobias, I think that constitutes an 'obvious' patch. OK for mainline.
Thanks Paul On Mon, 8 Feb 2021 at 18:53, Tobias Burnus <tob...@codesourcery.com> wrote: > Found when looking at Julian's 3/4 OpenACC patch, which has not > yet been committed (and needs still to be revised a bit.) > > The fix (a) avoids an ICE when Julian's patch has been applied. > The patch (b) just makes one error message less confusing. > > The testcase shows that only %re/%im run reach the new code as > %kind/%len are != EXPR_VARIABLE. (The error message is slightly > misleading if the 'list item'/'var' is not a variable.) > > > (a) We need to handle REF_INQUIRY gfc_is_simplify_contiguous. > > That function is used for 'is_contiguous(a(:)%re)', but it works > without this patch and simplifies already to .false. > And it is used in openmp.c, which can ICE without this patch. > > (b) Just makes the error message nicer - as only EXPR_VARIABLE > reaches that code, only %re and %im are mentioned in the > error message. > > (Actually, it is not completely clear whether %re/%im are invalid > or not; I think they should be – but one can argue otherwise. > For OpenMP I just saw that it is tacked internally in Issue 2661, > for OpenACC it is tracked as Issue 346 – but neither has been > discussed, yet.) > > OK for mainline? > > Tobias > > PS: '%re'/'%im' permit accessing the real/imaginary part of a > complex variable as lvalue (in the C++ sense) and also permit > "var(:)%re = 1.0", which real(z) or imag(z) does not permit. > > var%kind == kind(var), but derived types also permit > parameterized derived types (PDT), which can use '%foo' for respective > 'len' and 'kind' components. > > ----------------- > Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München > Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank > Thürauf > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
