XS test failing when compiling on Debian Wheezy because of old GCC version (4.7.2)

[ledvinap]

there seems to be some problem in trapezoid code in master.

    my $expolygon = Slic3r::ExPolygon->new($square);
    my $polygons = $expolygon->get_trapezoids(PI/2);
    is scalar(@$polygons), 1, 'correct number of trapezoids returned'; 

get_trapezoids returns empty list. Tracing the code everything is fine until passing polygon to boost::polygon::get_trapezoids() call, but this function returns empty list.

maybe assign is problem after assign(ps, polygon_set); :

(gdb) p polygon_set
$2 = std::vector of length 1, capacity 1 = {{contour = {<Slic3r::MultiPoint> = {_vptr.MultiPoint = 0x7ffff69e86d0, points = std::vector of length 4, capacity 4 = {{x = 100, y = 100}, {x = 200, y = 100}, {x = 200, y = 200}, {x = 100, y = 200}}}, <No data fields>}, holes = std::vector of length 0, capacity 0}}
(gdb) p ps
$3 = {data_ = std::vector of length 1, capacity 1 = {{first = {first = {coords_ = {100, 100}}, second = {coords_ = {100, 200}}}, second = 1}}, dirty_ = true, unsorted_ = true, is_45_ = true}

The template magic in boost is out of my reach ...
testing on debian stable,

cc --verison
cc (Debian 4.7.2-5) 4.7.2

[alranel]

Hm, not nice. It compiles and tests fine on all my OS X machines, various systems using clang and gcc. Will test on Ubuntu, crossing fingers...

[ledvinap]

Tried on another debian machine(same cc version), exactly same result ...

[ledvinap]

Another bad news - building XS with perl Build.PL --config optimize="-O0 -ggdb3" works ...
Any idea where to look?

[ledvinap]

Works with -Os, -O1, -O1 with all -f<> optimizations of O2 enabled ...

Current workaround is placing

Build_PL --config optimize="-Os -g"

into ~/.modulebuildrc

[alranel]

:-/

[alranel]

Bad news: compilation and XS tests succeed on my Ubuntu x86_64 with gcc 4.6.3...

[alranel]

It succeeds also on a Ubuntu i386 with same gcc 4.6.3...

[alranel]

If I were able to reproduce the issue I would try to write a simple C++ executable test case.

[ledvinap]

Hmm :-(
I could try to debug it, but debugging template metaprogramming with optimization enabled is crazy...

[alranel]

Isn't "-O1 with all -f<> optimizations of O2 enabled" equal to -O2?

[ledvinap]

No, it isn't (according to google and stack overflow). Some optimizations are only affected by -O level and not exported otherwise (by design).

[alranel]

Thanks to @ledvinap's research:

https://svn.boost.org/trac/boost/ticket/8695

Just compile code from ticket in xs/src directory (attached, just use
local boost and possibly c++98):
cc -std=c++11 -O2 -I. -lstdc++ boosttest.cpp -o boosttest && ./boosttest
poly_set area: 100
cc -std=c++11 -O1 -I. -lstdc++ boosttest.cpp -o boosttest && ./boosttest
poly_set area: 0

Also kicad folks had been bitten too:
https://bugs.launchpad.net/kicad/+bug/1056926, they just disabled
optimization as a fix ..

[ledvinap]

here is the test file: https://drive.google.com/file/d/0B9HM4UOKDQBLQXlnMHFlYXc4bHM/edit?usp=sharing

[alranel]

To summarize the problem, a bug introduced in GCC 4.7.0 and fixed in 4.7.3 prevents Boost.Polygon from returning correct results when -O2 or -O3 are used.
Debian Wheezy ships GCC 4.7.2, so ignoring the issue and requiring 4.7.3 would be a problem for users of that distro.

The bug was reported to Boost.Polygon maintainers in https://svn.boost.org/trac/boost/ticket/8695 but they closed it as worksforme since it can't be reproduced with an updated version of GCC. I reported the bug to Debian maintainers in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746261 but it's unlikely they will upgrade GCC or backport a patch for it.

I tried using a #pragma directive to lower the optimization level just locally, but it looks like it only works when using O0 (while -O1 is sufficient from command line):

#pragma GCC optimize ("O0")

Available options are:

• use the above #pragma with O0 when a faulty GCC version is detected using macros
• use -O1 for everything when a faulty GCC version is detected in Build.PL
• use another algorithm for trapezoidation (maybe slower but more robust and less dependent on Boost maintainers)

[ledvinap]

Simplest solution is probably detecting 4.7.[0-2] gcc in Build.PL and use -O1 + enable all optimization options that have command line option and are enabled in -O2

cc  -std=c++11 -O1  -fcaller-saves -fcrossjumping -fcse-follow-jumps -fdevirtualize -fexpensive-optimizations -fgcse -findirect-inlining -finline-small-functions -fipa-cp -fipa-sra -foptimize-register-move -foptimize-sibling-calls -foptimize-strlen -fpartial-inlining -fpeephole2 -free -fregmove -freorder-blocks -freorder-functions -frerun-cse-after-loop -fschedule-insns2 -fstrict-aliasing -fstrict-overflow -fthread-jumps -ftree-builtin-call-dce -ftree-pre -ftree-switch-conversion -ftree-tail-merge -ftree-vrp -I. -lstdc++ boosttest.cpp -o boosttest && ./boosttest

[ledvinap]

Could someone test slicing speed difference on working gcc? I can't do it simply myself ...

[alranel]

cpanm -f ./xs will install XS ignoring test results (and wrong trapezoidation isn't an issue for most slicing jobs), so you (and I) can do comparisons on the same Wheezy box.

[alranel]

What about having the O3 -f optimizations added too? Have you tried?

[alranel]

Bad news. ExtUtils::CBuilder forces the same optimization options used when compiling perl. I guess this is sane behavior, since the compiled library wouldn't be linkable to perl if they used different flags.

[alranel]

New get_trapezoids2() in place. It doesn't use Boost.Polygon anymore. Not too slow.

[ledvinap]

BTW: here is (vary badly designed) test slicing bunny-flatfoot.stl from #1916. Ten runs were made for each optimization level on slightly loaded server, only user time reported:

Flags       AVG   STDEV (runs)                                  
-O1         17.89 0.12  (17.94,17.82,18.01,17.86,17.82,17.84,18.12,17.68,17.82,18)
-O1+flags   17.35 0.28  (18.01,17.6,17.31,17.14,17.2,17.13,17.09,17.43,17.18,17.45)
-O2         17.48 0.16  (17.46,17.6,17.4,17.39,17.29,17.83,17.38,17.33,17.49,17.63)
-O3         17.07 0.06  (17.06,17.06,17.2,17.12,17.14,17.06,17.06,17.05,16.97,17.04)
-O0         58.60 0.25  (58.32,58.53,58.57,58.63,59.17,58.53,58.74,58.71,58.97,58.38)

Nothing representative (maybe it would be nice to add some test cases to slic3r repository for benchmarking), but quick conclusion is that c optimization after O1 is not something that matters much ... (the -O0 case is interresting ... )

[alranel]

Interesting. Those tests are a very useful reference. Unfortunately it looks like we can't use different optimizations settings than the ones used when compiling perl (perl -V | grep optimize will show them) because they are concatenated after the extra_compiler_settings provided in Build.PL and there's no way to change them. I think that's by design otherwise the shared library won't be linkable.

[alranel]

I think this can be closed now as it was fixed by replacing Boost.Polygon with another algorithm. No further action can be taken regarding -O flags...

[alranel]

Thank you @ledvinap for your help troubleshooting this one.

[ledvinap]

BTW: how does perl Build.PL --configure "optimize=-O1" work? It's impossible to do the some thing from inside of Build.PL?
Optimization settings should have no effect on public interface (and thus linking against different optimization). Also it worked for me for the optimization bug ...

[alranel]

I just did a test on the test Debian machine, and that does not work either. This is the generated command:

cc -I/usr/lib/perl/5.14/CORE -fPIC -xc++ -D_FILE_OFFSET_BITS=64 -D_GLIBCXX_USE_C99 -DHAS_BOOL -DNOGDI -DSLIC3RXS -O1 -fcaller-saves -fcrossjumping -fcse-follow-jumps -fdevirtualize -fexpensive-optimizations -fgcse -findirect-inlining -finline-small-functions -fipa-cp -fipa-sra -foptimize-register-move -foptimize-sibling-calls -foptimize-strlen -fpartial-inlining -fpeephole2 -free -fregmove -freorder-blocks -freorder-functions -frerun-cse-after-loop -fschedule-insns2 -fstrict-aliasing -fstrict-overflow -fthread-jumps -ftree-builtin-call-dce -ftree-pre -ftree-switch-conversion -ftree-tail-merge -ftree-vrp -Isrc -Ibuildtmp -c -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fstack-protector -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -o src/ClipperUtils.o src/ClipperUtils.cpp

ExtUtils::CBuilder hard-codes $Config{optimize} at the end of the command (-O2 -g in this case), no matter what you have put before. :-(

[ledvinap]

So there is no way to override $Config{optimize} inside Build.PL as if it is done from command line? I am a bit lost, CBuilder is totally new to me (and I am not too keen on learning it)

[alranel]

Actually, even when supplying it on command line it doesn't override $Config{optimize}... I was referring exactly to that test in the previous message...

[ledvinap]

Are you passing --config to perl Build.PL? It doesn't work with ./Build script if I remember correctly
perl Build.PL --config optimize="-O1 -ggdb3"

[alranel]

Yay! Got feedback from Boost devs:
https://svn.boost.org/trac/boost/ticket/8695#comment:10

[alranel]

I confirm -fno-inline-small-functions works, and also works regardless of the position of -Ox in the command line. I committed the relevant change to xs/Build.PL.

[llluis]

Sorry for digging old issue here, but I'm building a fresh new install with:

• Windows 7 64bits,
• strawberry-perl-5.22.0.1-64bit-portable,
• gcc (x86_64-posix-sjlj, built by strawberryperl.com project) 4.9.2
• master 6ac79e3

and I get an error (non-blocking) because of this fix (command not found in french):

Running Build.PL
Configuring F:/Software/Slic3r-master/xs ... 'cc' n'est pas reconnu en tant que commande interne ou externe, un programme exécutable ou un fichier de commandes.

While this has no impact in my build, maybe we need a cleanup here?