[Bug tree-optimization/57994] New: Constant folding of infinity

[Bug tree-optimization/57994] New: Constant folding of infinity

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994

            Bug ID: 57994
           Summary: Constant folding of infinity
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Keywords: missed-optimization
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: glisse at gcc dot gnu.org

double f(){
  return __builtin_exp(-__builtin_huge_val());
}

As noticed in PR57974, we fail to fold this to a constant. Indeed, in
do_mpfr_arg1, the relevant code is protected by if (real_isfinite (ra) ...

mpfr handles infinite values, so it should be doable, at least with -ffast-math
(there might be some errno issues with default options).

[Bug tree-optimization/57994] Constant folding of infinity

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994

--- Comment #1 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Thanks Marc.

[Bug tree-optimization/57994] Constant folding of infinity

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994

--- Comment #2 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
There are no errno issues - this is an exact zero result, not underflow.  
But I'm not confident that MPFR follows all the Annex F special cases for 
infinities and NaNs (and even less confident in MPC following Annex G), 
and in cases that are errors and should produce exceptions / errno (e.g. 
sin (Inf)) you do of course need to avoid folding.

[Bug tree-optimization/57994] Constant folding of infinity

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-07-27
                 CC|                            |ghazi at gcc dot gnu.org,
                   |                            |jsm28 at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #3 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Oh nice. And if I disable by hand the real_isfinite (ra) check in do_mpfr_arg1
I even get 0. And I also checked what happens for sin(Inf) in that case: a -nan
as before the hack.

Then which is at this point a safe way to proceed? Get in touch with the mpfr
people, ask if simplifying infinities has known issues? Tentatively remove the
real_isfinite checks from one of the do_mpfr_arg? functions at a time, or even
one mathematical function at a time?

[Bug tree-optimization/57994] Constant folding of infinity

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994

--- Comment #5 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Today I was thinking that given that, per docs and testsuite (double checked
yesterday) the mpfr functions are able to cope with +-Inf arguments to the
mathematical functions and evaluate correctly, gating the various do_mpfr_*
with !real_isnan instead of real_isfinite doesn't look like taking a big risk,
now that we are in Stage 1. Alone that would help a lot of code (in particular,
in the C++ library, which is the original motivating example). Note, I'm not
thinking replacing real_isfinite in various other places, in particular not in
do_mpc_* and its helpers (something for the future). Comments?

[Bug tree-optimization/57994] Constant folding of infinity

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994

--- Comment #6 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Paolo Carlini from comment #5)
> Today I was thinking that given that, per docs and testsuite (double checked
> yesterday) the mpfr functions are able to cope with +-Inf arguments to the
> mathematical functions and evaluate correctly, gating the various do_mpfr_*
> with !real_isnan instead of real_isfinite doesn't look like taking a big
> risk, now that we are in Stage 1. Alone that would help a lot of code (in
> particular, in the C++ library, which is the original motivating example).
> Note, I'm not thinking replacing real_isfinite in various other places, in
> particular not in do_mpc_* and its helpers (something for the future).
> Comments?

I haven't looked at that code closely enough to say if there is much that needs
changing. Earlier you said that removing the real_isfinite test replaced
sin(Inf) with NaN. Was that with -ffast-math? Without it, the change shouldn't
happen (not without inserting a few extra statements). I am hoping that there
is already code in place that checks if the mpfr calls set errno and calls
mpfr_overflow_p (and family) for possible exceptions, though I somehow doubt
that we test mpfr_inexflag_p or very little propagation would take place.

[Bug tree-optimization/57994] Constant folding of infinity

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994

--- Comment #7 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
An example of MPC not following all the Annex G special cases is that 
catanh (1 + i0) is specified in Annex G to return Inf + i0 with 
divide-by-zero exception, but at least with my MPC installation it returns 
Inf + iNaN.  I haven't tried to check how MPFR handles special cases; the 
issue with MPC is simply something I noticed incidentally while fixing 
glibc libm handling of various <complex.h> functions.

> I was wondering about that last point. Couldn't we replace:
> 
> x=sin(Inf);
> 
> with:
> 
> x=NaN;
> errno=EDOM; // only if flag_math_errno

errno is typically a macro....

> volatile double f=NaN+NaN; // if flag_trapping_math, something to raise invalid
> (make sure we don't recursively try to propagate the constant there, so maybe
> the NaN argument should be volatile)

I think you mean 0.0 / 0.0 or Inf - Inf or similar; NaN+NaN doesn't raise 
an exception if the NaNs are quiet NaNs.

[Bug tree-optimization/57994] Constant folding of infinity

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994

--- Comment #8 from Paolo Carlini <paolo.carlini at oracle dot com> ---
About sin(Inf): I checked that with / without the real_isfinite the expression
evaluated in every case the same, -nan, if I remember correctly. I don't have
more details at the moment. My general point, again, is that the mpfr testsuite
appears to include test which check that +-inf are correctly handled as
arguments to the mathematical functions. Which, hey, doesn't seem a miracle,
after all ;) Remember, I'm thinking as a start, no-nan, no-complex.

[Bug tree-optimization/57994] Constant folding of infinity

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994

--- Comment #9 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to joseph@codesourcery.com from comment #7)
> An example of MPC not following all the Annex G special cases is that 
> catanh (1 + i0) is specified in Annex G to return Inf + i0 with 
> divide-by-zero exception, but at least with my MPC installation it returns 
> Inf + iNaN.  I haven't tried to check how MPFR handles special cases; the 
> issue with MPC is simply something I noticed incidentally while fixing 
> glibc libm handling of various <complex.h> functions.

Thanks (I assume you reported it to MPC, so that will be one fewer issue in a
few years :-). I believe there are far fewer special cases (and thus risks)
with MPFR, but that would indeed require a suitable testsuite for all functions
for which we enable it (at least if MPFR doesn't already have such a testsuite,
and maybe even then, to make sure we call it properly).

> > I was wondering about that last point. Couldn't we replace:
> > 
> > x=sin(Inf);
> > 
> > with:
> > 
> > x=NaN;
> > errno=EDOM; // only if flag_math_errno
> 
> errno is typically a macro....

That's why I was mentioning front-end help... There should be ways to set errno
to EDOM faster than calling sin(Inf).

> > volatile double f=NaN+NaN; // if flag_trapping_math, something to raise invalid
> > (make sure we don't recursively try to propagate the constant there, so maybe
> > the NaN argument should be volatile)
> 
> I think you mean 0.0 / 0.0 or Inf - Inf or similar; NaN+NaN doesn't raise 
> an exception if the NaNs are quiet NaNs.

Yeah, any of those. I was inspired by glibc, which has for instance:

double
__fdim (double x, double y)
{
  int clsx = fpclassify (x);
  int clsy = fpclassify (y);

  if (clsx == FP_NAN || clsy == FP_NAN
      || (y < 0 && clsx == FP_INFINITE && clsy == FP_INFINITE))
    /* Raise invalid flag.  */
    return x - y;

which looks like it expects QNaN-QNaN to set the invalid flag.

[Bug tree-optimization/57994] Constant folding of infinity

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994

--- Comment #10 from Paolo Carlini <paolo.carlini at oracle dot com> ---
About testing, it would be just matter of extending/updating what Kaveh Ghazi
set up when mpfr/mpc came in.

[Bug tree-optimization/57994] Constant folding of infinity

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994

--- Comment #11 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Sat, 27 Jul 2013, glisse at gcc dot gnu.org wrote:

> Yeah, any of those. I was inspired by glibc, which has for instance:
> 
> double
> __fdim (double x, double y)
> {
>   int clsx = fpclassify (x);
>   int clsy = fpclassify (y);
> 
>   if (clsx == FP_NAN || clsy == FP_NAN
>       || (y < 0 && clsx == FP_INFINITE && clsy == FP_INFINITE))
>     /* Raise invalid flag.  */
>     return x - y;
> 
> which looks like it expects QNaN-QNaN to set the invalid flag.

Such comments must be understood to be written on the assumption that the 
reader is familiar with the desired IEEE semantics - that is, that the 
flags is raised if and only if a NaN argument is a signaling NaN (and such 
arithmetic patterns on input NaNs, to ensure that "invalid" is raised if 
either NaN is signaling, and otherwise that an input NaN's significand is 
preserved, are very common in glibc).

[Bug tree-optimization/57994] Constant folding of infinity

[vincent-gcc at vinc17 dot net]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 5602 bytes --]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994

--- Comment #12 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to Marc Glisse from comment #9)
> I believe there are far fewer special cases (and thus
> risks) with MPFR, but that would indeed require a suitable testsuite for all
> functions for which we enable it (at least if MPFR doesn't already have such
> a testsuite, and maybe even then, to make sure we call it properly).

MPFR's testsuite is just against the MPFR implementation. These are actually
non-regression tests. For comparisons with the functions from the C library,
there's mpcheck:

  https://gforge.inria.fr/projects/mpcheck/

but I don't know whether it includes special values (it wasn't its goal).

Note that we tried to follow C99's Annex F when this made sense. MPFR also
supports some special functions that are not in ISO C (yet), but may be
provided by the C library on some platforms (e.g. Bessel functions, which are
also specified in POSIX).

Don't forget that the specific rules for signed zeroes are also concerned;
again, we tried to follow C99's Annex F, IIRC, even when the specification was
rather inconsistent (e.g. under the rounding mode toward negative infinity, the
subtraction 1 - 1 returns -0, but log(1) is required to return +0).
>From gcc-bugs-return-426883-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Jul 28 18:18:39 2013
Return-Path: <gcc-bugs-return-426883-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 2465 invoked by alias); 28 Jul 2013 18:18:39 -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 2379 invoked by uid 48); 28 Jul 2013 18:18:35 -0000
From: "jeff.science at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/58016] New: stdatomic.h missing in 4.8.1
Date: Sun, 28 Jul 2013 18:18:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.8.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: blocker
X-Bugzilla-Who: jeff.science at gmail dot com
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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-58016-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: 2013-07/txt/msg01390.txt.bz2
Content-length: 2492

http://gcc.gnu.org/bugzilla/show_bug.cgi?idX016

            Bug ID: 58016
           Summary: stdatomic.h missing in 4.8.1
           Product: gcc
           Version: 4.8.1
            Status: UNCONFIRMED
          Severity: blocker
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jeff.science at gmail dot com

GCC 4.8.1 provides a -stdÁ1 option that defines __STDC_VERSION__ >= 201112L
and does not define __STDC_NO_ATOMICS__, hence is required to provide
stdatomic.h.  This requirement is not met.

This ticket is closely related to 53769 but I am not reporting the fact that
the macros aren't defined, but rather the missing header.

> cat test-c11-atomics.c
#if __STDC_VERSION__ >= 201112L
# ifdef __STDC_NO_ATOMICS__
#  error Your C11 compiler is not required to provide stdatomic.h
# else
#  include <stdatomic.h>
# endif
#else
# error Your C compiler isn't providing C11.
#endif

int main(int argc, char * argv[])
{
    return 0;
}

> gcc-mp-4.8 -g -Wall -stdÁ1 test-c11-atomics.c
test-c11-atomics.c:4:23: fatal error: stdatomic.h: No such file or directory
 #include <stdatomic.h>
                       ^
compilation terminated.

> gcc-mp-4.8 -v
Using built-in specs.
COLLECT_GCC=gcc-mp-4.8
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin11/4.8.1/lto-wrapper
Target: x86_64-apple-darwin11
Configured with: ../gcc-4.8.1/configure --prefix=/opt/local
--build=x86_64-apple-darwin11
--enable-languages=c,c++,objc,obj-c++,lto,fortran,java
--libdir=/opt/local/lib/gcc48 --includedir=/opt/local/include/gcc48
--infodir=/opt/local/share/info --mandir=/opt/local/share/man
--datarootdir=/opt/local/share/gcc-4.8 --with-local-prefix=/opt/local
--with-system-zlib --disable-nls --program-suffix=-mp-4.8
--with-gxx-include-dir=/opt/local/include/gcc48/c++/ --with-gmp=/opt/local
--with-mpfr=/opt/local --with-mpc=/opt/local --with-ppl=/opt/local
--with-cloog=/opt/local --enable-cloog-backend=isl
--disable-cloog-version-check --enable-stage1-checking --disable-multilib
--enable-lto --enable-libstdcxx-time --with-as=/opt/local/bin/as
--with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar
--with-bugurl=https://trac.macports.org/newticket --with-pkgversion='MacPorts
gcc48 4.8.1_0'
Thread model: posix
gcc version 4.8.1 (MacPorts gcc48 4.8.1_0)

> uname -a
Darwin Jeffs-MacBook-Pro.local 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23
16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64

[Bug tree-optimization/57994] Constant folding of infinity

[vincent-gcc at vinc17 dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994

--- Comment #13 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
A difference that may occur in the future if the C library adds a rsqrt
function (based on the IEEE 754-2008 rSqrt function) or constant folding is
used on builtins: in MPFR, mpfr_rec_sqrt on -0 gives +Inf, not -Inf.
>From gcc-bugs-return-427132-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Aug 01 21:26:51 2013
Return-Path: <gcc-bugs-return-427132-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 28184 invoked by alias); 1 Aug 2013 21:26:51 -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 28056 invoked by uid 48); 1 Aug 2013 21:26:46 -0000
From: "burnus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/55207] Automatic deallocation of variables declared in the main program
Date: Thu, 01 Aug 2013 21:26:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.8.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: burnus at gcc dot gnu.org
X-Bugzilla-Status: REOPENED
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-55207-4-h2AGZMOQyn@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-55207-4@http.gcc.gnu.org/bugzilla/>
References: <bug-55207-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: 2013-08/txt/msg00056.txt.bz2
Content-length: 808

http://gcc.gnu.org/bugzilla/show_bug.cgi?idU207

Tobias Burnus <burnus at gcc dot gnu.org> changed:

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

--- Comment #11 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to janus from comment #10)
> Created attachment 30584 [details]
> new patch

+  if ((gfc_current_state () == COMP_MODULE
+       || gfc_current_state () == COMP_PROGRAM)

I haven't tried the patch, but does it work correctly with BLOCK? (It might
well be valid.) For instance, "i" in the following code shouldn't acquire the
SAVE attribute:

  program main
    block
      integer :: i
    end block
  end program main

[Bug tree-optimization/57994] Constant folding of infinity

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |paolo.carlini at oracle dot com
   Target Milestone|---                         |4.9.0

--- Comment #14 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Let's see.

[Bug tree-optimization/57994] Constant folding of infinity

[vincent-gcc at vinc17 dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994

--- Comment #15 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
If GCC intends to handle Bessel functions j0, j1, jn, y0, y1, yn (POSIX), there
may be differences with GNU MPFR. See my messages and bug report:
  http://permalink.gmane.org/gmane.comp.standards.posix.austin.general/7982
  http://permalink.gmane.org/gmane.comp.standards.posix.austin.general/7990
  http://sourceware.org/bugzilla/show_bug.cgi?id=15901
>From gcc-bugs-return-428479-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Aug 27 17:49:15 2013
Return-Path: <gcc-bugs-return-428479-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 17830 invoked by alias); 27 Aug 2013 17:49:15 -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 17761 invoked by uid 48); 27 Aug 2013 17:49:12 -0000
From: "bernd.edlinger at hotmail dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/56933] [4.9 Regression] Vectorizer missing read-write dependency for interleaved accesses
Date: Tue, 27 Aug 2013 17:49:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: bernd.edlinger at hotmail dot de
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-56933-4-PYJO7TjcQE@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-56933-4@http.gcc.gnu.org/bugzilla/>
References: <bug-56933-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: 2013-08/txt/msg01403.txt.bz2
Content-length: 1258

http://gcc.gnu.org/bugzilla/show_bug.cgi?idV933

--- Comment #6 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
(In reply to Jakub Jelinek from comment #5)
> (In reply to Bernd Edlinger from comment #4)
> The test case
> gcc.dg/vect/pr56933.c fails on a pentium II,
> because of invalid
> instruction.
>
> A fairly obvious fix (which works for me) would be:

There
> is nothing obvious on it (maybe obviously broken).
The vect.exp tests aren't
> i?86/x86_64 only, so you definitely can't add
unguarded requirements for
> specific CPUs, it would cause the test not to be run on ppcs/arm/etc.

The
> bug in this test is that it specifies { dg-do run }, either it shouldn't
> (then the default will be run if CPU supports the -msse2 flags in this case,
> or
compile otherwise), or it should use the tree-vect.h + check_vect ()
> framework like many other tests.

Oh I thought that it is only for x86...

The problem is that the option -msse2 is somehow used to compile this
and therfore the following statement is generated.

       movapd  .LC4, %xmm0

I do not see how this test case can test anything unless it scans
the assembler output for this instruction. Maybe there is something
special in the -fdump-tree-xxx that should be looked for?

[Bug tree-optimization/57994] Constant folding of infinity

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994

--- Comment #16 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Uhm, something isn't going as planned. If I change that check in do_mpfr_arg1
to
!real_isnan (ra), then we always fold __builtin_expl(-__builtin_huge_vall()) to
an exact 0.

However, with *both* -fno-math-errno -funsafe-math-optimizations we don't fold
the kind of code we really care about:

  type num = __builtin_logl(0.0L);
  type res = __builtin_expl(num);

and res turns out to be -nan :( Probably the problem has to do with the log,
not sure yet.

[Bug tree-optimization/57994] Constant folding of infinity

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994

--- Comment #17 from Paolo Carlini <paolo.carlini at oracle dot com> ---
If I play with some constexprs, I understand that, irrespective of the command
line switches, we never fold to a constant the log. However, only for
-fno-math-errno -funsafe-math-optimizations the library call returns -nan,
instead of 0. Ok..

For the log, the check at the beginning of do_mpfr_arg1:

      if (!real_isnan (ra)
      && (!min || real_compare (inclusive ? GE_EXPR: GT_EXPR , ra, min))
      && (!max || real_compare (inclusive ? LE_EXPR: LT_EXPR , ra, max)))

is false, because real_compare (inclusive ? GE_EXPR: GT_EXPR , ra, min) is
false. It seems we never fold log(0).

[Bug tree-optimization/57994] Constant folding of infinity

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994

--- Comment #18 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Now the question is: why we use a library call for log(0) instead of mpfr?

[Bug tree-optimization/57994] Constant folding of infinity

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994

--- Comment #19 from Paolo Carlini <paolo.carlini at oracle dot com> ---
If I change fold_builtin_logarithm to pass a true as last argument to
do_mpfr_arg1 (thus 0 is accepted) and do_mpfr_ckconv to accept a folded result
which is infinity, things finally work. Patchlet below. Note however, that I
also need -O1 otherwise, at -O0, we don't try to propagate the constant num and
mpfr isn't used, we again have a library call which returns -nan.

Index: builtins.c
===================================================================
--- builtins.c    (revision 204005)
+++ builtins.c    (working copy)
@@ -8191,7 +8191,7 @@ fold_builtin_logarithm (location_t loc, tree fndec
       const enum built_in_function fcode = builtin_mathfn_code (arg);

       /* Calculate the result when the argument is a constant.  */
-      if ((res = do_mpfr_arg1 (arg, type, func, &dconst0, NULL, false)))
+      if ((res = do_mpfr_arg1 (arg, type, func, &dconst0, NULL, true)))
     return res;

       /* Special case, optimize logN(expN(x)) = x.  */
@@ -13527,7 +13527,7 @@ do_mpfr_ckconv (mpfr_srcptr m, tree type, int inex
   /* Proceed iff we get a normal number, i.e. not NaN or Inf and no
      overflow/underflow occurred.  If -frounding-math, proceed iff the
      result of calling FUNC was exact.  */
-  if (mpfr_number_p (m) && !mpfr_overflow_p () && !mpfr_underflow_p ()
+  if (!mpfr_nan_p (m) && !mpfr_overflow_p () && !mpfr_underflow_p ()
       && (!flag_rounding_math || !inexact))
     {
       REAL_VALUE_TYPE rr;
@@ -13537,7 +13537,7 @@ do_mpfr_ckconv (mpfr_srcptr m, tree type, int inex
      check for overflow/underflow.  If the REAL_VALUE_TYPE is zero
      but the mpft_t is not, then we underflowed in the
      conversion.  */
-      if (real_isfinite (&rr)
+      if (!real_isnan (&rr)
       && (rr.cl == rvc_zero) == (mpfr_zero_p (m) != 0))
         {
       REAL_VALUE_TYPE rmode;
@@ -13623,7 +13623,7 @@ do_mpfr_arg1 (tree arg, tree type, int (*func)(mpf
     {
       const REAL_VALUE_TYPE *const ra = &TREE_REAL_CST (arg);

-      if (real_isfinite (ra)
+      if (!real_isnan (ra)
       && (!min || real_compare (inclusive ? GE_EXPR: GT_EXPR , ra, min))
       && (!max || real_compare (inclusive ? LE_EXPR: LT_EXPR , ra, max)))
         {

[Bug tree-optimization/57994] Constant folding of infinity

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994

--- Comment #20 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Thus I clearly realize something: if we do better for mpfr, the issue remains
that if we do *not* optimize and constants are not propagated, we issue library
calls, which, for command line switches like -fno-math-errno
-funsafe-math-optimizations give incorrect nan result.

In other terms, I'm still more than willing to work on mpfr-related
improvements, but I'm still not convinced that when constants are not at issue
we are really ok with those nans... Note again, in case isn't clear already,
that for this kind of snippet I never managed to see nans with clang/icc.

About mpfr, I would appreciate feedback that I'm on the right track. Thanks!

[Bug tree-optimization/57994] Constant folding of infinity

[vincent-gcc at vinc17 dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994

--- Comment #21 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to Paolo Carlini from comment #19)
> If I change fold_builtin_logarithm to pass a true as last argument to
> do_mpfr_arg1 (thus 0 is accepted) and do_mpfr_ckconv to accept a folded
> result which is infinity, things finally work. Patchlet below. Note however,
> that I also need -O1 otherwise, at -O0, we don't try to propagate the
> constant num and mpfr isn't used, we again have a library call which returns
> -nan.

I don't know much about GCC internals, but did you think about exceptions, e.g.
FE_DIVBYZERO for log(0)?

Note that MPFR's divide-by-zero exception (flag) and associated functions are
new in MPFR 3.1.0.

> @@ -13527,7 +13527,7 @@ do_mpfr_ckconv (mpfr_srcptr m, tree type, int inex
>    /* Proceed iff we get a normal number, i.e. not NaN or Inf and no
>       overflow/underflow occurred.  If -frounding-math, proceed iff the
>       result of calling FUNC was exact.  */
> -  if (mpfr_number_p (m) && !mpfr_overflow_p () && !mpfr_underflow_p ()
> +  if (!mpfr_nan_p (m) && !mpfr_overflow_p () && !mpfr_underflow_p ()
>        && (!flag_rounding_math || !inexact))
[...]

If you do this, don't forget to update the comment. Ditto for the other
changes.
>From gcc-bugs-return-432625-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Oct 24 15:34:08 2013
Return-Path: <gcc-bugs-return-432625-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 15056 invoked by alias); 24 Oct 2013 15:34:08 -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 15006 invoked by uid 48); 24 Oct 2013 15:34:05 -0000
From: "ebotcazou at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/58831] [4.8/4.9 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu in 64-bit mode
Date: Thu, 24 Oct 2013 15:34:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ebotcazou at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: ebotcazou at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.3
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc assigned_to
Message-ID: <bug-58831-4-ZvJI8gYzJ7@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58831-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58831-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: 2013-10/txt/msg01769.txt.bz2
Content-length: 1665

http://gcc.gnu.org/bugzilla/show_bug.cgi?idX831

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|ebotcazou at gcc dot gnu.org       |
           Assignee|unassigned at gcc dot gnu.org      |ebotcazou at gcc dot gnu.org

--- Comment #6 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
Looking into it.  The non-deterministic behavior is cured by:

Index: recog.c
==================================================================--- recog.c    (revision 203876)
+++ recog.c    (working copy)
@@ -3068,6 +3068,9 @@ peep2_reg_dead_p (int ofs, rtx reg)
   return 1;
 }

+/* Regno offset to be used in the register search.  */
+static int search_ofs;
+
 /* Try to find a hard register of mode MODE, matching the register class in
    CLASS_STR, which is available at the beginning of insn CURRENT_INSN and
    remains available until the end of LAST_INSN.  LAST_INSN may be NULL_RTX,
@@ -3083,7 +3086,6 @@ rtx
 peep2_find_free_register (int from, int to, const char *class_str,
               enum machine_mode mode, HARD_REG_SET *reg_set)
 {
-  static int search_ofs;
   enum reg_class cl;
   HARD_REG_SET live;
   df_ref *def_rec;
@@ -3548,6 +3550,7 @@ peephole2_optimize (void)
   /* Initialize the regsets we're going to use.  */
   for (i = 0; i < MAX_INSNS_PER_PEEP2 + 1; ++i)
     peep2_insn_data[i].live_before = BITMAP_ALLOC (&reg_obstack);
+  search_ofs = 0;
   live = BITMAP_ALLOC (&reg_obstack);

   FOR_EACH_BB_REVERSE (bb)

but there is something wrong in the alias.c machinery as well.

[Bug tree-optimization/57994] Constant folding of infinity

[vincent-gcc at vinc17 dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994

--- Comment #22 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to Paolo Carlini from comment #20)
> Thus I clearly realize something: if we do better for mpfr, the issue
> remains that if we do *not* optimize and constants are not propagated, we
> issue library calls, which, for command line switches like -fno-math-errno
> -funsafe-math-optimizations give incorrect nan result.

Where does this nan come from? Do you mean that log(0) from the library gives
nan on your machine instead of the correct -inf? For any 0 (as 0 is signed)?
Are you sure that there is really a library call?
>From gcc-bugs-return-432627-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Oct 24 15:50:01 2013
Return-Path: <gcc-bugs-return-432627-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 30760 invoked by alias); 24 Oct 2013 15:50:01 -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 30720 invoked by uid 48); 24 Oct 2013 15:49:57 -0000
From: "burnus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/58861] Realloc on assignment: Bogus "Array bound mismatch" error with -fcheck=bounds
Date: Thu, 24 Oct 2013 15:50:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.8.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: burnus 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: keywords cc short_desc
Message-ID: <bug-58861-4-z4il2xJCuq@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58861-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58861-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: 2013-10/txt/msg01771.txt.bz2
Content-length: 959

http://gcc.gnu.org/bugzilla/show_bug.cgi?idX861

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
                 CC|                            |burnus at gcc dot gnu.org
            Summary|No reallocation assignment  |Realloc on assignment:
                   |performed (due to different |Bogus "Array bound
                   |kinds?)                     |mismatch" error with
                   |                            |-fcheck=bounds

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> ---
I can confirm the error message. However, the array seems to be properly
allocated. Only -fcheck=bounds seems to mishandle this case. (There might be
other PRs about this issue.)

Thus, as work around: Don't compile that file with -fcheck=bounds.

[Bug tree-optimization/57994] Constant folding of infinity

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994

--- Comment #23 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Thanks. I'm sending to the mailing list an updated version, which only proceeds
with do_mpfr_arg1 when !flag_trapping_math && !flag_errno_math.

About the -nan, yes by now we know well that if we don't use mpfr at compile
time, __builtin_expl(-inf) for -fno-math-errno -funsafe-math-optimizations
returns -nan. I think Uros has an explanation why long double is special (in
PR57974)

[Bug tree-optimization/57994] Constant folding of infinity

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.0                       |4.9.1

--- Comment #24 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.0 has been released

[Bug tree-optimization/57994] Constant folding of infinity

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.1                       |4.9.2

--- Comment #25 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.1 has been released.

[Bug tree-optimization/57994] Constant folding of infinity

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.2                       |4.9.3

--- Comment #26 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.2 has been released.

[Bug tree-optimization/57994] Constant folding of infinity

[jakub at gcc dot gnu.org]

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

--- Comment #27 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.3 has been released.

[Bug tree-optimization/57994] Constant folding of infinity

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.3                       |4.9.4

[Bug tree-optimization/57994] Constant folding of infinity

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.4                       |---