public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
* 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).