This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2] handle sem_t with ILP32 and __HAVE_64B_ATOMICS
- From: Chris Metcalf <cmetcalf at ezchip dot com>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: "H.J. Lu" <hjl dot tools at gmail dot com>, Andreas Schwab <schwab at suse dot de>, Carlos O'Donell <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, David Miller <davem at davemloft dot net>, Richard Henderson <rth at redhat dot com>, Mike Frysinger <vapier at gentoo dot org>, "Joseph S. Myers" <joseph at codesourcery dot com>, Kaz Kojima <kkojima at rr dot iij4u dot or dot jp>, Thomas Schwinge <thomas at codesourcery dot com>, Marcus Shawcroft <marcus dot shawcroft at linaro dot org>, Chung-Lin Tang <chunglin_tang at mentor dot com>, Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>, Andreas Krebbel <krebbel at linux dot vnet dot ibm dot com>
- Date: Wed, 28 Jan 2015 12:45:23 -0500
- Subject: Re: [PATCH v2] handle sem_t with ILP32 and __HAVE_64B_ATOMICS
- Authentication-results: sourceware.org; auth=none
- Authentication-results: linux.vnet.ibm.com; dkim=none (message not signed) header.d=none;linux.vnet.ibm.com; dmarc=none action=none header.from=ezchip.com;
- References: <54C2BDD7 dot 7000304 at redhat dot com> <54C3B6D5 dot 3090308 at ezchip dot com> <1422119595 dot 29655 dot 42 dot camel at triegel dot csb> <54C5094A dot 8060300 at ezchip dot com> <54C51D94 dot 6030007 at ezchip dot com> <1422276280 dot 29655 dot 91 dot camel at triegel dot csb> <54C6A1DD dot 4020004 at ezchip dot com> <1422305739 dot 29655 dot 144 dot camel at triegel dot csb> <87a915b170 dot fsf at igel dot home> <54C6CF4B dot 1020600 at ezchip dot com> <CAMe9rOqAx=6Jjjj4V7Rb3o+jfz+ibOZxYy1x3AWfRrLjSBfauA at mail dot gmail dot com> <54C8009A dot 2000709 at ezchip dot com> <1422435851 dot 29655 dot 179 dot camel at triegel dot csb>
On 1/28/2015 4:04 AM, Torvald Riegel wrote:
I thing using to_new_sem in all cases is cleaner, but my comment on the
union wasn't quite right. I agree the union should give the proper
alignment, because it includes struct new_sem directly, so will pick up
the uint64_t alignment of it.
I have reverted the code to just using the union, which on balance I
think I slightly prefer. I think mentioning to_new_sem() in the comment
as part of the explanation is a sufficient way to deal with this.
+ /* Create the initial file content. The union forces the
+ alignment of initsem to be at least as much as newsem.
+ When to_new_sem() provides for varying internal alignment,
+ this expression makes the alignment zero, and matches the
+ eventual alignment when the union is copied to the start of
+ an mmap'ed file page. */
--
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com