------- Comment #5 from manu at gcc dot gnu dot org 2009-03-10 19:15 ------- (In reply to comment #4) > > The previous version of "gcc" warned when implicit narrowing of doubles to > integral values, such as > > double n = 0.0000000005; > int d = n; > > when using the "-Wall" option.
AFAIK, that is not true. I just tried your very example with gcc 4.2.4 and it doesn't warn with -Wall -Wextra -Wconversion. g++ did warn but not with -Wall, you still needed to specify -Wconversion, and it did not warn in many cases. So please, check your facts. > The behavior of "gcc" has changed. Moving all the conversion warnings to fall > under "-Wconversion" may make semantic sense, but it alters the behavior of > "gcc". Fixing bugs alters behaviour. The change of behaviour was documented beyond what is normally expected. > We can fault ourselves for missing this change in the documentation, but there > a level of expectation that the fundamental behavior of the compiler is > consistent from release-to-release. And when fundamental behavior of "gcc" > changes, ample notice should be given. People need to change Makefiles, alter > code (if possible), etc... The behaviour of the compiler changes *every* release in many aspects. That is exactly what http://gcc.gnu.org/gcc-X.X/changes.html is for. > With regard to "-Wtraditional-conversion", it does not work when compiling > "C++" code. Of course it doesn't. Have you understood what -Wtraditional-converion (and the old -Wconversion) actually warned for? > Absolutely not. It's not a portable solution. There is nothing in the "C++" > standard (that I'm aware of) that suggests that "anding" an integral value > with > a "constant" value results in a truncated integral value. It's a bad hack. > Really? Then I have no ideas. In any case, someone else would need to take care of this because I do not have time. http://gcc.gnu.org/faq.html#support > If you have ideas on how to solve this, please submit them to the "C" or "C++" > standards group. bit-field cast operators? > We've already moved back to the 4.2 "gcc". Good that you found a solution. I will leave this open in case someone finds a better solution and decides to submit a patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39170