[Bug fortran/70842] New: internal compiler error with character members within a polymorphic pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70842 Bug ID: 70842 Summary: internal compiler error with character members within a polymorphic pointer Product: gcc Version: 5.1.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: nathanael.huebbe at informatik dot uni-hamburg.de Target Milestone: --- There is a problem with character members of derived types when using polymorphic pointers, which triggers an ICE. It seems as if gfortran looses track of the length of `character` members when performing a downcast from a limited polymorphic type. The bug can be reproduced with this little code snippet: $ cat mo_compiler_test.f90 module foo TYPE, ABSTRACT :: t_Intermediate END TYPE t_Intermediate type, extends(t_Intermediate) :: t_Foo character(:), allocatable :: string end type t_Foo contains subroutine bar(me) class(t_Intermediate), target :: me select type(me) type is(t_Foo) print*, len(me%string) end select end subroutine bar end module foo $ gfortran -c -o mo_compiler_test.o mo_compiler_test.f90 f951: internal compiler error: in gfc_add_component_ref, at fortran/class.c:245 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. I have been able to reproduce this bug with gfortran versions 4.9.3, 5.1.0, 5.3.0, up to the current master in the git-svn mirror (commit a80f3f45b016). The bug is not present in versions up to 4.9.2. A git-bisect on the git-svn mirror revealed commit 53ec6b3f003a to be the first bad commit. It is interesting to note that this bug is not triggered when the `select type()` argument is an unlimited polymorphic pointer, even if that unlimited polymorphic pointer is just an alias for a limited polymorphic variable. See the comments in the attached code for details on this.
[Bug fortran/70842] internal compiler error with character members within a polymorphic pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70842 --- Comment #1 from nathanael.huebbe at informatik dot uni-hamburg.de --- Created attachment 38357 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38357&action=edit Code to reproduced the bug the forgotten attachment...
[Bug fortran/70842] [4.9/5/6/7 Regression] internal compiler error with character members within a polymorphic pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70842 --- Comment #3 from nathanael.huebbe at informatik dot uni-hamburg.de --- This is getting even nastier. As it turns out, even though the code I gave above compiles, it does not produce correct results. To be precise, if I use a routine like subroutine bar(me) class(t_Intermediate), pointer, intent(in) :: me class(*), pointer :: meAlias character(len = :), pointer :: textAlias meAlias => me select type(meAlias) type is(t_Foo) textAlias => meAlias%string print*, "'"//textAlias//"', len = ", len(textAlias) !OK print*, "'"//meAlias%string//"', len = ", len(meAlias%string) !string ok, len = nonsense end select end subroutine I get some completely wrong length in the second `print` statement (like `152660480`), even though the string itself is output correctly. Again, the indirection via an additional pointer produces correct results. Another curious fact is, that the large number is constant across objects within a single run, but different when I restart my program. So I'm willing to speculate that somehow the vtable pointer is mistaken for the string length, but that may be completely wrong.
[Bug fortran/65079] New: -Werror= does not work on implicit-procedure warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65079 Bug ID: 65079 Summary: -Werror= does not work on implicit-procedure warning Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: nathanael.huebbe at informatik dot uni-hamburg.de System: Ubuntu Affected gfortran versions: at least 4.7.2 and 4.8.2 Description: Compiling this fortran code module bar implicit none contains subroutine baz() call bim() end subroutine end module program foo use bar call baz() end program with the call $ gfortran -c -Wimplicit-procedure -Werror=implicit-procedure foo.f90 correctly produces the warning, but fails to turn it into an error. The behavior is the same if `-Wimplicit-procedure` is absent, and if `implicit-procedure` is replaced by `-Wimplicit-interface`.
[Bug fortran/70842] [4.9/5/6/7 Regression] internal compiler error with character members within a polymorphic pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70842 --- Comment #6 from nathanael.huebbe at informatik dot uni-hamburg.de --- (In reply to kargl from comment #5) > With the patch I posted earlier today and code in comment #1, I see > > gfc7 -c a.f90 > a.f90:14:30: > > print*, len(me%string) > 1 > Error: Data transfer element at (1) cannot be polymorphic unless it > is processed by a defined input/output procedure > > I don't use CLASS and know little about its expected behavior. > Is the above even remotely right? I don't think so, but I may be wrong since I'm not an expert when it comes to the FORTRAN standard. The error sounds weird to me, because I would not consider `me%string` to be polymorphic to begin with, and because the value that is printed is the result of the `len()` intrinsic, which is just a non-polymorphic `integer`. Even the type of `me` is known precisely at this point since the statement appears within a `type is()` clause. What I would naively expect is that the code * compiles without error or warning (the issue in comment #1), and that it * prints the correct length of the string (the issue in comment #3). (I do hope my expectations are not in conflict with the standard...)
[Bug libfortran/72790] New: MOVE_ALLOC() of character looses content data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72790
Bug ID: 72790
Summary: MOVE_ALLOC() of character looses content data
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: nathanael.huebbe at informatik dot uni-hamburg.de
Target Milestone: ---
Created attachment 39052
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39052&action=edit
Code to reproduced the bug
The following code snippet reproduces the problem:
program move_alloc_test
character(:), allocatable :: srcString, destString
integer, allocatable :: srcArray(:), destArray(:)
srcString = "foo"
call move_alloc(srcString, destString)
write(0,*) "destString = '"//destString//"', &
&allocated(srcString) = ", allocated(srcString), ", &
&allocated(destString) = ", allocated(destString)
srcArray = [1, 2, 3]
call move_alloc(srcArray, destArray)
write(0,*) "destArray = (", destArray, "), &
&allocated(srcArray) = ", allocated(srcArray), ", &
&allocated(destArray) = ", allocated(destArray)
end program
The output of this program, when compiled with either gfortran 4.9.2 or 5.1.0,
shows an empty `destString` after the `move_alloc()` call:
destString = '', allocated(srcString) = F , allocated(destString) = T
destArray = ( 1 2 3 ), allocated(srcArray) =
F , allocated(destArray) = T
The output that I would have expected is this:
destString = 'foo', allocated(srcString) = F , allocated(destString) = T
destArray = ( 1 2 3 ), allocated(srcArray) =
F , allocated(destArray) = T
Note that this loss of data only happens for `character` allocatables, not for
array allocatables.
