[FFmpeg-devel] [PATCH] Fix decoding of ffv1 when compiling with icc

[Måns Rullgård]

Michael Niedermayer <michaelni at gmx.at> writes:

> On Sat, May 24, 2008 at 12:14:59AM +0200, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> I don't know what the C standard says about this, but icc compiles ffv1.c 
>> differently than gcc: Only sample[0] / sample[0][0] are initialized 
>> "correctly".
>>
>> Attached patch allows icc compilations to pass make test.
>>
>> In case this is not acceptable: Could anybody point me to the relevant part 
>> of the C specification and/or provide a minmal testcase so I can report the 
>> bug to Intel?
>>
>> Thank you, Carl Eugen
>
>> Index: libavcodec/ffv1.c
>> ===================================================================
>> --- libavcodec/ffv1.c	(revision 13263)
>> +++ libavcodec/ffv1.c	(working copy)
>> @@ -768,7 +768,9 @@
>>  static void decode_plane(FFV1Context *s, uint8_t *src, int w, int h, int stride, int plane_index){
>>      int x, y;
>>      int_fast16_t sample_buffer[2][w+6];
>> -    int_fast16_t *sample[2]= {sample_buffer[0]+3, sample_buffer[1]+3};
>> +    int_fast16_t *sample[2];
>> +    sample[0]=sample_buffer[0]+3;
>> +    sample[1]=sample_buffer[1]+3;
>>  
>>      s->run_index=0;
>>  
>> @@ -795,10 +797,13 @@
>>  static void decode_rgb_frame(FFV1Context *s, uint32_t *src, int w, int h, int stride){
>>      int x, y, p;
>>      int_fast16_t sample_buffer[3][2][w+6];
>> -    int_fast16_t *sample[3][2]= {
>> -        {sample_buffer[0][0]+3, sample_buffer[0][1]+3},
>> -        {sample_buffer[1][0]+3, sample_buffer[1][1]+3},
>> -        {sample_buffer[2][0]+3, sample_buffer[2][1]+3}};
>> +    int_fast16_t *sample[3][2];
>> +    sample[0][0] = sample_buffer[0][0]+3;
>> +    sample[0][1] = sample_buffer[0][1]+3;
>> +    sample[1][0] = sample_buffer[1][0]+3;
>> +    sample[1][1] = sample_buffer[1][1]+3;
>> +    sample[2][0] = sample_buffer[2][0]+3;
>> +    sample[2][1] = sample_buffer[2][1]+3;
>
> for(x=0, x<3; x++){
>     sample[x][0] = sample_buffer[x][0]+3;
>     sample[x][1] = sample_buffer[x][1]+3;
> }
>
> rest is ok
>
> And yes this is probably a icc bug workaround and a bug in icc.

It is quite obviously a bug in icc.  Under no interpretation of the
standard, should the result be different before and after the patch.

> It just IMHO does no harm to write it in a way which does work with both
> gcc and icc.

I agree.  Reporting the bug is of course still a good idea.

-- 
M?ns Rullg?rd
mans at mansr.com