Eric Blake <ebl...@redhat.com> writes: > On 12/03/2011 09:00 AM, Simon Josefsson wrote: >> What does -funit-at-a-time really do? My gcc 4.4 manual says: >> >> `-funit-at-a-time' >> This option is left for compatibility reasons. `-funit-at-a-time' >> has no effect, while `-fno-unit-at-a-time' implies >> `-fno-toplevel-reorder' and `-fno-section-anchors'. >> >> Enabled by default. > > That's the case for 4.4 and later. But in gcc 4.3, it was not > unconditionally enabled, and as I said earlier, at least coreutils ran > into a situation where gcc 4.3. failed to compile at -Werror because > -Wdisabled-optimization warned that -fno-unit-at-a-time was required, > which warning turned into an error. > > At this point, gcc 4.3 is slowly phasing out; most Linux distros and > Cygwin have moved on to newer compilers, where the problem is less > likely to happen.
Agreed -- so couldn't the answer to this situation be "don't use --enable-gcc-warnings"? I realize we may run into a similar situation in the future though, and I don't have a good idea on how to resolve that. We could deal with it on a case-by-case basis. >> The manual for -ipa-pure-const says: >> >> `-fipa-pure-const' >> Discover which functions are pure or constant. Enabled by default >> at `-O' and higher. >> >> That seems harmless and as far I understand would not modify code >> generation. > > It doesn't modify code generation, but it DOES modify warning > generation, and in a way that negatively interacts with libtool: > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10197 I see this problem from time to time as well, but I believe it is really a libtool problem that it hides messages, and not a problem with the triggers of that problem. It is especially problematic when building code that has a lot of '#if PIC' or '#if !PIC' in it. /Simon
