This is the mail archive of the gcc@gcc.gnu.org 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


Joe Buck <Joe.Buck@synopsys.COM> writes:

| On Tue, Jan 16, 2007 at 11:05:20AM -0800, David Daney wrote:
| > Roberto Bagnara wrote:
| > >
| > >Hmmm, it says nothing about the remainder.  Can some Google guru
| > >suggest how to prove or disprove the claim that what we are
| > >talking about is wildly known?
| > >
| > 
| > The point really is not how widely/wildly known the issue is.  Really 
| > the thing we consider on gcc@ is:  What is the 'best' thing for GCC and 
| > the GCC developers to do.
| > 
| > I don't claim to speak for others, but until now this issue has not 
| > seemed all that pressing.  And it still doesn't.
| 
| We can talk about this forever, but how about moving to a resolution?

seconded.

| First off, is there a PR for this bug?

I believe this is target/30484.

Ian, do you believe something along the line of

 # > I mean, could not we generate the following for "%": 
 # >
 # >     rem a b := 
 # >       if abs(b) == 1
 # >          return 0
 # >       return <machine-instruction> a b
 #
 # On x86 processors that have conditional moves, why not do the equivalent
 # of
 #
 #         neg_b = -b;
 #         cmov(last result is negative,neg_b,b)
 #         __machine_rem(a,b)
 #
 # Then there's no disruption of the pipeline.

is workable for the affected targets?

-- Gaby


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