Boost C++ Libraries: Ticket #8695: boost::polygon faillure with optimizations enabled on g++-4.7.2

owner, status changed

Andrii Sydorchuk — Sun, 16 Jun 2013 01:10:24 GMT

owner changed from Lucanus Simonson to Andrii Sydorchuk
status new → assigned

Andrii Sydorchuk — Sun, 16 Jun 2013 01:31:30 GMT

Hi,

I've tried to reproduce the given behavior with g++ 4.7.3, however got correct output.

[CLI] g++ -I ~/Downloads/boost_1_53_0 -Wall -std=c++0x -g -O2 -v main.cpp && ./a.out
[OUTPUT] poly_set area: 100

We've got a few other reports, that state some flakiness with -O2 flag for g++ 4.7.2.

Would it be feasible for you to upgrade to 4.7.3 and verify the failure?

hodevel@… — Mon, 01 Jul 2013 15:51:30 GMT

Hi,

Compiled gcc-4.7.3 on the same machine to test. Got no problem with gcc-4.7.3 - just like you.

Using gdb is not very easy since optimizations are enabled. Is there any other test I can run to find what's wrong ? Maybe this is more a bug of gcc rather than a bug in boost polygon...

status changed; resolution set

Andrii Sydorchuk — Thu, 07 Nov 2013 00:01:34 GMT

status assigned → closed
resolution → worksforme

I didn't have enough time to go deeper in this issue. So far I was not able to reproduce it, thus marking it as resolved. Potentially the issue here might be with the snap-rounding modes used by the Polygon. If that's the case the issue will be a duplicate of the ticket #6063.

aar@… — Mon, 28 Apr 2014 09:44:17 GMT

Hello, get_trapezoids() is affected too, and I can reproduce the issue on any Debian Wheezy machine, since that distro uses 4.7.2. It looks like the gcc issue might be http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56125 or http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54767

I think this needs to be reopened and investigated, and some macros need to be added to workaround the issue if 4.7.0, 4.7.1 or 4.7.2 is detected. While upgrading to 4.7.3 makes the problem disappear, the great popularity of gcc 4.7.2 (thanks to Debian Wheezy) raises the need for a built-in workaround IMHO.

aar@… — Mon, 28 Apr 2014 10:06:12 GMT

What about adding this to the relevant Boost.Polygon file(s):

#pragma GCC optimize ("O1")

wrapped in a conditional check for GCC version? Would the maintainers accept such a patch?

Andrii Sydorchuk — Sun, 04 May 2014 12:13:15 GMT

Thank you for your email aar.
I would prefer to avoid applying such a fix without understanding the actual reason of the issue.
I was able to reproduce the behavior on ARMv6, Arch OS, g++ 4.7.2 with the following compilation prompt:
g++ -O2 main.cpp -I ../../boost/libs/polygon -std=c++11
Going to investigate.

aar@… — Sun, 04 May 2014 12:17:36 GMT

Thank you asydorchuk for investigating. Maybe the GCC bugs I linked can give hints about the code patterns to look for?

Andrii Sydorchuk — Sun, 04 May 2014 12:53:56 GMT

Those are definitely a good references.
I've also found the following report: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60766.

Andrii Sydorchuk — Wed, 07 May 2014 23:49:46 GMT

I've found the defect in the optimizer. Only one edge (instead of four) is inserted into the resulting polygon_data_set inside the polygon_set_data.hpp:insert_vertex_sequence call.

Using binary search I've figured out, that this behavior is caused by the following g++ compilation option: -f-inline-small-functions.

It would be great if you could confirm that adding flag -fno-inline-small-functions to your prompt fixes the issue with trapezoids.

Polygon code is in places quite convoluted. I rewrote insert_vertex_sequence so that it's more readable for humans and less confusing for compiler. Please find the patch attached. It will be automatically released with the next version of Boost.

attachment set

Andrii Sydorchuk — Wed, 07 May 2014 23:50:10 GMT

attachment → 8695.patch

aar@… — Sat, 10 May 2014 15:00:58 GMT

Hi asydorchuk, sorry for the late reply. I can confirm that the OP code snippet works for me when I compile it with: -O3 -fno-inline-small-functions I also confirm that my trapezoid code works correctly if I compile with -fno-inline-small-functions -O3 (unfortunately my toolchain does not let me append anything after -O3 but luckily enough -f options take precedence over -O regardless of their position).

Andrii Sydorchuk — Sat, 10 May 2014 21:55:08 GMT

Glad to hear. I would assume that 8695 patch will also fix the issue, even without using -fno-inline-small-functions flag.