[Bug?] Internal compiler error concerning unlimited polymorphic pointer...

[Andre Vehreschild]

Hi Matthew,

in case no one responded yet: I have analyzed your bug and agree that this is a
compiler bug. Please open a bug-report in bugzilla for it and add this
information:

When translating the pointer assignment in the select type the backend_decl of
the _vptr's component-ref is not initialized (== NULL), leading to the crash
experienced here. I haven't encountered something similar yet, therefore I can
only guess: Something going wrong in the resolve-stage? Other ideas, gfortran
gurus?

Regards,
	Andre

On Mon, 9 Feb 2015 14:29:16 +0000
Matthew Neilson <matt@gneilson.plus.com> wrote:

> Dear all,
> 
> I am receiving an internal compiler error with what I believe should be a
> legitimate piece of code. I decided against filing this directly with
> bugzilla, since the GCC wiki states that it is also acceptable to ask
> questions here on the gfortran mailing list (especially for those who, like
> me, are unfamiliar with using bugzilla).
> 
> I have attached some annotated sample code ('test.f90') that produces the
> error in question. I have minimised the code to the best of my ability,
> whilst retaining my desired code structure. The attached file contains three
> inline modules:
> 
> Module X, which defines types,
> Module Y, which defines common pointers, and
> Module Z, which contains subroutines.
> 
> The compiler seems to have trouble with the subroutine that I've named
> 'BUG' (lines 37-50); more specifically, the compiler appears to be
> complaining about line 48 (which I have labelled line "C"). The 'BUG'
> subroutine calls the subroutine named 'NEXT' to associate the 'e' pointer
> with a piece of preallocated memory, and then points the unlimited
> polymorphic 'e%info' variable to the piece of memory associated with the
> pointer 'p'. Attempting to compile the code as-is produces the following
> output:
> 
> ### Beginning of Terminal output ###
> 
> matt$ gfortran -v -save-temps -o test test.f90 
> Driving: gfortran -mmacosx-version-min=10.10.1 -v -save-temps -o test
> test.f90 -l gfortran -shared-libgcc Using built-in specs.
> COLLECT_GCC=gfortran
> COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin14.0.0/4.9.2/lto-wrapper
> Target: x86_64-apple-darwin14.0.0
> Configured with: ../gcc-4.9-20141029/configure --enable-languages=c++,fortran
> Thread model: posix
> gcc version 4.9.2 20141029 (prerelease) (GCC) 
> COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.10.1' '-v' '-save-temps' '-o'
> 'test' '-shared-libgcc'
> '-mtune=core2' /usr/local/libexec/gcc/x86_64-apple-darwin14.0.0/4.9.2/f951
> test.f90 -fPIC -quiet -dumpbase test.f90 -mmacosx-version-min=10.10.1
> -mtune=core2 -auxbase test -version
> -fintrinsic-modules-path /usr/local/lib/gcc/x86_64-apple-darwin14.0.0/4.9.2/finclude
> -o test.s GNU Fortran (GCC) version 4.9.2 20141029 (prerelease)
> (x86_64-apple-darwin14.0.0) compiled by GNU C version 4.9.2 20141029
> (prerelease), GMP version 6.0.0, MPFR version 3.1.2-p10, MPC version 1.0.2
> GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
> GNU Fortran (GCC) version 4.9.2 20141029 (prerelease)
> (x86_64-apple-darwin14.0.0) compiled by GNU C version 4.9.2 20141029
> (prerelease), GMP version 6.0.0, MPFR version 3.1.2-p10, MPC version 1.0.2
> GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
> test.f90: In function ‘bug’: test.f90:48:0: internal compiler error: in
> gfc_conv_component_ref, at fortran/trans-expr.c:1660 e%info => p      ! line
> "C" ^
> 
> test.f90:48:0: internal compiler error: Abort trap: 6
> gfortran: internal compiler error: Abort trap: 6 (program f951)
> Abort trap: 6
> 
> ### End of Terminal output ###
> 
> Oddly enough, the code compiles without error if I comment-out the call to
> 'NEXT' (line 42, which I've labelled line "A") and uncomment lines 43-45
> (which I've labelled lines "B_1", "B_2", and "B_3"), even though the 'NEXT'
> subroutine contains *exactly* the same content as lines 43-45.
> 
> Am I correct in thinking that this is a bug in the compiler that needs to be
> fixed?
> 
> Best wishes,
> 
> -Matt
> 


-- 
Andre Vehreschild * Email: vehre ad gmx dot de