From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22403 invoked by alias); 4 Dec 2014 19:51:47 -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 22358 invoked by uid 48); 4 Dec 2014 19:51:43 -0000 From: "law at redhat dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md Date: Thu, 04 Dec 2014 19:51: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: 5.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: law at redhat dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: enkovich.gnu at gmail dot com 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: 2014-12/txt/msg00500.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003 --- Comment #19 from Jeffrey A. Law --- I was thinking more along the lines of documented in the texi documention for Length attributes. Useful to have in sh.md, but better documented in a location that is more likely to be read. I don't think that inlining ix86_bnd_prefixed_insn_p in the attribute stuff is really wise. Are you suggesting that we can put in a dummy clause similar to the sh or pa ports to resolve this issue? For reference the PA port's hack looks like: (set (attr "length") (cond [(and (const_int 0) (eq (const_int 0) (pc))) (const_int 8)] (symbol_ref "pa_attr_length_call (insn, 0)")))]) The result of this hack is that during shortening these insns are considered as having a fixed length (8 bytes). So we might overestimte their actual size and generate more long branches than necessary. We have the length right by final, so the final version may be shorter than the conservative estimate during shorten-branches.