User account creation filtered due to spam.
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
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:
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
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.
(In reply to Tobias Burnus from comment #0)
> foo (float * restrict a, float * restrict b, float * restrict c, float *ptr)
> *a = 1; /* Can delete. */
> *b = *ptr + 2;
> *a = 3;
> return *a + *b;
This is supported in current trunk, and the dead store '*a = 1' is removed.