mpeg4ip-1.3 does not compile with -O3

[Andersin]

When including -O3 in CXXFLAGS, mpeg4ip-1.3 compilation breaks when trying to compile common/video/iso-mpeg4/src/tools_entropy_huffman.cpp. The error does not occur when setting -O2 in CXXFLAGS. Is this worth to file as a bug, if yes, to whom, gcc-people or mpeg4ip people?

Thanks in Advance

Complete Error Message:
athena src # make tools_entropy_huffman.o
if i686-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../include -D__TRACE_AND_STATS_ -D__DOUBLE_PRECISION_ -D_REENTRANT -DNOCONTROLS -fexceptions -Wall -Werror -D_OBSS_ -Wall -Wmissing-prototypes -Wno-char-subscripts -Woverloaded-virtual -Wno-unknown-pragmas -Wno-deprecated -Wformat=2 -march=pentium3 -O3 -pipe -funroll-loops -finline-limit=1200 -fomit-frame-pointer -frerun-loop-opt -DMPEG4IP -I/usr/include/SDL -D_REENTRANT -MT tools_entropy_huffman.o -MD -MP -MF ".deps/tools_entropy_huffman.Tpo" -c -o tools_entropy_huffman.o tools_entropy_huffman.cpp; \
then mv -f ".deps/tools_entropy_huffman.Tpo" ".deps/tools_entropy_huffman.Po"; else rm -f ".deps/tools_entropy_huffman.Tpo"; exit 1; fi
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5-20050130/include/g++-v3/i686-pc-linux-gnu/bits/c++locale.h: In
function `int std::__convert_from_v(char*, int, const char*, _Tv,
__locale_struct* const&, int) [with _Tv = double]':
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5-20050130/include/g++-v3/bits/locale_facets.tcc:911: instantiated from `_OutIter std::num_put<_CharT, _OutIter>::_M_convert_float(_OutIter, std::ios_base&, _CharT, char, _ValueT) const [with _ValueT = double, _CharT = char, _OutIter = std::ostreambuf_iterator<char, std::char_traits<char> >]'
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5-20050130/include/g++-v3/bits/locale_facets.tcc:1058: instantiated from `_OutIter std::num_put<_CharT, _OutIter>::do_put(_OutIter, std::ios_base&, _CharT, double) const [with _CharT = char, _OutIter = std::ostreambuf_iterator<char, std::char_traits<char> >]'
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5-20050130/include/g++-v3/bits/locale_facets.h:891: instantiated from `_OutIter std::num_put<_CharT, _OutIter>::put(_OutIter, std::ios_base&, _CharT, double) const [with _CharT = char, _OutIter = std::ostreambuf_iterator<char, std::char_traits<char> >]'
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5-20050130/include/g++-v3/bits/ostream.tcc:250: instantiated from `std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(double) [with _CharT = char, _Traits = std::char_traits<char>]'
tools_entropy_huffman.cpp:246: instantiated from here
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5-20050130/include/g++-v3/i686-pc-linux-gnu/bits/c++locale.h:85: warning: format
not a string literal, argument types not checked
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5-20050130/include/g++-v3/i686-pc-linux-gnu/bits/c++locale.h:87: warning: format
not a string literal, argument types not checked
make: *** [tools_entropy_huffman.o] Error 1

[Marctraider]

O3 is often seen as over-optimization, and not worth it.

O2 are much safer and I think its much better.

When I used O3 with kde, konqueror crashed sometimes, now i reemerged it, same version same everything with O2 and all problems went away.


ofcourse you cannot file this as a bug report since it works fine with O2...
As they often say, first use standard CFLAGS like "-march=i386 -O0 -pipe", only if it still doesnt work, then its good to file a bug report (assuming its related to c/cxxflags)
_________________
MOBO: Maximus II Gene
RAM: DDR2 OCZ 4GB
CPU: E6400 Conroe
GPU: HD2600XT
SATA: 3x 250GB.

[nxsty]

[Marctraider]

Then I assume this should be in the ebuild or something? Ofcourse then he should commit a bug report to the gentoo stuff.
How can this be? If the program cannot be compiled with O3 it jumps back to O2 and tries to compile the specific part again? or the whole source?


I was thinking about the program itself I know enough programs which doesnt want to compile or works correctly with O3...
_________________
MOBO: Maximus II Gene
RAM: DDR2 OCZ 4GB
CPU: E6400 Conroe
GPU: HD2600XT
SATA: 3x 250GB.

[nxsty]

In the ebuild of course. The Makefiles and stuff shouldn't mess with the CFLAGS.

[Marctraider]

[ChrisWhite]