This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: New no-undefined-overflow branch
- From: Paolo Bonzini <bonzini at gnu dot org>
- To: gcc at gcc dot gnu dot org
- Date: Fri, 06 Mar 2009 15:29:35 +0100
- Subject: Re: New no-undefined-overflow branch
- References: <alpine.LNX.2.00.0902261204410.11836@zhemvz.fhfr.qr> <b798aad50902271506kc0233el6cb6bbb12a2266fb@mail.gmail.com> <Pine.LNX.4.64.0902272356150.32548@digraph.polyomino.org.uk> <alpine.LNX.2.00.0902281126000.11836@zhemvz.fhfr.qr> <DAC04B03-0815-4B28-A11E-E992FF93D57E@adacore.com> <alpine.LNX.2.00.0903061003010.10965@zhemvz.fhfr.qr>
> So while trapping variants can certainly be introduced it looks like
> this task may be more difficult.
I don't think you need to introduce trapping tree codes. You can
introduce them directly in the front-end as
s = x +nv y
(((s ^ x) & (s ^ y)) < 0) ? trap () : s
d = x -nv y
(((d ^ x) & (x ^ y)) < 0) ? trap () : d
(b == INT_MIN ? trap () : -nv b)
(int)((long long) a * (long long) b) == a *nv b ? trap () : a *nv b
Making sure they are compiled efficiently is another story, but
especially for the sake of LTO I think this is the way to go.
Paolo