* iso_c_bindings and optimization interaction bug
@ 2016-04-29 12:13 Ryan S. Elliott
2016-06-04 12:31 ` Ryan S. Elliott
0 siblings, 1 reply; 2+ messages in thread
From: Ryan S. Elliott @ 2016-04-29 12:13 UTC (permalink / raw)
To: fortran
[-- Attachment #1: Type: text/plain, Size: 2130 bytes --]
Hello,
I may have discovered a problem 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.
I would greatly appreciate any analysis of this issue. Is it a bug? Is my
code non-compliant in some way? etc.
Thanks, Ryan
-------------------------------------------------------------------------------
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
[-- Attachment #2: Type: application/octet-stream, Size: 1152 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: iso_c_bindings and optimization interaction bug
2016-04-29 12:13 iso_c_bindings and optimization interaction bug Ryan S. Elliott
@ 2016-06-04 12:31 ` Ryan S. Elliott
0 siblings, 0 replies; 2+ messages in thread
From: Ryan S. Elliott @ 2016-06-04 12:31 UTC (permalink / raw)
To: fortran
I've now submitted this as a bug to bugzilla. It is number 71412
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71412
On Fri, 29 Apr 2016, Ryan S. Elliott wrote:
> Hello,
>
> I may have discovered a problem 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.
>
> I would greatly appreciate any analysis of this issue. Is it a bug? Is my
> code non-compliant in some way? etc.
>
> Thanks, Ryan
>
> -------------------------------------------------------------------------------
>
> 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
>
--
Ryan S. Elliott, Ph.D. and Associate Professor
Aerospace Engineering & Mechanics, University of Minnesota
(612) 624-2376 (626-1558 fax)
http://www.aem.umn.edu/~relliott/
download vCard <http://www.aem.umn.edu/~relliott/relliott.vcf>
KIM Editor (http://openKIM.org)
Associate Editor: Journal of Elasticity (http://springer.com/10659)
MSI Associate Fellow (http://msi.umn.edu)
CMT textbook webpage (http://modelingmaterials.org)
----------
A synonym is a word you use when you can't spell the word you first thought
of.
Burt Bacharach
----------
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2016-06-04 12:31 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-04-29 12:13 iso_c_bindings and optimization interaction bug Ryan S. Elliott
2016-06-04 12:31 ` Ryan S. Elliott
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).