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!=