https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102994
Óscar Fuentes changed:
What|Removed |Added
Status|SUSPENDED |RESOLVED
Resolution|---
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102994
Óscar Fuentes changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
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.
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
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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96004
--- Comment #1 from Óscar Fuentes ---
This looks like a duplicate of PR53637 / PR53637.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58487
Óscar Fuentes changed:
What|Removed |Added
CC||gcc_bugzilla at axeitado dot
com
---
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:
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.
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
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 */
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
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
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
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
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
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
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:
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
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
>
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
> >
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.
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).
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
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
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
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
30 matches
Mail list logo
