Date: Mon, 17 Apr 2000 14:07:25 +0200 From: Martin Cracauer <cracauer@cons.org> To: Adrian Chadd <adrian@FreeBSD.ORG> Cc: hackers@FreeBSD.ORG Subject: Re: What are the best gcc optimization options for Pentium 200 MMX Message-ID: <20000417140725.A6672@cons.org> In-Reply-To: <20000410190151.A18146@ewok.creative.net.au>; from adrian@FreeBSD.ORG on Mon, Apr 10, 2000 at 07:01:51PM %2B0800 References: <Pine.LNX.4.10.10004082114170.23805-100000@inet.ssc.nsu.ru> <Pine.BSF.4.21.0004081416110.70551-100000@freefall.freebsd.org> <86snwuwk9w.fsf@not.demophon.com> <20000410190151.A18146@ewok.creative.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
In <20000410190151.A18146@ewok.creative.net.au>, Adrian Chadd wrote: > On Mon, Apr 10, 2000, Ville-Pertti Keinonen wrote: > > > > kris@FreeBSD.org (Kris Kennaway) writes: > > > > > Can you say "gimmick"? :-) gcc often produces demonstrably broken code for > > > optimisation levels higher than -O. > > > > That -O is safe seems to be a persistent myth. GCC also produces > > broken code for -O and no optimization in some cases, sometimes while > > producing working code for higher optimization levels... I wouldn't > > state e.g. that -O2 produces broken code any more often than -O, this > > may have been true for version X.Y.Z but is certainly not universally > > true. > > > > I believe that the reasons the FreeBSD build uses -O are the fact that > > especially with older versions of gcc, -O2 slowed down compilation > > considerably for little noticable performance improvement (as for -O3, > > automatic inlining is generally undesirable), and it is always best to > > only have to test the system with a single set of flags. > > I have exactly the same problem hacking squid code under 4.0-CURRENT > and 5.0-CURRENT. Basically, inside the dns routines a variable > would be corrupted between a couple of non-relevant lines, and cause > squid to segfault after trying to resolve anything. Taknig out -O2 > and replacing it with -O causes the same problem. Its annoying. :( Could you pleaseverify whether that looks like PR bin/16862? If they are releated, you need to change the optimization setting of the shared libraries (or generally -fpic code) your crashing code uses, not the setting of the code itself. Raising the optimization setting may as well help as lowering it. Basically, our gcc produces code our as doesn't understand and symbol locations in -fpic code may be damaged, so that access (read or write) to such a variable causes segmentation violations. Are there any as warning messages (especially GOTOFF - related ones) when you compile the code in question, especially when compiling shared libraries it may use? It sounds like you found the lines where the corruption happens, I would welcome the exact locations. I'd like to hunt this one down. Thanks! Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer/ BSD User Group Hamburg, Germany http://www.bsdhh.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000417140725.A6672>