> > 1) gcc shouldn't be making this optimization, and Paulus (who
> > wrote the
> > code) disliked this new feature.
>
> Why? If memcpy can then be expanded in line, and the string is short, this
> can be a *huge* win...
Show me a place in the kernel which is performance-critical where we
do strcpy(p, "string"). I can't think of one. The stuff in prom.c
isn't performance-critical.
> I think we MUST modify the RELOC macro. Currently the code has an undefined
> meaning WRT th eC standard, so is allowed to do almost anything from working
> as expected (quite bad in fact: it may suddenly fail when sth is modified
> elsewhere), to triggering the 3rd World War :-)
As I said in another email, if the gcc maintainers want to change gcc
so that pointer arithmetic can do anything other than an ordinary 2's
complement addition operation, then we will stop using gcc.
Paul.
-
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/