[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[pault at gcc dot gnu dot org]

--- Comment #38 from pault at gcc dot gnu dot org  2010-04-29 19:11 ---
Subject: Bug 42274

Author: pault
Date: Thu Apr 29 19:10:48 2010
New Revision: 158910

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158910
Log:
2010-04-29  Janus Weil  

PR fortran/43896
* symbol.c (add_proc_component,copy_vtab_proc_comps): Remove
initializers for PPC members of the vtabs.

2010-04-29  Janus Weil  

PR fortran/42274
* symbol.c (add_proc_component,add_proc_comps): Correctly set the 'ppc'
attribute for all PPC members of the vtypes.
(copy_vtab_proc_comps): Copy the correct interface.
* trans.h (gfc_trans_assign_vtab_procs): Modified prototype.
* trans-expr.c (gfc_trans_assign_vtab_procs): Pass the derived type as
a dummy argument and make sure all PPC members of the vtab are
initialized correctly.
(gfc_conv_derived_to_class,gfc_trans_class_assign): Additional argument
in call to gfc_trans_assign_vtab_procs.
* trans-stmt.c (gfc_trans_allocate): Ditto.

2010-04-29  Paul Thomas  

PR fortran/43326
* resolve.c (resolve_typebound_function): Renamed
resolve_class_compcall.Do all the detection of class references
here.
(resolve_typebound_subroutine): resolve_class_typebound_call
renamed. Otherwise same as resolve_typebound_function.
(gfc_resolve_expr): Call resolve_typebound_function.
(resolve_code): Call resolve_typebound_subroutine.

2010-04-29  Janus Weil  

PR fortran/43492
* resolve.c (resolve_typebound_generic_call): For CLASS methods
pass back the specific symtree name, rather than the target
name.

2010-04-29  Paul Thomas  

PR fortran/42353
* resolve.c (resolve_structure_cons): Make the initializer of
the vtab component 'extends' the same type as the component.

2010-04-29  Jerry DeLisle  

PR fortran/42680
* interface.c (check_interface1): Pass symbol name rather than NULL to
gfc_compare_interfaces.(gfc_compare_interfaces): Add assert to
trap MULL. (gfc_compare_derived_types): Revert previous change
incorporated incorrectly during merge from trunk, r155778.
* resolve.c (check_generic_tbp_ambiguity): Pass symbol name rather
than NULL to gfc_compare_interfaces.
* symbol.c (add_generic_specifics): Likewise.

2010-02-29  Janus Weil  

PR fortran/42353
* interface.c (gfc_compare_derived_types): Add condition for vtype.
* symbol.c (gfc_find_derived_vtab): Sey access to private.
(gfc_find_derived_vtab): Likewise.
* module.c (ab_attribute): Add enumerator AB_VTAB.
(mio_symbol_attribute): Use new attribute, AB_VTAB.
(check_for_ambiguous): Likewise.

2010-04-29  Paul Thomas  
Janus Weil  

PR fortran/41829
* trans-expr.c (select_class_proc): Remove function.
(conv_function_val): Delete reference to previous.
(gfc_conv_derived_to_class): Add second argument to the call to
gfc_find_derived_vtab.
(gfc_conv_structure): Exclude proc_pointer components when
accessing $data field of class objects.
(gfc_trans_assign_vtab_procs): New function.
(gfc_trans_class_assign): Add second argument to the call to
gfc_find_derived_vtab.
* symbol.c (gfc_build_class_symbol): Add delayed_vtab arg and
implement holding off searching for the vptr derived type.
(add_proc_component): New function.
(add_proc_comps): New function.
(add_procs_to_declared_vtab1): New function.
(copy_vtab_proc_comps): New function.
(add_procs_to_declared_vtab): New function.
(void add_generic_specifics): New function.
(add_generics_to_declared_vtab): New function.
(gfc_find_derived_vtab): Add second argument to the call to
gfc_find_derived_vtab. Add the calls to
add_procs_to_declared_vtab and add_generics_to_declared_vtab.
* decl.c (build_sym, build_struct): Use new arg in calls to
gfc_build_class_symbol.
* gfortran.h : Add vtype bitfield to symbol_attr. Remove the
definition of struct gfc_class_esym_list. Modify prototypes
of gfc_build_class_symbol and gfc_find_derived_vtab.
* trans-stmt.c (gfc_trans_allocate): Add second argument to the
call to gfc_find_derived_vtab.
* module.c : Add the vtype attribute.
* trans.h : Add prototype for gfc_trans_assign_vtab_procs.
* resolve.c (resolve_typebound_generic_call): Add second arg
to pass along the generic name for class methods.
(resolve_typebound_call): The same.
(resolve_compcall): Use the second arg to carry the generic
name from the above. Remove the reference to class_esym.
(check_members, check_class_members, resolve_class_esym,
hash_value_expr): Remov

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[pault at gcc dot gnu dot org]

--- Comment #37 from pault at gcc dot gnu dot org  2010-04-26 10:57 ---
I think that we can mark this as closed.

Thanks, first to Salvatore for the report and second to Janus for the fix.

Salvatore, to repeat Janus's request, could you please check that there are no
further regressions, relative to trunk?  I am aiming to synchronise the two
trees later on this week.

Thanks again for all the efforts

Paul 


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[janus at gcc dot gnu dot org]

--- Comment #36 from janus at gcc dot gnu dot org  2010-04-26 09:08 ---
Subject: Bug 42274

Author: janus
Date: Mon Apr 26 09:07:26 2010
New Revision: 158721

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158721
Log:
2010-04-26  Janus Weil  

PR fortran/42274
* symbol.c (add_proc_component,add_proc_comps): Correctly set the 'ppc'
attribute for all PPC members of the vtypes.
(copy_vtab_proc_comps): Copy the correct interface.
* trans.h (gfc_trans_assign_vtab_procs): Modified prototype.
* trans-expr.c (gfc_trans_assign_vtab_procs): Pass the derived type as
a dummy argument and make sure all PPC members of the vtab are
initialized correctly.
(gfc_conv_derived_to_class,gfc_trans_class_assign): Additional argument
in call to gfc_trans_assign_vtab_procs.
* trans-stmt.c (gfc_trans_allocate): Ditto.

2010-04-26  Janus Weil  

PR fortran/42274
* gfortran.dg/class_15.f03: New.

Added:
branches/fortran-dev/gcc/testsuite/gfortran.dg/class_15.f03
Modified:
branches/fortran-dev/gcc/fortran/ChangeLog.fortran-dev
branches/fortran-dev/gcc/fortran/symbol.c
branches/fortran-dev/gcc/fortran/trans-expr.c
branches/fortran-dev/gcc/fortran/trans-stmt.c
branches/fortran-dev/gcc/fortran/trans.h
branches/fortran-dev/gcc/testsuite/ChangeLog.fortran-dev


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[dominiq at lps dot ens dot fr]

--- Comment #35 from dominiq at lps dot ens dot fr  2010-04-26 08:23 ---
> The testsuite completed cleanly, without any failures. Paul, if you agree that
> this patch is ok, I can commit it tomorrow.

Confirmed without any problem on my own test.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[janus at gcc dot gnu dot org]

--- Comment #34 from janus at gcc dot gnu dot org  2010-04-25 22:26 ---
(In reply to comment #33)
> Will do a full testsuite run now.

The testsuite completed cleanly, without any failures. Paul, if you agree that
this patch is ok, I can commit it tomorrow.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[janus at gcc dot gnu dot org]

--- Comment #33 from janus at gcc dot gnu dot org  2010-04-25 21:44 ---
Created an attachment (id=20488)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20488&action=view)
patch v5

The attached version of the patch clears the failures of
dynamic_dispatch_{1-3}.f03. It is free of regressions in class_*, dynamic_* and
typebound_*. Will do a full testsuite run now.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #20482|0   |1
is obsolete||
  Attachment #20484|0   |1
is obsolete||
  Attachment #20485|0   |1
is obsolete||
  Attachment #20486|0   |1
is obsolete||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[sfilippone at uniroma2 dot it]

--- Comment #32 from sfilippone at uniroma2 dot it  2010-04-25 20:20 ---
(In reply to comment #30)
> 
> Salvatore: As you heard, Paul's patch is screwed up. Maybe you could rather 
> try
> the patch in comment #23, which is clean (except for a small regression) and
> fixes your original problem. Does this give the same error on your code?
> 
Actually I tried both, and both give the same error. The obvious question is
whether this is related to the patch or not.
I really look forward to the merge into trunk, and I would prefer reporting the
new bug against trunk. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[janus at gcc dot gnu dot org]

--- Comment #31 from janus at gcc dot gnu dot org  2010-04-25 20:17 ---
Ok, back to fixing the remaining regression, namely comment #24. Compiling this
with and without the patch in comment #23 shows the following difference:

--- c24.dump.unpatched  2010-04-25 22:03:44.418204091 +0200
+++ c24.dump.patched2010-04-25 21:55:50.500619202 +0200
@@ -27,7 +27,7 @@ MAIN__ ()
   if (vtab$t2.make_integer == 0B)
 {
   vtab$t2.make_integer = (integer(kind=4) (*) (void)) make_integer;
-  vtab$vtype$t2$extract.make_integer = make_integer_2;
+  vtab$vtype$t2$extract.make_integer = (integer(kind=4) (*) (struct
.class.t2 & restrict, integer(kind=4) & restrict)) make_integer;
   vtab$t2.extract = &vtab$vtype$t2$extract;
   vtab$t2.make_integer_2 = (integer(kind=4) (*) (void))
make_integer_2;
 }


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[janus at gcc dot gnu dot org]

--- Comment #30 from janus at gcc dot gnu dot org  2010-04-25 19:50 ---
(In reply to comment #29)
> (In reply to comment #27)
> > Created an attachment (id=20486)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20486&action=view) [edit]
> > 
> Tried this patch: compilation goes past the previous point, so we made
> progress.
> My library build stops later with 

Salvatore: As you heard, Paul's patch is screwed up. Maybe you could rather try
the patch in comment #23, which is clean (except for a small regression) and
fixes your original problem. Does this give the same error on your code?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[sfilippone at uniroma2 dot it]

--- Comment #29 from sfilippone at uniroma2 dot it  2010-04-25 19:16 ---
(In reply to comment #27)
> Created an attachment (id=20486)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20486&action=view) [edit]
> 
Tried this patch: compilation goes past the previous point, so we made
progress.
My library build stops later with 

psb_ssymbmm.f90: In function 'psb_ssymbmm':
psb_ssymbmm.f90:88:0: error: statement makes a memory store, but has no VDEFS
c_7.a.$data = 0B;
psb_ssymbmm.f90:88:0: internal compiler error: verify_ssa failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[2]: *** [psb_ssymbmm.o] Error 1

Does it ring a bell ? If this is not an obvious duplicate of some other issue,
I'll open a PR (tomorrow) 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[paul dot richard dot thomas at gmail dot com]

--- Comment #28 from paul dot richard dot thomas at gmail dot com  
2010-04-25 18:59 ---
Subject: Re:  [fortran-dev Regression] ICE: segmentation 
fault

Janus,

Forget all of our last exchanges - I screwed up somehow with the
patch.  This has nothing to do with your problem

Sorry

Paul

On Sun, Apr 25, 2010 at 8:27 PM, Paul Richard Thomas
 wrote:
> Dear Janus,
>
> I thought that I would lend a helping hand, so I applied your latest
> patch to my fortran-dev.  Since I had left some of my array reference
> development in place, it failed to apply on
>
> ***
> *** 2486,2492 
>      not to the class declared type.  */
>    vtab = gfc_find_derived_vtab (e->ts.u.derived, true);
>    gcc_assert (vtab);
> -   gfc_trans_assign_vtab_procs (&parmse->pre, vtab);
>    tmp = gfc_build_addr_expr (NULL_TREE, gfc_get_symbol_decl (vtab));
>    gfc_add_modify (&parmse->pre, ctree,
>                  fold_convert (TREE_TYPE (ctree), tmp));
> --- 2486,2492 
>      not to the class declared type.  */
>    vtab = gfc_find_derived_vtab (e->ts.u.derived, true);
>    gcc_assert (vtab);
> +   gfc_trans_assign_vtab_procs (&parmse->pre, e->ts.u.derived, vtab);
>    tmp = gfc_build_addr_expr (NULL_TREE, gfc_get_symbol_decl (vtab));
>    gfc_add_modify (&parmse->pre, ctree,
>                  fold_convert (TREE_TYPE (ctree), tmp));
>
> Since this was a compilable source, even with the failure, I decided
> to build it anyway. Lo and behold, the regressions have gone :-)
>
> It's just now regtesting.
>
> Please find the whole diff attached.
>
> I hope that this helps.
>
> Cheers
>
> Paul
>


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[paul dot richard dot thomas at gmail dot com]

--- Comment #26 from paul dot richard dot thomas at gmail dot com  
2010-04-25 18:28 ---
Subject: Re:  [fortran-dev Regression] ICE: segmentation 
fault

Dear Janus,

I thought that I would lend a helping hand, so I applied your latest
patch to my fortran-dev.  Since I had left some of my array reference
development in place, it failed to apply on

***
*** 2486,2492 
  not to the class declared type.  */
vtab = gfc_find_derived_vtab (e->ts.u.derived, true);
gcc_assert (vtab);
-   gfc_trans_assign_vtab_procs (&parmse->pre, vtab);
tmp = gfc_build_addr_expr (NULL_TREE, gfc_get_symbol_decl (vtab));
gfc_add_modify (&parmse->pre, ctree,
  fold_convert (TREE_TYPE (ctree), tmp));
--- 2486,2492 
  not to the class declared type.  */
vtab = gfc_find_derived_vtab (e->ts.u.derived, true);
gcc_assert (vtab);
+   gfc_trans_assign_vtab_procs (&parmse->pre, e->ts.u.derived, vtab);
tmp = gfc_build_addr_expr (NULL_TREE, gfc_get_symbol_decl (vtab));
gfc_add_modify (&parmse->pre, ctree,
  fold_convert (TREE_TYPE (ctree), tmp));

Since this was a compilable source, even with the failure, I decided
to build it anyway. Lo and behold, the regressions have gone :-)

It's just now regtesting.

Please find the whole diff attached.

I hope that this helps.

Cheers

Paul


--- Comment #27 from paul dot richard dot thomas at gmail dot com  
2010-04-25 18:28 ---
Created an attachment (id=20486)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20486&action=view)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[janus at gcc dot gnu dot org]

--- Comment #25 from janus at gcc dot gnu dot org  2010-04-25 18:23 ---
I just did a full testsuite run, verifying that "dynamic_dispatch_{1-3}.f03"
are indeed the only failures with the patch in comment #23.

This means that, if we can fix the failure in comment #24, the branch will most
probably be clean, and we can finally merge back to trunk.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[janus at gcc dot gnu dot org]

--- Comment #24 from janus at gcc dot gnu dot org  2010-04-25 17:16 ---
(In reply to comment #20)
> My suspicion, which is strengthened by the remaining regressions for version 3
> of your fix, is that the generic components of the vtab should not be marked 
> as
> ppc.  I have been tempted to apply it blind but have been trying to analyse
> first :-)  That does not mean that you should not give it a shot, though!

Well, in the light of today's progress I am quite optimistic that it should be
possible to have everything working with all the 'ppc' attributes in place.

Note that many cases of generic TBPs are working already. The remaining
failures seem to be related to generic TBPs with overriding.

The following is a reduced version of the runtime failure in
dynamic_dispatch_1.f03:


module m

  type :: t1
integer :: i = 42
  contains
procedure, pass :: make_integer
generic, public :: extract => make_integer
  end type t1

  type, extends(t1) :: t2
integer :: j = 99
  contains
procedure, pass :: make_integer_2
generic, public :: extract => make_integer_2
  end type t2

contains

  integer function make_integer (arg, arg2)
class(t1), intent(in) :: arg
integer :: arg2
make_integer = arg%i * arg2
  end function make_integer

  integer function make_integer_2 (arg, arg2)
class(t2), intent(in) :: arg
integer :: arg2
make_integer_2 = arg%j * arg2
  end function make_integer_2

end module m

  use m
  class(t1), pointer :: a
  type(t2), target :: c
  a => c
  print *,a%extract(3)
  if (a%extract (3) .ne. 297) call abort! FAIL

end


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[janus at gcc dot gnu dot org]

--- Comment #23 from janus at gcc dot gnu dot org  2010-04-25 17:09 ---
Created an attachment (id=20485)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20485&action=view)
patch v4

The attached update of the patch removes the ICEs in
typebound_operator_{3,4}.f03.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[janus at gcc dot gnu dot org]

--- Comment #22 from janus at gcc dot gnu dot org  2010-04-25 16:43 ---
(In reply to comment #21)
> /opt/gcc/work/gcc/testsuite/gfortran.dg/typebound_operator_3.f03:84:0: 
> internal
> compiler error: Segmentation fault

Yes, I can confirm that: typebound_operator_{3,4}.f03 both fail with an ICE.
Thanks for pointing that out. I haven't checked the full testsuite yet.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[dominiq at lps dot ens dot fr]

--- Comment #21 from dominiq at lps dot ens dot fr  2010-04-25 16:38 ---
> Here is an updated patch, which fixes (among others) comment #8 example 2 and
> comment #18. The remaining regressions are:
> 
> * dynamic_dispatch_{1-3}.f03

I also have

[macbook] f90/bug% gfc
/opt/gcc/work/gcc/testsuite/gfortran.dg/typebound_operator_3.f03
/opt/gcc/work/gcc/testsuite/gfortran.dg/typebound_operator_3.f03: In function
'check_in_module':
/opt/gcc/work/gcc/testsuite/gfortran.dg/typebound_operator_3.f03:84:0: internal
compiler error: Segmentation fault
[macbook] f90/bug% gfc pr43199.f90
pr43199.f90: In function 'char_less_equal_string':
pr43199.f90:162:0: internal compiler error: Segmentation fault

Note that this may be due to some interference between the patch in comment #19
and other ones I have in my tree.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[pault at gcc dot gnu dot org]

--- Comment #20 from pault at gcc dot gnu dot org  2010-04-25 16:27 ---
(In reply to comment #19)
Janus,

When I got up this morning, I made a start on documenting the fortran-dev
version of gfc_find_derived_vtab with a view to understand the code flow and to
understand why the original patch was failing.

My suspicion, which is strengthened by the remaining regressions for version 3
of your fix, is that the generic components of the vtab should not be marked as
ppc.  I have been tempted to apply it blind but have been trying to analyse
first :-)  That does not mean that you should not give it a shot, though!

Cheers

Paul


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[janus at gcc dot gnu dot org]

--- Comment #19 from janus at gcc dot gnu dot org  2010-04-25 14:56 ---
Created an attachment (id=20484)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20484&action=view)
patch v3

Here is an updated patch, which fixes (among others) comment #8 example 2 and
comment #18. The remaining regressions are:

* dynamic_dispatch_{1-3}.f03


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[janus at gcc dot gnu dot org]

--- Comment #18 from janus at gcc dot gnu dot org  2010-04-25 14:42 ---
Here is a maximally reduced version of comment #8 example 2, which still fails
with the patch in comment #17:

module m
  type :: t1
  contains
procedure :: make_integer
generic :: extract => make_integer
  end type
contains
  integer function make_integer (arg)
class(t1), intent(in) :: arg
make_integer = 3
  end function
end module

  use m
  class(t1), allocatable :: a
  allocate(a)
  print *, a%extract ()
end


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[janus at gcc dot gnu dot org]

--- Comment #17 from janus at gcc dot gnu dot org  2010-04-25 14:32 ---
Created an attachment (id=20482)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20482&action=view)
patch v2

The attached patch extends the one in comment #7, fixing all regressions
related to non-generic TBPs (hopefully). However, (at least) the following
regressions are left (all including generic TBPs):

* dynamic_dispatch_{1-3,5,7}.f03 in the testsuite
* comment #8 example 2


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[janus at gcc dot gnu dot org]

--- Comment #16 from janus at gcc dot gnu dot org  2010-04-22 20:58 ---
For completeness, here is a reduced/modified version of the original test case
in comment #1:


module mod_A
  type :: t1
  contains 
procedure,nopass :: fun
  end type
contains
  logical function fun()
  end function
end module

module mod_B
  use mod_A
  type, extends(t1) :: t2
  contains
procedure :: sub1
  end type
contains 
  subroutine sub1(a)
class(t2) :: a
  end subroutine
end module

module mod_C
contains 
  subroutine sub2(b)
use mod_B
type(t2) :: b
  end subroutine
end module

module mod_D
  use mod_A
  use mod_C
end module


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[dominiq at lps dot ens dot fr]

--- Comment #15 from dominiq at lps dot ens dot fr  2010-03-02 09:47 ---
I just opened pr43227 for a similar regression. For the record the backtrace
for the test in comment#1 with fortran-dev revision 157148 is

(gdb) run pr42274.f90
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /opt/gcc/gcc4.5d/libexec/gcc/x86_64-apple-darwin10/4.5.0/f951
pr42274.f90
 is_null csclip d_csgetblk d_csgetrow d_b_csclip d_csclip is_null
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0028
mio_pointer_ref (gp=0x28) at ../../for_work/gcc/fortran/module.c:2251
2251  p = get_pointer (*((char **) gp));
(gdb) bt
#0  mio_pointer_ref (gp=0x28) at ../../for_work/gcc/fortran/module.c:2251
#1  0x000100059c79 in mio_symbol_ref (symp=) at ../../for_work/gcc/fortran/module.c:2512
#2  0x000100059fc9 in mio_typebound_proc (proc=0x1418e8040) at
../../for_work/gcc/fortran/module.c:3381
#3  0x00010005b3ee in mio_component (c=0x1418e7fb0) at
../../for_work/gcc/fortran/module.c:2376
#4  0x00010005b578 in mio_symbol (sym=0x1418e7690) at
../../for_work/gcc/fortran/module.c:2393
#5  0x00010005b9ed in write_symbol (n=40, sym=0x1418e7690) at
../../for_work/gcc/fortran/module.c:4787
#6  0x00010005ba9f in write_symbol1 (p=0x14187c560) at
../../for_work/gcc/fortran/module.c:4856
#7  0x00010005ba65 in write_symbol1 (p=0x141870080) at
../../for_work/gcc/fortran/module.c:4860
#8  0x00010005ba65 in write_symbol1 (p=0x14186ff60) at
../../for_work/gcc/fortran/module.c:4860
#9  0x00010005ba53 in write_symbol1 (p=0x14187c8c0) at
../../for_work/gcc/fortran/module.c:4851
#10 0x00010005ba65 in write_symbol1 (p=0x1418ce660) at
../../for_work/gcc/fortran/module.c:4860
#11 0x00010005ba65 in write_symbol1 (p=0x1418cc130) at
../../for_work/gcc/fortran/module.c:4860
#12 0x00010005ba65 in write_symbol1 (p=0x141868b70) at
../../for_work/gcc/fortran/module.c:4860
#13 0x00010005ba65 in write_symbol1 (p=0x14187ab80) at
../../for_work/gcc/fortran/module.c:4860
#14 0x00010005ba65 in write_symbol1 (p=0x14187b480) at
../../for_work/gcc/fortran/module.c:4860
#15 0x00010005ba65 in write_symbol1 (p=0x1418c7e60) at
../../for_work/gcc/fortran/module.c:4860
#16 0x00010005ba53 in write_symbol1 (p=0x1418c03c0) at
../../for_work/gcc/fortran/module.c:4851
#17 0x00010005ba65 in write_symbol1 (p=0x1418c4e00) at
../../for_work/gcc/fortran/module.c:4860
#18 0x00010005ba65 in write_symbol1 (p=0x1418c28e0) at
../../for_work/gcc/fortran/module.c:4860
#19 0x00010005ba65 in write_symbol1 (p=0x141825cb0) at
../../for_work/gcc/fortran/module.c:4860
#20 0x00010005ba65 in write_symbol1 (p=0x1418a87e0) at
../../for_work/gcc/fortran/module.c:4860
#21 0x00010005d6dc in gfc_dump_module (name=0x7fff5fbfd3ad "",
dump_flag=) at
../../for_work/gcc/fortran/module.c:5006
#22 0x000100069b5b in gfc_parse_file () at
../../for_work/gcc/fortran/parse.c:4226
#23 0x0001000a2f4c in gfc_be_parse_file (set_yydebug=) at
../../for_work/gcc/fortran/f95-lang.c:239
#24 0x0001006d61ea in toplev_main (argc=2, argv=0x7fff5fbfd968) at
../../for_work/gcc/toplev.c:1053
#25 0x000117f4 in start ()


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[janus at gcc dot gnu dot org]

--- Comment #14 from janus at gcc dot gnu dot org  2009-12-10 21:21 ---
Comparing the dump of the test case in comment #9 with and without the patch in
comment #11 shows that with the patch the following is missing:

@@ -25,10 +25,6 @@ MAIN__ ()
   integer(kind=4) itmp;
   extern struct vtype$t1 vtab$t1;

-  if (vtab$t1.prod == 0B)
-{
-  vtab$t1.prod = (integer(kind=4) (*) (void)) i_m_j;
-}
   a.$vptr = &vtab$t1;
   a.$data = &b;
   itmp = a.$vptr->prod (&a);


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[pault at gcc dot gnu dot org]

--- Comment #13 from pault at gcc dot gnu dot org  2009-12-06 13:32 ---
(In reply to comment #11)

> However, I fail to see why. Paul, do you have an idea?
> 

I have loaded fortran-dev and this PR onto my laptop - I'm on the road again
this week.

I'll see if I have anything to offer.  In the mean time, there are various
problems associated with vtables that I would like to deal with

Cheers

Paul


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[dominiq at lps dot ens dot fr]

--- Comment #12 from dominiq at lps dot ens dot fr  2009-12-05 16:41 ---
Removing the line outlined in comment#11, slightly improve the situation:
class_9.f03 and dynamic_dispatch_5.f03, and the test in comment #9 now pass and
I get for pr41829.f90:

[macbook] f90/bug% gfc pr41829.f90 
[macbook] f90/bug% a.out 
 FOO%DOIT base version
 Getit value :1
Segmentation fault


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[janus at gcc dot gnu dot org]

--- Comment #11 from janus at gcc dot gnu dot org  2009-12-05 15:14 ---
(In reply to comment #8)
> With the patch in comment #7 the tests in pr41829 and the following ones
> segfault at runtime.

Since these run fine with a clean fortran-dev, this is a regression of my
patch, more exactly of the following part:

Index: gcc/fortran/symbol.c
===
--- gcc/fortran/symbol.c(revision 154956)
+++ gcc/fortran/symbol.c(working copy)
@@ -4751,6 +4751,7 @@ add_proc_component (gfc_component *c, gfc_symbol *
   if (!c->tb)
 c->tb = XCNEW (gfc_typebound_proc);
   *c->tb = *st->n.tb;
+  c->tb->ppc = 1;
   c->attr.procedure = 1;
   c->attr.proc_pointer = 1;
   c->attr.flavor = FL_PROCEDURE;

However, I fail to see why. Paul, do you have an idea?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[dominiq at lps dot ens dot fr]

--- Comment #10 from dominiq at lps dot ens dot fr  2009-12-05 13:31 ---
With the patch in comment #7 the tests gfortran.dg/class_9.f03 and
gfortran.dg/dynamic_dispatch_[1-6].f03 also give a segfault at runtime.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[janus at gcc dot gnu dot org]

--- Comment #9 from janus at gcc dot gnu dot org  2009-12-05 11:20 ---
(In reply to comment #8)
> With the patch in comment #7 the tests in pr41829 and the following ones
> segfault at runtime.

Confirmed. This may be an initialization issue of the vtypes. Reduced test
case:

module m
  type :: t1
integer :: i = 42
  contains
procedure, pass :: prod => i_m_j
  end type t1
contains
  integer function i_m_j (arg)
class(t1), intent(in) :: arg
print *,"in i_m_j"
i_m_j = 0
  end function i_m_j
end module m

  use m
  class(t1), pointer :: a
  type(t1), target :: b
  integer :: itmp
  a => b
  itmp = a%prod()
  print *, itmp
end


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pault at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[dominiq at lps dot ens dot fr]

--- Comment #8 from dominiq at lps dot ens dot fr  2009-12-04 21:37 ---
With the patch in comment #7 the tests in pr41829 and the following ones
segfault at runtime.

!

module m
  type :: t1
integer :: i = 42
  contains
procedure, pass :: prod => i_m_j
  end type t1
  type, extends(t1) :: t2
integer :: j = 99
  end type t2
contains
  integer function i_m_j (arg)
class(t1), intent(in) :: arg
select type (arg)
  type is (t1)
i_m_j = 0
  class is (t2)
i_m_j = 1
  class default
print *, "should not be here"
end select
  end function i_m_j
end module m

  use m
  class(t1), pointer :: a
  type(t1), target :: b
  type(t2), target :: c
  integer :: itmp
  a => b
  itmp = a%prod()
  print *, itmp
  a => c
  itmp = a%prod()
  print *, itmp
end

!

module m

  type :: null_type
  end type

  type :: t1
integer :: i = 42
procedure(make_real), pointer :: ptr
  contains
procedure, pass :: real => make_real
procedure, pass :: make_integer
procedure, pass :: prod => i_m_j
generic, public :: extract => real, make_integer
  end type t1

  type, extends(t1) :: t2
integer :: j = 99
  contains
procedure, pass :: real => make_real2
procedure, pass :: make_integer_2
procedure, pass :: prod => i_m_j_2
generic, public :: extract => real, make_integer_2
  end type t2

contains

  real function make_real (arg)
class(t1), intent(in) :: arg
make_real = real (arg%i)
  end function make_real

  real function make_real2 (arg)
class(t2), intent(in) :: arg
make_real2 = real (arg%j)
  end function make_real2

  integer function make_integer (arg, arg2)
class(t1), intent(in) :: arg
integer :: arg2
make_integer = arg%i * arg2
  end function make_integer

  integer function make_integer_2 (arg, arg2)
class(t2), intent(in) :: arg
integer :: arg2
make_integer_2 = arg%j * arg2
  end function make_integer_2

  integer function i_m_j (arg)
class(t1), intent(in) :: arg
i_m_j = arg%i
  end function i_m_j

  integer function i_m_j_2 (arg)
class(t2), intent(in) :: arg
i_m_j_2 = arg%j
  end function i_m_j_2

end module m


  use m
  class(t1), pointer :: a !=> NULL()
  type(t1), target :: b
  type(t2), target :: c
  a => b
  print *, a%i,a%real(), a%prod(), a%extract (2)
  a => c
  print *, a%i,a%real(), a%prod(), a%extract (3)
end


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[janus at gcc dot gnu dot org]

--- Comment #7 from janus at gcc dot gnu dot org  2009-12-04 19:43 ---
(In reply to comment #6)
> I think the problem is that c->tb->ppc is not set correctly for the PPCs 
> inside
> vtype.

The following patches fixes it:

Index: gcc/fortran/symbol.c
===
--- gcc/fortran/symbol.c(revision 154956)
+++ gcc/fortran/symbol.c(working copy)
@@ -4751,6 +4751,7 @@ add_proc_component (gfc_component *c, gfc_symbol *
   if (!c->tb)
 c->tb = XCNEW (gfc_typebound_proc);
   *c->tb = *st->n.tb;
+  c->tb->ppc = 1;
   c->attr.procedure = 1;
   c->attr.proc_pointer = 1;
   c->attr.flavor = FL_PROCEDURE;
@@ -4790,6 +4791,7 @@ add_proc_comps (gfc_component *c, gfc_symbol *vtyp
   else if (c->attr.proc_pointer && c->tb)
 {
   *c->tb = *st->n.tb;
+  c->tb->ppc = 1;
   c->ts.interface = st->n.tb->u.specific->n.sym; 
 }
 }
@@ -4886,7 +4888,7 @@ copy_vtab_proc_comps (gfc_symbol *declared, gfc_sy
   c->attr.flavor = FL_PROCEDURE;
   c->attr.access = ACCESS_PRIVATE;
   c->attr.external = 1;
-  c->ts.interface = cmp->tb->u.specific->n.sym;
+  c->ts.interface = cmp->ts.interface;
   c->attr.untyped = 1;
   c->attr.if_source = IFSRC_IFBODY;
   c->initializer = gfc_get_expr ();


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |janus at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-12-04 15:57:20 |2009-12-04 19:43:51
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[janus at gcc dot gnu dot org]

--- Comment #6 from janus at gcc dot gnu dot org  2009-12-04 17:06 ---
(In reply to comment #5)
> #3  0x004fa344 in mio_component (c=0x154b880) at
> /home/tob/projects/fortran-dev/gcc/fortran/module.c:2362

The component here is 'is_null', and the parent symbol is
'vtype$psb_d_base_sparse_mat'. In this context, the component 'is_null' refers
to the PPC of the vtype, not the TBP of the original type.

I think the problem is that c->tb->ppc is not set correctly for the PPCs inside
vtype. If one looks at psb_base_mat_mod.mod, one finds:

(55 'is_null'
(LOGICAL 4 0 0 LOGICAL ()) () (PROCEDURE UNKNOWN-INTENT UNKNOWN-PROC
DECL UNKNOWN 0 0 EXTERNAL FUNCTION PROCEDURE PROC_POINTER) PRIVATE (
NULL (UNKNOWN 0 0 0 UNKNOWN ()) 0) 56 (57) (PUBLIC OVERRIDABLE PASS
SPECIFIC NO_PPC 'a' 0 30))

Note the 'NO_PPC'! Although this clearly *is* a PPC, as indicated by
'PROC_POINTER', the tb.ppc attribute is missing.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274

[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault

[burnus at gcc dot gnu dot org]

--- Comment #5 from burnus at gcc dot gnu dot org  2009-12-04 15:57 ---
> (In reply to comment #3)
> Richard is probably right, it should be clearly marked against the branch,

I have now set "Reported against" to 'fortran-dev', marked it in the Subject
line and in 'known to work/fail'

Backtrace:

mio_pointer_ref (gp=0x28) at
/home/tob/projects/fortran-dev/gcc/fortran/module.c:2237
2237  p = get_pointer (*((char **) gp));
(gdb) bt
#0  mio_pointer_ref (gp=0x28) at
/home/tob/projects/fortran-dev/gcc/fortran/module.c:2237
#1  0x004f8da9 in mio_symbol_ref (symp=) at
/home/tob/projects/fortran-dev/gcc/fortran/module.c:2498
#2  0x004f90e9 in mio_typebound_proc (proc=0x154b908) at
/home/tob/projects/fortran-dev/gcc/fortran/module.c:3352
#3  0x004fa344 in mio_component (c=0x154b880) at
/home/tob/projects/fortran-dev/gcc/fortran/module.c:2362


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to fail||fortran-dev
  Known to work||4.5.0
   Last reconfirmed|-00-00 00:00:00 |2009-12-04 15:57:20
   date||
Summary|ICE: segmentation fault |[fortran-dev Regression]
   ||ICE: segmentation fault
Version|unknown |fortran-dev


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274