public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/99145] New: gfortran LOOP
@ 2021-02-18 10:55 zeccav at gmail dot com
2021-02-19 3:36 ` [Bug fortran/99145] " jvdelisle at gcc dot gnu.org
` (4 more replies)
0 siblings, 5 replies; 6+ messages in thread
From: zeccav at gmail dot com @ 2021-02-18 10:55 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99145
Bug ID: 99145
Summary: gfortran LOOP
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
Target Milestone: ---
Loop compiling the following code:
! gfortran LOOP?
character (len=2_8**32_8+4_8), parameter :: s = ""
end
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug fortran/99145] gfortran LOOP
2021-02-18 10:55 [Bug fortran/99145] New: gfortran LOOP zeccav at gmail dot com
@ 2021-02-19 3:36 ` jvdelisle at gcc dot gnu.org
2021-02-19 9:22 ` zeccav at gmail dot com
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: jvdelisle at gcc dot gnu.org @ 2021-02-19 3:36 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99145
Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jvdelisle at gcc dot gnu.org
--- Comment #1 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
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?
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug fortran/99145] gfortran LOOP
2021-02-18 10:55 [Bug fortran/99145] New: gfortran LOOP zeccav at gmail dot com
2021-02-19 3:36 ` [Bug fortran/99145] " jvdelisle at gcc dot gnu.org
@ 2021-02-19 9:22 ` zeccav at gmail dot com
2021-02-19 16:14 ` jvdelisle at gcc dot gnu.org
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: zeccav at gmail dot com @ 2021-02-19 9:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99145
--- Comment #2 from Vittorio Zecca <zeccav at gmail dot com> ---
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug fortran/99145] gfortran LOOP
2021-02-18 10:55 [Bug fortran/99145] New: gfortran LOOP zeccav at gmail dot com
2021-02-19 3:36 ` [Bug fortran/99145] " jvdelisle at gcc dot gnu.org
2021-02-19 9:22 ` zeccav at gmail dot com
@ 2021-02-19 16:14 ` jvdelisle at gcc dot gnu.org
2021-02-20 7:01 ` zeccav at gmail dot com
2021-02-20 12:00 ` dominiq at lps dot ens.fr
4 siblings, 0 replies; 6+ messages in thread
From: jvdelisle at gcc dot gnu.org @ 2021-02-19 16:14 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99145
--- Comment #3 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
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?
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug fortran/99145] gfortran LOOP
2021-02-18 10:55 [Bug fortran/99145] New: gfortran LOOP zeccav at gmail dot com
` (2 preceding siblings ...)
2021-02-19 16:14 ` jvdelisle at gcc dot gnu.org
@ 2021-02-20 7:01 ` zeccav at gmail dot com
2021-02-20 12:00 ` dominiq at lps dot ens.fr
4 siblings, 0 replies; 6+ messages in thread
From: zeccav at gmail dot com @ 2021-02-20 7:01 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99145
--- Comment #4 from Vittorio Zecca <zeccav at gmail dot com> ---
(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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug fortran/99145] gfortran LOOP
2021-02-18 10:55 [Bug fortran/99145] New: gfortran LOOP zeccav at gmail dot com
` (3 preceding siblings ...)
2021-02-20 7:01 ` zeccav at gmail dot com
@ 2021-02-20 12:00 ` dominiq at lps dot ens.fr
4 siblings, 0 replies; 6+ messages in thread
From: dominiq at lps dot ens.fr @ 2021-02-20 12:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99145
Dominique d'Humieres <dominiq at lps dot ens.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #5 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> Yes, please.
Done
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-02-20 12:00 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-18 10:55 [Bug fortran/99145] New: gfortran LOOP zeccav at gmail dot com
2021-02-19 3:36 ` [Bug fortran/99145] " jvdelisle at gcc dot gnu.org
2021-02-19 9:22 ` zeccav at gmail dot com
2021-02-19 16:14 ` jvdelisle at gcc dot gnu.org
2021-02-20 7:01 ` zeccav at gmail dot com
2021-02-20 12:00 ` dominiq at lps dot ens.fr
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).