[Bug target/59379] New: gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm

[Bug target/59379] New: gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm

[hjl.tools at gmail dot com]

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

            Bug ID: 59379
           Summary: gomp_init_num_threads is compiled into an infinite
                    loop with --with-arch=corei7  --with-cpu=slm
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hjl.tools at gmail dot com
                CC: areg.melikadamyan at gmail dot com

On Linux/x86-64, when GCC revision 205645 configured with

--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--enable-languages=c,c++,fortran,java,lto,objc,obj-c++,go  --prefix=/usr/local
--enable-gnu-indirect-function --disable-werror
--with-build-config=bootstrap-lto --with-fpmath=sse --with-arch=corei7 
--with-cpu=slm

is bootstrapped with "make profiledbootstrap", gomp_init_num_threads
is compiled into an infinite loop:

(gdb) next
90      gomp_cpusetp = (cpu_set_t *) gomp_malloc (gomp_cpuset_size);
(gdb) 
106            if (CPU_ISSET_S (i - 1, gomp_cpuset_size, gomp_cpusetp))
(gdb) 
90      gomp_cpusetp = (cpu_set_t *) gomp_malloc (gomp_cpuset_size);
(gdb) 
106            if (CPU_ISSET_S (i - 1, gomp_cpuset_size, gomp_cpusetp))
(gdb) 
90      gomp_cpusetp = (cpu_set_t *) gomp_malloc (gomp_cpuset_size);
(gdb) 
106            if (CPU_ISSET_S (i - 1, gomp_cpuset_size, gomp_cpusetp))
(gdb) 
90      gomp_cpusetp = (cpu_set_t *) gomp_malloc (gomp_cpuset_size);
(gdb) 
106            if (CPU_ISSET_S (i - 1, gomp_cpuset_size, gomp_cpusetp))
(gdb) 
90      gomp_cpusetp = (cpu_set_t *) gomp_malloc (gomp_cpuset_size);
(gdb) 
106            if (CPU_ISSET_S (i - 1, gomp_cpuset_size, gomp_cpusetp))
(gdb) 
90      gomp_cpusetp = (cpu_set_t *) gomp_malloc (gomp_cpuset_size);
(gdb) 
106            if (CPU_ISSET_S (i - 1, gomp_cpuset_size, gomp_cpusetp))
(gdb) 
90      gomp_cpusetp = (cpu_set_t *) gomp_malloc (gomp_cpuset_size);
(gdb) 
106            if (CPU_ISSET_S (i - 1, gomp_cpuset_size, gomp_cpusetp))
(gdb) 

Stage3 GCC is miscompiled.

[Bug target/59379] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm

[octoploid at yandex dot com]

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

Markus Trippelsdorf <octoploid at yandex dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |octoploid at yandex dot com

--- Comment #1 from Markus Trippelsdorf <octoploid at yandex dot com> ---
Maybe a dup of Bug59003?

[Bug target/59379] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu <hjl.tools at gmail dot com> ---
Symptom is msgfmt never stops:

30751 pts/0    t     43:26 msgfmt -o de.mo
/export/gnu/import/git/gcc/libstdc++-
30752 pts/0    R     64:42 msgfmt -o fr.mo
/export/gnu/import/git/gcc/libstdc++-

(gdb) info shared
>From                To                  Syms Read   Shared Object Library
0x0000003039808780  0x0000003039832a98  Yes (*)    
/lib64/libgettextsrc-0.18.2.so
0x000000303941aad0  0x000000303948179c  Yes (*)    
/lib64/libgettextlib-0.18.2.so
0x000000303e408d10  0x000000303e426ea8  Yes (*)     /lib64/libcroco-0.6.so.3
0x000000303901a260  0x00000030390af89c  Yes (*)     /lib64/libglib-2.0.so.0
0x0000003cf6606d50  0x0000003cf6620164  Yes (*)     /lib64/libncurses.so.5
0x0000003cf4a0ce40  0x0000003cf4a188d8  Yes (*)     /lib64/libtinfo.so.5
0x0000003cf4610160  0x0000003cf4643ad0  Yes (*)     /lib64/libunistring.so.0
0x0000003cdda1f410  0x0000003cddb6269f  Yes (*)     /lib64/libc.so.6
0x00007f570fecc380  0x00007f570fed9467  Yes        
/export/build/gnu/gcc-lto-fdo/build-x86_64-linux/x86_64-unknown-linux-gnu/libgomp/.libs/libgomp.so.1
0x0000003cdde05790  0x0000003cdde103b1  Yes (*)     /lib64/libpthread.so.0
0x0000003ce2a2e870  0x0000003ce2b15060  Yes (*)     /lib64/libxml2.so.2
0x0000003cde200ed0  0x0000003cde2019ce  Yes (*)     /lib64/libdl.so.2
0x0000003cdd600ae0  0x0000003cdd61ac5a  Yes (*)     /lib64/ld-linux-x86-64.so.2
0x0000003cdea02170  0x0000003cdea0e5f0  Yes (*)     /lib64/libz.so.1
0x0000003ce1602f30  0x0000003ce16187a0  Yes (*)     /lib64/liblzma.so.5
0x0000003cde6054b0  0x0000003cde66fbb6  Yes (*)     /lib64/libm.so.6
(*): Shared library is missing debugging information.
(gdb)

[Bug target/59379] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Markus Trippelsdorf from comment #1)
> Maybe a dup of Bug59003?

Maybe.

[Bug target/59379] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu <hjl.tools at gmail dot com> ---
Created attachment 31372
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31372&action=edit
A testcase

The outputs from stage 2 and stage 3 cc1 are different:

[hjl@gnu-mic-2 pr59379]$ make
/export/build/gnu/gcc-lto-fdo/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-lto-fdo/build-x86_64-linux/gcc/
-ftls-model=initial-exec -fPIC -O2 -S test.c
/export/build/gnu/gcc-lto-fdo/build-x86_64-linux/prev-gcc/xgcc
-B/export/build/gnu/gcc-lto-fdo/build-x86_64-linux/prev-gcc/
-ftls-model=initial-exec -fPIC -O2 -S -o good.s test.c
diff -up test.s good.s
--- test.s    2013-12-03 16:38:50.413067359 -0800
+++ good.s    2013-12-03 16:38:50.473066316 -0800
@@ -27,7 +27,7 @@ gomp_init_num_threads:
     movq    %rdi, gomp_cpuset_size(%rip)
     call    gomp_malloc@PLT
     .p2align 4,,15
-.L24:
+.L27:
     movq    %rax, gomp_cpusetp(%rip)
     movq    %rax, %rbx
 .L2:
@@ -40,9 +40,9 @@ gomp_init_num_threads:
     xorl    %eax, %eax
     call    pthread_getaffinity_np@PLT
     testl    %eax, %eax
-    je    .L27
+    je    .L30
     cmpl    $22, %eax
-    jne    .L25
+    jne    .L28
     movq    gomp_cpuset_size(%rip), %rsi
     cmpq    $127, %rsi
     ja    .L10
@@ -64,8 +64,8 @@ gomp_init_num_threads:
     movq    gomp_cpusetp(%rip), %rdi
     call    realloc@PLT
     testq    %rax, %rax
-    jne    .L24
-.L25:
+    jne    .L27
+.L28:
     movq    gomp_global_icv@GOTPCREL(%rip), %rbx
 .L4:
     movq    gomp_cpusetp(%rip), %rdi
@@ -88,7 +88,7 @@ gomp_init_num_threads:
     ret
     .p2align 4,,7
     .p2align 3
-.L27:
+.L30:
     .cfi_restore_state
     movq    gomp_cpusetp(%rip), %rsi
     movq    gomp_cpuset_size(%rip), %rdi
@@ -98,35 +98,31 @@ gomp_init_num_threads:
     testq    %rax, %rax
     movq    %rax, (%rbx)
     je    .L4
-    movq    gomp_cpuset_size(%rip), %rdi
-    movq    %rdi, gomp_get_cpuset_size(%rip)
-    salq    $3, %rdi
+    movq    gomp_cpuset_size(%rip), %rsi
+    movq    %rsi, gomp_get_cpuset_size(%rip)
+    salq    $3, %rsi
     je    .L14
-    movq    %rdi, %r8
-    movq    %rdi, %rsi
-    movq    gomp_cpusetp(%rip), %r9
-    negq    %r8
-    salq    $32, %r8
-    jmp    .L6
+    movq    gomp_cpusetp(%rip), %rdi
+    movq    %rsi, %rdx
+    jmp    .L8
     .p2align 4,,7
     .p2align 3
-.L8:
-    testq    %rdx, %rdx
-    je    .L5
 .L7:
-    movq    %rcx, %rsi
+    testq    %rcx, %rcx
+    je    .L5
 .L6:
-    leaq    -1(%rsi), %rcx
-    leaq    (%rcx,%r8), %rdx
-    cmpq    %rdx, %rdi
-    jbe    .L7
+    movq    %rcx, %rdx
+.L8:
+    leaq    -1(%rdx), %rcx
+    cmpq    %rcx, %rsi
+    jbe    .L6
     movq    %rcx, %rax
     shrq    $6, %rax
-    movq    (%r9,%rax,8), %rax
+    movq    (%rdi,%rax,8), %rax
     shrq    %cl, %rax
     andl    $1, %eax
-    je    .L8
-    leaq    63(%rsi), %rax
+    je    .L7
+    leaq    63(%rdx), %rax
     shrq    $6, %rax
     salq    $3, %rax
 .L5:
make: *** [all] Error 1

[Bug target/59379] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-12-04
     Ever confirmed|0                           |1

--- Comment #5 from H.J. Lu <hjl.tools at gmail dot com> ---
The difference starts in ivopts pass:

diff -upr good/test.c.120t.ivopts bad/test.c.120t.ivopts
--- good/test.c.120t.ivopts    2013-12-03 16:46:21.995210047 -0800
+++ bad/test.c.120t.ivopts    2013-12-03 16:46:34.847986232 -0800
@@ -13,6 +13,7 @@ gomp_init_num_threads ()
   long unsigned int _13;
   long unsigned int gomp_cpuset_size.2_14;
   void * gomp_cpusetp.3_17;
+  long unsigned int _19;
   long unsigned int gomp_cpuset_size.1_20;
   int _22;
   long unsigned int gomp_cpuset_size.1_25;
@@ -39,6 +40,7 @@ gomp_init_num_threads ()
   struct cpu_set_t * prephitmp_89;
   struct cpu_set_t * prephitmp_90;
   long unsigned int pretmp_91;
+  long unsigned int _92;
   long unsigned int pretmp_93;
   long unsigned int pretmp_95;
   long unsigned int prephitmp_96;
@@ -93,7 +95,9 @@ gomp_init_num_threads ()
   <bb 8>:
   # i_76 = PHI <i_48(12), i_47(7)>
   i_48 = i_76 + 18446744073709551615;
-  if (i_47 > i_48)
+  _92 = i_47 * 18446744069414584320;
+  i_94 = i_48 + _92;
+  if (i_47 > i_94)
     goto <bb 9>;
   else
     goto <bb 11>;
@@ -118,7 +122,9 @@ gomp_init_num_threads ()
   goto <bb 13>;

   <bb 11>:
-  if (i_48 != 0)
+  _19 = i_47 * 18446744069414584320;
+  i_69 = _19 + i_48;
+  if (i_69 != 0)
     goto <bb 12>;
   else
     goto <bb 13>;

[Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|gomp_init_num_threads is    |[4.9 Regression]
                   |compiled into an infinite   |gomp_init_num_threads is
                   |loop with                   |compiled into an infinite
                   |--with-arch=corei7          |loop with
                   |--with-cpu=slm              |--with-arch=corei7
                   |                            |--with-cpu=slm

--- Comment #6 from H.J. Lu <hjl.tools at gmail dot com> ---
It was introduced between r203047 and r203817.

[Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm

[hjl.tools at gmail dot com]

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

--- Comment #7 from H.J. Lu <hjl.tools at gmail dot com> ---
r202807 can bootstrap.  But r202811 failed with

[hjl@gnu-mic-2 libgcc]$
/export/build/gnu/gcc-lto-fdo/build-x86_64-linux/./gcc/xgcc
-B/export/build/gnu/gcc-lto-fdo/build-x86_64-linux/./gcc/
-B/usr/local/x86_64-unknown-linux-gnu/bin/
-B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/local/x86_64-unknown-linux-gnu/include -isystem
/usr/local/x86_64-unknown-linux-gnu/sys-include    -g -O2 -m32 -O2  -g -O2
-DIN_GCC   -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./include   -fpic -mlong-double-80 -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector   -fpic -mlong-double-80 -I. -I. -I../../.././gcc
-I/export/gnu/import/git/gcc/libgcc -I/export/gnu/import/git/gcc/libgcc/.
-I/export/gnu/import/git/gcc/libgcc/../gcc
-I/export/gnu/import/git/gcc/libgcc/../include
-I/export/gnu/import/git/gcc/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT
-DHAVE_CC_TLS  -DUSE_TLS -o unwind-dw2-fde-dip.o -MT unwind-dw2-fde-dip.o -MD
-MP -MF unwind-dw2-fde-dip.dep -fexceptions -c
/export/gnu/import/git/gcc/libgcc/unwind-dw2-fde-dip.c -fvisibility=hidden
-DHIDE_EXPORTS
In file included from
/export/gnu/import/git/gcc/libgcc/unwind-dw2-fde-dip.c:89:0:
/export/gnu/import/git/gcc/libgcc/unwind-dw2-fde.c: In function
‘classify_object_over_fdes’:
/export/gnu/import/git/gcc/libgcc/unwind-dw2-fde.c:660:1: internal compiler
error: Segmentation fault
 }
 ^
0x5eb5ce crash_signal
    /export/gnu/import/git/gcc/gcc/toplev.c:335
0x931cb3 htab_find_slot_with_hash
    /export/gnu/import/git/gcc/libiberty/hashtab.c:655
0x931cb3 gen_rtx_CONST_INT
    /export/gnu/import/git/gcc/gcc/emit-rtl.c:410
0x931cb3 gen_int_mode
    /export/gnu/import/git/gcc/gcc/emit-rtl.c:420
0x931cb3 get_mode_bounds(machine_mode, int, machine_mode, rtx_def**, rtx_def**)
    /export/gnu/import/git/gcc/gcc/stor-layout.c:2840
0x95245e simplify_const_relational_operation(rtx_code, machine_mode, rtx_def*,
rtx_def*)
    /export/gnu/import/git/gcc/gcc/simplify-rtx.c:5151
0x9525ab simplify_const_relational_operation(rtx_code, machine_mode, rtx_def*,
rtx_def*)
    /export/gnu/import/git/gcc/gcc/simplify-rtx.c:5006
0x95b364 simplify_relational_operation(rtx_code, machine_mode, machine_mode,
rtx_def*, rtx_def*)
    /export/gnu/import/git/gcc/gcc/simplify-rtx.c:4602
0x7a6dd2 fold_rtx
    /export/gnu/import/git/gcc/gcc/cse.c:3378
0x7a7046 fold_rtx
    /export/gnu/import/git/gcc/gcc/cse.c:3209
0x7aa6aa cse_insn
    /export/gnu/import/git/gcc/gcc/cse.c:4578
0x7af736 cse_extended_basic_block
    /export/gnu/import/git/gcc/gcc/cse.c:6410
0x7af736 cse_main(rtx_def*, int) [clone .isra.18]
    /export/gnu/import/git/gcc/gcc/cse.c:6588
0xf5394b rest_of_handle_cse
    /export/gnu/import/git/gcc/gcc/cse.c:7438
0xf5394b (anonymous namespace)::pass_cse::execute() [clone .lto_priv.9491]
    /export/gnu/import/git/gcc/gcc/cse.c:7484
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

The only difference in GCC source is:

diff --git a/gcc/DATESTAMP b/gcc/DATESTAMP
index 0f54f2b..b7c5255 100644
--- a/gcc/DATESTAMP
+++ b/gcc/DATESTAMP
@@ -1 +1 @@
-20130920
+20130921
>From gcc-bugs-return-436687-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Dec 04 23:53:41 2013
Return-Path: <gcc-bugs-return-436687-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 7014 invoked by alias); 4 Dec 2013 23:53:41 -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 6967 invoked by uid 48); 4 Dec 2013 23:53:38 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/59388] [4.7/4.8/4.9 Regression] ICE on valid code at -O1 and above on x86_64-linux-gnu
Date: Wed, 04 Dec 2013 23:53: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: jakub at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc short_desc
Message-ID: <bug-59388-4-1rNqHT7vZV@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59388-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59388-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-12/txt/msg00342.txt.bz2
Content-length: 681

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org
            Summary|[4.9 Regression] ICE on     |[4.7/4.8/4.9 Regression]
                   |valid code at -O1 and above |ICE on valid code at -O1
                   |on x86_64-linux-gnu         |and above on
                   |                            |x86_64-linux-gnu

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Likely introduced in r179388.

[Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm

[hjl.tools at gmail dot com]

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

--- Comment #8 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to H.J. Lu from comment #7)
> r202807 can bootstrap.  But r202811 failed with
> 
> The only difference in GCC source is:
> 
> diff --git a/gcc/DATESTAMP b/gcc/DATESTAMP
> index 0f54f2b..b7c5255 100644
> --- a/gcc/DATESTAMP
> +++ b/gcc/DATESTAMP
> @@ -1 +1 @@
> -20130920
> +20130921

This may not be related to this bug.

[Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm

[rguenth at gcc dot gnu.org]

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

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

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

[Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm

[hjl.tools at gmail dot com]

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

--- Comment #9 from H.J. Lu <hjl.tools at gmail dot com> ---
A small run-time testcase.  It went into an finite loop at -O.

---
[hjl@gnu-mic-2 pr59379]$ cat main.c 
#include <stdlib.h>
typedef unsigned long int __cpu_mask;
void *
__attribute__((malloc, noinline))
gomp_malloc (size_t s)
{
  return malloc (s);
}
typedef struct
{
  __cpu_mask __bits[1024 / (8 * sizeof (__cpu_mask))];
} cpu_set_t;
unsigned long gomp_cpuset_size __attribute__ ((visibility ("hidden")));
cpu_set_t *gomp_cpusetp __attribute__ ((visibility ("hidden")));
static unsigned long gomp_get_cpuset_size;
void
__attribute__ ((noinline))
gomp_init_num_threads (void)
{
  gomp_cpuset_size = 8;
  gomp_cpusetp = (cpu_set_t *) gomp_malloc (gomp_cpuset_size);
  do
    {
      gomp_get_cpuset_size = gomp_cpuset_size;
      unsigned long i;
      for (i = gomp_cpuset_size * 8; i; i--)
    if ((__extension__
         ({ size_t __cpu = (i - 1);
          __cpu < 8 * (gomp_cpuset_size)
          ? ((((const __cpu_mask *) ((gomp_cpusetp)->__bits))[((__cpu) / (8 *
sizeof (__cpu_mask)))] & ((__cpu_mask) 1 << ((__cpu) % (8 * sizeof
(__cpu_mask)))))) != 0
          : 0;
          })))
      break;
      gomp_cpuset_size = ((((i) + (8 * sizeof (__cpu_mask)) - 1) / (8 * sizeof
(__cpu_mask))) * sizeof (__cpu_mask));
      return;
    }
  while (1);
}
int
main ()
{
  gomp_init_num_threads ();
  return 0;
}
[hjl@gnu-mic-2 pr59379]$ make run
/export/build/gnu/gcc-lto-fdo/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-lto-fdo/build-x86_64-linux/gcc/ -O -o x main.c
./x
make: *** wait: No child processes.  Stop.
make: *** Waiting for unfinished jobs....
make: *** wait: No child processes.  Stop.
---

[Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

[Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm

[izamyatin at gmail dot com]

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

--- Comment #10 from Igor Zamyatin <izamyatin at gmail dot com> ---
I could build profiled bootstrap for r204980 successfully

[Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm

[hjl.tools at gmail dot com]

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

--- Comment #11 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Igor Zamyatin from comment #10)
> I could build profiled bootstrap for r204980 successfully

Is that possible to find a testcase?

[Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm

[hjl.tools at gmail dot com]

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

--- Comment #12 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Igor Zamyatin from comment #10)
> I could build profiled bootstrap for r204980 successfully

It isn't about profiled bootstrap.  It is about "make check" in
libgomp.  All libgomp tests go into an infinite loop.  It still
happens with r206208.

[Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm

[izamyatin at gmail dot com]

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

--- Comment #13 from Igor Zamyatin <izamyatin at gmail dot com> ---
I meant that with 3-stage gcc of r204980 testcase from the attachment was
compiled and ran successfully, i.e. no infinite loop.

Currently debugging shows that routine mul_double_wide_with_sign (which is
actually inlined into aff_combination_scale) from double_int.c is miscompiled:
in one case for a bad revision new_coef got value which is different from the
value for new_coef for r204980

[Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm

[izamyatin at gmail dot com]

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

--- Comment #14 from Igor Zamyatin <izamyatin at gmail dot com> ---
I meant new_coef from aff_combination_scale

[Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

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

--- Comment #15 from H.J. Lu <hjl.tools at gmail dot com> ---
The problem is in ix86_split_lea_for_addr.  For LEA operation with
SImode_address_operand, which zero-extends SImode to DImode, it turns

(set (reg:DI) ...)

into

(set (reg:SI) ...)

We need to do

(set (reg:DI) (zero_extend:DI (reg:SI)))

at the end:

---
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index ff210c8..5ceccdf 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -18375,7 +18375,7 @@ ix86_split_lea_for_addr (rtx insn, rtx operands[], enum
machine_mode mode)
         ix86_emit_binop (PLUS, mode, target, parts.disp);

           ix86_emit_binop (PLUS, mode, target, tmp1);
-          return;
+          goto check_mode;
         }

       ix86_emit_binop (PLUS, mode, target, tmp);
@@ -18384,6 +18384,13 @@ ix86_split_lea_for_addr (rtx insn, rtx operands[],
enum machine_mode mode)
       if (parts.disp && parts.disp != const0_rtx)
     ix86_emit_binop (PLUS, mode, target, parts.disp);
     }
+
+check_mode:
+  if (mode != GET_MODE (operands[0]))
+    {
+      gcc_assert (mode == SImode && GET_MODE (operands[0]) == DImode);
+      emit_insn (gen_zero_extendsidi2 (operands[0], target));
+    }
 }

 /* Return true if it is ok to optimize an ADD operation to LEA
---

Or we can avoid splitting LEA for SImode_address_operand by

---
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 954bbed..e5e6e12 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -5415,10 +5415,11 @@
   else 
     return "lea{<imodesuffix>}\t{%E1, %0|%0, %E1}";
 }
-  "reload_completed && ix86_avoid_lea_for_addr (insn, operands)" 
+  "reload_completed
+   && !SImode_address_operand (operands[1], VOIDmode)
+   && ix86_avoid_lea_for_addr (insn, operands)" 
   [(const_int 0)]
 {
-  enum machine_mode mode = <MODE>mode;
   rtx pat;

   /* ix86_avoid_lea_for_addr re-recognizes insn and may
@@ -5428,12 +5429,7 @@
   operands[0] = SET_DEST (pat);
   operands[1] = SET_SRC (pat);

-  /* Emit all operations in SImode for zero-extended addresses.  Recall
-     that x86_64 inheretly zero-extends SImode operations to DImode.  */
-  if (SImode_address_operand (operands[1], VOIDmode))
-    mode = SImode;
-
-  ix86_split_lea_for_addr (curr_insn, operands, mode);
+  ix86_split_lea_for_addr (curr_insn, operands, <MODE>mode);
   DONE;
 }
   [(set_attr "type" "lea")
---

Either patch fixes the problem.

[Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm

[ubizjak at gmail dot com]

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

--- Comment #16 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to H.J. Lu from comment #15)

> Either patch fixes the problem.

I prefer first patch. It splits all LEAs, where ix86_avoid_lea_for_addr is
true.
>From gcc-bugs-return-440851-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Jan 18 20:01:31 2014
Return-Path: <gcc-bugs-return-440851-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 16926 invoked by alias); 18 Jan 2014 20:01:31 -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 16887 invoked by uid 48); 18 Jan 2014 20:01:28 -0000
From: "hjl.tools at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7  --with-cpu=slm
Date: Sat, 18 Jan 2014 20:01: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.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hjl.tools at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-59379-4-mrn9QqUkw2@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59379-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59379-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: 2014-01/txt/msg01993.txt.bz2
Content-length: 1311

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

--- Comment #17 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Uroš Bizjak from comment #16)
> (In reply to H.J. Lu from comment #15)
> 
> > Either patch fixes the problem.
> 
> I prefer first patch. It splits all LEAs, where ix86_avoid_lea_for_addr is
> true.

Then we should avoid the extra

(set (reg:DI) (zero_extend:DI (reg:SI)))

by

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index ff210c8..346b0cb 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -18342,6 +18342,23 @@ ix86_split_lea_for_addr (rtx insn, rtx operands[],
enum machine_mode mode)
     }
   else
     {
+      if (mode != GET_MODE (operands[0]))
+    {
+      gcc_assert (mode == SImode && GET_MODE (operands[0]) == DImode);
+      if ((!parts.disp || parts.disp == const0_rtx)
+          && ((parts.base && !parts.index)
+          || (!parts.base && parts.index)))
+        {
+          if (parts.base)
+        emit_insn (gen_zero_extendsidi2 (operands[0],
+                         parts.base));
+          else
+        emit_insn (gen_zero_extendsidi2 (operands[0],
+                         parts.index));
+          return;
+        }
+    }
+
       if (!parts.base)
     {
       if (regno0 != regno2)
>From gcc-bugs-return-440852-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Jan 18 20:06:07 2014
Return-Path: <gcc-bugs-return-440852-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 21958 invoked by alias); 18 Jan 2014 20:06: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 21912 invoked by uid 55); 18 Jan 2014 20:06:01 -0000
From: "mikael at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/58007] [4.7/4.9 Regression] [OOP] ICE in free_pi_tree(): Unresolved fixup - resolve_fixups does not fixup component of __class_bsr_Bsr_matrix
Date: Sat, 18 Jan 2014 20:06: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.7.2
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: major
X-Bugzilla-Who: mikael at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P4
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.7.4
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-58007-4-O91DCBIIrO@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58007-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58007-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-01/txt/msg01994.txt.bz2
Content-length: 1157

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

--- Comment #13 from Mikael Morin <mikael at gcc dot gnu.org> ---
Author: mikael
Date: Sat Jan 18 20:05:25 2014
New Revision: 206759

URL: http://gcc.gnu.org/viewcvs?rev 6759&root=gcc&view=rev
Log:
fortran/
        PR fortran/58007
        * module.c (MOD_VERSION): Bump.
        (fp2, find_pointer2): Remove.
        (mio_component_ref): Don't forcedfully set the containing derived type
        symbol for loading.  Remove unused argument.
        (mio_ref): Update caller
        (mio_symbol): Dump component list earlier.
        (skip_list): New argument nest_level.  Initialize level with the new
        argument.
        (read_module): Add forced pointer components association for derived
        type symbols.

testsuite/
        PR fortran/58007
        * gfortran.dg/unresolved_fixup_1.f90: New test.
        * gfortran.dg/unresolved_fixup_2.f90: New test.


Added:
    trunk/gcc/testsuite/gfortran.dg/unresolved_fixup_1.f90
    trunk/gcc/testsuite/gfortran.dg/unresolved_fixup_2.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/module.c
    trunk/gcc/testsuite/ChangeLog

[Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm

[ubizjak at gmail dot com]

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

--- Comment #18 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to H.J. Lu from comment #17)

> > I prefer first patch. It splits all LEAs, where ix86_avoid_lea_for_addr is
> > true.
> 
> Then we should avoid the extra
> 
> (set (reg:DI) (zero_extend:DI (reg:SI)))

ree pass, located just after post-reload split, should handle this extra
zero-extend insn. Based on this fact, we can just slap a zero-extend insn at
the end of sequence with:

--cut here--
Index: config/i386/i386.md
===================================================================
--- config/i386/i386.md (revision 206753)
+++ config/i386/i386.md (working copy)
@@ -5428,12 +5428,17 @@
   operands[0] = SET_DEST (pat);
   operands[1] = SET_SRC (pat);

-  /* Emit all operations in SImode for zero-extended addresses.  Recall
-     that x86_64 inheretly zero-extends SImode operations to DImode.  */
+  /* Emit all operations in SImode for zero-extended addresses.  */
   if (SImode_address_operand (operands[1], VOIDmode))
     mode = SImode;

   ix86_split_lea_for_addr (curr_insn, operands, mode);
+
+  /* Zero-extend return register to DImode for zero-extended addresses.  */
+  if (mode != <MODE>mode)
+    emit_insn (gen_zero_extendsidi2
+              (operands[0], gen_lowpart ((mode), operands[0])));
+
   DONE;
 }
   [(set_attr "type" "lea")
--cut here--

I have checked that this patch with the testcase from Comment #9, using "-O
-march=corei7 -mtune=slm" compile options. The resulting binary worked OK.
>From gcc-bugs-return-440882-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Jan 19 10:03:59 2014
Return-Path: <gcc-bugs-return-440882-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 4527 invoked by alias); 19 Jan 2014 10:03:58 -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 4489 invoked by uid 48); 19 Jan 2014 10:03:53 -0000
From: "paolo.carlini at oracle dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/59867] Template string literal loses first symbol
Date: Sun, 19 Jan 2014 10:03: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:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: paolo.carlini at oracle dot com
X-Bugzilla-Status: NEW
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:
Message-ID: <bug-59867-4-ouCF3eXYOU@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59867-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59867-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-01/txt/msg02024.txt.bz2
Content-length: 189

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

--- Comment #9 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Tuesday works for me ;) Seriously, thanks for looking into this.

[Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm

[hjl.tools at gmail dot com]

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

--- Comment #19 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Uroš Bizjak from comment #18)
> I have checked that this patch with the testcase from Comment #9, using "-O
> -march=corei7 -mtune=slm" compile options. The resulting binary worked OK.

Yes, the resulting GCC works correctly.  However, we generate
extra

(set (reg:DI) (zero_extend:DI (reg:SI)))

It is because we generate

(set (reg:SI) (reg:SI)
(set (reg:DI) (zero_extend:DI (reg:SI)))

REE pass doesn't know

(set (reg:SI) (reg:SI)

has an implicit ZERO_EXTEND.  Here is a testcase:

---foo.c---
extern __thread unsigned int __bid_IDEC_glbflags;
typedef unsigned long long UINT64;
typedef __attribute__ ((aligned(16))) struct
{
  UINT64 w[2];
} UINT128;
extern UINT64 __bid64_from_uint64 (UINT64);
extern void __bid_round64_2_18 (int q,
                int x,
                UINT64 C,
                UINT64 * ptr_Cstar,
                int *delta_exp,
                int *ptr_is_midpoint_lt_even,
                int *ptr_is_midpoint_gt_even,
                int *ptr_is_inexact_lt_midpoint,
                int *ptr_is_inexact_gt_midpoint);
extern void __bid_round128_19_38 (int q,
                  int x,
                  UINT128 C,
                  UINT128 * ptr_Cstar,
                  int *delta_exp,
                  int *ptr_is_midpoint_lt_even,
                  int *ptr_is_midpoint_gt_even,
                  int *ptr_is_inexact_lt_midpoint,
                  int *ptr_is_inexact_gt_midpoint);
UINT64
__bid64_from_uint64 (UINT64 x)
{
  UINT64 res;
  UINT128 x128, res128;
  unsigned int q, ind;
  int incr_exp = 0;
  int is_midpoint_lt_even = 0, is_midpoint_gt_even = 0;
  int is_inexact_lt_midpoint = 0, is_inexact_gt_midpoint = 0;
  if (x <= 0x002386F26FC0ffffull) {
    if (x < 0x0020000000000000ull) {
      res = 0x31c0000000000000ull | x;
    } else {
      res = 0x6c70000000000000ull | (x & 0x0007ffffffffffffull);
    }
  }
  else
    {
      if (x < 0x16345785d8a0000ull) {
    q = 17;
    ind = 1;
      } else if (x < 0xde0b6b3a7640000ull) {
    q = 18;
    ind = 2;
      } else if (x < 0x8ac7230489e80000ull) {
    q = 19;
    ind = 3;
      } else {
    q = 20;
    ind = 4;
      }
      if (q <= 19) {
    __bid_round64_2_18 (
                q, ind, x, &res, &incr_exp,
                &is_midpoint_lt_even, &is_midpoint_gt_even,
                &is_inexact_lt_midpoint, &is_inexact_gt_midpoint);
      }
      else {
    x128.w[1] = 0x0;
    x128.w[0] = x;
    __bid_round128_19_38 (q, ind, x128, &res128, &incr_exp,
                  &is_midpoint_lt_even, &is_midpoint_gt_even,
                  &is_inexact_lt_midpoint, &is_inexact_gt_midpoint);
    res = res128.w[0];
      }
      if (incr_exp)
    ind++;
      if (is_inexact_lt_midpoint || is_inexact_gt_midpoint ||
      is_midpoint_lt_even || is_midpoint_gt_even)
    *&__bid_IDEC_glbflags |= 0x00000020;
      if (res < 0x0020000000000000ull) {
    res = (((UINT64) ind + 398) << 53) | res;
      } else
    {
      res = 0x6000000000000000ull | (((UINT64) ind + 398) << 51) |
        (res & 0x0007ffffffffffffull);
    }
    }
  return(res);;
}
-----------

Compiling with -fPIC -O2, the differences between your patch and mine
are

--- bad.s    2014-01-19 06:10:28.006570325 -0800
+++ foo.s    2014-01-19 06:11:46.117754696 -0800
@@ -84,19 +84,18 @@ __bid64_from_uint64:
     movabsq    $9007199254740991, %rax
     cmpq    %rax, %rbx
     jbe    .L23
-    movl    %ebp, %edx
     leaq    88(%rsp), %rsp
     .cfi_remember_state
     .cfi_def_cfa_offset 24
     movabsq    $2251799813685247, %rax
-    movl    %edx, %edx
+    movl    %ebp, %edx
     andq    %rbx, %rax
-    movabsq    $6917529027641081856, %rcx
     popq    %rbx
     .cfi_def_cfa_offset 16
+    movabsq    $6917529027641081856, %rcx
     addq    $398, %rdx
-    orq    %rcx, %rax
     salq    $51, %rdx
+    orq    %rcx, %rax
     popq    %rbp
     .cfi_def_cfa_offset 8
     orq    %rdx, %rax
@@ -154,7 +153,6 @@ __bid64_from_uint64:
     leaq    88(%rsp), %rsp
     .cfi_remember_state
     .cfi_def_cfa_offset 24
-    movl    %eax, %eax
     addq    $398, %rax
     salq    $53, %rax
     orq    %rbx, %rax

My patch removes 2 extra

(set (reg:DI) (zero_extend:DI (reg:SI)))
>From gcc-bugs-return-440911-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Jan 19 14:48:57 2014
Return-Path: <gcc-bugs-return-440911-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 9605 invoked by alias); 19 Jan 2014 14:48:55 -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 9553 invoked by uid 55); 19 Jan 2014 14:48:50 -0000
From: "rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug other/59862] Code does not compile with 4.8.1 tarball release but compiles with 4.8.1 SVN release
Date: Sun, 19 Jan 2014 14:48:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: other
X-Bugzilla-Version: 4.8.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenther at suse dot de
X-Bugzilla-Status: WAITING
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:
Message-ID: <bug-59862-4-kfZFfiMHbl@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59862-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59862-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-01/txt/msg02053.txt.bz2
Content-length: 896

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

--- Comment #7 from rguenther at suse dot de <rguenther at suse dot de> ---
On Sun, 19 Jan 2014, dominiq at lps dot ens.fr wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?idY862
>
> --- Comment #6 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> > The release tarball contain generated files so you don't need tools like
> > flex or makeinfo to build GCC.  Those are not present in SVN, so this is
> > definitely not a packaging bug.
>
> Not sure to understand: gcc/gengtype-lex.c is in the tarball, but not in SVN.
> From the above I understand that gcc/gengtype-lex.c should also not be in the
> tarball.

No, it is in the tarball so building does not require the tools to
build it.

> Is this correct? What could be the effect of gcc/gengtype-lex.c?

That local flex is not used to build gengtype-lex.c from gengtype-lex.l

[Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm

[uros at gcc dot gnu.org]

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

--- Comment #20 from uros at gcc dot gnu.org ---
Author: uros
Date: Sun Jan 19 15:48:14 2014
New Revision: 206774

URL: http://gcc.gnu.org/viewcvs?rev=206774&root=gcc&view=rev
Log:
    PR target/59379
    * config/i386/i386.md (*lea<mode>): Zero-extend return register
    to DImode for zero-extended addresses.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/i386.md

[Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm

[uros at gcc dot gnu.org]

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

--- Comment #21 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Jan 22 18:28:30 2014
New Revision: 206934

URL: http://gcc.gnu.org/viewcvs?rev=206934&root=gcc&view=rev
Log:
    Backport from mainline
    2014-01-20  Uros Bizjak  <ubizjak@gmail.com>

    * config/i386/i386.c (ix86_avoid_lea_for_addr): Return false
    for SImode_address_operand operands, having only a REG argument.

    2014-01-20  Jakub Jelinek  <jakub@redhat.com>

    PR target/59880
    * config/i386/i386.c (ix86_avoid_lea_for_addr): Return false
    if operands[1] is a REG or ZERO_EXTEND of a REG.

    2014-01-18  Uros Bizjak  <ubizjak@gmail.com>
            H.J. Lu  <hongjiu.lu@intel.com>

    PR target/59379
    * config/i386/i386.md (*lea<mode>): Zero-extend return register
    to DImode for zero-extended addresses.


Modified:
    branches/gcc-4_8-branch/gcc/ChangeLog
    branches/gcc-4_8-branch/gcc/config/i386/i386.c
    branches/gcc-4_8-branch/gcc/config/i386/i386.md

[Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm

[ubizjak at gmail dot com]

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

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |x86
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|4.9.0                       |4.8.3

--- Comment #22 from Uroš Bizjak <ubizjak at gmail dot com> ---
Fixed.
>From gcc-bugs-return-441231-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jan 22 18:56:11 2014
Return-Path: <gcc-bugs-return-441231-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 18902 invoked by alias); 22 Jan 2014 18:56:11 -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 18872 invoked by uid 48); 22 Jan 2014 18:56:07 -0000
From: "paolo.carlini at oracle dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/59482] A friend class cannot inherit a private nested class
Date: Wed, 22 Jan 2014 18:56: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:
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: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution target_milestone
Message-ID: <bug-59482-4-9Ciy3HJ86N@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59482-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59482-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-01/txt/msg02373.txt.bz2
Content-length: 500

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

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

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

--- Comment #3 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Fixed for 4.9.0.