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?
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 variable
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
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
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 c
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 all
: 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&action=edit
minimal skeleton code that illustrates the bug
A problem exists in
