From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 38434 invoked by alias); 16 Sep 2015 16:45:10 -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 38374 invoked by uid 48); 16 Sep 2015 16:45:05 -0000 From: "ubizjak at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/67484] options-save.c sanitizer asan detects freed storage referenced heap-use-after-free Date: Wed, 16 Sep 2015 16:45: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: 6.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ubizjak at gmail dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 6.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status assigned_to 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: 2015-09/txt/msg01329.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D67484 Uro=C5=A1 Bizjak changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEW Assignee|ubizjak at gmail dot com |unassigned at gcc d= ot gnu.org --- Comment #7 from Uro=C5=A1 Bizjak --- This should be implemented with garbage collected strings to avoid leaks. Unassigning, I don't know GCC's garbage collector well. >>From gcc-bugs-return-497352-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Sep 16 17:12:52 2015 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 44664 invoked by alias); 16 Sep 2015 17:12:52 -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 44595 invoked by uid 48); 16 Sep 2015 17:12:47 -0000 From: "foom at fuhm dot net" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/46942] x86_64 parameter passing unnecessary sign/zero extends Date: Wed, 16 Sep 2015 17: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.6.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: foom at fuhm dot net X-Bugzilla-Status: NEW X-Bugzilla-Resolution: 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: 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: 2015-09/txt/msg01330.txt.bz2 Content-length: 1557 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46942 James Y Knight changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |foom at fuhm dot net --- Comment #10 from James Y Knight --- Well, the ABI doc doesn't appear to say anything about this still. GCC as of 5.1 seems to still do sign/zero extension of 8/16-bit arguments to 32-bit on the callee side. Clang does not. Both do extension of 32-bit arguments to 64-bit on the callee side. Both sign/zero-extend 8/16-bit values to 32-bits, and do /not/ truncate 64-bit values to 32-bit on the caller side. So it looks like GCC could still generate more optimal code by taking advantage of the "de-facto" ABI that lets you assume 32-bit sign/zero-extension has happened on arguments. But it'd also be real nice for this all to be actually documented, so there's something to point people to. :) BTW: This undocumentedness came up recently with an optimizer change in clang: libjpeg-turbo has some assembly code which was using the full 64-bit value of an argument register, assuming the upper bits would be zeroed, while on the C side, the function was declared as taking an "int". The upper bits are thus left undefined (as is correct, per the unwritten ABI rules), which broke the asm. https://github.com/libjpeg-turbo/libjpeg-turbo/pull/20 http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20150907/138253.html