<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 23 May 2015, at 05:08, Erik Schnetter <<a href="mailto:schnetter@cct.lsu.edu">schnetter@cct.lsu.edu</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">On Fri, May 22, 2015 at 12:38 PM, Ian Hinder <span dir="ltr"><<a href="mailto:ian.hinder@aei.mpg.de" target="_blank">ian.hinder@aei.mpg.de</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto;"><div style="word-wrap:break-word"><br><div><span class=""><div>On 22 May 2015, at 18:34, Ian Hinder <<a href="mailto:ian.hinder@aei.mpg.de" target="_blank">ian.hinder@aei.mpg.de</a>> wrote:</div><br><blockquote type="cite"><div style="word-wrap:break-word"><br><div><div>On 22 May 2015, at 16:10, Roberto De Pietri <<a href="mailto:roberto.depietri@unipr.it" target="_blank">roberto.depietri@unipr.it</a>> wrote:</div><br><blockquote type="cite">Hi Ian:<br><br><br>Thanks for the answer. I followed exactly your procedure and I was very surprised of having<br>a failing compilation. Than I starting tracing back the problem. <br>* All the thorns except one were compiling correctly.<br>* The failing thorn was CarpetIOHDF5 and of the 5 source files present only 3 failed<br>* The error was very strange because the only real problem was related to <br> a system include “/opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h”<br> and was related to conversion using AVX intel intrinsic. The error were of the type:<br><br> error: can’t convert between vector values of different size<br> return (__m64) __builtin_ia32_vec_init_v2si (__i, 0);<br></blockquote><div><br></div><div>There is a stackoverflow post (<a href="http://stackoverflow.com/questions/19043109/gcc-4-8-1-combining-c-code-with-c11-code" target="_blank">http://stackoverflow.com/questions/19043109/gcc-4-8-1-combining-c-code-with-c11-code</a> ) 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.</div></div></div></blockquote></span></div></div></blockquote><div>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.</div><div><br></div><div>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.</div><div><br></div><div>I would try adding the line</div><div><br></div><div>#undef __attribute__</div><div><br></div><div>right after (below) any line that says</div><div><br></div><div>#include <hdf5.h></div><div><br></div><div>to undo (part of) the damage that HDF5 does. We should also complain to the HDF5 authors.</div></div></div></div></blockquote><div><br></div><div>So to summarise:</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>– HDF5 is undefining __attribute__, and this is a bug in hdf5. </div><div><span class="Apple-tab-span" style="white-space:pre"> </span>– In the stack overflow post, argp.h is undefining __attribute__, so this is a bug in glibc</div><div><br></div><div>Is that correct? My suggestion to try --std=gnu++11 in CXXFLAGS won't fix the problem in the HFD5 header; it would only affect the argp.h problem, which doesn't apply to us.</div><div><br></div><div>Digging a bit deeper, it seems that we have been bitten (again) by trying to track a moving target. The HDF5 MacPorts port was updated from 1.8.14 to 1.8.15 on 16-May-2015 (<a href="https://trac.macports.org/log/trunk/dports/science/hdf5/Portfile">https://trac.macports.org/log/trunk/dports/science/hdf5/Portfile</a>), 2 days before the ET release, and after the release branches had been created and the final testing had been done. Note that this also happened with OpenMPI a few days before, introducing a critical regression which we were able to work around in time.</div><div><br></div><div>The responsible commit in HDF5 seems to be this one:</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span><a href="https://github.com/live-clones/hdf5/commit/b283f087e32fb99023650240ef8290a3f46319c5">https://github.com/live-clones/hdf5/commit/b283f087e32fb99023650240ef8290a3f46319c5</a></div><div><br></div><div>They were previously undefining __attribute__ only in H5private.h, which is included by hdf5 source files, but not from the public api used by user code, and this commit moves this definition into a public header file included by user code. Erik, do you want to contact the developers, since you understand this better than I do? </div><div><br></div><div>I think the most sensible workaround for us would be set HDF5_DIR = BUILD in osx-macports.cfg, since the current macports version is broken. MacPorts has a single tree, they don't split into stable and unstable branches, presumably due to lack of resources. The same is true of homebrew; presumably they will also update to 1.8.15 at some point, so maybe we should build HDF5 for homebrew as well. The Cactus-provided version in ExternalLibraries is 1.8.14. </div><div><br></div><div>-- </div></div><div apple-content-edited="true"><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>Ian Hinder</div><div><a href="http://members.aei.mpg.de/ianhin">http://members.aei.mpg.de/ianhin</a></div></div></div></div></div>
</div>
<br></body></html>