Re: Problems testing Bison with GCC 12.1

Akim Demaille <[email protected]> Mon, 1 Aug 2022 07:02:57 +0200
Newsgroups gmane.comp.parsers.bison.patches
Message-ID <[email protected]>
Hi Paul,

Good to see you!

> Le 31 juil. 2022 =C3=A0 22:42, Paul Eggert <[email protected]> a =
=C3=A9crit :
>=20
> On 7/31/22 04:08, Akim Demaille wrote:
>=20
>>     Reported by clang's -Wunused-but-set-variable warning.
>=20
> I noticed that bleeding-edge Bison no longer passes 'make check' with =
current GCC (12.1) if one configures with --enable-gcc-warnings.

Thanks a lot for this!

> It's been a while since I built Bison; when I just now tried it I got =
some warnings from ./bootstrap and from GCC 12.1 and from a pedantic =
private 'grep' on Fedora x86-64, which I fixed with the attached patches =
which I hope are OK.

Of course they are :)

> Unfortunately there are still several failures in the tests. Tests =
306, 311, 322, 652 fail with diagnostics like "'yylval' may be used =
uninitialized [-Werror=3Dmaybe-uninitialized]".

Oh no, not that again :(

> Many C++ tests (400-25, 440-53, 664-5, 667-76, 679-80, 682-3, 685-9, =
692) fail with diagnostics like "noexcept-expression evaluates to =
'false' because of a call to =
'yy::parser::stack_symbol_type::stack_symbol_type()' =
[-Werror=3Dnoexcept]".

I'll have a look at that.

> One glr2.cc test (552) fails with "variable 'yyerrloc' might be =
clobbered by 'longjmp' or 'vfork' [-Werror=3Dclobbered]".
>=20
> A simple way to fix the -Wmaybe-uninitialized stuff is to omit =
-Wmaybe-uninitialized when compiling tests. There may be similar ways to =
work around the other issues. Of course there are pros and cons to =
simply disabling the static checking.

Yes.  What annoys me is that if we're ignoring these warnings, we are =
basically forwarding them to our users, and they will have to find ways =
to silence them.  And if we silence them too strongly, we might hide =
valid diagnostics about user code.

> At some point perhaps Bison should adopt Gnulib's manywarnings module, =
which tracks GCC warnings well. There are some new GCC warnings that =
I've found useful when compiling other programs.

Yes, I've considered the option several times, but never did it.  I =
don't remember exactly what the problem was; it might be related to the =
fact that I use different sets of compiler flags between compiling bison =
and testing it.

Cheers!=