[Bug middle-end/40194] fortran rules for optimizing

2013-03-29 Thread Joost.VandeVondele at mat dot ethz.ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40194 Joost VandeVondele changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC

[Bug middle-end/40194] fortran rules for optimizing

2012-06-29 Thread Joost.VandeVondele at mat dot ethz.ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40194 --- Comment #10 from Joost VandeVondele 2012-06-29 14:14:16 UTC --- this testcase now looks optimized (at least the optimized dump contains return 1; as expected). I guess this can be closed ?

[Bug middle-end/40194] fortran rules for optimizing

2009-08-13 Thread matz at gcc dot gnu dot org
--- Comment #9 from matz at gcc dot gnu dot org 2009-08-13 12:16 --- It is indeed somewhat related, but currently the patchset doesn't help here. The first issue is, that I create new types with unconflicting alias sets only for global variables, not local ones (as I1 is in this case).

[Bug middle-end/40194] fortran rules for optimizing

2009-08-13 Thread jv244 at cam dot ac dot uk
--- Comment #8 from jv244 at cam dot ac dot uk 2009-08-13 07:23 --- Michael, this is somewhat related to your 'restrict-for-fortran-patch' http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00610.html do you think it also fixes the issue here ? -- jv244 at cam dot ac dot uk changed:

[Bug middle-end/40194] fortran rules for optimizing

2009-05-19 Thread rguenth at gcc dot gnu dot org
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-05-19 12:10 --- Hm, no. It doesn't pass it by value. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40194

[Bug middle-end/40194] fortran rules for optimizing

2009-05-19 Thread rguenth at gcc dot gnu dot org
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-05-19 12:04 --- The intel compiler passes I1 by value: ..___tag_value_f1_.1: #1.18 subq $24, %rsp #1.18 ..___tag_value_f1_.3:

[Bug middle-end/40194] fortran rules for optimizing

2009-05-19 Thread jv244 at cam dot ac dot uk
--- Comment #5 from jv244 at cam dot ac dot uk 2009-05-19 11:54 --- (In reply to comment #3) > Does > > SUBROUTINE S(I1,IP) > INTEGER,INTENT(IN) :: I1 > INTEGER, POINTER :: IP > END SUBROUTINE S > > allow that S stores the pointer to I1 to global memory? this is no

[Bug middle-end/40194] fortran rules for optimizing

2009-05-19 Thread rguenth at gcc dot gnu dot org
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-05-19 10:39 --- Hmm, DECL_BY_REFERENCE is set too often. Maybe in addition set/check TREE_READONLY. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40194

[Bug middle-end/40194] fortran rules for optimizing

2009-05-19 Thread rguenth at gcc dot gnu dot org
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-05-19 10:20 --- Does SUBROUTINE S(I1,IP) INTEGER,INTENT(IN) :: I1 INTEGER, POINTER :: IP END SUBROUTINE S allow that S stores the pointer to I1 to global memory? I think that the easiest way to improve Fortran

[Bug middle-end/40194] fortran rules for optimizing

2009-05-19 Thread jv244 at cam dot ac dot uk
--- Comment #2 from jv244 at cam dot ac dot uk 2009-05-19 10:14 --- the context of the report is http://gcc.gnu.org/ml/gcc/2009-05/msg00465.html in particular, fortran variables are often not 'addressable' in the sense that seems to be important of the gcc optimizers -- http://gc

[Bug middle-end/40194] fortran rules for optimizing

2009-05-19 Thread jv244 at cam dot ac dot uk
--- Comment #1 from jv244 at cam dot ac dot uk 2009-05-19 10:01 --- OK, updated testcase, while the argument still holds for the previous code, this was the intended code, and the generated code is even worse: INTEGER FUNCTION F1() INTEGER :: I1 INTEGER, TARGET :: I2 INTEGER, POIN