public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/98988] New: delete is not a constant expression with -fsanitize=undefined
@ 2021-02-07 22:13 david at doublewise dot net
2021-02-08 15:29 ` [Bug c++/98988] " jakub at gcc dot gnu.org
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: david at doublewise dot net @ 2021-02-07 22:13 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98988
Bug ID: 98988
Summary: delete is not a constant expression with
-fsanitize=undefined
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: david at doublewise dot net
Target Milestone: ---
The following valid translation unit:
```
constexpr bool f() {
auto ptr = new int();
delete ptr;
return true;
}
static_assert(f());
```
is incorrectly rejected when compiled with `-fsanitize=undefined`, complaining
about
```
<source>:7:16: error: non-constant condition for static assertion
7 | static_assert(f());
| ~^~
<source>:7:16: in 'constexpr' expansion of 'f()'
<source>:3:9: error: '(((int*)(& heap )) != 0)' is not a constant expression
3 | delete ptr;
| ^~~~~~~~~~
Compiler returned: 1
```
See it live: https://godbolt.org/z/Yf67G7
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug c++/98988] delete is not a constant expression with -fsanitize=undefined
2021-02-07 22:13 [Bug c++/98988] New: delete is not a constant expression with -fsanitize=undefined david at doublewise dot net
@ 2021-02-08 15:29 ` jakub at gcc dot gnu.org
2021-02-10 18:32 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-02-08 15:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98988
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Some sanitizers imply -fno-delete-null-pointer-checks and this testcase fails
with fno-delete-null-pointer-checks too - the &heap_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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug c++/98988] delete is not a constant expression with -fsanitize=undefined
2021-02-07 22:13 [Bug c++/98988] New: delete is not a constant expression with -fsanitize=undefined david at doublewise dot net
2021-02-08 15:29 ` [Bug c++/98988] " jakub at gcc dot gnu.org
@ 2021-02-10 18:32 ` cvs-commit at gcc dot gnu.org
2021-02-10 18:48 ` jakub at gcc dot gnu.org
2021-03-19 23:28 ` cvs-commit at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-02-10 18:32 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98988
--- Comment #2 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:a8db7887dfbf502b7e60d64bfeebd0de592d2d45
commit r11-7176-ga8db7887dfbf502b7e60d64bfeebd0de592d2d45
Author: Jakub Jelinek <jakub@redhat.com>
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 <jakub@redhat.com>
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug c++/98988] delete is not a constant expression with -fsanitize=undefined
2021-02-07 22:13 [Bug c++/98988] New: delete is not a constant expression with -fsanitize=undefined david at doublewise dot net
2021-02-08 15:29 ` [Bug c++/98988] " jakub at gcc dot gnu.org
2021-02-10 18:32 ` cvs-commit at gcc dot gnu.org
@ 2021-02-10 18:48 ` jakub at gcc dot gnu.org
2021-03-19 23:28 ` cvs-commit at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-02-10 18:48 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98988
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
CC| |jakub at gcc dot gnu.org
Status|UNCONFIRMED |RESOLVED
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug c++/98988] delete is not a constant expression with -fsanitize=undefined
2021-02-07 22:13 [Bug c++/98988] New: delete is not a constant expression with -fsanitize=undefined david at doublewise dot net
` (2 preceding siblings ...)
2021-02-10 18:48 ` jakub at gcc dot gnu.org
@ 2021-03-19 23:28 ` cvs-commit at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-03-19 23:28 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98988
--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:4b47af4346ad0e8a428c09791111f6f61feb6579
commit r10-9466-g4b47af4346ad0e8a428c09791111f6f61feb6579
Author: Jakub Jelinek <jakub@redhat.com>
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 <jakub@redhat.com>
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)
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-03-19 23:28 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-07 22:13 [Bug c++/98988] New: delete is not a constant expression with -fsanitize=undefined david at doublewise dot net
2021-02-08 15:29 ` [Bug c++/98988] " jakub at gcc dot gnu.org
2021-02-10 18:32 ` cvs-commit at gcc dot gnu.org
2021-02-10 18:48 ` jakub at gcc dot gnu.org
2021-03-19 23:28 ` cvs-commit at gcc dot gnu.org
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).