[Bug lto/110605] Possible lack of error checking in lto-common.cc ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110605 --- Comment #5 from David Binderman --- Created attachment 55511 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55511&action=edit res file
[Bug lto/110605] Possible lack of error checking in lto-common.cc ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110605 Richard Biener changed: What|Removed |Added Last reconfirmed||2023-07-10 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #4 from Richard Biener --- If you do -save-temps -v you should see the actual resolution file passed as -fresolution=foobar.res to lto1 - can you attach that foobar.res file?
[Bug lto/110605] Possible lack of error checking in lto-common.cc ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110605 --- Comment #3 from David Binderman --- Given the command line: /home/dcb38/gcc/results.20230706.valgrind/bin/gcc cpgarro.o libpgplot.a then I get the valgrind error. I have attached cpgarro.o, but libpgplot.a, even with compression from xz, is 2,248,588 bytes long, so still too large. Any hints to avoid this file size limit would be most welcome.
[Bug lto/110605] Possible lack of error checking in lto-common.cc ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110605 --- Comment #2 from David Binderman --- Created attachment 55507 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55507&action=edit object module
[Bug lto/110605] Possible lack of error checking in lto-common.cc ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110605 --- Comment #1 from Andrew Pinski --- most likely not a big issue of not checking the return value here as the next fscanf that is the first thing inside the loop around num_symbols .