From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24380 invoked by alias); 14 Jun 2013 23:15:13 -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 24275 invoked by uid 48); 14 Jun 2013 23:15:02 -0000 From: "Simon.Richter at hogyros dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/52347] -Wno-tabs -Wall -Wno-tabs still warns about tabs Date: Fri, 14 Jun 2013 23:15:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 4.7.0 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: Simon.Richter at hogyros dot de 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: In-Reply-To: References: 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: 2013-06/txt/msg00767.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D52347 --- Comment #4 from Simon Richter --- Testcase is simple: $ cat tt.cpp void bar(int baz) { } $ g++-4.7 -c -W -Wall -Werror -Wno-unused tt.cpp=20 $ g++-4.8 -c -W -Wall -Werror -Wno-unused tt.cpp=20 tt.cpp:1:6: error: unused parameter =E2=80=98baz=E2=80=99 [-Werror=3Dunused= -parameter] void bar(int baz) { } ^ cc1plus: all warnings being treated as errors >>From gcc-bugs-return-424389-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jun 14 23:19:34 2013 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 25889 invoked by alias); 14 Jun 2013 23:19:34 -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 25861 invoked by uid 48); 14 Jun 2013 23:19:29 -0000 From: "ccoutant at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/57451] Incorrect debug ranges emitted for -freorder-blocks-and-partition -g Date: Fri, 14 Jun 2013 23:19: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.8.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ccoutant 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: In-Reply-To: References: 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-06/txt/msg00768.txt.bz2 Content-length: 4046 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57451 --- Comment #4 from Cary Coutant --- The problem is a lexical block in main() that appears to be getting split by -freorder-blocks-and-partition, but when debug info is emitted during rest_of_handle_final(), this particular lexical block still appears to be a single block -- BLOCK_FRAGMENT_CHAIN is NULL, so the DWARF output code decides that it can emit a DW_AT_low_pc/high_pc pair instead of a DW_AT_ranges. The DW_AT_high_pc is now being output relative to DW_AT_low_pc, so we see an assembly expression .LBE14 - .LBB14, which are labels attached to the block start and block end, and should be in the same section. Here's the block: (gdb) p stmt $1 = (tree) 0x7ffff5f4c4b0 (gdb) pt warning: Expression is not an assignment (and might have no effect) sizes-gimplified unsigned DI size unit size align 64 symtab 0 alias set -1 canonical type 0x7ffff609b930> readonly tree_1 tree_3 unsigned decl_5 DI file pr49115.C line 21 col 25 size unit size align 64 context > supercontext used tree_1 tree_3 decl_5 SI file pr49115.C line 18 col 8 size unit size align 128 context (reg/v:SI 64 [ data ])> supercontext subblocks supercontext subblocks chain >>>> (gdb) p stmt->block $2 = {base = {code = BLOCK, side_effects_flag = 0, constant_flag = 0, addressable_flag = 0, volatile_flag = 0, readonly_flag = 0, asm_written_flag = 1, nowarning_flag = 0, visited = 0, used_flag = 1, nothrow_flag = 0, static_flag = 0, public_flag = 0, private_flag = 0, protected_flag = 0, deprecated_flag = 0, default_def_flag = 0, u = {bits = {lang_flag_0 = 0, lang_flag_1 = 0, lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0, lang_flag_5 = 0, lang_flag_6 = 0, saturating_flag = 0, unsigned_flag = 0, packed_flag = 0, user_align = 0, nameless_flag = 1, spare0 = 0, spare1 = 0, address_space = 0}, length = 2048, version = 2048}}, chain = 0x0, abstract_flag = 0, block_num = 14, locus = 0, vars = 0x7ffff608bc78, nonlocalized_vars = 0x0, subblocks = 0x0, supercontext = 0x7ffff60c00f0, abstract_origin = 0x0, fragment_origin = 0x0, fragment_chain = 0x0} Here's the fragment of assembly code between .LBB14 and .LBE14: .LBB14: # pr49115.C:21 .loc 1 21 0 call __cxa_begin_catch .LVL7: call __cxa_end_catch .LVL8: .p2align 4,,5 # SUCC: 3 [100.0%] count:1 jmp .L15 .cfi_endproc .section .text.unlikely .cfi_startproc .cfi_personality 0x3,__gxx_personality_v0 .cfi_lsda 0x3,.LLSDAC4 # BLOCK 6 freq:5000 seq:4 # PRED: 4 [50.0%] (CROSSING,CAN_FALLTHRU) .L14: .cfi_def_cfa_offset 16 .p2align 4,,8 .LEHB1: # SUCC: call _Unwind_Resume .LEHE1: .LVL9: .LBE14: .LBE15: .cfi_endproc You can see that the block from .LBB14 to .LBE14 has been split across two sections. In order for dwarf2out to generate the proper debug info, BLOCK_FRAGMENT_CHAIN(stmt) needs to be non-NULL. I'm not sure why that's not happening when the block is split.