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/
This archive was generated by hypermail 2b29 : Mon Jan 07 2002 - 21:00:17 EST