public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/114441] New: Relocation issues when compiling with -O1,-O2,and -Os
@ 2024-03-23 12:04 njuwy at smail dot nju.edu.cn
2024-03-23 17:06 ` [Bug target/114441] " pinskia at gcc dot gnu.org
` (4 more replies)
0 siblings, 5 replies; 6+ messages in thread
From: njuwy at smail dot nju.edu.cn @ 2024-03-23 12:04 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug target/114441] Relocation issues when compiling with -O1,-O2,and -Os
2024-03-23 12:04 [Bug c++/114441] New: Relocation issues when compiling with -O1,-O2,and -Os njuwy at smail dot nju.edu.cn
@ 2024-03-23 17:06 ` pinskia at gcc dot gnu.org
2024-03-23 17:07 ` sjames at gcc dot gnu.org
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-03-23 17:06 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug target/114441] Relocation issues when compiling with -O1,-O2,and -Os
2024-03-23 12:04 [Bug c++/114441] New: Relocation issues when compiling with -O1,-O2,and -Os njuwy at smail dot nju.edu.cn
2024-03-23 17:06 ` [Bug target/114441] " pinskia at gcc dot gnu.org
@ 2024-03-23 17:07 ` sjames at gcc dot gnu.org
2024-03-24 5:22 ` njuwy at smail dot nju.edu.cn
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: sjames at gcc dot gnu.org @ 2024-03-23 17:07 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug target/114441] Relocation issues when compiling with -O1,-O2,and -Os
2024-03-23 12:04 [Bug c++/114441] New: Relocation issues when compiling with -O1,-O2,and -Os njuwy at smail dot nju.edu.cn
2024-03-23 17:06 ` [Bug target/114441] " pinskia at gcc dot gnu.org
2024-03-23 17:07 ` sjames at gcc dot gnu.org
@ 2024-03-24 5:22 ` njuwy at smail dot nju.edu.cn
2024-03-24 11:38 ` xry111 at gcc dot gnu.org
2024-03-25 12:07 ` njuwy at smail dot nju.edu.cn
4 siblings, 0 replies; 6+ messages in thread
From: njuwy at smail dot nju.edu.cn @ 2024-03-24 5:22 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug target/114441] Relocation issues when compiling with -O1,-O2,and -Os
2024-03-23 12:04 [Bug c++/114441] New: Relocation issues when compiling with -O1,-O2,and -Os njuwy at smail dot nju.edu.cn
` (2 preceding siblings ...)
2024-03-24 5:22 ` njuwy at smail dot nju.edu.cn
@ 2024-03-24 11:38 ` xry111 at gcc dot gnu.org
2024-03-25 12:07 ` njuwy at smail dot nju.edu.cn
4 siblings, 0 replies; 6+ messages in thread
From: xry111 at gcc dot gnu.org @ 2024-03-24 11:38 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug target/114441] Relocation issues when compiling with -O1,-O2,and -Os
2024-03-23 12:04 [Bug c++/114441] New: Relocation issues when compiling with -O1,-O2,and -Os njuwy at smail dot nju.edu.cn
` (3 preceding siblings ...)
2024-03-24 11:38 ` xry111 at gcc dot gnu.org
@ 2024-03-25 12:07 ` njuwy at smail dot nju.edu.cn
4 siblings, 0 replies; 6+ messages in thread
From: njuwy at smail dot nju.edu.cn @ 2024-03-25 12:07 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2024-03-25 12:07 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-03-23 12:04 [Bug c++/114441] New: Relocation issues when compiling with -O1,-O2,and -Os njuwy at smail dot nju.edu.cn
2024-03-23 17:06 ` [Bug target/114441] " pinskia at gcc dot gnu.org
2024-03-23 17:07 ` sjames at gcc dot gnu.org
2024-03-24 5:22 ` njuwy at smail dot nju.edu.cn
2024-03-24 11:38 ` xry111 at gcc dot gnu.org
2024-03-25 12:07 ` njuwy at smail dot nju.edu.cn
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).