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).