[Bug lto/110605] Possible lack of error checking in lto-common.cc ?

[dcb314 at hotmail dot com via Gcc-bugs]

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=edit
res file

[Bug lto/110605] Possible lack of error checking in lto-common.cc ?

[rguenth at gcc dot gnu.org via Gcc-bugs]

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 ?

[dcb314 at hotmail dot com via Gcc-bugs]

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 ?

[dcb314 at hotmail dot com via Gcc-bugs]

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=edit
object module

[Bug lto/110605] Possible lack of error checking in lto-common.cc ?

[pinskia at gcc dot gnu.org via Gcc-bugs]

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 .