I am in the process of creating a new CMakeified project at SF (sf.net/projects/timeephem) where I have been having trouble with an uninitialized variable. valgrind reacted by claiming uninitialized variables were being used at absolutely nonsensical locations in the code that had nothing to do with the location where I eventually found (by massive code scrutiny) the uninitialized variable had been used. Also, --track-origins=yes was generating nonsensical locations for which variable was uninitialized.
Although this bug is fixed now by brute force code scrutiny with no help from valgrind, and that fix shuts up valgrind so I now have a clean valgrind report, I am still quite concerned that valgrind was screwing up this way because until now it has been one of my more useful development tools. So I would like to test the working hypothesis that one of the default optimizations that are normally set even though -O is not specified or -O0 is specified was confusing valgrind. So I set CFLAGS to the following: -g -fno-align-loops -fno-argument-alias -fno-asynchronous-unwind-tables -fno-branch-count-reg -fno-common -fno-dce -fno-dse -fno-early-inlining -fno-gcse-lm -fno-inline-functions-called-once -fno-ivopts -fno-jump-tables -fno-math-errno -fno-move-loop-invariants -fno-peephole -fno-rename-registers -fno-sched-interblock -fno-sched-spec -fno-sched-stalled-insns-dep -fno-signed-zeros -fno-split-ivs-in-unroller -fno-toplevel-reorder -fno-trapping-math -fno-tree-cselim -fno-tree-loop-im -fno-tree-loop-ivcanon -fno-tree-loop-optimize -fno-tree-reassoc -fno-tree-scev-cprop -fno-tree-switch-conversion -fno-tree-vect-loop-version -fno-unit-at-a-time -fno-var-tracking -fno-vect-cost-model -fno-web (with all those options separated by spaces rather than line feeds). I have checked with gcc -c -Q $CFLAGS --help=optimizers | less that setting all those negative options really does disable all but one optimization of gcc (which I don't think has a negative option although it appears to tolerate me using the negative form of the option without complaining). Also, that $CFLAGS can be used to compile one of my source code files by hand, e.g., gcc $CFLAGS -c testeph.c with no obvious issues. However that $CFLAGS kills cmake's detection and simple test of gcc completely so I cannot build my code (with the uninitialized variable still there as a test) to see if suppressing virtually all optimizations will make valgrind work correctly. Here is a simple test case: CMakeLists.txt: project(test C) cmake_minimum_required(VERSION 2.8.5 FATAL_ERROR) Running that without CFLAGS set works fine. Running it with the above CFLAGS gives the following errors: -- The C compiler identification is unknown -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- broken CMake Error at /home/software/cmake/install-2.8.5-rc2/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:52 (MESSAGE): The C compiler "/usr/bin/gcc" is not able to compile a simple test program. It fails with the following output: Change Dir: /tmp/cmake_test/build_dir/CMakeFiles/CMakeTmp Run Build Command:/usr/bin/make "cmTryCompileExec/fast" /usr/bin/make -f CMakeFiles/cmTryCompileExec.dir/build.make CMakeFiles/cmTryCompileExec.dir/build make[1]: Entering directory `/tmp/cmake_test/build_dir/CMakeFiles/CMakeTmp' CMakeFiles/cmTryCompileExec.dir/flags.make:6: *** missing separator. Stop. make[1]: Leaving directory `/tmp/cmake_test/build_dir/CMakeFiles/CMakeTmp' make: *** [cmTryCompileExec/fast] Error 2 CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:1 (project) -- Configuring incomplete, errors occurred! That "missing separator" issue makes me think I may be running into some length limit with cmake. The length of the above CFLAGS variable is 697 bytes. In any case, I would like to report this as a CMake bug with the hope of getting it quickly fixed for 2.8.6 (assuming it is some unnecessary constraint on the length of CFLAGS). If the CFLAGS length is the issue, then I hope there is no practical need to be less than extremely generous with that length (say at least several thousand bytes) to anticipate odd tests developers might want to do like above. 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); PLplot scientific plotting software package (plplot.org); 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 __________________________ _______________________________________________ cmake-developers mailing list [email protected] http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
