public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
* [Bug c/57896] New: ICE in in expand_expr_real_2 @ 2013-07-15 6:44 zeccav at gmail dot com 2013-07-15 9:37 ` [Bug c/57896] " mikpe at it dot uu.se ` (31 more replies) 0 siblings, 32 replies; 33+ messages in thread From: zeccav at gmail dot com @ 2013-07-15 6:44 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896 Bug ID: 57896 Summary: ICE in in expand_expr_real_2 Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: zeccav at gmail dot com Created attachment 30504 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30504&action=edit C code causing an ICE in expand_expr_real_2 The attached code causes an ICE in in expand_expr_real_2, This is from testsuite/gcc.target/vperm-v4si-2.c The ICE is maybe due to wrong index at cfgexpand.c:4329 I put gcc_assert ((int) ((enum tree_code) (t)->base.code) < sizeof_tree_code_type); before "if (IS_TYPE_OR_DECL_P (t))" and I got the backtrace in the bottom of the attached file. I defined sizeof_tree_code_type in tree.h and tree.c const int sizeof_tree_code_type=sizeof(tree_code_type); I am sorry I was not able to produce a shorter test case. ^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug c/57896] ICE in in expand_expr_real_2 2013-07-15 6:44 [Bug c/57896] New: ICE in in expand_expr_real_2 zeccav at gmail dot com @ 2013-07-15 9:37 ` mikpe at it dot uu.se 2013-07-15 14:23 ` mikpe at it dot uu.se ` (30 subsequent siblings) 31 siblings, 0 replies; 33+ messages in thread From: mikpe at it dot uu.se @ 2013-07-15 9:37 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896 Mikael Pettersson <mikpe at it dot uu.se> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mikpe at it dot uu.se --- Comment #1 from Mikael Pettersson <mikpe at it dot uu.se> --- I can reproduce the ICE with gcc-4.8.1 and gcc-4.8-20130711 on x86_64-linux, using options -O0 -m64. At higher optimization levels or with -m32 the ICE doesn't occur. gcc-4.9-20130714 doesn't ICE. ^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug c/57896] ICE in in expand_expr_real_2 2013-07-15 6:44 [Bug c/57896] New: ICE in in expand_expr_real_2 zeccav at gmail dot com 2013-07-15 9:37 ` [Bug c/57896] " mikpe at it dot uu.se @ 2013-07-15 14:23 ` mikpe at it dot uu.se 2013-07-15 15:32 ` glisse at gcc dot gnu.org ` (29 subsequent siblings) 31 siblings, 0 replies; 33+ messages in thread From: mikpe at it dot uu.se @ 2013-07-15 14:23 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896 Mikael Pettersson <mikpe at it dot uu.se> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |glisse at gcc dot gnu.org --- Comment #2 from Mikael Pettersson <mikpe at it dot uu.se> --- The ICE was fixed for 4.9/trunk by Marc Glisse's "Property for vector lowering" patch in r196890, originally described here: http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00421.html Backporting r196890 to current 4.8 branch fixes the ICE there too, but that may or may not be the appropriate fix. Author CC:d. ^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug c/57896] ICE in in expand_expr_real_2 2013-07-15 6:44 [Bug c/57896] New: ICE in in expand_expr_real_2 zeccav at gmail dot com 2013-07-15 9:37 ` [Bug c/57896] " mikpe at it dot uu.se 2013-07-15 14:23 ` mikpe at it dot uu.se @ 2013-07-15 15:32 ` glisse at gcc dot gnu.org 2013-07-15 16:32 ` glisse at gcc dot gnu.org ` (28 subsequent siblings) 31 siblings, 0 replies; 33+ messages in thread From: glisse at gcc dot gnu.org @ 2013-07-15 15:32 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896 Marc Glisse <glisse at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Last reconfirmed| |2013-07-15 Ever confirmed|0 |1 --- Comment #3 from Marc Glisse <glisse at gcc dot gnu.org> --- (In reply to Mikael Pettersson from comment #2) > The ICE was fixed for 4.9/trunk by Marc Glisse's "Property for vector > lowering" patch in r196890, originally described here: > http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00421.html Really? Ah, right, I moved a pass in that patch, that's probably what matters. > Backporting r196890 to current 4.8 branch fixes the ICE there too, but that > may or may not be the appropriate fix. Author CC:d. I doubt that backporting the whole thing makes sense. If moving the pass really helps, that part maybe... But we first need to understand what is going on, the patch is likely just hiding the real bug. ^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug c/57896] ICE in in expand_expr_real_2 2013-07-15 6:44 [Bug c/57896] New: ICE in in expand_expr_real_2 zeccav at gmail dot com ` (2 preceding siblings ...) 2013-07-15 15:32 ` glisse at gcc dot gnu.org @ 2013-07-15 16:32 ` glisse at gcc dot gnu.org 2013-07-15 23:42 ` zeccav at gmail dot com ` (27 subsequent siblings) 31 siblings, 0 replies; 33+ messages in thread From: glisse at gcc dot gnu.org @ 2013-07-15 16:32 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896 --- Comment #4 from Marc Glisse <glisse at gcc dot gnu.org> --- Created attachment 30506 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30506&action=edit Slightly reduced testcase The bug disappears if we remove some unused typedefs, or the preprocessor line indications, or... valgrind doesn't report anything though. I have no idea what kind of corruption is going on. ^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug c/57896] ICE in in expand_expr_real_2 2013-07-15 6:44 [Bug c/57896] New: ICE in in expand_expr_real_2 zeccav at gmail dot com ` (3 preceding siblings ...) 2013-07-15 16:32 ` glisse at gcc dot gnu.org @ 2013-07-15 23:42 ` zeccav at gmail dot com 2013-07-16 6:19 ` zeccav at gmail dot com ` (26 subsequent siblings) 31 siblings, 0 replies; 33+ messages in thread From: zeccav at gmail dot com @ 2013-07-15 23:42 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896 --- Comment #5 from Vittorio Zecca <zeccav at gmail dot com> --- Trying your vastly reduced test case, 152 lines vs 3057 of my original test case, I am getting an ICE in convert_move, at expr.c:452. The following is my backtrace: <command-line>: In function ‘__get_cpuid_max’: <command-line>:1:1: internal compiler error: in convert_move, at expr.c:452 0x62ee1b convert_move(rtx_def*, rtx_def*, int) ../../gcc-4.8.1/gcc/expr.c:451 0x62f098 convert_modes(machine_mode, machine_mode, rtx_def*, int) ../../gcc-4.8.1/gcc/expr.c:781 0x9939dd ix86_legitimize_address ../../gcc-4.8.1/gcc/config/i386/i386.c:13276 0x619880 memory_address_addr_space(machine_mode, rtx_def*, unsigned char) ../../gcc-4.8.1/gcc/explow.c:461 0x60b5a4 change_address_1 ../../gcc-4.8.1/gcc/emit-rtl.c:2021 0x671808 assign_parm_setup_stack ../../gcc-4.8.1/gcc/function.c:3234 0x671808 assign_parms ../../gcc-4.8.1/gcc/function.c:3416 0x67355f expand_function_start(tree_node*) ../../gcc-4.8.1/gcc/function.c:4824 0x58ac99 gimple_expand_cfg ../../gcc-4.8.1/gcc/cfgexpand.c:4552 Adding option -m32 I get ICE in ix86_expand_prologue, at config/i386/i386.c:10559 >From gcc-bugs-return-426250-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jul 16 01:59:26 2013 Return-Path: <gcc-bugs-return-426250-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org> Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 10812 invoked by alias); 16 Jul 2013 01:59:25 -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 8566 invoked by uid 48); 16 Jul 2013 01:57:22 -0000 From: "raj.khem at gmail dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/57717] error: unrecognizable insn compiling ./strtod_l.c from glibc on powerpc-gnuspe Date: Tue, 16 Jul 2013 01:59: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: raj.khem 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: Message-ID: <bug-57717-4-hXqPGGGHw0@http.gcc.gnu.org/bugzilla/> In-Reply-To: <bug-57717-4@http.gcc.gnu.org/bugzilla/> References: <bug-57717-4@http.gcc.gnu.org/bugzilla/> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-07/txt/msg00757.txt.bz2 Content-length: 1366 http://gcc.gnu.org/bugzilla/show_bug.cgi?idW717 --- Comment #6 from Khem Raj <raj.khem at gmail dot com> --- here is another case which fails before suggested patch and also after the patch void foo() { double a[20000]; double b = 3.1L / 20000; } Here is result below after applying the patch in comment #3 $ ./gcc/cc1 ~/a.c foo Analyzing compilation unit Performing interprocedural optimizations <*free_lang_data> <visibility> <early_local_cleanups> <*free_inline_summary> <emutls> <whole-program>Assembling functions: foo /homes/kraj/a.c: In function 'foo': /homes/kraj/a.c:6:1: internal compiler error: in change_address_1, at emit-rtl.c:1955 } ^ 0x5d7dd0 change_address_1 ../../gcc/gcc/emit-rtl.c:1955 0x5dad82 adjust_address_1(rtx_def*, machine_mode, long, int, int, int, long) ../../gcc/gcc/emit-rtl.c:2087 0x61ac98 alter_subreg(rtx_def**, bool) ../../gcc/gcc/final.c:3062 0x61aed9 cleanup_subreg_operands(rtx_def*) ../../gcc/gcc/final.c:3008 0x7e80b6 reload(rtx_def*, int) ../../gcc/gcc/reload1.c:1240 0x70227b do_reload ../../gcc/gcc/ira.c:4701 0x70227b rest_of_handle_reload ../../gcc/gcc/ira.c:4801 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions. ^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug c/57896] ICE in in expand_expr_real_2 2013-07-15 6:44 [Bug c/57896] New: ICE in in expand_expr_real_2 zeccav at gmail dot com ` (4 preceding siblings ...) 2013-07-15 23:42 ` zeccav at gmail dot com @ 2013-07-16 6:19 ` zeccav at gmail dot com 2014-02-19 8:11 ` [Bug c/57896] [4.8 Regression] ICE " mpolacek at gcc dot gnu.org ` (25 subsequent siblings) 31 siblings, 0 replies; 33+ messages in thread From: zeccav at gmail dot com @ 2013-07-16 6:19 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896 --- Comment #6 from Vittorio Zecca <zeccav at gmail dot com> --- The following is a shorter version of Marc's test case: __get_cpuid_max (unsigned int __ext, unsigned int *__sig) { unsigned __edx; __cpuid (0, 0, 0, 0, __edx); } int __get_cpuid (unsigned int __level, unsigned int *__eax, unsigned int *__ebx, unsigned int *__ecx, unsigned int *__edx) { fail: return 0; } typedef int IV __attribute__((vector_size(16))); typedef union { int s; IV v; } U; static U i[2], b, c; void check0(void) { b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 4, 0, 0, 0}); (memcmp (&b, &c, sizeof(c)) == 0) || (__builtin_trap (), 0); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 5, 0, 0, 0}); (memcmp (&b, &c, sizeof(c)) == 0) || (__builtin_trap (), 0); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 6, 0, 0, 0}); (memcmp (&b, &c, sizeof(c)) == 0) || (__builtin_trap (), 0); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 7, 0, 0, 0}); (memcmp (&b, &c, sizeof(c)) == 0) || (__builtin_trap (), 0); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 4, 1, 0, 0}); (memcmp (&b, &c, sizeof(c)) == 0) || (__builtin_trap (), 0); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 5, 1, 0, 0}); (memcmp (&b, &c, sizeof(c)) == 0) || (__builtin_trap (), 0); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 6, 1, 0, 0}); (memcmp (&b, &c, sizeof(c)) == 0) || (__builtin_trap (), 0); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 7, 1, 0, 0}); (memcmp (&b, &c, sizeof(c)) == 0) || (__builtin_trap (), 0); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 0, 4, 0, 0}); (memcmp (&b, &c, sizeof(c)) == 0) || (__builtin_trap (), 0); } void check2(void) { b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 0, 0, 4, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 1, 0, 4, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 4, 0, 4, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 5, 0, 4, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 0, 1, 4, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 1, 1, 4, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 4, 1, 4, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 5, 1, 4, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 0, 0, 5, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 1, 0, 5, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 4, 0, 5, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 5, 0, 5, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 0, 1, 5, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 1, 1, 5, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 4, 1, 5, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 5, 1, 5, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 0, 4, 5, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 1, 4, 5, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 4, 4, 5, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 5, 4, 5, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 0, 5, 5, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 1, 5, 5, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 4, 5, 5, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 5, 5, 5, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 0, 0, 6, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 1, 0, 6, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 6, 0, 6, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 7, 0, 6, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 0, 1, 6, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 1, 1, 6, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 6, 1, 6, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 7, 1, 6, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 0, 6, 6, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 1, 6, 6, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 6, 6, 6, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 7, 6, 6, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 0, 7, 6, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 1, 7, 6, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 6, 7, 6, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 7, 7, 6, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 0, 0, 7, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 1, 0, 7, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 6, 0, 7, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 7, 0, 7, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 0, 1, 7, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 1, 1, 7, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 6, 1, 7, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 7, 1, 7, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 0, 6, 7, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 1, 6, 7, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 6, 6, 7, 0}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 4, 3, 4, 4}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 5, 3, 4, 4}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 0, 4, 4, 4}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 1, 4, 4, 4}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 2, 4, 4, 4}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 3, 4, 4, 4}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 0, 5, 4, 4}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 1, 5, 4, 4}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 2, 5, 4, 4}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 3, 5, 4, 4}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 4, 0, 5, 4}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 5, 0, 5, 4}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 4, 1, 5, 4}); b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){ 5, 1, 5, 4}); } As an aside, in gcc 4.8.1 source code, before line 6995 of gcc/expr.c I put printf("\nexpr.c:6995 value->code=%d NUM_RTX_CODE=%d\n",(int) value->code,NUM_RTX_CODE); gcc_assert((int) value->code < NUM_RTX_CODE); and I get an ICE there because value->code is 34816 and NUM_RTX_CODE is 145 Indeed at line 6995 ARITHMETIC_P (value) accesses rtx_class[(int) value->code] but the array rtx_class has only NUM_RTX_CODE elements. However, I do not know how this is relevant to this issue. ^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug c/57896] [4.8 Regression] ICE in expand_expr_real_2 2013-07-15 6:44 [Bug c/57896] New: ICE in in expand_expr_real_2 zeccav at gmail dot com ` (5 preceding siblings ...) 2013-07-16 6:19 ` zeccav at gmail dot com @ 2014-02-19 8:11 ` mpolacek at gcc dot gnu.org 2014-02-19 17:59 ` [Bug target/57896] " ubizjak at gmail dot com ` (24 subsequent siblings) 31 siblings, 0 replies; 33+ messages in thread From: mpolacek at gcc dot gnu.org @ 2014-02-19 8:11 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896 Marek Polacek <mpolacek at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mpolacek at gcc dot gnu.org Target Milestone|--- |4.8.4 Summary|ICE in expand_expr_real_2 |[4.8 Regression] ICE in | |expand_expr_real_2 --- Comment #7 from Marek Polacek <mpolacek at gcc dot gnu.org> --- Currently, I see ICE only with 4.8: ./cc1 xx.c -m32 -quiet -march=x86-64 In function ‘__get_cpuid_max’: Segmentation fault } ^ 0xa3924f crash_signal /home/marek/src/gcc/gcc/toplev.c:332 0x11fc5fe pp_base_string(pretty_print_info*, char const*) /home/marek/src/gcc/gcc/pretty-print.c:835 0x11fd0a4 pp_base_format(pretty_print_info*, text_info*) /home/marek/src/gcc/gcc/pretty-print.c:496 0x11fa7ac diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*) /home/marek/src/gcc/gcc/diagnostic.c:755 0x11faabb internal_error(char const*, ...) /home/marek/src/gcc/gcc/diagnostic.c:1094 0x9b9aa7 rtl_check_failed_code1(rtx_def const*, rtx_code, char const*, int, char const*) /home/marek/src/gcc/gcc/rtl.c:773 0xc93a5d pro_epilogue_adjust_stack /home/marek/src/gcc/gcc/config/i386/i386.c:9517 0xca0b20 ix86_expand_prologue() /home/marek/src/gcc/gcc/config/i386/i386.c:10491 0xd645da gen_prologue() /home/marek/src/gcc/gcc/config/i386/i386.md:11810 0x80dc79 thread_prologue_and_epilogue_insns /home/marek/src/gcc/gcc/function.c:5949 0x8110a2 rest_of_handle_thread_prologue_and_epilogue /home/marek/src/gcc/gcc/function.c:6973 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions. >From gcc-bugs-return-444171-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Feb 19 08:12:27 2014 Return-Path: <gcc-bugs-return-444171-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org> Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 28083 invoked by alias); 19 Feb 2014 08:12:27 -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 28016 invoked by uid 48); 19 Feb 2014 08:12:22 -0000 From: "mpolacek at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/57896] [4.8 Regression] ICE in expand_expr_real_2 Date: Wed, 19 Feb 2014 08:12: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.8.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: minor X-Bugzilla-Who: mpolacek 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: 4.8.4 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: component Message-ID: <bug-57896-4-Hopx8I0tUA@http.gcc.gnu.org/bugzilla/> In-Reply-To: <bug-57896-4@http.gcc.gnu.org/bugzilla/> References: <bug-57896-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-02/txt/msg01928.txt.bz2 Content-length: 381 http://gcc.gnu.org/bugzilla/show_bug.cgi?idW896 Marek Polacek <mpolacek at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|c |target --- Comment #8 from Marek Polacek <mpolacek at gcc dot gnu.org> --- Not a C FE issue. ^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug target/57896] [4.8 Regression] ICE in expand_expr_real_2 2013-07-15 6:44 [Bug c/57896] New: ICE in in expand_expr_real_2 zeccav at gmail dot com ` (6 preceding siblings ...) 2014-02-19 8:11 ` [Bug c/57896] [4.8 Regression] ICE " mpolacek at gcc dot gnu.org @ 2014-02-19 17:59 ` ubizjak at gmail dot com 2014-02-19 18:06 ` ubizjak at gmail dot com ` (23 subsequent siblings) 31 siblings, 0 replies; 33+ messages in thread From: ubizjak at gmail dot com @ 2014-02-19 17:59 UTC (permalink / raw) To: gcc-bugs [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 4271 bytes --] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896 --- Comment #9 from UroÅ¡ Bizjak <ubizjak at gmail dot com> --- (In reply to Vittorio Zecca from comment #6) > As an aside, in gcc 4.8.1 source code, before line 6995 of gcc/expr.c I put > > printf("\nexpr.c:6995 value->code=%d NUM_RTX_CODE=%d\n",(int) > value->code,NUM_RTX_CODE); > gcc_assert((int) value->code < NUM_RTX_CODE); > > and I get an ICE there because value->code is 34816 and NUM_RTX_CODE is 145 > > Indeed at line 6995 ARITHMETIC_P (value) accesses rtx_class[(int) > value->code] > but the array rtx_class has only NUM_RTX_CODE elements. > However, I do not know how this is relevant to this issue. This one points to infrastructure problem. Adding a debug patch: --cut here-- Index: explow.c =================================================================== --- explow.c (revision 207910) +++ explow.c (working copy) @@ -186,8 +186,13 @@ plus_constant (enum machine_mode mode, rtx x, HOST } if (c != 0) - x = gen_rtx_PLUS (mode, x, GEN_INT (c)); + { + rtx z = GEN_INT (c); + printf ("cccccc, %li\n", c); + debug_rtx (z); + x = gen_rtx_PLUS (mode, x, z); + } if (GET_CODE (x) == SYMBOL_REF || GET_CODE (x) == LABEL_REF) return x; else if (all_constant) --cut here-- ~/gcc-build-48/gcc/cc1 pr57896.c ... __get_cpuidcccccc, -4 (const_int -4 [0xfffffffffffffffc]) cccccc, -16 (const_int -16 [0xfffffffffffffff0]) cccccc, -24 (const_int -24 [0xffffffffffffffe8]) cccccc, -32 (const_int -32 [0xffffffffffffffe0]) cccccc, -40 (??? bad code 47104 ) pr57896.c: In function â__get_cpuidâ: pr57896.c:5:5: internal compiler error: in emit_move_insn_1, at expr.c:3437 int __get_cpuid (unsigned int __level, unsigned int *__eax, unsigned int *__ebx, unsigned int *__ecx, unsigned int *__edx) { ^ 0x62d74d emit_move_insn_1(rtx_def*, rtx_def*) /home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/expr.c:3437 0x62d7b5 emit_move_insn(rtx_def*, rtx_def*) /home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/expr.c:3535 Please note that the debug patch only encloses GEN_INT (...) >From gcc-bugs-return-444241-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Feb 19 18:03:54 2014 Return-Path: <gcc-bugs-return-444241-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org> Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 15188 invoked by alias); 19 Feb 2014 18:03:54 -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 14781 invoked by uid 48); 19 Feb 2014 18:03:48 -0000 From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c/37743] Bogus printf format warning with __builtin_bswap32. Date: Wed, 19 Feb 2014 18:03:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: unknown X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub 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: attachments.created Message-ID: <bug-37743-4-yDecQATOVD@http.gcc.gnu.org/bugzilla/> In-Reply-To: <bug-37743-4@http.gcc.gnu.org/bugzilla/> References: <bug-37743-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-02/txt/msg01998.txt.bz2 Content-length: 299 http://gcc.gnu.org/bugzilla/show_bug.cgi?id7743 --- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> --- Created attachment 32173 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id2173&actioníit gcc49-pr37743.patch Untested fix. The deprecation can hopefully be done separately. ^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug target/57896] [4.8 Regression] ICE in expand_expr_real_2 2013-07-15 6:44 [Bug c/57896] New: ICE in in expand_expr_real_2 zeccav at gmail dot com ` (7 preceding siblings ...) 2014-02-19 17:59 ` [Bug target/57896] " ubizjak at gmail dot com @ 2014-02-19 18:06 ` ubizjak at gmail dot com 2014-02-19 18:34 ` ubizjak at gmail dot com ` (22 subsequent siblings) 31 siblings, 0 replies; 33+ messages in thread From: ubizjak at gmail dot com @ 2014-02-19 18:06 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896 --- Comment #10 from Uroš Bizjak <ubizjak at gmail dot com> --- (In reply to Vittorio Zecca from comment #5) > Adding option -m32 I get ICE in ix86_expand_prologue, at > config/i386/i386.c:10559 I can confirm this with: gcc version 4.8.3 20140219 (prerelease) [gcc-4_8-branch revision 207910] (GCC) ~/gcc-build-48/gcc/cc1 -m32 -march=x86-64 pr57896.c pr57896.c: In function ‘__get_cpuid_max’: pr57896.c:4:1: internal compiler error: in ix86_expand_prologue, at config/i386/i386.c:10539 } ^ 0x98fdf5 ix86_expand_prologue() /home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/config/i386/i386.c:10539 0xa1ce5a gen_prologue() /home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/config/i386/i386.md:11829 0x673927 thread_prologue_and_epilogue_insns /home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/function.c:5949 0x673927 rest_of_handle_thread_prologue_and_epilogue /home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/function.c:6973 The output from the debug patch doesn't look suspicious, so this looks like a real bug to me. Can someone please bisect which commit fixed/hid this bug? >From gcc-bugs-return-444243-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Feb 19 18:10:40 2014 Return-Path: <gcc-bugs-return-444243-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org> Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 32414 invoked by alias); 19 Feb 2014 18:10:40 -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 32374 invoked by uid 55); 19 Feb 2014 18:10:37 -0000 From: "hjl at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/60207] Wrong TFmode check in construct_container Date: Wed, 19 Feb 2014 18:10:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: hjl at gcc dot gnu.org 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: Message-ID: <bug-60207-4-SdCZioxKtE@http.gcc.gnu.org/bugzilla/> In-Reply-To: <bug-60207-4@http.gcc.gnu.org/bugzilla/> References: <bug-60207-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-02/txt/msg02000.txt.bz2 Content-length: 487 http://gcc.gnu.org/bugzilla/show_bug.cgi?id`207 --- Comment #2 from hjl at gcc dot gnu.org <hjl at gcc dot gnu.org> --- Author: hjl Date: Wed Feb 19 18:10:04 2014 New Revision: 207913 URL: http://gcc.gnu.org/viewcvs?rev 7913&root=gcc&view=rev Log: Remove TFmode check for X86_64_INTEGER_CLASS PR target/60207 * config/i386/i386.c (construct_container): Remove TFmode check for X86_64_INTEGER_CLASS. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c ^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug target/57896] [4.8 Regression] ICE in expand_expr_real_2 2013-07-15 6:44 [Bug c/57896] New: ICE in in expand_expr_real_2 zeccav at gmail dot com ` (8 preceding siblings ...) 2014-02-19 18:06 ` ubizjak at gmail dot com @ 2014-02-19 18:34 ` ubizjak at gmail dot com 2014-02-19 18:37 ` [Bug middle-end/57896] " ubizjak at gmail dot com ` (21 subsequent siblings) 31 siblings, 0 replies; 33+ messages in thread From: ubizjak at gmail dot com @ 2014-02-19 18:34 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896 --- Comment #11 from Uroš Bizjak <ubizjak at gmail dot com> --- (In reply to Uroš Bizjak from comment #10) > (In reply to Vittorio Zecca from comment #5) > > > Adding option -m32 I get ICE in ix86_expand_prologue, at > > config/i386/i386.c:10559 > > I can confirm this with: > > gcc version 4.8.3 20140219 (prerelease) [gcc-4_8-branch revision 207910] > (GCC) > > ~/gcc-build-48/gcc/cc1 -m32 -march=x86-64 pr57896.c This is the same problem, as confirmed by following debug patch: --cut here-- Index: i386.c =================================================================== --- i386.c (revision 207912) +++ i386.c (working copy) @@ -10449,8 +10449,12 @@ ix86_expand_prologue (void) else if (!ix86_target_stack_probe () || frame.stack_pointer_offset < CHECK_STACK_LIMIT) { + rtx x = GEN_INT (-allocate); + + printf ("\nTestP1 %li\n", -allocate); + debug_rtx (x); pro_epilogue_adjust_stack (stack_pointer_rtx, stack_pointer_rtx, - GEN_INT (-allocate), -1, + x, -1, m->fs.cfa_reg == stack_pointer_rtx); } else @@ -10536,6 +10540,7 @@ ix86_expand_prologue (void) gen_frame_mem (word_mode, t)); } } + printf ("\nTestP2 %li %li\n", m->fs.sp_offset, frame.stack_pointer_offset); gcc_assert (m->fs.sp_offset == frame.stack_pointer_offset); /* If we havn't already set up the frame pointer, do so now. */ --cut here-- GEN_INT (...) produces some non-sensical RTX, and INTVAL at the end of pro_epilogue_adjust_stack chokes on it. m->fs.sp_offset = ooffset - INTVAL (offset); m->fs.sp_valid = valid; ~/gcc-build-48/gcc/cc1 -m32 -march=x86-64 pr57896.c ... TestP1 -56 (??? bad code 42752 ) TestP2 -139787679344504 64 pr57896.c: In function ‘__get_cpuid_max’: pr57896.c:4:1: internal compiler error: in ix86_expand_prologue, at config/i386/i386.c:10544 } ^ 0x98fe35 ix86_expand_prologue() /home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/config/i386/i386.c:10544 0xa1ce9a gen_prologue() /home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/config/i386/i386.md:11829 0x673927 thread_prologue_and_epilogue_insns /home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/function.c:5949 0x673927 rest_of_handle_thread_prologue_and_epilogue /home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/function.c:6973 >From gcc-bugs-return-444250-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Feb 19 18:34:44 2014 Return-Path: <gcc-bugs-return-444250-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org> Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 29625 invoked by alias); 19 Feb 2014 18:34:43 -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 29462 invoked by uid 48); 19 Feb 2014 18:34:40 -0000 From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c/37743] Bogus printf format warning with __builtin_bswap32. Date: Wed, 19 Feb 2014 18:34: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: unknown X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org 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: bug_status resolution Message-ID: <bug-37743-4-H9wiXCtT6s@http.gcc.gnu.org/bugzilla/> In-Reply-To: <bug-37743-4@http.gcc.gnu.org/bugzilla/> References: <bug-37743-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-02/txt/msg02007.txt.bz2 Content-length: 650 http://gcc.gnu.org/bugzilla/show_bug.cgi?id7743 Jakub Jelinek <jakub at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> --- Fixed. That said, both testcases in this PR are inherently non-portable, on some targets __builtin_bswap32 returns unsigned long, on most unsigned int, could be even unsigned long long. So, one should really use uint32_t and PRIu32. ^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug middle-end/57896] [4.8 Regression] ICE in expand_expr_real_2 2013-07-15 6:44 [Bug c/57896] New: ICE in in expand_expr_real_2 zeccav at gmail dot com ` (9 preceding siblings ...) 2014-02-19 18:34 ` ubizjak at gmail dot com @ 2014-02-19 18:37 ` ubizjak at gmail dot com 2014-02-19 19:19 ` mpolacek at gcc dot gnu.org ` (20 subsequent siblings) 31 siblings, 0 replies; 33+ messages in thread From: ubizjak at gmail dot com @ 2014-02-19 18:37 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896 Uroš Bizjak <ubizjak at gmail dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ebotcazou at gcc dot gnu.org, | |jakub at redhat dot com Component|target |middle-end Version|4.8.1 |4.8.3 --- Comment #12 from Uroš Bizjak <ubizjak at gmail dot com> --- Reconfirmed on 4.8.3 as "middle-end" catch-all bug. Adding some CCs that might be interested in this PR. >From gcc-bugs-return-444253-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Feb 19 18:44:58 2014 Return-Path: <gcc-bugs-return-444253-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org> Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 11105 invoked by alias); 19 Feb 2014 18:44:58 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: <gcc-bugs.gcc.gnu.org> List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/> List-Post: <mailto:gcc-bugs@gcc.gnu.org> List-Help: <mailto:gcc-bugs-help@gcc.gnu.org> Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 11075 invoked by uid 48); 19 Feb 2014 18:44:55 -0000 From: "slayoo at staszic dot waw.pl" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/60267] ICE in c_pp_lookup_pragma, at c-family/c-pragma.c:1232; ICE in tsubst_copy, at cp/pt.c:12887 Date: Wed, 19 Feb 2014 18:44: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: slayoo at staszic dot waw.pl X-Bugzilla-Status: RESOLVED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: <bug-60267-4-f5iFV9VIYF@http.gcc.gnu.org/bugzilla/> In-Reply-To: <bug-60267-4@http.gcc.gnu.org/bugzilla/> References: <bug-60267-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-02/txt/msg02010.txt.bz2 Content-length: 221 http://gcc.gnu.org/bugzilla/show_bug.cgi?id`267 --- Comment #12 from Sylwester Arabas <slayoo at staszic dot waw.pl> --- Thanks a lot! I'll try it as soon as it will get into Debian's gcc-snapshot package. Sylwester ^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug middle-end/57896] [4.8 Regression] ICE in expand_expr_real_2 2013-07-15 6:44 [Bug c/57896] New: ICE in in expand_expr_real_2 zeccav at gmail dot com ` (10 preceding siblings ...) 2014-02-19 18:37 ` [Bug middle-end/57896] " ubizjak at gmail dot com @ 2014-02-19 19:19 ` mpolacek at gcc dot gnu.org 2014-02-20 9:29 ` ubizjak at gmail dot com ` (19 subsequent siblings) 31 siblings, 0 replies; 33+ messages in thread From: mpolacek at gcc dot gnu.org @ 2014-02-19 19:19 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896 --- Comment #13 from Marek Polacek <mpolacek at gcc dot gnu.org> --- Seems like r196890 made this latent. ^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug middle-end/57896] [4.8 Regression] ICE in expand_expr_real_2 2013-07-15 6:44 [Bug c/57896] New: ICE in in expand_expr_real_2 zeccav at gmail dot com ` (11 preceding siblings ...) 2014-02-19 19:19 ` mpolacek at gcc dot gnu.org @ 2014-02-20 9:29 ` ubizjak at gmail dot com 2014-02-20 9:58 ` ubizjak at gmail dot com ` (18 subsequent siblings) 31 siblings, 0 replies; 33+ messages in thread From: ubizjak at gmail dot com @ 2014-02-20 9:29 UTC (permalink / raw) To: gcc-bugs [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 5267 bytes --] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896 --- Comment #16 from UroÅ¡ Bizjak <ubizjak at gmail dot com> --- (In reply to Jakub Jelinek from comment #15) > I'll have a look (unless you want to continue poking). According to ChangeLogs, you have much more experience in this part, so I would be much grateful if you can take it from here. >From gcc-bugs-return-444318-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Feb 20 09:29:06 2014 Return-Path: <gcc-bugs-return-444318-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org> Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 15495 invoked by alias); 20 Feb 2014 09:29:06 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: <gcc-bugs.gcc.gnu.org> List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/> List-Post: <mailto:gcc-bugs@gcc.gnu.org> List-Help: <mailto:gcc-bugs-help@gcc.gnu.org> Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 15470 invoked by uid 48); 20 Feb 2014 09:29:02 -0000 From: "vogt at linux dot vnet.ibm.com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug go/60288] New: gccgo crashes compiling '*func_ptr(0)' Date: Thu, 20 Feb 2014 09:29:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: go X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: vogt at linux dot vnet.ibm.com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: ian at airs dot com 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 attachments.created Message-ID: <bug-60288-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-02/txt/msg02075.txt.bz2 Content-length: 3074 http://gcc.gnu.org/bugzilla/show_bug.cgi?id`288 Bug ID: 60288 Summary: gccgo crashes compiling '*func_ptr(0)' Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: vogt at linux dot vnet.ibm.com Created attachment 32179 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id2179&actioníit test program git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@207936 138bc75d-0d04-0410-961f-82ee72b054a4 This program crashes gcc: -- BEGIN package main func f(i int) int { return i } func main() { g := f println(*&g(0)) // <-- compiles (see below) pg := &g println(*pg(0)) // <-- crash } -- END Instead of producing an error message, gccgo crashes in line 7: -- snip -- foo.go:7:11: error: expected function println(*pg(0)) ^ go1: internal compiler error: in do_flatten, at go/gofrontend/expressions.cc:3835 0x80151dc9 Unary_expression::do_flatten(Gogo*, Named_object*, Statement_inserter*) ../../gcc/go/gofrontend/expressions.cc:3835 0x80196583 Expression::flatten(Gogo*, Named_object*, Statement_inserter*) ../../gcc/go/gofrontend/expressions.h:635 0x80196583 Flatten::expression(Expression**) ../../gcc/go/gofrontend/gogo.cc:2841 0x80152a75 Expression::traverse(Expression**, Traverse*) ../../gcc/go/gofrontend/expressions.cc:54 0x80152a75 Expression_list::traverse(Traverse*) ../../gcc/go/gofrontend/expressions.cc:15187 0x80152a75 Call_expression::do_traverse(Traverse*) ../../gcc/go/gofrontend/expressions.cc:9124 0x80152a75 Call_expression::do_traverse(Traverse*) ../../gcc/go/gofrontend/expressions.cc:9118 0x801965a3 Flatten::expression(Expression**) ../../gcc/go/gofrontend/gogo.cc:2837 0x80154d67 Expression::traverse(Expression**, Traverse*) ../../gcc/go/gofrontend/expressions.cc:54 0x80198ddf Flatten::statement(Block*, unsigned long*, Statement*) ../../gcc/go/gofrontend/gogo.cc:2797 0x801da0b3 Statement::traverse(Block*, unsigned long*, Traverse*) ../../gcc/go/gofrontend/statements.cc:43 0x8019c791 Block::traverse(Traverse*) ../../gcc/go/gofrontend/gogo.cc:4279 0x8019cca3 Function::traverse(Traverse*) ../../gcc/go/gofrontend/gogo.cc:3805 0x8019cca3 Flatten::function(Named_object*) ../../gcc/go/gofrontend/gogo.cc:2774 0x8019d071 Bindings::traverse(Traverse*, bool) ../../gcc/go/gofrontend/gogo.cc:5877 0x8019d81d Gogo::traverse(Traverse*) ../../gcc/go/gofrontend/gogo.cc:1466 0x8019d81d Gogo::flatten() ../../gcc/go/gofrontend/gogo.cc:2875 0x8018bb8d go_parse_input_files(char const**, unsigned int, bool, bool) ../../gcc/go/gofrontend/go.cc:126 -- snip -- As a side note, gccgo compiles line 5 without even as much as a warning while golang treats this as an error: (golang) ./foo.go:5: cannot take the address of g(0) So it looks like gccgo reads the expression as (*pg)(0) while golang reads it as *(pg(0)) Not sure whether this is a bug in gccgo. ^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug middle-end/57896] [4.8 Regression] ICE in expand_expr_real_2 2013-07-15 6:44 [Bug c/57896] New: ICE in in expand_expr_real_2 zeccav at gmail dot com ` (12 preceding siblings ...) 2014-02-20 9:29 ` ubizjak at gmail dot com @ 2014-02-20 9:58 ` ubizjak at gmail dot com 2014-02-20 10:15 ` ubizjak at gmail dot com ` (17 subsequent siblings) 31 siblings, 0 replies; 33+ messages in thread From: ubizjak at gmail dot com @ 2014-02-20 9:58 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896 --- Comment #17 from Uroš Bizjak <ubizjak at gmail dot com> --- Somehow we get old_size = 0 in gen_reg_rtx. It is calculated as: int old_size = crtl->emit.regno_pointer_align_length; Trivial patch that prevents this situation and fixes the problem. However, it is not clear to me if crtl->emit.regno_pointer_align_length should start larger than zero. --cut here-- Index: emit-rtl.c =================================================================== --- emit-rtl.c (revision 207935) +++ emit-rtl.c (working copy) @@ -903,6 +903,8 @@ gen_reg_rtx (enum machine_mode mode) char *tmp; rtx *new1; + if (old_size < 1) + old_size = 1; tmp = XRESIZEVEC (char, crtl->emit.regno_pointer_align, old_size * 2); memset (tmp + old_size, 0, old_size); crtl->emit.regno_pointer_align = (unsigned char *) tmp; --cut here-- >From gcc-bugs-return-444322-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Feb 20 09:59:06 2014 Return-Path: <gcc-bugs-return-444322-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org> Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 31750 invoked by alias); 20 Feb 2014 09:59:06 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: <gcc-bugs.gcc.gnu.org> List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/> List-Post: <mailto:gcc-bugs@gcc.gnu.org> List-Help: <mailto:gcc-bugs-help@gcc.gnu.org> Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 31479 invoked by uid 48); 20 Feb 2014 09:59:02 -0000 From: "burnus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c/60287] Various issues on -WformatDate: Thu, 20 Feb 2014 09:59: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: burnus at gcc dot gnu.org 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: cc Message-ID: <bug-60287-4-CFveWMRPBe@http.gcc.gnu.org/bugzilla/> In-Reply-To: <bug-60287-4@http.gcc.gnu.org/bugzilla/> References: <bug-60287-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-02/txt/msg02079.txt.bz2 Content-length: 2006 http://gcc.gnu.org/bugzilla/show_bug.cgi?id`287 Tobias Burnus <burnus at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> --- (In reply to Chengnian Sun from comment #0) > 1) Besides "-Wformat=2", gcc accepts any option in the form of > -Wformat=<number> > Based on the manual, gcc only accepts "-Wformat=2", and others such as > "-Wformat=0,1, 3-9" should be invalid. Any undocumented behavior? Well, -Wformat=0 disables all format warnings (not really documented) - and should be equivalent to -Wno-format; "-Wformat=1" is equivalent to "-Wformat" - and that is explicitly documented in the manual: http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wformat-294 And -Wformat=2 is equivalent to -Wformat=1 plus additional warnings. -Wformat=3 would be equivalent to -Wformat=2 plus additional (nonexisting) options. And I think it currently acts as -Wformat=2, which should be fine as well. (Similar is: -O0, -O1, -O2, -O3; where some other compilers have -O4 - but GCC doesn't and [I think it] treats it as -O3.) > 2) Is the warning name "[-Wformat=]" in the warning message intended? Yes - as one doesn't want to distinguish between "-Wformat=2" and "-Wformat/-Wformat=1 -Wformat-security". In particular, "-Wformat-security" requires "-Wformat=1" in addition, otherwise, it doesn't warn at all. Thus, printing [-Wformat=] is way easier than to re-construct the exact option. > 3) Is the column number information correct in the warning message? Should > the warning refer to the location of the problematic argument, or the > function call? Well, the column number is correct - but pointing to either to the proper '%' in the format string or to the argument would be better. - Like always, there is room for improvement. ^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug middle-end/57896] [4.8 Regression] ICE in expand_expr_real_2 2013-07-15 6:44 [Bug c/57896] New: ICE in in expand_expr_real_2 zeccav at gmail dot com ` (13 preceding siblings ...) 2014-02-20 9:58 ` ubizjak at gmail dot com @ 2014-02-20 10:15 ` ubizjak at gmail dot com 2014-02-20 10:27 ` [Bug target/57896] " jakub at gcc dot gnu.org ` (16 subsequent siblings) 31 siblings, 0 replies; 33+ messages in thread From: ubizjak at gmail dot com @ 2014-02-20 10:15 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896 --- Comment #18 from Uroš Bizjak <ubizjak at gmail dot com> --- And finally, it looks that expand_vector_operations doesn't call init_emit (). Backtrace: Breakpoint 1, gen_reg_rtx (mode=V4SImode) at ../../gcc-svn/branches/gcc-4_8-branch/gcc/emit-rtl.c:864 864 unsigned int align = GET_MODE_ALIGNMENT (mode); (gdb) bt #0 gen_reg_rtx (mode=V4SImode) at ../../gcc-svn/branches/gcc-4_8-branch/gcc/emit-rtl.c:864 #1 0x000000000098aa82 in expand_vec_perm_interleave2 (d=0x7fffffffc110) at ../../gcc-svn/branches/gcc-4_8-branch/gcc/config/i386/i386.c:39408 #2 0x000000000098b2d0 in ix86_expand_vec_perm_const_1 (d=0x7fffffffc110) at ../../gcc-svn/branches/gcc-4_8-branch/gcc/config/i386/i386.c:40464 #3 0x000000000098b847 in ix86_vectorize_vec_perm_const_ok (vmode=<optimized out>, sel=<optimized out>) at ../../gcc-svn/branches/gcc-4_8-branch/gcc/config/i386/i386.c:40670 #4 0x000000000072cac2 in can_vec_perm_p (mode=V4SImode, variable=false, sel=0x7fffffffc1b0 "\004") at ../../gcc-svn/branches/gcc-4_8-branch/gcc/optabs.c:6492 #5 0x00000000008ed774 in lower_vec_perm(struct {...} *) (gsi=0x7fffffffc280) at ../../gcc-svn/branches/gcc-4_8-branch/gcc/tree-vect-generic.c:1207 #6 0x00000000008f0d39 in expand_vector_operations () at ../../gcc-svn/branches/gcc-4_8-branch/gcc/tree-vect-generic.c:1489 where p x_rtl.emit.regno_pointer_align_length $2 = 0 >From gcc-bugs-return-444326-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Feb 20 10:19:30 2014 Return-Path: <gcc-bugs-return-444326-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org> Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 17280 invoked by alias); 20 Feb 2014 10:19:30 -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 17257 invoked by uid 48); 20 Feb 2014 10:19:26 -0000 From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/60280] [4.9 Regression] gcc.target/arm/ivopts.c and gcc.target/arm/ivopts-2.c failed caused by preserving loop structure. Date: Thu, 20 Feb 2014 10:19:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.9.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: keywords target_milestone short_desc Message-ID: <bug-60280-4-ijBthpMKYD@http.gcc.gnu.org/bugzilla/> In-Reply-To: <bug-60280-4@http.gcc.gnu.org/bugzilla/> References: <bug-60280-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-02/txt/msg02083.txt.bz2 Content-length: 871 http://gcc.gnu.org/bugzilla/show_bug.cgi?id`280 Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |missed-optimization Target Milestone|--- |4.9.0 Summary|gcc.target/arm/ivopts.c and |[4.9 Regression] |gcc.target/arm/ivopts-2.c |gcc.target/arm/ivopts.c and |failed caused by preserving |gcc.target/arm/ivopts-2.c |loop structure. |failed caused by preserving | |loop structure. --- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> --- Btw, does it work in 4.8? We preserve loops there as well (just not so early). ^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug target/57896] [4.8 Regression] ICE in expand_expr_real_2 2013-07-15 6:44 [Bug c/57896] New: ICE in in expand_expr_real_2 zeccav at gmail dot com ` (14 preceding siblings ...) 2014-02-20 10:15 ` ubizjak at gmail dot com @ 2014-02-20 10:27 ` jakub at gcc dot gnu.org 2014-02-20 10:41 ` jakub at gcc dot gnu.org ` (15 subsequent siblings) 31 siblings, 0 replies; 33+ messages in thread From: jakub at gcc dot gnu.org @ 2014-02-20 10:27 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896 Jakub Jelinek <jakub at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|middle-end |target --- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> --- The bug is in the backend, gen_reg_rtx shouldn't be called when init_emit has not been called. If one looks e.g. at tree-ssa-loop-ivopts.c or even ix86_vectorize_vec_perm_const_ok, it avoids using gen_reg_rtx and instead uses gen_raw_REG: d.target = gen_raw_REG (d.vmode, LAST_VIRTUAL_REGISTER + 1); d.op1 = d.op0 = gen_raw_REG (d.vmode, LAST_VIRTUAL_REGISTER + 2); if (!d.one_operand_p) d.op1 = gen_raw_REG (d.vmode, LAST_VIRTUAL_REGISTER + 3); So, we should avoid calling gen_reg_rtx if d->testing_p, we can create gen_raw_REG instead if really needed. Let me skim through the routines. ^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug target/57896] [4.8 Regression] ICE in expand_expr_real_2 2013-07-15 6:44 [Bug c/57896] New: ICE in in expand_expr_real_2 zeccav at gmail dot com ` (15 preceding siblings ...) 2014-02-20 10:27 ` [Bug target/57896] " jakub at gcc dot gnu.org @ 2014-02-20 10:41 ` jakub at gcc dot gnu.org 2014-02-20 10:45 ` ubizjak at gmail dot com ` (14 subsequent siblings) 31 siblings, 0 replies; 33+ messages in thread From: jakub at gcc dot gnu.org @ 2014-02-20 10:41 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896 --- Comment #20 from Jakub Jelinek <jakub at gcc dot gnu.org> --- So, from quick skim of relevant routines that do gen_reg_rtx, I see: gen_reg_rtx called only after if (d->testing_p) return true;, thus ok: expand_vec_perm_blend expand_vec_perm_pshufb expand_vec_perm_palignr expand_vec_perm_vpermq_perm_1 expand_vec_perm_vperm2f128 expand_vec_perm_vperm2f128_vblend expand_vec_perm_2vperm2f128_vshuf expand_vec_perm_vpshufb2_vpermq expand_vec_perm_vpshufb2_vpermq_even_odd expand_vec_perm_vpshufb4_vpermq2 Does not look at testing_p at all, not ok: expand_vec_perm_pshufb2 expand_vec_perm_even_odd_1 Not ok: expand_vec_perm_interleave2 expand_vec_perm_broadcast_1 So, I think we want to fix those 4 routines. ^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug target/57896] [4.8 Regression] ICE in expand_expr_real_2 2013-07-15 6:44 [Bug c/57896] New: ICE in in expand_expr_real_2 zeccav at gmail dot com ` (16 preceding siblings ...) 2014-02-20 10:41 ` jakub at gcc dot gnu.org @ 2014-02-20 10:45 ` ubizjak at gmail dot com 2014-02-20 10:57 ` jakub at gcc dot gnu.org ` (13 subsequent siblings) 31 siblings, 0 replies; 33+ messages in thread From: ubizjak at gmail dot com @ 2014-02-20 10:45 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896 --- Comment #21 from Uroš Bizjak <ubizjak at gmail dot com> --- --cut here-- Index: config/i386/i386.c =================================================================== --- config/i386/i386.c (revision 207935) +++ config/i386/i386.c (working copy) @@ -40666,9 +40666,9 @@ ix86_vectorize_vec_perm_const_ok (enum machine_mod if (!d.one_operand_p) d.op1 = gen_raw_REG (d.vmode, LAST_VIRTUAL_REGISTER + 3); - start_sequence (); + init_dummy_function_start (); ret = ix86_expand_vec_perm_const_1 (&d); - end_sequence (); + expand_dummy_function_end (); return ret; } --cut here-- Jakub, what do you think about this patch? >From gcc-bugs-return-444331-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Feb 20 10:53:34 2014 Return-Path: <gcc-bugs-return-444331-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org> Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 8515 invoked by alias); 20 Feb 2014 10:53:33 -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 8461 invoked by uid 48); 20 Feb 2014 10:53:29 -0000 From: "amker.cheng at gmail dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/60280] [4.9 Regression] gcc.target/arm/ivopts.c and gcc.target/arm/ivopts-2.c failed caused by preserving loop structure. Date: Thu, 20 Feb 2014 10:53:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: amker.cheng 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: 4.9.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: <bug-60280-4-zqvy3ZK2yw@http.gcc.gnu.org/bugzilla/> In-Reply-To: <bug-60280-4@http.gcc.gnu.org/bugzilla/> References: <bug-60280-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-02/txt/msg02088.txt.bz2 Content-length: 258 http://gcc.gnu.org/bugzilla/show_bug.cgi?id`280 --- Comment #3 from bin.cheng <amker.cheng at gmail dot com> --- I think 4_8 is ok for this case. At least it doesn't have http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01530.html committed if I was right. ^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug target/57896] [4.8 Regression] ICE in expand_expr_real_2 2013-07-15 6:44 [Bug c/57896] New: ICE in in expand_expr_real_2 zeccav at gmail dot com ` (17 preceding siblings ...) 2014-02-20 10:45 ` ubizjak at gmail dot com @ 2014-02-20 10:57 ` jakub at gcc dot gnu.org 2014-02-20 11:01 ` ubizjak at gmail dot com ` (12 subsequent siblings) 31 siblings, 0 replies; 33+ messages in thread From: jakub at gcc dot gnu.org @ 2014-02-20 10:57 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896 --- Comment #22 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Uroš Bizjak from comment #21) > --- config/i386/i386.c (revision 207935) > +++ config/i386/i386.c (working copy) > @@ -40666,9 +40666,9 @@ ix86_vectorize_vec_perm_const_ok (enum machine_mod > if (!d.one_operand_p) > d.op1 = gen_raw_REG (d.vmode, LAST_VIRTUAL_REGISTER + 3); > > - start_sequence (); > + init_dummy_function_start (); > ret = ix86_expand_vec_perm_const_1 (&d); > - end_sequence (); > + expand_dummy_function_end (); > > return ret; > } > --cut here-- > > Jakub, what do you think about this patch? IMHO that is way too expensive. So, say expand_vec_perm_interleave2 is only called with d->testing_p from ix86_vectorize_vec_perm_const_ok, and thus I'd say something like: if (!d->testing_p) { dremap.target = gen_reg_rtx (dremap.vmode); dfinal.op0 = gen_lowpart (dfinal.vmode, dremap.target); } dfinal.op1 = dfinal.op0; should fix expand_vec_perm_interleave2. I think dfinal.op0 should have dfinal.vmode already from the caller (we can easily perhaps gcc_checking_assert double check it when testing the patch). >From gcc-bugs-return-444334-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Feb 20 10:57:16 2014 Return-Path: <gcc-bugs-return-444334-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org> Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 11783 invoked by alias); 20 Feb 2014 10:57: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 11718 invoked by uid 48); 20 Feb 2014 10:57:11 -0000 From: "vogt at linux dot vnet.ibm.com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug go/60288] gccgo crashes compiling '*func_ptr(0)' Date: Thu, 20 Feb 2014 10:57:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: go X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: vogt at linux dot vnet.ibm.com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: ian at airs dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: <bug-60288-4-RibpBO22rB@http.gcc.gnu.org/bugzilla/> In-Reply-To: <bug-60288-4@http.gcc.gnu.org/bugzilla/> References: <bug-60288-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-02/txt/msg02091.txt.bz2 Content-length: 298 http://gcc.gnu.org/bugzilla/show_bug.cgi?id`288 --- Comment #1 from Dominik Vogt <vogt at linux dot vnet.ibm.com> --- > So it looks like gccgo reads the expression as > > (*pg)(0) ^^^^^^^^ I meant -> (*(&g))(0) > while golang reads it as > > *(pg(0)) ^^^^^^^^ -> *(&(g(0))) ^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug target/57896] [4.8 Regression] ICE in expand_expr_real_2 2013-07-15 6:44 [Bug c/57896] New: ICE in in expand_expr_real_2 zeccav at gmail dot com ` (18 preceding siblings ...) 2014-02-20 10:57 ` jakub at gcc dot gnu.org @ 2014-02-20 11:01 ` ubizjak at gmail dot com 2014-02-20 11:07 ` [Bug target/57896] [4.7/4.8/4.9 " ubizjak at gmail dot com ` (11 subsequent siblings) 31 siblings, 0 replies; 33+ messages in thread From: ubizjak at gmail dot com @ 2014-02-20 11:01 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896 --- Comment #23 from Uroš Bizjak <ubizjak at gmail dot com> --- (In reply to Jakub Jelinek from comment #22) > IMHO that is way too expensive. Agreed. Anyway, it looks you got this problem under control ;) >From gcc-bugs-return-444336-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Feb 20 11:07:20 2014 Return-Path: <gcc-bugs-return-444336-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org> Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 18560 invoked by alias); 20 Feb 2014 11:07:19 -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 18521 invoked by uid 48); 20 Feb 2014 11:07:15 -0000 From: "dominiq at lps dot ens.fr" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/60236] gfortran.dg/vect/pr32380.f fails on ARM Date: Thu, 20 Feb 2014 11:07:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: dominiq at lps dot ens.fr 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: Message-ID: <bug-60236-4-SA9cHIP9ad@http.gcc.gnu.org/bugzilla/> In-Reply-To: <bug-60236-4@http.gcc.gnu.org/bugzilla/> References: <bug-60236-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-02/txt/msg02093.txt.bz2 Content-length: 1631 http://gcc.gnu.org/bugzilla/show_bug.cgi?id`236 --- Comment #7 from Dominique d'Humieres <dominiq at lps dot ens.fr> --- > This patch tries to solve the problem in a more general way. > I wonder if one of you could try this patch on PowerPC? Sorry for the late answer, but my G5 was buzzy regtesting. With the patch in comment 5, tested with make -k check-gfortran RUNTESTFLAGS="vect.exp=pr32380.f --target_board=unix'{-m32,-m64}'" I get === gfortran tests == Schedule of variations: unix/-m32 unix/-m64 Running target unix/-m32 Using /sw/share/dejagnu/baseboards/unix.exp as board description file for target. Using /sw/share/dejagnu/config/unix.exp as generic interface file for target. Using /opt/gcc/work/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /opt/gcc/work/gcc/testsuite/gfortran.dg/vect/vect.exp ... === gfortran Summary for unix/-m32 == # of expected passes 2 Running target unix/-m64 Using /sw/share/dejagnu/baseboards/unix.exp as board description file for target. Using /sw/share/dejagnu/config/unix.exp as generic interface file for target. Using /opt/gcc/work/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /opt/gcc/work/gcc/testsuite/gfortran.dg/vect/vect.exp ... === gfortran Summary for unix/-m64 == # of expected passes 2 === gfortran Summary == # of expected passes 4 /opt/gcc/darwin_buildw/gcc/testsuite/gfortran/../../gfortran version 4.9.0 20140218 (experimental) [trunk revision 207836p2] (GCC) So the patch is OK for powerpc-apple-darwin9. ^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug target/57896] [4.7/4.8/4.9 Regression] ICE in expand_expr_real_2 2013-07-15 6:44 [Bug c/57896] New: ICE in in expand_expr_real_2 zeccav at gmail dot com ` (19 preceding siblings ...) 2014-02-20 11:01 ` ubizjak at gmail dot com @ 2014-02-20 11:07 ` ubizjak at gmail dot com 2014-02-20 11:42 ` jakub at gcc dot gnu.org ` (10 subsequent siblings) 31 siblings, 0 replies; 33+ messages in thread From: ubizjak at gmail dot com @ 2014-02-20 11:07 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896 Uroš Bizjak <ubizjak at gmail dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- Target| |x86 Target Milestone|4.8.4 |4.7.4 Summary|[4.8 Regression] ICE in |[4.7/4.8/4.9 Regression] |expand_expr_real_2 |ICE in expand_expr_real_2 Severity|minor |normal --- Comment #24 from Uroš Bizjak <ubizjak at gmail dot com> --- >From a quick view of expand_vec_perm_interleave2, the problem is latent on 4.9 and 4.7 branches. Probably more important than P3 due to data corruption, but let RMs decide. >From gcc-bugs-return-444338-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Feb 20 11:34:39 2014 Return-Path: <gcc-bugs-return-444338-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org> Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 5642 invoked by alias); 20 Feb 2014 11:34:38 -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 5615 invoked by uid 48); 20 Feb 2014 11:34:34 -0000 From: "mpolacek at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/60276] [4.7/4.8 Regression] -O3 autovectorizer breaks on a particular loop Date: Thu, 20 Feb 2014 11:34:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 4.8.2 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: mpolacek 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: 4.7.4 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: <bug-60276-4-mCpSZjIMtr@http.gcc.gnu.org/bugzilla/> In-Reply-To: <bug-60276-4@http.gcc.gnu.org/bugzilla/> References: <bug-60276-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-02/txt/msg02095.txt.bz2 Content-length: 469 http://gcc.gnu.org/bugzilla/show_bug.cgi?id`276 Marek Polacek <mpolacek at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek <mpolacek at gcc dot gnu.org> --- It fails for me with trunk: r207224 works, but starting with r207225 it fails again. ^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug target/57896] [4.7/4.8/4.9 Regression] ICE in expand_expr_real_2 2013-07-15 6:44 [Bug c/57896] New: ICE in in expand_expr_real_2 zeccav at gmail dot com ` (20 preceding siblings ...) 2014-02-20 11:07 ` [Bug target/57896] [4.7/4.8/4.9 " ubizjak at gmail dot com @ 2014-02-20 11:42 ` jakub at gcc dot gnu.org 2014-02-20 12:00 ` jakub at gcc dot gnu.org ` (9 subsequent siblings) 31 siblings, 0 replies; 33+ messages in thread From: jakub at gcc dot gnu.org @ 2014-02-20 11:42 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896 --- Comment #25 from Jakub Jelinek <jakub at gcc dot gnu.org> --- Created attachment 32180 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32180&action=edit gcc48-pr57896.patch So like this (4.8 version, untested)? Uros, can you please double-check it? The point is, if d->testing_p is true, we should do as few work as possible, certainly not call any emit_insn or gen_reg_rtx, and as soon as we know we'll certainly eventually return true, return it. ^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug target/57896] [4.7/4.8/4.9 Regression] ICE in expand_expr_real_2 2013-07-15 6:44 [Bug c/57896] New: ICE in in expand_expr_real_2 zeccav at gmail dot com ` (21 preceding siblings ...) 2014-02-20 11:42 ` jakub at gcc dot gnu.org @ 2014-02-20 12:00 ` jakub at gcc dot gnu.org 2014-02-20 12:09 ` ubizjak at gmail dot com ` (8 subsequent siblings) 31 siblings, 0 replies; 33+ messages in thread From: jakub at gcc dot gnu.org @ 2014-02-20 12:00 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896 --- Comment #26 from Jakub Jelinek <jakub at gcc dot gnu.org> --- Created attachment 32181 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32181&action=edit gcc49-pr57896.patch Corresponding 4.9 version, which is somewhat different due to my? changes not to emit subregs on the lhs when possible. ^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug target/57896] [4.7/4.8/4.9 Regression] ICE in expand_expr_real_2 2013-07-15 6:44 [Bug c/57896] New: ICE in in expand_expr_real_2 zeccav at gmail dot com ` (22 preceding siblings ...) 2014-02-20 12:00 ` jakub at gcc dot gnu.org @ 2014-02-20 12:09 ` ubizjak at gmail dot com 2014-02-20 13:00 ` jakub at gcc dot gnu.org ` (7 subsequent siblings) 31 siblings, 0 replies; 33+ messages in thread From: ubizjak at gmail dot com @ 2014-02-20 12:09 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896 --- Comment #27 from Uroš Bizjak <ubizjak at gmail dot com> --- (In reply to Jakub Jelinek from comment #25) > Created attachment 32180 [details] > gcc48-pr57896.patch > > So like this (4.8 version, untested)? Uros, can you please double-check it? > The point is, if d->testing_p is true, we should do as few work as possible, > certainly not call any emit_insn or gen_reg_rtx, and as soon as we know > we'll certainly eventually return true, return it. I have started bootstrap/regtest on 4.8 branch, together with following patch: --cut here-- Index: emit-rtl.c =================================================================== --- emit-rtl.c (revision 207935) +++ emit-rtl.c (working copy) @@ -894,6 +894,9 @@ gen_reg_rtx (enum machine_mode mode) return gen_rtx_CONCAT (mode, realpart, imagpart); } + /* Do not call gen_reg_rtx with uninitialized crtl. */ + gcc_assert (crtl->emit.regno_pointer_align_length); + /* Make sure regno_pointer_align, and regno_reg_rtx are large enough to have an element for this pseudo reg number. */ --cut here-- I will propose this patch for mainline, hopefully to save someone from debugging this nasty data corruption. >From gcc-bugs-return-444350-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Feb 20 12:09:55 2014 Return-Path: <gcc-bugs-return-444350-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org> Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 4810 invoked by alias); 20 Feb 2014 12:09:55 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: <gcc-bugs.gcc.gnu.org> List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/> List-Post: <mailto:gcc-bugs@gcc.gnu.org> List-Help: <mailto:gcc-bugs-help@gcc.gnu.org> Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 4461 invoked by uid 48); 20 Feb 2014 12:09:51 -0000 From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/60276] [4.7/4.8/4.9 Regression] -O3 autovectorizer breaks on a particular loop Date: Thu, 20 Feb 2014 12:09:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 4.8.2 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.7.4 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: <bug-60276-4-nvcLahbBSd@http.gcc.gnu.org/bugzilla/> In-Reply-To: <bug-60276-4@http.gcc.gnu.org/bugzilla/> References: <bug-60276-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-02/txt/msg02107.txt.bz2 Content-length: 942 http://gcc.gnu.org/bugzilla/show_bug.cgi?id`276 --- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> --- And with less convoluted vectorized code but still broken (avoids integer promotions): extern void abort (void); static void foo (int *out, const int *lp, const int *hp, unsigned samples) { int x, target; for (x = 0, target = 0; x < (int)samples; x += 2, target++) { out[x + 0] = lp[target] - ((hp[target] + hp[target - 1] + 2) >> 2); out[x - 1] = hp[target - 1] + ((out[x - 2] + out[x]) >> 1); } } int main(void) { const int lp[25] = { 0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30, 32, 34, 36, 38, 40, 42, 44, 46, 48, }; const int hp[25] = {0}; int out[49] = {0}; int s; out[0] = lp[0] - (((hp[0] << 1) + 2) >> 2); foo (out + 2, lp + 1, hp + 1, 48); for (s = 0; s < 49; s++) if (out[s] != s) abort (); return 0; } ^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug target/57896] [4.7/4.8/4.9 Regression] ICE in expand_expr_real_2 2013-07-15 6:44 [Bug c/57896] New: ICE in in expand_expr_real_2 zeccav at gmail dot com ` (23 preceding siblings ...) 2014-02-20 12:09 ` ubizjak at gmail dot com @ 2014-02-20 13:00 ` jakub at gcc dot gnu.org 2014-02-20 13:12 ` ubizjak at gmail dot com ` (6 subsequent siblings) 31 siblings, 0 replies; 33+ messages in thread From: jakub at gcc dot gnu.org @ 2014-02-20 13:00 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896 --- Comment #28 from Jakub Jelinek <jakub at gcc dot gnu.org> --- Perhaps just make it gcc_checking_assert? ^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug target/57896] [4.7/4.8/4.9 Regression] ICE in expand_expr_real_2 2013-07-15 6:44 [Bug c/57896] New: ICE in in expand_expr_real_2 zeccav at gmail dot com ` (24 preceding siblings ...) 2014-02-20 13:00 ` jakub at gcc dot gnu.org @ 2014-02-20 13:12 ` ubizjak at gmail dot com 2014-02-20 17:25 ` ubizjak at gmail dot com ` (5 subsequent siblings) 31 siblings, 0 replies; 33+ messages in thread From: ubizjak at gmail dot com @ 2014-02-20 13:12 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896 --- Comment #29 from Uroš Bizjak <ubizjak at gmail dot com> --- (In reply to Jakub Jelinek from comment #28) > Perhaps just make it gcc_checking_assert? On release branches perhaps, but the consequences of crtl->emit.regno_pointer_align_length == 0 warrant ICE even in the released compiler. We are talking about "ICE in gen_reg_rtx ..." vs. "some random ICE due to corrupted internal data" (as is this PR) reports. From maintainer's POV, I'd like to have gcc_assert in development and release branches. >From gcc-bugs-return-444358-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Feb 20 13:15:03 2014 Return-Path: <gcc-bugs-return-444358-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org> Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 1327 invoked by alias); 20 Feb 2014 13:15:02 -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 1195 invoked by uid 48); 20 Feb 2014 13:14:54 -0000 From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/60268] [4.9 regression] ICE: in rank_for_schedule, at haifa-sched.c:2557 Date: Thu, 20 Feb 2014 13:15:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: abel at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.9.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: <bug-60268-4-q6qqBUZQ6o@http.gcc.gnu.org/bugzilla/> In-Reply-To: <bug-60268-4@http.gcc.gnu.org/bugzilla/> References: <bug-60268-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-02/txt/msg02115.txt.bz2 Content-length: 185 http://gcc.gnu.org/bugzilla/show_bug.cgi?id`268 --- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> --- If this works, fine with me, but I'll defer the review to Vladimir. ^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug target/57896] [4.7/4.8/4.9 Regression] ICE in expand_expr_real_2 2013-07-15 6:44 [Bug c/57896] New: ICE in in expand_expr_real_2 zeccav at gmail dot com ` (25 preceding siblings ...) 2014-02-20 13:12 ` ubizjak at gmail dot com @ 2014-02-20 17:25 ` ubizjak at gmail dot com 2014-02-20 20:40 ` jakub at gcc dot gnu.org ` (4 subsequent siblings) 31 siblings, 0 replies; 33+ messages in thread From: ubizjak at gmail dot com @ 2014-02-20 17:25 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896 --- Comment #30 from Uroš Bizjak <ubizjak at gmail dot com> --- (In reply to Jakub Jelinek from comment #25) > Created attachment 32180 [details] > gcc48-pr57896.patch > > So like this (4.8 version, untested)? Uros, can you please double-check it? > The point is, if d->testing_p is true, we should do as few work as possible, > certainly not call any emit_insn or gen_reg_rtx, and as soon as we know > we'll certainly eventually return true, return it. I have: - eyeballed the code a bit and found no issues (this is sorta unreliable test). - bootstrapped and regression tested on x86_64-pc-linux-gnu {,-m32} with the gen_reg_rtx patch from Comment #27 applied. - additionaly tested with GCC_TEST_RUN_EXPENSIVE=1 make check-gcc RUNTESTFLAGS='--target_board=unix\{-msse2,-msse4,-mavx\} dg-torture.exp=vshuf*' on x86_64 AVX target (also with gen_reg_rtx patch applied) and found no issues. - I don't have AVX2 target to test on, perhaps the above test should be also run on AVX2 capable target with -mavx2 option added, preferably with gen_reg_rtx patch applied. >From gcc-bugs-return-444395-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Feb 20 17:42:52 2014 Return-Path: <gcc-bugs-return-444395-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org> Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 16228 invoked by alias); 20 Feb 2014 17:42: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 16168 invoked by uid 48); 20 Feb 2014 17:42:48 -0000 From: "dominiq at lps dot ens.fr" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/60292] New: [4.9 Regression] ICE: in fill_vec_av_set, at sel-sched.c:3863 with -m64 after r206174 on powerpc-apple-darwin9.8.0 Date: Thu, 20 Feb 2014 17:42:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new 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: dominiq at lps dot ens.fr 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 cc cf_gcchost cf_gcctarget cf_gccbuild Message-ID: <bug-60292-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-02/txt/msg02152.txt.bz2 Content-length: 1103 http://gcc.gnu.org/bugzilla/show_bug.cgi?id`292 Bug ID: 60292 Summary: [4.9 Regression] ICE: in fill_vec_av_set, at sel-sched.c:3863 with -m64 after r206174 on powerpc-apple-darwin9.8.0 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: abel at gcc dot gnu.org, iains at gcc dot gnu.org Host: powerpc-apple-darwin9 Target: powerpc-apple-darwin9 Build: powerpc-apple-darwin9 Compiling the test gfortran.dg/pr44691.f with -m64 -O2 -fselective-scheduling2 gives the following ICE /opt/gcc/work/gcc/testsuite/gfortran.dg/pr44691.f:39:0: internal compiler error: in fill_vec_av_set, at sel-sched.c:3863 END Line 3863 of sel-sched.c is the gcc_assert /* A fence insn should not get here. */ gcc_assert (!fence_insn_p); introduced by r206174. ^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug target/57896] [4.7/4.8/4.9 Regression] ICE in expand_expr_real_2 2013-07-15 6:44 [Bug c/57896] New: ICE in in expand_expr_real_2 zeccav at gmail dot com ` (26 preceding siblings ...) 2014-02-20 17:25 ` ubizjak at gmail dot com @ 2014-02-20 20:40 ` jakub at gcc dot gnu.org 2014-02-20 20:41 ` jakub at gcc dot gnu.org ` (3 subsequent siblings) 31 siblings, 0 replies; 33+ messages in thread From: jakub at gcc dot gnu.org @ 2014-02-20 20:40 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896 --- Comment #31 from Jakub Jelinek <jakub at gcc dot gnu.org> --- Author: jakub Date: Thu Feb 20 20:39:46 2014 New Revision: 207969 URL: http://gcc.gnu.org/viewcvs?rev=207969&root=gcc&view=rev Log: PR target/57896 * config/i386/i386.c (expand_vec_perm_interleave2): Don't call gen_reg_rtx if d->testing_p. (expand_vec_perm_pshufb2, expand_vec_perm_broadcast_1): Return early if d->testing_p and we will certainly return true. (expand_vec_perm_even_odd_1): Likewise. Don't call gen_reg_rtx if d->testing_p. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c ^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug target/57896] [4.7/4.8/4.9 Regression] ICE in expand_expr_real_2 2013-07-15 6:44 [Bug c/57896] New: ICE in in expand_expr_real_2 zeccav at gmail dot com ` (27 preceding siblings ...) 2014-02-20 20:40 ` jakub at gcc dot gnu.org @ 2014-02-20 20:41 ` jakub at gcc dot gnu.org 2014-02-20 20:42 ` [Bug target/57896] [4.7 " jakub at gcc dot gnu.org ` (2 subsequent siblings) 31 siblings, 0 replies; 33+ messages in thread From: jakub at gcc dot gnu.org @ 2014-02-20 20:41 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896 --- Comment #32 from Jakub Jelinek <jakub at gcc dot gnu.org> --- Author: jakub Date: Thu Feb 20 20:40:52 2014 New Revision: 207970 URL: http://gcc.gnu.org/viewcvs?rev=207970&root=gcc&view=rev Log: PR target/57896 * config/i386/i386.c (expand_vec_perm_interleave2): Don't call gen_reg_rtx if d->testing_p. (expand_vec_perm_pshufb2, expand_vec_perm_even_odd_1, expand_vec_perm_broadcast_1): Return early if d->testing_p and we will certainly return true. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/i386/i386.c ^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug target/57896] [4.7 Regression] ICE in expand_expr_real_2 2013-07-15 6:44 [Bug c/57896] New: ICE in in expand_expr_real_2 zeccav at gmail dot com ` (28 preceding siblings ...) 2014-02-20 20:41 ` jakub at gcc dot gnu.org @ 2014-02-20 20:42 ` jakub at gcc dot gnu.org 2014-02-21 7:56 ` uros at gcc dot gnu.org 2014-02-21 8:01 ` ubizjak at gmail dot com 31 siblings, 0 replies; 33+ messages in thread From: jakub at gcc dot gnu.org @ 2014-02-20 20:42 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896 Jakub Jelinek <jakub at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|[4.7/4.8/4.9 Regression] |[4.7 Regression] ICE in |ICE in expand_expr_real_2 |expand_expr_real_2 --- Comment #33 from Jakub Jelinek <jakub at gcc dot gnu.org> --- Hopefully fixed for 4.8+ for now. ^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug target/57896] [4.7 Regression] ICE in expand_expr_real_2 2013-07-15 6:44 [Bug c/57896] New: ICE in in expand_expr_real_2 zeccav at gmail dot com ` (29 preceding siblings ...) 2014-02-20 20:42 ` [Bug target/57896] [4.7 " jakub at gcc dot gnu.org @ 2014-02-21 7:56 ` uros at gcc dot gnu.org 2014-02-21 8:01 ` ubizjak at gmail dot com 31 siblings, 0 replies; 33+ messages in thread From: uros at gcc dot gnu.org @ 2014-02-21 7:56 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896 --- Comment #34 from uros at gcc dot gnu.org --- Author: uros Date: Fri Feb 21 07:55:35 2014 New Revision: 207983 URL: http://gcc.gnu.org/viewcvs?rev=207983&root=gcc&view=rev Log: Backport from mainline 2014-02-21 Jakub Jelinek <jakub@redhat.com> * config/i386/i386.c (ix86_expand_vec_perm): Use V8SImode mode for mask of V8SFmode permutation. Backport from 4.8 branch 2014-02-20 Jakub Jelinek <jakub@redhat.com> PR target/57896 * config/i386/i386.c (expand_vec_perm_interleave2): Don't call gen_reg_rtx if d->testing_p. (expand_vec_perm_pshufb2, expand_vec_perm_even_odd_1, expand_vec_perm_broadcast_1): Return early if d->testing_p and we will certainly return true. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/config/i386/i386.c ^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug target/57896] [4.7 Regression] ICE in expand_expr_real_2 2013-07-15 6:44 [Bug c/57896] New: ICE in in expand_expr_real_2 zeccav at gmail dot com ` (30 preceding siblings ...) 2014-02-21 7:56 ` uros at gcc dot gnu.org @ 2014-02-21 8:01 ` ubizjak at gmail dot com 31 siblings, 0 replies; 33+ messages in thread From: ubizjak at gmail dot com @ 2014-02-21 8:01 UTC (permalink / raw) To: gcc-bugs [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 4430 bytes --] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896 UroÅ¡ Bizjak <ubizjak at gmail dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED URL| |http://gcc.gnu.org/ml/gcc-p | |atches/2014-02/msg01255.htm | |l Resolution|--- |FIXED --- Comment #35 from UroÅ¡ Bizjak <ubizjak at gmail dot com> --- Fixed everywhere. >From gcc-bugs-return-444446-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Feb 21 08:20:24 2014 Return-Path: <gcc-bugs-return-444446-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org> Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 27049 invoked by alias); 21 Feb 2014 08:20:23 -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 27006 invoked by uid 48); 21 Feb 2014 08:20:18 -0000 From: "terry.guo at arm dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/60298] New: [ARM/Thumb1] ICE caused by LRA for case pr54713-1.c Date: Fri, 21 Feb 2014 08:20:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new 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: terry.guo at arm 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 attachments.created Message-ID: <bug-60298-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-02/txt/msg02203.txt.bz2 Content-length: 1977 http://gcc.gnu.org/bugzilla/show_bug.cgi?id`298 Bug ID: 60298 Summary: [ARM/Thumb1] ICE caused by LRA for case pr54713-1.c Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: terry.guo at arm dot com Created attachment 32185 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id2185&actioníit case to reproduce the ICE This issue is found during regression test of latest trunk for Thumb-1 target Cortex-M0. Here is command to reproduce this issue: terguo01@terry-pc01:case$ ../install-native/bin/arm-none-eabi-gcc -O0 -w -c -mthumb -mcpu=cortex-m0 -o pr54713-1.o pr54713-1.c pr54713-1.c: In function 'f10': pr54713-1.c:70:1: internal compiler error: Segmentation fault } ^ 0xb1b7ce crash_signal /myssd/terguo01/toolchain-build/lra-regression/src/gcc/gcc/toplev.c:337 0xaeccbf simplify_replace_fn_rtx(rtx_def*, rtx_def const*, rtx_def* (*)(rtx_def*, rtx_def const*, void*), void*) /myssd/terguo01/toolchain-build/lra-regression/src/gcc/gcc/simplify-rtx.c:417 0x9a6df3 update_equiv /myssd/terguo01/toolchain-build/lra-regression/src/gcc/gcc/lra-constraints.c:351 0x9b06e7 lra_constraints(bool) /myssd/terguo01/toolchain-build/lra-regression/src/gcc/gcc/lra-constraints.c:4054 0x99d609 lra(_IO_FILE*) /myssd/terguo01/toolchain-build/lra-regression/src/gcc/gcc/lra.c:2339 0x94b7af do_reload /myssd/terguo01/toolchain-build/lra-regression/src/gcc/gcc/ira.c:5457 0x94baf8 rest_of_handle_reload /myssd/terguo01/toolchain-build/lra-regression/src/gcc/gcc/ira.c:5598 0x94bb42 execute /myssd/terguo01/toolchain-build/lra-regression/src/gcc/gcc/ira.c:5627 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions. ^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2014-02-21 8:01 UTC | newest] Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-07-15 6:44 [Bug c/57896] New: ICE in in expand_expr_real_2 zeccav at gmail dot com 2013-07-15 9:37 ` [Bug c/57896] " mikpe at it dot uu.se 2013-07-15 14:23 ` mikpe at it dot uu.se 2013-07-15 15:32 ` glisse at gcc dot gnu.org 2013-07-15 16:32 ` glisse at gcc dot gnu.org 2013-07-15 23:42 ` zeccav at gmail dot com 2013-07-16 6:19 ` zeccav at gmail dot com 2014-02-19 8:11 ` [Bug c/57896] [4.8 Regression] ICE " mpolacek at gcc dot gnu.org 2014-02-19 17:59 ` [Bug target/57896] " ubizjak at gmail dot com 2014-02-19 18:06 ` ubizjak at gmail dot com 2014-02-19 18:34 ` ubizjak at gmail dot com 2014-02-19 18:37 ` [Bug middle-end/57896] " ubizjak at gmail dot com 2014-02-19 19:19 ` mpolacek at gcc dot gnu.org 2014-02-20 9:29 ` ubizjak at gmail dot com 2014-02-20 9:58 ` ubizjak at gmail dot com 2014-02-20 10:15 ` ubizjak at gmail dot com 2014-02-20 10:27 ` [Bug target/57896] " jakub at gcc dot gnu.org 2014-02-20 10:41 ` jakub at gcc dot gnu.org 2014-02-20 10:45 ` ubizjak at gmail dot com 2014-02-20 10:57 ` jakub at gcc dot gnu.org 2014-02-20 11:01 ` ubizjak at gmail dot com 2014-02-20 11:07 ` [Bug target/57896] [4.7/4.8/4.9 " ubizjak at gmail dot com 2014-02-20 11:42 ` jakub at gcc dot gnu.org 2014-02-20 12:00 ` jakub at gcc dot gnu.org 2014-02-20 12:09 ` ubizjak at gmail dot com 2014-02-20 13:00 ` jakub at gcc dot gnu.org 2014-02-20 13:12 ` ubizjak at gmail dot com 2014-02-20 17:25 ` ubizjak at gmail dot com 2014-02-20 20:40 ` jakub at gcc dot gnu.org 2014-02-20 20:41 ` jakub at gcc dot gnu.org 2014-02-20 20:42 ` [Bug target/57896] [4.7 " jakub at gcc dot gnu.org 2014-02-21 7:56 ` uros at gcc dot gnu.org 2014-02-21 8:01 ` ubizjak at gmail dot com
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).