[FFmpeg-devel] [PATCH] Fix warnings in decode_significance_x86 and decode_significance_8x8_x86 (in h264_i386.h)

[Eli Friedman]

On Tue, Jul 6, 2010 at 12:17 PM, Alex Converse <alex.converse at gmail.com> wrote:
> On Tue, Jul 6, 2010 at 8:10 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
>> On Tue, Jul 06, 2010 at 02:06:41PM +0200, Michael Niedermayer wrote:
>>> On Tue, Jul 06, 2010 at 12:34:55PM +0100, M?ns Rullg?rd wrote:
>>> > Michael Niedermayer <michaelni at gmx.at> writes:
>>> >
>>> > > On Mon, Jul 05, 2010 at 08:02:09PM -0700, Eli Friedman wrote:
>>> > >> On Sat, Jul 3, 2010 at 10:07 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
>>> > >> > On Thu, Jul 1, 2010 at 9:46 AM, Eli Friedman <eli.friedman at gmail.com> wrote:
>>> > >> >> On Sun, Jun 27, 2010 at 4:17 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
>>> > >> >>> On Sun, Jun 27, 2010 at 3:53 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
>>> > >> >>>> On Sun, Jun 27, 2010 at 01:33:01PM -0700, Eli Friedman wrote:
>>> > >> >>>>> 2010/6/27 M?ns Rullg?rd <mans at mansr.com>:
>>> > >> >>>>> > Eli Friedman <eli.friedman at gmail.com> writes:
>>> > >> >>>>> >
>>> > >> >>>>> >> Patch attached; adds extra casts so gcc doesn't warn about truncating
>>> > >> >>>>> >> pointers.
>>> > >> >>>>> >
>>> > >> >>>>> > Do you mean "implicit conversion of pointer to integer of different size"?
>>> > >> >>>>>
>>> > >> >>>>> Yes.
>>> > >> >>>> [...]
>>> > >> >>>>> Okay, second try attached.
>>> > >> >>>>
>>> > >> >>>> if this generates identical object files: then i abstain from commenting
>>> > >> >>>> if it changes object files to being slower then i object to this change
>>> > >> >>>
>>> > >> >>> This generates identical object files, at least on gcc 4.4.
>>> > >> >>>
>>> > >> >>
>>> > >> >> Ping.
>>> > >> >
>>> > >> > PINGPINGPINGPINGPING.
>>> > >> >
>>> > >>
>>> > >> This is completely ridiculous: this tiny patch hasn't had any response
>>> > >> in over a week!
>>> > >
>>> > > can someone please take care of tiny patch, play with it, feed it, make
>>> > > sure its not just sitting lonely and sad in the corner
>>> > > you guys are so cruel
>>> >
>>> > I'm fine with the patch, but I'm not maintainer of that file, you are.
>>>
>>> Didnt you say "Double casts are almost always the wrong solution." ?
>>>
>>> its still doing pointer -> intptr_t -> int, one cast is implict but there are
>>> still 2 casts.
>>> i dont care really as long as compilers dont generate extra instructions,
>>> you where the one being against double casts, not that i like them
>>
>> Also as we are already speaking of this, how exactly should one cast from
>> a 64bit pointer to int32_t in cases where exactly this is needed?
>> i mean if the compiler just doesnt like this opperation, the solution
>> with "obfuscating it through a intermediate step really feels ugly to me.
>>
>
> Excuse my ignorance but why is a 64bit pointer conversion to int32_t
> needed/acceptable here in the first place?
>
> 1075 ? ? significant_coeff_ctx_base = h->cabac_state
> 1076 ? ? ? ? + significant_coeff_flag_offset[MB_FIELD][cat];
>
> cabac_state is an offset in the context. How do we know it will fall
> in the bottom 32-bits of our address space?

It doesn't matter; the truncated pointers are only used for pointer subtraction.

-Eli