What steps will reproduce the problem? 1. Install pure 0.45 2. Download and untar pure-gen 0.9 3. make pure-gen

What is the expected output? What do you see instead? A pure-gen binary; build errors

What version of the product are you using? On what operating system? gcc-4.5.1-4.fc14.x86_64 llvm-2.8-4.fc14.x86_64 pure-0.45-3.fc14.x86_64 pure-0.9.tar.gz

Please provide any additional information below.

This looks like a garbled or corrupted assembler file. I've never seen anything like this before. The native assembler gets written by the LLVM toolchain, so I suspect that this isn't Pure-related. Are you sure that you didn't run into an intermittent disk failure or lack of space on the build host?

Please also double-check that you have a working LLVM installation (you probably do if Pure's compile went ok and it passes 'make check') and that the version of the LLVM tools (llc and opt, in particular) matches that of the installed LLVM library.

If that all looks fine then I'd need copies of the generated LLVM and native assembler files to tell you more. You can get these by compiling pure-gen manually with:

pure -c pure-gen.pure -o pure-gen.ll pure -c pure-gen.pure -o pure-gen.s

(These files will be big, so it might be a good idea to upload them in a tarball.)

There is no disk space issue, and I only install LLVM and pure from RPMs so there's only one version installed (llvm 2.8, pure 0.45).

Pure is dynamically linked against LLVM -- could this make a difference?

Please find .ll and .s tarball attached.

I have Pure dynamically linked against LLVM, too, and it works fine. The problem is most definitely not with Pure and not with LLVM either. Using Pure 0.45 and pure-gen-0.9, I get exactly the same .ll and .s sources, so they're fine. They also compile without a hitch, using GNU as 2.19.

I strongly suspect that the problem is with the GNU as that you're using. Line 155645 of pure-gen.s defines a string constant which is pretty long (some 40k characters). It seems that your GNU as gives up around column 21962, truncating the string constant at '...\nscanf_fo' and then going on to read 'rmat_error 786...' as a new statement. This would explain both the warning (missing closing `"') and the subsequent error (no such instruction) from the assembler in your build log. I get exactly the same warning and error message with my GNU as if I artificially break the line at that point.

This would be bad because it means that Pure's batch compiler won't work on FC14, even if you find a way to work around the problem in order to compile pure-gen. (Of course I could work around this in the assembler code generated by pure -c, but that would be an awful hack, so I'd rather not do that.)

In any case, GNU utilities aren't supposed to have such arbitrary length restrictions, so I'd consider this a bug in GNU as. You should be able to verify this by running GNU as on the attached excerpt from the .s file (bug.s):

as bug.s -o bug.o

This should produce a ~40k object file. If it gives you the same assembler error message as in your build log, then you have a minimal bug witness that you can submit to the GNU binutils developers.

If you have older and newer versions of the binutils available, you can try those as well. There must be some point between the GNU as 2.19 that I have and the version that you're running where this was broken. Maybe it has even been fixed already in the latest revisions of GNU as.

I'm setting this issue to "WontFix" for now. Please reopen it if you think that my analysis of the problem is incorrect.

We have binutils-2.20.51.0.7, and our -5 release indeed has a bug in that as cannot handle long lines. Someone else reported it and there is a -6 build that fixes this, but somehow an update was not pushed out! I'm checking with the maintainer to find out why -- hopefully it's just an omission -- and we'd hopefully have it out soon.

The test case does not work, by the way -- even with the defective -5 build of binutils I could assemble it fine. However, -6 does indeed compile pure-gen.

Good to hear that there's a fix available. Hopefully it can be rolled out soon.