2013/4/22 Tobias Burnus <bur...@net-b.de>: > Am 22.04.2013 20:00, schrieb Janus Weil: >>> >>> >Side remark and just for completeness, there is also rank == -1 for >>> >assumed-rank arrays. However, as TRANSFER is not an inquiry function, it >>> >shouldn't reach that code. (Maybe you could quickly check that that's >>> > indeed >>> >the case.) >> >> well, I guess you*can* actually reach that code with assumed-rank >> >> arrays, e.g. via >> >> subroutine assumed_rank (a) >> integer, intent(in) :: a(..) >> integer :: c(1:4) >> c = transfer(a,c,4) >> end subroutine >> >> So, good point! The code part quoted above has been removed in the >> last revision, but I have updated gfc_target_expr_size to check for >> "(e->rank)" now (i.e. without the "> 0"), and I have also added the >> above test case (which indeed showed the false warning with the last >> version of the patch, but not any more). > > > Checking for "rank" instead of "rank >0" is fine - but I wouldn't add the > test case as it is invalid
ok, committed as r198155. Will backport to 4.8 and 4.7 in about a week or so ... > and gfortran should reject the code according > to the following TS29113 constraint: > > "C535b An assumed-rank variable name shall not appear in a designator or > expression except as an actual argument corresponding to a dummy argument > that is assumed-rank, the argument of the C_LOC function in the > ISO_C_BINDING intrinsic module, or the first argument in a reference to an > intrinsic inquiry function." > > Seemingly, the constraint code is not correctly checked for intrinsics as > TRANSFER is a transformational function. > > I wonder whether TYPE(*) and !GCC$ attributes no_arg_check have the same > problems as similar constraints exist for those. > > I have now filled: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57035 Ok, thanks! Cheers, Janus
