With the attached test case I get: [sfilippo@localhost type_ambiguity]$ gfortran -v -c type_ambiguity.f90 Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.3.1/configure --prefix=/usr/local/gcc43 --with-mpfr=/usr/local/mpfr --with-gmp=/usr/local/gmp Thread model: posix gcc version 4.3.1 (GCC) COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=generic' /usr/local/gcc43/libexec/gcc/i686-pc-linux-gnu/4.3.1/f951 type_ambiguity.f90 -quiet -dumpbase type_ambiguity.f90 -mtune=generic -auxbase type_ambiguity -version -fintrinsic-modules-path /usr/local/gcc43/lib/gcc/i686-pc-linux-gnu/4.3.1/finclude -o /tmp/cc6I26kb.s GNU F95 (GCC) version 4.3.1 (i686-pc-linux-gnu) compiled by GNU C version 4.3.1, GMP version 4.2.2, MPFR version 2.3.0. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 type_ambiguity.f90:283.14: type(vector) :: new_pos ! the new vertex position, after smoothing 1 Error: Type name 'vector' at (1) is ambiguous I cannot see any ambiguity in the source code. The code compiles cleanly on 4.2.4, fails on 4.4-20080822, compiles cleanly on Intel 10.1.015 and on XLF 10.1. The code has been extracted from an application, and has been heavily pruned. The Intel compiler gives a warning about an intent(out) variable not being set, but this is an artifact of pruning the test case. The most puzzling things are the two workarounds that I have found so far: 1. In the subroutine smooth_mesh, comment the USE statement at line 279. This is not an option in the original application code, though. 2. In the subroutine smooth_mesh, switch the order of the USE statements at lines 277/278; this also fixes the original application code. I cannot see anything illegal in the code, so I presume it is a reject-valid; however even if the code is shown to be illegal, the reported error does precious little to help the user. Salvatore
Created attachment 16159 [details] test case
Confirmed Salvatore, what is the date on your 4.2.4? Is it the release version - ie. 19th May 2008? Cheers Paul
Yes, it's the release. [sfilippo@localhost type_ambiguity]$ gfortran -v -c type_ambiguity.f90 Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.2.4/configure Thread model: posix gcc version 4.2.4 /usr/local/libexec/gcc/i686-pc-linux-gnu/4.2.4/f951 type_ambiguity.f90 -quiet -dumpbase type_ambiguity.f90 -mtune=generic -auxbase type_ambiguity -version -I /usr/local/lib/gcc/i686-pc-linux-gnu/4.2.4/finclude -o /tmp/ccZJJLfj.s GNU F95 version 4.2.4 (i686-pc-linux-gnu) compiled by GNU C version 4.2.4. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 as -V -Qy -o type_ambiguity.o /tmp/ccZJJLfj.s GNU assembler version 2.17.50.0.12-4 (i386-redhat-linux) using BFD version 2.17.50.0.12-4 20070128 [sfilippo@localhost type_ambiguity]$
Does it have anything to do with 36374?
(In reply to comment #4) > Does it have anything to do with 36374? > Salvatore, I don't think so, since this PR is a regression. Anyway, I'll take a look at them both together.... in a few days. I'm still not entirely back in action after my move to Barcelona and the theft of my laptop; in particular, I still do not have a working tree that I can use for debugging. As soon as posssible.... honest! Paul
Created attachment 16163 [details] A reduced version of the testcase I still do not feel much the wiser - making vector visible in class motion makes the problem go away. This evidently gives the component 'law_y' of 'motion' a visible type that is no longer ambiguous with the "real" 'vector'. Paul
I think this should be rejected : module class_vector implicit none type vector end type vector end module class_vector module tools_math implicit none interface lin_interp function lin_interp_v() use class_vector type(vector ) :: lin_interp_v end function lin_interp_v end interface end module tools_math module smooth_mesh use tools_math implicit none type(vector ) :: new_pos ! vector shouldn't be available IMHO end module smooth_mesh I find this behavior very confusing, inconsistent with the concept of scoping units. While I understand that vector should make its way to the tools_math.mod file for lin_interp_v's type checking, it should be kept local to that function. I haven't seen it explicitely in the standard though. Salvatore, as a workaround you can put a private statement in modules where you "use module" from within a function.
Created attachment 16171 [details] another testcase with comments telling how to get/not get the error Look at the comments in module class_bc_math. This is very strange.
Forget comment #8. I was testing with version 4.3.1
(In reply to comment #7) > I think this should be rejected : > I think your example should be rejected, but it is not like my code, where smooth_mesh explicitly USEs class_vector. So, I am not sure what's your point. Salvatore
(In reply to comment #10) > I think your example should be rejected, but it is not like my code, where > smooth_mesh explicitly USEs class_vector. So, I am not sure what's your point. My point is this: As you said in your first comment, there is no ambiguity in your code. vector is defined in only one module which is used when needed in other modules. Moreover you use private statements to prevent use associated entities from being exported in those modules. Doing this way, no module but class_vector exports vector. No ambiguity possible What my example shows is that tools_math (and other modules in your code) export vector as well. Ambiguities are possible. As gfortran seems to handle simple ambiguities correctly, what I'm underlying is not the bug, but it might be part of it.
Actually, my comment #7 seems to be more related to bug #36374.
(In reply to comment #12) > Actually, my comment #7 seems to be more related to bug #36374. No, it's not
(In reply to comment #11) > My point is this: > As you said in your first comment, there is no ambiguity in your code. > vector is defined in only one module which is used when needed in other > modules. > Moreover you use private statements to prevent use associated entities from > being exported in those modules. Well, the code would be legal even without the private statement, I can USE definitions directly or indirectly as many times as I like. Or at least so I understand..... Salvatore
Since I am homing in on a solution, I might as well take it on. Cheers Paul
> I find this behavior very confusing, inconsistent with the concept of scoping > units. (In reply to comment #7) > I think this should be rejected : Lahey and deep contemplation agree with you:-) I am trying to understand why this happens - it's not just interfaces but contained functions too. Paul
(In reply to comment #16) Lest anybody is worrying about the patch that I posted, I cannot commit until tonight or tomorrow morning. Since my laptop was stolen, I have no means to update my tree nor commit anything when I am on the road - my work laptop does not give me administrator rights:-( Paul
Subject: Bug 37274 Author: pault Date: Wed Sep 17 22:23:51 2008 New Revision: 140434 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140434 Log: 2008-09-18 Paul Thomas <pault@gcc.gnu.org> PR fortran/37274 PR fortran/36374 * module.c (check_for_ambiguous): New function to test loaded symbol for ambiguity with fixup symbol. (read_module): Call check_for_ambiguous. (write_symtree): Do not write the symtree for symbols coming from an interface body. PR fortran/36374 * resolve.c (count_specific_procs ): New function to count the number of specific procedures with the same name as the generic and emit appropriate errors for and actual argument reference. (resolve_assumed_size_actual): Add new argument no_formal_args. Correct logic around passing generic procedures as arguments. Call count_specific_procs from two locations. (resolve_function): Evaluate and pass no_formal_args. (resolve call): The same and clean up a bit by using csym more widely. PR fortran/36454 * symbol.c (gfc_add_access): Access can be updated if use associated and not private. 2008-09-18 Paul Thomas <pault@gcc.gnu.org> PR fortran/37274 * gfortran.dg/used_types_22.f90: New test. * gfortran.dg/used_types_23.f90: New test. PR fortran/36374 * gfortran.dg/generic_17.f90: New test. * gfortran.dg/ambiguous_specific_2.f90: New test. * gfortran.dg/generic_actual_arg.f90: Add test for case that is not ambiguous. PR fortran/36454 * gfortran.dg/access_spec_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/access_spec_3.f90 trunk/gcc/testsuite/gfortran.dg/ambiguous_specific_2.f90 trunk/gcc/testsuite/gfortran.dg/generic_17.f90 trunk/gcc/testsuite/gfortran.dg/used_types_22.f90 trunk/gcc/testsuite/gfortran.dg/used_types_23.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/generic_actual_arg.f90
Fixed on trunk Thanks for the report Paul
Subject: Bug 37274 Author: pault Date: Tue Sep 23 06:25:39 2008 New Revision: 140578 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140578 Log: 2008-09-23 Paul Thomas <pault@gcc.gnu.org> PR fortran/37274 PR fortran/36374 * module.c (check_for_ambiguous): New function to test loaded symbol for ambiguity with fixup symbol. (read_module): Call check_for_ambiguous. (write_symtree): Do not write the symtree for symbols coming from an interface body. PR fortran/36374 * resolve.c (count_specific_procs ): New function to count the number of specific procedures with the same name as the generic and emit appropriate errors for and actual argument reference. (resolve_assumed_size_actual): Add new argument no_formal_args. Correct logic around passing generic procedures as arguments. Call count_specific_procs from two locations. (resolve_function): Evaluate and pass no_formal_args. (resolve call): The same and clean up a bit by using csym more widely. PR fortran/36454 * symbol.c (gfc_add_access): Access can be updated if use associated and not private. 2008-09-23 Paul Thomas <pault@gcc.gnu.org> PR fortran/37274 * gfortran.dg/used_types_22.f90: New test. * gfortran.dg/used_types_23.f90: New test. PR fortran/36374 * gfortran.dg/generic_17.f90: New test. * gfortran.dg/ambiguous_specific_2.f90: New test. * gfortran.dg/generic_actual_arg.f90: Add test for case that is not ambiguous. PR fortran/36454 * gfortran.dg/access_spec_3.f90: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/access_spec_3.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/ambiguous_specific_2.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/generic_17.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/used_types_22.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/used_types_23.f90 Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/module.c branches/gcc-4_3-branch/gcc/fortran/resolve.c branches/gcc-4_3-branch/gcc/fortran/symbol.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/generic_actual_arg.f90
Fixed on trunk and 4.3. Thanks for the report Paul PS The original problem was not present in 4.3 but the reduced version was.