Bug 52994 - [OOP] [F08] internal compiler error: in gfc_trans_assignment_1, at fortran/trans-expr.c:6881
Summary: [OOP] [F08] internal compiler error: in gfc_trans_assignment_1, at fortran/tr...
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.8.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on: 40054
Blocks: 39627
  Show dependency treegraph
 
Reported: 2012-04-15 11:39 UTC by Sylwester Arabas
Modified: 2012-04-16 09:11 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2012-04-15 00:00:00


Attachments
Fortran source file with minimal example to reproduce the descibed behaviour (495 bytes, text/x-fortran)
2012-04-15 11:40 UTC, Sylwester Arabas
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sylwester Arabas 2012-04-15 11:39:49 UTC
$ /usr/lib/gcc-snapshot/bin/gfortran -std=f2008 -ffree-form test.f
test.f: In function 'test':
test.f:43:0: internal compiler error: in gfc_trans_assignment_1, at fortran/trans-expr.c:6881
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-snapshot/README.Bugs> for instructions.

$ /usr/lib/gcc-snapshot/bin/gfortran --version
GNU Fortran (Debian 20120407-1) 4.8.0 20120407 (experimental) [trunk revision 186212]

Hope that helps,
Sylwester
Comment 1 Sylwester Arabas 2012-04-15 11:40:49 UTC
Created attachment 27159 [details]
Fortran source file with minimal example to reproduce the descibed behaviour
Comment 2 janus 2012-04-15 18:46:39 UTC
ICE Confirmed with 4.6, 4.7 and trunk.

I think the test case is invalid in F03, but should be valid in F08: It makes use of pointer functions as lvalue, which is PR40054.

However, it does not just use a 'plain' pointer function, but even a pointer-valued (and dimensionful) type-bound procedure. Phew. Thanks for the nice test case :)
Comment 3 Sylwester Arabas 2012-04-15 19:28:22 UTC
> pointer-valued (and dimensionful) type-bound procedure. Phew. 
> Thanks for the nice test case :)

That's what I've got trying to reimplement quite verbosely a piece of C++ code in Fortran :)
Sylwester
Comment 4 janus 2012-04-15 19:32:22 UTC
Just out of curiosity: Are you aware of any compiler which swallows this?


Here is a slightly reduced test case, which gives the same ICE:

module adv
  implicit none

  type adv_t
  contains
    procedure, nopass :: left_halo
  end type 

contains

  function left_halo (arr)
    real, intent(in), dimension(:), pointer :: arr
    real, dimension(:), pointer :: left_halo
    left_halo => arr(-1:-1)
  end function

end module

program test
  use adv
  implicit none

  real, dimension(:), pointer :: arr
  class(adv_t), allocatable :: a

  allocate(adv_t::a)
  allocate(arr(-1:5))

  arr(-1) = 666
  print*, a%left_halo(arr)

  a%left_halo(arr) = -666  ! ICE

end program
Comment 5 janus 2012-04-15 19:37:13 UTC
(In reply to comment #3)
> That's what I've got trying to reimplement quite verbosely a piece of C++ code
> in Fortran :)

That seems like a rare intention. There are certainly more people doing it the other way around ;)
Comment 6 janus 2012-04-15 19:40:58 UTC
(In reply to comment #4)
> Here is a slightly reduced test case, which gives the same ICE:

Note #1: When commenting out the 'ICE' line, compilation goes through and running the program yields the output:

   666.000000

I.e. it prints only one number, where it actually should print three.
Comment 7 janus 2012-04-15 19:43:22 UTC
(In reply to comment #4)
> Here is a slightly reduced test case, which gives the same ICE:

Note #2: When changing "class(adv_t)" into "type(adv_t)", one gets:

  a%left_halo(arr) = -666
  1
Error: 'left_halo' at (1) is not a VALUE
Comment 8 Sylwester Arabas 2012-04-15 20:23:18 UTC
> Just out of curiosity: Are you aware of any compiler which swallows this?

No. I've just tried it with PGI (pgf95) but it chokes on "contains" "within a
derived type definition".

>> That's what I've got trying to reimplement quite verbosely a piece of C++ code
>> in Fortran :)
>
> That seems like a rare intention. There are certainly more people doing 
> it the other way around ;)

Indeed, but there're also lots of people (around me) dead sure of Fortran being
faster than anything :)

> I.e. it prints only one number, where it actually should print three.

Isn't arr(-1:-1) meaning a[-1], i.e. just one element? 

Sylwester
Comment 9 janus 2012-04-15 20:41:27 UTC
(In reply to comment #8)
> > Just out of curiosity: Are you aware of any compiler which swallows this?
> 
> No. I've just tried it with PGI (pgf95) but it chokes on "contains" "within a
> derived type definition".

That was probably an older version. I'm pretty sure the more recent versions of PGI at least support type-bound procedures.



> > I.e. it prints only one number, where it actually should print three.
> 
> Isn't arr(-1:-1) meaning a[-1], i.e. just one element? 

Ah, yes. I somehow misread it as arr(-1:1). Sorry for the false alarm.
Comment 10 janus 2012-04-16 09:04:51 UTC
(In reply to comment #9)
> (In reply to comment #8)
> > > Just out of curiosity: Are you aware of any compiler which swallows this?
> > 
> > No. I've just tried it with PGI (pgf95) but it chokes on "contains" "within a
> > derived type definition".
> 
> That was probably an older version. I'm pretty sure the more recent versions of
> PGI at least support type-bound procedures.

I just tried ifort 12.1.1.256 and PGI 11.9 on comment #4, and both reject it:


ifort pr52994.f90 
pr52994.f90(32): error #6515: This function, which is specified as the left side of an assignment statement, is invalid.   [LEFT_HALO]
  a%left_halo(arr) = -666  ! ICE
----^


pgf95 pr52994.f90 
PGF90-S-0072-Assignment operation illegal to external procedure left_halo9 (pr52994.f90: 32)
  0 inform,   0 warnings,   1 severes, 0 fatal for test
Comment 11 janus 2012-04-16 09:11:07 UTC
Note that at gfortran correctly rejects the test case with -std=f2003:

  a%left_halo(arr) = -666  ! ICE
  1
Error: Fortran 2008: Pointer functions in variable definition context (assignment) at (1)