[Bug c/85800] A miscompilation bug with unsigned char

[Bug c/85800] A miscompilation bug with unsigned char

[sjames at gcc dot gnu.org]

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

Sam James <sjames at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code

--- Comment #4 from Sam James <sjames at gcc dot gnu.org> ---
Adding "wrong-code" given that's the claim. If the bug is invalid, we can
always close it as such.

[Bug c/85800] A miscompilation bug with unsigned char

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
To me the testcase looks invalid.
int B[4], A[4];
...
store_10_to_p(A, &B[4]);
...
memcpy((unsigned char*)arr2, (unsigned char *)&q, sizeof(q));

Constructing &B[4] is valid, it is a pointer to one past the last element of
the array object.  But C99 6.5.6/8
"If the result points one past the last element of the array object, it
shall not be used as the operand of a unary * operator that is evaluated."
then triggers during the memcpy when the pointer is dereferenced.
Doesn't matter that the A array starts at the same address, you'd need to use A
or &A[0] etc. instead of &B[4] to make it valid.

[Bug c/85800] A miscompilation bug with unsigned char

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

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

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Yeah.  I think we have enough duplicates that show cases where conditional
equivalence propagation introduces these issues.  Here it's already present in
the source.