Re: Problems testing Bison with GCC 12.1

[Akim Demaille]

Hi Paul,

Good to see you!

> Le 31 juil. 2022 à 22:42, Paul Eggert <eggert@cs.ucla.edu> a écrit :
> 
> On 7/31/22 04:08, Akim Demaille wrote:
> 
>>     Reported by clang's -Wunused-but-set-variable warning.
> 
> 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=maybe-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=noexcept]".

I'll have a look at that.

> One glr2.cc test (552) fails with "variable 'yyerrloc' might be clobbered by 
> 'longjmp' or 'vfork' [-Werror=clobbered]".
> 
> 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!