[cmake-developers] [wishlist BUG?] limit on the length of the CFLAGS environment variable too small?

[Alan W. Irwin]

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
__________________________