Hi Jeff,
On Mon, 29 Sep 2014 22:40:58, Jeff Law wrote:
On 09/27/14 03:53, Bernd Edlinger wrote:
Comment before this change. Someone not familiar with this code is
going to have no idea why these two lines exist.
Ok, I added a comment now, do you like it?
Yes.
Please try to include a
On 09/30/14 03:01, Bernd Edlinger wrote:
Sigh. Yea, I guess if we're hitting the allocator insanely hard,
scrubbing memory might turn out to slow things down in a significant
way. Or it may simply be the case that we're using free'd memory in
some way and with the MALLOC_PERTURB changes we're in
On 09/27/14 03:53, Bernd Edlinger wrote:
Comment before this change. Someone not familiar with this code is
going to have no idea why these two lines exist.
Ok, I added a comment now, do you like it?
Yes.
Please try to include a testcase. If you're having trouble reproducing
on the
Hmm, original massage bounced, resent, without html.
From: bernd.edlin...@hotmail.de
To: l...@redhat.com; gcc-patches@gcc.gnu.org
CC: jos...@codesourcery.com
Subject: RE: [PATCH] Fix PR preprocessor/58893 access to uninitialized memory
Date: Sat, 27 Sep
Hi,
this patch fixes PR58893, which is an access to uninitialized memory, which may
or may not crash in
linemap_resolve_location, or just print error messages with bogus location.
When the first -include file is processed we have the case, where
pfile-cur_token == pfile-cur_run-base, this is
On Fri, Sep 26, 2014 at 02:16:05PM +0200, Bernd Edlinger wrote:
Boot-Strapped and Regression-tested on x86_64-linux-gnu
Ok for trunk?
-ENOPATCH.
Marek
Aehm, sorry.,
again, with patch files.
Hi,
this patch fixes PR58893, which is an access to uninitialized memory, which
may or may not crash in
linemap_resolve_location, or just print error messages with bogus location.
When the first -include file is processed we have the case, where
On 09/26/14 06:21, Bernd Edlinger wrote:
Hi,
this patch fixes PR58893, which is an access to uninitialized memory, which
may or may not crash in
linemap_resolve_location, or just print error messages with bogus location.
When the first -include file is processed we have the case, where
