I am not sure whether the code snippet is legal at all, but it should emit an error, not an ICE. --snip module bug implicit none contains subroutine tbug integer :: i i = len("123") call sub(len) end subroutine tbug end module bug --snip >gfortran -c fbug1.f90 fbug1.f90: In Funktion »tbug«: fbug1.f90:6: interner Compiler-Fehler: in gfc_typenode_for_spec, bei fortran/trans-types.c:651 Bitte senden Sie einen vollständigen Fehlerbericht auf Englisch ein; bearbeiten Sie die Quellen zunächst mit einem Präprozessor, wenn es dienlich ist. Fehler in der deutschen Übersetzung sind an translation-team-de@lists.sourceforge.net zu melden. Gehen Sie gemäß den Hinweisen in <URL:http://gcc.gnu.org/bugs.html> vor. >gfortran --version GNU Fortran 95 (GCC) 4.2.0 20060603 (experimental) Copyright (C) 2006 Free Software Foundation, Inc. --snip
(In reply to comment #0) > I am not sure whether the code snippet is legal at all, but it should emit an > error, not an ICE. Klaus, It is legal and should compile OK. It is related to PR27554 and various predecessors, even though the symtoms are somewhat different. I essence passing intrinsics as actual arguments is somewhat broken. I have put these onto a "look at as soon as possible list". Thank you for the report. Paul
Since I took on the other, similar bug, I might as well do this one too! Paul
I'm about to submit a patch that globally fixes this problem of intrinsics as actual arguments, but this one is still eluding me. It's due to the "implicit none" statement, and it works otherwise.
Further reduced testcase (no need for a module): implicit none integer i i = len("123") call sub(len) end When the len in "call sub(len)" is resolved, it is never given its correct return type, which leads to the ICE. I still don't understand why the implicit none is doing this on us... Paul, any idea?
FX, > When the len in "call sub(len)" is resolved, it is never given its correct > return type, which leads to the ICE. I still don't understand why the implicit > none is doing this on us... Paul, any idea? > ..bother, yes I was onto this.... a while back. I will consult my notes and come back to you. I got severely stuck for some reason that I do not recall. Paul
(In reply to comment #5) > FX, > > When the len in "call sub(len)" is resolved, it is never given its correct > > return type, which leads to the ICE. I still don't understand why the implicit > > none is doing this on us... Paul, any idea? > > > ..bother, yes I was onto this.... a while back. I will consult my notes and > come back to you. I got severely stuck for some reason that I do not recall. > Paul I am glad to see that you are pursuing that one. I nearly bust my head on it my notes indicate that I had a fix that broke everything else; no details, so not much help I'm afraid. I think that you had better take it that I got nowhere! The bug that involves INDEX (PR???) is clearer. The mechanism, in trans-decl(gfc_get_extern_function_decl), for handling intrinsics simply does not allow that number of arguments. I tried to extend it by looking at isym->resolve.f1 and f2. It seemed to work but I did not have time to work on it. I saw the correspondence on comp.lang.fortran about this. I note that INDEX is explicitly allowable as an actual argument. That said, there is no mention in 13.13 of the optional argument BACK. Is that intentional, do you think? Since you are actively working on this, I have reassigned it to you. I hope that's OK? Best regards Paul
(In reply to comment #6) > I am glad to see that you are pursuing that one. I nearly bust my head on it > my notes indicate that I had a fix that broke everything else; no details, so > not much help I'm afraid. I think that you had better take it that I got > nowhere! Well, this is really about the resolution scheme, which I still don't fully understand, so I'm in the dark here too. I'll give it a longer shot over the next week-end. > The bug that involves INDEX (PR???) is clearer. The mechanism, in > trans-decl(gfc_get_extern_function_decl), for handling intrinsics simply does > not allow that number of arguments. I tried to extend it by looking at > isym->resolve.f1 and f2. It seemed to work but I did not have time to work on > it. That bug is fixed by my submitted patch about INTRINSICS (http://gcc.gnu.org/ml/fortran/2006-10/msg00022.html).
Subject: Re: ICE using intrinsics as arguments FX >That bug is fixed by my submitted patch about INTRINSICS >(http://gcc.gnu.org/ml/fortran/2006-10/msg00022.html). > > > > I'll review it tomorrow - I am going to give gfortran a break tonight! Whilst I am about it, I will put my thinking cap on about PR27900, whilst I am about it. At lunchtime, I made an automatic loop reverser for the scalarizer. It works fine but breaks other cases. A very promising start for one hour's work though (I have been cogitating about this for some weeks, I must admit.). A. Paul
(In reply to comment #6) > Since you are actively working on this, I have reassigned it to you. I hope > that's OK? It was OK, but I spent time looking at it and looking again, and I can't figure it out. Unassigning myself, sorry!
Patch just submitted. Paul
Subject: Bug number PR27900 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01874.html
Subject: Bug 27900 Author: pault Date: Sun Dec 31 07:51:47 2006 New Revision: 120296 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120296 Log: 2006-12-31 Paul Thomas <pault@gcc.gnu.org> PR fortran/27900 * resolve.c (resolve_actual_arglist): If all else fails and a procedure actual argument has no type, see if a specific intrinsic matches. PR fortran/24325 * resolve.c (resolve_function): If the function reference is FL_VARIABLE this is an error. 2006-12-31 Paul Thomas <pault@gcc.gnu.org> PR fortran/27900 * gfortran.dg/intrinsic_actual_4.f90: New test. PR fortran/24325 * gfortran.dg/func_decl_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/func_decl_3.f90 trunk/gcc/testsuite/gfortran.dg/intrinsic_actual_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
Subject: Bug 27900 Author: pault Date: Sat Jan 6 14:13:20 2007 New Revision: 120525 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120525 Log: 2007-01-06 Paul Thomas <pault@gcc.gnu.org> Bug fixes from trunk PR fortran/30034 * resolve.c (resolve_formal_arglist): Exclude the test for pointers and procedures for subroutine arguments as well as functions. PR fortran/30237 * intrinsic.c (remove_nullargs): Do not pass up arguments with a label. If the actual has a label and the formal has a type then emit an error. PR fortran/25135 * module.c (load_generic_interfaces): If the symbol is present and is not generic it is ambiguous. PR fortran/23060 * intrinsic.c (compare_actual_formal ): Distinguish argument list functions from keywords. * intrinsic.c (sort_actual): If formal is NULL, the presence of an argument list function actual is an error. * trans-expr.c (conv_arglist_function) : New function to implement argument list functions %VAL, %REF and %LOC. (gfc_conv_function_call): Call it. * resolve.c (resolve_actual_arglist): Add arg ptype and check argument list functions. (resolve_function, resolve_call): Set value of ptype before calls to resolve_actual_arglist. * primary.c (match_arg_list_function): New function. (gfc_match_actual_arglist): Call it before trying for a keyword argument. PR fortran/27900 * resolve.c (resolve_actual_arglist): If all else fails and a procedure actual argument has no type, see if a specific intrinsic matches. PR fortran/24325 * resolve.c (resolve_function): If the function reference is FL_VARIABLE this is an error. 2007-01-06 Paul Thomas <pault@gcc.gnu.org> PR fortran/30034 * gfortran.dg/pure_formal_proc_1.f90: New test. PR fortran/30237 * gfortran.dg/intrinsic_actual_3.f90: New test. PR fortran/25135 * gfortran.dg/generic_11.f90: New test. * gfortran.dg/interface_7.f90: Remove name clash between module name and procedure 'x' referenced in the interface. PR fortran/23060 * gfortran.dg/c_by_val.c: Called by c_by_val_1.f. * gfortran.dg/c_by_val_1.f: New test. * gfortran.dg/c_by_val_2.f: New test. * gfortran.dg/c_by_val_3.f: New test. PR fortran/27900 * gfortran.dg/intrinsic_actual_4.f90: New test. PR fortran/24325 * gfortran.dg/func_decl_3.f90: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/c_by_val.c branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/c_by_val_1.f branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/c_by_val_2.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/c_by_val_3.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/func_decl_3.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/generic_11.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/intrinsic_actual_3.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/intrinsic_actual_4.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/pure_formal_proc_1.f90 Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/interface.c branches/gcc-4_2-branch/gcc/fortran/intrinsic.c branches/gcc-4_2-branch/gcc/fortran/module.c branches/gcc-4_2-branch/gcc/fortran/primary.c branches/gcc-4_2-branch/gcc/fortran/resolve.c branches/gcc-4_2-branch/gcc/fortran/trans-expr.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/dummy_procedure_1.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/interface_7.f90
Fixed on trunk and 4.2 Paul