[Bug fortran/58157] New: ICE on character function with len given by a PURE function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58157 Bug ID: 58157 Summary: ICE on character function with len given by a PURE function Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: dcesari69 at gmail dot com Created attachment 30655 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30655&action=edit Fortran source for reproducing ICE Hello, the attached simplified code contains a module with a CHARACTER function whose results' length is given by another PURE function, which I assume is correct Fortran 95 and I have used succesfully in other contexts. The module compiles well, but as soon as the function is encountered in another piece of code using the module, I get an ICE (+segfault): [davide@localhost ~]$ rm -f *.mod; LANG= gfortran -c icetest.f90 icetest.f90: In function 'icetest': icetest.f90:34:0: internal compiler error: Segmentation fault tkey = strtofchar_chararr(key) ! ICE here!!! ^ Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. It reminds somehow bug 55287: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55827, but that one is fixed in 4.9, while this remains. Same bug with older versions of gfortran. This is my first bug submission to gcc, so please forgive any procedural mistake. Thank you for your work, Davide
[Bug fortran/78021] New: Wrong result with optimization, character constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78021
Bug ID: 78021
Summary: Wrong result with optimization, character constant
Product: gcc
Version: 6.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: dcesari69 at gmail dot com
Target Milestone: ---
The following simple code:
PROGRAM test_o_char
PRINT*,mylen('c')+mylen('c ')
CONTAINS
FUNCTION mylen(c)
CHARACTER(len=*),INTENT(in) :: c
INTEGER :: mylen
mylen=LEN(c)
END FUNCTION mylen
END PROGRAM test_o_char
gives a wrong result (8 instead of 5) when compiled with -O1 or higher. It is
evident that a static optimisation does not take into account blank padding of
character constants and considers the two calls to mylen() equivalent.
GNU Fortran (GCC) 6.2.1 20160916 (Red Hat 6.2.1-2)
Copyright (C) 2016 Free Software Foundation, Inc.
[Bug fortran/78021] [5/6/7 Regression] Wrong result with optimization on character constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78021 --- Comment #8 from Davide Cesari --- Thanks for the quick fix!
[Bug fortran/58157] ICE on character function with len given by a PURE function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58157 --- Comment #3 from Davide Cesari --- Update: I tested with the latest version available on a fresh Fedora24, gcc version 6.1.1 20160621, and the bug is still the same: internal compiler error: Segmentation fault Davide
[Bug fortran/111521] New: Polymorphic variable loses information about the actual type assigned when passed as function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111521 Bug ID: 111521 Summary: Polymorphic variable loses information about the actual type assigned when passed as function result Product: gcc Version: 13.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: dcesari69 at gmail dot com Target Milestone: --- Created attachment 55961 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55961&action=edit Program showing the described behavior Hello, the attached program shows an anomalous behavior since gcc-gfortran version 13, in the previous gfortran versions it worked as expected. gcc version: GNU Fortran (GCC) 13.2.1 20230728 (Red Hat 13.2.1-1) Copyright (C) 2023 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. OS (Fedora 38): Linux trentotto 6.3.8-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Jun 15 02:15:40 UTC 2023 x86_64 GNU/Linux Build command line: gfortran -g -fcheck=all -o testpoli testpoli.f90 Actual program stdout: 1.integer 1.integer 2.unknown type 3.unknown type 8 -1 Expected program stdout (e.g. when compiled with gfortran 12.2.1): 1.integer 2.integer 3.integer 8 8 Description: The unlimited polymorphic derived type member %val is initialised with an integer, but when passed back as a result of a chain of functions, it loses its type. Additionally, the debugging print show that the function link_getval is apparently executed twice, while it is called only once. By executing the commented line `v => this%curr%getval()` instead of `v => this%getcurr()` the program gives the expected result with version 13, however the original code was obviously more complex and this chained function call was necessary. The bug could be somehow related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110415 also appearing in version 13.
[Bug fortran/111521] Polymorphic variable loses information about the actual type assigned when passed as function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111521 --- Comment #1 from Davide Cesari --- An update: By replacing the line list_getcurr => this%curr%getval() with CLASS(*),POINTER :: l_p l_p => this%curr%getval() list_getcurr => l_p i.e. assigning the upper function result to a temporary local pointer and setting the current function result to that pointer gives the correct result.
[Bug fortran/114781] New: Error in ALLOCATE with MOLD=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114781 Bug ID: 114781 Summary: Error in ALLOCATE with MOLD= Product: gcc Version: 13.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: dcesari69 at gmail dot com Target Milestone: --- Created attachment 57990 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57990&action=edit Failing program Allocation af an unlimited polymorphic array with MOLD= after a MOVE_ALLOC fails with an unrealistic allocation size. With slight modifications to the code the error disappears (see comments in the code itself). The code is attached. The distribution is a Fedora 38. # gfortran -g -o mold_test mold_test.f90 # ./mold_test In file 'mold_test.f90', around line 13: Error allocating 1118068033978368 bytes: Cannot allocate memory Error termination. Backtrace: #0 0x7f1c5dc23872 in ??? #1 0x7f1c5dc24379 in ??? #2 0x7f1c5dc246bf in ??? #3 0x401669 in __mold_test_mo_MOD_aalloc at /home/dces...@arpa.emr.net/mold_test.f90:12 #4 0x40195b in mold_test at /home/dces...@arpa.emr.net/mold_test.f90:25 #5 0x401992 in main at /home/dces...@arpa.emr.net/mold_test.f90:23 # gfortran --version GNU Fortran (GCC) 13.2.1 20240316 (Red Hat 13.2.1-7) Copyright (C) 2023 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
