This testcase coms from SPEC CPU 2006: [hjl@gnu-25 wrf-1]$ cat foo.f90 module foo use bar implicit none private type ESMF_Clock type(ESMF_Time) :: CurrTime end type interface operator (+) function add (x, y) use bar type(ESMF_Time) :: add type(ESMF_Time), intent(in) :: x type(ESMF_Time), intent(in) :: y end function add end interface contains subroutine ESMF_ClockAdvance(clock) type(ESMF_Clock), intent(inout) :: clock clock%CurrTime = clock%CurrTime + clock%CurrTime end subroutine ESMF_ClockAdvance end module foo [hjl@gnu-25 wrf-1]$ cat bar.f90 module bar implicit none public type ESMF_Time integer :: DD end type end module bar [hjl@gnu-25 wrf-1]$ make /export/build/gnu/gcc-last/build-x86_64-linux/gcc/gfortran -B/export/build/gnu/gcc-last/build-x86_64-linux/gcc/ -S -o bar.s bar.f90 /export/build/gnu/gcc-last/build-x86_64-linux/gcc/gfortran -B/export/build/gnu/gcc-last/build-x86_64-linux/gcc/ -S -o foo.s foo.f90 foo.f90: In function ‘esmf_clockadvance’: foo.f90:17: internal compiler error: in fold_convert, at fold-const.c:2098 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. make: *** [foo.s] Error 1
When reporting regressions can you at least give the version of GCC you are using as it might had been fixed already.
Also saying what is the last known version to work is also nice. Note I am going to say this is related to PR 28630 and either is caused by it or fixed by it.
The regression was introduced between revision 116091 and 116362. revision 116590 still has this bug.
Revision 116268 is the cause. There are several bug fixes in one checkin. It is hard to just back out one bug fix.
This patch: http://gcc.gnu.org/ml/fortran/2006-08/msg00154.html is the cause.
Before the change, gfc_get_derived_type will search a module to reuse TREE_TYPE. The current one will create a new TREE_TYPE for the same type. But fold_convert has if (type == orig) return arg; Although TYPE and ORIG are the same type, they have different memory locations. fold_convert doesn't handle it.
Subject: Re: [4.2 Regression]: fold_convert fails for Fortran operator hjl at lucon dot org wrote: >------- Comment #6 from hjl at lucon dot org 2006-08-30 19:40 ------- >Before the change, gfc_get_derived_type will search a module to reuse >TREE_TYPE. >The current one will create a new TREE_TYPE for the same type. But fold_convert >has > > if (type == orig) > return arg; > >Although TYPE and ORIG are the same type, they have different memory locations. >fold_convert doesn't handle it. > > > > HJ I am just about to post the patch - all the regressions that I have had to deal with emanating from the revamp of derived type association have been very subtle to understand... except this one, which is down to stupidity on my part. The sad thing is that I though that I was being clever too! However, I have to say that I am really surprised that none of my tests caught it. I am sorry for the inconvenience. Paul
Created attachment 12159 [details] Patch for the PR This is regtesting as I write. I do not doubt that it will pass because none of the tests caught this PR! Thanks HJ Paul
The patch doesn't work for me: Starting program: /export/build/gnu/gcc-next/build-x86_64-linux/gcc/f951 xxx.f90 -quiet -dumpbase xxx.f90 -mtune=generic -auxbase-strip xxx.s -version -o xxx.s -I /usr/gcc-next/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/finclude GNU F95 version 4.2.0 20060830 (experimental) [trunk revision 116593] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.2.0 20060830 (experimental) [trunk revision 116593]. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Program received signal SIGSEGV, Segmentation fault. 0x00000000004539c8 in switch_types (st=0xc95e00, from=0xcca330, to=0xcc9720) at /net/gnu-13/export/gnu/src/gcc-next/gcc/gcc/fortran/symbol.c:1401 1401 { (gdb)
Subject: Re: [4.2 Regression]: fold_convert fails for Fortran operator hjl at lucon dot org wrote: >------- Comment #9 from hjl at lucon dot org 2006-08-30 20:38 ------- >The patch doesn't work for me: > >Starting program: /export/build/gnu/gcc-next/build-x86_64-linux/gcc/f951 >xxx.f90 -quiet -dumpbase xxx.f90 -mtune=generic -auxbase-strip xxx.s -version >-o xxx.s -I /usr/gcc-next/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/finclude >GNU F95 version 4.2.0 20060830 (experimental) [trunk revision 116593] >(x86_64-unknown-linux-gnu) > compiled by GNU C version 4.2.0 20060830 (experimental) [trunk revision >116593]. >GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 > >Program received signal SIGSEGV, Segmentation fault. >0x00000000004539c8 in switch_types (st=0xc95e00, from=0xcca330, to=0xcc9720) > at /net/gnu-13/export/gnu/src/gcc-next/gcc/gcc/fortran/symbol.c:1401 >1401 { >(gdb) > > > > No... no for me. Between the portable downstairs and the machine in my office, I have lost something. Bear with me please; I am doing something daft. Paul
Subject: Re: [4.2 Regression]: fold_convert fails for Fortran operator HJ, I have cross-checked the patch between the two machines; it is the same. One regtests fine and the other segfaults in switch_types. I am so dog-tired that I have to crash right now. At least I know that I am on the right track. Clearly, I am missing some dangling reference. I will pick it up again in the morning. Paul
It also fails with gcc 4.1 revision 116602.
Subject: Re: [4.1/4.2 Regression]: fold_convert fails for Fortran operator hjl at lucon dot org wrote: >------- Comment #12 from hjl at lucon dot org 2006-08-31 16:57 ------- >It also fails with gcc 4.1 revision 116602. > > > > Yes, I know. I have a patch that seems to work but I do not like it very much; still, it is a sign of progress! I am rushing on this one, HJ, but I want to get it right. The problem is that operator interfaces is a part of gfortran that I have rarely touched and I do not know my way around. They have namespaces that do not have very much of anything attached to them, as far as I can see. That's why the simple fix causes a segfault. However, I cannot quite see how the symbols for the arguments are attached to the namespace. I'll be with you as soon as I have a solution - < 24hours now. Paul
I don't think it is specific to operator. I got the same failure with function: [hjl@gnu-16 wrf-1]$ cat yyy.f90 ! { dg-do compile } ! Tests the fix for a further regression caused by the ! fix for PR28788 and posted as PR28908. The problem was ! caused by the patch preventing interface derived types ! from associating with identical derived types in the ! containing namespaces. ! ! Contributed by HJ Lu <hjl@lucon.org> ! module bar implicit none public type ESMF_Time integer :: DD end type end module bar module foo use bar implicit none private type ESMF_Clock type(ESMF_Time) :: CurrTime end type interface function add (x, y) use bar type(ESMF_Time) :: add type(ESMF_Time), intent(in) :: x type(ESMF_Time), intent(in) :: y end function add end interface contains subroutine ESMF_ClockAdvance(clock) type(ESMF_Clock), intent(inout) :: clock clock%CurrTime = add (clock%CurrTime, clock%CurrTime) end subroutine ESMF_ClockAdvance end module foo ! { dg-final { cleanup-modules "foo bar" } } [hjl@gnu-16 wrf-1]$ make yyy.s /export/build/gnu/gcc/build-x86_64-linux/gcc/gfortran -B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -S -o yyy.s yyy.f90 yyy.f90: In function ‘esmf_clockadvance’: yyy.f90:34: internal compiler error: in fold_convert, at fold-const.c:2098 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. make: *** [yyy.s] Error 1 [hjl@gnu-16 wrf-1]$
I think the issue may be that gfc_get_derived_type creates a new TREE_TYPE for the same type when there is an existing one. type1 == type2 no longer works when type1 and type2 have different memory locations even if they are the same.
Subject: Re: [4.1/4.2 Regression]: fold_convert fails for Fortran operator HJ Yes, I think that function interfaces in general are of the same horrible kind. Thanks Paul
The previous gfc_get_derived_type tries to reuse the same TREE_TYPE: /* In a module, if an equal derived type is already available in the specification block, use its backend declaration and those of its components, rather than building anew so that potential dummy and actual arguments use the same TREE_TYPE. Non-module structures, need to be built, if found, because the order of visits to the namespaces is different. */ for (ns = derived->ns->parent; ns; ns = ns->parent) { for (dt = ns->derived_types; dt; dt = dt->next) { if (derived->module == NULL && dt->derived->backend_decl == NULL && gfc_compare_derived_types (dt->derived, derived)) gfc_get_derived_type (dt->derived); if (copy_dt_decls_ifequal (dt->derived, derived)) break; } if (derived->backend_decl) goto other_equal_dts; }
Subject: Re: [4.1/4.2 Regression]: fold_convert fails for Fortran operator hjl, >------- Comment #17 from hjl at lucon dot org 2006-08-31 18:28 ------- >The previous gfc_get_derived_type tries to reuse the same TREE_TYPE: > > /* In a module, if an equal derived type is already available in the > specification block, use its backend declaration and those of its > components, rather than building anew so that potential dummy and > actual arguments use the same TREE_TYPE. Non-module structures, > need to be built, if found, because the order of visits to the > namespaces is different. */ > > for (ns = derived->ns->parent; ns; ns = ns->parent) > { > for (dt = ns->derived_types; dt; dt = dt->next) > { > if (derived->module == NULL > && dt->derived->backend_decl == NULL > && gfc_compare_derived_types (dt->derived, derived)) > gfc_get_derived_type (dt->derived); > > if (copy_dt_decls_ifequal (dt->derived, derived)) > break; > } > if (derived->backend_decl) > goto other_equal_dts; > } > > > > Yes, I was the author of that part of gfortran. Knowing it as well as I did, I wanted to get rid of it. Please find attached the patch (relative to trunk) that I am regtesting now. It doesn't permit the host derived type to be renamed yet but it does successfully deal with these problems of yours. Thanks Paul Index: gcc/fortran/symbol.c =================================================================== *** gcc/fortran/symbol.c (revision 116593) --- gcc/fortran/symbol.c (working copy) *************** gfc_use_derived (gfc_symbol * sym) *** 1460,1467 **** if (!(sym->attr.use_assoc || sym->attr.sequence)) return sym; ! /* Derived types must be defined within an interface. */ ! if (gfc_current_ns->proc_name->attr.if_source == IFSRC_IFBODY) return sym; } --- 1460,1469 ---- if (!(sym->attr.use_assoc || sym->attr.sequence)) return sym; ! /* Derived types must be defined within an interface and are not ! associated until resolve.c (resolve_symbol). */ ! if (gfc_current_ns->proc_name->attr.if_source ! == IFSRC_IFBODY) return sym; } Index: gcc/fortran/resolve.c =================================================================== *** gcc/fortran/resolve.c (revision 116593) --- gcc/fortran/resolve.c (working copy) *************** resolve_symbol (gfc_symbol * sym) *** 5681,5686 **** --- 5681,5715 ---- } } + if (sym->ts.type == BT_DERIVED + && sym->ns->proc_name->attr.if_source == IFSRC_IFBODY) + { + gfc_symbol *s; + + /* Look in parent namespace for a derived type of the same name. */ + if (gfc_find_symbol (sym->ts.derived->name, sym->ns->parent, 1, &s)) + { + gfc_error ("Symbol '%s' at %C is ambiguous", sym->name); + return; + } + + if (s != NULL && gfc_compare_derived_types (sym->ts.derived, s)) + sym->ts.derived = s; + else + { + gfc_error ("Cannot associate type '%s' at %C", sym->name); + return; + } + + if (sym->ns->proc_name->attr.function + && sym->ns->proc_name->ts.type == BT_DERIVED) + { + sym->ns->proc_name->ts.derived = s; + if (sym->ns->proc_name->result != NULL) + sym->ns->proc_name->result->ts.derived = s; + } + } + switch (sym->attr.flavor) { case FL_VARIABLE:
The new patch works for the testcase. But wrf still fails: [hjl@gnu-25 build_base_o2.0000]$ /usr/gcc-4.2/bin/gfortran -c -o ESMF_Clock.fppized.o -I. -I./netcdf/include -O2 -ffast-math -DSPEC_CPU_LINUX -DSPEC_CPU_CASE_FLAG -DSPEC_CPU_LOGICAL_STRICT -frecord-marker=4 ESMF_Clock.fppized.f90 ESMF_Clock.fppized.f90: In function ‘esmf_clockadvance’: ESMF_Clock.fppized.f90:752: internal compiler error: in fold_convert, at fold-const.c:2098 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. I am working on a small testcase.
Here it is: [hjl@gnu-25 wrf-1]$ cat zzz.f90 module bar implicit none public type ESMF_Time sequence integer :: MM end type public operator (+) private add interface operator (+) module procedure add end interface contains function add (x, y) type(ESMF_Time) :: add type(ESMF_Time), intent(in) :: x type(ESMF_Time), intent(in) :: y add = x end function add end module bar module foo use bar implicit none private type ESMF_Clock sequence type(ESMF_Time) :: CurrTime end type contains subroutine ESMF_ClockAdvance(clock) use bar type(ESMF_Clock), intent(inout) :: clock clock%CurrTime = clock%CurrTime + clock%CurrTime end subroutine ESMF_ClockAdvance end module foo [hjl@gnu-25 wrf-1]$ make zzz.s /usr/gcc-4.2/bin/gfortran -O2 -ffast-math -S -o zzz.s zzz.f90 zzz.f90: In function ‘esmf_clockadvance’: zzz.f90:31: internal compiler error: in fold_convert, at fold-const.c:2098 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. make: *** [zzz.s] Error 1 [hjl@gnu-25 wrf-1]$
Subject: Re: [4.1/4.2 Regression]: fold_convert fails for Fortran operator hjl at lucon dot org wrote: Thanks HJ. It seems that I am going to have to revert this one; I have spent way too much time on it and wasted a load of yours as well. At least the testsuite is enormously improved! Paul >------- Comment #20 from hjl at lucon dot org 2006-08-31 22:24 ------- >Here it is: > >[hjl@gnu-25 wrf-1]$ cat zzz.f90 >module bar > implicit none > public > type ESMF_Time > sequence > integer :: MM > end type > public operator (+) > private add > interface operator (+) > module procedure add > end interface >contains > function add (x, y) > type(ESMF_Time) :: add > type(ESMF_Time), intent(in) :: x > type(ESMF_Time), intent(in) :: y > add = x > end function add >end module bar > >module foo > use bar > implicit none > private > type ESMF_Clock > sequence > type(ESMF_Time) :: CurrTime > end type >contains > subroutine ESMF_ClockAdvance(clock) > use bar > type(ESMF_Clock), intent(inout) :: clock > clock%CurrTime = clock%CurrTime + clock%CurrTime > end subroutine ESMF_ClockAdvance >end module foo >[hjl@gnu-25 wrf-1]$ make zzz.s >/usr/gcc-4.2/bin/gfortran -O2 -ffast-math -S -o zzz.s zzz.f90 >zzz.f90: In function ‘esmf_clockadvance’: >zzz.f90:31: internal compiler error: in fold_convert, at fold-const.c:2098 >Please submit a full bug report, >with preprocessed source if appropriate. >See <URL:http://gcc.gnu.org/bugs.html> for instructions. >make: *** [zzz.s] Error 1 >[hjl@gnu-25 wrf-1]$ > > > >
Created attachment 12166 [details] A partial reversion to the previous method of type association. This regests OK on trunk and fixes the problems(regressions!) below. Sufficient of the original patch remains that the PRs that it was intended to fix remain fixed. My apologies to one and all for this struggle but the result has been an improved gfortran. HJ, you will see that in submitting to the list , I have required your green light before committing. If you have time today, I would be very grateful if you would test the patch, relative to trunk. Best regards Paul 2006-09-01 Paul Thomas <pault@gcc.gnu.org> PR fortran/28908 REGRESSION FIX * gfortran.h : Restore the gfc_dt_list structure and reference to it in gfc_namespace. * resolve.c (resolve_fl_derived): Restore the building of the list of derived types for the current namespace. * symbol.c (gfc_free_dt_list): Restore. (gfc_free_namespace): Restore call to previous. * trans-types.c (copy_dt_decls_ifequal): Restore. (gfc_get_derived_type): Restore all the paraphenalia for association of derived types, including calls to previous. 2006-09-01 Paul Thomas <pault@gcc.gnu.org> PR fortran/28908 * gfortran.dg/used_types_7.f90: New test. * gfortran.dg/used_types_8.f90: New test.
Subject: Bug number PR28908 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00008.html
Fix posted - I await your goahead, HJ. Paul
I am not sure if the patch is correct. I got [hjl@gnu-25 build_base_o2.0000]$ /usr/gcc-4.2/bin/gfortran -c -o module_integrate.fppized.o -I. -I./netcdf/include -O2 -ffast-math -DSPEC_CPU_LINUX -DSPEC_CPU_CASE_FLAG -DSPEC_CPU_LOGICAL_STRICT -frecord-marker=4 module_integrate.fppized.f90 gfortran: Internal error: Segmentation fault (program f951) Please submit a full bug report. See <URL:http://gcc.gnu.org/bugs.html> for instructions.
Here is a testcase: [hjl@gnu-25 wrf-1]$ cat bad.f90 module bar implicit none public type domain_ptr type(domain), POINTER :: ptr end type domain_ptr type domain TYPE(domain_ptr) , DIMENSION( : ) , POINTER :: parents TYPE(domain_ptr) , DIMENSION( : ) , POINTER :: nests end type domain end module bar module foo contains recursive subroutine integrate (grid) use bar implicit none type(domain), POINTER :: grid interface subroutine solve_interface (grid) use bar TYPE (domain) grid end subroutine solve_interface end interface end subroutine integrate end module foo [hjl@gnu-25 wrf-1]$ make bad.s /usr/gcc-4.2/bin/gfortran -S -o bad.s bad.f90 gfortran: Internal error: Segmentation fault (program f951) Please submit a full bug report. See <URL:http://gcc.gnu.org/bugs.html> for instructions. make: *** [bad.s] Error 1 [hjl@gnu-25 wrf-1]$
Subject: Re: [4.1/4.2 Regression]: fold_convert fails for Fortran operator HJ, I might be slow but I get there... what has been plaguing me all week is doing the development under Cygwin. I just realised that NONE of the failing cases that you have presented this week fail on Cygwin. It is only when I return to the ranch that I can reproduce what you are seeing; this goes for the business the other night - the portbale is running Cygwin because the b***y wireless card will not run with Linux/ndiswrapper, no matter what I do. Anyway, I agree that your latest shows that there is still a problem and will revert still further. Thanks and apologies about being so long winded about this - I am blowed if I am going to revert so far that I do not fix the two original bugs. *sigh* Paul
If you are using Intel Centrino notebook, there is an open source driver for wireless from Intel.
Created attachment 12183 [details] Fix for HJ's problems HJ, Could you try this one, please? I am pretty certain it will do the job. Thanks Paul
Gcc 4.2.0 revision 116560 plus the patch in comment #29 fixes this regression and passes SPEC CPU 2006. Thanks.
Subject: Re: [4.1/4.2 Regression]: fold_convert fails for Fortran operator hjl at lucon dot org wrote: >------- Comment #30 from hjl at lucon dot org 2006-09-04 17:39 ------- >Gcc 4.2.0 revision 116560 plus the patch in comment #29 fixes this regression >and passes SPEC CPU 2006. Thanks. > > > > HJ, You are in danger - in this neck of the woods, men kiss each other; by way of greetings and to show gratitude....... hah! Thanks I will commit first thing tomorrow. Paul
Paul, FYI, between the changes in the proposed patch here and others in gcc trunk to gfortran.h, resolve.c and trans-types.c, the proposed patch for PR 20541 needs to be readjusted again. Jack
Subject: Re: [4.1/4.2 Regression]: fold_convert fails for Fortran operator Jack, I know.... *sigh* First I have to fix that which was working that I broke. Then I will fix that which was neither broken nor fixed that might need breaking or fixing. I am so fed up of the whole business; it has taken two weeks from me. Paul
Subject: Bug 28908 Author: pault Date: Tue Sep 5 04:26:10 2006 New Revision: 116690 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116690 Log: 2006-09-05 Paul Thomas <pault@gcc.gnu.org> PR fortran/28908 REGRESSION FIX * gfortran.h : Restore the gfc_dt_list structure and reference to it in gfc_namespace. * resolve.c (resolve_fl_derived): Restore the building of the list of derived types for the current namespace. Modify the restored code so that a check is made to see if the symbol is already in the list. (resolve_fntype): Make sure that the specification block version of the derived type is used for a module function that returns that type. * symbol.c (gfc_free_dt_list): Restore. (gfc_free_namespace): Restore call to previous. * trans-types.c (copy_dt_decls_ifequal): Restore. (gfc_get_derived_type): Restore all the paraphenalia for association of derived types, including calls to previous. Modify the restored code such that all derived types are built if their symbols are found in the parent namespace; not just non-module types. Add backend_decls to like derived types in sibling namespaces, as well as that of the derived type. 2006-09-05 Paul Thomas <pault@gcc.gnu.org> PR fortran/28908 * gfortran.dg/used_types_7.f90: New test. * gfortran.dg/used_types_8.f90: New test. * gfortran.dg/used_types_9.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/used_types_7.f90 trunk/gcc/testsuite/gfortran.dg/used_types_8.f90 trunk/gcc/testsuite/gfortran.dg/used_types_9.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog
Subject: Bug 28908 Author: pault Date: Tue Sep 5 04:29:56 2006 New Revision: 116691 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116691 Log: 2006-09-05 Paul Thomas <pault@gcc.gnu.org> PR fortran/28908 REGRESSION FIX * gfortran.h : Restore the gfc_dt_list structure and reference to it in gfc_namespace. * resolve.c (resolve_fl_derived): Restore the building of the list of derived types for the current namespace. Modify the restored code so that a check is made to see if the symbol is already in the list. (resolve_fntype): Make sure that the specification block version of the derived type is used for a module function that returns that type. * symbol.c (gfc_free_dt_list): Restore. (gfc_free_namespace): Restore call to previous. * trans-types.c (copy_dt_decls_ifequal): Restore. (gfc_get_derived_type): Restore all the paraphenalia for association of derived types, including calls to previous. Modify the restored code such that all derived types are built if their symbols are found in the parent namespace; not just non-module types. Add backend_decls to like derived types in sibling namespaces, as well as that of the derived type. 2006-09-05 Paul Thomas <pault@gcc.gnu.org> PR fortran/28908 * gfortran.dg/used_types_7.f90: New test. * gfortran.dg/used_types_8.f90: New test. * gfortran.dg/used_types_9.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/used_types_7.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/used_types_8.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/used_types_9.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/gfortran.h branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/symbol.c branches/gcc-4_1-branch/gcc/fortran/trans-types.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog
Closed, at last! Thanks everybody. Paul