Date: Wed, 27 Jun 2007 14:47:34 +0000 From: Andrey Chernov <ache@freebsd.org> To: Xin LI <delphij@delphij.net> Cc: Kostik Belousov <kostikbel@gmail.com>, cvs-src@FreeBSD.org, src-committers@FreeBSD.org, Harti Brandt <harti@FreeBSD.org>, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/share/mk sys.mk Message-ID: <20070627144734.GA49174@freebsd.org> In-Reply-To: <46826A8C.8070908@delphij.net> References: <200706261910.l5QJALb8093717@repoman.freebsd.org> <20070627093610.GU2268@deviant.kiev.zoral.com.ua> <20070627113859.N64822@knop-beagle.kn.op.dlr.de> <20070627101148.GB44554@nagual.pp.ru> <46826A8C.8070908@delphij.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jun 27, 2007 at 09:47:56PM +0800, Xin LI wrote: > Nitpicking: I think -O1 implies no strict-aliasing. So -O1 -pipe might > be just Ok. It is for easy change-back. > Well, I'd say that all these changes looks scary to me. > > Is there any code in our base system to trigger tree-vrp bug? Do we > still have some time to have gcc fixed and tested rather than using > band-aid like this? IMHO fixing gcc sounds better than "fix"ing sys.mk > if time permits us to fix and test a vendor solution. It is hard to find such cases because of the silent nature of the bug: basically any array usage inside loop, with array size smaller than the loop iterations can trigger that (premature exit from the loop). I think this case is general enough to worry at the system level. There is no vendor solution right now and will not be until gcc 4.2.1 I doubt it will be available as separate patch because of complexity of tree vrp optimization. This change will be backed out right after fixing gcc in any way. -- http://ache.pp.ru/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070627144734.GA49174>