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:
 > |  >
 > |  > |
 > |  > | From a performance/convenience angle, the best place to handle this is
 > |  > | either libc or the kernel.
 > |  >
 > |  > Hmm, that is predicated on assumptions not convenient to users
 > |  > on targets that are not glibc-based or GNU/Linux-based.
 > |
 > | Well, if GNU libc/Linux/whatever can fix this bug in libc or the
 > | kernel, so can anyone else.
 > (1) people upgrde OS less frequently than compilers.
 > (2) it is not at all obvious that the problem is in the libc or in the kernel
 > | "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.  You could blame the library for passing on the
signal, or the kernel for passing the signal to the library, or the
compiler for generating the instruction in the first place.

If we decide that the current behaviour is wrong, then we want to
change the behaviour.  If we want to do that, then we want do to so in
the way that has the least cost for most programs and most users.


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