[Bug fortran/46339] New: Internal compiler error

[Bug fortran/46339] New: Internal compiler error

[david.sagan at gmail dot com]

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

           Summary: Internal compiler error
           Product: gcc
           Version: 4.5.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: david.sagan@gmail.com


The test program is:


module tao_graph_setup_mod

type coor_struct    
  real :: vec(6)    
end type

type particle_struct
  type (coor_struct) r 
end type

contains

!---------------------------------------------------------

subroutine tao_phase_space_axis (p, axis)

type (particle_struct), optional, target :: p(:)
real, pointer, optional :: axis(:)

axis => p%r%vec(1)

end subroutine tao_phase_space_axis

end module



Running the program gives:

~/bmad/bmad_dist/test> gfortran err.f90
err.f90: In function 'tao_phase_space_axis':
err.f90:15:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

~/bmad/bmad_dist/test> gfortran --version
GNU Fortran (GCC) 4.5.1
Copyright (C) 2010 Free Software Foundation, Inc.

~/bmad/bmad_dist/test> uname -a
Darwin David-Sagans-Mac-mini.local 10.4.0 Darwin Kernel Version 10.4.0: Fri Apr
23 18:28:53 PDT 2010; root:xnu-1504.7.4~1/RELEASE_I386 i386

[Bug fortran/46339] [4.3/4.4/4.5/4.6 Regression] ICE (segfault) in gfc_trans_pointer_assignment

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4
             Status|UNCONFIRMED                 |NEW
      Known to work|                            |4.1.2
           Keywords|                            |ice-on-valid-code
   Last reconfirmed|                            |2010.11.07 08:24:07
                 CC|                            |burnus at gcc dot gnu.org
     Ever Confirmed|0                           |1
            Summary|gfortran internal compiler  |[4.3/4.4/4.5/4.6
                   |error                       |Regression] ICE (segfault)
                   |                            |in
                   |                            |gfc_trans_pointer_assignmen
                   |                            |t
   Target Milestone|---                         |4.4.6
      Known to fail|                            |4.3.4, 4.4.0, 4.5.1

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-11-07 08:24:07 UTC ---
==16250== Invalid read of size 8
==16250==    at 0x56962A: gfc_trans_pointer_assignment (trans-expr.c:4892)
==16250==    by 0x54610D: trans_code (trans.c:1259)
==16250==    by 0x562721: gfc_generate_function_code (trans-decl.c:4651)
==16250==    by 0x546581: gfc_generate_module_code (trans.c:1560)

      else if (expr2->expr_type == EXPR_VARIABLE)
        [...]
              gfc_add_modify (&lse.post, GFC_DECL_SPAN(decl), tmp);

Hereby GFC_DECL_SPAN(decl) == decl->decl_common.lang_specific->span
but decl->decl_common.lang_specific == NULL

[Bug fortran/46339] [4.3/4.4/4.5/4.6 Regression] ICE (segfault) in gfc_trans_pointer_assignment

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jvdelisle at gcc dot
                   |                            |gnu.org

--- Comment #2 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2010-11-13 06:52:45 UTC ---
I am looking at this one.

[Bug fortran/46339] [4.3/4.4/4.5/4.6 Regression] ICE (segfault) in gfc_trans_pointer_assignment

[jvdelisle at gcc dot gnu.org]

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

--- Comment #3 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2010-11-13 07:11:57 UTC ---
This avoids the segfault.  But what is lang_specific and why is it not set in
problem case?  Where does it normally get set?

Index: trans-expr.c
===================================================================
--- trans-expr.c    (revision 166686)
+++ trans-expr.c    (working copy)
@@ -4881,7 +4881,8 @@

       /* If this is a subreference array pointer assignment, use the rhs
          descriptor element size for the lhs span.  */
-      if (expr1->symtree->n.sym->attr.subref_array_pointer)
+      if (expr1->symtree->n.sym->attr.subref_array_pointer
+          && expr1->symtree->n.sym->backend_decl->decl_common.lang_specific)
         {
           decl = expr1->symtree->n.sym->backend_decl;
           gfc_init_se (&rse, NULL);

[Bug fortran/46339] [4.3/4.4/4.5/4.6 Regression] ICE (segfault) in gfc_trans_pointer_assignment

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-11-13 19:01:00 UTC ---
(In reply to comment #3)
> This avoids the segfault.  But what is lang_specific and why is it not set in
> problem case?  Where does it normally get set?

lang_specific allows to attach front-end specific data to a middle-end tree.
The lang-specific part can be obtained by using
  DECL_LANG_SPECIFIC (decl)
thus, your check should rather use
  DECL_LANG_SPECIFIC (expr1->symtree->n.sym->backend_decl)

See trans.h for the access macros for this data. In the given case, one uses
  GFC_DECL_SPAN (decl)
Thus searching for GFC_DECL_SPAN should show all files in which the value
should have been set.

If I recall correctly, it allows for
  pointer => dt(:)%element
which currently cannot be properly represented as on used a sm (stride
multiplier) of sizeof(dt) rather than a stride in bytes, thus a subpointer with
a span has been introduced. But I might also misremember.

Regarding the program:
  axis => p(:)%r%vec(1)
is what I have described. (I have added the "(:)" for clarity.) That's an array
to the the component "r%vec(1)" of all elements of the array "p".

[Bug fortran/46339] [4.3/4.4/4.5/4.6 Regression] ICE (segfault) in gfc_trans_pointer_assignment

[jvdelisle at gcc dot gnu.org]

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

--- Comment #5 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2010-11-14 17:56:30 UTC ---
After getting rid of the segfault, it is clear the runtime results are wrong. 
It does look like the span is not getting set correctly. So I begin to look for
why it is not being set.

[Bug fortran/46339] [4.3/4.4/4.5/4.6 Regression] ICE (segfault) in gfc_trans_pointer_assignment

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pault at gcc dot gnu.org

--- Comment #6 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-11-14 18:13:14 UTC ---
(In reply to comment #5)
> After getting rid of the segfault, it is clear the runtime results are wrong. 
> It does look like the span is not getting set correctly. So I begin to look for
> why it is not being set.

It might be that this is one of those issues which can only be solved with the
new array descriptor - but maybe one can also extend the hack to make it work.

Regarding related bugs, cf. PR 40737 and PR 38471

See also http://gcc.gnu.org/wiki/ArrayDescriptorUpdate

[Bug fortran/46339] [4.3/4.4/4.5/4.6 Regression] ICE (segfault) in gfc_trans_pointer_assignment

[jvdelisle at gcc dot gnu.org]

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

--- Comment #7 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2010-11-14 18:50:30 UTC ---
The code that sets the span is never reached.  I am studying this to see if I
can sort it out.  I think the problem is in trans_decl.c (gfc_get_symbol_decl).

[Bug fortran/46339] [4.3/4.4/4.5/4.6 Regression] ICE (segfault) in gfc_trans_pointer_assignment

[jvdelisle at gcc dot gnu.org]

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

--- Comment #8 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2010-11-15 06:43:24 UTC ---
Created attachment 22394
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22394
A sample runtime case

The sample runtime case.  The pointer is set to the specified element of the
vector which may be i the middle, Then the remaining values of the pointer
array are the elements in array order so it can cross the boundary between two
vectors in the array of vectors.

[Bug fortran/46339] [4.3/4.4/4.5/4.6 Regression] ICE (segfault) in gfc_trans_pointer_assignment

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot       |jvdelisle at gcc dot
                   |gnu.org                     |gnu.org

--- Comment #9 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2010-11-15 06:50:58 UTC ---
Once I understood what I was seeing in the attachment.  The first patch and
this cleaner one, actually works.

Index: trans-expr.c
===================================================================
--- trans-expr.c    (revision 166686)
+++ trans-expr.c    (working copy)
@@ -4881,7 +4881,8 @@ gfc_trans_pointer_assignment (gfc_expr * expr1, gf

       /* If this is a subreference array pointer assignment, use the rhs
          descriptor element size for the lhs span.  */
-      if (expr1->symtree->n.sym->attr.subref_array_pointer)
+      if (expr1->symtree->n.sym->attr.subref_array_pointer
+          && DECL_LANG_SPECIFIC (expr1->symtree->n.sym->backend_decl))
         {
           decl = expr1->symtree->n.sym->backend_decl;
           gfc_init_se (&rse, NULL);

[Bug fortran/46339] [4.3/4.4/4.5/4.6 Regression] ICE (segfault) in gfc_trans_pointer_assignment

[jvdelisle at gcc dot gnu.org]

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

--- Comment #10 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2010-11-15 06:53:50 UTC ---
Created attachment 22395
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22395
An alternate patch that also works

This alternate patch also fixes the problem by initializing the lang_specific
info sooner.  I came up with this one when I though the other was not working.

[Bug fortran/46339] [4.3/4.4/4.5/4.6 Regression] ICE (segfault) in gfc_trans_pointer_assignment

[dominiq at lps dot ens.fr]

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

--- Comment #11 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2010-11-15 10:14:16 UTC ---
The patch in comment #9 fixes this PR along with pr34640 (and its duplicates),
pr39304, pr40737, and pr41627 (probably also duplicates of pr34640) without
regression. The only problem I have found is that the test in
http://gcc.gnu.org/bugzilla/attachment.cgi?id=16885 compiles now, but abort
with

           1           0           2           0
Abort

(note that the result in test_sub2 is OK).

The patch in comment #10 does not work for me (with Paul's patch for
'reallocate on assignment' and Tobias' one for libquad):

[macbook] f90/bug% gfc pr46339.f90
pr46339.f90: In function 'tao_phase_space_axis':
pr46339.f90:20:0: internal compiler error: tree check: expected tree that
contains 'decl common' structure, have 'nop_expr' in gfc_allocate_lang_decl, at
fortran/trans-decl.c:594

This second patch looks very similar to the one in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34640#c5 .

[Bug fortran/46339] [4.3/4.4/4.5/4.6 Regression] ICE (segfault) in gfc_trans_pointer_assignment

[jvdelisle at gcc dot gnu.org]

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

--- Comment #12 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2010-11-16 02:14:06 UTC ---
The test case in http://gcc.gnu.org/bugzilla/attachment.cgi?id=16885 I believe
is wrong.

The structure type(b) has two components, j and c, where c is a single
character not initialized in the test case.  The integer value of c is 0.

The pointer ptr is of type integer and is set to point to the integer component
of the first element of myA.

Because ptr is of type integer, printing returns the integer storage locations.

I will attached a test case that illustrates this a little better.

[Bug fortran/46339] [4.3/4.4/4.5/4.6 Regression] ICE (segfault) in gfc_trans_pointer_assignment

[jvdelisle at gcc dot gnu.org]

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

--- Comment #13 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2010-11-16 03:45:17 UTC ---
Created attachment 22417
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22417
Test case example. what is the correct interpretation?

This attachment shows the point I am trying to describe.  I guess we could see
what other compilers do with this.  With my first patch in this pr, I get the
following results:

$ gfc test2.f90 
$ ./a.out 
 *******************
 myA      =           1 a           2 b           3 c           4 d
 -------------------
 ipn%i%j  =           1          97           2          98
 ipn      =           1          97           2          98
 main ptr =           1          97           2          98
 myA%i%j  =           1           2           3           4
 sorb%i%j =           1           2           3           4
 local_ptr=           1           2           3           4

The specific question is should main ptr give the same result as local_ptr?

[Bug fortran/46339] [4.3/4.4/4.5/4.6 Regression] ICE (segfault) in gfc_trans_pointer_assignment

[jvdelisle at gcc dot gnu.org]

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

--- Comment #14 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2010-11-16 05:42:26 UTC ---
With ifort:

$ ifort test2.f90 
$ ./a.out 
 *******************
 myA      =           1 a           2 b           3 c           4 d
 -------------------
 ipn%i%j  =           1           2           3           4
 ipn      =           1           2           3           4
 main ptr =           1           2           3           4
 myA%i%j  =           1           2           3           4
 sorb%i%j =           1           2           3           4
 local_ptr=           1           2           3           4

[Bug fortran/46339] [4.3/4.4/4.5/4.6 Regression] ICE (segfault) in gfc_trans_pointer_assignment

[jvdelisle at gcc dot gnu.org]

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

--- Comment #15 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2010-11-16 06:42:08 UTC ---
With a slight modification to the patch in Comment #10, gfortran now gives:

@@ -1041,7 +1041,7 @@
 tree
 gfc_get_symbol_decl (gfc_symbol * sym)
 {
-  tree decl;
+  tree decl = NULL;
   tree length = NULL_TREE;
   tree attributes;
   int byref;


$ ./a.out 
 *******************
 myA      =           1 a           2 b           3 c           4 d
 -------------------
 Inside test_sub:
   sorb%i%j =           1           2           3           4
   ipn%i%j  =           1           2           3           4
   ipn      =           1           2           3           4
 Inside main:
        ptr =           1          97           2          98
    myA%i%j =           1           2           3           4
 Inside test_sub2:
   sorb%i%j =           1           2           3           4
  local_ptr =           1           2           3           4

This is much closer. Just need to get the returned pointer right.

Test case is:

module test
  implicit none
  type b
    integer :: j
    character :: c
  end type b
  type a
    type(b), dimension(4) :: i
  end type a
contains
  subroutine test_sub(sorb,ipn)
    type(a), intent(in), target :: sorb
    integer, dimension(:), pointer :: ipn
    ipn=>sorb%i%j
    print *, "Inside test_sub:"
    print *, "  sorb%i%j =", sorb%i%j
    print *, "  ipn%i%j  =", ipn(:)
    print *, "  ipn      =", ipn
  end subroutine test_sub
  subroutine test_sub2(sorb)
    type(a), intent(in), target :: sorb
    integer, dimension(:), pointer :: local_ptr
    local_ptr=>sorb%i%j
    print *, "Inside test_sub2:"
    print *, "  sorb%i%j =", sorb%i%j
    print *, " local_ptr =", local_ptr
    if (any(local_ptr /= (/ 1,2,3,4 /))) call abort()
  end subroutine test_sub2
end module test

program main
  use test
  implicit none
  type(a), target :: myA
  integer, dimension(:), pointer :: ptr
  myA%i(1:4)%j = (/ 1, 2, 3, 4 /)
  myA%i(1:4)%c = (/ 'a', 'b', 'c', 'd' /)
  print *, "*******************"
  print *, "myA      =", myA
  print *, "-------------------"
  call test_sub(myA,ptr)
  print *, "Inside main:"
  print *, "       ptr =", ptr
  print *, "   myA%i%j =", myA%i%j
  !if (any(ptr /= (/ 1,2,3,4 /))) call abort()
  call test_sub2(myA)
end program main

[Bug fortran/46339] [4.3/4.4/4.5/4.6 Regression] ICE (segfault) in gfc_trans_pointer_assignment

[jvdelisle at gcc dot gnu.org]

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

--- Comment #16 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2010-11-16 07:42:34 UTC ---
dump shows:

  ipn->dtype = 265;
  ipn->dim[0].lbound = 1;
  ipn->dim[0].ubound = 4;
  ipn->dim[0].stride = 1;
  ipn->data = (void *) &sorb->i[0].j;
  ipn->offset = -1;
  span.9 = 8;

I think we want ipn->span = 8;

I am not sure how to do this.

[Bug fortran/46339] [4.3/4.4/4.5/4.6 Regression] ICE (segfault) in gfc_trans_pointer_assignment

[burnus at gcc dot gnu.org]

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

--- Comment #17 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-11-16 08:18:12 UTC ---
(In reply to comment #16)
>   ipn->offset = -1;
>   span.9 = 8;
> 
> I think we want ipn->span = 8;

While I am sure that we want to have ipn->span, I am not sure we can. My
understanding is that there is no space left in the array descriptor for
anything - not even for a sm(stride multiplier)/span. Thus, the main
implementation was deferred and an extra 'span' variable was introduced which
often but not always works.

If my understanding is correct, we can either try to extend the 'span' hack to
make it work for more cases - or we defer it to the array descriptor updated
and possibly error out when it is known that the hack does not work.

[Bug fortran/46339] [4.3/4.4/4.5/4.6 Regression] ICE (segfault) in gfc_trans_pointer_assignment

[paul.richard.thomas at gmail dot com]

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

--- Comment #18 from paul.richard.thomas at gmail dot com <paul.richard.thomas at gmail dot com> 2010-11-16 15:04:39 UTC ---
Dear Tobias,


> If my understanding is correct, we can either try to extend the 'span' hack to
> make it work for more cases - or we defer it to the array descriptor updated
> and possibly error out when it is known that the hack does not work.

Your understanding is correct.  The case at point here should be
easily fixed.  It is a question of getting the span right by obtaining
the element size of the array. ie. you need to go through the
references until a REF_ARRAY is found and to take theelement size of
that array.

Passing these beasts to pointer formal arguments is a tad awkward.
The only way that I know to extend the current mechanism is to pass
'span' variable in the same way as character variables; only when the
formal argument is a pointer, however.  This would mean that all dummy
pointers would have to have a 'span' associated with them.

Note that we could do array descriptor reform in two steps; first add
all the extra fields and then, possibly, change the dimension
structure.  I say possibly about the latter because I am not convinced
that it is necessary and my first attempts this summer indicated what
a hard job it will be. We could get an SoC student going on it?

Cheers

Paul

[Bug fortran/46339] [4.3/4.4/4.5/4.6 Regression] ICE (segfault) in gfc_trans_pointer_assignment

[jvdelisle at gcc dot gnu.org]

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

--- Comment #19 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2010-11-19 17:42:12 UTC ---
Another test case to think about. Ifort compiles but gives:

        ptr =
    myA%i%j =           1           2           3           4

gfortran compiles and gives:

$ ./a.out 
Segmentation fault (core dumped)

$ gfc -fbounds-check test3.f90
$ ./a.out 
At line 19 of file test3.f90
Fortran runtime error: Array bound mismatch for dimension 1 of array 'ptr'
(140251380424698/4)

Is there something invalid here?

module test
  implicit none
  type b
    integer :: j
    character :: c
  end type b
  type a
    type(b), dimension(4) :: i
  end type a
end module test

program main
  use test
  implicit none
  type(a), target :: myA
  integer, dimension(:), pointer :: ptr
  myA%i(1:4)%j = (/ 1, 2, 3, 4 /)
  myA%i(1:4)%c = (/ 'a', 'b', 'c', 'd' /)
  ptr = myA%i%j
  print *, "       ptr =", ptr
  print *, "   myA%i%j =", myA%i%j
end program main

[Bug fortran/46339] [4.3/4.4/4.5/4.6 Regression] ICE (segfault) in gfc_trans_pointer_assignment

[david.sagan at gmail dot com]

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

--- Comment #20 from david.sagan at gmail dot com 2010-11-19 20:46:36 UTC ---
(In reply to comment #19)

> Is there something invalid here?
>   ptr = myA%i%j

Yes this is not correct. This line should be:
  ptr => myA%i%j

If you use "gfortran -fcheck=all test.f90" then what you get when you run the
program is:

At line 19 of file test.f90
Fortran runtime error: Array bound mismatch for dimension 1 of array 'ptr'
(140736642904848/4)

[Bug fortran/46339] [4.3/4.4/4.5/4.6 Regression] ICE (segfault) in gfc_trans_pointer_assignment

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #21 from kargl at gcc dot gnu.org 2010-11-19 20:49:31 UTC ---
(In reply to comment #19)

> Is there something invalid here?

Yes.  You need to allocate ptr unless you have
pault's [re-]allocate on assignment patch.

> module test
>   implicit none
>   type b
>     integer :: j
>     character :: c
>   end type b
>   type a
>     type(b), dimension(4) :: i
>   end type a
> end module test
> 
> program main
>   use test
>   implicit none
>   type(a), target :: myA
>   integer, dimension(:), pointer :: ptr
>   myA%i(1:4)%j = (/ 1, 2, 3, 4 /)
>   myA%i(1:4)%c = (/ 'a', 'b', 'c', 'd' /)

    allocate(ptr(size(myA%i)))

>   ptr = myA%i%j
>   print *, "       ptr =", ptr
>   print *, "   myA%i%j =", myA%i%j
> end program main

[Bug fortran/46339] [4.3/4.4/4.5/4.6 Regression] ICE (segfault) in gfc_trans_pointer_assignment

[dominiq at lps dot ens.fr]

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

--- Comment #22 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2010-11-19 21:04:22 UTC ---
> > Is there something invalid here?
>
> Yes.  You need to allocate ptr unless you have
> pault's [re-]allocate on assignment patch.

Even with Paul's patch it does not work.

[Bug fortran/46339] [4.3/4.4/4.5/4.6 Regression] ICE (segfault) in gfc_trans_pointer_assignment

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #24 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2010-11-19 21:32:38 UTC ---
On Fri, Nov 19, 2010 at 09:04:42PM +0000, dominiq at lps dot ens.fr wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46339
> 
> --- Comment #22 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2010-11-19 21:04:22 UTC ---
> > > Is there something invalid here?
> >
> > Yes.  You need to allocate ptr unless you have
> > pault's [re-]allocate on assignment patch.
> 
> Even with Paul's patch it does not work.
> 

Well, in theory, I believe it should work with Paul's patch.
Of course, theory and experience are two different beast. :)

[Bug fortran/46339] [4.3/4.4/4.5/4.6 Regression] ICE (segfault) in gfc_trans_pointer_assignment

[david.sagan at gmail dot com]

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

--- Comment #23 from david.sagan at gmail dot com 2010-11-19 21:24:01 UTC ---
(In reply to comment #22)
> > > Is there something invalid here?
> >
> > Yes.  You need to allocate ptr unless you have
> > pault's [re-]allocate on assignment patch.
> 
> Even with Paul's patch it does not work.

It works for me. The following two variants give the correct result (and this
is without any patching):

program main
 use test
 implicit none
 type(a), target :: myA
 integer, dimension(:), pointer :: ptr
 myA%i(1:4)%j = (/ 1, 2, 3, 4 /)
 myA%i(1:4)%c = (/ 'a', 'b', 'c', 'd' /)
 allocate (ptr(4))
 ptr =  myA%i%j
 print *, "       ptr =", ptr
 print *, "   myA%i%j =", myA%i%j
end program main

program main
 use test
 implicit none
 type(a), target :: myA
 integer, dimension(:), pointer :: ptr
 myA%i(1:4)%j = (/ 1, 2, 3, 4 /)
 myA%i(1:4)%c = (/ 'a', 'b', 'c', 'd' /)
 ptr => myA%i%j
 print *, "       ptr =", ptr
 print *, "   myA%i%j =", myA%i%j
end program main


Both give:
        ptr =           1           2           3           4
    myA%i%j =           1           2           3           4

[Bug fortran/46339] [4.3/4.4/4.5/4.6 Regression] ICE (segfault) in gfc_trans_pointer_assignment

[dominiq at lps dot ens.fr]

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

--- Comment #25 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2010-11-19 21:46:56 UTC ---
> Well, in theory, I believe it should work with Paul's patch.
> Of course, theory and experience are two different beast. :)

When Paul will have commit his final patch, it will be time to open a PR if the
agreement is that this should work and if it does not;-)

[Bug fortran/46339] [4.3/4.4/4.5/4.6 Regression] ICE (segfault) in gfc_trans_pointer_assignment

[pault at gcc dot gnu.org]

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

--- Comment #26 from Paul Thomas <pault at gcc dot gnu.org> 2010-11-21 07:18:04 UTC ---
(In reply to comment #0)
> The test program is:

....snip....

> type (particle_struct), optional, target :: p(:)
> real, pointer, optional :: axis(:)
> 
> axis => p%r%vec(1)
> 
> end subroutine tao_phase_space_axis
> 
> end module

'axis' gets labeled, correctly, as a subref_array_pointer.  The 'span' variable
that is meant to deal with this is generated in
trans-decl.c:gfc_get_symbol_decl at line 1266, onwards. Dummy variables have
already been returned at line 1136, as remarked in the comment at line 1084.
Since 'axis' is a dummy, it means that the 'span' variable will not exist and
this is the cause of the segfault.

Now, we could remedy this directly by adding the 'span' variable to dummies. 
The reason that this was not done is that it cannot be returned to the caller. 
We have a choice here:
(i) Hope that the dummy is returned, pointing to something less complicated
(ie. the span value is the same as the actual argument element size);
(ii) Copy the passing of character lengths; or
(iii) Add the requisite field to the descriptor.

(i)-(ii) Are consistent with being in stage 3. (ii) Would not hit the API
because the segfault is bound to occur otherwise.

This is not a regression because the incorrect result was returned in gcc-4.2
and earlier.

Cheers

Paul

[Bug fortran/46339] ICE (segfault) in gfc_trans_pointer_assignment

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE
            Summary|[4.3/4.4/4.5/4.6            |ICE (segfault) in
                   |Regression] ICE (segfault)  |gfc_trans_pointer_assignmen
                   |in                          |t
                   |gfc_trans_pointer_assignmen |
                   |t                           |

--- Comment #27 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2010-11-25 19:48:03 UTC ---
This bug is not really a regression and is the same bug as 34640. Though we can
get rid of the ICE we still will get wrong code:

Here is a little different test case which compiles with patches above but
gives wring results.

module test
  implicit none
  type b
    integer(kind=2) :: j
    character(kind=1, len=52) :: c
    real(kind=16) :: x
  end type b
  type a
    type(b), dimension(4) :: i
  end type a
contains
  subroutine test_sub(sorb,ipn)
    type(a), intent(in), target :: sorb
    integer(kind=2), dimension(:), pointer :: ipn
    ipn=>sorb%i(2:4)%j
    print *, ipn
  end subroutine test_sub
end module test

program main
  use test
  implicit none
  integer :: stride, ub, lb, span, str
  type(a), target :: myA
  integer(kind=2), dimension(:), pointer :: ptr
  myA%i(1:4)%j = (/ 1, 3, 5, 7 /)
  myA%i(1:4)%c = (/ 'a', 'b', 'c', 'd' /)
  call test_sub(myA,ptr)
  print *, ptr
end program main

*** This bug has been marked as a duplicate of bug 34640 ***