hughperman / pure-lang

Automatically exported from code.google.com/p/pure-lang
0 stars 0 forks source link

pure-gen compilation fails #49

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
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.

Original issue reported on code.google.com by Michael....@gmail.com on 27 Nov 2010 at 3:56

Attachments:

GoogleCodeExporter commented 8 years ago
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.)

Original comment by aggraef@gmail.com on 28 Nov 2010 at 2:03

GoogleCodeExporter commented 8 years ago
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.

Original comment by Michael....@gmail.com on 30 Nov 2010 at 11:33

Attachments:

GoogleCodeExporter commented 8 years ago
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.

Original comment by aggraef@gmail.com on 4 Dec 2010 at 1:07

Attachments:

GoogleCodeExporter commented 8 years ago
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.

Original comment by Michael....@gmail.com on 4 Dec 2010 at 8:05

GoogleCodeExporter commented 8 years ago
Good to hear that there's a fix available. Hopefully it can be rolled out soon.

Original comment by aggraef@gmail.com on 4 Dec 2010 at 10:17