The simplify-libcalls pass seems to generate LLVM code that does not pass the
LLVM bytecode verifier.  Running the -simplify-libcalls pass on the (soon to be)
attached bytecode file generates the following assertion:

Call parameter type does not match function signature!
ubyte* getelementptr ([27 x ubyte]* %.str_247, int 0, int 0)
 sbyte* %tmp.51 = call uint %fwrite( ubyte* getelementptr ([27 x ubyte]*
%.str_247, int 0, int 0), uint 26, uint 1, %struct._IO_FILE* %tmp.52 )         ;
<uint> [#uses=0]
Broken module found, compilation aborted!
opt((anonymous namespace)::PrintStackTrace()+0x1a)[0x8731ef2]
opt((anonymous namespace)::SignalHandler(int)+0xc7)[0x873215f]
/lib/tls/libc.so.6[0x7f7a58]
/lib/tls/libc.so.6(abort+0x1d2)[0x7f9342]
opt((anonymous namespace)::Verifier::abortIfBroken()+0xd5)[0x86fc833]
opt((anonymous namespace)::Verifier::runOnFunction(llvm::Function&)+0x57)[0x86fc97b]
opt(llvm::PassManagerTraits<llvm::Function>::runPass(llvm::FunctionPass*,
llvm::Function*)+0x1f)[0x86e51ad]
opt(llvm::PassManagerT<llvm::Function>::runOnUnit(llvm::Function*)+0x5c1)[0x86e4a81]
opt(llvm::PassManagerTraits<llvm::Function>::runOnFunction(llvm::Function&)+0x1f)[0x86e573b]
opt(llvm::FunctionPass::runOnModule(llvm::Module&)+0xa5)[0x868c29f]
opt(llvm::PassManagerTraits<llvm::Module>::runPass(llvm::ModulePass*,
llvm::Module*)+0x1f)[0x86e0149]
opt(llvm::PassManagerT<llvm::Module>::runOnUnit(llvm::Module*)+0x5c0)[0x86df128]opt(llvm::PassManagerTraits<llvm::Module>::runOnModule(llvm::Module&)+0x1f)[0x86e2257]
opt(llvm::PassManager::run(llvm::Module&)+0x23)[0x868b6bd]
opt(main+0x8d6)[0x842153a]
/lib/tls/libc.so.6(__libc_start_main+0xf0)[0x7e5770]
opt(std::__throw_logic_error(char const*)+0x55)[0x8420ad1]
Abort (core dumped)

Created an attachment (id=256) [details]
LLVM assembly that can reproduce the problem

To reproduce the bug, do the following:

llvm-as -f file.ll
opt -simplify-libcalls file.bc -o opt.bc

The code was reduced from cp-demangle.cc from the LLVM GCC sources.

The problem seems to occur when an fprintf() is converted to an fwrite().  

I've attempted to reduce the problem with bugpoint, but to no avail.  Bugpoint
initially detects the asssertion when running the optimization pass.  But then,
during function reduction, the assertion is never triggered again.

I suspect that the in-memory bytecode of the program is somehow incorrect after
the simplify-libcalls pass is run, causing the verifier pass to assert.  Once
bugpoint starts modifying the in-memory representation, it somehow fixes the
problem (or, at least that is my guess.  I don't know for sure).

Basic fix here:

http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20050627/026855.html

This should fix building of libstdc++ on Linux/PowerPC (where this is an issue).

I'm not sure what to do about a regression test; the above test case is rather
large.

Verified that this bug exists within LLVM 1.5.

Thanks John!