[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734 --- Comment #48 from Alexander Varnin fenixk19 at mail dot ru --- Created attachment 34224 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34224action=edit config.log for compiler with the bug Here is my config.log from cross compiler build.
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734 --- Comment #43 from Alexander Varnin fenixk19 at mail dot ru --- And I also confirm that adding -latomic to build options fixes the issue.
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734 --- Comment #45 from Alexander Varnin fenixk19 at mail dot ru --- (In reply to Damien Buhl (daminetreg) from comment #44) While given test works properly with -latomic on my installation, my application doesn't. It fails with segfault in approximately half of launches. Core dump points to some thread execution code. I suppose, it is still broken in some way. Replacing std::thread in my code with pthread_* makes it work properly. So I conclude, that this std::thread and atomic things is broken on my gcc 4.8.2 arm freescale imx53 yocto build.
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734 Alexander Varnin fenixk19 at mail dot ru changed: What|Removed |Added CC||fenixk19 at mail dot ru --- Comment #42 from Alexander Varnin fenixk19 at mail dot ru --- I confirm an issue with G++ 4.8.2 and ARM platform. The platform is Freescale IMX53. OS build with yocto system using these instructions: https://github.com/Freescale/fsl-community-bsp-platform uname -a: Linux imx53qsb 2.6.35.3-gb51e9aa-dirty #34 PREEMPT Wed Dec 3 19:47:54 MSK 2014 armv7l GNU/Linux
[Bug fortran/47007] Values from namelist file should not depend on locale settings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007 --- Comment #14 from Alexander Varnin fenixk19 at mail dot ru 2010-12-20 14:04:08 UTC --- There is internal variants of strtof/strtod/strtold/etc functions in glibc, that allow explicitly set locale of convertion. These functions are base for user variants of strto*. If we only could access these internal functions some way, it would be solution of problem, and not workaround.
[Bug fortran/47007] Values from namelist file should not depend on locale settings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007 --- Comment #6 from Alexander Varnin fenixk19 at mail dot ru 2010-12-19 13:54:58 UTC --- Created attachment 22820 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22820 Test case
[Bug fortran/47007] Values from namelist file should not depend on locale settings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007 --- Comment #7 from Alexander Varnin fenixk19 at mail dot ru 2010-12-19 13:58:35 UTC --- $ gfortran -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.4.4-14ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.4 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5) libc6 version - 2.12.1. This is from Ubuntu 10.10 repo, it is called Embedded GNU C library there.
[Bug fortran/47007] Values from namelist file should not depend on locale settings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007 --- Comment #8 from Alexander Varnin fenixk19 at mail dot ru 2010-12-19 14:13:24 UTC --- Created attachment 22821 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22821 Write namelist test case Here is also test case for writing namelist. It shows, that '.' is used whatever locale is selected. It is fun - i can generate namelist file on ru_RU with '.' as decimal, and then program will fail to read it on the same locale, because it expects ','. Moreover, ',' can't be used as decimal, because it is used to separate values in namelist.
[Bug fortran/47007] Values from namelist file should not depend on locale settings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007 --- Comment #11 from Alexander Varnin fenixk19 at mail dot ru 2010-12-19 18:04:04 UTC --- I was glad to help.
[Bug fortran/47007] New: Values from namelist file should not depend on locale settings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007 Summary: Values from namelist file should not depend on locale settings Product: gcc Version: 4.4.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: fenix...@mail.ru Namelist files can be generated on any platform with any locale settings. And namelist files must be usable among this platforms. But today some data in namelist files depends on locale settings, for example floating point format. So when you try to open namelist file, generated on en_US locale in the environment with ru_RU locale, for example, you get into trouble with reading floating points values. Namelist entry DT=7.302E-011 is read as 7.3E-11 on en_US and as 7 in ru_RU. Namelist should not depend on locale settings, so we can open namelist file generated with any locale settings on any other locale settings, without changing file and locale.
