[Bug fortran/71412] [F03] iso_c_bindings and optimization interaction bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71412 --- Comment #14 from relliott at umn dot edu --- It is great to see some life on this bug report. This is still an important issue for our project! Is there any chance of reviving the discussion and coming to a resolution?
[Bug fortran/71412] iso_c_bindings and optimization interaction bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71412 --- Comment #9 from relliott at umn dot edu --- Hello, I still believe there is a bug associated with the iso_c_bindings and c_loc() support. In the attached, I've created an example program that shows that ALLOCATABLE local variables are deallocated at the end of a routine (noleak), but pointer variables are not (leak). Then, I've created a program without using iso_c_bindings that gives the same result for -O0 and -O3 (pointer_fortran) and a program that uses iso_c_bindings to do the same thing that gives different results for -O0 and -O3 (pointer_cstyle). Use the 'runme.sh' script to illustrate the following behavior: $ ./runme.sh - running 'noleak' - running 'leak' ./runme.sh: line 15: 3233 Killed ./leak - running O0 version of 'pointer_fortran' F T 3.1410 - running O3 version of 'pointer_fortran' F T 3.1410 - running O0 version of 'pointer_cstyle' F F T F T T 3.1410 - running O3 version of 'pointer_cstyle' F F T F T T 0. Thanks, Ryan
[Bug fortran/71412] iso_c_bindings and optimization interaction bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71412 --- Comment #7 from relliott at umn dot edu --- Hello, I just want to make one think certain. You quoted section 6.3.3.1 of the J3/04-007 document to show that a NAMED local allocatable variable would be deallocated at the end of a routine. However, it is unclear to me that this applies to a POINTER variable (as I have in my skeleton code). In Section 6.3.1.2 is says: Allocation of a pointer creates an object that implicitly has the TARGET attribute. Following successful execution of an ALLOCATE statement for a pointer, the pointer is associated with the target and may be used to reference or define the target This seems to say that an UNNAMED allocatable target object is created when the allocate statement for a pointer variable is executed. In which case, section 6.3.3.1 is not applicable. Can you help me to understand why this is not the case? Many thanks, Ryan
[Bug fortran/71412] iso_c_bindings and optimization interaction bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71412 --- Comment #6 from relliott at umn dot edu --- > Have you considered the SAVE attribute? > > integer(c_int), pointer,save:: val > > laptop-kargl:kargl[246] gmake > gfc -O3 -g -Wall -pedantic -c skeleton-f.F90 > ~/work/bin/gcc -O3 -g -Wall -ansi -pedantic -c skeleton-c.c > gfc -O3 -g -Wall skeleton*.o -o skeleton > laptop-kargl:kargl[247] ./skeleton > -- in storePtr: pointer address --> 0x28621018 <-- value --> 0 <-- index --> 0 > -- just a print statement --> nothing <-- index --> 0 > -- in getPtr: pointer address --> 0x28621018 <-- value --> 21 <-- index --> > 0 > -- in storePtr: pointer address --> 0x28621020 <-- value --> 0 <-- index --> 1 > -- just a print statement --> nothing <-- index --> 1 > -- in getPtr: pointer address --> 0x28621020 <-- value --> 12 <-- index --> > 1 > -- value of 'val0' variable --> 21 > -- value of 'val1' variable --> 12 Thanks, I'll look at SAVE more closely. > > PS: You probably do not want to use -pedantic with gfortran. OK. > > PPS: bugzilla is not an appropriate forum to learn Fortran. Try > comp.lang.fortran. Agreed. I didn't get any response from fort...@gcc.gnu.org and I thought it was a bug, so I submitted to bugzilla. I'll consider this closed now and look for other resources. Many thanks for your interaction. Ryan
[Bug fortran/71412] iso_c_bindings and optimization interaction bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71412 --- Comment #4 from relliott at umn dot edu --- > Ahem, give val the SAVE attribute. > > integer(c_int), pointer, save :: val Hi, Thanks for your help. Unfortunately, I don't think using save will serve my purpose in this case. Although, now I see that the skeleton code does not illustrate this aspect of my requirements. The myalloc() function is supposed to be able to allocate multiple independent values. I've updated the code to demonstrate this requirement. Attached. The typical output is now: $ make gfortran -m32 -O3 -g -Wall -pedantic -c skeleton-f.F90 gcc -m32 -O3 -g -Wall -ansi -pedantic -c skeleton-c.c gfortran -m32 -O3 -g -Wall skeleton*.o -o skeleton $ ./skeleton -- in storePtr: pointer address --> 0x78625940 <-- value --> 805306368 <-- index --> 0 -- just a print statement --> nothing <-- index --> 0 -- in getPtr: pointer address --> 0x78625940 <-- value --> 805306368 <-- index --> 0 -- in storePtr: pointer address --> 0x78625950 <-- value --> 805306368 <-- index --> 1 -- just a print statement --> nothing <-- index --> 1 -- in getPtr: pointer address --> 0x78625950 <-- value --> 805306368 <-- index --> 1 -- value of 'val0' variable -->805306368 -- value of 'val1' variable -->805306368 $ make clean rm -f skeleton skeleton*.o *.mod $ make DEFS=-DOK gfortran -m32 -O3 -g -Wall -pedantic -DOK -c skeleton-f.F90 gcc -m32 -O3 -g -Wall -ansi -pedantic -DOK -c skeleton-c.c gfortran -m32 -O3 -g -Wall skeleton*.o -o skeleton $ ./skeleton -- in storePtr: pointer address --> 0x78e41c80 <-- value --> -268435456 <-- index --> 0 -- value of 'val' variable --> 21 <-- index -->0 -- in getPtr: pointer address --> 0x78e41c80 <-- value --> 21 <-- index --> 0 -- in storePtr: pointer address --> 0x78e41c90 <-- value --> -268435456 <-- index --> 1 -- value of 'val' variable --> 12 <-- index -->1 -- in getPtr: pointer address --> 0x78e41c90 <-- value --> 12 <-- index --> 1 -- value of 'val0' variable --> 21 -- value of 'val1' variable --> 12 Suggestions would be much appreciated. Thanks, Ryan
[Bug fortran/71412] iso_c_bindings and optimization interaction bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71412 --- Comment #2 from relliott at umn dot edu --- > I believe gfortran's behavior conforms to the standard. F2003 states > > When the execution of a procedure is terminated by execution > of a RETURN or END statement, an allocatable variable that is > a named local variable of the procedure retains its allocation > and definition status if it has the SAVE attribute or is a > function result variable or a subobject thereof; otherwise, it > is deallocated. > > val is a local variable. val does not have the SAVE attribute. If that is the case, how should the desired result be achieved in a standard conformant way?
[Bug fortran/71412] New: iso_c_bindings and optimization interaction bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71412 Bug ID: 71412 Summary: iso_c_bindings and optimization interaction bug Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: relliott at umn dot edu Target Milestone: --- Created attachment 38644 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38644=edit minimal skeleton code that illustrates the bug A problem exists in the way gfortran optimizes functions/subroutines when c interoperability (and specifically the c_loc() intrinsic) are used. The attached code illustrates the issue. A variable is allocated and a pointer is to the allocated memory is sent to C and stored in global memory. Next the memory is initialized in the same routine that it was allocated. Finally, in a different routine the memory pointer is retrieved from c and the value stored in memory is printed. With optimization -O3 the initialization is optimized out. With optimization -O0 the initialization occurs and the code runs correctly. The typical output and sequence of steps to run the code is given below. vagrant@vagrant-ubuntu-trusty-64:/vagrant$ cd skeleton/ vagrant@vagrant-ubuntu-trusty-64:/vagrant/skeleton$ make gfortran -m32 -O3 -g -Wall -pedantic -c skeleton-f.F90 gcc -m32 -O3 -g -Wall -ansi -pedantic -c skeleton-c.c gfortran -m32 -O3 -g -Wall skeleton*.o -o skeleton vagrant@vagrant-ubuntu-trusty-64:/vagrant/skeleton$ ./skeleton -- in storePtr: pointer address --> 0x95caba0 <-- value --> -144534256 -- just a print statement --> nothing -- in getPtr: pointer address --> 0x95caba0 <-- value --> -144534256 -- value of 'val2' variable --> -144534256 vagrant@vagrant-ubuntu-trusty-64:/vagrant/skeleton$ make clean rm -f skeleton skeleton*.o *.mod vagrant@vagrant-ubuntu-trusty-64:/vagrant/skeleton$ make OPT=-O0 gfortran -m32 -O0 -g -Wall -pedantic -c skeleton-f.F90 gcc -m32 -O0 -g -Wall -ansi -pedantic -c skeleton-c.c gfortran -m32 -O0 -g -Wall skeleton*.o -o skeleton vagrant@vagrant-ubuntu-trusty-64:/vagrant/skeleton$ ./skeleton -- in storePtr: pointer address --> 0x8d09ba0 <-- value --> -143915760 -- just a print statement --> nothing -- in getPtr: pointer address --> 0x8d09ba0 <-- value --> 21 -- value of 'val2' variable --> 21
