[Bug other/35014] Libgfortran.a (downloaded) is not PIC compiled...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35014 --- Comment #16 from Amir Shahmoradi --- A new optional flag could be a viable (and in my opinion, very good) solution. Unfortunately, I do not have the expertise and experience with gfortran internals to propose and implement a patch for such an option.
[Bug other/35014] Libgfortran.a (downloaded) is not PIC compiled...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35014 --- Comment #14 from Amir Shahmoradi --- It's not a bug but a popular requested feature. See, for example, the discussion here: https://fortran-lang.discourse.group/t/distribute-shared-libraries-or-not/7532/1 Are there any downsides to distributing PIC-enabled `libgfortran.a` on all platforms? For consistency, if this is the default behavior on macOS, it should be the default on all platforms.
[Bug fortran/105117] New: automatic deallocation of objects in procedures with heap arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105117 Bug ID: 105117 Summary: automatic deallocation of objects in procedures with heap arrays Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: a.shahmoradi at gmail dot com Target Milestone: --- The following code yields a runtime error when compiled with heap arrays option `gfortran -fmax-stack-var-size=10 main.f90 -o`, ``` call testAutoDealloc call testAutoDealloc contains subroutine testAutoDealloc real, allocatable :: temp(:) allocate(temp(200)) !deallocate(temp) end end ``` The problem is that `temp` is not automatically deallocated when the program returns the control to the main scoping unit. To the best of my knowledge, this appears to be a bug. Allocatable should be automatically deallocated when it is out of scope, regardless of heap vs. stack usage. Intel ifort has no issues with it. The code can be tested here: https://godbolt.org/z/9z48Tze8c
[Bug fortran/104908] New: gfortran 11/trunk regression: incorrect Fortran out-of-bound runtime error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104908 Bug ID: 104908 Summary: gfortran 11/trunk regression: incorrect Fortran out-of-bound runtime error. Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: a.shahmoradi at gmail dot com Target Milestone: --- The following code appears to be standard-conforming, but gfortran throws a runtime error with the flag `-check=bounds`, ``` program test type vec integer :: x(3) end type type(vec) :: v(2) call sub(v) contains subroutine sub (v) class(vec), intent(in) :: v(:) integer :: k, q(3) q = [ (v(1)%x(k), k = 1, 3) ] ! <-- fails here end subroutine end program ``` Here is the error message, ``` At line 19 of file /app/example.f90 Fortran runtime error: Index '3' of dimension 1 of array 'v%_data%x' above upper bound of 2 ``` This is a gfortran-11 regression since the code is functional with gfortran-10 with the same compile flags. It can be tested here with different versions of gfortran: https://godbolt.org/z/K6chcYE5e This issue was raised in a StackOverflow question: https://stackoverflow.com/questions/71441100/class-dummy-argument-for-array-of-custom-types-stuck-on-fcheck-bounds I am only reporting it to the GNU Bugzilla.
[Bug fortran/104900] New: segfault with parameterized derived type with kind parameter and allocatable component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104900 Bug ID: 104900 Summary: segfault with parameterized derived type with kind parameter and allocatable component Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: a.shahmoradi at gmail dot com Target Milestone: --- Created attachment 52617 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52617=edit sample source code The attached file contains a is a valid Fortran standard program with parameterized derived types with kind type parameter (no len parameter) and an allocatable component. However, gfortran yields a runtime segfault with this code, ``` use, intrinsic :: iso_fortran_env!, only: real64, int64 integer, parameter :: RK1 = real_kinds(1) integer, parameter :: RK2 = real_kinds(2) type :: Container_type(RK) integer, kind :: RK = RK1 real(RK), allocatable :: value(:) end type type(Container_type(RK1)), allocatable :: List(:) interface wrap procedure :: wrap_RK1, wrap_RK2 end interface List = wrap([1.,2.,3.,4.,5.,6.]) print *, List(1)%value print *, List(2)%value contains function wrap_RK1(array) result(List) real(RK1), intent(in) :: array(:) type(Container_type(RK1)), allocatable :: List(:) allocate(List(2)) List(1)%value = array(1:size(array)/2) List(2)%value = array(size(array)/2 + 1 : size(array)) end function function wrap_RK2(array) result(List) real(RK2), intent(in) :: array(:) type(Container_type(RK2)), allocatable :: List(:) allocate(List(2)) List(1)%value = array(1:size(array)/2) List(2)%value = array(size(array)/2 + 1 : size(array)) end function end ``` Here is the error message, ``` Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x7f1e57dcc8d2 in ??? #1 0x7f1e57dcba65 in ??? #2 0x7f1e57a430bf in ??? #3 0x401927 in wrap_rk1 at /app/example.f90:27 #4 0x4012f4 in MAIN__ at /app/example.f90:17 #5 0x401bfc in main at /app/example.f90:19 ``` There segfault happen where the automatic allocation of the `value` component occurs in the procedures. Here is an online test: https://godbolt.org/z/8n5fs44sa
[Bug fortran/104811] maxloc/minloc cannot accept character arguments without `dim` optional argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104811 --- Comment #5 from Amir Shahmoradi --- (In reply to Thomas Koenig from comment #4) > (In reply to anlauf from comment #2) > > (In reply to kargl from comment #1) > > > Compiles and executes without optimization or if -fno-frontend-optimize is > > > used with optimization. > > > > Good observation. > > > > The inline expansion that may be helpful for integer and real arguments > > will not even be done in trans-intrinsic.cc, as the following comment > > explains: > > > > /* Special case for character maxloc. Remove unneeded actual > > arguments, then call a library function. */ > > > > The obvious solution is to punt on character array arguments: > > > > diff --git a/gcc/fortran/frontend-passes.cc b/gcc/fortran/frontend-passes.cc > > index 4033f27df99..5eba6345145 100644 > > --- a/gcc/fortran/frontend-passes.cc > > +++ b/gcc/fortran/frontend-passes.cc > > @@ -2276,6 +2276,7 @@ optimize_minmaxloc (gfc_expr **e) > >if (fn->rank != 1 > >|| fn->value.function.actual == NULL > >|| fn->value.function.actual->expr == NULL > > + || fn->value.function.actual->expr->ts.type == BT_CHARACTER > >|| fn->value.function.actual->expr->rank != 1) > > return; > > Thanks for analyzing this before I ever got a round tuit. > > Patch is pre-approved or obvious, take your pick :-) Thank you for your prompt action and fix. Glad to hear both "pre-approved" and "obvious".
[Bug fortran/104811] New: maxloc/minloc cannot accept character arguments without `dim` optional argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104811 Bug ID: 104811 Summary: maxloc/minloc cannot accept character arguments without `dim` optional argument. Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: a.shahmoradi at gmail dot com Target Milestone: --- The following code appears to be standard-conforming. ``` character(1) :: str(3) str = ["a", "c", "a"] print *, maxloc(str) ! requires dim = 1 argument to function. print *, minloc(str) ! requires dim = 1 argument to function. end ``` However, gfortran 11 or newer versions generate code that crashes with a segfault error at runtime, ``` Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x7faba0a82642 in ??? #1 0x7faba0a81815 in ??? #2 0x7faba070020f in ??? #3 0x7faba0c70caa in ??? #4 0x40125b in MAIN__ at /app/example.f90:3 #5 0x4010bc in main at /app/example.f90:5 ``` The above code snippet can be readily tested here to reproduce the segfault: https://godbolt.org/z/jGchG7zq3 If we add `dim = 1` to the maxloc/minloc calls, then the error is resolved. But the dim argument is optional and should not be needed. Intel ifort compiles and generates a correct answer with the above code.
[Bug fortran/104776] New: incorrect compiler error with Parameterized derived type component initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104776 Bug ID: 104776 Summary: incorrect compiler error with Parameterized derived type component initialization Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: a.shahmoradi at gmail dot com Target Milestone: --- The following code is standard-conforming, but none of the gfortran latest versions can compile it, ``` module pdt_mod use iso_fortran_env type:: BG_type(kind) integer , kind :: kind = character_kinds(1) character(5 , kind) :: str = achar(27,kind) end type end module end ``` An example error message is the following, ``` 7 | character(5 , kind) :: str = achar(27,kind) |1 Error: Cannot convert UNKNOWN to CHARACTER(5) at (1) ``` Intel ifort does not have any problems compiling this code. The code can be tested here: https://godbolt.org/z/x56MqPqbM
[Bug fortran/104750] New: Parameterized derived type extension from outside the host module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104750 Bug ID: 104750 Summary: Parameterized derived type extension from outside the host module Product: gcc Version: 10.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: a.shahmoradi at gmail dot com Target Milestone: --- Created attachment 52543 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52543=edit sample source code The following code is standard-compliant but does not compile with gfortran 10, 11, or the latest GNU trunk. ``` module amat type :: amatrix(k,c,r) integer, kind :: k = 4 integer, len :: r = 1 integer, len :: c = 1 end type amatrix end module program test_PDT_extension use amat type, extends(amatrix) :: imatrix(key) ! valid integer, kind :: key integer(kind=k) :: m(c,r) end type imatrix end ``` It returns the error: ``` Error: Parameter 'k' at (1) has not been declared or is a variable, which does not reduce to a constant expression ``` which is incorrect, because `k` is declared in the parent type. This code compiles with ifort >2021 and possibly older versions. Attached is a copy of the source code. The code can be readily tested with all versions of GNU and Intel compilers here: https://godbolt.org/z/xsz4Eb4qa
[Bug fortran/104585] New: incorrect error for dummy arguments with both VALUE and DIMENSION attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104585 Bug ID: 104585 Summary: incorrect error for dummy arguments with both VALUE and DIMENSION attributes Product: gcc Version: og11 (devel/omp/gcc-11) Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: a.shahmoradi at gmail dot com Target Milestone: --- The following interface conforms to Fortran 2008/2018 standards but is not recognized by gfortran, which seems to still follow the rules of Fortran2003 in this regard. ``` interface function test(Matrix) result(res) real, value :: Matrix(:,:) ! valid F2008 (although invalid F2003). real :: res end function end interface end ``` This enhancement requires lifting an existing restriction to allow `value` attribute with array-like dummy arguments in agreement with F2008/F2018 standards. The additional relevant discussion is also available in Fortran Discourse: https://fortran-lang.discourse.group/t/value-with-dimension-attribute-conflict/2808
[Bug fortran/104393] New: incorrect results with elemental functions of scalar derived types with allocatable components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104393
Bug ID: 104393
Summary: incorrect results with elemental functions of scalar
derived types with allocatable components
Product: gcc
Version: og11 (devel/omp/gcc-11)
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: a.shahmoradi at gmail dot com
Target Milestone: ---
Created attachment 52354
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52354=edit
main program to reproduce the bug
The elemental attribute for functions that take derived-type scalar containers
with allocatable components does not yield the correct result.
The following is the output of the test program supplied, compiled with
gfortran-11 elementalBugGfortran10.f90
on Microsoft Subsystem for Linux (WSL-2).
! This result is incorrect
ismore([Container('A'), Container('B'), Container('C')], Container('B'))
F T T
! This result is the expected answer and is correct
['A', 'B', 'C'] > 'B'
F F T
