[Bug libgcc/109685] [13/14 Regression] Memory leak in `__deregister_frame`

2023-09-27 Thread markus.boeck02 at gmail dot com via Gcc-bugs
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`

2023-05-01 Thread markus.boeck02 at gmail dot com via Gcc-bugs
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

2022-02-18 Thread markus.boeck02 at gmail dot com via Gcc-bugs
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

2021-05-14 Thread markus.boeck02 at gmail dot com via Gcc-bugs
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

2021-05-01 Thread markus.boeck02 at gmail dot com via Gcc-bugs
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

2021-04-23 Thread markus.boeck02 at gmail dot com via Gcc-bugs
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

2020-12-21 Thread markus.boeck02 at gmail dot com via Gcc-bugs
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

2020-12-21 Thread markus.boeck02 at gmail dot com via Gcc-bugs
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

2020-11-12 Thread markus.boeck02 at gmail dot com via Gcc-bugs
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

2020-11-06 Thread markus.boeck02 at gmail dot com via Gcc-bugs
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

2020-11-05 Thread markus.boeck02 at gmail dot com via Gcc-bugs
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

2020-11-05 Thread markus.boeck02 at gmail dot com via Gcc-bugs
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

2020-11-05 Thread markus.boeck02 at gmail dot com via Gcc-bugs
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

2020-11-05 Thread markus.boeck02 at gmail dot com via Gcc-bugs
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

2020-11-01 Thread markus.boeck02 at gmail dot com via Gcc-bugs
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

2020-08-14 Thread markus.boeck02 at gmail dot com
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

2020-08-13 Thread markus.boeck02 at gmail dot com
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

2020-05-31 Thread markus.boeck02 at gmail dot com
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

2020-05-31 Thread markus.boeck02 at gmail dot com
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

2020-05-29 Thread markus.boeck02 at gmail dot com
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

2020-05-28 Thread markus.boeck02 at gmail dot com
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