[Bug c++/51829] decltype() deduces non-const but only in a template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51829 --- Comment #8 from Seth Heeren bugs at sehe dot nl 2012-10-15 21:14:45 UTC --- That is great. I confirmed this with gcc version 4.7.0 20111010 (experimental) [trunk revision 179769] The problem has been solved. Thanks everyone, Seth
[Bug c++/51829] decltype() deduces non-const but only in a template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51829 --- Comment #5 from Seth Heeren bugs at sehe dot nl 2012-05-13 00:05:00 UTC --- On 13-05-12 00:46, paolo.carlini at oracle dot com wrote: Still waiting. Really. Well, to be honest, I can't afford to spend even more time minimizing that any further. I have to pick priorities. For quick win, of course, you could check whether the problem still exists with GCC 4.7 or dev versions. It might have been fixed in the process of other development/fixes. God knows I had spent over 6 hours trying to minimize that by manually decimating the preprocessed sources even before initially posting the report. And it wasn't even my own bug; it was a support call on the [spirit-general] list. I don't think it is worth my time to **learn** how to further reduce the testcase further, since that seems to be a highly specialized craft and, tools could do a good job. I'd be rather surprised if the GCC team didn't have just such tools, as well as people skilled and experienced in using them. All of the above would require a lot of time on my side, and sadly I don't have it. Regards Seth
[Bug c++/51829] New: decltype() deduces non-const but only in a template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51829
Bug #: 51829
Summary: decltype() deduces non-const but only in a template
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: b...@sehe.nl
The problem rejects a valid `auto expr = ...;` initialization. I have reduced
things to the following (full preprocessed version attached)
The template arguments aren't relevant (unused).
#include boost/spirit/include/qi_eps.hpp
template typename // without template, works!
void bug()
{
const auto e1 = boost::spirit::qi::eps(false);
const auto e2 = e1 | '1';
decltype(boost::spirit::qi::eps(false) | '1') *notok;
notok = e2; // FAILS if in template function
}
int main() { bugvoid(); }
By using a pointer declaration for `notok` I was able to use demangling to
print the difference between the deduced types:
boost::proto::exprns_::exprboost::proto::tagns_::tag::bitwise_or,
boost::proto::argsns_::list2boost::proto::exprns_::exprboost::proto::tagns_::tag::terminal,
boost::proto::argsns_::termboost::spirit::terminal_exboost::spirit::tag::eps,
boost::fusion::vector1bool , 0l const,
boost::proto::exprns_::exprboost::proto::tagns_::tag::terminal,
boost::proto::argsns_::termchar const, 0l , 2l
boost::proto::exprns_::exprboost::proto::tagns_::tag::bitwise_or,
boost::proto::argsns_::list2boost::proto::exprns_::exprboost::proto::tagns_::tag::terminal,
boost::proto::argsns_::termboost::spirit::terminal_exboost::spirit::tag::eps,
boost::fusion::vector1bool , 0l CONST,
boost::proto::exprns_::exprboost::proto::tagns_::tag::terminal,
boost::proto::argsns_::termchar const, 0l , 2l const*
The 'CONST' I capitalized in the middle, is missing when the decltype() is in a
function template, which prevents the assignment.
I don't know how to further reduce the testcase at this point in time. MSVC
2010 compiles the code without problem.
[Bug c++/51829] decltype() deduces non-const but only in a template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51829 --- Comment #1 from Seth Heeren bugs at sehe dot nl 2012-01-11 21:32:11 UTC --- Created attachment 26302 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26302 (gz) preprocessed source for the minimal testcase
[Bug c++/51829] decltype() deduces non-const but only in a template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51829 --- Comment #2 from Seth Heeren bugs at sehe dot nl 2012-01-12 00:30:36 UTC --- To clarify, the valid code that was rejected looks like: auto expr = boost::spirit::qi::eps(false) | '1'; this might explain the 'strange' breaking up into e1 and e2 for the minimal testcase. HTH
[Bug libstdc++/48750] for_each_template_random_access_ed has unbalanced new/delete[]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48750 --- Comment #19 from Seth Heeren bugs at sehe dot nl 2011-05-03 15:47:28 UTC --- Cheers!
[Bug libstdc++/48750] for_each_template_random_access_ed has unbalanced new/delete[]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48750 --- Comment #15 from Seth Heeren bugs at sehe dot nl 2011-04-27 09:51:26 UTC --- Probably redundant info, but the compiler used in my prior post is sehe@sid:~$ g++-4.6 -v Using built-in specs. COLLECT_GCC=g++-4.6 COLLECT_LTO_WRAPPER=/usr/lib/gcc/i486-linux-gnu/4.6.1/lto-wrapper Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.0-2' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr --program-suffix=-4.6 --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.6 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default --with-plugin-ld --enable-objc-gc --enable-targets=all --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.6.1 20110329 (prerelease) (Debian 4.6.0-2)
[Bug libstdc++/48750] for_each_template_random_access_ed has unbalanced new/delete[]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48750 --- Comment #14 from Seth Heeren bugs at sehe dot nl 2011-04-27 09:48:57 UTC --- I just built a debian SID chroot and applied the diff to it's libstdc++6 (4.6.0-2), and tested your patch with the minimal.cpp from this bug report patch -p1 ~sehe/attachment.cgi?id=24108 patching file parallel/multiway_merge.h patching file parallel/losertree.h patching file parallel/par_loop.h Hunk #1 succeeded at 91 with fuzz 1. patching file parallel/quicksort.h patching file parallel/random_shuffle.h patching file parallel/multiway_mergesort.h patching file parallel/partial_sum.h g++-4.6 -g -O0 -fopenmp minimal.cpp -o minimal -save-temps valgrind --leak-check=full ./minimal ==5960== LEAK SUMMARY: ==5960==definitely lost: 0 bytes in 0 blocks ==5960==indirectly lost: 0 bytes in 0 blocks ==5960== possibly lost: 456 bytes in 3 blocks ==5960==still reachable: 1,748 bytes in 3 blocks ==5960== suppressed: 0 bytes in 0 blocks The allocation possibly lost are attributed to GOMP_parallel_start from numeric:99). Helgrind gives quite the array of possible data races. I don't know whether I need to worry about them (as I don't know what kind of thread primitives GOMP uses internally and if helgrind supports them). If you want I can attach precompiled sources + val/helgrind outputs
[Bug libstdc++/48750] New: for_each_template_random_access_ed has unbalanced new/delete[]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48750
Summary: for_each_template_random_access_ed has unbalanced
new/delete[]
Product: gcc
Version: 4.4.4
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: b...@sehe.nl
thread_results is allocated using scalar new, yet deleted with array delete[]
Version of libs (ubuntu package): libstdc++6-4.4-dev through libstdc++6-4.6-dev
Version of compiler: g++ (Ubuntu/Linaro 4.4.4-14ubuntu5) 4.4.5
Also with: g++ (Debian 4.5.2-8) 4.5.2
Snippets:
/usr/include/c++/4.4/parallel/par_loop.h:87
# pragma omp single
{
num_threads = omp_get_num_threads();
thread_results = static_castResult*(
::operator new(num_threads * sizeof(Result)));
constructed = new bool[num_threads];
}
but line 127:
delete[] thread_results;
This is unbalanced, and leads to the expected valgrind errors. Attached is a
snippet (originally from
http://stackoverflow.com/questions/5769908/unexpected-segfault-with-gnu-parallelaccumulate)
that will segfault.
I witnessed the segfault went away when fixing the `delete[]` into `delete`.
However, I think it should be evaluated whether the optimized (uninitializing)
allocation of thread_results is safe to do (valgrind keeps reporting
uninitialized memory references even if the attached example doesn't segfault
anymore).
I'll attach the sources in 10 minutes due to time restriction and browser
flakiness
[Bug libstdc++/48750] for_each_template_random_access_ed has unbalanced new/delete[]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48750 --- Comment #1 from Seth Heeren bugs at sehe dot nl 2011-04-24 11:51:17 UTC --- Created attachment 24089 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24089 minimal example Compiled with g++ -g -O0 -fopenmp minimal.cpp -o minimal -save-temps
[Bug libstdc++/48750] for_each_template_random_access_ed has unbalanced new/delete[]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48750 --- Comment #6 from Seth Heeren bugs at sehe dot nl 2011-04-24 12:54:15 UTC --- That _is quick response. Thank you. I'll keep an eye on this one
