How critical are my compilation warnings?

option, parallelism,...

Moderators: fgoudreault, mcote

Forum rules
Please have a look at ~abinit/doc/config/build-config.ac in the source package for detailed and up-to-date information about the configuration of Abinit 8 builds.
For a video explanation on how to build Abinit 7.x for Linux, please go to: http://www.youtube.com/watch?v=DppLQ-KQA68.
IMPORTANT: when an answer solves your problem, please check the little green V-like button on its upper-right corner to accept it.
Locked
spamrefuse
Posts: 35
Joined: Wed Jan 20, 2010 3:08 am

How critical are my compilation warnings?

Post by spamrefuse » Fri Mar 19, 2010 9:02 am

On my Fedora 12 linux system, I do:

$ ./configure --disable-etsf_io --disable-libxc --disable-netcdf --disable-bigdft --disable-wannier90
$ make
[...]
drotmg.f:138.15:

GO TO IGO(120,150,180,210)
1
Warning: Deleted feature: Assigned GOTO statement at (1)
drotmg.f:144.72:

ASSIGN 120 TO IGO
1
Warning: Deleted feature: ASSIGN statement at (1)
drotmg.f:156.72:

ASSIGN 150 TO IGO
1
Warning: Deleted feature: ASSIGN statement at (1)
drotmg.f:169.72:

ASSIGN 180 TO IGO
1
Warning: Deleted feature: ASSIGN statement at (1)
drotmg.f:180.72:

ASSIGN 210 TO IGO
1
Warning: Deleted feature: ASSIGN statement at (1)
srotmg.f:140.15:

GO TO IGO(120,150,180,210)
1
Warning: Deleted feature: Assigned GOTO statement at (1)
srotmg.f:146.72:

ASSIGN 120 TO IGO
1
Warning: Deleted feature: ASSIGN statement at (1)
srotmg.f:158.72:

ASSIGN 150 TO IGO
1
Warning: Deleted feature: ASSIGN statement at (1)
srotmg.f:171.72:

ASSIGN 180 TO IGO
1
Warning: Deleted feature: ASSIGN statement at (1)
srotmg.f:182.72:

ASSIGN 210 TO IGO
1
Warning: Deleted feature: ASSIGN statement at (1)
dtsetcopy.F90:590: warning: "DTSET_AREA_SIZE2" redefined
dtsetcopy.F90:555: warning: this is the location of the previous definition

[...]


How critical are these warnings?

R.L.

xecle
Posts: 11
Joined: Mon Mar 08, 2010 6:54 am
Location: Hangzhou , China

Re: How critical are my compilation warnings?

Post by xecle » Sun Mar 21, 2010 2:02 am

recheck your fortran compiler version or ignore them .

spamrefuse
Posts: 35
Joined: Wed Jan 20, 2010 3:08 am

Re: How critical are my compilation warnings?

Post by spamrefuse » Sun Mar 21, 2010 1:37 pm

$ gfortran --version
GNU Fortran (GCC) 4.4.3 20100127 (Red Hat 4.4.3-4)
Copyright (C) 2010 Free Software Foundation, Inc.

Is that not an appropriate fortran compiler version?

R.L.

xecle
Posts: 11
Joined: Mon Mar 08, 2010 6:54 am
Location: Hangzhou , China

Re: How critical are my compilation warnings?

Post by xecle » Sun Mar 21, 2010 4:20 pm

spamrefuse wrote:$ gfortran --version
GNU Fortran (GCC) 4.4.3 20100127 (Red Hat 4.4.3-4)
Copyright (C) 2010 Free Software Foundation, Inc.

Is that not an appropriate fortran compiler version?

R.L.


I think the following infomation may help you to understand the warring.

The features deleted in the Fortran 95 draft were on the obsolete features list of Fortran 90, and thus candidates for deletion in Fortran 95. However, until Fortran 95 replaces Fortran 90, these statements are standard conforming. Many vendors will leave these statements in Fortran to make sure that users have upward compatibility of their old codes. The arithmetic IF statement, alternate returns, the Computed GO TO statement, and single line statement functions were on the obsolescent list in Fortran 90, but were not deleted this time. They remain on the obsolete features list.

Following is a list of deleted and obsolete features, along with suggestions for replacing them:

Deleted features

Real and double precision DO variables. Use integer DO variables or a form of the DO not requiring a DO variable. This feature has been very little used by programmers and was not mentioned in the public review.

Branching to an ENDIF statement from outside the IF block. This makes for a confusing program and interrupts the logic flow.

PAUSE statement. This is very little used, if at all. However, it should be noted that there is no asynchronous input/output in the standard. It is in the requirements planning for Fortran 2000, however.

ASSIGN, ASSIGNED GOTO, and assigned FORMAT. The standard no longer allows the assignment of a label to an integer. Use a character variable.

H edit descriptor. The H edit descriptor is inconsistent with the other character features that have been developed in Fortran. Use a character constant in the print statement or the A edit descriptor in a format specification.


Dealing with obsolescent features

Some features are new to the obsolescent features list. The obsolete features in Fortran 95 include those remaining from Fortran 90 and not deleted as well. We recommend that these obsolete features not be introduced into new projects. Some alternatives are suggested below. If users object to the removal of any feature on this list, the standards committee will not remove it. However, it is important to keep the size of the language under control.

Arithmetic IF remains on the list from Fortran 90. Many users still depend on this feature. Use an IF statement or construct that does not depend on an arithmetic subtraction.

Shared DO termination remains in the list from Fortran 90. Use END DO or a CONTINUE statement to separate terminal statements in a nested DO loop.

Alternate RETURN remains from Fortran 90. Use a CASE construct instead.

Computed GO TO is a little too specific. Use the CASE construct, which is more general, easier to use, as well as more efficient.

Statement functions are redundant with internal procedures, which you should use instead.

DATA statements among executables are little used and can easily be moved to the nonexecutable part of the program. It is likely this will be required in Fortran 95.

Assumed character length functions are a language irregularity. Use an automatic character length function.

Fixed source form is an old set of form rules based on unit record equipment and punched cards. With today's terminal environment, free form source is more efficient.

CHARACTER * form of the character declaration. This form is an unnecessary redundancy. Use the other form, for example:

CHARACTER (LEN=80) X



Locked