I can confirm than trunk builds clean with intel-14.0, and that prior to this fix it did not.
I'm getting segfaults at the end of applications though - so I'll dig into that a little more. Might be something else in my new intel-14.0 stack… -Ben On Nov 11, 2013, at 2:13 PM, John Peterson <jwpeter...@gmail.com> wrote: > > > > On Thu, Oct 24, 2013 at 9:36 AM, Paul T. Bauman <ptbau...@gmail.com> wrote: > I'll try this. I naively fired off a build last night on a machine that had > 14.0.080 and while configure didn't set the flags, the build seemed to do OK. > > > On Thu, Oct 24, 2013 at 10:34 AM, Kirk, Benjamin (JSC-EG311) > <benjamin.k...@nasa.gov> wrote: > On Oct 23, 2013, at 4:58 PM, John Peterson <jwpeter...@gmail.com> wrote: > > > They are using the Intel 14 compilers, and some library which uses > > libmesh. It would be good if we could help them out... > > > I just committed the minimum fix I expect is necessary. I have not been able > to get the compilers yet, so I can't swear it'll work. Provided that the > compiler flags are the same as v13, trunk should be good to go. > > > Getting back to the issues with Intel 14 compilers... > > I took a more careful look at the linking errors in the build log that Carlos > sent me, and all the undefined references are of the following form: > > ./.libs/libmesh_opt.so: undefined reference to `libMesh::FE<0u, > (libMeshEnums::FEFamily)0>::inverse_map(libMesh::Elem const*, libMesh::Point > const&, double, bool)' > > for pretty much all the FE families as far as I can tell. > > I think I may see the problem -- we do explicitly instantiate the version of > inverse_map() that takes a _vector_ of points, but not the version that takes > a reference to a single Point -- but I don't know if the Intel compiler is > actually correct to complain about it, since it seems like explicitly > instantiating the former should automatically instantiate the latter. > > Anyway, I think I patched this in eef3af524 but I won't know for sure until > Carlos has a chance to try it... in the meantime does anybody know why the > explicit instantiations > > template void FE<_dim,_type>::inverse_map(const Elem*,const > std::vector<Point>&,std::vector<Point>&,Real,bool); > template Point FE<_dim,_type>::inverse_map(const Elem*,const > Point&,Real,bool) > > don't exactly match the function signatures > > void inverse_map (const Elem*, const std::vector<Point>&, > std::vector<Point>&, const Real, const bool); > Point inverse_map (const Elem*, const Point&, const Real, const bool); > > with regard to the constness of the last two arguments, yet no compilers have > ever complained about it? > > -- > John ------------------------------------------------------------------------------ November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
