Date: Wed, 23 Jul 2003 18:15:11 +0200 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Paul Richards <paul@freebsd-services.com> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern init_main.c kern_malloc.c md5c.c subr_autoconf.c subr_mbuf.c subr_prf.c tty_subr.c vfs_cluster.c vfs_subr.c Message-ID: <23600.1058976911@critter.freebsd.dk> In-Reply-To: Your message of "23 Jul 2003 16:34:20 BST." <1058974459.31173.17.camel@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <1058974459.31173.17.camel@localhost>, Paul Richards writes: >On Wed, 2003-07-23 at 06:40, Poul-Henning Kamp wrote: > >> >> The ones I took out yesterday are the onces which GCC had ignored and >> which therefore ipso facto were "unproven" _and_ added significant >> amounts of object code if respected. > >That's just untrue. The inline you removed from lnc had *ZERO* impact on >code size. It would _really_ help if you would bother to listen to what people tell you about how the new GCC warnings work. GCC rejects inlining things above a certain limit, and while the limit is arguably measured in "elbonian mud gallons", it is nontheless something we have to address: If we ever want to be able to use those warnings to tell us when something is amiss, we need to set the limit reasonably. The two inlines in the lnc driver were among the largest in the system. If we had set the GCC limit to allow those inlines, we would never get a warning when inline mistakes were made. And when you consider that that the inlines in lnc were purely ornamental, and that GCC previously had silently refused the inline request, you will realize that by removing them, I merely preserved the status-quo. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?23600.1058976911>