Thank you very much. In this case, it can be fixed with like the following
change. if it is still backward compatibility in the future, we have
to always test it in the previous gcc version.
For example, in the crg_reloc.f,
.....
if ( cr_upcharge(i) == .false. ) cycle
===> if ( cr_upcharge(i) .eqv. .false. ) cycle
.....
.....
_REAL_, dimension(:,:), allocatable, intent(inout) :: hold_dcdr
===>_REAL_, dimension(:,:), pointer :: hold_dcdr
.....
Best Regards,
Fu Lin
2011/12/14 David A Case <case.biomaps.rutgers.edu>
> On Wed, Dec 14, 2011, Lin Fu wrote:
> >
>
> Thanks for your note(Below). These points should be posted on the Amber
> developers list; and I am cc-ing this there.
>
> I think we are still trying to support gcc 4.1.2, mainly because Ross has
> noted that such compilers are still prevalent at supercomputer sites, and
> there are other machines in the same boat. I'd love to get past that
> however,
> and I wonder if supercomputer users don't have access to other compilers
> (e.g.
> Intel, pathscale, etc.) that would avoid this problem. There are many
> other
> places that would benefit from not being tied to gcc 4.1.2, and most
> developers (including me) don't have such machines; (instructions for
> setting
> up a virutal machine with whatever OS this is [RHEL x??] might help.
>
> (InSuk: can you work on fixing the problems noted below...thx.)
>
> ....dac
>
> > I would like to enquiry whether the current amber on the git can be
> > compiled successfully with gcc4.1.2, albeit it can be compiled on the
> > gcc4.6 etc.. Do we still support gcc4.1.2 in the future release. It seems
> > that in current version some code are following the style of
> > Fortran03 standard.
> > ........
> > ........
> > ........
> > cpp -traditional -P -DBINTRAJ crg_reloc.f > _crg_reloc.f
> > crg_reloc.f:2609: warning: extra tokens at end of #endif directive
> > crg_reloc.f:2689: warning: extra tokens at end of #endif directive
> > gfortran -c -O3 -ffree-form -I../../AmberTools/src/pbsa
> > -I../../AmberTools/src/sqm -I../../AmberTools/src/rism -I../../include
> -o
> > crg_reloc.o _crg_reloc.f
> > In file _crg_reloc.f:1821
> >
> > _dcdr
> > 1
> > Error: ALLOCATABLE attribute conflicts with DUMMY attribute at (1)
> > In file _crg_reloc.f:1834
> >
> > allocate( hold_dcdr(j_beg:j_end,3), stat=ierr )
> > 1
> > Error: Syntax error in ALLOCATE statement at (1)
> > In file _crg_reloc.f:1816
> >
> > subroutine cr_get_hold( cr_type, hold, release, hold_dcdr, j_beg, j_end,&
> > 1
> > Error: Symbol 'hold_dcdr' at (1) has no IMPLICIT type
> > In file _crg_reloc.f:1750
> >
> > call cr_get_hold( cr_type, hold, release, hold_dcdr, &
> > 1
> > Error: Type/rank mismatch in argument 'hold_dcdr' at (1)
> > In file _crg_reloc.f:1772
> >
> > call cr_get_hold( cr_type, hold, release, hold_dcdr, &
> > 1
> > Error: Type/rank mismatch in argument 'hold_dcdr' at (1)
> >
> > *gcc version 4.1.2 20080704 (Red Hat 4.1.2-44) is used here.*
> > *
> > *
> >
> > Thank you very much,
> > Fu Lin
> > ==================================
> > Postdoc, Simmerling Lab
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Dec 14 2011 - 09:30:03 PST
