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

Gabriel Dos Reis writes:
 > On Wed, 17 Jan 2007, Andrew Haley wrote:
 > | Gabriel Dos Reis writes:
 > |  > On Wed, 17 Jan 2007, Andrew Haley wrote:
 > |  >
 > |  > [...]
 > |  >
 > |  > |  > | "To a man with a hammer, all things look like a nail."  It's very
 > |  > |  > | tempting for us in gcc-land always to fix things in gcc, not because
 > |  > |  > | it's technically the right place but because it's what we control
 > |  > |  > | ourselves.
 > |  > |  >
 > |  > |  > well, I'm unclear what your point is here, but certainly GCC is
 > |  > |  > at fault for generating trapping instructions.
 > |  > |  > So, we fix the problem in GCC, not because that is what we control
 > |  > |  > ourselves, but we we failed to generate proper code.
 > |  > |
 > |  > | It's not a matter of whose fault it is; trying to apportion blame
 > |  > | makes no sense.
 > |  >
 > |  > we have a communication problem here.  Nobody is trying to apportion
 > |  > blame.  However, gcc is the tool that generates trapping instruction.
 > |  > It is unclear why it would be the responsability of the OS or libc
 > |  > to fix what GCC has generated in the first place.
 > |
 > | That makes no sense either.
 > |
 > | It's an engineering problem.  We have a widget that does the wrong
 > | thing*.  We have several ways to make it do the right thing, only one
 > | of which has no adverse impact on the existing users of the widget.
 > You believe there is one solution, except that it does not work for
 > the supported target.

Sorry, I don't understand what you mean by that.

I've been thinking about why we see this so very differently, and it's
dawned on me why that is.

I first came across this "architectural feature" of the 8086 in the
mid-1980s.  To begin with, there was no divide overflow handler at
all: the machine would simply crash.  It took me a little while to
figure out what was happening, but once I'd done so it was a simple
matter to write a few lines of assembly language that fix up the
operands and carry on.

Fast-forward ten years or so and for the first time I come across
unices running on an x86.  And I was surprised to see that rather than
fixing up the operands and continuing, the kernel punted the problem
to the user's program, which usually responded by core dumping.  "OK,"
I thought, "that must be what UNIX programmers want.  This trap must
be desired, because it is trivially easy to fixup and continue.
Perhaps it's because programmers want to be alerted that there is a
bug in their program."

And that's what I thought until last week.  :-)


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