EGCS bad on loop invariant optimization ?

[Martin von Loewis]

> Consider 
> 
> #include <cstddef>
> 
> class array {
> public:
>     array (size_t i) : sz(i), data (new double[i]) {}
> 
>     double operator[] (size_t i) const { return data[i]; }
>     double& operator[] (size_t i) { return data[i]; }
> 
> private:
>     size_t sz;
>     double* data;
> };
> 
> int main ()
> {
>     const size_t n = 1000;
> 
>     array a(n), b(n), c(n);
> 
>     for (size_t i=0; i<n; ++i) a[i] = b[i] + c[i];
> 
>     return 0;
> }
> 

...

> Can't EGCS see that a.data, b.data, c.data are loop invariants and
> then move the loads out of the loop ? At least, one can expect
> b.data and c.data to be subject of this kind of optimization since the
> only way to access them is through the (leaf) *const* class member
> fonction `array::operator[](size_t) const'. What am I missing ? 

I believe this would depend on how ::operator new is implemented.  It
*could* return pointers into the stack, so that the writes to a[i]
overwrite the contents of b and c, so that reloading b.date and c.data
is necessary.

Of course, ::operator new never does such things. g++ doesn't now
that, though, and assumes worst-case.

Regards,
Martin