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

Bug#735310: marked as done (Error: bad register name `%bpl' in i386)

Your message dated Thu, 16 Jan 2014 14:55:00 +0200
with message-id <20140116125500.GA13614@perseus.local>
and subject line Re: Error: bad register name `%bpl' in i386
has caused the Debian Bug report #735310,
regarding Error: bad register name `%bpl' in i386
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org

735310: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735310
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: gcc-4.8
Version: 4.8.2-12
Severity: important

webkitgtk 2.3.4 FTBFS with the latest gcc-4.8:

../Source/WTF/wtf/Atomics.h: Assembler messages:
../Source/WTF/wtf/Atomics.h:300: Error: bad register name `%sil'

You can see the full log here:


My understanding is that gcc is incorrectly producing x86-64 registers
when generating x86 code.

I managed to narrow it down with a pre-processed version of the
CodeBlock.cpp source file from webkit (I can attach it or post it
somewhere, it's ~400KB of compressed code):

$ gcc -O1 -m32 --std=c++11 -c CodeBlock.ii 
../Source/WTF/wtf/Atomics.h: Assembler messages:
../Source/WTF/wtf/Atomics.h:300: Error: bad register name `%bpl'
../Source/WTF/wtf/Atomics.h:300: Error: bad register name `%bpl'
../Source/WTF/wtf/Atomics.h:300: Error: bad register name `%dil'

This works fine, though (which I don't quite understand since
-frename-registers should already be enabled by -O1):

$ gcc -O1 -m32 --std=c++11 -c -frename-registers CodeBlock.ii 

Here's the relevant part of the source file:

inline bool weakCompareAndSwap(uint8_t* location, uint8_t expected, uint8_t newValue)
    unsigned char result;
    asm volatile(
        "lock; cmpxchgb %3, %2\n\t"
        "sete %1"
        : "+a"(expected), "=q"(result), "+m"(*location)
        : "r"(newValue)
        : "memory"
    return result;

This upstream GCC bug is related:


Although the suggestion to use '=r' instead of '=q' doesn't seem to
solve the problem.


-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages gcc-4.8 depends on:
ii  binutils        2.24-2
ii  cpp-4.8         4.8.2-12
ii  gcc-4.8-base    4.8.2-12
ii  libc6           2.17-97
ii  libcloog-isl4   0.18.1-3
ii  libgcc-4.8-dev  4.8.2-12
ii  libgmp10        2:5.1.3+dfsg-1
ii  libisl10        0.12.1-2
ii  libmpc3         1.0.1-1
ii  libmpfr4        3.1.2-1
ii  zlib1g          1:1.2.8.dfsg-1

Versions of packages gcc-4.8 recommends:
ii  libc6-dev  2.17-97

Versions of packages gcc-4.8 suggests:
ii  binutils [binutils-gold]  2.24-2
ii  gcc-4.8-doc               4.8.2-2
pn  gcc-4.8-locales           <none>
pn  gcc-4.8-multilib          <none>
pn  libasan0-dbg              <none>
pn  libatomic1-dbg            <none>
pn  libbacktrace1-dbg         <none>
pn  libgcc1-dbg               <none>
pn  libgomp1-dbg              <none>
pn  libitm1-dbg               <none>
pn  libquadmath0-dbg          <none>
pn  libtsan0-dbg              <none>

-- no debconf information

--- End Message ---
--- Begin Message ---
It turned out to be a bug in the source code in the end, sorry for the
noise, I'm closing this.


--- End Message ---

Reply to: