* [Bug target/59379] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm
2013-12-03 21:40 [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
@ 2013-12-03 21:46 ` octoploid at yandex dot com
2013-12-03 21:51 ` hjl.tools at gmail dot com
` (21 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: octoploid at yandex dot com @ 2013-12-03 21:46 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 24+ messages in thread* [Bug target/59379] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm
2013-12-03 21:40 [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
2013-12-03 21:46 ` [Bug target/59379] " octoploid at yandex dot com
@ 2013-12-03 21:51 ` hjl.tools at gmail dot com
2013-12-03 21:52 ` hjl.tools at gmail dot com
` (20 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: hjl.tools at gmail dot com @ 2013-12-03 21:51 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 24+ messages in thread* [Bug target/59379] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm
2013-12-03 21:40 [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
2013-12-03 21:46 ` [Bug target/59379] " octoploid at yandex dot com
2013-12-03 21:51 ` hjl.tools at gmail dot com
@ 2013-12-03 21:52 ` hjl.tools at gmail dot com
2013-12-04 0:41 ` hjl.tools at gmail dot com
` (19 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: hjl.tools at gmail dot com @ 2013-12-03 21:52 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 24+ messages in thread* [Bug target/59379] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm
2013-12-03 21:40 [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
` (2 preceding siblings ...)
2013-12-03 21:52 ` hjl.tools at gmail dot com
@ 2013-12-04 0:41 ` hjl.tools at gmail dot com
2013-12-04 0:48 ` hjl.tools at gmail dot com
` (18 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: hjl.tools at gmail dot com @ 2013-12-04 0:41 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 24+ messages in thread* [Bug target/59379] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm
2013-12-03 21:40 [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
` (3 preceding siblings ...)
2013-12-04 0:41 ` hjl.tools at gmail dot com
@ 2013-12-04 0:48 ` hjl.tools at gmail dot com
2013-12-04 10:52 ` [Bug target/59379] [4.9 Regression] " hjl.tools at gmail dot com
` (17 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: hjl.tools at gmail dot com @ 2013-12-04 0:48 UTC (permalink / raw)
To: gcc-bugs
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>;
^ permalink raw reply [flat|nested] 24+ messages in thread* [Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm
2013-12-03 21:40 [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
` (4 preceding siblings ...)
2013-12-04 0:48 ` hjl.tools at gmail dot com
@ 2013-12-04 10:52 ` hjl.tools at gmail dot com
2013-12-04 23:39 ` hjl.tools at gmail dot com
` (16 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: hjl.tools at gmail dot com @ 2013-12-04 10:52 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 24+ messages in thread* [Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm
2013-12-03 21:40 [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
` (5 preceding siblings ...)
2013-12-04 10:52 ` [Bug target/59379] [4.9 Regression] " hjl.tools at gmail dot com
@ 2013-12-04 23:39 ` hjl.tools at gmail dot com
2013-12-05 3:11 ` hjl.tools at gmail dot com
` (15 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: hjl.tools at gmail dot com @ 2013-12-04 23:39 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 24+ messages in thread* [Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm
2013-12-03 21:40 [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
` (6 preceding siblings ...)
2013-12-04 23:39 ` hjl.tools at gmail dot com
@ 2013-12-05 3:11 ` hjl.tools at gmail dot com
2013-12-05 11:17 ` rguenth at gcc dot gnu.org
` (14 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: hjl.tools at gmail dot com @ 2013-12-05 3:11 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 24+ messages in thread* [Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm
2013-12-03 21:40 [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
` (7 preceding siblings ...)
2013-12-05 3:11 ` hjl.tools at gmail dot com
@ 2013-12-05 11:17 ` rguenth at gcc dot gnu.org
2013-12-06 1:45 ` hjl.tools at gmail dot com
` (13 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-12-05 11:17 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 24+ messages in thread* [Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm
2013-12-03 21:40 [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
` (8 preceding siblings ...)
2013-12-05 11:17 ` rguenth at gcc dot gnu.org
@ 2013-12-06 1:45 ` hjl.tools at gmail dot com
2013-12-19 15:37 ` rguenth at gcc dot gnu.org
` (12 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: hjl.tools at gmail dot com @ 2013-12-06 1:45 UTC (permalink / raw)
To: gcc-bugs
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.
---
^ permalink raw reply [flat|nested] 24+ messages in thread* [Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm
2013-12-03 21:40 [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
` (9 preceding siblings ...)
2013-12-06 1:45 ` hjl.tools at gmail dot com
@ 2013-12-19 15:37 ` rguenth at gcc dot gnu.org
2013-12-26 12:41 ` izamyatin at gmail dot com
` (11 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-12-19 15:37 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 24+ messages in thread* [Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm
2013-12-03 21:40 [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
` (10 preceding siblings ...)
2013-12-19 15:37 ` rguenth at gcc dot gnu.org
@ 2013-12-26 12:41 ` izamyatin at gmail dot com
2013-12-26 12:57 ` hjl.tools at gmail dot com
` (10 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: izamyatin at gmail dot com @ 2013-12-26 12:41 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 24+ messages in thread* [Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm
2013-12-03 21:40 [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
` (11 preceding siblings ...)
2013-12-26 12:41 ` izamyatin at gmail dot com
@ 2013-12-26 12:57 ` hjl.tools at gmail dot com
2013-12-26 14:41 ` hjl.tools at gmail dot com
` (9 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: hjl.tools at gmail dot com @ 2013-12-26 12:57 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 24+ messages in thread* [Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm
2013-12-03 21:40 [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
` (12 preceding siblings ...)
2013-12-26 12:57 ` hjl.tools at gmail dot com
@ 2013-12-26 14:41 ` hjl.tools at gmail dot com
2013-12-30 21:16 ` izamyatin at gmail dot com
` (8 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: hjl.tools at gmail dot com @ 2013-12-26 14:41 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 24+ messages in thread* [Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm
2013-12-03 21:40 [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
` (13 preceding siblings ...)
2013-12-26 14:41 ` hjl.tools at gmail dot com
@ 2013-12-30 21:16 ` izamyatin at gmail dot com
2013-12-31 7:02 ` izamyatin at gmail dot com
` (7 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: izamyatin at gmail dot com @ 2013-12-30 21:16 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 24+ messages in thread* [Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm
2013-12-03 21:40 [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
` (14 preceding siblings ...)
2013-12-30 21:16 ` izamyatin at gmail dot com
@ 2013-12-31 7:02 ` izamyatin at gmail dot com
2014-01-18 17:13 ` hjl.tools at gmail dot com
` (6 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: izamyatin at gmail dot com @ 2013-12-31 7:02 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 24+ messages in thread* [Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm
2013-12-03 21:40 [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
` (15 preceding siblings ...)
2013-12-31 7:02 ` izamyatin at gmail dot com
@ 2014-01-18 17:13 ` hjl.tools at gmail dot com
2014-01-18 19:47 ` ubizjak at gmail dot com
` (5 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: hjl.tools at gmail dot com @ 2014-01-18 17:13 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 24+ messages in thread* [Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm
2013-12-03 21:40 [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
` (16 preceding siblings ...)
2014-01-18 17:13 ` hjl.tools at gmail dot com
@ 2014-01-18 19:47 ` ubizjak at gmail dot com
2014-01-19 9:51 ` ubizjak at gmail dot com
` (4 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: ubizjak at gmail dot com @ 2014-01-18 19:47 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 24+ messages in thread* [Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm
2013-12-03 21:40 [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
` (17 preceding siblings ...)
2014-01-18 19:47 ` ubizjak at gmail dot com
@ 2014-01-19 9:51 ` ubizjak at gmail dot com
2014-01-19 14:18 ` hjl.tools at gmail dot com
` (3 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: ubizjak at gmail dot com @ 2014-01-19 9:51 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 24+ messages in thread* [Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm
2013-12-03 21:40 [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
` (18 preceding siblings ...)
2014-01-19 9:51 ` ubizjak at gmail dot com
@ 2014-01-19 14:18 ` hjl.tools at gmail dot com
2014-01-19 15:48 ` uros at gcc dot gnu.org
` (2 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: hjl.tools at gmail dot com @ 2014-01-19 14:18 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 24+ messages in thread* [Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm
2013-12-03 21:40 [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
` (19 preceding siblings ...)
2014-01-19 14:18 ` hjl.tools at gmail dot com
@ 2014-01-19 15:48 ` uros at gcc dot gnu.org
2014-01-22 18:29 ` uros at gcc dot gnu.org
2014-01-22 18:40 ` ubizjak at gmail dot com
22 siblings, 0 replies; 24+ messages in thread
From: uros at gcc dot gnu.org @ 2014-01-19 15:48 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 24+ messages in thread* [Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm
2013-12-03 21:40 [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
` (20 preceding siblings ...)
2014-01-19 15:48 ` uros at gcc dot gnu.org
@ 2014-01-22 18:29 ` uros at gcc dot gnu.org
2014-01-22 18:40 ` ubizjak at gmail dot com
22 siblings, 0 replies; 24+ messages in thread
From: uros at gcc dot gnu.org @ 2014-01-22 18:29 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 24+ messages in thread* [Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm
2013-12-03 21:40 [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
` (21 preceding siblings ...)
2014-01-22 18:29 ` uros at gcc dot gnu.org
@ 2014-01-22 18:40 ` ubizjak at gmail dot com
22 siblings, 0 replies; 24+ messages in thread
From: ubizjak at gmail dot com @ 2014-01-22 18:40 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 24+ messages in thread