On 02/03/16 06:20, Jakub Jelinek wrote:
On Sun, Feb 28, 2016 at 09:56:24PM +0000, Tom Hughes wrote:
From past experience I know that they haven't shown a huge amount of
interest in failures that are specific to 32 bit platforms though in this
case they do have somebody that has been trying to tame some of the wilder
excesses of memory usage in the compilations.
You can try to look at which optimization pass is requiring most memory and
perhaps disable it for 32-bit host building on selected source files.
g++ -fmem-report -ftime-report could help in figuring that out.
E.g. if it is debug info generation, you might try to just decrease quality
of the debug info through -fno-var-tracking-assignments, if it is
var-tracking itself, you might try to decrease
--param max-vartrack-size=50000000 to smaller value, or
--param max-vartrack-expr-depth=12 , or --param max-vartrack-reverse-op-size=50
Does the problematic source file contain one huge function (especially with
lots of control flow)? You might want to try -O1 in that case (-O1 is an
option generally trying to avoid most of quadratic algorithms both in
compile time and memory time, meant e.g. for huge generated functions with
lots of control flow).
Upstream has come up with a patch now that seems to have fixed things
and I managed a scratch build on all platforms. Diagnosis and patch are:
https://github.com/mapnik/mapnik/issues/3327#issuecomment-190433248
https://github.com/mapnik/mapnik/pull/3338
Tom
--
Tom Hughes (tom@xxxxxxxxxx)
http://compton.nu/
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
