Re: Error compiling bison 3.4.2 on Solaris

[Akim Demaille]

Hi Paul,

> Le 20 oct. 2019 à 21:45, Paul Eggert <address@hidden> a écrit :
> 
> On 10/20/19 5:04 AM, Akim Demaille wrote:
> 
>> I still believe the warning is valid.  Annoying, but valid.
> 
> Sure, just as a compiler that said "warning: semicolon present in the source 
> code" for each semicolon would be annoying-but-valid.

I was answering to your wording: "false positive".  It's an annoying-positive, 
hardly a false positive.

> (Semicolons are dangerous! Think how much safer your C program will be if you 
> omit semicolons! :-)

Actually, it would be the sign that I stopped writing C, and was writing in Go 
for instance.  That does make my programs safer :)


> However, the question is not whether the warning is *valid*; it's whether the 
> warning is *useful*.

Agreed.  C lacks a way to say "hey, these are templates, don't bug me with 
problems that are only for handwritten code".

> And when the warning is about code that is doing portable and reliable 
> integer overflow checking (as is the case here), a compiler that in essence 
> is saying "watch out! the code is trying to do portable and reliable integer 
> overflow checking!" is harmful, not useful.

Again, agreed.  That's what I meant when I wrote

>> I don't really understand what you call them false alarms.  I agree they are 
>> annoying alarms, that are meant for hand-written code rather than 
>> compile-time metaprogramming in cpp as is the case here, but they seem legit.

>> And therefore I would prefer to have intprops.h use pragmas to disable it 
>> locally.
> 
> I'd rather not. Newer compilers are doing their jobs better in this area,

I don't see that, given that I have the problem with GCC 7, 8 and 9 on macOS.

> and we should not worry about pacifying older compilers as it's considerably 
> more trouble than it's worth.

Too soon to call GCC 9 old :)

> Instead, we should simply suggest that builders who employ older or buggy 
> compilers should not use --enable-gcc-warnings.

See also what I said about the warnings in the test suite.


>> But of course we can disable the warning for bison, and not the test suite, 
>> as below.  It fixes the issues with GCC, but not yet with old clangs (3.3 
>> and 3.4).
> 
> Yes, that is a good fix - it's more targeted than the one I proposed.
> 
> To pacify old Clangs, you can add 
> "-Wno-tautological-constant-out-of-range-compare" as well. That's what 
> Coreutils does.
> 
> To give you a preview of future problems you might run into with Clang, here 
> are some other Clang flags that Coreutils and other GCC projects have found 
> useful:
> 
> -Wno-tautological-compare
> -Wno-switch
> -Wno-pointer-sign
> -Wno-string-plus-int
> -Wno-unknown-attributes
> -Wno-initializer-overrides
> 
> Emacs also adds "-Wno-null-pointer-arithmetic" on the somewhat-controversial 
> grounds that ((char *)0 == (char *)0 + 0) is true everywhere even if the C 
> standard doesn't require it (Emacs relies on this for its pointer tagging).
> 
> Of course Bison should add these other flags only if needed.

So I installed this.  Thanks!

commit fdef997432f7141d8eaf4396f61708fd3c52ec9d
Author: Akim Demaille <address@hidden>
Date:   Mon Oct 21 10:35:01 2019 +0200

    build: disable -Wtautological-constant-out-of-range-compare
    
    Also see e31f92495ce14a5d924b148c8ea1470003cc47c1 and
    https://lists.gnu.org/archive/html/bug-bison/2019-10/msg00061.html
    
    * configure.ac (warn_common): Disable
    -Wtautological-constant-out-of-range-compare.
    (warn_tests): Restore it.

diff --git a/configure.ac b/configure.ac
index f055a68c..f0689070 100644
--- a/configure.ac
+++ b/configure.ac
@@ -94,10 +94,16 @@ AC_ARG_ENABLE([gcc-warnings],
               [enable_gcc_warnings=no])
 AM_CONDITIONAL([ENABLE_GCC_WARNINGS], [test "$enable_gcc_warnings" = yes])
 if test "$enable_gcc_warnings" = yes; then
+  # -Wno-tautological-constant-out-of-range-compare for Clang 3.3 and
+  # 3.4 on GNU/Linux that choke on intprops.h's INT_MULTIPLY_WRAPV,
+  # etc.  It's also for these macros, but on GCC 7, 8 and 9 on macOS
+  # and GCC 4.6, 4.7 and 4.9 on GNU/Linux, that we disable
+  # -Wtype-limits globally.  See
+  # https://lists.gnu.org/archive/html/bug-bison/2019-10/msg00061.html.
   warn_common='-Wall -Wextra -Wcast-align
     -fparse-all-comments -Wdocumentation
     -Wformat -Wimplicit-fallthrough -Wnull-dereference
-    -Wno-sign-compare -Wno-type-limits
+    -Wno-sign-compare -Wno-tautological-constant-out-of-range-compare 
-Wno-type-limits
     -Wpointer-arith -Wshadow
     -Wwrite-strings'
   warn_c='-Wbad-function-cast -Wstrict-prototypes'
@@ -112,7 +118,8 @@ if test "$enable_gcc_warnings" = yes; then
   # trick in the test suite to check some private implementation
   # details for lalr1.cc.
   warn_tests='-Wundef -pedantic -Wconversion
-    -Wdeprecated -Wsign-compare -Wsign-conversion -Wtype-limits
+    -Wdeprecated -Wsign-compare -Wsign-conversion
+    -Wtautological-constant-out-of-range-compare -Wtype-limits
     -fno-color-diagnostics
     -Wno-keyword-macro'