{"id":1174,"date":"2022-08-30T15:13:37","date_gmt":"2022-08-30T15:13:37","guid":{"rendered":"https:\/\/unknownerror.org\/index.php\/2013\/11\/09\/gcc-4-4-4-optimization-error-only-with-o1-or-o2no-strict-aliasing-collection-of-common-programming-errors\/"},"modified":"2022-08-30T15:13:37","modified_gmt":"2022-08-30T15:13:37","slug":"gcc-4-4-4-optimization-error-only-with-o1-or-o2no-strict-aliasing-collection-of-common-programming-errors","status":"publish","type":"post","link":"https:\/\/unknownerror.org\/index.php\/2022\/08\/30\/gcc-4-4-4-optimization-error-only-with-o1-or-o2no-strict-aliasing-collection-of-common-programming-errors\/","title":{"rendered":"gcc 4.4.4 optimization error only with O1 OR O2+no-strict-aliasing-Collection of common programming errors"},"content":{"rendered":"<p><b>Close:<\/b> The problem was the use of a pointer to a stack variable that had gone out of scope. Nothing to do with optimization. Pity that valgrind can&#8217;t find stack errors&#8230;<\/p>\n<p>I have a segfault that appears only when enabling -O1 level optimization in gcc 4.4.4 (CentOS 5.5). All other optimization levels (0,2,3,s) are fine. I haven&#8217;t managed to create a reduced test case for it yet, but it appears to be related to an array offset calculation causing the stack to be overwritten.<\/p>\n<p>If I enable -O1 and disable all optimizations that have a flag (http:\/\/gcc.gnu.org\/onlinedocs\/gcc\/Optimize-Options.html) the bug still occurs.<\/p>\n<p>If I use -O2 (or any other level) there is no problem. If I use O2 and disable strict-aliasing with -fno-strict-aliasing then the segfault returns.<\/p>\n<p><b>Edit:<\/b> If I add -fstack-protector-all to the build flags (either O1 or O2 -fno-strict-aliasing) the segfault disappears.<\/p>\n<p>So it appears to be caused by an optimization that happens by default in O1 that is disabled by strict-aliasing.<\/p>\n<p>I suspect that this is a compiler bug (but without a reduced testcase I can&#8217;t prove it). This is a production server that needs a quick turn around. The normal optimization level is O1 and I&#8217;m loathe to just change it to O2 as it seems that the fix might be more dangerous than the original problem.<\/p>\n<p>I would really appreciate some suggestions. Currently I&#8217;m thinking to try compiling gcc 4.4.6 and seeing if that fixes it. However not knowing for sure what is causing the problem is a little worrying.<\/p>\n<p><b>Edit:<\/b> the server is compiled with -Wall -Werror (and a few others). It runs without error in valgrind (valgrind checks heap accesses and this appears to be a stack related error).<\/p>\n<ol>\n<li>\n<p>Often, compiler optimizations can expose invalid or undefined behavior in source code, that you are lucky to get to work otherwise. A few things I would try:<\/p>\n<ol>\n<li>compiling with <code>-Wall -Wextra<\/code><\/li>\n<li>running under <code>valgrind<\/code> to see if you can get more of a hint of where the error is<\/li>\n<li>finding that minimum testcase!<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n<p id=\"rop\"><small>Originally posted 2013-11-09 23:35:44. <\/small><\/p>","protected":false},"excerpt":{"rendered":"<p>Close: The problem was the use of a pointer to a stack variable that had gone out of scope. Nothing to do with optimization. Pity that valgrind can&#8217;t find stack errors&#8230; I have a segfault that appears only when enabling -O1 level optimization in gcc 4.4.4 (CentOS 5.5). All other optimization levels (0,2,3,s) are fine. [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1174","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/posts\/1174","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/comments?post=1174"}],"version-history":[{"count":0,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/posts\/1174\/revisions"}],"wp:attachment":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/media?parent=1174"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/categories?post=1174"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/tags?post=1174"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}