tags 625756 +wheezy sid
thanks
this bug does not affect squeeze as the default gcc there is 4.4
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
On 19/09/11 15:55, Colin Watson wrote:
On Thu, Sep 08, 2011 at 06:14:49PM +0100, Colin Watson wrote:
* Build with -fno-tree-dse, since otherwise GCC= 4.5 misoptimises
allocateMoreSlots() (closes: #625756, LP: #749139).
In fact, as GCC upstream pointed out, a more targeted - and I
On Thu, Sep 08, 2011 at 06:14:49PM +0100, Colin Watson wrote:
* Build with -fno-tree-dse, since otherwise GCC = 4.5 misoptimises
allocateMoreSlots() (closes: #625756, LP: #749139).
In fact, as GCC upstream pointed out, a more targeted - and I think more
correct - fix is
On Mon, Sep 19, 2011 at 03:55:57PM +0100, Colin Watson wrote:
On Thu, Sep 08, 2011 at 06:14:49PM +0100, Colin Watson wrote:
* Build with -fno-tree-dse, since otherwise GCC = 4.5 misoptimises
allocateMoreSlots() (closes: #625756, LP: #749139).
In fact, as GCC upstream pointed out, a
tags 625756 patch
user ubuntu-de...@lists.ubuntu.com
usertags 625756 ubuntu-patch oneiric
On Thu, May 05, 2011 at 05:54:35PM +, brian m. carlson wrote:
When I build electric-fence from source on amd64/sid with gcc-4.5 or
gcc-4.6, the ./tstheap 3072 call gets to iteration 100 and then starts
Package: electric-fence
Version: 2.1.16
Severity: serious
When I build electric-fence from source on amd64/sid with gcc-4.5 or
gcc-4.6, the ./tstheap 3072 call gets to iteration 100 and then starts
allocating massive amounts of memory. Within less than a minute it goes
through 3.5GB of physical
6 matches
Mail list logo
