[master] b86f51495 Make builds work with SunCC 12.6

Nils Goroll nils.goroll at uplex.de
Thu Oct 31 20:31:06 UTC 2024


commit b86f5149566202ebe99c85c428672b06676a155d
Author: Nils Goroll <nils.goroll at uplex.de>
Date:   Thu Oct 31 21:03:46 2024 +0100

    Make builds work with SunCC 12.6
    
    this afternoon, I went down a rabbit hole of the unpleasent kind:
    
    Our SunCC 12.4 vtester stopped working after an upgrade of the "host" (global
    zone), for reasons which I have not fully understood:
    
    "VSC_lck.c", line 22: can not declare variably modified type at file scope (E_CANT_DECL_FILESCOPE_VM)
    "VSC_lck.c", line 23: can not declare variably modified type at file scope (E_CANT_DECL_FILESCOPE_VM)
    ...
    
    The immediate cause for this is that the fallback for v_static_assert was used,
    which would fail the compilation for the reason given (somehow justified).
    
    While SunCC 12.4 offers a -std=c11 option, that would only give an
    __STDC_VERSION__ of 1999something, which we can not safely assume to support
    native static asserts. And making E_CANT_DECL_FILESCOPE_VM non-fatal seemed to
    be too high a price.
    
    After not seeing a way to make the old compiler work again while retaining some
    usefulness (I have _no_ clue as to why the behavior changed, because the
    compiler suite binaries were not touched at all), I tried to make a later
    version work.
    
    Which was a success in the sense that it would compile again without ugly hacks
    around v_static_assert, but was a failure in the sense that a _lot_ of warnings
    had to be made non-fatal. Which, given that compiler warnings are one of the
    main reasons for having a variety of compilers to begin with, brought me close
    to the point of simply giving up on SunCC.
    
    In the end, there was _one_ new warning which I did not suppress and rather
    addressed in the source code (see previous commit).
    
    For the other issues I saw no satisfactory changes to the source, so I made the
    respective warnings non-fatal:
    
    * no%E_END_OF_LOOP_CODE_NOT_REACHED
    
      For patterns like do { /* ... */ return; } while (0)
    
      I really do not see much sense in avoiding this pattern
    
    * no%E_UNRECOGNIZED_PRAGMA_IGNORED
    
      Harmless complaints about #pragma GCC
    
    * no%E_STATEMENT_NOT_REACHED no%E_FUNC_HAS_NO_RETURN_STMT
    
      SunCC now complains about NEEDLESS() statements which we had added because ...
      SunCC complained. Facepalm...
    
    * no%E_INITIALIZATION_TYPE_MISMATCH no%E_ARG_INCOMPATIBLE_WITH_ARG_L no%E_ASSIGNMENT_TYPE_MISMATCH
    
      These all concern function pointers set to / passed as NULL. Yes, NULL
      defined as (void *)0 is not a valid function pointer, true, but I really see
      no sense in changing all these places to just 0 or add casts...
    
    * no%E_FUNC_NO_RET_RET
    
      SunCC now thinks that functions which we declared noreturn might return. I
      checked one case which absolutely would never return because of an exit(2).
      Why on earth SunCC would think it still would, I have no idea.
    
    * -xatomic=studio
    
      This was necessary because SunCC would not automatically link to its atomic
      library, despite the documentation saying it would.
    
    Version used:
    
    $ cc -V
    cc: Studio 12.6 Sun C 5.15 SunOS_i386 2017/05/30

diff --git a/configure.ac b/configure.ac
index f0d1a3b1f..b36c599f3 100644
--- a/configure.ac
+++ b/configure.ac
@@ -675,8 +675,9 @@ AX_CHECK_COMPILE_FLAG([-Wall],
 
 if test "$SUNCC" = "yes" ; then
     SUNCC_CFLAGS=" \
-	-errwarn=%all,no%E_EMPTY_TRANSLATION_UNIT \
+	-errwarn=%all,no%E_EMPTY_TRANSLATION_UNIT,no%E_END_OF_LOOP_CODE_NOT_REACHED,no%E_UNRECOGNIZED_PRAGMA_IGNORED,no%E_STATEMENT_NOT_REACHED,no%E_INITIALIZATION_TYPE_MISMATCH,no%E_ARG_INCOMPATIBLE_WITH_ARG_L,no%E_ASSIGNMENT_TYPE_MISMATCH,no%E_FUNC_HAS_NO_RETURN_STMT,no%E_FUNC_NO_RET_RET \
 	-errtags=yes \
+	-xatomic=studio \
 	"
     AX_CHECK_COMPILE_FLAG([${SUNCC_CFLAGS}],
 	[CFLAGS="${CFLAGS} ${SUNCC_CFLAGS}"


More information about the varnish-commit mailing list