[Bug c++/114441] New: Relocation issues when compiling with -O1,-O2,and -Os

[Bug c++/114441] New: Relocation issues when compiling with -O1,-O2,and -Os

[njuwy at smail dot nju.edu.cn]

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

            Bug ID: 114441
           Summary: Relocation issues when compiling with -O1,-O2,and -Os
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: njuwy at smail dot nju.edu.cn
  Target Milestone: ---

The source file is:
root@ubuntu:~/test/111# cat 222.cpp
#include <stdio.h>
int a[1][1][1][1][1];
short b[6268435456];
void c() {
  for (size_t d;;)
    for (size_t e;;)
      for (size_t f;;)
        for (size_t g;;)
          for (size_t i = 0; i < 16; ++i)
            a[d][e][f][g][i] = 2;
}
main() {}

The version of g++:
root@ubuntu:~/test/111# /root/software/IP-gcc/gcc-trunk/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/root/software/IP-gcc/gcc-trunk/bin/g++
COLLECT_LTO_WRAPPER=/root/software/IP-gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/root/software/IP-gcc/gcc-trunk
--enable-languages=c,c++ --disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.1 20240318 (experimental) (GCC)


The issue I had when compiling at different optimization level.At the -O0 and
-O3 optimization level, the compilation proceeded without any errors, but any
attempt to compile with other three optimization levels (-01, -O2 and -Os)
resulted in  relocation-related errors, which is also present in exsiting
releases:
root@ubuntu:~/test/111# /root/software/IP-gcc/gcc-trunk/bin/g++ 222.cpp -o test
-w -O0
root@ubuntu:~/test/111# /root/software/IP-gcc/gcc-trunk/bin/g++ 222.cpp -o test
-w -O3
root@ubuntu:~/test/111# /root/software/IP-gcc/gcc-trunk/bin/g++ 222.cpp -o test
-w -O1
/tmp/ccizb4WS.o: In function `c()':
222.cpp:(.text+0xd): relocation truncated to fit: R_X86_64_32S against symbol
`a' defined in .bss section in /tmp/ccizb4WS.o
collect2: error: ld returned 1 exit status
root@ubuntu:~/test/111# /root/software/IP-gcc/gcc-trunk/bin/g++ 222.cpp -o test
-w -O2
/tmp/cchi03vq.o: In function `c()':
222.cpp:(.text+0x13): relocation truncated to fit: R_X86_64_32S against symbol
`a' defined in .bss section in /tmp/cchi03vq.o
collect2: error: ld returned 1 exit status
root@ubuntu:~/test/111# /root/software/IP-gcc/gcc-trunk/bin/g++ 222.cpp -o test
-w -Os
/tmp/ccHbxau8.o: In function `c()':
222.cpp:(.text+0x7): relocation truncated to fit: R_X86_64_32S against symbol
`a' defined in .bss section in /tmp/ccHbxau8.o
collect2: error: ld returned 1 exit status

[Bug target/114441] Relocation issues when compiling with -O1,-O2,and -Os

[pinskia at gcc dot gnu.org]

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

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

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This is not a GCC bug, 

You need to use -mcmodel=large if you have huge statically allocated arrays.

The default -mcmodel=medium does not support more than 2GB size arrays

See

https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/x86-Options.html#index-mcmodel_003dlarge-3

[Bug target/114441] Relocation issues when compiling with -O1,-O2,and -Os

[sjames at gcc dot gnu.org]

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

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

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

--- Comment #2 from Sam James <sjames at gcc dot gnu.org> ---
It might be worth filing an ld bug for a better error message.

[Bug target/114441] Relocation issues when compiling with -O1,-O2,and -Os

[njuwy at smail dot nju.edu.cn]

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

--- Comment #3 from Yang Wang <njuwy at smail dot nju.edu.cn> ---
(In reply to Andrew Pinski from comment #1)
> This is not a GCC bug, 
> 
> You need to use -mcmodel=large if you have huge statically allocated arrays.
> 
> The default -mcmodel=medium does not support more than 2GB size arrays
> 
> See
>  https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/x86-Options.html#index-
> mcmodel_003dlarge-3

Thanks for your reply! Indeed, the compilation was successful when either the
-mcmodel=medium or -mcmodel=large was enabled. However, I'm still curious why
it can be compiled successfully at the -O3 optimization level when the default
-mcmodel=small is enabled? As far as I know, the -O3 optimization level is the
highest.


root@ubuntu:~/test/111# /root/software/IP-gcc/gcc-trunk/bin/g++ 222.cpp -o test
-w -mcmodel=medium -O0

root@ubuntu:~/test/111# /root/software/IP-gcc/gcc-trunk/bin/g++ 222.cpp -o test
-w -mcmodel=medium -O3

root@ubuntu:~/test/111# /root/software/IP-gcc/gcc-trunk/bin/g++ 222.cpp -o test
-w -mcmodel=medium -O1

root@ubuntu:~/test/111# /root/software/IP-gcc/gcc-trunk/bin/g++ 222.cpp -o test
-w -mcmodel=medium -O2

root@ubuntu:~/test/111# /root/software/IP-gcc/gcc-trunk/bin/g++ 222.cpp -o test
-w -mcmodel=medium -Os

root@ubuntu:~/test/111# /root/software/IP-gcc/gcc-trunk/bin/g++ 222.cpp -o test
-w -mcmodel=small -O0

root@ubuntu:~/test/111# /root/software/IP-gcc/gcc-trunk/bin/g++ 222.cpp -o test
-w -mcmodel=small -O3

root@ubuntu:~/test/111# /root/software/IP-gcc/gcc-trunk/bin/g++ 222.cpp -o test
-w -mcmodel=small -O1
/tmp/ccdtPXUH.o: In function `c()':
222.cpp:(.text+0xd): relocation truncated to fit: R_X86_64_32S against symbol
`a' defined in .bss section in /tmp/ccdtPXUH.o
collect2: error: ld returned 1 exit status

root@ubuntu:~/test/111# /root/software/IP-gcc/gcc-trunk/bin/g++ 222.cpp -o test
-w -mcmodel=small -O2
/tmp/ccbjzODN.o: In function `c()':
222.cpp:(.text+0x13): relocation truncated to fit: R_X86_64_32S against symbol
`a' defined in .bss section in /tmp/ccbjzODN.o
collect2: error: ld returned 1 exit status

root@ubuntu:~/test/111# /root/software/IP-gcc/gcc-trunk/bin/g++ 222.cpp -o test
-w -mcmodel=small -Os
/tmp/ccUUdbLp.o: In function `c()':
222.cpp:(.text+0x7): relocation truncated to fit: R_X86_64_32S against symbol
`a' defined in .bss section in /tmp/ccUUdbLp.o
collect2: error: ld returned 1 exit status

[Bug target/114441] Relocation issues when compiling with -O1,-O2,and -Os

[xry111 at gcc dot gnu.org]

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

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

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

--- Comment #4 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to Yang Wang from comment #3)
> (In reply to Andrew Pinski from comment #1)
> > This is not a GCC bug, 
> > 
> > You need to use -mcmodel=large if you have huge statically allocated arrays.
> > 
> > The default -mcmodel=medium does not support more than 2GB size arrays
> > 
> > See
> >  https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/x86-Options.html#index-
> > mcmodel_003dlarge-3
> 
> Thanks for your reply! Indeed, the compilation was successful when either
> the -mcmodel=medium or -mcmodel=large was enabled. However, I'm still
> curious why it can be compiled successfully at the -O3 optimization level
> when the default -mcmodel=small is enabled? As far as I know, the -O3
> optimization level is the highest.

Because the entire `c` function is optimized to empty.  Note that `c` always
invokes undefined behavior:

t.cc: In function 'void c()':
t.cc:10:30: warning: iteration 1 invokes undefined behavior
[-Waggressive-loop-optimizations]
   10 |             a[d][e][f][g][i] = 2;
      |             ~~~~~~~~~~~~~~~~~^~~
t.cc:9:32: note: within this loop
    9 |           for (size_t i = 0; i < 16; ++i)
      |                              ~~^~~~

So the compiler is allowed to optimize it into nothing.

A test case without undefined behavior:

#include <stdio.h>
int a[1][1][1][1][1];
short b[6268435456];
void c() {
  a[0][0][0][0][0] = 114514;
}
int main() {}

fails at -O3 too.

Also note that -O levels are for optimizing the *valid* programs, not for
debugging the compiler.  It's wrong to report bugs solely because of "different
behaviors with different -O levels" (without analysing the validity of the test
case).

[Bug target/114441] Relocation issues when compiling with -O1,-O2,and -Os

[njuwy at smail dot nju.edu.cn]

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

--- Comment #5 from Yang Wang <njuwy at smail dot nju.edu.cn> ---
(In reply to Xi Ruoyao from comment #4)
> (In reply to Yang Wang from comment #3)
> > (In reply to Andrew Pinski from comment #1)
> > > This is not a GCC bug, 
> > > 
> > > You need to use -mcmodel=large if you have huge statically allocated arrays.
> > > 
> > > The default -mcmodel=medium does not support more than 2GB size arrays
> > > 
> > > See
> > >  https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/x86-Options.html#index-
> > > mcmodel_003dlarge-3
> > 
> > Thanks for your reply! Indeed, the compilation was successful when either
> > the -mcmodel=medium or -mcmodel=large was enabled. However, I'm still
> > curious why it can be compiled successfully at the -O3 optimization level
> > when the default -mcmodel=small is enabled? As far as I know, the -O3
> > optimization level is the highest.
> 
> Because the entire `c` function is optimized to empty.  Note that `c` always
> invokes undefined behavior:
> 
> t.cc: In function 'void c()':
> t.cc:10:30: warning: iteration 1 invokes undefined behavior
> [-Waggressive-loop-optimizations]
>    10 |             a[d][e][f][g][i] = 2;
>       |             ~~~~~~~~~~~~~~~~~^~~
> t.cc:9:32: note: within this loop
>     9 |           for (size_t i = 0; i < 16; ++i)
>       |                              ~~^~~~
> 
> So the compiler is allowed to optimize it into nothing.
> 
> A test case without undefined behavior:
> 
> #include <stdio.h>
> int a[1][1][1][1][1];
> short b[6268435456];
> void c() {
>   a[0][0][0][0][0] = 114514;
> }
> int main() {}
> 
> fails at -O3 too.
> 
> Also note that -O levels are for optimizing the *valid* programs, not for
> debugging the compiler.  It's wrong to report bugs solely because of
> "different behaviors with different -O levels" (without analysing the
> validity of the test case).

Thanks for your reply!I'll pay more attention.