X-Spam-Check-By: sourceware.org Message-ID: <46840F0E.9EA8612B@dessent.net> Date: Thu, 28 Jun 2007 12:42:06 -0700 From: Brian Dessent X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: possible compiler optimization error References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Reply-To: cygwin AT cygwin DOT com Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Mike Marchywka wrote: > This doesn't have anything to do with cygwin but it can be an important > point. > Some compilers or applications , I think Intel IIRC, can figure out which > processor you have > at run time and pick which code to run- obviously the exe size gets large > but > if you need speed it can be helpful. I've thrown in assembly code that needs > certain fpu's and its great as long as you have a fall back or diagnostics > and don't > fail with an unexplained invalid instruction of "core dump." Recent versions of gcc have -march=native, when tells the compiler to detect the architecture of the machine it's running on do the equivalent -march= of that. However this happens at compile time, not at runtime, so this is not a substitute for the common practice of compiling several different architecture-specific versions of performance sensitive code and then detecting at runtime which to call. There is also -mtune=generic which is the new default tuning. This is a tweaked scheduler model that is meant to provide balanced performance on a wide array of common modern architectures, i.e. pentium4/prescott/nocona/core2/k8. As I understand it, this is not so much specific to any one arch, it's just a better default compromise that reflects the current modern state of the field better than the old -mtune=i386. Being a "tune" and not an "arch" it doesn't affect instruction set selection, i.e. the code that gcc outputs by default should still should run fine on any 386 class machine, unless either the user gave overriding options or the compiler was built with an -march override (configure --with-arch=foo). But both of these are too new to be in Cygwin's gcc 3.4.x so this is kind of off-topic. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/