public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "daniel.kruegler at googlemail dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/55149] capturing VLA in lambda (error in 4.7.2 ICE in 4.8 Date: Wed, 31 Oct 2012 21:57:00 -0000 [thread overview] Message-ID: <bug-55149-4-diP79lZmRQ@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-55149-4@http.gcc.gnu.org/bugzilla/> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55149 Daniel Krügler <daniel.kruegler at googlemail dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |daniel.kruegler at | |googlemail dot com --- Comment #1 from Daniel Krügler <daniel.kruegler at googlemail dot com> 2012-10-31 21:56:58 UTC --- I think your example codes involves at least two different issues here. In the following my data was realized by using gcc 4.8.0 20121014 (experimental) with the flags -Wall -std=c++11 -pedantic First a test case can be constructed that involves attempting to capture the VLA alone, like this: //------------------ void test(int n) { int r[n]; [r]() { return r + 0; }; } //------------------ giving me "3|internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:2045|" I expect that code to result in a problem for the compiler, because according to 5.1.2 p21 captured arrays are really copied element-by-element and *no* previous array-to-pointer conversion shall proceed. But VLAs are effectively not prepared to be copied (in all other expressions they would first undergo an array to pointer conversion). The second (more complex) problem seems to be related to the fact that this lambda closure with an VLA capture also attempts to capture an integer (I don't know why this is a problem), which becomes observable here //---------------------- template<class T> void f(T){ } void test(int n, int m) { int r[n]; f([r, m](){ return r + m; }); } //---------------------- "|6|internal compiler error: tree check: expected integer_cst, have mult_expr in walk_subobject_offsets, at cp/class.c:3431|" The same problem here: template<class T> void f(T){ } void test(int n, int m) { int r[n]; f([=](){ return r + m; }); } I found that to produce this effect, both a VLA and an integer must be captured by copy. I think it doesn't make sense technically to capture a VLA by copy because that would require to copy a VLA - this seems something not foreseen for them by the nature of that type. In this sense your "workaround" really seems necessary to me and is *not* equivalent to the "#ifdef VLA" branch. This is one of the rare situations where array-to-pointer conversions does not immediately happen to an array.
next prev parent reply other threads:[~2012-10-31 21:57 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-10-31 13:02 [Bug c++/55149] New: " vincenzo.innocente at cern dot ch 2012-10-31 21:57 ` daniel.kruegler at googlemail dot com [this message] 2012-11-07 9:40 ` [Bug c++/55149] [4.8 Regression] capturing VLA in lambda jakub at gcc dot gnu.org 2012-11-07 15:01 ` [Bug c++/55149] " paolo.carlini at oracle dot com 2012-11-30 9:31 ` paolo.carlini at oracle dot com 2012-11-30 9:33 ` paolo.carlini at oracle dot com 2013-04-17 14:19 ` paolo.carlini at oracle dot com 2013-05-10 0:56 ` paolo.carlini at oracle dot com 2013-05-10 14:31 ` jason at gcc dot gnu.org 2013-05-10 14:59 ` paolo.carlini at oracle dot com 2013-06-06 21:16 ` david.abdurachmanov at gmail dot com 2013-06-07 13:34 ` jason at gcc dot gnu.org 2013-06-07 17:01 ` david.abdurachmanov at gmail dot com 2013-06-07 23:29 ` paolo.carlini at oracle dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-55149-4-diP79lZmRQ@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).