public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/60553] New: segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO
@ 2014-03-17 14:54 marxin.liska at gmail dot com
2014-03-17 15:23 ` [Bug c++/60553] " rguenth at gcc dot gnu.org
` (8 more replies)
0 siblings, 9 replies; 10+ messages in thread
From: marxin.liska at gmail dot com @ 2014-03-17 14:54 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60553
Bug ID: 60553
Summary: segfault in gt_ggc_mx_lang_tree_node in Chromium with
LTO
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin.liska at gmail dot com
I do compile Chromium with LTO and there's ICE with enormous call stack:
gcc --version:
gcc (GCC) 4.9.0 20140313 (experimental)
ld --version:
GNU gold (GNU Binutils 2.24.51.20140304) 1.11
(gdb) bt -20
#529301 0x00000000005aae8e in gt_ggc_mx_lang_tree_node (x_p=0x7f5c763af738) at
./gtype-lto.h:359
#529302 0x00000000005aaf8b in gt_ggc_mx_lang_tree_node (x_p=0x7f5c644eedc8) at
./gtype-lto.h:378
#529303 0x00000000005aae8e in gt_ggc_mx_lang_tree_node (x_p=0x7f5c763a40a8) at
./gtype-lto.h:359
#529304 0x00000000005a92ef in gt_ggc_mx_lang_tree_node (x_p=0x7f5c763a70c0) at
./gtype-lto.h:55
#529305 0x00000000005aae54 in gt_ggc_mx_lang_tree_node (x_p=0x7f5c763a4150) at
./gtype-lto.h:357
#529306 0x00000000005a92ef in gt_ggc_mx_lang_tree_node (x_p=0x7f5c763a73a0) at
./gtype-lto.h:55
#529307 0x00000000005aae37 in gt_ggc_mx_lang_tree_node (x_p=0x7f5c763a4690) at
./gtype-lto.h:356
#529308 0x00000000005aadfd in gt_ggc_mx_lang_tree_node (x_p=0x7f5c763c2c78) at
./gtype-lto.h:354
#529309 0x00000000005aa694 in gt_ggc_mx_lang_tree_node (x_p=0x7f5c7650fc00) at
./gtype-lto.h:263
#529310 0x0000000000821c23 in gt_ggc_m_P9tree_node4htab (x_p=0x7f5c7775a850) at
gtype-desc.c:3185
#529311 0x00000000007bfde6 in ggc_mark_root_tab (rt=0x10cd140
<gt_ggc_r_gt_optabs_h>) at ../../gcc/ggc-common.c:133
#529312 0x00000000007c0281 in ggc_mark_roots () at ../../gcc/ggc-common.c:152
#529313 0x00000000005d0c2a in ggc_collect () at ../../gcc/ggc-page.c:2077
#529314 0x00000000005c32e7 in read_cgraph_and_symbols (nfiles=11258,
fnames=0x36701f0) at ../../gcc/lto/lto.c:3004
#529315 0x00000000005c406a in lto_main () at ../../gcc/lto/lto.c:3406
#529316 0x00000000009e4273 in compile_file () at ../../gcc/toplev.c:548
#529317 0x00000000009e640a in do_compile () at ../../gcc/toplev.c:1914
#529318 0x00000000009e6575 in toplev_main (argc=11283, argv=0x35fe750) at
../../gcc/toplev.c:1990
#529319 0x00007f5c765b6be5 in __libc_start_main () from /lib64/libc.so.6
#529320 0x0000000000587831 in _start () at ../sysdeps/x86_64/start.S:122
(gdb) bt 10
#0 0x00000000005cec2c in lookup_page_table_entry (p=<error reading variable:
Cannot access memory at address 0x7fffa80e8fc8>) at ../../gcc/ggc-page.c:584
#1 0x00000000005cfc5e in ggc_set_mark (p=0x7f5c399c1170) at
../../gcc/ggc-page.c:1467
#2 0x00000000005a9222 in gt_ggc_mx_lang_tree_node (x_p=0x7f5c399c1170) at
./gtype-lto.h:36
#3 0x00000000005aae1a in gt_ggc_mx_lang_tree_node (x_p=0x7f5c399c6f18) at
./gtype-lto.h:355
#4 0x00000000005aaf34 in gt_ggc_mx_lang_tree_node (x_p=0x7f5c399c6e70) at
./gtype-lto.h:375
#5 0x00000000005aa4b8 in gt_ggc_mx_lang_tree_node (x_p=0x7f5c399c10b8) at
./gtype-lto.h:246
#6 0x00000000005aaf17 in gt_ggc_mx_lang_tree_node (x_p=0x7f5c399c60a8) at
./gtype-lto.h:374
#7 0x00000000005aaf34 in gt_ggc_mx_lang_tree_node (x_p=0x7f5c399bf5e8) at
./gtype-lto.h:375
#8 0x00000000005aa461 in gt_ggc_mx_lang_tree_node (x_p=0x7f5c399bae60) at
./gtype-lto.h:243
#9 0x00000000005aaf17 in gt_ggc_mx_lang_tree_node (x_p=0x7f5c399bf348) at
./gtype-lto.h:374
I don't know what to dump, if you are interested I can add all kind info you
need.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c++/60553] segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO
2014-03-17 14:54 [Bug c++/60553] New: segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO marxin.liska at gmail dot com
@ 2014-03-17 15:23 ` rguenth at gcc dot gnu.org
2014-03-17 15:45 ` marxin.liska at gmail dot com
` (7 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-03-17 15:23 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60553
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #0)
> I do compile Chromium with LTO and there's ICE with enormous call stack:
>
> gcc --version:
> gcc (GCC) 4.9.0 20140313 (experimental)
>
> (gdb) bt 10
> #0 0x00000000005cec2c in lookup_page_table_entry (p=<error reading
> variable: Cannot access memory at address 0x7fffa80e8fc8>) at
> ../../gcc/ggc-page.c:584
> #1 0x00000000005cfc5e in ggc_set_mark (p=0x7f5c399c1170) at
> ../../gcc/ggc-page.c:1467
> #2 0x00000000005a9222 in gt_ggc_mx_lang_tree_node (x_p=0x7f5c399c1170) at
> ./gtype-lto.h:36
> #3 0x00000000005aae1a in gt_ggc_mx_lang_tree_node (x_p=0x7f5c399c6f18) at
> ./gtype-lto.h:355
> #4 0x00000000005aaf34 in gt_ggc_mx_lang_tree_node (x_p=0x7f5c399c6e70) at
> ./gtype-lto.h:375
> #5 0x00000000005aa4b8 in gt_ggc_mx_lang_tree_node (x_p=0x7f5c399c10b8) at
> ./gtype-lto.h:246
> #6 0x00000000005aaf17 in gt_ggc_mx_lang_tree_node (x_p=0x7f5c399c60a8) at
> ./gtype-lto.h:374
> #7 0x00000000005aaf34 in gt_ggc_mx_lang_tree_node (x_p=0x7f5c399bf5e8) at
> ./gtype-lto.h:375
> #8 0x00000000005aa461 in gt_ggc_mx_lang_tree_node (x_p=0x7f5c399bae60) at
> ./gtype-lto.h:243
> #9 0x00000000005aaf17 in gt_ggc_mx_lang_tree_node (x_p=0x7f5c399bf348) at
> ./gtype-lto.h:374
>
> I don't know what to dump, if you are interested I can add all kind info you
> need.
Can you show what lines you have in gtype-lto.h at these points? I have
stuff that doesn't make much sense
#3 gt_ggc_m_9tree_node
((*x).generic.type_non_common.with_lang_specific.common.common.chain)
#4 gt_ggc_m_9tree_node
((*x).generic.type_non_common.with_lang_specific.common.next_variant);
#5 gt_ggc_m_9tree_node
((*x).generic.type_decl.common.common.common.common.common.context);
#6 gt_ggc_m_9tree_node
((*x).generic.type_non_common.with_lang_specific.common.name);
#7 gt_ggc_m_9tree_node
((*x).generic.type_non_common.with_lang_specific.common.next_variant);
#8 gt_ggc_m_9tree_node
((*x).generic.type_decl.common.common.common.common.common.common.typed.type);
#9 gt_ggc_m_9tree_node
((*x).generic.type_non_common.with_lang_specific.common.name);
so it seems to be following a variant chain (but of course bt 10 may just
not be enough to see the real problem).
>From gcc-bugs-return-446578-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Mar 17 15:25:41 2014
Return-Path: <gcc-bugs-return-446578-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 12352 invoked by alias); 17 Mar 2014 15:25: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 12305 invoked by uid 55); 17 Mar 2014 15:25:37 -0000
From: "rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/60546] [4.8/4.9] O2 & asan enable generates wrong insns
Date: Mon, 17 Mar 2014 15:25:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenther at suse dot de
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-60546-4-Q2N0fWDFBx@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60546-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60546-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-03/txt/msg01447.txt.bz2
Content-length: 611
http://gcc.gnu.org/bugzilla/show_bug.cgi?id`546
--- Comment #17 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 17 Mar 2014, manjian2006 at gmail dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id`546
>
> --- Comment #16 from linzj <manjian2006 at gmail dot com> ---
> Yes,that may work.But what exactly go wrong in the original algorithm? I can't
> change a correct algorithm just because it volatiles TBBA and make the compiler
> generate wrong code.Because it's CORRECT logically.
You have to fix the memory reads from data[] to not read 'short's but
to read 'char's.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c++/60553] segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO
2014-03-17 14:54 [Bug c++/60553] New: segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO marxin.liska at gmail dot com
2014-03-17 15:23 ` [Bug c++/60553] " rguenth at gcc dot gnu.org
@ 2014-03-17 15:45 ` marxin.liska at gmail dot com
2014-03-18 10:28 ` rguenth at gcc dot gnu.org
` (6 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: marxin.liska at gmail dot com @ 2014-03-17 15:45 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60553
--- Comment #2 from Martin Liška <marxin.liska at gmail dot com> ---
Reduced input object files to ~800, bt consists of ~66K frames.
gdb:
(gdb) bt 10
#0 0x00000000005cec2c in lookup_page_table_entry (p=<error reading variable:
Cannot access memory at address 0x7fff63d42ff8>) at ../../gcc/ggc-page.c:584
#1 0x00000000005cfc5e in ggc_set_mark (p=0x7feaf406c020) at
../../gcc/ggc-page.c:1467
#2 0x00000000005a9222 in gt_ggc_mx_lang_tree_node (x_p=0x7feaf406c020) at
./gtype-lto.h:36
#3 0x00000000005aae37 in gt_ggc_mx_lang_tree_node (x_p=0x7feaec684bd0) at
./gtype-lto.h:356
#4 0x00000000005aa461 in gt_ggc_mx_lang_tree_node (x_p=0x7feaec6ad398) at
./gtype-lto.h:243
#5 0x00000000005aaf17 in gt_ggc_mx_lang_tree_node (x_p=0x7feaec68af18) at
./gtype-lto.h:374
#6 0x00000000005aaf34 in gt_ggc_mx_lang_tree_node (x_p=0x7feaec68c2a0) at
./gtype-lto.h:375
#7 0x00000000005aa461 in gt_ggc_mx_lang_tree_node (x_p=0x7feaec695e60) at
./gtype-lto.h:243
#8 0x00000000005aaf17 in gt_ggc_mx_lang_tree_node (x_p=0x7feaec69a0a8) at
./gtype-lto.h:374
#9 0x00000000005aaf34 in gt_ggc_mx_lang_tree_node (x_p=0x7feaec697d20) at
./gtype-lto.h:375
#2 0x00000000005a9222 in gt_ggc_mx_lang_tree_node (x_p=0x7feaf406c020) at
./gtype-lto.h:36
36 while (ggc_test_and_set_mark (xlimit))
(gdb) print (*x).generic.base
$20 = {code = INTEGER_CST, side_effects_flag = 0, constant_flag = 1,
addressable_flag = 0, volatile_flag = 0, readonly_flag = 0, asm_written_flag =
0, nowarning_flag = 0, visited = 0, used_flag = 0, nothrow_flag = 0,
static_flag = 0,
public_flag = 0, private_flag = 0, protected_flag = 0, deprecated_flag = 0,
default_def_flag = 0, u = {bits = {lang_flag_0 = 0, lang_flag_1 = 0,
lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0, lang_flag_5 = 0, lang_flag_6
= 0,
saturating_flag = 0, unsigned_flag = 0, packed_flag = 0, user_align = 0,
nameless_flag = 0, atomic_flag = 0, spare0 = 0, spare1 = 0, address_space = 0},
length = 0, version = 0}}
(gdb) up
#3 0x00000000005aae37 in gt_ggc_mx_lang_tree_node (x_p=0x7feaec684bd0) at
./gtype-lto.h:356
356 gt_ggc_m_9tree_node
((*x).generic.type_non_common.with_lang_specific.common.size);
(gdb) print (*x).generic.base
$21 = {code = INTEGER_TYPE, side_effects_flag = 0, constant_flag = 0,
addressable_flag = 0, volatile_flag = 0, readonly_flag = 0, asm_written_flag =
0, nowarning_flag = 0, visited = 0, used_flag = 0, nothrow_flag = 0,
static_flag = 0,
public_flag = 0, private_flag = 0, protected_flag = 0, deprecated_flag = 0,
default_def_flag = 0, u = {bits = {lang_flag_0 = 0, lang_flag_1 = 0,
lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0, lang_flag_5 = 0, lang_flag_6
= 0,
saturating_flag = 0, unsigned_flag = 1, packed_flag = 0, user_align = 0,
nameless_flag = 0, atomic_flag = 0, spare0 = 0, spare1 = 0, address_space = 0},
length = 256, version = 256}}
(gdb) up
#4 0x00000000005aa461 in gt_ggc_mx_lang_tree_node (x_p=0x7feaec6ad398) at
./gtype-lto.h:243
243 gt_ggc_m_9tree_node
((*x).generic.type_decl.common.common.common.common.common.common.typed.type);
(gdb) print (*x).generic.base
$22 = {code = TYPE_DECL, side_effects_flag = 0, constant_flag = 0,
addressable_flag = 0, volatile_flag = 0, readonly_flag = 0, asm_written_flag =
0, nowarning_flag = 0, visited = 0, used_flag = 0, nothrow_flag = 0,
static_flag = 0,
public_flag = 0, private_flag = 0, protected_flag = 0, deprecated_flag = 0,
default_def_flag = 0, u = {bits = {lang_flag_0 = 0, lang_flag_1 = 0,
lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0, lang_flag_5 = 0, lang_flag_6
= 0,
saturating_flag = 0, unsigned_flag = 1, packed_flag = 0, user_align = 0,
nameless_flag = 0, atomic_flag = 0, spare0 = 0, spare1 = 0, address_space = 0},
length = 256, version = 256}}
(gdb) up
#5 0x00000000005aaf17 in gt_ggc_mx_lang_tree_node (x_p=0x7feaec68af18) at
./gtype-lto.h:374
374 gt_ggc_m_9tree_node
((*x).generic.type_non_common.with_lang_specific.common.name);
(gdb) print (*x).generic.base
$23 = {code = RECORD_TYPE, side_effects_flag = 0, constant_flag = 0,
addressable_flag = 1, volatile_flag = 0, readonly_flag = 0, asm_written_flag =
0, nowarning_flag = 0, visited = 0, used_flag = 0, nothrow_flag = 0,
static_flag = 0,
public_flag = 0, private_flag = 0, protected_flag = 0, deprecated_flag = 0,
default_def_flag = 0, u = {bits = {lang_flag_0 = 0, lang_flag_1 = 0,
lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0, lang_flag_5 = 0, lang_flag_6
= 0,
saturating_flag = 0, unsigned_flag = 0, packed_flag = 0, user_align = 0,
nameless_flag = 0, atomic_flag = 0, spare0 = 0, spare1 = 0, address_space = 0},
length = 0, version = 0}}
(gdb) up
#6 0x00000000005aaf34 in gt_ggc_mx_lang_tree_node (x_p=0x7feaec68c2a0) at
./gtype-lto.h:375
375 gt_ggc_m_9tree_node
((*x).generic.type_non_common.with_lang_specific.common.next_variant);
(gdb) print (*x).generic.base
$24 = {code = RECORD_TYPE, side_effects_flag = 0, constant_flag = 0,
addressable_flag = 1, volatile_flag = 0, readonly_flag = 0, asm_written_flag =
0, nowarning_flag = 0, visited = 0, used_flag = 0, nothrow_flag = 0,
static_flag = 0,
public_flag = 0, private_flag = 0, protected_flag = 0, deprecated_flag = 0,
default_def_flag = 0, u = {bits = {lang_flag_0 = 0, lang_flag_1 = 0,
lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0, lang_flag_5 = 0, lang_flag_6
= 0,
saturating_flag = 0, unsigned_flag = 0, packed_flag = 0, user_align = 0,
nameless_flag = 0, atomic_flag = 0, spare0 = 0, spare1 = 0, address_space = 0},
length = 0, version = 0}}
(gdb) up
#7 0x00000000005aa461 in gt_ggc_mx_lang_tree_node (x_p=0x7feaec695e60) at
./gtype-lto.h:243
243 gt_ggc_m_9tree_node
((*x).generic.type_decl.common.common.common.common.common.common.typed.type);
(gdb) print (*x).generic.base
$25 = {code = TYPE_DECL, side_effects_flag = 0, constant_flag = 0,
addressable_flag = 0, volatile_flag = 0, readonly_flag = 0, asm_written_flag =
0, nowarning_flag = 0, visited = 0, used_flag = 0, nothrow_flag = 0,
static_flag = 0,
public_flag = 0, private_flag = 1, protected_flag = 0, deprecated_flag = 0,
default_def_flag = 0, u = {bits = {lang_flag_0 = 0, lang_flag_1 = 0,
lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0, lang_flag_5 = 0, lang_flag_6
= 0,
saturating_flag = 0, unsigned_flag = 0, packed_flag = 0, user_align = 0,
nameless_flag = 0, atomic_flag = 0, spare0 = 0, spare1 = 0, address_space = 0},
length = 0, version = 0}}
>From gcc-bugs-return-446587-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Mar 17 15:46:30 2014
Return-Path: <gcc-bugs-return-446587-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 29584 invoked by alias); 17 Mar 2014 15:46:29 -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 29548 invoked by uid 48); 17 Mar 2014 15:46:26 -0000
From: "marxin.liska at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/60553] segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO
Date: Mon, 17 Mar 2014 15:46: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: marxin.liska at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: attachments.created
Message-ID: <bug-60553-4-Qus470aVLg@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60553-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60553-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-03/txt/msg01456.txt.bz2
Content-length: 238
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60553
--- Comment #3 from Martin Liška <marxin.liska at gmail dot com> ---
Created attachment 32374
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32374&action=edit
gtype-lto.h
>From gcc-bugs-return-446588-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Mar 17 15:52:08 2014
Return-Path: <gcc-bugs-return-446588-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 5580 invoked by alias); 17 Mar 2014 15:52:08 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 5557 invoked by uid 48); 17 Mar 2014 15:52:05 -0000
From: "marxin.liska at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/60553] segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO
Date: Mon, 17 Mar 2014 15:52: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: marxin.liska at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: attachments.created
Message-ID: <bug-60553-4-kclZwBCSiH@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60553-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60553-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-03/txt/msg01457.txt.bz2
Content-length: 234
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60553
--- Comment #4 from Martin Liška <marxin.liska at gmail dot com> ---
Created attachment 32375
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32375&action=edit
bt 1000
>From gcc-bugs-return-446589-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Mar 17 16:27:11 2014
Return-Path: <gcc-bugs-return-446589-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 29581 invoked by alias); 17 Mar 2014 16:27:10 -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 29561 invoked by uid 48); 17 Mar 2014 16:27:06 -0000
From: "l_belev at yahoo dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/60554] New: redundant instruction is generated for setting the flags on x86
Date: Mon, 17 Mar 2014 16:27:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: minor
X-Bugzilla-Who: l_belev at yahoo dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-60554-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-03/txt/msg01458.txt.bz2
Content-length: 1017
http://gcc.gnu.org/bugzilla/show_bug.cgi?id`554
Bug ID: 60554
Summary: redundant instruction is generated for setting the
flags on x86
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: l_belev at yahoo dot com
consider this simple function:
int is_float_negative(int x) { return (int)(x ^ 0x80000000) > 0; }
for x86, with options "-O3 -march=core2", GCC 4.8.2 generates the following
code:
....
_is_float_negative:
movl 4(%esp), %eax
addl $-2147483648, %eax
testl %eax, %eax
setg %al
movzbl %al, %eax
ret
....
apparently (x^0x80000000) is replaced with (x+0x80000000), that's ok.
the problem is the testl instruction - why the compiler decided to emit it?
the addl instruction itself sets the needed flags (Z and N) just right.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c++/60553] segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO
2014-03-17 14:54 [Bug c++/60553] New: segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO marxin.liska at gmail dot com
2014-03-17 15:23 ` [Bug c++/60553] " rguenth at gcc dot gnu.org
2014-03-17 15:45 ` marxin.liska at gmail dot com
@ 2014-03-18 10:28 ` rguenth at gcc dot gnu.org
2014-03-18 11:00 ` rguenth at gcc dot gnu.org
` (5 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-03-18 10:28 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60553
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
next_variant->type_name->type->next_variant->type-name->decl_original_type->type_name->decl_context->next_variant->type_context->next_variant->next_variant->next_variant->type_fields->type->...
it's walking a type hierarchy, up-and-down. Ideally the GC walking would
be more structured here, but ...
Can you try if sth as simple as
Index: gcc/tree-core.h
===================================================================
--- gcc/tree-core.h (revision 208615)
+++ gcc/tree-core.h (working copy)
@@ -1265,11 +1265,11 @@ struct GTY(()) tree_type_common {
const char * GTY ((tag ("TYPE_SYMTAB_IS_POINTER"))) pointer;
struct die_struct * GTY ((tag ("TYPE_SYMTAB_IS_DIE"))) die;
} GTY ((desc ("debug_hooks->tree_type_symtab_field"))) symtab;
- tree name;
+ tree canonical;
tree next_variant;
tree main_variant;
tree context;
- tree canonical;
+ tree name;
};
struct GTY(()) tree_type_with_lang_specific {
helps? That makes sure to first walk fields that point us downward the
type hierarchy and then those that point us upward?
With LTO it may be the case that TYPE_CANONICAL connects very many types
that are otherwise unrelated ...
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c++/60553] segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO
2014-03-17 14:54 [Bug c++/60553] New: segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO marxin.liska at gmail dot com
` (2 preceding siblings ...)
2014-03-18 10:28 ` rguenth at gcc dot gnu.org
@ 2014-03-18 11:00 ` rguenth at gcc dot gnu.org
2014-03-18 15:33 ` marxin.liska at gmail dot com
` (4 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-03-18 11:00 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60553
--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Another idea would be (many next-variant walks in the call stack)
Index: lto/lto-tree.h
===================================================================
--- lto/lto-tree.h (revision 208615)
+++ lto/lto-tree.h (working copy)
@@ -48,7 +48,7 @@ enum lto_tree_node_structure_enum {
};
union GTY((desc ("lto_tree_node_structure (&%h)"),
- chain_next ("CODE_CONTAINS_STRUCT (TREE_CODE (&%h.generic),
TS_COMMON) ? ((union lang_tree_node *) TREE_CHAIN (&%h.generic)) : NULL")))
+ chain_next ("CODE_CONTAINS_STRUCT (TREE_CODE (&%h.generic),
TS_TYPE_COMMON) ? ((union lang_tree_node *) TYPE_NEXT_VARIANT (&%h.generic)) :
CODE_CONTAINS_STRUCT (TREE_CODE (&%h.generic), TS_COMMON) ? ((union
lang_tree_node *) TREE_CHAIN (&%h.generic)) : NULL")))
lang_tree_node
{
union tree_node GTY ((tag ("TS_LTO_GENERIC"),
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c++/60553] segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO
2014-03-17 14:54 [Bug c++/60553] New: segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO marxin.liska at gmail dot com
` (3 preceding siblings ...)
2014-03-18 11:00 ` rguenth at gcc dot gnu.org
@ 2014-03-18 15:33 ` marxin.liska at gmail dot com
2014-03-19 13:04 ` rguenth at gcc dot gnu.org
` (3 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: marxin.liska at gmail dot com @ 2014-03-18 15:33 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60553
--- Comment #7 from Martin Liška <marxin.liska at gmail dot com> ---
Patches helped me!
First one was sufficient for my simplified case (~800 files), but it was
necessary to add second one for chromium.
Will you add this changes to mainline or should I create a patch?
Thanks,
Martin
>From gcc-bugs-return-446730-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Mar 18 15:43:54 2014
Return-Path: <gcc-bugs-return-446730-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 5712 invoked by alias); 18 Mar 2014 15:43:53 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 5670 invoked by uid 48); 18 Mar 2014 15:43:49 -0000
From: "janus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/60550] [OOP] ICE on factory design pattern
Date: Tue, 18 Mar 2014 15:43: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.9.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: janus at gcc dot gnu.org
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: keywords bug_status cf_reconfirmed_on cc short_desc everconfirmed
Message-ID: <bug-60550-4-aCYQw6eLLj@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60550-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60550-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-03/txt/msg01599.txt.bz2
Content-length: 2925
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60550
janus at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |ice-on-valid-code
Status|UNCONFIRMED |NEW
Last reconfirmed| |2014-03-18
CC| |janus at gcc dot gnu.org
Summary|ICE on factory design |[OOP] ICE on factory design
|pattern |pattern
Ever confirmed|0 |1
--- Comment #1 from janus at gcc dot gnu.org ---
Confirmed. I think it may be related (or identical) to PR 58880, which shows a
very similar backtrace. The one I get here is:
ice_factory_pattern.f90: In function ‘create_problem’:
ice_factory_pattern.f90:350:0: internal compiler error: in fold_convert_loc, at
fold-const.c:1994
ALLOCATE(self%problemPtr, SOURCE=FRosenbrock(self%problemID, ndim,
self%problemName))
^
0x79251f fold_convert_loc(unsigned int, tree_node*, tree_node*)
/home/jweil/gcc49/trunk/gcc/fold-const.c:1993
0x61c8de gfc_conv_descriptor_data_set(stmtblock_t*, tree_node*, tree_node*)
/home/jweil/gcc49/trunk/gcc/fortran/trans-array.c:178
0x63b2e5 gfc_conv_scalar_to_descriptor(gfc_se*, tree_node*, symbol_attribute)
/home/jweil/gcc49/trunk/gcc/fortran/trans-expr.c:74
0x619799 gfc_add_comp_finalizer_call(stmtblock_t*, tree_node*, gfc_component*,
bool)
/home/jweil/gcc49/trunk/gcc/fortran/trans.c:1012
0x624769 structure_alloc_comps
/home/jweil/gcc49/trunk/gcc/fortran/trans-array.c:7672
0x63e487 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec<tree_node*, va_gc, vl_embed>*)
/home/jweil/gcc49/trunk/gcc/fortran/trans-expr.c:4630
0x663dc4 gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*, bool)
/home/jweil/gcc49/trunk/gcc/fortran/trans-stmt.c:408
0x6698fc gfc_trans_allocate(gfc_code*)
/home/jweil/gcc49/trunk/gcc/fortran/trans-stmt.c:5300
0x619137 trans_code
/home/jweil/gcc49/trunk/gcc/fortran/trans.c:1778
0x6683dd gfc_trans_integer_select
/home/jweil/gcc49/trunk/gcc/fortran/trans-stmt.c:2003
0x6683dd gfc_trans_select(gfc_code*)
/home/jweil/gcc49/trunk/gcc/fortran/trans-stmt.c:2497
0x6191b7 trans_code
/home/jweil/gcc49/trunk/gcc/fortran/trans.c:1744
0x638eb2 gfc_generate_function_code(gfc_namespace*)
/home/jweil/gcc49/trunk/gcc/fortran/trans-decl.c:5610
0x61a641 gfc_generate_module_code(gfc_namespace*)
/home/jweil/gcc49/trunk/gcc/fortran/trans.c:1956
0x5d8edb translate_all_program_units
/home/jweil/gcc49/trunk/gcc/fortran/parse.c:4523
0x5d8edb gfc_parse_file()
/home/jweil/gcc49/trunk/gcc/fortran/parse.c:4733
0x6159a5 gfc_be_parse_file
/home/jweil/gcc49/trunk/gcc/fortran/f95-lang.c:188
>From gcc-bugs-return-446731-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Mar 18 15:44:20 2014
Return-Path: <gcc-bugs-return-446731-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 6500 invoked by alias); 18 Mar 2014 15:44:20 -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 6457 invoked by uid 48); 18 Mar 2014 15:44:16 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/60562] [4.9 Regression] FAIL: gcc.target/i386/excess-precision-3.c execution test after r208587
Date: Tue, 18 Mar 2014 15:44: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: jakub at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: rth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-60562-4-m15rVIsfvQ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60562-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60562-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-03/txt/msg01600.txt.bz2
Content-length: 429
http://gcc.gnu.org/bugzilla/show_bug.cgi?id`562
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
BTW, it is actually 4 tests in excess-precision-3.c that fail now:
if ((float)i1 != 0x1.0p30f)
abort ();
if ((float)u1 != 0x1.0p31f)
abort ();
if ((float)ll1 != 0x1.0p62f)
abort ();
...
if ((double)ll1 != 0x1.0p62)
abort ();
commenting all those 4 out makes the test pass with the trunk.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c++/60553] segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO
2014-03-17 14:54 [Bug c++/60553] New: segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO marxin.liska at gmail dot com
` (4 preceding siblings ...)
2014-03-18 15:33 ` marxin.liska at gmail dot com
@ 2014-03-19 13:04 ` rguenth at gcc dot gnu.org
2014-03-19 15:38 ` rguenth at gcc dot gnu.org
` (2 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-03-19 13:04 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60553
--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
I've posted the patches but I'm curious if the 2nd change alone helps enough.
The first is somewhat handwaving (because we also have type_non_common which
breaks the argument of the former).
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c++/60553] segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO
2014-03-17 14:54 [Bug c++/60553] New: segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO marxin.liska at gmail dot com
` (5 preceding siblings ...)
2014-03-19 13:04 ` rguenth at gcc dot gnu.org
@ 2014-03-19 15:38 ` rguenth at gcc dot gnu.org
2014-03-19 16:42 ` marxin.liska at gmail dot com
2014-03-20 9:11 ` rguenth at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-03-19 15:38 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60553
--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Wed Mar 19 15:37:28 2014
New Revision: 208682
URL: http://gcc.gnu.org/viewcvs?rev=208682&root=gcc&view=rev
Log:
2014-03-19 Richard Biener <rguenther@suse.de>
PR middle-end/60553
* tree-core.h (tree_type_common): Re-order pointer members
to reduce recursion depth during GC walks.
lto/
* lto-tree.h (lang_tree_node): For types use TYPE_NEXT_VARIANT
instead of TREE_CHAIN as chain_next.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lto/ChangeLog
trunk/gcc/lto/lto-tree.h
trunk/gcc/tree-core.h
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c++/60553] segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO
2014-03-17 14:54 [Bug c++/60553] New: segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO marxin.liska at gmail dot com
` (6 preceding siblings ...)
2014-03-19 15:38 ` rguenth at gcc dot gnu.org
@ 2014-03-19 16:42 ` marxin.liska at gmail dot com
2014-03-20 9:11 ` rguenth at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: marxin.liska at gmail dot com @ 2014-03-19 16:42 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60553
--- Comment #10 from Martin Liška <marxin.liska at gmail dot com> ---
Second part of suggested patch is sufficient.
ps auxf:
marxin 20293 0.0 0.0 8604 1200 pts/0 S 17:27 0:00 | \_
c++ -Wl,-z,now -Wl,-z,relro -pthread -Wl,-z,noexecstack -fPIC -pie -L.
-Wl,-uIsHeapProfilerRunning,-uProfilerStart
-Wl,-u_Z21InitialMallocHook_NewPKvj,-u_Z22Init
marxin 20294 0.0 0.0 8128 692 pts/0 S 17:27 0:00 |
\_
/home/marxin/Programming/bin/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/collect2
-plugin /home/marxin/Programming/bin/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.
marxin 20295 1.1 7.2 3881556 1181360 pts/0 S 17:27 0:03 |
\_
/home/marxin/Programming/bin/gcc/lib64/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../x86_64-unknown-linux-gnu/bin/ld
-plugin /home/marxin/Programming/bi
marxin 20412 0.0 0.1 34448 27212 pts/0 S 17:28 0:00 |
\_
/home/marxin/Programming/bin/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
@/tmp/ccw1zmZQ
marxin 20413 0.0 0.0 12060 4548 pts/0 S 17:28 0:00 |
\_ c++ @/tmp/ccH68rYD.args
marxin 20414 23.7 33.4 5533676 5489912 pts/0 t 17:28 0:54 |
\_
/home/marxin/Programming/bin/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/lto1
-quiet -dumpdir ./ -dumpbase chrome.wpa -mtune=generic -march=x8
ps ax | grep 20414:
20414 pts/0 t 0:54
/home/marxin/Programming/bin/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/lto1
-quiet -dumpdir ./ -dumpbase chrome.wpa -mtune=generic -march=x86-64 -msse2
-mssse3 -msse -mmmx -m64 -mtune=generic -march=x86-64 -auxbase
chrome_initial.chrome_exe_main_aura -O3 -fno-trapv -fno-exceptions -fPIC
-fno-fat-lto-objects -fltrans-output-list=/tmp/ccqDrHsV.ltrans.out -fwpa=9
-fresolution=/tmp/ccufR16A.res @/tmp/cc13JyyZ
GDB:
#1409777 0x00000000006b3b11 in gt_ggc_m_P9tree_node4htab (x_p=0x7f0f55752850)
at gtype-desc.c:3185
(gdb) p *x
$2 = {hash_f = 0x75a1f0 <libfunc_decl_hash(void const*)>, eq_f = 0x75a200
<libfunc_decl_eq(void const*, void const*)>, del_f = 0x0, entries =
0x7f0f54390a00, size = 61, n_elements = 17, n_deleted = 0, searches = 17,
collisions = 4,
alloc_f = 0x681250 <ggc_cleared_alloc_ptr_array_two_args(unsigned long,
unsigned long)>, free_f = 0x549db0 <ggc_free(void*)>, alloc_arg = 0x0,
alloc_with_arg_f = 0x0, free_with_arg_f = 0x0, size_prime_index = 3}
down iterations:
(gdb) p x->generic->base->code
$7 = FUNCTION_DECL
$8 = FUNCTION_TYPE
$9 = INTEGER_TYPE
$10 = INTEGER_CST
$11 = INTEGER_TYPE
$12 = INTEGER_CST
$13 = INTEGER_TYPE
$14 = POINTER_TYPE
$15 = POINTER_TYPE
$16 = POINTER_TYPE
$17 = POINTER_TYPE
$18 = POINTER_TYPE
$19 = INTEGER_TYPE
Hope it will help.
Martin
>From gcc-bugs-return-446899-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Mar 19 16:50:52 2014
Return-Path: <gcc-bugs-return-446899-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 12849 invoked by alias); 19 Mar 2014 16:50:52 -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 12810 invoked by uid 48); 19 Mar 2014 16:50:49 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/60591] Report enum conversions as part of Wconversion
Date: Wed, 19 Mar 2014 16:50: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: enhancement
X-Bugzilla-Who: manu at gcc dot gnu.org
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: bug_status cf_reconfirmed_on cc component everconfirmed
Message-ID: <bug-60591-4-c7lHQCMcDa@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60591-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60591-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-03/txt/msg01768.txt.bz2
Content-length: 1035
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60591
Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2014-03-19
CC| |manu at gcc dot gnu.org
Component|middle-end |c
Ever confirmed|0 |1
--- Comment #1 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
The code in unsafe_conversion_p does not handle enumeral_type only integer_type
and real_type. Somebody will need to update it to handle it, being careful with
existing warnings in the C++ FE that do warn about enumeral type conversions.
Clang does warn:
pr60591.c:11:10: warning: implicit conversion loses integer precision: 'enum
xpto' to 'unsigned char' [-Wconversion]
return a;
~~~~~~ ^
>From gcc-bugs-return-446900-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Mar 19 16:52:16 2014
Return-Path: <gcc-bugs-return-446900-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 15091 invoked by alias); 19 Mar 2014 16:52:16 -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 15047 invoked by uid 48); 19 Mar 2014 16:52:11 -0000
From: "hjl.tools at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/60556] tip of tree crash with mips compiler
Date: Wed, 19 Mar 2014 16:52: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: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hjl.tools at gmail 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-60556-4-5lcBTdAgCO@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60556-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60556-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-03/txt/msg01769.txt.bz2
Content-length: 143
http://gcc.gnu.org/bugzilla/show_bug.cgi?id`556
--- Comment #15 from H.J. Lu <hjl.tools at gmail dot com> ---
This is related to PR 54037.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c++/60553] segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO
2014-03-17 14:54 [Bug c++/60553] New: segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO marxin.liska at gmail dot com
` (7 preceding siblings ...)
2014-03-19 16:42 ` marxin.liska at gmail dot com
@ 2014-03-20 9:11 ` rguenth at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-03-20 9:11 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60553
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |FIXED
--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
Ah, ok. We come via TYPE_CANONICAL of sizetype * to some other type. Not sure
how that happens though.
Anyway, closing as fixed.
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2014-03-20 9:11 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-03-17 14:54 [Bug c++/60553] New: segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO marxin.liska at gmail dot com
2014-03-17 15:23 ` [Bug c++/60553] " rguenth at gcc dot gnu.org
2014-03-17 15:45 ` marxin.liska at gmail dot com
2014-03-18 10:28 ` rguenth at gcc dot gnu.org
2014-03-18 11:00 ` rguenth at gcc dot gnu.org
2014-03-18 15:33 ` marxin.liska at gmail dot com
2014-03-19 13:04 ` rguenth at gcc dot gnu.org
2014-03-19 15:38 ` rguenth at gcc dot gnu.org
2014-03-19 16:42 ` marxin.liska at gmail dot com
2014-03-20 9:11 ` rguenth at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).