[Bug c++/57484] 'std::numeric_limits< T >::signaling_NaN()' signaling-bit is incorrect for x86 32-bit.

[Bug c++/57484] 'std::numeric_limits< T >::signaling_NaN()' signaling-bit is incorrect for x86 32-bit.

[daniel.kruegler at googlemail dot com]

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

--- Comment #1 from Daniel Krügler <daniel.kruegler at googlemail dot com> ---
I haven't checked your bit arithmetics, but I have checked the full bit
patterns of the resulting NaNs in hex on my mingw-64 bit system. What I'm
getting for are the following results:

1) gcc 4.7.2/4.9.0 20130519 (experimental) -m32:

Signaling NaN's of "f" is 7fa00000
Quiet     NaN's of "f" is 7fc00000
Signaling NaN's of "d" is 7ff4000000000000
Quiet     NaN's of "d" is 7ff8000000000000

2) gcc 4.7.2/4.9.0 20130519 (experimental) -m64:

Signaling NaN's of "f" is 7fa00000
Quiet     NaN's of "f" is 7fc00000
Signaling NaN's of "d" is 7ff4000000000000
Quiet     NaN's of "d" is 7ff8000000000000

All values look consistent with valid sNaN/qNaN patterns according to the
ranges listed here:

http://www.doc.ic.ac.uk/~eedwards/compsys/float/nan.html

What are the full bit patterns that you get by printing the
signaling_NaN.bits/quiet_NaN.bits values in hex?
>From gcc-bugs-return-423599-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri May 31 19:32:06 2013
Return-Path: <gcc-bugs-return-423599-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 3737 invoked by alias); 31 May 2013 19:32:05 -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 3638 invoked by uid 48); 31 May 2013 19:32:00 -0000
From: "tromey at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug debug/57487] New: vterminate.cc local variable optimized out
Date: Fri, 31 May 2013 19:32:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: debug
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: tromey 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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-57487-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-05/txt/msg02272.txt.bz2
Content-length: 1207

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

            Bug ID: 57487
           Summary: vterminate.cc local variable optimized out
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
          Assignee: unassigned at gcc dot gnu.org
          Reporter: tromey at gcc dot gnu.org

I built git master gcc today (317121db1372a50999ab1cba75aa59df0f2eff7c)
using the default arguments on my x86-64 Fedora 18 machine.

Then I compiled this program with the new g++ and ran it in gdb:

int main()
{
  throw 5;
}

Then, at the crash, I went up until I was in the verbose terminate
handler frame.  At this point I looked at the locals:

#2  0x00007ffff7d59515 in __gnu_cxx::__verbose_terminate_handler ()
    at ../../../../gcc/libstdc++-v3/libsupc++/vterminate.cc:95
95        abort();
(gdb) info local
terminating = true
t = <optimized out>


Here, it is unfortunate that 't' is optimized out.  If it were
not, then the thrown exception type would be obvious from the stack
trace.  As it is, this information is written to stderr but otherwise
lost -- for example, ABRT cannot easily pick it up.

[Bug c++/57484] 'std::numeric_limits< T >::signaling_NaN()' signaling-bit is incorrect for x86 32-bit.

[zxClhzAApX1EdJwQANqrjLERmFeURQVy at cynd dot net]

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

Charles L. Wilcox <zxClhzAApX1EdJwQANqrjLERmFeURQVy at cynd dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #30234|0                           |1
        is obsolete|                            |

--- Comment #2 from Charles L. Wilcox <zxClhzAApX1EdJwQANqrjLERmFeURQVy at cynd dot net> ---
Created attachment 30239
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30239&action=edit
Updated test code to print out the full signaling and quiet NaN's values in
hex.

[Bug c++/57484] 'std::numeric_limits< T >::signaling_NaN()' signaling-bit is incorrect for x86 32-bit.

[zxClhzAApX1EdJwQANqrjLERmFeURQVy at cynd dot net]

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

--- Comment #3 from Charles L. Wilcox <zxClhzAApX1EdJwQANqrjLERmFeURQVy at cynd dot net> ---
Daniel,

Unfortunately, my initial machine, a laptop, decided to commit seppuku
yesterday.

Fortunately, the disk survived, I ported the code to another machine I have,
and am still seeing similar results there.

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5'
--with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.2 (Debian 4.7.2-5) 


I updated my code to print out the full contents of the NaN values in hex.

My machine produces the following output:

$ g++ -Wall -Wextra test-signaling-nan.cpp -m32
$ ./a.out 
Signaling NaN for type "f" in hex is "7fe00000".
Signaling NaN's signaling-bit status for type "f" is set to "true".
Quiet NaN for type "f" in hex is "7fc00000".
Quiet NaN's signaling-bit status for type "f" is set to "true".
Signaling NaN for type "d" in hex is "7ffc000000000000".
Signaling NaN's signaling-bit status for type "d" is set to "true".
Quiet NaN for type "d" in hex is "7ff8000000000000".
Quiet NaN's signaling-bit status for type "d" is set to "true".

$ g++ -Wall -Wextra test-signaling-nan.cpp -m64
$ ./a.out 
Signaling NaN for type "f" in hex is "7fa00000".
Signaling NaN's signaling-bit status for type "f" is set to "false".
Quiet NaN for type "f" in hex is "7fc00000".
Quiet NaN's signaling-bit status for type "f" is set to "true".
Signaling NaN for type "d" in hex is "7ff4000000000000".
Signaling NaN's signaling-bit status for type "d" is set to "false".
Quiet NaN for type "d" in hex is "7ff8000000000000".
Quiet NaN's signaling-bit status for type "d" is set to "true".

The resulting values on 32-bit vs. 64-bit are different, and I believe the
64-bit values are the correct ones.

[Bug c++/57484] 'std::numeric_limits< T >::signaling_NaN()' signaling-bit is incorrect for x86 32-bit.

[daniel.kruegler at googlemail dot com]

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

--- Comment #4 from Daniel Krügler <daniel.kruegler at googlemail dot com> ---
(In reply to Charles L. Wilcox from comment #3)
> Signaling NaN for type "f" in hex is "7fe00000".

I agree, this one doesn't look right to me, because that looks indeed like a
valid qNaN bit pattern only.

> Quiet NaN for type "f" in hex is "7fc00000".

OK.

> Signaling NaN for type "d" in hex is "7ffc000000000000".

Similar problem here: Only a qNaN

> Quiet NaN for type "d" in hex is "7ff8000000000000".

OK.

> $ g++ -Wall -Wextra test-signaling-nan.cpp -m64

> Signaling NaN for type "f" in hex is "7fa00000".
> Quiet NaN for type "f" in hex is "7fc00000".
> Signaling NaN for type "d" in hex is "7ff4000000000000".
> Quiet NaN for type "d" in hex is "7ff8000000000000".

All OK.

> The resulting values on 32-bit vs. 64-bit are different, and I believe the
> 64-bit values are the correct ones.

I agree.
>From gcc-bugs-return-423648-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Jun 01 17:37:23 2013
Return-Path: <gcc-bugs-return-423648-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 16435 invoked by alias); 1 Jun 2013 17:37:22 -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 16371 invoked by uid 48); 1 Jun 2013 17:37:16 -0000
From: "dominiq at lps dot ens.fr" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/57366] gcc.dg/lto/attr-weakref-1 FAILs
Date: Sat, 01 Jun 2013 17:37: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: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dominiq at lps dot ens.fr
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: hubicka at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-57366-4-VXJGJXFRJh@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57366-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57366-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-06/txt/msg00027.txt.bz2
Content-length: 162

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

--- Comment #15 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Fixed on darwin at revision 199583.

[Bug c++/57484] 'std::numeric_limits< T >::signaling_NaN()' signaling-bit is incorrect for x86 32-bit.

[paolo.carlini at oracle dot com]

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

--- Comment #5 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Just to clarify that this is neither a library neither a C++ front-end issue:
<limits> just uses the various __builtin_nans*

[Bug c++/57484] 'std::numeric_limits< T >::signaling_NaN()' signaling-bit is incorrect for x86 32-bit.

[zxClhzAApX1EdJwQANqrjLERmFeURQVy at cynd dot net]

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

--- Comment #6 from Charles L. Wilcox <zxClhzAApX1EdJwQANqrjLERmFeURQVy at cynd dot net> ---
(In reply to Paolo Carlini from comment #5)
> Just to clarify that this is neither a library neither a C++ front-end
> issue: <limits> just uses the various __builtin_nans*

Paolo,

I guessed this was the case from what I could tell using the debugger, but I
wanted some confirmation that I was correct.  Should the "Component" be changed
from C++ to something else?

[Bug middle-end/57484] 'std::numeric_limits< T >::signaling_NaN()' signaling-bit is incorrect for x86 32-bit.

[zxClhzAApX1EdJwQANqrjLERmFeURQVy at cynd dot net]

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

--- Comment #8 from Charles L. Wilcox <zxClhzAApX1EdJwQANqrjLERmFeURQVy at cynd dot net> ---
FWIW, I tried this with g++ 4.8 on a 32-bit only system I have; it still
produces erroneous sNaN values there:

$ g++-4.8 -v
Using built-in specs.
COLLECT_GCC=g++-4.8
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i486-linux-gnu/4.8/lto-wrapper
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.8.1-1'
--with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-i386/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-i386
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-i386
--with-arch-directory=i386 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-targets=all --enable-multiarch --with-arch-32=i586
--with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release
--build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.8.1 (Debian 4.8.1-1) 
$ g++-4.8 -Wall -Wextra test-signaling-nan.cpp 
$ ./a.out 
Signaling NaN for type "f" in hex is "7fe00000".
Signaling NaN's signaling-bit status for type "f" is set to "true".
Quiet NaN for type "f" in hex is "7fc00000".
Quiet NaN's signaling-bit status for type "f" is set to "true".
Signaling NaN for type "d" in hex is "7ffc000000000000".
Signaling NaN's signaling-bit status for type "d" is set to "true".
Quiet NaN for type "d" in hex is "7ff8000000000000".
Quiet NaN's signaling-bit status for type "d" is set to "true".

[Bug middle-end/57484] 'std::numeric_limits< T >::signaling_NaN()' signaling-bit is incorrect for x86 32-bit.

[zxClhzAApX1EdJwQANqrjLERmFeURQVy at cynd dot net]

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

--- Comment #9 from Charles L. Wilcox <zxClhzAApX1EdJwQANqrjLERmFeURQVy at cynd dot net> ---
So, given a month has gone by, should I expect any response or action on this
bug-report?

[Bug middle-end/57484] 'std::numeric_limits< T >::signaling_NaN()' signaling-bit is incorrect for x86 32-bit.

[paolo.carlini at oracle dot com]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ubizjak at gmail dot com

--- Comment #10 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Maybe Uros can help.

[Bug middle-end/57484] 'std::numeric_limits< T >::signaling_NaN()' signaling-bit is incorrect for x86 32-bit.

[ubizjak at gmail dot com]

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

--- Comment #11 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Paolo Carlini from comment #10)
> Maybe Uros can help.

On an x86 target using the legacy x87 instructions and the 80-bit registers, a
load of a 64-bit or 32-bit value in memory into the 80-bit registers counts as
a format conversion and an signaling NaN input will turn into a quiet NaN in
the register format.
>From gcc-bugs-return-426033-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jul 09 18:44:45 2013
Return-Path: <gcc-bugs-return-426033-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 21428 invoked by alias); 9 Jul 2013 18:44:45 -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 21418 invoked by uid 89); 9 Jul 2013 18:44:45 -0000
X-Spam-SWARE-Status: No, score=2.6 required=5.0 tests=AWL,BAYES_00,FORGED_YAHOO_RCVD,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,TW_AV,TW_MX,URI_HEX autolearn=no version=3.3.1
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)    by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 09 Jul 2013 18:44:44 +0000
Received: from [192.168.236.26] (helo=sam.nabble.com)	by sam.nabble.com with esmtp (Exim 4.72)	(envelope-from <verthex2099@yahoo.com>)	id 1Uwcu2-000703-Ri	for gcc-bugs@gcc.gnu.org; Tue, 09 Jul 2013 11:44:42 -0700
Date: Tue, 09 Jul 2013 18:44:00 -0000
From: gcc_user_666 <verthex2099@yahoo.com>
To: gcc-bugs@gcc.gnu.org
Message-ID: <1373395482793-952132.post@n5.nabble.com>
Subject: Trouble running GCC compiled program using XOP intrinsic instructions?
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-SW-Source: 2013-07/txt/msg00540.txt.bz2
Content-length: 1409

Hi,

I'm getting a seg-fault running this code.

#include <emmintrin.h>
#include <x86intrin.h>
#include <stdio.h>
#include <stdint.h>

void print_2_64_bit_ints(const char * label, __m128i m64_r)
{
    int *val = (int *) &m64_r;
    printf("%s: %d %d\n", label, val[0], val[1]);
}
int main()
{
    __m128i HADDQinput = _mm_set_epi8(4, 3, 2, 1, 8, 7, 5, 3, 7, 6, 5, 4, 9,
0, 3, 3);
    //__m128i RESULT = _mm_haddq_epi8(HADDQinput);
    //_mm_empty();

    //print_2_64_bit_ints("Result ", RESULT);

    return 0;
}

The GCC compiler flags used are -msse3 -msse4 -mxop -mavx and I'm compiling
this with GCC-TDM 4.7.1-2.

If I run the code through GDB it gets up to this line

__m128i HADDQinput = _mm_set_epi8(4, 3, 2, 1, 8, 7, 5, 3, 7, 6, 5, 4, 9, 0,
3, 3);

and it crashes on line 603 in emmintrin.h. I also noticed that this only
occurs if the header x86intrin.h is included otherwise the program exits
fine. I'm using an AMD-8150 FX (Bulldozer) processor with these instructions
available according to CPU-Z (CPUID)

MMX(+), SSE(1,2,3,3S,4.1,4.2,4A), x86-64, AMD-V, AES,AVX,XOP

Someone told me that the fault occurs due to an Intel instruction 'vmovd
xmm0..' using WinDbg.

thanks,

Andrew




--
View this message in context: http://gcc.1065356.n5.nabble.com/Trouble-running-GCC-compiled-program-using-XOP-intrinsic-instructions-tp952132.html
Sent from the gcc - bugs mailing list archive at Nabble.com.

[Bug middle-end/57484] 'std::numeric_limits< T >::signaling_NaN()' signaling-bit is incorrect for x86 32-bit.

[ubizjak at gmail dot com]

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

--- Comment #12 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Uroš Bizjak from comment #11)
> (In reply to Paolo Carlini from comment #10)
> > Maybe Uros can help.
> 
> On an x86 target using the legacy x87 instructions and the 80-bit registers,
> a load of a 64-bit or 32-bit value in memory into the 80-bit registers
> counts as a format conversion and an signaling NaN input will turn into a
> quiet NaN in the register format.

Also, using -msse2 -mfpmath=sse on 32bit target won't help, since 32bit ABI
mandates that FP values are returned in x87 register. Your test will work when
compiled with "-msse2 -mfpmath=sse -mno-fp-ret-in-387". But note that
-mno-fp-ret-in-387 is a compiler option that changes ABI.

The ABI is just wrong for the underlying x87 hardware as far as NaNs are
concerned.
>From gcc-bugs-return-426044-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jul 09 18:55:19 2013
Return-Path: <gcc-bugs-return-426044-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 2384 invoked by alias); 9 Jul 2013 18:55:19 -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 2349 invoked by uid 48); 9 Jul 2013 18:55:17 -0000
From: "jason at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/57415] [4.9 Regression] New PPC testsuite failure C++ compound literarl expr unimplemented
Date: Tue, 09 Jul 2013 18:55:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jason at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: jason at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution target_milestone
Message-ID: <bug-57415-4-QkEN8zGU5r@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57415-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57415-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/msg00551.txt.bz2
Content-length: 476

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

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |4.9.0

--- Comment #4 from Jason Merrill <jason at gcc dot gnu.org> ---
Fixed.

[Bug middle-end/57484] 'std::numeric_limits< T >::signaling_NaN()' signaling-bit is incorrect for x86 32-bit.

[paolo.carlini at oracle dot com]

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

--- Comment #13 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Thanks Uros, you are providing plenty of detaild which I largely ignored. Thus,
realistically, do you think this issue is largely unfixable?

[Bug middle-end/57484] 'std::numeric_limits< T >::signaling_NaN()' signaling-bit is incorrect for x86 32-bit.

[ubizjak at gmail dot com]

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

--- Comment #14 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Paolo Carlini from comment #13)
> Thanks Uros, you are providing plenty of detaild which I largely ignored.
> Thus, realistically, do you think this issue is largely unfixable?

This issue is unfortunately unfixable. x87 and x86-32 ABI are just not designed
to handle all details of IEEE 754 standard.
>From gcc-bugs-return-426054-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jul 09 20:22:35 2013
Return-Path: <gcc-bugs-return-426054-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 20612 invoked by alias); 9 Jul 2013 20:22:35 -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 20551 invoked by uid 48); 9 Jul 2013 20:22:32 -0000
From: "paolo.carlini at oracle dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/57870] Internal compiler error in use of emplace
Date: Tue, 09 Jul 2013 20:22:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.7.3
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: paolo.carlini at oracle dot com
X-Bugzilla-Status: RESOLVED
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_status resolution
Message-ID: <bug-57870-4-mnHqKk4eiS@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57870-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57870-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/msg00561.txt.bz2
Content-length: 499

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |DUPLICATE

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

*** This bug has been marked as a duplicate of bug 57086 ***

[Bug middle-end/57484] 'std::numeric_limits< T >::signaling_NaN()' signaling-bit is incorrect for x86 32-bit.

[paolo.carlini at oracle dot com]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #15 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Ok, thanks.

[Bug target/57484] 'std::numeric_limits< T >::signaling_NaN()' signaling-bit is incorrect for x86 32-bit.

[zxClhzAApX1EdJwQANqrjLERmFeURQVy at cynd dot net]

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

Charles L. Wilcox <zxClhzAApX1EdJwQANqrjLERmFeURQVy at cynd dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #30239|0                           |1
        is obsolete|                            |

--- Comment #16 from Charles L. Wilcox <zxClhzAApX1EdJwQANqrjLERmFeURQVy at cynd dot net> ---
Created attachment 30487
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30487&action=edit
Expanded unit-test code to set signaling-NaN values via 'union' aliasing.

Adding code to demonstrate how to generate a signaling-NaN using the existing
ABI along with the "return through the x87 register" restriction.

[Bug target/57484] 'std::numeric_limits< T >::signaling_NaN()' signaling-bit is incorrect for x86 32-bit.

[zxClhzAApX1EdJwQANqrjLERmFeURQVy at cynd dot net]

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

--- Comment #17 from Charles L. Wilcox <zxClhzAApX1EdJwQANqrjLERmFeURQVy at cynd dot net> ---
Okay... so why not avoid the x87 restriction and use aliasing to load the
correct value?

I've updated my example to show how I was doing exactly this for some unit-test
code I created.

[Bug target/57484] 'std::numeric_limits< T >::signaling_NaN()' signaling-bit is incorrect for x86 32-bit.

[ubizjak at gmail dot com]

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

--- Comment #18 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Charles L. Wilcox from comment #17)
> Okay... so why not avoid the x87 restriction and use aliasing to load the
> correct value?

Load to x87 stack? The very moment sNaN gets loaded (using fldl or flds) will
be converted to qNaN. You can do some trick here (and the compiler can pass FP
value in integer registers), but there is no guarantee that the value won't
move through x87 stack registers.
>From gcc-bugs-return-426060-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jul 09 21:59:50 2013
Return-Path: <gcc-bugs-return-426060-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 16620 invoked by alias); 9 Jul 2013 21:59:50 -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 16576 invoked by uid 48); 9 Jul 2013 21:59:47 -0000
From: "jason at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/57471] [4.9 Regression] Bizarre error for template parameter pack
Date: Tue, 09 Jul 2013 21:59:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: rejects-valid
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jason at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: jason at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution
Message-ID: <bug-57471-4-FFe3QVZviF@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57471-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57471-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/msg00567.txt.bz2
Content-length: 432

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

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #2 from Jason Merrill <jason at gcc dot gnu.org> ---
Fixed by r200852.

[Bug target/57484] 'std::numeric_limits< T >::signaling_NaN()' signaling-bit is incorrect for x86 32-bit.

[zxClhzAApX1EdJwQANqrjLERmFeURQVy at cynd dot net]

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

--- Comment #19 from Charles L. Wilcox <zxClhzAApX1EdJwQANqrjLERmFeURQVy at cynd dot net> ---
(In reply to Uroš Bizjak from comment #11)
> On an x86 target using the legacy x87 instructions and the 80-bit registers,
> a load of a 64-bit or 32-bit value in memory into the 80-bit registers
> counts as a format conversion and an signaling NaN input will turn into a
> quiet NaN in the register format.

Does this mean if a 80-bit sNaN was generated and loaded into a register it was
still have the signaling bit set correctly?  And if so, could this value then
be down-converted to a 32 or 64-bit float?  In C++:
    float float32_snan const
      = static_cast< float >( std::numeric_limits< long double
>::signaling_NaN() );
    double float64_snan const
      = static_cast< double >( std::numeric_limits< long double
>::signaling_NaN() );
Or, is the "cast" here a format conversion, causing the signaling NaN to
convert to a quiet NAN?
>From gcc-bugs-return-426090-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jul 10 11:56:06 2013
Return-Path: <gcc-bugs-return-426090-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 9250 invoked by alias); 10 Jul 2013 11:56:06 -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 9218 invoked by uid 48); 10 Jul 2013 11:56:03 -0000
From: "sebastian.huber@embedded-brains.de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/57865] Broken _save64gpr and _rest64gpr usage
Date: Wed, 10 Jul 2013 11:56:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.8.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: sebastian.huber@embedded-brains.de
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: amodra at gmail dot com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-57865-4-bp34NyX7kJ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57865-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57865-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/msg00597.txt.bz2
Content-length: 377

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

--- Comment #5 from Sebastian Huber <sebastian.huber@embedded-brains.de> ---
(In reply to Alan Modra from comment #4)
> Created attachment 30489 [details]
> Fix ool_adjust
>
> Please verify that this fixes the problem

Yes, your patch fixes also the problem if applied to the 4.8 head.

Thanks a lot for the quick response.

[Bug target/57484] 'std::numeric_limits< T >::signaling_NaN()' signaling-bit is incorrect for x86 32-bit.

[ubizjak at gmail dot com]

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

--- Comment #20 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Charles L. Wilcox from comment #19)
> (In reply to Uroš Bizjak from comment #11)
> > On an x86 target using the legacy x87 instructions and the 80-bit registers,
> > a load of a 64-bit or 32-bit value in memory into the 80-bit registers
> > counts as a format conversion and an signaling NaN input will turn into a
> > quiet NaN in the register format.
> 
> Does this mean if a 80-bit sNaN was generated and loaded into a register it
> was still have the signaling bit set correctly?  And if so, could this value

80-bit load is not considered as a format conversion, so signalling bit will be
set correctly.

> then be down-converted to a 32 or 64-bit float?  In C++:
>     float float32_snan const
>       = static_cast< float >( std::numeric_limits< long double
> >::signaling_NaN() );
>     double float64_snan const
>       = static_cast< double >( std::numeric_limits< long double
> >::signaling_NaN() );
> Or, is the "cast" here a format conversion, causing the signaling NaN to
> convert to a quiet NAN?

I don't know the c++ details, but compiler can spill the value out from the
register stack using 32- or 64-bit float moves. In any case, signalling bit in
x87 is unreliable and should not be used.
>From gcc-bugs-return-426092-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jul 10 12:11:03 2013
Return-Path: <gcc-bugs-return-426092-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 15102 invoked by alias); 10 Jul 2013 12:11:03 -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 15008 invoked by uid 48); 10 Jul 2013 12:10:57 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug driver/42485] [4.4/4.5/4.6 Regression] -V switch broken
Date: Wed, 10 Jul 2013 12:11:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: driver
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords: patch
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.4.4
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-42485-4-gIufTvD7Z9@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-42485-4@http.gcc.gnu.org/bugzilla/>
References: <bug-42485-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-07/txt/msg00599.txt.bz2
Content-length: 751

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

--- Comment #10 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Michael Matz from comment #9)that it isn't anymore ;-)
> 
> Well, too bad, I guess.

I am not sure of the exact details but unless the path itself is hard-coded,
you could always put a fake gcc, to be found in the path before the real gcc, 
that parses -V VERSION and calls the correct gcc. It should be a few lines of
shell (or another scripting language). Another alternative is to make gcc a
symlink to the actual gcc-VERSION. Yet another may be shell aliases, but I am
not sure if that works for Makefiles.

The -V switch was not working so it wouldn't have helped your user anyway.
>From gcc-bugs-return-426093-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jul 10 12:20:33 2013
Return-Path: <gcc-bugs-return-426093-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 21703 invoked by alias); 10 Jul 2013 12:20:32 -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 21648 invoked by uid 48); 10 Jul 2013 12:20:28 -0000
From: "mikpe at it dot uu.se" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/57861] wrong code at -O3 on x86_64-linux-gnu in 32-bit mode
Date: Wed, 10 Jul 2013 12:20: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:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mikpe at it dot uu.se
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-57861-4-YcEXxLgXFI@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57861-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57861-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/msg00600.txt.bz2
Content-length: 456

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

Mikael Pettersson <mikpe at it dot uu.se> changed:

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

--- Comment #1 from Mikael Pettersson <mikpe at it dot uu.se> ---
It's a recent regression, caused by the LRA change in r200723.  Author CCd.