This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Miscompilation of remainder expressions
Robert Dewar wrote:
Roberto Bagnara wrote:
Andrew Haley wrote:
Roberto Bagnara writes:
> > Reading the thread "Autoconf manual's coverage of signed integer
> overflow & portability" I was horrified to discover about GCC's
> miscompilation of the remainder expression that causes INT_MIN % -1
> to cause a SIGFPE on CPUs of the i386 family. Are there plans to
> fix this bug (which, to me, looks quite serious)?
No, there aren't. It would make more sense for you to wrap % in some
code that checks for this, rather than for us to slow down every
division
for this one special case.
With all due respect, I must say I am shocked. I always thought
(and taught) that we, Free Software people, value standard conformance
and getting things right. Now we have a bug that can shut down
airplanes
Please do not indulge in excessive rhetoric, planes do not get
shut down by compiler bugs. If you really think that the integrity
of avionics software depends on bug free compilers you have no
idea what you are talking about (I would guess you are for
example unfamiliar with DO-178B certification).
You are right: I am not familiar with DO-178B certification.
Yes, it's a bug, is it a serious bug, no? Will real software
be affected? no. Indeed I find any program that actually
does this remainder operation in practice to be highly
suspect.
But I am not wrong if I say that a bug is a bug and must be fixed.
I was answering to a message saying (basically) "we won't fix
it since there is a performance penalty to be paid."
I do not feel to be excessively rhetoric if I say that others,
not us, are said to knowingly disregard standards, whether it be
for performance reasons or for other reasons. Of course, this
is a matter of taste.
A final remark: I think that today the problem is safety, not speed.
I don't think doing the right thing for remainder expression will
have such a high cost with the help of the optimizer and, maybe,
assistance from the kernel. But even if the cost turns out to be high,
the actual state of things is unacceptable: mentioning the bug
prominently
in the documentation, trying to change the standard, ..., whatever;
but not leaving things as they are.
Yes, it should probably be fixed, but making a major fuss about
it seems peculiar at best. I think it is perfectly reasonable
for you to propose a patch to fix this if you are specially
concerned, but don't expect the community to rush to fix this
particular bug at high priority in response to this complaint.
I am sorry if I brought you to think that I am asking something
for me. There is no longer a problem for me personally: I will
simply stop using % in my projects (which, by the way are in C++)
and will use custom functions instead. I have almost finished
an Autoconf test to check for this bug. Most importantly, I am
now perfectly aware of the problem. I have filed a couple
of bug reports, one for GCC and the other for the Intel C/C++
compiler. I have been told that a C Standard Defect Report
already exists on this subject. So, it is the end of the
story, as far as I am personally concerned.
Concerning the community (to which I belong, by the way)
I propose that, to start with, the documentation is modified
to mention this problem in a prominent way. The text can
be borrowed from the new Autoconf's documentation that has
been recently discussed on this list.
There are lots of known bugs far more important than this one.
Wow! I hope they are all in Bugzilla: the one we are talking
about was apparently not there until a couple of hours ago.
--
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:bagnara@cs.unipr.it