On Thu, 22 May 2003 15:24:06 +0200, Carl-Daniel Hailfinger said:
> Nobody has found an error in the code we talked about, so a compiler bu=
g
> in gcc 3.2.3 seems to be the only explanation.
In the last 20 years, I've come across lots of cases where optimizers did=
foolish things that broke code. I've also come across the odd case or th=
ree
where the optimizer merely exposed a bug. Favorite cases here are where
the optimizer removes what it thinks is a dead/redundant load/store, and
exposes a race condition on a variable that should have been 'volatile' b=
ut
wasn't, odd corner cases where sequence points actually matter (one of th=
ese was
just posted here the other day, in fact)... stuff like that.
So yes. It's probably something borked in gcc 3.2.3 - but we probably wo=
n't
know for sure till somebody goes over the assembler output with a fine to=
oth
comb...
--==_Exmh_-104199101P
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001
iD8DBQE+zNkvcC3lWbTT17ARAuX0AJ0foGS95xmrR8uRQRFV78Rr69MtxQCgsJ9Y
f1OA9coczD/e9Sic46OHFR4=
=SwSV
-----END PGP SIGNATURE-----
--==_Exmh_-104199101P--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/