Hi Tobias, Yes, OK for trunk.
I would have been perfectly happy for you to commit as 'obvious'. Cheers Paul On Mon, 3 Feb 2020 at 08:44, Tobias Burnus <tob...@codesourcery.com> wrote: > > Another slightly early ping. > > Tobias > > On 1/31/20 3:24 PM, Tobias Burnus wrote: > > *ping* after 4 days. > > > > On 1/27/20 2:49 PM, Tobias Burnus wrote: > >> Semantically, there is an issue when the function name is used both > >> for recursively calling and as result variable. Hence, one should > >> only use one own's function name – in context of function calls – if > >> one has a separate result variable. > >> > >> This somehow got messed up with r10-5722-g4d12437 (3 Jan 2020, > >> PR92994) – rejecting also the use of the function name as result > >> variable. > >> > >> Fixed by removing the check. At least the most straight-forward > >> invalid use is still rejected as shown by the augmented test case. > >> > >> OK for the trunk? > >> > >> Tobias > >> > >> > >> On 1/25/20 6:37 AM, Andrew Benson wrote: > >>> I opened PR 93427 for the issue below: > >>> > >>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93427 > >>> > >>> The following code fails to compile (using git commit > >>> 472dc648ce3e7661762931d584d239611ddca964): > >>> > >>> module a > >>> > >>> type :: t > >>> end type t > >>> > >>> contains > >>> > >>> recursive function b() > >>> class(t), pointer :: b > >>> type(t) :: c > >>> allocate(t :: b) > >>> select type (b) > >>> type is (t) > >>> b=c > >>> end select > >>> end function b > >>> > >>> end module a > >>> > >>> > >>> > >>> $ gfortran -v > >>> Using built-in specs. > >>> COLLECT_GCC=gfortran > >>> COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper > >>> > >>> Target: x86_64-pc-linux-gnu > >>> Configured with: ../gcc-git/configure > >>> --prefix=/home/abenson/Galacticus/Tools > >>> --enable-languages=c,c++,fortran > >>> --disable-multilib > >>> Thread model: posix > >>> Supported LTO compression algorithms: zlib > >>> gcc version 10.0.1 20200124 (experimental) (GCC) > >>> > >>> > >>> $ gfortran -c p.F90 -o p.o > >>> p.F90:12:15: > >>> > >>> 12 | select type (b) > >>> | 1 > >>> Error: Associating entity 'b' at (1) is a procedure name > >>> p.F90:14:5: > >>> > >>> 14 | b=c > >>> | 1 > >>> Error: 'b' at (1) associated to vector-indexed target cannot be used > >>> in a variable definition context (assignment) > >>> > >>> > >>> The code compiles successfully using ifort 18.0.1. Removing the > >>> "recursive" attribute, or specifying a "result()" variable makes the > >>> errors go away. > >>> > >>> > >>> -- > >>> > >>> * Andrew Benson: > >>> http://users.obs.carnegiescience.edu/abenson/contact.html > >>> > >>> * Galacticus: https://github.com/galacticusorg/galacticus -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
