Clang error

Clang Frontend
1

With clang version 97437 and llvm 97442 built in Release mode I get the following error:

Stack dump:
0. Program arguments: /home/gonzo/bin/clang -cc1 -triple i386-pc-linux-gnu -S -disable-free -disable-llvm-verifier -main-file-name bla.cc -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -target-cpu pentium4 -g -resource-dir /home/gonzo/lib/clang/1.1 -Wall -Wextra -fmessage-length 177 -fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-byEFZN.s -x c++ bla.cc
1. <eof> parser at end of file
2. Code generation
3. Running pass 'X86 DAG->DAG Instruction Selection' on function '@atomic_exchange_and_add'
clang: error: compiler command failed due to signal 11 (use -v to see invocation)

when compiling the following file:

#include <boost/shared_ptr.hpp>
using ::boost::shared_ptr;

class A {};

int main()
{
  shared_ptr<A> a;
}

Debug mode seems to work.

Reduced testcase:

inline int atomic_exchange_and_add( int * pw, int dv )
{
     int r;

     __asm__ __volatile__
     (
         "lock\n\t"
         "xadd %1, %0":
         "=m"( *pw ), "=r"( r ):
         "m"( *pw ), "1"( dv ):
         "memory", "cc"
     );

     return r;
}

void release() {
  int use_count_;
         if( atomic_exchange_and_add( &use_count_, -1 ) == 1 ) { }
}

g

2

That looks like it's in the backend. This code is under flux, so I suggest updating LLVM + Clang and trying again. If it still fails, please file a bug against LLVM at http://llvm.org/bugs/

  - Doug

3

I updated and it still fails.
Filed under http://llvm.org/bugs/show_bug.cgi?id=6475

g

4

I added a reduced testcase in bug 6475.

int main()
{
  int i;

  // Compiled by gcc and clang
  //__asm__ ( "nop": "=r"( i ) );

  // Compiled by gcc but clang fails due to signal 11
  __asm__ ( "nop": "=m"( i ) );

  return 0;
}

Regards,

g

5

Hi,

I updated and it still fails.
Filed under 6475 – Inline asm bug with atomic_exchange_and_add

Can you try LLVM r97474? r97475 enabled the new isel by default
which started to crash our out-of-tree backend (we also use inline asm
even in crt0()), maybe this is related. I've been tracking this since
yesterday. r97474 works for us.

Also, can you try to produce a proper backtrace by enabling core
dump and inspecting it with gdb so I can see if it matches ours.

For some reason I get an illegal SDNode to the Select() which crashes
when being dumped (which actually causes the segfault also for me as
it propagates to CannotYetSelect() which tries to dump it).
Makes it nasty to debug.