On 2017-02-16 10:07-0500 Chuck Atkins wrote:

Hi YC,


cmake version on fedora 25: 3.6.2


Fedora is specifically patching CMake in the RPM spec file to reduce the
gcc flag from O3 to O2 so it's the distributuion's packaging making that
change, not CMake itself.  If you download and build the source from
cmake.org then you'll get O3 as default for gcc release builds.

That being said, I do think we should revisit the use of O3 by default
given the safety issues surounding it.

I agree with RedHat developers that O3 by default (especially if you
only use it for releases in a largely untested way) is likely a bad
idea. But developers of other distros obviously disagree with RedHat. Of course, this also means that the decision CMake developers
make about this doesn't affect that many users because distros are
likely going to override whatever decision CMake developers make in
this regard.  And some CMake users like me who build our own CMake version
also ignore all default optimization choices set by CMake developers.

For example, in my case I want to test that PLplot reduces externally
visible library symbols to a minimum, and I want to look for
uninitialized variable possibilities so I typically use

export CFLAGS='-O3 -fvisibility=hidden -Wuninitialized'
export CXXFLAGS='-O3 -fvisibility=hidden -Wuninitialized'

for testing throughout our release cycles and not just at the end of
release cycles in the last-minute rush before release.

But before getting to why I do that, I want to review why some
developers (like me) feel that in certain circumstances -O3 can be
dangerous.

There is an interesting discussion of O3 safety at
<http://stackoverflow.com/questions/11546075/is-optimisation-level-o3-dangerous-in-g>.
Issues discussed that seem to weigh against using O3 for any default
choice were the following:

1. O3 can expose incorrect code assumptions.

2. O3 adds additional optimizations to O2 and is less thoroughly
tested by users so there is more chance of gcc
compiler suite bugs for O3.  (Although nobody was aware at the time of that
discussion of any O3-specific bug in the gcc compiler suite).

3. O3 can sometimes give you slower code due to cache considerations.

My own personal experience is that several years ago I started testing
with -O3 late in a release cycle for a particular PLplot release, and
it started segfaulting like crazy while it was perfectly fine with
-O2.  We finally narrowed the problem to a small recursive routine
that we had implemented, and the only solution to avoid the -O3 issue
was to rewrite that routine in a non-recursive way even though none of
our developers could see anything wrong with the recursive version.

We never did figure out whether we were encountering issue 1 or issue
2, but the story does illustrate the problems you can encounter if you
debug and do the bulk of the testing of your code at low optimization
levels, and then introduce a high optimization level late in a release
cycle.  So now I always test consistently with -O3 throughout the
release cycle (and have never again encountered an issue with that
optimization level, natch).  Also, we don't make binary releases of
PLplot ourselves so essentially we leave it to Linux, Mac, and Windows
distributors of binary versions of PLplot to decide what optimization
level they are going to use for all the binary software projects they
distribute.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Reply via email to