[Bug fortran/71544] gfortran compiler optimization bug when dealing with c-style pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71544 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #17 from Thomas Koenig --- Fixed on all open branches, closing.
[Bug fortran/71544] gfortran compiler optimization bug when dealing with c-style pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71544 --- Comment #16 from Thomas Koenig --- Author: tkoenig Date: Sun Mar 10 11:26:25 2019 New Revision: 269552 URL: https://gcc.gnu.org/viewcvs?rev=269552=gcc=rev Log: 2019-03-10 Thomas Koenig PR fortran/71544 Backport from trunk * trans-types.c (gfc_typenode_for_spec) Set ts->is_c_interop of C_PTR and C_FUNPTR. (create_fn_spec): Mark argument as escaping if ts->is_c_interop is set. 2019-03-10 Thomas Koenig PR fortran/71544 Backport from trunk * gfortran.dg/c_ptr_tests_19.f90: New test. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/c_ptr_tests_19.f90 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/trans-types.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug fortran/71544] gfortran compiler optimization bug when dealing with c-style pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71544 --- Comment #15 from Thomas Koenig --- Author: tkoenig Date: Sun Mar 10 11:19:58 2019 New Revision: 269551 URL: https://gcc.gnu.org/viewcvs?rev=269551=gcc=rev Log: 2019-03-10 Thomas Koenig PR fortran/71544 Backport from trunk * trans-types.c (gfc_typenode_for_spec) Set ts->is_c_interop of C_PTR and C_FUNPTR. (create_fn_spec): Mark argument as escaping if ts->is_c_interop is set. 2019-03-10 Thomas Koenig PR fortran/71544 Backport from trunk * gfortran.dg/c_ptr_tests_19.f90: New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/c_ptr_tests_19.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/trans-types.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug fortran/71544] gfortran compiler optimization bug when dealing with c-style pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71544 --- Comment #14 from Thomas Koenig --- Author: tkoenig Date: Sat Mar 9 19:21:24 2019 New Revision: 269532 URL: https://gcc.gnu.org/viewcvs?rev=269532=gcc=rev Log: 2019-03-09 Thomas Koenig PR fortran/71544 * trans-types.c (gfc_typenode_for_spec) Set ts->is_c_interop of C_PTR and C_FUNPTR. (create_fn_spec): Mark argument as escaping if ts->is_c_interop is set. 2019-03-09 Thomas Koenig PR fortran/71544 * gfortran.dg/c_ptr_tests_19.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/c_ptr_tests_19.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/71544] gfortran compiler optimization bug when dealing with c-style pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71544
--- Comment #13 from Thomas Koenig ---
This looks like it does the trick (test case passes):
Index: trans-types.c
===
--- trans-types.c (Revision 269260)
+++ trans-types.c (Arbeitskopie)
@@ -1176,7 +1176,8 @@ gfc_typenode_for_spec (gfc_typespec * spec, int co
{
spec->type = BT_INTEGER;
spec->kind = gfc_index_integer_kind;
- spec->f90_type = BT_VOID;
+ spec->f90_type = BT_VOID;
+ spec->is_c_interop = 1; /* Mark as escaping later. */
}
break;
case BT_VOID:
@@ -2957,7 +2958,8 @@ create_fn_spec (gfc_symbol *sym, tree fntype)
|| f->sym->ts.u.derived->attr.pointer_comp))
|| (f->sym->ts.type == BT_CLASS
&& (CLASS_DATA (f->sym)->ts.u.derived->attr.proc_pointer_comp
- || CLASS_DATA (f->sym)->ts.u.derived->attr.pointer_comp)))
+ || CLASS_DATA (f->sym)->ts.u.derived->attr.pointer_comp))
+ || (f->sym->ts.type == BT_INTEGER && f->sym->ts.is_c_interop))
spec[spec_len++] = '.';
else if (f->sym->attr.intent == INTENT_IN)
spec[spec_len++] = 'r';
[Bug fortran/71544] gfortran compiler optimization bug when dealing with c-style pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71544 Thomas Koenig changed: What|Removed |Added Status|NEW |ASSIGNED CC||tkoenig at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org
[Bug fortran/71544] gfortran compiler optimization bug when dealing with c-style pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71544 Dominique d'Humieres changed: What|Removed |Added CC||relliott at umn dot edu --- Comment #12 from Dominique d'Humieres --- *** Bug 71412 has been marked as a duplicate of this bug. ***
[Bug fortran/71544] gfortran compiler optimization bug when dealing with c-style pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71544
--- Comment #11 from kargl at gcc dot gnu.org ---
(In reply to Richard Biener from comment #9)
> Confirmed as fortran FE bug. The FE manages to set ".r" as fn spec attribute
> on save_cptr which specifies that its first argument does not escape.
>
> It's trans-types.c:create_fn_spec that does this by doing
>
> for (f = gfc_sym_get_dummy_args (sym); f; f = f->next)
> if (spec_len < sizeof (spec))
> {
> if (!f->sym || f->sym->attr.pointer || f->sym->attr.target
> || f->sym->attr.external || f->sym->attr.cray_pointer
> || (f->sym->ts.type == BT_DERIVED
> && (f->sym->ts.u.derived->attr.proc_pointer_comp
> || f->sym->ts.u.derived->attr.pointer_comp))
> || (f->sym->ts.type == BT_CLASS
> && (CLASS_DATA (f->sym)->ts.u.derived->attr.proc_pointer_comp
> || CLASS_DATA
> (f->sym)->ts.u.derived->attr.pointer_comp)))
> spec[spec_len++] = '.';
> else if (f->sym->attr.intent == INTENT_IN)
> spec[spec_len++] = 'r';
> else if (f->sym)
> spec[spec_len++] = 'w';
> }
>
> and it looks like the side-effect of marking arguments as not escaping as
> soon
> as you specify anything else than . was overlooked.
>
> Or Fortran really doesn't allow args to be stored away but has an exception
> for
> C binding types which needs handling above.
This patch works around the inability of a programmer
to type SAVE in the line 'integer(c_int), pointer :: a'.
I'm not convinced that gfortran cannot optimize away the
assignment 'a = 100' as 'a' is a local variable in
subroutine init(). I can find nothing in the standard that
requires a compiler to assume that the return result from
c_loc() is cached somewhere.
I have no intentions to commit this patch. It is recorded
here so that I can clean up my development tree. If one thinks
about its ramifications, one should arrive at the conclusion
that the patch will cause a leak of memory.
Index: match.c
===
--- match.c (revision 237481)
+++ match.c (working copy)
@@ -1349,6 +1349,11 @@ gfc_match_assignment (void)
gfc_set_sym_referenced (lvalue->symtree->n.sym);
+ if (lvalue->symtree->n.sym->attr.pointer == 1
+ && lvalue->symtree->n.sym->attr.referenced == 1
+ && lvalue->symtree->n.sym->attr.save == SAVE_NONE)
+lvalue->symtree->n.sym->attr.save = SAVE_IMPLICIT;
+
new_st.op = EXEC_ASSIGN;
new_st.expr1 = lvalue;
new_st.expr2 = rvalue;
[Bug fortran/71544] gfortran compiler optimization bug when dealing with c-style pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71544 --- Comment #10 from Dominique d'Humieres --- > Thank you for the suggested workaround. This can certainly be helpful in the > short term. However, we would not want to rely on tuning compiler > optimization switches in the future to ensure correct code operation. ... You can do the inlining in your code, e.g., --- pr71544.f90 2016-06-15 18:54:59.0 +0200 +++ pr71544_db.f90 2016-06-28 10:06:17.0 +0200 @@ -7,10 +7,12 @@ end module store_cptr subroutine init() use, intrinsic :: iso_c_binding +use store_cptr implicit none integer(c_int), pointer :: a allocate(a) -call save_cptr(c_loc(a)) +!call save_cptr(c_loc(a)) +cptr = c_loc(a) a = 100 end subroutine init
[Bug fortran/71544] gfortran compiler optimization bug when dealing with c-style pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71544
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|NEW
Component|tree-optimization |fortran
--- Comment #9 from Richard Biener ---
Confirmed as fortran FE bug. The FE manages to set ".r" as fn spec attribute
on save_cptr which specifies that its first argument does not escape.
It's trans-types.c:create_fn_spec that does this by doing
for (f = gfc_sym_get_dummy_args (sym); f; f = f->next)
if (spec_len < sizeof (spec))
{
if (!f->sym || f->sym->attr.pointer || f->sym->attr.target
|| f->sym->attr.external || f->sym->attr.cray_pointer
|| (f->sym->ts.type == BT_DERIVED
&& (f->sym->ts.u.derived->attr.proc_pointer_comp
|| f->sym->ts.u.derived->attr.pointer_comp))
|| (f->sym->ts.type == BT_CLASS
&& (CLASS_DATA (f->sym)->ts.u.derived->attr.proc_pointer_comp
|| CLASS_DATA (f->sym)->ts.u.derived->attr.pointer_comp)))
spec[spec_len++] = '.';
else if (f->sym->attr.intent == INTENT_IN)
spec[spec_len++] = 'r';
else if (f->sym)
spec[spec_len++] = 'w';
}
and it looks like the side-effect of marking arguments as not escaping as soon
as you specify anything else than . was overlooked.
Or Fortran really doesn't allow args to be stored away but has an exception for
C binding types which needs handling above.
[Bug fortran/71544] gfortran compiler optimization bug when dealing with c-style pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71544 --- Comment #7 from fortranbug at gmail dot com --- (In reply to fortranbug from comment #6) > Thank you for the suggested workaround. This can certainly be helpful in the > short term. However, we would not want to rely on tuning compiler > optimization switches in the future to ensure correct code operation. (Our > system is used by a community of users and it is not possible for us to > ensure that they all use specific optimizations switches.) > > Can someone clarify the status of this bug report? Is this a recognized > issue that will be addressed at some point? Any thoughts on this? I'm not sure what the process is for bug reports for gfortran. Should we expect a response as to whether this is accepted as a bug report?
[Bug fortran/71544] gfortran compiler optimization bug when dealing with c-style pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71544 --- Comment #6 from fortranbug at gmail dot com --- Thank you for the suggested workaround. This can certainly be helpful in the short term. However, we would not want to rely on tuning compiler optimization switches in the future to ensure correct code operation. (Our system is used by a community of users and it is not possible for us to ensure that they all use specific optimizations switches.) Can someone clarify the status of this bug report? Is this a recognized issue that will be addressed at some point?
[Bug fortran/71544] gfortran compiler optimization bug when dealing with c-style pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71544
--- Comment #4 from noamb ---
(In reply to noamb from comment #3)
> However, presence of options that are invalid for
> 4.9.3 in that list makes me think that perhaps the correct list of options
> in that (moderately old) version is just different.
The same behavior (incorrect with -O1, correct with full list of specific
options) is also present on linux gfortran 4.9.3 when the list of options
turned on by -O1 is automatically generated by "-O1 -Q --help=optimizers":
tin 1035 : gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/gnu/4.9.3/libexec/gcc/x86_64-unknown-linux-gnu/4.9.3/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/usr/local/gnu/4.9.3
--enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.9.3 (GCC)
tin 1036 : gfortran -O1 orig_example.F90 ; ./a.out
The following line should print 100
589837704
tin 1037 : gfortran `gfortran -O1 -Q --help=optimizers | grep enabled | awk
'{print $1}'` orig_example.F90 ; ./a.out
f951: warning: command line option ‘-frtti’ is valid for C++/ObjC++ but not for
Fortran
f951: warning: command line option ‘-fno-threadsafe-statics’ is valid for
C++/ObjC++ but not for Fortran
f951: warning: variable tracking requested, but useless unless producing debug
info
The following line should print 100
100
[Bug fortran/71544] gfortran compiler optimization bug when dealing with c-style pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71544 --- Comment #5 from Dominique d'Humieres --- > I do not observe correct behavior with the options that the previous comment > list s as being turned on by -O1 (this is on OS X 10.10, macports gfortran > 4.9.3): gfortran-fsf-5: error: unrecognized command line option '-fssa-backprop' gfortran-fsf-4.9: error: unrecognized command line option '-fssa-phiopt' So these options are not available for 4.9 and older. For 4.8.5 and 4.9.3 on x86_64-apple-darwin15 (fink builds or mine ones), I get [Book15] f90/bug% gfortran-fsf-4.8 pr71544.f90 -fauto-inc-dec -fbranch-count-reg -fcombine-stack-adjustments -fcompare-elim -fcprop-registers -fdce -fdefer-pop -fdse -fforward-propagate -fguess-branch-probability -fif-conversion2 -fif-conversion -finline-functions-called-once -fipa-pure-const -fipa-profile -fipa-reference -fmerge-constants -fmove-loop-invariants -freorder-blocks -fshrink-wrap -fsplit-wide-types -ftree-bit-ccp -ftree-ccp -ftree-ch -ftree-coalesce-vars -ftree-copy-prop -ftree-dce -ftree-dominator-opts -ftree-dse -ftree-forwprop -ftree-fre -ftree-phiprop -ftree-sink -ftree-slsr -ftree-sra -ftree-pta -ftree-ter -funit-at-a-time -fomit-frame-pointer [Book15] f90/bug% ./a.out The following line should print 100 100
[Bug fortran/71544] gfortran compiler optimization bug when dealing with c-style pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71544 --- Comment #3 from noamb --- (In reply to noamb from comment #2) > I do not observe correct behavior with the options that the previous comment > list s as being turned on by -O1 (this is on OS X 10.10, macports gfortran > 4.9.3): Sorry - this is wrong. It was just failing to recompile because of the uknown -fssa-* options. Once I actually recompile with the long list of optimizations documented as corresponding to -O1, it does work correctly, as the first comment says. However, presence of options that are invalid for 4.9.3 in that list makes me think that perhaps the correct list of options in that (moderately old) version is just different.
[Bug fortran/71544] gfortran compiler optimization bug when dealing with c-style pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71544 noamb changed: What|Removed |Added CC||noamb at bollweevil dot gdbg.org --- Comment #2 from noamb --- From Dominique d'Humieres > Duplicate of pr71412? This one is probably related, but does not actually involve calling a C routine. Also, that previous bug has different dependence on -O level (works with -O0, fails with -O1, -O2, -O3, at least on OS X gfortran 4.9.3 from macports) I do not observe correct behavior with the options that the previous comment list s as being turned on by -O1 (this is on OS X 10.10, macports gfortran 4.9.3): [bernstei@rhodium tmp]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin14/4.9.3/lto-wrapper Target: x86_64-apple-darwin14 Configured with: /opt/local/var/macports/build/_opt_mports_dports_lang_gcc49/gcc49/work/gcc-4.9.3/configure --prefix=/opt/local --build=x86_64-apple-darwin14 --enable-languages=c,c++,objc,obj-c++,lto,fortran,java --libdir=/opt/local/lib/gcc49 --includedir=/opt/local/include/gcc49 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --datarootdir=/opt/local/share/gcc-4.9 --with-local-prefix=/opt/local --with-system-zlib --disable-nls --program-suffix=-mp-4.9 --with-gxx-include-dir=/opt/local/include/gcc49/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --with-isl=/opt/local --disable-isl-version-check --with-cloog=/opt/local --disable-cloog-version-check --enable-stage1-checking --disable-multilib --enable-lto --enable-libstdcxx-time --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket --with-pkgversion='MacPorts gcc49 4.9.3_0' Thread model: posix gcc version 4.9.3 (MacPorts gcc49 4.9.3_0) [bernstei@rhodium tmp]$ gfortran -fauto-inc-dec -fbranch-count-reg -fcombine-stack-adjustments -fcompare-elim -fcprop-registers -fdce -fdefer-pop -fdse -fforward-propagate -fguess-branch-probability -fif-conversion2 -fif-conversion -finline-functions-called-once -fipa-pure-const -fipa-profile -fipa-reference -fmerge-constants -fmove-loop-invariants -freorder-blocks -fshrink-wrap -fsplit-wide-types -fssa-backprop -fssa-phiopt -ftree-bit-ccp -ftree-ccp -ftree-ch -ftree-coalesce-vars -ftree-copy-prop -ftree-dce -ftree-dominator-opts -ftree-dse -ftree-forwprop -ftree-fre -ftree-phiprop -ftree-sink -ftree-slsr -ftree-sra -ftree-pta -ftree-ter -funit-at-a-time -fomit-frame-pointer -fstrict-aliasing t.F90 gfortran: error: unrecognized command line option '-fssa-backprop' gfortran: error: unrecognized command line option '-fssa-phiopt' [bernstei@rhodium tmp]$ ./a.out The following line should print 100 0
[Bug fortran/71544] gfortran compiler optimization bug when dealing with c-style pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71544 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-06-15 CC||hubicka at gcc dot gnu.org, ||jakub at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Duplicate of pr71412? Present from 4.8 up to trunk (7.0). A workaround is to compile the test at -O1 with -finline-small-functions (turned on by -O2 and above). Note that compiling the test with all the documented optimization turned on by -O1, e.g., -fauto-inc-dec -fbranch-count-reg -fcombine-stack-adjustments -fcompare-elim -fcprop-registers -fdce -fdefer-pop -fdse -fforward-propagate -fguess-branch-probability -fif-conversion2 -fif-conversion -finline-functions-called-once -fipa-pure-const -fipa-profile -fipa-reference -fmerge-constants -fmove-loop-invariants -freorder-blocks -fshrink-wrap -fsplit-wide-types -fssa-backprop -fssa-phiopt -ftree-bit-ccp -ftree-ccp -ftree-ch -ftree-coalesce-vars -ftree-copy-prop -ftree-dce -ftree-dominator-opts -ftree-dse -ftree-forwprop -ftree-fre -ftree-phiprop -ftree-sink -ftree-slsr -ftree-sra -ftree-pta -ftree-ter -funit-at-a-time -fomit-frame-pointer -fstrict-aliasing gives the expected result. So the problem occurs for either an undocumented option or an optimization not controlled by an option.
