<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - Patch to resolve aliasing issues in src/glsl/list.h"
href="https://bugs.freedesktop.org/show_bug.cgi?id=91320#c5">Comment # 5</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - Patch to resolve aliasing issues in src/glsl/list.h"
href="https://bugs.freedesktop.org/show_bug.cgi?id=91320">bug 91320</a>
from <span class="vcard"><a class="email" href="mailto:tschwinger@isonews2.com" title="tschw <tschwinger@isonews2.com>"> <span class="fn">tschw</span></a>
</span></b>
<pre>Thanks for the pointer.
There are external projects using the glsl-compiler code and it'd be great to
see a fixed upstream. We're running it in the browser via emscripten where
optimized builds are crucial to achieve reasonable speed and download size.
I don't really care about the debate on principles, whether the rest of Mesa
should obey strict aliasing rules or not. I neither care whose patch fixes the
issue.
That being said, there are some advantages over the changes proposed on the
mailing list:
o My first patch already gets the job done. It may not be "clean" in terms of
language lawery, but it is very much "to the point", as I actually traced the
assembly to spot the one assumption that breaks it all. The patch can very
easily be approved to be non-breaking.
o My second patch is a 1:1 translation of the introductory inline comment into
code. Why not share our cleverness with the compiler so it can act less stupid?
It's API compatible, but allows for a optional and gradual rewrite of code that
uses 'head', 'tail', and 'tail_pred' directly as a cleanup step. Other than
PATCHv3 from the mailing list, it does not increase the memory footprint of
'exec_list' - in fact, it's binary compatible. I also added #pragma pack(1) so
its binary format is portable to ABIs that prefer an alignment of more than one
address size (x32 may be one of these, but I'm not sure).</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the QA Contact for the bug.</li>
</ul>
</body>
</html>