* [Patch, Fortran] PR 42072: [F03] wrong-code with C_F_PROCPOINTER @ 2009-11-17 22:39 Janus Weil 2009-11-18 10:39 ` Paul Richard Thomas 0 siblings, 1 reply; 7+ messages in thread From: Janus Weil @ 2009-11-17 22:39 UTC (permalink / raw) To: gfortran, gcc-patches [-- Attachment #1: Type: text/plain, Size: 1454 bytes --] Hi all, the attached patch fixes the behavior of C_F_PROCPOINTER if its procptr argument is itself a dummy argument of another procedure. For this case I added an additional 'build_fold_indirect_ref_loc', and I also removed an unneeded 'tmp' variable. The patch was regtested on x86_64-unknown-linux-gnu with no failures. Ok for trunk? Two side-notes: 1) About the wrong static decl (cf. comments #3 and #5): I currently have no idea how this comes about, and why the static prototype is different from the actual declaration of the function. Does anyone have an idea? 2) Once again I stumbled over the fact that the ISO_C_BINDING intrinsics are handled in gfc_conv_procedure_call, in contrast to all the other intrinsics, which are translated in trans-intrinsic.c. It seems to me that gfc_conv_procedure_call is not a particularly good place for this, as it is already a *huge* routine (several hundred lines), even without the additional clobbering due to these intrinsics. Is there a special reason that this is done in this very place, or should we rather move this code to trans-intrinsic.c? (If the latter, I would open a cleanup PR for this.) Cheers, Janus 2009-11-17 Janus Weil <janus@gcc.gnu.org> PR fortran/42072 * trans-expr.c (gfc_conv_procedure_call): Handle procedure pointer dummies which are passed to C_F_PROCPOINTER. 2009-11-17 Janus Weil <janus@gcc.gnu.org> PR fortran/42072 * gfortran.dg/proc_ptr_8.f90: Extended. [-- Attachment #2: pr42072.diff --] [-- Type: text/x-diff, Size: 1928 bytes --] Index: gcc/testsuite/gfortran.dg/proc_ptr_8.f90 =================================================================== --- gcc/testsuite/gfortran.dg/proc_ptr_8.f90 (revision 154242) +++ gcc/testsuite/gfortran.dg/proc_ptr_8.f90 (working copy) @@ -23,12 +23,23 @@ MODULE X END MODULE X USE X -PROCEDURE(mytype), POINTER :: ptype +PROCEDURE(mytype), POINTER :: ptype,ptype2 CALL init() CALL C_F_PROCPOINTER(funpointer,ptype) if (ptype(3) /= 9) call abort() +! the stuff below was added with PR 42072 +call setpointer(ptype2) +if (ptype2(4) /= 12) call abort() + +contains + + subroutine setpointer (p) + PROCEDURE(mytype), POINTER :: p + CALL C_F_PROCPOINTER(funpointer,p) + end subroutine + END ! { dg-final { cleanup-modules "X" } } Index: gcc/fortran/trans-expr.c =================================================================== --- gcc/fortran/trans-expr.c (revision 154242) +++ gcc/fortran/trans-expr.c (working copy) @@ -2640,14 +2640,17 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * gfc_conv_expr (&fptrse, arg->next->expr); gfc_add_block_to_block (&se->pre, &fptrse.pre); gfc_add_block_to_block (&se->post, &fptrse.post); + + if (arg->next->expr->symtree->n.sym->attr.proc_pointer + && arg->next->expr->symtree->n.sym->attr.dummy) + fptrse.expr = build_fold_indirect_ref_loc (input_location, + fptrse.expr); + + se->expr = fold_build2 (MODIFY_EXPR, TREE_TYPE (fptrse.expr), + fptrse.expr, + fold_convert (TREE_TYPE (fptrse.expr), + cptrse.expr)); - if (gfc_is_proc_ptr_comp (arg->next->expr, NULL)) - tmp = gfc_get_ppc_type (arg->next->expr->ref->u.c.component); - else - tmp = TREE_TYPE (arg->next->expr->symtree->n.sym->backend_decl); - se->expr = fold_build2 (MODIFY_EXPR, tmp, fptrse.expr, - fold_convert (tmp, cptrse.expr)); - return 0; } else if (sym->intmod_sym_id == ISOCBINDING_ASSOCIATED) ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Patch, Fortran] PR 42072: [F03] wrong-code with C_F_PROCPOINTER 2009-11-17 22:39 [Patch, Fortran] PR 42072: [F03] wrong-code with C_F_PROCPOINTER Janus Weil @ 2009-11-18 10:39 ` Paul Richard Thomas 2009-11-18 11:55 ` Tobias Burnus 2009-11-18 14:09 ` Janus Weil 0 siblings, 2 replies; 7+ messages in thread From: Paul Richard Thomas @ 2009-11-18 10:39 UTC (permalink / raw) To: Janus Weil; +Cc: gfortran, gcc-patches Janus, > x86_64-unknown-linux-gnu with no failures. Ok for trunk? OK for trunk (and fortran-dev :-)) > > Two side-notes: > > 1) About the wrong static decl (cf. comments #3 and #5): I currently > have no idea how this comes about, and why the static prototype is > different from the actual declaration of the function. Does anyone > have an idea? That is indeed very odd and clearly incorrect. Could you please raise a new PR for this? > > 2) Once again I stumbled over the fact that the ISO_C_BINDING > intrinsics are handled in gfc_conv_procedure_call, in contrast to all > the other intrinsics, which are translated in trans-intrinsic.c. It > seems to me that gfc_conv_procedure_call is not a particularly good > place for this, as it is already a *huge* routine (several hundred > lines), even without the additional clobbering due to these > intrinsics. Is there a special reason that this is done in this very > place, or should we rather move this code to trans-intrinsic.c? (If > the latter, I would open a cleanup PR for this.) I have been eying gfc_conv_procedure_call with a view to breaking out the various sections into functions so that its structure becomes apparent once more. I have not thought about it much and would certainly applaud anybody taking it upon themselves to do it. As usual, such a task requires identifying the seams such that argument lists do not become as long as the functions being replaced :-) As for doing the ISO_C_BINDING in gfc_conv_procedure_call, I do not have any opinion, other than to note that the "normal" intrinsics are different beasts altogether. Thanks for the fix Paul > 2009-11-17 Janus Weil <janus@gcc.gnu.org> > > PR fortran/42072 > * trans-expr.c (gfc_conv_procedure_call): Handle procedure pointer > dummies which are passed to C_F_PROCPOINTER. > > > 2009-11-17 Janus Weil <janus@gcc.gnu.org> > > PR fortran/42072 > * gfortran.dg/proc_ptr_8.f90: Extended. > -- The knack of flying is learning how to throw yourself at the ground and miss. --Hitchhikers Guide to the Galaxy ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Patch, Fortran] PR 42072: [F03] wrong-code with C_F_PROCPOINTER 2009-11-18 10:39 ` Paul Richard Thomas @ 2009-11-18 11:55 ` Tobias Burnus 2009-11-18 14:09 ` Janus Weil 1 sibling, 0 replies; 7+ messages in thread From: Tobias Burnus @ 2009-11-18 11:55 UTC (permalink / raw) To: Paul Richard Thomas; +Cc: Janus Weil, gfortran, gcc-patches On 11/18/2009 11:28 AM, Paul Richard Thomas wrote: > x86_64-unknown-linux-gnu with no failures. Ok for trunk? > > OK for trunk (and fortran-dev :-)) > fortran-dev should automatically pick up the changes from the trunk - the next time someone does a merge. I just merged the trunk into fortran-dev as Rev. 154286. The branch contains all changes from the trunk up to 154283. (Current is Rev. 154286.) Tobias ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Patch, Fortran] PR 42072: [F03] wrong-code with C_F_PROCPOINTER 2009-11-18 10:39 ` Paul Richard Thomas 2009-11-18 11:55 ` Tobias Burnus @ 2009-11-18 14:09 ` Janus Weil 2009-11-18 22:59 ` Janus Weil 1 sibling, 1 reply; 7+ messages in thread From: Janus Weil @ 2009-11-18 14:09 UTC (permalink / raw) To: Paul Richard Thomas; +Cc: gfortran, gcc-patches >> x86_64-unknown-linux-gnu with no failures. Ok for trunk? > > OK for trunk (and fortran-dev :-)) Thanks. Committed as r154292. > As for doing the ISO_C_BINDING in gfc_conv_procedure_call, I do not have > any opinion, other than to note that the "normal" intrinsics are > different beasts altogether. Why are they so much different? Regarding the translation, we do pretty much the same for the ISO_C_BINDING intrinsics as we do for some of the others, namely replacing the call by some inline code. E.g. for C_F_PROCPOINTER, we just put in a simple pointer assignment. Cheers, Janus >> 2009-11-17 Janus Weil <janus@gcc.gnu.org> >> >> PR fortran/42072 >> * trans-expr.c (gfc_conv_procedure_call): Handle procedure pointer >> dummies which are passed to C_F_PROCPOINTER. >> >> >> 2009-11-17 Janus Weil <janus@gcc.gnu.org> >> >> PR fortran/42072 >> * gfortran.dg/proc_ptr_8.f90: Extended. >> > > > > -- > The knack of flying is learning how to throw yourself at the ground and miss. > --Hitchhikers Guide to the Galaxy > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Patch, Fortran] PR 42072: [F03] wrong-code with C_F_PROCPOINTER 2009-11-18 14:09 ` Janus Weil @ 2009-11-18 22:59 ` Janus Weil 2009-11-19 4:28 ` Jerry DeLisle 0 siblings, 1 reply; 7+ messages in thread From: Janus Weil @ 2009-11-18 22:59 UTC (permalink / raw) To: Paul Richard Thomas; +Cc: gfortran, gcc-patches [-- Attachment #1: Type: text/plain, Size: 918 bytes --] >> As for doing the ISO_C_BINDING in gfc_conv_procedure_call, I do not have >> any opinion, other than to note that the "normal" intrinsics are >> different beasts altogether. > > Why are they so much different? Regarding the translation, we do > pretty much the same for the ISO_C_BINDING intrinsics as we do for > some of the others, namely replacing the call by some inline code. > E.g. for C_F_PROCPOINTER, we just put in a simple pointer assignment. Well, ok, I can see that they are handled a bit differently in some ways. The least thing one could do would be to just separate out the ISO_C_BINDING special handling code from gfc_conv_procedure_call, to make it less of a monster. The attachted patch does this by just putting the ISO_C_BINDING stuff into a separate routine. And it does so without introducing any regressions in the testsuite (i just checked). Should I commit this to trunk? Cheers, Janus [-- Attachment #2: pr42072_2.diff --] [-- Type: text/x-diff, Size: 10035 bytes --] Index: gcc/fortran/trans-expr.c =================================================================== --- gcc/fortran/trans-expr.c (revision 154292) +++ gcc/fortran/trans-expr.c (working copy) @@ -2533,6 +2533,149 @@ conv_arglist_function (gfc_se *se, gfc_expr *expr, } +/* The following routine generates code for the intrinsic + procedures from the ISO_C_BINDING module: + * C_LOC (function) + * C_FUNLOC (function) + * C_F_POINTER (subroutine) + * C_F_PROCPOINTER (subroutine) + * C_ASSOCIATED (function) + One exception which is not handled here is C_F_POINTER with non-scalar + arguments. Returns 1 if the call was replaced by inline code (else: 0). */ + +static int +conv_isocbinding_procedure (gfc_se * se, gfc_symbol * sym, + gfc_actual_arglist * arg) +{ + gfc_symbol *fsym; + gfc_ss *argss; + + if (sym->intmod_sym_id == ISOCBINDING_LOC) + { + if (arg->expr->rank == 0) + gfc_conv_expr_reference (se, arg->expr); + else + { + int f; + /* This is really the actual arg because no formal arglist is + created for C_LOC. */ + fsym = arg->expr->symtree->n.sym; + + /* We should want it to do g77 calling convention. */ + f = (fsym != NULL) + && !(fsym->attr.pointer || fsym->attr.allocatable) + && fsym->as->type != AS_ASSUMED_SHAPE; + f = f || !sym->attr.always_explicit; + + argss = gfc_walk_expr (arg->expr); + gfc_conv_array_parameter (se, arg->expr, argss, f, + NULL, NULL, NULL); + } + + /* TODO -- the following two lines shouldn't be necessary, but + they're removed a bug is exposed later in the codepath. + This is workaround was thus introduced, but will have to be + removed; please see PR 35150 for details about the issue. */ + se->expr = convert (pvoid_type_node, se->expr); + se->expr = gfc_evaluate_now (se->expr, &se->pre); + + return 1; + } + else if (sym->intmod_sym_id == ISOCBINDING_FUNLOC) + { + arg->expr->ts.type = sym->ts.u.derived->ts.type; + arg->expr->ts.f90_type = sym->ts.u.derived->ts.f90_type; + arg->expr->ts.kind = sym->ts.u.derived->ts.kind; + gfc_conv_expr_reference (se, arg->expr); + + return 1; + } + else if ((sym->intmod_sym_id == ISOCBINDING_F_POINTER + && arg->next->expr->rank == 0) + || sym->intmod_sym_id == ISOCBINDING_F_PROCPOINTER) + { + /* Convert c_f_pointer if fptr is a scalar + and convert c_f_procpointer. */ + gfc_se cptrse; + gfc_se fptrse; + + gfc_init_se (&cptrse, NULL); + gfc_conv_expr (&cptrse, arg->expr); + gfc_add_block_to_block (&se->pre, &cptrse.pre); + gfc_add_block_to_block (&se->post, &cptrse.post); + + gfc_init_se (&fptrse, NULL); + if (sym->intmod_sym_id == ISOCBINDING_F_POINTER + || gfc_is_proc_ptr_comp (arg->next->expr, NULL)) + fptrse.want_pointer = 1; + + gfc_conv_expr (&fptrse, arg->next->expr); + gfc_add_block_to_block (&se->pre, &fptrse.pre); + gfc_add_block_to_block (&se->post, &fptrse.post); + + if (arg->next->expr->symtree->n.sym->attr.proc_pointer + && arg->next->expr->symtree->n.sym->attr.dummy) + fptrse.expr = build_fold_indirect_ref_loc (input_location, + fptrse.expr); + + se->expr = fold_build2 (MODIFY_EXPR, TREE_TYPE (fptrse.expr), + fptrse.expr, + fold_convert (TREE_TYPE (fptrse.expr), + cptrse.expr)); + + return 1; + } + else if (sym->intmod_sym_id == ISOCBINDING_ASSOCIATED) + { + gfc_se arg1se; + gfc_se arg2se; + + /* Build the addr_expr for the first argument. The argument is + already an *address* so we don't need to set want_pointer in + the gfc_se. */ + gfc_init_se (&arg1se, NULL); + gfc_conv_expr (&arg1se, arg->expr); + gfc_add_block_to_block (&se->pre, &arg1se.pre); + gfc_add_block_to_block (&se->post, &arg1se.post); + + /* See if we were given two arguments. */ + if (arg->next == NULL) + /* Only given one arg so generate a null and do a + not-equal comparison against the first arg. */ + se->expr = fold_build2 (NE_EXPR, boolean_type_node, arg1se.expr, + fold_convert (TREE_TYPE (arg1se.expr), + null_pointer_node)); + else + { + tree eq_expr; + tree not_null_expr; + + /* Given two arguments so build the arg2se from second arg. */ + gfc_init_se (&arg2se, NULL); + gfc_conv_expr (&arg2se, arg->next->expr); + gfc_add_block_to_block (&se->pre, &arg2se.pre); + gfc_add_block_to_block (&se->post, &arg2se.post); + + /* Generate test to compare that the two args are equal. */ + eq_expr = fold_build2 (EQ_EXPR, boolean_type_node, + arg1se.expr, arg2se.expr); + /* Generate test to ensure that the first arg is not null. */ + not_null_expr = fold_build2 (NE_EXPR, boolean_type_node, + arg1se.expr, null_pointer_node); + + /* Finally, the generated test must check that both arg1 is not + NULL and that it is equal to the second arg. */ + se->expr = fold_build2 (TRUTH_AND_EXPR, boolean_type_node, + not_null_expr, eq_expr); + } + + return 1; + } + + return 0; +} + + /* Generate code for a procedure call. Note can return se->post != NULL. If se->direct_byref is set then se->expr contains the return parameter. Return nonzero, if the call has alternate specifiers. @@ -2576,131 +2719,10 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * len = NULL_TREE; gfc_clear_ts (&ts); - if (sym->from_intmod == INTMOD_ISO_C_BINDING) - { - if (sym->intmod_sym_id == ISOCBINDING_LOC) - { - if (arg->expr->rank == 0) - gfc_conv_expr_reference (se, arg->expr); - else - { - int f; - /* This is really the actual arg because no formal arglist is - created for C_LOC. */ - fsym = arg->expr->symtree->n.sym; + if (sym->from_intmod == INTMOD_ISO_C_BINDING + && conv_isocbinding_procedure (se, sym, arg)) + return 0; - /* We should want it to do g77 calling convention. */ - f = (fsym != NULL) - && !(fsym->attr.pointer || fsym->attr.allocatable) - && fsym->as->type != AS_ASSUMED_SHAPE; - f = f || !sym->attr.always_explicit; - - argss = gfc_walk_expr (arg->expr); - gfc_conv_array_parameter (se, arg->expr, argss, f, - NULL, NULL, NULL); - } - - /* TODO -- the following two lines shouldn't be necessary, but - they're removed a bug is exposed later in the codepath. - This is workaround was thus introduced, but will have to be - removed; please see PR 35150 for details about the issue. */ - se->expr = convert (pvoid_type_node, se->expr); - se->expr = gfc_evaluate_now (se->expr, &se->pre); - - return 0; - } - else if (sym->intmod_sym_id == ISOCBINDING_FUNLOC) - { - arg->expr->ts.type = sym->ts.u.derived->ts.type; - arg->expr->ts.f90_type = sym->ts.u.derived->ts.f90_type; - arg->expr->ts.kind = sym->ts.u.derived->ts.kind; - gfc_conv_expr_reference (se, arg->expr); - - return 0; - } - else if ((sym->intmod_sym_id == ISOCBINDING_F_POINTER - && arg->next->expr->rank == 0) - || sym->intmod_sym_id == ISOCBINDING_F_PROCPOINTER) - { - /* Convert c_f_pointer if fptr is a scalar - and convert c_f_procpointer. */ - gfc_se cptrse; - gfc_se fptrse; - - gfc_init_se (&cptrse, NULL); - gfc_conv_expr (&cptrse, arg->expr); - gfc_add_block_to_block (&se->pre, &cptrse.pre); - gfc_add_block_to_block (&se->post, &cptrse.post); - - gfc_init_se (&fptrse, NULL); - if (sym->intmod_sym_id == ISOCBINDING_F_POINTER - || gfc_is_proc_ptr_comp (arg->next->expr, NULL)) - fptrse.want_pointer = 1; - - gfc_conv_expr (&fptrse, arg->next->expr); - gfc_add_block_to_block (&se->pre, &fptrse.pre); - gfc_add_block_to_block (&se->post, &fptrse.post); - - if (arg->next->expr->symtree->n.sym->attr.proc_pointer - && arg->next->expr->symtree->n.sym->attr.dummy) - fptrse.expr = build_fold_indirect_ref_loc (input_location, - fptrse.expr); - - se->expr = fold_build2 (MODIFY_EXPR, TREE_TYPE (fptrse.expr), - fptrse.expr, - fold_convert (TREE_TYPE (fptrse.expr), - cptrse.expr)); - - return 0; - } - else if (sym->intmod_sym_id == ISOCBINDING_ASSOCIATED) - { - gfc_se arg1se; - gfc_se arg2se; - - /* Build the addr_expr for the first argument. The argument is - already an *address* so we don't need to set want_pointer in - the gfc_se. */ - gfc_init_se (&arg1se, NULL); - gfc_conv_expr (&arg1se, arg->expr); - gfc_add_block_to_block (&se->pre, &arg1se.pre); - gfc_add_block_to_block (&se->post, &arg1se.post); - - /* See if we were given two arguments. */ - if (arg->next == NULL) - /* Only given one arg so generate a null and do a - not-equal comparison against the first arg. */ - se->expr = fold_build2 (NE_EXPR, boolean_type_node, arg1se.expr, - fold_convert (TREE_TYPE (arg1se.expr), - null_pointer_node)); - else - { - tree eq_expr; - tree not_null_expr; - - /* Given two arguments so build the arg2se from second arg. */ - gfc_init_se (&arg2se, NULL); - gfc_conv_expr (&arg2se, arg->next->expr); - gfc_add_block_to_block (&se->pre, &arg2se.pre); - gfc_add_block_to_block (&se->post, &arg2se.post); - - /* Generate test to compare that the two args are equal. */ - eq_expr = fold_build2 (EQ_EXPR, boolean_type_node, - arg1se.expr, arg2se.expr); - /* Generate test to ensure that the first arg is not null. */ - not_null_expr = fold_build2 (NE_EXPR, boolean_type_node, - arg1se.expr, null_pointer_node); - - /* Finally, the generated test must check that both arg1 is not - NULL and that it is equal to the second arg. */ - se->expr = fold_build2 (TRUTH_AND_EXPR, boolean_type_node, - not_null_expr, eq_expr); - } - - return 0; - } - } - gfc_is_proc_ptr_comp (expr, &comp); if (se->ss != NULL) ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Patch, Fortran] PR 42072: [F03] wrong-code with C_F_PROCPOINTER 2009-11-18 22:59 ` Janus Weil @ 2009-11-19 4:28 ` Jerry DeLisle 2009-11-19 10:54 ` Janus Weil 0 siblings, 1 reply; 7+ messages in thread From: Jerry DeLisle @ 2009-11-19 4:28 UTC (permalink / raw) To: Janus Weil; +Cc: Paul Richard Thomas, gfortran, gcc-patches On 11/18/2009 02:55 PM, Janus Weil wrote: >>> As for doing the ISO_C_BINDING in gfc_conv_procedure_call, I do not have >>> any opinion, other than to note that the "normal" intrinsics are >>> different beasts altogether. >> >> Why are they so much different? Regarding the translation, we do >> pretty much the same for the ISO_C_BINDING intrinsics as we do for >> some of the others, namely replacing the call by some inline code. >> E.g. for C_F_PROCPOINTER, we just put in a simple pointer assignment. > > Well, ok, I can see that they are handled a bit differently in some ways. > > The least thing one could do would be to just separate out the > ISO_C_BINDING special handling code from gfc_conv_procedure_call, to > make it less of a monster. > > The attachted patch does this by just putting the ISO_C_BINDING stuff > into a separate routine. And it does so without introducing any > regressions in the testsuite (i just checked). Should I commit this to > trunk? > > Cheers, > Janus OK after some spelling fixes in the comment. A nit, change to: + /* TODO -- the following two lines shouldn't be necessary, but if + they're removed, a bug is exposed later in the code path. + This workaround was thus introduced, but will have to be + removed; please see PR 35150 for details about the issue. */ Jerry ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Patch, Fortran] PR 42072: [F03] wrong-code with C_F_PROCPOINTER 2009-11-19 4:28 ` Jerry DeLisle @ 2009-11-19 10:54 ` Janus Weil 0 siblings, 0 replies; 7+ messages in thread From: Janus Weil @ 2009-11-19 10:54 UTC (permalink / raw) To: Jerry DeLisle; +Cc: Paul Richard Thomas, gfortran, gcc-patches 2009/11/19 Jerry DeLisle <jvdelisle@verizon.net>: > On 11/18/2009 02:55 PM, Janus Weil wrote: >>>> >>>> As for doing the ISO_C_BINDING in gfc_conv_procedure_call, I do not have >>>> any opinion, other than to note that the "normal" intrinsics are >>>> different beasts altogether. >>> >>> Why are they so much different? Regarding the translation, we do >>> pretty much the same for the ISO_C_BINDING intrinsics as we do for >>> some of the others, namely replacing the call by some inline code. >>> E.g. for C_F_PROCPOINTER, we just put in a simple pointer assignment. >> >> Well, ok, I can see that they are handled a bit differently in some ways. >> >> The least thing one could do would be to just separate out the >> ISO_C_BINDING special handling code from gfc_conv_procedure_call, to >> make it less of a monster. >> >> The attachted patch does this by just putting the ISO_C_BINDING stuff >> into a separate routine. And it does so without introducing any >> regressions in the testsuite (i just checked). Should I commit this to >> trunk? > > OK after some spelling fixes in the comment. A nit, change to: > > + /* TODO -- the following two lines shouldn't be necessary, but if > + they're removed, a bug is exposed later in the code path. > + This workaround was thus introduced, but will have to be > + removed; please see PR 35150 for details about the issue. */ Committed as r154327 with the spelling fixes (the comment above is not mine, I just carried it over from gfc_conv_procedure call). Cheers, Janus ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2009-11-19 10:34 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-11-17 22:39 [Patch, Fortran] PR 42072: [F03] wrong-code with C_F_PROCPOINTER Janus Weil 2009-11-18 10:39 ` Paul Richard Thomas 2009-11-18 11:55 ` Tobias Burnus 2009-11-18 14:09 ` Janus Weil 2009-11-18 22:59 ` Janus Weil 2009-11-19 4:28 ` Jerry DeLisle 2009-11-19 10:54 ` Janus Weil
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).