After compiling GNU Make with llvmgcc, lli fails to run with the following
assertion error:

lli: /home/vadve/criswell/llvm/lib/VMCore/Function.cpp:69: virtual void
Argument::setName(const std::string&, SymbolTable*): Assertion `(ST == 0 ||
(!getParent() || ST == &getParent()->getSymbolTable())) && "Invalid symtab
argument!"' failed.
/home/vadve/criswell/Downloads/BenchPrograms/make-3.80/make: line 2: 15276
Aborted                 (core dumped)
/home/vadve/criswell/box/x86/llvm/tools/Debug/lli -q $0.bc $*

I got that once, now I'm getting this:
lli: job.c:1337: start_waiting_job: Assertion `f->command_state == cs_finished'
failed.

This is not specific to the JIT.  The CBE does the same thing.

I'm not sure what the problem is with this.  It seems to work fine if gmake is
run in a directory where it doesn't need to run a sub-gmake.

Unless someone has time to dig into this more an narrow down the problem, I'm
probably not going to have time to fix it before the release.

This is most likely a C frontend bug.

-Chris

Hopefully this is related to Bug 110.

-Chris

It's definitely a miscompilation of job.o; I haven't nailed it down to a
particular component, yet.

This seems to be a failure of llvm-gcc (the C frontend).

llvm-gcc is miscompiling make-3.80/job.c:start_waiting_job(). It is all unhappy
because an enum bitfield member of a "struct file" has taken on an impossible
value for a two-bit quantity. I'll see if I can produce a small test case.

I suspect that this may be related to Bug 6 and Bug 113, even though it does not
cause a crash. Clearly, bitfields are not Chris's friends.

SEXY.  I eagerly await a nice happy testcase.  I suspect that it's not quite the
same as Bug 6 and friends, so it's _yet another_ bitfield problem.  :(

-Chris

Created an attachment (id=24) [details]
Test case similar to Make problem

This test case is structured similarly to the Make problem.
It too fails with llvm-gcc, and works with native gcc.
Although I did not directly reduce Make to it, I think
that if this is fixed, Make will also be fixed.

Sweet, I'll look into it.  Thanks Brian!!

-Chris

What a GREAT optimizer.  It reduces it down to exactly the wrong thing:  :)

int %main(int %argc.1, sbyte** %argv.1) {
entry:
        call void %__main( )
        call void %abort( )
        ret int 0
}

-Chris

Yeah, I saw that myself. :-) I guess you could say that is a great optimizer at
work. It just didn't quite "make that left turn at Albuquerque," as Bugs Bunny
would say.

Here's the fix:

$ diff -u llvm-expand.c~ llvm-expand.c
--- llvm-expand.c~      2003-11-13 10:24:18.000000000 -0600
+++ llvm-expand.c       2003-11-18 00:17:24.000000000 -0600
@@ -4972,8 +4972,20 @@
       op0 = llvm_expand_lvalue_expr(Fn, exp, &BitStart, &BitSize);
 
       if (!isDestTyComposite) {  /* Return a normal scalar by loading it */
+        unsigned ResultBitSize;
         Result = append_inst(Fn, create_load_inst("tmp", op0, expVolatile));
 
+        ResultBitSize = llvm_type_get_size(Result->Ty)*8;
+
+        if (BitStart != 0 || BitStart+BitSize != ResultBitSize) {
+          llvm_type *ResultTy = llvm_type_get_integer(ResultBitSize,
+                                                TREE_UNSIGNED(TREE_TYPE(exp)));
+          /* Make sure that the value we are dealing with is of the right
+           * signedness.
+           */
+          Result = cast_if_type_not_equal(Fn, Result, ResultTy);
+        }
+
         /* If this is a read of a bitfield value, we have to mask and shift the
          * cruft out.
          */

We now happily compile this to:
int %main(int %argc.1, sbyte** %argv.1) {
entry:
        call void %__main( )
        %tmp.18 = call int (sbyte*, ...)* %printf( sbyte* getelementptr ([4 x
sbyte]* %.str_1, long 0, long 0) )             ; <int> [#uses=0]
        ret int 0
}

Which is just as optimized, but actually correct this time. :)

MAJOR thanks to Brian for reducing this nasty nasty bug for me!

-Chris

With any luck, this might fix some of the OTHER miscompilations too... :)

-Chris

Sorry, Chris, this does not fix either bug #6 or bug #113. Unless you meant
something else by "OTHER miscompilations"...

Those aren't miscompilations.  :)

-Chris