On Fri, September 25, 2009 14:25, Scott Brozell wrote:
> Hi,
>
> The numvec issue appears to be a library problem with libstdc++
> which both gnu and intel use. pgi uses stlport.
> The best way to fix this is to rewrite our code to avoid the
> _Expr constructor use caused by libstdc++.
> It's not clear to me that this is easy.
Indeed their valaray does not use expression templates (which is
somewhat unexpected to me since they have a reputation of being
"high performance"); nevertheless, how about something as the
following (works for me, but may not work for a newer pgCC if
it uses the ETs):
+# ifndef __PGI
template< typename T > numvec( const std::_Expr<T,double>& rhs )
: std::valarray<double>( rhs ) {}
+# endif
Best,
Volodymyr
> I havent read the code and probably won't until oct 1.
> scott
>
> On Fri, Sep 25, 2009 at 02:04:12PM -0400, Volodymyr Babin wrote:
>> Hi Scott,
>>
>> I see -- I did not check the logs/etc assuming that nobody
>> tried pgi; the netcdf issue is simple: their preprocessor
>> puts spaces around '=' and this fools the netcdf's config.guess;
>> C++ issue should be fixable too [I did not try myself -- nobody
>> is going to use pgCC for leap anyway]; the _Complex and
>> command_argument_count() seem to be due to the old version
>> of the compilers we have here.
>>
>> Best,
>>
>> Volodymyr
>>
>> On Fri, September 25, 2009 13:51, Scott Brozell wrote:
>> > Hi,
>> >
>> > Version 6 is from Mar 2005.
>> > Some of your problems are due to an old version.
>> > Read the configure cvs log for problems on a recent version, 9;
>> > these are your netcdf and numvec problems.
>> > If i don't fix these shortly then I'll file a bug report.
>> >
>> > thanks,
>> > Scott
>> >
>> > On Fri, Sep 25, 2009 at 11:25:14AM -0400, case wrote:
>> >> On Thu, Sep 24, 2009, Volodymyr Babin wrote:
>> >>
>> >> >
>> >> > We have some old (6.0) version around and it goes as follows:
>> >> >
>> >> > 1. netcdf/src/config.guess could not guess the LIBC for CC=pgcc
>> >>
>> >> We'll try the suggested change for a while, then commit if it doesn't
>> >> break
>> >> anything else.
>> >>
>> >> >
>> >> > 2. cpp -traditional -P -DNO_SANDER_DIVCON -DBINTRAJ sqm.f >
>> _sqm.f
>> >> > pgf90 -c -O1 -Mfree -o sqm.o _sqm.f
>> >> > PGF90-S-0038-Symbol, command_argument_count, has not been
>> explicitly
>> >> > declared (_sqm.f)
>> >> > 0 inform, 0 warnings, 1 severes, 0 fatal for sqm
>> >> >
>> >> > tried 'iargc()' -- same result [cutting edge fortran?]
>> >>
>> >> The docs for Portland group may provide their solution for getting
>> >> iargc(?)
>> >>
>> >> >
>> >> > C++ style comment in line 79
>> >>
>> >> I fixed the various reported C++ comments, and put into CVS.
>> >>
>> >> > pgCC -c -I../../freelib -I../../freelib -o numvec.o numvec.cpp
>> >> > "numvec.hpp", line 27: warning: omission of explicit type is
>> >> nonstandard
>> >> > ("int" assumed)
>> >> > template< typename T > numvec( const
>> std::_Expr<T,double>&
>> >> rhs )
>> >> > : std::valarray<double>( rhs ) {}
>> >>
>> >> Scott is working on this one, which seems to affect more than just
>> >> Portland
>> >> group(?)
>> >>
>> >> > pgcc -c -Dflex -O2 -DBINTRAJ -o nmode.o nmode.c
>> >> > PGC-S-0040-Illegal use of symbol, _Complex
>> >>
>> >> Does it help to include -DUSE_AMBER_C9XCOMPLEX in your OCFLAGS
>> variable?
>> >> If so, we could add that to the configure script.
>> >>
>
> _______________________________________________
> AMBER-Developers mailing list
> AMBER-Developers.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber-developers
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Fri Sep 25 2009 - 12:00:02 PDT
