Re: Live range splitting in new allocator

[Marc Espie <espie at quatramaran dot ens dot fr>]

In article <20010130140050.6AFC734D80@nile.gnat.com> you write:
><<Indeed.  If -g subtly changes the code generated by
>"-O99 -fdiscombobulate", it can be a real nightmare
>finding a compiler bug.


>Or a user bug. We see all the time cases of erroneous programs,
>e.g. from the use of an uninitialized variable, that work "fine"
>in -O0, but blow up in -O2. Of course these often get reported
>as compiler bugs, and they kind of look like compiler bugs to the
>app programmer, but they are not!

I don't know how hard it would be to do, but I feel that it would make
a lot of sense to make *sure* the uninitialized variables are set to
something completely different from 0 in -O0 mode. After all, we already
know that -O0 code is bad, performance-wise, why not take the plunge and
initialize variables to bad defaults so that stuff *will* crash at -O0 as
well ?

(I'm probably rehashing the obvious there, as this problem tends to be common
knowledge. The only people I've ever seen fall into that trap are freshmen).