On Fri, May 22, 2015 at 12:38 PM, Ian Hinder <[email protected]> wrote:
> > On 22 May 2015, at 18:34, Ian Hinder <[email protected]> wrote: > > > On 22 May 2015, at 16:10, Roberto De Pietri <[email protected]> > wrote: > > Hi Ian: > > > Thanks for the answer. I followed exactly your procedure and I was very > surprised of having > a failing compilation. Than I starting tracing back the problem. > * All the thorns except one were compiling correctly. > * The failing thorn was CarpetIOHDF5 and of the 5 source files present > only 3 failed > * The error was very strange because the only real problem was related to > a system include > “/opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h” > and was related to conversion using AVX intel intrinsic. The error were > of the type: > > error: can’t convert between vector values of different size > return (__m64) __builtin_ia32_vec_init_v2si (__i, 0); > > > There is a stackoverflow post ( > http://stackoverflow.com/questions/19043109/gcc-4-8-1-combining-c-code-with-c11-code > ) which describes a similar problem, which I haven't studied in depth, but > they seem to suggest that it's a bug in gcc, and that setting > --std=gnu++11 instead of --std=c++11 in CXXFLAGS will work around the > problem. > > Yes, it seems that this describes the problem we're having. GCC uses __attribute__ to provide certain language extensions, e.g. for vectorization. These are not optional declarations -- these modify function definition and can't just be omitted. And HDF5 does just that: it #defines __attribute__ to be empty (file H5api_adpt.h, near the beginning) if the file is included from C++. I have no idea why they would think this is legal, or why they would think this is even a good idea. We use __attribute__ in Cactus (after checking via autoconf whether it is supported) for a variety of optimizations and security checks. I would try adding the line #undef __attribute__ right after (below) any line that says #include <hdf5.h> to undo (part of) the damage that HDF5 does. We should also complain to the HDF5 authors. -erik > We currently have > > CXXFLAGS = -g -std=c++14 > > so I'm guessing that changing this to > > CXXFLAGS = -g -std=gnu++14 > > might have the same effect. > > What I don't understand is why we didn't pick this up in testing. I > successfully compiled the whole ET using exactly that set of MacPorts > packages and the optionlist before the release, and the gcc49 macports > package hasn't been updated since 4 weeks ago. > > > I should add that I tested it on 10.9.5, since I haven't been brave enough > to update to 10.10 yet. I think Erik was testing on 10.10, but he can > confirm that. > > -- > Ian Hinder > http://members.aei.mpg.de/ianhin > > > _______________________________________________ > Users mailing list > [email protected] > http://lists.einsteintoolkit.org/mailman/listinfo/users > > -- Erik Schnetter <[email protected]> http://www.perimeterinstitute.ca/personal/eschnetter/
_______________________________________________ Users mailing list [email protected] http://lists.einsteintoolkit.org/mailman/listinfo/users
