Bug 46581 - [4.6 Regression] [OOP] segfault in SELECT TYPE with associate-name
Summary: [4.6 Regression] [OOP] segfault in SELECT TYPE with associate-name
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.6.0
: P3 normal
Target Milestone: 4.6.0
Assignee: janus
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-20 16:28 UTC by janus
Modified: 2016-11-16 13:45 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2010-11-21 18:15:45


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description janus 2010-11-20 16:28:01 UTC
Reported by Salvatore at http://gcc.gnu.org/ml/fortran/2010-11/msg00290.html.

Reduced test case:


program bug23
  implicit none

  type :: t1
    integer, allocatable :: ja(:)
  end type

  class(t1), allocatable  :: a 

  allocate(a)

  select type (aa=>a)
  type is (t1)
    write(*,*) 'Allocation status: ',allocated(aa%ja)
  end select

end program bug23


This compiles, but fails at runtime with a segfault.

It was working at r166401 (and r166825?), but fails at r166914. Possibly a regression of r166480.

Note: With 4.5 it fails at runtime with a 'double free' error, after correctly printing "Allocation status:  F".
Comment 1 Dominique d'Humieres 2010-11-20 16:45:08 UTC
> This compiles, but fails at runtime with a segfault.

On x86_64-apple-darwin10 (for both r166533 and r16697) it gives the wrong result:

 Allocation status:  T
Comment 2 janus 2010-11-20 17:04:17 UTC
(In reply to comment #0)
> It was working at r166401 (and r166825?), but fails at r166914. Possibly a
> regression of r166480.

I just checked: It's indeed due to my r166480.
Comment 3 janus 2010-11-21 16:32:23 UTC
(In reply to comment #2)
> I just checked: It's indeed due to my r166480.

Well, at least this commit is the direct cause of the regression, because it changed the names of the temporaries. However, there is nothing wrong with that patch, and I think it rather uncovered a latent bug of Daniel's patch for SELECT TYPE with associate-name:

http://gcc.gnu.org/viewcvs?view=revision&revision=163572

Namely, it does not handle correctly nested ASSOCIATE statements, which is how SELECT TYPE is implemented: There is an outer BLOCK namespace for the whole SELECT TYPE statement, with the selector as associate-name. And then there are inner BLOCK namespaces for each TYPE IS/CLASS IS case with a temporary as associate-name.

Right now all the temporaries (and the selector) are initialized in the outer ns, though they should be initialized in their respective inner ns. So it can happen that by accident the temps get initialized before the selector, which causes the error.

I have a draft patch which fixes this (regtesting now).
Comment 4 janus 2010-11-25 22:05:06 UTC
Author: janus
Date: Thu Nov 25 22:04:59 2010
New Revision: 167154

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167154
Log:
2010-11-25  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/46581
	* trans.h (gfc_process_block_locals): Removed second argument.
	* trans-decl.c (trans_associate_var): Moved to trans-stmt.c.
	(gfc_trans_deferred_vars): Skip ASSOCIATE variables.
	(gfc_process_block_locals): Don't mark associate names to be
	initialized.
	* trans-stmt.c (trans_associate_var): Moved here from trans-decl.c.
	(gfc_trans_block_construct): Call 'trans_associate_var' from here
	to make sure SELECT TYPE with associate-name is treated correctly.

2010-11-25  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/46581
	* gfortran.dg/select_type_19.f03: New.

Added:
    trunk/gcc/testsuite/gfortran.dg/select_type_19.f03
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-decl.c
    trunk/gcc/fortran/trans-stmt.c
    trunk/gcc/fortran/trans.h
    trunk/gcc/testsuite/ChangeLog
Comment 5 janus 2010-11-25 22:07:25 UTC
Fixed with r167154. Closing.