g++ 4.1.0/4.2.x, x86/x86-64, segfaults due to bogus SSE alignments

[tbp <tbptbp at gmail dot com>]

This bug is really transient, and AFAIK i only trigger it when using
the cluebat on g++, that is bloating every function in sight
appropriately with always_inline/noinline attributes, in a unit that
inflates much.

Tracked one occurence to something like that:
union float4_t {
	float	f[4];
	__m128	v;
	...
};

static void foobar() {
	float4_t __attribute__((aligned (16))) bar;
	...
	__m128 foo;
	...
	bar = foo;
}

If i let g++ decide if foobar() should be inlined or not, everything's
fine (but performance of course). Then if i force_inline foobar() i
may or may not get something to the effect of:
  40666a:       movaps %xmm0,0x348(%esp)
  406672:       mov    0x348(%esp),%eax
  406679:       mov    %eax,0x310(%esp)
  406680:       mov    0x34c(%esp),%eax
  406687:       movaps 0x210(%esp),%xmm0
  40668f:       mov    %eax,0x314(%esp)
  406696:       mov    0x350(%esp),%eax
  40669d:       movaps %xmm0,0x40(%esp)
  4066a2:       mov    %eax,0x318(%esp)
  4066a9:       mov    0x354(%esp),%eax

Why that value gets suddenly copied around, i don't know. It doesn't
matter much anyway, as the program won't survive past the bogus store.

It's not just related to that kind of mixed unions either, and again
it clearly depends on surrounding functions being force_inlined and
noinlined and lots of stuff ending up on the stack.

I can trigger it on cygwin and linux, with g++ 4.1.0 and various 4.2.x
and once triggered using -0s or -Ox doesn't matter; it's been there
for a long time but that's the first time i can track it down somehow
(inlining heuristics being extremly anyway).

I haven't made a bugreport yet, as that would require disclosing large
amounts of code, but i'd like to know if it's a known issue by any
chance.

Regards,
	tbp.