This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Miscompilation of remainder expressions

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?


[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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]