Created attachment 25268 [details] just compile it SIGSEGV in gfc_trans_label_assign
Confirmed on gfortran 4.4.6, 4.5.3, 4.6.1, and trunk (r178842). The backtrace is pr50392.f90:3.20: assign 1 to kf 1 Warning: Deleted feature: ASSIGN statement at (1) kf Program received signal SIGSEGV, Segmentation fault. gfc_trans_label_assign (code=<value optimized out>) at ../../work/gcc/fortran/trans-stmt.c:107 107 len = GFC_DECL_STRING_LEN (se.expr); (gdb) bt #0 gfc_trans_label_assign (code=<value optimized out>) at ../../work/gcc/fortran/trans-stmt.c:107 #1 0x00000001000b4d48 in trans_code (code=<value optimized out>, cond=<value optimized out>) at ../../work/gcc/fortran/trans.c:1204 #2 0x00000001000dbb64 in gfc_generate_function_code (ns=<value optimized out>) at ../../work/gcc/fortran/trans-decl.c:5211 #3 0x0000000100072f5d in gfc_parse_file () at ../../work/gcc/fortran/parse.c:4404 #4 0x00000001000af786 in gfc_be_parse_file () at ../../work/gcc/fortran/f95-lang.c:250 #5 0x00000001007b72bc in toplev_main (argc=2, argv=0x7fff5fbfdc08) at ../../work/gcc/toplev.c:548 #6 0x0000000100001974 in start ()
The code looks valid (Fortran 90) to me. Except that "kf" needs to be re-defined before returning from the function. From Fortran 95's deleted section: "B.1.4 ASSIGN, assigned GO TO, and assigned FORMAT" "The definitions of the ASSIGN and assigned GO TO statements are: assign-stmt is ASSIGN label TO scalar-int-variable Constraint: The label shall be the statement label of a branch target statement or format-stmt that appears in the same scoping unit as the assign-stmt. Constraint: scalar-int-variable shall be named and of type default integer. [...] "Execution of an ASSIGN statement causes a statement label to be assigned to an integer variable. While defined with a statement label value, the integer variable may be referenced only in the context of an assigned GO TO statement or as a format specifier in an input/output statement. An integer variable defined with a statement label value may be redefined with a statement label value or an integer value."
Patch: --- a/gcc/fortran/trans-decl.c +++ b/gcc/fortran/trans-decl.c @@ -1264,9 +1265,7 @@ gfc_get_symbol_decl (gfc_symbol * sym) TREE_USED (sym->backend_decl) = 1; if (sym->attr.assign && GFC_DECL_ASSIGN (sym->backend_decl) == 0) - { - gfc_add_assign_aux_vars (sym); - } + gfc_add_assign_aux_vars (sym); if (sym->attr.dimension && DECL_LANG_SPECIFIC (sym->backend_decl) @@ -1277,6 +1276,10 @@ gfc_get_symbol_decl (gfc_symbol * sym) return sym->backend_decl; } + if (sym->result == sym && sym->attr.assign + && GFC_DECL_ASSIGN (sym->backend_decl) == 0) + gfc_add_assign_aux_vars (sym); + if (sym->backend_decl) return sym->backend_decl;
(In reply to comment #3) > Patch: I have accidentally submitted the patch before testing finished. It does not work. The problem is that it does create the required declaration - but it does not get used as one later calls gfc_get_fake_result_decl, which does not propagate this information on. That's fixed by applying additionally the following patch, which feels slightly hackish. --- a/gcc/fortran/trans-decl.c +++ b/gcc/fortran/trans-decl.c @@ -2557,6 +2561,9 @@ gfc_get_fake_result_decl (gfc_symbol * sym, int parent_flag) else current_fake_result_decl = build_tree_list (NULL, decl); + if (sym->attr.assign) + DECL_LANG_SPECIFIC (decl) = DECL_LANG_SPECIFIC (sym->backend_decl); + return decl; } ... maybe by moving the gfc_add_assign_aux_vars to gfc_get_fake_result_decl - like below? @@ -2501,6 +2501,10 @@ gfc_get_fake_result_decl (gfc_symbol * sym, int parent_flag) if (!sym) return NULL_TREE; + if (sym->attr.assign + && GFC_DECL_ASSIGN (sym->backend_decl) == 0) + gfc_add_assign_aux_vars (sym); + if (sym->ts.type == BT_CHARACTER) { if (sym->ts.u.cl->backend_decl == NULL_TREE)
(In reply to comment #4) > (In reply to comment #3) > > Patch: > > I have accidentally submitted the patch before testing finished. It does not > work. The problem is that it does create the required declaration - but it does > not get used as one later calls gfc_get_fake_result_decl, which does not > propagate this information on. > > That's fixed by applying additionally the following patch, which feels slightly > hackish. Just a FYI. The following code works with the current gfortran. function kf() result(j) assign 3 to j 3 continue j = 3 end
I still have the same bug on gfortran 4.8.0.
Still in gfortran 4.8.1. In trans-stmt.c:105 " len = GFC_DECL_STRING_LEN (se.expr);" the pointer se.expr->decl_common.lang_specific is NULL. Thus causing the segmentation fault.
ICE still in 5.3.0
Still in 7.1.0 and in trunk 8.0.0! Will it ever be fixed?
(In reply to Vittorio Zecca from comment #9) > Still in 7.1.0 and in trunk 8.0.0! > Will it ever be fixed? You forgot to attach our patch. Your initial report of the bug is 2011-09-14. It seems that you've had nearly 6 years to develop a patch.
You still around, Steven? I cannot say I missed you. Nobody asked me to apply those fixes, I imagined that Tobias Burnus, their author, would try them and eventually apply them. It seems that it did not happen. Anyway, I just applied the patches to the trunk 8.0.0 level 247930 and the ICE disappeared.
On Mon, May 15, 2017 at 02:27:04PM +0000, zeccav at gmail dot com wrote: > > --- Comment #11 from Vittorio Zecca <zeccav at gmail dot com> --- > You still around, Steven? > I cannot say I missed you. I've never left, and you're more than welcomed to delete all my patches from your copy of gfortran as you can obviously to better. % grep -i kargl gcc/fortran/ChangeLog-2011 | wc -l 15 % grep -i kargl gcc/fortran/ChangeLog-2012 | wc -l 3 % grep -i kargl gcc/fortran/ChangeLog-2013 | wc -l 3 % grep -i kargl gcc/fortran/ChangeLog-2015 | wc -l 62 % grep -i kargl gcc/fortran/ChangeLog-2016 | wc -l 53 % grep -i kargl gcc/fortran/ChangeLog | wc -l 1 % grep -i kargl libgfortran/ChangeLog-2013 | wc -l 1 % grep -i kargl libgfortran/ChangeLog-2014 | wc -l 2 % grep -i kargl libgfortran/ChangeLog-2015 | wc -l 2 % grep -i kargl libgfortran/ChangeLog-2016 | wc -l 1 % grep -i kargl libgfortran/ChangeLog | wc -l 1 I do find posts of the form > Still in 7.1.0 and in trunk 8.0.0! > Will it ever be fixed? to be rather condescending. There is a dwindling number of gfortran developers, and posts like yours is a contributing reason.
Steve, you know why I do not like you. If you are so sensitive please take care of the sensitivity of people submitting bugs and do not call them "idiot". But this is not relevant here. What is relevant is that I just ran "make check-fortran" and it was almost clean, except for another NULL pointer dereferencing at check.c with coarrays. I just opened a new bug 80768. For what regards me you are welcome to look into it and provide me with a patch.
On Mon, May 15, 2017 at 04:57:37PM +0000, zeccav at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50392 > > --- Comment #13 from Vittorio Zecca <zeccav at gmail dot com> --- > Steve, you know why I do not like you. Because I point out your flaws? Instead of your passive aggressive comment: >> Still in 7.1.0 and in trunk 8.0.0! >> Will it ever be fixed? Try something like I was going through some old bug reports and found PR 50392 still open. I tested the patch in comment #4, and it appears to fix the problem. Could someone review and commit the patch?
This gives in ICE now with the current trunk, while it just shows an error message for a "Deleted feature" when using -std=f95.
> This gives in ICE now with the current trunk, while it just shows > an error message for a "Deleted feature" when using -std=f95. Confirmed from at least 4.8 up to trunk (9.0).
Sorry, I don't want to generate unnecessary traffic, I'm just scrolling thru old c.l.f. discussions and stumble over some old reports there from time to time.
The master branch has been updated by Mark Eggleston <markeggleston@gcc.gnu.org>: https://gcc.gnu.org/g:a7fd43c38f7469a3ef5ee30e889d60e1376d4dfc commit r11-665-ga7fd43c38f7469a3ef5ee30e889d60e1376d4dfc Author: Mark Eggleston <markeggleston@gcc.gnu.org> Date: Thu May 7 08:15:26 2020 +0100 Fortran : ICE in gfc_trans_label_assign PR50392 A function may contain an assigned goto. If the the return variable is an integer a statement can be assigned to it. Prior to this fix this resulted in an ICE. 2020-05-27 Tobias Burnus <tobias@codesourcery.com> gcc/fortran/ PR fortran/50392 * trans-decl.c (gfc_get_symbol_decl): Remove unnecessary block delimiters. Add auxiliary variables if a label is assigned to a return variable. (gfc_gat_fake_result): If the symbol has an assign attribute set declaration from the symbol's backend declaration. 2020-05-27 Mark Eggleston <markeggleston@gnu.gcc.org> gcc/testsuite/ PR fortran/50392 * gfortran.dg/pr50392.f: New test.
The releases/gcc-10 branch has been updated by Mark Eggleston <markeggleston@gcc.gnu.org>: https://gcc.gnu.org/g:4e2c7f9a29c212db4bf428799a2d62f79f392511 commit r10-8196-g4e2c7f9a29c212db4bf428799a2d62f79f392511 Author: Mark Eggleston <markeggleston@gcc.gnu.org> Date: Thu May 7 08:15:26 2020 +0100 Fortran : ICE in gfc_trans_label_assign PR50392 A function may contain an assigned goto. If the the return variable is an integer a statement can be assigned to it. Prior to this fix this resulted in an ICE. 2020-05-28 Tobias Burnus <tobias@codesourcery.com> gcc/fortran/ PR fortran/50392 * trans-decl.c (gfc_get_symbol_decl): Remove unnecessary block delimiters. Add auxiliary variables if a label is assigned to a return variable. (gfc_gat_fake_result): If the symbol has an assign attribute set declaration from the symbol's backend declaration. 2020-05-28 Mark Eggleston <markeggleston@gnu.gcc.org> gcc/testsuite/ PR fortran/50392 * gfortran.dg/pr50392.f: New test. (cherry picked from commit a7fd43c38f7469a3ef5ee30e889d60e1376d4dfc)
The releases/gcc-9 branch has been updated by Mark Eggleston <markeggleston@gcc.gnu.org>: https://gcc.gnu.org/g:c575cd2e0089cf2fcb11ffb7899e5fd472b3780c commit r9-8631-gc575cd2e0089cf2fcb11ffb7899e5fd472b3780c Author: Mark Eggleston <markeggleston@gcc.gnu.org> Date: Thu May 7 08:15:26 2020 +0100 Fortran : ICE in gfc_trans_label_assign PR50392 A function may contain an assigned goto. If the the return variable is an integer a statement can be assigned to it. Prior to this fix this resulted in an ICE. 2020-05-28 Tobias Burnus <tobias@codesourcery.com> gcc/fortran/ PR fortran/50392 * trans-decl.c (gfc_get_symbol_decl): Remove unnecessary block delimiters. Add auxiliary variables if a label is assigned to a return variable. (gfc_gat_fake_result): If the symbol has an assign attribute set declaration from the symbol's backend declaration. 2020-05-28 Mark Eggleston <markeggleston@gnu.gcc.org> gcc/testsuite/ PR fortran/50392 * gfortran.dg/pr50392.f: New test. (cherry picked from commit a7fd43c38f7469a3ef5ee30e889d60e1376d4dfc)
The releases/gcc-8 branch has been updated by Mark Eggleston <markeggleston@gcc.gnu.org>: https://gcc.gnu.org/g:83b84b6ef84ffc0ca25aef5c91720d8f82212a5c commit r8-10280-g83b84b6ef84ffc0ca25aef5c91720d8f82212a5c Author: Mark Eggleston <markeggleston@gcc.gnu.org> Date: Thu May 7 08:15:26 2020 +0100 Fortran : ICE in gfc_trans_label_assign PR50392 A function may contain an assigned goto. If the the return variable is an integer a statement can be assigned to it. Prior to this fix this resulted in an ICE. 2020-05-28 Tobias Burnus <tobias@codesourcery.com> gcc/fortran/ PR fortran/50392 * trans-decl.c (gfc_get_symbol_decl): Remove unnecessary block delimiters. Add auxiliary variables if a label is assigned to a return variable. (gfc_gat_fake_result): If the symbol has an assign attribute set declaration from the symbol's backend declaration. 2020-05-28 Mark Eggleston <markeggleston@gnu.gcc.org> gcc/testsuite/ PR fortran/50392 * gfortran.dg/pr50392.f: New test. (cherry picked from commit a7fd43c38f7469a3ef5ee30e889d60e1376d4dfc)
committed to master and backported
The update proposed in comment #18 fixed the issue. Thank you!