[Bug c/106939] New: Linker-defined symbols are stained due to 'array subscript is partly outside array bounds' warning

[Bug c/106939] New: Linker-defined symbols are stained due to 'array subscript is partly outside array bounds' warning

[neoxic at icloud dot com]

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

            Bug ID: 106939
           Summary: Linker-defined symbols are stained due to 'array
                    subscript is partly outside array bounds' warning
           Product: gcc
           Version: 12.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: neoxic at icloud dot com
  Target Milestone: ---

Working with embedded applications, one often deals with manipulating memory
regions via symbols defined in a linker script. Please consider the following
snippet:

-----------------------------------------------------
#include <string.h>

extern char _src, _dst; // Defined by the linker

int main(void) {
    memcpy(&_dst, &_src + 1024, 1111);
    return 0;
}
-----------------------------------------------------

Compilation with GCC 12.2.0 yields lots of warnings:

-----------------------------------------------------
$ cc -O2 -Wall -Wextra -fno-strict-aliasing -fwrapv a.c
a.c: In function ‘main’:
a.c:6:29: warning: array subscript 1024 is outside array bounds of ‘char[1]’
[-Warray-bounds]
    6 |         memcpy(&_dst, &_src + 1024, 1111);
      |                       ~~~~~~^~~~~~
a.c:3:13: note: at offset 1024 into object ‘_src’ of size 1
    3 | extern char _src, _dst; // Defined by the linker
      |             ^~~~
a.c:6:9: warning: ‘memcpy’ forming offset [1, 1110] is out of the bounds [0, 1]
of object ‘_dst’ with type ‘char’ [-Warray-bounds]
    6 |         memcpy(&_dst, &_src + 1024, 1111);
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
a.c:3:19: note: ‘_dst’ declared here
    3 | extern char _src, _dst; // Defined by the linker
      |                   ^~~~
-----------------------------------------------------

These symbols are used as mere address anchors, they don't contain anything.
But no matter what I do like changing their type, casting their addresses, etc,
I can't get rid of the pesky sticky warnings now. Is there a clean way to work
around these warning without turning off Warray-bounds?

[Bug c/106939] Linker-defined symbols are stained due to 'array subscript is partly outside array bounds' warning

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |DUPLICATE
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
See bug 77964 comment #6 (and 7) on how to do this correctly.

*** This bug has been marked as a duplicate of bug 77964 ***

[Bug c/106939] Linker-defined symbols are stained due to 'array subscript is partly outside array bounds' warning

[neoxic at icloud dot com]

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

--- Comment #2 from Arseny Vakhrushev <neoxic at icloud dot com> ---
Thanks for the quick reply! I've read the aforementioned comments, but can't
get to see  any similarities. May I ask you to recap what needs to be done in
plain and simple words or direct me to the corresponding manual page?

[Bug c/106939] Linker-defined symbols are stained due to 'array subscript is partly outside array bounds' warning

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|DUPLICATE                   |INVALID

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---

#include <string.h>

extern char _src[], _dst[]; // Defined by the linker

int main(void) {
  char *l_src = src;
  char *l_dst = dst;
  asm ("" : "+r" (l_src));
  asm ("" : "+r" (l_dst));
    memcpy(l_src, l_dst + 1024, 1111);
    return 0;
}

--- CUT ---
Well this works too because you are not comparing the start and ends:
#include <string.h>

extern char _src[], _dst[]; // Defined by the linker

int main(void) {
    memcpy(&_dst[0], &_src[0] + 1024, 1111);
    return 0;
}
----- CUT ---
Basically this is a C question really as _src/_dst is only size of 1 in the
original code you provided while in the above two cases it is an unknown size.

[Bug c/106939] Linker-defined symbols are stained due to 'array subscript is partly outside array bounds' warning

[neoxic at icloud dot com]

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

--- Comment #4 from Arseny Vakhrushev <neoxic at icloud dot com> ---
Thanks a lot, Andrew! Totally my bad. Well, comparison seems to work too:

extern char _src[], _dst[], _end[]; // Defined by the linker
int main(void) {
    char *src = &_src[0];
    char *dst = &_dst[0];
    char *end = &_end[0];
    while (src < end) *dst++ = *src++;
    return 0;
}

Are the asm("" : "+r" (p)) statements strictly needed?

[Bug c/106939] Linker-defined symbols are stained due to 'array subscript is partly outside array bounds' warning

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Arseny Vakhrushev from comment #4)
> Thanks a lot, Andrew! Totally my bad. Well, comparison seems to work too:
> 
> extern char _src[], _dst[], _end[]; // Defined by the linker
> int main(void) {
>     char *src = &_src[0];
>     char *dst = &_dst[0];
>     char *end = &_end[0];
>     while (src < end) *dst++ = *src++;
>     return 0;
> }
> 
> Are the asm("" : "+r" (p)) statements strictly needed?

The inline-asm is needed because in C it is undefined to compare pointers that
are from different arrays. Basically it is a way to hide it from the compiler.

[Bug c/106939] Linker-defined symbols are stained due to 'array subscript is partly outside array bounds' warning

[neoxic at icloud dot com]

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

--- Comment #6 from Arseny Vakhrushev <neoxic at icloud dot com> ---
Lots of thanks again, Andrew!

----------------------------------------------
#include <string.h>
#include <stdint.h>

extern char _dst[], _src[], _end[];

int main(void) {

        memcpy(_dst, _src, _end - _src);

        uint32_t *dst = (uint32_t *)_dst;
        uint32_t *src = (uint32_t *)_src;
        uint32_t *end = (uint32_t *)_end;
        while (src < end) *dst++ = *src++;

        return 0;
}
-----------------------------------------------

Well, I hope I'm not doing anything terribly wrong, but the above works very
nice for me, looks clean, involves pointer arithmetics and doesn't produce any
warnings. I also can't really understand how it is possible for pointer
comparison to be undefined. If you could point me to the corresponding C
standard section, I would really appreciate that! Thanks a lot again!

[Bug c/106939] Linker-defined symbols are stained due to 'array subscript is partly outside array bounds' warning

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
In C99, it is in 6.5.8/5 (Relational operators).

[Bug c/106939] Linker-defined symbols are stained due to 'array subscript is partly outside array bounds' warning

[neoxic at icloud dot com]

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

--- Comment #8 from Arseny Vakhrushev <neoxic at icloud dot com> ---
Thank you, Jakub! I have read that section and can see that the Standard is
just very cautious about the cases it doesn't cover labeling them as "undefined
behaviour". The most likely reason is memory segmentation. Comparing two
pointers that point to different objects located in different memory segments
make no sense. But taking into account that the times of segmented memory are
long gone for the average C programmer, it is save to assume that no additional
action is needed to fool the compiler.