[Bug c++/56611] New: [C++11] Template instanciation failure with variadic arguments and template aliases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56611 Bug #: 56611 Summary: [C++11] Template instanciation failure with variadic arguments and template aliases Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: antoine...@gmail.com The attached code fails to compile because of failed template instanciation / type matching, but seems correct, compiles with clang, and can be made to compile with gcc with minor modifications (see code comments). Problem statement: R need result2 but the compiler does not seem able to instanciate result2. If result2 is explicitly instanciated, the code compiles. Also if template alias result2 is replaced with a typedef in a class (result1) the code compiles. __ gcc 4.7.2 configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.7.2-2ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --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
[Bug c++/56611] [C++11] Template instanciation failure with variadic arguments and template aliases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56611 --- Comment #2 from Antoine Poliakov 2013-03-13 11:09:19 UTC --- Created attachment 29662 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29662 g++ -std=c++11 -Wall -Wextra -c gcc-test.cpp
[Bug c++/56611] [C++11] Template instantiation failure with variadic arguments and template aliases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56611 --- Comment #3 from Antoine Poliakov 2013-03-13 11:12:25 UTC --- (In reply to comment #1) > The attachment is missing. Thanks! I got an error on first upload, but I thought it was ok - sorry.
[Bug c++/56611] [C++11] Template instantiation failure with variadic arguments and template aliases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56611 --- Comment #7 from Antoine Poliakov 2013-03-13 12:15:30 UTC --- Thanks. You can remove struct result1 (lines 11-15 in alias-decl-32.C) from the test-case, it's not necessary (I would have done it but it's a very minor edit and I don't have commit right).
[Bug c++/56669] New: Short code causes segfault with large -ftemplate-depth
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56669 Bug #: 56669 Summary: Short code causes segfault with large -ftemplate-depth Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: antoine...@gmail.com Created attachment 29701 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29701 Code causing segault with large -ftemplate-depth Attached code compiled with g++ -Wall -std=c++11 -c -ftemplate-depth=65536 causes gcc (4.7.2 & 4.8.0) to segfault. The attached code is obviously a little demanding on the compiler and segfault only occurs with large -ftemplate-depth, but still a segfault is not nice and might be triggered by more mundane code?
[Bug c++/56669] Short code causes segfault with large -ftemplate-depth
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56669 --- Comment #1 from Antoine Poliakov 2013-03-20 14:46:27 UTC --- Created attachment 29702 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29702 error message from 4.8.0 with stack trace
[Bug c++/51304] gcc segfaults for large -ftemplate-depth values (if depth is reached)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51304 --- Comment #4 from Antoine Poliakov 2013-03-20 16:52:35 UTC --- Yes, I also submitted the bug (15551) to clang. Doesn't seem to kill intel's icc though.
[Bug c++/56687] New: [C++11] No visibility check within static_assert
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56687
Bug #: 56687
Summary: [C++11] No visibility check within static_assert
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: antoine...@gmail.com
template struct same {static const bool value = false; };
template struct same {static const bool value = true; };
template class id { typedef T type; };
static_assert( same::type /* private */ >::value, "bad type");
Compile with -std=c++11 -Wall -pedantic
Neither gcc nor g++ triggers an error, though id::type should not be
accessible (private)!
[Bug libstdc++/53169] New: Memory leak in std::vector
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53169 Bug #: 53169 Summary: Memory leak in std::vector Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: antoine...@gmail.com Created attachment 27268 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27268 Test case: 500Mb used after memory neutral function returns! The attached source is a minimal test case, implementing a sparse array of std::vectors in class Collection, and test() demonstrates its use in a memory neutral way (all allocated objects are freed). When compiled on x86-64 linux with gcc 4.6.1, gcc 4.7.1 and clang 3.0 (using GNU libstdc++), tools such as top show that memory increases when running test(), but does not not decrease after the function exits: 500Mb are lost in this test case. Just increase to loop count and make that 4Gb if you wish: the amount of leaked memory don't seem to be bounded. `valgrind --leak-check=full ./a.out` reports there is not a single byte leaked, which I double checked with the heap profiler from google perf tools. The memory is reserved by libstdc++ and unavailable to other processes or subsequent malloc/frees within the same program. Subsequent C++ STL allocations (e.g. resizing a big vector) on the other hand don't register on process memory and seem to ruse the reserved buffers; sometimes they even trigger deallocation of the "leaked" memory. For example when running test() multiple times, the bug only occurs on the first call. Subsequent calls free memory when done. I guess the reserved memory is accounted for within libstdc++ internals, and deallocated on finalization which is why valgrind can't see it. My application is a sequence of memory intensive operations, and this bug prevents memory from being freed between steps, and the system quickly runs out of memory. Thanks a lot! *** Note: As this is quite time-critical for me, if someone points me in the right direction (files, classes involved) I can try to investigate this and send back a patch.
[Bug libstdc++/53169] Memory leak in std::vector
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53169
--- Comment #5 from Antoine Poliakov 2012-04-30
15:27:16 UTC ---
(In reply to comment #2)
> So it's possible to get the memory libstdc+ allocates to be returned to the
> system, but it's under the control of glibc, nothing to do with std::vector or
> libstdc++
>
> If your memory usage patterns don't result in memory being returned then there
> are several posibilities, including not freeing memory when you think you are,
> or fragmenting the heap so that later allocations cannot re-use memory
> returned
> to freelists and must allocate new memory using mmap.
>
> Not a GCC bug though.
Thanks a lot for explaining this, and sorry for the invalid bug report.
There is probably a lot of memory fragmentation going on, but what's bothering
me is that if you launch several processes with { test(); sleep(30); }, waiting
each time for test() to return you will eventually begin to swap and go out of
memory. So the freed memory is not exactly available to other processes: that's
not just a counter problem.
Thanks for your feedback, and the
[Bug libstdc++/53169] Memory leak in std::vector
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53169 --- Comment #6 from Antoine Poliakov 2012-04-30 15:31:17 UTC --- (In reply to comment #4) > (In reply to comment #3) > > You should probably use sbrk and/or experiment with > > Sorry, I meant use strace, *not* sbrk! malloc_trim(0) saved the day! Thanks again
