On Wed, Jan 17, 2007 at 12:43:40AM +0100, Vincent Lefevre wrote:
> On 2007-01-16 21:27:42 +0000, Andrew Haley wrote:
> > Ian Lance Taylor writes:
> > > I suspect that the best fix, in the sense of generating the best
> > > code, would be to do this at the tree level. That will give loop
> > > and VRP optimizations the best chance to eliminate the test for -1.
> > > Doing it during gimplification would be easy, if perhaps rather
> > > ugly. If there are indeed several processors with this oddity,
> > > then it would even make a certain degree of sense as a
> > > target-independent option.
> >
> > x86, x86-64, S/390, as far as I'm aware.
>
> and PowerPC G4 and G5, where I don't get a crash, but an incorrect
> result (as said on PR#30484).
>
On PPC, the solution is to use "divo." [1] followed by an unlikely
conditional branch to out of line code to handle the corner cases.
The question is: what do we do in the case of a divide by zero on PPC?
Are there other architectures that do not trap?
Gabriel
[1] sadly gcc does not know about the overflow flag and (unless it has
improved greatly since the last time I checked on a small ADA program)
generates bloated and slow code when checking for overflow. This is not
specific to the rs6000 backend.
