From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31516 invoked by alias); 15 Feb 2015 08:40:14 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 31483 invoked by uid 48); 15 Feb 2015 08:40:11 -0000 From: "trippels at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/65066] New: [5 Regression] ICE: Segmentation fault with -Wformat=2 Date: Sun, 15 Feb 2015 08:40:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: trippels 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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-02/txt/msg01629.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D65066 Bug ID: 65066 Summary: [5 Regression] ICE: Segmentation fault with -Wformat=3D2 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org CC: mpolacek at gcc dot gnu.org markus@x4 /tmp % cat rt_names.i extern int sscanf(__const char *__restrict __s, __const char *__restrict __format, ...); int *a; void foo() { sscanf(0, "0x%x #", a); } markus@x4 /tmp % gcc -Wformat=3D2 -c rt_names.i rt_names.i: In function =E2=80=98foo=E2=80=99: rt_names.i:4:1: internal compiler error: Segmentation fault void foo() { sscanf(0, "0x%x #", a); } ^ 0xaed31f crash_signal ../../gcc/gcc/toplev.c:383 0x57c131 check_format_types ../../gcc/gcc/c-family/c-format.c:2495 0x57c131 check_format_info_main ../../gcc/gcc/c-family/c-format.c:2326 0x6a6ec8 check_format_arg ../../gcc/gcc/c-family/c-format.c:1623 0x6a7604 check_format_info ../../gcc/gcc/c-family/c-format.c:1358 0x6a7604 check_function_format(tree_node*, int, tree_node**) ../../gcc/gcc/c-family/c-format.c:1028 0x6949a7 check_function_arguments(tree_node const*, int, tree_node**) ../../gcc/gcc/c-family/c-common.c:9540 0x6293dd build_function_call_vec(unsigned int, vec, tree_node*, vec*, vec*) ../../gcc/gcc/c/c-typeck.c:2994 0x64b44a c_parser_postfix_expression_after_primary ../../gcc/gcc/c/c-parser.c:7894 0x644a36 c_parser_postfix_expression ../../gcc/gcc/c/c-parser.c:7715 0x6470fa c_parser_unary_expression ../../gcc/gcc/c/c-parser.c:6602 0x647d0f c_parser_cast_expression ../../gcc/gcc/c/c-parser.c:6440 0x647ef2 c_parser_binary_expression ../../gcc/gcc/c/c-parser.c:6255 0x648a55 c_parser_conditional_expression ../../gcc/gcc/c/c-parser.c:6031 0x649030 c_parser_expr_no_commas ../../gcc/gcc/c/c-parser.c:5949 0x649702 c_parser_expression ../../gcc/gcc/c/c-parser.c:8022 0x64a129 c_parser_expression_conv ../../gcc/gcc/c/c-parser.c:8055 0x642988 c_parser_statement_after_labels ../../gcc/gcc/c/c-parser.c:5115 0x644183 c_parser_compound_statement_nostart ../../gcc/gcc/c/c-parser.c:4701 0x65605e c_parser_compound_statement ../../gcc/gcc/c/c-parser.c:4538 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See for instructions. Probably started with r220677. >>From gcc-bugs-return-477297-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Feb 15 08:59:28 2015 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 18002 invoked by alias); 15 Feb 2015 08:59:27 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 17686 invoked by uid 48); 15 Feb 2015 08:59:23 -0000 From: "terry.guo at arm dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/65067] New: regression on accessing volatile bit field Date: Sun, 15 Feb 2015 08:59:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: major 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 Message-ID: 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: 2015-02/txt/msg01630.txt.bz2 Content-length: 2263 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65067 Bug ID: 65067 Summary: regression on accessing volatile bit field Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: terry.guo at arm dot com Due to the impact of option -fstrict-volatile-bitfields, current trunk gcc generate worse code to access volatile bitfield which can be nicely handled with gcc 4.8. Here is test case: $ cat y.c #include struct tmp { uint32_t dummy; union { struct { uint32_t xyz : 1; uint32_t mode: 3; uint32_t res : 28; } bf; uint32_t wordval; } reg; }; void set_mode(int mode) { volatile struct tmp *t = (struct tmp *) 0x1000; t->reg.bf.mode = mode; } When compiled with gcc 4.8 and command "gcc-arm-none-eabi-4_8-2014q3/bin/arm-none-eabi-gcc -mthumb -mcpu=cortex-m3 -O2 -S y.c", the generated code is good and expected: mov r3, #4096 ldr r2, [r3, #4] bfi r2, r0, #1, #3 str r2, [r3, #4] bx lr But when compiled with current gcc 5.0 and same command, worse code is generated: mov r2, #4096 ldr r3, [r2, #4] and r0, r0, #7 bic r3, r3, #14 orr r3, r3, r0, lsl #1 str r3, [r2, #4] bx lr If turn off the option -fstrict-volatile-bitfields, we can get expected code. In my opinion, this gcc code is making bad decision: /* Handle -fstrict-volatile-bitfields in the cases where it applies. */ if (strict_volatile_bitfield_p (str_rtx, bitsize, bitnum, fieldmode, bitregion_start, bitregion_end)) { The function strict_volatile_bitfield_p should make correct decision that we don't need to consider strict volatile bitfield here for this case. When debug this function, the arguments are: Breakpoint 1, strict_volatile_bitfield_p (op0=0x7ffff6096e88, bitsize=3, bitnum=33, fieldmode=SImode, bitregion_start=32, bitregion_end=63) The mode of op0 is also SImode. So it should be easy to figure out that we are working on a perfect 32-bit entity and no boundary crossing here.