[Bug fortran/69360] loop optimization produces invalid code when a common array has dimension 1 in some files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69360 --- Comment #7 from Steve Kargl --- On Thu, Apr 22, 2021 at 10:20:54PM +, johnnorthall263 at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69360 > > --- Comment #6 from John Northall --- > It's deliberate! I think with this level of understanding of fortran use > in the real world commercial compilers have a bright future! I'm commercial compiler do have bright future. Of course, with commercial compiler and a license with paid user support, a commercial vendor will gladly deal with garbage-in code. > If it works with dimension set to 2 (whatever the background > true value) then it must be easy to make it do so with > dimension 1? >From the Fortran 2018 standard, R873 common-stmt is COMMON [ / [ common-block-name ] / ] common-block-object-list R874 common-block-object is variable-name [ ( array-spec ) ] C8117 (R874) An array-spec in a common-block-object shall be an explicit-shape-spec-list. R816 explicit-shape-spec is [ lower-bound : ] upper-bound This is nearly identical to the language in the Fortran 95 standard. This statement in setmid.f COMMON /SPACE/ XY(1),XYM(1) is telling gfortran that the array has an upper bound of 1. Changing the above statement to have XY(2), XYM(2) does not mean it works. It means you got luck with processor defined behavior. You simply get a different error message if you ask your Fortran compiler to help you debug your code. % ./example1 At line 21 of file setmid.f Fortran runtime error: Index '155' of dimension 1 of array 'xym' above upper bound of 2 As to "it must be easy to make it do so with dimension 1", you forgot to attach your patch. gfortran isn't a commercial compiler. It depends on contributions for volunteers such as yourself,
[Bug fortran/69360] loop optimization produces invalid code when a common array has dimension 1 in some files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69360 --- Comment #6 from John Northall --- It's deliberate! I think with this level of understanding of fortran use in the real world commercial compilers have a bright future! If it works with dimension set to 2 (whatever the background true value) then it must be easy to make it do so with dimension 1? Cheers, John On Sat, Apr 17, 2021 at 2:48 AM kargl at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69360 > > kargl at gcc dot gnu.org changed: > >What|Removed |Added > > > CC||kargl at gcc dot gnu.org > > --- Comment #5 from kargl at gcc dot gnu.org --- > (In reply to John Northall from comment #4) > > O dear - that makes gfortran unusable on many existing codes - not really > > satisfactory is it? > > John > > > > > gfortran is fairly good at finding bugs in a user's program if > one asks gfortran to do so. Add -fcheck=all to your options. > > At line 21 of file setmid.f > Fortran runtime error: Index '155' of dimension 1 of array 'xym' above > upper > bound of 1 > > Now, you have an opportunity to fix your code. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug fortran/69360] loop optimization produces invalid code when a common array has dimension 1 in some files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69360 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #5 from kargl at gcc dot gnu.org --- (In reply to John Northall from comment #4) > O dear - that makes gfortran unusable on many existing codes - not really > satisfactory is it? > John > gfortran is fairly good at finding bugs in a user's program if one asks gfortran to do so. Add -fcheck=all to your options. At line 21 of file setmid.f Fortran runtime error: Index '155' of dimension 1 of array 'xym' above upper bound of 1 Now, you have an opportunity to fix your code.
[Bug fortran/69360] loop optimization produces invalid code when a common array has dimension 1 in some files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69360 --- Comment #4 from John Northall --- O dear - that makes gfortran unusable on many existing codes - not really satisfactory is it? John On Fri, Apr 16, 2021 at 11:08 PM pinskia at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69360 > > Andrew Pinski changed: > >What|Removed |Added > > > CC||johnnorthall263 at gmail > dot com > > --- Comment #3 from Andrew Pinski --- > *** Bug 100123 has been marked as a duplicate of this bug. *** > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug fortran/69360] loop optimization produces invalid code when a common array has dimension 1 in some files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69360 Andrew Pinski changed: What|Removed |Added CC||johnnorthall263 at gmail dot com --- Comment #3 from Andrew Pinski --- *** Bug 100123 has been marked as a duplicate of this bug. ***
[Bug fortran/69360] loop optimization produces invalid code when a common array has dimension 1 in some files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69360 Richard Biener changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #2 from Richard Biener --- Invalid thus.
[Bug fortran/69360] loop optimization produces invalid code when a common array has dimension 1 in some files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69360 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-01-19 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- The code is indeed invalid on two counts. The first one is named commons of different sizes (related to/duplicate of pr44882). The second is out of bound access: the array 'e' is defined with only one element, accessing e(2) is invalid (caught if the code is compiled with -fcheck=bounds). Thus the compiler can do whatever it wants, e.g., considers that the loop is run only once. This should be disabled by the option no-aggressive-loop-optimizations, but it is not.
