[Bug 91320] The cure for all kinds of weirdness caused by list defects in release builds

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Mon Jul 13 08:17:01 PDT 2015


--- Comment #2 from tschw <tschwinger at isonews2.com> ---
`configure.ac` at lines 282 and 329 reads:

    # Work around aliasing bugs - developers should comment this out
    CFLAGS="$CFLAGS -fno-strict-aliasing"

This workaround may keep the effects from showing - and also prevents lots of
useful compiler optimizations. These lines will need to be commented out before
recreating the buildfiles for reproducing the problems (I encountered them in a
derived codebase).

An alternative, more thorough solution to my first patch would be telling the
compiler what's really going on: It can be done using union types - as in the
second patch. This approach results in ~4K less executable size.

In this case, it even works without volatile qualifiers for GCC (tested with
version 4.8.3, Gentoo build). I kept the previous members because a lot of the
codebase relies on their presence. I also kept the volatile qualifiers, since
the generated code was smallest and did not run measurably slower.
The patch optimistically removes the constructor of 'exec_node' (what's a
node's life without a list?) and I didn't experience problems. Since types in
unions may not have constructors, the recipe to keep that constructor would be
a separate struct 'exec_node_c' (C-style POD type, without constructor) that
'exec_node' (with constructor) inherits from.

Both variants work with "-O6 -fstrict-aliasing".

You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20150713/9a21646a/attachment-0001.html>

More information about the intel-3d-bugs mailing list