g++ 3.2, djvulibre i athlon

[Jakub Bogusz]

WRESZCIE namierzyłem byka. Tylko gdzie - w gcc, czy w djvulibre?

Ktoś chyba tutaj (malekith?) pisał, że C++ nie dopuszcza równoczesnego
istnienia wskaźników różnych typów do tej samej zmiennej i gcc 3.x
wykorzystuje to przy optymalizacji. Jakie są dokładne ograniczenia?

Czy taka konstrukcja jest poprawna (wycięta tylko istotna część):

#v+
class GPBufferBase
{
public:
  GPBufferBase(void *&,const size_t n,const size_t t);
private:
  void *&ptr;
};

inline
GPBufferBase::GPBufferBase(void *&xptr,const size_t n,const size_t t) : ptr(xptr), num(n)
{
  xptr=(n*t)?(::operator new(n*t)):0;
}

template<class TYPE>
class GPBuffer : public GPBufferBase
{
public:
  GPBuffer(TYPE *&xptr,const size_t n=0) : GPBufferBase((void *&)xptr,n,sizeof(TYPE)) {}
}
#v-

i dalej użycie:

#v+
  unsigned int *posn;
  GPBuffer<unsigned int> gposn(posn,blocksize);
  memset(posn, 0, sizeof(unsigned int)*size);
#v-      

Ten kod działa oprócz przypadku optymalizacji z "-O2 -march=athlon".

Kod dla np. "-O2 -march=i686" wygląda ~tak:

#v+
  leal 60(%esp),%esi
[...]
.Lxxx
  movl %eax,(%esi)
  leal 0(,%edx,4),%ecx
  movl 60(%esp),%edi
#v-

dla "-O2 -march=athlon":

#v+
  leal 60(%esp),%esi
[...]
.Lxxx
  movl 60(%esp),%edi
  leal 0(,%edx,4),%ecx
  movl %eax,(%esi)
#v-

Jak widać (%esi) i 60(%esp) to to samo słowo - w drugim przypadku
najpierw jest odczytywana wartość (jakiś śmieć?), potem dopiero
zapisywana... a że %edi jest potem używane jako adres do zerowania, to
zeruje to jakieś miejsce w pamięci (na podstawie efektów - struktury
dynamicznego linkera).


-- 
Jakub Bogusz    http://www.cs.net.pl/~qboosh/