Re: new pacification suggestion?

2018-11-25 Thread Akim Demaille


> Le 20 nov. 2018 à 23:18, Akim Demaille  a écrit :
> 
> I don’t have any problems with having two pairs of parens, after all we’ve 
> done that forever in the case of assignments in if’s etc.  That’s a clear way 
> to tell the others, including the compiler, that something fishy is 
> intentional (until ‘sic’ becomes a keyword).
> 
> The problem here is that it does not work, although it should.

This appears to be the proper fix.

commit cc050fd3218c4ee467dfe6c234867d84bd3e7119
Author: Akim Demaille 
Date:   Thu Nov 22 18:03:12 2018 +0100

warning: avoid warnings about unreachable code

Reported by Uxio Prego.
https://lists.gnu.org/archive/html/help-bison/2018-11/msg00031.html

We also need to move the unreachable 'goto' to a reachable place,
otherwise clang complains about the code being unreachable anyway.
See also https://bugs.llvm.org/show_bug.cgi?id=39736.

Interestingly, we don't have to apply that trick to
`#define YYCDEBUG if (false) std::cerr`, clang does not warn when the
code comes from macro expansion.

* configure.ac: Use -Wunreachable-code when supported.
* data/lalr1.cc, data/yacc.c: Pacify clang's warning about `if (0)`
by using a macro.
Another possibility was to move this statement to a reachable place.
* tests/actions.at, tests/c++.at: Avoid generating unreachable code.

diff --git a/configure.ac b/configure.ac
index 3d55f08c..959fc968 100644
--- a/configure.ac
+++ b/configure.ac
@@ -113,6 +113,7 @@ if test "$enable_gcc_warnings" = yes; then
 -fno-color-diagnostics
 -Wno-keyword-macro'
 
+
   AC_LANG_PUSH([C])
   # Clang supports many of GCC's -W options, but only issues warnings
   # on the ones it does not recognize.  In that case, gl_WARN_ADD
@@ -126,6 +127,11 @@ if test "$enable_gcc_warnings" = yes; then
   # CFLAGS, and restore CFLAGS after the tests.
   save_CFLAGS=$CFLAGS
   gl_WARN_ADD([-Werror=unknown-warning-option], [CFLAGS])
+  # Accept this warning only if it is not too touchy (e.g., clang 3.3
+  # and 3.4).
+  gl_WARN_ADD([-Wunreachable-code], [WARN_CFLAGS],
+  [AC_LANG_PROGRAM([],
+  [[if (sizeof (long) < sizeof (int)) return 1;]])])
   for i in $warn_common $warn_c;
   do
 gl_WARN_ADD([$i], [WARN_CFLAGS])
@@ -147,6 +153,7 @@ if test "$enable_gcc_warnings" = yes; then
   CFLAGS=$save_CFLAGS
   AC_LANG_POP([C])
 
+
   AC_LANG_PUSH([C++])
   save_CXXFLAGS=$CXXFLAGS
   gl_WARN_ADD([-Werror=unknown-warning-option], [CXXFLAGS])
@@ -154,6 +161,11 @@ if test "$enable_gcc_warnings" = yes; then
   do
 gl_WARN_ADD([$i], [WARN_CXXFLAGS])
   done
+  # Accept this warning only if it is not too touchy (e.g., clang 3.3
+  # and 3.4).
+  gl_WARN_ADD([-Wunreachable-code], [WARN_CXXFLAGS],
+  [AC_LANG_PROGRAM([],
+  [[if (sizeof (long) < sizeof (int)) return 1;]])])
   gl_WARN_ADD([-Wzero-as-null-pointer-constant], [WARN_CXXFLAGS],
   [AC_LANG_PROGRAM([], [nullptr])])
   gl_WARN_ADD([-Werror], [WERROR_CXXFLAGS])
diff --git a/data/lalr1.cc b/data/lalr1.cc
index 8486f9e8..78f3d1e0 100644
--- a/data/lalr1.cc
+++ b/data/lalr1.cc
@@ -971,11 +971,11 @@ b4_dollar_popdef])[]dnl
   | yyerrorlab -- error raised explicitly by YYERROR.  |
   `---*/
   yyerrorlab:
-/* Pacify compilers like GCC when the user code never invokes
-   YYERROR and the label yyerrorlab therefore never appears in user
-   code.  */
+/* Pacify compilers when the user code never invokes YYERROR and
+   the label yyerrorlab therefore never appears in user code.  */
 if (false)
-  goto yyerrorlab;
+  YYERROR;
+
 /* Do not reclaim the symbols of the rule whose action triggered
this YYERROR.  */
 yypop_ (yylen);
diff --git a/data/yacc.c b/data/yacc.c
index 3f2883c6..ee0acd5b 100644
--- a/data/yacc.c
+++ b/data/yacc.c
@@ -1777,11 +1777,10 @@ yyerrlab:
 | yyerrorlab -- error raised explicitly by YYERROR.  |
 `---*/
 yyerrorlab:
-  /* Pacify compilers like GCC when the user code never invokes
- YYERROR and the label yyerrorlab therefore never appears in user
- code.  */
+  /* Pacify compilers when the user code never invokes YYERROR and the
+ label yyerrorlab therefore never appears in user code.  */
   if (0)
-goto yyerrorlab;
+YYERROR;
 
   /* Do not reclaim the symbols of the rule whose action triggered
  this YYERROR.  */
diff --git a/examples/calc++/local.mk b/examples/calc++/local.mk
index 059f2b05..8de5bf4d 100644
--- a/examples/calc++/local.mk
+++ b/examples/calc++/local.mk
@@ -20,7 +20,7 @@
 
 # Don't depend on $(BISON) otherwise we would rebuild these files
 # in srcdir, including during distcheck, which is forbidden.
-%D%/parser.stamp: $(BISON_IN)
+%D%/parser.stamp: $(BISON_IN) $(dist_pkgdata_DATA)
 SUFFIXES += .yy .stamp
 .yy.stamp:
$(AM_V_YACC)rm -f $@
diff --git a/tests/actions.at b/tests/actions.at
i

Re: new pacification suggestion?

2018-11-25 Thread Uxio Prego
So the problem was in an upper scope, a label never jumped to.

Please forgive me this little off-topic: I'm having the same alert in
https://github.com/westes/flex/blob/98018e3f58d79e082216d406866942841d4bdf8a/src/flex.skl#L1394
didn't report there yet. For no particular reason other I maybe wanted to
report one by one and I was already registered in this list.

There, unlike in the Bison case, I can't see any comment noting that I might
be misusing some known utility supposed to be used. So if the Bison case
is relevant, I guess this one is more relevant.

> On 25 Nov 2018, at 10:28, Akim Demaille  wrote:
> 
> 
> 
>> Le 20 nov. 2018 à 23:18, Akim Demaille  a écrit :
>> 
>> I don’t have any problems with having two pairs of parens, after all we’ve 
>> done that forever in the case of assignments in if’s etc.  That’s a clear 
>> way to tell the others, including the compiler, that something fishy is 
>> intentional (until ‘sic’ becomes a keyword).
>> 
>> The problem here is that it does not work, although it should.
> 
> This appears to be the proper fix.
> 
> commit cc050fd3218c4ee467dfe6c234867d84bd3e7119
> Author: Akim Demaille 
> Date:   Thu Nov 22 18:03:12 2018 +0100
> 
>warning: avoid warnings about unreachable code
> 
>[...]


___
help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison

Re: new pacification suggestion?

2018-11-25 Thread Uxio Prego
Well... for flex 2.6.4 goes away when replacing `%option noyywrap` for
a real `int _wrap(void) { return 1; }`. So that’s an easy workaround
if those warnings where blockers. But I think the `%option` should prevent
such thing from popping up.

> On 25 Nov 2018, at 17:39, Uxio Prego  wrote:
> 
> […]
> 
> There, unlike in the Bison case, I can't see any comment noting that I might
> be misusing some known utility supposed to be used. So if the Bison case
> is relevant, I guess this one is more relevant.
> 
>> On 25 Nov 2018, at 10:28, Akim Demaille  wrote:
>> 
>>> […]
>> 
>> This appears to be the proper fix.
>> 
>> commit cc050fd3218c4ee467dfe6c234867d84bd3e7119
>> Author: Akim Demaille 
>> Date:   Thu Nov 22 18:03:12 2018 +0100
>> 
>>   warning: avoid warnings about unreachable code
>> 
>>   [...]


___
help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison