I’m trying to write some tests for inline asm constraints, single and multiple alternative.
Does anyone know of some example/test code using all or some subset of the constraint letters for one or more platforms that I could look at?
Does anyone know how to set up an asm statement using the “o” constraint?
Thanks.
-John
I believe ffmpeg uses a lot of inline asm, and doesn't build & work yet because of asm-related bugs in the register allocators and perhaps other places. And there's always the various testsuites of course, especially gcc's.
Hi John,
Have you looked at the GCC test suite? It certainly has some examples
-- I know for sure because one of them is now failing with Clang after
your recent patch. 
I have a hacked up version in the 'clang-tests' module in SVN which
has been made a bit easier to run with clang.
- Daniel
Daniel,
Sorry, I’m implementing the back-end support for multiple-alternative constraints in stages. I wouldn’t expect any serious inline asm multiple alternative constraints tests to work yet, as a number of the constraint characters aren’t implemented yet. I’ll try to fix it so that it doesn’t assert when unsupported constraints are used. Clang may have passed parsing tests before my latest change, but there wasn’t real support for multiple-alternative constraints with the front-end/back-end combination yet.
I’m glad you’re working on the gcc tests. I’ve pulled them down now. Seeing that they have a makefile, I’m assuming they probably won’t work on Windows, so I’m putting them on my Linux box.
Questions:
Should I be able to get these running on Ubuntu Linux, or are they targeted for Darwin only? I changed the variables at the start of the makefile to reflect Linux and my paths, and installed DejaGNU. The tests are running right now, and right off I’m getting a number of messages about failing tests. Some for paths like “gcc.apple/pascal-strings-2.c”, some like gcc.c-torture/compile/20000922-1.c. It’s fairly quiet now, so I’m assuming some are passing.
Will they work with the debug build of Clang?
What was the name of the failing test?
I’m a novice here, so any help would be appreciated.
-John
I’m assuming they need to be run on Linux. I’ll see if I can make it so it doesn’t assert if any of the unsupported constraints are used.
I just tried running the gcc tests, but am missing “runtest”.
-John
[snip]
I just tried running the gcc tests, but am missing "runtest".
Follow the directions there. I think the GCC test suite wants DejaGNU to be installed in a sibling directory, adjacent to the llvm-gcc or clang toplevel.
HTH,
stuart
Thanks, Stuart. Sorry, I had some left-over editing cruft in my email. From Googling runtest, I had found dejagnu, which I’d heard some folks were using over there, so I used the local package manager to install it. But from what you said I went ahead and got the dejagnu sources and built it, but had problems in running make install, which is trying to put it /usr/local/bin rather than /usr/bin like the package manager did, so I left it alone for now. But the dejagnu tree is adjacent to the gcc test suite tree. Should I try to resolve the install problems? Running runtest --version:
Expect version is 5.43.0
Tcl version is 8.4
Framework version is 1.4.99
In my first run, only 95 tests passed, 516 unexpected failures, etc. So either I still need some kind of configuration fix, or this particular snap of the tests doesn’t work on my particular Linux box. I’m using the triple i386-unknown-linux in Daniel’s makefile.
I’m running the tests again adding the -v option to runtest to see if that gives me any more information, plus using the Release+Asserts version of the clang binaries.
But I’m hoping you or Daniel can straighten me out.
Thanks again,
-John
Hi John,
Here is one simple example that clang crashes on now that your patch went in:
pr20314-2.c (1.49 KB)
If the test suite Makefile is able to invoke runtest, and runtest works, then it's configured well enough. I can't tell from here what's going on. Find a log file (e.g. "% find <dir> -name \*.log") and study that to determine exactly what's broken. Is the compiler getting invoked?
stuart
Thanks, Stuart. Sorry, I had some left-over editing cruft in my email. From Googling runtest, I had found dejagnu, which I’d heard some folks were using over there, so I used the local package manager to install it. But from what you said I went ahead and got the dejagnu sources and built it, but had problems in running make install, which is trying to put it /usr/local/bin rather than /usr/bin like the package manager did, so I left it alone for now. But the dejagnu tree is adjacent to the gcc test suite tree. Should I try to resolve the install problems? Running runtest --version:
Expect version is 5.43.0
Tcl version is 8.4
Framework version is 1.4.99In my first run, only 95 tests passed, 516 unexpected failures, etc. So either I still need some kind of configuration fix, or this particular snap of the tests doesn’t work on my particular Linux box. I’m using the triple i386-unknown-linux in Daniel’s makefile.
There should be far more than 600 tests run, more like 40000 for C alone. You’re doing something basic wrong.
I did ask you to run this before checking in your patch. Please don’t skimp on testing in the future.
Dale,
Sorry, I see you did say I should run the gcc tests. I apologize for forgetting this. I’ll work on getting them to run here.
Chris et. all,
I have a fix for the assertion failure in the enclosed llvmmultalt8.patch file. I didn’t realize the input constraints could have different numbers of alternatives from the outputs, which now makes sense. The pr20314-2.c file now compiles on my 64-bit Linux box. However, it still has a problem on 32-bit Windows and 32-bit Linux:
fatal error: error in backend: Ran out of registers during register allocation!
Please check your inline asm statement for invalid constraints:
INLINEASM es:, 0, 10, %reg16396, 10, %reg16397, 10, %reg16398, 10, %reg16399, 10, %reg16400, 10, %reg16401,10, %reg16402, 10, %reg16403, 10, %reg16404, 10, %reg16405, 10, %reg16406, 10, %reg16407, 2147483657, %EAX, 2147549193, %ECX, 2147614729, %EDX, 2147680265, %ESI, 2147745801, %EDI, 2147811337, %EBX, 2147876873, %EBP, 2147942409, %reg16403, 2148007945, %reg16404, 2148073481, %reg16405, 2148139017, %reg16406, 2148204553, %reg16407, 14, %EFLAGS<earlyclobber,imp-def>, <>; GR32:%reg16396,16397,16398,16399,16400,16401,16402,16403,16404,16405,16406,16407,16403,16404,16405,16406,16407
For the code:
int a, b, c, d, e, f, g, h, i, j, k, l;
void
f1 (void)
{
asm volatile (“”
: [a] “+r” (a), [b] “+r” (b), [c] “+r” (c), [d] “+r” (d),
[e] “+r” (e), [f] “+r” (f), [g] “+r” (g), [h] “+r” (h),
[i] “+r” (i), [j] “+r” (j), [k] “+r” (k), [l] “+r” (l));
}
This confused me since it doesn’t use multiple-alternative constraints, meaning it should fall back to the original logic. I’m thinking this problem probably isn’t related to my code. To try to confirm this, I built an LLVM tree I had checked out on August 24 (rev 111968) and I see the same error.
If you agree, I’ll go ahead and check in my patches, and file a bug on the above error.
The llvmmultalt8.patch and the clangmultalt8.patch files have a little extra stuff I had just added previous to this, namely adding partial support for the E, F, and p constraint characters I saw from the GCC docs, and which should be benign.
Sorry for the hassle.
-John
llvmmultalt8.patch (3.15 KB)
clangmultalt8.patch (555 Bytes)
Yes, this test asks for 12 different registers, so there's no way it could pass on x86-32, which has only 6 (at most).
Thanks, Dale. I guess this also means I should be running the gcc tests in x86-64 mode. I’m giving that a spin on my Linux box.
Is Daniel going to package it up with a configure and so forth and make it part of the Clang tests, or like the llvm test-suite?
Also, it would be really nice if the gcc tests could run on Windows, and especially also the LLVM regression tests and projects/test-suite. At present, I develop on Windows and then copy a patch over to Linux, as using command-line GDB is very painful for me
How do you guys debug on your systems? Is there something comparible to the Visual Studio debugger? I’ve tried a few GDB GUI wrappers I found from googling a while ago, but I couldn’t get any of them to work well enough to use.
-John
I don't have an opinion, as I haven't had time to look at the original patch yet. If it fixes the test failure on x86-64 and you are confident in it, please go ahead and apply it. In the clang tests you can force x86-64 by specifying -mtriple.
-Chris