Bug 46971 - [4.6 Regression] [OOP] ICE on long class names
Summary: [4.6 Regression] [OOP] ICE on long class names
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.6.0
: P3 normal
Target Milestone: ---
Assignee: janus
URL:
Keywords: ice-on-valid-code
Depends on:
Blocks:
 
Reported: 2010-12-15 20:59 UTC by Thomas Koenig
Modified: 2010-12-31 10:18 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2010-12-30 13:40:20


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Koenig 2010-12-15 20:59:43 UTC
Reported by Andrew Benson on

http://gcc.gnu.org/ml/fortran/2010-12/msg00100.html

module Molecular_Abundances_Structure
  public
  
  type molecularAbundancesStructure
     double precision, allocatable, dimension(:) :: molecularValue
  end type molecularAbundancesStructure

contains

  double precision function Molecules_Abundances(molecules)
    implicit none

    class(molecularAbundancesStructure), intent(in) :: molecules

    return
  end function Molecules_Abundances

end module Molecular_Abundances_Structure

Looking at gfc_new_symbol:

Breakpoint 1, gfc_new_symbol (
    name=0x7fffffffd5f0 "__class_molecular_abundances_structure_molecularabundancesstructure",
    ns=0x148b420) at ../../trunk/gcc/fortran/symbol.c:2551
2551        gfc_internal_error ("new_symbol(): Symbol name too long");
(gdb) p name
$1 = 0x7fffffffd5f0 "__class_molecular_abundances_structure_molecularabundancesstructure"

... which, because we put _class_ before the name, is longer than the
maximum symbol size GFC_MAX_SYMBOL_LEN.
Comment 1 Dominique d'Humieres 2010-12-15 21:45:06 UTC
Confirmed (on x86_64-apple-darwin10.5.0 the compilation hangs). The test passes if I remove four characters to both Molecular_Abundances_Structure and molecularAbundancesStructure.
Comment 2 Tobias Burnus 2010-12-15 21:55:17 UTC
Isn't this a duplicate of PR 46313?
Comment 3 Dominique d'Humieres 2010-12-15 22:16:51 UTC
> Isn't this a duplicate of PR 46313?

I won't say so, but it is an instance of your fears in the comment #15 of PR 46313;-)
Comment 4 janus 2010-12-30 13:40:20 UTC
This is a 4.6 regression. Here is a more compactified version of the test case:

module Molecular_Abundances_Structure
  type molecularAbundancesStructure
  end type
  class(molecularAbundancesStructure), pointer :: molecules
end module


It can be fixed by using hashed strings for the vtab names, as proposed by Tobias in PR46313. I'm working on a patch ...
Comment 5 janus 2010-12-31 10:08:22 UTC
Author: janus
Date: Fri Dec 31 10:08:17 2010
New Revision: 168363

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

	PR fortran/46971
	* gfortran.h (gfc_hash_value): Add prototype.
	* class.c (get_unique_type_string): Check if proc_name is present and
	make sure string contains an underscore.
	(get_unique_hashed_string): New function which creates a hashed string
	if the given unique string is too long.
	(gfc_hash_value): Moved here from decl.c, renamed and simplified.
	(gfc_build_class_symbol, gfc_find_derived_vtab): Use hashed strings.
	* decl.c (hash_value): Moved to class.c.
	(gfc_match_derived_decl): Renamed 'hash_value'.


2010-12-31  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/46971
	* gfortran.dg/class_33.f90: New.

Added:
    trunk/gcc/testsuite/gfortran.dg/class_33.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/class.c
    trunk/gcc/fortran/decl.c
    trunk/gcc/fortran/gfortran.h
    trunk/gcc/testsuite/ChangeLog
Comment 6 janus 2010-12-31 10:18:00 UTC
Fixed with r168363. Closing.

Thanks to Andrew for reporting this!