Paul Eggert wrote:
> This sounds like GCC bug 85734, which has been marked as fixed.
> Evidently it's rearing its ugly head again. We should fix the bug rather
> than pollute the code with compiler pacifications.
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85734
I've now reported these as
On 2023-05-19 05:12, Bruno Haible wrote:
These are global data flow properties, that "gcc -flto" can well exploit to
produce better code. But a function's declaration must remain valid
independently of the global data flow in the surrounding program.
So I guess _GL_ATTRIBUTE_CONST is fine there
Pádraig Brady wrote:
> In general for any tuning though, since the tuning param struct is declared
> const,
That the 'tuning' parameter is a 'const Hash_tuning *' is merely an indication
that the function is pure. If it was a 'Hash_tuning *' and if there was an
assignment to a field tuning->somet
On 19/05/2023 12:03, Bruno Haible wrote:
Hi Pádraig,
diff --git a/lib/hash.c b/lib/hash.c
index 918aa0d1c3..332cca6df9 100644
--- a/lib/hash.c
+++ b/lib/hash.c
@@ -492,7 +492,7 @@ check_tuning (Hash_table *table)
TUNING, or return 0 if there is no possible way to allocate that
many en
Hi Pádraig,
> diff --git a/lib/hash.c b/lib/hash.c
> index 918aa0d1c3..332cca6df9 100644
> --- a/lib/hash.c
> +++ b/lib/hash.c
> @@ -492,7 +492,7 @@ check_tuning (Hash_table *table)
> TUNING, or return 0 if there is no possible way to allocate that
> many entries. */
>
> -static size_t
* lib/hash.c (compute_bucket_size): Change _GL_ATTRIBUTE_PURE
to _GL_ATTRIBUTE_CONST as suggested by GCC 13 with -flto.
---
ChangeLog | 6 ++
lib/hash.c | 2 +-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/ChangeLog b/ChangeLog
index 5e93f9ac31..a57cc4ae59 100644
--- a/Change
