gcc 11 weird bug

[Thomas Wolff]

Am 27.10.2021 um 20:52 schrieb Thomas Wolff:
>
> Am 27.10.2021 um 12:55 schrieb Hannes Domani:
>>   Am Mittwoch, 27. Oktober 2021, 11:19:19 MESZ hat Thomas Wolff 
>> <towo@towo.net> Folgendes geschrieben:
>>
>>> I noticed that mintty did not compile anymore after upgrade to gcc 11,
>>> but only on cygwin 32-bit.
>>> I tried to minimize the test case as much as possible without having 
>>> the
>>> bug vanish, to the attached standalone file.
>>> Compile this with
>>> cc -O2 -Wall -Werror m0.c
>>> and it gives a false positive warning about possible uninitialized data
>>> usage.
>>> While data flow analysis is not perfect, it is weird that this used to
>>> happen on 32 bit but not on 64 bit.
>>> Meanwhile, after updating some other packages (not sure which), but
>>> still the same gcc version, the report on the test case also happens on
>>> 64 bit, while the original, unstripped file, as part of mintty, still
>>> works without error on 64 bit, which is even weirder.
>>> I have not yet had the opportunity to test this on Linux, sorry, so I'm
>>> reporting it here.
>>> Thomas
>> If you mean this warning:
>>
>> m0.c: In function 'do_bidi':
>> m0.c:256:12: error: '*types[0]' may be used uninitialized 
>> [-Werror=maybe-uninitialized]
>>
>> This warning is correct, because as far as gcc is concerned, count could
>> be 0, and in this case types[0] will be uninitialized (and doesn't even
>> exist, since it's declared as 'uchar types[count];').
> Thanks for the hint. I acknowledge that the analyser cannot know that 
> count > 0 here. But if types[0] exists, it cannot be unitialized so 
> the wording of the warning is not correct in this case. Anyway, this 
> leads to a less obtrusive workaround than the current one.
And, forgot to mention, it's still mysterious how the distinction 
32bit/64bit makes a difference about the warning to occur.
Kind regards
Thomas