NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



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: Thu, 11 Oct 2012 11:04:41 +0200

 Building lang/gcc47 from pkgsrc, on a NetBSD/i386 -current host, fails
 as described in this PR, with:
 
 /usr/include/x86/lock.h:108: Error: bad register name `%sil'
 
 The problematic source file is gcc-4.7.0/libiberty/physmem.c, 
 which includes <sys/sysctl.h> which (through several levels of 
 includes) eventually includes <x86/lock.h>.  x86/lock.h contains 
 this code:
 
 static __inline int
 __cpu_simple_lock_try(__cpu_simple_lock_t *lockp)
 {
          uint8_t val;
 
          val = __SIMPLELOCK_LOCKED;
          __asm volatile ("xchgb %0,(%2)" :
              "=r" (val)
              :"0" (val), "r" (lockp));
          __insn_barrier();
          return val == __SIMPLELOCK_UNLOCKED;
 }
 
 The physmem.s file that I get from invoking the compiler with the
 "-save-temps" flag, and without any "-O" flags, includes this code:
 
 #APP
 # 108 "/usr/include/x86/lock.h" 1
          xchgb %sil,(%eax)
 # 0 "" 2
 #NO_APP
 
 The assembler is correctly complaining that %sil is not a valid 
 register name.
 
 If I change <x86/lock.h> to have "=qQ" or "=q" instead of "=r" in 
 the register constraint for the (val) output, then gcc chooses to 
 use the %dl register, not %sil, and compilation is successful.
 
 With "-O", the entire function is optimised away (because it's not
 called).
 
 There may be a gcc bug, as earlier commenters on thei PAR said, 
 because %sil is not a valid register for i386.  However, changing 
 the register constraint in <x86/lock.h> from "=r" to "=q" or "=qQ" 
 seems to me to be a simple, safe, and reasonable solution to the 
 problem without needing to modify gcc.
 
 I have performed a complete build of NetBSD-current/i386 with 
 "=qQ" in the relevant place in src/sys/arch/x86/include/lock.h, 
 and it passes all tests.  Also, the output from "objdump -d" is 
 identical before and after this change, for both the i386 GENERIC 
 and MONOLITHIC kernels.
 
 --apb (Alan Barrett)
 


Home | Main Index | Thread Index | Old Index