LLVM Bugzilla is read-only and represents the historical archive of all LLVM issues filled before November 26, 2021. Use github to submit LLVM bugs

Bug 48 - crash on input from C++ frontend
Summary: crash on input from C++ frontend
Status: RESOLVED FIXED
Alias: None
Product: libraries
Classification: Unclassified
Component: LLVM assembly language parser (show other bugs)
Version: trunk
Hardware: PC FreeBSD
: P normal
Assignee: Chris Lattner
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-10-16 22:15 PDT by Brian R. Gaeke
Modified: 2010-02-22 12:53 PST (History)
1 user (show)

See Also:
Fixed By Commit(s):


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Brian R. Gaeke 2003-10-16 22:15:43 PDT
void %_ZNSt12strstreambufC2Ei() {
%tmp.20 = or bool %tmp.19, and (bool shl (bool false, ubyte 1), bool true)
}

The above input crashes llvm-as in the parser, with the message:
Assertion failed: (V1.getType()->isInteger() && V2.getType() == Type::UByteTy),
function operator<<, file
/usr/home/brg/work/llvm/include/llvm/ConstantHandling.h, line 179.
Abort (core dumped)

I got this input from compiling libstdc++-v3/src/strstream.cc, in the middle
of trying to build libstdc++ on FreeBSD. I reduced the test case to the above
instruction in the above-named method. I am unsure whether the statement is
valid llvm assembly.

The stack trace is as follows:
(gdb) where
#0  0x2834d763 in kill () from /usr/lib/libc.so.5
#1  0x283b8e8c in abort () from /usr/lib/libc.so.5
#2  0x28391f8f in __assert () from /usr/lib/libc.so.5
#3  0x08188872 in operator<< (V1=@0x866e180, V2=@0x866e540)
    at ConstantHandling.h:179
#4  0x08164608 in ConstantFoldShiftInstruction(unsigned, Constant const*, Consta
nt const*) (Opcode=29, V1=0x866e180, V2=0x866e540) at ConstantHandling.cpp:139
#5  0x08168813 in ConstantExpr::getShiftTy(Type const*, unsigned, Constant*, Con
stant*) (ReqTy=0x866a680, Opcode=29, C1=0x866e180, C2=0x866e540)
    at Constants.cpp:939
#6  0x0814cec4 in ConstantExpr::getShift(unsigned, Constant*, Constant*) (
    Opcode=29, C1=0x866e180, C2=0x866e540) at Constants.h:527
#7  0x0813a4ac in llvmAsmparse() () at llvmAsmParser.y:1098
#8  0x08135fdd in RunVMAsmParser(std::string const&, __sFILE*) (
    Filename=@0x826a138, F=0x283c71e0) at llvmAsmParser.y:601
#9  0x08133ab7 in ParseAssemblyFile(std::string const&) (Filename=@0x826a138)
    at Parser.cpp:27
#10 0x0812faeb in main (argc=1, argv=0xbfbff528) at llvm-as.cpp:44
#11 0x0812f9f5 in _start ()
(gdb) up 4
#4  0x08164608 in ConstantFoldShiftInstruction(unsigned, Constant const*, Consta
nt const*) (Opcode=29, V1=0x866e180, V2=0x866e540) at ConstantHandling.cpp:139
139       case Instruction::Shl:     return *V1 << *V2;
(gdb) p V1->dump()
 bool false

(at this point gdb invariably crashes; who knows what else is going on.)
Apparently it doesn't like the bool shl (bool false, ubyte 1).
Comment 1 Chris Lattner 2003-10-16 22:47:36 PDT
Interesting.  This certainly needs to be fixed in the checker, but this should
also be fixed in the C++ front-end.  Do you have the C++ code that generated
this bad LLVM?
Comment 2 Brian R. Gaeke 2003-10-16 23:06:35 PDT
Sorry for being unclear... I think it's _ZNSt12strstreambufC2Ei
(std::strstreambuf::strstreambuf[not-in-charge](int), according to c++filt)
in cfrontend/src/libstdc++-v3/src/strstream.cc. 
"streamsize" is int; it's therefore the first constructor defined in that file.

The test case I pasted is not supposed to be a valid function; it's just
the smallest input I found that triggers the bug. This
is one llvm assembly statement from a much larger function.
Comment 3 Chris Lattner 2003-10-17 00:15:39 PDT
This is fixed:
http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20031013/008231.html

I have reproduced the underlying C++FE problem, and am working on it as well. 
I'll close this bug when it is gone as well.
Comment 4 Chris Lattner 2003-10-17 00:41:42 PDT
Here's a reduced testcase that caused the C++ to crash with an assertion (it now
checks to make sure it doesn't emit illegal shifts as well):
http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20031013/008232.html

This bug is now fixed in the C/C++ front-end.  Have I mentioned how much I
*LOVE* bitfields?

Thanks for the bug report!