Bug 60905 - ffmpeg built with gcc 4.9 RC produces incorrect loco playback code
Summary: ffmpeg built with gcc 4.9 RC produces incorrect loco playback code
Status: RESOLVED DUPLICATE of bug 60902
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 4.9.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-04-20 16:28 UTC by Carl Eugen Hoyos
Modified: 2014-04-20 17:29 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Carl Eugen Hoyos 2014-04-20 16:28:19 UTC 
gcc 4.9.0 RC miscompiles FFmpeg's loco decoder (an old video format), this is reproducible with current FFmpeg git head (e70b9b32) and the last release, 2.2.1:
The problem can be reproduced with the fate tests (FFmpeg's self test, the samples are large):
$ ./configure && make ffmpeg
$ make SAMPLES=fate-samples fate-rsync
$ make SAMPLES=fate-samples fate-loco-rgb
$ make SAMPLES=fate-samples fate-loco-yuy2
Both tests take a very long time instead of fractions of a second and output incorrect data.

Also reproducible without running the tests:
$ rsync -t rsync://fate-suite.ffmpeg.org/fate-suite/loco/pig* .
$ ffmpeg -i pig-loco-0.avi out1.avi
$ ffmpeg -i pig-loco-rgb.avi out2.avi
The output files look completely broken.

Works fine with many previous versions of gcc, including 4.8.2 and 4.7.2.

This may or may not be related to Bug 60902 and Bug 60904

I originally found the problem when testing FFmpeg ticket #3559:
https://trac.ffmpeg.org/ticket/3559
Comment 1 Markus Trippelsdorf 2014-04-20 17:29:06 UTC 
Same thing. Also dup of PR60902.

*** This bug has been marked as a duplicate of bug 60902 ***