[Bug c++/98988] delete is not a constant expression with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98988 --- Comment #4 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:4b47af4346ad0e8a428c0979f6f61feb6579 commit r10-9466-g4b47af4346ad0e8a428c0979f6f61feb6579 Author: Jakub Jelinek Date: Wed Feb 10 19:31:15 2021 +0100 c++: Consider addresses of heap artificial vars always non-NULL [PR98988, PR99031] With -fno-delete-null-pointer-checks which is e.g. implied by -fsanitize=undefined or default on some embedded targets, the middle-end folder doesn't consider addresses of global VAR_DECLs to be non-NULL, as one of them could have address 0. Still, I think malloc/operator new (at least the nonthrowing) relies on NULL returns meaning allocation failure rather than success. Furthermore, the artificial VAR_DECLs we create for constexpr new never actually live in the address space of the program, so we can pretend they will never be NULL too. > I'm surprised that nonzero_address has such a limited set of things it will > actually believe have non-zero addresses with > -fno-delete-null-pointer-checks. But it seems that we should be able to > arrange to satisfy > > > if (definition && !DECL_EXTERNAL (decl) > > since these "variables" are indeed defined within the current translation > unit. Doing that seems to work and as added benefit it fixes another PR that has been filed recently. I need to create the varpool node explicitly and call a method that sets the definition member in there, but I can also unregister those varpool nodes at the end of constexpr processing, as the processing ensured they don't leak outside of the processing. 2021-02-10 Jakub Jelinek PR c++/98988 PR c++/99031 * constexpr.c: Include cgraph.h. (cxx_eval_call_expression): Call varpool_node::finalize_decl on heap artificial vars. (cxx_eval_outermost_constant_expr): Remove varpool nodes for heap artificial vars. * g++.dg/cpp2a/constexpr-new16.C: New test. * g++.dg/cpp2a/constexpr-new17.C: New test. (cherry picked from commit a8db7887dfbf502b7e60d64bfeebd0de592d2d45)
[Bug c++/98988] delete is not a constant expression with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98988 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED CC||jakub at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #3 from Jakub Jelinek --- Fixed.
[Bug c++/98988] delete is not a constant expression with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98988 --- Comment #2 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a8db7887dfbf502b7e60d64bfeebd0de592d2d45 commit r11-7176-ga8db7887dfbf502b7e60d64bfeebd0de592d2d45 Author: Jakub Jelinek Date: Wed Feb 10 19:31:15 2021 +0100 c++: Consider addresses of heap artificial vars always non-NULL [PR98988, PR99031] With -fno-delete-null-pointer-checks which is e.g. implied by -fsanitize=undefined or default on some embedded targets, the middle-end folder doesn't consider addresses of global VAR_DECLs to be non-NULL, as one of them could have address 0. Still, I think malloc/operator new (at least the nonthrowing) relies on NULL returns meaning allocation failure rather than success. Furthermore, the artificial VAR_DECLs we create for constexpr new never actually live in the address space of the program, so we can pretend they will never be NULL too. > I'm surprised that nonzero_address has such a limited set of things it will > actually believe have non-zero addresses with > -fno-delete-null-pointer-checks. But it seems that we should be able to > arrange to satisfy > > > if (definition && !DECL_EXTERNAL (decl) > > since these "variables" are indeed defined within the current translation > unit. Doing that seems to work and as added benefit it fixes another PR that has been filed recently. I need to create the varpool node explicitly and call a method that sets the definition member in there, but I can also unregister those varpool nodes at the end of constexpr processing, as the processing ensured they don't leak outside of the processing. 2021-02-10 Jakub Jelinek PR c++/98988 PR c++/99031 * constexpr.c: Include cgraph.h. (cxx_eval_call_expression): Call varpool_node::finalize_decl on heap artificial vars. (cxx_eval_outermost_constant_expr): Remove varpool nodes for heap artificial vars. * g++.dg/cpp2a/constexpr-new16.C: New test. * g++.dg/cpp2a/constexpr-new17.C: New test.
[Bug c++/98988] delete is not a constant expression with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98988 --- Comment #1 from Jakub Jelinek --- Some sanitizers imply -fno-delete-null-pointer-checks and this testcase fails with fno-delete-null-pointer-checks too - the _magic_var_decl != NULL comparison in that case which is done on delete is not folded into true. Wonder if at least for the magic heap vars we shouldn't fold comparisons against NULL, because those will never live in any memory and thus we can pretend their address will never be 0.
