Was there a conscious decision to begin using 0b prefixes [more widely] in 3.14.0? I'm trying to build 3.14.0 on/for an x86 linux box using gcc 4.1.2 (it's an old FC7 distro that we're using for an embedded application). I pulled the 3.14.0 valgrind source from the repository using git, ran the autogen, followed by "./configure prefix=$HOME/valgrind exec_prefix=$HOME/valgrind", and make. The build chokes on a binary constant ("0b00010000") at line 1802 in priv/guest_s390_toIR.c: priv/guest_s390_toIR.c:1802:43: error: invalid suffix "b00010000" on integer constant 3.13.0 builds fine (though I didn't use git to pull it -- I just used the source tarball). I noticed that there are uses of the "0b" prefix in 3.13.0, but that seems to be limited to the ARM architectures (where presumably all the SDKs are relatively new and support "0b" use). Would it be possible to avoid use of "0b" in the x86 flavors?
Converting the constant to a simple 0x10 seems to make everything better (at least as far as compilation and running on x86 linux).
Note -- the target application is in a regulated industry and the development environment has all been validated (i.e., changing-up to a later version of gcc isn't in the cards for quite a while). Would it be at least possible to add some sort of config (in combination with a variably defined #define for the constant)?
Support for binary constants has been around since gcc 4.3.0 (since 2008, 10 years ago). Also clang supports this notation. I don't see any reason why we need to prefer compatibility with ancient compilers over readability and maintainability. I think your case is a singular one; majority of LTS distros have moved off of such ancient gcc versions long time ago. You can't expect recent version of Valgrind work with an ancient version of the compiler; neither is the case of other toolchain components. There are going to be more and more cases of Valgrind using compiler features available only to reasonably recent compilers. You could get away for now with a simple patch, changing the binary constants into hexadecimal ones, for example. But with the evolution bringing new changes, you could end up with a huge patchset eventually.