[Bug middle-end/64101] New: GCC considers that the erf math function does not set errno

[Bug middle-end/64101] New: GCC considers that the erf math function does not set errno

[niva at niisi dot msk.ru]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64101

            Bug ID: 64101
           Summary: GCC considers that the erf math function does not set
                    errno
           Product: gcc
           Version: 4.7.4
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: niva at niisi dot msk.ru

Created attachment 34131
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34131&action=edit
The preprocessed source of the test program

We use a cross-conpiler configured as follows: 
/home/niva/src/gcc-4.7.4/configure --target=mips64-none-elf --enable-threads=no
--disable-shared --enable-long-long --enable-c99 --enable-languages=c
--enable-multilib --enable-symvers=gnu --disable-libmudflap --disable-libssp
--disable-libgcc_eh --with-newlib --with-dwarf2 --with-system-zlib
--enable-generated-files-in-srcdir --verbose --prefix=/home/niva/local
--enable-cpp

The following program (the preprocessed source is attached)

#include <assert.h>
#include <errno.h>
#include <math.h>

int main ()
{
   double res;
   errno = 0;
   res = erf (-1.2553634935946022721708238314E-308);
   assert (errno == ERANGE);
   return 0;
}

compiled as

  mips64-none-elf-gcc -O1 tst_erf.c

produces an assertion though we use a POSIX-compliant math
library and the erf function sets errno = ERANGE
according to erf description in POSIX Programmer's Manual.  

The test program works correctly (i.e. without the assertion)
if we compile it with -fno-builtin-erf.

Apparently GCC treats erf as a "clean" or "pure" function
(see gcc/builtins.def). IMHO this is not correct. 

ISO C 99 (see 7.12.8.1) does not state directly whether erf
may set errno. But in 7.12.1 (6) it is stated that
"If the result underflows, the function returns an
implementation-defined value whose magnitude is no greater than the smallest
normalized positive number in the specified type; if the integer expression
math_errhandling & MATH_ERRNO is nonzero, whether errno acquires the
value ERANGE is implementation-defined; if the integer expression
math_errhandling & MATH_ERREXCEPT is nonzero, whether the ‘‘underflow’’
floating-point exception is raised is implementation-defined."

In many Linux erf man pages we read that 
"These functions do not set errno". 

But there is a bug report
https://sourceware.org/bugzilla/show_bug.cgi?id=6785 :
"When erf() is given a subnormal argument, it raises an underflow exception. 
However errno is not set.  It should be set to ERANGE."
>From gcc-bugs-return-468841-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 28 12:59:40 2014
Return-Path: <gcc-bugs-return-468841-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 6809 invoked by alias); 28 Nov 2014 12:59:40 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 6754 invoked by uid 48); 28 Nov 2014 12:59:35 -0000
From: "dominiq at lps dot ens.fr" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/64099] [5 Regression] ~15% runtime increase for fatigue.f90.
Date: Fri, 28 Nov 2014 12:59:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dominiq at lps dot ens.fr
X-Bugzilla-Status: WAITING
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-64099-4-yRi13z5353@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64099-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64099-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-11/txt/msg03313.txt.bz2
Content-length: 2787

https://gcc.gnu.org/bugzilla/show_bug.cgi?idd099

--- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> I don't see this on any of our testers.  What CPU do you have and what default
> -march gets used for you?  (thus please show -v output)

My CPU is a 2.8 GHz Intel Core i7. All the versions reported in comment 0 have
been configured with

../p_work/configure --prefix=/opt/gcc/gcc4.10p-#rev.p#patch
--enable-languages=c,c++,lto,fortran,ada,objc,obj-c++ --with-gmp=/opt/mp
--with-system-zlib --enable-checking=release --with-isl=/opt/mp --enable-lto
--enable-plugin --with-arch=core2 --with-cpu=core2

but r216631 for which --enable-checking=release has been omitted. #rev. is the
revision and #patch is the number of patches required to bootstrap.

> Btw, -flto should be redundant for a single-file benchmark - -fwhole-program
> is enough.

I know, however I have seen in the past some regressions when -flto is added.
Since I can afford to double the compile time, I keep it in my reference
options.

> Does -ftree-loop-linear make a difference for you?

AFAICT it does not on fatigue.f90, but I see some (minor) improvements for
other tests in the suite.

> Our testers use -ffast-math -funroll-loops -O3.

Using '-O3 -ffast-math' instead of '-Ofast' almost double the runtime:

[Book15] lin/test% gfortran -O3 -ffast-math -fwhole-program fatigue.f90
[Book15] lin/test% time a.out > /dev/null
2.648u 0.002s 0:02.65 99.6%    0+0k 0+3io 38pf+0w
[Book15] lin/test% gfortran -Ofast -fwhole-program fatigue.f90
[Book15] lin/test% time a.out > /dev/null
1.385u 0.002s 0:01.38 100.0%    0+0k 0+1io 0pf+0w
[Book15] lin/test% gfc -O3 -ffast-math -fwhole-program fatigue.f90
[Book15] lin/test% time a.out > /dev/null
2.952u 0.002s 0:02.96 99.6%    0+0k 0+0io 40pf+0w
[Book15] lin/test% gfc -Ofast -fwhole-program fatigue.f90
[Book15] lin/test% time a.out > /dev/null
1.643u 0.001s 0:01.64 100.0%    0+0k 0+1io 0pf+0w

(gfortran is 4.9.2 and gfc is 5.0 r218134).

The runtime increase with '-O3 -ffast-math' is ~0.4s between r217816 and
r217833

[Book15] lin/test% /opt/gcc/gcc4.10p-217816p2/bin/gfortran -O3 -ffast-math
-fwhole-program fatigue.f90
[Book15] lin/test% time a.out > /dev/null
2.654u 0.002s 0:02.66 99.6%    0+0k 0+1io 41pf+0w
[Book15] lin/test% /opt/gcc/gcc4.10p-217833p1/bin/gfortran -O3 -ffast-math
-fwhole-program fatigue.f90
[Book15] lin/test% time a.out > /dev/null
2.962u 0.001s 0:02.97 99.6%    0+0k 0+1io 39pf+0w

> Can you bisect the regressions to a single commit?

I can do it for the range r217816-r217833 (the candidates are r217824 and
r217827, may be r217828 also). As indicated by the p? in my coding scheme, I
cannot bootstrap in the range r216631-r216747 without at least two patches, so
bisecting this range will take much longer.

[Bug middle-end/64101] GCC considers that the erf math function does not set errno

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64101

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |x86_64-*-*, mips64-none-elf
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-11-28
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
I think the issue is that you don't use the result of erf() and the function
is marked as 'const' - thus does not use ATTR_MATHFN_FPROUNDING_ERRNO.
If you make 'res' global then it will work.

[Bug middle-end/64101] GCC considers that the erf math function does not set errno

[niva at niisi dot msk.ru]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64101

--- Comment #2 from niva at niisi dot msk.ru ---
Please explain why erf is marked as 'const' and
does not use ATTR_MATHFN_FPROUNDING_ERRNO? 
ISO C does not say that erf may not set errno. 
And POSIX directly requires that erf, erff, erfl 
set errno=ERANGE in case of underflow.

Here is another example:

#include <stdio.h>
#include <errno.h>
#include <math.h>

extern double res;
int main ()
{
   errno = 0;
   res = erf (-1.2553634935946022721708238314E-308);
   printf ("errno=%d, res=%g\n", errno, res);
   return 0;
}

As a result of

    mips64-none-elf-gcc -O1 -S tst2_erf.c -o tst2_erf.s

the following code is generated:

main:
    ...
    addiu    $sp,$sp,-40
    sd    $31,32($sp)
    sw    $0,%gp_rel(errno)($28)
    jal    erf
    ldc1    $f12,%gp_rel($LC0)($28)

    sdc1    $f0,%gp_rel(res)($28)
    lui    $4,%hi($LC1)    # printf arg 0: format line
    addiu    $4,$4,%lo($LC1)
    dmfc1    $6,$f0        # printf arg 2: res
    jal    printf
    move    $5,$0        #! printf arg 1: zero (must be errno)

    move    $2,$0
    ld    $31,32($sp)
    j    $31
    addiu    $sp,$sp,40

Zero ($0) is passed to printf instead of errno.
If -fno-builtin-printf is used the compiler generates

    lw    $5,%gp_rel(errno)($28)

instead of 

    move    $5,$0

in the delay slot after "jal  printf".





В Птн, 28/11/2014 в 13:24 +0000, rguenth at gcc dot gnu.org пишет:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64101
> 
> Richard Biener <rguenth at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Target|                            |x86_64-*-*, mips64-none-elf
>              Status|UNCONFIRMED                 |NEW
>    Last reconfirmed|                            |2014-11-28
>      Ever confirmed|0                           |1
> 
> --- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
> I think the issue is that you don't use the result of erf() and the function
> is marked as 'const' - thus does not use ATTR_MATHFN_FPROUNDING_ERRNO.
> If you make 'res' global then it will work.
>
>From gcc-bugs-return-469034-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Dec 01 11:30:53 2014
Return-Path: <gcc-bugs-return-469034-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 4892 invoked by alias); 1 Dec 2014 11:30:53 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 4854 invoked by uid 48); 1 Dec 2014 11:30:49 -0000
From: "trippels at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/64128] Let vector take advantage of malloc_usable_size for malloc-using allocators
Date: Mon, 01 Dec 2014 11:30:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 4.8.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: trippels at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-64128-4-gvzWJRyt59@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64128-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64128-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-12/txt/msg00041.txt.bz2
Content-length: 589

https://gcc.gnu.org/bugzilla/show_bug.cgi?idd128

Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |trippels at gcc dot gnu.org

--- Comment #3 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
Or LD_PRELOAD a different malloc implementation like llalloc or tcmalloc.
llalloc (http://locklessinc.com/articles/allocator_tricks/) for example,
speeds up the testcase by 36% on my machine.

[Bug middle-end/64101] GCC considers that the erf math function does not set errno

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64101

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|NEW                         |RESOLVED

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
Recent glibc documents

       These functions do not set errno.

(and in fact they do not).  GCC does not elide the erf() call with -O0 which is
how you can verify your erf implementation sets or does not set errno, at -O1
GCC elides the erf call as the result is unused.

According to Joseph glibcs behavior is correct and so is then GCCs.