[Bug libstdc++/102994] std::atomic::wait is not marked const

[gcc_bugzilla at axeitado dot com via Gcc-bugs]

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

Óscar Fuentes  changed:

   What|Removed |Added

 Status|SUSPENDED   |RESOLVED
 Resolution|--- |FIXED

--- Comment #12 from Óscar Fuentes  ---
(In reply to Jonathan Wakely from comment #9)
> (In reply to Óscar Fuentes from comment #6)
> > So IIUC you are applying modifications to libstdc++ that deviate from the
> > published standard expecting that the committee will accept those changes.
> > As a user, this is troublesome, because right now I need to special-case gcc
> > version >11.2 and maybe version  > not accepted and is reverted.
> 
> Why do you need to special case anything? What problem are these extra const
> qualifications causing you?

One project here consists on a compiler for certain strict, statically typed
language that transparently interacts with C++ code bases. We have a mechanism
for inferring the signature of C/C++ functions and automatically create
wrappers for them, using a combination of macros and templates. For instance,
this is how std::atomic_notify_all is reflected:

LP0_FFI_FN_OV("notify-all", void, (std::atomic*), std::atomic_notify_all);

The "_OV" means "overloaded", "void" is the type returned, (std::atomic*)
is the argument list. If the returned type and argument list does not match an
overload of std::atomic_notify_all, the C++ compiler throws an error.

For stdlibc++ we could simply use

LP0_FFI_FN("notify-all", std::atomic_notify_all>);

and let our template machinery deduce the signature of std::atomic_notify_all,
but other implementations (libc++) do provide the "volatile" overload, so we
are forced to explicitly tell the compiler which overload we want.

Thus, if the function's signature differ from one implementation to another, we
need to detect the correct signature and use it on each instantiation of
std::atomic_notify_all et al we reflect.

To make things worse, some distros picked the change and incorporated them to
their gcc 11.2 packages. I'm afraid the only solution is a platform check at
configure time plus the corresponding macro-sprinkling on our C++ sources. A
hairy mess for what otherwise would be something quite simple and clean.

There are other technical inconveniences related to our precise use case that
would be too long to explain here.

Anyway, thanks for explaining the state of affairs. I understand your POV, so
I'm closing this issue.

[Bug libstdc++/102994] std::atomic::wait is not marked const

[gcc_bugzilla at axeitado dot com via Gcc-bugs]

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

--- Comment #6 from Óscar Fuentes  ---
(In reply to Jonathan Wakely from comment #5)
> (In reply to Óscar Fuentes from comment #4)
> > The fix is wrong. It changes atomic_notify_one and atomic_notify_all instead
> > of atomic<>::wait.
> 
> It changed both.
> 
> > So right now atomic<>::wait remains unfixed
> 
> Are you sure?

Sigh. Sorry. It would be nice if the commit message mentioned the change to
atomic_notify_* and its motivation, though.

> > and atomic_notify_(one|all) arg
> > is wrongly marked as const.
> 
> This will be the subject of a library issue, potentially fixing the
> standard. The notify functions should be const too.

So IIUC you are applying modifications to libstdc++ that deviate from the
published standard expecting that the committee will accept those changes. As a
user, this is troublesome, because right now I need to special-case gcc version
>11.2 and maybe version 

[Bug libstdc++/103933] atomics: notify_one, notify_all marked const

[gcc_bugzilla at axeitado dot com via Gcc-bugs]

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

--- Comment #4 from Óscar Fuentes  ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to Óscar Fuentes from comment #1)
> > Also, the template functions atomic_notify_one and atomic_notify_all take a
> > const argument, when it should be non-const.
> > 
> > The `volatile' arg overload is missing too.
> 
> Because there is no atomic_flag::notify_one() or atomic_flag::notify_all()
> in libstdc++. The volatile overloads are not useful, and are deprecated, and
> are not present in libstdc++.

Ok, thanks, but atomic<>::notify_(one|all) exist and show the problem, which
was introduced as a "fix" for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102994

[Bug libstdc++/103933] atomics: notify_one, notify_all marked const

[gcc_bugzilla at axeitado dot com via Gcc-bugs]

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

--- Comment #2 from Óscar Fuentes  ---
The breakage mentioned on my previous message was introduced by a wrong fix for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102994

[Bug libstdc++/102994] std::atomic::wait is not marked const

[gcc_bugzilla at axeitado dot com via Gcc-bugs]

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

Óscar Fuentes  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #4 from Óscar Fuentes  ---
The fix is wrong. It changes atomic_notify_one and atomic_notify_all instead of
atomic<>::wait.

So right now atomic<>::wait remains unfixed and atomic_notify_(one|all) arg is
wrongly marked as const.

[Bug libstdc++/103933] atomics: notify_one, notify_all marked const

[gcc_bugzilla at axeitado dot com via Gcc-bugs]

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

--- Comment #1 from Óscar Fuentes  ---
Also, the template functions atomic_notify_one and atomic_notify_all take a
const argument, when it should be non-const.

The `volatile' arg overload is missing too.

[Bug libstdc++/103934] New: std::atomic_flag: multiple C++20 functions missing

[gcc_bugzilla at axeitado dot com via Gcc-bugs]

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

Bug ID: 103934
   Summary: std::atomic_flag: multiple C++20 functions missing
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc_bugzilla at axeitado dot com
  Target Milestone: ---

atomic_flag_test(_explicit), atomic_flag_wait(_explicit),
atomic_flag_notify_one and atomic_flag_notify_all are missing. This seems an
oversight, as their definition should be trivial.

[Bug libstdc++/103933] New: atomics: notify_one, notify_all marked const

[gcc_bugzilla at axeitado dot com via Gcc-bugs]

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

Bug ID: 103933
   Summary: atomics: notify_one, notify_all marked const
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc_bugzilla at axeitado dot com
  Target Milestone: ---

std::atomic::notify_one and std::atomic_flag::notify_one are marked const.

As per cppreference.com and 31.10 / 31.8.1 from the latest C++20 draft they
should be non-const.

Same for notify_all.

[Bug c++/96004] Copy elision with conditional

[gcc_bugzilla at axeitado dot com via Gcc-bugs]

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

--- Comment #1 from Óscar Fuentes  ---
This looks like a duplicate of PR53637 / PR53637.

[Bug c++/58487] Missed return value optimization

[gcc_bugzilla at axeitado dot com via Gcc-bugs]

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

Óscar Fuentes  changed:

   What|Removed |Added

 CC||gcc_bugzilla at axeitado dot 
com

--- Comment #4 from Óscar Fuentes  ---
Isn't this PR a trivial variation of PR53637 ?

[Bug libstdc++/102994] New: std::atomic::wait is not marked const

[gcc_bugzilla at axeitado dot com via Gcc-bugs]

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

Bug ID: 102994
   Summary: std::atomic::wait is not marked const
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc_bugzilla at axeitado dot com
  Target Milestone: ---

This code fails to compile because the `wait' member function is not marked
`const' in the specialization of std::atomic for pointers:

#include 

void foo(const std::atomic , char *p) {
a.wait(p);
}


g++ --std=c++20

: In function 'void foo(const std::atomic&, char*)':
:4:11: error: passing 'const std::atomic' as 'this' argument
discards qualifiers [-fpermissive]
4 | a.wait(p);
  | ~~^~~
In file included from :1:
/opt/compiler-explorer/gcc-trunk-20211028/include/c++/12.0.0/atomic:651:5:
note:   in call to 'void
std::atomic<_Tp*>::wait(std::atomic<_Tp*>::__pointer_type, std::memory_order)
[with _Tp = char; std::atomic<_Tp*>::__pointer_type = char*]'
  651 | wait(__pointer_type __old, memory_order __m = memory_order_seq_cst)
noexcept
  | ^~~~
Compiler returned: 1

[Bug ada/100486] Ada build fails for 32bit Windows

[gcc_bugzilla at axeitado dot com via Gcc-bugs]

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

--- Comment #71 from Óscar Fuentes  ---
(In reply to Eric Botcazou from comment #70)
> Tentatively fixed, reopen if not.

The bootstrap works.

Thank you.

[Bug ada/100486] Ada build fails for 32bit Windows

[gcc_bugzilla at axeitado dot com via Gcc-bugs]

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

--- Comment #66 from Óscar Fuentes  ---
(In reply to Eric Botcazou from comment #65)
> Thanks.  Do you still have this line:
> 
>  r .eh_frame
> 
> for crtend.o of the GCC 10 compiler after the grep mess was resolved?  Do
> you have the same line for the crtend.o of the GCC 11 compiler?

The problem with grep didn't affect my gcc 10 install because it was built with
grep 3.0, so crtend.o didn't change. Here it is again for completeness:

$ for f in `find /mingw32 -name crtend.o` ; do echo $f && nm $f ; done 
/mingw32/lib/gcc/i686-w64-mingw32/10.3.0/crtend.o
 b .bss
 d .ctors.65535
 d .data
 r .eh_frame
 r .rdata$zzz
 t .text
 t .text.startup
 r ___FRAME_END__
 U ___gcc_register_frame
 t _register_frame_ctor


Now, these are the crtend.o created in the gcc 11.2 build directory before it
failed at a-except.o (this is also with grep 3.0, while in comment#29 was with
the botched grep 3.6, but I see no differences):

$ for f in `find
/d/dev/other/MINGW-packages/mingw-w64-gcc/src/build-i686-w64-mingw32 -name
crtend.o` ; do echo $f && nm $f ; done
/d/dev/other/MINGW-packages/mingw-w64-gcc/src/build-i686-w64-mingw32/prev-gcc/crtend.o
 b .bss
 d .ctors.65535
 d .data
 r .eh_frame
 r .rdata$zzz
 t .text
 r ___FRAME_END__
 U ___gcc_register_frame
 t _register_frame_ctor
/d/dev/other/MINGW-packages/mingw-w64-gcc/src/build-i686-w64-mingw32/prev-i686-w64-mingw32/libgcc/crtend.o
 b .bss
 d .ctors.65535
 d .data
 r .eh_frame
 r .rdata$zzz
 t .text
 r ___FRAME_END__
 U ___gcc_register_frame
 t _register_frame_ctor


Note that, as before, .text.startup is present in gcc-10 but missing in gcc-11
crtend.o.

[Bug ada/100486] Ada build fails for 32bit Windows

[gcc_bugzilla at axeitado dot com via Gcc-bugs]

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

--- Comment #64 from Óscar Fuentes  ---
Searching for HAVE_LD_RO_RW_SECTION_MIXING in the build directory used for
extracting the previous gdb backtraces shows this:

gcc/auto-host.h:1684:11:/* #undef HAVE_LD_RO_RW_SECTION_MIXING */

[Bug ada/100486] Ada build fails for 32bit Windows

[gcc_bugzilla at axeitado dot com via Gcc-bugs]

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

--- Comment #55 from Óscar Fuentes  ---
Here we go (this is a debug build):

$
/d/dev/other/MINGW-packages/mingw-w64-gcc/src/build-i686-w64-mingw32/./prev-gcc/xgcc
-B/d/dev/other/MINGW-packages/mingw-w64-gcc/src/build-i686-w64-mingw32/./prev-gcc/
-B/mingw32/i686-w64-mingw32/bin/ -L/mingw32/i686-w64-mingw32/lib -L/mingw32/lib
-isystem /mingw32/i686-w64-mingw32/include -isystem /mingw32/include
-B/mingw32/i686-w64-mingw32/bin/ -B/mingw32/i686-w64-mingw32/lib/ -isystem
/mingw32/i686-w64-mingw32/include -isystem
/mingw32/i686-w64-mingw32/sys-include   -fno-checking -c -g -O2
-D__USE_MINGW_ACCESS -Wno-pedantic-ms-format -fno-checking -gtoggle  -gnatpg 
-W -Wall -g -O1 -fno-inline  -nostdinc -I- -I. -Iada/generated -Iada
-Iada/gcc-interface -I../../gcc-11.2.0/gcc/ada
-I../../gcc-11.2.0/gcc/ada/gcc-interface -Iada/libgnat
-I../../gcc-11.2.0/gcc/ada/libgnat
../../gcc-11.2.0/gcc/ada/libgnat/a-except.adb -o ada/libgnat/a-except.o
-wrapper gdb,--args
GNU gdb (GDB) 10.2
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "i686-w64-mingw32".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from
D:/dev/other/MINGW-packages/mingw-w64-gcc/src/build-i686-w64-mingw32/prev-gcc/gnat1.exe...
Breakpoint 1 at 0x1b9b938: file ../../gcc-11.2.0/gcc/diagnostic.c, line 1884.
Breakpoint 2 at 0x1b9b79f: file ../../gcc-11.2.0/gcc/diagnostic.c, line 1804.
Breakpoint 3 at 0x1e3b618
Breakpoint 4 at 0x1e3b5e8
File tree.h will be skipped when stepping.
File is-a.h will be skipped when stepping.
File line-map.h will be skipped when stepping.
File timevar.h will be skipped when stepping.
Function rtx_expr_list::next will be skipped when stepping.
Function rtx_expr_list::element will be skipped when stepping.
Function rtx_insn_list::next will be skipped when stepping.
Function rtx_insn_list::insn will be skipped when stepping.
Function rtx_sequence::len will be skipped when stepping.
Function rtx_sequence::element will be skipped when stepping.
Function rtx_sequence::insn will be skipped when stepping.
Function INSN_UID will be skipped when stepping.
Function PREV_INSN will be skipped when stepping.
Function SET_PREV_INSN will be skipped when stepping.
Function NEXT_INSN will be skipped when stepping.
Function SET_NEXT_INSN will be skipped when stepping.
Function BLOCK_FOR_INSN will be skipped when stepping.
Function PATTERN will be skipped when stepping.
Function INSN_LOCATION will be skipped when stepping.
Function INSN_HAS_LOCATION will be skipped when stepping.
Function JUMP_LABEL_AS_INSN will be skipped when stepping.
Successfully loaded GDB hooks for GCC
(gdb) catch exception
Catchpoint 5: all Ada exceptions
(gdb) run
Starting program:
D:\dev\other\MINGW-packages\mingw-w64-gcc\src\build-i686-w64-mingw32\prev-gcc\gnat1.exe
-I - -I . -I ada/generated -I ada -I ada/gcc-interface -I
../../gcc-11.2.0/gcc/ada -I ../../gcc-11.2.0/gcc/ada/gcc-interface -I
ada/libgnat -I ../../gcc-11.2.0/gcc/ada/libgnat -gnatwa -quiet -nostdinc -O2
-O1 -Wno-pedantic-ms-format -Wextra -Wall -dumpdir ada/libgnat/ -dumpbase
a-except.adb -dumpbase-ext .adb -g -fno-checking -gtoggle -gnatpg -g
-fno-inline "-mtune=generic" "-march=i686" -gnatO ada/libgnat/a-except.o
../../gcc-11.2.0/gcc/ada/libgnat/a-except.adb -o C:\apps\msys64\tmp\ccyhgK0H.s
[New Thread 4320.0x1d80]
[New Thread 4320.0x1d04]
[New Thread 4320.0x2010]
gnat1.exe: warning: command-line option '-Wno-pedantic-ms-format' is valid for
C/C++/ObjC/ObjC++ but not for Ada

Catchpoint 5, SEM_PRAG.ANALYZE_PRAGMA.PRAGMA_EXIT (sem_prag.adb:6605) at
0x007e816c in sem_prag.analyze_pragma.check_valid_library_unit_pragma ()
at ../../gcc-11.2.0/gcc/ada/sem_prag.adb:6605
6605  raise Pragma_Exit;
(gdb) bt
#0  <__gnat_debug_raise_exception> (
e=0x207a990 , message=...)
at ../../gcc-11.2.0/gcc/ada/libgnat/s-excdeb.adb:40
#1  0x0048e862 in ada.exceptions.complete_occurrence (x=x@entry=0x132d8ac0)
at ../../gcc-11.2.0/gcc/ada/libgnat/a-except.adb:912
#2  0x0048e878 in ada.exceptions.complete_and_propagate_occurrence (
x=x@entry=0x132d8ac0) at ../../gcc-11.2.0/gcc/ada/libgnat/a-except.adb:923
#3  0x0048e8b3 in <__gnat_raise_exception> (
e=0x207a990 , message=...)
at ../../gcc-11.2.0/gcc/ada/libgnat/a-except.adb:960
#4  0x007e816c in sem_prag.analyze_pragma.check_valid_library_unit_pragma ()
at ../../gcc-11.2.0/gcc/ada/sem_prag.adb:6605
#5  

[Bug ada/100486] Ada build fails for 32bit Windows

[gcc_bugzilla at axeitado dot com via Gcc-bugs]

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

--- Comment #53 from Óscar Fuentes  ---
(In reply to Christoph Reiter from comment #52)
> Turns out this might be fallout from the last grep update, see
> https://github.com/msys2/MINGW-packages/issues/9771#issuecomment-945007372
> Needs investigating..

"this" means the problem with C++ exceptions, which indeed is fixed by building
gcc after reverting to grep 3.0.

The build failure with Ada, which predated the grep upgrade, persists.

Eric: I'm sorry for the time you wasted on this wild goose chase.

[Bug ada/100486] Ada build fails for 32bit Windows

[gcc_bugzilla at axeitado dot com via Gcc-bugs]

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

--- Comment #43 from Óscar Fuentes  ---
(In reply to Eric Botcazou from comment #42)
> Can you remove the crtbegin.o too, just to be sure, rebuild libstdc++ and
> upload the DLL at the same URL as before?

Same result after moving away crtbegin.o. DLL uploaded with name

libstdc++-6.dll.without-crt-begin-end

[Bug ada/100486] Ada build fails for 32bit Windows

[gcc_bugzilla at axeitado dot com via Gcc-bugs]

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

--- Comment #41 from Óscar Fuentes  ---
(In reply to Eric Botcazou from comment #40)
> > Do you want a full rebuild of gcc?
> 
> At least a full rebuild of libstdc++-v3:
>   rm -rf i686-w64-mingw32/libstdc++-v3
>   make all-target-libstdc++-v3 -jN

After removing the spurious crtend.o and rebuilding libstdc++ following those
instructions, the new libstdc++-6.dll still crashes the same way.

[Bug ada/100486] Ada build fails for 32bit Windows

[gcc_bugzilla at axeitado dot com via Gcc-bugs]

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

--- Comment #38 from Óscar Fuentes  ---
(In reply to Eric Botcazou from comment #37)
> > It comes from the MinGW-w64 CRT.
> 
> We do not have it.  Can you (temporarily) remove it and see what happens?

After moving away that file, exceptions still are broken, but that can be due
to a tainted libstdc++ dll.

Do you want a full rebuild of gcc?

[Bug ada/100486] Ada build fails for 32bit Windows

[gcc_bugzilla at axeitado dot com via Gcc-bugs]

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

--- Comment #36 from Óscar Fuentes  ---
(In reply to Eric Botcazou from comment #34)
> > These are the crtend.o from the installed gcc 10.3 (which works fine):
> > 
> > $ for f in `find /mingw32 -name crtend.o` ; do echo $f && nm $f ; done  
> > /mingw32/i686-w64-mingw32/lib/crtend.o
> >  b .bss
> >  d .data
> >  r .rdata$zzz
> >  t .text
> 
> Where does this one come from exactly?  It looks totally empty.

It comes from the MinGW-w64 CRT.

[Bug ada/100486] Ada build fails for 32bit Windows

[gcc_bugzilla at axeitado dot com via Gcc-bugs]

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

--- Comment #35 from Óscar Fuentes  ---
Yes, it is a debug build (the libstdc++ dll you got is from that). The same
crash happens with a release build, though.

Note the -Og going after the -O2:

/d/dev/other/MINGW-packages/mingw-w64-gcc/src/build-i686-w64-mingw32/./gcc/xgcc
-B/d/dev/other/MINGW-packages/mingw-w64-gcc/src/build-i686-w64-mingw32/./gcc/
-L/mingw32/i686-w64-mingw32/lib -L/mingw32/lib -isystem
/mingw32/i686-w64-mingw32/include -isystem /mingw32/include
-B/mingw32/i686-w64-mingw32/bin/ -B/mingw32/i686-w64-mingw32/lib/ -isystem
/mingw32/i686-w64-mingw32/include -isystem
/mingw32/i686-w64-mingw32/sys-include-g -march=pentium4 -mtune=generic -O2
-pipe -ggdb -Og
-fdebug-prefix-map=/d/dev/other/MINGW-packages/mingw-w64-gcc/src=/usr/src/debug
-O2 -g -march=pentium4 -mtune=generic -O2 -pipe -ggdb -Og
-fdebug-prefix-map=/d/dev/other/MINGW-packages/mingw-w64-gcc/src=/usr/src/debug
-DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
-Wno-error=format-diag -Wstrict-prototypes -Wmissing-prototypes
-Wno-error=format-diag -Wold-style-definition  -isystem ./include  -I. -I.
-I../.././gcc -I../../../gcc-11.2.0/libgcc -I../../../gcc-11.2.0/libgcc/.
-I../../../gcc-11.2.0/libgcc/../gcc -I../../../gcc-11.2.0/libgcc/../include
-I../../../gcc-11.2.0/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT  -g0 
-finhibit-size-directive -fno-inline -fno-exceptions
-fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-tree-vectorize
-fbuilding-libgcc -fno-stack-protector-I. -I. -I../.././gcc
-I../../../gcc-11.2.0/libgcc -I../../../gcc-11.2.0/libgcc/.
-I../../../gcc-11.2.0/libgcc/../gcc -I../../../gcc-11.2.0/libgcc/../include
-I../../../gcc-11.2.0/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -o
crtend.o -MT crtend.o -MD -MP -MF crtend.dep -fno-omit-frame-pointer -Wno-error
-c ../../../gcc-11.2.0/libgcc/config/i386/cygming-crtend.c

[Bug ada/100486] Ada build fails for 32bit Windows

[gcc_bugzilla at axeitado dot com via Gcc-bugs]

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

--- Comment #31 from Óscar Fuentes  ---
> Could you replay the compilation of this file?  In the top level directory,
> do
>   rm i686-w64-mingw32/libgcc/crtend.o
>   make all-target-libgcc
> copy the (long) command line, go into the i686-w64-mingw32/libgcc directory
> and execute it after adding -save-temps to it.  You should get a small
> assembly file named crtend.s and I would be interested in its contents.

The compilation emits this warning:

../../../gcc-11.2.0/libgcc/config/i386/cygming-crtend.c:59:1: warning:
constructor priorities from 0 to 100 are reserved for the implementation
[-Wprio-ctor-dtor]
   59 | static void register_frame_ctor (void) __attribute__ ((constructor
(0)));
  | ^~


Contents of crtend.s:

$ cat crtend.s
.file   "cygming-crtend.c"
.text
.section.eh_frame,"w"
.align 4
___FRAME_END__:
.space 4
.text
.def_register_frame_ctor;   .scl3;  .type   32; .endef
_register_frame_ctor:
LFB55:
.cfi_startproc
pushl   %ebp
.cfi_def_cfa_offset 8
.cfi_offset 5, -8
movl%esp, %ebp
.cfi_def_cfa_register 5
subl$8, %esp
call___gcc_register_frame
leave
.cfi_restore 5
.cfi_def_cfa 4, 4
ret
.cfi_endproc
LFE55:
.section.ctors.65535,"w"
.align 4
.long   _register_frame_ctor
.ident  "GCC: (Rev1, Built by MSYS2 project) 11.2.0"
.def___gcc_register_frame;  .scl2;  .type   32; .endef

[Bug ada/100486] Ada build fails for 32bit Windows

[gcc_bugzilla at axeitado dot com via Gcc-bugs]

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

--- Comment #29 from Óscar Fuentes  ---
(In reply to Eric Botcazou from comment #28)
> OK, I know what's wrong in the libstdc++.dll of GCC 11, now let's try to
> figure out why this is so...  Can you run 'nm' on one of the occurrences of
> crtend.o in the build tree (there are two copies of it)?  On my machine it
> yields:
> 
>  b .bss
>  d .ctors.65535
>  d .data
>  d .eh_frame
>  r .rdata$zzz
>  t .text
>  t .text.startup
>  d ___FRAME_END__
>  U ___gcc_register_frame
>  t _register_frame_ctor

I have quite a few crtend.o files in the build directory. A quick glance
indicates that .text.startup is missing:

$ for f in `find ./build-i686-w64-mingw32/ -name crtend.o` ; do echo $f && nm
$f ; done
./build-i686-w64-mingw32/gcc/crtend.o
 b .bss
 d .ctors.65535
 d .data
 r .eh_frame
 r .rdata$zzz
 t .text
 r ___FRAME_END__
 U ___gcc_register_frame
 t _register_frame_ctor
./build-i686-w64-mingw32/i686-w64-mingw32/libgcc/crtend.o
 b .bss
 d .ctors.65535
 d .data
 r .eh_frame
 r .rdata$zzz
 t .text
 r ___FRAME_END__
 U ___gcc_register_frame
 t _register_frame_ctor
./build-i686-w64-mingw32/prev-gcc/crtend.o
 b .bss
 d .ctors.65535
 d .data
 r .eh_frame
 r .rdata$zzz
 t .text
 r ___FRAME_END__
 U ___gcc_register_frame
 t _register_frame_ctor
./build-i686-w64-mingw32/prev-i686-w64-mingw32/libgcc/crtend.o
 b .bss
 d .ctors.65535
 d .data
 r .eh_frame
 r .rdata$zzz
 t .text
 r ___FRAME_END__
 U ___gcc_register_frame
 t _register_frame_ctor
./build-i686-w64-mingw32/stage1-gcc/crtend.o
 b .bss
 d .ctors.65535
 d .data
 r .eh_frame
 r .rdata$zzz
 t .text
 r ___FRAME_END__
 U ___gcc_register_frame
 t _register_frame_ctor
./build-i686-w64-mingw32/stage1-i686-w64-mingw32/libgcc/crtend.o
 b .bss
 d .ctors.65535
 d .data
 r .eh_frame
 r .rdata$zzz
 t .text
 r ___FRAME_END__
 U ___gcc_register_frame
 t _register_frame_ctor



These are the crtend.o from the installed gcc 10.3 (which works fine):

$ for f in `find /mingw32 -name crtend.o` ; do echo $f && nm $f ; done 
/mingw32/i686-w64-mingw32/lib/crtend.o
 b .bss
 d .data
 r .rdata$zzz
 t .text
/mingw32/lib/gcc/i686-w64-mingw32/10.3.0/crtend.o
 b .bss
 d .ctors.65535
 d .data
 r .eh_frame
 r .rdata$zzz
 t .text
 t .text.startup
 r ___FRAME_END__
 U ___gcc_register_frame
 t _register_frame_ctor

[Bug ada/100486] Ada build fails for 32bit Windows

[gcc_bugzilla at axeitado dot com via Gcc-bugs]

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

--- Comment #26 from Óscar Fuentes  ---
(In reply to Eric Botcazou from comment #25)
> > Sorry, I misread your message and now realized that you just wanted the
> > executable and its dependencies. They are now on the same URL. The 11.2
> > libstdc++ and libgcc dlls are built with debug info.
> 
> Thanks.  I cannot reproduce the problem though:

Curious. I tested the executable on Windows 10 and on Wine, with same result.
Maybe your setup is hiding the output? Or the executable is not being started
at all? (I've seen that on some environments where a required dll was missing
or was incorrect.)

I uploaded new excep.cpp/excep.exe files. Now the executable should give signs
of life before crashing:

$ ./excep.exe
Throwing...

terminate called after throwing an instance of 'int'
terminate called recursively

abnormal program termination


I suggest to try the reproducer under a normal Windows shell, not some
MSYS2/Cygwin terminal emulator.

[Bug ada/100486] Ada build fails for 32bit Windows

[gcc_bugzilla at axeitado dot com via Gcc-bugs]

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

--- Comment #24 from Óscar Fuentes  ---
Sorry, I misread your message and now realized that you just wanted the
executable and its dependencies. They are now on the same URL. The 11.2
libstdc++ and libgcc dlls are built with debug info.

[Bug ada/100486] Ada build fails for 32bit Windows

[gcc_bugzilla at axeitado dot com via Gcc-bugs]

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

--- Comment #23 from Óscar Fuentes  ---
See http://88.17.68.234/clientes/gcc

It contains the gcc binary packages with debug info, plus packages for
dependencies (mpc/gmp/etc.)

It also contains the libstdc++ dll from 10.3 (the "working" one).

The gcc packages are built with the MSYS2 local patches included in the tarfile
patches.tgz.

Note that a build without local patches was already tried with the same failure
while building Ada.

If the local patches are a problem for you, I'll make a build from stock gcc,
but it will take time.

Please let me know if you need something else. Thanks.

[Bug ada/100486] Ada build fails for 32bit Windows

[gcc_bugzilla at axeitado dot com via Gcc-bugs]

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

--- Comment #21 from Óscar Fuentes  ---
(In reply to Eric Botcazou from comment #20)
> Weird, I don't have any dependency on the DLL for it:
> 
> $ ldd t.exe
> ntdll.dll => /Windows/SYSTEM32/ntdll.dll (0x7ffc6556)
> ntdll.dll => /Windows/SysWOW64/ntdll.dll (0x770b)
> wow64.dll => /Windows/System32/wow64.dll (0x5d1b)
> wow64win.dll => /Windows/System32/wow64win.dll (0x5d21)
> 
> Can you post the output of 'g++ foo.cpp -v' for your C++ testcase?  Can you
> find out what symbol(s) of libstdc++.dll are referenced by your executable?

ldd does not list libstdc++.dll, but `Dependency Walker` lists both
libstdc++.dll and libgcc_s_dw2-1.dll.

Imports from libstdc++.dll:

_ZTIi
__cxa_allocate_exception
__cxa_begin_catch
__cxa_end_catch
__cxa_throw
__gxx_personality_v0


Imports from libgcc_s_dw2-1.dll:

__deregister_frame_info
__register_frame_info


$ g++ -v excep.cpp
Using built-in specs.
COLLECT_GCC=D:\dev\other\MINGW-packages\mingw-w64-gcc\pkg\mingw-w64-i686-gcc\mingw32\bin\g++.exe
COLLECT_LTO_WRAPPER=D:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with: ../gcc-11.2.0/configure --prefix=/mingw32
--with-local-prefix=/mingw32/local --build=i686-w64-mingw32
--host=i686-w64-mingw32 --target=i686-w64-mingw32
--with-native-system-header-dir=/mingw32/i686-w64-mingw32/include
--libexecdir=/mingw32/lib --enable-bootstrap --enable-checking=release
--with-arch=i686 --with-tune=generic
--enable-languages=c,lto,c++,fortran,objc,obj-c++,jit --enable-shared
--enable-static --enable-libatomic --enable-threads=posix --enable-graphite
--enable-fully-dynamic-string --enable-libstdcxx-filesystem-ts
--enable-libstdcxx-time --disable-libstdcxx-pch --enable-libstdcxx-debug
--enable-lto --enable-libgomp --disable-multilib --disable-rpath
--disable-win32-registry --disable-nls --disable-werror --disable-symvers
--with-libiconv --with-system-zlib --with-gmp=/mingw32 --with-mpfr=/mingw32
--with-mpc=/mingw32 --with-isl=/mingw32 --with-pkgversion='Rev1, Built by MSYS2
project' --with-bugurl=https://github.com/msys2/MINGW-packages/issues
--with-gnu-as --with-gnu-ld --with-boot-ldflags='-pipe
-Wl,--dynamicbase,--nxcompat,--no-seh -Wl,--large-address-aware
-Wl,--disable-dynamicbase -static-libstdc++ -static-libgcc'
'LDFLAGS_FOR_TARGET=-pipe -Wl,--dynamicbase,--nxcompat,--no-seh
-Wl,--large-address-aware'
--enable-linker-plugin-flags='LDFLAGS=-static-libstdc++\ -static-libgcc\ -pipe\
-Wl,--dynamicbase,--nxcompat,--no-seh\ -Wl,--large-address-aware\
-Wl,--stack,12582912' --disable-sjlj-exceptions --with-dwarf2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (Rev1, Built by MSYS2 project)
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=i686'
'-dumpdir' 'a-'

D:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/cc1plus.exe
-quiet -v -iprefix
D:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/
-D_REENTRANT excep.cpp -quiet -dumpdir a- -dumpbase excep.cpp -dumpbase-ext
.cpp -mtune=generic -march=i686 -version -o C:\apps\msys64\tmp\ccit4tWf.s
GNU C++17 (Rev1, Built by MSYS2 project) version 11.2.0 (i686-w64-mingw32)
compiled by GNU C version 11.2.0, GMP version 6.2.1, MPFR version
4.1.0-p13, MPC version 1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"D:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/../../../../i686-w64-mingw32/include"
ignoring duplicate directory
"D:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/lib/gcc/../../lib/gcc/i686-w64-mingw32/11.2.0/../../../../include/c++/11.2.0"
ignoring duplicate directory
"D:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/lib/gcc/../../lib/gcc/i686-w64-mingw32/11.2.0/../../../../include/c++/11.2.0/i686-w64-mingw32"
ignoring duplicate directory
"D:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/lib/gcc/../../lib/gcc/i686-w64-mingw32/11.2.0/../../../../include/c++/11.2.0/backward"
ignoring duplicate directory
"D:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/lib/gcc/../../lib/gcc/i686-w64-mingw32/11.2.0/include"
ignoring duplicate directory
"D:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/lib/gcc/../../lib/gcc/i686-w64-mingw32/11.2.0/include-fixed"
ignoring nonexistent directory
"D:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/lib/gcc/../../lib/gcc/i686-w64-mingw32/11.2.0/../../../../i686-w64-mingw32/include"
#include "..." search starts here:
#include <...> search starts here:

[Bug ada/100486] Ada build fails for 32bit Windows

[gcc_bugzilla at axeitado dot com via Gcc-bugs]

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

--- Comment #19 from Óscar Fuentes  ---
When I say that --enable-frame-pointer makes no difference, I'm talking about
the build failure that prompted this bug report. The build still fails with

  /C/_/mingw-w64-gcc/src/build-i686-w64-mingw32/./prev-gcc/xgcc
-B/C/_/mingw-w64-gcc/src/build-i686-w64-mingw32/./prev-gcc/
-B/mingw32/i686-w64-mingw32/bin/ -L/mingw32/i686-w64-mingw32/lib -L/mingw32/lib
-isystem /mingw32/i686-w64-mingw32/include -isystem /mingw32/include
-B/mingw32/i686-w64-mingw32/bin/ -B/mingw32/i686-w64-mingw32/lib/ -isystem
/mingw32/i686-w64-mingw32/include -isystem
/mingw32/i686-w64-mingw32/sys-include   -fno-checking -c -g -O2
-D__USE_MINGW_ACCESS -Wno-pedantic-ms-format -fno-checking -gtoggle  -gnatpg 
-W -Wall -g -O1 -fno-inline \
   -nostdinc -I- -I. -Iada/generated -Iada -Iada/gcc-interface
-I../../gcc-11.2.0/gcc/ada -I../../gcc-11.2.0/gcc/ada/gcc-interface
-Iada/libgnat -I../../gcc-11.2.0/gcc/ada/libgnat
../../gcc-11.2.0/gcc/ada/libgnat/a-except.adb -o ada/libgnat/a-except.o

make[3]: *** [../../gcc-11.2.0/gcc/ada/gcc-interface/Make-lang.in:1052:
ada/libgnat/a-except.o] Error 1

[Bug ada/100486] Ada build fails for 32bit Windows

[gcc_bugzilla at axeitado dot com via Gcc-bugs]

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

--- Comment #18 from Óscar Fuentes  ---
Adding --enable-frame-pointer makes no difference. No change either adding

--enable-large-address-aware --with-fpmath=sse --disable-sjlj-exceptions
--enable-frame-pointer --disable-libada --enable-libstdcxx

Another data point: for the test mentioned on Comment 16, if I replace
libstdc++.dll with the same file from gcc 10, the test works.

[Bug ada/100486] Ada build fails for 32bit Windows

[gcc_bugzilla at axeitado dot com via Gcc-bugs]

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

--- Comment #16 from Óscar Fuentes  ---
With g++ 11.2 mingw-w64-i686 a simple test like this crashes:

int main() {
  try {
throw 13;
  }
  catch(...) {
return 1;
  }
  return 0;
}

$ g++ foo.cpp
$ ./a.exe
terminate called after throwing an instance of 'int'
terminate called recursively


The configure command is the same mentioned in comment 5, sans Ada.