[FFmpeg-devel] GCC 5.1 warning: -Warray-bounds

Ganesh Ajjanagadde gajjanag at mit.edu
Wed Jul 22 04:43:18 CEST 2015

On Tue, Jul 21, 2015 at 10:28 PM, Ronald S. Bultje <rsbultje at gmail.com> wrote:
> Hi,
> On Tue, Jul 21, 2015 at 10:07 PM, Ganesh Ajjanagadde <gajjanag at mit.edu>
> wrote:
>> On Tue, Jul 21, 2015 at 5:31 PM, Ganesh Ajjanagadde <gajjanag at mit.edu>
>> wrote:
>> > On Tue, Jul 21, 2015 at 5:14 PM, Michael Niedermayer
>> > <michael at niedermayer.cc> wrote:
>> >> On Thu, Jun 25, 2015 at 01:25:08AM -0300, James Almer wrote:
>> >>> On 04/06/15 6:55 PM, Ganesh Ajjanagadde wrote:
>> >>> > I have created a small test case which gets at the heart of one of
>> >>> > these spurious
>> >>> > warnings, namely the one for libavfilter/vf_swapuv.c.
>> >>> >
>> >>> > Here is the ticket on the GCC Bugzilla:
>> >>> >
>> >>> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66422
>> >>> >
>> >>> > Note that as of the moment, -Warray-bounds appears quite broken on
>> >>> > GCC
>> >>> > (especially on -O3), and the bugzilla is full of bug reports on
>> >>> > this.
>> >>>
>> >>> For the record, these bogus warnings have been fixed on the gcc 5
>> >>> branch.
>> >>
>> >> do any warnings remain for ffmpeg ?
>> >> are they real issues or false positives as well ?
>> >
>> > Most are gone, only two files trigger these, namely
>> > libavformat/dvenc.c and libavcodec/dca_x11.c.
>> > I have attached a logfile from the build and will investigate this to
>> > see whether they are real or false positives.
>> So I checked the above, and it turns out both are false positives.
>> However, in neither case was it trivial to see that access patterns
>> are well defined,
>> and both required analysis across the function boundary.
>> Perhaps this is why GCC still struggles with this stuff.
>> I will try creating a test case based on this and file a GCC ticket.
>> By the way, both false positives can be easily silenced with one line
>> changes,
>> but of course we should not needlessly bend our code to satisfy the
>> whims of GCC.
> Well, that depends, right? So, the question is one of benefit vs. effort. If
> all warnings are useless and gcc never provided us any new insights we
> didn't already have (i.e. identify a real bug), it's probably not worth it.
> However, if gcc turned out to help us find real bugs and the changes are
> minor and clean, I see no problem silencing the noise a little. I believe
> we've done that in the past to make valgrind happier.

That's essentially the issue of -Warray-bounds.
Warray-bounds is a great concept, and to me on first glance should be super
useful to a project like ffmpeg, given the number of loops, array
manipulations/indexing, etc
that are performed.
Moreover, it is very easy to screw up the indexing and make off by one
mistakes, etc
which could lead to segfaults/corruption of buffers, and the like.
Thus, I would have hoped this was more useful to ffmpeg.
It seems like instead it can only catch simple cases,
and in complex situations (like most cases in ffmpeg) it either does
nothing or gives false positives.

On a positive note, as above thread indicates, most spurious stuff has
been silenced,
and in ffmpeg, only two instances remain.
I am happy to provide simple patches to silence these two cases,
or try to work upstream with GCC to remove these spurious warnings.

> Ronald

More information about the ffmpeg-devel mailing list