Bug 39298 - Optimize away only set but not used variable
Summary: Optimize away only set but not used variable
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: ipa (show other bugs)
Version: 4.4.0
: P3 enhancement
Target Milestone: 5.0
Assignee: Not yet assigned to anyone
URL:
Keywords: missed-optimization
Depends on:
Blocks:
 
Reported: 2009-02-25 09:12 UTC by Tobias Burnus
Modified: 2021-12-25 06:00 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2009-02-25 09:43:40


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Burnus 2009-02-25 09:12:44 UTC
In the following Fortran program, the variable "foo" is never used, it is only set.

Result: Using "gfortran -O3", "foo" is not optimized away.
Expected: "foo" is optimized away as it happens with "ifort -O2".

      program a
      implicit none
      integer*8 it,two
      parameter(it=1073741824,two=2)
      complex foo(it*two-1)

      foo(10)=1.
      write(*,*) ''
      end program a
Comment 1 Richard Biener 2009-02-25 09:43:39 UTC
Is there a reason the Fortran frontend gives function local variables static
storage duration?

a ()
{
  struct __st_parameter_dt dt_parm.1;
  static integer(kind=4) options.0[8] = {68, 255, 0, 0, 0, 1, 0, 1};
  static complex(kind=4) foo[2147483647];

<bb 2>:
  _gfortran_set_options (8, &options.0);
  foo[9] = __complex__ (1.0e+0, 0.0);
Comment 2 Richard Biener 2009-02-25 09:51:57 UTC
It works with it == 1024 in which case foo is not static.
Comment 3 Tobias Burnus 2009-02-25 10:21:12 UTC
> Is there a reason the Fortran frontend gives function local variables static
> storage duration?

For huge arrays, there is a problem if the memory is allocated on the stack, as one quickly hits stack-size limits. Thus gfortran puts large local arrays in static memory, except when a procedure can be called recursively/simultaneously (RECURSIVE attribute, -frecursive, -fopenmp). The size for which this happens is controlled by -fmax-stack-var-size=<n>.

Actually, I don't quite see why the "static" matters: As local variable it cannot be accessed from elsewhere and if it is not accessed in the procedure ...

Additionally, C's main() and Fortran's PRORGRAM (= "MAIN__") are special because they are only called once.
Comment 4 Tobias Burnus 2009-02-25 10:35:15 UTC
I did some testing with sunf95, icc and ifort.

sunf95 also puts the variable in .bss as gfortran does, while ifort puts it on the stack (unless explicitly declared as static ["SAVE"]). If the variable is static, neither of the compilers optimizes it away.

a) Why are static variables not optimized away? (Not even in main()/MAIN_?)
b) Is there something what one could do to get the advantage of not having huge variables on the stack but still allowing to optimize the variable away?
Comment 5 Richard Biener 2009-02-25 11:21:13 UTC
Optimizing dead local static variables requires special handling which probably
is not thought to be worth the trouble.  If the variable is unused the
programmer can as well remove it.
Comment 6 pinskia@gmail.com 2009-02-25 13:37:09 UTC
Subject: Re:  Optimize away only set but not used variable



Sent from my iPhone

On Feb 25, 2009, at 1:43 AM, "rguenth at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org 
 > wrote:

>
>
> ------- Comment #1 from rguenth at gcc dot gnu dot org  2009-02-25  
> 09:43 -------
> Is there a reason the Fortran frontend gives function local  
> variables static
> storage duration?
>

Yes, it is larger than the threshhold. Remember fortran has no  
recursive functions except for the ones which marked as such.

> a ()
> {
>  struct __st_parameter_dt dt_parm.1;
>  static integer(kind=4) options.0[8] = {68, 255, 0, 0, 0, 1, 0, 1};
>  static complex(kind=4) foo[2147483647];
>
> <bb 2>:
>  _gfortran_set_options (8, &options.0);
>  foo[9] = __complex__ (1.0e+0, 0.0);
>
>
> -- 
>
> rguenth at gcc dot gnu dot org changed:
>
>           What    |Removed                     |Added
> --- 
> --- 
> ----------------------------------------------------------------------
>             Status|UNCONFIRMED                 |NEW
>     Ever Confirmed|0                           |1
>   Last reconfirmed|0000-00-00 00:00:00         |2009-02-25 09:43:40
>               date|                            |
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39298
>
Comment 7 Andrew Pinski 2009-02-27 00:00:59 UTC
The fortran front-end needs to be able to tell the middle-end that the function cannot be recursive and then the middle-end needs to use that info.
Comment 8 Andrew Pinski 2021-12-25 06:00:31 UTC
Fixed in GCC 5 by r5-657.