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

[Alex Converse]

On Tue, Jul 6, 2010 at 3:22 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
> 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
>

ok thanks