On Wed, Aug 3, 2011 at 14:15, Gabriel Charette wrote:
> We will probably need the strings in here until the end of the
> compilation, so we could either just not free it (i.e. memory leak,
> but allow important when program is over...)
>
> Or we could strcpy the strings pph'ed in, but that involv
My linemap implementation just caught a very important failure due to
this patch (because of it's massive use of pph_in_string for
filenames).
We CANNOT free stream->encoder.r.file_data this early as it contains
all of the strings streamed in (which are refered to directly from all
over the place
I removed the build directories and rebuilt. Everything worked.
There are gremlins in the machine.
On 7/29/11, Gabriel Charette wrote:
> I just stashed all my changes and pulled in the latest svn HEAD this
> morning to check if I was seeing these failures:
>
> Repository Root: svn+ssh://gcc.gnu.
I just stashed all my changes and pulled in the latest svn HEAD this
morning to check if I was seeing these failures:
Repository Root: svn+ssh://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 176906
Node Kind: directory
Schedule: normal
Last Changed Author: cro
On Thu, Jul 28, 2011 at 16:30, Lawrence Crowl wrote:
> I'm getting massive failures after incorporating this change:
>
> bytecode stream: trying to read 1735 bytes after the end of the
> input buffer
>
> where the number of bytes changes. Suggestions?
Odd. I'm getting the usual results with
I'm getting massive failures after incorporating this change:
bytecode stream: trying to read 1735 bytes after the end of the
input buffer
where the number of bytes changes. Suggestions?
On 7/28/11, Diego Novillo wrote:
> Noticed this while debugging the new tree encoding cache. No
> f
