[Bug fortran/52994] New: internal compiler error: in gfc_trans_assignment_1, at fortran/trans-expr.c:6881

[Bug fortran/52994] New: internal compiler error: in gfc_trans_assignment_1, at fortran/trans-expr.c:6881

[slayoo at staszic dot waw.pl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52994

             Bug #: 52994
           Summary: internal compiler error: in gfc_trans_assignment_1, at
                    fortran/trans-expr.c:6881
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: slayoo@staszic.waw.pl


$ /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

[Bug fortran/52994] internal compiler error: in gfc_trans_assignment_1, at fortran/trans-expr.c:6881

[slayoo at staszic dot waw.pl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52994

--- Comment #1 from Sylwester Arabas <slayoo at staszic dot waw.pl> 2012-04-15 11:40:49 UTC ---
Created attachment 27159
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27159
Fortran source file with minimal example to reproduce the descibed behaviour

[Bug fortran/52994] [OOP] [F08] internal compiler error: in gfc_trans_assignment_1, at fortran/trans-expr.c:6881

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52994

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-04-15
                 CC|                            |janus at gcc dot gnu.org
         Depends on|                            |40054
            Summary|internal compiler error: in |[OOP] [F08] internal
                   |gfc_trans_assignment_1, at  |compiler error: in
                   |fortran/trans-expr.c:6881   |gfc_trans_assignment_1, at
                   |                            |fortran/trans-expr.c:6881
     Ever Confirmed|0                           |1

--- Comment #2 from janus at gcc dot gnu.org 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 :)

[Bug fortran/52994] [OOP] [F08] internal compiler error: in gfc_trans_assignment_1, at fortran/trans-expr.c:6881

[slayoo at staszic dot waw.pl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52994

--- Comment #3 from Sylwester Arabas <slayoo at staszic dot waw.pl> 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

[Bug fortran/52994] [OOP] [F08] internal compiler error: in gfc_trans_assignment_1, at fortran/trans-expr.c:6881

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52994

--- Comment #4 from janus at gcc dot gnu.org 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

[Bug fortran/52994] [OOP] [F08] internal compiler error: in gfc_trans_assignment_1, at fortran/trans-expr.c:6881

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52994

--- Comment #5 from janus at gcc dot gnu.org 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 ;)

[Bug fortran/52994] [OOP] [F08] internal compiler error: in gfc_trans_assignment_1, at fortran/trans-expr.c:6881

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52994

--- Comment #6 from janus at gcc dot gnu.org 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.

[Bug fortran/52994] [OOP] [F08] internal compiler error: in gfc_trans_assignment_1, at fortran/trans-expr.c:6881

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52994

--- Comment #7 from janus at gcc dot gnu.org 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

[Bug fortran/52994] [OOP] [F08] internal compiler error: in gfc_trans_assignment_1, at fortran/trans-expr.c:6881

[slayoo at staszic dot waw.pl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52994

--- Comment #8 from Sylwester Arabas <slayoo at staszic dot waw.pl> 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

[Bug fortran/52994] [OOP] [F08] internal compiler error: in gfc_trans_assignment_1, at fortran/trans-expr.c:6881

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52994

--- Comment #9 from janus at gcc dot gnu.org 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.

[Bug fortran/52994] [OOP] [F08] internal compiler error: in gfc_trans_assignment_1, at fortran/trans-expr.c:6881

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52994

--- Comment #10 from janus at gcc dot gnu.org 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

[Bug fortran/52994] [OOP] [F08] internal compiler error: in gfc_trans_assignment_1, at fortran/trans-expr.c:6881

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52994

--- Comment #11 from janus at gcc dot gnu.org 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)

[Bug fortran/52994] [OOP] [F08] internal compiler error: in gfc_trans_assignment_1, at fortran/trans-expr.c:6881

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52994
Bug 52994 depends on bug 40054, which changed state.

Bug 40054 Summary: [F08] Pointer functions as lvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40054

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

[Bug fortran/52994] [OOP] [F08] internal compiler error: in gfc_trans_assignment_1, at fortran/trans-expr.c:6881

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52994

Paul Thomas <pault at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
                 CC|                            |pault at gcc dot gnu.org

--- Comment #15 from Paul Thomas <pault at gcc dot gnu.org> ---
From as far back as GNU Fortran (GCC) 11.2.1 20210728, the pointer function
assignment gives the correct result arr(-1) = -666.0

Marking it as fixed.

Paul