GCC 11

[Sveinar Søpler]

The logfile from the WineHQ Ubuntu 21.04 build on OBS is here: 
[ https://build.opensuse.org/build/Emulators:Wine:Debian/xUbuntu_21.04/x86_64/wine-devel/_log | https://build.opensuse.org/build/Emulators:Wine:Debian/xUbuntu_21.04/x86_64/wine-devel/_log ] 

I could not immediately find warnings about what you are talking about here, but there sure is enough warnings about "format argument" (-Wformat and -Wstrict-aliasing) stuff, that i don't get when i compile wine myself locally. Might not be related to what you ask here, but since you were talking about "gcc 11 becomes mainstream", i thought it was worth to point to the official OBS buildlog for Ubuntu 21.04 - that uses gcc-11 (although gcc-mingw-w64 is still at 10.3). 

I guess debian/ubuntu "debuild" system sets these -Wformat= and -Wstrict-aliasing options when building as default, and that seem to throw a lot of warnings. I did not browse through the entire log, but maybe it is just some overly eager checks that some distro's enable by default, that it is not really critical? 

Do you have a "sample warning" for me to search for? Eg. 
dlls/ncrypt/main.c:106:11: warning: format '%lx' expects argument of type 'long unsigned int', but argument 5 has type 'NCRYPT_PROV_HANDLE' {aka 'long long unsigned int'} [-Wformat=] 

Sveinar 

----- On Sep 29, 2021, at 11:17 AM, Eric Pouech <eric.pouech at orange.fr> wrote: 

> For sharing :

> - newest gcc version (11) sets by default of bunch of new tests for code
> correctness

> - it spits out around ten thousand lines of warnings (*), making it quite
> impossible to look into compiler output

> there are a couple of genuine issues reported by gcc11

> - Rémi and I already sent a serie of patches for addressing those

> - a strange indentation waiting for a volunteer

> (in dlls/ wininet/internet.c:2878, the line
> lpwhh->ErrorMask = *(ULONG*)lpBuffer;

> at the end of the if/else chain is misindented)

> unfortunately, most of the generated warnings are false positives, that need to
> be fixed (or removerd) before GCC11 becomes mainstream

> - Fedora 35 with GCC11 is in beta right now, and GA is mid of October

> - I haven't checked other distros though, but I expect similar evolution in
> coming weeks/months

> - in Fedora both gcc and mingw-gcc have been upgraded to version 11

> The false positives we need to tackle:

> A) misleading indentation

> ===================

> GCC11 complains about code like:

> foo;

> todo_wine

> ok(tst, ...);

> bar;

> (gcc11 warns about 'bar ' not being properly indented wrt todo_wine)

> there are (as of today) 817 occurrences of those in wine tree (spread across 127
> files)

> and counts for ~90% (*) of the line of warnings generated by GCC

> only 2 true positives are generated by this GCC warning

> Remarks:

> - constructs on a single line don't generate the warning

> todo_wine ok(tst, ...); // ok no warning, whatever the indentation of the line
> wrt the rest of the code

> - having the ok(tst, ...) inside a block after the todo_wine doesn't generate
> the warning

> possible solutions:

> - disable the warning in configure cons: will not trigger on true positive

> pros: minor impact on code base (either committed and under progress in dev:s
> trees)

> - merge the todo_wine and ok() line into a single one

> pros: keep current indentation, coherent with todo_wine + block

> cons: harder to read, esp. for todo_wine_if

> cons: for todo_wine_if, could generate too long lines

> cons: large impact on code base

> pros/cons: git blame on ok() line will tell who removed the todo_wine, not who
> wrote the test

> - reindent only problematic todo_wine
> foo;

> todo_wine

> ok(tst, ...);

> bar; ^ without indenting the line ok(tst, ...);

> ^ without indenting the "todo_wine {\n<...>\n}" nor the "todo_wine ok()" on a
> single line constructs as they don't generate warnings

> pros/cons: indentation isn't used for adding comments to the code (that's what
> comments are for)

> cons: large impact on code base

> - reindent all todo_wine

> same as above, but also reindenting the "todo_wine {\n<...>\n}" and the
> "todo_wine ok()" on a single line constructs

> pros/cons: indentation isn't used for adding comments to the code (that's what
> comments are for)

> cons: large impact on code base

> B) uninitialized objects

> ===============

> GCC11 warns on code like:

> void foo(const TYPE* s);

> .....

> TYPE s;

> foo(&s);

> because, s isn't initialized, and is passed as const ptr, hence could be read by
> function foo without being initialized

> proposal:

> - depending on context, different fixes are at hand: either initialize s, or
> when applicable, play with aliasing

> C) partial structures

> ============

> In a bunch of places, we use a pointer to a structure, where underlying
> allocated object is smaller than the actual size of the structure.

> (roughly 400 lines of warnings (*))

> It's used:

> - when dealing with two structures sharing their first fields (like in BITMAP
> for example)

> - in tests, to test behavior will various sizes of objects as input...

> proposal: disable this warning in configure

> D) sizeof/sizeof

> =========

> GCC11 warns when sizeof(foo)/sizeof(bar) is used and cannot be reduced to
> computing the number of elements of an array

> proposal: rewrite as sizeof(foo)/(sizeof(bar)) (note the parenthesis around
> sizeof(bar), as suggested by GCC)

> A+

> (*) those values are rough estimates, only consider the order of magnitude
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20210929/936d0c27/attachment-0001.htm>