[Bug sanitizer/109308] New: False positive store to address 0x62600000016c with insufficient space for an object of type 'int' since r12-6030-g422f9eb7011b76c1

[Bug sanitizer/109308] New: False positive store to address 0x62600000016c with insufficient space for an object of type 'int' since r12-6030-g422f9eb7011b76c1

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109308

            Bug ID: 109308
           Summary: False positive store to address 0x62600000016c with
                    insufficient space for an object of type 'int' since
                    r12-6030-g422f9eb7011b76c1
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: sanitizer
          Assignee: unassigned at gcc dot gnu.org
          Reporter: marxin at gcc dot gnu.org
                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, siddhesh at gcc dot gnu.org
  Target Milestone: ---

It's something I reduced from:
https://sourceware.org/bugzilla/show_bug.cgi?id=30279

$ cat y.i
struct m68hc11_opcode_def
{
  long format;
};

int main()
{
  int num_opcodes = 1;
  struct m68hc11_opcode_def *opc;

  opc = (struct m68hc11_opcode_def *) __builtin_malloc (sizeof (struct
m68hc11_opcode_def) * num_opcodes);
  __builtin_printf ("opc=%p\n", opc);
  --opc;

  for (int i = 0; i < num_opcodes; i++)
  {
      opc++;
      opc->format = 0;
  }

  return 0;
}

$ gcc -g y.i -fsanitize=undefined -O2 && ./a.out
opc=0x4172b0
y.i:18:19: runtime error: store to address 0x0000004172b0 with insufficient
space for an object of type 'long int'
0x0000004172b0: note: pointer points here
 00 00 00 00  ba ba ba ba ba ba ba ba  00 00 00 00 00 00 00 00  00 00 00 00 00
00 00 00  11 04 00 00
              ^ 
    #0 0x4010e3 in main /home/marxin/Programming/binutils/objdir/gas/y.i:18
    #1 0x7ffff762cbaf in __libc_start_call_main (/lib64/libc.so.6+0x27baf)
(BuildId: a3b5459af6c888d99845457c6f4d0c3b06f2404b)
    #2 0x7ffff762cc78 in __libc_start_main_alias_1 (/lib64/libc.so.6+0x27c78)
(BuildId: a3b5459af6c888d99845457c6f4d0c3b06f2404b)
    #3 0x401134 in _start ../sysdeps/x86_64/start.S:115

[Bug sanitizer/109308] False positive store to address 0x62600000016c with insufficient space for an object of type 'int' since r12-6030-g422f9eb7011b76c1

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109308

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://sourceware.org/bugz
                   |                            |illa/show_bug.cgi?id=30279
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2023-03-28

[Bug sanitizer/109308] False positive store to address 0x62600000016c with insufficient space for an object of type 'int' since r12-6030-g422f9eb7011b76c1

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109308

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Doing:
--opc;

On an address which starts an array is undefined. Even for an a memory
allocated by malloc.

[Bug sanitizer/109308] False positive store to address 0x62600000016c with insufficient space for an object of type 'int' since r12-6030-g422f9eb7011b76c1

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109308

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
Thus invalid.

[Bug sanitizer/109308] False positive store to address 0x62600000016c with insufficient space for an object of type 'int' since r12-6030-g422f9eb7011b76c1

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109308

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This code is very much undefined.
THe original code did:
  opc = XNEWVEC (struct m68hc11_opcode_def, num_opcodes);
  m68hc11_opcode_defs = opc--;

Which is definitely undefined. You cannot take the address before the allocated
memory and have it be defined. The only address which is valid is where the
array starts and one element past the allocation.

[Bug sanitizer/109308] False positive store to address 0x62600000016c with insufficient space for an object of type 'int' since r12-6030-g422f9eb7011b76c1

[amodra at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109308

Alan Modra <amodra at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amodra at gmail dot com

--- Comment #4 from Alan Modra <amodra at gmail dot com> ---
I agree the code is undefined, but "store to address 0x0000004172b0 with
insufficient space for an object of type 'long int'" is a lie.  There plainly
*is* sufficient space at that address.

It would be nice to diagnose the actual undefined behaviour.  As a compiler
developer you might have the mindset of "it's undefined code so the compiler
can do anything", but that argument strikes me as disingenuous when we are
talking about -fsanitize=undefined!

[Bug sanitizer/109308] False positive store to address 0x62600000016c with insufficient space for an object of type 'int' since r12-6030-g422f9eb7011b76c1

[siddhesh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109308

--- Comment #5 from Siddhesh Poyarekar <siddhesh at gcc dot gnu.org> ---
This kinda has happened before:

https://github.com/Perl/perl5/issues/20678

Should we keep this bug open for the message, which is obviously wrong?