[Bug libgcc/109685] [13/14 Regression] Memory leak in `__deregister_frame`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109685 Markus Böck changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Markus Böck --- Fixed
[Bug libgcc/109685] New: Memory leak in `__deregister_frame`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109685 Bug ID: 109685 Summary: Memory leak in `__deregister_frame` Product: gcc Version: 13.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: markus.boeck02 at gmail dot com Target Milestone: --- Sorry that I can't ship a proper reproducer, since I believe this essentially requires a JIT or extracts of binary sections I am not yet familiar with. If I do figure out a viable minimal reproducer I'll post them later. With the recent release of GCC 13 landing on my fedora machine I have suddenly started getting memory leaks reports by the leak sanitizer within a JIT application of mine using `__register_frame` and `__deregister_frame`, pointing to memory allocated by libgcc. I have then gone through debugging sessions with GDB and found following oddities which I believe should be the causes of the leak: First of all, the memory allocation being leaked happens in `start_fde_sort` https://github.com/gcc-mirror/gcc/blob/12de8da8961d294904d6af90b9cc27a5ba1ccfd0/libgcc/unwind-dw2-fde.c#L507 ``` if ((accu->linear = malloc (size))) { accu->linear->count = 0; if ((accu->aux = malloc (size))) accu->aux->count = 0; return 1; } ``` Specifically the assignment to `accu->linear`. `accu->aux` is only temporarily working memory that gets properly freed later. `accu->linear` instead gets put into an `object` that is inserted into a global btree (pointer is assigned to `u.sort` https://github.com/gcc-mirror/gcc/blob/12de8da8961d294904d6af90b9cc27a5ba1ccfd0/libgcc/unwind-dw2-fde.c#L918) The above call chains happens the first time unwinding happens since objects are lazily initialized. Later during JIT shutdown, `__deregsiter_frame` is called to erase all the unwind information that has been produced. This leads us to following code: ``` #ifdef ATOMIC_FDE_FAST_PATH ... uintptr_type range[2]; get_pc_range (, range); // And remove ob = btree_remove (_frames, range[0]); #else ... #endif gcc_assert (in_shutdown || ob); return (void *) ob; ``` https://github.com/gcc-mirror/gcc/blob/12de8da8961d294904d6af90b9cc27a5ba1ccfd0/libgcc/unwind-dw2-fde.c#L242 with the caller calling `free` on the returned `ob`. Problem is that the `ob` may still have the pointer previously set by `init_object` within its `u.sort` field. No attempt to free it is done within the `ATOMIC_FDE_FAST_PATH` region however (something that does happen in the #else region, which is seemingly not the default or maybe not enabled by the distribution). This therefore leads to the memory pointed to by `ob->u.sort` to become unreachable and leak. The `ATOMIC_FDE_FAST_PATH` fast path was only added after the GCC 12 release which would also explain why the LSAN only caught the leak after the GCC 13 release
[Bug c++/104601] New: [11 Regression] Invalid branch elimination at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104601 Bug ID: 104601 Summary: [11 Regression] Invalid branch elimination at -O2 Product: gcc Version: 11.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: markus.boeck02 at gmail dot com Target Milestone: --- Following code has been produced via reduction with `creduce`. When compiled with `-O2`, GCC 11 and later versions will incorrectly print `f`, while if `-O1` or lower, or an older version of GCC is used, it will correctly print 't'. #include #include #include inline std::optional a(std::vector::iterator b, std::vector::iterator c, std::optional h(int)) { std::optional d; find_if(b, c, [&](auto e) { d = h(e); return d; }); return d; } std::optional f(int) { return 1; } main() { std::vector g(100); auto e = a(g.begin(), g.end(), f); printf("%c", e ? 't' : 'f'); } For the sake of completion, this was the original code: https://godbolt.org/z/enx19v7E5
[Bug other/100598] New: MinGW Canadian cross toolchain fails to build due to missing BASEVER in genversion.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100598 Bug ID: 100598 Summary: MinGW Canadian cross toolchain fails to build due to missing BASEVER in genversion.c Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: markus.boeck02 at gmail dot com Target Milestone: --- I am currently unable to build trunk version of gcc due to a compiler error when compiling the file genversion.c. This happens when crosscompiling a GCC toolchain for a x86_64-w64-mingw32 host. The compiler error: ../../gcc/genversion.c: In function ‘int main()’: ../../gcc/genversion.c:37:20: error: ‘BASEVER’ was not declared in this scope char basever[] = BASEVER; ^~~ ../../gcc/genversion.c:50:11: error: ‘DEVPHASE’ was not declared in this scope phase = DEVPHASE[0]; ^~~~ ../../gcc/genversion.c:73:39: error: expected ‘)’ before ‘BASEVER’ printf ("#define version_string \"" BASEVER DATESTAMP DEVPHASE REVISION "\"\n"); ^~~ ../../gcc/genversion.c:74:42: error: expected ‘)’ before ‘PKGVERSION’ printf ("#define pkgversion_string \"" PKGVERSION "\"\n\n"); ^~ ../../gcc/genversion.c:82:39: error: expected ‘)’ before ‘BUGURL’ printf ("#define bug_report_url \"" BUGURL "\"\n\n"); ^~ make[2]: *** [build/genversion.o] Error 1 make[2]: *** Waiting for unfinished jobs The compile command used in the build is: g++ -c -DIN_GCC -DGENERATOR_FILE -I. -Ibuild -I../../gcc -I../../gcc/build -I../../gcc/../include -I../../gcc/../libcpp/include -I/mnt/c/GCC-Build/NewestLinux/Libraries/include \ -o build/genversion.o ../../gcc/genversion.c where g++ is 7.5.0 shipped with Ubuntu 18.04 which I am using as build environment. The configure command used is: ../configure --target=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --disable-bootstrap --enable-libstdcxx-debug --with-tune=znver1 --prefix=/mnt/c/GCC --with-sysroot=/mnt/c/GCC-Build/NewestLinux --with-build-sysroot=/mnt/c/GCC-Build/NewestLinux --disable-libstdcxx-pch --disable-multilib --enable-libgomp --with-cross-host --with-libiconv-prefix=/mnt/c/GCC-Build/NewestLinux/Libraries --disable-libstdcxx-verbose --enable-languages=c,c++,fortran,lto,objc,obj-c++,d --disable-nls --disable-win32-registry --enable-shared --with-gnu-as --with-gnu-ld --enable-threads=posix --program-suffix=-12 --enable-version-specific-runtime-libs --with-gcc-major-version-only --enable-__cxa_atexit --enable-plugin --program-prefix= --enable-checking=release
[Bug libstdc++/100238] [11/12 Regression] Link failure in debug libstdc++ on MinGW due to atomicitiy.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100238 Markus Böck changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #4 from Markus Böck --- Clean build fixed this. Closing
[Bug libstdc++/100238] New: [11/12] Link failure in debug libstdc++ on MinGW due to atomicitiy.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100238 Bug ID: 100238 Summary: [11/12] Link failure in debug libstdc++ on MinGW due to atomicitiy.cc Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: markus.boeck02 at gmail dot com Target Milestone: --- Building a shared libstdc++ with --enable-libstdcxx-debug for MinGW currently fails to link on both trunk and the upcoming GCC 11 branch. The precise error as shown in the terminal is: /mnt/c/GCC-Build/NewestLinux/bin/x86_64-w64-mingw32-ld: ../../src/debug/c++98/.libs/libc++98convenience.a(atomicity.o): in function `__gnu_cxx::__exchange_and_add(int volatile*, int)': /mnt/c/GCC-Build-Array/gcc/build-target-x86_64/x86_64-w64-mingw32/libstdc++-v3/src/debug/c++98/atomicity.cc:36: multiple definition of `__gnu_cxx::__exchange_and_add(int volatile*, int)'; ../../libsupc++/.libs/libsupc++convenience.a(atomicity.o):C:/GCC-Build-Array/gcc/build-target-x86_64/x86_64-w64-mingw32/libstdc++-v3/libsupc++/atomicity.cc:36: first defined here /mnt/c/GCC-Build/NewestLinux/bin/x86_64-w64-mingw32-ld: ../../src/debug/c++98/.libs/libc++98convenience.a(atomicity.o): in function `__gnu_cxx::__atomic_add(int volatile*, int)': /mnt/c/GCC-Build-Array/gcc/build-target-x86_64/x86_64-w64-mingw32/libstdc++-v3/src/debug/c++98/atomicity.cc:41: multiple definition of `__gnu_cxx::__atomic_add(int volatile*, int)'; ../../libsupc++/.libs/libsupc++convenience.a(atomicity.o):C:/GCC-Build-Array/gcc/build-target-x86_64/x86_64-w64-mingw32/libstdc++-v3/libsupc++/atomicity.cc:41: first defined here Configure option used was: ../configure --target=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --disable-bootstrap --enable-libstdcxx-debug --with-tune=znver1 --prefix=/mnt/c/GCC --with-sysroot=/mnt/c/GCC-Build/NewestLinux --with-build-sysroot=/mnt/c/GCC-Build/NewestLinux --disable-libstdcxx-pch --disable-multilib --enable-libgomp --with-cross-host --with-libiconv-prefix=/mnt/c/GCC-Build/NewestLinux/Libraries --disable-libstdcxx-verbose --enable-languages=c,c++,fortran,lto,objc,obj-c++,d --disable-nls --disable-win32-registry --enable-shared --with-gnu-as --with-gnu-ld --enable-threads=posix --program-suffix=-11 --enable-version-specific-runtime-libs --with-gcc-major-version-only --enable-__cxa_atexit --enable-plugin --program-prefix= --enable-checking=release Last tested on revision 886b6c1e8af502b69e3f318b9830b73b88215878 of the master branch
[Bug c++/98409] Installing g++-mapper-server fails when cross compiling to Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98409 --- Comment #2 from Markus Böck --- That is indeed weird. At the top of the Makefile it says: EXEEXT := .exe and further down in the Makefile: g++-mapper-server$(exeext): $(MAPPER.O) $(CODYLIB) +$(CXX) $(LDFLAGS) -o $@ $^ $(VERSION.O) $(LIBIBERTY) # copy to gcc dir so tests there can run all::../gcc/g++-mapper-server$(exeext) ../gcc/g++-mapper-server$(exeext): g++-mapper-server$(exeext) $(INSTALL) $< $@ install:: $(SHELL) $(srcdir)/../mkinstalldirs $(DESTDIR)$(libexecsubdir) $(INSTALL_PROGRAM) g++-mapper-server$(exeext) $(DESTDIR)$(libexecsubdir) which seems correct to me? Yet running make gives: make[2]: Entering directory '/mnt/c/GCC-Build-Array/gcc/build-target-x86_64/c++tools' # --enable-maintainer-mode to rebuild ../../c++tools/config.h.in, or make MAINTAINER=touch x86_64-w64-mingw32-g++-10 -static-libstdc++ -static-libgcc -L/mnt/c/GCC-Build/NewestLinux/Libraries/lib -Wl,--stack,12582912 -o g++-mapper-server server.o resolver.o ../libcody/libcody.a ../gcc/version.o ../libiberty/libiberty.a /usr/bin/install -c g++-mapper-server ../gcc/g++-mapper-server /usr/bin/install: cannot stat 'g++-mapper-server': No such file or directory Makefile:97: recipe for target '../gcc/g++-mapper-server' failed make[2]: *** [../gcc/g++-mapper-server] Error 1 make[2]: Leaving directory '/mnt/c/GCC-Build-Array/gcc/build-target-x86_64/c++tools' Makefile:11807: recipe for target 'all-c++tools' failed make[1]: *** [all-c++tools] Error 2 make[1]: Leaving directory '/mnt/c/GCC-Build-Array/gcc/build-target-x86_64' Makefile:980: recipe for target 'all' failed make: *** [all] Error 2 I am using GNU Make 4.1 on an Ubuntu 18.04 WSL 1 Host in case that could be important
[Bug c++/98409] New: Installing g++-mapper-server fails when cross compiling to Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98409 Bug ID: 98409 Summary: Installing g++-mapper-server fails when cross compiling to Windows Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: markus.boeck02 at gmail dot com Target Milestone: --- Current version of trunk GCC (1b021bbd85a79c9d16c1359cbc23b608685dfd9f) fails to compile when cross compiling GCC to Windows due to a install command trying to install g++-mapper-server even though the file is named g++-mapper-server.exe which does exist. make: /usr/bin/install: cannot stat 'g++-mapper-server': No such file or directory make[2]: *** [../gcc/g++-mapper-server] Error 1 make[1]: *** [all-c++tools] Error 2 make[1]: *** Waiting for unfinished jobs Configure comment used: ../configure --target=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --disable-bootstrap --enable-libstdcxx-debug --with-tune=znver1 --prefix=/mnt/c/GCC --with-sysroot=/mnt/c/GCC-Build/NewestLinux --with-build-sysroot=/mnt/c/GCC-Build/NewestLinux --disable-libstdcxx-pch --disable-multilib --enable-libgomp --with-cross-host --with-libiconv-prefix=/mnt/c/GCC-Build/NewestLinux/Libraries --disable-libstdcxx-verbose --enable-languages=c,c++,fortran,lto,objc,obj-c++ --disable-nls --disable-win32-registry --enable-shared --with-gnu-as --with-gnu-ld --enable-threads=posix --program-suffix=-11 --enable-version-specific-runtime-libs --with-gcc-major-version-only --enable-__cxa_atexit --enable-plugin --program-prefix=
[Bug libstdc++/97813] New: std::filesystem::equivalent returning incorrect results on MinGW due to symlinks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97813 Bug ID: 97813 Summary: std::filesystem::equivalent returning incorrect results on MinGW due to symlinks Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: markus.boeck02 at gmail dot com Target Milestone: --- Given two std::filesystem::path that are identical except for maybe spelling std::filesystem::equivalent will fail if the path is a or a subdirectory of a symlink. This is due to the use of _wstat. Microsoft states here: https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2013/14h5k7ff(v=vs.120) that _wstat does not work with symlinks. Using stat would be possible but converting to a multibyte coding seems dirty and could lead to localization issues I believe? There is a forum discussion here that I read through as well. http://gtk.10911.n7.nabble.com/wstat-on-Windows-actually-stat-stuff-in-general-td19965.html It seems like the best way of working around this is to not use _wstat on Windows, wherever possible. I saw in the implementation of equivalent that additional code for windows already exists that opens the files and compares Fileinformation. Maybe this could be used instead on Windows?
[Bug c++/97740] New: Weird error message about accessing a private member of my own class inside of std::string_view inside of constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97740 Bug ID: 97740 Summary: Weird error message about accessing a private member of my own class inside of std::string_view inside of constexpr Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: markus.boeck02 at gmail dot com Target Milestone: --- Created attachment 49513 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49513=edit Reproduction of the bug. Simply compile with -std=c++17 I want to apologize for the code you are about to see already. I am one of those people who likes to constexpr and templates at times. In one of my recent code that does some constexpr string parsing and validation I encountered a very very weird error message: /opt/compiler-explorer/gcc-10.2.0/include/c++/10.2.0/string_view: In instantiation of 'cld::detail::CommandLine::parseOptions, {detail::INCLUDESbind0, std::in_place_type > >}>:: [with auto:7 = {const std::pair, std::in_place_type_t > > >&}]': /opt/compiler-explorer/gcc-10.2.0/include/c++/10.2.0/type_traits:2506:26: required by substitution of 'template static std::__result_of_success()((declval<_Args>)()...)), std::__invoke_other> std::__result_of_other_impl::_S_test(int) [with _Fn = cld::detail::CommandLine::parseOptions, {detail::INCLUDESbind0, std::in_place_type > >}>::; _Args = {const std::pair, std::in_place_type_t > > >&}]' /opt/compiler-explorer/gcc-10.2.0/include/c++/10.2.0/type_traits:2517:55: required from 'struct std::__result_of_impl, {detail::INCLUDESbind0, std::in_place_type > >}>::, const std::pair, std::in_place_type_t > > >&>' /opt/compiler-explorer/gcc-10.2.0/include/c++/10.2.0/type_traits:138:12: recursively required by substitution of 'template struct std::__is_invocable_impl<_Result, _Ret, true, std::__void_t > [with _Result = std::__invoke_result, {detail::INCLUDESbind0, std::in_place_type > >}>::, const std::pair, std::in_place_type_t > > >&>; _Ret = void]' /opt/compiler-explorer/gcc-10.2.0/include/c++/10.2.0/type_traits:138:12: required from 'struct std::__and_, {detail::INCLUDESbind0, std::in_place_type > >}>::, const std::pair, std::in_place_type_t > > >&>, void, true, void>, std::__call_is_nothrow, {detail::INCLUDESbind0, std::in_place_type > >}>::, const std::pair, std::in_place_type_t > > >&>, cld::detail::CommandLine::parseOptions, {detail::INCLUDESbind0, std::in_place_type > >}>::, const std::pair, std::in_place_type_t > > >&> >' /opt/compiler-explorer/gcc-10.2.0/include/c++/10.2.0/type_traits:2979:12: required from 'struct std::is_nothrow_invocable, {detail::INCLUDESbind0, std::in_place_type > >}>::, const std::pair, std::in_place_type_t > > >&>' /opt/compiler-explorer/gcc-10.2.0/include/c++/10.2.0/tuple:1715:37: required from 'constexpr const bool std::__unpack_std_tuple struct std::is_nothrow_invocable, cld::detail::CommandLine::parseOptions, {detail::INCLUDESbind0, std::in_place_type > >}>::, const std::tuple, std::in_place_type_t > > > >&>' /opt/compiler-explorer/gcc-10.2.0/include/c++/10.2.0/tuple:1730:14: required from 'constexpr decltype(auto) std::apply(_Fn&&, _Tuple&&) [with _Fn = cld::detail::CommandLine::parseOptions, {detail::INCLUDESbind0, std::in_place_type > >}>::; _Tuple = const std::tuple, std::in_place_type_t > > > >&]' :456:36: required from 'constexpr auto cld::detail::CommandLine::parseOptions(std::string_view, cld::CLIMultiArg) [with T = cld::detail::CommandLine::Pack; auto& ...args = {detail::INCLUDESbind0, std::in_place_type > >}; std::string_view = std::basic_string_view]' :502:62: required from here /opt/compiler-explorer/gcc-10.2.0/include/c++/10.2.0/string_view:287:34: error: 'char cld::Constexpr::basic_fixed_string::m_data [7]' is private within this context 287 | return basic_string_view{_M_str + __pos, __rlen}; | ~~~^~~ :18:5: note: declared private here 18 | T m_data[N] = {}; | I tried to create a minimum reproducible from scratch but failed to so. Instead I now used my code and tried to minimize that as much as possible which sadly still amounts to 500 lines of code but does reproduce the issue. I have attached the file. To my knowledge the code is correct and clang and MSVC compile it without issues. Changing m_data in basic_fixed_string from private to public makes the build succeed. Every version of GCC 8 to trunk fail with the same error. GCC 7 instead has an internal compiler error. Alternatively see this compiler explorer link: https://godbolt.org/z/snnfo7
[Bug libstdc++/97729] [11 Regression] Link failure due to basic_stringbuf and others when building DLL on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97729 Markus Böck changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from Markus Böck --- Can happily report that it links now! Thanks a lot
[Bug libstdc++/97729] [11 Regression] Link failure due to basic_stringbuf and others when building DLL on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97729 --- Comment #4 from Markus Böck --- Indeed that sounds like it might be the issue. I am currently on a very recent version of binutils: $ ./x86_64-w64-mingw32-ld --versionGNU ld (GNU Binutils) 2.35.50.20200709 Copyright (C) 2020 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. Changing the lines you posted above yields me a compiler error now: libtool: compile: /mnt/c/GCC-Build-Array/gcc/build-host-x86_64/./gcc/xgcc -shared-libgcc -B/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/./gcc -nostdinc++ -L/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/src -L/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/src/.libs -L/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/libsupc++/.libs -L/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/x86_64-w64-mingw32/lib -L/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/mingw/lib -isystem /mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/x86_64-w64-mingw32/include -isystem /mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/mingw/include -B/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/x86_64-w64-mingw32/bin/ -B/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/x86_64-w64-mingw32/lib/ -isystem /mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/x86_64-w64-mingw32/include -isystem /mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/x86_64-w64-mingw32/sys-include -I/mnt/c/GCC-Build-Array/gcc/libstdc++-v3/../libgcc -I/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/include/x86_64-w64-mingw32 -I/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/include -I/mnt/c/GCC-Build-Array/gcc/libstdc++-v3/libsupc++ -I/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/include -std=gnu++11 -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=future.lo -Wno-error=format-extra-args -Wno-error=format -g1 -fdebug-prefix-map=/mnt/c=C: -c ../../../../../libstdc++-v3/src/c++11/future.cc -o future.o In file included from ../../../../../libstdc++-v3/src/c++11/future.cc:29: /mnt/c/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/include/future: In member function 'std::__future_base::_Result<_Res>& std::__basic_future<_Res>::_M_get_result() const': /mnt/c/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/include/future:712:30: error: ambiguous overload for 'operator==' (operand types are 'std::__exception_ptr::exception_ptr' and 'int') 712 | if (!(__res._M_error == 0)) | ~~ ^~ ~ | | | | | int | std::__exception_ptr::exception_ptr /mnt/c/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/include/future:712:30: note: candidate: 'operator==(std::__exception_ptr::exception_ptr::__safe_bool {aka void (std::__exception_ptr::exception_ptr::*)()}, std::__exception_ptr::exception_ptr::__safe_bool {aka void (std::__exception_ptr::exception_ptr::*)()})' (built-in) 712 | if (!(__res._M_error == 0)) | ~~~^~~~ In file included from /mnt/c/GCC-Build-Array/gcc/libstdc++-v3/libsupc++/exception:147, from /mnt/c/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/include/mutex:40, from /mnt/c/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/include/future:38, from ../../../../../libstdc++-v3/src/c++11/future.cc:29: /mnt/c/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/include/bits/exception_ptr.h:223:5: note: candidate: 'bool std::__exception_ptr::operator==(const std::__exception_ptr::exception_ptr&, const std::__exception_ptr::exception_ptr&)' 223 | operator==(const exception_ptr&, const exception_ptr&) | ^~~~ Makefile:644: recipe for target 'future.lo' failed make[5]: Leaving directory '/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/src/c++11'
[Bug libstdc++/97729] [11 Regression] Link failure due to basic_stringbuf and others when building DLL on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97729 --- Comment #2 from Markus Böck --- Created attachment 49507 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49507=edit config.h Applied the patch and it fixed the issue regarding the undefined references. Still getting the multiple definitions of exception_ptr: /mnt/c/GCC-Build/NewestLinux/bin/x86_64-w64-mingw32-ld: ../libsupc++/.libs/libsupc++convenience.a(nested_exception.o): in function `std::__exception_ptr::exception_ptr::~exception_ptr()': C:/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/libsupc++/C:/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/include/bits/exception_ptr.h:194: multiple definition of `std::__exception_ptr::exception_ptr::~exception_ptr()'; ../libsupc++/.libs/libsupc++convenience.a(eh_ptr.o):C:/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/libsupc++/C:/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/include/bits/exception_ptr.h:194: first defined here /mnt/c/GCC-Build/NewestLinux/bin/x86_64-w64-mingw32-ld: ../src/c++11/.libs/libc++11convenience.a(future.o): in function `std::__exception_ptr::exception_ptr::exception_ptr()': C:/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/src/c++11/C:/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/include/bits/std_mutex.h:105: multiple definition of `std::__exception_ptr::exception_ptr::exception_ptr()'; ../libsupc++/.libs/libsupc++convenience.a(eh_ptr.o):C:/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/libsupc++/C:/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/include/bits/exception_ptr.h:176: first defined here I am using a cross compiler setup (though in WSL 1) as well so I'd be curious what leads to the differences in reproducability as this is not the first time this has happened. I'll attach my config.h if that helps. The MinGW version I use is current trunk.
[Bug libstdc++/97729] New: Link failure due to basic_stringbuf and others when building DLL on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97729 Bug ID: 97729 Summary: Link failure due to basic_stringbuf and others when building DLL on MinGW Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: markus.boeck02 at gmail dot com Target Milestone: --- Current trunk of libstdc++ is not able to be built when building a shared library on the i686-w64-mingw32 and x86_64-w64-mingw32 targets. Following configure arguments were used: ../configure --target=x86_64-w64-mingw32 --disable-bootstrap --with-sysroot=/mnt/c/GCC-Build/NewestLinux --prefix=/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install --disable-multilib --with-tune=znver1 --disable-libstdcxx-verbose --disable-nls --enable-shared --with-gnu-ld --enable-threads=posix --enable-__cxa_atexit --enable-libgomp --with-gnu-as --with-as=/mnt/c/GCC-Build/NewestLinux/bin/x86_64-w64-mingw32-as --with-ld=/mnt/c/GCC-Build/NewestLinux/bin/x86_64-w64-mingw32-ld --enable-languages=c,c++,fortran,lto,objc,obj-c++ --with-cross-host The last relevant lines of stdout are: /bin/bash ../libtool --tag CXX --mode=link /mnt/c/GCC-Build-Array/gcc/build-host-x86_64/./gcc/xgcc -shared-libgcc -B/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/./gcc -nostdinc++ -L/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/src -L/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/src/.libs -L/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/libsupc++/.libs -L/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/x86_64-w64-mingw32/lib -L/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/mingw/lib -isystem /mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/x86_64-w64-mingw32/include -isystem /mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/mingw/include -B/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/x86_64-w64-mingw32/bin/ -B/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/x86_64-w64-mingw32/lib/ -isystem /mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/x86_64-w64-mingw32/include -isystem /mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/x86_64-w64-mingw32/sys-include -Wl,-O1 -no-undefined -bindir "/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/x86_64-w64-mingw32/lib/../lib" -Wl,--gc-sections -std=gnu++98 -DDLL_EXPORT -DPIC -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=libstdc++.la -o libstdc++.la -version-info 6:29:0 -Wl,--version-script=libstdc++-symbols.ver -lm -no-undefined -bindir "/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/x86_64-w64-mingw32/lib/../lib" -rpath /mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/x86_64-w64-mingw32/lib/../lib compatibility.lo compatibility-debug_list.lo compatibility-debug_list-2.lo compatibility-c++0x.lo compatibility-atomic-c++0x.lo compatibility-thread-c++0x.lo compatibility-chrono.lo compatibility-condvar.lo ../libsupc++/libsupc++convenience.la ../src/c++98/libc++98convenience.la ../src/c++11/libc++11convenience.la ../src/c++17/libc++17convenience.la ../src/c++20/libc++20convenience.la make all-am make[3]: Entering directory '/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libgfortran' libtool: link: rm -fr .libs/libstdc++.dll.a libtool: link: /mnt/c/GCC-Build-Array/gcc/build-host-x86_64/./gcc/xgcc -shared-libgcc -B/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/./gcc -nostdinc++ -L/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/src -L/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/src/.libs -L/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/x86_64-w64-mingw32/libstdc++-v3/libsupc++/.libs -L/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/x86_64-w64-mingw32/lib -L/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/mingw/lib -isystem /mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/x86_64-w64-mingw32/include -isystem /mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/mingw/include -B/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/x86_64-w64-mingw32/bin/ -B/mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/x86_64-w64-mingw32/lib/ -isystem /mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/x86_64-w64-mingw32/include -isystem /mnt/c/GCC-Build-Array/gcc/build-host-x86_64/install/x86_64-w64-mingw32/sys-include -shared -nostdlib /mnt/c/GCC-Build/NewestLinux/mingw/lib/../lib/dllcrt2.o /mnt/c/GCC-Build-Array/gcc/build-host-x86_64/./gcc/crtbegin.o .libs/compatibility.o .libs/compatibility-debug_list.o .libs/compatibility-debug_list-2.o .libs/compatibility-c++0x.o .libs/compatibility-atomic-c++0x.o .libs/compatibility-thread-c++0x.o .libs/compatibility-chrono.o .libs/compatibility-co
[Bug c++/97661] New: Bogus error message about initializing a using declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97661 Bug ID: 97661 Summary: Bogus error message about initializing a using declaration Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: markus.boeck02 at gmail dot com Target Milestone: --- Following code produces an error message I can't quite decipher. The code to my knowledge is also correct and compiles with clang and MSVC: template class Base { }; class Derived : public Base { }; template struct DeduceArgs { Base* p; using type = Base; }; template DeduceArgs(Base*) -> DeduceArgs; template constexpr bool always_false = false; #include template ()})::type> class Deleter { static_assert(always_false); }; template class Deleter> { public: void operator()(Derived* pointer) const noexcept { delete pointer; } }; #include template using IntrVarPtr = std::unique_ptr>; int main() { IntrVarPtr ptr; } The error message I receive is: : In substitution of 'template using IntrVarPtr = std::unique_ptr > [with T = Derived]': :54:23: required from here :50:7: error: initializer for 'Base' must be brace-enclosed 50 | using IntrVarPtr = std::unique_ptr>; | ^~ Corresponding godbolt link: https://godbolt.org/z/eK8fex
[Bug analyzer/96608] Build failure due to cast to type long on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608 --- Comment #2 from Markus Böck --- Don't worry there's no rush! It's the master branch after all. Just wanted to make sure people are aware of it as soon as possible.
[Bug analyzer/96608] New: Build failure due to cast to type long on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608 Bug ID: 96608 Summary: Build failure due to cast to type long on MinGW Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: markus.boeck02 at gmail dot com Target Milestone: --- Current trunk (revision 808f4dfeb3a95f50f15e71148e5c1067f90a126d) fails when using the MinGW target due to a few casts to the type long which is 32 bit on Windows. Following compiler errors appear: In file included from ../../gcc/analyzer/checker-path.cc:51: ../../gcc/analyzer/store.h: In member function 'hashval_t ana::symbolic_binding::hash() const': ../../gcc/analyzer/store.h:271:41: error: cast from 'const ana::region*' to 'long int' loses precision [-fpermissive] 271 | return (binding_key::impl_hash () ^ (long)m_region); | ^~ With the same error appearing roughly 10 times through the code base. Compiler used was GCC 10.2.1. Compilation command: x86_64-w64-mingw32-g++-10 -fno-PIE -c -fdebug-prefix-map=/mnt/c=C: -g -march=nehalem -O3 -I/mnt/c/GCC-Build/NewestLinux/Libraries/include -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -fno-common -DHAVE_CONFIG_H -I. -Ianalyzer -I../../gcc -I../../gcc/analyzer -I../../gcc/../include -I../../gcc/../libcpp/include -I/mnt/c/GCC-Build-Array/gcc/build-target-i686/./gmp -I/mnt/c/GCC-Build-Array/gcc/gmp -I/mnt/c/GCC-Build-Array/gcc/build-target-i686/./mpfr/src -I/mnt/c/GCC-Build-Array/gcc/mpfr/src -I/mnt/c/GCC-Build-Array/gcc/mpc/src -I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/bid -I../libdecnumber -I../../gcc/../libbacktrace -I/mnt/c/GCC-Build-Array/gcc/build-target-i686/./isl/include -I/mnt/c/GCC-Build-Array/gcc/isl/include -I/mnt/c/GCC-Build/NewestLinux/Libraries/include -o analyzer/checker-path.o -MT analyzer/checker-path.o -MMD -MP -MF analyzer/.deps/checker-path.TPo ../../gcc/analyzer/checker-path.cc
[Bug libfortran/95418] [11 Regression] Static assert going off on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95418 --- Comment #8 from Markus Böck --- Tested the above patch and the build failure is gone now
[Bug libfortran/95418] Static assert going off on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95418 --- Comment #2 from Markus Böck --- I printed the size of the struct and it yielded 36. Interestingly, using clang instead yields 32 like on Linux
[Bug libfortran/95418] New: Static assert going off on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95418 Bug ID: 95418 Summary: Static assert going off on MinGW Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: markus.boeck02 at gmail dot com Target Milestone: --- Since commit "i386: Use generic division to generate INEXACT exception" (d3a1459cd4f2d4997fb53e34ddef72e91a7855c1) libgfortran is not able to be compiled with the target x86_64-w64-mingw32. This is due to a _Static_assert going off in fpu-target.h. The exact error message is: In file included from ../../../libgfortran/runtime/fpu.c:29: ./fpu-target.h:91:1: error: static assertion failed: "GFC_FPE_STATE_BUFFER_SIZE is too small" 91 | _Static_assert (sizeof(struct fenv) <= (size_t) GFC_FPE_STATE_BUFFER_SIZE, | ^~ Reverting the above commit makes compilation succeed.
[Bug libstdc++/95392] New: Build failure on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95392 Bug ID: 95392 Summary: Build failure on MinGW Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: markus.boeck02 at gmail dot com Target Milestone: --- Current trunk version of GCC (tested with HEAD at 4833c1adc3c7b125bf1c59e8bd8d802ac3b0d205) fails to build using MinGW. The compiler error is as follows: In file included from /mnt/c/GCC-Build/gcc/build/x86_64-w64-mingw32/libstdc++-v3/include/filesystem:45, from ../../../../../libstdc++-v3/src/c++17/fs_ops.cc:32, from ../../../../../libstdc++-v3/src/c++17/cow-fs_ops.cc:26: /mnt/c/GCC-Build/gcc/build/x86_64-w64-mingw32/libstdc++-v3/include/bits/fs_path.h: In function 'std::filesystem::path std::filesystem::u8path(const _Source&)': /mnt/c/GCC-Build/gcc/build/x86_64-w64-mingw32/libstdc++-v3/include/bits/fs_path.h:789:32: error: '_S_string_from_iter' is not a member of 'std::filesystem::path' 789 |std::string __s = path::_S_string_from_iter(__source); | The change that introduced the breakage is 584d52b088f9fcf78704b504c3f1f07e17c1cded. Reverting this commit makes the build succeed