[Bug target/67484] options-save.c sanitizer asan detects freed storage referenced heap-use-after-free

["ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67484

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |NEW
           Assignee|ubizjak at gmail dot com           |unassigned at gcc dot gnu.org

--- Comment #7 from Uroš Bizjak <ubizjak at gmail dot com> ---
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: <gcc-bugs-return-497352-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
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: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
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" <gcc-bugzilla@gcc.gnu.org>
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: <bug-46942-4-oKpLO2mucS@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-46942-4@http.gcc.gnu.org/bugzilla/>
References: <bug-46942-4@http.gcc.gnu.org/bugzilla/>
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?idF942

James Y Knight <foom at fuhm dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |foom at fuhm dot net

--- Comment #10 from James Y Knight <foom at fuhm dot net> ---
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