From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-403652-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 25884 invoked by alias); 14 Oct 2012 19:23:26 -0000
Received: (qmail 25851 invoked by uid 48); 14 Oct 2012 19:23:11 -0000
From: "hjl.tools at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug other/54691] [4.8 Regression] --enable-checking=valgrind doesn't build
Date: Sun, 14 Oct 2012 19:23:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: other
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hjl.tools at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields:
Message-ID: <bug-54691-4-rhAxELOwLX@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-54691-4@http.gcc.gnu.org/bugzilla/>
References: <bug-54691-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
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
X-SW-Source: 2012-10/txt/msg01328.txt.bz2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54691

--- Comment #8 from H.J. Lu <hjl.tools at gmail dot com> 2012-10-14 19:23:11 UTC ---
(In reply to comment #7)
> Created attachment 28445 [details]
> Prototype patch that introduces VALGRIND_MAKE_MEM_DEFINED
> 
> Attached prototype patch builds on HJ's patch. The patch detects valgrind in
> the same way as in gcc directory (actually, it just copies relevant bits) and
> changes:
> 
> +      memset (to.text + to.len + 1, 0, 16);
> 
> to
> 
> +      VALGRIND_DISCARD (VALGRIND_MAKE_MEM_DEFINED (to.text + to.len + 1, 16));
> 
> (BTW: Probably, we should align end of buffer to 16 byte boundary instead of
> hardcoding 16.)
> 

libcpp will read in advance beyond the end of buffer in
some cases, even without SSE optimization.