re: toolchain/45673: gcc on i386 current generates bad code for assembler code in lock.h

[matthew green <mrg%eterna.com.au@localhost>]

The following reply was made to PR toolchain/45673; it has been noted by GNATS.

From: matthew green <mrg%eterna.com.au@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: toolchain-manager%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
    netbsd-bugs%netbsd.org@localhost, kuehro%gmx.de@localhost
Subject: re: toolchain/45673: gcc on i386 current generates bad code for 
assembler code in lock.h
Date: Tue, 13 Mar 2012 09:49:12 +1100

 >  On Sun, 11 Mar 2012, Kai-Uwe Eckhardt wrote:
 >  > it looks like a problem in the toolchain. The gcc in 
 >  > 6.0_BETA and current i386 is built with --with-march=i486 
 >  > --with-tune=nocona. Nocona has the 64 bit registers available 
 >  > and this leads to wrong code.
 >  
 >  According to my reading of "man gcc", -march is supposed 
 >  to control the available set of CPU features, registers, 
 >  instructions, and the like, while -mtune is supposed to affect 
 >  the cost of using the available CPU features (while not affecting 
 >  the set of available features).  If a feature is not present in 
 >  the CPU type specified with "-march", but is present in the CPU 
 >  type specified with "-mtune", then I believe that GCC should NOT 
 >  attempt to use that feature.
 >  
 >  If GCC is invoked with "-march=i486 -mtune=nocona" and is using 
 >  features that are present in the nocona CPU but not present in the 
 >  i486 CPU, then I believe that indicates a GCC bug.
 
 i had a read through the i386 gcc code and i couldn't see anyway
 that -mtune=nocona would change the available instructions.  i
 agree that this would be a bug if it does so.
 
 fortunately, the real bug seems to be the register constraints.
 
 
 .mrg.