[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