Build fails with strict-aliasing violations.

[eli-schwartz]

I tried to compile with LTO: -flto=4 -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing

The -Werror=* flags are important to detect cases where the compiler can try to optimize based on assuming UB cannot happen, and miscompile code that has UB in it. strict-aliasing issues are always bad but LTO can make them even worse.

I got this error:

x86_64-pc-linux-gnu-g++ -march=native -fstack-protector-all -O2 -pipe -fdiagnostics-color=always -frecord-gcc-switches -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-clash-protection -flto=4 -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing  -Wformat -Werror=format-security -Wno-write-strings -Wno-unused-result  -I. -MD -MF dp_lib/evaluate_dirichlet.deps -c -o dp_lib/evaluate_dirichlet.o dp_lib/evaluate_dirichlet.c
In file included from ./io_lib_header.h:33,
                 from dp_lib/evaluate_dirichlet.c:33:
./io_lib/tree_util.h:30:1: warning: ‘typedef’ was ignored in this declaration
   30 | typedef struct ALNcol
      | ^~~~~~~
dp_lib/evaluate_dirichlet.c: In function ‘double sin_pi(double)’:
dp_lib/evaluate_dirichlet.c:499:14: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
  499 |         ix=(*(long long *)&x)>>32;
      |              ^~~~~~~~~~~~~~~
dp_lib/evaluate_dirichlet.c:519:29: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
  519 |                         n=(*(long long *)&x);
      |                             ^~~~~~~~~~~~~~~
dp_lib/evaluate_dirichlet.c: In function ‘double lgamma_r(double, int*)’:
dp_lib/evaluate_dirichlet.c:548:14: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
  548 |         hx=(*(long long *)&x)>>32;
      |              ^~~~~~~~~~~~~~~
dp_lib/evaluate_dirichlet.c:549:14: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
  549 |         lx=(*(long long *)&x);
      |              ^~~~~~~~~~~~~~~
cc1plus: some warnings being treated as errors
make: *** [makefile:9: dp_lib/evaluate_dirichlet.o] Error 1

Downstream report: https://bugs.gentoo.org/862327 -- note that I updated to 13.46.0 and still got the same issue.
Full build log: build.log

[cnotred]

Hi Eli, Thanks for this update. I happened to have my hands in the code and  I have now fixed the code and pushed it in the dev branch, we will merge on the master ASAP Now a bit of background for all the clanking things around. What you just stumbled upon  is really is legacy code, that made its way in T-Coffee a long time ago (in the 90s I think) and is not really used any more. Much more than a production tool, T-Coffee is a framework through which many things have been tested over time, and can be rapidly re-tested when needed. These things are sometimes implemented in a sub-optimal way, or a deprecated way. I do not think the dirichelet mixtures are used any more in any default mode. Also, about 10 years ago, we moved T-Coffee from C to C++, and this created other issues like this one. Thanks a lot for the feedback, Cedric

On 20/3/24 21:07, Eli Schwartz wrote: I tried to compile with LTO: |-flto=4 -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing| The -Werror=* flags are important to detect cases where the compiler can try to optimize based on assuming UB cannot happen, and miscompile code that has UB in it. strict-aliasing issues are always bad but LTO can make them even worse. I got this error: |x86_64-pc-linux-gnu-g++ -march=native -fstack-protector-all -O2 -pipe -fdiagnostics-color=always -frecord-gcc-switches -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-clash-protection -flto=4 -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing -Wformat -Werror=format-security -Wno-write-strings -Wno-unused-result -I. -MD -MF dp_lib/evaluate_dirichlet.deps -c -o dp_lib/evaluate_dirichlet.o dp_lib/evaluate_dirichlet.c In file included from ./io_lib_header.h:33, from dp_lib/evaluate_dirichlet.c:33: ./io_lib/tree_util.h:30:1: warning: ‘typedef’ was ignored in this declaration 30 | typedef struct ALNcol | ^~~~~~~ dp_lib/evaluate_dirichlet.c: In function ‘double sin_pi(double)’: dp_lib/evaluate_dirichlet.c:499:14: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] 499 | ix=(*(long long *)&x)>>32; | ^~~~~~~~~~~~~~~ dp_lib/evaluate_dirichlet.c:519:29: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] 519 | n=(*(long long *)&x); | ^~~~~~~~~~~~~~~ dp_lib/evaluate_dirichlet.c: In function ‘double lgamma_r(double, int*)’: dp_lib/evaluate_dirichlet.c:548:14: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] 548 | hx=(*(long long *)&x)>>32; | ^~~~~~~~~~~~~~~ dp_lib/evaluate_dirichlet.c:549:14: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] 549 | lx=(*(long long *)&x); | ^~~~~~~~~~~~~~~ cc1plus: some warnings being treated as errors make: *** [makefile:9: dp_lib/evaluate_dirichlet.o] Error 1 | Downstream report: https://bugs.gentoo.org/862327 <https://urldefense.com/v3/__https://bugs.gentoo.org/862327__;!!D9dNQwwGXtA!STbH52DCWPOr93rtrxAyVA3QRV065WwN6ztKOHFRBN_SYl6jtcAbo7IEjPaFKV860OrngyIaKnwgLOIIOp7UriOXoc-1$> -- note that I updated to 13.46.0 and still got the same issue. Full build log: build.log <https://urldefense.com/v3/__https://github.com/cbcrg/tcoffee/files/14672068/build.log__;!!D9dNQwwGXtA!STbH52DCWPOr93rtrxAyVA3QRV065WwN6ztKOHFRBN_SYl6jtcAbo7IEjPaFKV860OrngyIaKnwgLOIIOp7Urpeyq95k$> — Reply to this email directly, view it on GitHub <https://urldefense.com/v3/__https://github.com/cbcrg/tcoffee/issues/60__;!!D9dNQwwGXtA!STbH52DCWPOr93rtrxAyVA3QRV065WwN6ztKOHFRBN_SYl6jtcAbo7IEjPaFKV860OrngyIaKnwgLOIIOp7Urlbid4sG$>, or unsubscribe <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ABML3KNLXZLHZJTQIUV3YGDYZHUANAVCNFSM6AAAAABFAFDKOWVHI2DSMVQWIX3LMV43ASLTON2WKOZSGE4TQNBWGMYDKNY__;!!D9dNQwwGXtA!STbH52DCWPOr93rtrxAyVA3QRV065WwN6ztKOHFRBN_SYl6jtcAbo7IEjPaFKV860OrngyIaKnwgLOIIOp7Urm6bEGeA$>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

--------------VsUNPWw40itcWRv2Xp6HM8gq Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit <!DOCTYPE html><html><head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body> <p>Hi Eli,</p> <p>Thanks for this update. I happened to have my hands in the code and&nbsp; I have now fixed the code and pushed it in the dev branch, we will merge on the master ASAP <br> </p> <p>Now a bit of background for all the clanking things around. What you just stumbled upon&nbsp; is really is legacy code, that made its way in T-Coffee a long time ago (in the 90s I think) and is not really used any more. Much more than a production tool, T-Coffee is a framework through which many things have been tested over time, and can be rapidly re-tested when needed. These things are sometimes implemented in a sub-optimal way, or a deprecated way. I do not think the dirichelet mixtures are used any more in any default mode. <br> </p> <p>Also, about 10 years ago, we moved T-Coffee from C to C++, and this created other issues like this one. <br> </p> <p>Thanks a lot for the feedback,</p> <p>Cedric <br> </p> <div class="moz-cite-prefix">On 20/3/24 21:07, Eli Schwartz wrote:<br> </div> <blockquote type="cite" ***@***.***"> <p dir="auto">I tried to compile with LTO: <code class="notranslate">-flto=4 -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing</code></p> <p dir="auto">The -Werror=* flags are important to detect cases where the compiler can try to optimize based on assuming UB cannot happen, and miscompile code that has UB in it. strict-aliasing issues are always bad but LTO can make them even worse.</p> <p dir="auto">I got this error:</p> <pre class="notranslate"><code class="notranslate">x86_64-pc-linux-gnu-g++ -march=native -fstack-protector-all -O2 -pipe -fdiagnostics-color=always -frecord-gcc-switches -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-clash-protection -flto=4 -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing -Wformat -Werror=format-security -Wno-write-strings -Wno-unused-result -I. -MD -MF dp_lib/evaluate_dirichlet.deps -c -o dp_lib/evaluate_dirichlet.o dp_lib/evaluate_dirichlet.c In file included from ./io_lib_header.h:33, from dp_lib/evaluate_dirichlet.c:33: ./io_lib/tree_util.h:30:1: warning: ‘typedef’ was ignored in this declaration 30 | typedef struct ALNcol | ^~~~~~~ dp_lib/evaluate_dirichlet.c: In function ‘double sin_pi(double)’: dp_lib/evaluate_dirichlet.c:499:14: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] 499 | ix=(*(long long *)&amp;x)&gt;&gt;32; | ^~~~~~~~~~~~~~~ dp_lib/evaluate_dirichlet.c:519:29: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] 519 | n=(*(long long *)&amp;x); | ^~~~~~~~~~~~~~~ dp_lib/evaluate_dirichlet.c: In function ‘double lgamma_r(double, int*)’: dp_lib/evaluate_dirichlet.c:548:14: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] 548 | hx=(*(long long *)&amp;x)&gt;&gt;32; | ^~~~~~~~~~~~~~~ dp_lib/evaluate_dirichlet.c:549:14: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] 549 | lx=(*(long long *)&amp;x); | ^~~~~~~~~~~~~~~ cc1plus: some warnings being treated as errors make: *** [makefile:9: dp_lib/evaluate_dirichlet.o] Error 1 </code></pre> <p dir="auto">Downstream report: <a href="https://urldefense.com/v3/__https://bugs.gentoo.org/862327__;!!D9dNQwwGXtA!STbH52DCWPOr93rtrxAyVA3QRV065WwN6ztKOHFRBN_SYl6jtcAbo7IEjPaFKV860OrngyIaKnwgLOIIOp7UriOXoc-1$" rel="nofollow" moz-do-not-send="true">https://bugs.gentoo.org/862327</a> -- note that I updated to 13.46.0 and still got the same issue.<br> Full build log: <a href="https://urldefense.com/v3/__https://github.com/cbcrg/tcoffee/files/14672068/build.log__;!!D9dNQwwGXtA!STbH52DCWPOr93rtrxAyVA3QRV065WwN6ztKOHFRBN_SYl6jtcAbo7IEjPaFKV860OrngyIaKnwgLOIIOp7Urpeyq95k$" moz-do-not-send="true">build.log</a></p> <p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br> Reply to this email directly, <a href="https://urldefense.com/v3/__https://github.com/cbcrg/tcoffee/issues/60__;!!D9dNQwwGXtA!STbH52DCWPOr93rtrxAyVA3QRV065WwN6ztKOHFRBN_SYl6jtcAbo7IEjPaFKV860OrngyIaKnwgLOIIOp7Urlbid4sG$" moz-do-not-send="true">view it on GitHub</a>, or <a href="https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ABML3KNLXZLHZJTQIUV3YGDYZHUANAVCNFSM6AAAAABFAFDKOWVHI2DSMVQWIX3LMV43ASLTON2WKOZSGE4TQNBWGMYDKNY__;!!D9dNQwwGXtA!STbH52DCWPOr93rtrxAyVA3QRV065WwN6ztKOHFRBN_SYl6jtcAbo7IEjPaFKV860OrngyIaKnwgLOIIOp7Urm6bEGeA$" moz-do-not-send="true">unsubscribe</a>.<br> You are receiving this because you are subscribed to this thread.<img src="https://github.com/notifications/beacon/ABML3KLXFKLAI7OXDD5E6SLYZHUANA5CNFSM6AAAAABFAFDKOWWGG33NNVSW45C7OR4XAZNFJFZXG5LFVJRW63LNMVXHIX3JMTHIGCPCKE.gif" alt="" moz-do-not-send="true" width="1" height="1"><span style="color: transparent; font-size: 0; display: none; visibility: hidden; overflow: hidden; opacity: 0; width: 0; height: 0; max-width: 0; max-height: 0; mso-hide: all">Message ID: <span>&lt;cbcrg/tcoffee/issues/60</span><span>@</span><span>github</span><span>.</span><span>com&gt;</span></span></p> <script type="application/ld+json">[ { ***@***.***": "http://schema.org", ***@***.***": "EmailMessage", "potentialAction": { ***@***.***": "ViewAction", "target": "#60", "url": "#60", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { ***@***.***": "Organization", "name": "GitHub", "url": "https://github.com" } } ]</script> </blockquote> </body> </html>

…

--------------VsUNPWw40itcWRv2Xp6HM8gq--

[eli-schwartz]

Excellent, thank you for the speedy update.

Now a bit of background for all the clanking things around. What you just stumbled upon is really is legacy code, that made its way in T-Coffee a long time ago (in the 90s I think) and is not really used any more. Much more than a production tool, T-Coffee is a framework through which many things have been tested over time, and can be rapidly re-tested when needed. These things are sometimes implemented in a sub-optimal way, or a deprecated way. I do not think the dirichelet mixtures are used any more in any default mode.

Yup, makes sense. :) Most of the issues we've been uncovering (Gentoo is trying to get all packages to be LTO-clean, since it's something a lot of people want to add to their default *FLAGS, and that involves reporting a lot of bugs) come from legacy code or legacy portions of a codebase. Sadly, it has a tendency to break any code it gets linked with even if it never gets used...

[JoseEspinosa]

Fixed in #61