|
View:
New views
10 Messages
—
Rating Filter:
Alert me
|
|
|
[PATCH] Fix aliasing violation.src/netif/etharp.c: In function ‘etharp_arp_input’:
src/netif/etharp.c:708: warning: dereferencing type-punned pointer will break strict-aliasing rules Index: src/netif/etharp.c =================================================================== RCS file: /sources/lwip/lwip/src/netif/etharp.c,v retrieving revision 1.148 diff -u -p -r1.148 etharp.c --- src/netif/etharp.c 19 Jun 2008 16:40:59 -0000 1.148 +++ src/netif/etharp.c 3 Oct 2008 09:39:55 -0000 @@ -705,7 +705,7 @@ etharp_arp_input(struct netif *netif, st hdr->opcode = htons(ARP_REPLY); hdr->dipaddr = hdr->sipaddr; - hdr->sipaddr = *(struct ip_addr2 *)&netif->ip_addr; + memcpy(&hdr->sipaddr, &netif->ip_addr, sizeof(hdr->sipaddr)); LWIP_ASSERT("netif->hwaddr_len must be the same as ETHARP_HWADDR_LEN for etharp!", (netif->hwaddr_len == ETHARP_HWADDR_LEN)); -- David Woodhouse Open Source Technology Centre David.Woodhouse@... Intel Corporation _______________________________________________ lwip-devel mailing list lwip-devel@... http://lists.nongnu.org/mailman/listinfo/lwip-devel |
|
|
RE: [PATCH] Fix aliasing violation.But we should use SMEMCPY. I use a macro that converts this to a series of inline load/stores.
Bill > -----Original Message----- > From: lwip-devel-bounces+bauerbach=arrayonline.com@... > [mailto:lwip-devel-bounces+bauerbach=arrayonline.com@...] On > Behalf Of David Woodhouse > Sent: Friday, October 03, 2008 5:43 AM > To: lwip-devel > Subject: [lwip-devel] [PATCH] Fix aliasing violation. > > src/netif/etharp.c: In function ‘etharp_arp_input’: > src/netif/etharp.c:708: warning: dereferencing type-punned pointer will > break strict-aliasing rules > > Index: src/netif/etharp.c > =================================================================== > RCS file: /sources/lwip/lwip/src/netif/etharp.c,v > retrieving revision 1.148 > diff -u -p -r1.148 etharp.c > --- src/netif/etharp.c 19 Jun 2008 16:40:59 -0000 1.148 > +++ src/netif/etharp.c 3 Oct 2008 09:39:55 -0000 > @@ -705,7 +705,7 @@ etharp_arp_input(struct netif *netif, st > hdr->opcode = htons(ARP_REPLY); > > hdr->dipaddr = hdr->sipaddr; > - hdr->sipaddr = *(struct ip_addr2 *)&netif->ip_addr; > + memcpy(&hdr->sipaddr, &netif->ip_addr, sizeof(hdr->sipaddr)); > > LWIP_ASSERT("netif->hwaddr_len must be the same as > ETHARP_HWADDR_LEN for etharp!", > (netif->hwaddr_len == ETHARP_HWADDR_LEN)); > > -- > David Woodhouse Open Source Technology > Centre > David.Woodhouse@... Intel > Corporation > > > > _______________________________________________ > lwip-devel mailing list > lwip-devel@... > http://lists.nongnu.org/mailman/listinfo/lwip-devel _______________________________________________ lwip-devel mailing list lwip-devel@... http://lists.nongnu.org/mailman/listinfo/lwip-devel |
|
|
RE: [PATCH] Fix aliasing violation.On Fri, 2008-10-03 at 09:39 -0400, bill wrote:
> But we should use SMEMCPY. I use a macro that converts this to a > series of inline load/stores. Isn't that the compiler's job? -- David Woodhouse Open Source Technology Centre David.Woodhouse@... Intel Corporation _______________________________________________ lwip-devel mailing list lwip-devel@... http://lists.nongnu.org/mailman/listinfo/lwip-devel |
|
|
Re: [PATCH] Fix aliasing violation.David Woodhouse wrote:
> On Fri, 2008-10-03 at 09:39 -0400, bill wrote: >> But we should use SMEMCPY. I use a macro that converts this to a >> series of inline load/stores. > > Isn't that the compiler's job? Not all compilers do it. GCC does, and I expect that's what you're using. For GCC, SMEMCPY can remain as memcpy. Jifl -- eCosCentric Limited http://www.eCosCentric.com/ The eCos experts Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No 4422071. ------["Si fractum non sit, noli id reficere"]------ Opinions==mine _______________________________________________ lwip-devel mailing list lwip-devel@... http://lists.nongnu.org/mailman/listinfo/lwip-devel |
|
|
Re: [PATCH] Fix aliasing violation.David Woodhouse wrote:
>> But we should use SMEMCPY. I use a macro that converts this to a >> series of inline load/stores. >> > Isn't that the compiler's job? > In 1.3.0, we converted all calls to 'memcpy' to either 'MEMCPY' or 'SMEMCPY' (s for short). The goal is optimization: SMEMCPY is defined to memcpy (which the compiler may inline e.g. if size is known at compile time and small); whil MEMCPY can be overridden to provide a better copy mechanism (on my platform, for example, copying non-aligned data can be solved much better when loading full words and shifting in registers). Therfore, using 'memcpy' directly should be avoided: when you know your compiler can't optimize it, you can redefine SMEMCPY to inlining yourself. Simon _______________________________________________ lwip-devel mailing list lwip-devel@... http://lists.nongnu.org/mailman/listinfo/lwip-devel |
|
|
Re: [PATCH] Fix aliasing violation.Jonathan Larmour wrote:
> David Woodhouse wrote: >> On Fri, 2008-10-03 at 09:39 -0400, bill wrote: >>> But we should use SMEMCPY. I use a macro that converts this to a >>> series of inline load/stores. >> Isn't that the compiler's job? > > Not all compilers do it. GCC does, and I expect that's what you're using. > For GCC, SMEMCPY can remain as memcpy. Oh, and I've made the changes (as SMEMCPY), thanks. Jifl -- eCosCentric Limited http://www.eCosCentric.com/ The eCos experts Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No 4422071. ------["Si fractum non sit, noli id reficere"]------ Opinions==mine _______________________________________________ lwip-devel mailing list lwip-devel@... http://lists.nongnu.org/mailman/listinfo/lwip-devel |
|
|
Re: [PATCH] Fix aliasing violation.On Fri, 2008-10-03 at 16:43 +0200, goldsimon@... wrote:
> In 1.3.0, we converted all calls to 'memcpy' to either 'MEMCPY' or > 'SMEMCPY' (s for short). The goal is optimization: SMEMCPY is defined to > memcpy (which the compiler may inline e.g. if size is known at compile > time and small); whil MEMCPY can be overridden to provide a better copy > mechanism (on my platform, for example, copying non-aligned data can be > solved much better when loading full words and shifting in registers). > > Therfore, using 'memcpy' directly should be avoided: when you know your > compiler can't optimize it, you can redefine SMEMCPY to inlining yourself. I'm inclined to suggest that the correct answer in that case is to _fix_ the compiler, not work around it. But OK... Index: src/netif/etharp.c =================================================================== RCS file: /sources/lwip/lwip/src/netif/etharp.c,v retrieving revision 1.148 diff -u -p -r1.148 etharp.c --- src/netif/etharp.c 19 Jun 2008 16:40:59 -0000 1.148 +++ src/netif/etharp.c 3 Oct 2008 14:49:57 -0000 @@ -705,7 +705,7 @@ etharp_arp_input(struct netif *netif, st hdr->opcode = htons(ARP_REPLY); hdr->dipaddr = hdr->sipaddr; - hdr->sipaddr = *(struct ip_addr2 *)&netif->ip_addr; + SMEMCPY(&hdr->sipaddr, &netif->ip_addr, sizeof(hdr->sipaddr)); LWIP_ASSERT("netif->hwaddr_len must be the same as ETHARP_HWADDR_LEN for etharp!", (netif->hwaddr_len == ETHARP_HWADDR_LEN)); -- David Woodhouse Open Source Technology Centre David.Woodhouse@... Intel Corporation _______________________________________________ lwip-devel mailing list lwip-devel@... http://lists.nongnu.org/mailman/listinfo/lwip-devel |
|
|
RE: [PATCH] Fix aliasing violation.When it calls a slow memcpy runtime library routine you get what you get.
If all compilers did this, SMEMCPY wouldn't have been defined in lwIP. > -----Original Message----- > From: lwip-devel-bounces+bauerbach=arrayonline.com@... > [mailto:lwip-devel-bounces+bauerbach=arrayonline.com@...] On > Behalf Of David Woodhouse > Sent: Friday, October 03, 2008 9:49 AM > To: lwip-devel > Subject: RE: [lwip-devel] [PATCH] Fix aliasing violation. > > On Fri, 2008-10-03 at 09:39 -0400, bill wrote: > > But we should use SMEMCPY. I use a macro that converts this to a > > series of inline load/stores. > > Isn't that the compiler's job? > > -- > David Woodhouse Open Source Technology > Centre > David.Woodhouse@... Intel > Corporation > > > > _______________________________________________ > lwip-devel mailing list > lwip-devel@... > http://lists.nongnu.org/mailman/listinfo/lwip-devel _______________________________________________ lwip-devel mailing list lwip-devel@... http://lists.nongnu.org/mailman/listinfo/lwip-devel |
|
|
Re: [PATCH] Fix aliasing violation.David Woodhouse wrote:
> On Fri, 2008-10-03 at 16:43 +0200, goldsimon@... wrote: > >> In 1.3.0, we converted all calls to 'memcpy' to either 'MEMCPY' or >> 'SMEMCPY' (s for short). The goal is optimization: SMEMCPY is defined to >> memcpy (which the compiler may inline e.g. if size is known at compile >> time and small); whil MEMCPY can be overridden to provide a better copy >> mechanism (on my platform, for example, copying non-aligned data can be >> solved much better when loading full words and shifting in registers). >> >> Therfore, using 'memcpy' directly should be avoided: when you know your >> compiler can't optimize it, you can redefine SMEMCPY to inlining yourself. >> > > I'm inclined to suggest that the correct answer in that case is to _fix_ > the compiler, not work around it. But OK... question (an optimized memcpy is much bigger than a simple for-loop that does a byte copy). If the compiler decides not to inline, it would call 'memcpy'. And since on most platforms, memcpy is a generic implementation of a C-library which is NOT optimized for the actual hardware, an assembly-routine can be much faster. SMEMCPY was chosen to explicitly state this is a short memcpy and we (lwIP developers) don't want to call the fast routine for it since the compiler might optimize it. Simon _______________________________________________ lwip-devel mailing list lwip-devel@... http://lists.nongnu.org/mailman/listinfo/lwip-devel |
|
|
Re: [PATCH] Fix aliasing violation.anyone could tell me how to use the patch file in cygwin?
|
| Free embeddable forum powered by Nabble | Forum Help |