Quuxplusone / LLVMBugzillaTest

0 stars 0 forks source link

Assert failure: getConstant with a uint64_t value that doesn't fit in the type! #5126

Closed Quuxplusone closed 15 years ago

Quuxplusone commented 15 years ago
Bugzilla Link PR4612
Status RESOLVED FIXED
Importance P normal
Reported by Alan Mock (docmach+llvm@gmail.com)
Reported on 2009-07-23 12:05:44 -0700
Last modified on 2009-07-23 18:19:25 -0700
Version unspecified
Hardware PC Linux
CC llvm-bugs@lists.llvm.org
Fixed by commit(s)
Attachments main.c (365 bytes, text/plain)
Blocks
Blocked by
See also
Created attachment 3236
Code to reproduce bug

When compiling the attached code with -O3 the compilation fails.  It succeeds
if no optimization flags are used.

main.c:5:24: warning: implicitly declaring C library function 'malloc' with type
      'void *(unsigned long)'
    int * largeArray = malloc(largeSize*sizeof(int));
                       ^
main.c:5:24: note: please include the header <stdlib.h> or explicitly provide a
      declaration for 'malloc'
clang-cc: SelectionDAG.cpp:872: llvm::SDValue
llvm::SelectionDAG::getConstant(uint64_t, llvm::MVT, bool): Assertion
`(EltVT.getSizeInBits() >= 64 || (uint64_t)((int64_t)Val >>
EltVT.getSizeInBits()) + 1 < 2) && "getConstant with a uint64_t value that
doesn't fit in the type!"' failed.
0   clang-cc        0x00000000011bdc7f
1   clang-cc        0x00000000011be069
2   libpthread.so.0 0x00007fe5e4aa5a10
3   libc.so.6       0x00007fe5e3dca205 gsignal + 53
4   libc.so.6       0x00007fe5e3dcb723 abort + 387
5   libc.so.6       0x00007fe5e3dc3229 __assert_fail + 233
6   clang-cc        0x0000000000d94e2b
7   clang-cc        0x0000000000db31bd
8   clang-cc        0x0000000000dd944c
9   clang-cc        0x0000000000dd9841
10  clang-cc        0x0000000000ddb5ef
11  clang-cc        0x00000000011529ea
12  clang-cc        0x0000000001152bf6
13  clang-cc        0x0000000001152e60
14  clang-cc        0x000000000044ba1d
15  clang-cc        0x000000000044c1c7
16  clang-cc        0x000000000063457d
17  clang-cc        0x0000000000431209
18  clang-cc        0x000000000043a1d2 main + 5506
19  libc.so.6       0x00007fe5e3db65c6 __libc_start_main + 230
20  clang-cc        0x000000000042ee29
Stack dump:
0.  Program arguments: /opt/src/llvm/Release/bin/clang-cc -triple x86_64-unknown-
linux-gnu -S -disable-free -main-file-name main.c --relocation-model static --
disable-fp-elim --unwind-tables=1 --mcpu=x86-64 --fmath-errno=1 -O3 -
fdiagnostics-show-option -o /tmp/cc-UKxix3.s -x c main.c
1.  <eof> parser at end of file
2.  Code generation
3.  Running pass 'X86 DAG->DAG Instruction Selection' on function '@main'
clang: error: compiler command failed due to signal 6 (use -v to see invocation)

This is with llvm r76880 and clang r76881
Quuxplusone commented 15 years ago

Attached main.c (365 bytes, text/plain): Code to reproduce bug

Quuxplusone commented 15 years ago
Reduced testcase:

target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-
f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128"
target triple = "x86_64-apple-darwin9.7"

define i32 @main(i32 %argc, i8** nocapture %argv) nounwind {
entry:
    %0 = malloc [3758096384 x i32]      ; <[3758096384 x i32]*> [#uses=0]
    unreachable
}

we're planning to eliminate the malloc instruction in the near future, but this
should still be fixed before that.
Quuxplusone commented 15 years ago

I fixed this crash (r76899), but we're now generating silently incorrect code for this. Victor is working on ripping out the malloc instruciton completely, which is the real fix for this. Please see PR715 to track that work.