public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug bootstrap/99920] [10 regression] ICE building gcc 10 on power 7 BE
Date: Thu, 08 Apr 2021 10:53:28 +0000 [thread overview]
Message-ID: <bug-99920-4-IDwQbxHKNA@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-99920-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99920
--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #13)
> So I can confirm the issue trying to build gcc10 packages for SLE11 ppc64
> (after much massaging). It works fine (past the failure point) on x86_64
> with the same versioned host compiler. It works fine when using gcc 4.8
> as host compiler (also available on SLES11).
>
> With the 4.3 based host compiler I see loads of
>
> [ 309s] In file included from ../../gcc/gimple-ssa-store-merging.c:168:
> [ 309s] ../../gcc/rtl.h: In function 'rtx_def* rtx_init(rtx_def*,
> rtx_code)':
> [ 309s] ../../gcc/rtl.h:2966: warning: invalid access to non-static data
> member 'rtx_def::u' of NULL object
> [ 309s] ../../gcc/rtl.h:2966: warning: (perhaps the 'offsetof' macro was
> used incorrectly)
the same warning happens with -save-temps and the .ii file has
# 2956 "../../gcc/rtl.h"
extern long trunc_int_for_mode (long, machine_mode);
extern poly_int64 trunc_int_for_mode (poly_int64, machine_mode);
extern rtx plus_constant (machine_mode, rtx, poly_int64, bool = false);
extern long get_stack_check_protect (void);
extern rtx rtx_alloc (enum rtx_code );
inline rtx
rtx_init (rtx rt, enum rtx_code code)
{
memset (rt, 0, __builtin_offsetof (struct rtx_def, u));
((rt)->code = (code));
return rt;
}
a build / gdb inside qemu (ick) shows
Program received signal SIGSEGV, Segmentation fault.
0x000000001218ecb4 in trim_filename (
name=0x1293bbf0 <vtable for (anonymous
namespace)::pass_early_thread_jumps+16> "") at ../../gcc/diagnostic.c:1223
1223 while (q[0] == '.' && q[1] == '.' && IS_DIR_SEPARATOR (q[2]))
(gdb) bt
#0 0x000000001218ecb4 in trim_filename (
name=0x1293bbf0 <vtable for (anonymous
namespace)::pass_early_thread_jumps+16> "") at ../../gcc/diagnostic.c:1223
#1 0x0000000012191cf0 in fancy_abort (
file=0x1293bbf0 <vtable for (anonymous
namespace)::pass_early_thread_jumps+16> "", line=3768, function=0x12bce0c8
<cfun> "") at ../../gcc/diagnostic.c:1778
#2 0x0000000010943ac4 in operand_compare::hash_operand (
this=0x12c87ba8 <global_options>, t=0x1ffffde22800, hstate=..., flags=0)
at ../../gcc/fold-const.c:3768
#3 0x0000000010944104 in inchash::add_expr (t=0x1ffffde22800, hstate=...,
flags=0) at ../../gcc/fold-const.c:3919
#4 0x000000001102a2ec in iterative_hash_expr (tree=0x1ffffde22800, seed=0)
at ../../gcc/tree.h:5207
#5 0x0000000011030e18 in tree_operand_hash::hash (
t=@0x3fffffffe220: 0x1ffffde22800) at ../../gcc/tree-hash-traits.h:34
#6 0x0000000011f71eb8 in
simple_hashmap_traits<default_hash_traits<tree_operand_hash>,
<unnamed>::imm_store_chain_info*>::hash(tree_node * const&) (
h=@0x3fffffffe220: 0x1ffffde22800) at ../../gcc/hash-map-traits.h:50
#7 0x0000000011f73378 in hash_map<tree_operand_hash,
<unnamed>::imm_store_chain_info*,
simple_hashmap_traits<default_hash_traits<tree_operand_hash>,
<unnamed>::imm_store_chain_info*> >::get(tree_node * const&) (this=0x12cec998,
k=@0x3fffffffe220: 0x1ffffde22800) at ../../gcc/hash-map.h:184
#8 0x0000000011f846f4 in (anonymous
namespace)::pass_store_merging::process_sto---Type <return> to continue, or q
<return> to quit---
re (this=0x12cec940, stmt=0x1ffffdd61e50)
at ../../gcc/gimple-ssa-store-merging.c:4883
#9 0x0000000011f84fec in (anonymous namespace)::pass_store_merging::execute (
this=0x12cec940, fun=0x1ffffdd90000)
at ../../gcc/gimple-ssa-store-merging.c:5040
#10 0x0000000010df8740 in execute_one_pass (pass=0x12cec940)
at ../../gcc/passes.c:2502
#3 0x0000000010944104 in inchash::add_expr (t=0x1ffffde22800, hstate=...,
flags=0) at ../../gcc/fold-const.c:3919
3919 default_compare_instance.hash_operand (t, hstate, flags);
(gdb) p t
$1 = (const_tree) 0x1ffffde22800
(gdb) p debug_tree (t)
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
<addr_expr 0x1ffffde22800
type <pointer_type 0x1ffffdd5bda8
type <union_type 0x1ffffdd50d20 _FP_UNION_Q sizes-gimplified
asm_written type_0 TI
size <integer_cst 0x1ffffdab1068 constant 128>
unit-size <integer_cst 0x1ffffdab1080 constant 16>
align:128 warn_if_not_align:0 symtab:8191 alias-set 4
canonical-type 0x1ffffdd50d20 fields <field_decl 0x1ffffdae3a30 flt> context
<translation_unit_decl 0x1ffffdd80078 trunckfdf2-sw.c>
pointer_to_this <pointer_type 0x1ffffdd5bda8> chain <type_decl
0x1ffffdae3998 D.3040>>
public unsigned DI
size <integer_cst 0x1ffffdab1020 constant 64>
unit-size <integer_cst 0x1ffffdab1038 constant 8>
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x1ffffdd5bda8>
arg:0 <var_decl 0x1ffffff90bd0 _FP_UNPACK_RAW_2_flo type <union_type
0x1ffffdd50d20 _FP_UNION_Q>
used read TI trunckfdf2-sw.c:46:31 size <integer_cst 0x1ffffdab1068
128> unit-size <integer_cst 0x1ffffdab1080 16>
align:128 warn_if_not_align:0 context <function_decl 0x1ffffdd2ce00
__trunckfdf2>>>
(gdb) down
#2 0x0000000010943ac4 in operand_compare::hash_operand (
this=0x12c87ba8 <global_options>, t=0x1ffffde22800, hstate=..., flags=0)
at ../../gcc/fold-const.c:3768
3768 gcc_assert (flags & OEP_HASH_CHECK);
(gdb) l
3763 hash_operand (TREE_OPERAND (TREE_OPERAND (t, 0), 0),
3764 hstate, flags);
3765 /* Don't ICE on FE specific trees, or their arguments etc.
3766 during operand_equal_p hash verification. */
3767 else if (!IS_EXPR_CODE_CLASS (tclass))
3768 gcc_assert (flags & OEP_HASH_CHECK);
(gdb) p tclass
$3 = tcc_exceptional
(gdb) p code
$4 = ADDR_EXPR
eh? Looks like some unfortunate mis-optimization of
operand_compare::hash_operand ... :/
next prev parent reply other threads:[~2021-04-08 10:53 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-05 22:28 [Bug bootstrap/99920] New: " seurer at gcc dot gnu.org
2021-04-06 7:29 ` [Bug bootstrap/99920] " rguenth at gcc dot gnu.org
2021-04-06 7:31 ` jakub at gcc dot gnu.org
2021-04-06 9:24 ` jakub at gcc dot gnu.org
2021-04-06 13:02 ` seurer at gcc dot gnu.org
2021-04-06 13:09 ` rguenther at suse dot de
2021-04-06 13:30 ` jakub at gcc dot gnu.org
2021-04-06 16:04 ` jakub at gcc dot gnu.org
2021-04-06 17:11 ` seurer at gcc dot gnu.org
2021-04-06 17:40 ` seurer at gcc dot gnu.org
2021-04-07 8:13 ` jakub at gcc dot gnu.org
2021-04-07 8:26 ` rguenther at suse dot de
2021-04-07 17:57 ` seurer at gcc dot gnu.org
2021-04-07 18:56 ` jakub at gcc dot gnu.org
2021-04-08 8:55 ` rguenth at gcc dot gnu.org
2021-04-08 10:53 ` rguenth at gcc dot gnu.org [this message]
2021-04-08 11:19 ` rguenth at gcc dot gnu.org
2021-04-08 11:52 ` rguenth at gcc dot gnu.org
2021-04-08 11:53 ` rguenth at gcc dot gnu.org
2021-04-08 12:02 ` rguenth at gcc dot gnu.org
2021-04-08 14:15 ` seurer at gcc dot gnu.org
2022-01-11 11:10 ` [Bug bootstrap/99920] [10 regression] ICE building gcc 10 on power 7 BE with GCC 4.3.4 (SUSE) host compiler rguenth at gcc dot gnu.org
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-99920-4-IDwQbxHKNA@http.gcc.gnu.org/bugzilla/ \
--to=gcc-bugzilla@gcc.gnu.org \
--cc=gcc-bugs@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).