<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">Hi,<br><br></div><div class="gmail_quote">Let me state this early enough:<br>- the concerns I raised are related to *usability* and not some standard common practice defines the current compiler flag setup and behaviour;<br>
- I consider the current setup safe and consistent for anyone who dos not care about compiler flags, but extremely confusing, a potential performance concern, and error prone as well for those who want to do *anything* with compiler flags. Just think through how will you explain to an average, rather inexperienced GROMACS user to change a default flag to something else.<br>
</div><div class="gmail_quote"><br>On Sun, Feb 3, 2013 at 1:53 AM, Roland Schulz <span dir="ltr"><<a href="mailto:roland@utk.edu" target="_blank">roland@utk.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div>On Sat, Feb 2, 2013 at 5:42 PM, Szilárd Páll <span dir="ltr"><<a href="mailto:szilard.pall@cbr.su.se" target="_blank">szilard.pall@cbr.su.se</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div dir="ltr"><span style="font-family:arial,sans-serif;font-size:13px">Hi,</span>
<div style="font-family:arial,sans-serif;font-size:13px"><br>
</div>
<div style="font-family:arial,sans-serif;font-size:13px">With the compiler flag handling changed between beta3 and final, now it is completely impossible to check or modify compiler flags we generate.</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br>
</div>
<div style="font-family:arial,sans-serif;font-size:13px">I might have missed the discussion on this during code review, but I simply consider this a bug. It is pretty much impossible to know what compiler flags are being used - at least not at build time, not
even by looking at the cache, and not without first compiling a binary and checking the "-version" output.</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br>
</div>
<div style="font-family:arial,sans-serif;font-size:13px">Not only that this is a rather annoying, making it impossible to change the default compiler options is a very naive behavior. </div></div></div></blockquote></div>
<div>
You need to set GMX_SKIP_DEFAULT_CFLAGS. This lets you overwrite and see what would be appended.</div></div></div></div></blockquote><div><br></div><div>Sorry, but that does not answer my questions/concerns. Moreover, GMX_SKIP_DEFAULT_CFLAGS seems to me an awkward workaround. First of all, there is no intuitive way to figure out how to do what many moderately advanced user will want accomplish at some point: simply reviewing and changing the compiler flags.<br>
Secondly, the name of the variable suggests nothing about the fact that this is the only way to review/edit the flags and even if some user happens to magically figure it out (which I highly doubt), a cluttered dump of the flags "skipped" is even worse than providing a "configure-compatible" behaviour, i.e with configure everything is in the config.log while we have only the CMake defaults (=inferior), with configure you override everything, in our case some flags get overridden other don't.<br>
<br></div> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div><br></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div><div dir="ltr">
<div style="font-family:arial,sans-serif;font-size:13px">Additionally, there is another issue with the bove example: manually passing CMAKE_C_FAGLS_RELEASE will overwrite the default release flags (-O3 -DNDEBUG). This leads to another issue: passing any additional release
flag will lead to -O2 being used as this is the default with most compilers (and -O3 get overridden). Consequently, if one wants to *append* and optimization flag, this can only be done post-configure by modifying the cache, but not during configure which
goes against the principle we tried to adhere to that users should be able to flexibly configure GROMACS by using a single command.</div></div></div></blockquote><div><br></div></div><div>O3 is set by cmake not by us - and it behaves as cmake developers think it should behave. Look at the redmine issues for the details.</div>
</div></div></div></blockquote><div><br></div><div>If you consider this for a second you will probably agree: it's
pretty much irrelevant (from the user's point of view) whether a flag is
CMake default or custom GROMACS one. In fact, as we are very much concerned about performance and many of the flags we set serve this goal, I would argue that the optimization level should perhaps be controlled by us and not CMake - especially that CMake happily overwrites the non-hidden part of CMAKE_C_FAGLS_RELEASE thus throwing out the *very important* -O3. This will result in falling back to -O2 (the default with most compilers) which will lead to significant performance loss.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir="ltr">
<div style="font-family:arial,sans-serif;font-size:13px">I think the above issues need fixing asap, preferably by 4.6.1, but I'm not familiar with the code, so I can't suggest a concrete solution.</div></div></div>
</blockquote></div><div>I disagree. Everything works the way as has been discussed in redmine. We shoudn't change the behaviour after a release.</div></div></div></div></blockquote><div><br></div><div>Sorry, but that's not entirely true. #1038 was mostly concerned about the CPU acceleration detection not working consistently and about monolithic vs modular CFLAGS which is not what I am talking about. Unfortunately I did not have time neither to comment on 1040 nor to review the change before it got merged (rather hastily, after only 12h by the author himself). Note that 1040 which was talking about usability and consistency and while the latter has improved, the former has IMO gotten worse. <br>
<br><br><div>To conclude, I would be OK with the current behaviour if certain thing were possible or less awkward to do, e.g.:<br></div><div>- reviewing compiler flags used at *configure-time*;<br></div><div>- adding compiler flags;<br>
</div><div>- removing/overriding compiler flags;<br></div><div>and adding or overriding should be possible through a single command-line invocation.<br><br>More concretely IMO what we need is:<br>- A summary printed or at least some read-only advanced variables so that one does not need to run e.g "mdrun -version" to know what flags are used;<br>
</div><div><br>- An intuitive and consistent way to add/change the flags, what the user wants is simple, but currently requires a set of strange steps: enable skipping GROMACS flags, copy the printed flags, remove cache, re-run cmake with the copied flags.<br>
It might be a good idea to override everything or nothing regardless whether it's GROMACS or CMake flags.<br><br></div><div>Cheers,<br>Szilard<br></div>
<br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>
Roland </div><div><br></div><div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir="ltr">
<div style="font-family:arial,sans-serif;font-size:13px"><br>
</div>
<div style="font-family:arial,sans-serif;font-size:13px">Cheers,</div><span><font color="#888888">
<div>
<div>--<br>
Szilárd</div>
</div>
</font></span></div><span><font color="#888888">
</font></span></div><span><font color="#888888">
</font></span></blockquote></div><span><font color="#888888"><br><br clear="all"><div><br></div>-- <br>ORNL/UT Center for Molecular Biophysics <a href="http://cmb.ornl.gov" target="_blank">cmb.ornl.gov</a><br>865-241-1537, ORNL PO BOX 2008 MS6309
</font></span></div></div>
<br>--<br>
gmx-developers mailing list<br>
<a href="mailto:gmx-developers@gromacs.org" target="_blank">gmx-developers@gromacs.org</a><br>
<a href="http://lists.gromacs.org/mailman/listinfo/gmx-developers" target="_blank">http://lists.gromacs.org/mailman/listinfo/gmx-developers</a><br>
Please don't post (un)subscribe requests to the list. Use the<br>
www interface or send it to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.<br></blockquote></div><br></div></div>