[Bug fortran/40969] [4.5 regression] Revision 150465 failed gfortran.dg/c_by_val_1.f
--- Comment #3 from hjl dot tools at gmail dot com 2009-08-05 18:58 --- (In reply to comment #1) Works for me on x86-64-linux and seems also to work on several other systems according to the testresults mailing list. (Only failure - your ia64 system: http://gcc.gnu.org/ml/gcc-testresults/2009-08/msg00487.html) As I cannot reproduce it, can you provide more details? It is caused by revision 150465: http://gcc.gnu.org/ml/gcc-cvs/2009-08/msg00145.html It is run-time failure. * * * Side note: Can you change your tester to not attach the results as binary but as text/..., cf. http://gcc.gnu.org/ml/gcc-testresults/2009-08/msg00484.html; that makes is quicker to reading the test results. See PR 40704. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||burnus at net-b dot de OtherBugsDependingO||40949 nThis|| Summary|[4.5 regression]|[4.5 regression] Revision |gfortran.dg/c_by_val_1.f|150465 failed |failed |gfortran.dg/c_by_val_1.f http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40969
[Bug fortran/40969] [4.5 regression] Revision 150465 failed gfortran.dg/c_by_val_1.f
--- Comment #4 from kargl at gcc dot gnu dot org 2009-08-05 19:06 --- (In reply to comment #3) (In reply to comment #1) Works for me on x86-64-linux and seems also to work on several other systems according to the testresults mailing list. (Only failure - your ia64 system: http://gcc.gnu.org/ml/gcc-testresults/2009-08/msg00487.html) As I cannot reproduce it, can you provide more details? It is caused by revision 150465: http://gcc.gnu.org/ml/gcc-cvs/2009-08/msg00145.html It is run-time failure. You have got to be kidding! This is not the details that was requested. Your subject line already pointed to the revision. Where the heck is the backtrace? What's the difference in generated assembly before and after the revision? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40969
[Bug fortran/40969] [4.5 regression] Revision 150465 failed gfortran.dg/c_by_val_1.f
--- Comment #5 from hjl dot tools at gmail dot com 2009-08-05 19:07 --- (gdb) bt #0 0xa0010621 in __kernel_syscall_via_break () #1 0x203e7630 in raise () from /lib/tls/libc.so.6.1 #2 0x203ea010 in abort () from /lib/tls/libc.so.6.1 #3 0x400014b0 in f_to_f__ (retval=0x6fffb420, a1=0, a2=0x6fffb430, a3=0x6fffb418) at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gfortran.dg/c_by_val.c:21 #4 0x4ad0 in c_by_val_1 () at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gfortran.dg/c_by_val_1.f:18 #5 0x400013e0 in main (argc=1, argv=0x6fffb99c /export/build/gnu/gcc/build-ia64-linux/gcc/testsuite/gfortran/c_by_val_1.exe) at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gfortran.dg/c_by_val_1.f:52 #6 0x203bd430 in __libc_start_main () from /lib/tls/libc.so.6.1 #7 0x48a0 in _start () (gdb) f 3 #3 0x400014b0 in f_to_f__ (retval=0x6fffb420, a1=0, a2=0x6fffb430, a3=0x6fffb418) at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gfortran.dg/c_by_val.c:21 21if ( a1 != *a2 ) abort(); (gdb) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40969
[Bug fortran/40969] [4.5 regression] Revision 150465 failed gfortran.dg/c_by_val_1.f
--- Comment #6 from hjl dot tools at gmail dot com 2009-08-05 19:09 --- 21if ( a1 != *a2 ) abort(); (gdb) p a1 $1 = 0 (gdb) p *a2 $2 = 42 (gdb) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40969
[Bug fortran/40969] [4.5 regression] Revision 150465 failed gfortran.dg/c_by_val_1.f
--- Comment #7 from hjl dot tools at gmail dot com 2009-08-05 19:22 --- When we see external f_to_f, i_to_i, c_to_c external f_to_f8, i_to_i8, c_to_c8 and do typelist = gfc_chainon_list (typelist, void_type_node); Later, we see call f_to_f (b, %VAL (a), %REF (c), %LOC (c)) We build typelist again with an extra void_type_node at the beginning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40969
[Bug fortran/40969] [4.5 regression] Revision 150465 failed gfortran.dg/c_by_val_1.f
--- Comment #8 from hjl dot tools at gmail dot com 2009-08-05 19:28 --- (In reply to comment #7) When we see external f_to_f, i_to_i, c_to_c external f_to_f8, i_to_i8, c_to_c8 and do typelist = gfc_chainon_list (typelist, void_type_node); Later, we see call f_to_f (b, %VAL (a), %REF (c), %LOC (c)) We build typelist again with an extra void_type_node at the beginning. That is incorrect. For some reason, typelist is always NULL before the change. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40969
[Bug fortran/40969] [4.5 regression] Revision 150465 failed gfortran.dg/c_by_val_1.f
--- Comment #9 from burnus at gcc dot gnu dot org 2009-08-05 19:33 --- (In reply to comment #6) 21if ( a1 != *a2 ) abort(); (gdb) p a1 $1 = 0 (gdb) p *a2 $2 = 42 Thanks! I think the following patch should cure this. I think we will still have issues with LTO but those are inevitable and need to be solved on the middle end. Index: trans-types.c === --- trans-types.c (Revision 150497) +++ trans-types.c (Arbeitskopie) @@ -2324,7 +2324,10 @@ while (nstr--) typelist = gfc_chainon_list (typelist, gfc_charlen_type_node); - typelist = gfc_chainon_list (typelist, void_type_node); + /* If the explicit interface is known, we tell the middle end + that no more additional arguments will follow in calls. */ + if (sym-attr.if_source != IFSRC_UNKNOWN) +typelist = gfc_chainon_list (typelist, void_type_node); if (alternate_return) type = integer_type_node; -- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-08-05 19:33:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40969
[Bug fortran/40969] [4.5 regression] Revision 150465 failed gfortran.dg/c_by_val_1.f
--- Comment #10 from hjl dot tools at gmail dot com 2009-08-05 19:49 --- (In reply to comment #9) Thanks! I think the following patch should cure this. I think we will still have issues with LTO but those are inevitable and need to be solved on the middle end. Index: trans-types.c === --- trans-types.c (Revision 150497) +++ trans-types.c (Arbeitskopie) @@ -2324,7 +2324,10 @@ while (nstr--) typelist = gfc_chainon_list (typelist, gfc_charlen_type_node); - typelist = gfc_chainon_list (typelist, void_type_node); + /* If the explicit interface is known, we tell the middle end + that no more additional arguments will follow in calls. */ + if (sym-attr.if_source != IFSRC_UNKNOWN) +typelist = gfc_chainon_list (typelist, void_type_node); if (alternate_return) type = integer_type_node; It failed at a different place: (gdb) bt #0 0xa0010621 in __kernel_syscall_via_break () #1 0x203e7630 in raise () from /lib/tls/libc.so.6.1 #2 0x203ea010 in abort () from /lib/tls/libc.so.6.1 #3 0x40001ac0 in c_to_c__ (retval=0x6fffb498, c1=43 + 0 * I, c2=0x6fffb480, c3=0x6fffb3e8) at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gfortran.dg/c_by_val.c:61 #4 0x4f50 in c_by_val_1 () at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gfortran.dg/c_by_val_1.f:42 #5 0x40001430 in main (argc=1, argv=0x6fffb983 /export/build/gnu/gcc-work/build-ia64-linux/gcc/testsuite/gfortran/c_by_val_1.exe) at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gfortran.dg/c_by_val_1.f:52 #6 0x203bd430 in __libc_start_main () from /lib/tls/libc.so.6.1 #7 0x48a0 in _start () (gdb) f 3 #3 0x40001ac0 in c_to_c__ (retval=0x6fffb498, c1=43 + 0 * I, c2=0x6fffb480, c3=0x6fffb3e8) at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gfortran.dg/c_by_val.c:61 61if ( c1 != *c2) abort(); (gdb) p c1 $1 = 43 + 0 * I (gdb) p *c2 $2 = -1 + 2 * I (gdb) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40969
[Bug fortran/40969] [4.5 regression] Revision 150465 failed gfortran.dg/c_by_val_1.f
--- Comment #11 from hjl dot tools at gmail dot com 2009-08-05 19:52 --- This patch works: --- ./trans-types.c.foo 2009-08-05 07:26:53.0 -0700 +++ ./trans-types.c 2009-08-05 12:51:00.0 -0700 @@ -2324,7 +2324,10 @@ gfc_get_function_type (gfc_symbol * sym) while (nstr--) typelist = gfc_chainon_list (typelist, gfc_charlen_type_node); - typelist = gfc_chainon_list (typelist, void_type_node); + /* If the explicit interface is known, we tell the middle end + that no more additional arguments will follow in calls. */ + if (typelist || sym-attr.if_source != IFSRC_UNKNOWN) +typelist = gfc_chainon_list (typelist, void_type_node); if (alternate_return) type = integer_type_node; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40969
[Bug fortran/40969] [4.5 regression] Revision 150465 failed gfortran.dg/c_by_val_1.f
--- Comment #12 from burnus at gcc dot gnu dot org 2009-08-05 20:03 --- (In reply to comment #10) It failed at a different place: 61if ( c1 != *c2) abort(); (gdb) p c1 $1 = 43 + 0 * I (gdb) p *c2 $2 = -1 + 2 * I Hmm, I honestly have no idea why this fails. In my understanding, it should have failed before and should now be working. The reason is that for call f_to_f (b, %VAL (a), %REF (c), %LOC (c)) using external f_to_f generates a prototype void f_to_f(...) which my previous patch in PR 40949 wrongly modified to void f_to_f(void). However, for v = c_to_c (%VAL (u), %REF (w), %LOC (w)) with external c_to_c complex c_to_c and call by reference (-ff2c), the prototype should be void c_to_c(complex*, ...) In my opinion that's what my patch in comment 9 does, while pre-PR40949 gfortran appended a void node, leading to void c_to_c(complex *) // misses , ... I think I miss something obvious here. * * * At the end, gfortran should produce a proper prototype, which is useful to have to provide better diagnostics and needed to fix some LTO issues. I filled PR 40976 to track this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40969
[Bug fortran/40969] [4.5 regression] Revision 150465 failed gfortran.dg/c_by_val_1.f
--- Comment #13 from burnus at gcc dot gnu dot org 2009-08-05 20:36 --- (In reply to comment #11) This patch works: + if (typelist || sym-attr.if_source != IFSRC_UNKNOWN) +typelist = gfc_chainon_list (typelist, void_type_node); That patch essentially undoes the patch of PR 40949 as this is essentially identically to if (typelist) typelist = gfc_chainon_list (typelist, void_type_node); I think it is best to go back to the old version (i.e. revert the patch PR 40949) and fix it properly as proposed in PR 40976 (and in PR 40978) -- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|burnus at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40969
[Bug fortran/40969] [4.5 regression] Revision 150465 failed gfortran.dg/c_by_val_1.f
-- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-08-05 19:33:47 |2009-08-05 20:42:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40969
[Bug fortran/40969] [4.5 regression] Revision 150465 failed gfortran.dg/c_by_val_1.f
--- Comment #14 from burnus at gcc dot gnu dot org 2009-08-05 20:47 --- Subject: Bug 40969 Author: burnus Date: Wed Aug 5 20:47:19 2009 New Revision: 150500 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150500 Log: 2009-08-05 Tobias Burnus bur...@net-b.de PR fortran/40969 Revert: 2009-08-04 Tobias Burnus bur...@net-b.de PR fortran/40949 * trans-types.c (gfc_get_function_type): Fix typelist of functions without argument. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-types.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40969
[Bug fortran/40969] [4.5 regression] Revision 150465 failed gfortran.dg/c_by_val_1.f
--- Comment #15 from burnus at gcc dot gnu dot org 2009-08-05 20:52 --- FIXED by reverting the bug. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40969
