Can't reproduce this on my system with all the latest packages.

This defect considered MUST-FIX for Florence Gold release

I can reproduce it on yesterdays tree... I'll try upgrading it.

I think this is a problem with gcc - if you build it with -O0 or -O2, it works
fine. If you add our standard "-march=i386 -mcpu=i686" flags as well, it
segfaults when run.

Ouch, this won't be easy to find out.
I've tracked it down to the gcc-c++-addressof.patch, but unfortunately
that patch changes the assembly output considerably, so I haven't located
which routine gets miscompiled yet.

Preston, Glen... I think you might want to look at this: These are our default
compiler options.

Localized to aspell_default_writable_repl::WritableReplS::soundslike_elements(void) const
being miscompiled, more to follow (hopefully).

Minimalized into:
class G {};

struct N {
  N *a;
};

struct V {
  typedef N *W;
  W *m, *n;
  int s() const { return int(n - m); }
  const W &operator[](int x) const { return *(m + x); }
};

struct H;

struct J {
  N *c;
  H *d;
  J(N *x, H *y) : c(x), d(y) {}
};

struct K {
  const N *c;
  const H *d;
  K(const N *x, const H *y) : c(x), d(y) {}
  K(const J &x) : c(x.c), d(x.d) {}
};

struct H {
  V e;
  int f;

  J u()
  {
    for (int x = 0; x < e.s(); ++x)
      if (e[x])
        return J(e[x], this);
    return v();
  }
  J v() { return J((N*)64, this); }
};

struct I {
  H d;
  J u() { return d.u(); }
  J v() { return d.v(); }
};

struct bar {
  virtual ~bar() {}
};

struct E {
  K g;
  E(K x) : g(x) {}
};

struct foo : public bar {
  K h;
  E i;
  foo(const K x, const E &y) : h(x), i(y) {}
};

struct A {
  I *l;
  foo *baz() const;
};

foo *A::baz() const
{
  return new foo(l->u(), E(l->v()));
}

A x;
I i;
foo *f;

int main ()
{
  x.l = &i;
  f = x.baz();
  if (f->h.c != f->i.g.c || f->h.d != f->i.g.d)
    return 1;
  return 0;
}

which fails with -O2 -mcpu=i686 and does not fail with -O2 (or -O0).
The issue is that scheduling reorders load with store to the same location,
but the load is marked as mem/u (constant), so I need to find out what
is supposed to prevent this reordering.

When you've found at more about it, please tell us which packages may be
miscompiled by this (how long has this patch been there).

Trond, I'm afraid this would be pretty hard to tell, hacking the backend
so that it would go and discover these cases would be non-trivial.
Anyway, I've just created a patch which seems to make this go away
with -O2 -mcpu=i686 -fPIC (what aspell is actually using), unfortunately
the testcase I've created from it is still miscompiled at -O2 -mcpu=i686
(without -fpic). I've called for help to gcc-local for the second time
(and will at least try to sufficiently test the patch I've made later today).

the only real C++ packages that matter in the distribution are kde and aspell. 
 If KDE isn't segafaulting, then this problem I doubt this problem is being 
encountered there.

BTW: Anybody see any reason why:
    MakeVirEmulation(const Iterator i, const Parms & p = Parms())
      : i_(i), parms_(p) {}
uses const Iterator instead of either Iterator or const Iterator & ?
(I'm discussing the fix on gcc-patches now, so don't take this as an attempt
not to fix gcc, but the above thing which is what causes the miscompilation
does not make sense to me).

Not really - ask kevina.net.

I've added debugging into the place and potentially many C++ programs could
be miscompiled (I'm not saying they are, it just has to have bad luck and be
scheduled "right" so that loads precede stores to it.
aspell is affected, doxygen freetype htdig ImageMagick kdeadmin kdegames kdegraphics kdelibs kdemultimedia kdenetwork kdenetwork kdepim kdesdk kdeutils koffice kpppload lam mozilla qt tripwire might be,
plus maybe some of the C++ stuff which failed during last mass rebuild.

ETA on the compiler fix?

fixed compiler is in the tree.