[Bug c++/95221] g++.dg/ubsan/vptr-12.C fails with -fstrong-eval-order=all

2020-06-01 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95221 --- Comment #9 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:172f2c42a10fd470c93f1e84575de9766c157591 commit r11-775-g172f2c42a10fd470c93f1e84575de9766c157591 Author: Jason Merrill Date:

[Bug c++/95221] g++.dg/ubsan/vptr-12.C fails with -fstrong-eval-order=all

2020-05-29 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95221 --- Comment #8 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:8e915901deb3518d4bef73ea52eab2ece7a2bbf6 commit r11-728-g8e915901deb3518d4bef73ea52eab2ece7a2bbf6 Author: Jason Merrill Date:

[Bug c++/95221] g++.dg/ubsan/vptr-12.C fails with -fstrong-eval-order=all

2020-05-22 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95221 Jason Merrill changed: What|Removed |Added Target Milestone|--- |11.0 Status|ASSIGNED

[Bug c++/95221] g++.dg/ubsan/vptr-12.C fails with -fstrong-eval-order=all

2020-05-21 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95221 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org

[Bug c++/95221] g++.dg/ubsan/vptr-12.C fails with -fstrong-eval-order=all

2020-05-19 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95221 Jason Merrill changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed|

[Bug c++/95221] g++.dg/ubsan/vptr-12.C fails with -fstrong-eval-order=all

2020-05-19 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95221 --- Comment #5 from Marek Polacek --- You're not wrong, but here we're dealing with the undefined behavior sanitizer whose point is to detect broken code like the above.

[Bug c++/95221] g++.dg/ubsan/vptr-12.C fails with -fstrong-eval-order=all

2020-05-19 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95221 --- Comment #4 from Andrew Pinski --- Is this code even defined? We call a method after calling the deconstructor on the object? If we do: c->~MyClass (); new(c) MyClass(); c->Doit (); Then it is defined. Or am I wrong about that?

[Bug c++/95221] g++.dg/ubsan/vptr-12.C fails with -fstrong-eval-order=all

2020-05-19 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95221 --- Comment #3 from Marek Polacek --- And for completeness, the asm for the -fstrong-eval-order=all case: movq%rbx, %rdi call*%r12 movq-24(%rbp), %rax movq(%rax), %rax addq$16, %rax

[Bug c++/95221] g++.dg/ubsan/vptr-12.C fails with -fstrong-eval-order=all

2020-05-19 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95221 --- Comment #2 from Marek Polacek --- I think the thing is that we have a CALL_EXPR, something like OBJ_TYPE_REF (...) (.UBSAN_VPTR ()) and now we first evaluate the OBJ_TYPE_REF. In this case this is what seems to happen here: 1) we

[Bug c++/95221] g++.dg/ubsan/vptr-12.C fails with -fstrong-eval-order=all

2020-05-19 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95221 --- Comment #1 from Marek Polacek --- It is caused by this code: 853 if (flag_strong_eval_order == 2 854 && CALL_EXPR_FN (*expr_p) 855 && cp_get_callee_fndecl_nofold (*expr_p) == NULL_TREE) 856 { 857