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

[David Laight <david%l8s.co.uk@localhost>]

On Mon, Mar 12, 2012 at 09:20:04PM +0000, Alan Barrett wrote:
> The following reply was made to PR toolchain/45673; it has been noted by 
> GNATS.
> 
> From: Alan Barrett <apb%cequrux.com@localhost>
> To: gnats-bugs%NetBSD.org@localhost
> Cc: 
> Subject: Re: toolchain/45673: gcc on i386 current generates bad code for
>  assembler code in lock.h
> Date: Mon, 12 Mar 2012 15:17:36 -0600
> 
>  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.

Specifying the arch or tune shouldn't be affecting the available
set of registers. What it probably does is just change the
instruction scheduling enough so that the code compiles.

The 64 bit registers are never available in 32bit mode.
(Well gcc could be configured to generate 32bit code within
the 64bit instruction set - but that is something different.)

In spite of an old gcc bug (from 2003) which suggests using a different
constraint (=qQ instead or =r) it shouldn't really be needed.
gcc has a pile of architecture specific defines that tell it
the names of all the registers, which registers use the same physical
space (think MMX and SSE) and which validy share the same contents
but with different data sizes, and some special defs for x86 %ah.
These are all based on explicit lists, not pattern rules.
So the definitions incorrectly allow %sil, %dil and %bpl when
compiling with -m32.
Possibly the same 'bug' would allow %r8-%r15 be used for 8, 16
or 32bit quantities (or that code would show the fix).

Probably a simple matter of reading and understanding the way -m32
is done.

        David

-- 
David Laight: david%l8s.co.uk@localhost