[Bug fortran/79933] gfortran no longer able to compile dolfyn benchmark

2017-11-04 Thread sgk at troutmask dot apl.washington.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79933

--- Comment #6 from Steve Kargl  ---
On Sat, Nov 04, 2017 at 09:18:22PM +, tulipawn at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79933
> 
> --- Comment #5 from PeteVine  ---
> You're right, sorry for the confusion. It seems I skimmed over the wall of
> errors too quickly while the last one came from a different source file.
> 
> According to my own results in bug #77730, I was somehow able to build the
> benchmark with earlier versions of gcc 6/7 using the -std=f95 flag. Could you
> try the following steps?
> 
> wget http://www.phoronix-test-suite.com/benchmark-files/dolfyn-cfd_0.527.tgz 
> tar xvf dolfyn-cfd_0.527.tgz
> cd dolfyn-cfd_0.527/src/
> sed -i 's/F90FLAGS = -O2/F90FLAGS = -O2 -std=f95/' Makefile
> make
> 

Please, just fix the code.

If you're using sed to "fix" the Makefile, then use
sed to fix the source.

[Bug fortran/79933] gfortran no longer able to compile dolfyn benchmark

2017-11-04 Thread tulipawn at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79933

--- Comment #5 from PeteVine  ---
You're right, sorry for the confusion. It seems I skimmed over the wall of
errors too quickly while the last one came from a different source file.

According to my own results in bug #77730, I was somehow able to build the
benchmark with earlier versions of gcc 6/7 using the -std=f95 flag. Could you
try the following steps?

wget http://www.phoronix-test-suite.com/benchmark-files/dolfyn-cfd_0.527.tgz 
tar xvf dolfyn-cfd_0.527.tgz
cd dolfyn-cfd_0.527/src/
sed -i 's/F90FLAGS = -O2/F90FLAGS = -O2 -std=f95/' Makefile
make

[Bug fortran/79933] gfortran no longer able to compile dolfyn benchmark

2017-11-04 Thread kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79933

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to PeteVine from comment #3)
> In gcc 8, -std=f2003 is required to overcome the issue but there's another
> failure later on:
> 

-std=f95 works fine with the attached source code.

In fact, I find

% grep -i real a.f90
real  node(3) 

REAL*4 is no where present in this code.

[Bug fortran/79933] gfortran no longer able to compile dolfyn benchmark

2017-11-04 Thread tulipawn at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79933

--- Comment #3 from PeteVine  ---
In gcc 8, -std=f2003 is required to overcome the issue but there's another
failure later on:

gfortran -c -O2 -std=f2003solverinterface.f90
solverinterface.f90:108:9:

real*4  fpar(16)  ! hint by Shibo
 1
Error: GNU Extension: Nonstandard type declaration REAL*4 at (1)
solverinterface.f90:153:7:

fpar(1) = RTOL(VarSC)
   1
Error: Unclassifiable statement at (1)
solverinterface.f90:154:7:

fpar(2) = ATOL(VarSC)
   1
Error: Unclassifiable statement at (1)
solverinterface.f90:156:7:

fpar(1) = RTOL(ivar) ! relative tolerance, must be between (0, 1)
   1
Error: Unclassifiable statement at (1)
solverinterface.f90:157:7:

fpar(2) = ATOL(ivar) ! absolute tolerance, must be positive
   1
Error: Unclassifiable statement at (1)
solverinterface.f90:176:1:

 NNZ,  Alu,Jlu,Ju,Jw )
 1

Are there any gfortran switches that would enable compiling this code base as
is?

[Bug fortran/79933] gfortran no longer able to compile dolfyn benchmark

2017-03-06 Thread jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79933

Jerry DeLisle  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Jerry DeLisle  ---
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77978 for some history on the
change.

[Bug fortran/79933] gfortran no longer able to compile dolfyn benchmark

2017-03-06 Thread jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79933

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #1 from Jerry DeLisle  ---
Well, from the comments I see in our matchers, the blank is required by F2008
Standard so we are enforcing that requirement.

From my copy of the standard:

3.3.2.2 Blank characters in free form

1) A blank shall be used to separate names, constants, or labels from adjacent
keywords, names, constants, or labels.

So I would put a blank in there and then forget about it.  I noticed that the
file has a scattering of TAB characters in there which are strictly speaking
forbidden, but we allow it. -Wtabs or -Wall will show where.

I would call this "not a bug"