Compiling the original test for pr43199 with fortran-dev revision 157148 gives a segmentation fault: (gdb) run pr43199.f90 Starting program: /opt/gcc/gcc4.5d/libexec/gcc/x86_64-apple-darwin10/4.5.0/f951 pr43199.f90 Reading symbols for shared libraries .++++++++++++..... done Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 0x000000010005a6a5 in mio_expr (ep=<value temporarily unavailable, due to optimizations>) at ../../for_work/gcc/fortran/module.c:3074 3074 write_atom (ATOM_STRING, e->value.function.isym->name); (gdb) bt #0 0x000000010005a6a5 in mio_expr (ep=<value temporarily unavailable, due to optimizations>) at ../../for_work/gcc/fortran/module.c:3074 #1 0x000000010005ac8d in mio_charlen (clp=0x1418425f0) at ../../for_work/gcc/fortran/module.c:2050 #2 0x000000010005a4df in mio_typespec (ts=0x1418425e8) at ../../for_work/gcc/fortran/module.c:2106 #3 0x000000010005b377 in mio_component (c=0x1418425e0) at ../../for_work/gcc/fortran/module.c:2343 #4 0x000000010005b578 in mio_symbol (sym=0x141841880) at ../../for_work/gcc/fortran/module.c:2393 #5 0x000000010005b9ed in write_symbol (n=4, sym=0x141841880) at ../../for_work/gcc/fortran/module.c:4787 #6 0x000000010005ba9f in write_symbol1 (p=0x1418b4570) at ../../for_work/gcc/fortran/module.c:4856 #7 0x000000010005ba65 in write_symbol1 (p=0x1418b1990) at ../../for_work/gcc/fortran/module.c:4860 #8 0x000000010005ba53 in write_symbol1 (p=0x1418b1bd0) at ../../for_work/gcc/fortran/module.c:4851 #9 0x000000010005ba53 in write_symbol1 (p=0x1418b25f0) at ../../for_work/gcc/fortran/module.c:4851 #10 0x000000010005ba65 in write_symbol1 (p=0x1418acad0) at ../../for_work/gcc/fortran/module.c:4860 #11 0x000000010005ba53 in write_symbol1 (p=0x1418b3a30) at ../../for_work/gcc/fortran/module.c:4851 #12 0x000000010005ba65 in write_symbol1 (p=0x1418ac890) at ../../for_work/gcc/fortran/module.c:4860 #13 0x000000010005ba65 in write_symbol1 (p=0x1418ac650) at ../../for_work/gcc/fortran/module.c:4860 #14 0x000000010005ba53 in write_symbol1 (p=0x1418b3c70) at ../../for_work/gcc/fortran/module.c:4851 #15 0x000000010005ba65 in write_symbol1 (p=0x1418ab9f0) at ../../for_work/gcc/fortran/module.c:4860 #16 0x000000010005ba53 in write_symbol1 (p=0x1418b1510) at ../../for_work/gcc/fortran/module.c:4851 #17 0x000000010005d6dc in gfc_dump_module (name=0x7fff5fbfd3dd "", dump_flag=<value temporarily unavailable, due to optimizations>) at ../../for_work/gcc/fortran/module.c:5006 #18 0x0000000100069b5b in gfc_parse_file () at ../../for_work/gcc/fortran/parse.c:4226 #19 0x00000001000a2f4c in gfc_be_parse_file (set_yydebug=<value temporarily unavailable, due to optimizations>) at ../../for_work/gcc/fortran/f95-lang.c:239 #20 0x00000001006d61ea in toplev_main (argc=2, argv=0x7fff5fbfd968) at ../../for_work/gcc/toplev.c:1053 #21 0x00000001000017f4 in start () Note that this pr may be related to or a duplicate of pr42274. Since the exact places of the segmentation fault are different, I prefer to open a new pr. If this pr is a duplicate, please feel free to close it.
Here is a reduced test case, which ICEs with the same backtrace: module m_string type t_string character, dimension(:), allocatable :: string contains procedure :: char => string_to_char end type t_string contains function string_to_char (s) result(res) class(t_string), intent(in) :: s character(len=size(s%string)) :: res end function string_to_char end module m_string
Subject: Re: [fortran-dev Regression] ICE: segmentation fault in mio_expr Janus, I am looking at this and PR42274; I will be in a hotel room the evenings of next week and hope to get fortran-dev ready to merge back to trunk. In the mean time, I have posted a patch for the other fortran-dev regression, PR42353. I want to understand absolutely why it works and then I will commit an "obvious" fix. Cheers Paul On Thu, Apr 15, 2010 at 11:30 PM, janus at gcc dot gnu dot org <gcc-bugzilla@gcc.gnu.org> wrote: > > > ------- Comment #1 from janus at gcc dot gnu dot org 2010-04-15 21:30 ------- > Here is a reduced test case, which ICEs with the same backtrace: > > > module m_string > > type t_string > character, dimension(:), allocatable :: string > contains > procedure :: char => string_to_char > end type t_string > > contains > > function string_to_char (s) result(res) > class(t_string), intent(in) :: s > character(len=size(s%string)) :: res > end function string_to_char > > end module m_string > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43227 > > ------- You are receiving this mail because: ------- > You are on the CC list for the bug, or are watching someone who is. >
It turns out this problem is not specific to the OOP stuff on fortran-dev, but instead is due to an underlying problem with PROCEDURE statements (which affects procedure pointers as well as PPCs), demonstrated by this test case: module m_string procedure(string_to_char) :: char1 ! segfault ! procedure(string_to_char),pointer :: char2 ! segfault ! type t_string ! procedure(string_to_char),pointer,nopass :: char3 ! segfault ! end type t_string contains function string_to_char (s) result(res) character, dimension(:), intent(in) :: s character(len=size(s)) :: res end function string_to_char end module m_string All of the three forms of the PROCEDURE statement shown above trigger the same ICE (which is also the same ICE as in comment #0 and #1, due to fortran-dev's usage of PPCs in the implementation of polymorphic TBPs). The above test case segfaults with 4.3, works with 4.4, and then fails again with 4.5, 4.6 and fortran-dev. Therefore this PR is rather a 4.5 regression than a fortran-dev regressions.
Marked as a 4.5/4.6 regression.
What about pr42274? Is it a duplicate or not?
(In reply to comment #5) > What about pr42274? Is it a duplicate or not? I don't think so.
Created attachment 20410 [details] Fix for the problem This needs to be regtested but I believe it to be bombproof. However, I should attempt to find out why the resolution is not being done else where. Paul
(In reply to comment #6) > (In reply to comment #5) > > What about pr42274? Is it a duplicate or not? > > I don't think so. > My patch fixes pr42274 comment #9 but not the main part of it. Janus is quite right that the bugs are different. The patch regtests OK, as expected. I will do some investigating as to the right place to do the resolution. module.c does not look right :-) Cheers Paul Cheers Paul
I decided to take a look at this during lunchtime today. The source that I had to hand is the 20091203 4.5.0 snapshot. To my astonishment, this does not show the problem. I have had a quick look at the intervening gcc-cvs postings but cannot identify the source of the regression yet. Janus's patch of 20091211 is NOT the cause. Paul
> I decided to take a look at this during lunchtime today. The source that I had > to hand is the 20091203 4.5.0 snapshot. To my astonishment, this does not show > the problem. I have had a quick look at the intervening gcc-cvs postings but > cannot identify the source of the regression yet. Janus's patch of 20091211 is > NOT the cause. AFAICR the problem is specific to the fortran-dev branch. From my logs and my habits, I suspect that it was introduced between revisions 156573 (Feb 7 2010) and 157148 (probably at or after r157133, i.e. on or after Mon Mar 1 09:23:35 2010).
(In reply to comment #10) > AFAICR the problem is specific to the fortran-dev branch. No, this is definitely not the case! Only the failure of comment #0 is specific to the branch. However, this failure is caused by an underlying problem with procedure pointers, which is also present in the 4.5 release (see comment #3). When searching for the origin of the regression, one should use the test case in comment #3 and look at the 4.5 trunk.
> When searching for the origin of the regression, one should use the test case > in comment #3 and look at the 4.5 trunk. I keep forgetting this test!-(on i686-apple-darwin9, it compiles at revision 147438, 20090512, and fails at revision 150825, 20090817).
> I keep forgetting this test!-(on i686-apple-darwin9, it compiles at revision > 147438, 20090512, and fails at revision 150825, 20090817). That's a start. I can see two (hypothetical) candidates in this range: * r150725 * r150823 Will try to find out if one of these is the culprit.
(In reply to comment #13) > > I keep forgetting this test!-(on i686-apple-darwin9, it compiles at revision > > 147438, 20090512, and fails at revision 150825, 20090817). > > That's a start. I can see two (hypothetical) candidates in this range: > > * r150725 > * r150823 I just checked r150724, which also fails. This means that both my guesses were wrong. But at least it bring us down to the range 147438:150724 (which is still three months of development).
> I just checked r150724, which also fails. This means that both my guesses were > wrong. But at least it bring us down to the range 147438:150724 (which is still > three months of development). I don't have access to IRC from my office desk. If you have access to it, you may ping Tobias and Jerry to ask them to look to their archives for something in between.
Works: 2009-07-24-r150035 Fails: 2009-07-29-r150196 (Both trees were _not_ clean, but the first has the same patches as the second one, plus one more - thus, it is rather likely that the regression range is still correct.) I think the culprit is: Date: Sat Jul 25 11:56:35 2009 New Revision: 150078 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150078 2009-07-25 Janus Weil <janus@gcc.gnu.org> PR fortran/39630 * decl.c (match_ppc_decl): Implement the PASS attribute for procedure pointer components. [...] * module.c (MOD_VERSION): Bump module version. (binding_ppc): New string constants. (mio_component): Only use formal args if component is a procedure pointer and add 'tb' member. (mio_typebound_proc): Include pass_arg and take care of procedure pointer components. [...]
(In reply to comment #16) > I think the culprit is: > > Date: Sat Jul 25 11:56:35 2009 > New Revision: 150078 > URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150078 Close, but not quite :) It's actually r150047, as I just found out. However, this revision only introduces the first ICE in the test case: module m_string procedure(string_to_char) :: char1 ! ICE #1 ! procedure(string_to_char),pointer :: char2 ! ICE #2 ! type t_string ! procedure(string_to_char),pointer,nopass :: char3 ! ICE #3 ! end type t_string contains function string_to_char (s) result(res) character, dimension(:), intent(in) :: s character(len=size(s)) :: res end function string_to_char end module m_string The second one is already there at r150046. For this I found a window of 147438:148816 up to now. Will try to find out more. The third ICE is not present at 150047, but is apparently masked by another error: character(len=size(s)) :: res 1 Error: Character length of component 'char3' needs to be a constant specification expression at (1)
(In reply to comment #16) I sort of doubt it. The problem arises because mio_symbol crashes in writing the character length of the procedure symbol: Breakpoint 1, mio_symbol (sym=0x9d02370) at ../../fortran-dev/gcc/fortran/module.c:3560 3560 mio_typespec (&sym->ts); (gdb) print sym->name $1 = 0xb7c8c9f0 "char1" (gdb) print sym->ts.u.cl $2 = (gfc_charlen *) 0x9d04400 (gdb) print *sym->ts.u.cl $3 = {length = 0x9d04420, next = 0x0, length_from_typespec = 0 '\0', backend_decl = 0x0, passed_length = 0x0, resolved = 0} (gdb) print *sym->ts.interface->ts.u.cl $4 = {length = 0x9d03000, next = 0x9cb6be8, length_from_typespec = 0 '\0', backend_decl = 0x0, passed_length = 0x0, resolved = 1} (gdb) Note that the interface character length has been resolved, whereas the procedure character length has not. This is why my patch of #7 works. I believe that the problem must lie in resolve.c. For some reason, the symbol's own character length expression is not being resolved. Paul
Note that the patch in comment #7 fixes the test in comment #3 when the 'type t_string' block is uncommented. But there is still a "Segmentation fault" when the line ! procedure(string_to_char),pointer :: char2 ! segfault is uncommented.
Created attachment 20429 [details] A provisional fix for the PR This needs cleaning up and FAILUREs of the gfc_resolve_expr's need dealing with. Once this is done and a testcase fabricated, I will submit it - tomorrow morning, I guess. BTW It bootstraps and regtests on trunk. Paul
(In reply to comment #20) > Created an attachment (id=20429) [edit] > A provisional fix for the PR Yes, the following parts are approved (they're exactly what I had in mind): @@ -10292,6 +10298,8 @@ { c->ts.u.cl = gfc_new_charlen (sym->ns, ifc->ts.u.cl); gfc_expr_replace_comp (c->ts.u.cl->length, c); + if (c->ts.u.cl->length && !c->ts.u.cl->resolved) + gfc_resolve_expr (c->ts.u.cl->length); } } else if (c->ts.interface->name[0] != '\0' && !sym->attr.vtype) @@ -10805,6 +10813,8 @@ { sym->ts.u.cl = gfc_new_charlen (sym->ns, ifc->ts.u.cl); gfc_expr_replace_symbols (sym->ts.u.cl->length, sym); + if (sym->ts.u.cl->length && !sym->ts.u.cl->resolved) + gfc_resolve_expr (sym->ts.u.cl->length); } } else if (sym->ts.interface->name[0] != '\0') Could you explain what the other stuff is needed for? I currently fail to see that.
(In reply to comment #21) > > Could you explain what the other stuff is needed for? I currently fail to see > that. > Ignore the first bit in resolve.c, The change to trans-decl.c fixes the second segfault. The procedure pointers do not need a character length to do their job. So rather than making a decl for it, we just charge through. It needs a gcc_assert to make sure that we don't let everything through. Watch this space! Paul
Created attachment 20433 [details] fix for this PR and PR43266 The attached is what I intend to submit tonight, unless somebody approves it in the mean time. Obviously, the patch needs ChangeLogs. Also included is the fix for PR43266, which was first posted on March 27 and is very 'obvious'. Bootstrapped and regtested on FC9/x86_64 and RHEL5.4/i686 OK?
The patch in comment #23 works fine on my tests. Thanks for it. > Also included is the fix for PR43266, which was first posted on March 27 and is > very 'obvious'. Note for the record that it gives an additional error for PR43266 instead of the ICE: pr43266.f90:37.25: CALL obj%middle%proc_b 1 Error: 'proc_b' at (1) should be a SUBROUTINE
Subject: Re: [4.5/4.6 Regression] ICE: segmentation fault in mio_expr Dominiq, > > Note for the record that it gives an additional error for PR43266 instead of > the ICE: > > pr43266.f90:37.25: > > CALL obj%middle%proc_b > 1 > Error: 'proc_b' at (1) should be a SUBROUTINE Yes, indeed. This appears in the testcase and results from the module not being written. Paul
Subject: Bug 43227 Author: pault Date: Tue Apr 20 19:07:14 2010 New Revision: 158570 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158570 Log: 2010-04-20 Paul Thomas <pault@gcc.gnu.org> PR fortran/43227 * resolve.c (resolve_fl_derived): If a component character length has not been resolved, do so now. (resolve_symbol): The same as above for a symbol character length. * trans-decl.c (gfc_create_module_variable): A 'length' decl is not needed for a character valued, procedure pointer. PR fortran/43266 * resolve.c (ensure_not_abstract_walker): If 'overriding' is not found, return FAILURE rather than ICEing. 2010-04-20 Paul Thomas <pault@gcc.gnu.org> PR fortran/43227 * gfortran.dg/proc_decl_23.f90: New test. PR fortran/43266 * gfortran.dg/abstract_type_6.f03: New test. Added: trunk/gcc/testsuite/gfortran.dg/abstract_type_6.f03 trunk/gcc/testsuite/gfortran.dg/proc_decl_23.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog
Fixed on trunk - will do 4.5 next week. Paul
Subject: Bug 43227 Author: pault Date: Sat Apr 24 12:29:23 2010 New Revision: 158687 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158687 Log: 2010-04-24 Paul Thomas <pault@gcc.gnu.org> PR fortran/43227 * resolve.c (resolve_fl_derived): If a component character length has not been resolved, do so now. (resolve_symbol): The same as above for a symbol character length. * trans-decl.c (gfc_create_module_variable): A 'length' decl is not needed for a character valued, procedure pointer. PR fortran/43266 * resolve.c (ensure_not_abstract_walker): If 'overriding' is not found, return FAILURE rather than ICEing. 2010-04-24 Paul Thomas <pault@gcc.gnu.org> PR fortran/43227 * gfortran.dg/proc_decl_23.f90: New test. PR fortran/43266 * gfortran.dg/abstract_type_6.f03: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/abstract_type_6.f03 branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/proc_decl_23.f90 Modified: branches/gcc-4_5-branch/gcc/fortran/ChangeLog branches/gcc-4_5-branch/gcc/fortran/resolve.c branches/gcc-4_5-branch/gcc/fortran/trans-decl.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
Fixed on trunk and 4.5. Thanks, as ever, Dominique! Paul