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

Ganesh Ajjanagadde gajjanag at mit.edu
Thu Jun 4 23:55:08 CEST 2015


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.

On Thu, Jun 4, 2015 at 12:16 PM, James Almer <jamrial at gmail.com> wrote:
> On 04/06/15 10:08 AM, Ganesh Ajjanagadde wrote:
>> On Thu, Jun 4, 2015 at 7:00 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
>>> On Wed, Jun 03, 2015 at 10:05:54PM -0400, Ganesh Ajjanagadde wrote:
>>>> While compiling ffmpeg, I noticed a bunch of -Warray-bounds warnings.
>>>> I think it would be great if ffmpeg could be built warning-free, and
>>>> -Warray-bounds seems to be one of the biggest culprits. Nevertheless,
>>>
>>>> -Warray-bounds is quite useful in most cases.
>>>
>>> how many of the warnings shown are real and how many are false
>>> positives (in some version not neccessarily the latest of FFmpeg)
>>> ?
>>
>> So I checked out n2.5 release. There are too many warnings to quickly
>> audit all of them.
>> Nevertheless, I went through about 6 instances (randomly selected),
>> and found all of them to be false positives.
>> Basically, there is a basic pattern to all of these warnings:
>> struct foo {
>>     int bar[MAX_BAR];
>>     int num_bar;
>> }; // could have other declarations as well
>>
>> // in usage
>> int set_foo(foo* my_foo) {
>>     my_foo->num_bar = get_num_bar();
>>     if (num_bar > MAX_BAR)
>>         return -1;
>> }
>>
>> int loop_over(const foo* my_foo) {
>>     int i;
>>     for(i = 0; i < foo->num_bar; i++) {
>>         // do something with foo->bar[i]
>>         // this triggers the warning: GCC tries to do a constant
>> propagation to verify array in bounds, since it knows MAX_BAR, i.e
>> foo->bar is an array.
>>         // However, it can't do deep enough analysis to verify that in
>> set_foo, num_bar is sanitized to ensure proper in bounds access.
>>    }
>> }
>
> Could you make a bug report about this on https://gcc.gnu.org/bugzilla/?
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


More information about the ffmpeg-devel mailing list