ghost
commented
11 years ago @stepancheg This works fine for me on OSX and Linux. Are you using an unmodified clay/master?
Closed stepancheg closed 11 years ago
ghost
commented
11 years ago @stepancheg This works fine for me on OSX and Linux. Are you using an unmodified clay/master?
stepancheg
commented
11 years ago @agemogolk Yes, I'm using clean upstream clay/master, rev 3c3bdada. On 64-bit Ubuntu 12.04 compiling with command:
CC="ccache clang" CXX="ccache clang++" cmake -DLLVM_DIR=$HOME/usr/clang+llvm-3.2-x86_64-linux-ubuntu-12.04 -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCMAKE_CXX_FLAGS="-Wall -ggdb" ..Using clang 3.2 for compilation:
clang++ --version
clang version 3.2 (tags/RELEASE_32/final)
Target: x86_64-unknown-linux-gnu
Thread model: posixBoth clang and llvm downloaded as binary from llvm site.
Compiling test with command executed from ./test directory:
../build/compiler/clay ./lib-clay/parsing/combinators/generic/test.clayAnd I forgot to clarify, that debug version (compiled with -O0) works fine.
ghost
commented
11 years ago I've tried using the same compile options (I don't use ccache - although maybe I should ...) and still no issues. Is that the only test that fails?
jckarter
commented
11 years ago The 'runaway recursion' message is just a warning. Is there an actual error after it, or does it crash?
stepancheg
commented
11 years ago @jckarter It crashes with stack overflow: https://gist.github.com/4488034
jckarter
commented
11 years ago Makes sense, parsing combinators tend to blow the stack. Maybe try increasing ulimit -s.
stepancheg
commented
11 years ago @jckarter setting ulimit -s 64000 instead of default 8192 doesn't help, still crashes.
stepancheg
commented
11 years ago @jckarter @agemogolk have a look at error report I've attached: call to Int32(UInt64) appears multiple times in compilation context. Doesn't it mean that compiler fails to detect recursion somewhere?
stepancheg
commented
11 years ago Hmm, multiple tests fail, and all failing test output contains calls related to integer conversion (like Int32(UInt64) call).
On the other hand, compilation of lib-clay/llvm/intrinsics/main.clay crashes with segmentation fault even with debug clay. Looks like some intrinsic-related code corrupts memory.
[yozh@alpha:~/devel/left/clay/test;master:0]% ../build-debug/compiler/clay lib-clay/llvm/intrinsics/main.claysignal 11!
compilation context:
leadingZeros(UInt64)
lib-clay/llvm/intrinsics/main.clay(11,30):
main()
/Users/yozh/devel/left/clay/build-debug/compiler/../../lib-clay/core/system/system.clay(23,30):
getExitCode()
/Users/yozh/devel/left/clay/build-debug/compiler/../../lib-clay/core/system/system.clay(23,26):
runMain(Int32, Pointer[Pointer[Int8]], Static[main])
/Users/yozh/devel/left/clay/build-debug/compiler/../../lib-clay/core/system/system.clay(39,13):
callMain(Static[main], Int32, Pointer[Pointer[Int8]])
external main
zsh: segmentation fault ../build-debug/compiler/clay lib-clay/llvm/intrinsics/main.clay
[yozh@alpha:~/devel/left/clay/test;master:0]% gdb --args ../build-debug/compiler/clay lib-clay/llvm/intrinsics/main.clay
GNU gdb 6.3.50-20050815 (Apple version gdb-1820) (Sat Jun 16 02:40:11 UTC 2012)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries ... done
(gdb) bt
No stack.
(gdb) r
Starting program: /Users/yozh/devel/left/clay/build-debug/compiler/clay lib-clay/llvm/intrinsics/main.clay
Reading symbols for shared libraries ++............................. done
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
0x0000000100c3d7da in llvm::BumpPtrAllocator::Allocate ()
(gdb) bt
#0 0x0000000100c3d7da in llvm::BumpPtrAllocator::Allocate ()
#1 0x0000000100c142e0 in llvm::FunctionType::get ()
#2 0x0000000100bca040 in llvm::Intrinsic::getType ()
#3 0x0000000100bca2e3 in llvm::Intrinsic::getDeclaration ()
#4 0x00000001000426ac in clay::analyzeIntrinsic (intrin=0x10366d7f0, args=0x104480910) at analyzer.cpp:1960
#5 0x000000010002ce35 in clay::analyzeCallExpr (callable=@0x7fff5fbe1df8, args=@0x7fff5fbe1df0, env=@0x7fff5fbe1de8) at analyzer.cpp:2043
#6 0x0000000100023d5b in clay::analyzeExpr2 (expr=@0x7fff5fbe2110, env=@0x7fff5fbe2108) at analyzer.cpp:795
#7 0x000000010001cd76 in clay::analyzeExpr (expr=@0x7fff5fbe21d0, env=@0x7fff5fbe21c8) at analyzer.cpp:687
#8 0x000000010001c4a3 in clay::analyzeOne (expr=@0x7fff5fbe22c0, env=@0x7fff5fbe22b8) at analyzer.cpp:555
#9 0x00000001000212bb in clay::analyzeMulti2 (exprs=@0x7fff5fbe23f8, env=@0x7fff5fbe23f0, wantCount=0) at analyzer.cpp:538
#10 0x000000010001c9e5 in clay::analyzeMulti (exprs=@0x7fff5fbe29d0, env=@0x7fff5fbe29c8, wantCount=0) at analyzer.cpp:510
#11 0x00000001000451d9 in clay::analyzeStatement (stmt=@0x7fff5fbe2ba8, env=@0x7fff5fbe2ba0, ctx=0x7fff5fbe2bb8) at analyzer.cpp:2598
#12 0x0000000100044d3b in clay::analyzeCodeBody (entry=0x102a70a50) at analyzer.cpp:2482
#13 0x000000010001e40f in clay::analyzeCallable (x=@0x7fff5fbe2fa8, argsKey={Data = 0x10447db40, Length = 1}, argsTempness={Data = 0x10447f7f0, Length = 1}) at analyzer.cpp:2297
#14 0x000000010002c910 in clay::analyzeCallExpr (callable=@0x7fff5fbe3688, args=@0x7fff5fbe3680, env=@0x7fff5fbe3678) at analyzer.cpp:2030
#15 0x0000000100023d5b in clay::analyzeExpr2 (expr=@0x7fff5fbe39a0, env=@0x7fff5fbe3998) at analyzer.cpp:795
#16 0x000000010001cd76 in clay::analyzeExpr (expr=@0x7fff5fbe3a50, env=@0x7fff5fbe3a48) at analyzer.cpp:687
#17 0x0000000100022150 in clay::analyzeArgExpr (x=@0x7fff5fbe3b40, env=@0x7fff5fbe3b38, startIndex=0, dispatchIndices=@0x7fff5fbe4010) at analyzer.cpp:650
#18 0x0000000100021d1f in clay::analyzeOneArg (x=@0x7fff5fbe3c60, env=@0x7fff5fbe3c58, startIndex=0, dispatchIndices=@0x7fff5fbe4010) at analyzer.cpp:628
#19 0x0000000100021ab6 in clay::analyzeMultiArgs2 (exprs=@0x7fff5fbe3d78, env=@0x7fff5fbe3d70, startIndex=0, dispatchIndices=@0x7fff5fbe4010) at analyzer.cpp:613
#20 0x000000010001dded in clay::analyzeMultiArgs (exprs=@0x7fff5fbe3ff8, env=@0x7fff5fbe3ff0, dispatchIndices=@0x7fff5fbe4010) at analyzer.cpp:581
#21 0x000000010002c58f in clay::analyzeCallExpr (callable=@0x7fff5fbe4638, args=@0x7fff5fbe4630, env=@0x7fff5fbe4628) at analyzer.cpp:2019
#22 0x0000000100023d5b in clay::analyzeExpr2 (expr=@0x7fff5fbe4950, env=@0x7fff5fbe4948) at analyzer.cpp:795
#23 0x000000010001cd76 in clay::analyzeExpr (expr=@0x7fff5fbe4a00, env=@0x7fff5fbe49f8) at analyzer.cpp:687
#24 0x0000000100022150 in clay::analyzeArgExpr (x=@0x7fff5fbe4af0, env=@0x7fff5fbe4ae8, startIndex=0, dispatchIndices=@0x7fff5fbe4fc0) at analyzer.cpp:650
#25 0x0000000100021d1f in clay::analyzeOneArg (x=@0x7fff5fbe4c10, env=@0x7fff5fbe4c08, startIndex=0, dispatchIndices=@0x7fff5fbe4fc0) at analyzer.cpp:628
#26 0x0000000100021ab6 in clay::analyzeMultiArgs2 (exprs=@0x7fff5fbe4d28, env=@0x7fff5fbe4d20, startIndex=0, dispatchIndices=@0x7fff5fbe4fc0) at analyzer.cpp:613
#27 0x000000010001dded in clay::analyzeMultiArgs (exprs=@0x7fff5fbe4fa8, env=@0x7fff5fbe4fa0, dispatchIndices=@0x7fff5fbe4fc0) at analyzer.cpp:581
#28 0x000000010002c58f in clay::analyzeCallExpr (callable=@0x7fff5fbe55e8, args=@0x7fff5fbe55e0, env=@0x7fff5fbe55d8) at analyzer.cpp:2019
#29 0x0000000100023d5b in clay::analyzeExpr2 (expr=@0x7fff5fbe5900, env=@0x7fff5fbe58f8) at analyzer.cpp:795
#30 0x000000010001cd76 in clay::analyzeExpr (expr=@0x7fff5fbe5998, env=@0x7fff5fbe5980) at analyzer.cpp:687
#31 0x000000010001cb32 in clay::safeAnalyzeExpr (expr=@0x7fff5fbe5b38, env=@0x7fff5fbe5b30) at analyzer.cpp:437
#32 0x000000010006e607 in clay::codegenExprAsRef2 (expr=@0x7fff5fbe5bf0, env=@0x7fff5fbe5be8, ctx=0x7fff5fbea210) at codegen.cpp:695
#33 0x000000010006c7f8 in clay::codegenExprAsRef (expr=@0x7fff5fbe6c60, env=@0x7fff5fbe6c58, ctx=0x7fff5fbea210) at codegen.cpp:771
#34 0x0000000100068089 in clay::codegenStatement (stmt=@0x7fff5fbe7590, env=@0x7fff5fbe7588, ctx=0x7fff5fbea210) at codegen.cpp:4059
#35 0x00000001000b4c5a in clay::codegenBlockStatement (block=@0x7fff5fbe8e40, i=3, stmt=@0x7fff5fbe8e38, env=@0x7fff5fbe9950, ctx=0x7fff5fbea210, terminated=@0x7fff5fbe8e4f) at codegen.cpp:3679
#36 0x0000000100061ec2 in clay::codegenStatement (stmt=@0x7fff5fbe9958, env=@0x7fff5fbe9950, ctx=0x7fff5fbea210) at codegen.cpp:3756
#37 0x00000001000b0635 in clay::codegenCodeBody (entry=0x1029743c0) at codegen.cpp:3289
#38 0x00000001000a50ef in clay::codegenCallCode (entry=0x1029743c0, args=@0x7fff5fbea870, ctx=0x7fff5fbf78a0, out=@0x7fff5fbea868) at codegen.cpp:2585
#39 0x000000010007b27b in clay::codegenCallExpr (callable=@0x7fff5fbeb320, args=@0x7fff5fbeb318, env=@0x7fff5fbeb310, ctx=0x7fff5fbf78a0, out=@0x7fff5fbeb308) at codegen.cpp:2190
#40 0x0000000100072bdc in clay::codegenExpr (expr=@0x7fff5fbeb6b8, env=@0x7fff5fbeb6b0, ctx=0x7fff5fbf78a0, out=@0x7fff5fbeb6a8) at codegen.cpp:1061
#41 0x000000010006e85a in clay::codegenExprAsRef2 (expr=@0x7fff5fbeb7b0, env=@0x7fff5fbeb7a8, ctx=0x7fff5fbf78a0) at codegen.cpp:701
#42 0x000000010006c7f8 in clay::codegenExprAsRef (expr=@0x7fff5fbeb980, env=@0x7fff5fbeb978, ctx=0x7fff5fbf78a0) at codegen.cpp:771
#43 0x000000010006d9d2 in clay::codegenMultiAsRef (exprs=@0x7fff5fbebbd0, env=@0x7fff5fbebbc8, ctx=0x7fff5fbf78a0) at codegen.cpp:676
#44 0x000000010007b1e7 in clay::codegenCallExpr (callable=@0x7fff5fbec670, args=@0x7fff5fbec668, env=@0x7fff5fbec660, ctx=0x7fff5fbf78a0, out=@0x7fff5fbec658) at codegen.cpp:2189
#45 0x0000000100072bdc in clay::codegenExpr (expr=@0x7fff5fbeca28, env=@0x7fff5fbeca20, ctx=0x7fff5fbf78a0, out=@0x7fff5fbeca18) at codegen.cpp:1061
#46 0x0000000100071191 in clay::codegenExprInto (expr=@0x7fff5fbece58, env=@0x7fff5fbece50, ctx=0x7fff5fbf78a0, out=@0x7fff5fbece48) at codegen.cpp:874
#47 0x000000010006fa5b in clay::codegenMultiInto (exprs=@0x7fff5fbee080, env=@0x7fff5fbee078, ctx=0x7fff5fbf78a0, out=@0x7fff5fbee070, wantCount=1) at codegen.cpp:814
#48 0x0000000100066b9f in clay::codegenStatement (stmt=@0x7fff5fbee7b0, env=@0x7fff5fbee7a8, ctx=0x7fff5fbf78a0) at codegen.cpp:3943
#49 0x00000001000b4c5a in clay::codegenBlockStatement (block=@0x7fff5fbf0060, i=0, stmt=@0x7fff5fbf0058, env=@0x7fff5fbf0e70, ctx=0x7fff5fbf78a0, terminated=@0x7fff5fbf006f) at codegen.cpp:3679
#50 0x0000000100061ec2 in clay::codegenStatement (stmt=@0x7fff5fbf0e78, env=@0x7fff5fbf0e70, ctx=0x7fff5fbf78a0) at codegen.cpp:3756
#51 0x0000000100068f9d in clay::codegenStatement (stmt=@0x7fff5fbf19b0, env=@0x7fff5fbf19a8, ctx=0x7fff5fbf78a0) at codegen.cpp:4167
#52 0x00000001000b4c5a in clay::codegenBlockStatement (block=@0x7fff5fbf3260, i=1, stmt=@0x7fff5fbf3258, env=@0x7fff5fbf35e8, ctx=0x7fff5fbf78a0, terminated=@0x7fff5fbf326f) at codegen.cpp:3679
#53 0x0000000100061ec2 in clay::codegenStatement (stmt=@0x7fff5fbf35f0, env=@0x7fff5fbf35e8, ctx=0x7fff5fbf78a0) at codegen.cpp:3756
#54 0x00000001000a4c46 in clay::codegenCallByName (entry=0x102968508, callable=@0x7fff5fbf3a38, args=@0x7fff5fbf3a30, env=@0x7fff5fbf3a28, ctx=0x7fff5fbf78a0, out=@0x7fff5fbf3a20) at codegen.cpp:3615
#55 0x000000010007afc5 in clay::codegenCallExpr (callable=@0x7fff5fbf44b0, args=@0x7fff5fbf44a8, env=@0x7fff5fbf44a0, ctx=0x7fff5fbf78a0, out=@0x7fff5fbf4498) at codegen.cpp:2185
#56 0x0000000100072bdc in clay::codegenExpr (expr=@0x7fff5fbf4868, env=@0x7fff5fbf4860, ctx=0x7fff5fbf78a0, out=@0x7fff5fbf4858) at codegen.cpp:1061
#57 0x0000000100071191 in clay::codegenExprInto (expr=@0x7fff5fbf4c98, env=@0x7fff5fbf4c90, ctx=0x7fff5fbf78a0, out=@0x7fff5fbf4c88) at codegen.cpp:874
#58 0x000000010006fa5b in clay::codegenMultiInto (exprs=@0x7fff5fbf5ec0, env=@0x7fff5fbf5eb8, ctx=0x7fff5fbf78a0, out=@0x7fff5fbf5eb0, wantCount=1) at codegen.cpp:814
#59 0x0000000100066b9f in clay::codegenStatement (stmt=@0x7fff5fbf6fe8, env=@0x7fff5fbf6fe0, ctx=0x7fff5fbf78a0) at codegen.cpp:3943
#60 0x00000001000b0635 in clay::codegenCodeBody (entry=0x1029683c0) at codegen.cpp:3289
#61 0x00000001000a50ef in clay::codegenCallCode (entry=0x1029683c0, args=@0x7fff5fbf7f00, ctx=0x7fff5fbfcd28, out=@0x7fff5fbf7ef8) at codegen.cpp:2585
#62 0x000000010007b27b in clay::codegenCallExpr (callable=@0x7fff5fbf89b0, args=@0x7fff5fbf89a8, env=@0x7fff5fbf89a0, ctx=0x7fff5fbfcd28, out=@0x7fff5fbf8998) at codegen.cpp:2190
#63 0x0000000100072bdc in clay::codegenExpr (expr=@0x7fff5fbf8d68, env=@0x7fff5fbf8d60, ctx=0x7fff5fbfcd28, out=@0x7fff5fbf8d58) at codegen.cpp:1061
#64 0x0000000100071191 in clay::codegenExprInto (expr=@0x7fff5fbf9198, env=@0x7fff5fbf9190, ctx=0x7fff5fbfcd28, out=@0x7fff5fbf9188) at codegen.cpp:874
#65 0x000000010006fa5b in clay::codegenMultiInto (exprs=@0x7fff5fbfa3c0, env=@0x7fff5fbfa3b8, ctx=0x7fff5fbfcd28, out=@0x7fff5fbfa3b0, wantCount=1) at codegen.cpp:814
#66 0x0000000100066b9f in clay::codegenStatement (stmt=@0x7fff5fbfaaf0, env=@0x7fff5fbfaae8, ctx=0x7fff5fbfcd28) at codegen.cpp:3943
#67 0x00000001000b4c5a in clay::codegenBlockStatement (block=@0x7fff5fbfc3a0, i=0, stmt=@0x7fff5fbfc398, env=@0x7fff5fbfcb40, ctx=0x7fff5fbfcd28, terminated=@0x7fff5fbfc3af) at codegen.cpp:3679
#68 0x0000000100061ec2 in clay::codegenStatement (stmt=@0x7fff5fbfcb48, env=@0x7fff5fbfcb40, ctx=0x7fff5fbfcd28) at codegen.cpp:3756
#69 0x0000000100080db8 in clay::codegenExternalProcedure (x=@0x7fff5fbfd290, codegenBody=true) at codegen.cpp:1705
#70 0x00000001000c43eb in clay::codegenMain (module=@0x7fff5fbfd4d0) at codegen.cpp:7131
#71 0x00000001000c4f96 in clay::codegenEntryPoints (module=@0x7fff5fbfe5d8, importedExternals=true) at codegen.cpp:7170
#72 0x0000000100006c70 in clay::main2 (argc=2, argv=0x7fff5fbff640, envp=0x7fff5fbff658) at clay.cpp:1107
#73 0x000000010027c0bf in clay::parachute (mainfn=0x100001c20 <clay::main2(int, char**, char const* const*)>, argc=2, argv=0x7fff5fbff640, envp=0x7fff5fbff658) at parachute.cpp:85
#74 0x000000010000b6cc in main (argc=2, argv=0x7fff5fbff640, envp=0x7fff5fbff658) at clay.cpp:1227
(gdb) FYI, Valgrind output: https://gist.github.com/40f7232f8edc05a7afe0
jckarter
commented
11 years ago Yeah, the intrinsics module stuff was totally busted by the LLVM 3.2 upgrade because LLVM changed how intrinsics are registered—see #466. Are you sure you aren't picking up a stale lib-clay or some local changes that are causing the infinite recursion? I don't see it either, and it's weird that it would show up for your Linux but not @agemogolk's.
stepancheg
commented
11 years ago Backtrace with Debug+Asserts LLVM: https://gist.github.com/645b431a15ed87dd83d4 . Interesting part is:
(gdb) up
#8 0x0000000000914ca5 in clay::analyzeIntrinsic (intrin=0x40ff4d8,
args=0x513cd20)
at /home/stepancheg/devel/left/clay/compiler/analyzer.cpp:1960
1960 instance.function = llvm::Intrinsic::getDeclaration(llvmModule,
(gdb) list
1955 }
1956 IntrinsicAnalyzer ia(intrin->id, inputTypes);
1957 ia.run();
1958 IntrinsicInstance &instance = intrin->instances[argsKey];
1959 if (ia.outError.empty()) {
1960 instance.function = llvm::Intrinsic::getDeclaration(llvmModule,
1961 intrin->id,
1962 ia.outOverloadedTypes);
1963 instance.outputTypes = intrinsicOutputTypes(instance.function);
1964 return instance.outputTypes;
(gdb) print intrin->id
$10 = llvm::Intrinsic::ctlz
(gdb) print ia.outOverloadedTypes.size()
$11 = 0Is it OK that ia.outOverloadedTypes is empty for ctlz?
stepancheg
commented
11 years ago OK, digging further. There's magic in analyzer.cpp: function VerifyIntrinsicPrototype and GET_INTRINSIC_VERIFIER macro. Funny thing is that
egrep 'VerifyIntrinsicPrototype|GET_INTRINSIC_VERIFIER'outputs several results in llvm-3.1 source directory and none in llvm-3.2 source directory.
jckarter
commented
11 years ago Right, that's the part that got replaced in 3.2. There is a new, cleaner API for looking up intrinsics: look for getIntrinsicInfoTableEntries.
stepancheg
commented
11 years ago About original problem (lib-clay/parsing/combinators/strings/test.clay).
On OSX it is reproduced with clang 3.2 (clang version 3.2 (tags/RELEASE_32/final)), downloaded from LLVM site, but not reproduced with /usr/bin/clang (Apple clang version 4.0 (tags/Apple/clang-421.0.57) (based on LLVM 3.1svn))
On Linux it is also reproduced with clang 3.2, but not reproduced with system gcc (gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3).
stepancheg
commented
11 years ago Minimal code reproducing the problem:
forceinline foo() {
Int64(1);
}
main() {
finally foo();
}Output looks like this:
###############################
errorWithPrintfNoThrow(stringLiteralConcat(
"invalid integer math: " , StaticName(checkedFn)
, "(" , StaticName(T) , ", " , PrintfFmt(U) , ")"),
----------------------------------------------------^
arg2);
return out;
###############################
/Users/yozh/devel/left/clay/build/compiler/../../lib-clay/core/numbers/overflow/overflow.clay(278,52): warning: potential runaway recursion
compilation context:
errorWithPrintfNoThrow(Static["invalid integer math: integerConvertWithOverflow(Int64, %d)"], Int32)
/Users/yozh/devel/left/clay/build/compiler/../../lib-clay/core/numbers/overflow/overflow.clay(276,30):
checked(Static[integerConvertWithOverflow], Static[Int64], Int32)
/Users/yozh/devel/left/clay/build/compiler/../../lib-clay/core/numbers/overflow/overflow.clay(308,13):
doIntegerConvertChecked(Static[Int64], Int32)
/Users/yozh/devel/left/clay/build/compiler/../../lib-clay/core/numbers/numbers.clay(478,27):
Int64(Int32)
./tmp.clay(2,9):
foo()
./tmp.clay(6,15):
errorWithPrintfNoThrow(Static["invalid integer math: integerConvertWithOverflow(Int64, %d)"], Int32)
/Users/yozh/devel/left/clay/build/compiler/../../lib-clay/core/numbers/overflow/overflow.clay(276,30):
checked(Static[integerConvertWithOverflow], Static[Int64], Int32)
/Users/yozh/devel/left/clay/build/compiler/../../lib-clay/core/numbers/overflow/overflow.clay(308,13):
doIntegerConvertChecked(Static[Int64], Int32)
/Users/yozh/devel/left/clay/build/compiler/../../lib-clay/core/numbers/numbers.clay(478,27):
Int64(Int32)
./tmp.clay(2,9):
foo()
...According to this context information, errorWithPrintfNoThrow calls foo, but it does not.
And for the record: I tried clean checkout: https://gist.github.com/acced9a86847103b0fc4 .
ghost
commented
11 years ago FYI, I've managed to reproduce this on Linux using clang-3.2 (apparently cmake requires CXX to be set explicitly rather using env variable).
stepancheg
commented
11 years ago @agemogolk great news (for me).
BTW, CMake uses environement variables CC and CXX. From documentation:
Use for example: CC=gcc-3.3 CXX=g++-3.3 cmake to set the compiler.
ghost
commented
11 years ago That method doesn't seem to work with fish shell. Had to use the -DCMAKE_C/CXX_COMPILER=clang flags.
jckarter
commented
11 years ago Can you see any difference in the -log-match output for a clang 3.2-compiled clay vs a working clay?
jckarter
commented
11 years ago Another thing to try would be to see if clang top-of-trunk has the same problem.
jckarter
commented
11 years ago @agemogolk You can use env as a shell-neutral way to set environment variables in a subprocess: env CXX=clang-3.2 cmake -D...
stepancheg
commented
11 years ago Even smaller code that reproduces the problem:
bar() : {
true;
}
forceinline quux() { }
forceinline foo() : {
quux();
bar();
}
main() {
finally foo();
}OK, I'm not sure if this is clang bug or not, but this patch helps:
diff --git a/compiler/codegen.hpp b/compiler/codegen.hpp
index 7fe6bd5..cb0cd00 100644
--- a/compiler/codegen.hpp
+++ b/compiler/codegen.hpp
@@ -137,7 +137,7 @@ struct CodegenContext {
vector<JumpTarget> continues;
vector<JumpTarget> exceptionTargets;
llvm::Value *exceptionValue;
- int inlineDepth:31;
+ int inlineDepth;
bool checkExceptions:1;
CodegenContext()OK, it is clang bug:
#include <stdio.h>
#include <stdlib.h>
struct foo {
int x:31;
int y:1;
};
void baz(struct foo* f) {
--f->x;
if (!(f->x >= 0))
exit(1);
}
int main() {
struct foo f;
f.x = 1;
f.y = 0;
printf("%d %d\n", f.x, f.y);
baz(&f);
printf("%d %d\n", f.x, f.y);
return 0;
}outputs
1 0
0 0when compiled with -O0 or with older clang, and
1 0
0 -1when compiled with -O2. Going to report it.
stepancheg
commented
11 years ago Bugreport: http://llvm.org/bugs/show_bug.cgi?id=14880
jckarter
commented
11 years ago Thanks for tracking that down @stepancheg. Your workaround patch looks reasonable. The checkExceptions bit could be won back perhaps by cramming it into a PointerIntPair with the exceptionValue.
stepancheg
commented
11 years ago Workaround committed 7ea9f1a212ac7c636eb8ddb9ded708b67412b5c2.
Seen on OSX and on Linux when compiled with -O2.
It is stack overlflow accoring to gdb: https://gist.github.com/4488034