Closed GoogleCodeExporter closed 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
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:
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:
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
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
Original issue reported on code.google.com by
Michael....@gmail.com
on 27 Nov 2010 at 3:56Attachments: