g++ 4.5.0, end-user disappointment and interrogations

[tbp <tbptbp at gmail dot com>]

Hello,

having finally built myself a 4.5.0 (linux x86-64), i've quickly tried
it on some of my code and it soon became apparent some things weren't
for the better.
Here's my febrile attempt to sum up what surprised me
$ cat huh.cc
#include <cmath>
#if __GNUC__ * 100 + __GNUC_MINOR__ < 405
	#define constexpr
#endif
struct foo_t {
	float x, y, z;
	foo_t() {}
	constexpr foo_t(float a, float b, float c) : x(a),y(b),z(c) {}
	friend foo_t operator*(foo_t lhs, float s) { return foo_t(lhs.x*s,
lhs.y*s, lhs.z*s); }
	friend float dot(foo_t lhs, foo_t rhs) { return lhs.x*rhs.x +
lhs.y*rhs.y + lhs.z*rhs.z; }
};
struct bar_t {
	float m[3];
	bar_t() {}
	constexpr bar_t(float a, float b, float c) : m{a, b, c} {}
	friend bar_t operator*(bar_t lhs, float s) { return bar_t(lhs.m[0]*s,
lhs.m[1]*s, lhs.m[2]*s); }
	friend float dot(bar_t lhs, bar_t rhs) { return lhs.m[0]*rhs.m[0] +
lhs.m[1]*rhs.m[1] + lhs.m[2]*rhs.m[2]; }
};
namespace {
	template<typename T> float magsqr(T v) { return dot(v, v); }
	template<typename T> T norm(T v) { return v*(1/std::sqrt(magsqr(v))); }
	constexpr foo_t foo(1, 2, 3);
	constexpr bar_t bar(1, 2, 3);
}
void frob1(const foo_t &a, foo_t &b) { b = norm(a); }
void frob2(const bar_t &a, bar_t &b) { b = norm(a); }
int main() { return 0; }
$ g++ -std=c++0x -O3 -march=native -ffast-math -mno-recip huh.cc

a) Code produced for frob1 and frob2 differ (a dead store isn't
removed with the array variant), when they used not to (for example
with g++ 4.4.1); that's a really annoying regression (can't index
foo_t members etc...).
b) Note the rsqrtss in there: -ffast-math turns
-funsafe-math-optimizations on which, now, also turns on
-freciprocal-math; the old -m[no-]recip switch that used to direct the
emission of reciprocals is useless; no warnings of any sort emitted.
The only mention of the new behaviour is in the manual (nothing in
http://gcc.gnu.org/gcc-4.5/changes.html).
c) constexpr apparently makes no difference, stuff still gets
constructed/stored at runtime. Vectors aren't allowed either: error:
parameter '__vector(4) float v' is not of literal type; even if that's
what the standard say, it would have been handy.

Q:
Is the dead store removal/fuss with arrays a known/transient issue
soon to be fixed (again)?
Would it be possible to foolproof
-ffast-math/-freciprocal-math/-mrecip in some way?
What's the deal with constexpr (or what can i reasonably expect)?