[Bug fortran/57966] New: Using a TBP to specify the shape of a dummy argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57966 Bug ID: 57966 Summary: Using a TBP to specify the shape of a dummy argument Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: stefan.mauerberger at gmail dot com Created attachment 30542 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30542action=edit minimal example Hi There! I am faced with some weired behavior. Because it is a little hard to describe I am providing an example: There is a DDT 'config_cls' whose pure TBP 'my_size' does nothing but returning 10 . TYPE config_cls CONTAINS PROCEDURE, NOPASS :: my_size END TYPE PURE INTEGER FUNCTION my_size() my_size = 10 END FUNCTION my_size In addition there is a subroutine 'my_sub' which expects a dummy argument of explicit shape 'config%my_size()'. SUBROUTINE my_sub( field ) REAL, INTENT(INOUT) :: field( config%my_size() ) !REAL, INTENT(INOUT), CONTIGUOUS :: field(:) ! Assumed shape works !REAL, INTENT(INOUT) :: field( my_size() ) ! works, too END SUBROUTINE my_sub As far as I can see this is valid Fortran code. However, gfortran complains that config%my_size() is not a function. Well, this is wrong (for non dummy arguments it works perfectly fine)! Attached, there is a minimal example. Compiling it with gfortran terminates with: test.f90:33.22: REAL :: field( config%my_size() ) 1 Error: 'my_size' at (1) should be a FUNCTION Any ideas? Cheers, Stefan Actually, ifort 12.1.6, nag 5.3.2 and pgfortran 13.4 are just fine.
[Bug fortran/56008] [F03] wrong code with lhs-realloc on assignment with derived types having allocatable components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56008 --- Comment #10 from stefan.mauerberger at gmail dot com 2013-02-10 18:34:51 UTC --- Hi There! Its me again. Unfortunately, I have to report that there is still something wired. The following slightly modified code causes a memory leak: PROGRAM main TYPE :: test_typ REAL, ALLOCATABLE :: a(:) END TYPE TYPE(test_typ) :: conc(2) conc = [ test_typ( [1.0,2.0] ), test_typ( [4.0,4.9] ) ] END PROGRAM main Well, the code does not crash, however, valgrind says: ... ==18920== LEAK SUMMARY: ==18920==definitely lost: 16 bytes in 2 blocks ... Not invoking the array-constructor, everything seems to be fine. Any ideas?
[Bug fortran/56008] [F03] wrong code with lhs-realloc on assignment with derived types having allocatable components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56008 --- Comment #7 from stefan.mauerberger at gmail dot com 2013-01-22 19:08:10 UTC --- Unfortunately, I do not understand a thing about all the internals and the actual implementations. I just wanted to let you know that I am totally overwhelmed how series bugs are treated and how quick bug-fixes approach. You guys are just awesome! In case I can support you in any kind fixing that bug, please let me know.
[Bug fortran/56008] New: [F03] lhs-allocation invoking the array-constructor on DDTs causes memory error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56008 Bug #: 56008 Summary: [F03] lhs-allocation invoking the array-constructor on DDTs causes memory error Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: stefan.mauerber...@gmail.com Created attachment 29183 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29183 minimal testcase Hi There! I encountered some wired behavior with F03's automatic (re)allocation features in 4.7.2 and 4.8.0 from trunk. What I have is a DDT with an allocatable member-variable. TYPE :: test_typ REAL, ALLOCATABLE :: a(:) END TYPE I am initializing two instances of that type 'xx' and 'yy' with allocated member-variables. In addition there is an allocatable array 'conc' of 'test_typ' which is not yet allocated. TYPE(test_typ) :: xx, yy TYPE(test_typ), ALLOCATABLE :: conc(:) xx = test_typ( [1.0] ) yy = test_typ( [1.0,2.0,3.0] ) To allocate 'conc' I want to utilize the array-constructor: conc = [ xx, yy ] This however, referring to Valgrinds memory analysis, causes a memory error: ==14558== Conditional jump or move depends on uninitialised value(s) ==14558==at 0x401030: MAIN__ (test.f90:16) ==14558==by 0x40118B: main (test.f90:20) ==14558== Uninitialised value was created by a heap allocation ==14558==at 0x4C2B3F8: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==14558==by 0x400DCB: MAIN__ (test.f90:16) ==14558==by 0x40118B: main (test.f90:20) Well, 'gfortran -v -Wall -Wextra test.f90' compiles just fine without any complaints. Also the executable produces results as expected (in most cases). The above problem, however, will be exposed and triggered by initializing the MPI execution environment. Just invoking CALL MPI_INIT() will cause a segmentation fault. First of all I wanted to blame OMPI for that (see: http://www.open-mpi.org/community/lists/users/2013/01/21103.php). However, those guys convinced me asking you for advice. To reproduce all that, there is a minimal test-case attached. In addition, there is a file containing the system configuration and one with Valgrind's memory analysis. Cheers, Stefan (Btw. what is the appropriate Fortran expression/terminology for DDT member-variables)
[Bug fortran/56008] [F03] lhs-allocation invoking the array-constructor on DDTs causes memory error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56008 --- Comment #1 from stefan.mauerberger at gmail dot com 2013-01-16 19:37:56 UTC --- Created attachment 29184 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29184 gfortran -v -Wall -Wextra -g test.f90
[Bug fortran/56008] [F03] lhs-allocation invoking the array-constructor on DDTs causes memory error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56008 --- Comment #2 from stefan.mauerberger at gmail dot com 2013-01-16 19:38:45 UTC --- Created attachment 29185 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29185 valgrind -v --track-origins=yes ./a.out
[Bug fortran/55932] DDT's default structure constructor does not work with having allocatable member variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55932 --- Comment #2 from stefan.mauerberger at gmail dot com 2013-01-11 11:50:19 UTC --- Indeed, it is a F2003 feature. Does that matter? I searched for duplicates without finding a similar one. Anyways ... Thanks for the suggested workaround. It seems to work just fine for my pursues.
[Bug fortran/55932] New: DDT's default structure constructor does not work with having allocatable member variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55932 Bug #: 55932 Summary: DDT's default structure constructor does not work with having allocatable member variables Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: stefan.mauerber...@gmail.com Created attachment 29138 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29138 minimal working example Hi Everybody! First of all, this is my first bug-report. In case I am doing something inappropriate pleas be soft with me. Concerning my problem: Invoking the default DDT structure constructor on types with allocatable member variables causes an internal compiler error. I tried with 4.7.1, 4.7.2 and 4.8.0 20121008. Defining a DDT having an allocatable member variable TYPE :: test_typ REAL, ALLOCATABLE :: a END TYPE the default structure constructor causes gfortran to crash my_test_typ = test_typ(a=1.0) As far as I can see, my code is valid Fortran. With NAG, PGI and Intel everything works just fine. If you need more details pleas let me know. Cheers, Stefan Environment: Ubuntu 12.10 How-To-Repeat: Try to compile the attached code
