https://sourceware.org/bugzilla/show_bug.cgi?id=31009
Bug ID: 31009 Summary: regression: assertion fail ../../bfd/merge.c:243 Product: binutils Version: 2.41 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: jonny.weir at clearpool dot io Target Milestone: --- Hi, I am building a complex, large-scale C++23 project using gcc12 in Debian Linux (sid) with kernel 6.5.0-1-amd64. When using binutils 2.39, the linking stage is successful whether the project was built using the -O2 or -O3 flag. However, upon testing binutils 2.41, there appears to be an issue with the linking stage when -O3 is used (-O2 builds and links correctly). To be clear, the only difference between success and failure is the optimisation level that is used. Work flow (with includes and full paths removed): g++-12 -o main.o -c -std=c++2b -fexceptions -fconcepts -fcoroutines -flto=auto -Wall -g -O3 main.cpp g++-12 -o output -flto=auto -rdynamic -Wl,-rpath=. <object_files> -Xlinker -Bstatic -lpthread -lrt -lcurl -lssl -lcrypto I get the following output: /bin/ld: BFD (GNU Binutils for Debian) 2.41 assertion fail ../../bfd/merge.c:243 /bin/ld: BFD (GNU Binutils for Debian) 2.41 assertion fail ../../bfd/merge.c:243 /bin/ld: BFD (GNU Binutils for Debian) 2.41 assertion fail ../../bfd/merge.c:243 ... /bin/ld: BFD (GNU Binutils for Debian) 2.41 assertion fail ../../bfd/merge.c:243 /bin/ld: BFD (GNU Binutils for Debian) 2.41 assertion fail ../../bfd/merge.c:243 /bin/ld: BFD (GNU Binutils for Debian) 2.41 assertion fail ../../bfd/merge.c:243 /bin/ld: BFD (GNU Binutils for Debian) 2.41 assertion fail ../../bfd/merge.c:243 /bin/ld: BFD (GNU Binutils for Debian) 2.41 assertion fail ../../bfd/merge.c:243 /bin/ld: /tmp/ccmkypk7.ltrans0.ltrans.o: access beyond end of merged section (4) /bin/ld: /tmp/ccmkypk7.ltrans0.ltrans.o: access beyond end of merged section (4) /bin/ld: /tmp/ccmkypk7.ltrans0.ltrans.o: access beyond end of merged section (20) /bin/ld: /tmp/ccmkypk7.ltrans0.ltrans.o: access beyond end of merged section (33) /bin/ld: /tmp/ccmkypk7.ltrans0.ltrans.o: access beyond end of merged section (41) /bin/ld: /tmp/ccmkypk7.ltrans0.ltrans.o: access beyond end of merged section (48) /bin/ld: /tmp/ccmkypk7.ltrans0.ltrans.o: access beyond end of merged section (60) /bin/ld: /tmp/ccmkypk7.ltrans0.ltrans.o: access beyond end of merged section (71) /bin/ld: /tmp/ccmkypk7.ltrans0.ltrans.o: access beyond end of merged section (85) /bin/ld: /tmp/ccmkypk7.ltrans0.ltrans.o: access beyond end of merged section (95) ... /bin/ld: /tmp/ccmkypk7.ltrans0.ltrans.o: access beyond end of merged section (289) /bin/ld: /tmp/ccmkypk7.ltrans0.ltrans.o: access beyond end of merged section (289) /bin/ld: /tmp/ccmkypk7.ltrans0.ltrans.o: access beyond end of merged section (278) /bin/ld: /tmp/ccmkypk7.ltrans0.ltrans.o: access beyond end of merged section (278) collect2: error: ld returned 1 exit status The output has been snipped for brevity. There are a total of 751340 lines of assertion fail output and 193 lines of output that contain the "access beyond end" message. Unfortunately, due to the nature and complexity of the project, I have been unable to provide a code example that generates the above output. I appreciate that this description is quite vague without an example piece of code to illustrate the problem, but something appears to have been changed that causes this recursive output of messages upon failure. -- You are receiving this mail because: You are on the CC list for the bug.