[Bug c++/108334] New: Strange message

[lukaszcz18 at wp dot pl via Gcc-bugs]

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

Bug ID: 108334
   Summary: Strange message
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lukaszcz18 at wp dot pl
  Target Milestone: ---

Strange message
In GCC version 20221124 this message wasn't there.

Using built-in specs.
COLLECT_GCC=g++.exe
Target: x86_64-w64-mingw32
Configured with: /home/ma/m/source/gcc-g/configure --host=x86_64-w64-mingw32
--target=x86_64-w64-mingw32 --disable-nls --enable-languages=c,c++,objc,obj-c++
--with-gmp=/home/ma/m/build/for_target --with-mpfr=/home/ma/m/build/for_target
--with-mpc=/home/ma/m/build/for_target --with-isl=/home/ma/m/build/for_target
--enable-twoprocess --disable-libstdcxx-pch --disable-win32-registry
--disable-shared --enable-fully-dynamic-string --enable-libssp
--prefix=/home/ma/m/target --with-sysroot=/home/ma/m/target
Thread model: win32
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20221229 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-std=gnu++11' '-march=x86-64-v2' '-ftree-vectorize'
'-g0' '-O3' '-fPIC' '-mavx' '-mxsave' '-mpclmul' '-maes' '-D' 'WINVER=0x0602'
'-D' '_WIN32_WINNT=0x0602' '-D' 'WIN32_LEAN_AND_MEAN=//' '-D'
'_WIN32_WINNT_WIN7=0x0601' '-D' 'LIBGAV1_THREADPOOL_USE_STD_MUTEX=1' '-D'
'LIBGAV1_MAX_BITDEPTH=12' '-D' 'LIBGAV1_PUBLIC=//' '-D' 'LIBGAV1_ENABLE_SSE4_1'
'-c' '-o' 'cdef.o'
 c:/gcc1300/bin/../libexec/gcc/x86_64-w64-mingw32/13.0.0/cc1plus.exe -quiet -v
-iprefix c:\gcc1300\bin\../lib/gcc/x86_64-w64-mingw32/13.0.0/ -U_REENTRANT -D
WINVER=0x0602 -D _WIN32_WINNT=0x0602 -D WIN32_LEAN_AND_MEAN=// -D
_WIN32_WINNT_WIN7=0x0601 -D LIBGAV1_THREADPOOL_USE_STD_MUTEX=1 -D
LIBGAV1_MAX_BITDEPTH=12 -D LIBGAV1_PUBLIC=// -D LIBGAV1_ENABLE_SSE4_1 cdef.cc
-quiet -dumpbase cdef.cc -dumpbase-ext .cc -march=x86-64-v2 -mavx -mxsave
-mpclmul -maes -g0 -O3 -std=gnu++11 -version -ftree-vectorize -fPIC -o
C:\Users\KOMPUT~1\AppData\Local\Temp\ccMZzeha.s
GNU C++11 (GCC) version 13.0.0 20221229 (experimental) (x86_64-w64-mingw32)
compiled by GNU C version 13.0.0 20221229 (experimental), GMP version
6.2.1, MPFR version 4.1.1, MPC version 1.3.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring duplicate directory
"c:/gcc1300/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../include/c++/13.0.0"
ignoring duplicate directory
"c:/gcc1300/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../include/c++/13.0.0/x86_64-w64-mingw32"
ignoring duplicate directory
"c:/gcc1300/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../include/c++/13.0.0/backward"
ignoring duplicate directory
"c:/gcc1300/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.0.0/include"
ignoring nonexistent directory
"/home/ma/m/target/home/ma/m/target/lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../include"
ignoring duplicate directory
"c:/gcc1300/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.0.0/include-fixed"
ignoring duplicate directory
"c:/gcc1300/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../x86_64-w64-mingw32/include"
ignoring nonexistent directory "/home/ma/m/target/mingw/include"
#include "..." search starts here:
#include <...> search starts here:

c:\gcc1300\bin\../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../include/c++/13.0.0

c:\gcc1300\bin\../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../include/c++/13.0.0/x86_64-w64-mingw32

c:\gcc1300\bin\../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../include/c++/13.0.0/backward
 c:\gcc1300\bin\../lib/gcc/x86_64-w64-mingw32/13.0.0/include
 c:\gcc1300\bin\../lib/gcc/x86_64-w64-mingw32/13.0.0/include-fixed

c:\gcc1300\bin\../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../x86_64-w64-mingw32/include
End of search list.
GNU C++11 (GCC) version 13.0.0 20221229 (experimental) (x86_64-w64-mingw32)
compiled by GNU C version 13.0.0 20221229 (experimental), GMP version
6.2.1, MPFR version 4.1.1, MPC version 1.3.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 764f1c9ee3426717f9fd65dfa7ce224a
In function 'void libgav1::{anonymous}::CopyPixels(const uint8_t*, int,
uint8_t*, int, int, int, size_t)',
inlined from 'void libgav1::PostFilter::ApplyCdefForOneUnit(uint16_t*, int,
int, int, int, int, uint8_t (*)[3][256], bool (*)[2]) [with Pixel = short
unsigned int]' at cdef.cc:330:15,
inlined from 'void
libgav1::PostFilter::ApplyCdefForOneSuperBlockRowHelper(uint16_t*, uint8_t
(*)[3][256], int, int)' at cdef.cc:612:36,
inlined from 'void libgav1::PostFilter::ApplyCdefForOneSuperBlockRow(int,
int, bool)' at cdef.cc:642:41:
cdef.cc:81:11: warning: writing 4 bytes into a region of size 0
[-Wstringop-overflow=]
   81 | memcpy(dst, src, width * pixel_size);
  | ~~^~
In member 

[Bug target/106459] Compiler crashing for loongarch64-linux-gnu on windows

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |12.4
 Status|UNCONFIRMED |RESOLVED

--- Comment #9 from Andrew Pinski  ---
Fixed.

[Bug driver/108328] gcc --help -v doesn't work correctly in some circumstances in gcc>=10

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

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

--- Comment #5 from Andrew Pinski  ---
So basically from what I understand is buildroot is doing this so they can
hardcode supporting only 4k pages. THIS IS BROKEN. Someone could build a kernel
and try to use a buildroot built sysroot and it will break ...

[Bug driver/108328] gcc --help -v doesn't work correctly in some circumstances in gcc>=10

[sagimor6 at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Sagi Mor  ---
created a bug report on buildroot as a workaround for the time being:

https://bugs.busybox.net/show_bug.cgi?id=15231

[Bug c++/98995] [10/11/12/13 Regression] Copy elision not applied to members declared with [[no_unique_address]]

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|11.4|10.5
Summary|[11/12/13 Regression] Copy  |[10/11/12/13 Regression]
   |elision not applied to  |Copy elision not applied to
   |members declared with   |members declared with
   |[[no_unique_address]]   |[[no_unique_address]]

[Bug c++/98995] [11/12/13 Regression] Copy elision not applied to members declared with [[no_unique_address]]

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||yronglin777 at gmail dot com

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

[Bug c++/108333] [10/11/12/13/trunk Regression] no_unique_address and direct-non-list-initialization is rejected

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Andrew Pinski  ---
Dup of bug 98995.  See bug 98995 comment #2 on why this is even a language/ABI
issue and it is currently suspended as it might not be a legal thing to do ...

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

[Bug c++/108333] [10/11/12/13/trunk Regression] The behavior of direct-non-list-initialized is not correct, parsing error on valid code

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |10.5
Summary|[10.3/10.4/11/12/13/trunk   |[10/11/12/13/trunk
   |Regression] The behavior of |Regression] The behavior of
   |direct-non-list-initialized |direct-non-list-initialized
   |is not correct, parsing |is not correct, parsing
   |error on valid code |error on valid code

[Bug c++/108333] New: [10.3/10.4/11/12/13/trunk Regression] The behavior of direct-non-list-initialized is not correct, parsing error on valid code

[yronglin777 at gmail dot com via Gcc-bugs]

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

Bug ID: 108333
   Summary: [10.3/10.4/11/12/13/trunk Regression] The behavior of
direct-non-list-initialized is not correct, parsing
error on valid code
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yronglin777 at gmail dot com
  Target Milestone: ---

GCC parsing error on valid code:

Compiler Explorer: https://godbolt.org/z/K6edrdTG5 (Thanks Nikolas Klauser)

```
struct NonCopyable {
  NonCopyable(int) {}
  NonCopyable(const NonCopyable&) = delete;
};

struct S {
  S(int i) : val(NonCopyable{1}) {}

  [[no_unique_address]] NonCopyable val;
};

struct T {
  T(int i) : val(NonCopyable{1}) {}

  NonCopyable val;
};

```

This code accept by GCC[9/10.1/10.2], clang and MSVC, but compile failed with
GCC[10.3/10.4/11/12/13/trunk], seems a regression.

[Bug testsuite/108192] g++.dg/cet-notrack-1.C searching for wrong function on mingw

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to jon_y from comment #4)
> Is Nightstrike's patch OK?

I think it is correct but patches should goto gcc-patches@ really.

[Bug testsuite/108192] g++.dg/cet-notrack-1.C searching for wrong function on mingw

[10walls at gmail dot com via Gcc-bugs]

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

jon_y <10walls at gmail dot com> changed:

   What|Removed |Added

 CC||10walls at gmail dot com

--- Comment #4 from jon_y <10walls at gmail dot com> ---
Is Nightstrike's patch OK?

[Bug testsuite/108150] gcc.dg/attr-aligned.c fails with incorrect max alignment

[10walls at gmail dot com via Gcc-bugs]

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

--- Comment #3 from jon_y <10walls at gmail dot com> ---
Created attachment 54211
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54211=edit
Fix attempt 1

Makes errors emitted same as on Linux.

[Bug libstdc++/108331] [13 Regression] ABI break of std::__c_file and std::fstream for win32 thread model of GCC for windows

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

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

--- Comment #3 from Eric Botcazou  ---
> Eric, can we add a new macro to gthr-win32.h that says "this is the win32
> thread model" which libstdc++ can then use like so:

Sure, but can't we define a __GTHREAD_TYPE_FOR_HISTORICAL_MUTEX macro instead
that would expand to a __gthread_historical_mutex_t defined in gthr-win32.h?
Or something along these lines or with better monikers.

[Bug libstdc++/108332] dynamic link libstdc++ with win32 thread model's gcc for windows native toolchain would cause .rdata_r: section below image base

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #4 from cqwrteur  ---
(In reply to Andrew Pinski from comment #3)
> cygwin was improved here:
> https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;
> h=801120c1f402f9b0f72b5a231bf9e1cf82614cac
> 
> It might be the case mingw linker script is broken 

This is mingw-w64, not newlib-cygwin

[Bug libstdc++/108332] dynamic link libstdc++ with win32 thread model's gcc for windows native toolchain would cause .rdata_r: section below image base

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

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

--- Comment #3 from Andrew Pinski  ---
cygwin was improved here:
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=801120c1f402f9b0f72b5a231bf9e1cf82614cac

It might be the case mingw linker script is broken 

[Bug libstdc++/108332] dynamic link libstdc++ with win32 thread model's gcc for windows native toolchain would cause .rdata_r: section below image base

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

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

--- Comment #2 from Andrew Pinski  ---
https://sourceware.org/pipermail/binutils-cvs/2021-March/056031.html

[Bug libstdc++/108332] dynamic link libstdc++ with win32 thread model's gcc for windows native toolchain would cause .rdata_r: section below image base

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

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

--- Comment #1 from Andrew Pinski  ---
This seems like a binutils ld bug rather than a libstdc++ bug ...

[Bug libstdc++/108332] New: dynamic link libstdc++ with win32 thread model's gcc for windows native toolchain would cause .rdata_r: section below image base

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 108332
   Summary: dynamic link libstdc++ with win32 thread model's gcc
for windows native toolchain would cause .rdata_r:
section below image base
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

g++ -o helloworld helloworld.cc -Ofast -std=c++23 -s -flto -march=native
-I../../include -static

//ok no issue

g++ -o helloworld helloworld.cc -Ofast -std=c++23 -s -flto -march=native
-I../../include
d:/x86_64-windows-gnu/x86_64-w64-mingw32/bin/../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
helloworld.exe:.rdata_r: section below image base

Do not know whether it is an issue for mingw-w64 or libstdc++

[Bug libstdc++/108327] [13 Regression] Lots of libstdc++ FAILs on powerpc64le-linux

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

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

--- Comment #2 from Jakub Jelinek  ---
Yes, I wrote:
on --with-long-double-128  --with-long-double-format=ieee powerpc64le-linux.
above.  It was a Fedora package build actually:
https://kojipkgs.fedoraproject.org/packages/gcc/13.0.0/0.4.fc38/
and same happens in
https://koji.fedoraproject.org/koji/taskinfo?taskID=95815427
that is currently building.

[Bug libstdc++/108327] [13 Regression] Lots of libstdc++ FAILs on powerpc64le-linux

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

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

--- Comment #1 from Jonathan Wakely  ---
I assume this is with --with-long-double-format=ieee ? I don't see it when
testing without that. I'm building with that option now and re-testing.

[Bug libstdc++/108331] [13 Regression] ABI break of std::__c_file and std::fstream for win32 thread model of GCC for windows

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

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #1)
> --- a/libstdc++-v3/config/io/c_io_stdio.h
> +++ b/libstdc++-v3/config/io/c_io_stdio.h
> @@ -39,7 +39,17 @@ namespace std _GLIBCXX_VISIBILITY(default)
>  {
>  _GLIBCXX_BEGIN_NAMESPACE_VERSION
>  
> +#ifdef __GTHREAD_WIN32
> +  // The layout of __gthread_mutex_t changed in GCC 13, but libstdc++
> doesn't
> +  // actually use the basic_filebuf::_M_lock member, so define it
> consistently
> +  // with the old __gthread_mutex_t to avoid an unnecessary layout change:
> +  struct __c_lock {
> +long counter;
> +void *sema;

We should use reserved names here, like __unused1 and __unused2.

> +  };
> +#else
>typedef __gthread_mutex_t __c_lock;
> +#endif
>  
>// for basic_file.h
>typedef FILE __c_file;

[Bug libstdc++/108331] [13 Regression] ABI break of std::__c_file and std::fstream for win32 thread model of GCC for windows

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org
   Last reconfirmed||2023-01-07
 Ever confirmed|0   |1
Summary|ABI break of std::__c_file  |[13 Regression] ABI break
   |and std::fstream for win32  |of std::__c_file and
   |thread model of GCC for |std::fstream for win32
   |windows |thread model of GCC for
   ||windows
   Target Milestone|--- |13.0
   Keywords||ABI
 Status|UNCONFIRMED |NEW

--- Comment #1 from Jonathan Wakely  ---
(In reply to cqwrteur from comment #0)
> I do not understand why you need a mutex for std::fstream.

It is there for historical reasons, it's completely unused.

> Now win32, posix
> and mcf thread model they cause abi issues for this due to that lock. Can we
> unify the abi for windows here?

No. The thread model is already ABI-changing, there is no way to make
std::mutex ABI compatible when it has a wildly different implementation.

But the std::basic_filebuf::_M_lock member does indeed change layout for the
win32 thread model between GCC 12 and GCC 13. We can't make the ABI consistent
between different thread models, but we do want it to be consistent for a
single thread model.

Since that mutex is unused anyway, we should just define it consistently with
GCC 12 for the win32 thread model, i.e. as a struct like:

typedef struct {
  long counter;
  void *sema;
} __gthread_mutex_t;

Eric, can we add a new macro to gthr-win32.h that says "this is the win32
thread model" which libstdc++ can then use like so:

--- a/libstdc++-v3/config/io/c_io_stdio.h
+++ b/libstdc++-v3/config/io/c_io_stdio.h
@@ -39,7 +39,17 @@ namespace std _GLIBCXX_VISIBILITY(default)
 {
 _GLIBCXX_BEGIN_NAMESPACE_VERSION

+#ifdef __GTHREAD_WIN32
+  // The layout of __gthread_mutex_t changed in GCC 13, but libstdc++ doesn't
+  // actually use the basic_filebuf::_M_lock member, so define it consistently
+  // with the old __gthread_mutex_t to avoid an unnecessary layout change:
+  struct __c_lock {
+long counter;
+void *sema;
+  };
+#else
   typedef __gthread_mutex_t __c_lock;
+#endif

   // for basic_file.h
   typedef FILE __c_file;

[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

   See Also||https://sourceware.org/bugz
   ||illa/show_bug.cgi?id=29966
 Status|WAITING |RESOLVED
 Resolution|--- |MOVED

--- Comment #21 from Jonathan Wakely  ---
(In reply to cqwrteur from comment #18)
> The solution would probably be for libstdc++ to guard against
> __GHTREAD_HAS_COND instead

No it wouldn't, you don't know what you're talking about.

That's defined under exactly the same condition as the __GTHREADS_CXX0X macro
that libstdc++ uses, so it would make no difference at all.

This is a GDB bug which has a configure check for std::thread which doesn't
work with GCC 13. See the linked GDB bug report.

[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 #20 from cqwrteur  ---
(In reply to cqwrteur from comment #19)
> (In reply to cqwrteur from comment #18)
> > (In reply to cqwrteur from comment #17)
> > > (In reply to Eric Botcazou from comment #16)
> > > > > #if _WIN32_WINNT >= 0x0600
> > > > > #define __GTHREAD_HAS_COND 1
> > > > > #define __GTHREADS_CXX0X 1
> > > > > #endif
> > > > > 
> > > > > I suggest remove this macro in the header due to potential breakage
> > > > > 
> > > > > #if _WIN32_WINNT >= 0x0600
> > > > > #endif
> > > > 
> > > > That's nonsensical.
> > > 
> > > The problem is that libstdc++ would instantly break if someone randomly
> > > defines _WIN32_WINNT (like gdb does).
> > 
> > The solution would probably be for libstdc++ to guard against
> > __GHTREAD_HAS_COND instead
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=29966

D:\msys64\home\unlvs\projects\fast_io\examples\0001.helloworld>g++ -o
helloworld helloworld.cc -Ofast -std=c++23 -s -flto -march=native
-I../../include
d:/x86_64-windows-gnu/x86_64-w64-mingw32/bin/../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
helloworld.exe:.rdata_r: section below image base

Do not know why.

[Bug libstdc++/108327] [13 Regression] Lots of libstdc++ FAILs on powerpc64le-linux

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-01-07
 Ever confirmed|0   |1

[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 #19 from cqwrteur  ---
(In reply to cqwrteur from comment #18)
> (In reply to cqwrteur from comment #17)
> > (In reply to Eric Botcazou from comment #16)
> > > > #if _WIN32_WINNT >= 0x0600
> > > > #define __GTHREAD_HAS_COND 1
> > > > #define __GTHREADS_CXX0X 1
> > > > #endif
> > > > 
> > > > I suggest remove this macro in the header due to potential breakage
> > > > 
> > > > #if _WIN32_WINNT >= 0x0600
> > > > #endif
> > > 
> > > That's nonsensical.
> > 
> > The problem is that libstdc++ would instantly break if someone randomly
> > defines _WIN32_WINNT (like gdb does).
> 
> The solution would probably be for libstdc++ to guard against
> __GHTREAD_HAS_COND instead

https://sourceware.org/bugzilla/show_bug.cgi?id=29966

[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 #18 from cqwrteur  ---
(In reply to cqwrteur from comment #17)
> (In reply to Eric Botcazou from comment #16)
> > > #if _WIN32_WINNT >= 0x0600
> > > #define __GTHREAD_HAS_COND 1
> > > #define __GTHREADS_CXX0X 1
> > > #endif
> > > 
> > > I suggest remove this macro in the header due to potential breakage
> > > 
> > > #if _WIN32_WINNT >= 0x0600
> > > #endif
> > 
> > That's nonsensical.
> 
> The problem is that libstdc++ would instantly break if someone randomly
> defines _WIN32_WINNT (like gdb does).

The solution would probably be for libstdc++ to guard against
__GHTREAD_HAS_COND instead

[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|WAITING
 Resolution|WONTFIX |---

--- Comment #17 from cqwrteur  ---
(In reply to Eric Botcazou from comment #16)
> > #if _WIN32_WINNT >= 0x0600
> > #define __GTHREAD_HAS_COND 1
> > #define __GTHREADS_CXX0X 1
> > #endif
> > 
> > I suggest remove this macro in the header due to potential breakage
> > 
> > #if _WIN32_WINNT >= 0x0600
> > #endif
> 
> That's nonsensical.

The problem is that libstdc++ would instantly break if someone randomly defines
_WIN32_WINNT (like gdb does).

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

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

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

Eric Botcazou  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|REOPENED|RESOLVED

--- Comment #16 from Eric Botcazou  ---
> #if _WIN32_WINNT >= 0x0600
> #define __GTHREAD_HAS_COND 1
> #define __GTHREADS_CXX0X 1
> #endif
> 
> I suggest remove this macro in the header due to potential breakage
> 
> #if _WIN32_WINNT >= 0x0600
> #endif

That's nonsensical.

[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

 Resolution|WONTFIX |---
 Status|RESOLVED|REOPENED

--- Comment #15 from cqwrteur  ---
(In reply to Jonathan Wakely from comment #14)
> 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.

#if _WIN32_WINNT >= 0x0600
#define __GTHREAD_HAS_COND 1
#define __GTHREADS_CXX0X 1
#endif

I suggest remove this macro in the header due to potential breakage

#if _WIN32_WINNT >= 0x0600
#endif

[Bug libstdc++/108331] New: ABI break of std::__c_file and std::fstream for win32 thread model of GCC for windows

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 108331
   Summary: ABI break of std::__c_file and std::fstream for win32
thread model of GCC for windows
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

The recent win32 thread model changes cause abi break of std::fstream due to
layout silently change.

I do not understand why you need a mutex for std::fstream. Now win32, posix and
mcf thread model they cause abi issues for this due to that lock. Can we unify
the abi for windows here?

[Bug target/102783] [powerpc] FPSCR manipulations cannot be relied upon

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

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

--- Comment #12 from Marc Glisse  ---
(In reply to Marc Glisse from comment #11)
> Since I had forgotten where it was, let me write here that it is git branch
> /users/glisse/fenv

Since it became impossible (hooks) to push to that branch a while ago, I should
post somewhere the FIXME file I couldn't push last year:

Looking at LLVM, I notice that my design in the gcc fenv branch seems to be
missing a fundamental piece: it has nothing preventing "normal" operations from
outside from migrating towards the protected region, where they may end up
using an unexpected rounding mode (unprotected doesn't mean any rounding mode,
it means the default one), or setting flags that we will observe.
One idea to prevent this would be to make sure that there are no normal FP
operations in functions that have protected operations (does that mean we
should mark functions? Just checking if there is a protected FP op doesn't work
if we call a function that does the op).
This means that we should turn all FP operations of the function into protected
ones (possibly with more relaxed flags if they are not in the protected
region), and we should also do that whenever inlining mixed functions. And
cross my fingers that the compiler doesn't start using FP ops out of thin air.
Would that be sufficient?

[Bug middle-end/108249] cc1plus segmentation fault compiling Marlin on RPI3

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

--- Comment #5 from Andrew Pinski  ---
.

[Bug middle-end/108249] cc1plus segmentation fault compiling Marlin on RPI3

[steinhelten at gmail dot com via Gcc-bugs]

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

John Lind  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from John Lind  ---
Apparently, it was a corrupted install.  Reinstalled and the segfault went
away.

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

[arsen at aarsen dot me via Gcc-bugs]

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

--- Comment #11 from Arsen Arsenović  ---
(In reply to LIU Hao from comment #10)
> I think Jonathan's proposal makes it unnecessarily complex. Renaming `abort`
> to `gcc_fancy_abort`, as well as all invocations accordingly, should be much
> simpler than those inline functions and `__builtin_*` stuff.

This feels like an increase in development overhead and potential for error. 
The approach described by Jonathan is pretty standard, and it doesn't really
have a cost at all.

[Bug lto/108330] [13 Regression] ICE in add, at hash-set.h:64

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug c++/107616] c++tools: select not found breaks build

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

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

--- Comment #2 from John David Anglin  ---
Patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609536.html

[Bug fortran/108329] IEEE_SET_ROUNDING_MODE ineffective with common subexpression elimination

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

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

Thomas Koenig  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-01-07
   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED

[Bug libstdc++/108326] Question about definitions in c++config.h for gcc13 20221229

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

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Jamaika from comment #0)
> Amateur questions
> I know that creating exe files two years ago with ,  with
> _GLIBCXX_HAS_GTHREADS definition was impossible.

This is just nonsense, so I assume you mean impossible when using mingw without
libwinpthread. It works fine on most targets, and for mingw-w64 when using
libwinpthread.

[Bug libstdc++/108326] Question about definitions in c++config.h for gcc13 20221229

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Bugzilla is for bugs, questions belong on the mailing lists.

https://gcc.gnu.org/lists.html

(In reply to Jamaika from comment #0)
> Why is _GLIBCXX_HAS_GTHREADS enabled only for C++20 and above in ?

It's not, so I don't know what you mean.

[Bug middle-end/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 #10 from LIU Hao  ---
(In reply to Arsen Arsenović from comment #9)
> (In reply to LIU Hao from comment #8)
> > The commit above just lets GCC bootstrap on Windows. The cause of this issue
> > is still there.
> > 
> > Maybe it's possible to replace all direct calls to `abort()` in gcc and
> > libcpp with `fancy_abort (__FILE__, __LINE__, __FUNCTION__)`, and eventually
> > get rid of that macro.
> 
> See Jonathans comment above.  I'll do that refactor this week, likely.

I think Jonathan's proposal makes it unnecessarily complex. Renaming `abort` to
`gcc_fancy_abort`, as well as all invocations accordingly, should be much
simpler than those inline functions and `__builtin_*` stuff.

[Bug fortran/108329] IEEE_SET_ROUNDING_MODE ineffective with common subexpression elimination

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

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

--- Comment #2 from Thomas Koenig  ---
(In reply to Thomas Koenig from comment #1)
> As long as PR 36678

That should be PR 34678 .

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

[arsen at aarsen dot me via Gcc-bugs]

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

--- Comment #9 from Arsen Arsenović  ---
(In reply to LIU Hao from comment #8)
> The commit above just lets GCC bootstrap on Windows. The cause of this issue
> is still there.
> 
> Maybe it's possible to replace all direct calls to `abort()` in gcc and
> libcpp with `fancy_abort (__FILE__, __LINE__, __FUNCTION__)`, and eventually
> get rid of that macro.

See Jonathans comment above.  I'll do that refactor this week, likely.

[Bug middle-end/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 #8 from LIU Hao  ---
The commit above just lets GCC bootstrap on Windows. The cause of this issue is
still there.

Maybe it's possible to replace all direct calls to `abort()` in gcc and libcpp
with `fancy_abort (__FILE__, __LINE__, __FUNCTION__)`, and eventually get rid
of that macro.

[Bug lto/108330] New: [13 Regression] ICE in add, at hash-set.h:64

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 108330
   Summary: [13 Regression] ICE in add, at hash-set.h:64
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, lto
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

gcc 13.0.0 20230101 snapshot (g:4f1314f547f69d3a2b1f16ce301267e3bfb4e427) ICEs
when compiling gcc/testsuite/g++.dg/pr82128.C w/ -flto:

% g++-13 -flto -c gcc/testsuite/g++.dg/pr82128.C
during IPA pass: modref
gcc/testsuite/g++.dg/pr82128.C:20:1: internal compiler error: in add, at
hash-set.h:64
   20 | }
  | ^
0x7fdc6d hash_set >::add(void* const&)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20230101/work/gcc-13-20230101/gcc/hash-set.h:64
0x7fdc6d hash_set >::add(void* const&)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20230101/work/gcc-13-20230101/gcc/hash-set.h:56
0x7fdc6d compute_ltrans_boundary(lto_symtab_encoder_d*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20230101/work/gcc-13-20230101/gcc/lto-cgraph.cc:921
0x10fa1df ipa_write_summaries()
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20230101/work/gcc-13-20230101/gcc/passes.cc:2897
0xd34497 ipa_passes
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20230101/work/gcc-13-20230101/gcc/cgraphunit.cc:2218
0xd34497 symbol_table::compile()
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20230101/work/gcc-13-20230101/gcc/cgraphunit.cc:2291
0xd36ef7 symbol_table::compile()
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20230101/work/gcc-13-20230101/gcc/cgraphunit.cc:2271
0xd36ef7 symbol_table::finalize_compilation_unit()
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20230101/work/gcc-13-20230101/gcc/cgraphunit.cc:2543

[Bug tree-optimization/89098] ICE: verify_ssa failed (Error: definition in block 27 follows the use)

[asolokha at gmx dot com via Gcc-bugs]

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

--- Comment #3 from Arseny Solokha  ---
While the C testcase in comment 2 is definitely much shorter, current gcc 13
snapshot ICEs on gcc/testsuite/gcc.target/i386/pr63448.c w/ -O1
-fkeep-gc-roots-live --param max-slsr-cand-scan=1.

[Bug fortran/108329] IEEE_SET_ROUNDING_MODE ineffective with common subexpression elimination

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

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

Thomas Koenig  changed:

   What|Removed |Added

Version|unknown |13.0
 Depends on||34678
   Keywords||wrong-code
 Blocks||105105

--- Comment #1 from Thomas Koenig  ---
As long as PR 36678 is not fixed, I see one possible solution in
putting a memory barrier after ieee_set_rounding_mode.

This is a rather big hammer, but as long as the middle-end issue
is not fixed, I do not see an alternative.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
[Bug 34678] Optimization generates incorrect code with -frounding-math option
(#pragma STDC FENV_ACCESS not implemented)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105105
[Bug 105105] [Meta] Fortran IEEE support

[Bug fortran/108329] New: IEEE_SET_ROUNDING_MODE ineffective with common subexpression elimination

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

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

Bug ID: 108329
   Summary: IEEE_SET_ROUNDING_MODE ineffective with common
subexpression elimination
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

Split from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678#c47 .

The test case

$ cat y.f90
module y
  implicit none
  integer, parameter :: wp = selected_real_kind(15)
contains
  subroutine foo(a,b,c)
use ieee_arithmetic
real(kind=wp), dimension(4), intent(out) :: a
real(kind=wp), intent(in) :: b, c
type (ieee_round_type), dimension(4), parameter :: mode = &
 [ieee_nearest, ieee_to_zero, ieee_up, ieee_down]
call ieee_set_rounding_mode (mode(1))
a(1) = b + c
call ieee_set_rounding_mode (mode(2))
a(2) = b + c
call ieee_set_rounding_mode (mode(3))
a(3) = b + c
call ieee_set_rounding_mode (mode(4))
a(4) = b + c
  end subroutine foo
end module y

program main
  use y
  real(kind=wp), dimension(4) :: a
  call foo(a, 0.1_wp, 0.2_wp)
  print *,a
end program main
$ gfortran -O  y.f90 && ./a.out
  0.30004   0.30004   0.30004  
0.30004 
$ gfortran y.f90 && ./a.out
  0.30004   0.2   0.30004  
0.2

shows that common subexpression removal causes the addition to be performed
only once.

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

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

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

--- Comment #49 from Thomas Koenig  ---
(In reply to Thomas Koenig from comment #48)
> Clang gets this right, even without the pragma;

The "even without the pragma" part is wrong.

[Bug driver/108328] gcc --help -v doesn't work correctly in some circumstances in gcc>=10

[sagimor6 at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Sagi Mor  ---
I agree that the python check is broken, but I do think that the current
behavior is incorrect. it doesn't make sense that for N input file, the help
will be displayed N times. and that linker options suppress the help message.

The comment in the code above the if statement ("Ensure we only invoke each
subprocess once.") shows this was the intention, and the commit I talked about
broke it without noticing.

The fact that this worked till gcc 9.x.x, and stopped working from gcc 10.x.x,
also says that this is not the intended behavior, in my opinion.

[Bug c++/108324] Temporary not bound to reference in default member initializer destroyed early from parenthesized expression-list initialization of aggregate

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

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

--- Comment #1 from Andrew Pinski  ---
MSVC rejects it for the same reason as GCC:

(15): error C2131: expression did not evaluate to a constant
(11): note: a non-constant (sub-)expression was encountered
(16): error C2369: 'k': redefinition; different subscripts
(15): note: see declaration of 'k'

Note clang rejects both array definitions thinking it is a VLA 

[Bug driver/108328] gcc --help -v doesn't work correctly in some circumstances in gcc>=10

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

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

--- Comment #2 from Andrew Pinski  ---
I think this behavior is correctly documented too:
If the -v option is also specified then --help is also passed on to the various
processes invoked by gcc, so that they can display the command-line options
they accept. 

With -Wl,x you only invoke collect2(ld).

That is how it has been documented too.

I think just python configure is broken.

[Bug driver/108328] gcc --help -v doesn't work correctly in some circumstances in gcc>=10

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

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

--- Comment #1 from Andrew Pinski  ---
Considering -fwrapv has been there since GCC 3.4.0, I think python should just
change how their configuring.
-fwrapv was added in r0-50210-g4fa26a60791ec3 .

[Bug driver/108328] New: gcc --help -v doesn't work correctly in some circumstances in gcc>=10

[sagimor6 at gmail dot com via Gcc-bugs]

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

Bug ID: 108328
   Summary: gcc --help -v doesn't work correctly in some
circumstances in gcc>=10
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sagimor6 at gmail dot com
  Target Milestone: ---

Created attachment 54210
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54210=edit
patch to fix the bug

works:
gcc --help -v 2>/dev/null | grep ffunction-sections

(prints the ffunction-section description)

doesn't work:
gcc -Wl,--some-flag --help -v 2>/dev/null | grep ffunction-sections

(nothing is printed)
I am sure that this behavior is incorrect.

also (but maybe less important):
gcc a.c a.c a.c a.c --help -v 2>/dev/null | grep ffunction-sections

this prints the help 4 times (as many times as there are input files).
I am also sure that this behavior is incorrect. 

Some programs depend on --help -v to work, for example python. python checks if
fwrapv is supported with the mechanism. buildroot uses something called
toolchain-wrapper to add default flags to gcc when you call it, if you would
check the bootlin compilers in aarch64 they add -Wl,-z,relro by default. So, if
you were to compile python with a bootlin compiler with gcc>=10 it will not
compile with all the correct flags (no fwrapv).
This is just one example (this is where I noticed the bug).


The bug was introduced in the following commit:
https://github.com/gcc-mirror/gcc/commit/2dcfc8722b6146e479039a2f8994050c772b25e6
(commit 2dcfc8722b6146e479039a2f8994050c772b25e6)

So the bug only exists in gcc>=10, and doesn't in gcc<=9.

I created a patch to revert a small part of this commit (will send to the gcc
patches mailing list as well). I tested the patch.

One of the reasons I am sure this is a bug is because of the comment above the
if statement: "Ensure we only invoke each subprocess once.", so the help should
be printed once and only once.

[Bug libstdc++/108326] Question about definitions in c++config.h for gcc13 20221229

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||*-*-mingw

--- Comment #1 from Andrew Pinski  ---
r13-4881-g9149a5b7e0a66b improved GNU threads library on native Windows so 
I think this is by design ...

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

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

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

--- Comment #48 from Thomas Koenig  ---
Clang gets this right, even without the pragma; the original test case is
compiled to

pushq   %r14
pushq   %rbx
subq$24, %rsp
movq%rsi, %r14
movq%rdi, %rbx
movsd   %xmm1, 16(%rsp) # 8-byte Spill
movsd   %xmm0, 8(%rsp)  # 8-byte Spill
movl$1024, %edi # imm = 0x400
callq   fesetround@PLT
movsd   8(%rsp), %xmm0  # 8-byte Reload
divsd   16(%rsp), %xmm0 # 8-byte Folded Reload
movsd   %xmm0, (%rbx)
movl$2048, %edi # imm = 0x800
callq   fesetround@PLT
movsd   8(%rsp), %xmm0  # 8-byte Reload
divsd   16(%rsp), %xmm0 # 8-byte Folded Reload
movsd   %xmm0, (%r14)
addq$24, %rsp
popq%rbx
popq%r14
retq

[Bug libstdc++/108327] [13 Regression] Lots of libstdc++ FAILs on powerpc64le-linux

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug libstdc++/108327] New: [13 Regression] Lots of libstdc++ FAILs on powerpc64le-linux

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

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

Bug ID: 108327
   Summary: [13 Regression] Lots of libstdc++ FAILs on
powerpc64le-linux
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

I see
FAIL: libstdc++-abi/abi_check
FAIL: 22_locale/money_get/get/char/14.cc (test for excess errors)
UNRESOLVED: 22_locale/money_get/get/char/14.cc compilation failed to produce
executable
FAIL: 22_locale/money_get/get/char/19.cc (test for excess errors)
UNRESOLVED: 22_locale/money_get/get/char/19.cc compilation failed to produce
executable
FAIL: 22_locale/money_get/get/char/22131.cc (test for excess errors)
UNRESOLVED: 22_locale/money_get/get/char/22131.cc compilation failed to produce
executable
FAIL: 22_locale/money_get/get/char/38399.cc (test for excess errors)
UNRESOLVED: 22_locale/money_get/get/char/38399.cc compilation failed to produce
executable
FAIL: 22_locale/money_get/get/char/39168.cc (test for excess errors)
UNRESOLVED: 22_locale/money_get/get/char/39168.cc compilation failed to produce
executable
FAIL: 22_locale/money_get/get/char/6.cc (test for excess errors)
UNRESOLVED: 22_locale/money_get/get/char/6.cc compilation failed to produce
executable
FAIL: 22_locale/money_get/get/char/7.cc (test for excess errors)
UNRESOLVED: 22_locale/money_get/get/char/7.cc compilation failed to produce
executable
FAIL: 22_locale/money_get/get/char/8.cc (test for excess errors)
UNRESOLVED: 22_locale/money_get/get/char/8.cc compilation failed to produce
executable
FAIL: 22_locale/money_get/get/wchar_t/14.cc (test for excess errors)
UNRESOLVED: 22_locale/money_get/get/wchar_t/14.cc compilation failed to produce
executable
FAIL: 22_locale/money_get/get/wchar_t/19.cc (test for excess errors)
UNRESOLVED: 22_locale/money_get/get/wchar_t/19.cc compilation failed to produce
executable
FAIL: 22_locale/money_get/get/wchar_t/22131.cc (test for excess errors)
UNRESOLVED: 22_locale/money_get/get/wchar_t/22131.cc compilation failed to
produce executable
FAIL: 22_locale/money_get/get/wchar_t/38399.cc (test for excess errors)
UNRESOLVED: 22_locale/money_get/get/wchar_t/38399.cc compilation failed to
produce executable
FAIL: 22_locale/money_get/get/wchar_t/39168.cc (test for excess errors)
UNRESOLVED: 22_locale/money_get/get/wchar_t/39168.cc compilation failed to
produce executable
FAIL: 22_locale/money_get/get/wchar_t/6.cc (test for excess errors)
UNRESOLVED: 22_locale/money_get/get/wchar_t/6.cc compilation failed to produce
executable
FAIL: 22_locale/money_get/get/wchar_t/7.cc (test for excess errors)
UNRESOLVED: 22_locale/money_get/get/wchar_t/7.cc compilation failed to produce
executable
FAIL: 22_locale/money_get/get/wchar_t/8.cc (test for excess errors)
UNRESOLVED: 22_locale/money_get/get/wchar_t/8.cc compilation failed to produce
executable
FAIL: 22_locale/money_put/put/char/12971.cc (test for excess errors)
UNRESOLVED: 22_locale/money_put/put/char/12971.cc compilation failed to produce
executable
FAIL: 22_locale/money_put/put/char/39168.cc (test for excess errors)
UNRESOLVED: 22_locale/money_put/put/char/39168.cc compilation failed to produce
executable
FAIL: 22_locale/money_put/put/char/5.cc (test for excess errors)
UNRESOLVED: 22_locale/money_put/put/char/5.cc compilation failed to produce
executable
FAIL: 22_locale/money_put/put/char/6.cc (test for excess errors)
UNRESOLVED: 22_locale/money_put/put/char/6.cc compilation failed to produce
executable
FAIL: 22_locale/money_put/put/wchar_t/12971.cc (test for excess errors)
UNRESOLVED: 22_locale/money_put/put/wchar_t/12971.cc compilation failed to
produce executable
FAIL: 22_locale/money_put/put/wchar_t/39168.cc (test for excess errors)
UNRESOLVED: 22_locale/money_put/put/wchar_t/39168.cc compilation failed to
produce executable
FAIL: 22_locale/money_put/put/wchar_t/5.cc (test for excess errors)
UNRESOLVED: 22_locale/money_put/put/wchar_t/5.cc compilation failed to produce
executable
FAIL: 22_locale/money_put/put/wchar_t/6.cc (test for excess errors)
UNRESOLVED: 22_locale/money_put/put/wchar_t/6.cc compilation failed to produce
executable
on --with-long-double-128  --with-long-double-format=ieee powerpc64le-linux.
The FAILs are:
Excess errors:
/usr/bin/ld: /tmp/ccSqrsjq.o:(.toc+0x40): undefined reference to
`std::__gnu_cxx11_ieee128::money_get > >::id'
collect2: error: ld returned 1 exit status
or
Excess errors:
/usr/bin/ld: /tmp/ccz9eXoW.o:(.toc+0x18): undefined reference to
`std::__gnu_cxx11_ieee128::money_get > >::id'
collect2: error: ld returned 1 exit status
or
Excess errors:
/usr/bin/ld: /tmp/ccHAzeKf.o:(.toc+0x40): undefined reference to
`std::__gnu_cxx11_ieee128::money_put > >::id'
collect2: error: ld returned 1 exit status
or
Excess errors:
/usr/bin/ld: /tmp/ccl2BKfH.o:(.toc+0x18): undefined reference to

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

[i.nixman at autistici dot org via Gcc-bugs]

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

--- Comment #7 from niXman  ---
(In reply to CVS Commits from comment #6)
> The master branch has been updated by Jonathan Yong :
> 
> https://gcc.gnu.org/g:902c755930326cb4405672aa3ea13c35c653cbff
> 
> commit r13-5055-g902c755930326cb4405672aa3ea13c35c653cbff
> Author: LIU Hao 
> Date:   Fri Jan 6 23:18:15 2023 +0800
> 
> Always define `WIN32_LEAN_AND_MEAN` before 
> 
> Recently, mingw-w64 has got updated  from Wine which is included
> indirectly by  if `WIN32_LEAN_AND_MEAN` is not defined. The
> `IXMLDOMDocument` class has a member function named `abort()`, which gets
> affected by our `abort()` macro in "system.h".
> 
> `WIN32_LEAN_AND_MEAN` should, nevertheless, always be defined. This
> can exclude 'APIs such as Cryptography, DDE, RPC, Shell, and Windows
> Sockets' [1], and speed up compilation of these files a bit.
> 
> [1]
> https://learn.microsoft.com/en-us/windows/win32/winprog/using-the-windows-
> headers
> 
> gcc/
> 
> PR middle-end/108300
> * config/xtensa/xtensa-dynconfig.c: Define `WIN32_LEAN_AND_MEAN`
> before .
> * diagnostic-color.cc: Likewise.
> * plugin.cc: Likewise.
> * prefix.cc: Likewise.
> 
> gcc/ada/
> 
> PR middle-end/108300
> * adaint.c: Define `WIN32_LEAN_AND_MEAN` before `#include
> `.
> * cio.c: Likewise.
> * ctrl_c.c: Likewise.
> * expect.c: Likewise.
> * gsocket.h: Likewise.
> * mingw32.h: Likewise.
> * mkdir.c: Likewise.
> * rtfinal.c: Likewise.
> * rtinit.c: Likewise.
> * seh_init.c: Likewise.
> * sysdep.c: Likewise.
> * terminals.c: Likewise.
> * tracebak.c: Likewise.
> 
> gcc/jit/
> 
> PR middle-end/108300
> * jit-w32.h: Define `WIN32_LEAN_AND_MEAN` before .
> 
> libatomic/
> 
> PR middle-end/108300
> * config/mingw/lock.c: Define `WIN32_LEAN_AND_MEAN` before
> .
> 
> libffi/
> 
> PR middle-end/108300
> * src/aarch64/ffi.c: Define `WIN32_LEAN_AND_MEAN` before
> .
> 
> libgcc/
> 
> PR middle-end/108300
> * config/i386/enable-execute-stack-mingw32.c: Define
> `WIN32_LEAN_AND_MEAN` before .
> * libgcc2.c: Likewise.
> * unwind-generic.h: Likewise.
> 
> libgfortran/
> 
> PR middle-end/108300
> * intrinsics/sleep.c: Define `WIN32_LEAN_AND_MEAN` before
> .
> 
> libgomp/
> 
> PR middle-end/108300
> * config/mingw32/proc.c: Define `WIN32_LEAN_AND_MEAN` before
> .
> 
> libiberty/
> 
> PR middle-end/108300
> * make-temp-file.c: Define `WIN32_LEAN_AND_MEAN` before
> .
> * pex-win32.c: Likewise.
> 
> libssp/
> 
> PR middle-end/108300
> * ssp.c: Define `WIN32_LEAN_AND_MEAN` before .
> 
> libstdc++-v3/
> 
> PR middle-end/108300
> * src/c++11/system_error.cc: Define `WIN32_LEAN_AND_MEAN` before
> .
> * src/c++11/thread.cc: Likewise.
> * src/c++17/fs_ops.cc: Likewise.
> * src/filesystem/ops.cc: Likewise.
> 
> libvtv/
> 
> PR middle-end/108300
> * vtv_malloc.cc: Define `WIN32_LEAN_AND_MEAN` before .
> * vtv_rts.cc: Likewise.
> * vtv_utils.cc: Likewise.

now it bootstrapped OK, thanks!

[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 #12 from Jonathan Wakely  ---
The std::span default constructor that's causing problems has been there for a
few years, but nobody pointed out it didn't work for this mode. For a target to
remain usable we need test results and regular fixes. Otherwise things stay
broken for years and then we have to fix dozens of things all at once. This
target has bitrotted quite badly.

[Bug testsuite/108192] g++.dg/cet-notrack-1.C searching for wrong function on mingw

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #3 from nightstrike  ---
Created attachment 54209
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54209=edit
Patch to change printf to puts so it works everywhere

[Bug target/108229] [13 Regression] unprofitable STV transform since r13-4873-g0b2c1369d035e928

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

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

--- Comment #5 from Roger Sayle  ---
This should now be fixed on mainline.  The backend's microarchitecture tuning
now has much better control over whether Alexander's loop is converted by STV,
and this no longer happens at -Os where this obviously isn't a win/correct.

[Bug tree-optimization/92342] [10/11/12/13 Regression] a small missed transformation into x?b:0

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 CC||roger at nextmovesoftware dot 
com

--- Comment #27 from Roger Sayle  ---
Revised versions of Andrew's patches from comment #25 were posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609349.html

[Bug sanitizer/106726] ICE: verify_gimple failed (dead statement in EH table) on __builtin_alloca_with_align() with -fsanitize=hwaddress -fstack-check=generic -fexceptions

[zsojka at seznam dot cz via Gcc-bugs]

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

--- Comment #3 from Zdenek Sojka  ---
This can now be also observed on the x86_64 target, with -mlam=u57:
$ x86_64-pc-linux-gnu-gcc -fsanitize=hwaddress -fstack-check=generic
-fexceptions -mlam=u57 testcase.c 
testcase.c: In function 'foo':
testcase.c:4:1: error: dead statement in EH table
4 | foo (void)
  | ^~~
# _4 = VDEF <.MEM_2>
_5 = __builtin_alloca_with_align (64, 512);
during GIMPLE pass: asan0
testcase.c:4:1: internal compiler error: verify_gimple failed
0x141d106 verify_gimple_in_cfg(function*, bool, bool)
/repo/gcc-trunk/gcc/tree-cfg.cc:5647
0x12c0e20 execute_function_todo
/repo/gcc-trunk/gcc/passes.cc:2091
0x12c13cb execute_todo
/repo/gcc-trunk/gcc/passes.cc:2145
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.

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

[jdx at o2 dot pl via Gcc-bugs]

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

--- Comment #11 from Jan Dubiec  ---
(In reply to Jonathan Wakely from comment #8)
> (In reply to Jan Dubiec from comment #6)
> > Please note -mn -mint32 options –
> > normal mode (aka 16-bit mode) with 32-bit integers.
> 
> Has this bizarre mode ever been able to build libstdc++?
Yes, it was possible to build libstdc++ in this mode before introduction of all
that C++20 time zone stuff in 9fc61d45. E.g. I am able to build 907c84cb which
is parent of 9fc61d45.

That being said, the normal mode is indeed "bizzare" and I can't imagine myself
why one would want to use it these days, when the original 16-bit H8/300 died a
long time ago and its descendants are just dying. Perhaps support for normal
mode should be removed just like support for H8/300 was in mid-2020 (as far as
I remember).