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

Michael Niedermayer michaelni
Fri May 23 22:31:01 CEST 2008


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 just IMHO does no harm to write it in a way which does work with both
gcc and icc.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
-------------- 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/20080523/a915b7e6/attachment.pgp>



More information about the ffmpeg-devel mailing list