[Bug middle-end/54848] -ftrapv doesn't work when assigning to an integer with smaller size

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54848

Bruno Haible  changed:

   What|Removed |Added

 CC||bruno at clisp dot org

--- Comment #2 from Bruno Haible  ---
Another test case:

 u.c =
int
main ()
{
  unsigned short a = 0xeb64;
  unsigned short b = 0xf1e2;
  unsigned short c = a * b;
}
==
$ gcc -ftrapv u.c
$ ./a.out; echo $?
0

Reproduced with gcc 14.1.0.

[Bug analyzer/114920] New: null_terminated_string_arg attribute does not warn for non-nul-terminated strings

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114920

Bug ID: 114920
   Summary: null_terminated_string_arg attribute does not warn for
non-nul-terminated strings
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: bruno at clisp dot org
  Target Milestone: ---

Created attachment 58085
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58085=edit
test case foo.c

The documentation of null_terminated_string_arg in
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html gave me the
expectation that the analyzer would produce a warning when I pass a
non-NUL-terminated string to a function declared with this attribute. But it
doesn't, neither for stack-allocated strings nor for heap-allocated strings.

Test case:
= foo.c ===
#include 
#include 
#include 
extern size_t strlen (const char *s) __attribute__
((__null_terminated_string_arg__ (1)));
int main ()
{
  {
char s[7];
memcpy (s, "FOOBAR!", 7);
printf ("n=%d\n", (int) strlen (s));
  }
  {
char *s = malloc (7);
if (s != NULL) {
  memcpy (s, "FOOBAR!", 7);
  printf ("n=%d\n", (int) strlen (s));
}
  }
}
===
$ gcc -c foo.c -Wall -Wextra -fanalyzer -Wanalyzer-use-of-uninitialized-value
-Wanalyzer-out-of-bounds

Expected: two warnings
Actual: no warning.

$ gcc --version
gcc (GCC) 14.0.1 20240411 (Red Hat 14.0.1-0)

[Bug tree-optimization/114876] [11/12/13/14 Regression] -fprintf-return-value mishandles %lc with a '\0' argument.

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114876

--- Comment #4 from Bruno Haible  ---
(In reply to Jakub Jelinek from comment #3)
> Given that there are or at least were implementations which
> emitted no characters

Yes, musl libc emits/emitted 0 characters in this case.

[Bug tree-optimization/114876] -fprintf-return-value mishandles %lc with a '\0' argument.

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114876

Bruno Haible  changed:

   What|Removed |Added

 CC||bruno at clisp dot org

--- Comment #1 from Bruno Haible  ---
What does *printf of %lc with a (wint_t) '\0' argument do?

Note that the published POSIX:2018 still has a wrong description: Its
description requires *printf to produce 0 characters.

This was wrong in ISO C as well. It has been corrected in ISO C 23 § 7.23.6.1,
in the meeting from 2023-06-20 to 2023-06-23. See
https://www.open-std.org/JTC1/sc22/wg14/www/docs/n3167.pdf  section GB-141 page
23, 24. The decision ("option 1") is detailed in
https://www.open-std.org/JTC1/sc22/wg14/www/docs/n3148.doc row GB-141 page 34,
35:
  "Option 1 (require a NUL) - change the text to:
   If an l length modifier is present, the wint_t argument is converted
   as if by a call to the wcrtomb function with a pointer to storage of
   at least MB_CUR_MAX bytes, the wint_t argument converted to wchar_t,
   and an initial shift state."
This description requires *printf to produce 1 NUL character.

Then, the Austin Group followed suit and, through
https://austingroupbugs.net/view.php?id=1647 , decided that POSIX will use the
same definition:
  "If an l (ell) qualifier is present, the wint_t argument shall be converted
   to a multi-byte sequence as if by a call to wcrtomb( ) with the wint_t
   argument converted to wchar_t and an initial shift state, and the
   resulting bytes written."

This aligns the POSIX behaviour with what glibc was doing all the time, namely
to produce 1 NUL character.

[Bug middle-end/111655] [11/12/13/14 Regression] wrong code generated for __builtin_signbit and 0./0. on x86-64 -O2

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111655

Bruno Haible  changed:

   What|Removed |Added

 CC||bruno at clisp dot org

--- Comment #16 from Bruno Haible  ---
(In reply to Paul Eggert from comment #5)
> Although it is indeed unspecified whether 0.0/0.0 yields -NaN or +NaN, it is
> well understood that negating a floating point value flips its sign bit.

While I agree that this is generally true, it's not the case on mips with clang
as compiler.

Namely, this compiler generates 'neg.d' instructions for the unary minus of a
'double' value, and this instruction may be a no-op on NaN values, depending on
the CPU's control registers. For details, see the "MIPS® Architecture for
Progreammers, Volume II-A: The MIPS® Instruction Set Manual", page 307 (317).

Whereas gcc generates an integer XOR instruction (at least in my test cases),
so is fine.

[Bug target/114659] gcc miscompiles a __builtin_memcpy on i386, leading to wrong results for SNaN

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114659

--- Comment #9 from Bruno Haible  ---
(In reply to Andrew Pinski from comment #7)
> Much more related to PR 56831 and PR 57484 rather than the other two ...

Well, bug #56831 is more about function calls and the ABI, whereas this bug
here and bug #58416 and bug #93271 are about the compiler picking a memory
location which holds convert_snan_to_qnan(value) rather than a memory location
which holds the original value.

[Bug target/114659] gcc miscompiles a __builtin_memcpy on i386, leading to wrong results for SNaN

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114659

--- Comment #8 from Bruno Haible  ---
(In reply to Andrew Pinski from comment #6)
> I doubt there is not much to be done here.

I see it as an incorrect modelization of the x87 hardware, together with a
missing distinction in the common expression elimination / aliasing analysis.
In detail:

* Incorrect modelization of the x87 hardware: The compiler seems to assume that
flds MEM_LOCATION_1
fsts MEM_LOCATION_2
  will result in MEM_LOCATION_2 having the same value as MEM_LOCATION_1. This
is wrong;
  this is not how the x87 hardware behaves. The actual result is:
*MEM_LOCATION_2 = convert_snan_to_qnan(*MEM_LOCATION_1).

* In the common expression elimination / aliasing analysis, the compilers seems
to keep
  track of a set of memory locations MEM_LOCATION_1, ..., MEM_LOCATION_n which
have the
  same value. In fact, this set needs to be partitioned into two sets: a subset
which
  contains the same value, and the complementary subset which contains
  convert_snan_to_qnan(value).

  In other words, each element of the set needs to be annotated with a bit that
tells
  whether the value has been subject to the convert_snan_to_qnan.

[Bug c/114659] gcc miscompiles a __builtin_memcpy on i386, leading to wrong results for SNaN

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114659

--- Comment #5 from Bruno Haible  ---
Related: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93271

[Bug c/114659] gcc miscompiles a __builtin_memcpy on i386, leading to wrong results for SNaN

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114659

--- Comment #4 from Bruno Haible  ---
Related: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416

[Bug c/114659] gcc miscompiles a __builtin_memcpy on i386, leading to wrong results for SNaN

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114659

--- Comment #3 from Bruno Haible  ---
Also reproducible in 64-bit mode, with '-mfpmath=387':

$ gcc -mfpmath=387 -Wall tf.c
$ ./a.out ; echo $?
0
$ gcc -mfpmath=387 -Wall -O2 tf.c
$ ./a.out ; echo $?
1

$ gcc -mfpmath=387 -Wall td.c
$ ./a.out ; echo $?
0
$ gcc -mfpmath=387 -Wall -O2 td.c
$ ./a.out ; echo $?
1

[Bug c/114659] gcc miscompiles a __builtin_memcpy on i386, leading to wrong results for SNaN

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114659

Bruno Haible  changed:

   What|Removed |Added

  Build||x86_64-linux-gnu
   Host||x86_64-linux-gnu
 Target||x86_64-linux-gnu

--- Comment #2 from Bruno Haible  ---
Note: "gcc-version 13.2.0" just invokes gcc-13.2.0, which I built from source.

[Bug c/114659] gcc miscompiles a __builtin_memcpy on i386, leading to wrong results for SNaN

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114659

--- Comment #1 from Bruno Haible  ---
Created attachment 57913
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57913=edit
test case td.c

[Bug c/114659] New: gcc miscompiles a __builtin_memcpy on i386, leading to wrong results for SNaN

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114659

Bug ID: 114659
   Summary: gcc miscompiles a __builtin_memcpy on i386, leading to
wrong results for SNaN
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bruno at clisp dot org
  Target Milestone: ---

Created attachment 57912
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57912=edit
test case tf.c

In the two attached test cases, gcc miscompiles a __builtin_memcpy invocation.
In the first test case, the data type is a 'float' (4 bytes).
In the second test case, the data type is a 'double' (8 bytes).

A value of this data type exists in memory, given as *x and *y.
A modified copy of this value, convert_snan_to_qnan(value), exists
also in the stack, among the local variables.
gcc implements the __builtin_memcpy operation by accessing
convert_snan_to_qnan(value) instead of the original value.

How to reproduce:

$ gcc-version 13.2.0 -m32 -Wall tf.c
$ ./a.out ; echo $?
0
$ gcc-version 13.2.0 -m32 -Wall -O2 tf.c
$ ./a.out ; echo $?
1

$ gcc-version 13.2.0 -m32 -Wall td.c
$ ./a.out ; echo $?
0
$ gcc-version 13.2.0 -m32 -Wall -O2 td.c
$ ./a.out ; echo $?
1

Analysis:

$ gcc-version 13.2.0 -m32 -Wall -O2 -S tf.c

tf.c has this function:

int
my_totalorderf (float const *x, float const *y)
{
  int xs = __builtin_signbit (*x);
  int ys = __builtin_signbit (*y);
  if (!xs != !ys)
return xs;

  int xn = __builtin_isnan (*x);
  int yn = __builtin_isnan (*y);
  if (!xn != !yn)
return !xn == !xs;
  if (!xn)
return *x <= *y;

  unsigned int extended_sign = -!!xs;
  union { unsigned int i; float f; } xu = {0}, yu = {0};
  __builtin_memcpy (, x, sizeof (float));
  __builtin_memcpy (, y, sizeof (float));
  return (xu.i ^ extended_sign) <= (yu.i ^ extended_sign);
}

tf.s looks like this:

my_totalorderf:
pushl   %ebx
subl$8, %esp
;;  int xs = __builtin_signbit (*x);
movl16(%esp), %eax
flds(%eax)
fsts(%esp);; [%esp+0] := convert_snan_to_qnan(*x)
fxam
fnstsw  %ax
movl%eax, %edx
movl20(%esp), %eax
andl$512, %edx
;;  int ys = __builtin_signbit (*y);
flds(%eax)
sete%cl
fsts4(%esp)   ;; [%esp+4] := convert_snan_to_qnan(*y)
fxam
fnstsw  %ax
testb   $2, %ah
sete%al
;;  if (!xs != !ys)
cmpb%al, %cl
jne .L12
;;  int xn = __builtin_isnan (*x);
fxch%st(1)
fucomi  %st(0), %st
fxch%st(1)
setnp   %bl
;;  int yn = __builtin_isnan (*y);
fucomip %st(0), %st
setnp   %al
;;  if (!xn != !yn)
cmpb%al, %bl
jne .L11
fstp%st(0)
flds(%esp)
fucomi  %st(0), %st
jp  .L9
flds4(%esp)
xorl%edx, %edx
fcomip  %st(1), %st
fstp%st(0)
setnb   %dl
jmp .L6
.p2align 4,,10
.p2align 3
.L12:
fstp%st(0)
fstp%st(0)
.L6:
addl$8, %esp
movl%edx, %eax
popl%ebx
ret
.p2align 4,,10
.p2align 3
.L11:
fucomip %st(0), %st
setp%dl
addl$8, %esp
xorl%ecx, %edx
popl%ebx
movzbl  %dl, %edx
movl%edx, %eax
ret
.p2align 4,,10
.p2align 3
.L9:
fstp%st(0)
negl%edx  ;; computes -xs
movl(%esp), %eax  ;; fetches convert_snan_to_qnan(*x)
instead of *x
movl4(%esp), %ebx ;; fetches convert_snan_to_qnan(*y)
instead of *y
sbbl%edx, %edx;; computes extended_sign = -!!xs;
xorl%edx, %eax;; computes (xu.i ^ extended_sign)
xorl%ebx, %edx;; computes (yu.i ^ extended_sign)
cmpl%eax, %edx;; compares (xu.i ^ extended_sign) and
(xu.i ^ extended_sign)
setnb   %dl
movzbl  %dl, %edx
jmp .L6

As you can see, (%esp) and 4(%esp) contain *not* the original
*x and *y respectively, but the result of an flds/fsts instruction pair,
that is, convert_snan_to_qnan(*x) and convert_snan_to_qnan(*y), respectively.

See https://lists.gnu.org/archive/html/bug-gnulib/2023-10/msg00060.html
for some background about these instructions on i386.

The analysis of td.c is similar; here the value is stored to
memory through an fldl/fstl pair.

[Bug libgcc/114646] libgcc's gthr.h still defines GTHREAD_USE_WEAK to 1 for newer glibc

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114646

Bruno Haible  changed:

   What|Removed |Added

 CC||bruno at clisp dot org

--- Comment #11 from Bruno Haible  ---
(In reply to Andrew Pinski from comment #9)
> Dup.
> 
> *** This bug has been marked as a duplicate of bug 87189 ***

This makes no sense to me:
- I verified that https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87189 is fixed;
therefore it ought to be marked as RESOLVED FIXED.
- Whereas H.J. is seeing this bug here with GCC 13 and glibc 2.38.
Therefore they cannot be duplicates of each other.

[Bug libgcc/87189] libgcc/gthr-posix.h (__gthread_active_p) makes unwarranted assumptions about libpthread.a

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87189

--- Comment #10 from Bruno Haible  ---
It is fixed in
- glibc 2.35 + gcc 11.4 (verified on Ubuntu 22.04),
- glibc 2.39 + gcc 13.2.1 (verified on Arch Linux 2024.04).

[Bug analyzer/111289] [13 Regression] Unwarranted -Wanalyzer-va-arg-type-mismatch warning

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111289

--- Comment #6 from Bruno Haible  ---
(In reply to John David Anglin from comment #5)
> Don't include  on hpux to avoid conflicting type declarations
> for mode_t.   This fixes test on houx.

Why not entirely remove the '#include '? There is nothing in this
file that needs it.

[Bug rust/113553] rust fails to build on sparc64-linux-gnu

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113553

Bruno Haible  changed:

   What|Removed |Added

 CC||bruno at clisp dot org

--- Comment #12 from Bruno Haible  ---
For reference: The Gnulib unit tests for posix_spawn* pass on sparc-linux-gnu
(both in 32-bit mode and in 64-bit mode).

[Bug other/112836] gcc fails when job control is used

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112836

--- Comment #5 from Bruno Haible  ---
(In reply to John Paul Adrian Glaubitz from comment #4)
> I tried this patch but it does not address the issue with posix_spawn that I
> am seeing.
> 
> Trying to build gcc from git on Linux sparc64 with glibc 2.37 with the
> following configuration:
> 
> ./configure --enable-languages=c,c++ --disable-bootstrap --disable-multilib
> --disable-nls --host=sparc64-unknown-linux-gnu
> 
> fails with:
> 
> xgcc: fatal error: cannot execute '/home/glaubitz/gcc/build/./gcc/cc1plus':
> posix_spawn: Bad address
> compilation terminated.
> 
> This can be worked around when building with one parallel job (make -j1).

This appears to be a different bug, because
  - it appears under different conditions (parallel make, not Ctrl-Z / 'fg'),
  - the message is different ("posix_spawn: Bad address", not "failed to get
exit status: Interrupted system call").

Could you please register it as a separate bug under
https://gcc.gnu.org/bugzilla/ ?

[Bug other/111288] formatting mistake in HTML documentation

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111288

Bruno Haible  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #6 from Bruno Haible  ---
A fix that includes my patch has been applied by Jakub Jelinek on 2023-12-01:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=ff99671ac3ea583a9d65c8c3cd3ff4aad1d68592

This bug report is therefore FIXED.

[Bug driver/112836] gcc fails when job control is used

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112836

--- Comment #1 from Bruno Haible  ---
Created attachment 56779
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56779=edit
proposed fix

Although the error is not easily reproducible, it is easy to analyze
and fix:

The piece of error message string "failed to get exit status" occurs
only in one place: in gcc/gcc.cc line 3462.

The only possible cause for the error message
"failed to get exit status: Interrupted system call" is therefore
that pex_get_status returned 0, with error code EINTR.

pex_get_status is defined in libiberty/pex-common.c, line 547.
It returns 0 only in line 555. We can infer that the function
pex_get_status_and_time had returned 0, with error code EINTR.

pex_get_status_and_time is defined in libiberty/pex-common.c, line 518.
It returns 0 only when ret gets to 0 in line 537. We can infer
that the obj->funcs->wait function must have returned non-zero,
with error code EINTR.

obj->funcs->wait is the method declared in libiberty/pex-common.h
line 128. On this platform, the relevant implementation is in
libiberty/pex-unix.c. The initialization happens in
libiberty/pex-unix.c line 338:
  return pex_init_common (flags, pname, tempbase, );
The obj->funcs->wait function function is thus pex_unix_wait.
It must have returned non-zero, with error code EINTR.

pex_unix_wait is defined in libiberty/pex-unix.c line 938.
Looking at its code, the function pex_wait must have returned a
negative value, with errno being set to EINTR.

pex_wait has 4 possible implementations, in
  libiberty/pex-unix.c line 128
  libiberty/pex-unix.c line 159
  libiberty/pex-unix.c line 170
  libiberty/pex-unix.c line 219
Since glibc has the 'wait4' function, the implementation that
matters is the one from libiberty/pex-unix.c line 128. But the
other implementations have the same problem: they don't handle
EINTR so far.

Find attached a proposed patch.

[Bug driver/112836] New: gcc fails when job control is used

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112836

Bug ID: 112836
   Summary: gcc fails when job control is used
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bruno at clisp dot org
  Target Milestone: ---

A compilation command with gcc failed, when I used bash's job control:


$ ~/build-32 -C
...
gcc -m32 -DHAVE_CONFIG_H -DEXEEXT=\"\" -DEXEEXT=\"\" -DNO_XMALLOC -DEXEEXT=\"\"
-I. -I../../gllib -I..  -DGNULIB_STRICT_CHECKING=1
-I/home/bruno/prefix32/include -Wall -fvisibility=hidden -g -O2 -MT
git-merge-changelog.o -MD -MP -MF $depbase.Tpo -c -o git-merge-changelog.o
../../gllib/git-merge-changelog.c &&\
mv -f $depbase.Tpo $depbase.Po
^Z
[1]+  Stopped ~/build-32 -C
bruno@localhost:~/testdir-all$ free
   totalusedfree  shared  buff/cache  
available
Mem: 2056072  119664 1773880 632  224808
1936408
Swap: 514072   0  514072
bruno@localhost:~/testdir-all$ fg 1
~/build-32 -C
gcc: fatal error: failed to get exit status: Interrupted system call
compilation terminated.
make[4]: *** [Makefile:11320: git-merge-changelog.o] Error 1
make[4]: Leaving directory '/home/bruno/testdir-all/build-32/gllib'
make[3]: *** [Makefile:11366: all-recursive] Error 1
make[3]: Leaving directory '/home/bruno/testdir-all/build-32/gllib'
make[2]: *** [Makefile:8407: all] Error 2
make[2]: Leaving directory '/home/bruno/testdir-all/build-32/gllib'
make[1]: *** [Makefile:3220: all-recursive] Error 1
make[1]: Leaving directory '/home/bruno/testdir-all/build-32'
make: *** [Makefile:3151: all] Error 2


The expected behaviour that after 'fg 1', stopped jobs continue to run
without failing.

This is on Linux/sparc64. Versions:
  - gcc (T2SDE) 13.2.1 20231124
  - Linux 6.6.3
  - glibc 2.38

[Bug sanitizer/112708] "gcc -fsanitize=address" produces wrong debug info for variables in function prologue

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112708

--- Comment #10 from Bruno Haible  ---
(In reply to Jakub Jelinek from comment #9)
> var-tracking is very compile time intensive,
> so it would significantly slow down -O0 compilation.

Indeed, these are the timings of "time make" that I observe when compiling
GNU gettext 0.22 (only the "user" time figure, in seconds):

gcc 11.2gcc 13.2

-ggdb 58.768.2
-ggdb -fvar-tracking  62.571.8
-ggdb -fsanitize=address  69.680.6
-ggdb -fsanitize=address -fvar-tracking   82.793.7

So, while -fvar-tracking without -fsanitize=address has a penalty of ca. 6%,
-fvar-tracking in the presence of -fsanitize=address has a penalty of ca. 17%.

[Bug sanitizer/112708] "gcc -fsanitize=address" produces wrong debug info for variables in function prologue

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112708

--- Comment #8 from Bruno Haible  ---
(In reply to Richard Biener from comment #7)
> It's -fvar-tracking, not -fvar-tracking-assignments.  At -O0 debug info
> during the prologue is unreliable without that.

Then how about enabling -fvar-tracking automatically when "-g" or "-ggdb" is
requested and the debug format supports it?

The documentation
https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Debugging-Options.html says:
"It is enabled by default when compiling with optimization (-Os, -O, -O2, …),
debugging information (-g) and the debug info format supports it."

Why not also enable it when compiling _without_ optimization?

I'm not using "-Og" because the documentation
https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Optimize-Options.html says "-Og
enables all -O1 optimization flags except for those that may interfere with
debugging", but what I want is optimal debugging and don't want to spend CPU
cycles on optimization.

[Bug sanitizer/112708] "gcc -fsanitize=address" produces wrong debug info for variables in function prologue

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112708

--- Comment #6 from Bruno Haible  ---
For comparison, what clang 17 with -fsanitize=address does in this situation,
is to not generate a stepping point at the function entry (xg-message.c:50).
The gdb 'step' command brings me directly to the first statement in the
function (xg-message.c:55). This may have some other drawbacks, but at least it
prevents the possibility of displaying wrong values for function parameters.

[Bug sanitizer/112708] "gcc -fsanitize=address" produces wrong debug info for variables in function prologue

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112708

--- Comment #5 from Bruno Haible  ---
(In reply to Andrew Pinski from comment #3)
> Also did you add -fvar-tracking-assignments ?

No, I haven't. I have specified CFLAGS=-ggdb, indicating that
  - I don't care about the optimization level,
  - but I want the ability to debug with gdb. And that includes not being
disturbed and alarmed by wrong values of variables. (I wouldn't mind if
single-stepping would not stop at the function entry directly, only at the
first statement of the function. Then I would not have the opportunity to do
'print context' at the wrong moment.)

Which passes and internal machinery GCC needs in order to fulfil these goals,
should be GCC internal. In other words, I specify '-ggdb' and expect GCC to do
the rest.

Additionally, Jakub Jelinek writes in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102523#c2 :
! sometimes -O0 -g is debuggable much better than -Og -g, sometimes the other
way around.
Which is not really a recommendation to use this option on a general basis.

[Bug sanitizer/112708] "gcc -fsanitize=address" produces wrong debug info for variables in function prologue

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112708

--- Comment #4 from Bruno Haible  ---
(In reply to Andrew Pinski from comment #1)
> Is this with or without optimization?

Since in step 5, I specified CFLAGS=-ggdb, it is without optimization.
(configure sets CFLAGS="-O2 -g" only if CFLAGS is not preset.)

[Bug sanitizer/112708] New: "gcc -fsanitize=address" produces wrong debug info for variables in function prologue

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112708

Bug ID: 112708
   Summary: "gcc -fsanitize=address" produces wrong debug info for
variables in function prologue
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bruno at clisp dot org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

As "gcc -fsanitize=address" finds several categories of memory related bugs,
I'm trying to use CC="gcc -fsanitize=address" everywhere. Unfortunately,
in the following case, a variable's value during a function prologue is
wrong when displayed by gdb. The value is displayed correctly when I don't
use the option -fsanitize=address. Which means that the culprit is gcc.

How to reproduce:
1. $ wget https://ftp.gnu.org/gnu/gettext/gettext-0.22.tar.xz
2. $ tar xf gettext-0.22.tar.xz
3. $ cd gettext-0.22
4. $ GCC13DIR=/some/directory/with/gcc-13.2.0
   $ PATH=$GCC13DIR/bin:$PATH
   Verify it:
   $ gcc --version
5. $ CC="gcc -fsanitize=address" CXX="g++ -fsanitize=address
-Wl,-rpath,$GCC13DIR/lib64" CFLAGS=-ggdb ./configure --disable-shared
6. $ make
7. $ cd gettext-tools/src
8. $ cat > foo.vala <<\EOF
primary_text.set_markup(
"%s".printf(_("Welcome
to Shotwell!")));
EOF
9.
$ gdb xgettext
GNU gdb (Ubuntu 12.1-0ubuntu1~22.04) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from xgettext...
(gdb) break xg-message.c:383
Breakpoint 1 at 0x41cad1: file xg-message.c, line 383.
(gdb) run -o - foo.vala
Starting program: /tmp/gettext-0.22/gettext-tools/src/xgettext -o - foo.vala
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, remember_a_message (mlp=0x60e00040, msgctxt=0x0,
msgid=0x60300a30 "Welcome to Shotwell!", is_utf8=true, pluralp=false,
context=..., pos=0x610004c0, extracted_comment=0x0, comment=0x0,
comment_is_utf8=false) at xg-message.c:383
383   set_format_flags_from_context (is_format, context, mp->msgid, pos,
"msgid");
(gdb) print context
$1 = {is_format1 = 3, pass_format1 = 0, is_format2 = 0, pass_format2 = 0,
is_format3 = 0, pass_format3 = 0, is_format4 = 0, pass_format4 = 0}
(gdb) step
set_format_flags_from_context (is_format=0x7fffc620, context=...,
string=0x60300a30 "Welcome to Shotwell!", pos=0x610004c0,
pretty_msgstr=0x6f0d40 "msgid") at xg-message.c:50
50 flag_context_ty context, const char
*string,
(gdb) print context
$2 = {is_format1 = 0, pass_format1 = 0, is_format2 = 2, pass_format2 = 0,
is_format3 = 5, pass_format3 = 0, is_format4 = 7, pass_format4 = 0}
(gdb) next
55if (context.is_format1 != undecided
(gdb) print context
$3 = {is_format1 = 3, pass_format1 = 0, is_format2 = 0, pass_format2 = 0,
is_format3 = 0, pass_format3 = 0, is_format4 = 0, pass_format4 = 0}

The variable 'context' is passed from xg-message.c:383 to
set_format_flags_from_context.
The value printed as $1 and $3 is correct.
The value printed as $2 is nonsense.

[Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534

--- Comment #3 from Bruno Haible  ---
(In reply to Andrew Pinski from comment #1)
> Hmm. similar issue happen with gdb 5 years ago:
> https://lists.gnu.org/archive/html/bug-gnulib/2018-08/msg00151.html

Thanks; this is helpful. In this thread we have the explanation
https://lists.gnu.org/archive/html/bug-gnulib/2018-08/msg00158.html, which
could maybe be the root cause of the problem here.

> Looks like this is huge gnulib mess at that.

This comment is not helpful.

1) As shown in the previous comment, max_align_t problems arise from the use of
-std=... options that are too old. We are in the year 2023, and it seems right
to use ISO C 11 features (from a 12 years old standard), no?

2) Gnulib actually works around two problems related to max_align_t, as
documented here:
https://www.gnu.org/software/gnulib/manual/html_node/stddef_002eh.html
Without Gnulib, you would encounter more problems related to max_align_t, not
fewer.

[Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534

Bruno Haible  changed:

   What|Removed |Added

 CC||bruno at clisp dot org

--- Comment #2 from Bruno Haible  ---
> gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC) 
> gcc -std=gnu99 ...
> error: unknown type name 'max_align_t'

The type 'max_align_t' exists in C11, but not in C99, as can be seen from these
uses of gcc 4.8.5:
$ cat foo.c
#include 
max_align_t x;
$ gcc -std=c11 -c foo.c
$ gcc -std=gnu11 -c foo.c
$ gcc -std=c99 -c foo.c
foo.c:2:1: error: unknown type name ‘max_align_t’
 max_align_t x;
 ^
$ gcc -std=gnu99 -c foo.c
foo.c:2:1: error: unknown type name ‘max_align_t’
 max_align_t x;
 ^

But this occurs in the build tree of gettext-runtime, and this package uses
AC_PROG_CC, which adds option -std=gnu11 if supported (this is in GNU Autoconf
since version 2.70).

Maybe some configure file was built with Autoconf 2.69 and older and thus does
not add -std=gnu11 ?

Or some other configure in the build tree has determined CC="gcc -std=gnu99",
and this setting has been propagated into gettext-runtime, overriding the
findings from gettext-runtime/configure ?

[Bug middle-end/112098] suboptimal optimization of inverted bit extraction

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112098

--- Comment #1 from Bruno Haible  ---
The code that gets executed inside gcc is maybe the one mentioned in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109907#c2 .

[Bug middle-end/112098] New: suboptimal optimization of inverted bit extraction

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112098

Bug ID: 112098
   Summary: suboptimal optimization of inverted bit extraction
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bruno at clisp dot org
  Target Milestone: ---

gcc optimizes quite well a bit extraction such as

-- foo.c --
unsigned int foo (unsigned int x)
{
  return (x & 0x200 ? 0x10 : 0);
}
---

$ gcc -O2 -S foo.c && cat foo.s
...
shrl$5, %eax
andl$16, %eax
...
That is perfect: 2 arithmetic instructions.

However, for the inverted bit extraction
== foo.c ==
unsigned int foo (unsigned int x)
{
  return (x & 0x200 ? 0 : 0x10);
}
===

the resulting code has 4 arithmetic instructions:

$ gcc -O2 -S foo.c && cat foo.s
...
shrl$9, %eax
xorl$1, %eax
andl$1, %eax
sall$4, %eax
...

Very clearly, the last shift instruction could be saved by transforming this
code to

...
shrl$5, %eax
xorl$16, %eax
andl$16, %eax
...

clang 16 even replaces the "xorl $16, %eax" instruction with a "notl %eax". So,
the optimal instruction sequence is one of
...
shrl$5, %eax
notl%eax
andl$16, %eax
...
or
...
notl%eax
shrl$5, %eax
andl$16, %eax
...

$ gcc --version
gcc (GCC) 13.2.0
Copyright (C) 2023 Free Software Foundation, Inc.

This is for x86_64. But similar optimization opportunities exist for other CPUs
as well.
For example, arm:

...
lsr r0, r0, #9
eor r0, r0, #1
and r0, r0, #1
lsl r0, r0, #4
...
which can be optimized to
...
lsr r0, r0, #5
eor r0, r0, #16
and r0, r0, #16
...

Or for sparc64:

...
and %o0, 512, %o0
cmp %g0, %o0
subx%g0, -1, %o0
sll %o0, 4, %o0
jmp %o7+8
 srl%o0, 0, %o0
...
which can be optimized to
...
xnor%g0, %o0, %o0
srl %o0, 5, %o0
jmp %o7+8
 and%o0, 16, %o0
...

[Bug middle-end/111904] Miscompilation with -O3 -fharden-control-flow-redundancy?

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111904

--- Comment #4 from Bruno Haible  ---
I've added your fix to gnulib:
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=f8ce7e779de156cb6d0fa51dbaef49cd255b7171

Thank you, Alexandre!

[Bug target/111814] on sh4, __builtin_nan* returns signalling NaNs instead of quiet NaNs and vice versa

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111814

--- Comment #2 from Bruno Haible  ---
Created attachment 56111
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56111=edit
test case for long double

[Bug target/111814] on sh4, __builtin_nan* returns signalling NaNs instead of quiet NaNs and vice versa

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111814

--- Comment #1 from Bruno Haible  ---
Created attachment 56110
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56110=edit
test case for double

[Bug target/111814] New: on sh4, __builtin_nan* returns signalling NaNs instead of quiet NaNs and vice versa

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111814

Bug ID: 111814
   Summary: on sh4, __builtin_nan* returns signalling NaNs instead
of quiet NaNs and vice versa
   Product: gcc
   Version: 11.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bruno at clisp dot org
  Target Milestone: ---

Created attachment 56109
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56109=edit
test case for float

The bit that distinguishes a quiet NaN from a signalling NaN is,
according to , the most
significant bit of the mantissa field.  This bit is
*  == 0 to indicate a quiet NaN or Infinity,
   == 1 to indicate a signalling NaN,
   on these CPUs: hppa, mips, sh4.
*  == 1 to indicate a quiet NaN,
   == 0 to indicate a signalling NaN or Infinity,
   on all other CPUs.

The statement regarding sh4 follows from the "SH-4 Software Manual"

page 143.

The GCC primitives __builtin_nan* get this wrong:
- __builtin_nanf, __builtin_nan, __builtin_nanl return a signalling
  NaN instead of a quiet NaN.
- __builtin_nansf, __builtin_nans, __builtin_nansl return a quiet
  NaN instead of a signalling NaN.

How to reproduce:

Compile and run the attached programs in the Linux/sh4 QEMU user-mode
environment. I use QEMU version 8.0.2.

$ sh4-linux-gnu-gcc-11 foof.c
$ ./a.out 
Bits: 32
Mantissa bits: 24
Min exponent: -125
Max exponent:  128
1.0 representation: 00 00 80 3F
1/3 representation: AB AA AA 3E
+Infinity representation:   00 00 80 7F
-Infinity representation:   00 00 80 FF
qNaN representation:FF FF BF 7F
gcc qNaN representation:00 00 C0 7F
gcc sNaN representation:00 00 A0 7F

$ sh4-linux-gnu-gcc-11 food.c
$ ./a.out 
Bits: 64
Mantissa bits: 53
Min exponent: -1021
Max exponent:  1024
1.0 representation: 00 00 00 00 00 00 F0 3F
1/3 representation: 55 55 55 55 55 55 D5 3F
+Infinity representation:   00 00 00 00 00 00 F0 7F
-Infinity representation:   00 00 00 00 00 00 F0 FF
qNaN representation:FF FF FF FF FF FF F7 7F
gcc qNaN representation:00 00 00 00 00 00 F8 7F
gcc sNaN representation:00 00 00 00 00 00 F4 7F

$ sh4-linux-gnu-gcc-11 fool.c
$ ./a.out 
Bits: 64
Mantissa bits: 53
Min exponent: -1021
Max exponent:  1024
1.0 representation: 00 00 00 00 00 00 F0 3F
1/3 representation: 55 55 55 55 55 55 D5 3F
+Infinity representation:   00 00 00 00 00 00 F0 7F
-Infinity representation:   00 00 00 00 00 00 F0 FF
qNaN representation:FF FF FF FF FF FF F7 7F
gcc qNaN representation:00 00 00 00 00 00 F8 7F
gcc sNaN representation:00 00 00 00 00 00 F4 7F

The row "qNaN representation" shows the value of 0.0 / 0.0, as computed
by QEMU. As you can see, it is consistent with the "SH-4 Software Manual"

page 143.

The values in the rows "gcc qNaN representation" and
"gcc sNaN representation" are wrong: The most significant bit
of the mantissa field (bit 22 or 51, respectively) is the opposite
of what it should be.

[Bug analyzer/111289] New: Unwarranted -Wanalyzer-va-arg-type-mismatch warning

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111289

Bug ID: 111289
   Summary: Unwarranted -Wanalyzer-va-arg-type-mismatch warning
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: bruno at clisp dot org
  Target Milestone: ---

Created attachment 55842
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55842=edit
test case foo.c

On the attached program, gcc 13.2.0 with analyzer produces a warning:

$ gcc -fanalyzer -O2 -S foo.c
foo.c: In function ‘do_open’:
foo.c:13:10: warning: ‘va_arg’ expected ‘mode_t’ {aka ‘unsigned int’} but
received ‘int’ for variadic argument 1 of ‘arg’ [CWE-686]
[-Wanalyzer-va-arg-type-mismatch]
   13 |   mode_t mode = va_arg (arg, mode_t);
  |  ^~~~
  ‘main’: events 1-2
|
|   20 | main ()
|  | ^~~~
|  | |
|  | (1) entry to ‘main’
|   21 | {
|   22 |   do_open ("nonexist.ent/", 0600);
|  |   ~~~
|  |   |
|  |   (2) calling ‘do_open’ from ‘main’ with 1 variadic argument
|
+--> ‘do_open’: events 3-4
   |
   |8 | do_open (char const *name, ...)
   |  | ^~~
   |  | |
   |  | (3) entry to ‘do_open’
   |..
   |   13 |   mode_t mode = va_arg (arg, mode_t);
   |  |  
   |  |  |
   |  |  (4) ‘va_arg’ expected ‘mode_t’ {aka ‘unsigned
int’} but received ‘int’ for variadic argument 1 of ‘arg’
   |

There is no reason to warn here, because
1) ISO C 99 § 7.15.1.1.(2) says "... the behavior is undefined, except for the
following cases:
— one type is a signed integer type, the other type is the corresponding
unsigned integer type, and the value is representable in both types;
— ..."
Likewise ISO C 23 § 7.16.1.1.(2).
2) The argument that gets passed is an 'int'. The other type, mode_t, is
'unsigned int'. The argument is a constant, and its value 0600 is representable
both as 'int' and as 'unsigned int'.

[Bug other/111288] formatting mistake in HTML documentation

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111288

--- Comment #4 from Bruno Haible  ---
My proposed patch is a correction to commit
2b4e0415ad664cdb3ce87d1f7eee5ca26911a05b by Jakub Jelinek.

> patches should be posted to gcc-patches@ after reading 
> https://gcc.gnu.org/contribute.html

I do have a copyright assigment for GCC in place. But I don't have time to
follow the entire procedure. Maybe someone else can take over, from this point?

[Bug other/111288] formatting mistake in HTML documentation

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111288

--- Comment #2 from Bruno Haible  ---
Created attachment 55841
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55841=edit
Rendering after applying the fix

[Bug other/111288] formatting mistake in HTML documentation

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111288

--- Comment #1 from Bruno Haible  ---
Created attachment 55840
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55840=edit
Rendering before applying the fix

[Bug other/111288] New: formatting mistake in HTML documentation

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111288

Bug ID: 111288
   Summary: formatting mistake in HTML documentation
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bruno at clisp dot org
  Target Milestone: ---

Created attachment 55839
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55839=edit
proposed fix

In https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html the
declarations of the last 6 functions are not well formatted: the highlighted
token is "int" or "long", not the name of the built-in.

The attached patch fixes it. I'm also attaching the rendering before and after
the patch is applied.

[Bug other/111287] New: doc: "strict ISO mode" definition is not up-to-date

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111287

Bug ID: 111287
   Summary: doc: "strict ISO mode" definition is not up-to-date
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bruno at clisp dot org
  Target Milestone: ---

In https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html
we read: "Outside strict ISO C mode (-ansi, -std=c90, -std=c99 or -std=c11)
..."

Nowadays, the options -std=c17 and -std=c2x also put gcc in "strict ISO C
mode", as can be seen from the __STRICT_ANSI__ preprocessor macro:

$ : | gcc -std=c90 -E -dM - | grep __STRICT_ANSI__
#define __STRICT_ANSI__ 1
$ : | gcc -std=c99 -E -dM - | grep __STRICT_ANSI__
#define __STRICT_ANSI__ 1
$ : | gcc -std=c11 -E -dM - | grep __STRICT_ANSI__
#define __STRICT_ANSI__ 1
$ : | gcc -std=c17 -E -dM - | grep __STRICT_ANSI__
#define __STRICT_ANSI__ 1
$ : | gcc -std=c2x -E -dM - | grep __STRICT_ANSI__
#define __STRICT_ANSI__ 1

Could this sentence in the manual be updated to include these new -std options?

[Bug libstdc++/110149] New: std::format for pointer arguments allows a '0' option

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110149

Bug ID: 110149
   Summary: std::format for pointer arguments allows a '0' option
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bruno at clisp dot org
  Target Milestone: ---

Created attachment 55275
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55275=edit
test case bug.cc

In C++ 20, a sign, a '#' option, and a '0' option are disallowed for
std::format strings with a pointer argument. The text has the same language for
all three:

In https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/n4950.pdf
§ 22.14.2.2 Standard format specifiers [format.string.std]
Paragraph 5: "The sign option is only valid for arithmetic types other than
charT and bool or when an integer presentation type is specified."
Paragraph 7: "The # option  This option is valid for arithmetic types other
than charT and bool or when an integer presentation type is specified, and not
otherwise."
Paragraph 8: "The 0 option is valid for arithmetic types other than charT and
bool or when an integer presentation type is specified."

Paragraph 21 specifies the available integer presentation types; 'p' is not one
of them, it is listed in paragraph 25 instead.

Therefore in the attached program bug.cc, an error should be signalled in line
28 and in line 29.

How to reproduce:
1)
$ g++ -Wall -std=gnu++20 bug.cc

2) Enable line 18 or line 19 or line 23 or line 24.
$ g++ -Wall -std=gnu++20 bug.cc


Note also that the '0' option cannot be part of a width specification, because
the width cannot start with '0'.

[Bug libstdc++/110143] std::format for pointer arguments does not work

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110143

--- Comment #4 from Bruno Haible  ---
(In reply to Jonathan Wakely from comment #2)
> Those are the pointer specializations that are supported, and you can't use
> them to format int*

I see. If 'int*' was supported as a "pointer" here, 'char*' would be as well,
creating an ambiguity.

> Cast to void* first.

Thanks. With such as cast, it works fine.

[Bug libstdc++/110143] std::format for pointer arguments does not work

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110143

--- Comment #1 from Bruno Haible  ---
Created attachment 55273
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55273=edit
test case bug2.cc

[Bug libstdc++/110143] New: std::format for pointer arguments does not work

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110143

Bug ID: 110143
   Summary: std::format for pointer arguments does not work
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bruno at clisp dot org
  Target Milestone: ---

Created attachment 55272
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55272=edit
test case bug1.cc

The C++20  facility (n4861.pdf section 20.20.2.2 paragraph 23 specifies
that pointers should be printable through std::format, either with no type
specifier, or with the type specifier 'p'.

Neither of these works with GCC 13.1.0.

How to reproduce:
Use the attached bug1.c and bug2.c files.

$ g++ -Wall -std=gnu++20 bug1.cc
In file included from bug1.cc:1:
/inst-gcc/13.1.0/include/c++/13.1.0/format: In instantiation of ‘class
std::__format::_Checking_scanner’:
/inst-gcc/13.1.0/include/c++/13.1.0/format:3642:4:   required from ‘consteval
std::basic_format_string<_CharT, _Args>::basic_format_string(const _Tp&) [with
_Tp = char [4]; _CharT = char; _Args = {int*}]’
bug1.cc:11:27:   required from here
/inst-gcc/13.1.0/include/c++/13.1.0/format:3564:10: error: static assertion
failed: std::formatter must be specialized for each type being formatted
 3564 | (is_default_constructible_v> && ...),
  |  ^~~~
/inst-gcc/13.1.0/include/c++/13.1.0/format:3564:10: note:
‘std::is_default_constructible_v >’ evaluates to
false
/inst-gcc/13.1.0/include/c++/13.1.0/format: In instantiation of ‘constexpr void
std::__format::_Checking_scanner<_CharT,
_Args>::_M_parse_format_spec(std::size_t) [with _Tp = int*; _OtherArgs = {};
_CharT = char; _Args = {int*}; std::size_t = long unsigned int]’:
/inst-gcc/13.1.0/include/c++/13.1.0/format:3581:33:   required from here
bug1.cc:11:27:   in ‘constexpr’ expansion of ‘std::basic_format_string("{:}")’
/inst-gcc/13.1.0/include/c++/13.1.0/format:3643:19:   in ‘constexpr’ expansion
of ‘__scanner.std::__format::_Checking_scanner::.std::__format::_Scanner::_M_scan()’
/inst-gcc/13.1.0/include/c++/13.1.0/format:3453:30:   in ‘constexpr’ expansion
of
‘((std::__format::_Scanner*)this)->std::__format::_Scanner::_M_on_replacement_field()’
/inst-gcc/13.1.0/include/c++/13.1.0/format:3505:15:   in ‘constexpr’ expansion
of
‘((std::__format::_Scanner*)this)->std::__format::_Scanner::_M_format_arg(__id)’
/inst-gcc/13.1.0/include/c++/13.1.0/format:3594:38: error: use of deleted
function ‘std::formatter<_Tp, _CharT>::formatter() [with _Tp = int*; _CharT =
char]’
 3594 |   formatter<_Tp, _CharT> __f;
  |  ^~~
/inst-gcc/13.1.0/include/c++/13.1.0/format:140:7: note: declared here
  140 |   formatter() = delete; // No std::formatter specialization for
this type.
  |   ^
/inst-gcc/13.1.0/include/c++/13.1.0/format:3595:42: error: ‘struct
std::formatter’ has no member named ‘parse’
 3595 |   this->_M_pc.advance_to(__f.parse(this->_M_pc));
  |  ^

$ g++ -Wall -std=gnu++20 bug2.cc
In file included from bug2.cc:1:
/inst-gcc/13.1.0/include/c++/13.1.0/format: In instantiation of ‘class
std::__format::_Checking_scanner’:
/inst-gcc/13.1.0/include/c++/13.1.0/format:3642:4:   required from ‘consteval
std::basic_format_string<_CharT, _Args>::basic_format_string(const _Tp&) [with
_Tp = char [5]; _CharT = char; _Args = {int*}]’
bug2.cc:11:27:   required from here
/inst-gcc/13.1.0/include/c++/13.1.0/format:3564:10: error: static assertion
failed: std::formatter must be specialized for each type being formatted
 3564 | (is_default_constructible_v> && ...),
  |  ^~~~
/inst-gcc/13.1.0/include/c++/13.1.0/format:3564:10: note:
‘std::is_default_constructible_v >’ evaluates to
false
/inst-gcc/13.1.0/include/c++/13.1.0/format: In instantiation of ‘constexpr void
std::__format::_Checking_scanner<_CharT,
_Args>::_M_parse_format_spec(std::size_t) [with _Tp = int*; _OtherArgs = {};
_CharT = char; _Args = {int*}; std::size_t = long unsigned int]’:
/inst-gcc/13.1.0/include/c++/13.1.0/format:3581:33:   required from here
bug2.cc:11:27:   in ‘constexpr’ expansion of ‘std::basic_format_string("{:p}")’
/inst-gcc/13.1.0/include/c++/13.1.0/format:3643:19:   in ‘constexpr’ expansion
of ‘__scanner.std::__format::_Checking_scanner::.std::__format::_Scanner::_M_scan()’
/inst-gcc/13.1.0/include/c++/13.1.0/format:3453:30:   in ‘constexpr’ expansion
of
‘((std::__format::_Scanner*)this)->std::__format::_Scanner::_M_on_replacement_field()’
/inst-gcc/13.1.0/include/c++/13.1.0/format:3505:15:   in ‘constexpr’ expansion
of
‘((std::__format::_Scanner*)this)->std::__format::_Scanner::_M_format_arg(__id)’
/inst-gcc/13.1.0/include/c++/13.1.0/format:3594:38: error: use of 

[Bug analyzer/110112] [11/12/13 Regression] gcc -fanalyzer takes an excessive amount of time

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110112

Bruno Haible  changed:

   What|Removed |Added

   Host||x86_64-linux-gnu
  Known to fail||11.3.0, 12.3.0, 13.1.0
  Known to work||10.4.0
  Build||x86_64-linux-gnu
 Target||x86_64-linux-gnu

--- Comment #1 from Bruno Haible  ---
Compilation times with various gcc versions, with -O2 -fanalyzer:

gcc 13.1.0: 66 sec
gcc 12.3.0: 66 sec
gcc 11.3.0: 52 sec
gcc 10.4.0: 0.9 sec

[Bug analyzer/110112] New: [11/12/13 Regression] gcc -fanalyzer takes an excessive amount of time

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110112

Bug ID: 110112
   Summary: [11/12/13 Regression] gcc -fanalyzer takes an
excessive amount of time
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: bruno at clisp dot org
  Target Milestone: ---

Created attachment 55253
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55253=edit
test case uniname.c (compressed)

In a compilation unit with some large read-only static arrays, "gcc -fanalyzer"
takes an excessive amount of time: 66 seconds as opposed to less than 1 second
without '-fanalyzer'.

How to reproduce:
$ time gcc -O2 -c uniname.c 

real0m0,819s
user0m0,797s
sys 0m0,012s

$ time gcc -O2 -fanalyzer -c uniname.c 


real1m6,195s
user1m6,101s
sys 0m0,088s

[Bug ipa/109914] --suggest-attribute=pure misdiagnoses static functions

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109914

--- Comment #3 from Bruno Haible  ---
(In reply to Jan Hubicka from comment #2)
> The reason why gcc warns is that it is unable to prove that the function is
> always finite. This means that it can not auto-detect pure attribute since
> optimizing the call out may turn infinite program to finite one. 
> So adding the attribute would still help compiler to know that the loops are
> indeed finite.

Thanks for explaining. So, the warning asks the developer not only to add an
__attribute__((__pure__)) marker, but also to verify that the function
terminates. In this case, it does, but it took me a minute of reflection to
convince myself.

For what purpose shall the developer make this effort? The documentation
https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gcc/Common-Function-Attributes.html
says that it's to allow the compiler to do common subexpression elimination.
But in this case, the compiler could easily find out that it cannot do common
subexpression elimination anyway, because:
  - The only caller of this function (have_xattr) is file_has_acl.
  - In this function, there are three calls to have_xattr.
  - Each of them is executed only at most once. Control flow analysis shows
this.
  - Each of them has different argument lists: The first argument is a string
literal in each case, namely "system.nfs4_acl", "system.posix_acl_access",
"system.posix_acl_default" respectively.
So, there is no possibility for common subexpression elimination here, even if
the function was marked "pure".

Therefore it is pointless to suggest to the developer that it would be a gain
to mark the function as "pure" and that it is worth spending brain cycles on
that.

[Bug middle-end/109995] New: Bogus warning about __builtin_memset, from -Wstringop-overflow

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109995

Bug ID: 109995
   Summary: Bogus warning about __builtin_memset, from
-Wstringop-overflow
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bruno at clisp dot org
  Target Milestone: ---

Created attachment 55171
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55171=edit
test case bar.c

In the attached program, -Wall produces a warning "warning: ‘__builtin_memset’
specified bound 18446744073709551614 exceeds maximum object size
9223372036854775807 [-Wstringop-overflow=]", in a function that does not invoke
'memset' nor '__builtin_memset'.

With gcc 10.4.0:
$ gcc -O2 -Wall -S bar.c
In function ‘memset_small’,
inlined from ‘wrap’ at bar.c:242:1:
bar.c:249:17: warning: ‘__builtin_memset’ specified bound 18446744073709551614
exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]
  249 | do *++p = c; while (--n > 0);
  |~^~~

With gcc 11.3.0, 12.3.0, 13.1.0:
$ gcc -O2 -Wall -S bar.c
In function ‘memset_small’,
inlined from ‘memset_small’ at bar.c:242:1,
inlined from ‘wrap’ at bar.c:590:19:
bar.c:249:17: warning: ‘__builtin_memset’ specified bound 18446744073709551614
exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]
  249 | do *++p = c; while (--n > 0);
  |~^~~

[Bug middle-end/109990] [12/13/14 Regression] Bogus -Wuse-after-free warning after realloc

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109990

--- Comment #5 from Bruno Haible  ---
Created attachment 55170
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55170=edit
test case bar2.c

Find attached a modified test case. I changed the code to

  map[i].alias = new_pool + (map[i].alias -
string_space);
  map[i].value = new_pool + (map[i].value -
string_space);

so that it subtracts pointers into the old string_space, producing an integer,
and adding that integer to new_pool.

It produces the same warning (even twice, apparently because there is no common
subexpression between the two lines any more):

$ gcc -Wall -O2 -S bar2.c
bar2.c: In function ‘read_alias_file’:
bar2.c:123:67: warning: pointer may be used after ‘realloc’ [-Wuse-after-free]
  123 |   map[i].value = new_pool + (map[i].value -
string_space);
  |
~~^~~
bar2.c:114:45: note: call to ‘realloc’ here
  114 |   char *new_pool = (char *) realloc (string_space,
new_size);
  |
^~~~
bar2.c:122:67: warning: pointer may be used after ‘realloc’ [-Wuse-after-free]
  122 |   map[i].alias = new_pool + (map[i].alias -
string_space);
  |
~~^~~
bar2.c:114:45: note: call to ‘realloc’ here
  114 |   char *new_pool = (char *) realloc (string_space,
new_size);
  |
^~~~

[Bug middle-end/109990] [12/13/14 Regression] Bogus -Wuse-after-free warning after realloc

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109990

--- Comment #4 from Bruno Haible  ---
> > 
> >   char *new_pool = (char *) realloc (string_space, 
> > new_size);
> >   if (new_pool == ((void *)0))
> > goto out;
> >   if (__builtin_expect (string_space != new_pool, 0))
> > {
> >   size_t i;
> >   for (i = 0; i < nmap; i++)
> > {
> >   map[i].alias += new_pool - string_space;
> >   map[i].value += new_pool - string_space;
> > }
> > }
> >   string_space = new_pool;

> Also I think `new_pool - string_space` is undefined really.  That is
> subtracting two unrelated arrays is undefined. You can only compare equality
> on them.

That is the only way of keeping track of pointers _into_ the string_space area,
when it is reallocated. How else would you want to do it?

[Bug middle-end/109990] New: [12 Regression] Bogus -Wuse-after-free warning after realloc

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109990

Bug ID: 109990
   Summary: [12 Regression] Bogus -Wuse-after-free warning after
realloc
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bruno at clisp dot org
  Target Milestone: ---

Created attachment 55168
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55168=edit
test case bar.c

Compiling the attached file produces a warning that is not justified:

$ gcc -Wall -O2 -S bar.c
bar.c: In function ‘read_alias_file’:
bar.c:122:52: warning: pointer may be used after ‘realloc’ [-Wuse-after-free]
  122 |   map[i].alias += new_pool - string_space;
  |   ~^~
bar.c:114:45: note: call to ‘realloc’ here
  114 |   char *new_pool = (char *) realloc (string_space,
new_size);
  |
^~~~

The warning is not justified because only the pointer 'string_space' is used
here; it is not being dereferenced.

Seen with gcc 12.3.0 and 13.1.0.

[Bug ipa/109916] New: warning reported despite of "#pragma GCC diagnostic ignored", due to -flto

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109916

Bug ID: 109916
   Summary: warning reported despite of "#pragma GCC diagnostic
ignored", due to -flto
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bruno at clisp dot org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 55127
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55127=edit
test case sources s.tar.xz

When adding option '-flto' to the gcc command line, diagnostics that are
ordinarily suppressed through "#pragma GCC diagnostic ignored ..." get reported
nevertheless.

How to reproduce:
1. Unpack the attached sources s.tar.xz.
$ gcc --version
gcc (GCC) 13.1.0
...
$ gcc -Wmaybe-uninitialized -O2 s/*.c -o cut

$ gcc -Wmaybe-uninitialized -O2 s/*.c -o cut -flto
In function ‘getndelim2’,
inlined from ‘cut_fields’ at s/cut.c:5185:17:
s/getndelim2.c:2015:23: warning: ‘c’ may be used uninitialized
[-Wmaybe-uninitialized]
 2015 | *read_pos = c;
  |   ^
s/getndelim2.c: In function ‘cut_fields’:
s/getndelim2.c:1934:11: note: ‘c’ was declared here
 1934 |   int c;
  |   ^

[Bug ipa/109915] New: --suggest-attribute=const misdiagnoses static functions

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109915

Bug ID: 109915
   Summary: --suggest-attribute=const misdiagnoses static
functions
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bruno at clisp dot org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 55126
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55126=edit
test case date.c

GCC's --suggest-attribute=const diagnoses static functions, even though the
'const' attribute is useless for static functions (after all, the compiler has
deduced the property on its own). This is leading to my having to litter code
with '__attribute__ (const)' declarations merely to pacify GCC. GCC should
treat the 'const' attribute like other attributes (e.g., malloc, pure), and
should issue the diagnostic only for non-static functions where the attribute
is in fact useful.

How to reproduce:
$ gcc --version
gcc (GCC) 13.1.0
...
$ gcc -ftrapv -Wsuggest-attribute=pure -O2 -S date.c
date.c: In function ‘res_width’:
date.c:5658:12: warning: function might be candidate for attribute ‘const’ if
it is known to return normally [-Wsuggest-attribute=const]
 5658 | static int res_width (long int res)
  |^

[Bug ipa/109914] New: --suggest-attribute=pure misdiagnoses static functions

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109914

Bug ID: 109914
   Summary: --suggest-attribute=pure misdiagnoses static functions
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bruno at clisp dot org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 55125
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55125=edit
test case

GCC's --suggest-attribute=pure diagnoses static functions, even though the
'pure' attribute is useless for static functions (after all, the compiler has
deduced the property on its own). This is leading to my having to litter code
with '__attribute__ (pure)' declarations merely to pacify GCC. GCC should treat
the 'pure' attribute like other attributes (e.g., malloc, const), and should
issue the diagnostic only for non-static functions where the attribute is in
fact useful.

How to reproduce:
$ gcc --version
gcc (GCC) 13.1.0
...
$ gcc -Wsuggest-attribute=pure -O2 -S file-has-acl.c
file-has-acl.c: In function ‘have_xattr’:
file-has-acl.c:3385:14: warning: function might be candidate for attribute
‘pure’ if it is known to return normally [-Wsuggest-attribute=pure]
 3385 | static _Bool have_xattr (char const *attr, char const *listbuf, ssize_t
listsize)
  |  ^~

[Bug c/109155] New: A note is diagnosed, without any warning or error

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109155

Bug ID: 109155
   Summary: A note is diagnosed, without any warning or error
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bruno at clisp dot org
  Target Milestone: ---

Created attachment 54682
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54682=edit
test case

In this test case, the compiler emits a 'note', without any 'warning' or
'error'.

$ gcc -Wall -S i.c
i.c: In function ‘main’:
i.c:2:35: note: ‘s’ declared here
2 | struct s { _Bool s: 1; _Bool t; } s;
  |   ^

Which leaves me, as the user, completely baffled.

This is new in version 12. In versions 11 and older, no diagnostic is emitted.

[Bug c/108694] need a new warning option for preparing migration to ISO C 23

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108694

--- Comment #4 from Bruno Haible  ---
(In reply to Aaron Ballman from comment #3)
OK. So, except for this unlucky (*) choice of attribution in case of a conflict
between function declaration and function definition, the
'-Wdeprecated-non-prototype' warning is actually usable.

What we need is thus:
* -Wdeprecated-non-prototype,
* combined with a kind of -Wfuture-incompatible-function-pointer-types, that
considers the interpretation according to C23 instead of the interpretation
according to the currently chosen standard.

(*) Reported as a clang bug at
https://github.com/llvm/llvm-project/issues/60592 .

[Bug c/108694] need a new warning option for preparing migration to ISO C 23

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108694

--- Comment #2 from Bruno Haible  ---
(In reply to Florian Weimer from comment #1)
> “()” is going to be fine when matched with an empty parameter list in a
> definition, or an empty argument list in a call. I don't think it's
> necessary to warn in those cases. It distracts from the real issue.

OK. So let's see what we get with this approach where 'void func3 ();' doesn't
warn and only the wrong uses of func3 produce diagnostics. Here's a test case,
annotated with 'error' in those places where 'clang15 -std=c2x' produces an
error:

=
/* Function definitions: */
void func1 () {}
void func2 (void) {}
/* Function declarations: */
void func3 ();
void func4 (void);

void code ()
{
  void (*fp) (void);
  void (*fp1) (int);

  fp = func1;
  fp = func2;
  fp = func3;
  fp = func4;

  fp1 = func3;

  func1 (1); /* error */
  func2 (2); /* error */
  func3 (3); /* error */
  func4 (4); /* error */

  (void) fp;
  (void) fp1;
}

void func3 (int x, int y) {} /* error */
=

When compiling this in -std=c17 or older mode, we would like to get a warning
- in those places where we get an error in C23 mode, and
- in those places where there are unsafe conversions or parameter passing going
on in C23 or in C17 or older.
In detail, the desired behaviour in -std=c17 or older mode is:

=
/* Function definitions: */
void func1 () {} /* No warning */
void func2 (void) {} /* No warning */
/* Function declarations: */
void func3 (); /* No warning */
void func4 (void); /* No warning */

void code ()
{
  void (*fp) (void);
  void (*fp1) (int);

  fp = func1; /* No warning */
  fp = func2; /* No warning */
  fp = func3; /* No warning */
  fp = func4; /* No warning */

  fp1 = func3; /* warning */

  func1 (1); /* warning (if -std=c17) or error (if -std=c23) */
  func2 (2); /* error */
  func3 (3); /* warning (if -std=c17) or error (if -std=c23) */
  func4 (4); /* error */

  (void) fp;
  (void) fp1;
}

void func3 (int x, int y) {} /* warning (if -std=c17) or error (if -std=c23) */
=

In the line 'fp1 = func3;' a warning should be shown because it's an unsafe
function pointer conversion in C23. (Even though in C17 it is not dangerous
code and even though in C23 it's not an error!) 'clang15 -std=c2x
-Wincompatible-function-pointer-types' does show a "warning: incompatible
function pointer types" there.

> Clang now has -Wdeprecated-non-prototype apparently

But '-Wdeprecated-non-prototype' does not exactly have the behaviour you want:
while it warns for 'func1 (1);' and 'func3 (3);' (good!), it warns also for
'void func3 ();', that is, where you don't want to see a warning.

So, no existing GCC or clang warning option has the desired behaviour. What we
need (and even independently of programming style) is
* a part of -Wdeprecated-non-prototype: do warn in function call positions,
don't warn in function declaration/type positions,
* combined with a kind of -Wfuture-incompatible-function-pointer-types, that
considers the interpretation according to C23 instead of the interpretation
according to the currently chosen standard.

[Bug c/108694] New: need a new warning option for preparing migration to ISO C 23

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108694

Bug ID: 108694
   Summary: need a new warning option for preparing migration to
ISO C 23
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bruno at clisp dot org
  Target Milestone: ---

The use of () to denote an unknown or varargs parameter list in function
declarations and function types, a language feature from K C, is finally
disallowed in ISO C 23. Instead, () as a parameter list denotes a list of zero
arguments, the same as (void), in ISO C 23.

The set of warnings that were added to GCC over the years, regarding function
prototypes, were designed at a time when the migration target was still
unknown. Now that the migration target, ISO C 23, is known, some projects want
to have the following programming style, for code that compiles OK both in C99
and C23:
- (1) In function definitions, use () to denote argument lists with zero
arguments.
- (2) In function declarations and function types, use (void) to denote
argument lists with zero arguments.
See https://lists.gnu.org/archive/html/bug-gnulib/2023-02/msg00055.html and
https://lists.gnu.org/archive/html/bug-gnulib/2023-02/msg00062.html for details
of the rationale.

As a programmer, I would like to have an easy way to get warnings when this
programming style is not followed.

There are two ways such a warning could be added to GCC:

(A) A warning that applies when compiling for a language standard older than
C23 (e.g. -std=gnu99).

In which situations would this warning be emitted?
=
/* Function definitions: */
void func1 () {} /* No warning */
void func2 (void) {} /* No warning */
/* Function declarations: */
void func3 (); /* warning: an empty parameter list in function declarators will
have a different meaning in ISO C23 */
void func4 (void); /* No warning */
=

Looking through the existing warning options of GCC and clang:

Warning options from https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
Option  Not adequate because ...
--- 
-Wall   Does not warn for func3.
-Wstrict-prototypes Warns for func1 as well.
-Wold-style-declaration Does not warn for func3.
-Wold-style-definition  Does not warn for func3. Warns for func1.
-Wmissing-prototypesDoes not warn for func3. Warns for func1 and func2.
-Wmissing-declarations  Does not warn for func3. Warns for func1 and func2.
-Wpedantic  Does not warn for func3.

Warning options from https://clang.llvm.org/docs/DiagnosticsReference.html
Option  Not adequate because ...
--- 
-Wall   Does not warn for func3.
-Wdeprecated-declarations   Does not warn for func3.
-Wdeprecated-non-prototype  Does not warn for func3.
-Wmissing-prototypesDoes not warn for func3. Warns for func1 and func2.
-Wpedantic  Warns for func1 as well.

So, none of these existing warning options fits the need. A new warning option
is needed.

(B) A warning that applies when compiling for C23 (e.g. -std=gnu23).

The situations would be the same as above. Only the diagnostic's message would
refer to *older* standard versions, such as:
=
/* Function definitions: */
void func1 () {} /* No warning */
void func2 (void) {} /* No warning */
/* Function declarations: */
void func3 (); /* warning: an empty parameter list in function declarators
denotes a varargs parameter list in ISO C17 and older; use (void) to
disambiguate */
void func4 (void); /* No warning */
=

[Bug c++/108231] New: g++ mistakenly reports ambiguity between equivalent function declarations

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108231

Bug ID: 108231
   Summary: g++ mistakenly reports ambiguity between equivalent
function declarations
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bruno at clisp dot org
  Target Milestone: ---

Created attachment 54156
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54156=edit
test case

The attached code, i1.cc, contains two equivalent function declarations for the
function 'free'. They are equivalent because they have the same signature and
both have "C" linkage.

In lines 9, 10, 12, 13, referencing the function 'free' works fine.

However, referencing it in line 17, as part of a
__attribute__ ((__malloc__ (free, 1)))
attribute, leads to an error "‘malloc’ attribute argument 1 is ambiguous".

I would expect no error, no warning.

How to reproduce:
$ g++ -S i1.cc
i1.cc:17:67: error: ‘malloc’ attribute argument 1 is ambiguous
   17 | __attribute__ ((__malloc__)) __attribute__ ((__malloc__ (free, 1)));
  |   ^
i1.cc:17:67: note: use a cast to the expected type to disambiguate

[Bug other/105527] configure option --with-zstd is not documented

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105527

--- Comment #3 from Bruno Haible  ---
Created attachment 52955
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52955=edit
Patch to document also --with-zstd-include and --with-zstd-lib

Hi Martin,

The patch you added is pretty minimal: it refers to undocumented options
--with-zstd-include and --with-zstd-lib; it suggests that --with-zstd can be
used without an argument; and it does not clarify how this option applies to
cross-compilation.

How about adding the same details as for the --with-isl, --with-isl-include,
--with-isl-lib options, mutatis mutandis? Find attached a patch that does that.

[Bug other/105527] New: configure option --with-zstd is not documented

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105527

Bug ID: 105527
   Summary: configure option --with-zstd is not documented
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bruno at clisp dot org
  Target Milestone: ---

A GCC 12.1.0 build of mine is failing with the error messages

/usr/lib/gcc-cross/i686-linux-gnu/10/../../../../i686-linux-gnu/bin/ld:
/build-loongarch64-linux/gcc-12.1.0/gcc/../../../../sources/gcc-12.1.0/gcc/lto-compress.cc:170:
undefined reference to `ZSTD_isError'
/usr/lib/gcc-cross/i686-linux-gnu/10/../../../../i686-linux-gnu/bin/ld:
/build-loongarch64-linux/gcc-12.1.0/gcc/../../../../sources/gcc-12.1.0/gcc/lto-compress.cc:171:
undefined reference to `ZSTD_getErrorName'
collect2: error: ld returned 1 exit status
make: *** [/sources/gcc-12.1.0/gcc/c/Make-lang.in:87: cc1] error 1

Obviously, the ZStd prerequisite is missing. The documentation (in
gcc-12.1.0/gcc/doc/gccinstall.info and in
https://gcc.gnu.org/install/prerequisites.html) merely says "Alternatively, the
--with-zstd configure option should be used." But what is its argument?

I would expect to see this documented
1. in gcc-12.1.0/gcc/doc/gccinstall.info node "Configuration",
2. also in https://gcc.gnu.org/install/configure.html.

The only hint I can get is by running "gcc-12.1.0/gcc/configure --help", which
prints

  --with-zstd=PATHspecify prefix directory for installed zstd library.
  Equivalent to --with-zstd-include=PATH/include plus
  --with-zstd-lib=PATH/lib
  --with-zstd-include=PATH
  specify directory for installed zstd include files
  --with-zstd-lib=PATHspecify directory for the installed zstd library

This text gives the answer. It should be added to the .texi documentation.

[Bug tree-optimization/101494] -Wmaybe-uninitialized false alarm with memrchr of size 0

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101494

Bruno Haible  changed:

   What|Removed |Added

 CC||bruno at clisp dot org

--- Comment #1 from Bruno Haible  ---
It's a regression, since GCC 10.3.0 does not produce a warning here.

[Bug middle-end/30267] folding (~ -x) >= (-2147483647-1) to x != -2147483648

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30267

Bruno Haible  changed:

   What|Removed |Added

  Known to work||10.3.0, 11.1.0, 6.5.0,
   ||7.5.0, 8.4.0, 9.3.0
  Known to fail||4.9.4, 5.5.0

--- Comment #4 from Bruno Haible  ---
(In reply to Andrew Pinski from comment #3)
> Fixed with at least GCC 7.
> It was still broken in GCC 4.8.5 though.

Indeed. Here's the status with GCC versions since 4.0.x:

4.0.4 optimized
4.1.2 missed
4.2.4 missed
4.3.6 missed
4.4.7 missed
4.5.4 missed
4.6.4 missed
4.7.3 missed
4.8.5 missed
4.9.4 missed
5.5.0 missed
6.5.0 optimized
7.5.0 optimized
8.4.0 optimized
9.3.0 optimized
10.3.0 optimized
11.1.0 optimized

[Bug other/100735] -fno-trampolines doc wrongly implies it affects C, C++ etc.

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100735

Bruno Haible  changed:

   What|Removed |Added

 CC||bruno at clisp dot org

--- Comment #1 from Bruno Haible  ---
(In reply to Paul Eggert from comment #0)
> it is silently ignored for these languages, and I assume for any language
> other than Ada.

Confirmed: flag_trampolines matters only for calls with the ECF_BY_DESCRIPTOR
bit set or CALL_EXPR_BY_DESCRIPTOR being true. Other than from the Ada backend,
such calls are generated only from gimple nodes with subcode bit
GF_CALL_BY_DESCRIPTOR set. GF_CALL_BY_DESCRIPTOR gets set through
gimple_call_set_by_descriptor with argument true, and such calls exist only as
consequence of tree nodes with CALL_EXPR_BY_DESCRIPTOR being true.

[Bug target/51793] pragma GCC optimize wrapv leads to invalid code on Solaris

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51793

--- Comment #4 from Bruno Haible  ---
Correction to comment #3:
It works fine on
- Solaris 11.4 (gcc 7.3.0): foo.s contains '.p2align 4,,15'
- Solaris 11 OpenIndiana (gcc 7.2.0): likewise
- Solaris 11 OmniOS (gcc 9.3.0): foo.s contains '.p2align 4'

Consistently with what we see on Linux.

[Bug target/51793] pragma GCC optimize wrapv leads to invalid code on Solaris

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51793

Bruno Haible  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to fail||4.5.4, 4.6.4, 4.7.3, 4.8.5,
   ||4.9.4
  Known to work||10.3.0, 11.1.0, 5.5.0,
   ||6.5.0, 7.5.0, 8.4.0, 9.3.0
 Resolution|--- |FIXED

--- Comment #3 from Bruno Haible  ---
It works fine on
- Solaris 11.4 (gcc 7.3.0): foo.s contains '.p2align 4,,15'
- Solaris 11 OpenIndiana (gcc 7.2.0): likewise
- Solaris 11 OmniOS (gcc 9.3.0): foo.s does not contain .p2align directives any
more

More details by testing various versions on i386-pc-linux-gnu:

4.5.4 -> .p2align 4,,-1
4.6.4 -> .p2align 4,,-1
4.7.3 -> .p2align 4,,-1
4.8.5 -> .p2align 4,,-1
4.9.4 -> .p2align 4,,-1
5.5.0 -> no .p2align any more
6.5.0 -> .p2align 4,,15
7.5.0 -> .p2align 4,,15
8.4.0 -> .p2align 4,,15
9.3.0 -> .p2align 4
10.3.0 -> .p2align 4
11.1.0 -> .p2align 4

In summary, it appears to be fixed since GCC version 5.x.

[Bug middle-end/98396] gcc wrongly assumes that free preserves errno

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98396

--- Comment #4 from Bruno Haible  ---
(In reply to Richard Biener from comment #3)
> But note that while free() may clobber errno the state after it is undefined
> (it's not documented to set it to any specific value).  So I'd argue the
> check_errno_unmodified testcase is not really relevant.

The state of errno after calling free() is not "undefined", it is
"unspecified". See the POSIX citation in the description. See also the
definition of "undefined behavior" and "unspecified behavior" in ISO C 2018 §
3.4.3 and § 3.4.4.

The test case 'check_errno_unmodified' is therefore perfectly valid with glibc
versions newer than 2020-12-29 (where
https://sourceware.org/bugzilla/show_bug.cgi?id=17924 is fixed). In these glibc
versions glibc gives the guarantee that free() does not clobber errno.

If you (the GCC people) don't want to make this test case work unconditionally,
you at least need to tell in which way the free() declaration in glibc's
 needs to be modified, so that the test case will work in these newer
versions of glibc.

[Bug c/98396] gcc wrongly assumes that free preserves errno

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98396

Bruno Haible  changed:

   What|Removed |Added

  Known to work||4.0.4, 4.1.2, 4.2.4, 4.3.6,
   ||4.4.7, 4.5.4, 4.6.4, 4.7.3,
   ||4.8.5
  Known to fail||10.2.0, 4.9.4, 5.5.0,
   ||6.5.0, 7.5.0, 8.4.0, 9.3.0
 Target||x86_64-pc-linux-gnu
  Build||x86_64-pc-linux-gnu
   Host||x86_64-pc-linux-gnu

--- Comment #1 from Bruno Haible  ---
Related: bug 88576, bug 98070.

[Bug c/98396] New: gcc wrongly assumes that free preserves errno

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98396

Bug ID: 98396
   Summary: gcc wrongly assumes that free preserves errno
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bruno at clisp dot org
  Target Milestone: ---

Created attachment 49808
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49808=edit
Test case

On POSIX systems, free() can clobber the value of errno. This is implied by
1) https://pubs.opengroup.org/onlinepubs/9699919799/functions/errno.html
which says: "The setting of errno after a successful call to a function is
unspecified unless the description of that function specifies that errno shall
not be modified."
and 2) https://pubs.opengroup.org/onlinepubs/9699919799/functions/free.html
which does not mention errno.

A future version of POSIX will specify that a valid call to free() preserves
errno: https://www.austingroupbugs.net/view.php?id=385 . But this is not yet
standard.

In particular, on Linux/glibc systems, the glibc bug
https://sourceware.org/bugzilla/show_bug.cgi?id=17924 is still open, because
glibc does not guarantee that free() preserves errno — neither through the code
nor through the documentation. This glibc bug even has a test case of a
successful free() that sets errno to ENOMEM (via a call to munmap).

But GCC, when optimizing, eliminates tests of errno or assignments to errno
after 'free (ptr);' where ptr was the result of a malloc(...) call in the same
function.

How to reproduce:
$ gcc -O2 -S foo.c
Inspect the resulting foo.s. You see that
- In function 'check_errno_unmodified', GCC has eliminated the lines
  if (errno != 1789)
abort ();
- In function 'ensure_errno_unmodified', GCC has eliminated the lines
  int saved_errno = errno;
  and
  errno = saved_errno;
  So, while the programmer knew that free() can clobber errno and added
statements to ensure that errno gets preserved, GCC optimized these statements
away!

[Bug sanitizer/98165] Use of the UB sanitizer links the the program with libstdc++

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98165

Bruno Haible  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Bruno Haible  ---
Thank you. The option '-static-libubsan' indeed has the effect I was looking
for.

[Bug sanitizer/98165] Use of the UB sanitizer links the the program with libstdc++

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98165

--- Comment #1 from Bruno Haible  ---
Created attachment 49691
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49691=edit
Test case

[Bug sanitizer/98165] New: Use of the UB sanitizer links the the program with libstdc++

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98165

Bug ID: 98165
   Summary: Use of the UB sanitizer links the the program with
libstdc++
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bruno at clisp dot org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

I would like to use the 'signed-integer-overflow' sanitizer (part of the
undefined behaviour sanitizer) for all my C programs, as a security measure.

However, doing so with GCC causes a link dependency towards libstdc++:

$ gcc -Wall -fsanitize=signed-integer-overflow foo.c
$ ldd ./a.out
linux-vdso.so.1 (0x7ffc73977000)
libubsan.so.1 => /lib/x86_64-linux-gnu/libubsan.so.1
(0x7fbec9aa)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fbec98b6000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fbec98b)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x7fbec988e000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6
(0x7fbec96ad000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x7fbec9692000)
/lib64/ld-linux-x86-64.so.2 (0x7fbeca42a000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fbec9541000)

I don't want this, because libstdc++ increases the startup time of programs
(from ca. 2 ms to ca. 7 ms).

This is with gcc 10.2.0. With clang 11.0.0, I don't have this problem:

$ clang -fsanitize=signed-integer-overflow foo.c
$ ldd ./a.out 
linux-vdso.so.1 =>  (0x7fffc25e3000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x7f5fc1486000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f5fc127e000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f5fc0f75000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f5fc0d71000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x7f5fc0b5b000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f5fc0791000)
/lib64/ld-linux-x86-64.so.2 (0x7f5fc16a3000)

[Bug driver/98162] New: Documentation mentions non-existent option -mcet

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98162

Bug ID: 98162
   Summary: Documentation mentions non-existent option -mcet
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bruno at clisp dot org
  Target Milestone: ---

The documentation page
https://gcc.gnu.org/onlinedocs/gcc/x86-Built-in-Functions.html mentions "The
following built-in functions are available when -mcet or -mshstk option is
used."

But an option '-mcet' is not documented (see
https://gcc.gnu.org/onlinedocs/gcc/Option-Index.html) and not implemented
either:

$ gcc -S -O2 a.c -mcet -fcf-protection
gcc: error: unrecognized command-line option '-mcet'

[Bug tree-optimization/91029] missed optimization regarding value of modulo operation

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91029

--- Comment #8 from Bruno Haible  ---
> what is the reason to require that b >= 0 in all of this?

In the 1990ies there were portability problems with a%b, b < 0. ANSI C said
that the result was machine-dependent if a < 0 or b < 0. Fortunately the result
is formally specified now, since ISO C 99.

You're right: Since GCC emits the instructions for the % operation, and
supposedly in compliance with ISO C and ISO C++, it can assume that negative
operands behave as specified.

> So, shouldn't the rules be

Yes, these 4 rules look correct.

[Bug tree-optimization/91029] missed optimization regarding value of modulo operation

[bruno at clisp dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91029

--- Comment #5 from Bruno Haible  ---
Nice! Thank you.