This seems to be a logic error in the AsmParser. The affected code is this
production:

InstVal : ArithmeticOps Types ValueRef ',' ValueRef {
if (!($2)->isInteger() && !($2)->isFloatingPoint() &&
!isa(($2).get()))
GEN_ERROR(
"Arithmetic operator requires integer, FP, or packed operands!");
if (isa(($2).get()) && $1 == Instruction::Rem)
GEN_ERROR("Rem not supported on packed types!");
*** $$ = BinaryOperator::create($1, getVal($2, $3), getVal($2, $5));
if ($$ == 0)
GEN_ERROR("binary operator returned null!");
delete $2;
CHECK_FOR_ERROR
}

For some reason the second getVal call is ending up not liking the IntTy first
argument when it hits this assertion:

assert(Ty == Type::DoubleTy)

llvm::ConstantFP::get(const llvm::Type*, double)

In this case, Ty == Type::IntTy.

That's all the analysis I have time for right now.

The reason this crashes is as follows:

This line:
BinaryOperator::create($1, getVal($2, $3), getVal($2, $5))

calls: getVal("int", "1")
which is fine.

Then it calls: getVal("int", "2.0")

Which calls GenerateError on line 319:

if (!ConstantFP::isValueValidForType(Ty, D.ConstPoolFP))
  GenerateError("FP constant invalid for type!!");

However, GenerateError returns, which then falls into the next line:
return ConstantFP::get(Ty, D.ConstPoolFP);
... which aborts.

GenerateError should not return.

-Chris

Yeah, I think I see the problem. YYERROR can't be used inside getVal because it
is basically a goto statement which can only be used in the body of a
production. Consequently GenerateError is called directly instead of using the
GEN_ERROR macro. But, nothing checks for the error after this. Should be fairly
easy to fix. I'll try to take a look at this today and ensure the error gets
triggered in this and other similar cases.

Fixed with this patch:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060925/038179.html

Errors are generated with the YYERROR macro which can only be called from
a production (inside yyparse) because of the goto statement in the macro.
This lead to several situations where GEN_ERROR was not called but
GenerateError was used instead (because it doesn't use YYERROR). However,
in such situations, catching the error much later (e.g. at the end of
the production) is not sufficient because LLVM can assert on invalid data
before the end of the production is reached. The solution is to ensure that
the CHECK_FOR_ERROR macro (which invokes YYERROR if there's an error) is
used as soon as possible after a call to GenerateError has been made.