Re: [lmi] g++ 4.3 compilation fixes

[Greg Chicares]

On 2009-07-06 11:03Z, Vadim Zeitlin wrote:
> 
>  I've recently upgraded my main Linux system to Debian Lenny which uses g++
> 4.3.2 as its standard compiler and now I can't compile LMI any longer (to
> be honest I can still do it in "old stable" chroot but I'd prefer to do it
> in the real system directly instead of having to build in chroot and I
> think these problems should be fixed anyhow) because of several new
> warnings and LMI use of -Werror.

We'll run into similar issues when we try MinGW's new gcc-4.4.0 release.
I've seen some of them already when experimenting with earlier versions
of MinGW gcc-4.x .

>  First warning is a rather strange:
> 
> cc1plus: error: -funit-at-a-time is required for inlining of functions that 
> are only called once
> 
> which arise for (almost?) all files when building in "debug" mode, i.e.
> without optimizations (as -O enables -funit-at-a-time implicitly). There
> are 2 ways of suppressing it: we can either add -funit-at-a-time just as it
> hints. Or we can also use -fno-inline-functions-called-once to tell g++
> that it shouldn't try to inline static functions called only once. In fact
> I really don't know why is this even on by default (the man page says that
> it's enabled if -funit-at-a-time is used but clearly we do not use it here).
> I am not sure which one is preferable: on one hand, using -funit-at-a-time
> would make debug build behave more like the release/production one. OTOH we
> really don't care about inlining when debugging. Would you have any
> preference here?

That really sounds like a compiler defect; perhaps this item
  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30240
should not have been marked "INVALID". I suppose both the workarounds you
propose are equally good; I have no preference.

>  Also, could you please confirm that we don't care about g++ versions less
> than 3.4.4 any more? I checked that these options (both of them) are
> supported by 3.4.4 but I don't think they were present in 3.3.

For autotools, that's fine. For hand-written makefiles, I'd rather not
remove support for any earlier versions until we move to gcc-4.x for
production--at which time we can clean up a lot of old stuff.

>  Second, g++ 4.3 seems to be much more pedantic in its -Wconversion
> handling. The result is that including any wx header results in dozens of
> warnings, here are some (but by no means all) examples:
> 
> include/wx/windowid.h:46: error: conversion to 'wxWindowID' from 'long int' 
> may alter its value
> include/wx/unichar.h:45: error: conversion to 'wxUint32' from 'long int' may 
> alter its value
> include/wx/string.h:742: error: conversion to 'unsigned int' from 'long int' 
> may alter its value
> include/wx/dynarray.h:1013: error: conversion to 'int' from 'long int' may 
> alter its value
> include/wx/gdicmn.h:245: error: conversion to 'int' from 'long int' may alter 
> its value
> ...
> 
> Clearly, wx use of int and long as interchangeable types is at fault here.
> But fixing it would take a lot of time so for now I just removed
> -Wconversion from the warning flags. Please let me know if you think it's
> worth fixing wx headers to compile with -Wconversion.

I was going to ask why it wouldn't it be worthwhile to reconsider any
non-value-preserving conversions...but perhaps working around some
warnings would make the code poorer. In the last example cited:

           class WXDLLIMPEXP_CORE wxSize
           {
           ...
           int x, y;
           ...
           wxSize& operator/=(int i) { x /= i; y /= i; return *this; }
           ...
/* 245 */  wxSize& operator/=(long i) { x /= i; y /= i; return *this; }

the code is perfectly clear as it stands, and rewriting it to avoid this
warning would make it less clear AFAICS. So I guess I'd avoid sweeping
changes in code like this, and just use '-Wno-conversion'

The hand-written makefiles have wx-specific flags where we could put
'-Wno-conversion' if it turns out that lmi's own code triggers this
warning in just a few cases that seem worth rewriting.

>  Finally, -Wparentheses (enabled by -Wall) results in some more warnings
> too:
> 
> fenv_lmi_x86.hpp:211: error: suggest parentheses around arithmetic in operand 
> of |
> value_cast.hpp:200: error: suggest parentheses around && within ||
> ...
> 
> Again, would you prefer me to fix them by inserting the appropriate
> parentheses or just use -Wno-parentheses?

Let's use '-Wno-parentheses'. I know I wrestled with that when I tried
MinGW gcc-4.3.0, and it was the one warning that I definitely concluded
would do more harm than good. Someday I might add parentheses for
bitwise '|', but to warn about 'A && B || C && D' is excessive IMO.