Обсуждение: [patch] test failure on sparc64 due to undefined division by zero behaviour

Hello PostgreSQL hackers,

I recently got the following bug report about a test suite failure on
sparc64:

----- Forwarded message from Aurelien Jarno <aurel32@debian.org> -----

Date: Wed, 02 Mar 2011 23:49:05 +0100
From: Aurelien Jarno <aurel32@debian.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: Bug#616180: postgresql-9.0: FTBFS on sparc64, testsuite issues with int8

postgresql-9.0 fails to build on sparc64 due to testsuite errors with
int8. The division by 0 is not trapped and a SIGFPE is issued instead of
an error.

Postgresql people claims it's a gcc bug, while gcc people says the code
is incorrect [1]. Whatever the real issue is, the fix is very simple
(actually taken in another part from the very same file), so it's
probably the best to simply apply it.

[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29968

----- End forwarded message -----


The C99 standard [2], section 6.5.5 paragraph 5 actually says:

  "The result of the / operator is the quotient from the division of
  the first operand by the second; the result of the % operator is the
  remainder. In both operations, if the value of the second operand is
  zero, the behavior is undefined."

so the gcc folk's claim that this isn't a gcc bug looks justified.

Aurelien sent a straightforward patch for this, I updated it to apply
to current git head, updated the comments, and git-formatted it.

Thanks for considering!

Martin

[2] http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf
--
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

Martin Pitt <mpitt@debian.org> writes:
> The C99 standard [2], section 6.5.5 paragraph 5 actually says:

>   "The result of the / operator is the quotient from the division of
>   the first operand by the second; the result of the % operator is the
>   remainder. In both operations, if the value of the second operand is
>   zero, the behavior is undefined."

> so the gcc folk's claim that this isn't a gcc bug looks justified.

The gcc guys are full of it.  The issue that is relevant here is the C
standard's definition of sequence points, and in particular the
requirement that visible side effects of a later statement cannot happen
before the execution of an earlier function call.  The last time I
pestered them about this, I got some lame claim that a SIGFPE wasn't a
side effect within the definitions of the spec.  At that point useful
discussion stopped, because it's impossible to negotiate with someone
who's willing to claim that.

> Aurelien sent a straightforward patch for this, I updated it to apply
> to current git head, updated the comments, and git-formatted it.

Hmm ... I'm willing to put in the extra return statements, but not to
remove the comments that we're working around a gcc bug.  In particular,
given the gcc folks' claim that they need not consider the timing of
program-generated signals, there is really nothing to stop them from
trying to push the division up before the return too.  This is nothing
but a band-aid for a non-standards-compliant optimizer.

            regards, tom lane