Hi,
My apologies for hijacking this thread, but I'm afraid a regression was
introduced by your recent intrin patches. The regression is about the
__cpuid symbol. The qt4 package uses this symbol.
The compilation of qt 4.8.5 is successful with mingw-w64 r5915
(20130628), but with the mingw-w64
Erik van Pienbroek schreef op zo 14-07-2013 om 13:25 [+0200]:
Hi,
My apologies for hijacking this thread, but I'm afraid a regression was
introduced by your recent intrin patches. The regression is about the
__cpuid symbol. The qt4 package uses this symbol.
The compilation of qt 4.8.5 is
On Sat, Jun 8, 2013 at 11:13 PM, JonY jo...@users.sourceforge.net wrote:
On 6/9/2013 08:09, Daniel Verkamp wrote:
So, this leads us to a list of questions:
Why does --dynamicbase not enable generation of .reloc?
Barring that, is the -pie option the correct way to force generation
of .reloc
Patch is ok. Please apply.
JonY could you regenerate Makefile for it?
Thanks in advance,
Kai
2013/7/13 dw limegreenso...@yahoo.com:
Here is the patch jon_y asked for. It contains 1 change:
- Add _libm_dummy.c to lib32_libmoldname_a_SOURCES and
lib64_libmoldname_a_SOURCES so the archive
1) Move these functions to intrin-impl.h:
_BitScanForward, _BitScanReverse
_BitScanForward64, _BitScanReverse64
2) Update inline asm code:
*a) Remove memory clobber*.
*b) Remove volatile keyword.*
/c) Change (Mask) from output to input//.
//d) Change constraint for (n) to r//.
/e) add cc
Thanks. Parcg is fine.
Kai
Am 14.07.2013 15:42 schrieb dw limegreenso...@yahoo.com:
1) Move these functions to intrin-impl.h:
_BitScanForward, _BitScanReverse
_BitScanForward64, _BitScanReverse64
2) Update inline asm code:
*a) Remove memory clobber*.
*b) Remove volatile keyword.*
*c)
I believe JonY is halfway thru making a big change. That's why he had
me do the patch.
dw
On 7/14/2013 2:59 PM, Kai Tietz wrote:
Patch is ok. Please apply.
JonY could you regenerate Makefile for it?
Thanks in advance,
Kai
2013/7/13 dw limegreenso...@yahoo.com:
Here is the patch
When I build C apps with mingwbuilds 4.8.1-win32-sjlj, the built artifacts have
a runtime dependency on
`libgcc_s_sjlj-1.dll`. This is not the case when I use the rubenvb toolchains.
My understanding is that the `libgcc_s_sjlj-1.dll` dependency is only required
for C++, not C, apps due
to