Re: [Mingw-w64-public] How to backtrace a crash with gdb on Windows 7

2018-01-18 Thread sisyphus1



-Original Message- 
From: Hannes Domani via Mingw-w64-public

Sent: Thursday, January 18, 2018 10:11 PM
To: mingw-w64-public@lists.sourceforge.net
Cc: Hannes Domani
Subject: Re: [Mingw-w64-public] How to backtrace a crash with gdb on Windows 
7



(gdb) run
Starting program: C:\_64\comp\mpfr_bug\ggdb\mpfr-4.0.0\tests\tfprintf.exe
[New Thread 4680.0x160c]

This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.
repl-vsnprintf.c:358: GNU MP assertion failed: 0
[Inferior 1 (process 4680) exited with code 03]
(gdb) bt
No stack.


That's because it didn't crash, but an assertion failed.
This calls abort(), which then normally exits with exit code 3.

A crash looks in gdb like this:
Thread 1 received signal SIGSEGV, Segmentation fault.

To get a proper stacktrace for an assertion failure, just use "break 
abort"

before "run".


Aaah ... yes, that makes all the difference.
Thank you, Hannes.

Cheers,
Rob



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


[Mingw-w64-public] internal compiler error

2018-01-18 Thread Matt Sexton via Mingw-w64-public
Hello,

x86_64-w64-mingw32-gcc from the mingw64-gcc-7.2.0-1.fc27.x86_64 package on
Fedora 27 is reporting the following error in compiling some of our code:

internal compiler error: in get_constraint_for_ptr_offset, at
tree-ssa-structalias.c:3155

Is this the right place to ask about the bug?

Assuming so, here is some more information.  We see this on Fedora 27 with
the standard package:

$ x86_64-w64-mingw32-gcc -v
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-w64-mingw32/7.2.0/lto-wrapper
Target: x86_64-w64-mingw32
Configured with: ../configure --prefix=/usr --bindir=/usr/bin
--includedir=/usr/include --mandir=/usr/share/man --infodir=/usr/share/info
--datadir=/usr/share --build=x86_64-redhat-linux-gnu
--host=x86_64-redhat-linux-gnu --with-gnu-as --with-gnu-ld --verbose
--without-newlib --disable-multilib --disable-plugin --with-system-zlib
--disable-nls --without-included-gettext --disable-win32-registry
--enable-languages=c,c++,objc,obj-c++,fortran --with-bugurl=
http://bugzilla.redhat.com/bugzilla --with-cloog --enable-threads=posix
--enable-libgomp --target=x86_64-w64-mingw32
--with-sysroot=/usr/x86_64-w64-mingw32/sys-root
--with-gxx-include-dir=/usr/x86_64-w64-mingw32/sys-root/mingw/include/c++
Thread model: posix
gcc version 7.2.0 20170814 (Fedora MinGW 7.2.0-1.fc27) (GCC)

We also see the same issue on Fedora 25

$ x86_64-w64-mingw32-gcc -v
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-w64-mingw32/6.4.0/lto-wrapper
Target: x86_64-w64-mingw32
Configured with: ../configure --prefix=/usr --bindir=/usr/bin
--includedir=/usr/include --mandir=/usr/share/man --infodir=/usr/share/info
--datadir=/usr/share --build=x86_64-redhat-linux-gnu
--host=x86_64-redhat-linux-gnu --with-gnu-as --with-gnu-ld --verbose
--without-newlib --disable-multilib --disable-plugin --with-system-zlib
--disable-nls --without-included-gettext --disable-win32-registry
--enable-languages=c,c++,objc,obj-c++,fortran --with-bugurl=
http://bugzilla.redhat.com/bugzilla --with-cloog --enable-threads=posix
--enable-libgomp --target=x86_64-w64-mingw32
--with-sysroot=/usr/x86_64-w64-mingw32/sys-root
--with-gxx-include-dir=/usr/x86_64-w64-mingw32/sys-root/mingw/include/c++
Thread model: posix
gcc version 6.4.0 20170704 (Fedora MinGW 6.4.0-1.fc25) (GCC)

We do not see the issue on Fedora 21:

$ x86_64-w64-mingw32-gcc -v
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-w64-mingw32/4.9.2/lto-wrapper
Target: x86_64-w64-mingw32
Configured with: ../configure --prefix=/usr --bindir=/usr/bin
--includedir=/usr/include --mandir=/usr/share/man --infodir=/usr/share/info
--datadir=/usr/share --build=x86_64-redhat-linux-gnu
--host=x86_64-redhat-linux-gnu --with-gnu-as --with-gnu-ld --verbose
--without-newlib --disable-multilib --disable-plugin --with-system-zlib
--disable-nls --without-included-gettext --disable-win32-registry
--enable-languages=c,c++,objc,obj-c++,fortran --with-bugurl=
http://bugzilla.redhat.com/bugzilla --with-cloog --enable-threads=posix
--enable-libgomp --target=x86_64-w64-mingw32
--with-sysroot=/usr/x86_64-w64-mingw32/sys-root
--with-gxx-include-dir=/usr/x86_64-w64-mingw32/sys-root/mingw/include/c++
Thread model: posix
gcc version 4.9.2 20141030 (Fedora MinGW 4.9.2-1.fc21) (GCC)

We only see the issue when optimization is enabled.

When building the same code natively using gcc on CentOS 6 and 7 and Fedora
21, 26, and 27, we see no such error.  I do not have a pared-down,
stand-alone case that reproduces the issue, nor do I have a clear
correlation with any particular code pattern.  Could anyone shed any light
on what this error means, so that I might have a better chance of working
around it?

Thank you,
Matt
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


Re: [Mingw-w64-public] linux gcc vs mingw-w64 performance ?

2018-01-18 Thread Liu Hao
On 2018/1/18 9:27, lemonsqueeze wrote:
> Ah, found the big one:
> Was testing single threaded but code uses __thread thread-local storage
> which slows things down a lot on mingw.
> 
> Tried a few alternatives:
> - Microsoft TlsGetValue() / TlsSetValue()
> - pthread_getspecific() / pthread_setspecific()
> - __thread
> - own array-based tls using pthread_self()
> - own array-based tls using GetCurrentThreadId()
> 
> Fastest so far is the last one, getting comparable perf with linux
> (8% slower instead of 30%).
> 
> 
For `pthread_getspecific() / pthread_setspecific()`:

See `mingw-w64/winpthreads/src/threads.c`. `pthread_getspecific()`
contains a call to `pthread_spin_lock()` and `pthread_spin_unlock()`, in
addition to a call to `GetLastError()` and `SetLastError()`, so it could
be quite inefficient, which could be made worse if there is at all any
contention.


For `__thread`:

At the moment this is implemented using emutls
(https://gcc.gnu.org/onlinedocs/gccint/Emulated-TLS.html). See
`gcc/libgcc/emutls.c` for its implementation. It contains a call to
`__gthread_getspecific()`, which, in the posix thread model, is
effectively `pthread_getspecific()`.


-- 
Best regards,
LH_Mouse


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


Re: [Mingw-w64-public] How to backtrace a crash with gdb on Windows 7

2018-01-18 Thread Hannes Domani via Mingw-w64-public
> (gdb) run
> Starting program: C:\_64\comp\mpfr_bug\ggdb\mpfr-4.0.0\tests\tfprintf.exe
> [New Thread 4680.0x160c]
> 
> This application has requested the Runtime to terminate it in an unusual
> way.
> Please contact the application's support team for more information.
> repl-vsnprintf.c:358: GNU MP assertion failed: 0
> [Inferior 1 (process 4680) exited with code 03]
> (gdb) bt
> No stack.

That's because it didn't crash, but an assertion failed.
This calls abort(), which then normally exits with exit code 3.

A crash looks in gdb like this:
Thread 1 received signal SIGSEGV, Segmentation fault.

To get a proper stacktrace for an assertion failure, just use "break abort"
before "run".


Regards
Hannes

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


Re: [Mingw-w64-public] linux gcc vs mingw-w64 performance ?

2018-01-18 Thread Vincent Torri
On Thu, Jan 18, 2018 at 2:27 AM, lemonsqueeze  wrote:
> Ah, found the big one:
> Was testing single threaded but code uses __thread thread-local storage
> which slows things down a lot on mingw.
>
> Tried a few alternatives:
> - Microsoft TlsGetValue() / TlsSetValue()
> - pthread_getspecific() / pthread_setspecific()
> - __thread
> - own array-based tls using pthread_self()
> - own array-based tls using GetCurrentThreadId()
>
> Fastest so far is the last one, getting comparable perf with linux
> (8% slower instead of 30%).

what is the % with TlsGetValue / TlsSetValue ?

Vincent

>
>
> On 01/15/2018 10:22 PM, lemonsqueeze wrote:
>>
>> Hi,
>>
>> Typically what kind of performance should I expect when porting
>> cpu-intensive code from linux to mingw-w64 ?
>>
>> I'm doing some experiments with a particular C99 app:
>> linux i686 gcc 4.8vswindows x86 mingw-w64 7.2 (msys2)
>> same hardware (intel atom)
>>
>> Surprisingly it's getting almost 30% slower on windows in the
>> cpu-intensive part (single threaded, no syscalls, memory intensive
>> integer arithmetic mostly). gcc 4.8 doesn't favor linux, I would've
>> expected the opposite.
>>
>> Any ideas what's going on / where to look ?
>> I guess i'm going to need a good profiler to find out ...
>>
>> Cheers
>>
>>
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


[Mingw-w64-public] How to backtrace a crash with gdb on Windows 7

2018-01-18 Thread sisyphus1

Hi,

In the msys2 shell, I'm building gmp (with specific configure args) and then 
mpfr.
But there are 3 crashing tests in the mpfr test suite for which I would like 
to obtain a backtrace - but so far, all I'm getting is "No stack".


In the hope that someone might be able to see how I can improve on this 
(non) result, here's exactly what I'm doing.


gmp-6.1.2 source and mpfr-4.0.0 source are in /c/scratch.

In /c/scratch/gmp-6.1.2 I run:
./configure disable-shared --enable-static --enable-assert CC="gcc -ggdb" && 
make && make check.


That works fine, the -ggdb is propagated throughout the build, even to the 
compiling of the gmp test executables (all of which pass).


Then, in /c/scratch/mpfr-4.0.0 I run:
./configure 
disable-shared --enable-static --with-gmp-build=/c/scratch/gmp-6.1.2 && make 
&& make check


Again, the -ggdb flag (which mpfr inherits from gmp) is propagated 
throughout the build, including the compiling of the mpfr test executables 
(all of which pass except for the 3 crashing test programs).


The first crashing test is tests/tfprintf.exe, so I 'cd' to the tests 
directory and run:


###
$ gdb tfprintf.exe
GNU gdb (GDB) 8.0.1
Copyright (C) 2017 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 "x86_64-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 tfprintf.exe...done.
(gdb) run
Starting program: C:\_64\comp\mpfr_bug\ggdb\mpfr-4.0.0\tests\tfprintf.exe
[New Thread 4680.0x160c]

This application has requested the Runtime to terminate it in an unusual 
way.

Please contact the application's support team for more information.
repl-vsnprintf.c:358: GNU MP assertion failed: 0
[Inferior 1 (process 4680) exited with code 03]
(gdb) bt
No stack.
(gdb) q
###

And it's the same for the other 2 crashing test scripts (tprintf.exe and 
tsprint.exe).


Is there something I can do here to obtain a useful backtrace ?

Cheers,
Rob


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public