![]() | |||||||||||||
Messages in this thread |
On Wed, Jan 02, 2002 at 08:54:08AM +0200, Momchil Velikov wrote: > >>>>> "Tom" == Tom Rini <trini@kernel.crashing.org> writes: > > Tom> On Wed, Jan 02, 2002 at 01:03:25AM +0200, Momchil Velikov wrote: > > >> The appended patch fix incorrect code, which interferes badly with > >> optimizations in GCC 3.0.4 and GCC 3.1. > >> > >> The GCC tries to replace the strcpy from a constant string source with > >> a memcpy, since the length is know at compile time. > > Tom> Check the linuxppc-dev archives, but this has been discussed before, and > Tom> it came down to a few things. > > Well, you may discuss it again, but this time after actually reading > the C standard: > > "6.3.6 Additive operators > ... > > 9 Unless both the pointer operand and the result point to > elements of the same array object, or the pointer operand > points one past the last element of an array object and the > result points to an element of the same array object, the > behavior is undefined if the result is used as an operand of a > unary * operator that is actually evaluated." > > Tom> 1) gcc shouldn't be making this optimization, and Paulus (who wrote the > Tom> code) disliked this new feature. > > Why gcc shouldn't be making some optimization. Because a particular > person doesn't like it or ? What kind of statement is that anyway ? Well, Paulus wrote 'strcpy' not 'memcpy', so why does gcc get to assume it's safe to change it? In this case it's certainly not. > Tom> As a subnote, what you sent was sent > Tom> to Linus with a comment about working around a gcc-3.0 bug/feature, and > Tom> was rejected because of this. > > It is not a workaround, it is a fix to an invalid code, which gets > triggered by particular optimization. By a particular optimization that's not present before gcc-3.0, and happens to break things under some conditions, as you've seen. > Tom> 2) We could modify the RELOC macro, and not have this problem. The > Tom> patch was posted, but not acted upon. > > Although all uses of the RELOC macro violate the standard, this kind > of pointer arithmetic is far too common and usually produces the > expected behavior, thus it make sense to optimize the cases where ut > breaks And for the case it breaks? -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2005-03-22 12:15 [W:1.147 / U:0.510 seconds] ©2003-2008 Jasper Spaans | |||||||||||||