assigned to @echristo

previously, clang just ignored the register name, which could lead to miscompilations, telling the user that we don't support it yet is better. One work-around for this is to just remove the asm register declaration from the source, its use is dubious anyway.

previously, clang just ignored the register name

There is precedent here; llvm-gcc currently ignores the register name.

Llvmgcc honors it in inline asm stmts that the value is live across, which is technically all that is required for local vars.

Llvmgcc honors it in inline asm stmts that the value is live across, which is
technically all that is required for local vars.

FYI, I've opened bug #​1357 on redmine.ruby-lang.org about this with a patch removing the assignment-to-specific-registers code (see http://redmine.ruby-lang.org/issues/show/1357).

This also seems to prevent the FreeBSD kernel from being built. Fails somewhere when building ACPI code if I remember correctly.

*** Bug llvm/llvm-bugzilla-archive#6665 has been marked as a duplicate of this bug. ***

tcmalloc (google-perftools) also needs this.

Chromium apparently also needs this.

I'll take a look.

This is now the last thing that keeps us from building all of chromium (binary and all tests) on linux.

*** Bug llvm/llvm-bugzilla-archive#8874 has been marked as a duplicate of this bug. ***

I intend to do a partial fix for this as described in llvm/llvm-bugzilla-archive#8874 . Just remember that a variable was declared with asm("reg") and use that register if the variable is an argument to a asm statement.

We should probably also reject or at least warn about things like

register uint64_t foo asm("rbx");

asm("..." : "=a" (foo));

I think the most important part has been fixed in 122643. We are intentionally more restrictive than gcc, if too restrictive for a particular use, please open a new bug report.

The generated code also has more moves than the one produced by gcc, but that is an llvm problem, not clang's.

mentioned in issue llvm/llvm-bugzilla-archive#5511

mentioned in issue llvm/llvm-bugzilla-archive#6665

mentioned in issue #1234

mentioned in issue llvm/llvm-bugzilla-archive#8874