Hi,
And the answer is ... it's not standard conforming code and is a
lurking bug. Section 5.1.2.3 of the f95 standard applies. That's
reproduced (from the 2003 stand.) at this link with useful context:
http://forums.sun.com/thread.jspa?threadID=5325354
This is confirmed by my fortran expert.
On Thu, Sep 30, 2010 at 10:56:20AM -0700, Ross Walker wrote:
> My point is though that there is probably a lot more than just this one
> instance. So if we are going to release a patch for this one perhaps we
> should take a chunk of code each and go through and check it for use of
> intent out and fix as appropriate. I actually think we should try to have a
> code audit at some point, either at the developers meeting where several of
> us can sit down without distraction or at separate meeting. We could make a
> list of things we should check and then each go through a section of code
> looking for such things.
I welcome a code audit; last time we had one at the DAC Inn, a grand time
was had by all. I'm sure we could find comparable accommodations in
Athens Greece ;-)
But until the audit, unless someone is volunteering, i don't see a
practical alternative to piecemeal bugfix releases.
scott
ps note $(FC) -c $(FOPTFLAGS) -o $. _constantph.f
On Thu, Sep 30, 2010 at 03:20:30PM -0400, Jason Swails wrote:
> It's src/sander/constantph.f in the "cnstphupdatechrg" subroutine (and the
> subroutines that call it, specifically cnstphendstep). The charge array,
> whatever it is (charge or dcharge in cnstphendstep) is an array of length
> natom that has partial atomic charges for every atom, yet cnstphupdatechrg
> only updates the charges from a single residue, or a small portion of the
> array.
>
> On Thu, Sep 30, 2010 at 2:46 PM, Scott Brozell <sbrozell.rci.rutgers.edu>wrote:
> > On Thu, Sep 30, 2010 at 08:46:56AM -0400, Jason Swails wrote:
> > > Well intent(out) is applied to an array in which only a chunk of the
> > array
> > > is initialized (the charges of a single residue, or 2, are changed in the
> > > global charge array). According to the Fortran standard, I think the
> > rest
> > > of the array is technically undefined. So it would be legitimate
> > compiler
> > > behavior to trash the remaining array values. If I'm mistaken here,
> > please
> >
> > Sorry, when i read this the first time i saw derived type, not array.
> > So I don't think this is an example of the problem demonstrated at
> > http://www.cs.rpi.edu/~szymansk/OOF90/bugs.html#2<http://www.cs.rpi.edu/%7Eszymansk/OOF90/bugs.html#2>
> > I'm checking the f90 standard.
> >
> > What is the file and source line ?
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Thu Sep 30 2010 - 23:00:04 PDT
