[FFmpeg-devel] [PATCH] broken build with --disable-optimizations

[Michael Niedermayer]

On Mon, Jan 18, 2010 at 03:14:30PM +0000, M?ns Rullg?rd wrote:
> Michael Niedermayer <michaelni at gmx.at> writes:
> 
> > On Mon, Jan 18, 2010 at 02:01:11PM +0000, M?ns Rullg?rd wrote:
> >> Jai Menon <jmenon86 at gmail.com> writes:
> >> 
> >> > On Sun, Jan 17, 2010 at 10:06:17PM +0100, Michael Niedermayer wrote:
> >> >> On Mon, Jan 18, 2010 at 01:11:40AM +0530, Jai Menon wrote:
> >> >> > Hi,
> >> >> > 
> >> >> > Attached patch fixes it. This probably isn't correct and is
> >> >> > just meant to be an indicator of what the issue is.
> >> >> 
> >> >> Could you show me the error message with which it fails?
> >> >
> >> > here you go :
> >> >
> >> > /home/jai/ffbuild/libavcodec/libavcodec.a(h264.o): In function
> >> > `decode_significance_8x8_x86':
> >> > /home/jai/ffmpeg/libavcodec/x86/h264_i386.h:97: undefined reference to
> >> > `last_coeff_flag_offset_8x8'
> >> 
> >> The problem is all those non-inline functions in h264*.h. 
> >
> >> There is absolutely no sense whatsoever in having a non-inline
> >> function in a header file.
> >
> > There is a sense, some things like CABAC are constants that way but
> > would not if its in a C file. inlining OTOH may or may not be good,
> > its independant
> 
> I see your point.  However, you could still put both versions of the
> function in a .c file, perhaps by #including a template.h with
> different definitions.

yes, but simply adding a dummy symbol for the 2 problematic tables seems
like the simpler solution. If we need a workaround until someone benchmarks
the stuff and checks what is best


> 
> >> Either the function should be inlined or it should not.
> >> In the former case it should be marked inline explicitly, in the
> >> latter it should be in a .c file.  Having multiple copies of
> >> non-inline functions in the object code is obviously a bad thing.
> >> 
> >> Michael, if this is a work in progress and you're experimenting with
> >> inlining, say so and that's fine.  If you do not intend for these
> >> functions to be inlined, please move them to .c files.
> >
> > someone has to benchmark if static, static inline or static in .c is faster
> > for each function. If someone does iam perfectly fine with these functions
> > being changed to their fastes variant.
> > If someone wants they can also temporary mark all as static inline until
> > someone has time to benchmark them.
> >
> > besides the static function this time is in h264_i386.h and that was
> > there since a long time and not commited by me, actually i was unaware
> > that it was non inline until now.
> >
> > and jais compiler is broken if it does not remove unused static functions
> 
> There is no such requirement in the C standard, so technically the
> compiler is not broken at all, just not optimising very well (at the
> request of the user this time).

of course but i suspect there also is no such requirement for static inline
functions either.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have often repented speaking, but never of holding my tongue.
-- Xenocrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100118/43c4c9e7/attachment.pgp>