Re: Solaris compiler status

On 03.09.25 13:42, Daniel Gustafsson wrote:
>> On 3 Sep 2025, at 07:47, Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>
>> - Hundreds of compiler warnings (They are not necessarily wrong, but it shows that no one has taken care to tune the warnings or the code in any way recently.)
>
> Should these be posted somewhere before they are lost in case anyone is keen on
> digging through the list for any relevant fixes?

That would require me to figure out how to export files from this VM.
;-) But I did figure out how to copy and paste, so here is at least a
summary:

1 (E_ARG_INCOMPATIBLE_WITH_ARG_L)
16 (E_ASSIGNMENT_TYPE_MISMATCH)
1 (E_CONST_OBJ_SHOULD_HAVE_INITIZR)
24 (E_CONST_PROMOTED_LONG_LONG)
1 (E_EMPTY_DECLARATION)
1899 (E_END_OF_LOOP_CODE_NOT_REACHED)
22 (E_FUNC_NO_RET_RET)
2 (E_INTEGER_OVERFLOW_DETECTED)
23 (E_L_OPERAND_DOT_NOT_LVALUE_NOW)
2 (E_OPERANDS_INCOMPATIBLE_TYPES)
1 (E_REF_STATIC_EXTERN_INLINE)
714 (E_STATEMENT_NOT_REACHED)
435 (E_STRUCT_DERIVED_FROM_FLEX_MBR)

Most of these as you can see are from lack of understanding about flow
control annotations or conventions.

But there are a couple of interesting ones:

1 (E_EMPTY_DECLARATION)

This is actually a real find, albeit harmless:

```
diff --git a/src/backend/replication/logical/slotsync.c
b/src/backend/replication/logical/slotsync.c
index 9d0072a49ed..8c061d55bdb 100644
--- a/src/backend/replication/logical/slotsync.c
+++ b/src/backend/replication/logical/slotsync.c
@@ -1337,7 +1337,7 @@ reset_syncing_flag()
SpinLockRelease(&SlotSyncCtx->mutex);

syncing_slots = false;
-};
+}

/*
* The main loop of our worker process.
```

2 (E_INTEGER_OVERFLOW_DETECTED)

This complains about lwlock.c

StaticAssertDecl((MAX_BACKENDS & LW_FLAG_MASK) == 0,
"MAX_BACKENDS and LW_FLAG_MASK overlap");

StaticAssertDecl((LW_VAL_EXCLUSIVE & LW_FLAG_MASK) == 0,
"LW_VAL_EXCLUSIVE and LW_FLAG_MASK overlap");

Here, MAX_BACKENDS is of type unsigned int and LW_FLAG_MASK is of type
signed int. (LW_VAL_EXCLUSIVE is computed from MAX_BACKENDS and is also
unsigned int.) The & operation promotes both to unsigned int, and so it
thinks you might get an overflow of the LW_FLAG_MASK value?

I can make the warning go away with this:

diff --git a/src/backend/storage/lmgr/lwlock.c
b/src/backend/storage/lmgr/lwlock.c
index a4aecd1fbc3..667ed4cf699 100644
--- a/src/backend/storage/lmgr/lwlock.c
+++ b/src/backend/storage/lmgr/lwlock.c
@@ -95,7 +95,7 @@
#define LW_FLAG_RELEASE_OK ((uint32) 1 << 30)
#define LW_FLAG_LOCKED ((uint32) 1 << 29)
#define LW_FLAG_BITS 3
-#define LW_FLAG_MASK
(((1<<LW_FLAG_BITS)-1)<<(32-LW_FLAG_BITS))
+#define LW_FLAG_MASK
(((1U<<LW_FLAG_BITS)-1)<<(32-LW_FLAG_BITS))

/* assumes MAX_BACKENDS is a (power of 2) - 1, checked below */
#define LW_VAL_EXCLUSIVE (MAX_BACKENDS + 1)

I can't reproduce this with gcc by removing -fwrapv and dialing up the
-Wstrict-overflow= levels. And I also don't want to think about what
this double-shift expression even means. :-/

But intuitively, it seems better if a "mask" value has an unsigned type.

I don't know to what extent PostgreSQL can even survive in a non-fwrapv
environment. That's a larger philosophical question.