[Bug fortran/23169] INTENT information not used in the middle-end for optimizations

2009-04-14 Thread dfranke at gcc dot gnu dot org


--- Comment #11 from dfranke at gcc dot gnu dot org  2009-04-14 15:20 
---
The original testcase in #0 appears to be fixed if compiled with -fwhole-file.
Andrew's comment #4 appears to be still an issue?!


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23169



[Bug fortran/23169] INTENT information not used in the middle-end for optimizations

2009-01-03 Thread dfranke at gcc dot gnu dot org


--- Comment #10 from dfranke at gcc dot gnu dot org  2009-01-03 19:46 
---
Maybe realted: PR29697?!


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23169



[Bug fortran/23169] INTENT information not used in the middle-end for optimizations

2009-01-02 Thread tkoenig at gcc dot gnu dot org


--- Comment #9 from tkoenig at gcc dot gnu dot org  2009-01-02 11:04 ---
(In reply to comment #8)
> There is no way to tell the middle-end about anonymous readonly memory.

So, we could either

- teach that to the middle-end (I couldn't, though :-)

- make a duplicate variable for intent(in) variables, to transfer
  the test case from comment #4 into

integer function foo(b,c) 
  integer, intent(in) :: b, c
  integer :: b_shadow, c_shadow;
  integer :: d, e
  b_shadow = b;
  c_shadow = c;
  d = b_shadow;
  e = c_shadow;
  call bar(b,c)

  foo = d-b_shadow + e-c_shadow;
end function foo


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23169



[Bug fortran/23169] INTENT information not used in the middle-end for optimizations

2009-01-02 Thread rguenth at gcc dot gnu dot org


--- Comment #8 from rguenth at gcc dot gnu dot org  2009-01-02 10:29 ---
There is no way to tell the middle-end about anonymous readonly memory.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23169



[Bug fortran/23169] INTENT information not used in the middle-end for optimizations

2008-12-29 Thread dfranke at gcc dot gnu dot org


--- Comment #7 from dfranke at gcc dot gnu dot org  2008-12-29 14:25 ---
(In reply to comment #4)
> Here is a testcase which we would not get unless we take intent(in) into
> account:
[...]
> foo should always be zero as bar should not be able to touch b or c.

Is this really related to the INTENT? For the equivalent C/C++ cases, I tried
prototypes with int, int*, const int*, int& and const int& respectively -- only
if the arguments are passed by value, the return value of foo is optimized to
zero (as shown by "-O3 -fdump-tree-optimized").


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23169



[Bug fortran/23169] INTENT information not used in the middle-end for optimizations

2008-12-26 Thread dfranke at gcc dot gnu dot org


--- Comment #6 from dfranke at gcc dot gnu dot org  2008-12-27 00:38 ---
*** Bug 36076 has been marked as a duplicate of this bug. ***


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23169



[Bug fortran/23169] INTENT information not used in the middle-end for optimizations

2008-09-21 Thread steven at gcc dot gnu dot org


--- Comment #5 from steven at gcc dot gnu dot org  2008-09-21 13:36 ---
A C equivalent test case "works".  Once the infamous
multiple-decls-per-function issue in gfortran is fixed, this bug probably will
disappear.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23169



[Bug fortran/23169] INTENT information not used in the middle-end for optimizations

2005-10-09 Thread pinskia at gcc dot gnu dot org


--- Comment #4 from pinskia at gcc dot gnu dot org  2005-10-09 17:41 ---
There are a couple of problems here. First I noticed that bar in foo is not
marked as pure even though the IPA mechanism marked it as such, so that looks
like a fortran front-end bug in that it has two different DECLs for the same
function.

The second issue after that is filed as PR 24287 which talks about pure
functions causing local variables to be call clobbered even though they don't
escape.  This issue is related to PR 23134 also.

Here is a testcase which we would not get unless we take intent(in) into
account:
   integer function foo(b,c) 
  integer, intent(in) :: b, c 
  integer :: d, e
  d = b;
  e = c;
  call bar(b,c)

  foo = d-b + e-c;
   end function 


foo should always be zero as bar should not be able to touch b or c.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23169



[Bug fortran/23169] INTENT information not used in the middle-end for optimizations

2005-10-02 Thread steven at gcc dot gnu dot org


--- Comment #3 from steven at gcc dot gnu dot org  2005-10-03 06:14 ---
No it is not.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn|23134   |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23169



[Bug fortran/23169] INTENT information not used in the middle-end for optimizations

2005-10-02 Thread pinskia at gcc dot gnu dot org


--- Comment #2 from pinskia at gcc dot gnu dot org  2005-10-02 21:27 ---
I think this is just another case of PR 23134.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||23134


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23169



[Bug fortran/23169] INTENT information not used in the middle-end for optimizations

2005-08-01 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-08-01 
12:07 ---
Confirmed.

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-08-01 12:07:56
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23169