Thank you for catching the problem.
I just pushed changes. Let me know if there is still any problem.
Thank Jason for correcting some of them.
On Wed, Dec 14, 2011 at 12:00 PM, Lin Fu <linfu3200.gmail.com> wrote:
> 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
>>
>
>
--
Best,
InSuk Joung
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Dec 14 2011 - 10:00:02 PST
