[Bug c++/60553] New: segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO

[Bug c++/60553] New: segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO

[marxin.liska at gmail dot com]

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.

[Bug c++/60553] segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO

[rguenth at gcc dot gnu.org]

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.

[Bug c++/60553] segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO

[marxin.liska at gmail dot com]

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.

[Bug c++/60553] segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO

[rguenth at gcc dot gnu.org]

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

[Bug c++/60553] segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO

[rguenth at gcc dot gnu.org]

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"),

[Bug c++/60553] segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO

[marxin.liska at gmail dot com]

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.

[Bug c++/60553] segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO

[rguenth at gcc dot gnu.org]

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

[Bug c++/60553] segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO

[rguenth at gcc dot gnu.org]

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

[Bug c++/60553] segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO

[marxin.liska at gmail dot com]

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.

[Bug c++/60553] segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO

[rguenth at gcc dot gnu.org]

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.