Re: [Mingw-w64-public] winpthread build with static edition

So I looked a bit into libgomp's source code and I see that I might have found the cause for this crash. See in team.c the function gomp_new_team. Use here instead for 'team = gomp_malloc (size);' the following 'team = gomp_malloc_cleared (size);'. This might be already the cause for this crash.

Re: [Mingw-w64-public] clang++ exe fails to run on 64-Bit Windows 7

Ruben Van Boxem writes: > >... > > Yes, I'm aware of the problem. Clang++ is just a renamed version of clang.exe, so just copy clang.exe to clang++.exe and all will work as it should (it uses the image name to set c++ settings and link libraries). Yep, that worked. One minor issue: the output

Re: [Mingw-w64-public] winpthread build with static edition

You might get a different break-point by pressing instead of Ctrl-C the Ctrl-Break key. You are seeing here the signal-catcher of windows about control-c's exception. You can switch to different threads via the 'tread ' command. For more details about using gdb you can use 'info gdb' or you can

Re: [Mingw-w64-public] winpthread build with static edition

This issue is cause by libgomp feeding pthread library with an old handle. IMHO this seems to be an issue of libgomp and not treating here failure-codes proper. But well, maybe you can find out here more details, so we could be able to work-a-round this issue. Regards, Kai 2011/7/10 PcX > 于 2

Re: [Mingw-w64-public] clang++ exe fails to run on 64-Bit Windows 7

2011/7/10 Beman Dawes > Windows 7, 64-bit > > http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting > %20Win64/Personal%20Builds/rubenvb/4.6.2/ > > Downloaded x86

[Mingw-w64-public] clang++ exe fails to run on 64-Bit Windows 7

Windows 7, 64-bit http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting %20Win64/Personal%20Builds/rubenvb/4.6.2/ Downloaded x86_64-w64-mingw32-gcc-4.6.2_rubenvb.7z and x86_64-w64-mingw32-clang-3.0_rubenvb.7z Unpacked both into an empty directory, and added it at the sta

Re: [Mingw-w64-public] Building GCC with my scripts under MSYS

2011/7/10 Earnie > Ruben Van Boxem wrote: > > 2011/7/10 Earnie > > > >> PcX wrote: > >>> 于 2011/7/10 1:55, Ruben Van Boxem 写道: > Which is very odd, because the file that does not exist, > exists. > >>> > >>> Sometimes, on msys, if your source directory and build directory > >>> is diff

Re: [Mingw-w64-public] Building GCC with my scripts under MSYS

Ruben Van Boxem wrote: > 2011/7/10 Earnie > >> PcX wrote: >>> 于 2011/7/10 1:55, Ruben Van Boxem 写道: Which is very odd, because the file that does not exist, exists. >>> >>> Sometimes, on msys, if your source directory and build directory >>> is different, the "some file does not exit" er

Re: [Mingw-w64-public] Building GCC with my scripts under MSYS

2011/7/10 PcX > 于 2011/7/10 20:52, Earnie 写道: > > I didn't think it was possible to build in the > source directory for the GCC package, when did it change? It is also > advised to build in a separate build directory instead of the source > directory so if this is reproducibly true then a bug

Re: [Mingw-w64-public] Building GCC with my scripts under MSYS

2011/7/10 Earnie > PcX wrote: > > 于 2011/7/10 1:55, Ruben Van Boxem 写道: > >> Which is very odd, because the file that does not exist, exists. > > > > Sometimes, on msys, if your source directory and build directory is > > different, the "some file does not exit" error will appear. I don't > > kno

Re: [Mingw-w64-public] Building GCC with my scripts under MSYS

于 2011/7/10 20:52, Earnie 写道: I didn't think it was possible to build in the source directory for the GCC package, when did it change? It is also advised to build in a separate build directory instead of the source directory so if this is reproducibly true then a bug report needs to be open fo

Re: [Mingw-w64-public] Building GCC with my scripts under MSYS

PcX wrote: > 于 2011/7/10 1:55, Ruben Van Boxem 写道: >> Which is very odd, because the file that does not exist, exists. > > Sometimes, on msys, if your source directory and build directory is > different, the "some file does not exit" error will appear. I don't > know this reason. So if I build gcc

Re: [Mingw-w64-public] winpthread build with static edition

于 2011/7/10 18:30, Kai Tietz 写道: Ok, could you do a last test for attempt to fix this issue for winpthread? Rev 4269 Thanks in advance, Kai I update to 4269 It seems to fix the problem, but the run progress is not normal, and it seems to come int

Re: [Mingw-w64-public] winpthread build with static edition

Ok, could you do a last test for attempt to fix this issue for winpthread? Rev 4269 Thanks in advance, Kai -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive recor

Re: [Mingw-w64-public] winpthread build with static edition

于 2011/7/10 17:29, Kai Tietz 写道: > Sorry, but I will stop here further investigations as it seems to be a > bug somewhere else. Thanks. I will use pthread-win32 temporarily. -- Best Regards, PcX -- All of the data gene

Re: [Mingw-w64-public] winpthread build with static edition

Well, so it seems to be a bug in libgomp. To add here a sequence-list for valid objects within this library makes no sense, as it drains performance too much. It seems that libgomp stores internally pointer to internal objects and so invalid internal objects are passed. Sorry, but I will stop her

Re: [Mingw-w64-public] winpthread build with static edition

于 2011/7/10 16:44, Kai Tietz 写道: So, it might be a racing condition in destruction case and breaking of pending operations. So I addressed this at  revision 4267.  If this problem still happens, then it might be a bug in gomp. It also doesn't function...

Re: [Mingw-w64-public] winpthread build with static edition

So, it might be a racing condition in destruction case and breaking of pending operations. So I addressed this at revision 4267. If this problem still happens, then it might be a bug in gomp. Regards, Kai -- All of the d

Re: [Mingw-w64-public] winpthread build with static edition

于 2011/7/10 15:25, Kai Tietz 写道: Does it help to insert at line 90 of sem.c the check IsBadReadPtr (sv sizeof (*sv)) befor the check for sv->valid == DEAD_SEM?  if (!sem || (sv = *sem) == NULL || IsBadReadPtr (sv, sizeof (*sv)) || sv->valid == DEAD_SEM)

Re: [Mingw-w64-public] winpthread build with static edition

Hmm, it seems to me that omp destroys barriers and then try to continue to use them ... Does it help to insert at line 90 of sem.c the check IsBadReadPtr (sv sizeof (*sv)) befor the check for sv->valid == DEAD_SEM? Regards, Kai 2011/7/10 PcX > Hi, Kai Tietz > > I update to svn 4266, and th

Re: [Mingw-w64-public] winpthread build with static edition

Hi, Kai Tietz     I update to svn 4266, and there is also the problem, but is different: -- Best Regards, PcX -- All of the data generated in your IT inf