[Bug c++/71386] Wrong code on c++14 (GCC trunk)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71386 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.0 --- Comment #10 from Paolo Carlini --- Fixed in trunk.
[Bug c++/71386] Wrong code on c++14 (GCC trunk)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71386 --- Comment #9 from paolo at gcc dot gnu.org --- Author: paolo Date: Mon Oct 2 12:40:26 2017 New Revision: 253350 URL: https://gcc.gnu.org/viewcvs?rev=253350=gcc=rev Log: 2017-10-02 Paolo CarliniPR c++/79180 * g++.dg/cpp0x/lambda/lambda-nested8.C: New. * g++.dg/torture/pr79180.C: Likewise. PR c++/71386 * g++.dg/cpp1y/lambda-generic-nested1.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nested8.C trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-nested1.C trunk/gcc/testsuite/g++.dg/torture/pr79180.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/71386] Wrong code on c++14 (GCC trunk)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71386 --- Comment #7 from Richard Biener --- ISTR a similar bug in C++ lambda support related how we map them to nested functions. PR69756.
[Bug c++/71386] Wrong code on c++14 (GCC trunk)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71386 --- Comment #6 from Marc Glisse --- Slightly simpler template auto List(XS...xs) { return [=](auto processList){return processList(xs...);}; }; auto l1 = List(42); auto foo = [](auto... xs1) { return [=]() { return l1([=](auto) { return __builtin_printf("%d",xs1...); }); }; }; int main() { auto concat = l1(foo); concat(); __builtin_printf("\n"); } If I make xs1 non-variadic (just erase '...' in 2 places), things work. The main difference seems to be in[with auto:2 = {int}] (we write to some place in the stack then re-read the value from another place) but it isn't clear what is going wrong there.
[Bug c++/71386] Wrong code on c++14 (GCC trunk)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71386 --- Comment #5 from Marc Glisse --- (In reply to Anton Mitrokhin from comment #3) > I see those warnings with -O3, but not with -O0. Why is that? As the documentation says, this warning depends on optimizations. A bogus optimization that breaks the code may thus also cause this warning. > I also do not see what is wrong with the code. If you manage to reduce the example a little more, with fewer lambdas, that might help with the debugging.
[Bug c++/71386] Wrong code on c++14 (GCC trunk)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71386 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-06-26 Ever confirmed|0 |1 --- Comment #4 from Andrew Pinski --- Confirmed, looks like GCC is getting confused somewhere but I can't figure it out easily.
[Bug c++/71386] Wrong code on c++14 (GCC trunk)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71386 --- Comment #3 from Anton Mitrokhin --- I see those warnings with -O3, but not with -O0. Why is that? I also do not see what is wrong with the code. Note, that clang with all warnings enabled (and ub sanitizer!) will also not produce any warnings and will generate correct code.
[Bug c++/71386] Wrong code on c++14 (GCC trunk)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71386 --- Comment #2 from Andrew Pinski --- With -Wall -W I get the following warnings from gcc: t9.cc: In function ‘int main()’: t9.cc:37:44: warning: ‘xs1#0’ is used uninitialized in this function [-Wuninitialized] auto print_func = [](int x){printf("%d ",x);return x;}; ^ t9.cc:9:30: note: ‘xs1#0’ was declared here return [=](auto processList){return processList(xs...);}; ^ t9.cc:37:44: warning: ‘xs1#1’ is used uninitialized in this function [-Wuninitialized] auto print_func = [](int x){printf("%d ",x);return x;}; ^ t9.cc:9:30: note: ‘xs1#1’ was declared here return [=](auto processList){return processList(xs...);}; ^ t9.cc:37:44: warning: ‘xs1#2’ is used uninitialized in this function [-Wuninitialized] auto print_func = [](int x){printf("%d ",x);return x;}; ^ t9.cc:9:30: note: ‘xs1#2’ was declared here return [=](auto processList){return processList(xs...);}; ^
[Bug c++/71386] Wrong code on c++14 (GCC trunk)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71386 --- Comment #1 from Anton Mitrokhin --- Could anyone please take a look?