> That compiler is the Apple one... switching away from it is essentially > impossible (I don't know of anyone, anywhere that has ever been able to get > Fortrran and C++ to link together on OSX using non Apple GCC). The Intel > compilers used to be an option... but they have their own issues (like not > updating them properly for new versions of XCode, etc.).
Just curious. I have been using the compilers from hpc.sourceforge.net with open-mpi+petsc+slepc+arpack+libmesh without any problems in compile/link/run cycle on my macbook. But I do not use Xcode that much though and it still uses the in-built apple version of gcc. Have you tried using the hpc compilers in your macs ? The gcc version is at 4.6 on those. Vijay On Thu, Jun 16, 2011 at 1:00 PM, Derek Gaston <[email protected]> wrote: > > On Jun 16, 2011, at 11:46 AM, Roy Stogner wrote: > >> I'm just saying that, even if we do make the switch, you should >> upgrade your compiler too. If it flubbed std::fill that badly then >> there's probably lots of other stuff it's not optimizing as well as it >> should be. > > You have to remember that we use Macs.... > > That compiler is the Apple one... switching away from it is essentially > impossible (I don't know of anyone, anywhere that has ever been able to get > Fortrran and C++ to link together on OSX using non Apple GCC). The Intel > compilers used to be an option... but they have their own issues (like not > updating them properly for new versions of XCode, etc.). > > I'm hoping that with Lion they will give us either updated GCC, or a > CLANG/LLVM combo that works. Or maybe someone will finally release a third > party compiled version of GCC that can link Fortran and C++ together... I > guess I can always dream.... > >> It'd be nice to do a change like this ATLAS-style, where we test >> performance at configure-time and pick what to use... not sure if >> that's safe for casual use, though; I'd hate to get a grossly >> suboptimal option just because I happened to be running another >> process that interfered with timing while the optimal implementation >> was being tested. > > Interesting idea, but I agree with your conclusion. > > We could do some ifdefs to catch GCC 4.2... but I'm not sure it's necessary. > Like you point out, memset doesn't seem to ever produce _terrible_ > timings.... just less good in some cases.... > > Derek > ------------------------------------------------------------------------------ > EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image > Editing and ensure content is compliant with Accessibility Checking. > http://p.sf.net/sfu/ephox-dev2dev > _______________________________________________ > Libmesh-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/libmesh-devel > ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
