[Bug c++/56815] New: void pointer arithmetic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56815
Bug #: 56815
Summary: void pointer arithmetic
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d@ngs.ru
int main()
{
void *p = 0;
p += 1;
}
$ gcc -std=c++98 source.cpp
source.cpp: In function 'int main()':
source.cpp:4:7: warning: pointer of type 'void *' used in arithmetic
[-Wpedantic]
p += 1;
^
Why only warning? It must be error. Other compilers reject this code.
[Bug c++/56815] void pointer arithmetic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56815
--- Comment #1 from __vic 2013-04-02 17:00:23 UTC ---
Slightly modified:
int main()
{
void *p = 0;
p++;
}
$ gcc -std=c++98 source.cpp
source.cpp:4:6: error: arithmetic on a pointer to void
p++;
~^
[Bug c++/56815] void pointer arithmetic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56815 --- Comment #3 from __vic 2013-04-02 17:10:15 UTC --- (In reply to comment #2) > void* arithmetic is a GCC extension. But why my examples are treated differently?
[Bug c++/56815] void pointer arithmetic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56815 --- Comment #5 from __vic 2013-04-03 06:24:43 UTC --- (In reply to comment #4) > From gcc manpage, the option '-std=' specifies base standard and > accept some GNU extensions that do not contradict it. > > If you would like to issue warnings/errors demanded by strict > ISO C and ISO C++, the -pedantic/-pedantic-errors are required. Ok, thanks. It works. But still. What is the difference between +=1 and ++ ? It's the same operation.
[Bug c++/56815] void pointer arithmetic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56815 __vic changed: What|Removed |Added Severity|normal |minor
[Bug libstdc++/54513] New: "undefined reference to `___tls_get_addr'" when linking .so with libstdc++.a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54513
Bug #: 54513
Summary: "undefined reference to `___tls_get_addr'" when
linking .so with libstdc++.a
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d@ngs.ru
Target: i686-pc-linux-gnu
Program:
#include
void f() {}
Build command:
$ g++ -shared -static-libstdc++ -static-libgcc -Wl,-s -Wl,--no-undefined 1.cpp
/opt/gcc-4.7.1/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../libstdc++.a(future.o)(.gnu.linkonce.t._ZSt16__once_call_implISt12_Bind_simpleIFSt7_Mem_fnIMSt6threadFvvEESt17reference_wrapperIS2_vv+0x17):
In function `void std::__once_call_impl ()(std::reference_wrapper)> >()':
/home/vdyachenko/work/gcc-4.7.1/i686-pc-linux-gnu/libstdc++-v3/include/mutex:787:
undefined reference to `___tls_get_addr'
/opt/gcc-4.7.1/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../libstdc++.a(future.o)(.gnu.linkonce.t._ZSt9call_onceIMSt6threadFvvEISt17reference_wrapperIS0_EEEvRSt9once_flagOT_DpOT0_+0x34):
In function
`_ZSt9call_onceIMSt6threadFvvEJSt17reference_wrapperIS0_EEEvRSt9once_flagOT_DpOT0_':
/home/vdyachenko/work/gcc-4.7.1/i686-pc-linux-gnu/libstdc++-v3/include/mutex:809:
undefined reference to `___tls_get_addr'
/opt/gcc-4.7.1/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../libstdc++.a(future.o)(.gnu.linkonce.t._ZSt9call_onceIMSt6threadFvvEISt17reference_wrapperIS0_EEEvRSt9once_flagOT_DpOT0_+0x45):/home/vdyachenko/work/gcc-4.7.1/i686-pc-linux-gnu/libstdc++-v3/include/mutex:810:
undefined reference to `___tls_get_addr'
/opt/gcc-4.7.1/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../libstdc++.a(mutex.o)(.text.__once_proxy+0x17):
In function `__once_proxy':
../../../.././libstdc++-v3/src/c++11/mutex.cc:90: undefined reference to
`___tls_get_addr'
/opt/gcc-4.7.1/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../libstdc++.a(eh_globals.o)(.text.__cxa_get_globals_fast+0x14):
In function `__cxa_get_globals_fast':
../../.././libstdc++-v3/libsupc++/eh_globals.cc:59: undefined reference to
`___tls_get_addr'
/opt/gcc-4.7.1/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../libstdc++.a(eh_globals.o)(.text.__cxa_get_globals+0x14):../../.././libstdc++-v3/libsupc++/eh_globals.cc:63:
more undefined references to `___tls_get_addr' follow
collect2: error: ld returned 1 exit status
make: *** [a.out] Error 1
OS: CentOS 4
$ uname -a
Linux jansmb 2.6.9-103.ELsmp #1 SMP Fri Dec 9 04:31:51 EST 2011 i686 i686 i386
GNU/Linux
[Bug libstdc++/54513] "undefined reference to `___tls_get_addr'" when linking .so with libstdc++.a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54513 --- Comment #1 from __vic 2012-09-07 07:19:43 UTC --- Note: compiler with stdlib was built manually from sources
[Bug libstdc++/54513] "undefined reference to `___tls_get_addr'" when linking .so with libstdc++.a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54513 --- Comment #3 from __vic 2012-09-07 08:58:39 UTC --- $ g++ -shared -static-libstdc++ -static-libgcc -Wl,-s -Wl,--no-undefined 1.cpp /lib/ld-linux.so.2 works fine. Thanks
[Bug libstdc++/53680] New: Link problems with static libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53680 Bug #: 53680 Summary: Link problems with static libstdc++ Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: d@ngs.ru Target: i686-pc-linux-gnu The same problem as fixed in Bug 12595 but in Release 4.7: versioned symbols in the static libstdc++.a
[Bug libstdc++/53680] Link problems with static libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53680 --- Comment #2 from __vic 2012-06-15 08:30:06 UTC --- $ uname -a Linux m246 2.6.18-194.26.1.el5 #1 SMP Tue Nov 9 12:54:40 EST 2010 i686 i686 i386 GNU/Linux $ cat /etc/*-release CentOS release 5.4 (Final) When building on $ uname -a Linux jansmb 2.6.9-103.ELsmp #1 SMP Fri Dec 9 04:31:51 EST 2011 i686 i686 i386 GNU/Linux $ cat /etc/*-release CentOS release 4.9 (Final) it's all right
[Bug libstdc++/53680] Link problems with static libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53680 --- Comment #3 from __vic 2012-06-15 08:34:13 UTC --- When I'm trying link libstdc++.a statically to my .so I see messages like: "undefined versioned symbol name std::defer_lock@@GLIBCPP_3" $ nm libstdc++.a | grep @ shows me that archive contains versioned symbols. Do you need the entire list?
[Bug libstdc++/49894] [C++0x] Uniform initialization in constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49894 __vic changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #13 from __vic 2012-06-15 08:51:36 UTC --- NSDMI works fine. Thanx
[Bug libstdc++/53680] Link problems with static libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53680 --- Comment #4 from __vic 2012-06-15 08:57:21 UTC --- Note: undocumented configure option --disable-symvers helps but I think building with default parameters must work properly
[Bug libstdc++/53680] Versioned symbols in static libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53680 --- Comment #5 from __vic 2012-06-15 10:22:36 UTC --- The exact description: $ g++ -o formats/alcatel_alm9_decoder.fmt -shared -Llib -static-libgcc -O3 -Wl,-s -Wl,--no-undefined src/alcatel_alm9_decoder.o formats.a decoder.a -ljanuary_tools -ljanuary /usr/bin/ld: formats/alcatel_alm9_decoder.fmt: undefined versioned symbol name _ZSt10adopt_lock@@GLIBCXX_3.4.11 /usr/bin/ld: failed to set dynamic section sizes: Bad value collect2: error: ld returned 1 exit status $ nm lib/libstdc++.a | grep adopt B _ZN9__gnu_cxx10adopt_lockE B _ZSt10adopt_lock@@GLIBCXX_3.4.11
[Bug libstdc++/53680] Versioned symbols in static libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53680 --- Comment #8 from __vic 2012-06-15 10:30:30 UTC --- (In reply to comment #6) > (In reply to comment #4) > > Note: undocumented configure option --disable-symvers helps but I think > > building with default parameters must work properly > > It's not undocumented > http://gcc.gnu.org/onlinedocs/libstdc++/manual/configure.html Ok. But still. It must not be a mandatory option to build correct static lib
[Bug libstdc++/53680] Versioned symbols in static libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53680 --- Comment #9 from __vic 2012-06-15 10:33:13 UTC --- (In reply to comment #7) > isn't this PR 52689 ? Probably it is.
[Bug libstdc++/53680] Versioned symbols in static libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53680 --- Comment #10 from __vic 2012-06-15 10:36:24 UTC --- When 4.7.1 will be released?
[Bug libstdc++/28811] --with-pic vs static libraries and libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28811 --- Comment #18 from __vic 2012-06-27 10:19:18 UTC --- GCC 4.7.1 still fails to link .so against static libstdc++.a in 64-bit mode: $ g++ -shared -fPIC -static-libgcc -static-libstdc++ -o 1.so 1.cpp /usr/bin/ld: /opt/gcc-4.6.1/lib/gcc/x86_64-unknown-linux-gnu/4.6.1/../../../../lib64/libstdc++.a(globals_io.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /opt/gcc-4.6.1/lib/gcc/x86_64-unknown-linux-gnu/4.6.1/../../../../lib64/libstdc++.a: could not read symbols: Bad value collect2: ld returned 1 exit status make: *** [1.so] Error 1 32-bit mode is working: $ g++ -m32 -shared -fPIC -static-libgcc -static-libstdc++ -o 1.so 1.cpp
[Bug libstdc++/28811] --with-pic vs static libraries and libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28811 --- Comment #19 from __vic 2012-06-27 10:27:14 UTC --- I'm sorry, compiler version was 4.6.1 in previous example. Output for 4.7.1: $ g++ -shared -fPIC -static-libgcc -static-libstdc++ -o 1.so 1.cpp /usr/bin/ld: /opt/gcc-4.7.1/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../lib64/libstdc++.a(compatibility.o): relocation R_X86_64_32 against `_ZTIN10__cxxabiv115__forced_unwindE' can not be used when making a shared object; recompile with -fPIC /opt/gcc-4.7.1/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../lib64/libstdc++.a: could not read symbols: Bad value collect2: error: ld returned 1 exit status
[Bug libstdc++/28811] --with-pic vs static libraries and libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28811 --- Comment #23 from __vic --- What actual status of this bug is? Is it fixed or still not?
[Bug other/56811] [4.8/4.9 Regression] libbacktrace causes undefined symbol "_Unwind_GetIPInfo" on ia64-hpux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56811 --- Comment #9 from __vic --- Is there any progress and/or solid plan? The last available version of G++ for HP-UX is 4.7.1 (here http://h21007.www2.hp.com/portal/site/dspp/menuitem.863c3e4cbcdc3f3515b49c108973a801?ciid=2a08725cc2f02110725cc2f02110275d6e10RCRD) Without normal C++11 support and important bug fixes!
[Bug libstdc++/60936] [4.9/5/6/7 Regression] Binary code bloat with std::string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936 --- Comment #17 from __vic --- Created attachment 38319 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38319&action=edit Dirty patch for GCC 5/6 This dirty patch created for GCC5 solves the problem for GCC6 as well. (out_of_range will not contain pretty message)
[Bug libstdc++/60936] [5/6 Regression] Binary code bloat with std::string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936 --- Comment #34 from __vic --- Fixed in 7.1. Shouldn't we close this bug?
[Bug c++/82097] New: Invalid warning: declaration enum does not declare anything
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82097
Bug ID: 82097
Summary: Invalid warning: declaration enum does not declare
anything
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: d.v.a at ngs dot ru
Target Milestone: ---
This code
struct settings
{
enum class step { step1_clear, step2_copy };
step step;
};
inline const char *to_text(enum settings::step v)
{
using step = enum settings::step;
switch(v)
{
case step::step1_clear: return "STEP1";
case step::step2_copy: return "STEP2";
}
}
produces strange warning:
warning: declaration 'enum class settings::step' does not declare anything
using step = enum settings::step;
^~~~
[Bug target/78926] Build fails after update to GCC 6.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78926 --- Comment #14 from __vic --- GCC 7-RC1 now reports lto1: fatal error: bytecode stream in file ‘lib/libssl.a’ generated with LTO version 5.1 instead of the expected 6.0 compilation terminated. lto-wrapper: fatal error: g++ returned 1 exit status compilation terminated. /opt/binutils/bin/ld: fatal error: lto-wrapper failed collect2: error: ld returned 1 exit status in such situation. Very helpful!
[Bug c++/59423] Misleading warning when 'enum class' base type unresolved: elaborated-type-specifier for a scoped enum must not use the ‘class’ keyword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59423 __vic changed: What|Removed |Added CC||d.v.a at ngs dot ru --- Comment #1 from __vic --- GCC 7.1 gives now: error: use of enum 'FaceDirection' without previous declaration when clang fairly says: error: unknown type name 'int8'
[Bug c++/78926] New: Build fails after update to GCC 6.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78926 Bug ID: 78926 Summary: Build fails after update to GCC 6.3 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: d.v.a at ngs dot ru Target Milestone: --- Updated GCC 6.2 -> 6.3 and now see following build error: $ g++ -std=c++14 -pthread -c -MMD -pedantic-errors -Isrc/main -I/usr/local/ssl/include -DASIO_STANDALONE -DASIO_SEPARATE_COMPILATION -DASIO_NO_DEPRECATED -DHTTP_PARSER_STRICT=0 -g -Og -Wall -Wno-switch -Wno-parentheses -o src/main/migration/session.o src/main/migration/session.cpp $ g++ -std=c++14 -pthread -o flexify-engine -Llib -static-libgcc -static-libstdc++ -lssl -lcrypto -lexpat -ldl b_print.c: In function ‘_dopr’: b_print.c:169:1: error: SSE register return with SSE disabled b_print.c:338:28: error: SSE register argument with SSE disabled lto-wrapper: fatal error: g++ returned 1 exit status compilation terminated. /opt/binutils/bin/ld: fatal error: lto-wrapper failed collect2: error: ld returned 1 exit status OpenSSL library (static) built with previous version - GCC 6.2.
[Bug c++/78926] Build fails after update to GCC 6.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78926 __vic changed: What|Removed |Added Known to work||6.2.0 Host||linux-x64 Known to fail||6.3.0 --- Comment #1 from __vic --- Why I see messages about lto-wrapper if LTO isn't used? It's debug build w/o LTO.
[Bug target/78926] Build fails after update to GCC 6.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78926 --- Comment #3 from __vic --- See the first $. Or you mean openssl objects?
[Bug target/78926] Build fails after update to GCC 6.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78926 --- Comment #5 from __vic --- $ gcc -flto -ffunction-sections -fdata-sections -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -c -o uid.o uid.c
[Bug target/78926] Build fails after update to GCC 6.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78926 --- Comment #7 from __vic --- But it works with 6.2
[Bug target/78926] Build fails after update to GCC 6.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78926 --- Comment #8 from __vic --- OpenSSL v 1.0.2j $ env CC="gcc -flto -ffunction-sections -fdata-sections" AR=gcc-ar RANLIB=gcc-ranlib ./config threads no-shared
[Bug target/78926] Build fails after update to GCC 6.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78926 --- Comment #9 from __vic --- $ ld --version GNU gold (GNU Binutils 2.27) 1.12 Built from sources. Both gold and BFD produce the same result
[Bug target/78926] Build fails after update to GCC 6.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78926 --- Comment #11 from __vic --- Yes. As it is said in Comment 0: > OpenSSL library (static) built with previous version - GCC 6.2.
[Bug target/78926] Build fails after update to GCC 6.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78926 --- Comment #12 from __vic --- Actually it can be 6.1 as well. Don't remember exactly.
[Bug target/78926] Build fails after update to GCC 6.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78926 --- Comment #13 from __vic --- Rebuilt openssl with 6.3, the problem has gone. What was that? Bug in the previous version or in the new one?
[Bug libstdc++/60936] [5/6/7 Regression] Binary code bloat with std::string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936 --- Comment #23 from __vic --- Jonathan, have you tried to merge you patch with mine? Yours lacks decoupling of string and iostream in c++11/cow-string-inst.o. I think it's a reason why code size was unaffected
[Bug libstdc++/60936] [5/6 Regression] Binary code bloat with std::string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936 --- Comment #30 from __vic --- Excellent job, Jonathan! With gcc-7-20170212 the binaries are slim again.
[Bug rtl-optimization/63191] [5/6 Regression] 32-bit gcc uses excessive memory during dead store elimination with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63191 __vic changed: What|Removed |Added CC||d.v.a at ngs dot ru --- Comment #18 from __vic --- (In reply to Jakub Jelinek from comment #17) > Fixed. Not planning to backport. So Target Milestone is still 5.5?
[Bug c++/50025] [DR 1288] C++0x initialization syntax doesn't work for class members of reference type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50025
__vic changed:
What|Removed |Added
CC||d.v.a at ngs dot ru
--- Comment #23 from __vic ---
Is it related bug?
struct C
{
const std::string &st_ref;
explicit C(const std::string &st) : st_ref{st}
{
std::cout << &st << ' ' << &st_ref << std::endl;
assert(&st == &st_ref);
}
};
assert() fires! gcc 4.8.2
If we replace st_ref{st} with st_ref(st), assert() doesn't fire.
[Bug libstdc++/60936] New: Binary code bloat with std::string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936
Bug ID: 60936
Summary: Binary code bloat with std::string
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: d.v.a at ngs dot ru
Test program:
#include
int hello()
{
std::string st("abc");
return st.length();
}
Build:
$ g++ -shared -fPIC -static-libgcc -static-libstdc++ -Wl,-s -o $@ $?
Sizes of result:
gcc-4_7-string.so: 171744
gcc-4_8-string.so: 185808
gcc-4_9-string.so: 635960
[Bug libstdc++/60936] Binary code bloat with std::string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936 --- Comment #1 from __vic --- If we use iostream classes (without std::string) the difference isn't so dramatic: 4.7: 800320 4.8: 838944 4.9: 868664 May be it's connected with locales? Has std::string any dependences on it in 4.9?
[Bug libstdc++/60936] Binary code bloat with std::string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936 --- Comment #2 from __vic --- Non-stripped binary built with 4.9 has many symbols from locale. 4.8 - doesn't. How std::string uses locales???
[Bug bootstrap/65763] New: tm.h: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65763 Bug ID: 65763 Summary: tm.h: No such file or directory Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: d.v.a at ngs dot ru Host: x86_64-linux Target: x86_64-linux Build: x86_64-linux gcc-5.1.0-RC-20150412.tar.bz2 build error: ... libtool: compile: /home/vdyachenko/usr/misc/gcc/gcc-5.1.0-RC-20150412/host-x86_64-unknown-linux-gnu/gcc/xg++ -B/home/vdyachenko/usr/misc/gcc/gcc-5.1.0-RC-20150412/host-x86_64-unknown-linux-gnu/gcc/ -nostdinc++ -nostdinc++ -I/home/vdyachenko/usr/misc/gcc/gcc-5.1.0-RC-20150412/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/home/vdyachenko/usr/misc/gcc/gcc-5.1.0-RC-20150412/x86_64-unknown-linux-gnu/libstdc++-v3/include -I/home/vdyachenko/usr/misc/gcc/gcc-5.1.0-RC-20150412/libstdc++-v3/libsupc++ -I/home/vdyachenko/usr/misc/gcc/gcc-5.1.0-RC-20150412/libstdc++-v3/include/backward -I/home/vdyachenko/usr/misc/gcc/gcc-5.1.0-RC-20150412/libstdc++-v3/testsuite/util -L/home/vdyachenko/usr/misc/gcc/gcc-5.1.0-RC-20150412/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/home/vdyachenko/usr/misc/gcc/gcc-5.1.0-RC-20150412/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/vdyachenko/usr/misc/gcc/gcc-5.1.0-RC-20150412/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -B/home/vdyachenko/usr/misc/gcc/gcc-5.1.0-RC-20150412/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/home/vdyachenko/usr/misc/gcc/gcc-5.1.0-RC-20150412/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -B/opt/gcc-5.1/x86_64-unknown-linux-gnu/bin/ -B/opt/gcc-5.1/x86_64-unknown-linux-gnu/lib/ -isystem /opt/gcc-5.1/x86_64-unknown-linux-gnu/include -isystem /opt/gcc-5.1/x86_64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../.././libcc1 -I ../.././libcc1/../include -I ../.././libcc1/../libgcc -I ../host-x86_64-unknown-linux-gnu/gcc -I../.././libcc1/../gcc -I ../.././libcc1/../gcc/c -I ../.././libcc1/../gcc/c-family -I ../.././libcc1/../libcpp/include -I/home/vdyachenko/usr/misc/gcc/gcc-5.1.0-RC-20150412/host-x86_64-unknown-linux-gnu/gmp -I/home/vdyachenko/usr/misc/gcc/gcc-5.1.0-RC-20150412/gmp -I/home/vdyachenko/usr/misc/gcc/gcc-5.1.0-RC-20150412/host-x86_64-unknown-linux-gnu/mpfr/src -I/home/vdyachenko/usr/misc/gcc/gcc-5.1.0-RC-20150412/mpfr/src -I/home/vdyachenko/usr/misc/gcc/gcc-5.1.0-RC-20150412/mpc/src -W -Wall -fvisibility=hidden -g -O2 -D_GNU_SOURCE -MT plugin.lo -MD -MP -MF .deps/plugin.Tpo -c ../.././libcc1/plugin.cc -fPIC -DPIC -o .libs/plugin.o In file included from ../.././libcc1/plugin.cc:34:0: ../.././libcc1/../gcc/gcc-plugin.h:31:16: fatal error: tm.h: No such file or directory compilation terminated. make[3]: *** [plugin.lo] Error 1 make[3]: Leaving directory `/home/vdyachenko/usr/misc/gcc/gcc-5.1.0-RC-20150412/host-x86_64-unknown-linux-gnu/libcc1' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/vdyachenko/usr/misc/gcc/gcc-5.1.0-RC-20150412/host-x86_64-unknown-linux-gnu/libcc1' make[1]: *** [all-libcc1] Error 2 make[1]: Leaving directory `/home/vdyachenko/usr/misc/gcc/gcc-5.1.0-RC-20150412' make: *** [all] Error 2 $ uname -a; cat /etc/*-release Linux m247.meranetworks.ru 2.6.18-308.1.1.el5 #1 SMP Wed Mar 7 04:16:51 EST 2012 x86_64 x86_64 x86_64 GNU/Linux CentOS release 5.8 (Final) $ ./configure --prefix=/opt/gcc-5.1 --enable-languages=c,c++ --enable-lto What information is required additionally?
[Bug bootstrap/65763] tm.h: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65763 --- Comment #2 from __vic --- Will it help? OK, I'll try.
[Bug bootstrap/65763] tm.h: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65763 --- Comment #6 from __vic --- (In reply to __vic from comment #2) > Will it help? OK, I'll try. Yes. Has been built successfully. Thanks! P.S. I've read doc about building in a separate directory but all previous versions in practice used to be built successfully within source tree. Won't try to do it again.
[Bug libstdc++/60936] [4.9/5 Regression] Binary code bloat with std::string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936 --- Comment #6 from __vic --- 5.1-RC (gcc-5.1.0-RC-20150412) - the same problem. Suppose in GCC 6 too?
[Bug libstdc++/60936] [4.9/5/6 Regression] Binary code bloat with std::string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936
--- Comment #9 from __vic ---
For 4.9 this change was enough for me:
--- libstdc++-v3/src/c++11/functexcept.cc2014-01-03 02:30:10.0
+0400
+++ libstdc++-v3/src/c++11/functexcept.cc2014-11-06 18:40:20.0
+0300
@@ -89,6 +89,7 @@
void
__throw_out_of_range_fmt(const char* __fmt, ...)
{
+__throw_out_of_range(__fmt);/*
const size_t __len = __builtin_strlen(__fmt);
// We expect at most 2 numbers, and 1 short string. The additional
// 512 bytes should provide more than enough space for expansion.
@@ -100,6 +101,7 @@
__gnu_cxx::__snprintf_lite(__s, __alloca_size, __fmt, __ap);
_GLIBCXX_THROW_OR_ABORT(out_of_range(_(__s)));
va_end(__ap); // Not reached.
+*/
}
void
But now it doesn't solve the problem.
[Bug libstdc++/60936] [4.9/5/6 Regression] Binary code bloat with std::string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936 --- Comment #10 from __vic --- What brings new dependences on locales?
[Bug libstdc++/60936] [4.9/5/6 Regression] Binary code bloat with std::string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936
--- Comment #11 from __vic ---
Main problem hides in src/c++11/cow-string-inst.cc here:
namespace std _GLIBCXX_VISIBILITY(default)
{
_GLIBCXX_BEGIN_NAMESPACE_VERSION
// These came from c++98/misc-inst.cc, repeat them for COW string
// string related to iostreams.
template
basic_istream&
operator>>(basic_istream&, string&);
template
basic_ostream&
operator<<(basic_ostream&, const string&);
template
basic_istream&
getline(basic_istream&, string&, char);
template
basic_istream&
getline(basic_istream&, string&);
_GLIBCXX_END_NAMESPACE_VERSION
} // namespace
It pulls all iostream + locale.
On the whole, dependences between objects within libstdc++ a organized
terribly. When I just use std::string almost all lib will be linked into my
binary!!! If I remove snippet mentioned above + apply fix from Comment 9 this
set of objects is linked:
condition_variable.o
cow-stdexcept.o
cow-string-inst.o
eh_throw.o
functexcept.o
functional.o
futex.o
future.o
ios_failure.o
regex.o
stdexcept.o
string-inst.o
system_error.o
WHY?! I just want std::string!
I use no futures, no regex, no ios::failure, etc... Is all this stuff realy
necessary for my trivial program?
[Bug libstdc++/68133] New: constexpr basic_string_view(const _CharT* __str)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68133
Bug ID: 68133
Summary: constexpr basic_string_view(const _CharT* __str)
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: d.v.a at ngs dot ru
Target Milestone: ---
Compilation of this code:
#include
int main()
{
int arr[std::experimental::string_view("s").length()];
}
produces error:
error: ISO C++ forbids variable length array 'arr' [-Wvla]
Constructor's implementation:
constexpr basic_string_view(const _CharT* __str)
: _M_len{__str == nullptr ? 0 : traits_type::length(__str)},
_M_str{__str}
{ }
But traits_type::length() isn't constexpr
[Bug libstdc++/68133] constexpr basic_string_view(const _CharT* __str)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68133 --- Comment #2 from __vic --- Too much black magic in the library already... I think this is defect in specification/design of the class. But it's easier for you guys to reach the committee than for me
[Bug libstdc++/61658] New: Invalid std::string(size_type, value_type) constructor implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61658
Bug ID: 61658
Summary: Invalid std::string(size_type, value_type) constructor
implementation
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: d.v.a at ngs dot ru
#include
#include
int main()
{
std::string st{1U, '0'};
std::cout << st.length() << '\n';
std::cout << st << '\n';
}
Prints:
2
☺0
Must be:
1
0
[Bug libstdc++/61658] Invalid std::string(size_type, value_type) constructor implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61658
--- Comment #1 from __vic ---
If replace with:
std::string st(1U, '0');
then prints as expected:
1
0
Why {1U, '0'} is treated as std::initializer_list ?
[Bug other/56811] [4.8/4.9/4.10 Regression] libbacktrace causes undefined symbol "_Unwind_GetIPInfo" on ia64-hpux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56811 --- Comment #13 from __vic --- (In reply to Alexander from comment #12) > fixed in GCC 4.8.3 What about 4.9 branch?
[Bug libstdc++/60936] [4.9 Regression] Binary code bloat with std::string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936 __vic changed: What|Removed |Added Summary|Binary code bloat with |[4.9 Regression] Binary |std::string |code bloat with std::string Known to fail||4.9.0, 4.9.1 --- Comment #3 from __vic --- 4.9.1 - same results
[Bug libstdc++/63274] New: std::list uses T(...) instead of T{...} in implementation of emplace()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63274
Bug ID: 63274
Summary: std::list uses T(...) instead of T{...} in
implementation of emplace()
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: d.v.a at ngs dot ru
Example:
#include
struct C { int a, b; };
int main()
{
std::list l;
l.emplace_back(1, 2);
}
$ g++ -std=c++11 -Wall example.cpp
In file included from /opt/gcc-4.9.0/include/c++/4.9.0/list:63:0,
from /tmp/gcc-explorer-compiler114816-7339-16y749p/example.cpp:1:
/opt/gcc-4.9.0/include/c++/4.9.0/bits/stl_list.h: In instantiation of
‘std::_List_node<_Tp>::_List_node(_Args&& ...) [with _Args = {int, int}; _Tp =
C]’:
/opt/gcc-4.9.0/include/c++/4.9.0/ext/new_allocator.h:120:4: required from ‘void
__gnu_cxx::new_allocator<_Tp>::construct(_Up*, _Args&& ...) [with _Up =
std::_List_node; _Args = {int, int}; _Tp = std::_List_node]’
/opt/gcc-4.9.0/include/c++/4.9.0/bits/stl_list.h:514:8: required from
‘std::list<_Tp, _Alloc>::_Node* std::list<_Tp, _Alloc>::_M_create_node(_Args&&
...) [with _Args = {int, int}; _Tp = C; _Alloc = std::allocator;
std::list<_Tp, _Alloc>::_Node = std::_List_node]’
/opt/gcc-4.9.0/include/c++/4.9.0/bits/stl_list.h:1688:63: required from ‘void
std::list<_Tp, _Alloc>::_M_insert(std::list<_Tp, _Alloc>::iterator, _Args&&
...) [with _Args = {int, int}; _Tp = C; _Alloc = std::allocator;
std::list<_Tp, _Alloc>::iterator = std::_List_iterator]’
/opt/gcc-4.9.0/include/c++/4.9.0/bits/stl_list.h:1039:11: required from ‘void
std::list<_Tp, _Alloc>::emplace_back(_Args&& ...) [with _Args = {int, int}; _Tp
= C; _Alloc = std::allocator]’
8 : required from here
/opt/gcc-4.9.0/include/c++/4.9.0/bits/stl_list.h:114:71: error: no matching
function for call to ‘C::C(int, int)’
: __detail::_List_node_base(), _M_data(std::forward<_Args>(__args)...)
^
/opt/gcc-4.9.0/include/c++/4.9.0/bits/stl_list.h:114:71: note: candidates are:
3 : note: C::C()
struct C { int a, b; };
^
3 : note: candidate expects 0 arguments, 2 provided
3 : note: constexpr C::C(const C&)
3 : note: candidate expects 1 argument, 2 provided
3 : note: constexpr C::C(C&&)
3 : note: candidate expects 1 argument, 2 provided
Compilation failed
I suppose it should work without defining constructor for C.
[Bug libstdc++/63274] std::list uses T(...) instead of T{...} in implementation of emplace()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63274
--- Comment #1 from __vic ---
And yes, in this case I can just write
l.push_back({1, 2});
But both cases should be acceptable for compiler, IMO.
[Bug libstdc++/49020] New: Invalid std::strchr prototype in cstring
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49020 Summary: Invalid std::strchr prototype in cstring Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: d@ngs.ru Shall be const char *strchr(const char * , int ); char *strchr(char * , int ); according to Standard. But we have char *strchr(char * , int ); and invalid char *strchr(const char * , int ); from string.h
[Bug libstdc++/49020] Invalid std::strchr prototype in cstring
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49020 --- Comment #3 from __vic 2011-05-17 12:24:56 UTC --- (In reply to comment #1) > You haven't said which version of gcc or which platform. > Actually 3.4.3 on Linux and Windows (MinGW) but in SVN trunk version (r169421) /trunk/libstdc++-v3/include/c_std/cstring I have not found any changes.
[Bug libstdc++/49020] Invalid std::strchr prototype in cstring
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49020 --- Comment #4 from __vic 2011-05-17 12:31:50 UTC --- (In reply to comment #1) > With a recent GCC and recent glibc I get: > In which version of GCC can I find valid implementation?
[Bug libstdc++/49020] Invalid std::strchr prototype in cstring
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49020 __vic changed: What|Removed |Added Version|unknown |4.1.1 --- Comment #5 from __vic 2011-05-17 12:41:29 UTC --- GCC 4.1.1 - still no luck
[Bug libstdc++/49020] Invalid std::strchr prototype in cstring
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49020 __vic changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #7 from __vic 2011-05-17 13:25:31 UTC --- Ok, I'll try to upgrade my GCC version. Thanx
[Bug libstdc++/49020] Invalid std::strchr prototype in cstring
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49020 --- Comment #9 from __vic 2011-05-18 05:33:24 UTC --- The libstdc++ uses glibc anyway? What about alternative implementations like hp-gcc for HP-UX?
[Bug libstdc++/49020] Invalid std::strchr prototype in cstring
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49020 --- Comment #10 from __vic 2011-05-18 05:36:38 UTC --- (In reply to comment #8) > 3.4 and 4.1 are ancient history, active release series are listed on the home > page, http://gcc.gnu.org/ Yes, I know. But I have no ability to upgrade them in all installations
[Bug libstdc++/49020] Invalid std::strchr prototype in cstring
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49020 --- Comment #12 from __vic 2011-05-18 09:06:26 UTC --- (In reply to comment #11) > I don't know what hp-gcc is, but on non-glibc platforms the overloads aren't > correct, see PR 33935 > PR 33935 is mostly about overloads in string.h. I'm not interested in them. Could you clarify what happen in following case. C-implementation don't provides overloads, only standard C prototype in string.h. Can I get standard-conformant prototypes by including cstring from libstdc++ on such platform? According to the trunk version of cstring answer is "No". Is this true?
[Bug libstdc++/49020] Invalid std::strchr prototype in cstring
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49020
__vic changed:
What|Removed |Added
Status|CLOSED |UNCONFIRMED
Version|4.1.1 |4.7.0
Resolution|DUPLICATE |
--- Comment #15 from __vic 2011-05-18 09:30:59 UTC ---
The following code would work anyway:
namespace std {
#ifdef __CORRECT_ISO_CPP_STRING_H_PROTO
using ::strchr;
#else
inline const char *strchr(const char *__s, int __c)
{
return ::strchr(__s, __c);
}
inline char *strchr(char *__s, int __c)
{
return ::strchr(__s, __c);
}
#endif
}
[Bug libstdc++/49020] Invalid std::strchr prototype in cstring
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49020
--- Comment #16 from __vic 2011-05-18 09:55:34 UTC ---
Initial problem is that the following standard-conforming code is not compiled
by GCC.
#include
template
void f(Iter i1, Iter i2)
{
}
int main()
{
const char *st = "abc";
f(st, std::strchr(st, '\0'));
}
Yes, workaround is obvious: add the const_cast to the return value. But is
there a way to do without it?
[Bug libstdc++/49020] Invalid std::strchr prototype in cstring
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49020
__vic changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #19 from __vic 2011-05-18 10:35:51 UTC ---
(In reply to comment #18)
> (In reply to comment #15)
> > The following code would work anyway:
>
> No, it would make this ambiguous:
>
> #include
> using namespace std;
>
> int main()
> {
> strchr("foo", 'f');
> }
>
>
> (In reply to comment #16)
> > Yes, workaround is obvious: add the const_cast to the return value. But is
> > there a way to do without it?
>
> Only with assistance from the C library, which is why this is a dup of PR
> 33935
Yeah. Seems like it's not possible to do if C-library implementer didn't care
about this...
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773 __vic changed: What|Removed |Added CC||d.v.a at ngs dot ru --- Comment #80 from __vic 2011-07-21 07:01:12 UTC --- Gentlemans! It has been 10 years but there is no progress. Why the standard-compliant value is still not defined in platforms other that @#$%#^% Solaris? How do we write universal code for C++98 and C++11 without the proper defined macro?
[Bug c++/47453] Various non-conforming behaviors with braced-init-list initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47453
__vic changed:
What|Removed |Added
CC||d.v.a at ngs dot ru
--- Comment #4 from __vic 2011-07-29 06:08:29 UTC ---
struct A { int a[2]; A():a({1, 2}) { } };
Should be valid. Example:
class cond_variable
{
::pthread_cond_t cond;
public:
constexpr cond_variable() : cond(PTHREAD_COND_INITIALIZER) {}
};
What is pthread_cond_t? Struct? Array? Scalar? How I can be sure this code is
accepted in any case? Uniform initialization initially address this issue.
Out of constructor one can use "=":
::pthread_cond_t cond = PTHREAD_COND_INITIALIZER;
In constructor init-list "=" is prohibited therefore "()" must play a same
role.
[Bug c++/49894] New: Uniform initialization in constructor (C++0x)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49894
Summary: Uniform initialization in constructor (C++0x)
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d@ngs.ru
#include
class cond_variable
{
::pthread_cond_t cond;
public:
constexpr cond_variable() : cond(PTHREAD_COND_INITIALIZER) {}
};
int main() {}
test.cpp: In constructor 'constexpr cond_variable::cond_variable()':
test.cpp:7:84: error: could not convert '{{0, 0}, 0, "", 0}' from
'' to 'pthread_cond_t'
Variant
constexpr cond_variable() : cond((::pthread_cond_t)PTHREAD_COND_INITIALIZER) {}
is Ok.
[Bug c++/49894] Uniform initialization in constructor (C++0x)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49894
--- Comment #1 from __vic 2011-07-29 06:28:47 UTC ---
class mutex
{
::pthread_mutex_t mtx;
public:
constexpr mutex() : mtx(PTHREAD_MUTEX_INITIALIZER) {}
};
Compiles fine... What is the difference?
[Bug c++/49894] Uniform initialization in constructor (C++0x)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49894
--- Comment #3 from __vic 2011-07-29 10:13:16 UTC ---
> test.cpp:7:84: error: could not convert '{{0, 0}, 0, "", 0}' from
> '' to 'pthread_cond_t'
>
Initializer is:
{{0, 0}, 0, "", 0}
[Bug c++/49894] Uniform initialization in constructor (C++0x)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49894 --- Comment #4 from __vic 2011-07-29 10:17:35 UTC --- Created attachment 24861 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24861 Preprocessor output
[Bug c++/47453] Various non-conforming behaviors with braced-init-list initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47453
--- Comment #6 from __vic 2011-08-02 03:25:10 UTC ---
>
> Why not say
>
> constexpr cond_variable() : cond PTHREAD_COND_INITIALIZER { }
>
What if PTHREAD_COND_INITIALIZER is a just scalar?
>
> You can define it as follows to make it work in both cases
>
> #define PTHREAD_COND_INITIALIZER {}
I cannot define/redefine this value. It's already defined in system headers...
[Bug c++/71214] Typo in feature test macro for rvalue references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71214 __vic changed: What|Removed |Added CC||d.v.a at ngs dot ru --- Comment #1 from __vic --- The same in GCC 6.1
[Bug libstdc++/60936] [5/6/7 Regression] Binary code bloat with std::string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936 --- Comment #19 from __vic --- No plans for 6.2?
[Bug ipa/44563] GCC uses a lot of RAM when compiling a large numbers of functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563 --- Comment #36 from __vic --- What about 6.2?
[Bug libstdc++/60936] [5/6/7 Regression] Binary code bloat with std::string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936 --- Comment #20 from __vic --- Patch attachment 38319 solves the problem for GCC 6.2 as well
[Bug libstdc++/60936] [5/6/7 Regression] Binary code bloat with std::string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936 --- Comment #22 from __vic --- Of course. It's comment for people like me who needs solution right now (actually since 2014...)
