Обсуждение: BUG #4190: sparc64 test suite fails

The following bug has been logged online:

Bug reference:      4190
Logged by:          Dennis Gilmore
Email address:      dennis@ausil.us
PostgreSQL version: 8.3.1
Operating system:   Linux
Description:        sparc64 test suite fails
Details:

errors test fails.  the following is the output.  which to me indicates it
passed  but gave different output.

*** ./expected/errors.out       Sat Nov 10 09:36:44 2007
--- ./results/errors.out        Fri May 23 09:18:27 2008
***************
*** 304,312 ****
  select 1/0;
  ERROR:  division by zero
  select 1::int8/0;
! ERROR:  division by zero
  select 1/0::int8;
! ERROR:  division by zero
  select 1::int2/0;
  ERROR:  division by zero
  select 1/0::int2;
--- 304,314 ----
  select 1/0;
  ERROR:  division by zero
  select 1::int8/0;
! ERROR:  floating-point exception
! DETAIL:  An invalid floating-point operation was signaled. This probably
means an out-of-range result or an invalid operation, such as division by
zero.
  select 1/0::int8;
! ERROR:  floating-point exception
! DETAIL:  An invalid floating-point operation was signaled. This probably
means an out-of-range result or an invalid operation, such as division by
zero.
  select 1::int2/0;
  ERROR:  division by zero
  select 1/0::int2;

======================================================================

"Dennis Gilmore" <dennis@ausil.us> writes:
> errors test fails.  the following is the output.  which to me indicates it
> passed  but gave different output.

No, it failed.  The code in question looks like this:

    int64        arg1 = PG_GETARG_INT64(0);
    int32        arg2 = PG_GETARG_INT32(1);
    int64        result;

    if (arg2 == 0)
        ereport(ERROR,
                (errcode(ERRCODE_DIVISION_BY_ZERO),
                 errmsg("division by zero")));

    result = arg1 / arg2;

and the output you are showing indicates that the compiler thought it
could rearrange the code so that the division was executed *despite*
the protective test in front of it.

IMHO, what you have here is a compiler bug, or at least the gcc boys are
going to need to provide a damn good excuse why it's not.

BTW, kindly revert the patch you inserted in the Fedora repository.

            regards, tom lane

"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> IMHO, what you have here is a compiler bug, or at least the gcc boys are
> going to need to provide a damn good excuse why it's not.

You don't, perhaps have any of -ffast-math or these two suboptions which
-ffast-math enables turned on?

`-funsafe-math-optimizations'
     Allow optimizations for floating-point arithmetic that (a) assume
     that arguments and results are valid and (b) may violate IEEE or
     ANSI standards.  When used at link-time, it may include libraries
     or startup files that change the default FPU control word or other
     similar optimizations.

     This option should never be turned on by any `-O' option since it
     can result in incorrect output for programs which depend on an
     exact implementation of IEEE or ISO rules/specifications for math
     functions.

     The default is `-fno-unsafe-math-optimizations'.

`-fno-trapping-math'
     Compile code assuming that floating-point operations cannot
     generate user-visible traps.  These traps include division by
     zero, overflow, underflow, inexact result and invalid operation.
     This option implies `-fno-signaling-nans'.  Setting this option
     may allow faster code if one relies on "non-stop" IEEE arithmetic,
     for example.

     This option should never be turned on by any `-O' option since it
     can result in incorrect output for programs which depend on an
     exact implementation of IEEE or ISO rules/specifications for math
     functions.

     The default is `-ftrapping-math'.

--
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com
  Ask me about EnterpriseDB's Slony Replication support!

The full build log is=20
http://sparc.koji.fedoraproject.org/koji/getfile?taskID=3D56849&name=3Dbuil=
d.log

the build was using gcc-4.3  with the package as built on the rest of fedor=
a.=20=20
it builds ok sparc32 ppc ppc64 i386 x86_64 and ia64  but fails on sparc64.=
=20=20

I will forward everything to the gcc guys in a bug report.=20=20

Dennis

On Friday 23 May 2008, Gregory Stark wrote:
> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
> > IMHO, what you have here is a compiler bug, or at least the gcc boys are
> > going to need to provide a damn good excuse why it's not.
>
> You don't, perhaps have any of -ffast-math or these two suboptions which
> -ffast-math enables turned on?
>
> `-funsafe-math-optimizations'
>      Allow optimizations for floating-point arithmetic that (a) assume
>      that arguments and results are valid and (b) may violate IEEE or
>      ANSI standards.  When used at link-time, it may include libraries
>      or startup files that change the default FPU control word or other
>      similar optimizations.
>
>      This option should never be turned on by any `-O' option since it
>      can result in incorrect output for programs which depend on an
>      exact implementation of IEEE or ISO rules/specifications for math
>      functions.
>
>      The default is `-fno-unsafe-math-optimizations'.
>
> `-fno-trapping-math'
>      Compile code assuming that floating-point operations cannot
>      generate user-visible traps.  These traps include division by
>      zero, overflow, underflow, inexact result and invalid operation.
>      This option implies `-fno-signaling-nans'.  Setting this option
>      may allow faster code if one relies on "non-stop" IEEE arithmetic,
>      for example.
>
>      This option should never be turned on by any `-O' option since it
>      can result in incorrect output for programs which depend on an
>      exact implementation of IEEE or ISO rules/specifications for math
>      functions.
>
>      The default is `-ftrapping-math'.