GCC Bugzilla will be upgraded from version 4.4.9 to 5.0rc3 on Saturday, April 25, starting around 17:00 UTC. The upgrade process should only last a few minutes. Check bug 64968 for details.
Bug 43895 - [OOP] internal compiler error: verify_ssa failed
[OOP] internal compiler error: verify_ssa failed
Status: RESOLVED FIXED
Product: gcc
Classification: Unclassified
Component: fortran
fortran-dev
: P3 normal
: ---
Assigned To: Paul Thomas
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-04-26 14:32 UTC by Salvatore Filippone
Modified: 2010-06-06 03:17 UTC (History)
3 users (show)

See Also:
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu
Known to work:
Known to fail:
Last reconfirmed: 2010-06-05 10:40:32


Attachments
test-case (532 bytes, text/plain)
2010-04-26 14:34 UTC, Salvatore Filippone
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Salvatore Filippone 2010-04-26 14:32:14 UTC
The attached code produces the subject message, but only with optimization; at -O0 it works. 
------ behaviour ----------
[sfilippo@localhost bug14]$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/local/gnudev/bin/../libexec/gcc/i686-pc-linux-gnu/4.6.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../fortran-dev/configure --prefix=/usr/local/gnudev --enable-languages=c,c++,fortran : (reconfigured) ../fortran-dev/configure --prefix=/usr/local/gnudev --enable-languages=c,c++,fortran,lto --no-create --no-recursion : (reconfigured) ../fortran-dev/configure --prefix=/usr/local/gnudev --enable-languages=c,c++,fortran,lto --no-create --no-recursion : (reconfigured) ../fortran-dev/configure --prefix=/usr/local/gnudev --enable-languages=c,c++,fortran,lto --no-create --no-recursion : (reconfigured) ../fortran-dev/configure --prefix=/usr/local/gnudev --enable-languages=c,c++,fortran,lto --no-create --no-recursion : (reconfigured) ../fortran-dev/configure --prefix=/usr/local/gnudev --enable-languages=c,c++,fortran,lto --no-create --no-recursion : (reconfigured) ../fortran-dev/configure --prefix=/usr/local/gnudev --enable-languages=c,c++,fortran,lto --no-create --no-recursion
Thread model: posix
gcc version 4.6.0 20100421 (experimental) (GCC) 
[sfilippo@localhost bug14]$ gfortran  -O1  -c bug14.f90
bug14.f90: In function ‘bug14’:
bug14.f90:30:0: error: statement makes a memory store, but has no VDEFS
a_4.a.$data = 0B;
bug14.f90:30:0: internal compiler error: verify_ssa failed
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
[sfilippo@localhost bug14]$ gfortran  -O0  -c bug14.f90
[sfilippo@localhost bug14]$
Comment 1 Salvatore Filippone 2010-04-26 14:34:00 UTC
Created attachment 20491 [details]
test-case

Funny thing: if I change the declaration 
type(d_sparse_mat)  
into 
class(d_sparse_mat)
then it compiles.
Comment 2 Richard Biener 2010-04-26 14:38:23 UTC
smells like DECL_VALUE_EXPR
Comment 3 janus 2010-04-26 14:56:10 UTC
Note: There is another OOP PR which fails only with optimization: PR41753.
Comment 4 janus 2010-04-26 15:04:01 UTC
Confirmed.

It seems this fails already with the 4.5 release as well as with current trunk, which means that it's not specific to the fortran-dev branch.
Comment 5 Salvatore Filippone 2010-04-26 15:32:58 UTC
(In reply to comment #0)
> The attached code produces the subject message, but only with optimization; at
> -O0 it works. 
> ------ behaviour ----------
> [sfilippo@localhost bug14]$ gfortran  -O1  -c bug14.f90
> bug14.f90: In function ‘bug14’:
> bug14.f90:30:0: error: statement makes a memory store, but has no VDEFS
> a_4.a.$data = 0B;
> bug14.f90:30:0: internal compiler error: verify_ssa failed
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <http://gcc.gnu.org/bugs.html> for instructions.
>

Fails at -O2 and -O3 as well.. 
Comment 6 Tobias Burnus 2010-05-06 16:28:10 UTC
See also PR 43990 - I think the PRs might be related, though I have not really studied this PR.
Comment 7 Tobias Burnus 2010-05-17 20:22:22 UTC
Propagate comment from PR 43990:

There seems to be an inconsistency with CLASS with POINTER
or ALLOCATABLE attribute: Is "class.$DATA" or "class" the pointer variable. If
one adds "b = ALLOCATED(x)" one finds:

  x.a.$data = 0B;   ! Default initialization sets class.$data to NULL
  D.1577 = &x->a;   ! ALLOCATED check looks at "(class != NULL)"
  b = D.1577 != 0B;

Which does not make sense.  [This might be unrelated to the ICE.]
Comment 8 janus 2010-05-17 20:35:00 UTC
(In reply to comment #7)
> If one adds "b = ALLOCATED(x)" one finds:

Where do you add this? I don't see a test case where this fits into. Can you give a complete example?

Btw, after the recent patch for PR43969, this might well be fixed already ...
Comment 9 Salvatore Filippone 2010-05-18 10:41:24 UTC
(In reply to comment #8)
> (In reply to comment #7)

> 
> Btw, after the recent patch for PR43969, this might well be fixed already ...
> 
Unfortunately, no, I still get the ICE.

Comment 10 janus 2010-05-18 12:19:43 UTC
(In reply to comment #9)
> > Btw, after the recent patch for PR43969, this might well be fixed already ...
> > 
> Unfortunately, no, I still get the ICE.

Sure. Actually my comment was only targeted towards Tobias' ALLOCATED example, not the original ICE :)
Comment 11 Tobias Burnus 2010-05-18 12:24:46 UTC
(In reply to comment #8)
> > If one adds "b = ALLOCATED(x)" one finds:
> Where do you add this?

Add in bug14 of attachment 20491 [details] before 'end subroutine':
  logical b
  b = allocated(a%a)

However, this is now fixed.

 * * *

There are other problems related to allocatable scalars, but I think those are tracked in PR 42647. For instance (again based on attachment 20491 [details]):

  use d_mat_mod
  implicit none
  type(d_sparse_mat), ALLOCATABLE :: x
  call bug14(x) ! << OK around here
contains
subroutine bug14(a)
  type(d_sparse_mat), ALLOCATABLE, intent(out) :: a
  logical b
  ! <<< ICE here
  b = allocated(a); if (b) call abort() ! << OK here
end subroutine bug14
end
Comment 12 Paul Thomas 2010-06-05 10:40:32 UTC
(In reply to comment #11)
OK, all this has a simple explanation.  A revamped version of the original testcase segfaults in runtime, at -O0.

! { dg-do compile }
! Test the fix for PR43895, in which the dummy 'a' was not
! dereferenced for the deallocation of component 'a', as required
! for INTENT(OUT).
!
! Contributed by Salvatore Filippone <sfilippone@uniroma2.it>
!
module d_mat_mod
  type  :: base_sparse_mat
  end type base_sparse_mat

  type, extends(base_sparse_mat) :: d_base_sparse_mat
    integer :: i
  end type d_base_sparse_mat

  type :: d_sparse_mat
    class(d_base_sparse_mat), allocatable  :: a 
  end type d_sparse_mat
end module d_mat_mod

  use d_mat_mod
  type(d_sparse_mat) :: b
  allocate (b%a)
  b%a%i = 42
  call bug14 (b)
  if (allocated (b%a)) call abort
contains
  subroutine bug14(a)
    implicit none
    type(d_sparse_mat), intent(out) :: a
  end subroutine bug14
end
! { dg-final { cleanup-modules "d_mat_mod " } }

The reason is quite clear from the code below:

bug14 (struct d_sparse_mat & restrict a)
{
  if (a.a.$data != 0B)
    {
      __builtin_free ((void *) a.a.$data);
    }
  a.a.$data = 0B;
}

The dummy 'a' needs dereferencing, thus...

bug14 (struct d_sparse_mat & restrict a)
{
  if (a->a.$data != 0B)
    {
      __builtin_free ((void *) a->a.$data);
    }
  a->a.$data = 0B;
}

This patch is regtesting right now:

Index: /svn/trunk/gcc/fortran/trans-array.c
===================================================================
*** /svn/trunk/gcc/fortran/trans-array.c	(revision 159851)
--- /svn/trunk/gcc/fortran/trans-array.c	(working copy)
*************** structure_alloc_comps (gfc_symbol * der_
*** 5951,5957 ****
  
    gfc_init_block (&fnblock);
  
!   if (POINTER_TYPE_P (TREE_TYPE (decl)) && rank != 0)
      decl = build_fold_indirect_ref_loc (input_location,
  				    decl);
  
--- 5951,5958 ----
  
    gfc_init_block (&fnblock);
  
!   if ((POINTER_TYPE_P (TREE_TYPE (decl)) && rank != 0)
! 	|| (TREE_CODE (TREE_TYPE (decl)) == REFERENCE_TYPE && rank == 0))
      decl = build_fold_indirect_ref_loc (input_location,
  				    decl);

Cheers

Paul
Comment 13 Paul Thomas 2010-06-05 14:08:18 UTC
(In reply to comment #12)

This is tiresome - it regtested fine, I update the tree and now I get failures on:
alloc_comp_result_1.f90
alloc_comp_scalar_1.f90
alloc_comp_transformational_1.f90

All three segfault at runtime.  Happily, if I revert the above patch, they still segfault.

Paul
Comment 14 Paul Thomas 2010-06-05 17:51:53 UTC
Subject: Bug 43895

Author: pault
Date: Sat Jun  5 17:51:39 2010
New Revision: 160326

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160326
Log:
2010-06-05  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/43895
	* trans-array.c (structure_alloc_comps): Dereference scalar
	'decl' if it is a REFERENCE_TYPE. Tidy expressions containing
	TREE_TYPE (decl).

2010-06-05  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/43895
	* gfortran.dg/alloc_comp_class_1.f90 : New test.


Added:
    trunk/gcc/testsuite/gfortran.dg/alloc_comp_class_1.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-array.c
    trunk/gcc/testsuite/ChangeLog

Comment 15 janus 2010-06-06 03:17:18 UTC
I guess we can close this, right?