From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24446 invoked by alias); 13 Oct 2016 10:20:08 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 24422 invoked by uid 89); 13 Oct 2016 10:20:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:2296, Location X-HELO: mail-lf0-f52.google.com Received: from mail-lf0-f52.google.com (HELO mail-lf0-f52.google.com) (209.85.215.52) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 13 Oct 2016 10:19:57 +0000 Received: by mail-lf0-f52.google.com with SMTP id l131so91675822lfl.2 for ; Thu, 13 Oct 2016 03:19:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xvP/MViTJUmSEBXPFLY9oIaaIUjKvb0VzhgoaK6Xh0U=; b=hD14sbg4n3bq9crvwR+T5Ouy2EePZHMs+sd4BARwakdlunghn8gyIPvPcMdl7lR5Mj n6AY4xypu/wmg340sY/EYdC3y29RiAtPOti/qqpR5MFBJws4vOnAxupFZMaMgQHVGvEo zQG/m3Aeu6R/pMRfsV5T9QEfedeTwvDH12jndbwUdpil+R9XQz2g4M+1Rmcli8AjVnjo kPviM0FL5bMV9avT+Ol7HmzOstjGY/0G3wR3bNbDjchKLeeTjf7KqQCz1PdCRE4A1tcQ hC2Nybo1mdhbxpkK1gapp/EON4chRDzc3+rAVL/anVQGEVFr1q8+EDlGegVmYtpuLbpA hqVw== X-Gm-Message-State: AA6/9Rniw1fp4ClDnFSNs5aMCTMRdmb1b1JEx/SfyPVOgTGapkRcQnDLCnqkAiiXkQ5lumeKYkYwvS9FnY4HXg== X-Received: by 10.28.197.67 with SMTP id v64mr1638820wmf.9.1476353993528; Thu, 13 Oct 2016 03:19:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.155.146 with HTTP; Thu, 13 Oct 2016 03:19:53 -0700 (PDT) In-Reply-To: <1624828.Cq9Sk6vVoa@polaris> References: <1863165.r8qPLI7fxq@polaris> <2004625.PcKOVMIpSq@polaris> <1624828.Cq9Sk6vVoa@polaris> From: Richard Biener Date: Thu, 13 Oct 2016 10:20:00 -0000 Message-ID: Subject: Re: [patch] Fix GC issue triggered by arithmetic overflow checking To: Eric Botcazou Cc: GCC Patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-10/txt/msg01002.txt.bz2 On Thu, Oct 13, 2016 at 12:15 PM, Eric Botcazou wrote: >> Yes. But that's not the only source for DECL_UID differences. Btw, >> I see lots of FOR_EACH_HASH_TABLE_ELEMENT in var-tracking.c >> but they don't look like their outcome is supposed to be dependent on >> element ordering. > > This leads to NOTE_INSN_VAR_LOCATION notes emitted in a different order, which > are then interpreted by dwarf2out_var_location. In particular: > > (note 6350 6349 6351 (var_location temp (nil)) NOTE_INSN_VAR_LOCATION) > (note 6351 6350 6352 (var_location temp$low (mem/c:DI (plus:SI (reg/f:SI 30 > %fp) > (const_int -112 [0xffffffffffffff90])) [10 MEM[(struct cpp_num > *)&result + 8B]+0 S8 A64])) NOTE_INSN_VAR_LOCATION) > (note 6352 6351 6353 (var_location temp$8 (nil)) NOTE_INSN_VAR_LOCATION) > [...] > (code_label 2091 6355 2092 79 912 "" [1 uses]) > (note 2092 2091 5271 79 [bb 79] NOTE_INSN_BASIC_BLOCK) > > is interpreted differently from: > > (note 6350 6349 6351 (var_location temp (nil)) NOTE_INSN_VAR_LOCATION) > (note 6351 6350 6352 (var_location temp$8 (nil)) NOTE_INSN_VAR_LOCATION) > (note 6352 6351 6353 (var_location temp$low (mem/c:DI (plus:SI (reg/f:SI 30 > %fp) > (const_int -112 [0xffffffffffffff90])) [10 MEM[(struct cpp_num > *)&result + 8B]+0 S8 A64])) NOTE_INSN_VAR_LOCATION) > [...] > (note 2092 2091 5271 79 [bb 79] NOTE_INSN_BASIC_BLOCK) > > @@ -32608,6 +32608,17 @@ > .uleb128 0x8 > .byte 0x93 ! DW_OP_piece > .uleb128 0x8 > + .uaword .LLVL592-.LLtext0 ! Location list begin address > (*.LLLST153) > + .uaword .LLVL597-.LLtext0 ! Location list end address > (*.LLLST153) > + .uahalf 0x9 ! Location expression size > + .byte 0x93 ! DW_OP_piece > + .uleb128 0x8 > + .byte 0x8e ! DW_OP_breg30 > + .sleb128 -112 > + .byte 0x93 ! DW_OP_piece > + .uleb128 0x8 > + .byte 0x93 ! DW_OP_piece > + .uleb128 0x8 > .uaword .LLVL695-.LLtext0 ! Location list begin address > (*.LLLST153) > .uaword .LLVL696-.LLtext0 ! Location list end address > (*.LLLST153) > .uahalf 0xe ! Location expression size > > probably because the non-null location comes last in the second case. Definitely looks like a bug to me. Can you open a PR for this so it doesn't get lost? Thanks, Richard. > -- > Eric Botcazou