[gmx-developers] GROMACS 4.0.1 still broken on Bluegene

[Roland Schulz]

On Sun, Nov 9, 2008 at 4:07 PM, Erik Lindahl <lindahl at cbr.su.se> wrote:

> Hi,
>
> On Nov 9, 2008, at 7:41 PM, David van der Spoel wrote:
>
>>
>>>  I just followed your advice and neither on my Mac nor on a Centos Linux
>> 5.0 box did I get any warnings. Doubtlessly compilers are getting better,
>> but they have come from a very low starting quality. We regularly check
>> compilation in this manner, usually without finding anything beyond the
>> obvious. A new development is that the GNU C library has become more picky
>> with memory management. Due to this some problems in very old code have
>> surfaced (although the code was correct according to the book...). We try to
>> follow the developments, and are grateful for tips like this.
>>
>
> You won't get any warnings by adding -fno-strict-aliasing, as far as I know
> at least :-)


Only together with  -Wstrict-aliasing or -Wall.


> ANSI C actually specifies that no two arrays or pointers that are
> parameters to a function may point to the same memory (unless one of them is
> marked const, if I recall correctly), but the flag above relaxes that, which
> could inhibit some optimization.  However, we've been rather careful with
> this, so I think we adhere pretty close to the standard.


I'm not sure. But I think it is little bit different.

Parameters with *different* types are *not allowed* to point to the same
memory.
Parameters with *the same* types are *allowed* to point to the same memory.
Parameters with *the same* types declared *restricted* are *not allowed* to
point to the same memory.

See also:
http://www.cs.helsinki.fi/linux/linux-kernel/2003-06/0614.html


Roland


-- 
ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20081109/bd616222/attachment.html>