Date: Tue, 18 Sep 2012 20:14:52 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Jilles Tjoelker <jilles@stack.nl> Cc: arch@freebsd.org Subject: Re: Aliasing issue with TAILQ on ppc64 ? Message-ID: <23178.1347999292@critter.freebsd.dk> In-Reply-To: Your message of "Tue, 18 Sep 2012 21:53:53 %2B0200." <20120918195353.GA56160@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20120918195353.GA56160@stack.nl>, Jilles Tjoelker writes: >A dirty workaround is -fno-strict-aliasing but this reduces optimization >opportunities all over the code. Even if it works, I don't think we should mandate that for all code using <sys/queue.h> >An obvious fix is to make TAILQ_ENTRY and TAILQ_HEAD the same type (and >not just structurally identical) or to add an intermediate struct which >is the same between them. I've tried something along those lines several times, but I have so far not been able to make it work, without a major change to the TAILQ_* api, which I am not prepared to push. >However, I think the TAILQ_LAST and TAILQ_PREV macros are better >rewritten using __containerof, I really don't think that is an improvement, I'd prefer a typesafe standard C solution which static checker tools like Coverity and FlexeLint can see how works. I suspect it would be enough to make the tqh_last and tqe_prev pointer be volatile pointers to struct type pointers, but absent a deeper understanding of whats actually going on I can't tell if that would be a proper solution or merely obfuscation and workaround. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?23178.1347999292>