[Bug c++/108245] ICE with invalid variable auto arguments and supplying an extra type

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||lyubomir.filipov at amusnet 
dot co
   ||m

--- Comment #5 from Andrew Pinski  ---
*** Bug 108302 has been marked as a duplicate of this bug. ***

[Bug c++/108302] void fn (uint8_t auto... args); leads to internal compiler error: Segmentation fault

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #2 from Andrew Pinski  ---
Dup of bug 108245.

*** This bug has been marked as a duplicate of bug 108245 ***

[Bug c++/108302] void fn (uint8_t auto... args); leads to internal compiler error: Segmentation fault

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-01-06
 Status|UNCONFIRMED |NEW
  Known to fail||6.1.0
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Reduced:
typedef int t;
void fn (t auto... args);

[Bug c++/105656] remove BROKEN_VALUE_INITIALIZATION workaround

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||internal-improvement
   Last reconfirmed||2023-01-06
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #3 from Andrew Pinski  ---
Confirmed.

[Bug middle-end/108312] New: NULL definition in system.h is no longer needed any more

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 108312
   Summary: NULL definition in system.h is no longer needed any
more
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: internal-improvement
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

GCC requires a C++11 compiler to compile so the following in system.h is no
longer needed:
/* Define a generic NULL if one hasn't already been defined.  */
#ifndef NULL
#define NULL 0
#endif

[Bug middle-end/108311] New: system.h defines va_copy but we require C++11 compiler

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 108311
   Summary: system.h defines va_copy but we require C++11 compiler
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: internal-improvement
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

va_copy is part of C++11 so there is no reason for system.h to do:
#ifndef va_copy
# ifdef __va_copy
#   define va_copy(d,s)  __va_copy (d, s)
# else
#   define va_copy(d,s)  ((d) = (s))
# endif
#endif

[Bug middle-end/108300] `abort()` macro cause bootstrap failure on *-w64-mingw32

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|bootstrap   |middle-end
   Keywords||build

--- Comment #3 from Andrew Pinski  ---
This is remnant of when GCC was C code ...
I suspect there are other code like this too in system.h.

[Bug c++/100825] function signature constraints are not a part of mangled name

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-01-06
 Ever confirmed|0   |1

--- Comment #13 from Andrew Pinski  ---
Confirmed.

[Bug c++/108303] lookup failes with requires clause on non-template friend function of a class template

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Jonathan Wakely from comment #1)
> Currently we don't mangle requirements, so the foos all mangle the same and
> actually instantiating #1 will break, but for now we can test that they're
> considered distinct.

That would be PR 100825 .

[Bug c++/108309] [12 Regression] ICE in in cxx_eval_component_reference, at cp/constexpr.cc:4136

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Andrew Pinski  ---
(In reply to tim blechmann from comment #3)
> > That is a conditionally supported construct in C++. clang does not support 
> > it but GCC does. 
> > 
> > GCC does warn with -Wconditionally-supported
> 
> interesting. i may have to reduce it manually rather than going through
> cvise: the real-world code builds with clang and gcc doesn't seem to emit a
> warning with -Wconditionally-supported

Or you could add -Werror=conditionally-supported as an option and reduce it
that way ...

[Bug tree-optimization/108306] false-positive -Warray-bounds warning emitted with -fsanitize=shift

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Andrew Pinski  ---
The documentation now has:
Note that sanitizers tend to increase the rate of false positive
warnings, most notably those around @option{-Wmaybe-uninitialized}.
We recommend against combining @option{-Werror} and [the use of]
sanitizers.

[Bug c++/108309] [12 Regression] ICE in in cxx_eval_component_reference, at cp/constexpr.cc:4136

[tim at klingt dot org via Gcc-bugs]

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

--- Comment #3 from tim blechmann  ---
> That is a conditionally supported construct in C++. clang does not support it 
> but GCC does. 
> 
> GCC does warn with -Wconditionally-supported

interesting. i may have to reduce it manually rather than going through cvise:
the real-world code builds with clang and gcc doesn't seem to emit a warning
with -Wconditionally-supported

[Bug tree-optimization/108308] [13 Regression] wrong code at -Os and -O2 with "-fno-tree-ccp" on x86_64-linux-gnu

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

Version|unknown |13.0
Summary|wrong code at -Os and -O2   |[13 Regression] wrong code
   |with "-fno-tree-ccp" on |at -Os and -O2 with
   |x86_64-linux-gnu|"-fno-tree-ccp" on
   ||x86_64-linux-gnu
   Target Milestone|--- |13.0
   Keywords||wrong-code

[Bug c++/108309] [12 Regression] ICE in in cxx_eval_component_reference, at cp/constexpr.cc:4136

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.3
   Keywords||ice-on-valid-code,
   ||needs-bisection
  Known to fail||12.2.0
Summary|ICE in in   |[12 Regression] ICE in in
   |cxx_eval_component_referenc |cxx_eval_component_referenc
   |e, at cp/constexpr.cc:4136  |e, at cp/constexpr.cc:4136
  Known to work||11.3.0
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-01-06

--- Comment #2 from Andrew Pinski  ---
Reduced further:
```
struct _Enable_copy_move {};
struct h {
  union {
int _M_value;
  };
};
struct m {
  constexpr m(...) : _M_payload() {}
  constexpr m(const m &) {}
  h _M_payload;
};
struct optional : m, _Enable_copy_move {
  constexpr optional() {}
  template  constexpr optional(_Up __t) : m(__t) {}
};
struct array { optional t[1]; };

optional page {
  array {}
};

```

>clang++-15 doesn't (not sure if it's related, but i thought it's worth 
>mentioning:

That is a conditionally supported construct in C++. clang does not support it
but GCC does. 

GCC does warn with -Wconditionally-supported :

: In instantiation of 'constexpr optional::optional(_Up) [with _Up =
array]':
:20:1:   required from here
:14:62: warning: passing objects of non-trivially-copyable type 'struct
array' through '...' is conditionally supported [-Wconditionally-supported]
   14 |   template  constexpr optional(_Up __t) : m(__t) {}
  |  ^


Anyways this is fixed on the trunk; though since it is a GCC 12.x regression it
will/should be fixed on the GCC 12 branch too once someone figures out which
patch fixed it.

[Bug modula2/108294] soname bump for modula2 runtime libraries

[gaius at gcc dot gnu.org via Gcc-bugs]

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

Gaius Mulley  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Gaius Mulley  ---
Thanks for the bug report - all fixed now.

[Bug c/108310] Some warnings that -Wtraditional-conversion causes to be emitted aren't actually controlled by it

[egallager at gcc dot gnu.org via Gcc-bugs]

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

Eric Gallager  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=93082

--- Comment #2 from Eric Gallager  ---
(In reply to Eric Gallager from comment #1)
> Kinda related to bug 103210, IMO, in that I've uncovered both of them by
> building my fork of gdb with gcc:
> https://github.com/cooljeanius/apple-gdb-1824

More-specific link: https://github.com/cooljeanius/apple-gdb-1824/issues/8
(as the warnings in this bug can be seen preceding the error in question in
that bug, which is related to bug 93082)

[Bug jit/102824] building pdf/dvi documentation for libgccjit fails

[egallager at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Eric Gallager  ---
@marxin is this something you checked during the sphinx conversion and
reversion at all?

[Bug c/103210] "warning: braces around scalar initializer" should have a warning flag controlling it [-Wmany-braces-around-scalar-init]

[egallager at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Eric Gallager  ---
Downstream version of this issue:
https://github.com/cooljeanius/apple-gdb-1824/issues/9

[Bug c/108310] Some warnings that -Wtraditional-conversion causes to be emitted aren't actually controlled by it

[egallager at gcc dot gnu.org via Gcc-bugs]

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

Eric Gallager  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=103210
 Blocks||44209

--- Comment #1 from Eric Gallager  ---
Kinda related to bug 103210, IMO, in that I've uncovered both of them by
building my fork of gdb with gcc: https://github.com/cooljeanius/apple-gdb-1824
And, they're also both examples of places where warnings in gcc/c/c-typeck.cc
have a "0" for the second argument where they really ought to have an option
name instead, as per bug 44209.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44209
[Bug 44209] [meta-bug] Some warnings are not linked to diagnostics options

[Bug c/108310] New: Some warnings that -Wtraditional-conversion causes to be emitted aren't actually controlled by it

[egallager at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 108310
   Summary: Some warnings that -Wtraditional-conversion causes to
be emitted aren't actually controlled by it
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: diagnostic, easyhack
  Severity: trivial
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egallager at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
  Target Milestone: ---

So, I'm having trouble crafting a testcase that properly reproduces this issue,
but let's see if we can do this just by looking at the source: in
gcc/c/c-typeck.cc, starting at line 3464 (as it currently exists), there is a
block of code that emits some warnings from -Wtraditional-conversion:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/c/c-typeck.cc;h=e06f052eb46a72d3d50835330c5af975e7c52084;hb=HEAD#l3464
However, instead of being called like:
warning_at (ploc, OPT_Wtraditional_conversion, "");
like the rest of the warnings in the area, these two are just called like:
warning_at (ploc, 0, "");
This means that when the warning actually gets printed, the flag controlling
it, [-Wtraditional-conversion], isn't actually printed alongside it. `git
blame` says that Martin Sebor was the last person to touch this code in
r9-4484-g550dfbdcf6d93d. I might be able to fix this myself if someone can
confirm for me that this is an actual mistake that ought to be fixed (of
course, anyone else is welcome to fix it first!).

[Bug c++/108309] ICE in in cxx_eval_component_reference, at cp/constexpr.cc:4136

[tim at klingt dot org via Gcc-bugs]

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

--- Comment #1 from tim blechmann  ---
Created attachment 54200
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54200=edit
reduced test case

[Bug c++/108309] New: ICE in in cxx_eval_component_reference, at cp/constexpr.cc:4136

[tim at klingt dot org via Gcc-bugs]

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

Bug ID: 108309
   Summary: ICE in in cxx_eval_component_reference, at
cp/constexpr.cc:4136
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tim at klingt dot org
  Target Milestone: ---

```
template  constexpr _Tp forward(_Tp &__t) {
  return static_cast<_Tp &&>(__t);
}
struct _Enable_copy_move {};
struct optional;
template  struct __array_traits { typedef optional _Type[_Nm]; };
template  struct array { __array_traits<_Nm>::_Type _M_elems; };
struct _Optional_payload_base {
  union {
int _M_value;
  };
};
struct _Optional_base {
  constexpr _Optional_base(...) : _M_payload() {}
  constexpr _Optional_base(_Optional_base &&) {}
  _Optional_payload_base _M_payload;
};
struct optional : _Optional_base, _Enable_copy_move {
  using _Base = _Optional_base;
  constexpr optional() {}
  template  constexpr optional(_Up __t) : _Base(forward(__t)) {}
} page {
  array<8> {}
}
```

gives me:

```
➜  scratch /usr/bin/g++-12 -std=gnu++20 testcase.ii
testcase.ii:24:1:   in ‘constexpr’ expansion of
‘page.optional::optional >(array<8>{__array_traits<8>::_Type()})’
testcase.ii:24:1:   in ‘constexpr’ expansion of ‘forward(_Tp&) [with _Tp =
array<8>]()’
testcase.ii:24:1:   in ‘constexpr’ expansion of ‘array<8>((*
&((array<8>&&)__t)))’
testcase.ii:24:1:   in ‘constexpr’ expansion of
‘optional(.array<8>::_M_elems[0])’
testcase.ii:24:1: internal compiler error: in cxx_eval_component_reference, at
cp/constexpr.cc:4136
   24 | }
  | ^
0x7fb4eb429d8f __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x7fb4eb429e3f __libc_start_main_impl
../csu/libc-start.c:392
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
```

with
```
g++-12 (Ubuntu 12.2.0-3ubuntu1~22.04) 12.2.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
```

unfortunately cvise didn't reduce the test case to valid c++ code (afaict
there's only a missing semicolon, though). with a trailing semicolon, gcc-11
accepts the code, but clang++-15 doesn't (not sure if it's related, but i
thought it's worth mentioning:
```
testcase.reduced.cc:21:63: error: cannot pass object of non-trivial type
'array<8>' through variadic constructor; call will abort at runtime
[-Wnon-pod-varargs]
  template  constexpr optional(_Up __t) : _Base(forward(__t)) {}
  ^
testcase.reduced.cc:22:3: note: in instantiation of function template
specialization 'optional::optional>' requested here
} page {
  ^
1 error generated.
```

[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #14 from Jonathan Wakely  ---
And it isn't specific to Canadian cross compilation either. It happens for any
build with the latest mingw-w64 headers, both native and cross. And that has
nothing to do with std::mutex, which is the subject of this bug report.

[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #13 from Jonathan Wakely  ---
That's PR 108300 and has nothing to do with "macro pollution of __FILE__".

[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #12 from cqwrteur  ---
(In reply to cqwrteur from comment #11)
> The problem is that it breaks gcc build too. GCC won't build any more due to
> macro pollution of __FILE__

x86_64-w64-mingw32/artifacts/hostbuild/x86_64-w64-mingw32/gcc/./isl/include
-I/home/cqwrteur/toolchains_build/gcc/isl/include  -o cp/cvt.o -MT cp/cvt.o
-MMD -MP -MF cp/.deps/cvt.TPo /home/cqwrteur/toolchains_build/gcc/gcc/cp/cvt.cc
make[2]: *** [Makefile:1148: diagnostic-color.o] Error 1
make[2]: *** Waiting for unfinished jobs
/home/cqwrteur/toolchains_build/gcc/gcc/system.h:791:30: error: expected
identifier before string constant
  791 | #define abort() fancy_abort (__FILE__, __LINE__, __FUNCTION__)
  |  ^~~~
/home/cqwrteur/toolchains_build/gcc/gcc/system.h:791:30: error: expected ',' or
'...' before string constant
/home/cqwrteur/toolchains_build/gcc/gcc/system.h:791:30: error: expected
identifier before string constant
  791 | #define abort() fancy_abort (__FILE__, __LINE__, __FUNCTION__)
  |  ^~~~
/home/cqwrteur/toolchains_build/gcc/gcc/system.h:791:30: error: expected ',' or
'...' before string constant

It looks like macro pollution also causes the Canadian compilation for GCC to
fail. __FILE__ macro fails.

[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

[unlvsur at live dot com via Gcc-bugs]

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

cqwrteur  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
 Resolution|WONTFIX |---

--- Comment #11 from cqwrteur  ---
The problem is that it breaks gcc build too. GCC won't build any more due to
macro pollution of __FILE__

[Bug tree-optimization/108308] New: wrong code at -Os and -O2 with "-fno-tree-ccp" on x86_64-linux-gnu

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 108308
   Summary: wrong code at -Os and -O2 with "-fno-tree-ccp" on
x86_64-linux-gnu
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

This appears to be a recent regression as it does not reproduce with 12.2. 

Compiler Explorer: https://godbolt.org/z/h1hfa44We

[650] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
--with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20230105 (experimental) [master r13-5035-g4413365616e] (GCC) 
[651] % 
[651] % gcctk -Os small.c; ./a.out
[652] % 
[652] % gcctk -Os -fno-tree-ccp small.c
[653] % ./a.out
Floating point exception
[654] % 
[654] % cat small.c
int a = 1, *d = , f = 2766708631, h;
unsigned b = -1, c, e, g;
static void i(int j) {
  if (a) {
c = ~c;
while (e)
  j = 0;
goto k;
  }
 l:
  h = 1;
 k:
  *d = (!j) | 80;
  int m = ~(~(-1 / b) | (a ^ 1)), n = ~(~g / (11 >> m)), o = -1 / n;
  if (f) {
b = 9518150474215344 ^ ~f;
f = 0;
if (c)
  goto l;
if (o)
  goto k;
  }
}
int main() {
  i(1);
  return 0;
}

[Bug driver/108307] New: ICE compiling .S file with -fdiagnostics-format=sarif-file

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 108307
   Summary: ICE compiling .S file with
-fdiagnostics-format=sarif-file
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: diagnostic, ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

Given:

$ touch empty.S

$ ./xgcc -B. -c empty.S 

succeeds, but:

$ ./xgcc -B. -c empty.S -fdiagnostics-format=sarif-file

ICEs with:

0x11076c6 crash_signal
../../src/gcc/toplev.cc:314
0x226a532 xstrdup
../../src/libiberty/xstrdup.c:33
0x21dc81e diagnostic_output_format_init_sarif_file(diagnostic_context*, char
const*)
../../src/gcc/diagnostic-format-sarif.cc:1585
0x21b9cba common_handle_option(gcc_options*, gcc_options*, cl_decoded_option
const*, unsigned int, int, unsigned int, cl_option_handlers const*,
diagnostic_context*, void (*)())
../../src/gcc/opts.cc:2858
0x21beaae handle_option
../../src/gcc/opts-common.cc:1248
0x21bebf8 read_cmdline_option(gcc_options*, gcc_options*, cl_decoded_option*,
unsigned int, unsigned int, cl_option_handlers const*, diagnostic_context*)
../../src/gcc/opts-common.cc:1578
0x10126d2 read_cmdline_options
../../src/gcc/opts-global.cc:239
0x10126d2 decode_options(gcc_options*, gcc_options*, cl_decoded_option*,
unsigned int, unsigned int, diagnostic_context*, void (*)())
../../src/gcc/opts-global.cc:321
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

due to NULL base_file_name here.

#2  0x021dc81f in diagnostic_output_format_init_sarif_file
(context=0x2fe61c0 , base_file_name=0x0)
at ../../src/gcc/diagnostic-format-sarif.cc:1585
warning: Source file is more recent than executable.
1585  sarif_output_base_file_name = xstrdup (base_file_name);

Similar to PR 106133 (but for sarif-file, rather than json-file)

[Bug libstdc++/77691] [10/11/12/13 regression] experimental/memory_resource/resource_adaptor.cc FAILs

[danglin at gcc dot gnu.org via Gcc-bugs]

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

John David Anglin  changed:

   What|Removed |Added

   Last reconfirmed|2016-09-22 00:00:00 |2023-1-5

--- Comment #53 from John David Anglin  ---
Still fails on hppa64-hp-hpux11.11.

[Bug c/108306] false-positive -Warray-bounds warning emitted with -fsanitize=shift

[kees at outflux dot net via Gcc-bugs]

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

Kees Cook  changed:

   What|Removed |Added

  Attachment #54198|0   |1
is obsolete||

--- Comment #3 from Kees Cook  ---
Created attachment 54199
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54199=edit
better PoC

This is a better PoC showing the issue.

[Bug modula2/108261] modula-2 module registration process seems to fail with shared libraries.

[iains at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Iain Sandoe  ---
and another datum (on x86_64linux):

$ ../gcc-13-0-0p/bin/gm2
/home/iains/gcc-master/src-patched/gcc/testsuite/gm2/coroutines/pim/run/pass/testiotransfer.mod
-flibs=cor,iso,pim -o tio -O

$ LD_LIBRARY_PATH=../gcc-13-0-0p/lib64 ./tio
now to TRANSFER...
clock starting
now to LISTEN
1000 IOTRANSFERs successfully completed
exit 0

$ ../gcc-13-0-0p/bin/gm2
/home/iains/gcc-master/src-patched/gcc/testsuite/gm2/coroutines/pim/run/pass/testiotransfer.mod
-flibs=cor,pim,iso -o tio -O

$ LD_LIBRARY_PATH=../gcc-13-0-0p/lib64 ./tio
../../../../src-patched/libgm2/libm2iso/../../gcc/m2/gm2-libs-iso/RTentity.mod:244:in
findChildAndParent has caused internal runtime error, RTentity is either
corrupt or the module storage has not been initialized yet

[Bug c/108306] false-positive -Warray-bounds warning emitted with -fsanitize=shift

[kees at outflux dot net via Gcc-bugs]

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

--- Comment #2 from Kees Cook  ---
Ugh, sorry. The PoC is bad -- the bounds check isn't present. Let me try to get
a another PoC.

[Bug c/108306] false-positive -Warray-bounds warning emitted with -fsanitize=shift

[kees at outflux dot net via Gcc-bugs]

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

Kees Cook  changed:

   What|Removed |Added

 CC||arnd at linaro dot org,
   ||garsilva at embeddedor dot com,
   ||pbrobinson at gmail dot com,
   ||pinskia at gcc dot gnu.org,
   ||qing.zhao at oracle dot com,
   ||rguenth at gcc dot gnu.org

--- Comment #1 from Kees Cook  ---
FWIW, the Linux kernel is seeing these under GCC 13 (and 12, but we had to
disable -Warray-bounds entirely in GCC 12 due to similar bugs).

[Bug c/108306] New: false-positive -Warray-bounds warning emitted with -fsanitize=shift

[kees at outflux dot net via Gcc-bugs]

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

Bug ID: 108306
   Summary: false-positive -Warray-bounds warning emitted with
-fsanitize=shift
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kees at outflux dot net
  Target Milestone: ---

Created attachment 54198
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54198=edit
reduced PoC

This seems similar to bug #105679, but is still present in GCC 13 (and 12).
Something about -fsanitize=shift really confuses -Warray-bounds:

poc2.c: In function 'e':
poc2.c:12:8: warning: array subscript 32 is above array bounds of 'int[4]'
[-Warray-bounds=]
   12 | c.d[f]++;
  | ~~~^~~
poc2.c:4:7: note: while referencing 'd'
4 |   int d[MAX];
  |   ^
poc2.c:12:8: warning: array subscript 32 is above array bounds of 'int[4]'
[-Warray-bounds=]
   12 | c.d[f]++;
  | ~~~^~~
poc2.c:4:7: note: while referencing 'd'
4 |   int d[MAX];
  |   ^

[Bug rtl-optimization/108292] [13 Regression] wrong code with vector compare & mask at -O1 and above

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #15 from Roger Sayle  ---
This regression has now been resolved by reverting the problematic patch. 
Sorry for the inconvenience.  Perhaps we'll have better luck (with a better
solution) after we return to stage 1.

[Bug rtl-optimization/108292] [13 Regression] wrong code with vector compare & mask at -O1 and above

[roger at nextmovesoftware dot com via Gcc-bugs]

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

--- Comment #14 from Roger Sayle  ---
Created attachment 54197
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54197=edit
Related optimizations to ix86_expand_int_movcc.

Just for the record, here is a related patch that I was working on (touching
the problematic piece of code), before everything went pear shaped.

[Bug libbacktrace/108297] libtool link b2test fails: Unrecognized argument: --build-id

[ian at airs dot com via Gcc-bugs]

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

--- Comment #3 from Ian Lance Taylor  ---
Created attachment 54196
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54196=edit
Potential patch

Does this patch fix the problem for you?  Thanks.

[Bug libstdc++/108305] New: FAIL: 27_io/basic_ofstream/open/char/noreplace.cc execution test

[danglin at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 108305
   Summary: FAIL: 27_io/basic_ofstream/open/char/noreplace.cc
execution test
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11

spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir64/./gcc/xg++ -shared-libgcc
-B/ho
me/dave/gnu/gcc/objdir64/./gcc -nostdinc++
-L/home/dave/gnu/gcc/objdir64/hppa64-
hp-hpux11.11/libstdc++-v3/src
-L/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/
libstdc++-v3/src/.libs
-L/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc
++-v3/libsupc++/.libs -B/opt/gnu64/gcc/gcc-13/hppa64-hp-hpux11.11/bin/
-B/opt/gn
u64/gcc/gcc-13/hppa64-hp-hpux11.11/lib/ -isystem
/opt/gnu64/gcc/gcc-13/hppa64-hp
-hpux11.11/include -isystem
/opt/gnu64/gcc/gcc-13/hppa64-hp-hpux11.11/sys-includ
e -fchecking=1
-B/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/
src/.libs -fmessage-length=0 -fno-show-column -ffunction-sections
-fdata-section
s -O2 -g -DLOCALEDIR="." -nostdinc++
-I/home/dave/gnu/gcc/objdir64/hppa64-hp-hpu
x11.11/libstdc++-v3/include/hppa64-hp-hpux11.11
-I/home/dave/gnu/gcc/objdir64/hp
pa64-hp-hpux11.11/libstdc++-v3/include
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/lib
supc++ -I/home/dave/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/home/dave/gnu/g
cc/gcc/libstdc++-v3/testsuite/util
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite
/27_io/basic_ofstream/open/char/noreplace.cc -include bits/stdc++.h
-fdiagnostic
s-plain-output ./libtestc++.a -lm -o ./noreplace.exe
PASS: 27_io/basic_ofstream/open/char/noreplace.cc (test for excess errors)
Setting LD_LIBRARY_PATH to
:/home/dave/gnu/gcc/objdir64/gcc:/home/dave/gnu/gcc/o
bjdir64/hppa64-hp-hpux11.11/./libstdc++-v3/../libatomic/.libs:/home/dave/gnu/gcc
/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/../libgomp/.libs:/home/dave/gnu/gcc
/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs::/home/dave/gnu/gcc/objdi
r64/gcc:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/../libato
mic/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/../libg
omp/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/src/.li
bs::/home/dave/gnu/gcc/objdir64/gcc:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11
.11/./libstdc++-v3/../libatomic/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux
11.11/./libstdc++-v3/../libgomp/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux
11.11/./libstdc++-v3/src/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/.
/libatomic/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libatomic/.li
bs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libatomic/.libs:/home/dave/
gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libatomic/.libs:/home/dave/gnu/gcc/objdir
64/hppa64-hp-hpux11.11/./libatomic/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-h
pux11.11/./libatomic/.libs::/home/dave/gnu/gcc/objdir64/gcc:/home/dave/gnu/gcc/o
bjdir64/hppa64-hp-hpux11.11/./libstdc++-v3/../libatomic/.libs:/home/dave/gnu/gcc
/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/../libgomp/.libs:/home/dave/gnu/gcc
/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs:/home/dave/gnu/gcc/objdir
64/hppa64-hp-hpux11.11/./libatomic/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libatomic/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libatomic/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libatomic/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libatomic/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libatomic/.libs
Execution timeout is: 300
spawn [open ...]
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/27_io/basic_ofstream/open/char/noreplace.cc:28:
int main(): Assertion '! of.is_open()' failed.
FAIL: 27_io/basic_ofstream/open/char/noreplace.cc execution test

Similar fail:

/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/27_io/basic_ofstream/open/wchar_t/
noreplace.cc:28: int main(): Assertion '! of.is_open()' failed.
FAIL: 27_io/basic_ofstream/open/wchar_t/noreplace.cc execution test

[Bug rtl-optimization/108292] [13 Regression] wrong code with vector compare & mask at -O1 and above

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #13 from H.J. Lu  ---
I also got

$ cat foo.i
extern void foo (float *);

extern int x;
int
mouse_frame_side(void) {
  float mouseloc;
  foo ();
  return mouseloc > x ? 1 : 2;
}
$ gcc -march=alderlake -Ofast -S foo.i
during RTL pass: cse2
foo.i: In function ?mouse_frame_side?:
foo.i:9:1: internal compiler error: in copy_rtx, at rtl.cc:369
9 | }
  | ^
0x148a75b copy_rtx(rtx_def*)
../../src-master/gcc/rtl.cc:369
0x148a690 copy_rtx(rtx_def*)
../../src-master/gcc/rtl.cc:342
0x2b72758 cse_insn
../../src-master/gcc/cse.cc:4562
0x2b787b8 cse_extended_basic_block
../../src-master/gcc/cse.cc:6566
0x2b78cd6 cse_main
../../src-master/gcc/cse.cc:6711
0x2b7ae5e rest_of_handle_cse2
../../src-master/gcc/cse.cc:7600
0x2b7af84 execute
../../src-master/gcc/cse.cc:7655
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions. 

(gdb) f 3
#3  0x02b72759 in cse_insn (insn=0x7fffea01bac0)
at ../../src-master/gcc/cse.cc:4562
4562src_eqv = copy_rtx (XEXP (tem, 0));
(gdb) call debug_rtx (insn)
(insn 48 47 49 2 (parallel [
(set (reg:SI 94)
(if_then_else:SI (unlt:SI (reg:CCFP 17 flags)
(const_int 0 [0]))
(const_int -1 [0x])
(const_int 0 [0])))
(clobber (reg:CC 17 flags))
]) "/export/project/git/gcc-bisect/foo.i":8:27 discrim 2 1288
{*x86_movsicc_0_m1}
 (expr_list:REG_DEAD (reg:CCFP 17 flags)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_EQUAL (neg:SI (UnKnown:SI Unknown))
(nil)
(gdb)

[Bug rtl-optimization/108292] [13 Regression] wrong code with vector compare & mask at -O1 and above

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #12 from CVS Commits  ---
The master branch has been updated by Roger Sayle :

https://gcc.gnu.org/g:9e6ac747ac5cff9e3f58421cdd9f03538e48ed07

commit r13-5038-g9e6ac747ac5cff9e3f58421cdd9f03538e48ed07
Author: Roger Sayle 
Date:   Thu Jan 5 19:49:45 2023 +

[Committed] PR rtl-optimization/108292: Revert "Improve
ix86_expand_int_movcc to allow condition (mask) sharing"

This reverts commit d0558f420b2a5692fd38ac76ffa97ae6c1726ed9.

2023-01-05  Roger Sayle  

gcc/ChangeLog
PR rtl-optimization/108292
* config/i386/i386-expand.cc (ix86_expand_int_movcc): Revert
previous changes.

gcc/testsuite/ChangeLog
PR rtl-optimization/108292
* gcc.target/i386/cmov10.c: Remove test case.

[Bug libbacktrace/108297] libtool link b2test fails: Unrecognized argument: --build-id

[dave.anglin at bell dot net via Gcc-bugs]

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

--- Comment #2 from dave.anglin at bell dot net ---
On 2023-01-05 2:23 p.m., ian at airs dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108297
>
> Ian Lance Taylor  changed:
>
> What|Removed |Added
> 
>   CC||ian at airs dot com
>
> --- Comment #1 from Ian Lance Taylor  ---
> Does HP/UX 11.11 use ELF?
The 64-bit target uses ELF.
> If so, I guess we need a configure test to see
> whether the linker supports the --build-id option.  If it doesn't, I guess we
> need to skip the debuginfo tests.
Currently, HP ld is the only working linker and it doesn't support the
--build-id option.  GNU
ld has problems with shared library support.

[Bug rtl-optimization/108292] [13 Regression] wrong code with vector compare & mask at -O1 and above

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #11 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #10)
> (In reply to Roger Sayle from comment #8)
> > Here's my proposed patch (or something close to it, it's still bootstrapping
> > and regression testing).  The goal is to capture the original comparison (at
> > the top of the BB), and avoid/ignore the actual comparison that we may have
> > converted to.
> > Sorry again to the inconvenience.  Please let me know what you think.

The fix is not a simple patch, and it looks to me that the original patch has
several rough edges. I propose to revert the original patch at this stage of
development and retry with it at the next stage 1.

[Bug c++/108275] pointer to member field is not checked for accessibility inside a template argument

[ppalka at gcc dot gnu.org via Gcc-bugs]

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

Patrick Palka  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
   Target Milestone|--- |13.0
 Resolution|--- |FIXED
 CC||ppalka at gcc dot gnu.org
 Status|NEW |RESOLVED

--- Comment #3 from Patrick Palka  ---
Fixed for GCC 13

[Bug libbacktrace/108297] libtool link b2test fails: Unrecognized argument: --build-id

[ian at airs dot com via Gcc-bugs]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 CC||ian at airs dot com

--- Comment #1 from Ian Lance Taylor  ---
Does HP/UX 11.11 use ELF?  If so, I guess we need a configure test to see
whether the linker supports the --build-id option.  If it doesn't, I guess we
need to skip the debuginfo tests.

[Bug c++/108275] pointer to member field is not checked for accessibility inside a template argument

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:12b0d35ec52375da5652d2b8da74083ab700b9d7

commit r13-5037-g12b0d35ec52375da5652d2b8da74083ab700b9d7
Author: Patrick Palka 
Date:   Thu Jan 5 14:21:34 2023 -0500

c++: class-head parsing and CPP_TEMPLATE_ID access [PR108275]

When tentatively parsing what is really an elaborated-type-specifier
containing a template-id first as a class-specifier, we may form a
CPP_TEMPLATE_ID token that later gets reused by the fallback parse if
the tentative parse fails.  These special tokens also capture the access
checks that have been deferred while parsing the template-id.  But here
we form such a token when the access check state is dk_no_check, and so
the token captures no access checks.  This effectively bypasses access
checking for the template-id during the subsequent parse as an
elaborated-type-specifier.

This patch fixes this by using dk_deferred instead of dk_no_check when
parsing the class name of a class-head.

PR c++/108275

gcc/cp/ChangeLog:

* parser.cc (cp_parser_class_head): Use dk_deferred instead of
dk_no_check when parsing the class name.

gcc/testsuite/ChangeLog:

* g++.dg/parse/access14.C: New test.

[Bug rtl-optimization/108292] [13 Regression] wrong code with vector compare & mask at -O1 and above

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #10 from Jakub Jelinek  ---
(In reply to Roger Sayle from comment #8)
> Created attachment 54195 [details]
> Roger's proposed patch
> 
> Here's my proposed patch (or something close to it, it's still bootstrapping
> and regression testing).  The goal is to capture the original comparison (at
> the top of the BB), and avoid/ignore the actual comparison that we may have
> converted to.
> Sorry again to the inconvenience.  Please let me know what you think.

I don't like that much (of course, Uros is the maintainer so his call).
But, I think we should avoid bundling the code generation changes (the dropping
of ct or cf checks for negate_cc_compare_p; if that is a win, it should be
proven separately but it isn't clear if it is) and the patch just causes
further dead variables which the current code already has many.
What is the point of orig_code when code is already dead except for this newly
added REG_EQUAL note?  Why can't just code contain it?
As for the floating point stuff, yes, the - 1 would be an option, but perhaps
should be used only if we need to reverse floating point comparison?
If we introduce a bool for swap_ct_cf, then it seems pointless to also actually
swap ct/cf and recompute diff in all the spots, just set swap_ct_cf and
swap/recompute diff only if the bool is set and we need to look at ct/cf/diff.

[Bug rtl-optimization/108292] [13 Regression] wrong code with vector compare & mask at -O1 and above

[roger at nextmovesoftware dot com via Gcc-bugs]

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

--- Comment #9 from Roger Sayle  ---
Another way to avoid the SCALAR_FLOAT_MODE_P problem is:
  /* Add a REG_EQUAL note to allow condition to be shared.  */
  rtx note = gen_rtx_fmt_ee (orig_code, mode, op0, op1);
  /* TMP is (orig_code op0 op1) ? 0 : -1, or swapped.  */
  note = orig_swapped ? gen_rtx_NEG (mode, node)
  : gen_rtx_PLUS (mode, note, constm1_rtx);
  set_unique_reg_note (get_last_insn (), REG_EQUAL, note);

i.e. don't attempt to modify the initial comparison; instead tweak the note.

[Bug libstdc++/108304] New: FAIL: 20_util/from_chars/4.cc execution test

[danglin at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 108304
   Summary: FAIL: 20_util/from_chars/4.cc execution test
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11

spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir64/./gcc/xg++ -shared-libgcc
-B/ho
me/dave/gnu/gcc/objdir64/./gcc -nostdinc++
-L/home/dave/gnu/gcc/objdir64/hppa64-
hp-hpux11.11/libstdc++-v3/src
-L/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/
libstdc++-v3/src/.libs
-L/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc
++-v3/libsupc++/.libs -B/opt/gnu64/gcc/gcc-13/hppa64-hp-hpux11.11/bin/
-B/opt/gn
u64/gcc/gcc-13/hppa64-hp-hpux11.11/lib/ -isystem
/opt/gnu64/gcc/gcc-13/hppa64-hp
-hpux11.11/include -isystem
/opt/gnu64/gcc/gcc-13/hppa64-hp-hpux11.11/sys-includ
e -fchecking=1
-B/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/
src/.libs -fmessage-length=0 -fno-show-column -ffunction-sections
-fdata-section
s -O2 -g -DLOCALEDIR="." -nostdinc++
-I/home/dave/gnu/gcc/objdir64/hppa64-hp-hpu
x11.11/libstdc++-v3/include/hppa64-hp-hpux11.11
-I/home/dave/gnu/gcc/objdir64/hp
pa64-hp-hpux11.11/libstdc++-v3/include
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/lib
supc++ -I/home/dave/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/home/dave/gnu/g
cc/gcc/libstdc++-v3/testsuite/util
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite
/20_util/from_chars/4.cc -include bits/stdc++.h -fdiagnostics-plain-output
./lib
testc++.a -lm -o ./4.exe
PASS: 20_util/from_chars/4.cc (test for excess errors)
Setting LD_LIBRARY_PATH to
:/home/dave/gnu/gcc/objdir64/gcc:/home/dave/gnu/gcc/o
bjdir64/hppa64-hp-hpux11.11/./libstdc++-v3/../libatomic/.libs:/home/dave/gnu/gcc
/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/../libgomp/.libs:/home/dave/gnu/gcc
/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs::/home/dave/gnu/gcc/objdi
r64/gcc:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/../libato
mic/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/../libg
omp/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/src/.li
bs::/home/dave/gnu/gcc/objdir64/gcc:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11
.11/./libstdc++-v3/../libatomic/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux
11.11/./libstdc++-v3/../libgomp/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux
11.11/./libstdc++-v3/src/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/.
/libatomic/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libatomic/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libatomic/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libatomic/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libatomic/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libatomic/.libs::/home/dave/gnu/gcc/objdir64/gcc:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/../libatomic/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/../libgomp/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libatomic/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libatomic/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libatomic/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libatomic/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libatomic/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libatomic/.libs
Execution timeout is: 300
spawn [open ...]
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/20_util/from_chars/4.cc:325: void
test_max_mantissa() [with FloatT = long double; UIntT = __int128 unsigned]:
Assertion 'flt == val' failed.
FAIL: 20_util/from_chars/4.cc execution test

Similar fails:

/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/20_util/from_chars/8.cc:311: void
test_max_mantissa() [with FloatT = _Float128; UIntT = __int128 unsigned]:
Assert
ion 'flt == val' failed.
FAIL: 20_util/from_chars/8.cc execution test

/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/20_util/to_chars/float128_c++23.cc
:79: void test(std::chars_format): Assertion 'ec4 == std::errc() && ptr4 ==
ptr1
' failed.
FAIL: 20_util/to_chars/float128_c++23.cc execution test

[Bug rtl-optimization/108292] [13 Regression] wrong code with vector compare & mask at -O1 and above

[roger at nextmovesoftware dot com via Gcc-bugs]

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

--- Comment #8 from Roger Sayle  ---
Created attachment 54195
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54195=edit
Roger's proposed patch

Here's my proposed patch (or something close to it, it's still bootstrapping
and regression testing).  The goal is to capture the original comparison (at
the top of the BB), and avoid/ignore the actual comparison that we may have
converted to.
Sorry again to the inconvenience.  Please let me know what you think.

[Bug libstdc++/108288] Deadlock when using -fno-elide-constructor + -D_GLIBCXX_DEBUG=1 + -std=c++11

[simon.marchi at polymtl dot ca via Gcc-bugs]

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

--- Comment #8 from Simon Marchi  ---
I tested with just patching my /usr/include, and it looks like it works fine,
I'm able to run a program under my GDB.  Removing the fix, I get back the hang.

[Bug c++/108303] lookup failes with requires clause on non-template friend function of a class template

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #1 from Jonathan Wakely  ---
Started to be rejected with r13-4035

c++: only declare satisfied friends

A friend declaration can only have constraints if it is defined.  If
multiple instantiations of a class template define the same friend function
signature, it's an error, but that shouldn't happen if it's constrained to
only be declared in one instantiation.

Currently we don't mangle requirements, so the foos all mangle the same and
actually instantiating #1 will break, but for now we can test that they're
considered distinct.

[Bug libstdc++/108288] Deadlock when using -fno-elide-constructor + -D_GLIBCXX_DEBUG=1 + -std=c++11

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from Jonathan Wakely  ---
__gnu_debug::_Safe_iterator_base::_M_detach in debug.cc isn't affected by the
patch though.

The fix is to the post-inc and post-dec members, so only the code that calls
those needs to be recompiled.

[Bug libstdc++/108288] Deadlock when using -fno-elide-constructor + -D_GLIBCXX_DEBUG=1 + -std=c++11

[simon.marchi at polymtl dot ca via Gcc-bugs]

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

--- Comment #6 from Simon Marchi  ---
Because some code trying to acquire the lock (see frame #7 in my backtrace) is
in debug.cc, I thought it would maybe need to be changed too?  But I don't
really understand any of this.

[Bug rtl-optimization/108292] [13 Regression] wrong code with vector compare & mask at -O1 and above

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from Jakub Jelinek  ---
Or for now don't add any REG_EQUAL note if op0 has scalar floating point
mode...

[Bug rtl-optimization/108292] [13 Regression] wrong code with vector compare & mask at -O1 and above

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Jakub Jelinek  ---
So I wonder about:
--- gcc/config/i386/i386-expand.cc.jj   2023-01-04 10:45:49.978883731 +0100
+++ gcc/config/i386/i386-expand.cc  2023-01-05 18:22:40.228518935 +0100
@@ -3271,10 +3271,12 @@ ix86_expand_int_movcc (rtx operands[])
{
  negate_cc_compare_p = true;
  std::swap (ct, cf);
- code = EQ;
}
  else if (code == EQ && op1 == const0_rtx && cf == -1)
-   negate_cc_compare_p = true;
+   {
+ negate_cc_compare_p = true;
+ code = NE;
+   }
}

   diff = ct - cf;
@@ -3319,11 +3321,7 @@ ix86_expand_int_movcc (rtx operands[])

  /* To simplify rest of code, restrict to the GEU case.  */
  if (compare_code == LTU)
-   {
- std::swap (ct, cf);
- compare_code = reverse_condition (compare_code);
- code = reverse_condition (code);
-   }
+   std::swap (ct, cf);
  else
{
  if (fpcmp)
@@ -,6 +3331,10 @@ ix86_expand_int_movcc (rtx operands[])
  else
PUT_CODE (compare_op,
  reverse_condition (GET_CODE (compare_op)));
+ if (SCALAR_FLOAT_MODE_P (GET_MODE (op0)))
+   code = reverse_condition_maybe_unordered (code);
+ else
+   code = reverse_condition (code);
}
  diff = ct - cf;

but am not very sure about that, especially the floating point stuff, e.g.
whether
for -ffast-math it shouldn't actually be reverse_condition (and not add any
REG_EQUAL note if code is UNKNOWN?).

[Bug c++/108303] New: lookup failes with requires clause on non-template friend function of a class template

[ted at lyncon dot se via Gcc-bugs]

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

Bug ID: 108303
   Summary: lookup failes with requires clause on non-template
friend function of a class template
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ted at lyncon dot se
  Target Milestone: ---

This works up to 12.2 (inclusive) on godbolt but fails on trunk:
```
template 
struct base {
friend void foo(const Derived& d)
requires requires { bar(d); } // removing this makes it work
{
bar(d);
}
};

namespace adl {
struct S : base {
friend void bar(const S&) {}
};
}  // namespace adl

void test(adl::S const& s) {
foo(s);  // error: 'foo' was not declared in this scope
}
```

[Bug libstdc++/108288] Deadlock when using -fno-elide-constructor + -D_GLIBCXX_DEBUG=1 + -std=c++11

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Jonathan Wakely  ---
The patch doesn't change libstdc++.so, it only changes the headers.

You don't even need to rebuild GCC. You could just put a patched copy of
safe_iterator.h in /tmp/x/debug and then compile with -I/tmp/x so it finds the
patched header.

[Bug rtl-optimization/108292] [13 Regression] wrong code with vector compare & mask at -O1 and above

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Jakub Jelinek  ---
Though, it seems the REG_EQUAL note is also wrong on the cmov10.c testcase
which went with the commit (again, exact opposite).

Seems we have multiple cases where this REG_EQUAL note is newly added.
One is x != 0 ? -1 : y, negate_cc_compare_p is true and code overridden to EQ
and ct/cf swapped.
So, the note is then (neg (eq x const0_rtx)).
Another one is x == 0 ? y : -1, negate_cc_compare_p is true, code, ct and cf
unchanged.
The note is then (neg (eq x const0_rtx)) too.
The sequence emitted for both of these cases is neg{l,q} x; sbb{l,q} tmp, tmp,
which sets tmp to 0 if x == 0 and to -1 if x != 0.  So the right note would be
IMNSHO
(neg (ne x const0_rtx)) for both of the above cases.
Another case is the sign_bit_compare_p case, which happens for (signed)
x >= 0 ? y : z
x < 0 ? y : z
x > -1 ? y : z
x <= -1 ? y : z
The code handling those cases is:
  if (code == GT || code == GE)
code = reverse_condition (code);
  else
{
  std::swap (ct, cf);
  diff = ct - cf;
}
  tmp = emit_store_flag (tmp, code, op0, op1, VOIDmode, 0, -1);
In that case emit_store_flag sets tmp to (code op0 op1) ? -1 : 0 so I think
(neg (code op0 op1)) is the right REG_EQUAL note for it.
The last case is when ix86_expand_carry_flag_compare returns true.
This is when LTU/GEU comparisons are used or something which can be turned into
one,
e.g. x == 0 or x != 0 turned into x < 1U or x >= 1U.

Now, the code below the addition of the new REG_EQUAL note assumes that the
comparison
set tmp to 0 if true and to -1 if false (which can be seen e.g. from diff == 1
&& ct == 0 case not adding any further instructions).  So the REG_EQUAL note
should be IMHO
gen_rtx_NEG (mode, gen_rtx_fmt_ee (reverse_condition (code), mode, op0, op1))
rather than gen_rtx_NEG (mode, gen_rtx_fmt_ee (code, mode, op0, op1))
for the cases where std::swap (ct, cf); has not been done (with the original
code, not the adjusted one).  For the sign_bit_compare_p case that matches the
above analysis that
it is handled correctly, as we reverse_condition iff swap isn't done.
For the negate_cc_compare_p case I think it matches the analysis too that it is
always wrong and should be always NE.

[Bug rtl-optimization/108292] [13 Regression] wrong code with vector compare & mask at -O1 and above

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |roger at 
nextmovesoftware dot com
 CC||roger at nextmovesoftware dot 
com
 Status|NEW |ASSIGNED

--- Comment #4 from Roger Sayle  ---
Doh! Apologies for the inconvenience.  I'll have a fix soon.

[Bug c/108298] Wrong optimization of volatile access from gcc 11 and beyond

[segher at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Segher Boessenkool  ---
This is not x86-specific.  Like on powerpc64 we get

addi 3,3,3   # 11   [c=4 l=4]  *addsi3/1
extsw 3,3# 17   [c=4 l=4]  extendsidi2/1
blr  # 25   [c=4 l=4]  simple_return

Before RTL all is fine still:

int foo (int a, int b, int c)
{
  int _1;
  int _2;

;;   basic block 2, loop depth 0
;;pred:   ENTRY
  _1 = a_3(D) + 1;
  b = _1;
  _2 ={v} MEM[(volatile int *)];
  a_6 = _2 + 2;
  return a_6;
;;succ:   EXIT

}

But it is expanded to something that is not going through memory:

;; _2 ={v} MEM[(volatile int *)];

(insn 10 9 0 (set (reg:SI 118 [ _2 ])
(subreg/s/u:SI (reg/v:DI 121 [ b+-4 ]) 4)) "108298.c":10:9 -1
 (nil))

[Bug modula2/108182] gm2 driver mishandles target and multilib options

[iains at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Iain Sandoe  ---
(In reply to Gaius Mulley from comment #4)
> Created attachment 54184 [details]
> Potential fix for target multilib_dir handling -m and -f.
> 
> Work in progress.

1. (I think) the string you need is "multilib_os_dir" not "multilib_dir" (but
ICBW about that .. there are many twisty passages in the determination of these
things).

2. The concern remains that the language spec handler is run pretty much first
in the stack and there are several other claims on the command line that could
have specs that alter (or add) flags to the command line, giving a different
outcome to the computation of mulilib_{,os_}dir.

perhaps it would be a good idea to post this and ask the opinion of someone
like Joseph on the direction.

[Bug modula2/107631] many tests don't link on Mac OS X 10.7

[iains at gcc dot gnu.org via Gcc-bugs]

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #5 from Iain Sandoe  ---
now that we have resolved the visibility of the module registration CTORs and
eliminated uses of scalb*() and significand*() this is fixed.

[Bug modula2/107631] many tests don't link on Mac OS X 10.7

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Iain D Sandoe :

https://gcc.gnu.org/g:4413365616e8c6024d1ff4e23309e5012ee33b9f

commit r13-5035-g4413365616e8c6024d1ff4e23309e5012ee33b9f
Author: Iain Sandoe 
Date:   Wed Jan 4 21:03:24 2023 +

modula-2: Remove uses of scalb*() and significand*() [PR107631]

The scalb*() functions are obsolete in Posix from 2004 and removed in
2008.

The significand*() functions are glibc-only and considered there to be
obsolescent (not supported for types such as _Float128).

We can remove them from Modula-2 since they are not required for ISO
support, but we need to provide an implementation of significand* for
the "fraction()" functions.

PR modula2/107631

gcc/m2/ChangeLog:

* gm2-gcc/m2builtins.cc: Remove scalb, scalbf, scalbl,
significand, significandf, significandl.
* gm2-libs/Builtins.def (significand): Likewise.
* gm2-libs/Builtins.mod: Likewise.
* target-independent/Builtins.texi: Likewise.
* gm2-libs-iso/LowLong.mod: Implement fraction with scalbn*() and
ilogb*().
* gm2-libs-iso/LowReal.mod: Likewise.
* gm2-libs-iso/LowShort.mod: Likewise.

[Bug libstdc++/108288] Deadlock when using -fno-elide-constructor + -D_GLIBCXX_DEBUG=1 + -std=c++11

[simon.marchi at polymtl dot ca via Gcc-bugs]

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

--- Comment #4 from Simon Marchi  ---
Thanks for looking into this so quickly.  I'll try to test the patch against my
use case, but I might need some guidance.  I know how to build gcc and install
it in some non-default prefix.  But then, do I need to do something special
when building my program, to ensure that this libstdc++.so will be used,
instead of the system one?  Just set LD_LIBRARY_PATH appropriately, like for
any other lib?

[Bug ipa/108110] [13 Regression] ice in modify_call, at ipa-param-manipulation.cc:700 with -std=c++14 -O3 -march=znver3 since r13-4685-g4834e9360f7bf4

[jamborm at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #16 from Martin Jambor  ---
I have posted the sorting patch to the mailing list:

https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609459.html

[Bug target/108293] Incorrect assembly emitted for float for BPF target

[jemarch at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Jose E. Marchesi  ---
(In reply to Jakub Jelinek from comment #2)
> Another thing is that at least for all SFmode constant one could use mov
> instead of lddw.

For this I guess we could expand the "I" constraint to cover const_double that
fits in the 32-bit range.  But then we would need something like IN_RANGE that
works with const_double.

[Bug target/103784] suboptimal code for returning bool value on target ppc

[jskumari at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #8 from Surya Kumari Jangala  ---
Using -O3 with gcc13, I got (with the test in comment 2):

For P8:
cmpwi 0,3,2
bgt 0,.L3
subfic 4,4,9
srdi 3,4,63
xori 3,3,0x1
rldicl 3,3,0,63
blr
.p2align 4,,15
.L3:
li 3,0
rldicl 3,3,0,63
blr


For P10:
cmpwi 0,3,2
bgt 0,.L3
cmpwi 0,4,9
setbcr 3,1
rldicl 3,3,0,63
blr
.p2align 4,,15
.L3:
li 3,0
rldicl 3,3,0,63
blr

[Bug libstdc++/108212] [13 Regression] pretty printers don't work with Python 2 due to imports for chrono

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #2 from Jonathan Wakely  ---
Fixed.

[Bug libstdc++/108290] QoI: bind_front captureless lambda is too big

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Jonathan Wakely  ---
Done for GCC 13. Not suitable for backports.

Thanks for the report.

[Bug libstdc++/108290] QoI: bind_front captureless lambda is too big

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:e2eab3c4edb6aa9a93f982c4554cd756000934ca

commit r13-5033-ge2eab3c4edb6aa9a93f982c4554cd756000934ca
Author: Jonathan Wakely 
Date:   Thu Jan 5 11:35:35 2023 +

libstdc++: Reduce size of std::bind_front(empty_type) result [PR108290]

libstdc++-v3/ChangeLog:

PR libstdc++/108290
* include/std/functional (_Bind_front): Add no_unique_address
attribute to data members.
* testsuite/20_util/function_objects/bind_front/107784.cc: Check
size of call wrappers with empty types for targets and bound
arguments.

[Bug libstdc++/108212] [13 Regression] pretty printers don't work with Python 2 due to imports for chrono

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:80ff207da6d8784e227eb93f75c4ac5a300c8420

commit r13-5034-g80ff207da6d8784e227eb93f75c4ac5a300c8420
Author: Jonathan Wakely 
Date:   Thu Jan 5 13:41:21 2023 +

libstdc++: Fix  printers for Python 2 [PR108212]

The datetime.timezone.utc singleton doesn't exist in Python 2, but we
can create it ourselves by deriving from datetime.tzinfo.

libstdc++-v3/ChangeLog:

PR libstdc++/108212
* python/libstdcxx/v6/printers.py (_utc_timezone): New global
variable.
(StdChronoTimePointPrinter::to_string): Use it.

[Bug ipa/108130] [13 Regression] LTO compile time hog seen on bootstrap-lto config since r13-4684-g7450b25566b7a7

[jamborm at gcc dot gnu.org via Gcc-bugs]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Jambor  ---
This has been fixed by Honza's r13-4998-gedc038863d88ef

posted in https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609406.html

If the undefined reference problem persists, it is a different issue.

[Bug c++/108299] toplevel thread_local variables are not initialized if not referenced and initialized at wrong moment when referenced

[agriff at tin dot it via Gcc-bugs]

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

--- Comment #9 from Andrea Griffini  ---
I agree that comment 0 is wrong and was based on a text that I thought was
taken from the standard but apparently was not (cppreference.com). Sorry for
the noise.

I think that if the dynamic initialization should be tied only to uses of other
thread locals requiring dynamic initialization this should be stated more
precisely in the standard text.

[Bug c++/108299] toplevel thread_local variables are not initialized if not referenced and initialized at wrong moment when referenced

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #8 from Jonathan Wakely  ---
FWIW the current wording in the standard was introduced by
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0250r3.html

[Bug c++/108299] toplevel thread_local variables are not initialized if not referenced and initialized at wrong moment when referenced

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from Jonathan Wakely  ---
Comment 0 seems wrong to me, there is no requirement that flag is initialized
if not odr-used, and if it is initialized, it doesn't have to happen before the
printf statement.

I agree that the standard says comment 3 should initialized both thread local
variables.

[Bug c++/108302] New: void fn (uint8_t auto... args); leads to internal compiler error: Segmentation fault

[lyubomir.filipov at amusnet dot com via Gcc-bugs]

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

Bug ID: 108302
   Summary: void fn (uint8_t auto... args);  leads to internal
compiler error: Segmentation fault
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lyubomir.filipov at amusnet dot com
  Target Milestone: ---

Hi
Trying to compile the following code:

#include 

void fn (uint8_t auto... args); 

Leads to internal compiler error:

In file included from /usr/include/stdint.h:37,
 from
/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/include/stdint.h:9,
 from /usr/include/c++/12.2.0/cstdint:41,
 from source.cpp:1:
/usr/include/bits/stdint-uintn.h:24:19: internal compiler error: Segmentation
fault
   24 | typedef __uint8_t uint8_t;
  |   ^~~
0x7f1cf4949fcf ???
   
/packages/base/glibc-2.36/signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x7f1cf49351c9 __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x7f1cf4935284 __libc_start_main_impl
../csu/libc-start.c:381
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.
The bug is not reproducible, so it is likely a hardware or OS problem.

Yes, I know that uint8_t auto is not supported by the C++ standard, but the
internal compiler error is a bit strange.

I am using Ubuntu 22.04 on 12th Gen Intel(R) Core(TM) i3-12100E

It happens with gcc 12.0, gcc 11.3. It also happens in compiler explorer with
the trunk version of gcc:

https://godbolt.org/z/41fxs18To

As it does happen with compiler explorer too, it looks like it is not related
to my OS or Hardware issue, as the gcc error log suggests.

[Bug c++/108299] toplevel thread_local variables are not initialized if not referenced and initialized at wrong moment when referenced

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||redi at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
CCing C++ committee members.
Requiring that any odr-uses of thread_local vars which have static
initialization (which strongly happens before any dynamic initialization) would
dynamically initialize all thread_local variables in the same TU declared
before such vars would have serious ABI and performance effects for no useful
gains.

[Bug target/105010] [12/13 regression] GCC 12 after 20220227 fails to build on powerpc64-freebsd with Error: invalid mfcr mask

[segher at gcc dot gnu.org via Gcc-bugs]

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

Segher Boessenkool  changed:

   What|Removed |Added

   Last reconfirmed||2023-01-05
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #22 from Segher Boessenkool  ---
(In reply to Piotr Kubaj from comment #21)
> I'm not sure whether it will help, but the issue only affects building
> 32-bit multilib libraries on powerpc64. That is, building a full 32-bit gcc
> for powerpc works just fine.

I can reproduce it with a simple testcase always.  It needs a powerpc64-freebsd
compiler, built with all default options.  With -m32 it still uses the 64-bit
processor, so equivalent to -mcpu=power4.  If you manually use -mcpu=7450 all
works fine.

[Bug rtl-optimization/108292] [13 Regression] wrong code with vector compare & mask at -O1 and above

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||sayle at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
So, we have ix86_expand_int_movcc called with operands:
(reg:SI 170)
(ne (reg:SI 86 [ _14 ])
(const_int 0 [0]))
(const_int 31 [0x1f])
(const_int 0 [0])
and the function emits:
(insn 42 0 43 (set (reg:CC 17 flags)
(compare:CC (reg:SI 86 [ _14 ])
(const_int 1 [0x1]))) "pr108292.c":9:5 -1
 (nil))

(insn 43 42 44 (parallel [
(set (reg:SI 171)
(if_then_else:SI (ltu:SI (reg:CC 17 flags)
(const_int 0 [0]))
(const_int -1 [0x])
(const_int 0 [0])))
(clobber (reg:CC 17 flags))
]) "pr108292.c":9:5 -1
 (expr_list:REG_EQUAL (neg:SI (ne:SI (reg:SI 86 [ _14 ])
(const_int 0 [0])))
(nil)))

(insn 44 43 45 (set (reg:SI 172)
(not:SI (reg:SI 171))) "pr108292.c":9:5 -1
 (nil))

(insn 45 44 46 (parallel [
(set (reg:SI 173)
(and:SI (reg:SI 172)
(const_int 31 [0x1f])))
(clobber (reg:CC 17 flags))
]) "pr108292.c":9:5 -1
 (nil))

(insn 46 45 0 (set (reg:SI 170)
(reg:SI 173)) "pr108292.c":9:5 -1
 (nil))
I believe the REG_EQUAL note is incorrect, it would be correct on insn 44,
pseudo 172 is r86 != 0 ? -1 : 0, while pseudo 171 is r86 == 0 ? -1 : 0.

[Bug c/108298] Wrong optimization of volatile access from gcc 11 and beyond

[segher at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Segher Boessenkool  ---
But please use PR33053 for that, or open a new PR?  Let's keep this one
for just this actual bug :-)

[Bug c++/108299] toplevel thread_local variables are not initialized if not referenced and initialized at wrong moment when referenced

[agriff at tin dot it via Gcc-bugs]

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

--- Comment #5 from Andrea Griffini  ---
So you are saying that the standard forgot to add "that requires dynamic
initialization" and that this is the intention?

[Bug c++/108299] toplevel thread_local variables are not initialized if not referenced and initialized at wrong moment when referenced

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Jakub Jelinek  ---
flag2 doesn't have dynamic initialization, if you add dynamic initialization to
it, you'll see that flag is constructed before flag2 and that happens before it
is referenced in the current thread (after the printf in main).

[Bug libstdc++/108288] Deadlock when using -fno-elide-constructor + -D_GLIBCXX_DEBUG=1 + -std=c++11

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Jonathan Wakely  ---
This was my reproducer, although it doesn't deadlock without the hack to use a
single mutex for all objects.

#define _GLIBCXX_DEBUG 1
#include 

int main()
{
  std::vector v{1,2,3};
  auto i = v.begin();
  return *i++;
}

[Bug libstdc++/108288] Deadlock when using -fno-elide-constructor + -D_GLIBCXX_DEBUG=1 + -std=c++11

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org

--- Comment #2 from Jonathan Wakely  ---
I reproduced it by reducing the size of the mutex pool to one, so they always
collide. And the patch above seems to fix it. I'll test it properly and push.

[Bug c++/108299] toplevel thread_local variables are not initialized if not referenced and initialized at wrong moment when referenced

[agriff at tin dot it via Gcc-bugs]

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

--- Comment #3 from Andrea Griffini  ---
Thread storage duration is different from static storage duration.

The text I found on the topic is different from the one you are linking,
but even in this version (that is indeed more permissive) it's explicitly
stated that a thread_local variable must be initialized before any other
thread_local variable is accessed in the same compilation unit.

> it is implementation-defined whether the dynamic initialization of a
> non-block non-inline variable with thread storage duration is sequenced
> before the first statement of the initial function of a thread or is deferred.

> 
> If it is deferred, the initialization associated with the entity for thread
> t is sequenced before the first non-initialization odr-use by t of any
> non-inline variable with thread storage duration defined in the same
> translation unit as the variable to be initialized.
> 

> It is implementation-defined in which threads and at which points in
> the program such deferred dynamic initialization occurs.

g++ doesn't seem to follow the rule


#include 

thread_local int flag = ([](){
printf("HERE!\n"); // This initialization never happens
return 1;
})();

thread_local int flag2;

int main() {
printf("Hello, world.\n");
flag2 = 0; // accesses another thread_local variable in same compilation
unit
return 0;
}

[Bug libstdc++/108288] Deadlock when using -fno-elide-constructor + -D_GLIBCXX_DEBUG=1 + -std=c++11

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Jonathan Wakely  ---
I've tried to reproduce this, but it depends on the addresses of the
_Safe_iterator objects that get created, because they'll use different mutexes
unless their addresses collide in the hash function.

Would you be able to test this patch?

--- a/libstdc++-v3/include/debug/safe_iterator.h
+++ b/libstdc++-v3/include/debug/safe_iterator.h
@@ -761,12 +761,9 @@ namespace __gnu_debug
   _Safe_iterator
   operator++(int) _GLIBCXX_NOEXCEPT
   {
-   _GLIBCXX_DEBUG_VERIFY(this->_M_incrementable(),
- _M_message(__msg_bad_inc)
- ._M_iterator(*this, "this"));
-   __gnu_cxx::__scoped_lock __l(this->_M_get_mutex());
-   return _Safe_iterator(this->base()++, this->_M_sequence,
- _Attach_single());
+   _Safe_iterator __ret = *this;
+   ++*this;
+   return __ret;
   }

   // -- Bidirectional iterator requirements --
@@ -788,12 +785,9 @@ namespace __gnu_debug
   _Safe_iterator
   operator--(int) _GLIBCXX_NOEXCEPT
   {
-   _GLIBCXX_DEBUG_VERIFY(this->_M_decrementable(),
- _M_message(__msg_bad_dec)
- ._M_iterator(*this, "this"));
-   __gnu_cxx::__scoped_lock __l(this->_M_get_mutex());
-   return _Safe_iterator(this->base()--, this->_M_sequence,
- _Attach_single());
+   _Safe_iterator __ret = *this;
+   --*this;
+   return __ret;
   }

   // -- Random access iterator requirements --

[Bug libstdc++/108288] Deadlock when using -fno-elide-constructor + -D_GLIBCXX_DEBUG=1 + -std=c++11

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2023-01-05
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

[Bug libstdc++/108290] QoI: bind_front captureless lambda is too big

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
 Status|NEW |ASSIGNED

[Bug rtl-optimization/108292] [13 Regression] wrong code with vector compare & mask at -O1 and above

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Jakub Jelinek  ---
The assembly difference is
-   movl$1, x+20(%rip)
+   movl$-6, x+20(%rip)
Now, that is the correct value to be stored into x[5] by the
__builtin_sub_overflow (0, 6, [5]);
statement, but each element is then shifted right by (element != 0) ? 31 : 0,
so in this case -6U >> 31 aka 1.

[Bug target/105010] [12/13 regression] GCC 12 after 20220227 fails to build on powerpc64-freebsd with Error: invalid mfcr mask

[pkubaj at anongoth dot pl via Gcc-bugs]

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

--- Comment #21 from Piotr Kubaj  ---
I'm not sure whether it will help, but the issue only affects building 32-bit
multilib libraries on powerpc64. That is, building a full 32-bit gcc for
powerpc works just fine.

[Bug libstdc++/108221] Building cross compiler for H8 family fails at libstdc++-v3/src/c++20/tzdb.cc

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Jonathan Wakely  ---
I have a workaround for this, but bootstrap still fails for me at:

/tmp/ccC7KXoL.s: Assembler messages:
/tmp/ccC7KXoL.s:82719: Error: value of 0001254e too large for field of 2 bytes
at 0002
make[6]: *** [Makefile:970: cp-demangle.lo] Error 1

[Bug demangler/107884] H8/300: cp-demangle.c fix warning related demangle.h

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2023-01-05
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

[Bug c/108301] New: GCC Static Analyzer evaluates "__analyzer_eval((!(((0 != b[0]) == p_9) && p_9)))" to be TRUE in the true branch of "if ((((0 != b[0]) == p_9) && p_9))"

[geoffreydgr at icloud dot com via Gcc-bugs]

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

Bug ID: 108301
   Summary: GCC Static Analyzer evaluates "__analyzer_eval((!(((0
!= b[0]) == p_9) && p_9)))" to be TRUE in the true
branch of "if 0 != b[0]) == p_9) && p_9))"
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: geoffreydgr at icloud dot com
  Target Milestone: ---

Hi, I found a problem that GCC Static Analyzer evaluates two contradictory
expressions to be true at the same time.  

The  two contradictory expressions are "__analyzer_eval(  0 != b[0]) ==
p_9))) && (p_9) );" and "__analyzer_eval(! 0 != b[0]) == p_9))) && (p_9)
);".

https://godbolt.org/z/GYj1oaxqr

Input:
```c
#include 
#include "stdint.h"
void __analyzer_eval(int a) {}

int foo(const int p_9)
{ 
  int a = 8;
  int b[2] ={1,1};

  for (int i = 0; i < 2; i++)
  {
b[i] = 1;
  }

lbl_1710:
  if 0 != b[0]) == p_9) && p_9))
  { 
__analyzer_eval(  0 != b[0]) == p_9))) && (p_9) );
__analyzer_eval(! 0 != b[0]) == p_9))) && (p_9) );

for (a = (1); (a != 2); ++a)
{ 
  if (-1)
  {
goto lbl_1710;
  }
}
  }

  return p_9;
}

int main(){}
```

Output:
```bash
: In function 'foo':
:18:5: warning: TRUE
   18 | __analyzer_eval(  0 != b[0]) == p_9))) && (p_9) );
  | ^
:19:5: warning: TRUE
   19 | __analyzer_eval(! 0 != b[0]) == p_9))) && (p_9) );
  | ^
:18:5: warning: UNKNOWN
   18 | __analyzer_eval(  0 != b[0]) == p_9))) && (p_9) );
  | ^
:19:5: warning: UNKNOWN
   19 | __analyzer_eval(! 0 != b[0]) == p_9))) && (p_9) );
  | ^
Compiler returned: 0

```

[Bug rtl-optimization/108292] [13 Regression] wrong code with vector compare & mask at -O1 and above

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-01-05
 Ever confirmed|0   |1

[Bug rtl-optimization/108292] [13 Regression] wrong code with vector compare & mask at -O1 and above

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |13.0

--- Comment #1 from Jakub Jelinek  ---
Started with r13-4977-gd0558f420b2a5692fd38ac76ffa97ae6c1726ed9

[Bug target/108293] Incorrect assembly emitted for float for BPF target

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Jakub Jelinek  ---
Another thing is that at least for all SFmode constant one could use mov
instead of lddw.

[Bug bootstrap/108300] `abort()` macro cause bootstrap failure on *-w64-mingw32

[lh_mouse at 126 dot com via Gcc-bugs]

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

--- Comment #2 from LIU Hao  ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to LIU Hao from comment #0)
> >   791 | #define abort() fancy_abort (__FILE__, __LINE__, __FUNCTION__)
> 
> The C++ standard says this is undefined.
> 
> We should do something like:
> 

I was almost going to submit a patch for mingw-w64 headers. If you think this
can be fixed for GCC 13, that's very kind of you, and please consider
backporting.

[Bug target/108293] Incorrect assembly emitted for float for BPF target

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
The bug is in bpf_print_operand:
case CONST_DOUBLE:
  if (CONST_DOUBLE_HIGH (op))
fprintf (file, HOST_WIDE_INT_PRINT_DOUBLE_HEX,
 CONST_DOUBLE_HIGH (op), CONST_DOUBLE_LOW (op));
  else if (CONST_DOUBLE_LOW (op) < 0)
fprintf (file, HOST_WIDE_INT_PRINT_HEX, CONST_DOUBLE_LOW (op));
  else
fprintf (file, HOST_WIDE_INT_PRINT_DEC, CONST_DOUBLE_LOW (op));
  break;
Obviously, the above handling is fine only for integral CONST_DOUBLEs, so for
floating point modes one needs to do something that other targets do, like:
  else if (CONST_DOUBLE_P (x) && GET_MODE (x) == SFmode)
{
  long l;

  REAL_VALUE_TO_TARGET_SINGLE (*CONST_DOUBLE_REAL_VALUE (x), l);
  fprintf (file, "0x%08x", (unsigned int) l);
}
for SFmode, or

  else if (CONST_DOUBLE_P (x) && GET_MODE (x) == DFmode)
{
  long l[2];

  REAL_VALUE_TO_TARGET_DOUBLE (*CONST_DOUBLE_REAL_VALUE (x), l);
  fprintf (file, "0x%lx%08lx", l[1] & 0x, l[0] & 0x);
}
for DFmode.

[Bug libstdc++/108221] Building cross compiler for H8 family fails at libstdc++-v3/src/c++20/tzdb.cc

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Jonathan Wakely  ---
This is a pre-existing problem that std::to_chars for floating-point types
doesn't work on these targets. Until I started to use std::format in
std/c++20/tzdb.cc the library wasn't using that, so the missing feature only
caused testsuite failures.

[Bug libstdc++/108265] chrono::hh_mm_ss can't be constructed from unsigned durations

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Jonathan Wakely  ---
and for 12.3