[Bug fortran/37638] ICE in update_arglist_pass
--- Comment #7 from domob at gcc dot gnu dot org 2008-10-05 06:41 --- Subject: Bug 37638 Author: domob Date: Sun Oct 5 06:39:37 2008 New Revision: 140880 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140880 Log: 2008-10-05 Daniel Kraft [EMAIL PROTECTED] PR fortran/37638 * gfortran.h (struct gfc_typebound_proc): New flag `error'. * resolve.c (update_arglist_pass): Added assertion. (update_compcall_arglist): Fail early for erraneous procedures to avoid confusion later. (resolve_typebound_generic_call): Ignore erraneous specific targets and added assertions. (resolve_typebound_procedure): Set new `error' flag. 2008-10-05 Daniel Kraft [EMAIL PROTECTED] PR fortran/37638 * gfortran.dg/typebound_call_9.f03: New test. Added: trunk/gcc/testsuite/gfortran.dg/typebound_call_9.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37638
[Bug fortran/37638] ICE in update_arglist_pass
--- Comment #8 from domob at gcc dot gnu dot org 2008-10-05 06:41 --- Fixed on trunk. -- domob at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37638
[Bug fortran/37638] ICE in update_arglist_pass
--- Comment #4 from domob at gcc dot gnu dot org 2008-10-04 10:16 --- The problem is clearly that because of the error the type-bound procedure remains in a somewhat dubious state (its pass_arg_num is invalid) and this causes the ICE when resolving an actual call to it afterwards. This is of course easy to fix. But I wonder about what a subsequent call to the procedure should do, as the PASS could not be resolved... This will then probably generate errors about actual/formal arglist mismatch for correct calls where only the name inside PASS(x) is wrong. Is this ok? The easiest would probably be to take PASS(invalid) as NOPASS or interpret it as PASS without argument name for that matter. Another solution would be to simply ignore calls to such an erraneous procedure in the resolver (and set them to EXEC_NOP for instance to avoid later confusion of gfortran?) which would mean that there is no error checking at all for them; but as this is not possible anyway, maybe that should be the way to go? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37638
[Bug fortran/37638] ICE in update_arglist_pass
--- Comment #5 from sfilippone at uniroma2 dot it 2008-10-04 10:29 --- (In reply to comment #4) The problem is clearly that because of the error the type-bound procedure remains in a somewhat dubious state (its pass_arg_num is invalid) and this causes the ICE when resolving an actual call to it afterwards. This is of course easy to fix. But I wonder about what a subsequent call to the procedure should do, as the PASS could not be resolved... This will then probably generate errors about actual/formal arglist mismatch for correct calls where only the name inside PASS(x) is wrong. Is this ok? The easiest would probably be to take PASS(invalid) as NOPASS or interpret it as PASS without argument name for that matter. Another solution would be to simply ignore calls to such an erraneous procedure in the resolver (and set them to EXEC_NOP for instance to avoid later confusion of gfortran?) which would mean that there is no error checking at all for them; but as this is not possible anyway, maybe that should be the way to go? Hmm. I see that in my previous comment #3 I said the wrong thing: the attached sample code should be correct, once the name in the PASS argument is fixed. The reasoning behind #3 is that in my original code I have types derived from base_foo_type, which means that for *those* types an argument mismatch must be issued if I try to invoke makenull, until the CLASS() declaration is implemented, so that the makenull() body can be written in the proper way. So, I was still thinking of my code and not of the cut-down test case. Sorry for the confusion. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37638
[Bug fortran/37638] ICE in update_arglist_pass
--- Comment #6 from domob at gcc dot gnu dot org 2008-10-04 10:40 --- (In reply to comment #5) Hmm. I see that in my previous comment #3 I said the wrong thing: the attached sample code should be correct, once the name in the PASS argument is fixed. The reasoning behind #3 is that in my original code I have types derived from base_foo_type, which means that for *those* types an argument mismatch must be issued if I try to invoke makenull, until the CLASS() declaration is implemented, so that the makenull() body can be written in the proper way. So, I was still thinking of my code and not of the cut-down test case. Sorry for the confusion. No problem, in fact I was generally wondering how to handle this situation; I'm now going to write up a patch where there would simply be an error for the PROCEDURE declaration (of course), no ICE (also of course) and the call would not print an error for any mismatched or not mismatched arglist, as this would be problematic. Well, we'll see what the final patch will look like :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37638
[Bug fortran/37638] ICE in update_arglist_pass
--- Comment #1 from sfilippone at uniroma2 dot it 2008-09-24 13:51 --- Created an attachment (id=16400) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16400action=view) test case ICE-on-invalid -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37638
[Bug fortran/37638] ICE in update_arglist_pass
--- Comment #2 from domob at gcc dot gnu dot org 2008-09-24 14:39 --- Thanks for the report Salvatore, I'll take this one on. It seems the new F2003 features are starting to getting used, from the bug-noise :D -- domob at gcc dot gnu dot org changed: What|Removed |Added CC||domob at gcc dot gnu dot org AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-09-24 14:39:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37638
[Bug fortran/37638] ICE in update_arglist_pass
--- Comment #3 from sfilippone at uniroma2 dot it 2008-09-24 14:50 --- (In reply to comment #2) Thanks for the report Salvatore, I'll take this one on. It seems the new F2003 features are starting to getting used, from the bug-noise :D Unfortunately these features are not going to be very useful until CLASS() is implemented; indeed, the code is invalid, but if you change pass(a) into pass(m) it would still be invalid because the makenull procedure should be written with a CLASS() and not a TYPE() argument. In fact, if you comment the second contained subroutine the ICE goes away. As soon as CLASS() is in you (and PaulT) may expect a lot more noise :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37638
