subject:"Re\: \[CMake\] Default CMAKE_C

Re: [CMake] Default CMAKE_C_FLAGS value by OS

2017-02-16 Thread Zan Lynx

On 02/16/2017 08:07 AM, Chuck Atkins wrote:
> That being said, I do think we should revisit the use of O3 by default
> given the safety issues surounding it.

The following is just my opinion:

In my experience if O3 fails it is a bug in the compiler, which should
be fixed and somebody has to find them first. Or a bug in the code being
built with O3, usually something subtle with undefined behavior.

Code bugs that happen to work sort-of correctly under O2 but not O3
aren't really safe. Future compiler versions often include changes that
break the code anyway.

I build a couple of production release C++ projects under several
versions of GCC (Linux releases since 2010). I use O3 and profiling
feedback, which, yes, does reveal some bugs, even up to segfaulting the
compiler, so I have special checks in the Makefile for a few of those
versions.

The thing that makes this safe to do is testing. If the code isn't
working correctly because of O3 I know it because it fails to pass its
tests.

I haven't looked but I would hope CMake has tests that are run against
the optimized code...
-- 
Knowledge is Power -- Power Corrupts
Study Hard -- Be Evil
-- 

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

Re: [CMake] Default CMAKE_C_FLAGS value by OS

2017-02-16 Thread Alan W. Irwin


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
.
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

Re: [CMake] Default CMAKE_C_FLAGS value by OS

2017-02-16 Thread ycollette . nospam

Thanks a lot for all these informations.
I wrote a macro to be sure to replace all the -O3 flags ...

# replace_ccxx_flag: replace compilation flags from the compiler command line
# flag_orig: the flag to be replace
# flag_dest: the new flag value
macro(replace_ccxx_flag flag_orig flag_dest) 
  string(REPLACE "${flag_orig}" "${flag_dest}" CMAKE_C_FLAGS  
"${CMAKE_C_FLAGS}")
  string(REPLACE "${flag_orig}" "${flag_dest}" CMAKE_CXX_FLAGS
"${CMAKE_CXX_FLAGS}")
  string(REPLACE "${flag_orig}" "${flag_dest}" CMAKE_C_FLAGS_RELEASE  
"${CMAKE_C_FLAGS_RELEASE}")
  string(REPLACE "${flag_orig}" "${flag_dest}" CMAKE_CXX_FLAGS_RELEASE
"${CMAKE_CXX_FLAGS_RELEASE}")
  string(REPLACE "${flag_orig}" "${flag_dest}" CMAKE_C_FLAGS_DEBUG
"${CMAKE_C_FLAGS_DEBUG}")
  string(REPLACE "${flag_orig}" "${flag_dest}" CMAKE_CXX_FLAGS_DEBUG  
"${CMAKE_CXX_FLAGS_DEBUG}")
  string(REPLACE "${flag_orig}" "${flag_dest}" CMAKE_C_FLAGS_RELWITHDEBINFO   
"${CMAKE_C_FLAGS_RELWITHDEBINFO}")
  string(REPLACE "${flag_orig}" "${flag_dest}" CMAKE_CXX_FLAGS_RELWITHDEBINFO 
"${CMAKE_CXX_FLAGS_RELWITHDEBINFO}")
endmacro()

Best regards,

YC

----- Mail original -----
De: "Chuck Atkins" <chuck.atk...@kitware.com>
À: "ycollette nospam" <ycollette.nos...@free.fr>
Cc: "Dan Liew" <d...@su-root.co.uk>, "cmake" <cmake@cmake.org>
Envoyé: Jeudi 16 Février 2017 16:07:21
Objet: Re: [CMake] Default CMAKE_C_FLAGS value by OS





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. 


- Chuck 


-- 

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

Re: [CMake] Default CMAKE_C_FLAGS value by OS

2017-02-16 Thread Chuck Atkins

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.

- Chuck
-- 

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

Re: [CMake] Default CMAKE_C_FLAGS value by OS

2017-02-16 Thread ycollette . nospam

cmake version on fedora 25: 3.6.2

And the corresponding lines in GNU.cmake (there are some differences):

  # Initial configuration flags.
  set(CMAKE_${lang}_FLAGS_INIT "")
  set(CMAKE_${lang}_FLAGS_DEBUG_INIT "-g")
  set(CMAKE_${lang}_FLAGS_MINSIZEREL_INIT "-Os -DNDEBUG")
  set(CMAKE_${lang}_FLAGS_RELEASE_INIT "-O2 -DNDEBUG")
  set(CMAKE_${lang}_FLAGS_RELWITHDEBINFO_INIT "-O2 -g -DNDEBUG")
  set(CMAKE_${lang}_CREATE_PREPROCESSED_SOURCE "<CMAKE_${lang}_COMPILER> 
   -E  > ")
  set(CMAKE_${lang}_CREATE_ASSEMBLY_SOURCE "<CMAKE_${lang}_COMPILER>  
  -S  -o ")

So, as you can see, on  Fedora 25, there are no -O3 flags by default.

YC

- Mail original -
De: "Dan Liew" <d...@su-root.co.uk>
À: "ycollette nospam" <ycollette.nos...@free.fr>
Cc: "cmake" <cmake@cmake.org>
Envoyé: Jeudi 16 Février 2017 10:26:01
Objet: Re: [CMake] Default CMAKE_C_FLAGS value by OS

Hi,

On 16 February 2017 at 09:06,  <ycollette.nos...@free.fr> wrote:
> Hello,
>
> My question is related to CMAKE_*_FLAGS.
> I've got a project under linux fedora 24 and, in release mode, this project 
> compiles with the -O2 flag.
> But when I switched to other platform (ubuntu, fedora 16 - I now this one is 
> quite old but I need to compile on this platform), this default optimization 
> flag changes. On some platform, it's -O3.
> And because with -O3 flag some "risky" optimizations are enabled, my project 
> hangs ...

You can find CMake's defaults for gcc/clang in

/usr/share/cmake-/Modules/Compiler/GNU.cmake

where  is your CMake version.

E.g.

https://github.com/Kitware/CMake/blob/master/Modules/Compiler/GNU.cmake

You'll see lines like

```
string(APPEND CMAKE_${lang}_FLAGS_INIT " ")
string(APPEND CMAKE_${lang}_FLAGS_DEBUG_INIT " -g")
string(APPEND CMAKE_${lang}_FLAGS_MINSIZEREL_INIT " -Os -DNDEBUG")
string(APPEND CMAKE_${lang}_FLAGS_RELEASE_INIT " -O3 -DNDEBUG")
string(APPEND CMAKE_${lang}_FLAGS_RELWITHDEBINFO_INIT " -O2 -g -DNDEBUG")
```

It's possible that the defaults changed at some point but I would be
really surprised by this. Are you sure you weren't doing a
RELWITHDEBINFO build on one system and a RELEASE build on the other?

It is possible to override these defaults by writing an overrides file
(example [1]) and then using those overrides before the `project()`
declaration in your root `CMakeLists.txt` file.
Here's an example [2].

So if you need fine grained control over the optimization level used
for different build types then I suggest you use overrides.


[1] 
https://github.com/delcypher/fp-bench/blob/ebc8f939500b6ec28e6530f65273df8bfb122970/cmake/c_flags_override.cmake
[2] 
https://github.com/delcypher/fp-bench/blob/ebc8f939500b6ec28e6530f65273df8bfb122970/CMakeLists.txt#L5

HTH,
Dan.
-- 

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

Re: [CMake] Default CMAKE_C_FLAGS value by OS

2017-02-16 Thread Dan Liew

Hi,

On 16 February 2017 at 09:06,   wrote:
> Hello,
>
> My question is related to CMAKE_*_FLAGS.
> I've got a project under linux fedora 24 and, in release mode, this project 
> compiles with the -O2 flag.
> But when I switched to other platform (ubuntu, fedora 16 - I now this one is 
> quite old but I need to compile on this platform), this default optimization 
> flag changes. On some platform, it's -O3.
> And because with -O3 flag some "risky" optimizations are enabled, my project 
> hangs ...

You can find CMake's defaults for gcc/clang in

/usr/share/cmake-/Modules/Compiler/GNU.cmake

where  is your CMake version.

E.g.

https://github.com/Kitware/CMake/blob/master/Modules/Compiler/GNU.cmake

You'll see lines like

```
string(APPEND CMAKE_${lang}_FLAGS_INIT " ")
string(APPEND CMAKE_${lang}_FLAGS_DEBUG_INIT " -g")
string(APPEND CMAKE_${lang}_FLAGS_MINSIZEREL_INIT " -Os -DNDEBUG")
string(APPEND CMAKE_${lang}_FLAGS_RELEASE_INIT " -O3 -DNDEBUG")
string(APPEND CMAKE_${lang}_FLAGS_RELWITHDEBINFO_INIT " -O2 -g -DNDEBUG")
```

It's possible that the defaults changed at some point but I would be
really surprised by this. Are you sure you weren't doing a
RELWITHDEBINFO build on one system and a RELEASE build on the other?

It is possible to override these defaults by writing an overrides file
(example [1]) and then using those overrides before the `project()`
declaration in your root `CMakeLists.txt` file.
Here's an example [2].

So if you need fine grained control over the optimization level used
for different build types then I suggest you use overrides.


[1] 
https://github.com/delcypher/fp-bench/blob/ebc8f939500b6ec28e6530f65273df8bfb122970/cmake/c_flags_override.cmake
[2] 
https://github.com/delcypher/fp-bench/blob/ebc8f939500b6ec28e6530f65273df8bfb122970/CMakeLists.txt#L5

HTH,
Dan.
-- 

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

Re: [CMake] Default CMAKE_C_FLAGS value by OS

Re: [CMake] Default CMAKE_C_FLAGS value by OS

Re: [CMake] Default CMAKE_C_FLAGS value by OS

Re: [CMake] Default CMAKE_C_FLAGS value by OS

Re: [CMake] Default CMAKE_C_FLAGS value by OS

Re: [CMake] Default CMAKE_C_FLAGS value by OS

6 matches

Site Navigation

Mail list logo

Footer information