<div dir="ltr"><span style="font-size:12.6666669845581px">> Any other thoughts on whether this is a good idea to pursue? </span><div><span style="font-size:12.6666669845581px"><br></span></div><div><span style="font-size:12.6666669845581px">It probably is, but with some caveats. My main concern would be unnecessary code pollution. It's true that these warnings could be really useful. They might hint at actual issues in some cases (for example an unhandled error in the unused-result case). But suppressing them can also muddle the code. I rather 'fix' the cases that might hide real issues rather than suppress/silence noise just for its own sake.</span></div><div><span style="font-size:12.6666669845581px"><br></span></div><div><span style="font-size:12.6666669845581px">> One fear was that it might slow down compilation, but it doesn't actually seem to slow down "make clean && make" much at all for me.  I'll get some proper timing measurements.</span><br style="font-size:12.6666669845581px"></div><div><span style="font-size:12.6666669845581px"><br></span></div><div><span style="font-size:12.6666669845581px">Numbers are always a good reference. If it does slow down the build, it can go as a special 'pedantic' flag or something. Possibly it could be added such that (at least for now) it disables -Werror. This could be a good way to fix the errors without affecting the project.</span></div><div><span style="font-size:12.6666669845581px"><br></span></div><div><span style="font-size:12.6666669845581px"><br></span></div><div><span style="font-size:12.6666669845581px">So, with a special configure flag, this can be used by those who want to track-down potential issues and fix them without having to resolve every paranoid warning.</span></div><div><span style="font-size:12.6666669845581px">I think the benefits from this flag outweighs the cost of adding it.</span></div><div><span style="font-size:12.6666669845581px"><br></span></div><div><span style="font-size:12.6666669845581px">(Of course this is my </span><span style="font-size:12.6666669845581px">0.02 Swiss Franc's worth.)</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 15, 2015 at 7:47 AM, Luke Deller <span dir="ltr"><<a href="mailto:luke@deller.id.au" target="_blank">luke@deller.id.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I saw that gcc-4.8 introduced a new optimization level -Og which enables optimizations that do not interfere with debugging.<br>
<br>
Yesterday I floated the idea on IRC of using this with --enable-debug rather than -O0 if available, and some feedback was that it enables gcc to report extra warnings which would be a good thing.<br>
<br>
I tried it out and can see that it does indeed break the build if --enable-werror is enabled, eg:<br>
<br>
/home/deller/build/libo/vcl/<u></u>unx/glxtest.cxx: In function ‘void glxtest()’:<br>
/home/deller/build/libo/vcl/<u></u>unx/glxtest.cxx:236:44: error: ignoring return value of ‘ssize_t write(int, const void*, size_t)’, declared with attribute warn_unused_result [-Werror=unused-result]<br>
   write(write_end_of_the_pipe, buf, length);<br>
<br>
So I guess this means we couldn't incorporate -Og until all these new warnings are fixed right?<br>
<br>
Any other thoughts on whether this is a good idea to pursue?  One fear was that it might slow down compilation, but it doesn't actually seem to slow down "make clean && make" much at all for me.  I'll get some proper timing measurements.<br>
<br>
(A draft patch is attached to enable -Og if available)<br>
<br>
Regards,<br>
Luke.<br>
<br>_______________________________________________<br>
LibreOffice mailing list<br>
<a href="mailto:LibreOffice@lists.freedesktop.org">LibreOffice@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/libreoffice" target="_blank">http://lists.freedesktop.org/mailman/listinfo/libreoffice</a><br>
<br></blockquote></div><br></div>