This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: [PATCH] C undefined behavior fix
- From: Paul Mackerras <paulus at samba dot org>
- To: Bernard Dautrevaux <Dautrevaux at microprocess dot com>
- Cc: 'Tom Rini' <trini at kernel dot crashing dot org>,Momchil Velikov <velco at fadata dot bg>, linux-kernel at vger dot kernel dot org,gcc at gcc dot gnu dot org, linuxppc-dev at lists dot linuxppc dot org
- Date: Thu, 3 Jan 2002 10:02:12 +1100 (EST)
- Subject: RE: [PATCH] C undefined behavior fix
- References: <17B78BDF120BD411B70100500422FC6309E3ED@IIS000>
- Reply-to: paulus at samba dot org
Bernard Dautrevaux writes:
> > 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.