public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/112748] New: memmove(ptr, ptr, n) call optimized out even at -O0 with -fsanitize=undefined
@ 2023-11-28 18:02 tavianator at gmail dot com
2023-11-28 18:08 ` [Bug middle-end/112748] " pinskia at gcc dot gnu.org
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: tavianator at gmail dot com @ 2023-11-28 18:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112748
Bug ID: 112748
Summary: memmove(ptr, ptr, n) call optimized out even at -O0
with -fsanitize=undefined
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tavianator at gmail dot com
Target Milestone: ---
This is counter-productive, as I wrote the memmove() specifically to get the
sanitizers to check that ptr really points to a big enough allocation.
$ cat foo.c
typedef __SIZE_TYPE__ size_t;
void *memmove(void *dest, void *src, size_t n);
void foo(void *ptr, size_t n) {
memmove(ptr, ptr, n);
}
$ gcc -O0 -fsanitize=undefined -S foo.c
$ cat foo.s
.file "foo.c"
.text
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq %rsp, %rbp
.cfi_def_cfa_register 6
movq %rdi, -8(%rbp)
movq %rsi, -16(%rbp)
nop
popq %rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.size foo, .-foo
.ident "GCC: (GNU) 13.2.1 20230801"
.section .note.GNU-stack,"",@progbits
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug middle-end/112748] memmove(ptr, ptr, n) call optimized out even at -O0 with -fsanitize=undefined
2023-11-28 18:02 [Bug c/112748] New: memmove(ptr, ptr, n) call optimized out even at -O0 with -fsanitize=undefined tavianator at gmail dot com
@ 2023-11-28 18:08 ` pinskia at gcc dot gnu.org
2023-11-28 18:21 ` tavianator at gmail dot com
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-11-28 18:08 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112748
--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Does -fsanitize=address remove it?
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug middle-end/112748] memmove(ptr, ptr, n) call optimized out even at -O0 with -fsanitize=undefined
2023-11-28 18:02 [Bug c/112748] New: memmove(ptr, ptr, n) call optimized out even at -O0 with -fsanitize=undefined tavianator at gmail dot com
2023-11-28 18:08 ` [Bug middle-end/112748] " pinskia at gcc dot gnu.org
@ 2023-11-28 18:21 ` tavianator at gmail dot com
2023-11-29 6:53 ` [Bug sanitizer/112748] " rguenth at gcc dot gnu.org
2023-11-30 19:31 ` jakub at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: tavianator at gmail dot com @ 2023-11-28 18:21 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112748
--- Comment #2 from Tavian Barnes <tavianator at gmail dot com> ---
(In reply to Andrew Pinski from comment #1)
> Does -fsanitize=address remove it?
Yes, it's still removed with -fsanitize=address.
While ASAN is necessary to check that the memory is really allocated, UBSAN
should at least check that ptr is not NULL. So it shouldn't be removed in
either case.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug sanitizer/112748] memmove(ptr, ptr, n) call optimized out even at -O0 with -fsanitize=undefined
2023-11-28 18:02 [Bug c/112748] New: memmove(ptr, ptr, n) call optimized out even at -O0 with -fsanitize=undefined tavianator at gmail dot com
2023-11-28 18:08 ` [Bug middle-end/112748] " pinskia at gcc dot gnu.org
2023-11-28 18:21 ` tavianator at gmail dot com
@ 2023-11-29 6:53 ` rguenth at gcc dot gnu.org
2023-11-30 19:31 ` jakub at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-11-29 6:53 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112748
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Keywords| |documentation
CC| |dodji at gcc dot gnu.org,
| |dvyukov at gcc dot gnu.org,
| |jakub at gcc dot gnu.org,
| |kcc at gcc dot gnu.org,
| |marxin at gcc dot gnu.org
Ever confirmed|0 |1
Component|middle-end |sanitizer
Last reconfirmed| |2023-11-29
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed. We fold all calls early after gimplification and folding is known
to also affect -O0. This behavior is independent of sanitizing which happens
partly before and partly only after this folding takes place.
We also simplify 1 + 1 or x + 0 with -O0 or turn printf("%s", "Hello")
into puts("Hello") for example.
Documenting this behavior might be good. Gating some of the simplifications
on optimization might be also reasonable.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug sanitizer/112748] memmove(ptr, ptr, n) call optimized out even at -O0 with -fsanitize=undefined
2023-11-28 18:02 [Bug c/112748] New: memmove(ptr, ptr, n) call optimized out even at -O0 with -fsanitize=undefined tavianator at gmail dot com
` (2 preceding siblings ...)
2023-11-29 6:53 ` [Bug sanitizer/112748] " rguenth at gcc dot gnu.org
@ 2023-11-30 19:31 ` jakub at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-11-30 19:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112748
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So, do we want something like
--- gcc/gimple-fold.cc.jj 2023-11-02 12:15:12.205998817 +0100
+++ gcc/gimple-fold.cc 2023-11-30 20:24:01.092095623 +0100
@@ -5083,12 +5083,16 @@ gimple_fold_builtin (gimple_stmt_iterato
return gimple_fold_builtin_bzero (gsi);
case BUILT_IN_MEMSET:
+ if (!optimize)
+ return false;
return gimple_fold_builtin_memset (gsi,
gimple_call_arg (stmt, 1),
gimple_call_arg (stmt, 2));
case BUILT_IN_MEMCPY:
case BUILT_IN_MEMPCPY:
case BUILT_IN_MEMMOVE:
+ if (!optimize)
+ return false;
return gimple_fold_builtin_memory_op (gsi, gimple_call_arg (stmt, 0),
gimple_call_arg (stmt, 1), fcode);
case BUILT_IN_SPRINTF_CHK:
(and repeat for many other builtins)?
I'm afraid we can't do if (!optimize) return false; for all builtins in
gimple_fold_builtin, because some builtins by design must be always folded and
never expand. E.g. __builtin_clear_padding,
__builtin_{clz,ctz,clrsb,ffs,popcount,parity}g,
__builtin_{add,sub,mul}_overflow{,_p} and many others.
expand_builtin has
/* When not optimizing, generate calls to library functions for a certain
set of builtins. */
if (!optimize
&& !called_as_built_in (fndecl)
&& fcode != BUILT_IN_FORK
&& fcode != BUILT_IN_EXECL
&& fcode != BUILT_IN_EXECV
&& fcode != BUILT_IN_EXECLP
&& fcode != BUILT_IN_EXECLE
&& fcode != BUILT_IN_EXECVP
&& fcode != BUILT_IN_EXECVE
&& fcode != BUILT_IN_CLEAR_CACHE
&& !ALLOCA_FUNCTION_CODE_P (fcode)
&& fcode != BUILT_IN_FREE
&& (fcode != BUILT_IN_MEMSET
|| !(flag_inline_stringops & ILSOP_MEMSET))
&& (fcode != BUILT_IN_MEMCPY
|| !(flag_inline_stringops & ILSOP_MEMCPY))
&& (fcode != BUILT_IN_MEMMOVE
|| !(flag_inline_stringops & ILSOP_MEMMOVE))
&& (fcode != BUILT_IN_MEMCMP
|| !(flag_inline_stringops & ILSOP_MEMCMP)))
return expand_call (exp, target, ignore);
Perhaps just a general
if (!optimize && !called_as_built_in (fndecl))
return false;
at the start of gimple_fold_builtin? Or do we want to let some exceptions?
Do we also apply GIMPLE match.pd simplification at -O0?
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-11-30 19:31 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-11-28 18:02 [Bug c/112748] New: memmove(ptr, ptr, n) call optimized out even at -O0 with -fsanitize=undefined tavianator at gmail dot com
2023-11-28 18:08 ` [Bug middle-end/112748] " pinskia at gcc dot gnu.org
2023-11-28 18:21 ` tavianator at gmail dot com
2023-11-29 6:53 ` [Bug sanitizer/112748] " rguenth at gcc dot gnu.org
2023-11-30 19:31 ` jakub 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).