From clattner at apple.com Wed Jul 11 15:57:35 2007 From: clattner at apple.com (Chris Lattner) Date: Wed, 11 Jul 2007 13:57:35 -0700 Subject: [cfe-dev] New LLVM C front-end: "clang" Message-ID: Hi Everyone, I'm happy to say that we just got approval to open source the new C front-end for LLVM we've been working on. The goal of this work is to provide a high quality front-end for LLVM that is built with the same principles as the rest of LLVM (it is built as a set of reusable libraries, integrates well with rest of the LLVM architecture, same license, etc). Among other things, this means that LLVM can now be used for a variety source-level analysis and transformation tasks that it was not suitable for before. For more information about the motivation behind this work, please see Steve's talk at the LLVM '07 developer meeting: http://llvm.org/devmtg/2007-05/09-Naroff-CFE.pdf http://llvm.org/devmtg/2007-05/09-Naroff-CFE.mov Currently, there is not a lot of documentation for the project, but the code is well commented, and there is a README.txt file at the root of the tree with some notes, here: http://llvm.org/svn/llvm- project/cfe/trunk/README.txt While this work aims to provide a fully functional C/C++/ObjC front- end, it is *still very early work*. In particular, there is no real ObjC or C++ support yet (these are obviously big projects), and C support is still missing some features. Some of the more notable missing pieces of C support are: 1. The parser currently skip initializers in braces "int A[] = { 1,2,3,};" without trying to understand them. 2. The semantic analyzer does not produce all of the warnings and errors it should. 3. The LLVM code generator is still very early on. It does not support many important things, like any support for structs and unions. That said, it does handle scalar operations and vectors. 4. We don't consider the API to be stable yet, and reserve the right to change fundamental things :) We plan to continue chipping away at these issues until C works really well, but we'd love help from other interested contributors. I did create a new CFE component in bugzilla, but problems are probably better reported on cfe-dev for now. If you are interested in contributing, or just want to follow along with the project, I recommend signing for the cfe-dev and/or cfe- commits lists: http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits Note that we primed the cfe-commits list will all the revision history of the project, it doesn't normally get this much traffic ;-). If you'd like to check out and build the project, the current scheme is (many thanks to Reid for his help converting our CVS repository to SVN): 1. Check out llvm and build it (the C front-end uses libsupport and libsystem). You don't need llvm-gcc :) 2. cd llvm/tools 3. svn co http://llvm.org/svn/llvm-project/cfe/trunk clang 4. cd clang 5. make We will eventually integrate this better as a sub-project, but for now it builds a single tool named 'clang'. If you're not on a Mac, you'll need to make one change: paths to system header files are currently hard coded into the tool. To get this to work for you, you'll probably have to change clang/Driver/clang.cpp:606 to include the paths that 'touch empty.c; gcc -v empty.c -fsyntax-only' prints (it should list some lines after "#include <...> search starts here:"). Once this is built, you can compile C code (amazing, I know!). The clang driver takes a lot of GCC compatible options, which you can see with 'clang --help'. As a simple example: $ cat ~/t.c typedef float V __attribute__((vector_size(16))); V foo(V a, V b) { return a+b*a; } Preprocessing: $ clang ~/t.c -E # 1 "/Users/sabre/t.c" 1 typedef float V __attribute__((vector_size(16))); V foo(V a, V b) { return a+b*a; } Type checking: $ clang -fsyntax-only ~/t.c GCC options: $ clang -fsyntax-only ~/t.c -pedantic /Users/sabre/t.c:2:17: warning: extension used typedef float V __attribute__((vector_size(16))); ^ 1 diagnostic generated. Pretty printing from the AST: $ clang ~/t.c -parse-ast-print typedef float V __attribute__(( vector_size(16) )); V foo(V a, V b) { return a + b * a; } LLVM code generation: $ clang ~/t.c -emit-llvm | llvm-as | opt -std-compile-opts | llvm-dis define <4 x float> @foo(<4 x float> %a, <4 x float> %b) { entry: %mul = mul <4 x float> %b, %a ; <<4 x float>> [#uses=1] %add = add <4 x float> %mul, %a ; <<4 x float>> [#uses=1] ret <4 x float> %add } $ clang ~/t.c -emit-llvm | llvm-as | opt -std-compile-opts | llc - march=ppc32 -mcpu=g5 .. _foo: vmaddfp v2, v3, v2, v2 blr $ clang ~/t.c -emit-llvm | llvm-as | opt -std-compile-opts | llc - march=x86 -mcpu=yonah .. _foo: mulps %xmm0, %xmm1 addps %xmm0, %xmm1 movaps %xmm1, %xmm0 ret etc. In any case, we welcome questions, comments, and especially patches :). To avoid spamming llvmdev, please take all discussion to the cfe-dev mailing list, and patch submission/discussion to cfe- commits. Thanks! -Chris From greened at obbligato.org Wed Jul 11 19:31:39 2007 From: greened at obbligato.org (David A. Greene) Date: Wed, 11 Jul 2007 19:31:39 -0500 Subject: [cfe-dev] [LLVMdev] New LLVM C front-end: "clang" In-Reply-To: References: Message-ID: <200707111931.39931.greened@obbligato.org> On Wednesday 11 July 2007 15:57, Chris Lattner wrote: > Hi Everyone, > > I'm happy to say that we just got approval to open source the new C > front-end for LLVM we've been working on. This is very good news. One step closer to World Domination. -Dave From onesadcookie at gmail.com Thu Jul 12 04:25:29 2007 From: onesadcookie at gmail.com (Keith Bauer) Date: Thu, 12 Jul 2007 21:25:29 +1200 Subject: [cfe-dev] Pointer Arithmetic Message-ID: I've been working on pointer arithmetic. Attached is a patch which seems to correctly implement (pointer + int), (int + pointer) and (pointer - int). (pointer - pointer) doesn't seem to be possible within the infrastructure that exists, though I'd like confirmation of this. See my comments in the patch. Obviously, since this is my first effort, I'd like comments on what I've done well and what I've (inevitably) done poorly. I'm not really sure of the design or coding conventions of the project. Also, there's no test-cases. I haven't figured out how they're supposed to work yet. -Keith -------------- next part -------------- A non-text attachment was scrubbed... Name: PointerMath.diff Type: application/octet-stream Size: 5429 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20070712/ecc74ec6/attachment.obj From onesadcookie at gmail.com Thu Jul 12 06:56:21 2007 From: onesadcookie at gmail.com (Keith Bauer) Date: Thu, 12 Jul 2007 23:56:21 +1200 Subject: [cfe-dev] Pointer Arithmetic Message-ID: After further reflection, I've realized that the test if (isa(ExprTy)) { in case BinaryOperator::Sub should not detect (pointer - pointer), since the type of that expression should be integral (ptrdiff_t). However, it *is* detecting (pointer - pointer), which is causing at least one of the problems I had with implementing it... Where is that expression's type coming from? -Keith From snaroff at apple.com Thu Jul 12 09:17:07 2007 From: snaroff at apple.com (Steve Naroff) Date: Thu, 12 Jul 2007 07:17:07 -0700 Subject: [cfe-dev] Pointer Arithmetic In-Reply-To: References: Message-ID: + // How does one find the size of a QualType, or the llvm::Type it + // corresponds to? Keith, Currently, clang::BuiltinType is the only type that knows it's size (see getSize()). Eventually, getSize() will be implemented by clang::Type (the root of the type hierarchy). The main "gotcha" (with implementing it in Type) is struct layout (which is none trivial and target specific). snaroff On Jul 12, 2007, at 2:25 AM, Keith Bauer wrote: > I've been working on pointer arithmetic. Attached is a patch which > seems to correctly implement (pointer + int), (int + pointer) and > (pointer - int). (pointer - pointer) doesn't seem to be possible > within the infrastructure that exists, though I'd like confirmation of > this. See my comments in the patch. > > Obviously, since this is my first effort, I'd like comments on what > I've done well and what I've (inevitably) done poorly. I'm not really > sure of the design or coding conventions of the project. > > Also, there's no test-cases. I haven't figured out how they're > supposed to work yet. > > -Keith > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From clattner at apple.com Thu Jul 12 10:46:59 2007 From: clattner at apple.com (Chris Lattner) Date: Thu, 12 Jul 2007 08:46:59 -0700 Subject: [cfe-dev] Pointer Arithmetic In-Reply-To: References: Message-ID: On Jul 12, 2007, at 4:56 AM, Keith Bauer wrote: > After further reflection, I've realized that the test > > if (isa(ExprTy)) { > > in > > case BinaryOperator::Sub > > should not detect (pointer - pointer), since the type of that > expression should be integral (ptrdiff_t). However, it *is* detecting > (pointer - pointer), which is causing at least one of the problems I > had with implementing it... > > Where is that expression's type coming from? This looks like a bug in the semantic analyzer for -. Take a look at Sema/SemaExpr.cpp:819. -Chris From gabor at mac.com Thu Jul 12 10:52:30 2007 From: gabor at mac.com (Gabor Greif) Date: Thu, 12 Jul 2007 17:52:30 +0200 Subject: [cfe-dev] New LLVM C front-end: "clang" Message-ID: <46964E3E.8060308@mac.com> I normally build in a separate builddir and after reconfiguring I got: ggreif at my [!734] cd llvm-buil/tools/ ggreif at my [!735] ls clang/ Basic Makefile ggreif at my [!737] cd clang/ ggreif at my [!738] make make[1]: Entering directory `/home/ggreif/llvm-build/tools/clang/Basic' llvm[1]: Compiling SourceManager.cpp for Release build /home/ggreif/llvm/tools/clang/Basic/SourceManager.cpp: In function `const llvm::MemoryBuffer* ReadFileFast(const clang::FileEntry*)': /home/ggreif/llvm/tools/clang/Basic/SourceManager.cpp:63: error: `::open' has not been declared make[1]: *** [/home/ggreif/llvm-build/tools/clang/Basic/Release/SourceManager.o] Error 1 make[1]: Leaving directory `/home/ggreif/llvm-build/tools/clang/Basic' make: *** [all] Error 1 Any clues? Cheers, Gabor From clattner at apple.com Thu Jul 12 11:42:12 2007 From: clattner at apple.com (Chris Lattner) Date: Thu, 12 Jul 2007 09:42:12 -0700 Subject: [cfe-dev] New LLVM C front-end: "clang" In-Reply-To: <46964E3E.8060308@mac.com> References: <46964E3E.8060308@mac.com> Message-ID: On Jul 12, 2007, at 8:52 AM, Gabor Greif wrote: > I normally build in a separate builddir and > after reconfiguring I got: > > ggreif at my [!734] cd llvm-buil/tools/ > ggreif at my [!735] ls clang/ > Basic Makefile > ggreif at my [!737] cd clang/ > ggreif at my [!738] make > make[1]: Entering directory `/home/ggreif/llvm-build/tools/clang/ > Basic' > llvm[1]: Compiling SourceManager.cpp for Release build > /home/ggreif/llvm/tools/clang/Basic/SourceManager.cpp: In function > `const llvm::MemoryBuffer* ReadFileFast(const clang::FileEntry*)': > /home/ggreif/llvm/tools/clang/Basic/SourceManager.cpp:63: error: > `::open' has not been declared > make[1]: *** [/home/ggreif/llvm-build/tools/clang/Basic/Release/ > SourceManager.o] Error 1 > make[1]: Leaving directory `/home/ggreif/llvm-build/tools/clang/Basic' > make: *** [all] Error 1 Yep, you're stuck in a quagmire of code that should be removed once libsystem gets a bit smarter. Does it build correctly if you add "#include " at line 45 of that file? -Chris From onesadcookie at gmail.com Thu Jul 12 18:49:37 2007 From: onesadcookie at gmail.com (Keith Bauer) Date: Fri, 13 Jul 2007 11:49:37 +1200 Subject: [cfe-dev] Pointer Arithmetic In-Reply-To: References: Message-ID: OK, a new patch, with apparently-working (pointer - pointer) too. I've made getSize virtual in clang::Type (default implementation asserts, and it should become pure virtual when it's implemented for all the subclasses) and renamed the conflicting getSize in clang::ArrayType to getSizeExpr. I've added a getPointerDiffType alongside getSizeType, and updated SemaExpr to return that type for (pointer - pointer). There's a test case which checks that errors are generated or not as appropriate in all cases (tests/Parser/pointer-arithmetic.c). Again, criticism is welcome ;) -Keith -------------- next part -------------- A non-text attachment was scrubbed... Name: PointerArithmetic.diff Type: application/octet-stream Size: 12810 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20070713/33b03a4a/attachment.obj From onesadcookie at gmail.com Thu Jul 12 18:53:20 2007 From: onesadcookie at gmail.com (Keith Bauer) Date: Fri, 13 Jul 2007 11:53:20 +1200 Subject: [cfe-dev] Pointer Arithmetic In-Reply-To: References: Message-ID: Should also say, whilst I'm here, it compiles: int *test1(int *a) { return a + 1; } int *test2(int *a) { return 1 + a; } int *test3(int *a) { return a - 1; } int test4(int *a, int *b) { return a - b; } into: ; ModuleID = 'foo' define i32* @test1(i32* %a) { entry: %a.addr = alloca i32* ; [#uses=2] %allocapt = bitcast i32 undef to i32 ; [#uses=0] store i32* %a, i32** %a.addr %tmp = load i32** %a.addr ; [#uses=1] %add.ptr = getelementptr i32* %tmp, i32 1 ; [#uses=1] ret i32* %add.ptr ; No predecessors! ret i32* undef } define i32* @test2(i32* %a) { entry: %a.addr = alloca i32* ; [#uses=2] %allocapt = bitcast i32 undef to i32 ; [#uses=0] store i32* %a, i32** %a.addr %tmp = load i32** %a.addr ; [#uses=1] %add.ptr = getelementptr i32* %tmp, i32 1 ; [#uses=1] ret i32* %add.ptr ; No predecessors! ret i32* undef } define i32* @test3(i32* %a) { entry: %a.addr = alloca i32* ; [#uses=2] %allocapt = bitcast i32 undef to i32 ; [#uses=0] store i32* %a, i32** %a.addr %tmp = load i32** %a.addr ; [#uses=1] %sub.ptr.neg = sub i32 0, 1 ; [#uses=1] %sub.ptr = getelementptr i32* %tmp, i32 %sub.ptr.neg ; [#uses=1] ret i32* %sub.ptr ; No predecessors! ret i32* undef } define i32 @test4(i32* %a, i32* %b) { entry: %a.addr = alloca i32* ; [#uses=2] %b.addr = alloca i32* ; [#uses=2] %allocapt = bitcast i32 undef to i32 ; [#uses=0] store i32* %a, i32** %a.addr store i32* %b, i32** %b.addr %tmp = load i32** %a.addr ; [#uses=1] %tmp1 = load i32** %b.addr ; [#uses=1] %sub.ptr.lhs.cast = ptrtoint i32* %tmp to i32 ; [#uses=1] %sub.ptr.rhs.cast = ptrtoint i32* %tmp1 to i32 ; [#uses=1] %sub.ptr.sub = sub i32 %sub.ptr.lhs.cast, %sub.ptr.rhs.cast ; [#uses=1] %sub.ptr.div = sdiv i32 %sub.ptr.sub, 4 ; [#uses=1] ret i32 %sub.ptr.div ; No predecessors! ret i32 undef } which gets optimized to: ; ModuleID = '' define i32* @test1(i32* %a) { entry: %add.ptr = getelementptr i32* %a, i32 1 ; [#uses=1] ret i32* %add.ptr } define i32* @test2(i32* %a) { entry: %add.ptr = getelementptr i32* %a, i32 1 ; [#uses=1] ret i32* %add.ptr } define i32* @test3(i32* %a) { entry: %sub.ptr = getelementptr i32* %a, i32 -1 ; [#uses=1] ret i32* %sub.ptr } define i32 @test4(i32* %a, i32* %b) { entry: %sub.ptr.lhs.cast = ptrtoint i32* %a to i32 ; [#uses=1] %sub.ptr.rhs.cast = ptrtoint i32* %b to i32 ; [#uses=1] %sub.ptr.sub = sub i32 %sub.ptr.lhs.cast, %sub.ptr.rhs.cast ; [#uses=1] %sub.ptr.div = sdiv i32 %sub.ptr.sub, 4 ; [#uses=1] ret i32 %sub.ptr.div } (I guess the div can't be optimized to a shift because it's signed division?) -Keith From clattner at apple.com Thu Jul 12 19:06:58 2007 From: clattner at apple.com (Chris Lattner) Date: Thu, 12 Jul 2007 17:06:58 -0700 Subject: [cfe-dev] Pointer Arithmetic In-Reply-To: References: Message-ID: <8B604B6C-F48B-497B-A19D-4F74B30D3F52@apple.com> On Jul 12, 2007, at 4:49 PM, Keith Bauer wrote: > OK, a new patch, with apparently-working (pointer - pointer) too. > > I've made getSize virtual in clang::Type (default implementation > asserts, and it should become pure virtual when it's implemented for > all the subclasses) and renamed the conflicting getSize in > clang::ArrayType to getSizeExpr. > > I've added a getPointerDiffType alongside getSizeType, and updated > SemaExpr to return that type for (pointer - pointer). > > There's a test case which checks that errors are generated or not as > appropriate in all cases (tests/Parser/pointer-arithmetic.c). > > Again, criticism is welcome ;) Cool, this is looking really good. Minor (pedantic) comments: + /// the number of bits to represent the type. + // currently only implemented for BuiltinType -- the base implementation + // asserts. Should become pure virtual in future. + virtual unsigned getSize() const; The nearby code is a bit inconsistent, but please format the comment like this: + /// getSize - the number of bits to represent the type. + virtual unsigned getSize() const; In addition, please make it non-virtual, implemented in Type.cpp. For type predicates, we tend to implement them in terms of switch statements on the canonical type (see the other predicates for examples). We prefer non-virtual methods because we have vague plans to eliminate the vtable pointer at some point, and this keeps related code together in the same method. From a philosophical software engineering perspective, virtual methods are great when you have a class hierarchy that often changes. The C type system doesn't often change, so we're ok :) + // On Darwin, ptrdiff_t is defined as a "int". This seems silly, so I'm + // using "long" instead... + // FIXME: should derive from "Target". + return LongTy; Please use int :) bool Type::isConstantSizeType(SourceLocation *loc) const { if (const ArrayType *Ary = dyn_cast(CanonicalType)) { - assert(Ary->getSize() && "Incomplete types don't have a size at all!"); - return Ary->getSize()->isIntegerConstantExpr(loc); // Variable Length Array? + assert(Ary->getSizeExpr() && "Incomplete types don't have a size at all!"); + return Ary->getSizeExpr()->isIntegerConstantExpr(loc); // Variable Length Array? } Please keep the code in 80 columns. I'm not a stickler about testcases fitting in 80 columns, but the C++ code should. RValue EmitDiv(RValue LHS, RValue RHS, QualType EltTy); RValue EmitRem(RValue LHS, RValue RHS, QualType EltTy); RValue EmitAdd(RValue LHS, RValue RHS, QualType EltTy); + RValue EmitPointerAdd(RValue LHS, QualType LHSTy, RValue RHS, QualType RHSTy, QualType EltTy); RValue EmitSub(RValue LHS, RValue RHS, QualType EltTy); + RValue EmitPointerSub(RValue LHS, QualType LHSTy, RValue RHS, QualType RHSTy, QualType EltTy); RValue EmitShl(RValue LHS, RValue RHS, QualType ResTy); likewise. + case BinaryOperator::Add: { + QualType ExprTy = E->getType(); + if (isa(ExprTy)) { + Expr *LHSExpr = E->getLHS(); This won't work correctly if you're adding to a typedef for a pointer. Because of the way we handle typedefs, you should always strip off typedef information, by using ExprTy.getCanonicalType(), like this: + case BinaryOperator::Add: { + QualType ExprTy = E->getType(); + if (isa(ExprTy.getCanonicalType())) { + Expr *LHSExpr = E->getLHS(); You can think of this as "looking through" any typedefs if present to find the actual underlying type. Alternatively, there are some predicates on type that do this for you, which are even better to use when suitable. This would make the code be: + case BinaryOperator::Add: { + QualType ExprTy = E->getType(); + if (ExprTy->isPointerType()) { + Expr *LHSExpr = E->getLHS(); + case BinaryOperator::Sub: { + QualType ExprTy = E->getType(); + Expr *LHSExpr = E->getLHS(); + if (isa(LHSExpr->getType())) { +RValue CodeGenFunction::EmitPointerAdd(RValue LHS, QualType LHSTy, RValue RHS, QualType RHSTy, QualType ResTy) { + llvm::Value *LHSValue = LHS.getVal(); + llvm::Value *RHSValue = RHS.getVal(); + if (isa(LHSTy.getTypePtr())) { likewise, these should check Ty->isPointerType(). In the second case, you don't need to call getTypePtr(). +RValue CodeGenFunction::EmitPointerAdd(RValue LHS, QualType LHSTy, RValue RHS, QualType RHSTy, QualType ResTy) { +RValue CodeGenFunction::EmitPointerSub(RValue LHS, QualType LHSTy, RValue RHS, QualType RHSTy, QualType ResTy) { ... please keep these in 80 cols. For this case: +RValue CodeGenFunction::EmitPointerSub(RValue LHS, QualType LHSTy, RValue RHS, QualType RHSTy, QualType ResTy) { + llvm::Value *LHSValue = LHS.getVal(); + llvm::Value *RHSValue = RHS.getVal(); + const PointerType *RHSPtrType = dyn_cast (RHSTy.getTypePtr()); + if (RHSPtrType != NULL) { I suggest writing this as: + if (const PointerType *RHSPtrType = dyn_cast (RHSTy.getQualifiedType())) { + // do we care about non-8-bit bytes? Why is getSize returning bits? 1) no. 2) so we have a consistent measure of size, which works for bitfields and other things. Dividing by 8 here is good, but please update the comment. + // is signed division correct? Yep :) For example: int A[10]; int *B = &A[0], *C = &A[4]; C-B -> 4 B-C -> -4 Please update the patch and resend it, it's very close. Thanks! -Chris From clattner at apple.com Thu Jul 12 19:07:43 2007 From: clattner at apple.com (Chris Lattner) Date: Thu, 12 Jul 2007 17:07:43 -0700 Subject: [cfe-dev] Pointer Arithmetic In-Reply-To: References: Message-ID: <052C4E09-7C18-4F01-A402-ED40AF120EAE@apple.com> On Jul 12, 2007, at 4:53 PM, Keith Bauer wrote: > define i32 @test4(i32* %a, i32* %b) { > entry: > %sub.ptr.lhs.cast = ptrtoint i32* %a to i32 ; [#uses=1] > %sub.ptr.rhs.cast = ptrtoint i32* %b to i32 ; [#uses=1] > %sub.ptr.sub = sub i32 %sub.ptr.lhs.cast, %sub.ptr.rhs.cast ; > [#uses=1] > %sub.ptr.div = sdiv i32 %sub.ptr.sub, 4 ; [#uses=1] > ret i32 %sub.ptr.div > } > > (I guess the div can't be optimized to a shift because it's signed > division?) > Yep, this is right. In the future, LLVM may get some way to represent "exact division" which is useful for pointer subtraction. When it has that, it will be able to simplify this. -Chris From onesadcookie at gmail.com Thu Jul 12 22:14:07 2007 From: onesadcookie at gmail.com (Keith Bauer) Date: Fri, 13 Jul 2007 15:14:07 +1200 Subject: [cfe-dev] Trivial patch to fix codegen for int-to-pointer cast Message-ID: Someone typed "PtrToInt" where they meant "IntToPtr". I've added a tests/CodeGen directory, and a test for this case that used to fail and now passes. -Keith -------------- next part -------------- A non-text attachment was scrubbed... Name: IntToPointer.diff Type: application/octet-stream Size: 1296 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20070713/3a0f2b24/attachment.obj From onesadcookie at gmail.com Thu Jul 12 23:58:00 2007 From: onesadcookie at gmail.com (Keith Bauer) Date: Fri, 13 Jul 2007 16:58:00 +1200 Subject: [cfe-dev] Codegen for Character Literals and Conditional Operator Message-ID: Both in one patch, and the test case that Chris didn't commit last time is in there too... I'll split the patch up if somebody wants it split. -Keith -------------- next part -------------- A non-text attachment was scrubbed... Name: CharacterLiteralsAndConditionalOperator.diff Type: application/octet-stream Size: 5705 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20070713/30fdfaf1/attachment.obj From isanbard at gmail.com Fri Jul 13 00:04:39 2007 From: isanbard at gmail.com (Bill Wendling) Date: Thu, 12 Jul 2007 22:04:39 -0700 Subject: [cfe-dev] Patch for References Message-ID: Hi all, Here's a patch to correct some reference problems. We weren't accounting for references to functions and references to arrays. So something like this would produce errors: int g(int); void f() { int (&rg)(int) = g; rg(i); // Error int a[3]; int (&ra)[3] = a; ra[1] = i; // Error } Okay to commit? -bw -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff.txt Url: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20070712/d580cf6e/attachment.txt From clattner at apple.com Fri Jul 13 00:18:44 2007 From: clattner at apple.com (Chris Lattner) Date: Thu, 12 Jul 2007 22:18:44 -0700 Subject: [cfe-dev] Codegen for Character Literals and Conditional Operator In-Reply-To: References: Message-ID: On Jul 12, 2007, at 9:58 PM, Keith Bauer wrote: > Both in one patch, and the test case that Chris didn't commit last > time is in there too... > > I'll split the patch up if somebody wants it split. Splitting it up is good in that it lets us apply patches independently. I applied the patch, but here are some comments for follow-up: @@ -291,8 +292,14 @@ } void StmtPrinter::VisitCharacterLiteral(CharacterLiteral *Node) { - // FIXME: print value. - OS << "x"; + unsigned value = Node->getValue(); + if (isprint(value)) { + OS << "'" << (char)value << "'"; + } else { + // FIXME something to indicate this is a character literal? + OS << std::hex << std::setiosflags(std::ios_base::showbase) << value + << std::dec << std::resetiosflags(std::ios_base::showbase); + } } This should only print the 'x' syntax if the type is 'char'. If it is something else, it should print L'x'. For the fixme, you could print it as charliteral(0x1235) or something. Also, your ?: code won't work correctly for structs. That's ok, because structs are completely unimplemented, but please add a fixme. -Chris From clattner at apple.com Fri Jul 13 00:29:00 2007 From: clattner at apple.com (Chris Lattner) Date: Thu, 12 Jul 2007 22:29:00 -0700 Subject: [cfe-dev] Patch for References In-Reply-To: References: Message-ID: <7B98DFF2-22B7-45A4-BDF6-A9F7F6F7E83E@apple.com> On Jul 12, 2007, at 10:04 PM, Bill Wendling wrote: > Hi all, > > Here's a patch to correct some reference problems. We weren't > accounting for references to functions and references to arrays. So > something like this would produce errors: > > int g(int); > > void f() { > int (&rg)(int) = g; > rg(i); // Error > > int a[3]; > int (&ra)[3] = a; > ra[1] = i; // Error > } > > Okay to commit? + if (isa(TR.getCanonicalType())) // C++ 3.10p5 references + return LV_Valid; This citation doesn't make sense, it's talking about function results, not references in general. + } else if (isa(canonT1)) { + // C++ 8.5.3p1: A reference to an array. + baseType = canonT1; + indexType = canonT2; + baseExpr = static_cast(Base); + indexExpr = static_cast(Idx); + } else if (isa(canonT2)) { // uncommon + // C++ 8.5.3p1: A reference to an array. + baseType = canonT2; + indexType = canonT1; + baseExpr = static_cast(Idx); + indexExpr = static_cast(Base); This doesn't make sense to me. Wouldn't it be incorrect for: int *Q; int *&P = Q; P[1]; ? -Chris From isanbard at gmail.com Fri Jul 13 01:51:42 2007 From: isanbard at gmail.com (Bill Wendling) Date: Thu, 12 Jul 2007 23:51:42 -0700 Subject: [cfe-dev] Patch for References In-Reply-To: <7B98DFF2-22B7-45A4-BDF6-A9F7F6F7E83E@apple.com> References: <7B98DFF2-22B7-45A4-BDF6-A9F7F6F7E83E@apple.com> Message-ID: <07FD7140-1ECC-40F6-B3EB-6C50C85E2083@gmail.com> On Jul 12, 2007, at 10:29 PM, Chris Lattner wrote: > + if (isa(TR.getCanonicalType())) // C++ 3.10p5 > references > + return LV_Valid; > > This citation doesn't make sense, it's talking about function > results, not references in general. > True. I'll come up with a better citation. (The reason that one was there is because I found this error while trying to compile a call to a function that returns a reference.) > + } else if (isa(canonT1)) { > + // C++ 8.5.3p1: A reference to an array. > + baseType = canonT1; > + indexType = canonT2; > + baseExpr = static_cast(Base); > + indexExpr = static_cast(Idx); > + } else if (isa(canonT2)) { // uncommon > + // C++ 8.5.3p1: A reference to an array. > + baseType = canonT2; > + indexType = canonT1; > + baseExpr = static_cast(Idx); > + indexExpr = static_cast(Base); > > This doesn't make sense to me. Wouldn't it be incorrect for: > > int *Q; > int *&P = Q; > > P[1]; > > ? > True. How about this? Index: SemaExpr.cpp =================================================================== --- SemaExpr.cpp (revision 39794) +++ SemaExpr.cpp (working copy) @@ -291,9 +291,10 @@ // to the expression *((e1)+(e2)). This means the array "Base" may actually be // in the subscript position. As a result, we need to derive the array base // and index from the expression types. - + Expr *baseExpr, *indexExpr; QualType baseType, indexType; + QualType resultType; if (isa(canonT1) || isa(canonT1)) { baseType = canonT1; indexType = canonT2; @@ -304,6 +305,35 @@ indexType = canonT1; baseExpr = static_cast(Idx); indexExpr = static_cast(Base); + } else if (isa(canonT1)) { + // C++ 8.5.3p1: A reference to an array. + ReferenceType *ref = dyn_cast(canonT1); + + if (ArrayType *arr = dyn_cast(ref->getReferenceeType ())) { + resultType = arr->getElementType(); + baseType = canonT1; + } else { + baseType = ref->getReferenceeType(); + } + + indexType = canonT2; + baseExpr = static_cast(Base); + indexExpr = static_cast(Idx); + } else if (isa(canonT2)) { // uncommon + // C++ 8.5.3p1: A reference to an array. + ReferenceType *ref = dyn_cast(canonT2); + + if (ArrayType *arr = dyn_cast(ref->getReferenceeType ())) { + resultType = arr->getElementType(); + baseType = canonT2; + } else { + baseType = ref->getReferenceeType(); + } + + baseType = canonT2; + indexType = canonT1; + baseExpr = static_cast(Idx); + indexExpr = static_cast(Base); } else { return Diag(static_cast(Base)->getLocStart(), diag::err_typecheck_subscript_value, @@ -314,7 +344,6 @@ return Diag(indexExpr->getLocStart(), diag::err_typecheck_subscript, indexExpr->getSourceRange()); } - QualType resultType; if (PointerType *ary = dyn_cast(baseType)) { // FIXME: need to deal with const... resultType = ary->getPointeeType(); -bw From clattner at apple.com Fri Jul 13 11:39:56 2007 From: clattner at apple.com (Chris Lattner) Date: Fri, 13 Jul 2007 09:39:56 -0700 Subject: [cfe-dev] Patch for References In-Reply-To: <07FD7140-1ECC-40F6-B3EB-6C50C85E2083@gmail.com> References: <7B98DFF2-22B7-45A4-BDF6-A9F7F6F7E83E@apple.com> <07FD7140-1ECC-40F6-B3EB-6C50C85E2083@gmail.com> Message-ID: <45FEF0A7-FECF-4461-AB06-647A4F80DC5D@apple.com> > True. How about this? I still don't think this is right. Nothing in the subscript operator should care about arrays. You should rely on the usual unary conversions for decaying the array to a pointer. Perhaps you need to implement usual unary conversions for references? -Chris From onesadcookie at gmail.com Fri Jul 13 18:44:33 2007 From: onesadcookie at gmail.com (Keith Bauer) Date: Sat, 14 Jul 2007 11:44:33 +1200 Subject: [cfe-dev] Codegen for Character Literals and Conditional Operator In-Reply-To: References: Message-ID: Attached are patches to fix character literal printing (though there's still a slightly-less-than-desirable case that maybe should use a \u escape?) and assert when you try to ?: with an aggregate type, as requested. -Keith -------------- next part -------------- A non-text attachment was scrubbed... Name: CharacterLiteralPrinting.diff Type: application/octet-stream Size: 2817 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20070714/6261288f/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: ConditionalAggregateAssert.diff Type: application/octet-stream Size: 540 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20070714/6261288f/attachment-0001.obj From clattner at apple.com Fri Jul 13 19:01:28 2007 From: clattner at apple.com (Chris Lattner) Date: Fri, 13 Jul 2007 17:01:28 -0700 Subject: [cfe-dev] Codegen for Character Literals and Conditional Operator In-Reply-To: References: Message-ID: <6FF69B6F-CA88-4A3C-BA62-5C1D558D9C97@apple.com> On Jul 13, 2007, at 4:44 PM, Keith Bauer wrote: > Attached are patches to fix character literal printing (though there's > still a slightly-less-than-desirable case that maybe should use a \u > escape?) and assert when you try to ?: with an aggregate type, as > requested. > > -Keith > > Thanks, I applied the first one: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of- Mon-20070709/001243.html The second one isn't quite right. "Scalar" types in C include complex numbers, which are "aggregate" types according to LLVM (and to the LLVM lowering stuff). The correct predicate would be RValue::isScalar() (which checks to see whether it's an LLVM scalar type). However, getVal() already checks this, so this is already checked. I don't think it's worth adding another explicit check. I did add this fixme though: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of- Mon-20070709/001244.html Thanks for the patches! -Chris From isanbard at gmail.com Sat Jul 14 04:25:56 2007 From: isanbard at gmail.com (Bill Wendling) Date: Sat, 14 Jul 2007 02:25:56 -0700 Subject: [cfe-dev] Patch for References In-Reply-To: <45FEF0A7-FECF-4461-AB06-647A4F80DC5D@apple.com> References: <7B98DFF2-22B7-45A4-BDF6-A9F7F6F7E83E@apple.com> <07FD7140-1ECC-40F6-B3EB-6C50C85E2083@gmail.com> <45FEF0A7-FECF-4461-AB06-647A4F80DC5D@apple.com> Message-ID: <1CC99EC3-5EE2-4095-A222-22EDD1864A4B@gmail.com> On Jul 13, 2007, at 9:39 AM, Chris Lattner wrote: > I still don't think this is right. Nothing in the subscript > operator should care about arrays. You should rely on the usual > unary conversions for decaying the array to a pointer. Perhaps you > need to implement usual unary conversions for references? Ah! I understand what you're saying now. Here's a new patch submission. I think it does the correct thing now. I even have the correct standard citation. :-) -bw -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff.txt Url: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20070714/f2510f0c/attachment.txt -------------- next part -------------- From doug.gregor at gmail.com Sun Jul 15 22:35:43 2007 From: doug.gregor at gmail.com (Douglas Gregor) Date: Sun, 15 Jul 2007 23:35:43 -0400 Subject: [cfe-dev] C++0x flags/keywords Message-ID: <1978CF3F-E8CD-4B58-B1FF-74F65A69769D@osl.iu.edu> The attached patch adds all of the various bits to introduce a C++0x dialect into Clang, including the dialect option, C++0x keywords, and command-line switches for the driver. While adding keywords, I ran into this confusing bit: KEYWORD(_Complex , EXTC90) // C99/C++ _Complex isn't part of C++, so shouldn't this be marked EXTC99|EXTCPP| EXTCPP0x? When running "make test" in the clang directory, I get a lot of output that includes several "FAILED!" indicators. Should I expect the output of "make test" to be clean, with no errors? Is there a simple way to get a count of tests run/errors/etc. (aside from grep)? - Doug -------------- next part -------------- A non-text attachment was scrubbed... Name: clang-cxx0x-mode.patch Type: application/octet-stream Size: 10048 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20070715/e137bb05/attachment.obj From andersca at mac.com Sun Jul 15 23:05:02 2007 From: andersca at mac.com (Anders Carlsson) Date: Sun, 15 Jul 2007 21:05:02 -0700 Subject: [cfe-dev] Patch: Implement break and continue Message-ID: <6B85AB52-3218-43FE-B73E-5B6C851B4974@mac.com> Hello, here's a patch that implements break and continue in for, while and do loops. Since this is my first encounter ever with LLVM and cfe, the patch could very well be completely wrong :) I'd love any feedback it though. Regards, Anders -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: break-continue-in-loops.txt Url: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20070715/fdc7014a/attachment.txt From clattner at apple.com Sun Jul 15 23:24:51 2007 From: clattner at apple.com (Chris Lattner) Date: Sun, 15 Jul 2007 21:24:51 -0700 Subject: [cfe-dev] C++0x flags/keywords In-Reply-To: <1978CF3F-E8CD-4B58-B1FF-74F65A69769D@osl.iu.edu> References: <1978CF3F-E8CD-4B58-B1FF-74F65A69769D@osl.iu.edu> Message-ID: <9A10243A-DEFC-4660-9719-F0D1C11B57EF@apple.com> On Jul 15, 2007, at 8:35 PM, Douglas Gregor wrote: > The attached patch adds all of the various bits to introduce a C+ > +0x dialect into Clang, including the dialect option, C++0x > keywords, and command-line switches for the driver. Thanks, applied! > While adding keywords, I ran into this confusing bit: > > KEYWORD(_Complex , EXTC90) // C99/C++ > > _Complex isn't part of C++, so shouldn't this be marked EXTC99| > EXTCPP|EXTCPP0x? You're right. Interesting mistake, I've corrected it, thanks! > When running "make test" in the clang directory, I get a lot of > output that includes several "FAILED!" indicators. Should I expect > the output of "make test" to be clean, with no errors? Is there a > simple way to get a count of tests run/errors/etc. (aside from grep)? You should only get a single failure, which is xfailed: XFAILED 'Parser/expressions.c': // XFAIL: * ******************** TEST 'Parser/expressions.c' FAILED! ******************** Command: clang -fsyntax-only Parser/expressions.c Output: Output/expressions.c.out.script: line 1: 10038 Bus error clang -fsyntax-only Parser/expressions.c ******************** TEST 'Parser/expressions.c' FAILED! ******************** One "undocumented feature" of the test suite is that you have to add llvm/test/Scripts to your path for it to run correctly. I will see if I can make this happen as a side effect of make test. Thanks for pointing this out. -Chris From clattner at apple.com Mon Jul 16 00:02:18 2007 From: clattner at apple.com (Chris Lattner) Date: Sun, 15 Jul 2007 22:02:18 -0700 Subject: [cfe-dev] Patch: Implement break and continue In-Reply-To: <6B85AB52-3218-43FE-B73E-5B6C851B4974@mac.com> References: <6B85AB52-3218-43FE-B73E-5B6C851B4974@mac.com> Message-ID: <0FC0B8E7-C9EF-4F58-9093-E0E6B20F7177@apple.com> On Jul 15, 2007, at 9:05 PM, Anders Carlsson wrote: > Hello, > here's a patch that implements break and continue in for, while and > do loops. > > Since this is my first encounter ever with LLVM and cfe, the patch > could very well be completely wrong :) I'd love any feedback it > though. I have to say that this is *not* how I envisioned implementing this: it's actually a much better approach. Overall, I really like the patch. Some suggestions: 1. Instead of having separate break/continue stacks, I'd suggest merging them and using a SmallVector (or a custom struct instead of a pair if you prefer). For switch stmts (when we support them), we'd just use null as the continue point. 2. Two minor style issues: +void CodeGenFunction::EmitBreakStmt() +{ Please put the { on the same line as the function. + assert(!BreakStack.empty()); Please include some sort of message in the assert so that we know "why" that condition should be true. This doesn't need to be something particularly deep, just something like this should be sufficient: + assert(!BreakStack.empty() && "break stmt not in a loop or switch?"); 3. Some extremely minor typographic stuff: Minor typo: "foo": + // If the foor loop doesn't have an increment we can just use the Please end sentences with a period: :) + // If the foor loop doesn't have an increment we can just use the + // condition as the continue block Otherwise the patch looks great. Please update and resubmit, (not bad for a first encounter ;-) -Chris From isanbard at gmail.com Mon Jul 16 00:18:04 2007 From: isanbard at gmail.com (Bill Wendling) Date: Sun, 15 Jul 2007 22:18:04 -0700 Subject: [cfe-dev] Fixes for References Message-ID: <54FEA85B-B16A-44B4-B471-3B33B0B0EBD3@gmail.com> Hi, This is an updated patch to fix references. It now should implement subscripted references and references to functions correctly. I believe I got all of Chris's feedback into this patch. And it has the benefit of actually working!! :-) Okay to commit? -bw -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff.txt Url: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20070715/fcb2dfab/attachment.txt From clattner at apple.com Mon Jul 16 00:23:05 2007 From: clattner at apple.com (Chris Lattner) Date: Sun, 15 Jul 2007 22:23:05 -0700 Subject: [cfe-dev] Patch for References In-Reply-To: <1CC99EC3-5EE2-4095-A222-22EDD1864A4B@gmail.com> References: <7B98DFF2-22B7-45A4-BDF6-A9F7F6F7E83E@apple.com> <07FD7140-1ECC-40F6-B3EB-6C50C85E2083@gmail.com> <45FEF0A7-FECF-4461-AB06-647A4F80DC5D@apple.com> <1CC99EC3-5EE2-4095-A222-22EDD1864A4B@gmail.com> Message-ID: <71FC024B-74C3-47D5-B605-25A5970F6AB8@apple.com> On Jul 14, 2007, at 2:25 AM, Bill Wendling wrote: > On Jul 13, 2007, at 9:39 AM, Chris Lattner wrote: > >> I still don't think this is right. Nothing in the subscript >> operator should care about arrays. You should rely on the usual >> unary conversions for decaying the array to a pointer. Perhaps >> you need to implement usual unary conversions for references? > > Ah! I understand what you're saying now. Here's a new patch > submission. I think it does the correct thing now. I even have the > correct standard citation. :-) This patch has some of the same problems as the previous one. For example: + + const FunctionType *funcT = 0; + + if (PT == 0) { + // C++ 8.5.3p1: This is a reference to a function. + const ReferenceType *RT = dyn_cast(qType); + + if (RT) { + funcT = dyn_cast(RT->getReferenceeType()); + + if (funcT == 0) + funcT = ... The reference should be stripped off automatically by "implicit conversion handling" (See [conv], S4p3), not with explicit code in the call expr handler, because the callee is an rvalue. + if (const ReferenceType *ref = dyn_cast (t.getCanonicalType())) + t = ref->getReferenceeType(); // C++ 5p5 5p5 talks about the pointer-to-member operator, so I'm not sure how it is relevant. When citing the C++ standard, please use the section name as well, such as "[expr.mptr.oper]". I assume the intent is for these names to be stable as the standard moves forward. -Expr::isLvalueResult Expr::isLvalue() { +Expr::isLvalueResult Expr::isLvalue() const { Marking this method const is fine, please commit it as a separate patch. + if (isa(TR.getCanonicalType())) // C++ 5p5 + return LV_Valid; Likewise, this citation is non-sensical, see chapter 4 for the cite you are looking for. -Chris From clattner at apple.com Mon Jul 16 00:28:16 2007 From: clattner at apple.com (Chris Lattner) Date: Sun, 15 Jul 2007 22:28:16 -0700 Subject: [cfe-dev] Fixes for References In-Reply-To: <54FEA85B-B16A-44B4-B471-3B33B0B0EBD3@gmail.com> References: <54FEA85B-B16A-44B4-B471-3B33B0B0EBD3@gmail.com> Message-ID: <4BAD2A8C-E0FF-4867-B4BE-122F33FEF049@apple.com> On Jul 15, 2007, at 10:18 PM, Bill Wendling wrote: > Hi, > > This is an updated patch to fix references. It now should implement > subscripted references and references to functions correctly. I > believe I got all of Chris's feedback into this patch. And it has > the benefit of actually working!! :-) Heh, oops, I just responded. This patch has similar problems to the previous one. The citation [C+ + 3.10p5] doesn't make sense for isLvalue, because it only applies to call results. isLvalue applies to everything. +++ Sema/SemaExpr.cpp (working copy) @@ -282,10 +282,8 @@ Expr *LHSExp = static_cast(Base), *RHSExp = static_cast(Idx); // Perform default conversions. - DefaultFunctionArrayConversion(LHSExp); - DefaultFunctionArrayConversion(RHSExp); - - QualType LHSTy = LHSExp->getType(), RHSTy = RHSExp->getType(); + QualType LHSTy = DefaultFunctionArrayConversion(LHSExp); + QualType RHSTy = DefaultFunctionArrayConversion(RHSExp); assert(!LHSTy.isNull() && !RHSTy.isNull() && "missing types"); This is logically independent from the rest of the patch. I'd like to eventually remove the return value of DefaultFunctionArrayConversion, so please remove this piece. + if (PT == 0) { + // C++ 8.5.3p1: This is a reference to a function. + const ReferenceType *RT = dyn_cast(qType); This spec citation also seems wrong. It applies to initialization of references. -Chris From isanbard at gmail.com Mon Jul 16 00:33:25 2007 From: isanbard at gmail.com (Bill Wendling) Date: Sun, 15 Jul 2007 22:33:25 -0700 Subject: [cfe-dev] Patch for References In-Reply-To: <71FC024B-74C3-47D5-B605-25A5970F6AB8@apple.com> References: <7B98DFF2-22B7-45A4-BDF6-A9F7F6F7E83E@apple.com> <07FD7140-1ECC-40F6-B3EB-6C50C85E2083@gmail.com> <45FEF0A7-FECF-4461-AB06-647A4F80DC5D@apple.com> <1CC99EC3-5EE2-4095-A222-22EDD1864A4B@gmail.com> <71FC024B-74C3-47D5-B605-25A5970F6AB8@apple.com> Message-ID: <0896A3DB-7B70-45DD-96C3-39E9297C7BB2@gmail.com> On Jul 15, 2007, at 10:23 PM, Chris Lattner wrote: > This patch has some of the same problems as the previous one. For > example: > > + > + const FunctionType *funcT = 0; > + > + if (PT == 0) { > + // C++ 8.5.3p1: This is a reference to a function. > + const ReferenceType *RT = dyn_cast(qType); > + > + if (RT) { > + funcT = dyn_cast(RT->getReferenceeType()); > + > + if (funcT == 0) > + funcT = > > ... > > The reference should be stripped off automatically by "implicit > conversion handling" (See [conv], S4p3), not with explicit code in > the call expr handler, because the callee is an rvalue. Okay. > + if (const ReferenceType *ref = dyn_cast > (t.getCanonicalType())) > + t = ref->getReferenceeType(); // C++ 5p5 > > 5p5 talks about the pointer-to-member operator, so I'm not sure how > it is relevant. Mine doesn't talk about pointer-to-member operators. It is off by one, but not that far off (see below). :-) > When citing the C++ standard, please use the section name as well, > such as "[expr.mptr.oper]". I assume the intent is for these names > to be stable as the standard moves forward. Off by one error. It's 5p6: If an expression initially has the type ?reference toT? (8.3.2, 8.5.3), the type is adjusted to ?T? prior to any further analysis, the expression designates the object or function denoted by the reference, and the expression is an lvalue. It only has "[expr]" as the section (chapter) name. > -Expr::isLvalueResult Expr::isLvalue() { > +Expr::isLvalueResult Expr::isLvalue() const { > > Marking this method const is fine, please commit it as a separate > patch. Sure. > + if (isa(TR.getCanonicalType())) // C++ 5p5 > + return LV_Valid; > > Likewise, this citation is non-sensical, see chapter 4 for the cite > you are looking for. It's 5p6 :-) -bw From isanbard at gmail.com Mon Jul 16 00:37:38 2007 From: isanbard at gmail.com (Bill Wendling) Date: Sun, 15 Jul 2007 22:37:38 -0700 Subject: [cfe-dev] Fixes for References In-Reply-To: <4BAD2A8C-E0FF-4867-B4BE-122F33FEF049@apple.com> References: <54FEA85B-B16A-44B4-B471-3B33B0B0EBD3@gmail.com> <4BAD2A8C-E0FF-4867-B4BE-122F33FEF049@apple.com> Message-ID: On Jul 15, 2007, at 10:28 PM, Chris Lattner wrote: > On Jul 15, 2007, at 10:18 PM, Bill Wendling wrote: > >> Hi, >> >> This is an updated patch to fix references. It now should >> implement subscripted references and references to functions >> correctly. I believe I got all of Chris's feedback into this >> patch. And it has the benefit of actually working!! :-) > > Heh, oops, I just responded. We crossed pathes :-) > This patch has similar problems to the previous one. The citation > [C++ 3.10p5] doesn't make sense for isLvalue, because it only > applies to call results. isLvalue applies to everything. > > +++ Sema/SemaExpr.cpp (working copy) > @@ -282,10 +282,8 @@ > Expr *LHSExp = static_cast(Base), *RHSExp = > static_cast(Idx); > > // Perform default conversions. > - DefaultFunctionArrayConversion(LHSExp); > - DefaultFunctionArrayConversion(RHSExp); > - > - QualType LHSTy = LHSExp->getType(), RHSTy = RHSExp->getType(); > + QualType LHSTy = DefaultFunctionArrayConversion(LHSExp); > + QualType RHSTy = DefaultFunctionArrayConversion(RHSExp); > assert(!LHSTy.isNull() && !RHSTy.isNull() && "missing types"); > > > This is logically independent from the rest of the patch. I'd like > to eventually remove the return value of > DefaultFunctionArrayConversion, so please remove this piece. That would break the references stuff. The "stripping of the references" is why I made this change. Otherwise, we get a reference type from QualType LHSTy = LHSExp->getType(), RHSTy = RHSExp->getType(); And it fails below. If you're going to remove the return value of DefaultFunctionArrayConversion, then we'd have to do yet another stripping of the reference afterwards. > + if (PT == 0) { > + // C++ 8.5.3p1: This is a reference to a function. > + const ReferenceType *RT = dyn_cast(qType); > > This spec citation also seems wrong. It applies to initialization > of references. I'll put the correct one on when I fix the bigger problem. -bw From isanbard at gmail.com Mon Jul 16 00:45:42 2007 From: isanbard at gmail.com (Bill Wendling) Date: Sun, 15 Jul 2007 22:45:42 -0700 Subject: [cfe-dev] Patch for References In-Reply-To: <71FC024B-74C3-47D5-B605-25A5970F6AB8@apple.com> References: <7B98DFF2-22B7-45A4-BDF6-A9F7F6F7E83E@apple.com> <07FD7140-1ECC-40F6-B3EB-6C50C85E2083@gmail.com> <45FEF0A7-FECF-4461-AB06-647A4F80DC5D@apple.com> <1CC99EC3-5EE2-4095-A222-22EDD1864A4B@gmail.com> <71FC024B-74C3-47D5-B605-25A5970F6AB8@apple.com> Message-ID: <4B99B4D3-A28E-4EA9-86D4-23CAB4C15A70@gmail.com> On Jul 15, 2007, at 10:23 PM, Chris Lattner wrote: > This patch has some of the same problems as the previous one. For > example: > > + > + const FunctionType *funcT = 0; > + > + if (PT == 0) { > + // C++ 8.5.3p1: This is a reference to a function. > + const ReferenceType *RT = dyn_cast(qType); > + > + if (RT) { > + funcT = dyn_cast(RT->getReferenceeType()); > + > + if (funcT == 0) > + funcT = > > ... > Actually, even better, the fix for the subscripting thingy works for this as well. So there isn't any modification necessary. :-) I'll give you a submission soon. -bw From clattner at apple.com Mon Jul 16 00:46:51 2007 From: clattner at apple.com (Chris Lattner) Date: Sun, 15 Jul 2007 22:46:51 -0700 Subject: [cfe-dev] Patch for References In-Reply-To: <0896A3DB-7B70-45DD-96C3-39E9297C7BB2@gmail.com> References: <7B98DFF2-22B7-45A4-BDF6-A9F7F6F7E83E@apple.com> <07FD7140-1ECC-40F6-B3EB-6C50C85E2083@gmail.com> <45FEF0A7-FECF-4461-AB06-647A4F80DC5D@apple.com> <1CC99EC3-5EE2-4095-A222-22EDD1864A4B@gmail.com> <71FC024B-74C3-47D5-B605-25A5970F6AB8@apple.com> <0896A3DB-7B70-45DD-96C3-39E9297C7BB2@gmail.com> Message-ID: >> When citing the C++ standard, please use the section name as well, >> such as "[expr.mptr.oper]". I assume the intent is for these >> names to be stable as the standard moves forward. > > Off by one error. It's 5p6: > > If an expression initially has the type ?reference toT? (8.3.2, > 8.5.3), the type is adjusted to ?T? prior to any further analysis, > the expression designates the object or function denoted by the > reference, and the expression is an lvalue. > > It only has "[expr]" as the section (chapter) name. Ah, yep, we both made a mistake. You were off by one, I was looking at 5.5, not 5p5 :). 5p6 makes sense, this should go in unary conversions. -Chris From clattner at apple.com Mon Jul 16 00:48:13 2007 From: clattner at apple.com (Chris Lattner) Date: Sun, 15 Jul 2007 22:48:13 -0700 Subject: [cfe-dev] Fixes for References In-Reply-To: References: <54FEA85B-B16A-44B4-B471-3B33B0B0EBD3@gmail.com> <4BAD2A8C-E0FF-4867-B4BE-122F33FEF049@apple.com> Message-ID: <79C762D7-CEEA-4B73-A3BC-5F58BEC8D765@apple.com> >> This is logically independent from the rest of the patch. I'd >> like to eventually remove the return value of >> DefaultFunctionArrayConversion, so please remove this piece. > > That would break the references stuff. The "stripping of the > references" is why I made this change. Otherwise, we get a > reference type from > > QualType LHSTy = LHSExp->getType(), RHSTy = RHSExp->getType(); > > And it fails below. If you're going to remove the return value of > DefaultFunctionArrayConversion, then we'd have to do yet another > stripping of the reference afterwards. That's the problem: after calling DefaultFunctionArrayConversion, the expr returned should have its reference stripped off with an implicit conversion. One invariant is that the type (current) returned by DefaultFunctionArrayConversion should always be the type of the expr. -Chris From isanbard at gmail.com Mon Jul 16 01:43:15 2007 From: isanbard at gmail.com (Bill Wendling) Date: Sun, 15 Jul 2007 23:43:15 -0700 Subject: [cfe-dev] Fixes for References In-Reply-To: <79C762D7-CEEA-4B73-A3BC-5F58BEC8D765@apple.com> References: <54FEA85B-B16A-44B4-B471-3B33B0B0EBD3@gmail.com> <4BAD2A8C-E0FF-4867-B4BE-122F33FEF049@apple.com> <79C762D7-CEEA-4B73-A3BC-5F58BEC8D765@apple.com> Message-ID: On Jul 15, 2007, at 10:48 PM, Chris Lattner wrote: >>> This is logically independent from the rest of the patch. I'd >>> like to eventually remove the return value of >>> DefaultFunctionArrayConversion, so please remove this piece. >> >> That would break the references stuff. The "stripping of the >> references" is why I made this change. Otherwise, we get a >> reference type from >> >> QualType LHSTy = LHSExp->getType(), RHSTy = RHSExp->getType(); >> >> And it fails below. If you're going to remove the return value of >> DefaultFunctionArrayConversion, then we'd have to do yet another >> stripping of the reference afterwards. > > That's the problem: after calling DefaultFunctionArrayConversion, > the expr returned should have its reference stripped off with an > implicit conversion. > > One invariant is that the type (current) returned by > DefaultFunctionArrayConversion should always be the type of the expr. > Then that makes my patch even simpler. Here's the relevant part: Index: Sema/SemaExpr.cpp =================================================================== --- Sema/SemaExpr.cpp (revision 39902) +++ Sema/SemaExpr.cpp (working copy) @@ -579,7 +579,9 @@ QualType Sema::DefaultFunctionArrayConversion(Expr *&e) { QualType t = e->getType(); assert(!t.isNull() && "DefaultFunctionArrayConversion - missing type"); - + + if (const ReferenceType *ref = dyn_cast (t.getCanonicalType())) + t = promoteExprToType(e, ref->getReferenceeType()); // C++ 5p6 if (t->isFunctionType()) return promoteExprToType(e, Context.getPointerType(t)); if (const ArrayType *ary = dyn_cast(t.getCanonicalType ())) @@ -596,6 +598,8 @@ QualType t = expr->getType(); assert(!t.isNull() && "UsualUnaryConversions - missing type"); + if (const ReferenceType *ref = dyn_cast (t.getCanonicalType())) + t = promoteExprToType(expr, ref->getReferenceeType()); // C++ 5p6 if (t->isPromotableIntegerType()) // C99 6.3.1.1p2 return promoteExprToType(expr, Context.IntTy); return DefaultFunctionArrayConversion(expr); Okay? :-) -bw From doug.gregor at gmail.com Mon Jul 16 06:35:58 2007 From: doug.gregor at gmail.com (Douglas Gregor) Date: Mon, 16 Jul 2007 07:35:58 -0400 Subject: [cfe-dev] Patch for References In-Reply-To: <71FC024B-74C3-47D5-B605-25A5970F6AB8@apple.com> References: <7B98DFF2-22B7-45A4-BDF6-A9F7F6F7E83E@apple.com> <07FD7140-1ECC-40F6-B3EB-6C50C85E2083@gmail.com> <45FEF0A7-FECF-4461-AB06-647A4F80DC5D@apple.com> <1CC99EC3-5EE2-4095-A222-22EDD1864A4B@gmail.com> <71FC024B-74C3-47D5-B605-25A5970F6AB8@apple.com> Message-ID: <503A80FD-9940-43C3-986A-0AB5D14C3CB4@osl.iu.edu> On Jul 16, 2007, at 1:23 AM, Chris Lattner wrote: > When citing the C++ standard, please use the section > name as well, such as "[expr.mptr.oper]". I assume the intent is for > these names to be stable as the standard moves forward. Yes, the section names will remain the same but we have already changed some section and paragraph numbers. - Doug From andersca at mac.com Mon Jul 16 09:40:55 2007 From: andersca at mac.com (Anders Carlsson) Date: Mon, 16 Jul 2007 07:40:55 -0700 Subject: [cfe-dev] Patch: Implement break and continue In-Reply-To: <0FC0B8E7-C9EF-4F58-9093-E0E6B20F7177@apple.com> References: <6B85AB52-3218-43FE-B73E-5B6C851B4974@mac.com> <0FC0B8E7-C9EF-4F58-9093-E0E6B20F7177@apple.com> Message-ID: <21AF2D17-B90B-4D44-8BB7-72C4E5713836@mac.com> 15 jul 2007 kl. 22.02 skrev Chris Lattner: > On Jul 15, 2007, at 9:05 PM, Anders Carlsson wrote: >> Hello, >> here's a patch that implements break and continue in for, while >> and do loops. >> >> Since this is my first encounter ever with LLVM and cfe, the patch >> could very well be completely wrong :) I'd love any feedback it >> though. > > I have to say that this is *not* how I envisioned implementing > this: it's actually a much better approach. > > Overall, I really like the patch. Some suggestions: > > 1. Instead of having separate break/continue stacks, I'd suggest > merging them and using a SmallVector (or a custom struct > instead of a pair if you prefer). For switch stmts (when we > support them), we'd just use null as the continue point. > Thanks for the comments! Here's a new patch that addresses all of them and adds an extra assert that the break/continue stack is empty after generating the function body. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: break-continue-in-loops-2.txt Url: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20070716/b8c1a37c/attachment.txt -------------- next part -------------- Anders From clattner at apple.com Mon Jul 16 16:30:35 2007 From: clattner at apple.com (Chris Lattner) Date: Mon, 16 Jul 2007 14:30:35 -0700 Subject: [cfe-dev] Patch: Implement break and continue In-Reply-To: <21AF2D17-B90B-4D44-8BB7-72C4E5713836@mac.com> References: <6B85AB52-3218-43FE-B73E-5B6C851B4974@mac.com> <0FC0B8E7-C9EF-4F58-9093-E0E6B20F7177@apple.com> <21AF2D17-B90B-4D44-8BB7-72C4E5713836@mac.com> Message-ID: >> 1. Instead of having separate break/continue stacks, I'd suggest >> merging them and using a SmallVector (or a custom >> struct instead of a pair if you prefer). For switch stmts (when >> we support them), we'd just use null as the continue point. >> > > Thanks for the comments! Here's a new patch that addresses all of > them and adds an extra assert that the break/continue stack is > empty after generating the function body. > > > Applied, thanks! For future reference, I did forgot to mention one thing: please keep the code within 80 columns. I took care of the two long lines in this patch so it's not a big deal. Thanks again for the contribution! -Chris From clattner at apple.com Mon Jul 16 17:10:54 2007 From: clattner at apple.com (Chris Lattner) Date: Mon, 16 Jul 2007 15:10:54 -0700 Subject: [cfe-dev] Fixes for References In-Reply-To: References: <54FEA85B-B16A-44B4-B471-3B33B0B0EBD3@gmail.com> <4BAD2A8C-E0FF-4867-B4BE-122F33FEF049@apple.com> <79C762D7-CEEA-4B73-A3BC-5F58BEC8D765@apple.com> Message-ID: <1619BC40-3452-4DA0-9C50-EA34079D2DF1@apple.com> >> That's the problem: after calling DefaultFunctionArrayConversion, >> the expr returned should have its reference stripped off with an >> implicit conversion. >> >> One invariant is that the type (current) returned by >> DefaultFunctionArrayConversion should always be the type of the expr. >> > Then that makes my patch even simpler. Here's the relevant part: Nice, now we're getting there :) > + if (const ReferenceType *ref = dyn_cast > (t.getCanonicalType())) > + t = promoteExprToType(e, ref->getReferenceeType()); // C++ 5p6 Plz use a textual spec citation instead of a numeric one [foo.bar]. Other than that, it looks ok, please commit. It would be nice to refactor the code so that UsualUnaryConversions only needs to check for references once, but I'm not sure if that is possible. As a follow on patch, please eliminate the call to getCanonicalType by enhancing the Type::isReferenceType() predicate to return the reference type (like we now do for pointer type). This will allow you to retain the typedef info for reference typedefs. -Chris From isanbard at gmail.com Mon Jul 16 18:02:23 2007 From: isanbard at gmail.com (Bill Wendling) Date: Mon, 16 Jul 2007 16:02:23 -0700 Subject: [cfe-dev] Fixes for References In-Reply-To: <1619BC40-3452-4DA0-9C50-EA34079D2DF1@apple.com> References: <54FEA85B-B16A-44B4-B471-3B33B0B0EBD3@gmail.com> <4BAD2A8C-E0FF-4867-B4BE-122F33FEF049@apple.com> <79C762D7-CEEA-4B73-A3BC-5F58BEC8D765@apple.com> <1619BC40-3452-4DA0-9C50-EA34079D2DF1@apple.com> Message-ID: <16e5fdf90707161602o13ec010h1ad422c744b67df6@mail.gmail.com> On 7/16/07, Chris Lattner wrote: > Nice, now we're getting there :) > > > + if (const ReferenceType *ref = dyn_cast > > (t.getCanonicalType())) > > + t = promoteExprToType(e, ref->getReferenceeType()); // C++ 5p6 > > Plz use a textual spec citation instead of a numeric one [foo.bar]. > Other than that, it looks ok, please commit. > Okay. > It would be nice to refactor the code so that UsualUnaryConversions > only needs to check for references once, but I'm not sure if that is > possible. > > As a follow on patch, please eliminate the call to getCanonicalType > by enhancing the Type::isReferenceType() predicate to return the > reference type (like we now do for pointer type). This will allow > you to retain the typedef info for reference typedefs. > I'll submit tonight. Thanks! :-) -bw From andersca at mac.com Tue Jul 17 18:30:39 2007 From: andersca at mac.com (Anders Carlsson) Date: Tue, 17 Jul 2007 16:30:39 -0700 Subject: [cfe-dev] Patch: Add some semantic analysis to switch statements Message-ID: <477A860A-8945-4254-A923-017FE46B6A24@mac.com> Hello, here's a patch that makes sure that that the switch condition expression has an integer type, and also that a switch doesn't have more than one default: label. Anders -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: textmate stdin 2NXjY6.txt Url: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20070717/cf624ed0/attachment.txt From snaroff at apple.com Tue Jul 17 19:35:37 2007 From: snaroff at apple.com (Steve Naroff) Date: Tue, 17 Jul 2007 17:35:37 -0700 Subject: [cfe-dev] Patch: Add some semantic analysis to switch statements In-Reply-To: <477A860A-8945-4254-A923-017FE46B6A24@mac.com> References: <477A860A-8945-4254-A923-017FE46B6A24@mac.com> Message-ID: <1E9CB2A1-A200-40CB-840F-48A57D3926B6@apple.com> Anders, Thanks for the patch...looks great. One comment and one question... #1: Where is setSwitchStmt() called? #2: Getters should be declared "const". snaroff On Jul 17, 2007, at 4:30 PM, Anders Carlsson wrote: > Hello, > > here's a patch that makes sure that that the switch condition > expression has an integer type, and also that a switch doesn't have > more than one default: label. > > Anders > > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From andersca at mac.com Tue Jul 17 19:42:21 2007 From: andersca at mac.com (Anders Carlsson) Date: Tue, 17 Jul 2007 17:42:21 -0700 Subject: [cfe-dev] Patch: Add some semantic analysis to switch statements In-Reply-To: <1E9CB2A1-A200-40CB-840F-48A57D3926B6@apple.com> References: <477A860A-8945-4254-A923-017FE46B6A24@mac.com> <1E9CB2A1-A200-40CB-840F-48A57D3926B6@apple.com> Message-ID: <383C44DA-4C95-4055-9176-7844F10BB2C4@mac.com> 17 jul 2007 kl. 17.35 skrev Steve Naroff: > Anders, > > Thanks for the patch...looks great. > > One comment and one question... > > #1: Where is setSwitchStmt() called? > That was just some cruft, I've removed it. > #2: Getters should be declared "const". Whoops, missed that. Here's a new patch. Anders -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: textmate stdin b32ZBw.txt Url: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20070717/40e40b69/attachment.txt From snaroff at apple.com Tue Jul 17 20:04:45 2007 From: snaroff at apple.com (Steve Naroff) Date: Tue, 17 Jul 2007 18:04:45 -0700 Subject: [cfe-dev] Patch: Add some semantic analysis to switch statements In-Reply-To: <383C44DA-4C95-4055-9176-7844F10BB2C4@mac.com> References: <477A860A-8945-4254-A923-017FE46B6A24@mac.com> <1E9CB2A1-A200-40CB-840F-48A57D3926B6@apple.com> <383C44DA-4C95-4055-9176-7844F10BB2C4@mac.com> Message-ID: Excellent. Please commit. snaroff On Jul 17, 2007, at 5:42 PM, Anders Carlsson wrote: > > 17 jul 2007 kl. 17.35 skrev Steve Naroff: > >> Anders, >> >> Thanks for the patch...looks great. >> >> One comment and one question... >> >> #1: Where is setSwitchStmt() called? >> > > That was just some cruft, I've removed it. > > >> #2: Getters should be declared "const". > > Whoops, missed that. Here's a new patch. > > Anders > From neil at daikokuya.co.uk Tue Jul 17 21:14:17 2007 From: neil at daikokuya.co.uk (Neil Booth) Date: Wed, 18 Jul 2007 11:14:17 +0900 Subject: [cfe-dev] Patch: Add some semantic analysis to switch statements In-Reply-To: <477A860A-8945-4254-A923-017FE46B6A24@mac.com> References: <477A860A-8945-4254-A923-017FE46B6A24@mac.com> Message-ID: <20070718021417.GB481@daikokuya.co.uk> Anders Carlsson wrote:- > Hello, > > here's a patch that makes sure that that the switch condition > expression has an integer type, and also that a switch doesn't have But that's not what the standard requires; it requires a scalar type. You can download a copy of the revised standard from the openstd website. Neil. From andersca at mac.com Tue Jul 17 21:18:12 2007 From: andersca at mac.com (Anders Carlsson) Date: Tue, 17 Jul 2007 19:18:12 -0700 Subject: [cfe-dev] Patch: Add some semantic analysis to switch statements In-Reply-To: <20070718021417.GB481@daikokuya.co.uk> References: <477A860A-8945-4254-A923-017FE46B6A24@mac.com> <20070718021417.GB481@daikokuya.co.uk> Message-ID: 17 jul 2007 kl. 19.14 skrev Neil Booth: > Anders Carlsson wrote:- > >> Hello, >> >> here's a patch that makes sure that that the switch condition >> expression has an integer type, and also that a switch doesn't have > > But that's not what the standard requires; it requires a scalar > type. You can download a copy of the revised standard from the > openstd website. > > Neil. I'm reading that spec. It says: 6.8.4.2 The switch statement Constraints 1 The controlling expression of a switch statement shall have integer type. Am I missing something? Anders From neil at daikokuya.co.uk Tue Jul 17 21:18:22 2007 From: neil at daikokuya.co.uk (Neil Booth) Date: Wed, 18 Jul 2007 11:18:22 +0900 Subject: [cfe-dev] Patch: Add some semantic analysis to switch statements In-Reply-To: <20070718021417.GB481@daikokuya.co.uk> References: <477A860A-8945-4254-A923-017FE46B6A24@mac.com> <20070718021417.GB481@daikokuya.co.uk> Message-ID: <20070718021822.GC481@daikokuya.co.uk> Neil Booth wrote:- > Anders Carlsson wrote:- > > > Hello, > > > > here's a patch that makes sure that that the switch condition > > expression has an integer type, and also that a switch doesn't have > > But that's not what the standard requires; it requires a scalar > type. You can download a copy of the revised standard from the > openstd website. Apologies, I'm completely wrong. :) Neil. From neil at daikokuya.co.uk Wed Jul 18 01:28:49 2007 From: neil at daikokuya.co.uk (Neil Booth) Date: Wed, 18 Jul 2007 15:28:49 +0900 Subject: [cfe-dev] Preprocessor tweak Message-ID: <20070718062849.GA13293@daikokuya.co.uk> This fixes a minor issue where searching for the '(' to begin a macro invocation would spill into the surrounding file. Neil. Index: Lex/Preprocessor.cpp =================================================================== --- Lex/Preprocessor.cpp (revision 39996) +++ Lex/Preprocessor.cpp (working copy) @@ -552,14 +552,17 @@ Val = CurLexer->isNextPPTokenLParen(); else Val = CurMacroExpander->isNextTokenLParen(); - + if (Val == 2) { - // If we ran off the end of the lexer or macro expander, walk the include - // stack, looking for whatever will return the next token. + // We have run off the end. If it's a source file we don't + // examine enclosing ones (C99 5.1.1.2p4). Otherwise walk up the + // macro stack. + if (CurLexer) + return false; for (unsigned i = IncludeMacroStack.size(); Val == 2 && i != 0; --i) { IncludeStackInfo &Entry = IncludeMacroStack[i-1]; if (Entry.TheLexer) - Val = Entry.TheLexer->isNextPPTokenLParen(); + return false; else Val = Entry.TheMacroExpander->isNextTokenLParen(); } From neil at daikokuya.co.uk Wed Jul 18 01:32:38 2007 From: neil at daikokuya.co.uk (Neil Booth) Date: Wed, 18 Jul 2007 15:32:38 +0900 Subject: [cfe-dev] Preprocessor tweak In-Reply-To: <20070718062849.GA13293@daikokuya.co.uk> References: <20070718062849.GA13293@daikokuya.co.uk> Message-ID: <20070718063238.GB13293@daikokuya.co.uk> Neil Booth wrote:- > Index: Lex/Preprocessor.cpp > =================================================================== > --- Lex/Preprocessor.cpp (revision 39996) > +++ Lex/Preprocessor.cpp (working copy) > @@ -552,14 +552,17 @@ > Val = CurLexer->isNextPPTokenLParen(); > else > Val = CurMacroExpander->isNextTokenLParen(); > - > + > if (Val == 2) { > - // If we ran off the end of the lexer or macro expander, walk the include > - // stack, looking for whatever will return the next token. > + // We have run off the end. If it's a source file we don't > + // examine enclosing ones (C99 5.1.1.2p4). Otherwise walk up the > + // macro stack. > + if (CurLexer) > + return false; > for (unsigned i = IncludeMacroStack.size(); Val == 2 && i != 0; --i) { > IncludeStackInfo &Entry = IncludeMacroStack[i-1]; > if (Entry.TheLexer) > - Val = Entry.TheLexer->isNextPPTokenLParen(); > + return false; > else > Val = Entry.TheMacroExpander->isNextTokenLParen(); > } That's not quite right either. I'll repost. Neil. From bboissin+llvm at gmail.com Wed Jul 18 05:21:34 2007 From: bboissin+llvm at gmail.com (Benoit Boissinot) Date: Wed, 18 Jul 2007 12:21:34 +0200 Subject: [cfe-dev] fix Sema/unused-expr.c failing on r39999 Message-ID: <20070718102134.GB30404@ens-lyon.fr> I needed the following patch so that test/Sema/unused-expr.c does not fail: -- void is a valid cast type Index: Sema/SemaExpr.cpp =================================================================== --- Sema/SemaExpr.cpp (revision 39996) +++ Sema/SemaExpr.cpp (working copy) @@ -478,8 +478,9 @@ Expr *castExpr = static_cast(Op); QualType castType = QualType::getFromOpaquePtr(Ty); - // C99 6.5.4p2: both the cast type and expression type need to be scalars. - if (!castType->isScalarType()) { + // C99 6.5.4p2: the cast type needs to be void or scalar and the expression + // type needs to be scalar. + if (!castType->isScalarType() && !castType->isVoidType()) { return Diag(LParenLoc, diag::err_typecheck_cond_expect_scalar, castType.getAsString(), SourceRange(LParenLoc, RParenLoc)); } -- :wq From snaroff at apple.com Wed Jul 18 07:42:49 2007 From: snaroff at apple.com (Steve Naroff) Date: Wed, 18 Jul 2007 05:42:49 -0700 Subject: [cfe-dev] fix Sema/unused-expr.c failing on r39999 In-Reply-To: <20070718102134.GB30404@ens-lyon.fr> References: <20070718102134.GB30404@ens-lyon.fr> Message-ID: <11DE66D5-CA1D-4E6C-9A93-DE1754FED278@apple.com> Thanks for the (timely) patch (I planned on fixing this today:-). snaroff On Jul 18, 2007, at 3:21 AM, Benoit Boissinot wrote: > I needed the following patch so that test/Sema/unused-expr.c does not > fail: > > -- > void is a valid cast type > > Index: Sema/SemaExpr.cpp > =================================================================== > --- Sema/SemaExpr.cpp (revision 39996) > +++ Sema/SemaExpr.cpp (working copy) > @@ -478,8 +478,9 @@ > Expr *castExpr = static_cast(Op); > QualType castType = QualType::getFromOpaquePtr(Ty); > > - // C99 6.5.4p2: both the cast type and expression type need to > be scalars. > - if (!castType->isScalarType()) { > + // C99 6.5.4p2: the cast type needs to be void or scalar and the > expression > + // type needs to be scalar. > + if (!castType->isScalarType() && !castType->isVoidType()) { > return Diag(LParenLoc, diag::err_typecheck_cond_expect_scalar, > castType.getAsString(), SourceRange(LParenLoc, > RParenLoc)); > } > -- > :wq > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From clattner at apple.com Wed Jul 18 11:01:43 2007 From: clattner at apple.com (Chris Lattner) Date: Wed, 18 Jul 2007 09:01:43 -0700 Subject: [cfe-dev] fix Sema/unused-expr.c failing on r39999 In-Reply-To: <20070718102134.GB30404@ens-lyon.fr> References: <20070718102134.GB30404@ens-lyon.fr> Message-ID: <14F137B9-6A42-407F-A60B-624C4FB0C0D0@apple.com> On Jul 18, 2007, at 3:21 AM, Benoit Boissinot wrote: > I needed the following patch so that test/Sema/unused-expr.c does not > fail: Applied, thanks! With future patches, please include them as attachments to the email. This one applied fine, but I've had trouble with inline attachments in the past. Thanks again, -Chris > -- > void is a valid cast type > > Index: Sema/SemaExpr.cpp > =================================================================== > --- Sema/SemaExpr.cpp (revision 39996) > +++ Sema/SemaExpr.cpp (working copy) > @@ -478,8 +478,9 @@ > Expr *castExpr = static_cast(Op); > QualType castType = QualType::getFromOpaquePtr(Ty); > > - // C99 6.5.4p2: both the cast type and expression type need to > be scalars. > - if (!castType->isScalarType()) { > + // C99 6.5.4p2: the cast type needs to be void or scalar and the > expression > + // type needs to be scalar. > + if (!castType->isScalarType() && !castType->isVoidType()) { > return Diag(LParenLoc, diag::err_typecheck_cond_expect_scalar, > castType.getAsString(), SourceRange(LParenLoc, > RParenLoc)); > } > -- > :wq > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From neil at daikokuya.co.uk Wed Jul 18 17:57:15 2007 From: neil at daikokuya.co.uk (Neil Booth) Date: Thu, 19 Jul 2007 07:57:15 +0900 Subject: [cfe-dev] Preprocessor tweak In-Reply-To: <20070718063238.GB13293@daikokuya.co.uk> References: <20070718062849.GA13293@daikokuya.co.uk> <20070718063238.GB13293@daikokuya.co.uk> Message-ID: <20070718225714.GC13293@daikokuya.co.uk> This fixes the search for opening parentheses by stopping at EOF. Neil. Index: Lex/Preprocessor.cpp =================================================================== --- Lex/Preprocessor.cpp (revision 40021) +++ Lex/Preprocessor.cpp (working copy) @@ -552,16 +552,23 @@ Val = CurLexer->isNextPPTokenLParen(); else Val = CurMacroExpander->isNextTokenLParen(); - + if (Val == 2) { - // If we ran off the end of the lexer or macro expander, walk the include - // stack, looking for whatever will return the next token. - for (unsigned i = IncludeMacroStack.size(); Val == 2 && i != 0; --i) { + // We have run off the end. If it's a source file we don't + // examine enclosing ones (C99 5.1.1.2p4). Otherwise walk up the + // macro stack. + if (CurLexer) + return false; + for (unsigned i = IncludeMacroStack.size(); i != 0; --i) { IncludeStackInfo &Entry = IncludeMacroStack[i-1]; if (Entry.TheLexer) Val = Entry.TheLexer->isNextPPTokenLParen(); else Val = Entry.TheMacroExpander->isNextTokenLParen(); + if (Val != 2) + break; + if (Entry.TheLexer) + return false; } } From clattner at apple.com Wed Jul 18 19:08:30 2007 From: clattner at apple.com (Chris Lattner) Date: Wed, 18 Jul 2007 17:08:30 -0700 Subject: [cfe-dev] Preprocessor tweak In-Reply-To: <20070718225714.GC13293@daikokuya.co.uk> References: <20070718062849.GA13293@daikokuya.co.uk> <20070718063238.GB13293@daikokuya.co.uk> <20070718225714.GC13293@daikokuya.co.uk> Message-ID: <2EB98FEC-E6C5-4243-A604-B06731E4DB73@apple.com> On Jul 18, 2007, at 3:57 PM, Neil Booth wrote: > This fixes the search for opening parentheses by stopping at EOF. Thanks Neil, this is great. Some requests for future patches: * First, please include the patch as an attachment. * Please don't use tabs, use spaces instead. * Please include a testcase. I'll took care of these with this one: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of- Mon-20070716/001309.html Thanks Neil, -Chris From bboissin+llvm at gmail.com Thu Jul 19 01:17:44 2007 From: bboissin+llvm at gmail.com (Benoit Boissinot) Date: Thu, 19 Jul 2007 08:17:44 +0200 Subject: [cfe-dev] valgrind error Message-ID: <20070719061744.GE30404@ens-lyon.fr> I get the following errors with valgrind (and some leaks but I haven't resolved them yet) ==4810== Invalid write of size 4 ==4810== at 0x81BCE8A: clang::QualType::QualType() (Type.h:59) ==4810== by 0x820289A: clang::FunctionTypeProto::FunctionTypeProto(clang::QualType, clang::QualType*, unsigned, bool, clang::QualType) (Type.h:565) [snip] ==4810== Address 0x42CFD10 is 0 bytes after a block of size 24 alloc'd ==4810== at 0x4021620: malloc (vg_replace_malloc.c:149) ==4810== by 0x81FF7C1: clang::ASTContext::getFunctionType(clang::QualType, clang::QualType*, unsigned, bool) (ASTContext.cpp:550) [snip] The following patch fixes it: (it only removes 1 sizeof(QualType) if NumArgs is > 0) If you prefer to avoid !!NumArgs (it is quite common in the linux kernel for example, but it may be seen as an obfuscation by some people), I could use (NumArgs ? 1 : 0) --- AST/ASTContext.cpp (revision 40015) +++ AST/ASTContext.cpp (working copy) @@ -547,7 +547,7 @@ // variable size array (for parameter types) at the end of them. FunctionTypeProto *FTP = (FunctionTypeProto*)malloc(sizeof(FunctionTypeProto) + - (NumArgs-1)*sizeof(QualType)); + (NumArgs-!!NumArgs)*sizeof(QualType)); new (FTP) FunctionTypeProto(ResultTy, ArgArray, NumArgs, isVariadic, Canonical); Types.push_back(FTP); -- :wq -------------- next part -------------- A non-text attachment was scrubbed... Name: fix_valgrind.diff Type: text/x-diff Size: 624 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20070719/9cd6179d/attachment.bin From clattner at apple.com Fri Jul 20 13:48:54 2007 From: clattner at apple.com (Chris Lattner) Date: Fri, 20 Jul 2007 11:48:54 -0700 Subject: [cfe-dev] valgrind error In-Reply-To: <20070719061744.GE30404@ens-lyon.fr> References: <20070719061744.GE30404@ens-lyon.fr> Message-ID: On Jul 18, 2007, at 11:17 PM, Benoit Boissinot wrote: > I get the following errors with valgrind (and some leaks but I haven't > resolved them yet) Fixed, thanks: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of- Mon-20070716/001324.html -Chris From neil at daikokuya.co.uk Sat Jul 21 22:39:18 2007 From: neil at daikokuya.co.uk (Neil Booth) Date: Sun, 22 Jul 2007 12:39:18 +0900 Subject: [cfe-dev] Goto requires ident Message-ID: <20070722033917.GA14793@daikokuya.co.uk> Found by my tests. I'm assuming returning Res is OK, as it did before. Neil. -------------- next part -------------- Index: test/Parser/goto-ident.c =================================================================== --- test/Parser/goto-ident.c (revision 0) +++ test/Parser/goto-ident.c (revision 0) @@ -0,0 +1,6 @@ +/* RUN: clang -parse-ast-check %s +*/ + +void foo() { + goto ; /* expected-error {{expected identifier}} */ +} Index: Parse/ParseStmt.cpp =================================================================== --- Parse/ParseStmt.cpp (revision 40380) +++ Parse/ParseStmt.cpp (working copy) @@ -680,7 +680,10 @@ return true; } Res = Actions.ParseIndirectGotoStmt(GotoLoc, StarLoc, R.Val); + } else { + Diag(Tok, diag::err_expected_ident); } + return Res; } From clattner at apple.com Sat Jul 21 23:14:30 2007 From: clattner at apple.com (Chris Lattner) Date: Sat, 21 Jul 2007 21:14:30 -0700 Subject: [cfe-dev] Goto requires ident In-Reply-To: <20070722033917.GA14793@daikokuya.co.uk> References: <20070722033917.GA14793@daikokuya.co.uk> Message-ID: <59D9850D-62EF-4FFB-A2FC-FA2541196288@apple.com> On Jul 21, 2007, at 8:39 PM, Neil Booth wrote: > Found by my tests. I'm assuming returning Res is OK, as it did > before. Looks great, applied. I changed it to return an explicit true to be more obvious its an error case, I don't think it changes the semantics of the code. Thanks Neil, -Chris From clattner at apple.com Mon Jul 23 16:57:50 2007 From: clattner at apple.com (Chris Lattner) Date: Mon, 23 Jul 2007 14:57:50 -0700 Subject: [cfe-dev] clang and options In-Reply-To: <20070723214831.GL14220@nexus.in-nomine.org> References: <20070723214831.GL14220@nexus.in-nomine.org> Message-ID: On Jul 23, 2007, at 2:48 PM, Jeroen Ruigrok van der Werven wrote: > what I find funny/odd is the fact that clang supports neither -c or > -o, fairly > standardized option flags. > Even OpenGroup specifies them for c99: > http://www.opengroup.org/onlinepubs/000095399/utilities/c99.html > This causes typical .SUFFIX rules for .c.o such as this to fail: > > .c.o: > ${CC} ${CFLAGS} -c ${.IMPSRC} -o ${.TARGET} > > This is pretty common for the BSD's with their /usr/share/mk/*.mk > files. Yep, they are completely missing. The clang codegen support is extremely limited right now. At present it only handles simple scalars, arrays and vectors. It have very limited support for complex numbers and no support for structs/ unions. If you want to try it out, use the -emit-llvm option, which will emit a LLVM ".ll" file to standard out. To compile it, use something like: $ clang test.c -emit-llvm | llvm-as | opt -std-compile-opts | llc -o test.s At some point, I'll hook up -S to do that, and -c to do that plus invoke the system assembler. In the meantime, it's a good thing that we don't pretend that codegen is ready :) In the short term, we're focusing primarily on getting -fsyntax-only right. There are a small (and shrinking) collection of semantic checks that we don't perform (i.e. invalid code that should be rejected). We also do not emit many important warnings that GCC and other compilers do, and these are very important for end users (and thus, is a requirement before clang can be generally useful for developers). That said, to me at least, warnings are less important than codegen. -Chris From neil at daikokuya.co.uk Mon Jul 23 17:30:58 2007 From: neil at daikokuya.co.uk (Neil Booth) Date: Tue, 24 Jul 2007 07:30:58 +0900 Subject: [cfe-dev] Fix warning Message-ID: <20070723223058.GB14793@daikokuya.co.uk> about potentially uninitialized vars Size and Align. Neil. -------------- next part -------------- Index: AST/ASTContext.cpp =================================================================== --- AST/ASTContext.cpp (revision 40450) +++ AST/ASTContext.cpp (working copy) @@ -227,14 +227,14 @@ break; } case Type::Tagged: - if (RecordType *RT = dyn_cast(cast(T))) { - const RecordLayout &Layout = getRecordLayout(RT->getDecl(), L); - Size = Layout.getSize(); - Align = Layout.getAlignment(); - break; - } - // FIXME: Handle enums. - assert(0 && "Unimplemented type sizes!"); + RecordType *RT = dyn_cast(cast(T)); + if (!RT) + // FIXME: Handle enums. + assert(0 && "Unimplemented type sizes!"); + const RecordLayout &Layout = getRecordLayout(RT->getDecl(), L); + Size = Layout.getSize(); + Align = Layout.getAlignment(); + break; } assert(Align && (Align & (Align-1)) == 0 && "Alignment must be power of 2"); From clattner at apple.com Mon Jul 23 17:46:39 2007 From: clattner at apple.com (Chris Lattner) Date: Mon, 23 Jul 2007 15:46:39 -0700 Subject: [cfe-dev] Fix warning In-Reply-To: <20070723223058.GB14793@daikokuya.co.uk> References: <20070723223058.GB14793@daikokuya.co.uk> Message-ID: <6D39CC1A-A637-4DD9-9D12-B71964DD84F7@apple.com> On Jul 23, 2007, at 3:30 PM, Neil Booth wrote: > about potentially uninitialized vars Size and Align. Applied, thanks! -Chris From neil at daikokuya.co.uk Mon Jul 23 17:49:37 2007 From: neil at daikokuya.co.uk (Neil Booth) Date: Tue, 24 Jul 2007 07:49:37 +0900 Subject: [cfe-dev] Fix paste avoidance Message-ID: <20070723224937.GC14793@daikokuya.co.uk> Apparently a logic bug; confused how it was working for anyone else. Neil. -------------- next part -------------- Index: Driver/PrintPreprocessedOutput.cpp =================================================================== --- Driver/PrintPreprocessedOutput.cpp (revision 40450) +++ Driver/PrintPreprocessedOutput.cpp (working copy) @@ -540,7 +540,7 @@ } else if (Tok.hasLeadingSpace() || // If we haven't emitted a token on this line yet, PrevTok isn't // useful to look at and no concatenation could happen anyway. - (!Callbacks->hasEmittedTokensOnThisLine() && + (Callbacks->hasEmittedTokensOnThisLine() && // Don't print "-" next to "-", it would form "--". Callbacks->AvoidConcat(PrevTok, Tok))) { OutputChar(' '); From neil at daikokuya.co.uk Mon Jul 23 18:03:30 2007 From: neil at daikokuya.co.uk (Neil Booth) Date: Tue, 24 Jul 2007 08:03:30 +0900 Subject: [cfe-dev] Fix paste avoidance In-Reply-To: <20070723224937.GC14793@daikokuya.co.uk> References: <20070723224937.GC14793@daikokuya.co.uk> Message-ID: <20070723230330.GD14793@daikokuya.co.uk> Neil Booth wrote:- > Apparently a logic bug; confused how it was working for anyone > else. And another. Neil. -------------- next part -------------- Index: Driver/PrintPreprocessedOutput.cpp =================================================================== --- Driver/PrintPreprocessedOutput.cpp (revision 40452) +++ Driver/PrintPreprocessedOutput.cpp (working copy) @@ -426,7 +426,7 @@ if (Tok.getKind() == tok::equal || Tok.getKind() == tok::equalequal) return true; - ConcatInfo &= ~ConcatInfo; + ConcatInfo &= ~aci_avoid_equal; } if (ConcatInfo == 0) return false; @@ -540,7 +540,7 @@ } else if (Tok.hasLeadingSpace() || // If we haven't emitted a token on this line yet, PrevTok isn't // useful to look at and no concatenation could happen anyway. - (!Callbacks->hasEmittedTokensOnThisLine() && + (Callbacks->hasEmittedTokensOnThisLine() && // Don't print "-" next to "-", it would form "--". Callbacks->AvoidConcat(PrevTok, Tok))) { OutputChar(' '); From clattner at apple.com Mon Jul 23 18:22:45 2007 From: clattner at apple.com (Chris Lattner) Date: Mon, 23 Jul 2007 16:22:45 -0700 Subject: [cfe-dev] Fix paste avoidance In-Reply-To: <20070723230330.GD14793@daikokuya.co.uk> References: <20070723224937.GC14793@daikokuya.co.uk> <20070723230330.GD14793@daikokuya.co.uk> Message-ID: <91A81D55-A135-44E5-9B06-F5F7A1A56E93@apple.com> On Jul 23, 2007, at 4:03 PM, Neil Booth wrote: > Neil Booth wrote:- > >> Apparently a logic bug; confused how it was working for anyone >> else. > > And another. Yep, you're right. It was failing for me too, I just didn't notice it. Thanks for the fixes, late night hacking is bad :( I'm hoping that the llvm-top stuff that Reid is working will let us hook up dejagnu properly for the clang tests. This will make the output much less noisy, so it's easy to spot failures. -Chris From wilsonk at cpsc.ucalgary.ca Tue Jul 24 04:10:07 2007 From: wilsonk at cpsc.ucalgary.ca (Kelly Wilson) Date: Tue, 24 Jul 2007 03:10:07 -0600 (MDT) Subject: [cfe-dev] clang builds on Sparc/Linux! Message-ID: Hello everyone, I am not sure if this is the correct list for this, but I think so, because llvm-gcc didn't build error-free on Sparc/Linux last time I tried....but clang does! I am running an Enterprise 250 with Dual UltraSparc II's and 2 Gb ram running Aurora Sparc Linux 2.0 (2.6.13 kernel for Aurora is based on Fedora Core 3). GCC version 3.4.2. I built llvm-2.0 (not the svn version but the download version) by just typing "./configure;make". I then downloaded clang from the svn repository (revision 40382) and changed to it's directory under .../llvm/tools/clang. I did a "make" without incident for clang, as well. Woohoo. I tried a few examples and everything seemed to work fine, as far as llvm, some simple clang functionality and the JIT examples go. Then I ran this contrived example through clang and llvm: int x; int func1 (int g) { return g; } int main() { printf("Hello World %d times\n", func1(5)); } with this command: clang ./ex1.c -emit-llvm | llvm-as | opt -std-compile-opts | llc -march=sparc > ex1.S This worked fine and the code gen looked fine, except for two things: .text .align 16 .globl func1 .type func1, #function func1: save -96, %o6, %o6<---------------change restore %g0, %g0, %g0 retl nop .align 16 .globl main .type main, #function main: save -96, %o6, %o6<---------------change sethi %hi(.str), %l0 add %l0, %lo(.str), %o0 or %g0, 5, %o1 call printf nop !IMPLICIT_DEF %i0 restore %g0, %g0, %g0 retl nop .globl x .bss <-------------------------------------remove .align 4 .type x,#object .size x,4 x: .skip 4 .data .align 1 .type .str,#object .size .str,22 .str: .asciz "Hello World %d times\n" The two problems with this output. "save -96, %o6, %o6" should read "save %o6, -96, %o6" at both function entry points, and the ".bss" section identifier needs to be removed. THEN GCC CAN ASSEMBLE/LINK THIS AND IT RUNS!!!!! Cool, now you have a new OS/arch pair to run LLVM on, though I may be the only one running this pair ;) Let me know if anyone wants anymore information. I will do some more testing and let you know how it goes. Thanks, Kelly Wilson P.S. Maybe I should cross-post this to llvm-dev so that the Sparc backend writers can see it? I also have a couple very small diff's to fix these two problems in the Sparc backend...should I post them to llvm-dev? From asmodai at in-nomine.org Tue Jul 24 04:13:48 2007 From: asmodai at in-nomine.org (Jeroen Ruigrok van der Werven) Date: Tue, 24 Jul 2007 11:13:48 +0200 Subject: [cfe-dev] extern supported yet? Message-ID: <20070724091348.GQ14220@nexus.in-nomine.org> Just to verify and cross-check my sanity, but is extern properly supported yet? -- Jeroen Ruigrok van der Werven / asmodai ????? ?????? ??? ?? ?????? http://www.in-nomine.org/ | http://www.rangaku.org/ In the dark backward and abysm of time... From asmodai at in-nomine.org Tue Jul 24 07:03:58 2007 From: asmodai at in-nomine.org (Jeroen Ruigrok van der Werven) Date: Tue, 24 Jul 2007 14:03:58 +0200 Subject: [cfe-dev] core dump, how to best investigate Message-ID: <20070724120357.GR14220@nexus.in-nomine.org> I have done a lot of coredump analysis, but I need to touch base to see if there's any standard procedure on how to best do this within clang and llvm context. Partial backtrace: #0 0x081ba401 in clang::Expr::getType (this=0x0) at Expr.h:37 #1 0x081d94d7 in clang::Sema::ParseUnaryOp (this=0x831b880, OpLoc= {ID = 2148130816}, Op=clang::tok::kw___extension__, input=0x0) at SemaExpr.cpp:1455 #2 0x081f7c40 in clang::Parser::ParseCastExpression (this=0x831b800, isUnaryExpression=false) at ParseExpr.cpp:546 -- Jeroen Ruigrok van der Werven / asmodai ????? ?????? ??? ?? ?????? http://www.in-nomine.org/ | http://www.rangaku.org/ There is no joy in smallness. Joy is in the infinite... From asmodai at in-nomine.org Tue Jul 24 08:40:00 2007 From: asmodai at in-nomine.org (Jeroen Ruigrok van der Werven) Date: Tue, 24 Jul 2007 15:40:00 +0200 Subject: [cfe-dev] core dump, how to best investigate In-Reply-To: <20070724120357.GR14220@nexus.in-nomine.org> References: <20070724120357.GR14220@nexus.in-nomine.org> Message-ID: <20070724134000.GS14220@nexus.in-nomine.org> -On [20070724 14:04], Jeroen Ruigrok van der Werven (asmodai at in-nomine.org) wrote: >#1 0x081d94d7 in clang::Sema::ParseUnaryOp (this=0x831b880, OpLoc= > {ID = 2148130816}, Op=clang::tok::kw___extension__, input=0x0) > at SemaExpr.cpp:1455 >#2 0x081f7c40 in clang::Parser::ParseCastExpression (this=0x831b800, > isUnaryExpression=false) at ParseExpr.cpp:546 So ParseUnaryOp() has an input which is empty and as such resultType = Input->getType(); fails. ParseCastExpression() is executing: Res = Actions.ParseUnaryOp(SavedLoc, SavedKind, Res.Val); which has to mean that Res.Val is empty: (gdb) print Res.Val $1 = (void *) 0x0 It seems to come from including unistd.h on FreeBSD, which includes sys/types.h, which includes machine/endian.h which results in: [15:37] [asmodai at nexus] (1125) {0} % clang /usr/include/machine/endian.h /usr/include/machine/endian.h:146:10: warning: expression result unused return (__byte_swap_int(_x)); ^~~~~~~~~~~~~~~ zsh: segmentation fault (core dumped) clang /usr/include/machine/endian.h Relevant part of the source file: #define __byte_swap_int_var(x) \ __extension__ ({ register __uint32_t __X = (x); \ __asm ("bswap %0" : "+r" (__X)); \ __X; }) And looking at Parse/ParseExpr.cpp line 542 this seems expected: // FIXME: Extension not handled correctly here! -- Jeroen Ruigrok van der Werven / asmodai ????? ?????? ??? ?? ?????? http://www.in-nomine.org/ | http://www.rangaku.org/ To give your sheep or cow a large spacious meadow is the way to control him... From asmodai at in-nomine.org Tue Jul 24 08:43:19 2007 From: asmodai at in-nomine.org (Jeroen Ruigrok van der Werven) Date: Tue, 24 Jul 2007 15:43:19 +0200 Subject: [cfe-dev] core dump, how to best investigate In-Reply-To: <20070724134000.GS14220@nexus.in-nomine.org> References: <20070724120357.GR14220@nexus.in-nomine.org> <20070724134000.GS14220@nexus.in-nomine.org> Message-ID: <20070724134319.GT14220@nexus.in-nomine.org> -On [20070724 15:40], Jeroen Ruigrok van der Werven (asmodai at in-nomine.org) wrote: >So ParseUnaryOp() has an input which is empty and as such resultType = >Input->getType(); fails. Would it make sense to add a fail-safe in the form of (excuse my C++ I'm better in C and C#): if (Input == NULL) { bail_out(); } resultType = Input->getType(); -- Jeroen Ruigrok van der Werven / asmodai ????? ?????? ??? ?? ?????? http://www.in-nomine.org/ | http://www.rangaku.org/ Open your Heart and push the limits... From clattner at apple.com Tue Jul 24 10:58:22 2007 From: clattner at apple.com (Chris Lattner) Date: Tue, 24 Jul 2007 08:58:22 -0700 Subject: [cfe-dev] clang builds on Sparc/Linux! In-Reply-To: References: Message-ID: On Jul 24, 2007, at 2:10 AM, Kelly Wilson wrote: > I am not sure if this is the correct list for this, but I think so, > because llvm-gcc didn't build error-free on Sparc/Linux last time I > tried....but clang does! Cool! :) > I am running an Enterprise 250 with Dual UltraSparc II's and 2 Gb ram > running Aurora Sparc Linux 2.0 (2.6.13 kernel for Aurora is based on > Fedora Core 3). GCC version 3.4.2. > > I built llvm-2.0 (not the svn version but the download version) by > just > typing "./configure;make". I then downloaded clang from the svn > repository (revision 40382) and changed to it's directory > under .../llvm/tools/clang. I did a "make" without incident for clang, > as well. Woohoo. Nice. You probably got a bit lucky :). Usually clang SVN head will only work with LLVM SVN head. > I tried a few examples and everything seemed to work fine, as far as > llvm, some simple clang functionality and the JIT examples go. Then I > ran this contrived example through clang and llvm: > > int x; > int func1 (int g) { > return g; > } > int main() > { > printf("Hello World %d times\n", func1(5)); > } > > > with this command: > > clang ./ex1.c -emit-llvm | llvm-as | opt -std-compile-opts | llc > -march=sparc > ex1.S > > This worked fine and the code gen looked fine, except for two things: Ok > The two problems with this output. "save -96, %o6, %o6" should read > "save %o6, -96, %o6" at both function entry points, and the ".bss" > section identifier needs to be removed. THEN GCC CAN ASSEMBLE/LINK > THIS > AND IT RUNS!!!!! Cool, now you have a new OS/arch pair to run LLVM on, > though I may be the only one running this pair ;) Very nice! I'm not sure how the arguments to save got transposed, it must be a regression somewhere along the way. We don't have too many people testing sparc :) > P.S. Maybe I should cross-post this to llvm-dev so that the Sparc > backend writers can see it? I also have a couple very small diff's to > fix these two problems in the Sparc backend...should I post them to > llvm-dev? Yes please. I'm actually the author/maintainer of the sparc backend, but llvm-dev is the right place to take care of these bugs. Thanks! -Chris From clattner at apple.com Tue Jul 24 10:59:19 2007 From: clattner at apple.com (Chris Lattner) Date: Tue, 24 Jul 2007 08:59:19 -0700 Subject: [cfe-dev] extern supported yet? In-Reply-To: <20070724091348.GQ14220@nexus.in-nomine.org> References: <20070724091348.GQ14220@nexus.in-nomine.org> Message-ID: <7CA85D5D-0533-48D6-942A-238ACE2641FF@apple.com> On Jul 24, 2007, at 2:13 AM, Jeroen Ruigrok van der Werven wrote: > Just to verify and cross-check my sanity, but is extern properly > supported > yet? If you're asking, I assume you hit a bug. What isn't working? -Chris From clattner at apple.com Tue Jul 24 11:20:58 2007 From: clattner at apple.com (Chris Lattner) Date: Tue, 24 Jul 2007 09:20:58 -0700 Subject: [cfe-dev] core dump, how to best investigate In-Reply-To: <20070724134000.GS14220@nexus.in-nomine.org> References: <20070724120357.GR14220@nexus.in-nomine.org> <20070724134000.GS14220@nexus.in-nomine.org> Message-ID: <693A39E5-0EBE-48E8-B7B5-BCAC81182DCE@apple.com> On Jul 24, 2007, at 6:40 AM, Jeroen Ruigrok van der Werven wrote: > -On [20070724 14:04], Jeroen Ruigrok van der Werven (asmodai at in- > nomine.org) wrote: >> #1 0x081d94d7 in clang::Sema::ParseUnaryOp (this=0x831b880, OpLoc= >> {ID = 2148130816}, Op=clang::tok::kw___extension__, input=0x0) >> at SemaExpr.cpp:1455 >> #2 0x081f7c40 in clang::Parser::ParseCastExpression (this=0x831b800, >> isUnaryExpression=false) at ParseExpr.cpp:546 > > So ParseUnaryOp() has an input which is empty and as such resultType = > Input->getType(); fails. Yep, this is because the inner expression did not correctly return as AST node. > ParseCastExpression() is executing: > Res = Actions.ParseUnaryOp(SavedLoc, SavedKind, Res.Val); > > It seems to come from including unistd.h on FreeBSD, which includes > sys/types.h, which includes machine/endian.h which results in: Ah, it's bad this happens so frequently for you, ok. > [15:37] [asmodai at nexus] (1125) {0} % clang /usr/include/machine/ > endian.h > /usr/include/machine/endian.h:146:10: warning: expression result > unused > return (__byte_swap_int(_x)); > ^~~~~~~~~~~~~~~ > zsh: segmentation fault (core dumped) clang /usr/include/machine/ > endian.h > > Relevant part of the source file: > > #define __byte_swap_int_var(x) \ > __extension__ ({ register __uint32_t __X = (x); \ > __asm ("bswap %0" : "+r" (__X)); \ > __X; }) > > And looking at Parse/ParseExpr.cpp line 542 this seems expected: > > // FIXME: Extension not handled correctly here! __extension__ is actually handled correctly enough for this code. The FIXME refers to the fact that __extension__ doesn't currently silence extension-related diagnostics in subexpressions. For example, if you compile this: typedef unsigned __uint32_t; #define __byte_swap_int_var(x) \ __extension__ ({ register __uint32_t __X = (x); \ __asm ("bswap %0" : "+r" (__X)); \ __X; }) int test(int _x) { return (__byte_swap_int_var(_x)); } with: clang ~/t.c -parse-ast-print -pedantic You get: /Users/sabre/t.c:5:4: warning: extension used __asm ("bswap %0" : "+r" (__X)); \ ^ typedef unsigned int __uint32_t; /Users/sabre/t.c:9:10: warning: use of GNU statement expression extension return (__byte_swap_int_var(_x)); ^ /Users/sabre/t.c:9:10: warning: extension used return (__byte_swap_int_var(_x)); ^ /Users/sabre/t.c:9:10: warning: expression result unused return (__byte_swap_int_var(_x)); ^~~~~~~~~~~~~~~~~~~ Bus error Because those extension warnings are inside a __extension__ node, they should not be emitted. The actual problem happening here is that we don't current build an AST node for the GNU statement expression extension. This is the TODO on line 864 of ParseExpr.cpp. In the future, if you run into a problem, please include a self- contained testcase, like the example I provide above. This makes it much easier to understand what problem you're hitting. In any case, I'll add the AST node and get the example working. Thanks! -Chris From clattner at apple.com Tue Jul 24 11:21:35 2007 From: clattner at apple.com (Chris Lattner) Date: Tue, 24 Jul 2007 09:21:35 -0700 Subject: [cfe-dev] core dump, how to best investigate In-Reply-To: <20070724134319.GT14220@nexus.in-nomine.org> References: <20070724120357.GR14220@nexus.in-nomine.org> <20070724134000.GS14220@nexus.in-nomine.org> <20070724134319.GT14220@nexus.in-nomine.org> Message-ID: <9E6CF74E-4E99-4B25-89A1-9796D6BC5F18@apple.com> On Jul 24, 2007, at 6:43 AM, Jeroen Ruigrok van der Werven wrote: > -On [20070724 15:40], Jeroen Ruigrok van der Werven (asmodai at in- > nomine.org) wrote: >> So ParseUnaryOp() has an input which is empty and as such >> resultType = >> Input->getType(); fails. > > Would it make sense to add a fail-safe in the form of (excuse my C+ > + I'm > better in C and C#): > > if (Input == NULL) { > bail_out(); > } > resultType = Input->getType(); Yep, generally the idiom would be: assert(Input && "Expected an input AST node"); -Chris From hyperquantum at gmail.com Tue Jul 24 11:42:03 2007 From: hyperquantum at gmail.com (HyperQuantum) Date: Tue, 24 Jul 2007 18:42:03 +0200 Subject: [cfe-dev] wrong comment Message-ID: <20d882600707240942v60ef54dfhcb7aafe74642ee47@mail.gmail.com> I stumbled upon a wrong comment in the source of Parser.cpp. So here is my first little patch. HTH, Kevin Andr? -------------- next part -------------- A non-text attachment was scrubbed... Name: comment.patch Type: application/octet-stream Size: 669 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20070724/47a8ff8b/attachment.obj From asmodai at in-nomine.org Tue Jul 24 11:45:51 2007 From: asmodai at in-nomine.org (Jeroen Ruigrok van der Werven) Date: Tue, 24 Jul 2007 18:45:51 +0200 Subject: [cfe-dev] extern supported yet? In-Reply-To: <7CA85D5D-0533-48D6-942A-238ACE2641FF@apple.com> References: <20070724091348.GQ14220@nexus.in-nomine.org> <7CA85D5D-0533-48D6-942A-238ACE2641FF@apple.com> Message-ID: <20070724164551.GU14220@nexus.in-nomine.org> -On [20070724 17:58], Chris Lattner (clattner at apple.com) wrote: >If you're asking, I assume you hit a bug. What isn't working? [18:40] [asmodai at nexus] (1130) {139} % clang char.c char.c:166:12: error: redefinition of 'groups' char_group groups[MAX_GROUPS]; ^ In file included from char.c:56: ./char.h:133:19: error: previous definition is here extern char_group groups[]; ^ Additional information: typedef struct { char *name; letter *defn; } char_group; For all I know this should be valid. At least icc and gcc don't complain about it. And verifying with my standards and reference works I cannot see why it is failing. -- Jeroen Ruigrok van der Werven / asmodai ????? ?????? ??? ?? ?????? http://www.in-nomine.org/ | http://www.rangaku.org/ Religion... Is the opium of the people... From clattner at apple.com Tue Jul 24 12:01:47 2007 From: clattner at apple.com (Chris Lattner) Date: Tue, 24 Jul 2007 10:01:47 -0700 Subject: [cfe-dev] core dump, how to best investigate In-Reply-To: <693A39E5-0EBE-48E8-B7B5-BCAC81182DCE@apple.com> References: <20070724120357.GR14220@nexus.in-nomine.org> <20070724134000.GS14220@nexus.in-nomine.org> <693A39E5-0EBE-48E8-B7B5-BCAC81182DCE@apple.com> Message-ID: <8F1BA52B-E6DB-4B07-B3D4-0826F3448E7A@apple.com> > typedef unsigned __uint32_t; > > #define __byte_swap_int_var(x) \ > __extension__ ({ register __uint32_t __X = (x); \ > __asm ("bswap %0" : "+r" (__X)); \ > __X; }) > > int test(int _x) { > return (__byte_swap_int_var(_x)); > } > > In any case, I'll add the AST node and get the example working. > Thanks! Here ya go: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of- Mon-20070723/001371.html This implements ast building and semantic analysis, but not codegen support. On the example above, you get: $ clang test/Sema/stmt_exprs.c -parse-ast-print typedef unsigned int __uint32_t; test/Sema/stmt_exprs.c:11:10: warning: expression result unused return (__byte_swap_int_var(_x)); ^~~~~~~~~~~~~~~~~~~ int test(int _x) { return (__extension__({ register __uint32_t __X = (_x); __X; })); } 1 diagnostic generated. There are two issues here: 1. We don't currently build an AST node for GNU inline asm stmts, so the dump above doesn't include it. 2. We emit an 'expression result unused' warning for the "__X;" statement at the end of the compound stmt, even though it is used by the stmt expr. If you'd be interested in helping out with either of these, go for it :) -Chris From clattner at apple.com Tue Jul 24 12:03:39 2007 From: clattner at apple.com (Chris Lattner) Date: Tue, 24 Jul 2007 10:03:39 -0700 Subject: [cfe-dev] wrong comment In-Reply-To: <20d882600707240942v60ef54dfhcb7aafe74642ee47@mail.gmail.com> References: <20d882600707240942v60ef54dfhcb7aafe74642ee47@mail.gmail.com> Message-ID: On Jul 24, 2007, at 9:42 AM, HyperQuantum wrote: > I stumbled upon a wrong comment in the source of Parser.cpp. So here > is my first little patch. Applied, thanks! http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of- Mon-20070723/001372.html -Chris From clattner at apple.com Tue Jul 24 12:06:09 2007 From: clattner at apple.com (Chris Lattner) Date: Tue, 24 Jul 2007 10:06:09 -0700 Subject: [cfe-dev] extern supported yet? In-Reply-To: <20070724164551.GU14220@nexus.in-nomine.org> References: <20070724091348.GQ14220@nexus.in-nomine.org> <7CA85D5D-0533-48D6-942A-238ACE2641FF@apple.com> <20070724164551.GU14220@nexus.in-nomine.org> Message-ID: <7E95DA9A-2CC7-4CD2-A142-AB3610DBED5D@apple.com> On Jul 24, 2007, at 9:45 AM, Jeroen Ruigrok van der Werven wrote: > -On [20070724 17:58], Chris Lattner (clattner at apple.com) wrote: >> If you're asking, I assume you hit a bug. What isn't working? > > [18:40] [asmodai at nexus] (1130) {139} % clang char.c > char.c:166:12: error: redefinition of 'groups' > char_group groups[MAX_GROUPS]; > ^ > In file included from char.c:56: > ./char.h:133:19: error: previous definition is here > extern char_group groups[]; > ^ This is a bug or missing feature in the declaration merging code. Steve, can you take a look at this? Here's a self-contained example: int array[10]; extern int array[]; -Chris From asmodai at in-nomine.org Tue Jul 24 12:25:32 2007 From: asmodai at in-nomine.org (Jeroen Ruigrok van der Werven) Date: Tue, 24 Jul 2007 19:25:32 +0200 Subject: [cfe-dev] char and const char erroring out Message-ID: <20070724172532.GV14220@nexus.in-nomine.org> With a lot of Unix userland utilities this is a common occurence: #include int main(int argc, char *argv[]) { int ch; while ((ch = getopt(argc, argv, "h")) != -1) { switch (ch) { case 'h': return (-1); } } return (0); } [19:14] [asmodai at nexus] (1150) {18} % clang test.c test.c:8:28: error: incompatible types passing 'char *[]' to function expecting 'char *const []' while ((ch = getopt(argc, argv, "h")) != -1) { ~~~~~~ ^~~~ Well, it is correct yes, argv is a char *argv[] and the prototype of getopt() is as follows: int getopt(int argc, char * const argv[], const char *optstring); But in this case I think error is a pretty hefty one. You would not be able to compile any of the userland tools within any BSD like this. :) One could argue that the main call would need to be: int main(int argc, char * const argv[]) But C99 5.1.2.2.1 says: "The function called at program startup is named main. The implementation declares no prototype for this function. It shall be defined with a return type of int and with no parameters: int main(void) { /* ... */ } or with two parameters (referred to here as argc and argv, though any names may be used, as they are local to the function in which they are declared): int main(int argc, char *argv[]) { /* ... */ } or equivalent; or in some other implementation-defined manner." and "The parameters argc and argv and the strings pointed to by the argv array shall be modifiable by the program, and retain their last-stored values between program startup and program termination." so that solution is a no-no since it would not be compliment to the last paragraph. -- Jeroen Ruigrok van der Werven / asmodai ????? ?????? ??? ?? ?????? http://www.in-nomine.org/ | http://www.rangaku.org/ If you would thoroughly know anything, teach it to others... From snaroff at apple.com Tue Jul 24 12:43:52 2007 From: snaroff at apple.com (Steve Naroff) Date: Tue, 24 Jul 2007 10:43:52 -0700 Subject: [cfe-dev] extern supported yet? In-Reply-To: <7E95DA9A-2CC7-4CD2-A142-AB3610DBED5D@apple.com> References: <20070724091348.GQ14220@nexus.in-nomine.org> <7CA85D5D-0533-48D6-942A-238ACE2641FF@apple.com> <20070724164551.GU14220@nexus.in-nomine.org> <7E95DA9A-2CC7-4CD2-A142-AB3610DBED5D@apple.com> Message-ID: <2757AE95-77C5-44C7-BB5E-55499AF77144@apple.com> On Jul 24, 2007, at 10:06 AM, Chris Lattner wrote: > > On Jul 24, 2007, at 9:45 AM, Jeroen Ruigrok van der Werven wrote: > >> -On [20070724 17:58], Chris Lattner (clattner at apple.com) wrote: >>> If you're asking, I assume you hit a bug. What isn't working? >> >> [18:40] [asmodai at nexus] (1130) {139} % clang char.c >> char.c:166:12: error: redefinition of 'groups' >> char_group groups[MAX_GROUPS]; >> ^ >> In file included from char.c:56: >> ./char.h:133:19: error: previous definition is here >> extern char_group groups[]; >> ^ > > This is a bug or missing feature in the declaration merging code. > Steve, can you take a look at this? Here's a self-contained example: > > int array[10]; > extern int array[]; > This is a missing feature that has a clear FIXME... /// FIXME: Need to carefully consider tentative definition rules (C99 6.9.2p2). /// For example, we incorrectly complain about i1, i4 from C99 6.9.2p4. /// VarDecl *Sema::MergeVarDecl(VarDecl *New, Decl *OldD) { MergeTypedefDecl and MergeFunctionDecl are also incomplete. They both have TODO annotations... snaroff > -Chris > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20070724/bc6d0cb0/attachment.html From wilsonk at cpsc.ucalgary.ca Tue Jul 24 13:02:43 2007 From: wilsonk at cpsc.ucalgary.ca (Kelly Wilson) Date: Tue, 24 Jul 2007 12:02:43 -0600 (MDT) Subject: [cfe-dev] clang builds on Sparc/Linux! In-Reply-To: References: Message-ID: Hey Chris, On Tue, 24 Jul 2007, Chris Lattner wrote: >> The two problems with this output. "save -96, %o6, %o6" should read >> "save %o6, -96, %o6" at both function entry points, and the ".bss" >> section identifier needs to be removed. THEN GCC CAN ASSEMBLE/LINK >> THIS >> AND IT RUNS!!!!! Cool, now you have a new OS/arch pair to run LLVM on, >> though I may be the only one running this pair ;) >Very nice! I'm not sure how the arguments to save got transposed, it >must be a regression somewhere along the way. We don't have too many >people testing sparc :) This isn't actually an error of transposition for Sparc/SunOS when using the "cc" compiler. This "save -96, %o6, %o6" (and the .bss section identifier) work when using SunOS "cc" but not "gcc" under SunOS. My patches will assume that everyone is using "cc" under SunOS...because we can't check in llc whether someone will use "cc" or "gcc" to assemble and link in the future ;) Thanks, Kelly Wilson P.S. I will post patches to llvm-dev. From asmodai at in-nomine.org Tue Jul 24 14:37:24 2007 From: asmodai at in-nomine.org (Jeroen Ruigrok van der Werven) Date: Tue, 24 Jul 2007 21:37:24 +0200 Subject: [cfe-dev] extern supported yet? In-Reply-To: <2757AE95-77C5-44C7-BB5E-55499AF77144@apple.com> References: <20070724091348.GQ14220@nexus.in-nomine.org> <7CA85D5D-0533-48D6-942A-238ACE2641FF@apple.com> <20070724164551.GU14220@nexus.in-nomine.org> <7E95DA9A-2CC7-4CD2-A142-AB3610DBED5D@apple.com> <2757AE95-77C5-44C7-BB5E-55499AF77144@apple.com> Message-ID: <20070724193724.GW14220@nexus.in-nomine.org> -On [20070724 19:42], Steve Naroff (snaroff at apple.com) wrote: >This is a missing feature that has a clear FIXME... Yeah, sorry, still getting into the code base. -- Jeroen Ruigrok van der Werven / asmodai ????? ?????? ??? ?? ?????? http://www.in-nomine.org/ | http://www.rangaku.org/ You must be the change you wish to see in the world. - Mahatma Gandhi From snaroff at apple.com Tue Jul 24 15:09:14 2007 From: snaroff at apple.com (Steve Naroff) Date: Tue, 24 Jul 2007 13:09:14 -0700 Subject: [cfe-dev] extern supported yet? In-Reply-To: <20070724193724.GW14220@nexus.in-nomine.org> References: <20070724091348.GQ14220@nexus.in-nomine.org> <7CA85D5D-0533-48D6-942A-238ACE2641FF@apple.com> <20070724164551.GU14220@nexus.in-nomine.org> <7E95DA9A-2CC7-4CD2-A142-AB3610DBED5D@apple.com> <2757AE95-77C5-44C7-BB5E-55499AF77144@apple.com> <20070724193724.GW14220@nexus.in-nomine.org> Message-ID: <4CE94858-AAFB-4C14-97F8-EE239459A152@apple.com> On Jul 24, 2007, at 12:37 PM, Jeroen Ruigrok van der Werven wrote: > -On [20070724 19:42], Steve Naroff (snaroff at apple.com) wrote: >> This is a missing feature that has a clear FIXME... > > Yeah, sorry, still getting into the code base. > Understood (no problem). Fixing the Sema::Merge* functions is on our TODO list (probably 2-3 days work to complete and cross reference with the spec). Right now, I'm working on fixing the type checking issue you found. Should have a fix soon... snaroff > -- > Jeroen Ruigrok van der Werven / asmodai > ????? ?????? ??? ?? ?????? > http://www.in-nomine.org/ | http://www.rangaku.org/ > You must be the change you wish to see in the world. - Mahatma Gandhi From asmodai at in-nomine.org Wed Jul 25 00:39:15 2007 From: asmodai at in-nomine.org (Jeroen Ruigrok van der Werven) Date: Wed, 25 Jul 2007 07:39:15 +0200 Subject: [cfe-dev] Repo down Message-ID: <20070725053915.GZ14220@nexus.in-nomine.org> As soon as someone is available with sufficient rights, can he/she check why the repository is unreachable? [7:09] [asmodai at nexus] (2029) {0} % svn up svn: PROPFIND request failed on '/svn/llvm-project/cfe/trunk' svn: PROPFIND of '/svn/llvm-project/cfe/trunk': could not connect to server (http://llvm.org) It's pingable, just that http is dead. -- Jeroen Ruigrok van der Werven / asmodai ????? ?????? ??? ?? ?????? http://www.in-nomine.org/ | http://www.rangaku.org/ Crazy people don't think they're going crazy, they think they're getting saner. From clattner at apple.com Wed Jul 25 00:42:49 2007 From: clattner at apple.com (Chris Lattner) Date: Tue, 24 Jul 2007 22:42:49 -0700 Subject: [cfe-dev] Repo down In-Reply-To: <20070725053915.GZ14220@nexus.in-nomine.org> References: <20070725053915.GZ14220@nexus.in-nomine.org> Message-ID: On Jul 24, 2007, at 10:39 PM, Jeroen Ruigrok van der Werven wrote: > As soon as someone is available with sufficient rights, can he/she > check why > the repository is unreachable? > > [7:09] [asmodai at nexus] (2029) {0} % svn up > svn: PROPFIND request failed on '/svn/llvm-project/cfe/trunk' > svn: PROPFIND of '/svn/llvm-project/cfe/trunk': could not connect > to server > (http://llvm.org) > > It's pingable, just that http is dead. Yep, the web server is having some maintenance done: http://lists.cs.uiuc.edu/pipermail/llvmdev/2007-July/010055.html Sorry for the interruption, -Chris From asmodai at in-nomine.org Wed Jul 25 00:43:08 2007 From: asmodai at in-nomine.org (Jeroen Ruigrok van der Werven) Date: Wed, 25 Jul 2007 07:43:08 +0200 Subject: [cfe-dev] Repo down In-Reply-To: References: <20070725053915.GZ14220@nexus.in-nomine.org> Message-ID: <20070725054308.GA14220@nexus.in-nomine.org> -On [20070725 07:41], Chris Lattner (clattner at apple.com) wrote: >Yep, the web server is having some maintenance done: >http://lists.cs.uiuc.edu/pipermail/llvmdev/2007-July/010055.html Ahh, should've guessed. Only defence I have is that I don't monitor that list. ;) >Sorry for the interruption, No worries. Just wanted to give someone a heads up. -- Jeroen Ruigrok van der Werven / asmodai ????? ?????? ??? ?? ?????? http://www.in-nomine.org/ | http://www.rangaku.org/ A thousand times these mysteries unfold themselves like galaxies in my head... From hyperquantum at gmail.com Wed Jul 25 10:20:11 2007 From: hyperquantum at gmail.com (HyperQuantum) Date: Wed, 25 Jul 2007 17:20:11 +0200 Subject: [cfe-dev] wrong comment In-Reply-To: <20d882600707240942v60ef54dfhcb7aafe74642ee47@mail.gmail.com> References: <20d882600707240942v60ef54dfhcb7aafe74642ee47@mail.gmail.com> Message-ID: <20d882600707250820t12c3879btdcec330ad6e63610@mail.gmail.com> On 7/24/07, HyperQuantum wrote: > I stumbled upon a wrong comment in the source of Parser.cpp. So here > is my first little patch. The previous patch only corrected the comment in the cpp file. The header file Parser.h contains the same error, so here's fix no. 2. Greetings Kevin Andr? -- "Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats." -- Howard Aiken -------------- next part -------------- A non-text attachment was scrubbed... Name: comment2.patch Type: application/octet-stream Size: 644 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20070725/44598ef3/attachment.obj From clattner at apple.com Wed Jul 25 11:13:18 2007 From: clattner at apple.com (Chris Lattner) Date: Wed, 25 Jul 2007 09:13:18 -0700 Subject: [cfe-dev] proto web site set up Message-ID: FYI, I gathered various tidbits about the new front-end and put them up here: http://clang.llvm.org/ This is obviously just a placeholder page until I get time to do more. If you'd like to hack on it, the content is in the clang/www and clang/docs directory (docs maps to http://clang.llvm.org/ and http:// clang.llvm.org/docs/ ). This is currently synched to the web site once a day, but I'm going to work on getting that to once and hour or (better yet) instantly available. -Chris From asmodai at in-nomine.org Thu Jul 26 00:27:08 2007 From: asmodai at in-nomine.org (Jeroen Ruigrok van der Werven) Date: Thu, 26 Jul 2007 07:27:08 +0200 Subject: [cfe-dev] Wrong diagnostic for ternary operator Message-ID: <20070726052708.GC14220@nexus.in-nomine.org> This is a simplification of some code I let clang loose on: #include int main(void) { int test = 0; printf("Type is %s\n", (test >= 1 ? "short" : "char")); return (0); } It comes up with a diagnostic that's misleading upon first read. t.c:7:36: error: incompatible operand types ('char *' and 'char *') printf("Type is %s\n", (test >= 1 ? "short" : "char")); ^ ~~~~~~~ ~~~~~~ 1 diagnostic generated. I think the average developer will wonder why "short" and "char" are incompatible, especially since the tildes draw attention to that. The accent circumflex gets lost in the noise. The code in question used this to toggle which text to use in a %s argument to a printf() call and is quite valid. -- Jeroen Ruigrok van der Werven / asmodai ????? ?????? ??? ?? ?????? http://www.in-nomine.org/ | http://www.rangaku.org/ The last word in a chronicle is never set down... From neil at daikokuya.co.uk Thu Jul 26 07:54:15 2007 From: neil at daikokuya.co.uk (Neil Booth) Date: Thu, 26 Jul 2007 21:54:15 +0900 Subject: [cfe-dev] Wrong diagnostic for ternary operator In-Reply-To: <20070726052708.GC14220@nexus.in-nomine.org> References: <20070726052708.GC14220@nexus.in-nomine.org> Message-ID: <20070726125415.GF14793@daikokuya.co.uk> Jeroen Ruigrok van der Werven wrote:- > This is a simplification of some code I let clang loose on: > > #include > > int > main(void) { > int test = 0; > > printf("Type is %s\n", (test >= 1 ? "short" : "char")); > > return (0); > } > > It comes up with a diagnostic that's misleading upon first read. > > t.c:7:36: error: incompatible operand types ('char *' and 'char *') > printf("Type is %s\n", (test >= 1 ? "short" : "char")); > ^ ~~~~~~~ ~~~~~~ > 1 diagnostic generated. > > I think the average developer will wonder why "short" and "char" are > incompatible, especially since the tildes draw attention to that. The accent > circumflex gets lost in the noise. > > The code in question used this to toggle which text to use in a %s argument to > a printf() call and is quite valid. I'd guess operand decay isn't happening. Neil. From snaroff at apple.com Thu Jul 26 09:41:06 2007 From: snaroff at apple.com (Steve Naroff) Date: Thu, 26 Jul 2007 07:41:06 -0700 Subject: [cfe-dev] Wrong diagnostic for ternary operator In-Reply-To: <20070726125415.GF14793@daikokuya.co.uk> References: <20070726052708.GC14220@nexus.in-nomine.org> <20070726125415.GF14793@daikokuya.co.uk> Message-ID: On Jul 26, 2007, at 5:54 AM, Neil Booth wrote: > Jeroen Ruigrok van der Werven wrote:- > >> This is a simplification of some code I let clang loose on: >> >> #include >> >> int >> main(void) { >> int test = 0; >> >> printf("Type is %s\n", (test >= 1 ? "short" : "char")); >> >> return (0); >> } >> >> It comes up with a diagnostic that's misleading upon first read. >> >> t.c:7:36: error: incompatible operand types ('char *' and 'char *') >> printf("Type is %s\n", (test >= 1 ? "short" : "char")); >> ^ ~~~~~~~ ~~~~~~ >> 1 diagnostic generated. >> >> I think the average developer will wonder why "short" and "char" are >> incompatible, especially since the tildes draw attention to that. >> The accent >> circumflex gets lost in the noise. >> >> The code in question used this to toggle which text to use in a %s >> argument to >> a printf() call and is quite valid. > > I'd guess operand decay isn't happening. > The bug was more primitive...I was missing a return statement. There is still a FIXME (need to return the "composite" type). snaroff > Neil. > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From snaroff at apple.com Thu Jul 26 09:43:03 2007 From: snaroff at apple.com (Steve Naroff) Date: Thu, 26 Jul 2007 07:43:03 -0700 Subject: [cfe-dev] Wrong diagnostic for ternary operator In-Reply-To: <20070726052708.GC14220@nexus.in-nomine.org> References: <20070726052708.GC14220@nexus.in-nomine.org> Message-ID: <7C20F49F-15D0-44D5-9DED-44E685B07E6D@apple.com> Thanks for the bug report. Just checked in a fix... snaroff On Jul 25, 2007, at 10:27 PM, Jeroen Ruigrok van der Werven wrote: > This is a simplification of some code I let clang loose on: > > #include > > int > main(void) { > int test = 0; > > printf("Type is %s\n", (test >= 1 ? "short" : "char")); > > return (0); > } > > It comes up with a diagnostic that's misleading upon first read. > > t.c:7:36: error: incompatible operand types ('char *' and 'char *') > printf("Type is %s\n", (test >= 1 ? "short" : "char")); > ^ ~~~~~~~ ~~~~~~ > 1 diagnostic generated. > > I think the average developer will wonder why "short" and "char" are > incompatible, especially since the tildes draw attention to that. > The accent > circumflex gets lost in the noise. > > The code in question used this to toggle which text to use in a %s > argument to > a printf() call and is quite valid. > > -- > Jeroen Ruigrok van der Werven / asmodai > ????? ?????? ??? ?? ?????? > http://www.in-nomine.org/ | http://www.rangaku.org/ > The last word in a chronicle is never set down... > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From asmodai at in-nomine.org Thu Jul 26 09:48:59 2007 From: asmodai at in-nomine.org (Jeroen Ruigrok van der Werven) Date: Thu, 26 Jul 2007 16:48:59 +0200 Subject: [cfe-dev] Wrong diagnostic for ternary operator In-Reply-To: <7C20F49F-15D0-44D5-9DED-44E685B07E6D@apple.com> References: <20070726052708.GC14220@nexus.in-nomine.org> <7C20F49F-15D0-44D5-9DED-44E685B07E6D@apple.com> Message-ID: <20070726144859.GF14220@nexus.in-nomine.org> -On [20070726 16:41], Steve Naroff (snaroff at apple.com) wrote: >Thanks for the bug report. Just checked in a fix... Thanks Steve, still need to dig around the code more and grok it. So in the mean time I will keep pestering you guys with test cases like this. :) -- Jeroen Ruigrok van der Werven / asmodai ????? ?????? ??? ?? ?????? http://www.in-nomine.org/ | http://www.rangaku.org/ If you understand, things are as they are; if not, things are as they are... From snaroff at apple.com Thu Jul 26 12:03:30 2007 From: snaroff at apple.com (Steve Naroff) Date: Thu, 26 Jul 2007 10:03:30 -0700 Subject: [cfe-dev] Wrong diagnostic for ternary operator In-Reply-To: <20070726144859.GF14220@nexus.in-nomine.org> References: <20070726052708.GC14220@nexus.in-nomine.org> <7C20F49F-15D0-44D5-9DED-44E685B07E6D@apple.com> <20070726144859.GF14220@nexus.in-nomine.org> Message-ID: <82E8438E-0ADF-4F2F-B8F4-045855CD9CA3@apple.com> On Jul 26, 2007, at 7:48 AM, Jeroen Ruigrok van der Werven wrote: > -On [20070726 16:41], Steve Naroff (snaroff at apple.com) wrote: >> Thanks for the bug report. Just checked in a fix... > > Thanks Steve, > > still need to dig around the code more and grok it. So in the mean > time I will > keep pestering you guys with test cases like this. :) > Much appreciated (I don't feel pestered:-). I fully expect more type checking bugs (the code is fairly new and hasn't received much air time). Keep the test cases coming! snaroff > -- > Jeroen Ruigrok van der Werven / asmodai > ????? ?????? ??? ?? ?????? > http://www.in-nomine.org/ | http://www.rangaku.org/ > If you understand, things are as they are; if not, things are as > they are... From clattner at apple.com Tue Jul 31 01:39:15 2007 From: clattner at apple.com (Chris Lattner) Date: Mon, 30 Jul 2007 23:39:15 -0700 Subject: [cfe-dev] New Internals Manual Message-ID: <9022DEEE-A6F8-4040-A968-9519F1CD5E2A@apple.com> I uploaded a first cut of an internals manual for clang here: http://llvm.org/cfe/docs/InternalsManual.html It describes some of the more interesting classes, but is obviously missing a lot. It will eventually get a CSS file that makes it look less boring :) Patches welcome, -Chris