On Tue, 2005-07-05 at 20:05 +0200, Gabriel Dos Reis wrote:
> Paolo Carlin
> It is definitely a good thing to use the full bits of value
> representation if we ever want to make all "interesting" bits part of
> the hash value. For reasonable or sane representations it suffices to
> get your hand on
On Wed, 2005-07-06 at 15:54 +0300, Michael Veksler wrote:
> > most architectures have different bit representations for +0.0 and -0.0,
> > yet the two values compare equal.
> >
>
> Yet, their sign bit is observable through things like
> assert(a == 0.0);
> assert(b == 0.0);
> 1/(1/a+ 1/b)
Paul Schlie wrote:
In that case you may want to stick with -O0. There are *lots* of
things GCC does that alter undefined cases. How about the undefined
behavior when aliasing rules are violated? Would you want to make
-fno-strict-aliasing be the only supported setting?
- Isn't the purp
Kai Henningsen wrote:
So what you say is that any decent modern C++ coding guide/list wants to
forbid catching the C++ standard exceptions, and anything derived from
them?
no, only catch by value is problematic, as it can lead to slicing.
catch by reference is perfectly fine.
I recently had to build gcc 3.2.2 on an FC4 box. This failed using gcc
4.0.2 as the bootstrap compiler since gcc 3.2.2 uses no-longer-accepted
extensions. So I built gcc 3.4.5 using 4.0.2, and used that to bootstrap
3.2.2.
Now, if it is part of the release criteria that release N-1 must be
bu
