[Bug middle-end/79992] accessing storage member of lambda via pointer with -no-pie causes the next function to overwrite the pointer's data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79992 --- Comment #1 from Yanai Eliyahu --- Created attachment 40943 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40943&action=edit the .cpp that has the bug
[Bug middle-end/79992] New: accessing storage member of lambda via pointer with -no-pie causes the next function to overwrite the pointer's data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79992 Bug ID: 79992 Summary: accessing storage member of lambda via pointer with -no-pie causes the next function to overwrite the pointer's data Product: gcc Version: 6.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: yanai.eli11 at gmail dot com Target Milestone: --- See attached file for code, and compile it with `-no-pie`; I tried `-fno-strict-aliasing -fwrapv` and the problem still reproduces. Language: C++ Exact GCC version: 6.2.0 20161005 (Ubuntu 6.2.0-5ubuntu12) OS: Ubuntu Overall the problem is that when getting a pointer of member of lambda in certain flow, the pointer will point to the stack, and provoke other functions to overwrite it. I proved it by printing the variable twice without a gap, and it printed something else the second time.
[Bug middle-end/79992] accessing storage member of lambda via pointer with -no-pie causes the next function to overwrite the pointer's data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79992 Yanai Eliyahu changed: What|Removed |Added CC||yanai.eli11 at gmail dot com --- Comment #3 from Yanai Eliyahu --- Andrew: Same results
[Bug middle-end/79992] accessing storage member of lambda via pointer with -no-pie causes the next function to overwrite the pointer's data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79992 --- Comment #5 from Yanai --- but if I still hold the lambda locally, shouldn't it point to inside the lambda's storage? See that I still hold no_pie_2 when accessing the variable that I got from it's lambda object.
[Bug c++/79992] accessing storage member of lambda via pointer with -no-pie causes the next function to overwrite the pointer's data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79992 --- Comment #8 from Yanai --- Even though I don't understand this low level prints of GCC (which I interested in how you got them), can you tell me how in a manner I can understand how that pointer pointed to an automatic storage (I assume)?
[Bug c++/79992] accessing storage member of lambda via pointer with -no-pie causes the next function to overwrite the pointer's data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79992 --- Comment #9 from Yanai --- I don't mean step by step, but in which statement I created that lambda's storage and destroyed it, and between used it?
[Bug tree-optimization/79992] accessing storage member of lambda via pointer with -no-pie causes the next function to overwrite the pointer's data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79992 --- Comment #12 from Yanai --- It took me 5 minutes to guess that it polluted my home folder, but thanks anyway. More semi-on-topic: I have another potential bug (aside 4 others), the bug is that the compiler says there's no ::type in enable_if, when I use two enable_ifs in constructor's parameters. Does it sound like a front-end bug? When I use one enable_if like: enable_if::type it works. (instead of enable_if,enable_if)
[Bug tree-optimization/79992] accessing storage member of lambda via pointer with -no-pie causes the next function to overwrite the pointer's data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79992
--- Comment #14 from Yanai ---
>
> How so? SRA has
>
> > [t1.cc:10:47] [t1.cc:10:47] D.36138.v = [t1.cc:24:29] &[t1.cc:24:20]
> > MEM[(const struct __lambda0 *)[t1.cc:17:42] &D.36138].__i;
> ...
> > [t1.cc:17:42] D.36138 ={v} {CLOBBER};
> ...
> > [t1.cc:32:11] _2 = [t1.cc:32:11] *_39;
>
> so access *_39 after the clobber. And _39 points to D.36138.
>
> Clearly this is an invalid testcase.
>
> static auto get_wrapped_number() {
> return [i = 1] { return &i; };
> }
>
> returns an address to automatic storage.
maybe I am repeating myself, but lambda taking a pointer of one of it's members
should not point to the lambda itself?
it's like doing:
auto lambda;
auto v = &lambda.i;
printf(*v);
printf(*v);
or the by the standard it should copy `i` to stack take pointer?
because at other cases that I take pointer of lambda's member I wrote in the
attachment it actually works. (it doesn't work at one specific case)
[Bug tree-optimization/79992] accessing storage member of lambda via pointer with -no-pie causes the next function to overwrite the pointer's data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79992
--- Comment #15 from Yanai ---
> How so? SRA has
>
> > [t1.cc:10:47] [t1.cc:10:47] D.36138.v = [t1.cc:24:29] &[t1.cc:24:20]
> > MEM[(const struct __lambda0 *)[t1.cc:17:42] &D.36138].__i;
> ...
> > [t1.cc:17:42] D.36138 ={v} {CLOBBER};
> ...
> > [t1.cc:32:11] _2 = [t1.cc:32:11] *_39;
>
> so access *_39 after the clobber. And _39 points to D.36138.
>
> Clearly this is an invalid testcase.
>
> static auto get_wrapped_number() {
> return [i = 1] { return &i; };
> }
>
> returns an address to automatic storage.
I got why the code is not a GCC bug:
`auto v = need_pie_2.get();`, does copy constructor,
and it copies the pointer from the object that is immediately after going to be
destructed.
