whizard is hosted by Hepforge, IPPP Durham

Opened 10 years ago

Closed 10 years ago

#703 closed defect (fixed)

Code doesn't compile with recent 5.0

Reported by: Juergen Reuter Owned by: kilian
Priority: P0 Milestone: v2.2.5
Component: core Version: 2.2.4
Severity: blocker Keywords:
Cc:

Description

This is the problem

Making all in qft
/bin/sh ../../libtool  --tag=FC   --mode=compile gfortran -I../basics -I../utilities -I../testing -I../system -I../combinatorics -I../expr_base -I../physics  -fopenmp -g -O2 -c -o model_data.lo  model_data.f90
libtool: compile:  gfortran -I../basics -I../utilities -I../testing -I../system -I../combinatorics -I../expr_base -I../physics -fopenmp -g -O2 -c model_data.f90  -fno-common -o .libs/model_data.o
model_data.f90:329:49:

   pure subroutine modelpar_data_init_complex (par, name, value)
                                                 1
Error: INTENT(OUT) argument 'par' of pure procedure ‘modelpar_data_init_complex’ at (1) may not be polymorphic
model_data.f90:321:46:

   pure subroutine modelpar_data_init_real (par, name, value)
                                              1
Error: INTENT(OUT) argument 'par' of pure procedure ‘modelpar_data_init_real’ at (1) may not be polymorphic
model_data.f90:700:13:

     buffer = prt%get_name (.false.)
             1
Error: ELEMENTAL procedure pointer component ‘get_name’ is not allowed as an actual argument at (1)
model_data.f90:716:16:

        buffer = prt%get_name (.true.)
                1
Error: ELEMENTAL procedure pointer component ‘get_name’ is not allowed as an actual argument at (1)
make[2]: *** [model_data.lo] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1

The svn revision is 220505. We have to check whether this is a problem with the compiler or our code

Change History (4)

comment:1 Changed 10 years ago by Juergen Reuter

Bazinga: the first thing is valid in F2003, but _not_ in F2008, confer https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54756. Simplest solution is to impure these two subroutines.

comment:2 Changed 10 years ago by Juergen Reuter

The first one was revision r219085 of gcc, the second one also happened close to Christmas last year. My last update (before the one now) was for October or so.

comment:3 Changed 10 years ago by Juergen Reuter

What Wolfgang wrote seems to violate the Fortran Handbook paragraph 7.5.5.2, subparagraph 3, last sentence :D

comment:4 Changed 10 years ago by Juergen Reuter

Resolution: fixed
Status: newclosed

As of r6550, all problems with gcc 5.0.0 have been resolved. Closing. Commit stop remains until 5.0 is tested on Jenkins.

Note: See TracTickets for help on using tickets.