0

When compiling with GCC 12.2 the optimization flag appears to add warnings that otherwise didn't show up. I'm wondering if this is expected behavior or a bug. If it is expected are there ways around it (besides not using the flag)? Take the following example:

#include <boost/geometry.hpp>

using Point2D = boost::geometry::model::d2::point_xy<double>;
using Polygon2D = boost::geometry::model::polygon<Point2D>;
using MultiPolygon2D = boost::geometry::model::multi_polygon<Polygon2D>;

int main() {
  
  MultiPolygon2D one, two, result;
  boost::geometry::union_(one, two, result);
  
  return 0;
}

If compiled with -Wall it's clean (this is Fedora 37, Boost 1.78)

[sample]$ g++ --version
g++ (GCC) 12.2.1 20221121 (Red Hat 12.2.1-4)
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[sample]$ g++ -o main test.cpp -Wall -std=c++17

However if any of the -O optimization flags are added there are suddenly warnings that I would have thought would get picked up in the first place.

[sample]$ g++ -o main test.cpp -Wall -O3 -std=c++17
In file included from /usr/include/boost/geometry/policies/robustness/get_rescale_policy.hpp:39,
                 from /usr/include/boost/geometry/algorithms/detail/relate/turns.hpp:23,
                 from /usr/include/boost/geometry/algorithms/detail/relate/linear_linear.hpp:32,
                 from /usr/include/boost/geometry/algorithms/detail/relate/implementation.hpp:24,
                 from /usr/include/boost/geometry/algorithms/relate.hpp:15,
                 from /usr/include/boost/geometry/algorithms/detail/within/implementation.hpp:32,
                 from /usr/include/boost/geometry/algorithms/detail/covered_by/implementation.hpp:25,
                 from /usr/include/boost/geometry/algorithms/covered_by.hpp:24,
                 from /usr/include/boost/geometry/algorithms/detail/buffer/buffered_piece_collection.hpp:32,
                 from /usr/include/boost/geometry/algorithms/detail/buffer/buffer_inserter.hpp:29,
                 from /usr/include/boost/geometry/algorithms/buffer.hpp:41,
                 from /usr/include/boost/geometry/geometry.hpp:66,
                 from /usr/include/boost/geometry.hpp:17,
                 from test.cpp:1:
In constructor ‘boost::geometry::detail::robust_policy<FpPoint, IntPoint,
...
<spew redacted>
...
    inlined from ‘int main()’ at test.cpp:10:26:
/usr/include/boost/geometry/policies/robustness/rescale_policy.hpp:46:11: warning: ‘factor’ is used uninitialized [-Wuninitialized]
   46 |         , m_multiplier(the_factor)
      |           ^~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/boost/geometry/policies/robustness/get_rescale_policy.hpp: In function ‘int main()’:
/usr/include/boost/geometry/policies/robustness/get_rescale_policy.hpp:243:21: note: ‘factor’ was declared here
  243 |         factor_type factor;
      |

I didn't see anything in the docs https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html that would indicate this should happen. I didn't read every bug in https://gcc.gnu.org/bugzilla/ but it feels like maybe it is.

I think perhaps Odd Warning In Project with gcc 12.2 and boost 1.80.0 is related (it is a different warning) although I'm more interested in why the optimization flag causes the warning to crop up than why it's happening in the first place.

The -std= does need to be at least 17, but 20 and 23 also have the same result. [sample]$ g++ -o main test.cpp -O3 -std=c++17 by itself without -Wall is also clean, but the combination of the two of them is a problem.

Adam Fowles
  • 156
  • 5
  • 1
    The compiler has to do additional work when optimizing code and it takes advantage of this to do tasks like flow-analysis which are too expensive/unnecessary in a non-optimized (debug) build. This additional work can throw up new errors. It always well worth your time to do a optimized/release build every few hours of development for these additional errors/warnings. – Richard Critten May 01 '23 at 22:28
  • 1
    I'd answerate that, @Richard The asker's not getting much better – user4581301 May 01 '23 at 22:36
  • That is a more helpful explanation if that applies to this version. I'm trying to create a minimal example for this but I'm also finding ```/usr/include/c++/12/complex:1257:38: error: pointer may be used after ‘void free(void*)’ [-Werror=use-after-free] 1257 | real() const { return __real__ _M_value; }``` (Werror on) which seems out of standard users control but yes that post is helpful thanks – Adam Fowles May 01 '23 at 22:49
  • https://developers.redhat.com/blog/2019/03/13/understanding-gcc-warnings-part-2# was also a useful read after the linked question was explored more – Adam Fowles May 01 '23 at 23:22

0 Answers0