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

Bug#438415: marked as done (g++-4.1: [regression] "‘asm’ operand requires impossible reload" building WebKit on PPC)

Your message dated Sun, 11 Apr 2010 14:30:29 +0000
with message-id <E1O0yBB-0007p8-N5@ravel.debian.org>
and subject line C++ and mudflap packages not built anymore from the gcc-4.1 source
has caused the Debian Bug report #438415,
regarding g++-4.1: [regression] "‘asm’ operand requires impossible reload" building WebKit on PPC
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
immediately.)


-- 
438415: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=438415
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: g++-4.1
Version: 4.1.2-15
Severity: important

WebKit fails to build on linux PPC with the following error:
../../../JavaScriptCore/wtf/TCSpinLock.h: In function 'void* TCMalloc_SystemAlloc(size_t, size_t)':
../../../JavaScriptCore/wtf/TCSpinLock.h:98: error: 'asm' operand requires impossible reload

You can check the full relevant source code at the following address:
http://git.debian.org/?p=pkg-webkit/upstream.git;a=blob;f=JavaScriptCore/wtf/TCSystemAlloc.cpp;h=98cb5f73fa65b95d5c76ad772f0f18df74fa8dc1;hb=9ef19fbb3a114100a70c594c519a50145c1332a7
http://git.debian.org/?p=pkg-webkit/upstream.git;a=blob;f=JavaScriptCore/wtf/TCSpinLock.h;h=14c68cbee6737359b5d16cbee478584d18db8a84;hb=9ef19fbb3a114100a70c594c519a50145c1332a7

The attached file contains a reduced testcase that still fails to build
(though the code might not make much sense once reduced)

It has been validated to fail with g++-4.1 4.1.1-21 and g++-4.2 4.2.1-4.
With these versions, it has also been validated to correctly build with
-O0.

It builds fine with -O2 with g++-4.0 4.0.3-3.

For WebKit, I can work around the issue by building with the pthread
generic support, so it is not a blocker issue.

Mike

#include <stdint.h>
#include <unistd.h>
#include <stdlib.h>

static void SlowLock(volatile unsigned int* lockword);

struct SpinLock {
  volatile unsigned int private_lockword_;

  inline void Init() { private_lockword_ = 0; }
  inline void Finalize() { }
    
  inline void Lock() {
    int r;
    volatile unsigned int *lockword_ptr = &private_lockword_;
    __asm__ __volatile__
        ("1: lwarx %0, 0, %1\n\t"
         "stwcx. %2, 0, %1\n\t"
         "bne- 1b\n\t"
         "isync"
         : "=&r" (r), "=r" (lockword_ptr)
         : "r" (1), "1" (lockword_ptr)
         : "memory");
    if (r) SlowLock(&private_lockword_);
  }

  inline void Unlock() {
    __asm__ __volatile__
      ("isync\n\t"
       "eieio\n\t"
       "stw %1, %0"
       : "=o" (private_lockword_) 
       : "r" (0)
       : "memory");
  }
};

static void SlowLock(volatile unsigned int* lockword) {
    int r;
    int tmp = 1;
    __asm__ __volatile__
        ("1: lwarx %0, 0, %1\n\t"
         "stwcx. %2, 0, %1\n\t"
         "bne- 1b\n\t"
         "isync"
         : "=&r" (r), "=r" (lockword)
         : "r" (tmp), "1" (lockword)
         : "memory");
}

class SpinLockHolder {
 private:
  SpinLock* lock_;
 public:
  inline explicit SpinLockHolder(SpinLock* l)
    : lock_(l) { l->Lock(); }
  inline ~SpinLockHolder() { lock_->Unlock(); }
};

static SpinLock spinlock = { 0 };
  
void SystemAlloc(void) {
  SpinLockHolder lock_holder(&spinlock);
}

--- End Message ---
--- Begin Message --- 
The C++ and mudflap binary packages are not built anymore from the
gcc-4.1 source package.  Tagging this report as won't fix, and closing
the report.

Please check if the problem is fixed in gcc-4.4 (or gcc-4.5/gcc-snapshot).
If the problem is not fixed, and not yet reported for the new compiler
version(s), open a new report.

--- End Message ---
Reply to: