| Message ID | CAKwh3qiujGsKh+8UTzqC0LO2ncY89W32tNTESXroKF+mq7KXTw@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
Hi Paul, > I am somewhat startled that this was so "easy" to fix (ie. the patch looks > easy but I'll bet that find the fix was not!). well, actually finding it was not so hard: The backtrace in the PR pointed me directly to mio_expr, and a bit of debugging showed that we simply do do handle any refs for function calls. > OK for trunk. Thanks, committed as r205983. > I think that MOD_VERSION does need bumping but I would bow to > good negative arguments from others. I agree. One point is that the MOD_VERSION on trunk (11) is already different from the value on 4.8 (10), i.e. it has already been bumped in this release cycle. Moreover the changes I made are "backward-compatible" in the sense that trunk can still read old module files, and also old gfortran versions should still be able to handle modules written by trunk (as long as they don't contain TBP references - however this is anyway prevented by the already-bumped MOD_VERSION). Cheers, Janus > On 11 December 2013 22:57, Janus Weil <janus@gcc.gnu.org> wrote: >> >> Hi all, >> >> the PR in the subject line involves a module procedure whose result >> has array bounds which contain a type-bound procedure call. Since the >> procedure interface is written to the .mod file, also the TBP >> expression needs to be written. This leads to an ICE, since it simply >> has not been implemented yet. >> >> When writing a function reference, we now discriminate between three >> cases: (1) 'ordinary' procedures, (2) type-bound procedures and (3) >> intrinsic procedures. We first read/write an integer value to indicate >> which case we're dealing with, and then do the specific I/O for this >> case (see patch). Up to now we basically did the same already, but >> only including two cases (ordinary and intrinsic functions). >> >> The patch has been regtested on x86_64-unknown-linux-gnu. Ok for trunk? >> >> Should I also bump the MOD_VERSION? >> >> Cheers, >> Janus >> >> >> >> 2013-12-11 Janus Weil <janus@gcc.gnu.org> >> >> PR fortran/59450 >> * module.c (mio_expr): Handle type-bound function expressions. >> >> >> 2013-12-11 Janus Weil <janus@gcc.gnu.org> >> >> PR fortran/59450 >> * gfortran.dg/typebound_proc_31.f90: New. > > > > > -- > The knack of flying is learning how to throw yourself at the ground and > miss. > --Hitchhikers Guide to the Galaxy
Index: gcc/fortran/module.c =================================================================== --- gcc/fortran/module.c (revision 205857) +++ gcc/fortran/module.c (working copy) @@ -3358,12 +3358,24 @@ mio_expr (gfc_expr **ep) { e->value.function.name = mio_allocated_string (e->value.function.name); - flag = e->value.function.esym != NULL; + if (e->value.function.esym) + flag = 1; + else if (e->ref) + flag = 2; + else + flag = 0; mio_integer (&flag); - if (flag) - mio_symbol_ref (&e->value.function.esym); - else - write_atom (ATOM_STRING, e->value.function.isym->name); + switch (flag) + { + case 1: + mio_symbol_ref (&e->value.function.esym); + break; + case 2: + mio_ref_list (&e->ref); + break; + default: + write_atom (ATOM_STRING, e->value.function.isym->name); + } } else { @@ -3372,10 +3384,15 @@ mio_expr (gfc_expr **ep) free (atom_string); mio_integer (&flag); - if (flag) - mio_symbol_ref (&e->value.function.esym); - else + switch (flag) { + case 1: + mio_symbol_ref (&e->value.function.esym); + break; + case 2: + mio_ref_list (&e->ref); + break; + default: require_atom (ATOM_STRING); e->value.function.isym = gfc_find_function (atom_string); free (atom_string);
Hi all, the PR in the subject line involves a module procedure whose result has array bounds which contain a type-bound procedure call. Since the procedure interface is written to the .mod file, also the TBP expression needs to be written. This leads to an ICE, since it simply has not been implemented yet. When writing a function reference, we now discriminate between three cases: (1) 'ordinary' procedures, (2) type-bound procedures and (3) intrinsic procedures. We first read/write an integer value to indicate which case we're dealing with, and then do the specific I/O for this case (see patch). Up to now we basically did the same already, but only including two cases (ordinary and intrinsic functions). The patch has been regtested on x86_64-unknown-linux-gnu. Ok for trunk? Should I also bump the MOD_VERSION? Cheers, Janus 2013-12-11 Janus Weil <janus@gcc.gnu.org> PR fortran/59450 * module.c (mio_expr): Handle type-bound function expressions. 2013-12-11 Janus Weil <janus@gcc.gnu.org> PR fortran/59450 * gfortran.dg/typebound_proc_31.f90: New.