[Bug fortran/99145] gfortran LOOP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99145 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from Dominique d'Humieres --- > Yes, please. Done
[Bug fortran/99145] gfortran LOOP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99145 --- Comment #4 from Vittorio Zecca --- (In reply to Jerry DeLisle from comment #3) > Initially it is creating the very large string in the frontend passes and > then via resolution and translation phases, and finally into the middle-end > and back end phases where it I am guessing the optimizers are realizing the > simplifications. > > It is a known that some of these special cases are not recognized in the > front end and immediately reduced. In this case it is creating a literal > constant that big. Normally a program would be attempting to use the > parameter in more than one place in which case it is literally substituted > in. > > Should we mark this as invalid? Yes, please.
[Bug fortran/99145] gfortran LOOP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99145 --- Comment #3 from Jerry DeLisle --- Initially it is creating the very large string in the frontend passes and then via resolution and translation phases, and finally into the middle-end and back end phases where it I am guessing the optimizers are realizing the simplifications. It is a known that some of these special cases are not recognized in the front end and immediately reduced. In this case it is creating a literal constant that big. Normally a program would be attempting to use the parameter in more than one place in which case it is literally substituted in. Should we mark this as invalid?
[Bug fortran/99145] gfortran LOOP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99145 --- Comment #2 from Vittorio Zecca --- I am sorry I should have taken more time analyzing this issue. Actually it is not and infinite loop, I clocked the compilation first with the -S option, then with the -c option. The compiler takes 4'52" of real time, 2'47" user time, and 43" of sys time. Same timings for -S and -c. The workstation was dedicated, with 16GB RAM. The output .s file is 1012 bytes, .o file 1776 bytes. I do not understand how gfortran takes such a long time only to produce a small object file. Sorry again for having cried wolf.
[Bug fortran/99145] gfortran LOOP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99145 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #1 from Jerry DeLisle --- What do you mean by LOOP? You are trying to set a string of 4294967300 characters to empty. The compiler is tryingt o create a very long empty string, basically a literal constant. Did the system run out of memory? What did it do?
