[Bug libstdc++/55215] New: Constructor seeding is broken for Mersenne twister
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55215 Bug #: 55215 Summary: Constructor seeding is broken for Mersenne twister Classification: Unclassified Product: gcc Version: 4.6.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: w...@beyondunreal.com http://ideone.com/p8B7lF (the code is also provided in attachment). I expected that both functions, f and g, would return the same value every time. But, as we can see, initializing Mersenne using its constructor doesn't yield consistent results. I tested compiler from Visual Studio 2012, and it doesn't have this bug. Other random number engines probably don't have this bug (I tested std::minstd_rand).
[Bug libstdc++/55215] Constructor seeding is broken for Mersenne twister
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55215 --- Comment #1 from wgh at beyondunreal dot com 2012-11-05 16:15:06 UTC --- Created attachment 28619 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28619 reproduction
[Bug c/65208] New: Floats sometimes rounded up instead of being truncated on mips
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65208 Bug ID: 65208 Summary: Floats sometimes rounded up instead of being truncated on mips Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: wgh at beyondunreal dot com Created attachment 34869 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34869action=edit preprocessed input It seems like typical cast from double to unsigned sometimes rounds the result up. On my router, the attached code, compiled with the following commandline mipsel-linux-uclibc-gcc -Wall -Wextra -O2 -static -std=c11 test.c prints 0.7 i=1 i=0 The compiler generates no errors or warnings. Using built-in specs. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/mipsel-linux-uclibc/gcc-bin/4.9.2/mipsel-linux-uclibc-gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/mipsel-linux-uclibc/4.9.2/lto-wrapper Target: mipsel-linux-uclibc Configured with: /var/tmp/portage/cross-mipsel-linux-uclibc/gcc-4.9.2/work/gcc-4.9.2/configure --host=x86_64-pc-linux-gnu --target=mipsel-linux-uclibc --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/mipsel-linux-uclibc/gcc-bin/4.9.2 --includedir=/usr/lib/gcc/mipsel-linux-uclibc/4.9.2/include --datadir=/usr/share/gcc-data/mipsel-linux-uclibc/4.9.2 --mandir=/usr/share/gcc-data/mipsel-linux-uclibc/4.9.2/man --infodir=/usr/share/gcc-data/mipsel-linux-uclibc/4.9.2/info --with-gxx-include-dir=/usr/lib/gcc/mipsel-linux-uclibc/4.9.2/include/g++-v4 --with-python-dir=/share/gcc-data/mipsel-linux-uclibc/4.9.2/python --enable-languages=c --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.9.2 p1.1, pie-0.6.2' --enable-poison-system-directories --disable-shared --disable-shared --disable-libatomic --with-sysroot=/usr/mipsel-linux-uclibc --disable-bootstrap --disable-__cxa_atexit --enable-tls --disable-multilib --disable-altivec --disable-fixed-point --with-abi= --disable-libgcj --disable-libgomp --disable-libmudflap --disable-libssp --disable-libquadmath --enable-lto --without-cloog --enable-libsanitizer Thread model: posix gcc version 4.9.2 (Gentoo 4.9.2 p1.1, pie-0.6.2)
[Bug target/77669] Incorrect LTO code on embedded ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77669 wgh at beyondunreal dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #4 from wgh at beyondunreal dot com --- I've carefully analyzed the assembly code, and different constructor order was indeed the case. Thank you for your help.
[Bug lto/77669] New: Incorrect LTO code on embedded ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77669 Bug ID: 77669 Summary: Incorrect LTO code on embedded ARM Product: gcc Version: 5.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: wgh at beyondunreal dot com Target Milestone: --- So I've been playing around with my STM32 microcontroller and various compiler options, and noticed that my program doesn't work when I build it with LTO. I've observed this behaviour on GCC 4.9.3 and 5.4.0. The problematic piece of code looks like this: auto i = std::uniform_int_distribution<>(0, ncolors - 1)(random_engine); Where random_engine is declared at global level static std::minstd_rand random_engine; The function simply never returns. According to my debugging, the generator returns always zero, and it causes the "downscale" loop inside uniform_int_distribution::operator() (/usr/lib/gcc/armv7m-hardfloat-eabi/5.4.0/include/g++-v5/bits/uniform_int_dist.h) to loop forever. I'll try to post some more debugging info soon. Using built-in specs. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/armv7m-hardfloat-eabi/gcc-bin/5.4.0/armv7m-hardfloat-eabi-g++ COLLECT_LTO_WRAPPER=/usr/libexec/gcc/armv7m-hardfloat-eabi/5.4.0/lto-wrapper Target: armv7m-hardfloat-eabi Configured with: /var/tmp/portage/cross-armv7m-hardfloat-eabi/gcc-5.4.0/work/gcc-5.4.0/configure --host=x86_64-pc-linux-gnu --target=armv7m-hardfloat-eabi --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/armv7m-hardfloat-eabi/gcc-bin/5.4.0 --includedir=/usr/lib/gcc/armv7m-hardfloat-eabi/5.4.0/include --datadir=/usr/share/gcc-data/armv7m-hardfloat-eabi/5.4.0 --mandir=/usr/share/gcc-data/armv7m-hardfloat-eabi/5.4.0/man --infodir=/usr/share/gcc-data/armv7m-hardfloat-eabi/5.4.0/info --with-gxx-include-dir=/usr/lib/gcc/armv7m-hardfloat-eabi/5.4.0/include/g++-v5 --with-python-dir=/share/gcc-data/armv7m-hardfloat-eabi/5.4.0/python --enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 5.4.0 p1.0, pie-0.6.5' --enable-libstdcxx-time --enable-poison-system-directories --with-sysroot=/usr/armv7m-hardfloat-eabi --disable-bootstrap --with-newlib --enable-multilib --disable-altivec --disable-fixed-point --with-float=hard --with-arch=armv7-m --with-mode=thumb --with-float=hard --with-fpu=vfpv3-d16 --disable-libgcj --disable-libgomp --disable-libmudflap --disable-libssp --disable-libcilkrts --disable-libmpx --enable-vtable-verify --enable-libvtv --disable-libquadmath --enable-lto --without-isl --disable-libsanitizer Thread model: single gcc version 5.4.0 (Gentoo 5.4.0 p1.0, pie-0.6.5)
[Bug lto/77669] Incorrect LTO code on embedded ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77669
--- Comment #1 from wgh at beyondunreal dot com ---
The loop in question looks like this, in C++ and aseembly:
if (__urngrange > __urange)
{
// downscaling
const __uctype __uerange = __urange + 1; // __urange can be zero
const __uctype __scaling = __urngrange / __uerange;
const __uctype __past = __uerange * __scaling;
do
__ret = __uctype(__urng()) - __urngmin;
while (__ret >= __past);
__ret /= __scaling;
}
080001d6
<_ZNSt24uniform_int_distributionIiEclISt26linear_congruential_engineIjLj48271ELj0ELj2147483647iRT_RKNS0_10param_typeE.constprop.6>:
...
...
80001f4: f7ff ffda bl 80001ac
<_ZNSt8__detail4_ModIjLj2147483647ELj48271ELj0ELb0ELb1EE6__calcEj>
80001f8: 1e43subsr3, r0, #1
80001fa: 429ccmp r4, r3
80001fc: d9fabls.n 80001f4
<_ZNSt24uniform_int_distributionIiEclISt26linear_congruential_engineIjLj48271ELj0ELj2147483647iRT_RKNS0_10param_typeE.constprop.6+0x1e>
So LCG has been greatly optimized and has become a single __calc call.
gdb shows some extra "fake" frames, even though they have been optimized out.
#0 __calc (__x=0) at
/usr/lib/gcc/armv7m-hardfloat-eabi/5.4.0/include/g++-v5/bits/random.tcc:62
#1 0x080001f8 in std::__detail::__mod(unsigned int) ()
at
/usr/lib/gcc/armv7m-hardfloat-eabi/5.4.0/include/g++-v5/bits/random.h:151
#2 operator() (this=0x2430 ) at
/usr/lib/gcc/armv7m-hardfloat-eabi/5.4.0/include/g++-v5/bits/random.h:332
#3 operator() (this=this@entry=0x2001ffd0, __param=..., __urng=...)
at
/usr/lib/gcc/armv7m-hardfloat-eabi/5.4.0/include/g++-v5/bits/uniform_int_dist.h:242
#4 0x080002be in operator() (__urng=..., this=0x2001ffd0) at
/usr/lib/gcc/armv7m-hardfloat-eabi/5.4.0/include/g++-v5/bits/uniform_int_dist.h:16
The __calc function looks like this in assembly:
080001ac <_ZNSt8__detail4_ModIjLj2147483647ELj48271ELj0ELb0ELb1EE6__calcEj>:
80001ac: f64a 52c8 movwr2, #44488 ; 0xadc8
80001b0: fbb0 f1f2 udivr1, r0, r2
80001b4: fb02 0311 mls r3, r2, r1, r0
80001b8: f64b 428f movwr2, #48271 ; 0xbc8f
80001bc: 4353mulsr3, r2
80001be: f640 5247 movwr2, #3399 ; 0xd47
80001c2: fb02 f001 mul.w r0, r2, r1
80001c6: 4283cmp r3, r0
80001c8: bf3citt cc
80001ca: f103 4300 addcc.w r3, r3, #2147483648 ; 0x8000
80001ce: f103 33ff addcc.w r3, r3, #4294967295 ; 0x
80001d2: 1a18subsr0, r3, r0
80001d4: 4770bx lr
It should calculate x = (ax + c) mod m, where a = 48271u, c = 0u, m =
2147483647u
So in case of x=0, new x will also be zero. Hmm, sounds weird.
[Bug target/77669] Incorrect LTO code on embedded ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77669 --- Comment #2 from wgh at beyondunreal dot com --- It looks like LTO somehow breaks constructors for static variables. I have no better idea ATM.
[Bug lto/59000] lto can't merge user-defined weak builtin functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59000 wgh at beyondunreal dot com changed: What|Removed |Added CC||wgh at beyondunreal dot com --- Comment #6 from wgh at beyondunreal dot com --- Same problem as above when compiling qemu with lto with GCC-5.4.0.
