[Bug c/112748] New: memmove(ptr, ptr, n) call optimized out even at -O0 with -fsanitize=undefined

[Bug c/112748] New: memmove(ptr, ptr, n) call optimized out even at -O0 with -fsanitize=undefined

[tavianator at gmail dot com]

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

[Bug middle-end/112748] memmove(ptr, ptr, n) call optimized out even at -O0 with -fsanitize=undefined

[pinskia at gcc dot gnu.org]

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?

[Bug middle-end/112748] memmove(ptr, ptr, n) call optimized out even at -O0 with -fsanitize=undefined

[tavianator at gmail dot com]

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.

[Bug sanitizer/112748] memmove(ptr, ptr, n) call optimized out even at -O0 with -fsanitize=undefined

[rguenth at gcc dot gnu.org]

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.

[Bug sanitizer/112748] memmove(ptr, ptr, n) call optimized out even at -O0 with -fsanitize=undefined

[jakub at gcc dot gnu.org]

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?