<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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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><br></div><div>-erik</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span class=""><blockquote type="cite"><div style="word-wrap:break-word"><div><div> We currently have</div><div><br></div><div><div><span style="white-space:pre-wrap"> </span>CXXFLAGS = -g -std=c++14</div><div><br></div><div>so I'm guessing that changing this to</div><div><br></div><div><span style="white-space:pre-wrap"> </span>CXXFLAGS = -g -std=gnu++14</div><div><br></div><div>might have the same effect.</div></div><div><br></div><div>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.</div></div></div></blockquote><div><br></div></span><div>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.</div></div><span class=""><br><div>
<div style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><div style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><div style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><div style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><div>-- </div><div>Ian Hinder</div><div><a href="http://members.aei.mpg.de/ianhin" target="_blank">http://members.aei.mpg.de/ianhin</a></div></div></div></div></div>
</div>
<br></span></div><br>_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@einsteintoolkit.org">Users@einsteintoolkit.org</a><br>
<a href="http://lists.einsteintoolkit.org/mailman/listinfo/users" target="_blank">http://lists.einsteintoolkit.org/mailman/listinfo/users</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Erik Schnetter <<a href="mailto:schnetter@cct.lsu.edu" target="_blank">schnetter@cct.lsu.edu</a>><br><a href="http://www.perimeterinstitute.ca/personal/eschnetter/" target="_blank">http://www.perimeterinstitute.ca/personal/eschnetter/</a></div>
</div></div>