Bug 48390 - Multiple setting to restricted pointer variable not optimized away
Summary: Multiple setting to restricted pointer variable not optimized away
Status: UNCONFIRMED
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 4.7.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: missed-optimization
Depends on:
Blocks: 49774
  Show dependency treegraph
 
Reported: 2011-03-31 16:10 UTC by Tobias Burnus
Modified: 2011-07-18 08:53 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Burnus 2011-03-31 16:10:58 UTC
Missed optimization: In the following program, the first "a = 1" line can be removed - as the setting is not used and the value is latter overridden, however, the line remains even with -O3.


function foo (a, b, c, ptr)
 real :: a, b, c, foo
 real, pointer :: ptr

 a = 1 ! Can delete
 b = ptr + 2
 a = 3

 foo = a + b
end function


From the -O3 dump:

foo (real(kind=4) & restrict a, real(kind=4) & restrict b, real(kind=4) & restrict c, real(kind=4) * & ptr)
{ [...]
  *a_1(D) = 1.0e+0;  /* Expected: This line is removed.  */
[...]
  *a_1(D) = 3.0e+0;


The same result is obtained for the equivalent C program:

float
foo (float * restrict a, float * restrict b, float * restrict c, float *ptr)
{
 *a = 1; /* Can delete.  */
 *b = *ptr + 2;
 *a = 3;

 return *a + *b;
}


Reported in by Daniel Carrera at http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/ec8641acbcbbed10/fdc9369d5acf53f1#fdc9369d5acf53f1
Comment 1 Tobias Burnus 2011-03-31 16:15:56 UTC
For the C case: If "ptr" is also "restrict", the "*a = 1" is optimized away. Ditto for Fortran, if "ptr" is not a POINTER but a normal variable.

In case of Fortran, the a/b/c cannot alias with ptr as none of has the TARGET attribute. I would expect the same for C99 as a/b/c are "restrict" but maybe I am wrong about the C99 semantics.