From clattner at apple.com Tue Jul 1 00:28:53 2008 From: clattner at apple.com (Chris Lattner) Date: Mon, 30 Jun 2008 22:28:53 -0700 Subject: [cfe-dev] Review request: Patch for adding raw string support to clang In-Reply-To: <4865FD40.9090403@laposte.net> References: <48639414.5050606@laposte.net> <4865FD40.9090403@laposte.net> Message-ID: <826586A0-4A97-4030-853D-AE56326FA1C4@apple.com> On Jun 28, 2008, at 1:58 AM, C?dric Venet wrote: Hi C?dric, I know very little about this feature and haven't studied the wording, but here are some thoughts. This is actually a pretty nifty feature! >>> >>> + case tok::raw_string_literal: // TO REVIEW: objC and C++0x >>> possible? >>> >> >> What's the question? >> > > I was wondering if we could encounter a C++0x specific token in an > objC parser function... Anyways, adding the case is the safe > alternative and don't cost much. Yes, you definitely can. The "Objective C++" language contains a superset of C++ and Objective C features. However, I don't think we should allow @R"...", please do not accept this. > Thanks for taking the time. I attached a modified patch. And I > changed the option for thunderbird, so it should be correctly > attached. ok: +DIAG(err_too_much_dchars_rawstring, ERROR, + "The d-chars part of the string is too long (16 max)") What are d-chars? This is great for someone well versed in standardese, but not very useful for an end user. How about "raw string prefix too long"? +DIAG(err_invalid_dchar, ERROR, + "The d-chars part of a raw string should not contain space, left square" + " bracket [, right square bracket ], horizontal tab, vertical tab," + " form feed or new-line") This is too long. A diagnostic should be ~65 chars max with very few exceptions. Also, diagnostics should not be sentences, they should be all lower case. +TOK(raw_string_literal) // R"**[foo]**" (N2442) N2442 should be a more structured reference. How about "C++ working paper N2442"? +void Lexer::LexRawStringLiteral(Token &Result, const char *CurPtr, bool Wide) { +/* from http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2442.htm +raw-string: + "d-char-sequence_opt[r-char-sequence_opt]d-char-sequence_opt" The comment should go in a doxygen (///) comment above the method like other lexer methods. + // TO REVIEW: Is this the corect way to return from error? + // should we attempt to recuperate on error here? + Result.setKind(tok::unknown); + FormTokenWithChars(Result, CurPtr-1); + return; This is the right thing to do. + } else if (C == ' ' || C == ']' || C == '\t' || C == '\n' || C == '\f' + || C == '\v' || C == '\r') { + // TO REVIEW: how to set the error carret on the erroneous char? + Diag(BufferPtr, diag::err_invalid_dchar); This should do the right thing, please write a testcase. If this is one character *after* the intended one, just safe BufferPtr from before the call to getAndAdvanceChar and report it at that "const char*" location. + // TO REVIEW: Is this the corect way to return from error? + // should we attempt to recuperate on error here? this is correct. @@ -1294,6 +1399,18 @@ return LexStringLiteral(Result, ConsumeChar(CurPtr, SizeTmp, Result), true); + if(Char == 'R') { + const char* NextCharPtr=CurPtr+SizeTmp; + unsigned int NextSizeTmp; This should have a comment explaining what it is: e.g. LR"**[wide long string]**" Please add a space after the 'if'. + if(NextChar=='"') { This one too. + // TO REVIEW: do we need to consume each char of the token? + ConsumeChar(CurPtr, SizeTmp, Result); Please write a testcase to verify :) + return LexRawStringLiteral(Result, ConsumeChar(NextCharPtr, NextSizeTmp,Result), + true); 80 columns. +++ lib/Lex/LiteralSupport.cpp (working copy) @@ -608,7 +608,8 @@ MaxTokenLength = StringToks[i].getLength(); // Remember if we see any wide strings. - AnyWide |= StringToks[i].is(tok::wide_string_literal); + AnyWide |= StringToks[i].is(tok::wide_string_literal) The grammar above the StringLiteralParser ctor should be updated. It seems that the normal and raw string code in LiteralSupport are pretty distinct. How about splitting them out into two separate methods of StringLiteralParser? Please add several testcases for this feature to the clang testcase, verifying that the parser accepts valid cases and rejects invalid ones. Also, please add a simple codegen test. If you need help with these, please let me know. -Chris From clattner at apple.com Tue Jul 1 00:36:01 2008 From: clattner at apple.com (Chris Lattner) Date: Mon, 30 Jun 2008 22:36:01 -0700 Subject: [cfe-dev] New diff In-Reply-To: References: <9190D6D0-D4AC-4D9A-A6E1-435D51ECE51C@apple.com> <27956C03-C185-4463-AE53-AD3CF4E8DDD9@apple.com> Message-ID: <390B3F07-8AFD-4CDF-86B4-3360B8530533@apple.com> On Jun 30, 2008, at 6:43 AM, David Chisnall wrote: > On 29 Jun 2008, at 00:16, Chris Lattner wrote: >> >>> Here's a new version. It pulls out most of the cases where the >>> value from an llvm::Constant is taken in CodeGen and passes in the >>> initialisers instead. >> >> Now you're copying strings around all over the place for no >> reason. Converting things to a vector does a bunch of >> string copies. Why do we want this? > > Ideally I wouldn't. I'd want it to just take references, but since > Selector returns a string, rather than a pointer to a string, a copy > is required, and I made the others strings for consistency. Why not pass the selector around? It is exactly one word and is cheap to copy. It is perfect for this sort of interface. > Selector objects are not an adequate abstraction here because they > do not contain type information, Neither do strings. > which we can extract from the AST, and they are not really the > right thing to pass in semantically since it is the method name, not > the selector, that we want (the two are often used interchangeably, > but are not the same). Why not? >>> I've also changed it so that the Selector passed to the the >>> methods for generating message sends is a selector, rather than >>> the name of a selector. This should be previously obtained by >>> GetSelector. There are now two versions of this, one taking a >>> pair of char*s and one taking a pair of llvm::Value*s as arguments. >> >> I don't understand where you're going with this. You've taken all >> the nice simple APIs that take Selectors and pass Value*'s around. >> You are inverting the logic of the code generator to avoid passing >> in clang data structures. > > This part of the change is definitely cleaner. The runtime > interface now more closely mirrors how message dispatch works (as a > two stage process, getting the selector and sending the message). > It also allows as much type information to be provided to the > runtime as is available. Since clang knows the types of the > arguments being passed, it can pass this when looking up the > selector (it doesn't yet), without changing the message send > method. This will aid debugging Objective-C code in the future, > since a runtime exception can be thrown if a method is called with > arguments of the wrong type: this is not always possible to detect > at compile time, and currently causes a corrupt stack and is a > colossal pain to trace. Is this something supported by existing ObjC runtimes or some new feature you are prototyping? I don't see how this relates to the Selector vs string issue, since neither provides type info. >> Further, I don't see why the ObjC codegen stuff shouldn't pull in >> CodeGenModule. It seems that you're again inverting control flow >> here to eliminate a very reasonable dependency. Because of this, >> you've reinvented things (like CGObjCGNU::MakeConstantString), and >> introduced problems (e.g. MakeConstantString doesn't unique the >> strings like CGM's does). > > I would be more than happy to refactor this to reuse existing code > if it can be done in a way that didn't introduce direct dependencies > on clang. I would propose creating a delegate object that can be > passed in, which exposes any methods in CGM that are needed and can > be replaced by a different delegate in other implementations, if > this would be acceptable. Not acceptable. Why not just have your other implementations provide a corresponding version of CGM and Selector that they can pass around? >> I understand (now) that you are trying to reuse the clang codegen >> in the context of your smalltalk implementation. > > And in other compilers. The Nu team recently approached me to > discuss using the code for their object model (currently they target > the Apple runtime directly), and others are planning on using it for > JavaScript and Io ports. > > I have found bugs in the clang code directly as a result of using it > in other work, and I consider reuse to be an important way of > testing the code. I would rather not have to maintain a portable > and a clang version of this code, since it would mean that bug fixes > would take much longer to make their way into clang. That is very cool and I don't want to lose that. However, clang maintainability and performance is my #1 prio, so it trumps reusability of the code in other contexts. I think that we really just need to find the right way to factor this, I think we can come to a design that fits both purposes reasonably well. >> While this is an interesting goal, this is *not* an acceptable >> reason to make the clang ObjC codegen code inefficient and weird. > > Weird is highly subjective - I consider that the code now > corresponds closely to the object model semantics, and so don't find > it weird. Inefficient is probably true, and I would welcome any > constructive suggestions for optimisation. You're right and I was being overly critical here. The thing I really didn't like about the old design is that you emitted dead strings to LLVM IR and read them back out on the "other side" of the boundary. Passing std::strings around *is* a step up from that, but it still isn't as efficient as passing around Selectors. >> I'm somewhat ok with you adding codepaths that are not used by >> clang (and are thus dead) as long as they are not huge, but making >> codepaths clang *does* use inefficient and inelegant is not >> acceptable. > > I have not written anything in this file which is not intended for > use in compiling Objective-C. Some parts are not yet connected to > implementations, however anything intended for other languages I > have kept in separate files and not submitted. The only code paths > that are dead are ones where I have not yet written the calling code. There was code in the file for handling "typed selectors" which was dead. -Chris From filcab at gmail.com Tue Jul 1 05:35:53 2008 From: filcab at gmail.com (Filipe Cabecinhas) Date: Tue, 1 Jul 2008 11:35:53 +0100 Subject: [cfe-dev] Function pointer variables In-Reply-To: <642FFF7A-76B8-406E-92D2-BEA9C4F53AD5@apple.com> References: <83768C56-0B83-46F4-AB72-551529A61A58@gmail.com> <19C8BB23-4720-4331-A0AD-14E534A86E7E@gmail.com> <6660A913-58FC-43A9-A0EC-615A7B8505B6@gmail.com> <642FFF7A-76B8-406E-92D2-BEA9C4F53AD5@apple.com> Message-ID: <25BE2F28-34C4-4DFC-BC4B-BA97789FCA33@gmail.com> Hi, I reported the bug at bugzilla and, with Eli Friedman, we narrowed it down to MergeVarDecl. I changed the "OldCType != NewCType" to a call to typesAreCompatible(). I kept the call to areEquivalentArrayTypes but, as Eli pointed out, maybe it's doing checks that are already done in typesAreCompatible(). - Filipe Cabecinhas -------------- next part -------------- A non-text attachment was scrubbed... Name: clang-functionTypes.diff Type: application/octet-stream Size: 703 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080701/f9d9ffeb/attachment.obj From akyrtzi at gmail.com Tue Jul 1 06:11:54 2008 From: akyrtzi at gmail.com (Argiris Kirtzidis) Date: Tue, 01 Jul 2008 04:11:54 -0700 Subject: [cfe-dev] [PATCH]: Sema support for C++ classes In-Reply-To: References: <48627714.7020806@gmail.com> <84382ECA-17AC-4C3E-A79A-E6BEAC5BD477@apple.com> <4865846D.9060100@gmail.com> <4865F4A9.4040408@gmail.com> Message-ID: <486A10FA.1040109@gmail.com> Eli Friedman wrote: > On Sat, Jun 28, 2008 at 1:22 AM, Argiris Kirtzidis wrote: > >> I attached a new patch for Sema support, with the suggestions. >> > > + // FIXME: Use DeclRefExpr or a new Expr for a direct CXXField reference. > + ExprResult ThisExpr = ActOnCXXThis(Loc); > > Make this line "ExprResult ThisExpr = > ActOnCXXThis(SourceLocation());". (This isn't really the right fix, > but it's a bit better than what's there.) > Done! http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20080630/006315.html -Argiris From csdavec at swansea.ac.uk Tue Jul 1 08:14:47 2008 From: csdavec at swansea.ac.uk (David Chisnall) Date: Tue, 1 Jul 2008 14:14:47 +0100 Subject: [cfe-dev] New diff In-Reply-To: <390B3F07-8AFD-4CDF-86B4-3360B8530533@apple.com> References: <9190D6D0-D4AC-4D9A-A6E1-435D51ECE51C@apple.com> <27956C03-C185-4463-AE53-AD3CF4E8DDD9@apple.com> <390B3F07-8AFD-4CDF-86B4-3360B8530533@apple.com> Message-ID: <53B3901C-3C27-48E3-A9A8-65DDF6AA6FCB@swan.ac.uk> Okay, I think this all makes sense. I'll add back in the Selector and CGM dependency, and resubmit the diff. It will take me a little while to refactor and test it with both codebases, but I hope to have something for you this week (the code for typed selectors isn't dead, it's just resting. Both the GNU and ?toil? runtimes use these and can easily - or do already - support errors on lookups with incorrectly typed selectors. The GNUstep implementation of Distributed Objects is also faster if typed selectors are used, since it avoids the extra call to -methodSignatureForSelector: which can trigger a dozen or so message sends to look up information which can be provided by the compiler). David On 1 Jul 2008, at 06:36, Chris Lattner wrote: > On Jun 30, 2008, at 6:43 AM, David Chisnall wrote: >> On 29 Jun 2008, at 00:16, Chris Lattner wrote: >>> >>>> Here's a new version. It pulls out most of the cases where the >>>> value from an llvm::Constant is taken in CodeGen and passes in >>>> the initialisers instead. >>> >>> Now you're copying strings around all over the place for no >>> reason. Converting things to a vector does a bunch >>> of string copies. Why do we want this? >> >> Ideally I wouldn't. I'd want it to just take references, but since >> Selector returns a string, rather than a pointer to a string, a >> copy is required, and I made the others strings for consistency. > > Why not pass the selector around? It is exactly one word and is > cheap to copy. It is perfect for this sort of interface. > >> Selector objects are not an adequate abstraction here because they >> do not contain type information, > > Neither do strings. > >> which we can extract from the AST, and they are not really the >> right thing to pass in semantically since it is the method name, >> not the selector, that we want (the two are often used >> interchangeably, but are not the same). > > Why not? > >>>> I've also changed it so that the Selector passed to the the >>>> methods for generating message sends is a selector, rather than >>>> the name of a selector. This should be previously obtained by >>>> GetSelector. There are now two versions of this, one taking a >>>> pair of char*s and one taking a pair of llvm::Value*s as arguments. >>> >>> I don't understand where you're going with this. You've taken all >>> the nice simple APIs that take Selectors and pass Value*'s >>> around. You are inverting the logic of the code generator to >>> avoid passing in clang data structures. >> >> This part of the change is definitely cleaner. The runtime >> interface now more closely mirrors how message dispatch works (as a >> two stage process, getting the selector and sending the message). >> It also allows as much type information to be provided to the >> runtime as is available. Since clang knows the types of the >> arguments being passed, it can pass this when looking up the >> selector (it doesn't yet), without changing the message send >> method. This will aid debugging Objective-C code in the future, >> since a runtime exception can be thrown if a method is called with >> arguments of the wrong type: this is not always possible to detect >> at compile time, and currently causes a corrupt stack and is a >> colossal pain to trace. > > Is this something supported by existing ObjC runtimes or some new > feature you are prototyping? I don't see how this relates to the > Selector vs string issue, since neither provides type info. > >>> Further, I don't see why the ObjC codegen stuff shouldn't pull in >>> CodeGenModule. It seems that you're again inverting control flow >>> here to eliminate a very reasonable dependency. Because of this, >>> you've reinvented things (like CGObjCGNU::MakeConstantString), and >>> introduced problems (e.g. MakeConstantString doesn't unique the >>> strings like CGM's does). >> >> I would be more than happy to refactor this to reuse existing code >> if it can be done in a way that didn't introduce direct >> dependencies on clang. I would propose creating a delegate object >> that can be passed in, which exposes any methods in CGM that are >> needed and can be replaced by a different delegate in other >> implementations, if this would be acceptable. > > Not acceptable. Why not just have your other implementations > provide a corresponding version of CGM and Selector that they can > pass around? > > >>> I understand (now) that you are trying to reuse the clang codegen >>> in the context of your smalltalk implementation. >> >> And in other compilers. The Nu team recently approached me to >> discuss using the code for their object model (currently they >> target the Apple runtime directly), and others are planning on >> using it for JavaScript and Io ports. >> >> I have found bugs in the clang code directly as a result of using >> it in other work, and I consider reuse to be an important way of >> testing the code. I would rather not have to maintain a portable >> and a clang version of this code, since it would mean that bug >> fixes would take much longer to make their way into clang. > > That is very cool and I don't want to lose that. However, clang > maintainability and performance is my #1 prio, so it trumps > reusability of the code in other contexts. I think that we really > just need to find the right way to factor this, I think we can come > to a design that fits both purposes reasonably well. > >>> While this is an interesting goal, this is *not* an acceptable >>> reason to make the clang ObjC codegen code inefficient and weird. >> >> Weird is highly subjective - I consider that the code now >> corresponds closely to the object model semantics, and so don't >> find it weird. Inefficient is probably true, and I would welcome >> any constructive suggestions for optimisation. > > You're right and I was being overly critical here. The thing I > really didn't like about the old design is that you emitted dead > strings to LLVM IR and read them back out on the "other side" of the > boundary. Passing std::strings around *is* a step up from that, but > it still isn't as efficient as passing around Selectors. > >>> I'm somewhat ok with you adding codepaths that are not used by >>> clang (and are thus dead) as long as they are not huge, but making >>> codepaths clang *does* use inefficient and inelegant is not >>> acceptable. >> >> I have not written anything in this file which is not intended for >> use in compiling Objective-C. Some parts are not yet connected to >> implementations, however anything intended for other languages I >> have kept in separate files and not submitted. The only code paths >> that are dead are ones where I have not yet written the calling code. > > There was code in the file for handling "typed selectors" which was > dead. > > -Chris > From clattner at apple.com Tue Jul 1 12:06:18 2008 From: clattner at apple.com (Chris Lattner) Date: Tue, 1 Jul 2008 10:06:18 -0700 Subject: [cfe-dev] New diff In-Reply-To: <53B3901C-3C27-48E3-A9A8-65DDF6AA6FCB@swan.ac.uk> References: <9190D6D0-D4AC-4D9A-A6E1-435D51ECE51C@apple.com> <27956C03-C185-4463-AE53-AD3CF4E8DDD9@apple.com> <390B3F07-8AFD-4CDF-86B4-3360B8530533@apple.com> <53B3901C-3C27-48E3-A9A8-65DDF6AA6FCB@swan.ac.uk> Message-ID: <47B020E3-A6D5-404E-A630-7DE89A6E4BA0@apple.com> On Jul 1, 2008, at 6:14 AM, David Chisnall wrote: > Okay, I think this all makes sense. I'll add back in the Selector > and CGM dependency, and resubmit the diff. It will take me a little > while to refactor and test it with both codebases, but I hope to > have something for you this week Sounds great! Again, I'm sorry for pulling you around in multiple directions like this. I really do appreciate the work you are doing, and I highly value your contributions to clang! > (the code for typed selectors isn't dead, it's just resting. Both > the GNU and ?toil? runtimes use these and can easily - or do already > - support errors on lookups with incorrectly typed selectors. The > GNUstep implementation of Distributed Objects is also faster if > typed selectors are used, since it avoids the extra call to - > methodSignatureForSelector: which can trigger a dozen or so message > sends to look up information which can be provided by the compiler). Ok! I wasn't aware of that feature, sound nice. -Chris From thomascl at free.fr Tue Jul 1 16:33:33 2008 From: thomascl at free.fr (Thomas Clement) Date: Tue, 1 Jul 2008 23:33:33 +0200 Subject: [cfe-dev] Comparison of pointers between Objc subclasses Message-ID: <610BA04E-4EC1-4BE6-ACC1-0EF809234B91@free.fr> Hi, I'm not sure if this has already been discussed earlier, sorry if that's the case. I noticed that clang (-fsyntax-only) produces the following warning: MyClass.m:15:11: warning: comparison of distinct pointer types ('NSMutableArray *' and 'NSArray *') if (array != newArray) ~~~~~ ^ ~~~~~~~~ Since NSMutableArray is a subclass of NSArray, the warning doesn't seem really appropriate. Thanks, Thomas #import @interface MyClass { NSMutableArray *array; } - (void)setArray:(NSArray *)newArray; @end @implementation MyClass - (void)setArray:(NSArray *)newArray { if (array != newArray) { [array release]; array = [newArray mutableCopy]; } } @end From eli.friedman at gmail.com Tue Jul 1 17:40:11 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Tue, 1 Jul 2008 15:40:11 -0700 Subject: [cfe-dev] Comparison of pointers between Objc subclasses In-Reply-To: <610BA04E-4EC1-4BE6-ACC1-0EF809234B91@free.fr> References: <610BA04E-4EC1-4BE6-ACC1-0EF809234B91@free.fr> Message-ID: On Tue, Jul 1, 2008 at 2:33 PM, Thomas Clement wrote: > I noticed that clang (-fsyntax-only) produces the following warning: > > MyClass.m:15:11: warning: comparison of distinct pointer types > ('NSMutableArray *' and 'NSArray *') > if (array != newArray) > ~~~~~ ^ ~~~~~~~~ > > Since NSMutableArray is a subclass of NSArray, the warning doesn't > seem really appropriate. Probably caused by the fact that ASTContext::typesAreCompatible isn't commutative for ObjC types; clang currently considers (Base, Derived) to be compatible, while (Derived, Base) isn't. I actually have a patch that will fix that, but I'm not sure about some of the expectations for type compatibility and ObjC. Considering two ObjC pointers compatible in the C99 sense makes a lot of things legal which probably shouldn't be legal: for example, redeclaring a pointer to a base type as a pointer to a derived type is legal (illegal in C++), assigning a base type pointer to a derived type pointer is legal (requires a static_cast in C++), and assigning a pointer to a derived type pointer to a pointer to a base type pointer is legal (requires a reinterpret_cast in C++). Because of situations like these, C++ doesn't have type compatibility in the same sense; legal combinations of operands are defined on a case-by-case basis. What exactly are the rules supposed to be for ObjC? (Or, if the rules aren't written down anywhere, what does gcc do?) -Eli From devlists at shadowlab.org Tue Jul 1 18:06:41 2008 From: devlists at shadowlab.org (Jean-Daniel Dupas) Date: Wed, 2 Jul 2008 01:06:41 +0200 Subject: [cfe-dev] Comparison of pointers between Objc subclasses In-Reply-To: References: <610BA04E-4EC1-4BE6-ACC1-0EF809234B91@free.fr> Message-ID: Le 2 juil. 08 ? 00:40, Eli Friedman a ?crit : > On Tue, Jul 1, 2008 at 2:33 PM, Thomas Clement > wrote: >> I noticed that clang (-fsyntax-only) produces the following warning: >> >> MyClass.m:15:11: warning: comparison of distinct pointer types >> ('NSMutableArray *' and 'NSArray *') >> if (array != newArray) >> ~~~~~ ^ ~~~~~~~~ >> >> Since NSMutableArray is a subclass of NSArray, the warning doesn't >> seem really appropriate. > > Probably caused by the fact that ASTContext::typesAreCompatible isn't > commutative for ObjC types; clang currently considers (Base, Derived) > to be compatible, while (Derived, Base) isn't. I actually have a > patch that will fix that, but I'm not sure about some of the > expectations for type compatibility and ObjC. > > Considering two ObjC pointers compatible in the C99 sense makes a lot > of things legal which probably shouldn't be legal: for example, > redeclaring a pointer to a base type as a pointer to a derived type is > legal (illegal in C++), assigning a base type pointer to a derived > type pointer is legal (requires a static_cast in C++), and assigning a > pointer to a derived type pointer to a pointer to a base type pointer > is legal (requires a reinterpret_cast in C++). Because of situations > like these, C++ doesn't have type compatibility in the same sense; > legal combinations of operands are defined on a case-by-case basis. > What exactly are the rules supposed to be for ObjC? (Or, if the rules > aren't written down anywhere, what does gcc do?) > > -Eli At least for GCC: id generic; NSObject *base = nil; NSArray *array = nil; NSMutableArray *subArray = nil; base = array; // OK array = base; // Warning: assignment from distinct Obj-C Type array = subArray; // OK subArray = array; // Warning: assignment from distinct Obj-C Type generic = array; // OK array = generic; // OK -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080702/10a4b56b/attachment.bin From kremenek at apple.com Tue Jul 1 18:22:32 2008 From: kremenek at apple.com (Ted Kremenek) Date: Tue, 1 Jul 2008 16:22:32 -0700 Subject: [cfe-dev] Comparison of pointers between Objc subclasses In-Reply-To: References: <610BA04E-4EC1-4BE6-ACC1-0EF809234B91@free.fr> Message-ID: <824EC897-9645-44DA-BDD1-7C03982A173D@apple.com> On Jul 1, 2008, at 3:40 PM, Eli Friedman wrote: > On Tue, Jul 1, 2008 at 2:33 PM, Thomas Clement > wrote: >> I noticed that clang (-fsyntax-only) produces the following warning: >> >> MyClass.m:15:11: warning: comparison of distinct pointer types >> ('NSMutableArray *' and 'NSArray *') >> if (array != newArray) >> ~~~~~ ^ ~~~~~~~~ >> >> Since NSMutableArray is a subclass of NSArray, the warning doesn't >> seem really appropriate. > > Probably caused by the fact that ASTContext::typesAreCompatible isn't > commutative for ObjC types; clang currently considers (Base, Derived) > to be compatible, while (Derived, Base) isn't. I actually have a > patch that will fix that, but I'm not sure about some of the > expectations for type compatibility and ObjC. > > Considering two ObjC pointers compatible in the C99 sense makes a lot > of things legal which probably shouldn't be legal: for example, > redeclaring a pointer to a base type as a pointer to a derived type is > legal (illegal in C++), assigning a base type pointer to a derived > type pointer is legal (requires a static_cast in C++), and assigning a > pointer to a derived type pointer to a pointer to a base type pointer > is legal (requires a reinterpret_cast in C++). Because of situations > like these, C++ doesn't have type compatibility in the same sense; > legal combinations of operands are defined on a case-by-case basis. > What exactly are the rules supposed to be for ObjC? (Or, if the rules > aren't written down anywhere, what does gcc do?) Are pointer type compatibility checks for assignments and conversions being handled in the same way? I can understand why assigning a base type to a derived type is dangerous, but it seems to me that comparisons like these should be legal. I'm only raising this point because the code snippet with the warning involved a comparison, not an assignment. From eli.friedman at gmail.com Tue Jul 1 21:44:56 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Tue, 1 Jul 2008 19:44:56 -0700 Subject: [cfe-dev] Comparison of pointers between Objc subclasses In-Reply-To: <824EC897-9645-44DA-BDD1-7C03982A173D@apple.com> References: <610BA04E-4EC1-4BE6-ACC1-0EF809234B91@free.fr> <824EC897-9645-44DA-BDD1-7C03982A173D@apple.com> Message-ID: On Tue, Jul 1, 2008 at 4:22 PM, Ted Kremenek wrote: > Are pointer type compatibility checks for assignments and conversions being > handled in the same way? Assignment (from C99 6.5.16.1): One of the following shall hold: both operands are pointers to qualified or unqualified versions of compatible types, and the type pointed to by the left has all the qualifiers of the type pointed to by the right; Comparison (from C99 6.5.9): One of the following shall hold: both operands are pointers to qualified or unqualified versions of compatible types; And currently, we (inconsistently) consider ObjC base types and derived types compatible in the C99 sense, which is implemented in ASTContext::typesAreCompatible. -Eli From eli.friedman at gmail.com Tue Jul 1 21:50:15 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Tue, 1 Jul 2008 19:50:15 -0700 Subject: [cfe-dev] Comparison of pointers between Objc subclasses In-Reply-To: References: <610BA04E-4EC1-4BE6-ACC1-0EF809234B91@free.fr> Message-ID: On Tue, Jul 1, 2008 at 4:06 PM, Jean-Daniel Dupas wrote: > At least for GCC: > > id generic; > NSObject *base = nil; > NSArray *array = nil; > NSMutableArray *subArray = nil; > > base = array; // OK > array = base; // Warning: assignment from distinct Obj-C Type > > array = subArray; // OK > subArray = array; // Warning: assignment from distinct Obj-C Type > > generic = array; // OK > array = generic; // OK > Okay... would you mind checking few more potentially interesting cases? Redeclaration (i.e. nsarray*a;nsmutablearray*a;) Relational operators (<= and friends) Subtraction (i.e. nsarray-nsmutablearray) Assigning pointer to pointer (i.e. nsmutablearray**=nsarray**, and vice versa) I'd do it myself, but I don't know enough objc to write a testcase myself. -Eli From kremenek at apple.com Tue Jul 1 22:54:23 2008 From: kremenek at apple.com (Ted Kremenek) Date: Tue, 1 Jul 2008 20:54:23 -0700 Subject: [cfe-dev] Comparison of pointers between Objc subclasses In-Reply-To: References: <610BA04E-4EC1-4BE6-ACC1-0EF809234B91@free.fr> <824EC897-9645-44DA-BDD1-7C03982A173D@apple.com> Message-ID: <1341DC93-E993-4437-B650-E45008A8A175@apple.com> On Jul 1, 2008, at 7:44 PM, Eli Friedman wrote: > On Tue, Jul 1, 2008 at 4:22 PM, Ted Kremenek > wrote: >> Are pointer type compatibility checks for assignments and >> conversions being >> handled in the same way? > > Assignment (from C99 6.5.16.1): > One of the following shall hold: > > both operands are pointers to qualified or unqualified versions of > compatible types, and the type pointed to by the left has all the > qualifiers of the type pointed to by the right; > > > Comparison (from C99 6.5.9): > One of the following shall hold: > > both operands are pointers to qualified or unqualified versions of > compatible types; > > > And currently, we (inconsistently) consider ObjC base types and > derived types compatible in the C99 sense, which is implemented in > ASTContext::typesAreCompatible. Thanks Eli. C99 obviously doesn't stipulate the compatibility of pointers to Objective-C classes, which gets back to the original issue. In this regards, C99 6.5.9 might not even apply when comparing Objective-C types ("compatibility" is defined by an extended type system that is well beyond the scope of C99). This of course was the original issue. Because there is a subclassing relationship here between NSArray and NSMutableArray (which is a subtyping relationship from a PL theory standpoint), it makes sense to me that the pointer types are compatible, but I'm not an Objective-C lawyer. Incidentally, comparing a pointer to a derived type is with a pointer to a base type is okay in C++ (at least as far as C++ classes and g++ - pedantic is concerned; I'm not certain what the standard says): $ cat t.cpp class A {}; class B : public A {}; bool f(A* a, B* b) { return a == b; } $ g++ -pedantic -fsyntax-only t.cpp $ This example appears to be essentially the same as the one Thomas presented in his original email, except that we are dealing with C++ classes, not Objective-C classes. Incidentally, the following Objective-C example also passes with gcc -pedantic: $ cat t.m @interface A { int x; } @end @interface B : A { int y; } @end int f(A* a, B* b) { return a == b; } $ gcc -pedantic -fsytnax-only t.m $ If we remove the subtyping relationship between B and A, however, gcc issues a warning: $ cat t2.m @interface A { int x; } @end @interface B { int y; } @end int f(A* a, B* b) { return a == b; } $ gcc -fsyntax-only -pedantic t2.m t2.m: In function ?f?: t2.m:5: warning: comparison of distinct Objective-C types lacks a cast $ Now lets look at assignments (t3.m is the same as t.m except the comparison is now an assignment). Notice that B subclasses A: $ cat t3.m @interface A { int x; } @end @interface B : A { int y; } @end A* f(A* a, B* b) { return a = b; } $ gcc -pedantic -fsyntax-only t3.m $ What happens if we assign a to b (where B still subclasses A)? $ cat t4.m @interface A { int x; } @end @interface B : A { int y; } @end A* f(A* a, B* b) { return b = a; } $ gcc -pedantic -fsyntax-only t4.m t4.m: In function ?f?: t4.m:5: warning: assignment from distinct Objective-C type GCC's diagnostics are horrible, but I think this experiment illustrates that two Objective-C pointer types can be compared if one pointee subclasses the other (a subtyping relationship), and in an assignment two types are compatible if the type of the right expression subtypes the left expression. This makes sense because B* can be treated as an A*, but an A* cannot always be treated as a B* (since B is more specialized, and that A* might actually be a C*, where C subclasses A, but is neither a parent or subclass of B). So, I think the answers we are looking for are outside the letter of C99 standard. The Objective-C and C++ object type systems are a completely different animal. From eli.friedman at gmail.com Tue Jul 1 23:48:00 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Tue, 1 Jul 2008 21:48:00 -0700 Subject: [cfe-dev] Comparison of pointers between Objc subclasses In-Reply-To: <1341DC93-E993-4437-B650-E45008A8A175@apple.com> References: <610BA04E-4EC1-4BE6-ACC1-0EF809234B91@free.fr> <824EC897-9645-44DA-BDD1-7C03982A173D@apple.com> <1341DC93-E993-4437-B650-E45008A8A175@apple.com> Message-ID: On Tue, Jul 1, 2008 at 8:54 PM, Ted Kremenek wrote: > So, I think the answers we are looking for are outside the letter of C99 > standard. The Objective-C and C++ object type systems are a completely > different animal. Okay, so in that case typesAreCompatible should say that non-identical ObjC types aren't compatible, and the necessary handling for comparison/assignment/conditionals/whatever else is needed for ObjC pointers should move into SemaExpr. -Eli From wilsonkk at shaw.ca Wed Jul 2 00:49:50 2008 From: wilsonkk at shaw.ca (Kelly Wilson) Date: Tue, 01 Jul 2008 23:49:50 -0600 Subject: [cfe-dev] FW: GSL compiles pretty much Message-ID: <0K3D00AGX6V2RS00@l-daemon> Sorry, Didn't notice this was only sent to Eli. Thanks, K.Wilson -----Original Message----- From: Kelly Wilson [mailto:wilsonkk at shaw.ca] Sent: Tuesday, July 01, 2008 11:15 PM To: 'Eli Friedman' Subject: RE: [cfe-dev] GSL compiles pretty much Hey Eli, I found that the -O2 flag in the Makefile which makes the compilation of GSL fail is actually being passed to llvm-ld not ccc. If you set CFLAGS so that no -O2 argument is passed in (and -lm is), then things work. I am not sure why -lm is not being included by the configure script but it is easy to pass in, as well. Just type: export CFLAGS='-g'; export LDFLAGS='-lm'; ./configure in the gsl-1.11 directory (this is for the bash shell with debugging) and everything compiles out of the box. I am just being explicit here for new users ;) There are still a couple errors when doing a 'make check' but I will open a new thread for them, when I investigate. Seems like some rounding errors and a couple complex number errors to start :( Thanks, K.Wilson -----Original Message----- From: Eli Friedman [mailto:eli.friedman at gmail.com] Sent: Sunday, June 29, 2008 10:58 AM To: Kelly Wilson Cc: cfe-dev at cs.uiuc.edu Subject: Re: [cfe-dev] GSL compiles pretty much > regarding constants but one can fix this by > removing leading zeros for a couple lines. I also hand modified the > Makefiles to get rid of the '-O2' flag and added the '-lm' linker flag (one > could also just pass this in via configure, I guess). You shouldn't need to mess with that... maybe a bug in ccc? -Eli From clattner at apple.com Wed Jul 2 00:57:14 2008 From: clattner at apple.com (Chris Lattner) Date: Tue, 1 Jul 2008 22:57:14 -0700 Subject: [cfe-dev] FW: GSL compiles pretty much In-Reply-To: <0K3D00AGX6V2RS00@l-daemon> References: <0K3D00AGX6V2RS00@l-daemon> Message-ID: On Jul 1, 2008, at 10:49 PM, Kelly Wilson wrote: > in the gsl-1.11 directory (this is for the bash shell with > debugging) and > everything compiles out of the box. I am just being explicit here > for new > users ;) > > There are still a couple errors when doing a 'make check' but I will > open a > new thread for them, when I investigate. Seems like some rounding > errors and > a couple complex number errors to start :( Cool. I'm not hugely surprised we have complex number codegen bugs, it is a complex (har har) area to get right. Thanks for helping track these down! -Chris From kremenek at apple.com Wed Jul 2 01:30:48 2008 From: kremenek at apple.com (Ted Kremenek) Date: Tue, 1 Jul 2008 23:30:48 -0700 Subject: [cfe-dev] Comparison of pointers between Objc subclasses In-Reply-To: References: <610BA04E-4EC1-4BE6-ACC1-0EF809234B91@free.fr> <824EC897-9645-44DA-BDD1-7C03982A173D@apple.com> <1341DC93-E993-4437-B650-E45008A8A175@apple.com> Message-ID: <39A005F6-1279-4602-9871-705FBC4FD803@apple.com> On Jul 1, 2008, at 9:48 PM, Eli Friedman wrote: > On Tue, Jul 1, 2008 at 8:54 PM, Ted Kremenek > wrote: >> So, I think the answers we are looking for are outside the letter >> of C99 >> standard. The Objective-C and C++ object type systems are a >> completely >> different animal. > > Okay, so in that case typesAreCompatible should say that non-identical > ObjC types aren't compatible, and the necessary handling for > comparison/assignment/conditionals/whatever else is needed for ObjC > pointers should move into SemaExpr. > > -Eli That sounds like a reasonable plan. Incidentally, what does: __builtin_type_compatible_p do for these pointer types? I've never even used this builtin, so I'm not quite certain how to use it in practice. I only ask because we use ASTContext::typesAreCompatible to implement Expr::isIntegerConstantExpr for TypesCompatibleExpr. If we can cross-check GCC's behavior with this builtin, that should give a definitive answer on whether or not NSArray* and NSMutableArray* should be considered compatible types (and hence put the logic in ASTContext::typesAreCompatible) or, if not, put (as you suggest) the necessary handling for ObjC pointers in SemaExpr. From csdavec at swansea.ac.uk Wed Jul 2 05:58:48 2008 From: csdavec at swansea.ac.uk (David Chisnall) Date: Wed, 2 Jul 2008 11:58:48 +0100 Subject: [cfe-dev] Comparison of pointers between Objc subclasses In-Reply-To: <824EC897-9645-44DA-BDD1-7C03982A173D@apple.com> References: <610BA04E-4EC1-4BE6-ACC1-0EF809234B91@free.fr> <824EC897-9645-44DA-BDD1-7C03982A173D@apple.com> Message-ID: On 2 Jul 2008, at 00:22, Ted Kremenek wrote: > Are pointer type compatibility checks for assignments and conversions > being handled in the same way? I can understand why assigning a base > type to a derived type is dangerous, but it seems to me that > comparisons like these should be legal. I'm only raising this point > because the code snippet with the warning involved a comparison, not > an assignment. Comparisons between ObjC pointers should contain an implicit cast to id. I tweaked CodeGen to do this and sent the patch a month or so ago, but it wasn't an ideal solution since the problem is really in Sema, and it only fixed a few cases where Sema was doing almost the right thing but omitting the implicit cast. Currently there are lots of Objective-C type-system related bugs in clang. I hope to have some time in the next few weeks to be able to take a look at it. The Objective-C type system doesn't map very cleanly to the LLVM type system, unfortunately, and there are lots of places where implicit casts need to be emitted but aren't. David From akyrtzi at gmail.com Wed Jul 2 06:45:51 2008 From: akyrtzi at gmail.com (Argiris Kirtzidis) Date: Wed, 02 Jul 2008 04:45:51 -0700 Subject: [cfe-dev] C++ status report web page Message-ID: <486B6A6F.7040104@gmail.com> Hi, After a suggestion by Chris, I've added a page to track C++ support in Clang: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20080630/006333.html Please feel free to add something I missed, change wording and/or change the whole design of the page. Later I'll link to this page by the front page ("Current Status") and get_involved.html ("Open Projects"/"Continue work on C++ support"). -Argiris From akyrtzi at gmail.com Wed Jul 2 06:52:55 2008 From: akyrtzi at gmail.com (Argiris Kirtzidis) Date: Wed, 02 Jul 2008 04:52:55 -0700 Subject: [cfe-dev] C++ status report web page In-Reply-To: <486B6A6F.7040104@gmail.com> References: <486B6A6F.7040104@gmail.com> Message-ID: <486B6C17.4070307@gmail.com> Argiris Kirtzidis wrote: > Hi, > > After a suggestion by Chris, I've added a page to track C++ support in > Clang: Oh yeah, check it out by browsing here: http://clang.llvm.org/cxx_status.html -Argiris From hs4233 at mail.mn-solutions.de Wed Jul 2 07:36:43 2008 From: hs4233 at mail.mn-solutions.de (Holger Schurig) Date: Wed, 2 Jul 2008 14:36:43 +0200 Subject: [cfe-dev] C++ status report web page In-Reply-To: <486B6A6F.7040104@gmail.com> References: <486B6A6F.7040104@gmail.com> Message-ID: <200807021436.43155.hs4233@mail.mn-solutions.de> > Please feel free to add something I missed, change wording > and/or change the whole design of the page. Design: maybe make the table borderless, but at least not with the ugly double borders :-) Maybe make "Parser & Sema" and "Codegen" two columns. Also I'm not sure if many people that read the page knows what "Sema" means. Maybe drop the "C++ " at each line in the "Feature" column. It's clear that this page applies to C++ :-) Maybe use valign="top" Right now the page gives the impression that "Parsing and Sema" is basically done and just codegen is missing. However, lot's of C++ features are missing. Maybe adding them would give a better impression of the real state. Maybe something like: Templates Overloading Operator overloading Maybe we can use something like http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1905.pdf and re-use their TOC for this purpose. The paper from above URL just showed up after googling for "c++ standard", maybe there is something better or even ratified available on the net. From devlists at shadowlab.org Wed Jul 2 08:16:40 2008 From: devlists at shadowlab.org (Jean-Daniel Dupas) Date: Wed, 2 Jul 2008 15:16:40 +0200 Subject: [cfe-dev] Comparison of pointers between Objc subclasses In-Reply-To: References: <610BA04E-4EC1-4BE6-ACC1-0EF809234B91@free.fr> <824EC897-9645-44DA-BDD1-7C03982A173D@apple.com> Message-ID: <5F206E98-9600-49A7-967E-19B3AC6124CF@shadowlab.org> Le 2 juil. 08 ? 12:58, David Chisnall a ?crit : > On 2 Jul 2008, at 00:22, Ted Kremenek wrote: > >> Are pointer type compatibility checks for assignments and conversions >> being handled in the same way? I can understand why assigning a base >> type to a derived type is dangerous, but it seems to me that >> comparisons like these should be legal. I'm only raising this point >> because the code snippet with the warning involved a comparison, not >> an assignment. > > Comparisons between ObjC pointers should contain an implicit cast to > id. I tweaked CodeGen to do this and sent the patch a month or so > ago, but it wasn't an ideal solution since the problem is really in > Sema, and it only fixed a few cases where Sema was doing almost the > right thing but omitting the implicit cast. Wouldn't this implicit cast prevent the "comparison of distinct Objective-C types lacks a cast" warning ? I think gcc emit this warning, because if gcc is right (the two pointer does not have compatible type), the comparaison will always be false. It 's like when you try to compare a negative signed value with an unsigned value. considere this: unsigned i; ... if (-1 == i) ... In this case, it's safe/legal to compare the two values, and the condition may even be true, but gcc emit a warning (but it look like clang does not says anything about it). Note that I have no idea about what standard says about this case. I also saw that "clang -pedantic" properly handles the "incompatible pointer types assigning?" warning. > Currently there are lots of Objective-C type-system related bugs in > clang. I hope to have some time in the next few weeks to be able to > take a look at it. The Objective-C type system doesn't map very > cleanly to the LLVM type system, unfortunately, and there are lots of > places where implicit casts need to be emitted but aren't. > David -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080702/0e2805bf/attachment-0001.bin From csdavec at swansea.ac.uk Wed Jul 2 09:05:19 2008 From: csdavec at swansea.ac.uk (David Chisnall) Date: Wed, 2 Jul 2008 15:05:19 +0100 Subject: [cfe-dev] Comparison of pointers between Objc subclasses In-Reply-To: <5F206E98-9600-49A7-967E-19B3AC6124CF@shadowlab.org> References: <610BA04E-4EC1-4BE6-ACC1-0EF809234B91@free.fr> <824EC897-9645-44DA-BDD1-7C03982A173D@apple.com> <5F206E98-9600-49A7-967E-19B3AC6124CF@shadowlab.org> Message-ID: <07841EA4-F5F6-401C-ACA1-7302D51B7A65@swan.ac.uk> On 2 Jul 2008, at 14:16, Jean-Daniel Dupas wrote: > > Le 2 juil. 08 ? 12:58, David Chisnall a ?crit : > >> On 2 Jul 2008, at 00:22, Ted Kremenek wrote: >> >>> Are pointer type compatibility checks for assignments and >>> conversions >>> being handled in the same way? I can understand why assigning a >>> base >>> type to a derived type is dangerous, but it seems to me that >>> comparisons like these should be legal. I'm only raising this point >>> because the code snippet with the warning involved a comparison, not >>> an assignment. >> >> Comparisons between ObjC pointers should contain an implicit cast to >> id. I tweaked CodeGen to do this and sent the patch a month or so >> ago, but it wasn't an ideal solution since the problem is really in >> Sema, and it only fixed a few cases where Sema was doing almost the >> right thing but omitting the implicit cast. > > Wouldn't this implicit cast prevent the "comparison of distinct > Objective-C types lacks a cast" warning ? No. The warning is just a warning. Objective-C type tags are informative, nothing more. The type of an Objective-C object is a property of the object, not of the variable holding the object. The warning says 'you think these two objects have different types, but you are still comparing them, are you sure that's sensible?' The implicit cast should be inserted so that CodeGen will generate the correct code, rather than failing because you are comparing distinct pointer types. The same is true of an assignment. It is perfectly legal to assign any object pointer to any other object pointer in Objective-C, it just isn't usually sensible, which is why you get a warning. In some situations, however, it is useful. You might have something like this: - (void) method:(A*)anObject { if ([anObject isKindOfClass:[B class]]) { [self methodExpectingB:(B*)anObject]; } else ... } This can be required because Objective-C objects have two types - the implicit type determined by their signature and their structural type. The tag type carries both implicitly. You can safely pass object B to something expecting A if it implements every method of A. You may also want to override a method which expects an A, and have a special case for objects of type B, which either accesses their instance variables directly, or uses some methods only present in B. Of course, this is better done with protocols, but that requires you to have access to the class which you are subclassing's source code. David From akyrtzi at gmail.com Wed Jul 2 09:08:58 2008 From: akyrtzi at gmail.com (Argiris Kirtzidis) Date: Wed, 02 Jul 2008 07:08:58 -0700 Subject: [cfe-dev] C++ status report web page In-Reply-To: <200807021436.43155.hs4233@mail.mn-solutions.de> References: <486B6A6F.7040104@gmail.com> <200807021436.43155.hs4233@mail.mn-solutions.de> Message-ID: <486B8BFA.7070001@gmail.com> Holger Schurig wrote: > Design: maybe make the table borderless, but at least not with > the ugly double borders :-) > I'm not much of a html designer, the table has border="1", what should I put for 'single' borders ? > Maybe make "Parser & Sema" and "Codegen" two columns. Also I'm > not sure if many people that read the page knows what "Sema" > means. > How about 1 column for "Parser & Semantic analysis" and another for "Code generation" > Maybe drop the "C++ " at each line in the "Feature" column. It's > clear that this page applies to C++ :-) > Ok. > Maybe use valign="top" > I tried that but didn't make a difference wherever I put it (table,tr,td) (at least on firefox that is). > Right now the page gives the impression that "Parsing and Sema" > is basically done and just codegen is missing. However, lot's of > C++ features are missing. Maybe adding them would give a better > impression of the real state. Maybe something like: > > Templates > Overloading > Operator overloading > > Maybe we can use something like > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1905.pdf > and re-use their TOC for this purpose. The paper from above URL > just showed up after googling for "c++ standard", maybe there is > something better or even ratified available on the net. > I'm not sure if providing a looong list of missing C++ features is going to be much more helpful. How about we just make it clear that this page lists only C++ features that Clang has partial/full support for. When clang reaches a point where most of C++ is at least partially supported, we can add the missing stuff too to complete the picture. -Argiris From hs4233 at mail.mn-solutions.de Wed Jul 2 09:18:01 2008 From: hs4233 at mail.mn-solutions.de (Holger Schurig) Date: Wed, 2 Jul 2008 16:18:01 +0200 Subject: [cfe-dev] C++ status report web page In-Reply-To: <486B8BFA.7070001@gmail.com> References: <486B6A6F.7040104@gmail.com> <200807021436.43155.hs4233@mail.mn-solutions.de> <486B8BFA.7070001@gmail.com> Message-ID: <200807021618.02019.hs4233@mail.mn-solutions.de> > > Maybe use valign="top" > > I tried that but didn't make a difference wherever I put it > (table,tr,td) (at least on firefox that is). Couldn't you do that via CSS then ? > I'm not sure if providing a looong list of missing C++ > features is going to be much more helpful. > How about we just make it clear that this page lists only C++ > features that Clang has partial/full support for. When clang > reaches a point where most of C++ is at least partially > supported, we can add the missing stuff too to complete the > picture. Okay, then the page could state "Currently, we only support the following features whole or partially" (but let a native english speaker correct this sentence first :-) BTW, I always like the GNU classpath display of feature-completeness, e.g. look at http://builder.classpath.org/japi/jdk15-classpath.html However, that would need a) a good listing of features, b) lot's of little test programs for those features, c) either a database and a CGI or a little tool that does the tests and generates a static html page. From devlists at shadowlab.org Wed Jul 2 09:28:20 2008 From: devlists at shadowlab.org (Jean-Daniel Dupas) Date: Wed, 2 Jul 2008 16:28:20 +0200 Subject: [cfe-dev] Comparison of pointers between Objc subclasses In-Reply-To: <07841EA4-F5F6-401C-ACA1-7302D51B7A65@swan.ac.uk> References: <610BA04E-4EC1-4BE6-ACC1-0EF809234B91@free.fr> <824EC897-9645-44DA-BDD1-7C03982A173D@apple.com> <5F206E98-9600-49A7-967E-19B3AC6124CF@shadowlab.org> <07841EA4-F5F6-401C-ACA1-7302D51B7A65@swan.ac.uk> Message-ID: <2037E762-4F89-4133-92F1-F818A28AEA02@shadowlab.org> Le 2 juil. 08 ? 16:05, David Chisnall a ?crit : > On 2 Jul 2008, at 14:16, Jean-Daniel Dupas wrote: > >> >> Le 2 juil. 08 ? 12:58, David Chisnall a ?crit : >> >>> On 2 Jul 2008, at 00:22, Ted Kremenek wrote: >>> >>>> Are pointer type compatibility checks for assignments and >>>> conversions >>>> being handled in the same way? I can understand why assigning a >>>> base >>>> type to a derived type is dangerous, but it seems to me that >>>> comparisons like these should be legal. I'm only raising this >>>> point >>>> because the code snippet with the warning involved a comparison, >>>> not >>>> an assignment. >>> >>> Comparisons between ObjC pointers should contain an implicit cast to >>> id. I tweaked CodeGen to do this and sent the patch a month or so >>> ago, but it wasn't an ideal solution since the problem is really in >>> Sema, and it only fixed a few cases where Sema was doing almost the >>> right thing but omitting the implicit cast. >> >> Wouldn't this implicit cast prevent the "comparison of distinct >> Objective-C types lacks a cast" warning ? > > No. The warning is just a warning. Objective-C type tags are > informative, nothing more. The type of an Objective-C object is a > property of the object, not of the variable holding the object. The > warning says 'you think these two objects have different types, but > you are still comparing them, are you sure that's sensible?' The > implicit cast should be inserted so that CodeGen will generate the > correct code, rather than failing because you are comparing distinct > pointer types. > > The same is true of an assignment. It is perfectly legal to assign > any object pointer to any other object pointer in Objective-C, it > just isn't usually sensible, which is why you get a warning. In > some situations, however, it is useful. You might have something > like this: > > - (void) method:(A*)anObject > { > if ([anObject isKindOfClass:[B class]]) > { > [self methodExpectingB:(B*)anObject]; > } > else > ... > } > > This can be required because Objective-C objects have two types - > the implicit type determined by their signature and their structural > type. The tag type carries both implicitly. You can safely pass > object B to something expecting A if it implements every method of > A. You may also want to override a method which expects an A, and > have a special case for objects of type B, which either accesses > their instance variables directly, or uses some methods only present > in B. Of course, this is better done with protocols, but that > requires you to have access to the class which you are subclassing's > source code. > > David Sorry, didn't notice it was about implicit cast into CodeGen (and so should not have any impact on parse and Sema, and so on warning). Of course, I fully agree with you. The Obj-C runtime don't care about what kind of object you pass, as long as it's first field is an isa pointer (at least for the Apple runtime) and it can dynamically dispatch method on it (even if the object does not directly handle the message and uses forwarding or dynamic method generation to handle it). -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080702/b78e537a/attachment.bin From akyrtzi at gmail.com Wed Jul 2 10:13:25 2008 From: akyrtzi at gmail.com (Argiris Kirtzidis) Date: Wed, 02 Jul 2008 08:13:25 -0700 Subject: [cfe-dev] C++ status report web page In-Reply-To: <200807021618.02019.hs4233@mail.mn-solutions.de> References: <486B6A6F.7040104@gmail.com> <200807021436.43155.hs4233@mail.mn-solutions.de> <486B8BFA.7070001@gmail.com> <200807021618.02019.hs4233@mail.mn-solutions.de> Message-ID: <486B9B15.8060808@gmail.com> Holger Schurig wrote: > Couldn't you do that via CSS then ? > CSS works, thanks! > >> I'm not sure if providing a looong list of missing C++ >> features is going to be much more helpful. >> How about we just make it clear that this page lists only C++ >> features that Clang has partial/full support for. When clang >> reaches a point where most of C++ is at least partially >> supported, we can add the missing stuff too to complete the >> picture. >> > > Okay, then the page could state "Currently, we only support the > following features whole or partially" (but let a native english > speaker correct this sentence first :-) > I've added a note about this. > > BTW, I always like the GNU classpath display of > feature-completeness, e.g. look at > http://builder.classpath.org/japi/jdk15-classpath.html > > However, that would need a) a good listing of features, b) lot's > of little test programs for those features, c) either a database > and a CGI or a little tool that does the tests and generates a > static html page. > > That would be very cool! -Argiris From eli.friedman at gmail.com Wed Jul 2 10:18:04 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Wed, 2 Jul 2008 08:18:04 -0700 Subject: [cfe-dev] C++ status report web page In-Reply-To: <486B6A6F.7040104@gmail.com> References: <486B6A6F.7040104@gmail.com> Message-ID: On Wed, Jul 2, 2008 at 4:45 AM, Argiris Kirtzidis wrote: > Hi, > > After a suggestion by Chris, I've added a page to track C++ support in > Clang: > http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20080630/006333.html > > Please feel free to add something I missed, change wording and/or change > the whole design of the page. > > Later I'll link to this page by the front page ("Current Status") and > get_involved.html ("Open Projects"/"Continue work on C++ support"). Is a page like this really useful at this point? There's really so much missing that clang is basically useless for C++ at the moment. Some examples: C++-compatible conversions, constant-folding, inheritance, exceptions, overloading, constructors, copy-conversion, friends, custom operators, function-style type conversions, labels for declarations. -Eli From kremenek at apple.com Wed Jul 2 10:38:18 2008 From: kremenek at apple.com (Ted Kremenek) Date: Wed, 2 Jul 2008 08:38:18 -0700 Subject: [cfe-dev] C++ status report web page In-Reply-To: <486B6A6F.7040104@gmail.com> References: <486B6A6F.7040104@gmail.com> Message-ID: <917D409F-4FC7-4042-95A6-F92FB957A6C5@apple.com> On Jul 2, 2008, at 4:45 AM, Argiris Kirtzidis wrote: > Hi, > > After a suggestion by Chris, I've added a page to track C++ support in > Clang: > http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20080630/006333.html > > Please feel free to add something I missed, change wording and/or > change > the whole design of the page. > > Later I'll link to this page by the front page ("Current Status") and > get_involved.html ("Open Projects"/"Continue work on C++ support"). Hi Argiris, I think this is a good start for a page like this. Besides incorporating some of the feedback from the other responders, you might want to consider not using the terms "Sema", "CodeGen", "Parse", etc. These are libraries used to implement features, and are not the features themselves. Using these terms makes the page only useful to people who understand Clang's internals (i.e., Clang developers), and this page really should be targeted to a much broader audience (i.e., anybody who cares about C++ support in Clang). I would use the following terms instead: Parse -> "parsing" Sema -> "type checking" CodeGen -> "code generation (compilation)" For those who know the internals of Clang, they will be able to do the reverse mapping just fine. Ted From chandlerc at gmail.com Wed Jul 2 10:40:48 2008 From: chandlerc at gmail.com (Chandler Carruth) Date: Wed, 2 Jul 2008 08:40:48 -0700 Subject: [cfe-dev] C++ status report web page In-Reply-To: References: <486B6A6F.7040104@gmail.com> Message-ID: <18edb2ad0807020840g458ad226qb6e081d510e6a4f7@mail.gmail.com> On Wed, Jul 2, 2008 at 8:18 AM, Eli Friedman wrote: > On Wed, Jul 2, 2008 at 4:45 AM, Argiris Kirtzidis > wrote: > > Hi, > > > > After a suggestion by Chris, I've added a page to track C++ support in > > Clang: > > > http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20080630/006333.html > > > > Please feel free to add something I missed, change wording and/or change > > the whole design of the page. > > > > Later I'll link to this page by the front page ("Current Status") and > > get_involved.html ("Open Projects"/"Continue work on C++ support"). > > Is a page like this really useful at this point? There's really so > much missing that clang is basically useless for C++ at the moment. > Some examples: C++-compatible conversions, constant-folding, > inheritance, exceptions, overloading, constructors, copy-conversion, > friends, custom operators, function-style type conversions, labels for > declarations. I find it useful, as I'm extremely interested in the progress being made. Also, there are many applications which can leverage Clang without codegen for these constructs. Pretty printing HTML, analysis, AST representations, etc. It's just easier to check this type of page than to read all the commit and dev emails. -Chandler > > > -Eli > _______________________________________________ > 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/20080702/662c7e72/attachment.html From kremenek at apple.com Wed Jul 2 11:01:48 2008 From: kremenek at apple.com (Ted Kremenek) Date: Wed, 2 Jul 2008 09:01:48 -0700 Subject: [cfe-dev] C++ status report web page In-Reply-To: <18edb2ad0807020840g458ad226qb6e081d510e6a4f7@mail.gmail.com> References: <486B6A6F.7040104@gmail.com> <18edb2ad0807020840g458ad226qb6e081d510e6a4f7@mail.gmail.com> Message-ID: On Jul 2, 2008, at 8:40 AM, Chandler Carruth wrote: > Is a page like this really useful at this point? There's really so > much missing that clang is basically useless for C++ at the moment. > Some examples: C++-compatible conversions, constant-folding, > inheritance, exceptions, overloading, constructors, copy-conversion, > friends, custom operators, function-style type conversions, labels for > declarations. > > I find it useful, as I'm extremely interested in the progress being > made. Also, there are many applications which can leverage Clang > without codegen for these constructs. Pretty printing HTML, > analysis, AST representations, etc. It's just easier to check this > type of page than to read all the commit and dev emails. I strongly agree. Also, as I pointed out in my other email, it makes the C++ progress more transparent to non-Clang developers. Without a page like this non-Clang developers can only guess about the progress of C++ support (and most will assume that it doesn't exist at all). Actively publishing the development progress for key Clang features also has the added benefit that it will help attract more attention to the project. Such attention can bring both new users and contributors. Further, if the information is presented in a way that non-Clang developers can understand, it also means that articles written about LLVM/Clang on tech-related websites and blogs might be marginally more accurate. From akyrtzi at gmail.com Wed Jul 2 11:14:54 2008 From: akyrtzi at gmail.com (Argiris Kirtzidis) Date: Wed, 02 Jul 2008 09:14:54 -0700 Subject: [cfe-dev] C++ status report web page In-Reply-To: <917D409F-4FC7-4042-95A6-F92FB957A6C5@apple.com> References: <486B6A6F.7040104@gmail.com> <917D409F-4FC7-4042-95A6-F92FB957A6C5@apple.com> Message-ID: <486BA97E.3000601@gmail.com> Ted Kremenek wrote: > > On Jul 2, 2008, at 4:45 AM, Argiris Kirtzidis wrote: > >> Hi, >> >> After a suggestion by Chris, I've added a page to track C++ support in >> Clang: >> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20080630/006333.html >> >> >> Please feel free to add something I missed, change wording and/or change >> the whole design of the page. >> >> Later I'll link to this page by the front page ("Current Status") and >> get_involved.html ("Open Projects"/"Continue work on C++ support"). > > Hi Argiris, > > I think this is a good start for a page like this. Besides > incorporating some of the feedback from the other responders, you > might want to consider not using the terms "Sema", "CodeGen", "Parse", > etc. These are libraries used to implement features, and are not the > features themselves. Using these terms makes the page only useful to > people who understand Clang's internals (i.e., Clang developers), and > this page really should be targeted to a much broader audience (i.e., > anybody who cares about C++ support in Clang). > > I would use the following terms instead: > > Parse -> "parsing" > Sema -> "type checking" > CodeGen -> "code generation (compilation)" > > For those who know the internals of Clang, they will be able to do the > reverse mapping just fine. Would it be better to do Sema->"AST building" ? -Argiris From isanbard at gmail.com Wed Jul 2 11:22:41 2008 From: isanbard at gmail.com (Bill Wendling) Date: Wed, 2 Jul 2008 09:22:41 -0700 Subject: [cfe-dev] C++ status report web page In-Reply-To: <486B6A6F.7040104@gmail.com> References: <486B6A6F.7040104@gmail.com> Message-ID: Your comment is wrong for reinterpret_cast. You don't always cast from a pointer to a pointer. reinterpret_cast allows you to cast from a pointer to non-pointer, as long as the type cast to can hold the size of the pointer's value without loss of precision. So clang fails to emit an error in this situation: $ cat t.cpp #include void foo(int *f) { uintptr_t cp = reinterpret_cast(f); char c = reinterpret_cast(f); } $ clang -fsyntax-only t.cpp $ g++ -c t.cpp t.cpp: In function 'void foo(int*)': t.cpp:5: error: cast from 'int*' to 'char' loses precision $ Please reference the patch I sent out many weeks ago for review. It didn't pass muster, but at least caught situations like this. -bw On Jul 2, 2008, at 4:45 AM, Argiris Kirtzidis wrote: > Hi, > > After a suggestion by Chris, I've added a page to track C++ support in > Clang: > http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of- > Mon-20080630/006333.html > > Please feel free to add something I missed, change wording and/or > change > the whole design of the page. > > Later I'll link to this page by the front page ("Current Status") and > get_involved.html ("Open Projects"/"Continue work on C++ support"). > > > -Argiris > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From isanbard at gmail.com Wed Jul 2 11:26:42 2008 From: isanbard at gmail.com (Bill Wendling) Date: Wed, 2 Jul 2008 09:26:42 -0700 Subject: [cfe-dev] C++ status report web page In-Reply-To: <486B6A6F.7040104@gmail.com> References: <486B6A6F.7040104@gmail.com> Message-ID: <36CFA9B8-CD1F-4D00-B0BF-451C9295AB2A@gmail.com> More situations it doesn't emit errors for: typedef double *dptr; typedef const double *cdptr; void reinterpret_cast_check() { short s; double *d; float *f; const double * const ccd; // FIXME: Should error about uninitialized const. const double *cd; int const * volatile * vci; double * const * volatile * *vcd; dptr t_d; cdptr t_cd; // No errors: t_d = reinterpret_cast(d); f = reinterpret_cast(d); cd = reinterpret_cast(ccd); // Expected errors: f = reinterpret_cast(cd); // expected-error {{reinterpret_cast cannot cast \ away const}} s = reinterpret_cast(f); // expected-error {{loss of precision}} vcd = reinterpret_cast(vci); // expected- error {{reinterpr\ et_cast cannot cast away const}} t_d = reinterpret_cast(t_cd); // expected-error {{reinterpret_cast cannot cas\ t away const}} } Enjoy! -bw From kremenek at apple.com Wed Jul 2 11:28:03 2008 From: kremenek at apple.com (Ted Kremenek) Date: Wed, 2 Jul 2008 09:28:03 -0700 Subject: [cfe-dev] C++ status report web page In-Reply-To: <486BA97E.3000601@gmail.com> References: <486B6A6F.7040104@gmail.com> <917D409F-4FC7-4042-95A6-F92FB957A6C5@apple.com> <486BA97E.3000601@gmail.com> Message-ID: On Jul 2, 2008, at 9:14 AM, Argiris Kirtzidis wrote: > Ted Kremenek wrote: >> >> On Jul 2, 2008, at 4:45 AM, Argiris Kirtzidis wrote: >> >>> Hi, >>> >>> After a suggestion by Chris, I've added a page to track C++ >>> support in >>> Clang: >>> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20080630/006333.html >>> >>> Please feel free to add something I missed, change wording and/or >>> change >>> the whole design of the page. >>> >>> Later I'll link to this page by the front page ("Current Status") >>> and >>> get_involved.html ("Open Projects"/"Continue work on C++ support"). >> >> Hi Argiris, >> >> I think this is a good start for a page like this. Besides >> incorporating some of the feedback from the other responders, you >> might want to consider not using the terms "Sema", "CodeGen", >> "Parse", etc. These are libraries used to implement features, and >> are not the features themselves. Using these terms makes the page >> only useful to people who understand Clang's internals (i.e., Clang >> developers), and this page really should be targeted to a much >> broader audience (i.e., anybody who cares about C++ support in >> Clang). >> >> I would use the following terms instead: >> >> Parse -> "parsing" >> Sema -> "type checking" >> CodeGen -> "code generation (compilation)" >> >> For those who know the internals of Clang, they will be able to do >> the reverse mapping just fine. > > Would it be better to do Sema->"AST building" ? That assumes that everyone knows what an AST is, and for some people "parsing" == "AST building." The meta point here is "non-Clang developers" includes "non-compiler people" who still want to know that Clang is something worth caring about. From clattner at apple.com Wed Jul 2 11:31:08 2008 From: clattner at apple.com (Chris Lattner) Date: Wed, 2 Jul 2008 09:31:08 -0700 Subject: [cfe-dev] C++ status report web page In-Reply-To: <917D409F-4FC7-4042-95A6-F92FB957A6C5@apple.com> References: <486B6A6F.7040104@gmail.com> <917D409F-4FC7-4042-95A6-F92FB957A6C5@apple.com> Message-ID: <63C8CB2D-1E09-4CE8-9AD7-9B2775317A3C@apple.com> On Jul 2, 2008, at 8:38 AM, Ted Kremenek wrote: > > On Jul 2, 2008, at 4:45 AM, Argiris Kirtzidis wrote: > >> Hi, >> >> After a suggestion by Chris, I've added a page to track C++ support >> in >> Clang: >> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20080630/006333.html >> >> Please feel free to add something I missed, change wording and/or >> change >> the whole design of the page. >> >> Later I'll link to this page by the front page ("Current Status") and >> get_involved.html ("Open Projects"/"Continue work on C++ support"). > > Hi Argiris, > > I think this is a good start for a page like this. Besides > incorporating some of the feedback from the other responders, you > might want to consider not using the terms "Sema", "CodeGen", > "Parse", etc. These are libraries used to implement features, and > are not the features themselves. Using these terms makes the page > only useful to people who understand Clang's internals (i.e., Clang > developers), and this page really should be targeted to a much > broader audience (i.e., anybody who cares about C++ support in Clang). > > I would use the following terms instead: > > Parse -> "parsing" > Sema -> "type checking" > CodeGen -> "code generation (compilation)" > > For those who know the internals of Clang, they will be able to do > the reverse mapping just fine. I think that using contractions like this is ok. I added a paragraph to the top explaining what they mean and made the table use a nicer looking border. -Chris From eli.friedman at gmail.com Wed Jul 2 17:50:30 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Wed, 2 Jul 2008 15:50:30 -0700 Subject: [cfe-dev] C++ status report web page In-Reply-To: References: <486B6A6F.7040104@gmail.com> Message-ID: On Wed, Jul 2, 2008 at 9:22 AM, Bill Wendling wrote: > Your comment is wrong for reinterpret_cast. You don't always cast > from a pointer to a pointer. reinterpret_cast allows you to cast from > a pointer to non-pointer, as long as the type cast to can hold the > size of the pointer's value without loss of precision. So clang fails > to emit an error in this situation: I'm not completely sure what this comment is in reply to, but I don't see the relevance to this discussion. Are you arguing that we don't have full support for reinterpret_cast, and therefore shouldn't claim that? In any case, would you mind making sure this is filed in Bugzilla so we don't lose track of it? -Eli From isanbard at gmail.com Wed Jul 2 18:07:22 2008 From: isanbard at gmail.com (Bill Wendling) Date: Wed, 2 Jul 2008 16:07:22 -0700 Subject: [cfe-dev] C++ status report web page In-Reply-To: References: <486B6A6F.7040104@gmail.com> Message-ID: <16e5fdf90807021607q2434642fo1edbbb09fcbae823@mail.gmail.com> On Wed, Jul 2, 2008 at 3:50 PM, Eli Friedman wrote: > On Wed, Jul 2, 2008 at 9:22 AM, Bill Wendling wrote: >> Your comment is wrong for reinterpret_cast. You don't always cast >> from a pointer to a pointer. reinterpret_cast allows you to cast from >> a pointer to non-pointer, as long as the type cast to can hold the >> size of the pointer's value without loss of precision. So clang fails >> to emit an error in this situation: > > I'm not completely sure what this comment is in reply to, but I don't > see the relevance to this discussion. Are you arguing that we don't > have full support for reinterpret_cast, and therefore shouldn't claim > that? > Yup! It's on Argiris' web page and should be updated with the correct information. So should the comment in the source code. > In any case, would you mind making sure this is filed in Bugzilla so > we don't lose track of it? > "Do correct semantic analysis for reinterpret_cast"? What about all of the 10^100 other features that don't work/aren't done for C++? -bw From eli.friedman at gmail.com Wed Jul 2 18:53:31 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Wed, 2 Jul 2008 16:53:31 -0700 Subject: [cfe-dev] C++ status report web page In-Reply-To: <16e5fdf90807021607q2434642fo1edbbb09fcbae823@mail.gmail.com> References: <486B6A6F.7040104@gmail.com> <16e5fdf90807021607q2434642fo1edbbb09fcbae823@mail.gmail.com> Message-ID: On Wed, Jul 2, 2008 at 4:07 PM, Bill Wendling wrote: > On Wed, Jul 2, 2008 at 3:50 PM, Eli Friedman wrote: >> On Wed, Jul 2, 2008 at 9:22 AM, Bill Wendling wrote: >>> Your comment is wrong for reinterpret_cast. You don't always cast >>> from a pointer to a pointer. reinterpret_cast allows you to cast from >>> a pointer to non-pointer, as long as the type cast to can hold the >>> size of the pointer's value without loss of precision. So clang fails >>> to emit an error in this situation: >> >> I'm not completely sure what this comment is in reply to, but I don't >> see the relevance to this discussion. Are you arguing that we don't >> have full support for reinterpret_cast, and therefore shouldn't claim >> that? >> > Yup! It's on Argiris' web page and should be updated with the correct > information. So should the comment in the source code. > >> In any case, would you mind making sure this is filed in Bugzilla so >> we don't lose track of it? >> > "Do correct semantic analysis for reinterpret_cast"? What about all of > the 10^100 other features that don't work/aren't done for C++? Ah, nevermind; I didn't realize that the reinterpret_cast implementation doesn't do any typechecking at all. It's definitely misleading to list "reinterpret_cast" next to "Full support", and claim we have full Sema support for "Named Casts". -Eli From nikita at zhuk.fi Thu Jul 3 00:35:43 2008 From: nikita at zhuk.fi (Nikita Zhuk) Date: Thu, 3 Jul 2008 08:35:43 +0300 Subject: [cfe-dev] Missing dealloc analysis Message-ID: I noticed the addition of missing dealloc analysis in r53075. It's a good idea to check that dealloc is implemented and that it always calls [super dealloc], but there're couple of points I would like to mention: 1. It should be disabled in GC environment, because dealloc methods are not called under GC 2. In non-GC environment, the primary function of dealloc method is to update retain counts of variables the object being dealloced is pointing to. So that usually means that dealloc must be implemented when an object has some ivars. Dealloc is not always required, and there're lot of classes which don't need it (e.g. singleton classes). Currently missing dealloc analysis requires every class to implement dealloc and it's causing a lot of false positives. I'm not completely sure if absence of ivars should be the only factor which disables missing dealloc analysis, but at least in my case it would suppress a lot of false positives. From devlists at shadowlab.org Thu Jul 3 02:55:22 2008 From: devlists at shadowlab.org (Jean-Daniel Dupas) Date: Thu, 3 Jul 2008 09:55:22 +0200 Subject: [cfe-dev] Missing dealloc analysis In-Reply-To: References: Message-ID: <351A70B9-85C3-4D25-9B80-EDFE758B36BB@shadowlab.org> Le 3 juil. 08 ? 07:35, Nikita Zhuk a ?crit : > I noticed the addition of missing dealloc analysis in r53075. It's a > good idea to check that dealloc is implemented and that it always > calls [super dealloc], but there're couple of points I would like to > mention: > > 1. It should be disabled in GC environment, because dealloc methods > are not called under GC > > 2. In non-GC environment, the primary function of dealloc method is to > update retain counts of variables the object being dealloced is > pointing to. So that usually means that dealloc must be implemented > when an object has some ivars. Dealloc is not always required, and > there're lot of classes which don't need it (e.g. singleton classes). > Currently missing dealloc analysis requires every class to implement > dealloc and it's causing a lot of false positives. > > I'm not completely sure if absence of ivars should be the only factor > which disables missing dealloc analysis, but at least in my case it > would suppress a lot of false positives. dealloc is also used to nullify the pointer in some other class that have a weak reference on the disposed instance. You can have an object without ivar that is declare delegate of an other object and should call -[setDelegate:nil] on dealloc. You have the same issue with notification listeners, that have to unregister when they are disposed. And so, defining if dealloc should be implemented or not is not an easy task. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080703/cc1546ad/attachment.bin From akyrtzi at gmail.com Thu Jul 3 03:44:51 2008 From: akyrtzi at gmail.com (Argiris Kirtzidis) Date: Thu, 03 Jul 2008 01:44:51 -0700 Subject: [cfe-dev] C++ status report web page In-Reply-To: <16e5fdf90807021607q2434642fo1edbbb09fcbae823@mail.gmail.com> References: <486B6A6F.7040104@gmail.com> <16e5fdf90807021607q2434642fo1edbbb09fcbae823@mail.gmail.com> Message-ID: <486C9183.5020001@gmail.com> Hi Bill, Bill Wendling wrote: > On Wed, Jul 2, 2008 at 3:50 PM, Eli Friedman wrote: > >> I'm not completely sure what this comment is in reply to, but I don't >> see the relevance to this discussion. Are you arguing that we don't >> have full support for reinterpret_cast, and therefore shouldn't claim >> that? >> >> > Yup! It's on Argiris' web page and should be updated with the correct > information. So should the comment in the source code. > I updated the page. -Argiris From csdavec at swansea.ac.uk Thu Jul 3 05:39:19 2008 From: csdavec at swansea.ac.uk (David Chisnall) Date: Thu, 3 Jul 2008 11:39:19 +0100 Subject: [cfe-dev] Missing dealloc analysis In-Reply-To: References: Message-ID: <4C922E0E-9E15-4F3E-8F22-4AEFD9387109@swan.ac.uk> On 3 Jul 2008, at 06:35, Nikita Zhuk wrote: > It's a > good idea to check that dealloc is implemented and that it always > calls [super dealloc] One minor point: GCC emits a warning if -dealloc does not call [super dealloc], which is very frustrating when you are creating a root class (or a category on a root class) for which super is invalid, since it seems impossible to suppress the warning. Please don't replicate this bug! David From kremenek at apple.com Thu Jul 3 11:05:58 2008 From: kremenek at apple.com (Ted Kremenek) Date: Thu, 3 Jul 2008 09:05:58 -0700 Subject: [cfe-dev] Missing dealloc analysis In-Reply-To: <351A70B9-85C3-4D25-9B80-EDFE758B36BB@shadowlab.org> References: <351A70B9-85C3-4D25-9B80-EDFE758B36BB@shadowlab.org> Message-ID: On Jul 3, 2008, at 12:55 AM, Jean-Daniel Dupas wrote: > > Le 3 juil. 08 ? 07:35, Nikita Zhuk a ?crit : > >> I noticed the addition of missing dealloc analysis in r53075. It's a >> good idea to check that dealloc is implemented and that it always >> calls [super dealloc], but there're couple of points I would like to >> mention: >> >> 1. It should be disabled in GC environment, because dealloc methods >> are not called under GC >> >> 2. In non-GC environment, the primary function of dealloc method is >> to >> update retain counts of variables the object being dealloced is >> pointing to. So that usually means that dealloc must be implemented >> when an object has some ivars. Dealloc is not always required, and >> there're lot of classes which don't need it (e.g. singleton classes). >> Currently missing dealloc analysis requires every class to implement >> dealloc and it's causing a lot of false positives. >> >> I'm not completely sure if absence of ivars should be the only factor >> which disables missing dealloc analysis, but at least in my case it >> would suppress a lot of false positives. > > dealloc is also used to nullify the pointer in some other class that > have a weak reference on the disposed instance. > > You can have an object without ivar that is declare delegate of an > other object and should call -[setDelegate:nil] on dealloc. > You have the same issue with notification listeners, that have to > unregister when they are disposed. > > And so, defining if dealloc should be implemented or not is not an > easy task. I'd love to replicate some of these great observations in the check itself. I'm not a Cocoa programmer, so if anyone would be kind to provide some self-contained code examples (that we can potentially add to the Clang testsuite) that would be awesome. The goal of the check is to be pragmatic, not perfect. Ideally the check will have a modest false positive rate at the risk of some false negatives. If the check isn't useful than nobody will pay attention to it. From kremenek at apple.com Thu Jul 3 11:02:48 2008 From: kremenek at apple.com (Ted Kremenek) Date: Thu, 3 Jul 2008 09:02:48 -0700 Subject: [cfe-dev] Missing dealloc analysis In-Reply-To: <4C922E0E-9E15-4F3E-8F22-4AEFD9387109@swan.ac.uk> References: <4C922E0E-9E15-4F3E-8F22-4AEFD9387109@swan.ac.uk> Message-ID: <48B72092-3640-45E0-A24C-7761B4B422B8@apple.com> On Jul 3, 2008, at 3:39 AM, David Chisnall wrote: > On 3 Jul 2008, at 06:35, Nikita Zhuk wrote: > >> It's a >> good idea to check that dealloc is implemented and that it always >> calls [super dealloc] > > One minor point: > > GCC emits a warning if -dealloc does not call [super dealloc], which > is very frustrating when you are creating a root class (or a category > on a root class) for which super is invalid, since it seems impossible > to suppress the warning. Please don't replicate this bug! Right now the check only applies to ObjCImplementationDecls (@implementation for those not familiar with clang internals). The check walks the super chain to see if the class is a subclass of NSObject. Classes that don't subclass NSObject (including root classes) are skipped by this check. From kremenek at apple.com Thu Jul 3 11:28:08 2008 From: kremenek at apple.com (Ted Kremenek) Date: Thu, 3 Jul 2008 09:28:08 -0700 Subject: [cfe-dev] Missing dealloc analysis In-Reply-To: References: Message-ID: <9904231A-DFC6-4027-8CBF-34239B90BD20@apple.com> Hi Nikita, On Jul 2, 2008, at 10:35 PM, Nikita Zhuk wrote: > I noticed the addition of missing dealloc analysis in r53075. It's a > good idea to check that dealloc is implemented and that it always > calls [super dealloc], but there're couple of points I would like to > mention: > > 1. It should be disabled in GC environment, because dealloc methods > are not called under GC Done: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20080630/006371.html > 2. In non-GC environment, the primary function of dealloc method is to > update retain counts of variables the object being dealloced is > pointing to. So that usually means that dealloc must be implemented > when an object has some ivars. Dealloc is not always required, and > there're lot of classes which don't need it (e.g. singleton classes). > Currently missing dealloc analysis requires every class to implement > dealloc and it's causing a lot of false positives. > > I'm not completely sure if absence of ivars should be the only factor > which disables missing dealloc analysis, but at least in my case it > would suppress a lot of false positives. Done: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20080630/006373.html Both commits are now rolled into checker-55 on the Clang website. These are both great suggestions. I remembered the GC/non-GC issue this morning before I read your email, and I can easily see how not checking to see if a class contains any ivars would lead to many false positives. I also believe that checking for ivars should also handle the Singleton design pattern (please correct me if I am wrong). Please keep these great comments/suggestions coming! The goal is to have most checks have a false positive rate to not exceed 20%, and incorporating simple heuristics like these is often a huge win in cutting down false positives. Ted From devlists at shadowlab.org Thu Jul 3 12:18:49 2008 From: devlists at shadowlab.org (Jean-Daniel Dupas) Date: Thu, 3 Jul 2008 19:18:49 +0200 Subject: [cfe-dev] Missing dealloc analysis In-Reply-To: <9904231A-DFC6-4027-8CBF-34239B90BD20@apple.com> References: <9904231A-DFC6-4027-8CBF-34239B90BD20@apple.com> Message-ID: <96F7EB76-01D6-446B-8444-CA13DB9A369D@shadowlab.org> Le 3 juil. 08 ? 18:28, Ted Kremenek a ?crit : > Hi Nikita, > > On Jul 2, 2008, at 10:35 PM, Nikita Zhuk wrote: > >> I noticed the addition of missing dealloc analysis in r53075. It's a >> good idea to check that dealloc is implemented and that it always >> calls [super dealloc], but there're couple of points I would like to >> mention: >> >> 1. It should be disabled in GC environment, because dealloc methods >> are not called under GC > > Done: > > http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20080630/006371.html > >> 2. In non-GC environment, the primary function of dealloc method is >> to >> update retain counts of variables the object being dealloced is >> pointing to. So that usually means that dealloc must be implemented >> when an object has some ivars. Dealloc is not always required, and >> there're lot of classes which don't need it (e.g. singleton classes). >> Currently missing dealloc analysis requires every class to implement >> dealloc and it's causing a lot of false positives. >> >> I'm not completely sure if absence of ivars should be the only factor >> which disables missing dealloc analysis, but at least in my case it >> would suppress a lot of false positives. > > Done: > > http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20080630/006373.html > > Both commits are now rolled into checker-55 on the Clang website. > > These are both great suggestions. I remembered the GC/non-GC issue > this morning before I read your email, and I can easily see how not > checking to see if a class contains any ivars would lead to many false > positives. I also believe that checking for ivars should also handle > the Singleton design pattern (please correct me if I am wrong). Why do you think singleton class need a special case ? in obj-c a singleton class is usually implemented using a class method that return a shared instance: + (id)sharedInstance { static Foo *sharedInstance = nil; if (!sharedInstance) { sharedInstance = [[Foo alloc] init]; } return sharedInstance; } optionaly you can also override +alloc, -init, -retain, -release to prevent creation of other instance, and destruction of the shared instance, but this is not recommanded (except if you have a good reason to do so). It's a good practice to release ivars in a singleton dealloc, even if dealloc may never be call (like that, if needed, you can create other instance of this class). So I don't think it need a special case, but I maybe wrong too. > Please keep these great comments/suggestions coming! The goal is to > have most checks have a false positive rate to not exceed 20%, and > incorporating simple heuristics like these is often a huge win in > cutting down false positives. > > Ted > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080703/7311cb01/attachment.bin From csdavec at swansea.ac.uk Thu Jul 3 12:30:34 2008 From: csdavec at swansea.ac.uk (David Chisnall) Date: Thu, 3 Jul 2008 18:30:34 +0100 Subject: [cfe-dev] Missing dealloc analysis In-Reply-To: <96F7EB76-01D6-446B-8444-CA13DB9A369D@shadowlab.org> References: <9904231A-DFC6-4027-8CBF-34239B90BD20@apple.com> <96F7EB76-01D6-446B-8444-CA13DB9A369D@shadowlab.org> Message-ID: <54A30DB6-5852-48A4-895F-5D1A958B6B2D@swan.ac.uk> On 3 Jul 2008, at 18:18, Jean-Daniel Dupas wrote: > > Le 3 juil. 08 ? 18:28, Ted Kremenek a ?crit : > >> Hi Nikita, >> >> On Jul 2, 2008, at 10:35 PM, Nikita Zhuk wrote: >> >>> I noticed the addition of missing dealloc analysis in r53075. It's a >>> good idea to check that dealloc is implemented and that it always >>> calls [super dealloc], but there're couple of points I would like to >>> mention: >>> >>> 1. It should be disabled in GC environment, because dealloc methods >>> are not called under GC >> >> Done: >> >> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20080630/006371.html >> >>> 2. In non-GC environment, the primary function of dealloc method >>> is to >>> update retain counts of variables the object being dealloced is >>> pointing to. So that usually means that dealloc must be implemented >>> when an object has some ivars. Dealloc is not always required, and >>> there're lot of classes which don't need it (e.g. singleton >>> classes). >>> Currently missing dealloc analysis requires every class to implement >>> dealloc and it's causing a lot of false positives. >>> >>> I'm not completely sure if absence of ivars should be the only >>> factor >>> which disables missing dealloc analysis, but at least in my case it >>> would suppress a lot of false positives. >> >> Done: >> >> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20080630/006373.html >> >> Both commits are now rolled into checker-55 on the Clang website. >> >> These are both great suggestions. I remembered the GC/non-GC issue >> this morning before I read your email, and I can easily see how not >> checking to see if a class contains any ivars would lead to many >> false >> positives. I also believe that checking for ivars should also handle >> the Singleton design pattern (please correct me if I am wrong). > > Why do you think singleton class need a special case ? > > in obj-c a singleton class is usually implemented using a class > method that return a shared instance: > > + (id)sharedInstance { > static Foo *sharedInstance = nil; > if (!sharedInstance) { > sharedInstance = [[Foo alloc] init]; > } > return sharedInstance; > } > > optionaly you can also override +alloc, -init, -retain, -release to > prevent creation of other instance, and destruction of the shared > instance, but this is not recommanded (except if you have a good > reason to do so). > > It's a good practice to release ivars in a singleton dealloc, even > if dealloc may never be call (like that, if needed, you can create > other instance of this class). > > So I don't think it need a special case, but I maybe wrong too. This is especially true when you consider subclassing. A singleton can not guarantee that its subclasses will also be singletons, and so should release all of its ivars when it is -dealloc'd, or risk causing leaks if it is subclassed. If a singleton needs to have shared resources that are also shared with subclasses then it should store them in file statics, no ivars. David From catfish.man at gmail.com Thu Jul 3 12:40:15 2008 From: catfish.man at gmail.com (David Smith) Date: Thu, 3 Jul 2008 10:40:15 -0700 Subject: [cfe-dev] Static analysis and Adium Message-ID: <4EA3495F-5F81-4D61-B478-F16949A3E18A@gmail.com> After seeing the earlier email about static analysis being run on Adium I emailed our development list about making use of it. The result so far has been http://trac.adiumx.com/wiki/StaticAnalysis, which we'll be updating as we go through the reports. Augie is also doing another run using checker-55 since that report is from -47. So far this is pretty awesome :) I've fixed on leak and confirmed two in almost no time. This evening I'm going to go down the updated list in detail. Hopefully once we get comments on the false positives it'll be useful for improving the heuristics. David Smith From kremenek at apple.com Thu Jul 3 12:42:39 2008 From: kremenek at apple.com (Ted Kremenek) Date: Thu, 3 Jul 2008 10:42:39 -0700 Subject: [cfe-dev] Missing dealloc analysis In-Reply-To: <54A30DB6-5852-48A4-895F-5D1A958B6B2D@swan.ac.uk> References: <9904231A-DFC6-4027-8CBF-34239B90BD20@apple.com> <96F7EB76-01D6-446B-8444-CA13DB9A369D@shadowlab.org> <54A30DB6-5852-48A4-895F-5D1A958B6B2D@swan.ac.uk> Message-ID: <6A9DF794-3769-461B-B2A2-C454A9FEB8F6@apple.com> On Jul 3, 2008, at 10:30 AM, David Chisnall wrote: > This is especially true when you consider subclassing. A singleton > can not guarantee that its subclasses will also be singletons, and > so should release all of its ivars when it is -dealloc'd, or risk > causing leaks if it is subclassed. I think the current logic in the checker handles this. The check is obviated for a class if it doesn't contain any ivars, but the check is applied to every class, including subclasses of classes that didn't contain ivars. Consequently, it should handle the case where singletons are subclassed. > If a singleton needs to have shared resources that are also shared > with subclasses then it should store them in file statics, no ivars. Right. That's how I thought the Singleton pattern was typically implemented. From nikita at zhuk.fi Thu Jul 3 12:49:31 2008 From: nikita at zhuk.fi (Nikita Zhuk) Date: Thu, 3 Jul 2008 20:49:31 +0300 Subject: [cfe-dev] Missing dealloc analysis In-Reply-To: <54A30DB6-5852-48A4-895F-5D1A958B6B2D@swan.ac.uk> References: <9904231A-DFC6-4027-8CBF-34239B90BD20@apple.com> <96F7EB76-01D6-446B-8444-CA13DB9A369D@shadowlab.org> <54A30DB6-5852-48A4-895F-5D1A958B6B2D@swan.ac.uk> Message-ID: On 3.7.2008, at 20.30, David Chisnall wrote: > This is especially true when you consider subclassing. A singleton > can not guarantee that its subclasses will also be singletons, and so > should release all of its ivars when it is -dealloc'd, or risk causing > leaks if it is subclassed. > > If a singleton needs to have shared resources that are also shared > with subclasses then it should store them in file statics, no ivars. Yes, this is true, so the current "absence of ivars disables dealloc check" functionality should work with singletons as well, so no special cases needed. My original statement ("e.g. singletons don't need dealloc") was incorrect. But anyway, thanks for correction and quick implementation of these checks. From isanbard at gmail.com Thu Jul 3 13:15:59 2008 From: isanbard at gmail.com (Bill Wendling) Date: Thu, 3 Jul 2008 11:15:59 -0700 Subject: [cfe-dev] C++ status report web page In-Reply-To: <486C9183.5020001@gmail.com> References: <486B6A6F.7040104@gmail.com> <16e5fdf90807021607q2434642fo1edbbb09fcbae823@mail.gmail.com> <486C9183.5020001@gmail.com> Message-ID: <16e5fdf90807031115od167b67gddc31c3e928c668a@mail.gmail.com> On Thu, Jul 3, 2008 at 1:44 AM, Argiris Kirtzidis wrote: > Hi Bill, > > Bill Wendling wrote: >> >> On Wed, Jul 2, 2008 at 3:50 PM, Eli Friedman >> wrote: >> >>> >>> I'm not completely sure what this comment is in reply to, but I don't >>> see the relevance to this discussion. Are you arguing that we don't >>> have full support for reinterpret_cast, and therefore shouldn't claim >>> that? >>> >>> >> >> Yup! It's on Argiris' web page and should be updated with the correct >> information. So should the comment in the source code. >> > > I updated the page. > Thanks! :-) Are you (or someone else) going to work on full sema support for reinterpret_cast (and friends) or should I try to port my previous patch over to the new way of doing stuff? If others are going to do it, I suggest cannibalizing my patch. -bw From kremenek at apple.com Thu Jul 3 13:28:48 2008 From: kremenek at apple.com (Ted Kremenek) Date: Thu, 3 Jul 2008 11:28:48 -0700 Subject: [cfe-dev] Static analysis and Adium In-Reply-To: <4EA3495F-5F81-4D61-B478-F16949A3E18A@gmail.com> References: <4EA3495F-5F81-4D61-B478-F16949A3E18A@gmail.com> Message-ID: <33EE5412-DEAC-4C2A-90FC-DE6304A7DA32@apple.com> On Jul 3, 2008, at 10:40 AM, David Smith wrote: > After seeing the earlier email about static analysis being run on > Adium I emailed our development list about making use of it. The > result so far has been http://trac.adiumx.com/wiki/StaticAnalysis, > which we'll be updating as we go through the reports. Augie is also > doing another run using checker-55 since that report is from -47. So > far this is pretty awesome :) I've fixed on leak and confirmed two in > almost no time. This evening I'm going to go down the updated list in > detail. Hopefully once we get comments on the false positives it'll be > useful for improving the heuristics. > > David Smith Hi David, This is great news. It really gladdens me that people are finding the tool to be useful. Right now I'm looking at a few of the false positives in the list of warnings flagged for Adium. Some of them look like they are due to things that we are not tracking (and will hopefully eventually track), while others look like things we should handle right now. It's really helpful for me to see what reports are classified as false positives, as it gives me a systematic way to find bugs and shortcomings in the analyzer and eliminate them. It's also clear that the diagnostics still need significant improvement, especially with respect to null pointer dereferences. Beyond improving the precision of the analyzer, improving its output is also high on the todo list. (so any suggestions are welcome!) Finally, if you have feature requests for other bugs to check for, please email cfe-dev or file a bugzilla report. Ted From devlists at shadowlab.org Thu Jul 3 14:42:06 2008 From: devlists at shadowlab.org (Jean-Daniel Dupas) Date: Thu, 3 Jul 2008 21:42:06 +0200 Subject: [cfe-dev] Static Ananlyze, dead store false positive Message-ID: I'm playing with the last static analyzer (I'm always working with the svn trunk ;-)) and I'm scanning some of my projects. I confirm that it is a very valuable tool. I give you a fase positive (I think it 's one). It says I never read values out of keys, but I'm using it twice in the condition. void DeadStoreTest(NSObject *anObject) { NSArray *keys; // analyze result: Although the value stored to 'keys' is used in the enclosing expression, the value is never actually read from 'keys' if ((keys = [anObject exposedBindings]) && ([keys containsObject:@"name"] && [keys containsObject:@"icon"])) { // do something without keys } } -------------- next part -------------- A non-text attachment was scrubbed... Name: testdead.m Type: application/octet-stream Size: 248 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080703/1a439029/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080703/1a439029/attachment.bin From devlists at shadowlab.org Thu Jul 3 16:13:36 2008 From: devlists at shadowlab.org (Jean-Daniel Dupas) Date: Thu, 3 Jul 2008 23:13:36 +0200 Subject: [cfe-dev] signess error when building cfg Message-ID: Hello, I just encounter an assert when performing file analysis (cfg- building) in clang::Expr::isIntegerConstantExpr() When I perform an operation between to variable with different sign, APSInt raise an error (assert). And so, something like 'clang -cfg-dump' on this code will crash: #include void testBinaryOp() { void *bytes = 0; /* Alignement */ bytes = (intptr_t)bytes + 2; bytes = (intptr_t)bytes % 2; bytes = (intptr_t)bytes / 2; } Is it a known issue, or is it worth filling a bug report ? Stack trace: #4 0x91ca9063 in __assert_rtn () #5 0x00028789 in llvm::APSInt::operator+= (this=0xbfffe5b0, RHS=@0xbfffe454) at APSInt.h:159 #6 0x00025fd9 in clang::Expr::isIntegerConstantExpr (this=0xc0ae30, Result=@0xbfffe5b0, Ctx=@0xbfffef80, Loc=0x0, isEvaluated=true) at / Users/Projects/Tools/llvm/tools/clang/lib/AST/Expr.cpp:876 #7 0x00027036 in clang::Expr::isNullPointerConstant (this=0xc0ae30, Ctx=@0xbfffef80) at /Users/Projects/Tools/llvm/tools/clang/lib/AST/ Expr.cpp:1058 #8 0x00092871 in clang::Sema::CheckSingleAssignmentConstraints (this=0xbffff140, lhsType={ThePtr = 12595040}, rExpr=@0xbfffe708) at / Users/Projects/Tools/llvm/tools/clang/lib/Sema/SemaExpr.cpp:1431 #9 0x0009a0e9 in clang::Sema::CheckAssignmentOperands (this=0xbffff140, lex=0xc0ad90, rex=@0xbfffe708, loc={ID = 131294}, compoundType={ThePtr = 0}) at /Users/Projects/Tools/llvm/tools/clang/ lib/Sema/SemaExpr.cpp:1805 #10 0x00092af4 in clang::Sema::ActOnBinOp (this=0xbffff140, TokLoc={ID = 131294}, Kind=clang::tok::equal, LHS=0xc0ad90, RHS=0xc0ae30) at / Users/Projects/Tools/llvm/tools/clang/lib/Sema/SemaExpr.cpp:2052 #11 0x0005cfe0 in clang::Parser::ParseRHSOfBinaryExpression (this=0xbffff2b0, LHS={Val = 0xc0ad90, isInvalid = false}, MinPrec=1) at /Users/Projects/Tools/llvm/tools/clang/lib/Parse/ParseExpr.cpp:384 #12 0x0005e482 in clang::Parser::ParseExpressionWithLeadingIdentifier (this=0xbffff2b0, IdTok=@0xbfffea04) at /Users/Projects/Tools/llvm/ tools/clang/lib/Parse/ParseExpr.cpp:259 #13 0x000548ed in clang::Parser::ParseIdentifierStatement (this=0xbffff2b0, OnlyStatement=false) at /Users/Projects/Tools/llvm/ tools/clang/lib/Parse/ParseStmt.cpp:267 #14 0x000521da in clang::Parser::ParseStatementOrDeclaration (this=0xbffff2b0, OnlyStatement=false) at /Users/Projects/Tools/llvm/ tools/clang/lib/Parse/ParseStmt.cpp:86 #15 0x00051a7e in clang::Parser::ParseCompoundStatementBody (this=0xbffff2b0, isStmtExpr=false) at /Users/Projects/Tools/llvm/ tools/clang/lib/Parse/ParseStmt.cpp:425 #16 0x00051e68 in clang::Parser::ParseFunctionStatementBody (this=0xbffff2b0, Decl=0xc07160, L={ID = 131246}, R={ID = 131246}) at / Users/Projects/Tools/llvm/tools/clang/lib/Parse/ParseStmt.cpp:1149 #17 0x0001e09c in clang::Parser::ParseFunctionDefinition (this=0xbffff2b0, D=@0xbfffed70) at /Users/Projects/Tools/llvm/tools/ clang/lib/Parse/Parser.cpp:507 #18 0x0001e5f5 in clang::Parser::ParseDeclarationOrFunctionDefinition (this=0xbffff2b0) at /Users/Projects/Tools/llvm/tools/clang/lib/Parse/ Parser.cpp:442 #19 0x0001e74f in clang::Parser::ParseExternalDeclaration (this=0xbffff2b0) at /Users/Projects/Tools/llvm/tools/clang/lib/Parse/ Parser.cpp:353 #20 0x0001e979 in clang::Parser::ParseTopLevelDecl (this=0xbffff2b0, Result=@0xbffff384) at /Users/Projects/Tools/llvm/tools/clang/lib/ Parse/Parser.cpp:269 #21 0x000ab191 in clang::ParseAST (PP=@0xc011d0, Consumer=0xc02120, PrintStats=false) at /Users/Projects/Tools/llvm/tools/clang/lib/Sema/ ParseAST.cpp:56 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080703/0cb28ed8/attachment.bin From kremenek at apple.com Thu Jul 3 17:09:21 2008 From: kremenek at apple.com (Ted Kremenek) Date: Thu, 3 Jul 2008 15:09:21 -0700 Subject: [cfe-dev] signess error when building cfg In-Reply-To: References: Message-ID: Hi Jean-Daniel, This is a good test case. Please file a bug report. Even clang -ast- dump fails on this test case. Best, Ted On Jul 3, 2008, at 2:13 PM, Jean-Daniel Dupas wrote: > Hello, > > I just encounter an assert when performing file analysis (cfg- > building) in clang::Expr::isIntegerConstantExpr() > > When I perform an operation between to variable with different sign, > APSInt raise an error (assert). > > And so, something like 'clang -cfg-dump' on this code will crash: > > #include > > void testBinaryOp() { > void *bytes = 0; > /* Alignement */ > bytes = (intptr_t)bytes + 2; > bytes = (intptr_t)bytes % 2; > bytes = (intptr_t)bytes / 2; > } > > > Is it a known issue, or is it worth filling a bug report ? > > Stack trace: > > #4 0x91ca9063 in __assert_rtn () > #5 0x00028789 in llvm::APSInt::operator+= (this=0xbfffe5b0, > RHS=@0xbfffe454) at APSInt.h:159 > #6 0x00025fd9 in clang::Expr::isIntegerConstantExpr (this=0xc0ae30, > Result=@0xbfffe5b0, Ctx=@0xbfffef80, Loc=0x0, isEvaluated=true) at / > Users/Projects/Tools/llvm/tools/clang/lib/AST/Expr.cpp:876 > #7 0x00027036 in clang::Expr::isNullPointerConstant (this=0xc0ae30, > Ctx=@0xbfffef80) at /Users/Projects/Tools/llvm/tools/clang/lib/AST/ > Expr.cpp:1058 > #8 0x00092871 in clang::Sema::CheckSingleAssignmentConstraints > (this=0xbffff140, lhsType={ThePtr = 12595040}, rExpr=@0xbfffe708) > at /Users/Projects/Tools/llvm/tools/clang/lib/Sema/SemaExpr.cpp:1431 > #9 0x0009a0e9 in clang::Sema::CheckAssignmentOperands > (this=0xbffff140, lex=0xc0ad90, rex=@0xbfffe708, loc={ID = 131294}, > compoundType={ThePtr = 0}) at /Users/Projects/Tools/llvm/tools/clang/ > lib/Sema/SemaExpr.cpp:1805 > #10 0x00092af4 in clang::Sema::ActOnBinOp (this=0xbffff140, > TokLoc={ID = 131294}, Kind=clang::tok::equal, LHS=0xc0ad90, > RHS=0xc0ae30) at /Users/Projects/Tools/llvm/tools/clang/lib/Sema/ > SemaExpr.cpp:2052 > #11 0x0005cfe0 in clang::Parser::ParseRHSOfBinaryExpression > (this=0xbffff2b0, LHS={Val = 0xc0ad90, isInvalid = false}, > MinPrec=1) at /Users/Projects/Tools/llvm/tools/clang/lib/Parse/ > ParseExpr.cpp:384 > #12 0x0005e482 in > clang::Parser::ParseExpressionWithLeadingIdentifier > (this=0xbffff2b0, IdTok=@0xbfffea04) at /Users/Projects/Tools/llvm/ > tools/clang/lib/Parse/ParseExpr.cpp:259 > #13 0x000548ed in clang::Parser::ParseIdentifierStatement > (this=0xbffff2b0, OnlyStatement=false) at /Users/Projects/Tools/llvm/ > tools/clang/lib/Parse/ParseStmt.cpp:267 > #14 0x000521da in clang::Parser::ParseStatementOrDeclaration > (this=0xbffff2b0, OnlyStatement=false) at /Users/Projects/Tools/llvm/ > tools/clang/lib/Parse/ParseStmt.cpp:86 > #15 0x00051a7e in clang::Parser::ParseCompoundStatementBody > (this=0xbffff2b0, isStmtExpr=false) at /Users/Projects/Tools/llvm/ > tools/clang/lib/Parse/ParseStmt.cpp:425 > #16 0x00051e68 in clang::Parser::ParseFunctionStatementBody > (this=0xbffff2b0, Decl=0xc07160, L={ID = 131246}, R={ID = 131246}) > at /Users/Projects/Tools/llvm/tools/clang/lib/Parse/ParseStmt.cpp:1149 > #17 0x0001e09c in clang::Parser::ParseFunctionDefinition > (this=0xbffff2b0, D=@0xbfffed70) at /Users/Projects/Tools/llvm/tools/ > clang/lib/Parse/Parser.cpp:507 > #18 0x0001e5f5 in > clang::Parser::ParseDeclarationOrFunctionDefinition > (this=0xbffff2b0) at /Users/Projects/Tools/llvm/tools/clang/lib/ > Parse/Parser.cpp:442 > #19 0x0001e74f in clang::Parser::ParseExternalDeclaration > (this=0xbffff2b0) at /Users/Projects/Tools/llvm/tools/clang/lib/ > Parse/Parser.cpp:353 > #20 0x0001e979 in clang::Parser::ParseTopLevelDecl (this=0xbffff2b0, > Result=@0xbffff384) at /Users/Projects/Tools/llvm/tools/clang/lib/ > Parse/Parser.cpp:269 > #21 0x000ab191 in clang::ParseAST (PP=@0xc011d0, Consumer=0xc02120, > PrintStats=false) at /Users/Projects/Tools/llvm/tools/clang/lib/Sema/ > ParseAST.cpp:56 > > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From kremenek at apple.com Thu Jul 3 17:35:55 2008 From: kremenek at apple.com (Ted Kremenek) Date: Thu, 3 Jul 2008 15:35:55 -0700 Subject: [cfe-dev] Static Ananlyze, dead store false positive In-Reply-To: References: Message-ID: <3F80DCF7-BF19-4AC9-8B66-46EB4937C7A9@apple.com> On Jul 3, 2008, at 12:42 PM, Jean-Daniel Dupas wrote: > I'm playing with the last static analyzer (I'm always working with > the svn trunk ;-)) and I'm scanning some of my projects. > I confirm that it is a very valuable tool. > > I give you a fase positive (I think it 's one). It says I never read > values out of keys, but I'm using it twice in the condition. > > > void DeadStoreTest(NSObject *anObject) { > NSArray *keys; > // analyze result: Although the value stored to 'keys' is used in > the enclosing expression, the value is never actually read from 'keys' > if ((keys = [anObject exposedBindings]) && > ([keys containsObject:@"name"] && [keys > containsObject:@"icon"])) { > // do something without keys > > } > } This was a genuine bug in the Dead Stores checker, now fixed: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20080630/006378.html For those not working with the SVN trunk, the fix should now be in checker-56 (on the Clang website). BTW, this was an awesome test case. It nicely exercised a mishandled corner case in the analyzer's logic, which allowed me to quickly diagnose the problem. Thanks for providing it! Ted From akyrtzi at gmail.com Thu Jul 3 20:14:19 2008 From: akyrtzi at gmail.com (Argiris Kirtzidis) Date: Thu, 03 Jul 2008 18:14:19 -0700 Subject: [cfe-dev] Preprocessor::LookNext Message-ID: <486D796B.3080906@gmail.com> Hi, The "nested-name-specifier '::' " syntax occurs at enough places that it would really simplify the code if an efficient Parser::GetLookAheadToken(1) could be used. I attached a Preprocessor::LookNext implementation for this (pp-looknext.patch). In the "parse-labeled" patch I use LookNext to determine a label and use a separate Parser::ParseLabeledStatement. Let me know what you think. -Argiris -------------- next part -------------- A non-text attachment was scrubbed... Name: pp-looknext.patch Type: text/x-diff Size: 2163 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080703/b49b6797/attachment-0002.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: parse-labeled.patch Type: text/x-diff Size: 4331 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080703/b49b6797/attachment-0003.bin From akyrtzi at gmail.com Thu Jul 3 20:18:13 2008 From: akyrtzi at gmail.com (Argiris Kirtzidis) Date: Thu, 03 Jul 2008 18:18:13 -0700 Subject: [cfe-dev] C++ status report web page In-Reply-To: <16e5fdf90807031115od167b67gddc31c3e928c668a@mail.gmail.com> References: <486B6A6F.7040104@gmail.com> <16e5fdf90807021607q2434642fo1edbbb09fcbae823@mail.gmail.com> <486C9183.5020001@gmail.com> <16e5fdf90807031115od167b67gddc31c3e928c668a@mail.gmail.com> Message-ID: <486D7A55.4020702@gmail.com> Bill Wendling wrote: > Are you (or someone else) going to work on full sema > support for reinterpret_cast (and friends) or should I try to port my > previous patch over to the new way of doing stuff? If others are going > to do it, I suggest cannibalizing my patch. > Not in my TODO list at the moment :-) -Argiris From eli.friedman at gmail.com Thu Jul 3 20:43:11 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Thu, 3 Jul 2008 18:43:11 -0700 Subject: [cfe-dev] signess error when building cfg In-Reply-To: References: Message-ID: On Thu, Jul 3, 2008 at 2:13 PM, Jean-Daniel Dupas wrote: > Hello, > > I just encounter an assert when performing file analysis (cfg-building) in > clang::Expr::isIntegerConstantExpr() > > When I perform an operation between to variable with different sign, APSInt > raise an error (assert). > > And so, something like 'clang -cfg-dump' on this code will crash: > > #include > > void testBinaryOp() { > void *bytes = 0; > /* Alignement */ > bytes = (intptr_t)bytes + 2; > bytes = (intptr_t)bytes % 2; > bytes = (intptr_t)bytes / 2; > } > > > Is it a known issue, or is it worth filling a bug report ? > > Stack trace: > > #4 0x91ca9063 in __assert_rtn () > #5 0x00028789 in llvm::APSInt::operator+= (this=0xbfffe5b0, > RHS=@0xbfffe454) at APSInt.h:159 > #6 0x00025fd9 in clang::Expr::isIntegerConstantExpr (this=0xc0ae30, > Result=@0xbfffe5b0, Ctx=@0xbfffef80, Loc=0x0, isEvaluated=true) at > /Users/Projects/Tools/llvm/tools/clang/lib/AST/Expr.cpp:876 Mmm, if I'm not mistaken, this looks like a known issue with the hack allowing pointers in integer constant expressions; I was planning to fix it sooner, but the right fix grew a bit bigger than I expected it to, and I never got around to coming up with a quick hack. (Specifically, the complete fix involves the new constant expression evaluator work.) -Eli From clattner at apple.com Thu Jul 3 22:07:24 2008 From: clattner at apple.com (Chris Lattner) Date: Thu, 3 Jul 2008 20:07:24 -0700 Subject: [cfe-dev] signess error when building cfg In-Reply-To: References: Message-ID: On Jul 3, 2008, at 6:43 PM, Eli Friedman wrote: >> Stack trace: >> >> #4 0x91ca9063 in __assert_rtn () >> #5 0x00028789 in llvm::APSInt::operator+= (this=0xbfffe5b0, >> RHS=@0xbfffe454) at APSInt.h:159 >> #6 0x00025fd9 in clang::Expr::isIntegerConstantExpr (this=0xc0ae30, >> Result=@0xbfffe5b0, Ctx=@0xbfffef80, Loc=0x0, isEvaluated=true) at >> /Users/Projects/Tools/llvm/tools/clang/lib/AST/Expr.cpp:876 > > Mmm, if I'm not mistaken, this looks like a known issue with the hack > allowing pointers in integer constant expressions; I was planning to > fix it sooner, but the right fix grew a bit bigger than I expected it > to, and I never got around to coming up with a quick hack. > (Specifically, the complete fix involves the new constant expression > evaluator work.) Yes, it is. We really need to fix this. I poked at this briefly, and the basic problem is that isIntegerConstantExpr returns true for casts from pointer but doesn't fill in Result. We really should only return true (in the GCC hack mode) if we are able to fold the pointer expression. -Chris From hs4233 at mail.mn-solutions.de Fri Jul 4 02:17:00 2008 From: hs4233 at mail.mn-solutions.de (Holger Schurig) Date: Fri, 4 Jul 2008 09:17:00 +0200 Subject: [cfe-dev] Static analysis and Adium In-Reply-To: <33EE5412-DEAC-4C2A-90FC-DE6304A7DA32@apple.com> References: <4EA3495F-5F81-4D61-B478-F16949A3E18A@gmail.com> <33EE5412-DEAC-4C2A-90FC-DE6304A7DA32@apple.com> Message-ID: <200807040917.01005.hs4233@mail.mn-solutions.de> > dereferences. Beyond improving the precision of the analyzer, > improving its output is also high on the todo list. (so any > suggestions are welcome!) Add links to descriptions. E.g., when who first visits this page sees "Dead store on ...". I can imagine that only a few people know what a dead store actually is. From devlists at shadowlab.org Fri Jul 4 04:14:28 2008 From: devlists at shadowlab.org (Jean-Daniel Dupas) Date: Fri, 4 Jul 2008 11:14:28 +0200 Subject: [cfe-dev] Adding title in HTML report Message-ID: Hello, I'm think it may be convenient to update the HTMLRewriter to support a in the header. When I read a static report result page, I have to scroll to the top of the page to find the file name. If we put the filename into the html title field, the browser will display it in the window title. So I think we can update the HTMLRewriter, AddHeaderFooterInternalBuiltinCSS method to accept an optional title string. void html::AddHeaderFooterInternalBuiltinCSS(Rewriter& R, unsigned FileID, const char *title = NULL) But after, what is the recommanded way to compose the header. will something like this be fine (using a ostringstream) ? I also attach a patch that implements this change. ------------------------------------------------ std::ostringstream os; os << "<!doctype html>\n" // Use HTML 5 doctype "<html>\n<head>\n"; if (title) os << "<title>" << html::EscapeText(title) << "\n"; os << "\n\n"; // Generate header R.InsertStrBefore(StartLoc, os.str()); ------------------------------------------------ -------------- next part -------------- A non-text attachment was scrubbed... Name: html_title.diff Type: application/octet-stream Size: 3774 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080704/07a54700/attachment.obj -------------- next part -------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080704/07a54700/attachment.bin From catfish.man at gmail.com Fri Jul 4 16:41:30 2008 From: catfish.man at gmail.com (David Smith) Date: Fri, 4 Jul 2008 14:41:30 -0700 Subject: [cfe-dev] Static analysis output format Message-ID: <8253B101-7F22-41CE-BD00-7EC489709C54@gmail.com> As we've been working through the list of results from static analysis for Adium it's become increasingly clear that the output format is introducing some complications. Specifically, each time we rerun (whether to use an updated version of checker, or to check against the latest source) it eliminates any metadata that we've built up around the results, such as which ones were false positives. Unfortunately, fixing this seems somewhat tricky. The main thing that would be necessary is a way of identifying results across runs. That way we can plug this into our automated testing system so each time we commit it can rerun and say "ok, these ones are known, these ones are known false positives, and these ones are new" rather than just "here's a list to re-evaluate". I'm not sure how to come up with some sort of identifier for issues though. Line numbers probably change too frequently to be reliable. I suppose a heuristic based on function name, issue type, file name, and approximate line number might be fairly accurate. David From peter.neumark at gmail.com Sat Jul 5 10:31:34 2008 From: peter.neumark at gmail.com (Peter Neumark) Date: Sat, 5 Jul 2008 17:31:34 +0200 Subject: [cfe-dev] Clang Distcc Status P.S. Message-ID: <2e837e3a0807050831n564cb3bch711dec5565ed2986@mail.gmail.com> Not June 1 but July 1 ! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080705/b94c9d55/attachment.html From peter.neumark at gmail.com Sat Jul 5 10:44:47 2008 From: peter.neumark at gmail.com (Peter Neumark) Date: Sat, 5 Jul 2008 17:44:47 +0200 Subject: [cfe-dev] Clang Distcc Status Message-ID: <2e837e3a0807050844v612417e4o896200420c03df1e@mail.gmail.com> Hi! I'd like to introduce the first preview of (partly working) clang network distributed compiler project. All feedback is welcome. I was done all of this code form Tuesday (July 1). I'll send a complete design documentation soon. But the whole code is pretty simple, you can check it. There is a (small) patch for current clang driver to support network distributed compilation. There remote compilation is done by clangserver (the new remote driver). I'll send the design and user doc soon (in 3 days). P.S.: My system is ubuntu hardy linux. Cheers, Peter Neumark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080705/dccf8a5c/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: clang.nosvn.tar.gz Type: application/x-gzip Size: 92151 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080705/dccf8a5c/attachment-0001.gz From peter.neumark at gmail.com Sat Jul 5 10:29:36 2008 From: peter.neumark at gmail.com (Peter Neumark) Date: Sat, 5 Jul 2008 17:29:36 +0200 Subject: [cfe-dev] Clang Distcc Status Message-ID: <2e837e3a0807050829n1f2a4941yaf9d5a20daac241a@mail.gmail.com> Hi! I'd like to introduce the first preview of (partly working) clang network distributed compiler project. All feedback is welcome. I was done all of this code form Tuesday (June 1). I'll send a complete design documentation soon. But the whole code is pretty simple, you can check it. There is a (small) patch for current clang driver to support network distributed compilation. There remote compilation is done by clangserver (the new remote driver). I'll send the design and user doc soon (in 3 days). P.S.: My system is ubuntu hardy linux. Cheers, Peter Neumark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080705/721cd82f/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: clang.tar.gz Type: application/x-gzip Size: 159170 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080705/721cd82f/attachment-0001.gz From nunoplopes at sapo.pt Sat Jul 5 14:24:25 2008 From: nunoplopes at sapo.pt (Nuno Lopes) Date: Sat, 5 Jul 2008 20:24:25 +0100 Subject: [cfe-dev] __attribute__((alias)) Message-ID: <3FA4BB9CFECF4D5189AE40B46F951357@pc07654> Hi, Some time ago I added support for __attribute__((alias)). However it is not working when referencing an aliased function from a different file where it was defined. Take a look at this example: foo.ll: declare void @zend_error(i32, i8*, ...) ;declare void @zend_error_noreturn(i32, i8*, ...) noreturn @zend_error_noreturn = alias void (i32, i8*, ...)* @zend_error ; [#uses=0] bar.ll: declare void @zend_error_noreturn(i32, i8*, ...) noreturn linking those files leads to: llvm-as foo.ll; llvm-as bar.ll llvm-ld -native -o xpto foo.bc bar.bc llvm-ld: LinkModules.cpp:425: void ForceRenaming(llvm::GlobalValue*, const std::string&): Assertion `ConflictGV->hasInternalLinkage() && "Not conflicting with a static global, should link instead!"' failed. If you uncomment the 2nd line of foo.ll it doesn't trigger that exception. Is this a bug in the linker or should clang generate the extra declaration? Nuno P.S.: after fixing this problem, PHP should finally compile :-) From eli.friedman at gmail.com Sat Jul 5 16:13:36 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Sat, 5 Jul 2008 14:13:36 -0700 Subject: [cfe-dev] __attribute__((alias)) In-Reply-To: <3FA4BB9CFECF4D5189AE40B46F951357@pc07654> References: <3FA4BB9CFECF4D5189AE40B46F951357@pc07654> Message-ID: On Sat, Jul 5, 2008 at 12:24 PM, Nuno Lopes wrote: > Hi, > > Some time ago I added support for __attribute__((alias)). However it is not > working when referencing an aliased function from a different file where it > was defined. > Take a look at this example: > > foo.ll: > declare void @zend_error(i32, i8*, ...) > ;declare void @zend_error_noreturn(i32, i8*, ...) noreturn > @zend_error_noreturn = alias void (i32, i8*, ...)* @zend_error ; (i32, i8*, ...)*> [#uses=0] > > > bar.ll: > declare void @zend_error_noreturn(i32, i8*, ...) noreturn > > linking those files leads to: > llvm-as foo.ll; llvm-as bar.ll > llvm-ld -native -o xpto foo.bc bar.bc > > llvm-ld: LinkModules.cpp:425: void ForceRenaming(llvm::GlobalValue*, const > std::string&): Assertion `ConflictGV->hasInternalLinkage() && "Not > conflicting with a static global, should link instead!"' failed. > > If you uncomment the 2nd line of foo.ll it doesn't trigger that exception. > Is this a bug in the linker or should clang generate the extra declaration? Mmm, yes, I remember seeing that alias when I tried compiling PHP; I got around it by tweaking a couple of ifdefs. I think llvm-ld is doing the wrong thing here. Testcase: x.c: int a() {return 0;}int b() __attribute((alias("a"))); y.c: int b(); int main() {return b();} Both clang and llvm-gcc generate approximately the same thing, the results of both cause link errors with llvm-ld, and both work fine if compiled separately. -Eli From asl at math.spbu.ru Sat Jul 5 16:29:50 2008 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Sun, 06 Jul 2008 01:29:50 +0400 Subject: [cfe-dev] __attribute__((alias)) In-Reply-To: References: <3FA4BB9CFECF4D5189AE40B46F951357@pc07654> Message-ID: <1215293390.13183.8.camel@localhost> Hello, Eli > Both clang and llvm-gcc generate approximately the same thing, the > results of both cause link errors with llvm-ld, and both work fine if > compiled separately. This is PR2146 -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University. From nunoplopes at sapo.pt Sat Jul 5 17:22:51 2008 From: nunoplopes at sapo.pt (Nuno Lopes) Date: Sat, 5 Jul 2008 23:22:51 +0100 Subject: [cfe-dev] __attribute__((alias)) In-Reply-To: <1215293390.13183.8.camel@localhost> References: <3FA4BB9CFECF4D5189AE40B46F951357@pc07654> <1215293390.13183.8.camel@localhost> Message-ID: >> Both clang and llvm-gcc generate approximately the same thing, the >> results of both cause link errors with llvm-ld, and both work fine if >> compiled separately. > This is PR2146 Uhm, damn. Are you working on a fix for the problem? Do you have any ETA? If not I may try to adventure myself and try to fix it (although I prefer not to learn yet another sources right now). Thanks, Nuno From nunoplopes at sapo.pt Sun Jul 6 05:13:44 2008 From: nunoplopes at sapo.pt (Nuno Lopes) Date: Sun, 6 Jul 2008 11:13:44 +0100 Subject: [cfe-dev] __attribute__((alias)) In-Reply-To: <1215293390.13183.8.camel@localhost> References: <3FA4BB9CFECF4D5189AE40B46F951357@pc07654> <1215293390.13183.8.camel@localhost> Message-ID: <5BFABBFEF4FE462C87E5F04F51D28D93@pc07654> > Hello, Eli > >> Both clang and llvm-gcc generate approximately the same thing, the >> results of both cause link errors with llvm-ld, and both work fine if >> compiled separately. > This is PR2146 Ok, it's working now after your fix. Thanks! Now PHP compiles fine and passes most of the tests. However it is segfaulting in a few dozen tests and producing weird valgrind reports in others. How I love compilers.. :-) Nuno From kremenek at apple.com Sun Jul 6 19:28:38 2008 From: kremenek at apple.com (Ted Kremenek) Date: Sun, 6 Jul 2008 17:28:38 -0700 Subject: [cfe-dev] Static analysis and Adium In-Reply-To: <200807040917.01005.hs4233@mail.mn-solutions.de> References: <4EA3495F-5F81-4D61-B478-F16949A3E18A@gmail.com> <33EE5412-DEAC-4C2A-90FC-DE6304A7DA32@apple.com> <200807040917.01005.hs4233@mail.mn-solutions.de> Message-ID: <413D84B5-FDD1-43BE-A001-792A59B57352@apple.com> On Jul 4, 2008, at 12:17 AM, Holger Schurig wrote: >> dereferences. Beyond improving the precision of the analyzer, >> improving its output is also high on the todo list. (so any >> suggestions are welcome!) > > Add links to descriptions. E.g., when who first visits this page > sees "Dead store on ...". I can imagine that only a few people > know what a dead store actually is. Agreed. That's an excellent suggestion. From wilsonkk at shaw.ca Mon Jul 7 08:40:49 2008 From: wilsonkk at shaw.ca (Kelly Wilson) Date: Mon, 7 Jul 2008 07:40:49 -0600 Subject: [cfe-dev] GSL 'make check' failure Message-ID: <705ffc$cs8n@pd2mo1so-svcs.prod.shaw.ca> Hello all, I have built GSL without incident at this point, but 'make check' dies in the block subdirectory with this: make check-TESTS make[1]: Entering directory `/home/notroot/gsl-1.11/block' *** glibc detected *** ./test: free(): invalid pointer: 0x0805f050 *** ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6[0x400bca85] . . . FAIL: test =================== 1 of 1 tests failed =================== make[1]: *** [check-TESTS] Error 1 make[1]: Leaving directory `/home/notroot/gsl-1.11/block' make: *** [check-am] Error 2 If anyone wants the full backtrace, just let me know, but the meat of it is the invalid pointer in being passed to free(). The free function that fails is being called in the test_complex_binary function (test_complex_float_binary() fails as well, although test_complex_long_double_binary() doesn't fail???). I have looked at the assembly output of both failing functions (and the printed machine instructions output for LLVM) and can't see anything grossly wrong with the code. Something coming in off the stack is the problem, it seems. All other test cases in the block directory work fine. Looking at the differences between the regular test cases and the complex test cases, it seems that there is an address calculation into a struct containing the double (or float but not 'long double', as I said) that causes the next call to free() to fail. Here is a small snippet: For (i=0;idata[2*i] = ATOMIC(N - i); v->data[2*i + 1] = ATOMIC(10 * (N - i) + 1); }; fwrite(). fclose(). free(). this free() is the one that fails and the second offset into v->data is the only different calculation when compared to test_double_binary() or test_float_binary().so that seems to be the culprit. Any ideas? Thanks, K.Wilson -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080707/727ea61a/attachment.html From toddransom at mac.com Mon Jul 7 09:02:10 2008 From: toddransom at mac.com (Todd Ransom) Date: Mon, 07 Jul 2008 10:02:10 -0400 Subject: [cfe-dev] Static analysis and Adium In-Reply-To: <413D84B5-FDD1-43BE-A001-792A59B57352@apple.com> References: <4EA3495F-5F81-4D61-B478-F16949A3E18A@gmail.com> <33EE5412-DEAC-4C2A-90FC-DE6304A7DA32@apple.com> <200807040917.01005.hs4233@mail.mn-solutions.de> <413D84B5-FDD1-43BE-A001-792A59B57352@apple.com> Message-ID: I would like to see the output sorted by source file. For instance, if MyClass.m has 5 memory leaks reported then these leaks should all be next to one another so I don't have to hunt back and forth between files. And/or you could make the table of results sortable by column. Todd Ransom StoryMill & Montage Development Mariner Software On Jul 6, 2008, at 8:28 PM, Ted Kremenek wrote: > > On Jul 4, 2008, at 12:17 AM, Holger Schurig wrote: > >>> dereferences. Beyond improving the precision of the analyzer, >>> improving its output is also high on the todo list. (so any >>> suggestions are welcome!) >> >> Add links to descriptions. E.g., when who first visits this page >> sees "Dead store on ...". I can imagine that only a few people >> know what a dead store actually is. > > Agreed. That's an excellent suggestion. > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From matthijs at stdin.nl Mon Jul 7 09:31:43 2008 From: matthijs at stdin.nl (Matthijs Kooijman) Date: Mon, 7 Jul 2008 16:31:43 +0200 Subject: [cfe-dev] GSL 'make check' failure In-Reply-To: <705ffc$cs8n@pd2mo1so-svcs.prod.shaw.ca> References: <705ffc$cs8n@pd2mo1so-svcs.prod.shaw.ca> Message-ID: <20080707143143.GH32600@katherina.student.utwente.nl> > For (i=0;i > { > > v->data[2*i] = ATOMIC(N - i); > > v->data[2*i + 1] = ATOMIC(10 * (N - i) + 1); > > }; > > > > fwrite(). > > fclose(). > > free(). I've seen similar free errors after doing out-of-bounds write. Are you sure that data is allocated long enough (2N elements)? Gr. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080707/33637639/attachment.bin From kremenek at apple.com Mon Jul 7 10:25:42 2008 From: kremenek at apple.com (Ted Kremenek) Date: Mon, 7 Jul 2008 08:25:42 -0700 Subject: [cfe-dev] Static analysis and Adium In-Reply-To: References: <4EA3495F-5F81-4D61-B478-F16949A3E18A@gmail.com> <33EE5412-DEAC-4C2A-90FC-DE6304A7DA32@apple.com> <200807040917.01005.hs4233@mail.mn-solutions.de> <413D84B5-FDD1-43BE-A001-792A59B57352@apple.com> Message-ID: <425B2039-37D8-41D3-8E55-FB5605F17E8D@apple.com> Hi Todd, The table of results should already be sortable by column. Is this not working for you? We use the sorttable.js script found at: http://www.kryogenix.org/code/browser/sorttable/ This only works if the sorttable.js is in the same directory as the index.html that lists the set of warnings (scan-build copies this file over by default). Ted On Jul 7, 2008, at 7:02 AM, Todd Ransom wrote: > I would like to see the output sorted by source file. For instance, > if MyClass.m has 5 memory leaks reported then these leaks should all > be next to one another so I don't have to hunt back and forth > between files. And/or you could make the table of results sortable > by column. > > Todd Ransom > StoryMill & Montage Development > Mariner Software > > > > > On Jul 6, 2008, at 8:28 PM, Ted Kremenek wrote: > >> >> On Jul 4, 2008, at 12:17 AM, Holger Schurig wrote: >> >>>> dereferences. Beyond improving the precision of the analyzer, >>>> improving its output is also high on the todo list. (so any >>>> suggestions are welcome!) >>> >>> Add links to descriptions. E.g., when who first visits this page >>> sees "Dead store on ...". I can imagine that only a few people >>> know what a dead store actually is. >> >> Agreed. That's an excellent suggestion. >> _______________________________________________ >> cfe-dev mailing list >> cfe-dev at cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > From kremenek at apple.com Mon Jul 7 10:32:12 2008 From: kremenek at apple.com (Ted Kremenek) Date: Mon, 7 Jul 2008 08:32:12 -0700 Subject: [cfe-dev] Static analysis and Adium In-Reply-To: <425B2039-37D8-41D3-8E55-FB5605F17E8D@apple.com> References: <4EA3495F-5F81-4D61-B478-F16949A3E18A@gmail.com> <33EE5412-DEAC-4C2A-90FC-DE6304A7DA32@apple.com> <200807040917.01005.hs4233@mail.mn-solutions.de> <413D84B5-FDD1-43BE-A001-792A59B57352@apple.com> <425B2039-37D8-41D3-8E55-FB5605F17E8D@apple.com> Message-ID: <1FA8B02A-EDB4-4F3E-A5A2-B93C7F711B47@apple.com> Hi Todd, BTW, after I sent my last email, I realized that you may have been referring to the table on the Adium wiki: http://trac.adiumx.com/wiki/StaticAnalysis This table was not produced by the static analysis tool. The tool itself produces an index.html (not shown) that contains a table of warnings whose columns can be sorted with a mouse click. That table has a less polished look than the one in the wiki. If you are interested in getting the static analysis results on Adium where you can sort the results, you can easily just rerun the tool. If anyone is interested in making the tool's output more polished, patches are certainly welcome. I don't pretend to be an HTML guru. Ted On Jul 7, 2008, at 8:25 AM, Ted Kremenek wrote: > Hi Todd, > > The table of results should already be sortable by column. Is this > not working for you? We use the sorttable.js script found at: > > http://www.kryogenix.org/code/browser/sorttable/ > > This only works if the sorttable.js is in the same directory as the > index.html that lists the set of warnings (scan-build copies this file > over by default). > > Ted > > On Jul 7, 2008, at 7:02 AM, Todd Ransom wrote: > >> I would like to see the output sorted by source file. For instance, >> if MyClass.m has 5 memory leaks reported then these leaks should all >> be next to one another so I don't have to hunt back and forth >> between files. And/or you could make the table of results sortable >> by column. >> >> Todd Ransom >> StoryMill & Montage Development >> Mariner Software >> >> >> >> >> On Jul 6, 2008, at 8:28 PM, Ted Kremenek wrote: >> >>> >>> On Jul 4, 2008, at 12:17 AM, Holger Schurig wrote: >>> >>>>> dereferences. Beyond improving the precision of the analyzer, >>>>> improving its output is also high on the todo list. (so any >>>>> suggestions are welcome!) >>>> >>>> Add links to descriptions. E.g., when who first visits this page >>>> sees "Dead store on ...". I can imagine that only a few people >>>> know what a dead store actually is. >>> >>> Agreed. That's an excellent suggestion. >>> _______________________________________________ >>> cfe-dev mailing list >>> cfe-dev at cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev >> > > _______________________________________________ > 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/20080707/64d16b12/attachment-0001.html From toddransom at mac.com Mon Jul 7 10:39:11 2008 From: toddransom at mac.com (Todd Ransom) Date: Mon, 07 Jul 2008 11:39:11 -0400 Subject: [cfe-dev] Static analysis and Adium In-Reply-To: <1FA8B02A-EDB4-4F3E-A5A2-B93C7F711B47@apple.com> References: <4EA3495F-5F81-4D61-B478-F16949A3E18A@gmail.com> <33EE5412-DEAC-4C2A-90FC-DE6304A7DA32@apple.com> <200807040917.01005.hs4233@mail.mn-solutions.de> <413D84B5-FDD1-43BE-A001-792A59B57352@apple.com> <425B2039-37D8-41D3-8E55-FB5605F17E8D@apple.com> <1FA8B02A-EDB4-4F3E-A5A2-B93C7F711B47@apple.com> Message-ID: <7EEAEF33-DD70-423C-BB20-0A840B19FAD4@mac.com> No, I was talking about the table produced by the scan-build command line interface. I see now that it is sortable. It might be nice to provide some visual indicator of that. The default table sort seems to be by bug type. If you added a sort indicator to that column by default it would be more obvious the table is sortable. thanks, Todd Ransom StoryMill & Montage Development Mariner Software On Jul 7, 2008, at 11:32 AM, Ted Kremenek wrote: > Hi Todd, > > BTW, after I sent my last email, I realized that you may have been > referring to the table on the Adium wiki: > > http://trac.adiumx.com/wiki/StaticAnalysis > > This table was not produced by the static analysis tool. > > The tool itself produces an index.html (not shown) that contains a > table of warnings whose columns can be sorted with a mouse click. > That table has a less polished look than the one in the wiki. If > you are interested in getting the static analysis results on Adium > where you can sort the results, you can easily just rerun the tool. > > If anyone is interested in making the tool's output more polished, > patches are certainly welcome. I don't pretend to be an HTML guru. > > Ted > > On Jul 7, 2008, at 8:25 AM, Ted Kremenek wrote: > >> Hi Todd, >> >> The table of results should already be sortable by column. Is this >> not working for you? We use the sorttable.js script found at: >> >> http://www.kryogenix.org/code/browser/sorttable/ >> >> This only works if the sorttable.js is in the same directory as the >> index.html that lists the set of warnings (scan-build copies this >> file >> over by default). >> >> Ted >> >> On Jul 7, 2008, at 7:02 AM, Todd Ransom wrote: >> >>> I would like to see the output sorted by source file. For instance, >>> if MyClass.m has 5 memory leaks reported then these leaks should all >>> be next to one another so I don't have to hunt back and forth >>> between files. And/or you could make the table of results sortable >>> by column. >>> >>> Todd Ransom >>> StoryMill & Montage Development >>> Mariner Software >>> >>> >>> >>> >>> On Jul 6, 2008, at 8:28 PM, Ted Kremenek wrote: >>> >>>> >>>> On Jul 4, 2008, at 12:17 AM, Holger Schurig wrote: >>>> >>>>>> dereferences. Beyond improving the precision of the analyzer, >>>>>> improving its output is also high on the todo list. (so any >>>>>> suggestions are welcome!) >>>>> >>>>> Add links to descriptions. E.g., when who first visits this page >>>>> sees "Dead store on ...". I can imagine that only a few people >>>>> know what a dead store actually is. >>>> >>>> Agreed. That's an excellent suggestion. >>>> _______________________________________________ >>>> cfe-dev mailing list >>>> cfe-dev at cs.uiuc.edu >>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev >>> >> >> _______________________________________________ >> 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/20080707/db57cc5e/attachment.html From kremenek at apple.com Mon Jul 7 10:47:39 2008 From: kremenek at apple.com (Ted Kremenek) Date: Mon, 7 Jul 2008 08:47:39 -0700 Subject: [cfe-dev] Static analysis and Adium In-Reply-To: <7EEAEF33-DD70-423C-BB20-0A840B19FAD4@mac.com> References: <4EA3495F-5F81-4D61-B478-F16949A3E18A@gmail.com> <33EE5412-DEAC-4C2A-90FC-DE6304A7DA32@apple.com> <200807040917.01005.hs4233@mail.mn-solutions.de> <413D84B5-FDD1-43BE-A001-792A59B57352@apple.com> <425B2039-37D8-41D3-8E55-FB5605F17E8D@apple.com> <1FA8B02A-EDB4-4F3E-A5A2-B93C7F711B47@apple.com> <7EEAEF33-DD70-423C-BB20-0A840B19FAD4@mac.com> Message-ID: On Jul 7, 2008, at 8:39 AM, Todd Ransom wrote: > No, I was talking about the table produced by the scan-build command > line interface. I see now that it is sortable. It might be nice to > provide some visual indicator of that. The default table sort seems > to be by bug type. If you added a sort indicator to that column by > default it would be more obvious the table is sortable. Thanks for the suggestion Todd! Do you have an idea of what would be a good sort indicator? I do work at Apple, but I'm an analysis guy, not a GUI engineer. I would be happy to put in any changes that make the output easier to use. Best, Ted From toddransom at mac.com Mon Jul 7 10:58:16 2008 From: toddransom at mac.com (Todd Ransom) Date: Mon, 07 Jul 2008 11:58:16 -0400 Subject: [cfe-dev] Static analysis and Adium In-Reply-To: References: <4EA3495F-5F81-4D61-B478-F16949A3E18A@gmail.com> <33EE5412-DEAC-4C2A-90FC-DE6304A7DA32@apple.com> <200807040917.01005.hs4233@mail.mn-solutions.de> <413D84B5-FDD1-43BE-A001-792A59B57352@apple.com> <425B2039-37D8-41D3-8E55-FB5605F17E8D@apple.com> <1FA8B02A-EDB4-4F3E-A5A2-B93C7F711B47@apple.com> <7EEAEF33-DD70-423C-BB20-0A840B19FAD4@mac.com> Message-ID: There is a sort indicator that appears when you click on one of the column headers so you could use that one. I am not an HTML guy, either, so I can't tell where the image is coming from (I don't see it when viewing source). Maybe if you specify a default sort it will show up magically :) Todd Ransom StoryMill & Montage Development Mariner Software On Jul 7, 2008, at 11:47 AM, Ted Kremenek wrote: > > On Jul 7, 2008, at 8:39 AM, Todd Ransom wrote: > >> No, I was talking about the table produced by the scan-build >> command line interface. I see now that it is sortable. It might be >> nice to provide some visual indicator of that. The default table >> sort seems to be by bug type. If you added a sort indicator to that >> column by default it would be more obvious the table is sortable. > > Thanks for the suggestion Todd! Do you have an idea of what would > be a good sort indicator? I do work at Apple, but I'm an analysis > guy, not a GUI engineer. I would be happy to put in any changes > that make the output easier to use. > > Best, > Ted From peter.neumark at gmail.com Mon Jul 7 11:13:23 2008 From: peter.neumark at gmail.com (Peter Neumark) Date: Mon, 7 Jul 2008 18:13:23 +0200 Subject: [cfe-dev] final distributed clang patch Message-ID: <2e837e3a0807070913u449837beue9dfded1180a2ecd@mail.gmail.com> Hi! Here is the final patch for clang to support network distributed compilation. (clang.patch file) There is also the server part attached. (the tar.gz file) There 3 new files added to Driver directory: PrintPreprocessedOutputBuffer.cpp what is a modification of PrintPreprocessedOutput.cpp to support print text to a std::ostream. Other new files: NetSession.h and NetSession.cpp which handles and contains all networking code (portable thin networking code). There are some files changed, mostly to support saving its output to a std::stream. I've used that way to pass clang ASTConsumers data to an other computer via network. There are 3 new option added to clang. The basic one is -distribute what enables distributed compilation. The other two are: -dist-preprocesslocally and -dist-serializelocally. If the first one enabled then clang sends a preprocessed file for clangserver (a process in an other machine) to compile. In the second case the lexing and parsing is done locally and the built and serialized AST is sent to clangserver. You can play with this using -dist-preprocesslocally because it is working. P.S. There is some features left to implement like getting and sending full diagnostics (currently only diagID is sended by clangserver), and handling remote file requests (when clangserver (compile server) requires an include file) But what is currently is implemented is stable and final, there probably will not be big change in this code later. What is your opinion of this ? Cheers, Peter Neumark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080707/2f1eea89/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: clang.patch Type: application/octet-stream Size: 63107 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080707/2f1eea89/attachment-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: clangserver.tar.gz Type: application/x-gzip Size: 6623 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080707/2f1eea89/attachment-0001.gz From nicolasweber at gmx.de Mon Jul 7 11:45:52 2008 From: nicolasweber at gmx.de (Nico Weber) Date: Mon, 7 Jul 2008 18:45:52 +0200 Subject: [cfe-dev] Static analyzer Message-ID: <979A7328-0179-4BA3-B6B4-3EF3D8DB61B8@gmx.de> Hi, I'm currently playing with the static analyzer. It looks very nice, it found a few leaks already. Two comments: 1. It would be very useful to me if the file name of the reports could include the (beginning of) the original file name. When I'm looking at the reports in Safari, I could then simply look at the URL bar to see which file the current report is for. 2. The project I'm checking contains several sections that look like this: const void *bytes = [data bytes]; int rows = *((int*)bytes); bytes += sizeof(int); scan_build complains in these cases that "Value stored to 'bytes' is never read". Nico From eli.friedman at gmail.com Mon Jul 7 12:24:41 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Mon, 7 Jul 2008 10:24:41 -0700 Subject: [cfe-dev] final distributed clang patch In-Reply-To: <2e837e3a0807070913u449837beue9dfded1180a2ecd@mail.gmail.com> References: <2e837e3a0807070913u449837beue9dfded1180a2ecd@mail.gmail.com> Message-ID: On Mon, Jul 7, 2008 at 9:13 AM, Peter Neumark wrote: > Hi! > Here is the final patch for clang to support network distributed > compilation. (clang.patch file) > There is also the server part attached. (the tar.gz file) Okay... I'm not going to try and review the new code, just the modifications to existing code. > There 3 new files added to Driver directory: > PrintPreprocessedOutputBuffer.cpp what is a modification of > PrintPreprocessedOutput.cpp to support print text to a std::ostream. No good; that's a large chunk of code which you're duplicating. Would a callback-based API be a significant performance hit? Otherwise, can you refactor the code to avoid duplication? > Other new files: NetSession.h and NetSession.cpp which handles and contains > all networking code (portable thin networking code). Have you considered separating out the new code into a new directory? I don't think it's a good idea to be mixing this stuff together; it'll make reading the code in the Driver/ directory even more confusing than it is now. And actually, it might be a good idea to shift around some of the existing consumers so that they can be used by outside projects more easily. A lot of the code currently in Driver/, like PrintPreprocessedOutput, the rewriters, and the diagnostic printer, is non-trivial. Anyone have any thoughts on making a "lib/Consumers" or a "lib/ConsumerUtils" directory to make this easier? I know this is something we've been putting off for a while, but it's gotten to the point where it really needs to be done. > There are some files changed, mostly to support saving its output to a > std::stream. I've used that way to pass clang ASTConsumers data to an other > computer via network. I think we want to try and make the APIs of the included ASTConsumers as general as possible. To that end, it might be better to use some sort of callback-based system, rather than having to force everything to use iostream, or having to duplicate code to allow multiple IO systems. (I'm sorry about dragging your work into this architectural discussion, Peter; I don't mean this as a comment on the quality of your work. That said, making the changes to existing code as clean as possible is important, so this needs to be discussed.) -Eli From kremenek at apple.com Mon Jul 7 12:30:17 2008 From: kremenek at apple.com (Ted Kremenek) Date: Mon, 7 Jul 2008 10:30:17 -0700 Subject: [cfe-dev] Static analysis and Adium In-Reply-To: References: <4EA3495F-5F81-4D61-B478-F16949A3E18A@gmail.com> <33EE5412-DEAC-4C2A-90FC-DE6304A7DA32@apple.com> <200807040917.01005.hs4233@mail.mn-solutions.de> <413D84B5-FDD1-43BE-A001-792A59B57352@apple.com> <425B2039-37D8-41D3-8E55-FB5605F17E8D@apple.com> <1FA8B02A-EDB4-4F3E-A5A2-B93C7F711B47@apple.com> <7EEAEF33-DD70-423C-BB20-0A840B19FAD4@mac.com> Message-ID: On Jul 7, 2008, at 8:58 AM, Todd Ransom wrote: > There is a sort indicator that appears when you click on one of the > column headers so you could use that one. I am not an HTML guy, > either, so I can't tell where the image is coming from (I don't see > it when viewing source). Maybe if you specify a default sort it will > show up magically :) Done: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20080707/006406.html This fix will be incorporated in the next checker build. Thanks for the feedback Todd! From kremenek at apple.com Mon Jul 7 13:31:40 2008 From: kremenek at apple.com (Ted Kremenek) Date: Mon, 7 Jul 2008 11:31:40 -0700 Subject: [cfe-dev] Adding title in HTML report In-Reply-To: References: Message-ID: <17F57198-859D-4AE3-8AA3-35674897CA2D@apple.com> Applied: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20080707/006407.html Thanks! On Jul 4, 2008, at 2:14 AM, Jean-Daniel Dupas wrote: > Hello, > > I'm think it may be convenient to update the HTMLRewriter to support > a in the header. > > When I read a static report result page, I have to scroll to the top > of the page to find the file name. If we put the filename into the > html title field, the browser will display it in the window title. > > So I think we can update the HTMLRewriter, > AddHeaderFooterInternalBuiltinCSS method to accept an optional title > string. > > void html::AddHeaderFooterInternalBuiltinCSS(Rewriter& R, unsigned > FileID, const char *title = NULL) > > But after, what is the recommanded way to compose the header. > > will something like this be fine (using a ostringstream) ? I also > attach a patch that implements this change. > > ------------------------------------------------ > std::ostringstream os; > os << "<!doctype html>\n" // Use HTML 5 doctype > "<html>\n<head>\n"; > > if (title) > os << "<title>" << html::EscapeText(title) << "\n"; > > os << "\n\n"; > > // Generate header > R.InsertStrBefore(StartLoc, os.str()); > ------------------------------------------------ > > > > > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From kremenek at apple.com Mon Jul 7 15:05:41 2008 From: kremenek at apple.com (Ted Kremenek) Date: Mon, 7 Jul 2008 13:05:41 -0700 Subject: [cfe-dev] Static analyzer In-Reply-To: <979A7328-0179-4BA3-B6B4-3EF3D8DB61B8@gmx.de> References: <979A7328-0179-4BA3-B6B4-3EF3D8DB61B8@gmx.de> Message-ID: <25E19A35-3601-4193-B64A-45ABCACABC84@apple.com> On Jul 7, 2008, at 9:45 AM, Nico Weber wrote: > Hi, > > I'm currently playing with the static analyzer. It looks very nice, it > found a few leaks already. Two comments: > > 1. It would be very useful to me if the file name of the reports could > include the (beginning of) the original file name. When I'm looking at > the reports in Safari, I could then simply look at the URL bar to see > which file the current report is for. Hi Nico, Today I committed a patch that puts the name of the file with the bug in the title of the report page: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20080707/006407.html This patch should now be available in checker-58 (for those using the prebuilt binaries for Mac OS X). We can also potentially include a fragment of the original source file name in the name of the report-XXX.html file as well. I'm not certain if that is necessary given the patch I mentioned. What do you think? I'm fine with making the change if you feel it would make the tool easier to use. > 2. The project I'm checking contains several sections that look like > this: > > const void *bytes = [data bytes]; > int rows = *((int*)bytes); bytes += sizeof(int); > > scan_build complains in these cases that "Value stored to 'bytes' is > never read". I mocked up a test case, but I couldn't really reproduce this error. If it is no trouble, can you file a Bugzilla report with a reduced test case that exhibits the problem? Filing a Bugzilla report also ensures that a fix eventually goes in, as requests for changes have started queuing up and I don't want to forget this one. Thanks for the feedback! Ted From kremenek at apple.com Mon Jul 7 15:21:14 2008 From: kremenek at apple.com (Ted Kremenek) Date: Mon, 7 Jul 2008 13:21:14 -0700 Subject: [cfe-dev] Static analysis output format In-Reply-To: <8253B101-7F22-41CE-BD00-7EC489709C54@gmail.com> References: <8253B101-7F22-41CE-BD00-7EC489709C54@gmail.com> Message-ID: On Jul 4, 2008, at 2:41 PM, David Smith wrote: > As we've been working through the list of results from static > analysis for Adium it's become increasingly clear that the output > format is introducing some complications. Specifically, each time we > rerun (whether to use an updated version of checker, or to check > against the latest source) it eliminates any metadata that we've built > up around the results, such as which ones were false positives. > Unfortunately, fixing this seems somewhat tricky. The main thing that > would be necessary is a way of identifying results across runs. That > way we can plug this into our automated testing system so each time we > commit it can rerun and say "ok, these ones are known, these ones are > known false positives, and these ones are new" rather than just > "here's a list to re-evaluate". I believe this is a necessary feature, and I think it is one that will take several iterations to get right. > I'm not sure how to come up with some > sort of identifier for issues though. Line numbers probably change too > frequently to be reliable. I suppose a heuristic based on function > name, issue type, file name, and approximate line number might be > fairly accurate. This seems like a very reasonable heuristic. Even eluding the line number might be fine for now. BTW, some of this meta-data can easily be grepped right out of the HTML file. This is exactly what scan-build does to build the index.html file. For example: $ grep BUG report-wEXcKk.html We can easily include other meta-data, such as the function/method name where the bug occurs, an cryptographic hash of the source file (or function) that contained the bug, etc. Aside from your own automatic testing tools, ideally, we want the HTML output that the tool (scan-build) produces to allow users to triage and navigate bugs across runs. This is an important feature, but not immediately high on the priority list. Much of the heavy lifting would probably be done in scan-build (which is currently written in Perl) where the summary HTML pages are generated. Anyone with Perl and HTML knowledge is welcome to provide patches to improve this aspect of the system without basically having any knowledge of how the analyzer works (meta-data embedded in report- XXXXX.html files that is useful for building such features into scan- build could be implemented on demand). Moreover, scan-build can be completely rewritten to provide a more advanced system for triaging bugs if anyone is interested in undertaking such a project. Ted From kremenek at apple.com Mon Jul 7 15:24:51 2008 From: kremenek at apple.com (Ted Kremenek) Date: Mon, 7 Jul 2008 13:24:51 -0700 Subject: [cfe-dev] Static analysis output format In-Reply-To: References: <8253B101-7F22-41CE-BD00-7EC489709C54@gmail.com> Message-ID: On Jul 7, 2008, at 1:21 PM, Ted Kremenek wrote: > This is an important feature, but not > immediately high on the priority list. Much of the heavy lifting > would probably be done in scan-build (which is currently written in > Perl) where the summary HTML pages are generated. BTW, when I mean its not "immediately high on the priority list", I'm referring to my own queue. I'm more than happy to work with others to move this feature along. From nicolasweber at gmx.de Mon Jul 7 15:38:13 2008 From: nicolasweber at gmx.de (Nico Weber) Date: Mon, 7 Jul 2008 22:38:13 +0200 Subject: [cfe-dev] Static analyzer In-Reply-To: <25E19A35-3601-4193-B64A-45ABCACABC84@apple.com> References: <979A7328-0179-4BA3-B6B4-3EF3D8DB61B8@gmx.de> <25E19A35-3601-4193-B64A-45ABCACABC84@apple.com> Message-ID: <68886357-CAFE-476A-80AD-2D1A57752293@gmx.de> Hi, >> 1. It would be very useful to me if the file name of the reports >> could >> include the (beginning of) the original file name. When I'm looking >> at >> the reports in Safari, I could then simply look at the URL bar to see >> which file the current report is for. > > Today I committed a patch that puts the name of the file with the > bug in the title of the report page: > > http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20080707/006407.html > > This patch should now be available in checker-58 (for those using > the prebuilt binaries for Mac OS X). > > We can also potentially include a fragment of the original source > file name in the name of the report-XXX.html file as well. I'm not > certain if that is necessary given the patch I mentioned. What do > you think? I'm fine with making the change if you feel it would > make the tool easier to use. that change is sufficient in my eyes. Thanks :-) >> 2. The project I'm checking contains several sections that look like >> this: >> >> const void *bytes = [data bytes]; >> int rows = *((int*)bytes); bytes += sizeof(int); >> >> scan_build complains in these cases that "Value stored to 'bytes' is >> never read". > > I mocked up a test case, but I couldn't really reproduce this > error. If it is no trouble, can you file a Bugzilla report with a > reduced test case that exhibits the problem? Filing a Bugzilla > report also ensures that a fix eventually goes in, as requests for > changes have started queuing up and I don't want to forget this one. Done: http://llvm.org/bugs/show_bug.cgi?id=2528 Nico From kremenek at apple.com Mon Jul 7 15:44:28 2008 From: kremenek at apple.com (Ted Kremenek) Date: Mon, 7 Jul 2008 13:44:28 -0700 Subject: [cfe-dev] Static analyzer In-Reply-To: <68886357-CAFE-476A-80AD-2D1A57752293@gmx.de> References: <979A7328-0179-4BA3-B6B4-3EF3D8DB61B8@gmx.de> <25E19A35-3601-4193-B64A-45ABCACABC84@apple.com> <68886357-CAFE-476A-80AD-2D1A57752293@gmx.de> Message-ID: <57582617-87AA-4701-B438-8F6D8EB5D6A8@apple.com> On Jul 7, 2008, at 1:38 PM, Nico Weber wrote: >>> >>> 2. The project I'm checking contains several sections that look like >>> this: >>> >>> const void *bytes = [data bytes]; >>> int rows = *((int*)bytes); bytes += sizeof(int); >>> >>> scan_build complains in these cases that "Value stored to 'bytes' is >>> never read". >> >> I mocked up a test case, but I couldn't really reproduce this >> error. If it is no trouble, can you file a Bugzilla report with a >> reduced test case that exhibits the problem? Filing a Bugzilla >> report also ensures that a fix eventually goes in, as requests for >> changes have started queuing up and I don't want to forget this one. > > Done: http://llvm.org/bugs/show_bug.cgi?id=2528 Thanks for filing the bug report. My belief is that the checker is doing the right thing. The warning has to do with the "+=" operation to bytes, not the store to rows. The "+=" increment is essentially: bytes = bytes + sizeof(int); The checker is saying that the new value stored to bytes is never used (and in your test case, it isn't). Could it be the case that the test case doesn't capture the issues that you are seeing? Ted -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080707/8b12fe0f/attachment-0001.html From clattner at apple.com Tue Jul 8 01:41:06 2008 From: clattner at apple.com (Chris Lattner) Date: Mon, 7 Jul 2008 23:41:06 -0700 Subject: [cfe-dev] final distributed clang patch In-Reply-To: <2e837e3a0807070913u449837beue9dfded1180a2ecd@mail.gmail.com> References: <2e837e3a0807070913u449837beue9dfded1180a2ecd@mail.gmail.com> Message-ID: <64292416-CFE9-4349-8543-0DFE7951E31F@apple.com> On Jul 7, 2008, at 9:13 AM, Peter Neumark wrote: > Hi! > Here is the final patch for clang to support network distributed > compilation. (clang.patch file) > There is also the server part attached. (the tar.gz file) Hi Peter, I haven't looked at your patch in detail, but some thoughts in no particular order: 1) it would be very useful to separate and submit the mechanical changes independent from any other changes in your patch. As Eli mentioned, duplicating the -E printer is not acceptable. We should refactor that code into a form acceptable for your work independently of the rest of the patch. 2) It is generally bad form to have headers like NetSession.h #include system-specific stuff (like sys/socket or netinet/in.h) these #includes should move to a .cpp file. I like that you put the system specific code in a platform abstraction layer, it just needs to be a bit tighter. 3) I think we should have a high level discussion about how the new dist-cc implementation integrates with clang. I had envisioned a different *driver* on the client side that shared code but was independent of the clang driver. It doesn't make any sense to distribute many of the things the clang driver does (e.g. -Eonly, -ast- dump, etc). If we can come to a design, I think a number of the changes you made would be unneeded. This would basically amount to your "-dist-preprocesslocally" option, but would be simpler. Once that is working well, more aggressive models can be attempted. 4) It would be good to have some HTML documentation for this, including end-user documentation on how to set it up and use it. This should go in clang/docs. 5) Have you done any timings of this? Thanks for working on this. It is very exciting to see progress on this project! I know a number of people who are very interested in this work, -Chris From clattner at apple.com Tue Jul 8 01:51:24 2008 From: clattner at apple.com (Chris Lattner) Date: Mon, 7 Jul 2008 23:51:24 -0700 Subject: [cfe-dev] Preprocessor::LookNext In-Reply-To: <486D796B.3080906@gmail.com> References: <486D796B.3080906@gmail.com> Message-ID: On Jul 3, 2008, at 6:14 PM, Argiris Kirtzidis wrote: > The "nested-name-specifier '::' " syntax occurs at enough places > that it would really simplify the code if an efficient > Parser::GetLookAheadToken(1) could be used. > > I attached a Preprocessor::LookNext implementation for this (pp- > looknext.patch). > In the "parse-labeled" patch I use LookNext to determine a label and > use a separate Parser::ParseLabeledStatement. Hi Argiris, Is there a specific problem with calling LookAhead(0)? To me, this is a performance optimization tweak... I'd rather do this sort of thing when more of the C++ front-end is in place. This would give us better grounds for profiling and determine whether it is actually a win in the end. Adding a "LookNext()" method to the preprocessor as a helper for LookAhead(0) would be ok if you think it would be significantly useful though. Also, LookAhead could obviously be improved :). Finally, are you sure it would be completely unreasonable to refactor the C++ grammar to avoid the look-ahead in the common case? While always having peektok available is nice, it adds significant cost to the hotest part of the C preprocessor. I would expect a significant slowdown from the patch on large .i files with -Eonly for example (which spends almost all time in this code). -Chris From hs4233 at mail.mn-solutions.de Tue Jul 8 01:54:09 2008 From: hs4233 at mail.mn-solutions.de (Holger Schurig) Date: Tue, 8 Jul 2008 08:54:09 +0200 Subject: [cfe-dev] Static analysis and Adium In-Reply-To: <1FA8B02A-EDB4-4F3E-A5A2-B93C7F711B47@apple.com> References: <4EA3495F-5F81-4D61-B478-F16949A3E18A@gmail.com> <425B2039-37D8-41D3-8E55-FB5605F17E8D@apple.com> <1FA8B02A-EDB4-4F3E-A5A2-B93C7F711B47@apple.com> Message-ID: <200807080854.09627.hs4233@mail.mn-solutions.de> > If anyone is interested in making the tool's output more > polished, patches are certainly welcome. I don't pretend to > be an HTML guru. I'm not actually sure if the analysis tool should produce HTML at all. Maybe you simply produce text or XML as output. People can than write their own tools to make a nice web page out of that, if they prefer. Or if they prefer to use "grep", it would be OK then, too :-) This would allow you to focus on analysis (where you're good at) and let others do the HTML things, if they need it. From wilsonkk at shaw.ca Tue Jul 8 02:15:15 2008 From: wilsonkk at shaw.ca (Kelly Wilson) Date: Tue, 08 Jul 2008 01:15:15 -0600 Subject: [cfe-dev] FW: GSL 'make check' failure Message-ID: <0K3O003CYET9TW00@l-daemon> Hello Matthijs, Actually I just checked and the problem with this bit of code is an unsigned integer value for 'i'. What I previously failed to show in the code snippet was that 'i' is declared as type 'size_t'...which I'm guessing defaults to uint32 in this case. Instead of using 'size_t i;' I replaced it with a signed int and things worked fine. But if I used an unsigned variable then things blew up. Here is a failure table: short pass ushort pass int pass uint fail long pass ulong fail long long pass ulong long fail Unsigned short doesn't blow up???? Hmmmm.... I am compiling using Ubuntu 2.6.24 with a Quad6600 Intel chip and svn llvm/clang. Thanks, K.Wilson P.S. This is not my code. It is the Gnu Scientific Library and it uses some complex pure C (ie. function pointers and macro expansions that make things harder to track). Very nicely written and an interesting testing framework...just difficult to follow through with my quick perusal ;) > For (i=0;i > { > > v->data[2*i] = ATOMIC(N - i); > > v->data[2*i + 1] = ATOMIC(10 * (N - i) + 1); > > }; > > > > fwrite(). > > fclose(). > > free(). I've seen similar free errors after doing out-of-bounds write. Are you sure that data is allocated long enough (2N elements)? Gr. Matthijs From akyrtzi at gmail.com Tue Jul 8 09:28:46 2008 From: akyrtzi at gmail.com (Argiris Kirtzidis) Date: Tue, 08 Jul 2008 07:28:46 -0700 Subject: [cfe-dev] Preprocessor::LookNext In-Reply-To: References: <486D796B.3080906@gmail.com> Message-ID: <4873799E.3090408@gmail.com> Chris Lattner wrote: > Is there a specific problem with calling LookAhead(0)? To me, this is > a performance optimization tweak... I'd rather do this sort of thing > when more of the C++ front-end is in place. This would give us better > grounds for profiling and determine whether it is actually a win in > the end. Yes, it is only a performance optimization tweak; I wanted to find out if it is acceptable to optimize just LookAhead(0) (which, by the way, is currently the only use for LookAhead). > > Adding a "LookNext()" method to the preprocessor as a helper for > LookAhead(0) would be ok if you think it would be significantly useful > though. Also, LookAhead could obviously be improved :). > > [....] While always having peektok available is nice, it adds > significant cost to the hotest part of the C preprocessor. I would > expect a significant slowdown from the patch on large .i files with > -Eonly for example (which spends almost all time in this code). With a slight modification, the PeekedToken check can be avoided for the common case: > void Lex(Token &Result) { > if (CurLexer) > CurLexer->Lex(Result); > else > CurTokenLexer->Lex(Result); > else { > // We have a peeked token that hasn't been consumed yet. > Result = PeekedToken; > ConsumedPeekedToken(); > return; > } > } LookNext would cache CurLexer,CurTokenLexer before setting them to null, and ConsumedPeekedToken would restore them. > are you sure it would be completely unreasonable to refactor the C++ > grammar to avoid the look-ahead in the common case? I'll go ahead with GetLookAhead; after I post a patch and the code is there for reviewing, it will be a lot easier to discuss about this. -Argiris From kremenek at apple.com Tue Jul 8 10:36:35 2008 From: kremenek at apple.com (Ted Kremenek) Date: Tue, 8 Jul 2008 08:36:35 -0700 Subject: [cfe-dev] Static analysis and Adium In-Reply-To: <200807080854.09627.hs4233@mail.mn-solutions.de> References: <4EA3495F-5F81-4D61-B478-F16949A3E18A@gmail.com> <425B2039-37D8-41D3-8E55-FB5605F17E8D@apple.com> <1FA8B02A-EDB4-4F3E-A5A2-B93C7F711B47@apple.com> <200807080854.09627.hs4233@mail.mn-solutions.de> Message-ID: On Jul 7, 2008, at 11:54 PM, Holger Schurig wrote: >> If anyone is interested in making the tool's output more >> polished, patches are certainly welcome. I don't pretend to >> be an HTML guru. > > I'm not actually sure if the analysis tool should produce HTML at > all. Maybe you simply produce text or XML as output. People can > than write their own tools to make a nice web page out of that, > if they prefer. Or if they prefer to use "grep", it would be OK > then, too :-) > > This would allow you to focus on analysis (where you're good at) > and let others do the HTML things, if they need it. The HTML output is generated by HTMLDiagnostics, a subclass of PathDiagnosticClient that appears in the Driver. The analysis engine just knows that it is interacting with a PathDiagnosticClient, and has no knowledge that the reports are being blasted to HTML. This decoupling between presentation of bug reports and the generation of bug reports is intentional so that bug reports can be displayed or processed in multiple ways. If there is interest in doing XML or text output, all one would need to do is implement a new PathDiagnosticClient (and put it in the Driver). Patches welcome! Ted From eli.friedman at gmail.com Tue Jul 8 11:20:29 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Tue, 8 Jul 2008 09:20:29 -0700 Subject: [cfe-dev] FW: GSL 'make check' failure In-Reply-To: <0K3O003CYET9TW00@l-daemon> References: <0K3O003CYET9TW00@l-daemon> Message-ID: On Tue, Jul 8, 2008 at 12:15 AM, Kelly Wilson wrote: > Hello Matthijs, > > Actually I just checked and the problem with this bit of code is an unsigned > integer value for 'i'. > > What I previously failed to show in the code snippet was that 'i' is > declared as type 'size_t'...which I'm guessing defaults to uint32 in this > case. Can you give a reduced testcase, i.e. something that I could actually compile to reproduce the issue? If you have trouble reducing it, the output of clang -E for the whole file would be fine. I'll try to figure it out, but having actual code will make it a lot easier. (That said, this looks a bit similar to a bug I fixed recently; are you updated to trunk?) Another thing that might help is a diff between the output of clang -emit-llvm of the unsigned int version vs the output of clang -emit-llvm for the int version. That would help narrow down the problem. > Instead of using 'size_t i;' I replaced it with a signed int and things > worked fine. But if I used an unsigned variable then things blew up. Here is > a failure table: > > short pass > ushort pass > > int pass > uint fail > > long pass > ulong fail > > long long pass > ulong long fail > > > Unsigned short doesn't blow up???? Hmmmm.... My guess is that's because unsigned short promotes to int. Although, it's not obvious to me why signed vs unsigned would result in different code... -Eli From wilsonkk at shaw.ca Tue Jul 8 13:38:07 2008 From: wilsonkk at shaw.ca (Kelly Wilson) Date: Tue, 08 Jul 2008 12:38:07 -0600 Subject: [cfe-dev] FW: GSL 'make check' failure In-Reply-To: Message-ID: <0K3P005VGAFCEG40@l-daemon> Hello Eli, I am using the newest version of LLVM/clang, as of today. The short does look like it is being promoted...and the 'unsigned short' is promoted to 'signed int' instead of unsigned. I have attached the diff between the 'signed int' and 'unsigned int' versions of the test_complex_binary function when using -emit-llvm. I also attached the complete test_complex_binary function. This is the gist of the diff file: < %cmp = icmp ult i32 %tmp, 1027 ; [#uses=1] --- > %cmp = icmp slt i32 %tmp, 1027 ; [#uses=1] 29c29 < %conv = uitofp i32 %sub to double ; [#uses=1] --- > %conv = sitofp i32 %sub to double ; [#uses=1] So '(un)signed less than' and '(un)signed int to floating point' are the only differences. This function is hard to isolate because of all the macro expansions, so I tried to set up a small test case yesterday, with no luck. Let me know if you can make something of the attached information and if not I will try to isolate something again. Thanks, K.Wilson -----Original Message----- From: Eli Friedman [mailto:eli.friedman at gmail.com] Sent: Tuesday, July 08, 2008 10:20 AM To: Kelly Wilson Cc: cfe-dev at cs.uiuc.edu Subject: Re: [cfe-dev] FW: GSL 'make check' failure On Tue, Jul 8, 2008 at 12:15 AM, Kelly Wilson wrote: > Hello Matthijs, > > Actually I just checked and the problem with this bit of code is an unsigned > integer value for 'i'. > > What I previously failed to show in the code snippet was that 'i' is > declared as type 'size_t'...which I'm guessing defaults to uint32 in this > case. Can you give a reduced testcase, i.e. something that I could actually compile to reproduce the issue? If you have trouble reducing it, the output of clang -E for the whole file would be fine. I'll try to figure it out, but having actual code will make it a lot easier. (That said, this looks a bit similar to a bug I fixed recently; are you updated to trunk?) Another thing that might help is a diff between the output of clang -emit-llvm of the unsigned int version vs the output of clang -emit-llvm for the int version. That would help narrow down the problem. > Instead of using 'size_t i;' I replaced it with a signed int and things > worked fine. But if I used an unsigned variable then things blew up. Here is > a failure table: > > short pass > ushort pass > > int pass > uint fail > > long pass > ulong fail > > long long pass > ulong long fail > > > Unsigned short doesn't blow up???? Hmmmm.... My guess is that's because unsigned short promotes to int. Although, it's not obvious to me why signed vs unsigned would result in different code... -Eli -------------- next part -------------- A non-text attachment was scrubbed... Name: test.uint Type: application/octet-stream Size: 7037 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080708/25f75d2c/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: diff Type: application/octet-stream Size: 785 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080708/25f75d2c/attachment-0001.obj From next_ghost at quick.cz Tue Jul 8 13:55:15 2008 From: next_ghost at quick.cz (Martin Doucha) Date: Tue, 08 Jul 2008 20:55:15 +0200 Subject: [cfe-dev] Best place for semantic checks Message-ID: <4873B813.2080105@quick.cz> Hi, I want to write semantic checker for newbie mistakes/undefined behavior using Clang. Where should I put the code - into Sema module or into a new ASTConsumer module crammed between Sema and other ASTConsumers? Regards, Martin From kremenek at apple.com Tue Jul 8 15:19:45 2008 From: kremenek at apple.com (Ted Kremenek) Date: Tue, 8 Jul 2008 13:19:45 -0700 Subject: [cfe-dev] Best place for semantic checks In-Reply-To: <4873B813.2080105@quick.cz> References: <4873B813.2080105@quick.cz> Message-ID: <0CC29FB7-AAC1-4FB5-9FFB-8030AC87E72C@apple.com> On Jul 8, 2008, at 11:55 AM, Martin Doucha wrote: > Hi, > I want to write semantic checker for newbie mistakes/undefined > behavior > using Clang. Where should I put the code - into Sema module or into a > new ASTConsumer module crammed between Sema and other ASTConsumers? > > Regards, > Martin Hi Martin, You have three options. Put the logic in Sema, create a new ASTConsumer, or use the AnalysisConsumer interface, which was designed explicitly for running different kinds of static analysis checks. If you want your checks committed back to Clang, probably the best place is to use the new AnalysisConsumer interface (so that it hooks in nicely with the other static analysis checks), but it's entirely up to you. Note that the AnalysisConsumer interface is designed to be us If you use the new AnalysisConsumer interface, you will need to make a few small changes to AnalysisConsumer.h, AnalysisConsumer.cpp, and a small place in clang.cpp to hook up your checks to the driver. AnalysisConsumer calls the dead store checker, the memory leak checker, and so on. The actual logic for your checks should go into a separate .cpp file, either in the Driver or in the Analysis library, with a header file included by AnalysisConsumer.cpp to actually invoke the logic of your checks. Eventually, this interface will be further simplified, hopefully obviating the need to modify AnalysisConsumer.h, AnalysisConsumer.cpp, and clang.cpp. Using the AnalysisConsumer interface (or your own ASTConsumer) uses a different code path than code generation, so using that interface means the checks won't be performed when code is compiled using Clang. You can use scan-build/ccc-analyzer, however, to invoke your checker over an entire code base by modifying the clang command line invoked by ccc-analyzer. If your checks prove to be both effective and very quick, this logic could be migrated to Sema. I only suggest hooking it into AnalysisConsumer to start with because the logic is easier to work with than Sema (Sema is doing a lot of things), you get to harness the scan-build checker harness, and adding a new driver option is a snap. More specifically, you need to modify the following to use the AnalysisConsumer interface: -------------------- Driver/AnalysisConsumer.h: Add a new value to the enum Analyses: enum Analyses { CFGDump, CFGView, WarnDeadStores, WarnUninitVals, DisplayLiveVariables, CheckerCFRef, CheckerSimple, MyChecker // <-------------------------- }; -------------------- Driver/AnalysisConsumer.cpp: 1) Add a static "Action" function that calls your checker using the appropriate arguments. static void ActionMyChecker(AnalysisManager& mgr) { // Call the checker using arguments provided by queries to AnalysisManager. ... } 2) Add a case in CreateAnalysisConsumer for your Analysis using the enum value you added to Driver/AnalysisConsumer.h: ASTConsumer* clang::CreateAnalysisConsumer(...) { ... for ( ; Beg != End ; ++Beg) switch (*Beg) { case WarnDeadStores: C->addCodeAction(&ActionDeadStores); break; case WarnUninitVals: C->addCodeAction(&ActionUninitVals); break; // ADD A CASE HERE case MyChecker: C->addCodeAction(&ActionMyChecker); break; -------------------- Driver/Clang.cpp: Add your command line argument to "Analyses" static llvm::cl::list AnalysisList(llvm::cl::desc("Available Source Code Analyses:"), llvm::cl::values( clEnumValN(CFGDump, "cfg-dump", "Display Control-Flow Graphs"), clEnumValN(CFGView, "cfg-view", "View Control-Flow Graphs using GraphViz"), clEnumValN(DisplayLiveVariables, "dump-live-variables", "Print results of live variable analysis"), clEnumValN(WarnDeadStores, "warn-dead-stores", "Flag warnings of stores to dead variables"), clEnumValN(WarnUninitVals, "warn-uninit-values", "Flag warnings of uses of unitialized variables"), clEnumValN(CheckerSimple, "checker-simple", "Perform simple path-sensitive checks."), clEnumValN(CheckerCFRef, "checker-cfref", "Run the [Core] Foundation reference count checker"), clEnumValnN(MyChecker, "my-checker", // <------------------------------------------ "My Custom Checker"), clEnumValEnd)); - Ted From csaba.hruska at gmail.com Tue Jul 8 16:01:29 2008 From: csaba.hruska at gmail.com (Csaba Hruska) Date: Tue, 8 Jul 2008 23:01:29 +0200 Subject: [cfe-dev] take distributed clang project Message-ID: <8914b92d0807081401p1eee82a9vda662a86631de259@mail.gmail.com> Hi! I'm Peter Neumark's friend, and I'd like to continue develop his project. I've talked with him about this. Csaba Hruska -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080708/9f486a44/attachment.html From nunoplopes at sapo.pt Tue Jul 8 16:43:58 2008 From: nunoplopes at sapo.pt (Nuno Lopes) Date: Tue, 8 Jul 2008 22:43:58 +0100 Subject: [cfe-dev] name compatibility with llvm-gcc? Message-ID: Hi, I noticed that struct and union LLVM type names generated by clang and llvm-gcc don't follow the same naming convention, which is causing me some headaches. llvm-gcc uses the following convention: struct.struct_name; struct.union_name while clang uses: struct._struct_name; union._union_name. Can we change clang so that clang respects llvm-gcc's ABI? I would appreciate this change (I'm using clang, while my colleague is using llvm-gcc..). Thanks, Nuno From clattner at apple.com Tue Jul 8 17:11:53 2008 From: clattner at apple.com (Chris Lattner) Date: Tue, 8 Jul 2008 15:11:53 -0700 Subject: [cfe-dev] name compatibility with llvm-gcc? In-Reply-To: References: Message-ID: <489D29BC-9D4B-4B56-9298-151CECF91B21@apple.com> On Jul 8, 2008, at 2:43 PM, Nuno Lopes wrote: > Hi, > > I noticed that struct and union LLVM type names generated by clang and > llvm-gcc don't follow the same naming convention, which is causing > me some > headaches. > llvm-gcc uses the following convention: struct.struct_name; > struct.union_name > while clang uses: struct._struct_name; union._union_name. > > Can we change clang so that clang respects llvm-gcc's ABI? I would > appreciate this change (I'm using clang, while my colleague is using > llvm-gcc..). Sounds fine with me, it should be an easy change. -Chris From clattner at apple.com Tue Jul 8 17:16:18 2008 From: clattner at apple.com (Chris Lattner) Date: Tue, 8 Jul 2008 15:16:18 -0700 Subject: [cfe-dev] take distributed clang project In-Reply-To: <8914b92d0807081401p1eee82a9vda662a86631de259@mail.gmail.com> References: <8914b92d0807081401p1eee82a9vda662a86631de259@mail.gmail.com> Message-ID: On Jul 8, 2008, at 2:01 PM, Csaba Hruska wrote: > Hi! > I'm Peter Neumark's friend, and I'd like to continue develop his > project. Ok, great! Where do you want to start? -Chris From eli.friedman at gmail.com Tue Jul 8 18:03:36 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Tue, 8 Jul 2008 16:03:36 -0700 Subject: [cfe-dev] name compatibility with llvm-gcc? In-Reply-To: References: Message-ID: On Tue, Jul 8, 2008 at 2:43 PM, Nuno Lopes wrote: > Hi, > > I noticed that struct and union LLVM type names generated by clang and > llvm-gcc don't follow the same naming convention, which is causing me some > headaches. > llvm-gcc uses the following convention: struct.struct_name; > struct.union_name > while clang uses: struct._struct_name; union._union_name. Okay... I suppose we could try to follow llvm-gcc's convention. That said, LLVM type names aren't really reliable in the first place, since identical types are merged. And we don't always generate struct types in quite the same way as llvm-gcc (clang generates padding and unions quite differently). > Can we change clang so that clang respects llvm-gcc's ABI? I would > appreciate this change (I'm using clang, while my colleague is using > llvm-gcc..). This has nothing to do with the ABI, and in fact it doesn't affect the code's semantics at all; using the term ABI just confuses the issue. -Eli From kremenek at apple.com Tue Jul 8 18:27:10 2008 From: kremenek at apple.com (Ted Kremenek) Date: Tue, 8 Jul 2008 16:27:10 -0700 Subject: [cfe-dev] final distributed clang patch In-Reply-To: <2e837e3a0807070913u449837beue9dfded1180a2ecd@mail.gmail.com> References: <2e837e3a0807070913u449837beue9dfded1180a2ecd@mail.gmail.com> Message-ID: <535E73ED-491C-49BB-B5B7-E43A0B9B770B@apple.com> Hi Peter, I agree with the comments that Eli and Chris made; the code duplication is something we want to avoid. Eli brought up an excellent point that key pieces of the driver should be factored off to a separate library, and I too have felt this way for some time. I think that even resolving all the various preprocessor and compiler options (e.g., -I, -D, etc.) that is needed to instantiate a Preprocessor should also be factored out of clang.cpp into a separate library. I also agree with Chris's comments that separating the "distcc" driver from a regular clang driver is a good idea. That keeps the distcc implementation simpler, and potentially allows it to be used with multiple compilers (not just clang). I myself was fine with integrating the distcc support directly into the clang driver for a first pass, but because the distcc driver will not use all of the same functionality as the regular clang driver (and obviously do a few things that the regular clang driver does not), the better long term approach is to factor key components of the clang driver into libraries, make clang and distcc-clang separate executables, and simplify the logic for both. One thing that hasn't emerged in this discussion is whether or not the clang distcc should interoperate with the traditional distcc implementation, or (a different but related issue) is whether we should require that the compiler itself be clang. One advantage of a clang-based distcc, independent of using clang to perform compilation, is that clang-distcc can do the source preprocessing itself without forking off a separate process (which is what the traditional distcc implementation does). This seems more like a good step one: build a distcc client that just takes care of preprocessing in-process, and see what kind of speedups you get over forking and preprocessing. Ultimately we're interested in speed and scalability, and small steps like these help guide the design. Interoperability with other compilers doesn't mean we should limit the design of clang-distcc. We can certainly implement special functionality when multiple compiler "workers" are based on clang (e.g., serializing ASTs, special caching, etc.). I like the concept of the NetSession class, although the issue of interoperability with existing distcc implementations is something that is worth discussing. Chris is right that the system-specific APIs, such as the use of sockets, should not be in header files. A PIMPL approach, like what we use for FileManager, would probably work well (where the system-specific stuff only appears in the .cpp file). As for the clang server, both pthreads and sockets are system-specific APIs. We'll want a design that keeps the threading modeling separate from the code that processes a unit of work. This will allow us to tailor the implementation to use the best parallel computing primitives that are available on a specific architecture. I'm also a little confused with the overall design. It looks like a client (a 'clang' process) connects to a server, sends the preprocessed source to the server, waits for the server to chew on the file, gets the processed output from the server, and then writes the output to disk. It appears that the client attempts to connect to different servers in a serial fashion, and then picks the first available server. Is this how traditional distcc works? (I actually don't know) It's a simple design, but it doesn't amend itself well to good load balancing as well as reducing the latencies in firing off compilation jobs (a bunch of connection attempts in serial fashion seems potentially disastrous for performance). This particular point isn't a criticism of your patch; what's there is fine to get things started. I'm not a distributed computing expert, but something akin to the Google MapReduce system (which has workers and controllers) seems more flexible for fault tolerance, load balancing, and so forth. This is certainly something worth discussing in a higher-level discussion of the overall design of the system. A few comments inline. On Jul 7, 2008, at 9:13 AM, Peter Neumark wrote: > Here is the final patch for clang to support network distributed > compilation. (clang.patch file) > There is also the server part attached. (the tar.gz file) Like the client, the server shouldn't have so much code copied from the Driver, and it certainly doesn't need to use all of the ASTConsumers in the regular Clang driver. General work (by anyone who is interested) on modularizing the driver will help make this much easier. > There 3 new files added to Driver directory: > PrintPreprocessedOutputBuffer.cpp what is a modification of > PrintPreprocessedOutput.cpp to support print text to a std::ostream. I'm not certain why a separate version of PrintPreprocessedOutput was necessary. iostreams are slow, and writing to sockets using the FILE* abstraction is perfectly acceptable (via fdopen()). > Other new files: NetSession.h and NetSession.cpp which handles and > contains all networking code (portable thin networking code). > There are some files changed, mostly to support saving its output to > a std::stream. I've used that way to pass clang ASTConsumers data to > an other computer via network. > > There are 3 new option added to clang. The basic one is -distribute > what enables distributed compilation. The other two are: -dist- > preprocesslocally and -dist-serializelocally. > If the first one enabled then clang sends a preprocessed file for > clangserver (a process in an other machine) to compile. In the > second case the lexing and parsing is done locally and the built and > serialized AST is sent to clangserver. > > You can play with this using -dist-preprocesslocally because it is > working. Overall, I think this a good initial start! I think that next logical steps would be to look at both overall design as well as issues of code structure (addressing the comments on modularity, isolating various implementation details, etc.). Getting a few interesting performance timings would also be extremely useful to help shape some of those design decisions. Incidentally, how well does the code work when the two processes (client and server) are on actually two different machines? Right now, the client always connects to "localhost". Getting performance timings when both client and server are on the same and different machines is also interesting to see how much things like network latency, etc., are a factor in the design. There may also be some correctness issues that are masked by having the client on server on the same machine. Ted From eli.friedman at gmail.com Tue Jul 8 20:08:55 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Tue, 8 Jul 2008 18:08:55 -0700 Subject: [cfe-dev] FW: GSL 'make check' failure In-Reply-To: <0K3P005VGAFCEG40@l-daemon> References: <0K3P005VGAFCEG40@l-daemon> Message-ID: On Tue, Jul 8, 2008 at 11:38 AM, Kelly Wilson wrote: > Hello Eli, > > I am using the newest version of LLVM/clang, as of today. The short does > look like it is being promoted...and the 'unsigned short' is promoted to > 'signed int' instead of unsigned. > > I have attached the diff between the 'signed int' and 'unsigned int' > versions of the test_complex_binary function when using -emit-llvm. I also > attached the complete test_complex_binary function. [snip] > So '(un)signed less than' and '(un)signed int to floating point' are the > only differences. > > This function is hard to isolate because of all the macro expansions, so I > tried to set up a small test case yesterday, with no luck. Let me know if > you can make something of the attached information and if not I will try to > isolate something again. > > Thanks, > K.Wilson Mmm... I'll have to work on this a bit more. I actually tried compiling gsl myself; I ran into a bug with LLVM codegen for fabs, but that doesn't look like the issue you're running into. Everything seems to work after hacking around that issue. That said, I compiled with optimizations turned off (llvm-ld -disable-opt); your issue might actually be caused by an LLVM optimization pass. -Eli From wilsonkk at shaw.ca Tue Jul 8 20:31:21 2008 From: wilsonkk at shaw.ca (Kelly Wilson) Date: Tue, 08 Jul 2008 19:31:21 -0600 Subject: [cfe-dev] FW: GSL 'make check' failure In-Reply-To: Message-ID: <0K3P00F9YTK26A60@l-daemon> Hello Eli, Yep, it is one of the optimizations for llvm-ld because everything is fine when I turn them off :( And we know it is a problem with the LLVM codegen because everything works fine when using -native-cbe. Thanks, K.Wilson -----Original Message----- From: Eli Friedman [mailto:eli.friedman at gmail.com] Sent: Tuesday, July 08, 2008 7:09 PM To: Kelly Wilson Cc: cfe-dev at cs.uiuc.edu Subject: Re: [cfe-dev] FW: GSL 'make check' failure On Tue, Jul 8, 2008 at 11:38 AM, Kelly Wilson wrote: >Mmm... I'll have to work on this a bit more. I actually tried >compiling gsl myself; I ran into a bug with LLVM codegen for fabs, but >that doesn't look like the issue you're running into. Everything seems >to work after hacking around that issue. >That said, I compiled with optimizations turned off (llvm-ld >-disable-opt); your issue might actually be caused by an LLVM >optimization pass. -Eli From clattner at apple.com Tue Jul 8 21:42:18 2008 From: clattner at apple.com (Chris Lattner) Date: Tue, 8 Jul 2008 19:42:18 -0700 Subject: [cfe-dev] Preprocessor::LookNext In-Reply-To: <4873799E.3090408@gmail.com> References: <486D796B.3080906@gmail.com> <4873799E.3090408@gmail.com> Message-ID: <323C537C-76DC-4675-A1A6-B3ABB4240DA0@apple.com> On Jul 8, 2008, at 7:28 AM, Argiris Kirtzidis wrote: > Chris Lattner wrote: >> Is there a specific problem with calling LookAhead(0)? To me, this >> is a performance optimization tweak... I'd rather do this sort of >> thing when more of the C++ front-end is in place. This would give >> us better grounds for profiling and determine whether it is >> actually a win in the end. > > Yes, it is only a performance optimization tweak; I wanted to find > out if it is acceptable to optimize just LookAhead(0) (which, by the > way, is currently the only use for LookAhead). Ok. >> [....] While always having peektok available is nice, it adds >> significant cost to the hotest part of the C preprocessor. I would >> expect a significant slowdown from the patch on large .i files with >> -Eonly for example (which spends almost all time in this code). > > With a slight modification, the PeekedToken check can be avoided for > the common case: > >> void Lex(Token &Result) { >> if (CurLexer) >> CurLexer->Lex(Result); >> else if (CurTokenLexer) >> CurTokenLexer->Lex(Result); >> else { >> // We have a peeked token that hasn't been consumed yet. >> Result = PeekedToken; >> ConsumedPeekedToken(); >> return; >> } >> } > > LookNext would cache CurLexer,CurTokenLexer before setting them to > null, and ConsumedPeekedToken would restore them. I like this approach about 10 times better than the other one :) it is very clever and simple! The good thing about this is that it is an easy thing to measure. Can you whip up a patch that implements this approach? I don't think it will have a measurable performance impact on the preprocessor (unlike the other approach). If so, I would be very happy to commit it and simplify the (existing and future) parser to use it. -Chris From eli.friedman at gmail.com Wed Jul 9 00:33:05 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Tue, 8 Jul 2008 22:33:05 -0700 Subject: [cfe-dev] FW: GSL 'make check' failure In-Reply-To: <0K3P00F9YTK26A60@l-daemon> References: <0K3P00F9YTK26A60@l-daemon> Message-ID: On Tue, Jul 8, 2008 at 6:31 PM, Kelly Wilson wrote: > Hello Eli, > > Yep, it is one of the optimizations for llvm-ld because everything is fine > when I turn them off :( Found it; filed http://llvm.org/bugs/show_bug.cgi?id=2535. -Eli From devlists at shadowlab.org Wed Jul 9 03:25:30 2008 From: devlists at shadowlab.org (Jean-Daniel Dupas) Date: Wed, 9 Jul 2008 10:25:30 +0200 Subject: [cfe-dev] Static analysis and Adium In-Reply-To: References: <4EA3495F-5F81-4D61-B478-F16949A3E18A@gmail.com> <425B2039-37D8-41D3-8E55-FB5605F17E8D@apple.com> <1FA8B02A-EDB4-4F3E-A5A2-B93C7F711B47@apple.com> <200807080854.09627.hs4233@mail.mn-solutions.de> Message-ID: <48ACAB0A-51F9-4B29-919B-FF8C29840277@shadowlab.org> Le 8 juil. 08 ? 17:36, Ted Kremenek a ?crit : > > On Jul 7, 2008, at 11:54 PM, Holger Schurig wrote: > >>> If anyone is interested in making the tool's output more >>> polished, patches are certainly welcome. I don't pretend to >>> be an HTML guru. >> >> I'm not actually sure if the analysis tool should produce HTML at >> all. Maybe you simply produce text or XML as output. People can >> than write their own tools to make a nice web page out of that, >> if they prefer. Or if they prefer to use "grep", it would be OK >> then, too :-) >> >> This would allow you to focus on analysis (where you're good at) >> and let others do the HTML things, if they need it. > > The HTML output is generated by HTMLDiagnostics, a subclass of > PathDiagnosticClient that appears in the Driver. The analysis engine > just knows that it is interacting with a PathDiagnosticClient, and has > no knowledge that the reports are being blasted to HTML. This > decoupling between presentation of bug reports and the generation of > bug reports is intentional so that bug reports can be displayed or > processed in multiple ways. > > If there is interest in doing XML or text output, all one would need > to do is implement a new PathDiagnosticClient (and put it in the > Driver). > > Patches welcome! > > Ted I'm gonna works on an XML output. Is someone interested to do such thing too ? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080709/415da29a/attachment-0001.bin From nikita at zhuk.fi Wed Jul 9 03:49:26 2008 From: nikita at zhuk.fi (Nikita Zhuk) Date: Wed, 9 Jul 2008 11:49:26 +0300 Subject: [cfe-dev] A tool for generating reduced headers for test cases (delta debugging) Message-ID: <80EC12FA-D4B8-4B87-B819-09E6D2A13AD0@zhuk.fi> Hi, Several clang analysis test cases written in ObjC contain the following comment line in their header: "These declarations were reduced using Delta-Debugging from Foundation.h on Mac OS X.". Are there some instructions about tools which should be used to generate such reduced headers? Being able to do so would make it possible to report bugs by using runnable test cases, and those test cases could be eventually included with the clang itself. From nunoplopes at sapo.pt Wed Jul 9 06:18:58 2008 From: nunoplopes at sapo.pt (Nuno Lopes) Date: Wed, 9 Jul 2008 12:18:58 +0100 Subject: [cfe-dev] name compatibility with llvm-gcc? In-Reply-To: <489D29BC-9D4B-4B56-9298-151CECF91B21@apple.com> References: <489D29BC-9D4B-4B56-9298-151CECF91B21@apple.com> Message-ID: <842D6FE2AFA147BD9398C0844F7F7B44@pc07654> >> I noticed that struct and union LLVM type names generated by clang and >> llvm-gcc don't follow the same naming convention, which is causing me >> some >> headaches. >> llvm-gcc uses the following convention: struct.struct_name; >> struct.union_name >> while clang uses: struct._struct_name; union._union_name. >> >> Can we change clang so that clang respects llvm-gcc's ABI? I would >> appreciate this change (I'm using clang, while my colleague is using >> llvm-gcc..). > > Sounds fine with me, it should be an easy change. Arg, actually my analysis was wrong. The problem is that function decls save the canonical type. E.g.: typedef struct _zend_op_array zend_op_array; struct _zend_op_array { ... }; zend_op_array *foo() { return 0; } When codegening the function foo I get the 'struct _zend_op_array', instead of zend_op_array. This is the reason why I was getting the 'struct._struct_name' style names. So this problem isn't that easy to "fix". It would require saving the non-canonical type instead of the canonic one (that I think you don't want to do?). > > Can we change clang so that clang respects llvm-gcc's ABI? I would > > appreciate this change (I'm using clang, while my colleague is using > > llvm-gcc..). > > This has nothing to do with the ABI, and in fact it doesn't affect the > code's semantics at all; using the term ABI just confuses the issue. I called it ABI just in the sense that I wanted to link code generated by the 2 different frontends. I need to fill in structures at runtime that were compiled with either llvm-gcc or clang (I need a StructType* out of a name). Anyway just forget the ABI thing.. :) Nuno From csaba.hruska at gmail.com Wed Jul 9 07:14:05 2008 From: csaba.hruska at gmail.com (Csaba Hruska) Date: Wed, 9 Jul 2008 14:14:05 +0200 Subject: [cfe-dev] final distributed clang patch In-Reply-To: <535E73ED-491C-49BB-B5B7-E43A0B9B770B@apple.com> References: <2e837e3a0807070913u449837beue9dfded1180a2ecd@mail.gmail.com> <535E73ED-491C-49BB-B5B7-E43A0B9B770B@apple.com> Message-ID: <8914b92d0807090514w74383686o7101d4c63372832f@mail.gmail.com> Hi! Here are the cutted patch files of indepenent changes: TranslationUnit.patch - adds support (de)serialization (from)to (in memory) buffer. Preprocessor.patch - adds a new method (getPredefines) needed for passing predefines list to clangserver. ASTConsumers.patch - adds functions what supports capruing ASTConsumer's output. I haven't attached clang.cpp, clang.h NetSession.cpp, NetSession.h patch because they place in source structure is unknown. We have to refactor the Driver directory content first. distclang and clangserver requirements (needs redesign or cleanup): - ASTConsumer library - system headers and defines setup and target setup library (all target dependent stuff) - capture output of PrintPreprocessedOutput.cpp. Ted: openfd is not acceptable, because we have to know the output size before we send it. (required by net packet header) - platform independent thread and network support. Should these added to llvm/Support or System library ? We also have to decide if we want to be distcc compatible or not. And what's the benefit of distcc compatibility? I've also attached a skeleton of distclang documentation page (no info yet, it will be added after the initial commit). Cheers, Csaba Hruska -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080709/da5cae9c/attachment-0002.html -------------- next part -------------- A non-text attachment was scrubbed... Name: TranslationUnit.patch Type: text/x-diff Size: 5198 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080709/da5cae9c/attachment-0003.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: Preprocessor.patch Type: text/x-diff Size: 570 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080709/da5cae9c/attachment-0004.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ASTConsumers.patch Type: text/x-diff Size: 6662 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080709/da5cae9c/attachment-0005.bin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080709/da5cae9c/attachment-0003.html From eli.friedman at gmail.com Wed Jul 9 11:16:28 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Wed, 9 Jul 2008 09:16:28 -0700 Subject: [cfe-dev] A tool for generating reduced headers for test cases (delta debugging) In-Reply-To: <80EC12FA-D4B8-4B87-B819-09E6D2A13AD0@zhuk.fi> References: <80EC12FA-D4B8-4B87-B819-09E6D2A13AD0@zhuk.fi> Message-ID: On Wed, Jul 9, 2008 at 1:49 AM, Nikita Zhuk wrote: > Hi, > > Several clang analysis test cases written in ObjC contain the > following comment line in their header: "These declarations were > reduced using Delta-Debugging from Foundation.h on Mac OS X.". Are > there some instructions about tools which should be used to generate > such reduced headers? If I'm not mistaken, the steps are just to generate a full file with clang -E, then reduce the file using Delta (http://delta.tigris.org/). But Ted should be able to comment with more complete steps. > Being able to do so would make it possible to > report bugs by using runnable test cases, and those test cases could > be eventually included with the clang itself. Reducing out Foundation.h only really helps for non-runnable testcases; the presence of Foundation.h is a pretty good indicator of the presence of the Foundation classes. :) -Eli From kremenek at apple.com Wed Jul 9 11:46:42 2008 From: kremenek at apple.com (Ted Kremenek) Date: Wed, 9 Jul 2008 09:46:42 -0700 Subject: [cfe-dev] A tool for generating reduced headers for test cases (delta debugging) In-Reply-To: References: <80EC12FA-D4B8-4B87-B819-09E6D2A13AD0@zhuk.fi> Message-ID: <9ACE8734-E225-4E1C-BE53-F8BD55B3406A@apple.com> On Jul 9, 2008, at 9:16 AM, Eli Friedman wrote: > On Wed, Jul 9, 2008 at 1:49 AM, Nikita Zhuk wrote: >> Hi, >> >> Several clang analysis test cases written in ObjC contain the >> following comment line in their header: "These declarations were >> reduced using Delta-Debugging from Foundation.h on Mac OS X.". Are >> there some instructions about tools which should be used to generate >> such reduced headers? > > If I'm not mistaken, the steps are just to generate a full file with > clang -E, then reduce the file using Delta (http://delta.tigris.org/). > But Ted should be able to comment with more complete steps. That's exactly right. The Delta tool requires a user-provided script that discerns a "test case" between good and bad, and tries to remove pieces from the test case (which is any text file) until a minimal test case is generated that is still "good". In the case of header file reduction, I'm working with two files: t.i (the preprocessed header goop that I want to reduce) t.c (the file that includes t.i) The "test case" is t.i, and the my script (called "detect_error.pl") classifies a version of t.i as good or bad by doing the following: 1) If "gcc -fsyntax-only t.c" fails, the test case is BAD. 2) if "clang -fsyntax-only t.c" fails, the case is BAD. 3) Otherwise, the test case is GOOD. The trick is identifying what is failure: gcc emiting warnings, gcc or clang crashing, etc. Delta-debugging then whittles down t.i until it cannot make it any smaller. Once it reduces t.i, I just include the contents of t.i inside t.c (or t.m, or whatever). >> Being able to do so would make it possible to >> report bugs by using runnable test cases, and those test cases could >> be eventually included with the clang itself. I can certainly clean up the detect_error.pl script and post it the website with directions. > Reducing out Foundation.h only really helps for non-runnable > testcases; the presence of Foundation.h is a pretty good indicator of > the presence of the Foundation classes. :) Exactly. In general, header reduction might be good for filing any kind of test case against Clang that depends on system/library- specific APIs. From kremenek at apple.com Wed Jul 9 12:04:57 2008 From: kremenek at apple.com (Ted Kremenek) Date: Wed, 9 Jul 2008 10:04:57 -0700 Subject: [cfe-dev] Static analysis and Adium In-Reply-To: <48ACAB0A-51F9-4B29-919B-FF8C29840277@shadowlab.org> References: <4EA3495F-5F81-4D61-B478-F16949A3E18A@gmail.com> <425B2039-37D8-41D3-8E55-FB5605F17E8D@apple.com> <1FA8B02A-EDB4-4F3E-A5A2-B93C7F711B47@apple.com> <200807080854.09627.hs4233@mail.mn-solutions.de> <48ACAB0A-51F9-4B29-919B-FF8C29840277@shadowlab.org> Message-ID: On Jul 9, 2008, at 1:25 AM, Jean-Daniel Dupas wrote: >> >> The HTML output is generated by HTMLDiagnostics, a subclass of >> PathDiagnosticClient that appears in the Driver. The analysis engine >> just knows that it is interacting with a PathDiagnosticClient, and >> has >> no knowledge that the reports are being blasted to HTML. This >> decoupling between presentation of bug reports and the generation of >> bug reports is intentional so that bug reports can be displayed or >> processed in multiple ways. >> >> If there is interest in doing XML or text output, all one would need >> to do is implement a new PathDiagnosticClient (and put it in the >> Driver). >> >> Patches welcome! >> >> Ted > > I'm gonna works on an XML output. Is someone interested to do such > thing too ? Hi Jean-Daniel, That's great! BTW, the PathDiagnosticClient is an evolving interface, and I'm completely fine with modifying it to make the world a better place. I'll make some changes to the Driver to make it easier to hook up different PathDiagnosticClients to AnalysisConsumer (the ASTConsumer that drives the different static analysis passes) besides just the current HTMLDiagnostics. Ted From akyrtzi at gmail.com Wed Jul 9 12:17:48 2008 From: akyrtzi at gmail.com (Argiris Kirtzidis) Date: Wed, 09 Jul 2008 10:17:48 -0700 Subject: [cfe-dev] Preprocessor::LookNext In-Reply-To: <323C537C-76DC-4675-A1A6-B3ABB4240DA0@apple.com> References: <486D796B.3080906@gmail.com> <4873799E.3090408@gmail.com> <323C537C-76DC-4675-A1A6-B3ABB4240DA0@apple.com> Message-ID: <4874F2BC.5000504@gmail.com> Chris Lattner wrote: > > I like this approach about 10 times better than the other one :) it is > very clever and simple! The good thing about this is that it is an > easy thing to measure. Can you whip up a patch that implements this > approach? I don't think it will have a measurable performance impact > on the preprocessor (unlike the other approach). If so, I would be > very happy to commit it and simplify the (existing and future) parser > to use it. The attached "pp-looknext-2.patch" implements Preprocessor::LookNext(), and "parser-nexttoken.patch" modifies the parser to use it. Let me know if they look ok, with no performance impact. -Argiris -------------- next part -------------- A non-text attachment was scrubbed... Name: parser-nexttoken.patch Type: text/x-diff Size: 11078 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080709/867ed13d/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: pp-looknext-2.patch Type: text/x-diff Size: 2781 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080709/867ed13d/attachment-0001.bin From clattner at apple.com Wed Jul 9 13:05:56 2008 From: clattner at apple.com (Chris Lattner) Date: Wed, 9 Jul 2008 11:05:56 -0700 Subject: [cfe-dev] Unravelling i-c-e + the gnu mess Message-ID: <2A4A05CE-D13A-4617-B8D1-B4C3B563927A@apple.com> Ok, I'm preparing to do battle with Expr::isIntegerConstantExpr and want to consult the guru's to see if this is a sane plan. :) Problem statement: 1) we want to support fully conformant C code with GNU extensions disabled. 2) We want to support GNU extensions, but emit ext-warns when they are used. 3) If a subexpr is a GNU ice, we don't want to emit warnings multiple times in the subexpr. The canonical horrible example would be test/Sema/darwin-align-cast.c This same problem occurs with both i-c-e's and c-e's, but I'm only going to poke at i-c-e's now. My proposed fix is: 1. Introduce a new static function in Expr.cpp, something like this: static unsigned isIntegerConstExprHelper(const Expr *E, llvm::APSInt &Result, ASTContext &Ctx, SourceLocation &Loc, bool isEvaluated, bool AllowGNU); When AllowGNU is false, it evaluates the expr for i-c-e'ness strictly by the language standard indicated by ASTContext. If the expr *is* an ICE, it returns zero and fills in Result. If it is not an ICE, it puts a caret position in "Loc" and returns a diag # to issue that explains why not. When AllowGNU is true, it does the same, but 1) allows GNU craziness and 2) allows Expr to have pointer type (which is part of gnu craziness I suppose). 2. Change Expr::isIntegerConstantExpr to be something like this: // See if this expr is a real i-c-e. unsigned Diag = isIntegerConstExprHelper(this, ..., false) if (Diag == 0) return true; // See if it is a gnu one. if (!LangOptions.NoExtensions) { if (isIntegerConstExprHelper(this, ..., false) == 0) { Emit Warning about using GNU i-c-e. return true; } } return false; 3. Change Expr::isIntegerConstantExpr to return the diag reason up to its callers so they can emit more specific diags in some cases. Does this seem like a reasonable approach? -Chris From dpatel at apple.com Wed Jul 9 13:32:22 2008 From: dpatel at apple.com (Devang Patel) Date: Wed, 9 Jul 2008 11:32:22 -0700 Subject: [cfe-dev] A tool for generating reduced headers for test cases (delta debugging) In-Reply-To: <80EC12FA-D4B8-4B87-B819-09E6D2A13AD0@zhuk.fi> References: <80EC12FA-D4B8-4B87-B819-09E6D2A13AD0@zhuk.fi> Message-ID: <6739AE68-2D1E-4B70-BECC-1CF6678C6F9B@apple.com> On Jul 9, 2008, at 1:49 AM, Nikita Zhuk wrote: > Hi, > > Several clang analysis test cases written in ObjC contain the > following comment line in their header: "These declarations were > reduced using Delta-Debugging from Foundation.h on Mac OS X.". Are > there some instructions about tools which should be used to generate > such reduced headers? Being able to do so would make it possible to > report bugs by using runnable test cases, and those test cases could > be eventually included with the clang itself. Here is a small guide to use delta to reduce test cases. The guide is GCC specific but you can use it to understand how to use delta to reduce clang test cases. http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction - Devang From nunoplopes at sapo.pt Wed Jul 9 13:55:37 2008 From: nunoplopes at sapo.pt (Nuno Lopes) Date: Wed, 9 Jul 2008 19:55:37 +0100 Subject: [cfe-dev] A tool for generating reduced headers for test cases(delta debugging) In-Reply-To: References: <80EC12FA-D4B8-4B87-B819-09E6D2A13AD0@zhuk.fi> Message-ID: > On Wed, Jul 9, 2008 at 1:49 AM, Nikita Zhuk wrote: >> Hi, >> >> Several clang analysis test cases written in ObjC contain the >> following comment line in their header: "These declarations were >> reduced using Delta-Debugging from Foundation.h on Mac OS X.". Are >> there some instructions about tools which should be used to generate >> such reduced headers? > > If I'm not mistaken, the steps are just to generate a full file with > clang -E, then reduce the file using Delta (http://delta.tigris.org/). > But Ted should be able to comment with more complete steps. I'm not Ted :), but I've attached 2 script that I regularly use. I have more, which have other combinations. For example, imagine you want to reduce a test case that crashes clang. After the preprocessing, you would run (several times): multidelta -level=x ./crash_clang a.c the level (x) is a number between e.g. 0 and 10. Check the delta manual for how to best pick up a number. Now suppose clang triggers a error that gcc does not. Then you can use the clang_error script (provided you changed it to grep for your specific error). Nuno -------------- next part -------------- A non-text attachment was scrubbed... Name: clang_error Type: application/octet-stream Size: 319 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080709/ed7fb96a/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: crash_clang Type: application/octet-stream Size: 231 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080709/ed7fb96a/attachment-0001.obj From clattner at apple.com Wed Jul 9 15:41:37 2008 From: clattner at apple.com (Chris Lattner) Date: Wed, 9 Jul 2008 13:41:37 -0700 Subject: [cfe-dev] Preprocessor::LookNext In-Reply-To: <4874F2BC.5000504@gmail.com> References: <486D796B.3080906@gmail.com> <4873799E.3090408@gmail.com> <323C537C-76DC-4675-A1A6-B3ABB4240DA0@apple.com> <4874F2BC.5000504@gmail.com> Message-ID: <3A358899-A6D5-42B9-BDB4-FBC6E61B7ED4@apple.com> On Jul 9, 2008, at 10:17 AM, Argiris Kirtzidis wrote: > Chris Lattner wrote: >> >> I like this approach about 10 times better than the other one :) it >> is very clever and simple! The good thing about this is that it is >> an easy thing to measure. Can you whip up a patch that implements >> this approach? I don't think it will have a measurable performance >> impact on the preprocessor (unlike the other approach). If so, I >> would be very happy to commit it and simplify the (existing and >> future) parser to use it. > > The attached "pp-looknext-2.patch" implements > Preprocessor::LookNext(), and "parser-nexttoken.patch" modifies the > parser to use it. > > Let me know if they look ok, with no performance impact. The difference is *just barely* measurable in my -Eonly worst case. It is close enough and good enough to go in, thanks! Some comments about the patch (pp first): + + /// PeekedToken - Cache the token that was retrieved through LookNext(). + Token PeekedToken; Please mention in the comment that this is usually not valid, when invalid the location is set to invalid. + /// LookNext - Returns the next token that would be returned by Lex() without + /// consuming it. + Token LookNext() { This can return the token by const&. + if (PeekedToken.getLocation().isInvalid()) { + // We don't have a peeked token that hasn't been consumed yet. + // Peek it now. + Lex(PeekedToken); + // Cache the current Lexer, TokenLexer and set them both to null. + // When Lex() is called, PeekedToken will be "consumed". + IncludeMacroStack.push_back(IncludeStackInfo(CurLexer, CurDirLookup, + CurTokenLexer)); + CurLexer = 0; + CurTokenLexer = 0; + } Please move the body of this 'if' out of line. + /// ConsumedPeekedToken - Called when Lex() is about to return the PeekedToken + /// and have it "consumed". + void ConsumedPeekedToken() { + assert(PeekedToken.getLocation().isValid() && "Confused Peeking?"); + // Restore CurLexer, TokenLexer. + RemoveTopOfLexerStack(); + PeekedToken.startToken(); + } Please move this out of line also. +++ lib/Lex/PPLexerChange.cpp (working copy) @@ -85,6 +85,10 @@ // size we new to a multiple of 16 tokens. If the previous buffer has space // left, we can just grow it. This means we only have to do the new 1/16th as // often. + + // Optimized LookAhead(0) case. + if (N == 0) + return LookNext(); Token *LookaheadTokens = new Token[N+1]; Is this correct for the LookAhead(1) case? Parser change: + /// NextToken - This peeks ahead one token and returns it without + /// consuming it. + Token NextToken() { Should also return via const&. Otherwise, the parser change looks great, a major simplification! -Chris From kremenek at apple.com Wed Jul 9 16:35:27 2008 From: kremenek at apple.com (Ted Kremenek) Date: Wed, 9 Jul 2008 14:35:27 -0700 Subject: [cfe-dev] A tool for generating reduced headers for test cases (delta debugging) In-Reply-To: <9ACE8734-E225-4E1C-BE53-F8BD55B3406A@apple.com> References: <80EC12FA-D4B8-4B87-B819-09E6D2A13AD0@zhuk.fi> <9ACE8734-E225-4E1C-BE53-F8BD55B3406A@apple.com> Message-ID: <17600DC9-1404-4E5A-8700-F94772968384@apple.com> On Jul 9, 2008, at 9:46 AM, Ted Kremenek wrote: >>> Being able to do so would make it possible to >>> report bugs by using runnable test cases, and those test cases could >>> be eventually included with the clang itself. > > I can certainly clean up the detect_error.pl script and post it the > website with directions. Here is my scripts to add to the pile. Once must change the source file in "detect_error.pl" (this is the source that includes the header to be reduced) while "reduce.pl" takes as an argument the preprocessed header you want to reduce (this file is included by the source file). Both scripts rely on the delta-debugging scripts being in your path. -------------- next part -------------- A non-text attachment was scrubbed... Name: detect_error.pl Type: text/x-perl-script Size: 1323 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080709/c6a0c392/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: reduce.pl Type: text/x-perl-script Size: 331 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080709/c6a0c392/attachment-0001.bin -------------- next part -------------- I also saw that Nuno posted some scripts. Hopefully from all these scripts you'll find something that works for you. If these scripts prove useful, we should post them to the Clang website. From emilmont at gmail.com Wed Jul 9 17:41:50 2008 From: emilmont at gmail.com (Emilio Monti) Date: Wed, 9 Jul 2008 23:41:50 +0100 Subject: [cfe-dev] Static Analyzer Message-ID: <68b1f7640807091541k1b934a72l11d630cd179fcf4d@mail.gmail.com> Hi, I tried running scan-build wrapping a make building a simple test ANSI C application full of clear bugs (memory leaks, null pointer dereferencing, etc), but I always end up with: scan-build: No bugs found. Is it a problem of my build/configuration? Which type of bugs can be detected with the current static analyzer? I tried looking for this type of information, but I found only Objective C examples. Best Regards, Emilio From akyrtzi at gmail.com Wed Jul 9 17:54:34 2008 From: akyrtzi at gmail.com (Argiris Kirtzidis) Date: Wed, 09 Jul 2008 15:54:34 -0700 Subject: [cfe-dev] Preprocessor::LookNext In-Reply-To: <3A358899-A6D5-42B9-BDB4-FBC6E61B7ED4@apple.com> References: <486D796B.3080906@gmail.com> <4873799E.3090408@gmail.com> <323C537C-76DC-4675-A1A6-B3ABB4240DA0@apple.com> <4874F2BC.5000504@gmail.com> <3A358899-A6D5-42B9-BDB4-FBC6E61B7ED4@apple.com> Message-ID: <487541AA.8070804@gmail.com> I incorporated the suggestions and committed the patches here: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20080707/006444.html http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20080707/006445.html Chris Lattner wrote: > > +++ lib/Lex/PPLexerChange.cpp (working copy) > @@ -85,6 +85,10 @@ > // size we new to a multiple of 16 tokens. If the previous buffer > has space > // left, we can just grow it. This means we only have to do the > new 1/16th as > // often. > + > + // Optimized LookAhead(0) case. > + if (N == 0) > + return LookNext(); > > Token *LookaheadTokens = new Token[N+1]; > > Is this correct for the LookAhead(1) case? I don't quite understand what you mean, LookAhead(1) isn't affected by this change, can you elaborate ? -Argiris From kremenek at apple.com Wed Jul 9 17:59:36 2008 From: kremenek at apple.com (Ted Kremenek) Date: Wed, 9 Jul 2008 15:59:36 -0700 Subject: [cfe-dev] Static Analyzer In-Reply-To: <68b1f7640807091541k1b934a72l11d630cd179fcf4d@mail.gmail.com> References: <68b1f7640807091541k1b934a72l11d630cd179fcf4d@mail.gmail.com> Message-ID: On Jul 9, 2008, at 3:41 PM, Emilio Monti wrote: > Hi, > I tried running scan-build wrapping a make building a simple test ANSI > C application full of clear bugs (memory leaks, null pointer > dereferencing, etc), but I always end up with: > scan-build: No bugs found. > > Is it a problem of my build/configuration? > > Which type of bugs can be detected with the current static analyzer? > I tried looking for this type of information, but I found only > Objective C examples. > > Best Regards, > Emilio Hi Emilio, I've been tardy in posting a comprehensive list of bugs currently found by the tool, as well as a rough description of how the tool finds these bugs. I'll try and post some information on this to the Clang website soon. The only memory leaks that the analyzer looks for right now related to use of Apple's Core Foundation and Foundation frameworks. The former is a C API, while the latter is solely for Objective-C. If you aren't using these APIs, the tool will not flag any leaks. There are plans to eventually support finding leaks involving malloc, etc., but it requires more infrastructure that is in the queue to implement. Null dereferences are inferred by tracking constants and inequality relationships within a function. This does not involve inter- procedural analysis (yet). For example: if (p) ... *p = 1; // Null dereference because p could be null. The analysis also finds dead stores, which are stores to variables that are never used. While the compiler optimizer can optimize away many of these stores, they are often indicative of significant logical errors in a program. The analyzer also looks for path-specific uses of uninitialized values, undefined operations such as bit-shifting by too many bits, etc. There are a few other checks, but there are mainly API specific checks with respect to the Core Foundation/Foundation APIs. There are many other checks we plan on implementing some day, including buffer overflow analysis and uses-of-untrusted data, etc. The tool is still very early in development, and there is a whole wealth of even simple checks that could and should be implemented. If you have specific test cases that include bugs that the analyzer is not finding, please feel free to send them my way or file a Bugzilla report. Incidentally, how are you running the analyzer? As you said, it could be a problem with your build. Make sure you operate with a clean build, and that your build system will use the CC environment variable to determine what compiler to use. If you manually set CC within your build system files, the analyzer won't be run (all scan-build does right now is set CC to be ccc-analyzer instead of gcc). If your build system presents verbose output on what commands it is executing, you should see calls to 'ccc-analyzer' instead of 'gcc'. Ted From filcab at gmail.com Wed Jul 9 18:01:21 2008 From: filcab at gmail.com (Filipe Cabecinhas) Date: Thu, 10 Jul 2008 00:01:21 +0100 Subject: [cfe-dev] [patch] Error using ccc with some configure scripts Message-ID: <2A0C3CBC-525F-442E-B734-CE58AA2D5641@gmail.com> Hi, ccc doesn't do what configure expects (gcc to do), when passed the flag -v or --version. I hammered an ugly patch on it so configure would shut up (it just wants to know that the gcc is newer than 2.0 (preferably newer than 3.4). It's not nice and it isn't dynamic (the triple is just hardcoded in the string because I couldn't figure out how to extract it from clang). One could also just exec gcc $arg when we're passed one of those and be done with it. - Filipe Cabecinhas -------------- next part -------------- A non-text attachment was scrubbed... Name: ccc--version-hack.patch Type: application/octet-stream Size: 824 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080710/7768ad0f/attachment.obj From eli.friedman at gmail.com Wed Jul 9 18:03:14 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Wed, 9 Jul 2008 16:03:14 -0700 Subject: [cfe-dev] Unravelling i-c-e + the gnu mess In-Reply-To: <2A4A05CE-D13A-4617-B8D1-B4C3B563927A@apple.com> References: <2A4A05CE-D13A-4617-B8D1-B4C3B563927A@apple.com> Message-ID: On Wed, Jul 9, 2008 at 11:05 AM, Chris Lattner wrote: > Ok, I'm preparing to do battle with Expr::isIntegerConstantExpr and > want to consult the guru's to see if this is a sane plan. :) > > Problem statement: > 1) we want to support fully conformant C code with GNU extensions > disabled. > 2) We want to support GNU extensions, but emit ext-warns when they > are used. > 3) If a subexpr is a GNU ice, we don't want to emit warnings > multiple times in the subexpr. The canonical horrible example would > be test/Sema/darwin-align-cast.c I agree so far. > 2. Change Expr::isIntegerConstantExpr to be something like this: > > // See if this expr is a real i-c-e. > unsigned Diag = isIntegerConstExprHelper(this, ..., false) > if (Diag == 0) return true; > > // See if it is a gnu one. > if (!LangOptions.NoExtensions) { > if (isIntegerConstExprHelper(this, ..., false) == 0) { > Emit Warning about using GNU i-c-e. > return true; > } > } > return false; This is where it get really messy... the issue is that saying that something is an integer constant expression has indirect effects in some cases. Non-ICE array bounds indicate a VLA, and the compatibility rules for those are different from those for constant arrays. A conditional expression with a null pointer constant can silently end up with a different type from an conditional with a pointer that happens to evaluate to zero. These are edge cases, but -pedantic shouldn't affect semantics. I think the right approach is what we're doing in Sema::TryFixInvalidVariablyModifiedType: if we run into a situation where we print a warning/error, but gcc accepts the code, try to recover at the point where we would print the diagnostic. If it's convenient, we could add a "RequireIntegerConstantExpr" method which does roughly "if (Expr->ICE()) return val; if (Expr->TryEvaluate()) {pedwarn(); return val;} error(); return failure;". Downsides to this approach: it's possible it will let stuff slip by without a warning in non-pedantic mode that gcc wouldn't accept, and this will leave constructs like the glibc tgmath.h broken. On a related note, I'm considering rewriting Expr::isIntegerConstantExpression() to delegate actual calculation to Expr::TryEvaluate() at some point, to reduce code duplication. > 3. Change Expr::isIntegerConstantExpr to return the diag reason up to > its callers so they can emit more specific diags in some cases. We should definitely do this eventually in any case. -Eli From devlists at shadowlab.org Wed Jul 9 18:10:37 2008 From: devlists at shadowlab.org (Jean-Daniel Dupas) Date: Thu, 10 Jul 2008 01:10:37 +0200 Subject: [cfe-dev] Constant CF/NSString and Unicode Message-ID: <01768D72-43F1-461A-818E-E6429D0E0FF5@shadowlab.org> I just wonder if there is some kind of unicode support in __builtin___CFStringMakeConstantString. In the current GCC version, when you compile an objc file, constant strings that contains non-ascii chars are converted into utf-16 strings and a flag is set into the generated CFString. The fact that it works only for objc file look more like a design decision than a technical limit, and this feature can easily be extended to c files. In fact, I managed to implement this feature in cc1 and it look like it works. (if I'm wrong, feel free to correct me). And what about clang and unicode CFString ? From eli.friedman at gmail.com Wed Jul 9 18:29:24 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Wed, 9 Jul 2008 16:29:24 -0700 Subject: [cfe-dev] Constant CF/NSString and Unicode In-Reply-To: <01768D72-43F1-461A-818E-E6429D0E0FF5@shadowlab.org> References: <01768D72-43F1-461A-818E-E6429D0E0FF5@shadowlab.org> Message-ID: On Wed, Jul 9, 2008 at 4:10 PM, Jean-Daniel Dupas wrote: > The fact that it works only for objc file look more like a design > decision than a technical limit, and this feature can easily be > extended to c files. You're trying to use CFString in a C file? How can that possibly work? -Eli From clattner at apple.com Wed Jul 9 18:29:45 2008 From: clattner at apple.com (Chris Lattner) Date: Wed, 9 Jul 2008 16:29:45 -0700 Subject: [cfe-dev] Preprocessor::LookNext In-Reply-To: <487541AA.8070804@gmail.com> References: <486D796B.3080906@gmail.com> <4873799E.3090408@gmail.com> <323C537C-76DC-4675-A1A6-B3ABB4240DA0@apple.com> <4874F2BC.5000504@gmail.com> <3A358899-A6D5-42B9-BDB4-FBC6E61B7ED4@apple.com> <487541AA.8070804@gmail.com> Message-ID: <40F5413C-6E43-4A6D-9306-821AA0513CF2@apple.com> On Jul 9, 2008, at 3:54 PM, Argiris Kirtzidis wrote: > I incorporated the suggestions and committed the patches here: Thanks! >> +++ lib/Lex/PPLexerChange.cpp (working copy) >> @@ -85,6 +85,10 @@ >> // size we new to a multiple of 16 tokens. If the previous >> buffer has space >> // left, we can just grow it. This means we only have to do the >> new 1/16th as >> // often. >> + >> + // Optimized LookAhead(0) case. >> + if (N == 0) >> + return LookNext(); >> >> Token *LookaheadTokens = new Token[N+1]; >> >> Is this correct for the LookAhead(1) case? > > I don't quite understand what you mean, LookAhead(1) isn't affected > by this change, can you elaborate ? I haven't looked at the code, I just want to make sure that LookAhead(1) or LookAhead(2) doesn't get off-by-one due to the peeked token. -Chris From akyrtzi at gmail.com Wed Jul 9 18:50:16 2008 From: akyrtzi at gmail.com (Argiris Kirtzidis) Date: Wed, 09 Jul 2008 16:50:16 -0700 Subject: [cfe-dev] Preprocessor::LookNext In-Reply-To: <40F5413C-6E43-4A6D-9306-821AA0513CF2@apple.com> References: <486D796B.3080906@gmail.com> <4873799E.3090408@gmail.com> <323C537C-76DC-4675-A1A6-B3ABB4240DA0@apple.com> <4874F2BC.5000504@gmail.com> <3A358899-A6D5-42B9-BDB4-FBC6E61B7ED4@apple.com> <487541AA.8070804@gmail.com> <40F5413C-6E43-4A6D-9306-821AA0513CF2@apple.com> Message-ID: <48754EB8.8060509@gmail.com> Chris Lattner wrote: >>> +++ lib/Lex/PPLexerChange.cpp (working copy) >>> @@ -85,6 +85,10 @@ >>> // size we new to a multiple of 16 tokens. If the previous buffer >>> has space >>> // left, we can just grow it. This means we only have to do the >>> new 1/16th as >>> // often. >>> + >>> + // Optimized LookAhead(0) case. >>> + if (N == 0) >>> + return LookNext(); >>> >>> Token *LookaheadTokens = new Token[N+1]; >>> >>> Is this correct for the LookAhead(1) case? >> >> I don't quite understand what you mean, LookAhead(1) isn't affected >> by this change, can you elaborate ? > > I haven't looked at the code, I just want to make sure that > LookAhead(1) or LookAhead(2) doesn't get off-by-one due to the peeked > token. LookAhead isn't called recursively, it collects all tokens through Lex(), into the LookaheadTokens array. If a peeked token exists, like when calling "LookAhead(0); LookAhead(1);", it goes like this: LookAhead(0); There's a peeked token now. LookAhead(1); -LookAhead consumes through Lex() the peeked token -Peeked token is invalidated, Lex() will not use it again. -LookAhead consumes one more token by 'normal' Lex(). -Previously peeked token plus one more enter the token stream. -Previously peeked token will be the next available token. So, everything works as expected :-) -Argiris From clattner at apple.com Wed Jul 9 18:56:59 2008 From: clattner at apple.com (Chris Lattner) Date: Wed, 9 Jul 2008 16:56:59 -0700 Subject: [cfe-dev] Preprocessor::LookNext In-Reply-To: <48754EB8.8060509@gmail.com> References: <486D796B.3080906@gmail.com> <4873799E.3090408@gmail.com> <323C537C-76DC-4675-A1A6-B3ABB4240DA0@apple.com> <4874F2BC.5000504@gmail.com> <3A358899-A6D5-42B9-BDB4-FBC6E61B7ED4@apple.com> <487541AA.8070804@gmail.com> <40F5413C-6E43-4A6D-9306-821AA0513CF2@apple.com> <48754EB8.8060509@gmail.com> Message-ID: On Jul 9, 2008, at 4:50 PM, Argiris Kirtzidis wrote: >> >> I haven't looked at the code, I just want to make sure that >> LookAhead(1) or LookAhead(2) doesn't get off-by-one due to the >> peeked token. > > LookAhead isn't called recursively, it collects all tokens through > Lex(), into the LookaheadTokens array. > If a peeked token exists, like when calling "LookAhead(0); > LookAhead(1);", it goes like this: > > LookAhead(0); > > There's a peeked token now. > > LookAhead(1); > > -LookAhead consumes through Lex() the peeked token > -Peeked token is invalidated, Lex() will not use it again. > -LookAhead consumes one more token by 'normal' Lex(). > -Previously peeked token plus one more enter the token stream. > -Previously peeked token will be the next available token. > > So, everything works as expected :-) ok, great! :) -Chris From clattner at apple.com Thu Jul 10 00:44:25 2008 From: clattner at apple.com (Chris Lattner) Date: Wed, 9 Jul 2008 22:44:25 -0700 Subject: [cfe-dev] final distributed clang patch In-Reply-To: <8914b92d0807090514w74383686o7101d4c63372832f@mail.gmail.com> References: <2e837e3a0807070913u449837beue9dfded1180a2ecd@mail.gmail.com> <535E73ED-491C-49BB-B5B7-E43A0B9B770B@apple.com> <8914b92d0807090514w74383686o7101d4c63372832f@mail.gmail.com> Message-ID: On Jul 9, 2008, at 5:14 AM, Csaba Hruska wrote: > Hi! > Here are the cutted patch files of indepenent changes: Great! > > TranslationUnit.patch - adds support (de)serialization (from)to (in > memory) buffer. Ted, can you look at this? > > Preprocessor.patch - adds a new method (getPredefines) needed for > passing predefines list to clangserver. Looks good to me, applied! > > ASTConsumers.patch - adds functions what supports capruing > ASTConsumer's output. -ASTConsumer *clang::CreateASTDumper() { return new ASTDumper(); } +ASTConsumer *clang::CreateASTDumper(std::ostream* OS) { return new ASTDumper(OS); } Please stay in 80 cols. ASTConsumer* CreateHTMLPrinter(const std::string &OutFile, Diagnostic &D, Preprocessor *PP, PreprocessorFactory* PPF); +ASTConsumer* CreateHTMLPrinter(std::ostream &OutStream, Diagnostic &D, + Preprocessor *PP, PreprocessorFactory* PPF); It's unclear to me that duplicating each of these is really the right approach. Would it work to make the *only* entry points take an ostream, and then just have the caller create the ofstream etc and pass that in as the OutStream? > I've also attached a skeleton of distclang documentation page (no > info yet, it will be added after the initial commit). Applied. > > I haven't attached clang.cpp, clang.h NetSession.cpp, NetSession.h > patch because they place in source structure is unknown. > We have to refactor the Driver directory content first. Sounds good. Thank you for taking this in steps, it makes it far easier to review. > > - platform independent thread and network support. Should these > added to llvm/Support or System library ? The general rule is that really low level things that are highly system specific should go in libsystem. libsupport can contain target independent abstractions that may optionally be built on libsystem components. > We also have to decide if we want to be distcc compatible or not. > And what's the benefit of distcc compatibility? I don't really have an opinion or an answer here. :) Are there benefits? anyone have an opinion? > - capture output of PrintPreprocessedOutput.cpp. Ted: openfd is not > acceptable, because we have to know the output size before we send > it. (required by net packet header) Lets talk about this one specifically. The "Simple buffered I/O" code in PrintPreprocessedOutput.cpp was written with extensive profiling, tuning and other tweaking and it is quite effective, though very ugly, code. The basic algorithm is that it buffers up chunks of 64K, then writes them out to disk with open/write/close. The API for it is very simple, and is basically built around not copying strings unnecessarily. This is pretty simple stuff and would be very useful elsewhere in LLVM (e.g. the .s printer, the bc writer, ...). It has been on my todo list for a long time, and seems required for the distcc project, to refactor this out to be a more general interface. I think something like this would be a great interface: class outstream { char *OutBufStart, *OutBufEnd, *OutBufCur; outstream(const outstream&); // can't be copied. void operator=(const outstream&); // or assigned. protected: outstream() {} // may only be subclassed virtual void FlushBuffer() = 0; public: virtual ~outstream(); void OutputChar(char c) { ...} void OutputString(const char *Ptr, unsigned Size) { ... } void Close(); static outstream* CreateFile(...); static outstream* CreateOStream(std::ostream &O); ... }; The basic idea here is that all the buffering of simple things (e.g. strings and chars) is inline and trivial, and the flushing happens via a virtual method that does the write or whatever else is needed. This is a very simple and useful API that is mostly target-independent (and should thus live in libsupport) but does rely on a few system specific things (which could live in libsystem). Is this something you could take on? It should be pretty straight- forward. Once it exists, switching the -E printer over to it should be easy, and this will make it easy to get it to output to an std::ostream or whatever else is desired (you could even make an outstream for a socket or whatever, to avoid the extra std::ostream overhead). -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080709/21849c92/attachment-0001.html From clattner at apple.com Thu Jul 10 00:56:40 2008 From: clattner at apple.com (Chris Lattner) Date: Wed, 9 Jul 2008 22:56:40 -0700 Subject: [cfe-dev] Constant CF/NSString and Unicode In-Reply-To: <01768D72-43F1-461A-818E-E6429D0E0FF5@shadowlab.org> References: <01768D72-43F1-461A-818E-E6429D0E0FF5@shadowlab.org> Message-ID: <7A0D181A-F2D2-4DBD-807C-5AA6980CD0E9@apple.com> On Jul 9, 2008, at 4:10 PM, Jean-Daniel Dupas wrote: > I just wonder if there is some kind of unicode support in > __builtin___CFStringMakeConstantString. In GCC or clang? Clang doesn't have any unicode support yet. > In the current GCC version, when you compile an objc file, constant > strings that contains non-ascii chars are converted into utf-16 > strings and a flag is set into the generated CFString. Ok. Fariborz implemented that fwiw. > The fact that it works only for objc file look more like a design > decision than a technical limit, and this feature can easily be > extended to c files. In fact, I managed to implement this feature in > cc1 and it look like it works. (if I'm wrong, feel free to correct > me). > > And what about clang and unicode CFString ? I'm not sure what you mean, can you explain a bit more? -Chris From nikita at zhuk.fi Thu Jul 10 01:22:48 2008 From: nikita at zhuk.fi (Nikita Zhuk) Date: Thu, 10 Jul 2008 09:22:48 +0300 Subject: [cfe-dev] A tool for generating reduced headers for test cases (delta debugging) In-Reply-To: <17600DC9-1404-4E5A-8700-F94772968384@apple.com> References: <80EC12FA-D4B8-4B87-B819-09E6D2A13AD0@zhuk.fi> <9ACE8734-E225-4E1C-BE53-F8BD55B3406A@apple.com> <17600DC9-1404-4E5A-8700-F94772968384@apple.com> Message-ID: On 10.7.2008, at 0.35, Ted Kremenek wrote: > Here is my scripts to add to the pile. Once must change the source > file in "detect_error.pl" (this is the source that includes the > header to be reduced) while "reduce.pl" takes as an argument the > preprocessed header you want to reduce (this file is included by the > source file). > > Both scripts rely on the delta-debugging scripts being in your path. > > I also saw that Nuno posted some scripts. Hopefully from all these > scripts you'll find something that works for you. If these scripts > prove useful, we should post them to the Clang website. Thanks Ted and Nuno! I'll try these scripts and report any results (hopefully by submitting some reduced test cases) in couple of days. From devlists at shadowlab.org Thu Jul 10 01:31:49 2008 From: devlists at shadowlab.org (Jean-Daniel Dupas) Date: Thu, 10 Jul 2008 08:31:49 +0200 Subject: [cfe-dev] Constant CF/NSString and Unicode In-Reply-To: References: <01768D72-43F1-461A-818E-E6429D0E0FF5@shadowlab.org> Message-ID: <91ABBD2B-EAA1-4909-9AF7-E91A5BF72F35@shadowlab.org> Le 10 juil. 08 ? 01:29, Eli Friedman a ?crit : > On Wed, Jul 9, 2008 at 4:10 PM, Jean-Daniel Dupas > wrote: >> The fact that it works only for objc file look more like a design >> decision than a technical limit, and this feature can easily be >> extended to c files. > > You're trying to use CFString in a C file? How can that possibly > work? > > -Eli > It works just like in clang/test/CodeGen/cfstring.c Isn't CoreFoundation a C API ? What's the problem with CFString in C file ? From devlists at shadowlab.org Thu Jul 10 01:50:55 2008 From: devlists at shadowlab.org (Jean-Daniel Dupas) Date: Thu, 10 Jul 2008 08:50:55 +0200 Subject: [cfe-dev] Constant CF/NSString and Unicode In-Reply-To: <7A0D181A-F2D2-4DBD-807C-5AA6980CD0E9@apple.com> References: <01768D72-43F1-461A-818E-E6429D0E0FF5@shadowlab.org> <7A0D181A-F2D2-4DBD-807C-5AA6980CD0E9@apple.com> Message-ID: <256409B0-BF13-43C1-86FD-3CBD5DCBA39F@shadowlab.org> Le 10 juil. 08 ? 07:56, Chris Lattner a ?crit : > > On Jul 9, 2008, at 4:10 PM, Jean-Daniel Dupas wrote: >> I just wonder if there is some kind of unicode support in >> __builtin___CFStringMakeConstantString. > > In GCC or clang? Clang doesn't have any unicode support yet. > >> In the current GCC version, when you compile an objc file, constant >> strings that contains non-ascii chars are converted into utf-16 >> strings and a flag is set into the generated CFString. > > Ok. Fariborz implemented that fwiw. > >> The fact that it works only for objc file look more like a design >> decision than a technical limit, and this feature can easily be >> extended to c files. In fact, I managed to implement this feature in >> cc1 and it look like it works. (if I'm wrong, feel free to correct >> me). >> >> And what about clang and unicode CFString ? > > I'm not sure what you mean, can you explain a bit more? > > -Chris Yep, put this simple code snippet in cfstring.c : #include int main(int argc, char **argv) { CFShowStr(CFSTR("h? h? h?")); CFShow(CFSTR("h? h? h?")); return 0; } if you compile this file using "gcc -o cfstring cfstring.c -framework CoreFoundation" and run it you got: Length 11 IsEightBit 1 HasLengthByte 0 HasNullByte 1 InlineContents 0 Allocator SystemDefault Mutable 0 Contents 0x1ff2 h\u221a\u00a9 h\u221a\u00a9 h\u221a\u00a9 Now, if you compile this same file using gcc -x objective-c -o cfstring cfstring.c -framework CoreFoundation the output is: Length 8 IsEightBit 0 HasLengthByte 0 HasNullByte 0 InlineContents 0 Allocator SystemDefault Mutable 0 Contents 0x1fee h\u00e9 h\u00e9 h\u00e9 Maybe I miss something, but I really do not understand the current limitation. As clang will probably implements this feature some day, I just wonder if it should duplicate the GCC behavior (emitting a warning and generating an ascii based CFString) or if it can be extended to support also UTF-16 CFString generation in plain C file. From csaba.hruska at gmail.com Thu Jul 10 03:28:08 2008 From: csaba.hruska at gmail.com (Csaba Hruska) Date: Thu, 10 Jul 2008 10:28:08 +0200 Subject: [cfe-dev] final distributed clang patch In-Reply-To: References: <2e837e3a0807070913u449837beue9dfded1180a2ecd@mail.gmail.com> <535E73ED-491C-49BB-B5B7-E43A0B9B770B@apple.com> <8914b92d0807090514w74383686o7101d4c63372832f@mail.gmail.com> Message-ID: <8914b92d0807100128g63f68e1exf8699bc2897d0f2f@mail.gmail.com> 2008/7/10 Chris Lattner : > > On Jul 9, 2008, at 5:14 AM, Csaba Hruska wrote: > > Hi! > Here are the cutted patch files of indepenent changes: > > > Great! > > > TranslationUnit.patch - adds support (de)serialization (from)to (in memory) > buffer. > > > Ted, can you look at this? > > > Preprocessor.patch - adds a new method (getPredefines) needed for passing > predefines list to clangserver. > > > Looks good to me, applied! > > > ASTConsumers.patch - adds functions what supports capruing ASTConsumer's > output. > > > -ASTConsumer *clang::CreateASTDumper() { return new ASTDumper(); } > +ASTConsumer *clang::CreateASTDumper(std::ostream* OS) { return new > ASTDumper(OS); } > > > Please stay in 80 cols. > > ASTConsumer* CreateHTMLPrinter(const std::string &OutFile, Diagnostic &D, > Preprocessor *PP, PreprocessorFactory* > PPF); > > > +ASTConsumer* CreateHTMLPrinter(std::ostream &OutStream, Diagnostic &D, > + Preprocessor *PP, PreprocessorFactory* > PPF); > > It's unclear to me that duplicating each of these is really the right > approach. Would it work to make the *only* entry points take an ostream, > and then just have the caller create the ofstream etc and pass that in as > the OutStream? > > > I've also attached a skeleton of distclang documentation page (no info yet, > it will be added after the initial commit). > > > Applied. > > > I haven't attached clang.cpp, clang.h NetSession.cpp, NetSession.h patch > because they place in source structure is unknown. > > We have to refactor the Driver directory content first. > > > Sounds good. Thank you for taking this in steps, it makes it far easier to > review. > > > > - platform independent thread and network support. Should these added to > llvm/Support or System library ? > > > The general rule is that really low level things that are highly system > specific should go in libsystem. libsupport can contain target independent > abstractions that may optionally be built on libsystem components. > > We also have to decide if we want to be distcc compatible or not. And > what's the benefit of distcc compatibility? > > > I don't really have an opinion or an answer here. :) Are there benefits? > anyone have an opinion? > > > - capture output of PrintPreprocessedOutput.cpp. Ted: openfd is not > acceptable, because we have to know the output size before we send it. > (required by net packet header) > > > Lets talk about this one specifically. The "Simple buffered I/O" code in > PrintPreprocessedOutput.cpp was written with extensive profiling, tuning and > other tweaking and it is quite effective, though very ugly, code. The basic > algorithm is that it buffers up chunks of 64K, then writes them out to disk > with open/write/close. The API for it is very simple, and is basically > built around not copying strings unnecessarily. > > This is pretty simple stuff and would be very useful elsewhere in LLVM > (e.g. the .s printer, the bc writer, ...). It has been on my todo list for > a long time, and seems required for the distcc project, to refactor this out > to be a more general interface. I think something like this would be a > great interface: > > class outstream { > char *OutBufStart, *OutBufEnd, *OutBufCur; > outstream(const outstream&); // can't be copied. > void operator=(const outstream&); // or assigned. > protected: > outstream() {} // may only be subclassed > virtual void FlushBuffer() = 0; > public: > virtual ~outstream(); > > void OutputChar(char c) { ...} > void OutputString(const char *Ptr, unsigned Size) { ... } > void Close(); > > static outstream* CreateFile(...); > static outstream* CreateOStream(std::ostream &O); > ... > }; > > The basic idea here is that all the buffering of simple things (e.g. > strings and chars) is inline and trivial, and the flushing happens via a > virtual method that does the write or whatever else is needed. This is a > very simple and useful API that is mostly target-independent (and should > thus live in libsupport) but does rely on a few system specific things > (which could live in libsystem). > > Is this something you could take on? It should be pretty straight-forward. > Once it exists, switching the -E printer over to it should be easy, and > this will make it easy to get it to output to an std::ostream or whatever > else is desired (you could even make an outstream for a socket or whatever, > to avoid the extra std::ostream overhead). > This can solve my problem. And if we make the ASTConsumer library they should use the outstream class to write out they output (This will remove duplications from ASTConsumer.h functions). There is one more requirement if we follow this. Most of ASTConsumers have one output stream or file, but there is StaticAnalysis what is make a couple of HTML files and because distcc static analysis is a big speedup, we must support this astconsumer, so we have to capture its output somehow. Maybe with some outstream manager interface class, one implementation for normal clang to support files and stdout and one implementation for clangserver for netstreams. The outstream class interface is ok for this except we cannot overload CreateFile and CreateOStream. > > -Chris > Csaba -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080710/b38787a5/attachment-0001.html From matthijs at stdin.nl Thu Jul 10 03:54:47 2008 From: matthijs at stdin.nl (Matthijs Kooijman) Date: Thu, 10 Jul 2008 10:54:47 +0200 Subject: [cfe-dev] Custom calling conventions in C code In-Reply-To: <9C5303A7-5DE5-4C90-8FC6-9299021804FF@apple.com> References: <20080623092823.GS3816@katherina.student.utwente.nl> <9C5303A7-5DE5-4C90-8FC6-9299021804FF@apple.com> Message-ID: <20080710085447.GW32600@katherina.student.utwente.nl> Hi Chris, >> [Specifiying custom calling conventions from C] > There isn't currently a way to do this, you'd have to use specific named > conventions like "cdecl" "stdcall" "pascal" etc, along with attributes. The problem is that I'd like to have a completely custom and backend-specific calling convention, and using one of those keywords would be abuse. > I think it would be a great thing for compiler hackers to have a mechanism > to access an arbitrary calling convention, but I also think it would be a > disaster to expose this to end user code. The problem is that not all > constructs are valid with every calling convention, and if there is ever a > large install base of code using "calling convention 19" in their C code, > we'd have to support that forever. CC#'s are supposed to be an internal > implementation detail of the IR. In our case, we are working with a specific C variant, which is mostly C compatible and can therefore be parsed by clang completely. So, I'm looking for a way to be able to write down a custom calling convention from within that language, without having to modify clang locally. So, support for a __attribute__(()) extension would be just fine. I see something like this in a similar way as the annotate attribute. It's possible to write it down, but clang won't guarantee anything about how it's handled. In other words, its only useful when you know beforehand which backend is going to be handling your code. Support a specific calling convention is then something for the backend, which might or might not continue support for a specific calling convention. Doesn't that sound reasonable? Gr. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080710/10e4b939/attachment.bin From tastic at bycrom.org Thu Jul 10 09:00:59 2008 From: tastic at bycrom.org (Matthew Jimenez) Date: Thu, 10 Jul 2008 09:00:59 -0500 Subject: [cfe-dev] Constant CF/NSString and Unicode In-Reply-To: <256409B0-BF13-43C1-86FD-3CBD5DCBA39F@shadowlab.org> References: <01768D72-43F1-461A-818E-E6429D0E0FF5@shadowlab.org> <7A0D181A-F2D2-4DBD-807C-5AA6980CD0E9@apple.com> <256409B0-BF13-43C1-86FD-3CBD5DCBA39F@shadowlab.org> Message-ID: On Jul 10, 2008, at 1:50 AM, Jean-Daniel Dupas wrote: > > Le 10 juil. 08 ? 07:56, Chris Lattner a ?crit : > >> >> On Jul 9, 2008, at 4:10 PM, Jean-Daniel Dupas wrote: >>> I just wonder if there is some kind of unicode support in >>> __builtin___CFStringMakeConstantString. >> >> In GCC or clang? Clang doesn't have any unicode support yet. >> >>> In the current GCC version, when you compile an objc file, constant >>> strings that contains non-ascii chars are converted into utf-16 >>> strings and a flag is set into the generated CFString. >> >> Ok. Fariborz implemented that fwiw. >> >>> The fact that it works only for objc file look more like a design >>> decision than a technical limit, and this feature can easily be >>> extended to c files. In fact, I managed to implement this feature in >>> cc1 and it look like it works. (if I'm wrong, feel free to correct >>> me). >>> >>> And what about clang and unicode CFString ? >> >> I'm not sure what you mean, can you explain a bit more? >> >> -Chris > > > Yep, > put this simple code snippet in cfstring.c : > > #include > > int main(int argc, char **argv) { > CFShowStr(CFSTR("h? h? h?")); > CFShow(CFSTR("h? h? h?")); > return 0; > } > > if you compile this file using "gcc -o cfstring cfstring.c -framework > CoreFoundation" and run it you got: > > Length 11 > IsEightBit 1 > HasLengthByte 0 > HasNullByte 1 > InlineContents 0 > Allocator SystemDefault > Mutable 0 > Contents 0x1ff2 > h\u221a\u00a9 h\u221a\u00a9 h\u221a\u00a9 > > Now, if you compile this same file using > > gcc -x objective-c -o cfstring cfstring.c -framework CoreFoundation > > the output is: > > Length 8 > IsEightBit 0 > HasLengthByte 0 > HasNullByte 0 > InlineContents 0 > Allocator SystemDefault > Mutable 0 > Contents 0x1fee > h\u00e9 h\u00e9 h\u00e9 > > Maybe I miss something, but I really do not understand the current > limitation. > As clang will probably implements this feature some day, I just wonder > if it should duplicate the GCC behavior (emitting a warning and > generating an ascii based CFString) or if it can be extended to > support also UTF-16 CFString generation in plain C file. > Now I'm curious. Does this behavior change using -fconstant-cfstrings instead of defining the language as ObjC? According to the documentation, it looks like that is the flag to enable __builtin__CFStringMakeConstantString. -Matthew From mymlreader at gmail.com Thu Jul 10 09:08:45 2008 From: mymlreader at gmail.com (Zhongxing Xu) Date: Thu, 10 Jul 2008 22:08:45 +0800 Subject: [cfe-dev] Best place for semantic checks In-Reply-To: <0CC29FB7-AAC1-4FB5-9FFB-8030AC87E72C@apple.com> References: <4873B813.2080105@quick.cz> <0CC29FB7-AAC1-4FB5-9FFB-8030AC87E72C@apple.com> Message-ID: <4619993f0807100708w15fca2c6n95e4f0e8b0135bae@mail.gmail.com> To avoid unexpected troubles when doing svn update, I copy the whole clang/Driver directory to another place and do all things in that directory, and linking against the necessary LLVM/clang libraries to build a custom driver. > More specifically, you need to modify the following to use the > AnalysisConsumer interface: > > -------------------- > > Driver/AnalysisConsumer.h: > > Add a new value to the enum Analyses: > > enum Analyses { > CFGDump, > CFGView, > WarnDeadStores, > WarnUninitVals, > DisplayLiveVariables, > CheckerCFRef, > CheckerSimple, > MyChecker // <-------------------------- > }; > > -------------------- > > Driver/AnalysisConsumer.cpp: > > 1) Add a static "Action" function that calls your checker using the > appropriate arguments. > > static void ActionMyChecker(AnalysisManager& mgr) { > // Call the checker using arguments provided by queries to > AnalysisManager. > ... > } > > > 2) Add a case in CreateAnalysisConsumer for your Analysis using the > enum value you added to Driver/AnalysisConsumer.h: > > ASTConsumer* clang::CreateAnalysisConsumer(...) { > > ... > > for ( ; Beg != End ; ++Beg) > switch (*Beg) { > case WarnDeadStores: > C->addCodeAction(&ActionDeadStores); > break; > > case WarnUninitVals: > C->addCodeAction(&ActionUninitVals); > break; > > // ADD A CASE HERE > case MyChecker: > C->addCodeAction(&ActionMyChecker); > break; > > -------------------- > > Driver/Clang.cpp: > > Add your command line argument to "Analyses" > > static llvm::cl::list > AnalysisList(llvm::cl::desc("Available Source Code Analyses:"), > llvm::cl::values( > clEnumValN(CFGDump, "cfg-dump", "Display Control-Flow Graphs"), > clEnumValN(CFGView, "cfg-view", "View Control-Flow Graphs using > GraphViz"), > clEnumValN(DisplayLiveVariables, "dump-live-variables", > "Print results of live variable analysis"), > clEnumValN(WarnDeadStores, "warn-dead-stores", > "Flag warnings of stores to dead variables"), > clEnumValN(WarnUninitVals, "warn-uninit-values", > "Flag warnings of uses of unitialized variables"), > clEnumValN(CheckerSimple, "checker-simple", > "Perform simple path-sensitive checks."), > clEnumValN(CheckerCFRef, "checker-cfref", > "Run the [Core] Foundation reference count checker"), > clEnumValnN(MyChecker, "my-checker", // > <------------------------------------------ > "My Custom Checker"), > clEnumValEnd)); > > > - Ted > _______________________________________________ > 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/20080710/44719b06/attachment.html From devlists at shadowlab.org Thu Jul 10 09:23:33 2008 From: devlists at shadowlab.org (Jean-Daniel Dupas) Date: Thu, 10 Jul 2008 16:23:33 +0200 Subject: [cfe-dev] Constant CF/NSString and Unicode In-Reply-To: References: <01768D72-43F1-461A-818E-E6429D0E0FF5@shadowlab.org> <7A0D181A-F2D2-4DBD-807C-5AA6980CD0E9@apple.com> <256409B0-BF13-43C1-86FD-3CBD5DCBA39F@shadowlab.org> Message-ID: Le 10 juil. 08 ? 16:00, Matthew Jimenez a ?crit : > On Jul 10, 2008, at 1:50 AM, Jean-Daniel Dupas wrote: > >> >> Le 10 juil. 08 ? 07:56, Chris Lattner a ?crit : >> >>> >>> On Jul 9, 2008, at 4:10 PM, Jean-Daniel Dupas wrote: >>>> I just wonder if there is some kind of unicode support in >>>> __builtin___CFStringMakeConstantString. >>> >>> In GCC or clang? Clang doesn't have any unicode support yet. >>> >>>> In the current GCC version, when you compile an objc file, constant >>>> strings that contains non-ascii chars are converted into utf-16 >>>> strings and a flag is set into the generated CFString. >>> >>> Ok. Fariborz implemented that fwiw. >>> >>>> The fact that it works only for objc file look more like a design >>>> decision than a technical limit, and this feature can easily be >>>> extended to c files. In fact, I managed to implement this feature >>>> in >>>> cc1 and it look like it works. (if I'm wrong, feel free to correct >>>> me). >>>> >>>> And what about clang and unicode CFString ? >>> >>> I'm not sure what you mean, can you explain a bit more? >>> >>> -Chris >> >> >> Yep, >> put this simple code snippet in cfstring.c : >> >> #include >> >> int main(int argc, char **argv) { >> CFShowStr(CFSTR("h? h? h?")); >> CFShow(CFSTR("h? h? h?")); >> return 0; >> } >> >> if you compile this file using "gcc -o cfstring cfstring.c -framework >> CoreFoundation" and run it you got: >> >> Length 11 >> IsEightBit 1 >> HasLengthByte 0 >> HasNullByte 1 >> InlineContents 0 >> Allocator SystemDefault >> Mutable 0 >> Contents 0x1ff2 >> h\u221a\u00a9 h\u221a\u00a9 h\u221a\u00a9 >> >> Now, if you compile this same file using >> >> gcc -x objective-c -o cfstring cfstring.c -framework CoreFoundation >> >> the output is: >> >> Length 8 >> IsEightBit 0 >> HasLengthByte 0 >> HasNullByte 0 >> InlineContents 0 >> Allocator SystemDefault >> Mutable 0 >> Contents 0x1fee >> h\u00e9 h\u00e9 h\u00e9 >> >> Maybe I miss something, but I really do not understand the current >> limitation. >> As clang will probably implements this feature some day, I just >> wonder >> if it should duplicate the GCC behavior (emitting a warning and >> generating an ascii based CFString) or if it can be extended to >> support also UTF-16 CFString generation in plain C file. >> > > Now I'm curious. Does this behavior change using -fconstant-cfstrings > instead of defining the language as ObjC? According to the > documentation, > it looks like that is the flag to enable > __builtin__CFStringMakeConstantString. > > -Matthew This flags is on by default on modern version of Xcode (I think it depends the macosx-min-version flags). Turning it off (-fno-constant-cfstrings ) remove the compilation warning and defere it at runtime ;-) This is what the app log when CFSTR is called with "false constant cfstrings" that contains something that's not ascii. WARNING: CFSTR("h\37777777703\37777777651 h\37777777703\37777777651 h \37777777703\37777777651") has non-7 bit chars, interpreting using MacOS Roman encoding for now, but this will change. Please eliminate usages of non-7 bit chars (including escaped characters above \177 octal) in CFSTR(). I'm not suprise by this result. the GCC __builtin___CFStringMakeConstantString codegen function try to determine if the argument string contains non ascii chars. If it find one, it try to convert the string into an unicode string and to save it as a constant string in the module. But the function that converts the string and writes it, is implemented only in the obj-c module (cc1obj and cc1objplus) and not in the c one (cc1). So in C the convertion always returns null and GCC fall back to ascii string generation. From clattner at apple.com Thu Jul 10 11:53:21 2008 From: clattner at apple.com (Chris Lattner) Date: Thu, 10 Jul 2008 09:53:21 -0700 Subject: [cfe-dev] distributed clang patch In-Reply-To: <8914b92d0807100128g63f68e1exf8699bc2897d0f2f@mail.gmail.com> References: <2e837e3a0807070913u449837beue9dfded1180a2ecd@mail.gmail.com> <535E73ED-491C-49BB-B5B7-E43A0B9B770B@apple.com> <8914b92d0807090514w74383686o7101d4c63372832f@mail.gmail.com> <8914b92d0807100128g63f68e1exf8699bc2897d0f2f@mail.gmail.com> Message-ID: <6F5D6BF9-E572-4178-A4F4-5E573AB10662@apple.com> On Jul 10, 2008, at 1:28 AM, Csaba Hruska wrote: > Is this something you could take on? It should be pretty straight- > forward. Once it exists, switching the -E printer over to it should > be easy, and this will make it easy to get it to output to an > std::ostream or whatever else is desired (you could even make an > outstream for a socket or whatever, to avoid the extra std::ostream > overhead). > This can solve my problem. And if we make the ASTConsumer library > they should use the outstream class to write out they output (This > will remove duplications from ASTConsumer.h functions). That makes sense to me! > > There is one more requirement if we follow this. Most of > ASTConsumers have one output stream or file, but there is > StaticAnalysis what is make a couple of HTML files and because > distcc static analysis is a big speedup, we must support this > astconsumer, so we have to capture its output somehow. I would worry about this one later. I think it would be good to focus on distributing the other ASTConsumers before the static analysis one. Thanks for tackling this! -Chris From kremenek at apple.com Thu Jul 10 12:18:11 2008 From: kremenek at apple.com (Ted Kremenek) Date: Thu, 10 Jul 2008 10:18:11 -0700 Subject: [cfe-dev] distributed clang patch In-Reply-To: <6F5D6BF9-E572-4178-A4F4-5E573AB10662@apple.com> References: <2e837e3a0807070913u449837beue9dfded1180a2ecd@mail.gmail.com> <535E73ED-491C-49BB-B5B7-E43A0B9B770B@apple.com> <8914b92d0807090514w74383686o7101d4c63372832f@mail.gmail.com> <8914b92d0807100128g63f68e1exf8699bc2897d0f2f@mail.gmail.com> <6F5D6BF9-E572-4178-A4F4-5E573AB10662@apple.com> Message-ID: On Jul 10, 2008, at 9:53 AM, Chris Lattner wrote: >> There is one more requirement if we follow this. Most of >> ASTConsumers have one output stream or file, but there is >> StaticAnalysis what is make a couple of HTML files and because >> distcc static analysis is a big speedup, we must support this >> astconsumer, so we have to capture its output somehow. > > I would worry about this one later. I think it would be good to focus > on distributing the other ASTConsumers before the static analysis one. I think the solution for the AnalysisConsumer is two steps: 1) Factor out the creation of the HTMLDiagnostics object used for HTML rendering out of AnalysisConsumer. Instead, the ctor for AnalysisConsumer takes a PathDiagnosticClient* (which in the regular driver is an HTMLDiagnostics object). I planned on doing this anyway. 2) In the distcc client, instead of creating an HTMLDiagnostics object, create a different PathDiagnosticClient object that just batches the diagnostics (this doesn't exist yet, but is easy to implement). The distcc client can then send the diagnostics back to the original client, and not have to worry about HTML rendering. There will also probably be some ugly details, but ultimately the distcc client shouldn't care how the final analysis results are consumed by the end-user. From clattner at apple.com Thu Jul 10 12:43:26 2008 From: clattner at apple.com (Chris Lattner) Date: Thu, 10 Jul 2008 10:43:26 -0700 Subject: [cfe-dev] name compatibility with llvm-gcc? In-Reply-To: <842D6FE2AFA147BD9398C0844F7F7B44@pc07654> References: <489D29BC-9D4B-4B56-9298-151CECF91B21@apple.com> <842D6FE2AFA147BD9398C0844F7F7B44@pc07654> Message-ID: On Jul 9, 2008, at 4:18 AM, Nuno Lopes wrote: >>> I noticed that struct and union LLVM type names generated by clang >>> and >>> llvm-gcc don't follow the same naming convention, which is >>> causing me some >>> headaches. >>> llvm-gcc uses the following convention: struct.struct_name; >>> struct.union_name >>> while clang uses: struct._struct_name; union._union_name. >>> >>> Can we change clang so that clang respects llvm-gcc's ABI? I would >>> appreciate this change (I'm using clang, while my colleague is using >>> llvm-gcc..). >> >> Sounds fine with me, it should be an easy change. > > Arg, actually my analysis was wrong. > The problem is that function decls save the canonical type. E.g.: > > typedef struct _zend_op_array zend_op_array; > struct _zend_op_array { ... }; > > zend_op_array *foo() { return 0; } > > When codegening the function foo I get the 'struct _zend_op_array', > instead of zend_op_array. This is the reason why I was getting the > 'struct._struct_name' style names. > > So this problem isn't that easy to "fix". It would require saving > the non-canonical type instead of the canonic one (that I think you > don't want to do?). Why do you need this info? It sounds like a bad design somewhere. >> > I called it ABI just in the sense that I wanted to link code > generated by the 2 different frontends. I need to fill in structures > at runtime that were compiled with either llvm-gcc or clang (I need > a StructType* out of a name). Anyway just forget the ABI thing.. :) Regardless of whether it is part of the ABI, names are just entries in a symbol table. You can completely remove those names without affecting the semantics of the LLVM IR. -Chris From csaba.hruska at gmail.com Thu Jul 10 12:56:25 2008 From: csaba.hruska at gmail.com (Csaba Hruska) Date: Thu, 10 Jul 2008 19:56:25 +0200 Subject: [cfe-dev] distributed clang patch In-Reply-To: References: <2e837e3a0807070913u449837beue9dfded1180a2ecd@mail.gmail.com> <535E73ED-491C-49BB-B5B7-E43A0B9B770B@apple.com> <8914b92d0807090514w74383686o7101d4c63372832f@mail.gmail.com> <8914b92d0807100128g63f68e1exf8699bc2897d0f2f@mail.gmail.com> <6F5D6BF9-E572-4178-A4F4-5E573AB10662@apple.com> Message-ID: <8914b92d0807101056vb07a3ffk22db0cb0fcc13269@mail.gmail.com> 2008/7/10 Ted Kremenek : > > On Jul 10, 2008, at 9:53 AM, Chris Lattner wrote: > > There is one more requirement if we follow this. Most of >>> ASTConsumers have one output stream or file, but there is >>> StaticAnalysis what is make a couple of HTML files and because >>> distcc static analysis is a big speedup, we must support this >>> astconsumer, so we have to capture its output somehow. >>> >> >> I would worry about this one later. I think it would be good to focus >> on distributing the other ASTConsumers before the static analysis one. >> > > I think the solution for the AnalysisConsumer is two steps: > > 1) Factor out the creation of the HTMLDiagnostics object used for HTML > rendering out of AnalysisConsumer. Instead, the ctor for AnalysisConsumer > takes a PathDiagnosticClient* (which in the regular driver is an > HTMLDiagnostics object). I planned on doing this anyway. > > 2) In the distcc client, instead of creating an HTMLDiagnostics object, > create a different PathDiagnosticClient object that just batches the > diagnostics (this doesn't exist yet, but is easy to implement). The distcc > client can then send the diagnostics back to the original client, and not > have to worry about HTML rendering. > > There will also probably be some ugly details, but ultimately the distcc > client shouldn't care how the final analysis results are consumed by the > end-user. > Right. I've started working on putting all reusable thing from Driver directory into a separated library called driver. (in my opinion every app's dir name should be same as app name. clang (ordinary local driver), distclangserver(distcc server), distclang(distcc client)). The dist app names should be more simple if anyone can suggest greatet descriptive names. :) About supporting other compilers by distributed clang: Ted, please describe you ideas, because i have no idea what's the point of this thing. I'd like to put these things into the driver lib: almost everything from Driver dir and some functions from clang.cpp. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080710/8a64996e/attachment.html From clattner at apple.com Thu Jul 10 12:58:10 2008 From: clattner at apple.com (Chris Lattner) Date: Thu, 10 Jul 2008 10:58:10 -0700 Subject: [cfe-dev] Custom calling conventions in C code In-Reply-To: <20080710085447.GW32600@katherina.student.utwente.nl> References: <20080623092823.GS3816@katherina.student.utwente.nl> <9C5303A7-5DE5-4C90-8FC6-9299021804FF@apple.com> <20080710085447.GW32600@katherina.student.utwente.nl> Message-ID: <4819B794-DAC8-46B2-B537-E44E645C0BAB@apple.com> On Jul 10, 2008, at 1:54 AM, Matthijs Kooijman wrote: >> I think it would be a great thing for compiler hackers to have a >> mechanism >> to access an arbitrary calling convention, but I also think it >> would be a >> disaster to expose this to end user code. The problem is that not >> all >> constructs are valid with every calling convention, and if there is >> ever a >> large install base of code using "calling convention 19" in their C >> code, >> we'd have to support that forever. CC#'s are supposed to be an >> internal >> implementation detail of the IR. > In our case, we are working with a specific C variant, which is > mostly C > compatible and can therefore be parsed by clang completely. So, I'm > looking > for a way to be able to write down a custom calling convention from > within > that language, without having to modify clang locally. So, support > for a > __attribute__(()) extension would be just fine. Ok, so you have specific conventions you want to support. Something like: void foo() __interrupt__ { } or whatever. The best way to do this is to have __interrupt__ be a target-specific #define for __attribute__((interrupt)) and then have your target handle the interrupt attribute however you want. > backend is going to be handling your code. Support a specific calling > convention is then something for the backend, which might or might not > continue support for a specific calling convention. Doesn't that sound > reasonable? Yep, supporting specific calling conventions is fine, I just don't want something like: __attribute__((callingconv(47))) -Chris From matthijs at stdin.nl Thu Jul 10 14:19:22 2008 From: matthijs at stdin.nl (Matthijs Kooijman) Date: Thu, 10 Jul 2008 21:19:22 +0200 Subject: [cfe-dev] Custom calling conventions in C code In-Reply-To: <4819B794-DAC8-46B2-B537-E44E645C0BAB@apple.com> References: <20080623092823.GS3816@katherina.student.utwente.nl> <9C5303A7-5DE5-4C90-8FC6-9299021804FF@apple.com> <20080710085447.GW32600@katherina.student.utwente.nl> <4819B794-DAC8-46B2-B537-E44E645C0BAB@apple.com> Message-ID: <20080710191922.GC32600@katherina.student.utwente.nl> > or whatever. The best way to do this is to have __interrupt__ be a > target-specific #define for __attribute__((interrupt)) and then have your > target handle the interrupt attribute however you want. > Yep, supporting specific calling conventions is fine, I just don't want > something like: > > __attribute__((callingconv(47))) Okay, sounds reasonable. However, is there any generic way to do this in clang, or will I end up locally patching clang for this? If the latter is the case, might function annotation be an alternative? Currently, I can specify __attribute__((annotate("foo"))) for global variables, but not for functions (both in clang and gcc). I'm not sure where this limitation comes from, but enabling generic annotation for functions should also work for me (I can simply add a frontend pass that translates those annotations into calling conventions for my backend, or leave them as annotions even). Gr. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080710/41982d61/attachment.bin From clattner at apple.com Thu Jul 10 14:56:29 2008 From: clattner at apple.com (Chris Lattner) Date: Thu, 10 Jul 2008 12:56:29 -0700 Subject: [cfe-dev] Custom calling conventions in C code In-Reply-To: <20080710191922.GC32600@katherina.student.utwente.nl> References: <20080623092823.GS3816@katherina.student.utwente.nl> <9C5303A7-5DE5-4C90-8FC6-9299021804FF@apple.com> <20080710085447.GW32600@katherina.student.utwente.nl> <4819B794-DAC8-46B2-B537-E44E645C0BAB@apple.com> <20080710191922.GC32600@katherina.student.utwente.nl> Message-ID: On Jul 10, 2008, at 12:19 PM, Matthijs Kooijman wrote: >> or whatever. The best way to do this is to have __interrupt__ be a >> target-specific #define for __attribute__((interrupt)) and then >> have your >> target handle the interrupt attribute however you want. > >> Yep, supporting specific calling conventions is fine, I just don't >> want >> something like: >> >> __attribute__((callingconv(47))) > > Okay, sounds reasonable. However, is there any generic way to do > this in > clang, or will I end up locally patching clang for this? > > If the latter is the case, might function annotation be an > alternative? > Currently, I can specify __attribute__((annotate("foo"))) for global > variables, but not for functions (both in clang and gcc). I'm not > sure where > this limitation comes from, but enabling generic annotation for > functions > should also work for me (I can simply add a frontend pass that > translates > those annotations into calling conventions for my backend, or leave > them as > annotions even). You could use attr(annotate). I think attributes in general can only be put on function forward declarations, not definitions. -Chris From kremenek at apple.com Thu Jul 10 17:11:28 2008 From: kremenek at apple.com (Ted Kremenek) Date: Thu, 10 Jul 2008 15:11:28 -0700 Subject: [cfe-dev] final distributed clang patch In-Reply-To: <8914b92d0807090514w74383686o7101d4c63372832f@mail.gmail.com> References: <2e837e3a0807070913u449837beue9dfded1180a2ecd@mail.gmail.com> <535E73ED-491C-49BB-B5B7-E43A0B9B770B@apple.com> <8914b92d0807090514w74383686o7101d4c63372832f@mail.gmail.com> Message-ID: <07E20839-7B7C-4947-980B-5BF133EE7A8C@apple.com> On Jul 9, 2008, at 5:14 AM, Csaba Hruska wrote: > TranslationUnit.patch - adds support (de)serialization (from)to (in > memory) buffer. Applied! http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20080707/006452.html From kremenek at apple.com Thu Jul 10 17:45:03 2008 From: kremenek at apple.com (Ted Kremenek) Date: Thu, 10 Jul 2008 15:45:03 -0700 Subject: [cfe-dev] distributed clang patch In-Reply-To: <8914b92d0807101056vb07a3ffk22db0cb0fcc13269@mail.gmail.com> References: <2e837e3a0807070913u449837beue9dfded1180a2ecd@mail.gmail.com> <535E73ED-491C-49BB-B5B7-E43A0B9B770B@apple.com> <8914b92d0807090514w74383686o7101d4c63372832f@mail.gmail.com> <8914b92d0807100128g63f68e1exf8699bc2897d0f2f@mail.gmail.com> <6F5D6BF9-E572-4178-A4F4-5E573AB10662@apple.com> <8914b92d0807101056vb07a3ffk22db0cb0fcc13269@mail.gmail.com> Message-ID: On Jul 10, 2008, at 10:56 AM, Csaba Hruska wrote: > About supporting other compilers by distributed clang: Ted, please > describe you ideas, because i have no idea what's the point of this > thing. Suppose (for whatever reason) that a user wants to use icc/gcc to compile their sources instead of Clang. They can still benefit from the clang-distcc because of the performance advantage of Clang's preprocessor over using the preprocessor typically used by those compilers. Right now, distcc has to fork off a process just to preprocess a file, which also involves writing preprocessed files out to disk. A clang-distcc can have an integrated preprocessor that can be much faster, as it can be linked directly into the same executable (no fork and exec). Much of the scalability of distcc comes with how quickly you can send source code to the slave machines, so even if the end compiler is not Clang there is still a benefit to using clang- distcc over vanilla distcc. Another advantage of allowing other compilers to work with clang- distcc is that you get a *staged* implementation. Instead of requiring Clang to preprocess, parse, and compile in order to get clang-distcc working, you only need the preprocessing to work to get the core distcc functionality in place. This also allows clang-distcc to be used to compile code that Clang cannot: e.g., the full richness of C++. It also allows one to play with the distributed computed core of of clang-distcc without waiting for end-to-end compilation functionality in Clang to be completed. Incorporating more than just preprocessing into clang-distcc simply allows more optimizations, but the end-to-end functionality is already all there. For example, if you also parse the ASTs in clang-distcc , we can parse ASTs and serialize those over the wire (much more compact than preprocessed text). Those serialized ASTs could be compiled using Clang on the remote machine, or pretty-printed out and sent through the other compilers. From csaba.hruska at gmail.com Thu Jul 10 18:56:49 2008 From: csaba.hruska at gmail.com (Csaba Hruska) Date: Fri, 11 Jul 2008 01:56:49 +0200 Subject: [cfe-dev] distributed clang patch In-Reply-To: References: <2e837e3a0807070913u449837beue9dfded1180a2ecd@mail.gmail.com> <535E73ED-491C-49BB-B5B7-E43A0B9B770B@apple.com> <8914b92d0807090514w74383686o7101d4c63372832f@mail.gmail.com> <8914b92d0807100128g63f68e1exf8699bc2897d0f2f@mail.gmail.com> <6F5D6BF9-E572-4178-A4F4-5E573AB10662@apple.com> <8914b92d0807101056vb07a3ffk22db0cb0fcc13269@mail.gmail.com> Message-ID: <8914b92d0807101656p2dda7612y989b98fb99b81de7@mail.gmail.com> 2008/7/11 Ted Kremenek : > > On Jul 10, 2008, at 10:56 AM, Csaba Hruska wrote: > > About supporting other compilers by distributed clang: Ted, please >> describe you ideas, because i have no idea what's the point of this thing. >> > > Suppose (for whatever reason) that a user wants to use icc/gcc to compile > their sources instead of Clang. They can still benefit from the > clang-distcc because of the performance advantage of Clang's preprocessor > over using the preprocessor typically used by those compilers. Right now, > distcc has to fork off a process just to preprocess a file, which also > involves writing preprocessed files out to disk. A clang-distcc can have an > integrated preprocessor that can be much faster, as it can be linked > directly into the same executable (no fork and exec). Much of the > scalability of distcc comes with how quickly you can send source code to the > slave machines, so even if the end compiler is not Clang there is still a > benefit to using clang-distcc over vanilla distcc. > This looks for me a completly different project called: integrating clang preprocessor to (original) distcc because except the used preprocessor remains the original (command line options, network protocol and the whole functionality). This is not bad but i dont think that this is the primary task of this project. In my opinion the main goal to make as fast and scalable and portable(support crosscompialtion) compiler as we can using clang. > > Another advantage of allowing other compilers to work with clang-distcc is > that you get a *staged* implementation. Instead of requiring Clang to > preprocess, parse, and compile in order to get clang-distcc working, you > only need the preprocessing to work to get the core distcc functionality in > place. This also allows clang-distcc to be used to compile code that Clang > cannot: e.g., the full richness of C++. It also allows one to play with the > distributed computed core of of clang-distcc without waiting for end-to-end > compilation functionality in Clang to be completed. > > Incorporating more than just preprocessing into clang-distcc simply allows > more optimizations, but the end-to-end functionality is already all there. > For example, if you also parse the ASTs in clang-distcc , we can parse ASTs > and serialize those over the wire (much more compact than preprocessed > text). Those serialized ASTs could be compiled using Clang on the remote > machine, or pretty-printed out and sent through the other compilers. > This feature is supported by peter neumark's inital version: see -dist-serializelocally command line option. We can improve it with some realtime compression later. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080711/8d3168b6/attachment.html From kremenek at apple.com Thu Jul 10 19:05:41 2008 From: kremenek at apple.com (Ted Kremenek) Date: Thu, 10 Jul 2008 17:05:41 -0700 Subject: [cfe-dev] distributed clang patch In-Reply-To: <8914b92d0807101656p2dda7612y989b98fb99b81de7@mail.gmail.com> References: <2e837e3a0807070913u449837beue9dfded1180a2ecd@mail.gmail.com> <535E73ED-491C-49BB-B5B7-E43A0B9B770B@apple.com> <8914b92d0807090514w74383686o7101d4c63372832f@mail.gmail.com> <8914b92d0807100128g63f68e1exf8699bc2897d0f2f@mail.gmail.com> <6F5D6BF9-E572-4178-A4F4-5E573AB10662@apple.com> <8914b92d0807101056vb07a3ffk22db0cb0fcc13269@mail.gmail.com> <8914b92d0807101656p2dda7612y989b98fb99b81de7@mail.gmail.com> Message-ID: <9BEA9501-2220-4E7F-9E81-4C091A4A556E@apple.com> On Jul 10, 2008, at 4:56 PM, Csaba Hruska wrote: > This looks for me a completly different project called: integrating > clang preprocessor to (original) distcc because except the used > preprocessor remains the original (command line options, network > protocol and the whole functionality). This is not bad but i dont > think that this is the primary task of this project. In my opinion > the main goal to make as fast and scalable and portable(support > crosscompialtion) compiler as we can using clang. Of course our interest is making a great distcc for clang. My main meta-point was that by supporting other compilers for subtasks of the compilation work you can stage more of the implementation without relying on everything in Clang to be working perfectly. And despite Argiris great work on C++ parsing, full support for C++ compilation is a long way off, so supporting other compilers for this task might be a huge win for adoption of a new distcc. Also, it's better to get measurements early on where the performance issues are because that effects fundamental aspects of the design. A rapid evolution of the distcc design with testing and real numbers will not only make the new distcc both faster and more scalable (per your goals) but also potentially more stable and usable at an earlier stage. From csaba.hruska at gmail.com Thu Jul 10 19:36:23 2008 From: csaba.hruska at gmail.com (Csaba Hruska) Date: Fri, 11 Jul 2008 02:36:23 +0200 Subject: [cfe-dev] distributed clang patch In-Reply-To: <9BEA9501-2220-4E7F-9E81-4C091A4A556E@apple.com> References: <2e837e3a0807070913u449837beue9dfded1180a2ecd@mail.gmail.com> <8914b92d0807090514w74383686o7101d4c63372832f@mail.gmail.com> <8914b92d0807100128g63f68e1exf8699bc2897d0f2f@mail.gmail.com> <6F5D6BF9-E572-4178-A4F4-5E573AB10662@apple.com> <8914b92d0807101056vb07a3ffk22db0cb0fcc13269@mail.gmail.com> <8914b92d0807101656p2dda7612y989b98fb99b81de7@mail.gmail.com> <9BEA9501-2220-4E7F-9E81-4C091A4A556E@apple.com> Message-ID: <8914b92d0807101736x161ea9b7v106499cc50cd7d6f@mail.gmail.com> 2008/7/11 Ted Kremenek : > > On Jul 10, 2008, at 4:56 PM, Csaba Hruska wrote: > > This looks for me a completly different project called: integrating clang >> preprocessor to (original) distcc because except the used preprocessor >> remains the original (command line options, network protocol and the whole >> functionality). This is not bad but i dont think that this is the primary >> task of this project. In my opinion the main goal to make as fast and >> scalable and portable(support crosscompialtion) compiler as we can using >> clang. >> > > Of course our interest is making a great distcc for clang. My main > meta-point was that by supporting other compilers for subtasks of the > compilation work you can stage more of the implementation without relying on > everything in Clang to be working perfectly. And despite Argiris great work > on C++ parsing, full support for C++ compilation is a long way off, so > supporting other compilers for this task might be a huge win for adoption of > a new distcc. > > Also, it's better to get measurements early on where the performance issues > are because that effects fundamental aspects of the design. A rapid > evolution of the distcc design with testing and real numbers will not only > make the new distcc both faster and more scalable (per your goals) but also > potentially more stable and usable at an earlier stage. > I agree that benchmarking is important to find the weak design points and I'm also curious about performance results. I'll do some benchmark after when i finish the astconsumer lib and get the new driver code. My main problem is that I cant imagine how we can support external compilers without messing up the current design and without reimplement the original distcc. Distributed clang server's goal is support compilation natively without executing external programs. Or if you think to support the client side, (new clang distcc client with original distcc server case) then we have to reimplement distcc's protocol, including ssl support. In this case its far much easy to patch the original distcc client to include and use clang's preprocessor natively. I'd like to focus on clang specific stuff. Ex: I can imagine an AST mege function what can support precompiled headers, or can be used to store the already parsed and semachecked headers and reuse it later from a Database. This means one file (header) is parsed and semantically checked only one time. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080711/310afb30/attachment.html From kremenek at apple.com Thu Jul 10 19:54:25 2008 From: kremenek at apple.com (Ted Kremenek) Date: Thu, 10 Jul 2008 17:54:25 -0700 Subject: [cfe-dev] distributed clang patch In-Reply-To: <8914b92d0807101736x161ea9b7v106499cc50cd7d6f@mail.gmail.com> References: <2e837e3a0807070913u449837beue9dfded1180a2ecd@mail.gmail.com> <8914b92d0807090514w74383686o7101d4c63372832f@mail.gmail.com> <8914b92d0807100128g63f68e1exf8699bc2897d0f2f@mail.gmail.com> <6F5D6BF9-E572-4178-A4F4-5E573AB10662@apple.com> <8914b92d0807101056vb07a3ffk22db0cb0fcc13269@mail.gmail.com> <8914b92d0807101656p2dda7612y989b98fb99b81de7@mail.gmail.com> <9BEA9501-2220-4E7F-9E81-4C091A4A556E@apple.com> <8914b92d0807101736x161ea9b7v106499cc50cd7d6f@mail.gmail.com> Message-ID: On Jul 10, 2008, at 5:36 PM, Csaba Hruska wrote: > My main problem is that I cant imagine how we can support external > compilers without messing up the current design and without > reimplement the original distcc. Having the option to use other compilers would obviously be only for a subset of the ASTConsumers. For example, for the ASTConsumers that implement compilation, -fsyntax-only, etc., a fork and exec instead of running the equivalent Clang consumer seems like a reasonable solution. > Distributed clang server's goal is support compilation natively > without executing external programs. Don't conflate implementation design with project goals. Performance and stability are the goals. How this is accomplished can very well involve executing external programs. Obviously we believe that much of the performance win will come from *not* doing this, but again supporting other compilers makes the system far more testable and encourages more adoption. > Or if you think to support the client side, (new clang distcc client > with original distcc server case) then we have to reimplement > distcc's protocol, including ssl support. I see no reason to be compatible with the original distcc server or its protocol. I'm not fluent in the distributed computing design used by distcc, but I imagine there are more advanced techniques available. Good support for load balancing, efficient use of the network, etc., are all things that we want to be able to tackle. My goal is not to re-implement the current distcc, it's to build a better one that takes advantage of the features of Clang (be it the integrated preprocessor, its compilation features, serialization of ASTs, or whatever). I'm a big believer in Clang's future, and having unrivaled distributed compilation performance is my hope hope for a clang-distcc. I believe that having limited support to do compilation with other compilers is complementary to this goal. > In this case its far much easy to patch the original distcc client > to include and use clang's preprocessor natively. > I'd like to focus on clang specific stuff. Absolutely. > Ex: I can imagine an AST mege function what can support precompiled > headers, or can be used to store the already parsed and semachecked > headers and reuse it later from a Database. I see these as advanced features. Don't get me wrong; I'm excited about them too. What I'm talking about is getting a good basic distcc working first. What has been implemented right now is a good start towards this goal, but the overall design needs to be more modular (e.g., using a library for ASTConsumers, etc.), the distributed computing core can go a lot further without worrying about things like PCH, etc. Using the clang preprocessor even when the employed compiler is not Clang is a good incremental step that requires much of the boilerplate stuff to be working, and allows experimentation with different performance knobs. I don't think what I'm talking about will take years of work; I just think it's the first logical step. From nikita at zhuk.fi Fri Jul 11 00:17:34 2008 From: nikita at zhuk.fi (Nikita Zhuk) Date: Fri, 11 Jul 2008 08:17:34 +0300 Subject: [cfe-dev] A tool for generating reduced headers for test cases (delta debugging) In-Reply-To: <17600DC9-1404-4E5A-8700-F94772968384@apple.com> References: <80EC12FA-D4B8-4B87-B819-09E6D2A13AD0@zhuk.fi> <9ACE8734-E225-4E1C-BE53-F8BD55B3406A@apple.com> <17600DC9-1404-4E5A-8700-F94772968384@apple.com> Message-ID: On 10.7.2008, at 0.35, Ted Kremenek wrote: > I also saw that Nuno posted some scripts. Hopefully from all these > scripts you'll find something that works for you. If these scripts > prove useful, we should post them to the Clang website. I've been able to reduce headers in a simple test case with detect_error.pl and reduce.pl scripts very easily (some manual clean- up of result source code was required, but it was pretty minor), so at least for me those scripts were useful. I've submitted the test case as bug 2542 (NSAnimation self-ownership). From kremenek at apple.com Fri Jul 11 00:50:31 2008 From: kremenek at apple.com (Ted Kremenek) Date: Thu, 10 Jul 2008 22:50:31 -0700 Subject: [cfe-dev] A tool for generating reduced headers for test cases (delta debugging) In-Reply-To: References: <80EC12FA-D4B8-4B87-B819-09E6D2A13AD0@zhuk.fi> <9ACE8734-E225-4E1C-BE53-F8BD55B3406A@apple.com> <17600DC9-1404-4E5A-8700-F94772968384@apple.com> Message-ID: <7CAAC126-19F5-4D37-860F-1AC4FF01E9BB@apple.com> On Jul 10, 2008, at 10:17 PM, Nikita Zhuk wrote: > On 10.7.2008, at 0.35, Ted Kremenek wrote: > >> I also saw that Nuno posted some scripts. Hopefully from all these >> scripts you'll find something that works for you. If these scripts >> prove useful, we should post them to the Clang website. > > I've been able to reduce headers in a simple test case with > detect_error.pl and reduce.pl scripts very easily Cool! > (some manual clean-up of result source code was required, but it was > pretty minor), I have to do this every time as well. I'm sure that cleanup work could be automated one day as well. > I've submitted the test case as bug 2542 (NSAnimation self- > ownership). Wonderful test cases! I've posted some questions on the Bugzilla report. From clattner at apple.com Fri Jul 11 12:12:09 2008 From: clattner at apple.com (Chris Lattner) Date: Fri, 11 Jul 2008 10:12:09 -0700 Subject: [cfe-dev] Unravelling i-c-e + the gnu mess In-Reply-To: References: <2A4A05CE-D13A-4617-B8D1-B4C3B563927A@apple.com> Message-ID: <3BA5D146-E781-4E05-BC62-D9CFFEE36D09@apple.com> On Jul 9, 2008, at 4:03 PM, Eli Friedman wrote: > This is where it get really messy... the issue is that saying that > something is an integer constant expression has indirect effects in > some cases. Yeah, I know :(. Enabling extensions will change how code is sema'd. Unfortunately, I don't think this is avoidable. > Non-ICE array bounds indicate a VLA, and the > compatibility rules for those are different from those for constant > arrays. A conditional expression with a null pointer constant can > silently end up with a different type from an conditional with a > pointer that happens to evaluate to zero. These are edge cases, but > -pedantic shouldn't affect semantics. I agree... unfortunately, it does with GCC. GCC also handles enums differently in some cases when -pedantic is enabled. > I think the right approach is what we're doing in > Sema::TryFixInvalidVariablyModifiedType: if we run into a situation > where we print a warning/error, but gcc accepts the code, try to > recover at the point where we would print the diagnostic. > > If it's convenient, we could add a "RequireIntegerConstantExpr" method > which does roughly "if (Expr->ICE()) return val; if > (Expr->TryEvaluate()) {pedwarn(); return val;} error(); return > failure;". > > Downsides to this approach: it's possible it will let stuff slip by > without a warning in non-pedantic mode that gcc wouldn't accept, and > this will leave constructs like the glibc tgmath.h broken. Yeah, another way to say this is that some real code *depends* on GCC's mis-parsing code. For example, the "generous" null-pointer- constant case is needed in some situations. > On a related note, I'm considering rewriting > Expr::isIntegerConstantExpression() to delegate actual calculation to > Expr::TryEvaluate() at some point, to reduce code duplication. Ok! -Chris From eli.friedman at gmail.com Fri Jul 11 20:15:10 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Fri, 11 Jul 2008 18:15:10 -0700 Subject: [cfe-dev] Unravelling i-c-e + the gnu mess In-Reply-To: <3BA5D146-E781-4E05-BC62-D9CFFEE36D09@apple.com> References: <2A4A05CE-D13A-4617-B8D1-B4C3B563927A@apple.com> <3BA5D146-E781-4E05-BC62-D9CFFEE36D09@apple.com> Message-ID: On Fri, Jul 11, 2008 at 10:12 AM, Chris Lattner wrote: > On Jul 9, 2008, at 4:03 PM, Eli Friedman wrote: >> >> This is where it get really messy... the issue is that saying that >> something is an integer constant expression has indirect effects in >> some cases. > > Yeah, I know :(. Enabling extensions will change how code is sema'd. > Unfortunately, I don't think this is avoidable. We *really* want to avoid this if at all possible. For issues affecting system headers, this merely adds one more step to the steps to reproduce: "add -pedantic to the clang commandline". And it's extremely unintuitive. >> Non-ICE array bounds indicate a VLA, and the >> compatibility rules for those are different from those for constant >> arrays. A conditional expression with a null pointer constant can >> silently end up with a different type from an conditional with a >> pointer that happens to evaluate to zero. These are edge cases, but >> -pedantic shouldn't affect semantics. > > I agree... unfortunately, it does with GCC. GCC also handles enums > differently in some cases when -pedantic is enabled. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15236? Code depending on that isn't even compatible with gcc without -pedantic, so I don't think we need to worry about that. >> I think the right approach is what we're doing in >> Sema::TryFixInvalidVariablyModifiedType: if we run into a situation >> where we print a warning/error, but gcc accepts the code, try to >> recover at the point where we would print the diagnostic. >> >> If it's convenient, we could add a "RequireIntegerConstantExpr" method >> which does roughly "if (Expr->ICE()) return val; if >> (Expr->TryEvaluate()) {pedwarn(); return val;} error(); return >> failure;". >> >> Downsides to this approach: it's possible it will let stuff slip by >> without a warning in non-pedantic mode that gcc wouldn't accept, and >> this will leave constructs like the glibc tgmath.h broken. > > Yeah, another way to say this is that some real code *depends* on GCC's > mis-parsing code. For example, the "generous" null-pointer-constant case is > needed in some situations. The only code which can't be fixed using my approach is code which depends on types being resolved in a non-compliant way. The only such code we've run into so far is glibc's tgmath.h. However, since that's a system header, it can't be fixed in any way that depends on the compiler flags. So your proposal doesn't actually solve any more known broken cases than mine does. If we really do end up having to do something like your proposal, it at least shouldn't depend on the -pedantic flag. This might be a case where should distinguish between c99 and gnu99 modes. -Eli From wilsonkk at shaw.ca Sat Jul 12 01:07:37 2008 From: wilsonkk at shaw.ca (Kelly W) Date: Sat, 12 Jul 2008 00:07:37 -0600 Subject: [cfe-dev] Is __attribute(weak) supposed to fail? Message-ID: <7247it$2csot@pd2mo1so-svcs.prod.shaw.ca> Hello all, Just wondering if '__attribute(weak)' is supposed to fail in the Verifier due to it not being supported at this point for Linux? I checked around with Google and looked through the code a little.I can see weak support converted to objc_gc(weak) for Darwin and Solaris, but nothing for Linux. I was compiling libxml2 and the Verifier didn't like '__attribute(weak);' for an extern function declaration, so I thought I would ask. Thanks, K.Wilson P.S. I can just stick in some dummy functions for the weak functions (like in the test/CodeGen/attributes.c file) and I get past the Verifier but then llvm-ld gets into an infinite loop. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080712/42c3efc1/attachment.html From echristo at apple.com Sat Jul 12 02:38:59 2008 From: echristo at apple.com (Eric Christopher) Date: Sat, 12 Jul 2008 00:38:59 -0700 Subject: [cfe-dev] Is __attribute(weak) supposed to fail? In-Reply-To: <7247it$2csot@pd2mo1so-svcs.prod.shaw.ca> References: <7247it$2csot@pd2mo1so-svcs.prod.shaw.ca> Message-ID: <81105D67-8AAC-46B0-8480-108E77FD4B49@apple.com> On Jul 11, 2008, at 11:07 PM, Kelly W wrote: > Hello all, > > Just wondering if ?__attribute(weak)? is supposed to fail in the > Verifier due to it not being supported at this point for Linux? I > checked around with Google and looked through the code a little?I > can see weak support converted to objc_gc(weak) for Darwin and > Solaris, but nothing for Linux. I was compiling libxml2 and the > Verifier didn?t like ?__attribute(weak);? for an extern function > declaration, so I thought I would ask. > Hunh. It shouldn't be too hard to support - is there a bug for it? If it's supported in some way (objc_gc? weird.) on darwin it should be easy to support on linux. -eric From wilsonkk at shaw.ca Sat Jul 12 06:04:14 2008 From: wilsonkk at shaw.ca (Kelly W) Date: Sat, 12 Jul 2008 05:04:14 -0600 Subject: [cfe-dev] Is __attribute(weak) supposed to fail? In-Reply-To: <81105D67-8AAC-46B0-8480-108E77FD4B49@apple.com> Message-ID: <7247it$2egfl@pd2mo1so-svcs.prod.shaw.ca> Hey Eric, There is no bug filed for this, that I could see. I did get libxml2 to compile without pthread support and 'make tests' worked (though I am apparently missing some test xml files...but at least there were no fatal errors and 'testapi' seemed fine excluding pthread tests). So my question on '__attribute(weak)' still stands, but at least I could get around it. Thanks, K.Wilson -----Original Message----- From: Eric Christopher [mailto:echristo at apple.com] Sent: Saturday, July 12, 2008 1:39 AM To: Kelly W Cc: cfe-dev at cs.uiuc.edu Subject: Re: [cfe-dev] Is __attribute(weak) supposed to fail? On Jul 11, 2008, at 11:07 PM, Kelly W wrote: > Hello all, > > Just wondering if '__attribute(weak)' is supposed to fail in the > Verifier due to it not being supported at this point for Linux? I > checked around with Google and looked through the code a little.I > can see weak support converted to objc_gc(weak) for Darwin and > Solaris, but nothing for Linux. I was compiling libxml2 and the > Verifier didn't like '__attribute(weak);' for an extern function > declaration, so I thought I would ask. > Hunh. It shouldn't be too hard to support - is there a bug for it? If it's supported in some way (objc_gc? weird.) on darwin it should be easy to support on linux. -eric= No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.138 / Virus Database: 270.4.8/1547 - Release Date: 7/11/2008 6:05 PM From krj at rajaratnam.dk Sat Jul 12 08:15:53 2008 From: krj at rajaratnam.dk (Kovarththanan Rajaratnam) Date: Sat, 12 Jul 2008 15:15:53 +0200 Subject: [cfe-dev] Compile errors with MSVC 2005 (SVN revision 53516) Message-ID: Hello, Compiling SVN revision 53516 with MSVC 2005 results in many compile errors similar to this one: --------------- lli.cpp c:\build\llvm\include\llvm\adt\alist.h(41) : error C2535: 'llvm::alist_iterator::alist_iterator(NodeIterT)' : member function already defined or declared c:\build\llvm\include\llvm\adt\alist.h(40) : see declaration of 'llvm::alist_iterator::alist_iterator' c:\build\llvm\include\llvm\adt\alist.h(90) : see reference to class template instantiation 'llvm::alist_iterator' being compiled --------------- I'm using the llvm/win32/clang.sln project to build clang. Is this the correct way to do so? -- Best Regards Kovarththanan Rajaratnam From cedric.venet at laposte.net Sat Jul 12 10:58:54 2008 From: cedric.venet at laposte.net (=?iso-8859-1?Q?C=E9dric_Venet?=) Date: Sat, 12 Jul 2008 17:58:54 +0200 Subject: [cfe-dev] Compile errors with MSVC 2005 (SVN revision 53516) In-Reply-To: References: Message-ID: <00c201c8e438$306b77b0$91426710$@venet@laposte.net> > > Hello, > > Compiling SVN revision 53516 with MSVC 2005 results in many compile > errors similar to this one: > [...] > I'm using the llvm/win32/clang.sln project to build clang. Is this the > correct way to do so? Yes, but llvm is broken for VC2005 it seems. In llvm/adt/alist.h: There is two constructor and in some case VS complain alist_iterator(NodeIterT NI) : NodeIter(NI) {} alist_iterator(pointer EP) : NodeIter(NodeTy::getNode(EP)) {} at first I was thinking it was because NodeIterT and pointer resolved to the same type but doing some metaprogramming to remove one of the constructor in this special case don't seems to work. In fact it seems they never are the same type. So I don't understand what is the problem. And the error message don't have the type nor the position of the instantiation error... really strange. I suppose you can try to revert llvm to previous 53209 (53210 added the file on july, 8th), it should/may work. It seems Ted Kremenek compiled it ok with one unknow version of VS. Ted? Was is VS2008 or VS2005sp1 or has it been broken since rev53432? Regards, C?dric From clattner at apple.com Sat Jul 12 11:31:32 2008 From: clattner at apple.com (Chris Lattner) Date: Sat, 12 Jul 2008 09:31:32 -0700 Subject: [cfe-dev] Is __attribute(weak) supposed to fail? In-Reply-To: <7247it$2csot@pd2mo1so-svcs.prod.shaw.ca> References: <7247it$2csot@pd2mo1so-svcs.prod.shaw.ca> Message-ID: On Jul 11, 2008, at 11:07 PM, Kelly W wrote: > Hello all, > > Just wondering if ?__attribute(weak)? is supposed to fail in the > Verifier due to it not being supported at this point for Linux? No, it works fine with llvm-gcc. > like ?__attribute(weak);? for an extern function declaration, so I > thought I would ask. > The weak attribute does two different things depending on context: 1. on a function with a definition, it allows the body to be overridden 2. on a function prototype, it makes the function "optional" and makes it resolve to a null pointer if not linked into the app. The former is llvm::GlobalValue::WeakLinkage, the later is ..::ExternalWeakLinkage. Clang probably just has the later confused with the former. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080712/fed4643b/attachment.html From kremenek at apple.com Sat Jul 12 11:53:36 2008 From: kremenek at apple.com (Ted Kremenek) Date: Sat, 12 Jul 2008 09:53:36 -0700 Subject: [cfe-dev] Compile errors with MSVC 2005 (SVN revision 53516) In-Reply-To: <00c201c8e438$306b77b0$91426710$%venet@laposte.net> References: <00c201c8e438$306b77b0$91426710$%venet@laposte.net> Message-ID: <62596857-C3FB-488F-B3C5-25785BF86009@apple.com> On Jul 12, 2008, at 8:58 AM, C?dric Venet wrote: >> >> Hello, >> >> Compiling SVN revision 53516 with MSVC 2005 results in many compile >> errors similar to this one: >> [...] >> I'm using the llvm/win32/clang.sln project to build clang. Is this >> the >> correct way to do so? > > Yes, but llvm is broken for VC2005 it seems. > > In llvm/adt/alist.h: > There is two constructor and in some case VS complain > > alist_iterator(NodeIterT NI) : NodeIter(NI) {} > alist_iterator(pointer EP) : NodeIter(NodeTy::getNode(EP)) {} > > at first I was thinking it was because NodeIterT and pointer > resolved to the > same type but doing some metaprogramming to remove one of the > constructor in > this special case don't seems to work. In fact it seems they never > are the > same type. So I don't understand what is the problem. And the error > message > don't have the type nor the position of the instantiation error... > really > strange. > > I suppose you can try to revert llvm to previous 53209 (53210 added > the file > on july, 8th), it should/may work. It seems Ted Kremenek compiled it > ok with > one unknow version of VS. Ted? Was is VS2008 or VS2005sp1 or has it > been > broken since rev53432? I've seen this problem as well. I encountered a series of VC++ errors with alist and ilist with regards to typedefs being private (and fixed those), but I hit this same problem and was still in the process of diagnosing it. I didn't have a chance to dive into this further on Friday or today because I am away from a Windows machine. I am using VS 2005. FWIW, VC++ has far more limited template support than GCC does. When I was writing the serialization library (for generic object serialization; this is used in Clang), I had to be careful of the use of things like member templates in templated classes because I would hit weird limitations with VC++. It's entirely possible that parts of alist need to be rewritten in order for it to work on VC++. The changes to (or rather the creation of) alist I think are very recent (I believe this is Dan Gohman's work). I've CC'ed him on this message in case he has any ideas of what an easy fix would be, since he's the one most familiar with that code. From akyrtzi at gmail.com Sat Jul 12 15:05:52 2008 From: akyrtzi at gmail.com (Argiris Kirtzidis) Date: Sat, 12 Jul 2008 13:05:52 -0700 Subject: [cfe-dev] Compile errors with MSVC 2005 (SVN revision 53516) In-Reply-To: <62596857-C3FB-488F-B3C5-25785BF86009@apple.com> References: <00c201c8e438$306b77b0$91426710$%venet@laposte.net> <62596857-C3FB-488F-B3C5-25785BF86009@apple.com> Message-ID: <48790EA0.9030908@gmail.com> If you change alist_iterator(pointer EP) : NodeIter(NodeTy::getNode(EP)) {} to alist_iterator(ValueT *EP) : NodeIter(NodeTy::getNode(EP)) {} It will compile fine. Not sure if this is definitely the right fix, though... -Argiris From cedric.venet at laposte.net Sat Jul 12 12:20:54 2008 From: cedric.venet at laposte.net (=?iso-8859-1?Q?C=E9dric_Venet?=) Date: Sat, 12 Jul 2008 19:20:54 +0200 Subject: [cfe-dev] Compile errors with MSVC 2005 (SVN revision 53516) In-Reply-To: <48790EA0.9030908@gmail.com> References: <00c201c8e438$306b77b0$91426710$%venet@laposte.net> <62596857-C3FB-488F-B3C5-25785BF86009@apple.com> <48790EA0.9030908@gmail.com> Message-ID: <00d001c8e443$a4ebfcd0$eec3f670$@venet@laposte.net> > > > If you change > > alist_iterator(pointer EP) : NodeIter(NodeTy::getNode(EP)) {} > > to > > alist_iterator(ValueT *EP) : NodeIter(NodeTy::getNode(EP)) {} > > It will compile fine. Yes, I just changed typedef typename super::pointer pointer; to typedef ValueT* pointer; and it work. Before it was referring to bidirectional_iterator::pointer which is std::iterator::pointer which with the STL of VC++2005 is template struct iterator : public _Iterator_base { // base type for all iterator classes typedef _Category iterator_category; typedef _Ty value_type; typedef _Diff difference_type; typedef _Diff distance_type; // retained typedef _Pointer pointer; typedef _Reference reference; }; So it is just doing manually what the compiler should do. I don't think this will break with any existing STL implementation, someone should commit a patch at least as temporary fix. -- C?dric From kremenek at apple.com Sat Jul 12 13:02:21 2008 From: kremenek at apple.com (Ted Kremenek) Date: Sat, 12 Jul 2008 11:02:21 -0700 Subject: [cfe-dev] Compile errors with MSVC 2005 (SVN revision 53516) In-Reply-To: <00d001c8e443$a4ebfcd0$eec3f670$%venet@laposte.net> References: <00c201c8e438$306b77b0$91426710$%venet@laposte.net> <62596857-C3FB-488F-B3C5-25785BF86009@apple.com> <48790EA0.9030908@gmail.com> <00d001c8e443$a4ebfcd0$eec3f670$%venet@laposte.net> Message-ID: <5088875C-D60A-4A1F-94FE-9F5D11608BF4@apple.com> On Jul 12, 2008, at 10:20 AM, C?dric Venet wrote: > Yes, I just changed > typedef typename super::pointer pointer; > to > typedef ValueT* pointer; Incidentally, does the following work: change: typedef typename super::pointer pointer; typedef typename super::reference reference; to: typedef typename bidirectional_iterator::pointer pointer typedef typename bidirectional_iterator::reference reference If that worked, it would obviate the need to make an assumption on how bidirectional_iterator defines "pointer" and "reference". From cedric.venet at laposte.net Sat Jul 12 13:17:48 2008 From: cedric.venet at laposte.net (=?iso-8859-1?Q?C=E9dric_Venet?=) Date: Sat, 12 Jul 2008 20:17:48 +0200 Subject: [cfe-dev] Compile errors with MSVC 2005 (SVN revision 53516) In-Reply-To: <5088875C-D60A-4A1F-94FE-9F5D11608BF4@apple.com> References: <00c201c8e438$306b77b0$91426710$%venet@laposte.net> <62596857-C3FB-488F-B3C5-25785BF86009@apple.com> <48790EA0.9030908@gmail.com> <00d001c8e443$a4ebfcd0$eec3f670$%venet@laposte.net> <5088875C-D60A-4A1F-94FE-9F5D11608BF4@apple.com> Message-ID: <00d101c8e44b$979c4460$c6d4cd20$@venet@laposte.net> > change: > > typedef typename super::pointer pointer; > > to: > > typedef typename bidirectional_iterator::pointer > pointer This does not work, I tried it first. Even when I modify bidirectional_iterator by adding a public typedef to std::iterator<>::pointer directly in the class... On the other hand I remember reading that the way the std::allocator is defined in C++03, you don't have much choice for defining pointer. From kremenek at apple.com Sat Jul 12 13:30:17 2008 From: kremenek at apple.com (Ted Kremenek) Date: Sat, 12 Jul 2008 11:30:17 -0700 Subject: [cfe-dev] Compile errors with MSVC 2005 (SVN revision 53516) In-Reply-To: <00d001c8e443$a4ebfcd0$eec3f670$%venet@laposte.net> References: <00c201c8e438$306b77b0$91426710$%venet@laposte.net> <62596857-C3FB-488F-B3C5-25785BF86009@apple.com> <48790EA0.9030908@gmail.com> <00d001c8e443$a4ebfcd0$eec3f670$%venet@laposte.net> Message-ID: <692BB353-9E58-4AEA-B63C-85B083EC1BA1@apple.com> On Jul 12, 2008, at 10:20 AM, C?dric Venet wrote: > Yes, I just changed > typedef typename super::pointer pointer; > to > typedef ValueT* pointer; I've applied this patch. Hopefully we can find a better workaround. This solution also only goes half way (what to do about "reference"?). From krj at rajaratnam.dk Sat Jul 12 14:53:23 2008 From: krj at rajaratnam.dk (Kovarththanan Rajaratnam) Date: Sat, 12 Jul 2008 21:53:23 +0200 Subject: [cfe-dev] Compile errors with MSVC 2005 (SVN revision 53516) In-Reply-To: <692BB353-9E58-4AEA-B63C-85B083EC1BA1@apple.com> References: <00c201c8e438$306b77b0$91426710$%venet@laposte.net> <62596857-C3FB-488F-B3C5-25785BF86009@apple.com> <48790EA0.9030908@gmail.com> <00d001c8e443$a4ebfcd0$eec3f670$%venet@laposte.net> <692BB353-9E58-4AEA-B63C-85B083EC1BA1@apple.com> Message-ID: <48790BB3.6090501@rajaratnam.dk> Hello, Ted Kremenek wrote: > On Jul 12, 2008, at 10:20 AM, C?dric Venet wrote: > >> Yes, I just changed >> typedef typename super::pointer pointer; >> to >> typedef ValueT* pointer; > > I've applied this patch. Hopefully we can find a better workaround. > This solution also only goes half way (what to do about "reference"?). Thanks to everybody. However, I did run into a few other issues (stale/missing) files. The two attached patches should fix that. -- Best Regards Kovarththanan Rajaratnam -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: remove_machine_debug.diff Url: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080712/d2443b00/attachment.pl -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: add_files.diff Url: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080712/d2443b00/attachment-0001.pl From akyrtzi at gmail.com Sat Jul 12 17:55:41 2008 From: akyrtzi at gmail.com (Argiris Kirtzidis) Date: Sat, 12 Jul 2008 15:55:41 -0700 Subject: [cfe-dev] C++ classes support (GSoC project) progress report Message-ID: <4879366D.1010704@gmail.com> Hi, These are some details about my GSoC project for C++ classes support, what has been delivered and what is coming next, for anyone interested: Implemented parsing and semantic analysis support (type checking, AST building) for basic C++ classes; to be more specific, classes with: -nested types (nested classes, typedefs, enums) -static and non-static data members -static and non-static member functions -inline function definitions -access specifiers Additional features: -use of 'this' pointer -function local classes This C++ class test case is a good indicator of what is currently supported: https://llvm.org/svn/llvm-project/cfe/trunk/test/Sema/cxx-class.cpp Coming next: -scope specifier for namespaces and classes: namespace N { struct C { static int x; }; } void f() { N::C::x = 0; } -out-of-line method definitions class C { void f(); }; void C::f() {} -member access control: class C { private: int x; }; void f() { C c; c.x = 0; // error: 'x' is private } Beyond the GSoC project, I intend to continue improving the C++ classes support, such as: -support for inheritance: -member name lookup that takes into account inheritance chains -virtual functions -Argiris From krj at rajaratnam.dk Sat Jul 12 14:53:23 2008 From: krj at rajaratnam.dk (Kovarththanan Rajaratnam) Date: Sat, 12 Jul 2008 21:53:23 +0200 Subject: [cfe-dev] Compile errors with MSVC 2005 (SVN revision 53516) In-Reply-To: <692BB353-9E58-4AEA-B63C-85B083EC1BA1@apple.com> References: <00c201c8e438$306b77b0$91426710$%venet@laposte.net> <62596857-C3FB-488F-B3C5-25785BF86009@apple.com> <48790EA0.9030908@gmail.com> <00d001c8e443$a4ebfcd0$eec3f670$%venet@laposte.net> <692BB353-9E58-4AEA-B63C-85B083EC1BA1@apple.com> Message-ID: <48790BB3.6090501@rajaratnam.dk> Hello, Ted Kremenek wrote: > On Jul 12, 2008, at 10:20 AM, C?dric Venet wrote: > >> Yes, I just changed >> typedef typename super::pointer pointer; >> to >> typedef ValueT* pointer; > > I've applied this patch. Hopefully we can find a better workaround. > This solution also only goes half way (what to do about "reference"?). Thanks to everybody. However, I did run into a few other issues (stale/missing) files. The two attached patches should fix that. -- Best Regards Kovarththanan Rajaratnam -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: remove_machine_debug.diff Url: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080712/d2443b00/attachment-0006.pl -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: add_files.diff Url: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080712/d2443b00/attachment-0007.pl From kremenek at apple.com Sun Jul 13 12:35:20 2008 From: kremenek at apple.com (Ted Kremenek) Date: Sun, 13 Jul 2008 10:35:20 -0700 Subject: [cfe-dev] Compile errors with MSVC 2005 (SVN revision 53516) In-Reply-To: <48790BB3.6090501@rajaratnam.dk> References: <00c201c8e438$306b77b0$91426710$%venet@laposte.net> <62596857-C3FB-488F-B3C5-25785BF86009@apple.com> <48790EA0.9030908@gmail.com> <00d001c8e443$a4ebfcd0$eec3f670$%venet@laposte.net> <692BB353-9E58-4AEA-B63C-85B083EC1BA1@apple.com> <48790BB3.6090501@rajaratnam.dk> Message-ID: I checked with Cedric and he committed the appropriate fix. Apparently cfe-commits is having problems, as I couldn't tell that the patch was applied until doing an svn update. On Jul 12, 2008, at 12:53 PM, Kovarththanan Rajaratnam wrote: > Hello, > > Ted Kremenek wrote: > > On Jul 12, 2008, at 10:20 AM, C?dric Venet wrote: > > > >> Yes, I just changed > >> typedef typename super::pointer pointer; > >> to > >> typedef ValueT* pointer; > > > > I've applied this patch. Hopefully we can find a better workaround. > > This solution also only goes half way (what to do about > "reference"?). > > Thanks to everybody. > > However, I did run into a few other issues (stale/missing) files. > > The two attached patches should fix that. > > -- > Best Regards > Kovarththanan Rajaratnam > Index: win32/CodeGen/CodeGen.vcproj > =================================================================== > --- win32/CodeGen/CodeGen.vcproj (revision 53518) > +++ win32/CodeGen/CodeGen.vcproj (working copy) > @@ -377,10 +377,6 @@ > > > > - RelativePath="..\..\lib\CodeGen\MachineDebugInfoDesc.cpp" > - > > - > - RelativePath="..\..\lib\CodeGen\MachineDominators.cpp" > > > > Index: win32/clangAnalysis/clangAnalysis.vcproj > =================================================================== > --- win32/clangAnalysis/clangAnalysis.vcproj (revision 53516) > +++ win32/clangAnalysis/clangAnalysis.vcproj (working copy) > @@ -159,6 +159,10 @@ > > > > + RelativePath="..\..\lib\Analysis\BasicStore.cpp" > + > > + > + RelativePath="..\..\lib\Analysis\BasicValueFactory.cpp" > > > > @@ -175,6 +179,10 @@ > > > > + RelativePath="..\..\lib\Analysis\CheckObjCInstMethSignature.cpp" > + > > + > + RelativePath="..\..\lib\Analysis\DeadStores.cpp" > > > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From mymlreader at gmail.com Mon Jul 14 03:16:49 2008 From: mymlreader at gmail.com (Zhongxing Xu) Date: Mon, 14 Jul 2008 16:16:49 +0800 Subject: [cfe-dev] svn does not compile Message-ID: <4619993f0807140116h70ea8f1eq242dbffe1747c7dd@mail.gmail.com> svn rev 53524 Compilation fails: CGObjCEtoile.cpp: In member function 'virtual llvm::Function*::CGObjCEtoile::MethodPreamble(const std::string&, const std::string&, const std::string&, const llvm::Type*, const llvm::Type*, const llvm::Type**, unsigned int, bool, bool)': CGObjCEtoile.cpp:240: error: ambiguous overload for 'operator[]' in 'AI[0]' CGObjCEtoile.cpp:240: note: candidates are: operator[](llvm::Argument*, int) /home/xzx/llvm/include/llvm/ADT/ilist.h:98: note: void llvm::ilist_iterator::operator[](unsigned int) [with NodeTy = llvm::Argument] /home/xzx/llvm/include/llvm/ADT/ilist.h:99: note: void llvm::ilist_iterator::operator[](unsigned int) const [with NodeTy = llvm::Argument] CGObjCEtoile.cpp:241: error: ambiguous overload for 'operator[]' in 'AI[1]' CGObjCEtoile.cpp:241: note: candidates are: operator[](llvm::Argument*, int) /home/xzx/llvm/include/llvm/ADT/ilist.h:98: note: void llvm::ilist_iterator::operator[](unsigned int) [with NodeTy = llvm::Argument] /home/xzx/llvm/include/llvm/ADT/ilist.h:99: note: void llvm::ilist_iterator::operator[](unsigned int) const [with NodeTy = llvm::Argument] make[2]: *** [/home/xzx/llvm/tools/clang/lib/CodeGen/Debug/CGObjCEtoile.o] Error 1 make[2]: Leaving directory `/home/xzx/llvm/tools/clang/lib/CodeGen' make[1]: *** [CodeGen/.makeall] Error 2 make[1]: Leaving directory `/home/xzx/llvm/tools/clang/lib' make: *** [all] Error 1 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080714/6e724d1d/attachment.html From csdavec at swansea.ac.uk Mon Jul 14 03:48:34 2008 From: csdavec at swansea.ac.uk (David Chisnall) Date: Mon, 14 Jul 2008 09:48:34 +0100 Subject: [cfe-dev] svn does not compile In-Reply-To: <4619993f0807140116h70ea8f1eq242dbffe1747c7dd@mail.gmail.com> References: <4619993f0807140116h70ea8f1eq242dbffe1747c7dd@mail.gmail.com> Message-ID: <0363FC4F-A93C-413A-892D-CFC127A25E6C@swan.ac.uk> CGObjCEtoile.cpp is quite badly bit-rotted at this stage. I would recommend deleting it from svn, and I will submit a new version soon. David On 14 Jul 2008, at 09:16, Zhongxing Xu wrote: > svn rev 53524 > > Compilation fails: > > CGObjCEtoile.cpp: In member function 'virtual > llvm::Function*::CGObjCEtoile::MethodPreamble(const > std::string&, const std::string&, const std::string&, const > llvm::Type*, const llvm::Type*, const llvm::Type**, unsigned int, > bool, bool)': > CGObjCEtoile.cpp:240: error: ambiguous overload for 'operator[]' in > 'AI[0]' > CGObjCEtoile.cpp:240: note: candidates are: operator[] > (llvm::Argument*, int) > /home/xzx/llvm/include/llvm/ADT/ilist.h:98: note: > void llvm::ilist_iterator::operator[](unsigned int) [with > NodeTy = llvm::Argument] > /home/xzx/llvm/include/llvm/ADT/ilist.h:99: note: > void llvm::ilist_iterator::operator[](unsigned int) const > [with NodeTy = llvm::Argument] > CGObjCEtoile.cpp:241: error: ambiguous overload for 'operator[]' in > 'AI[1]' > CGObjCEtoile.cpp:241: note: candidates are: operator[] > (llvm::Argument*, int) > /home/xzx/llvm/include/llvm/ADT/ilist.h:98: note: > void llvm::ilist_iterator::operator[](unsigned int) [with > NodeTy = llvm::Argument] > /home/xzx/llvm/include/llvm/ADT/ilist.h:99: note: > void llvm::ilist_iterator::operator[](unsigned int) const > [with NodeTy = llvm::Argument] > make[2]: *** [/home/xzx/llvm/tools/clang/lib/CodeGen/Debug/ > CGObjCEtoile.o] Error 1 > make[2]: Leaving directory `/home/xzx/llvm/tools/clang/lib/CodeGen' > make[1]: *** [CodeGen/.makeall] Error 2 > make[1]: Leaving directory `/home/xzx/llvm/tools/clang/lib' > make: *** [all] Error 1 > > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From mymlreader at gmail.com Mon Jul 14 07:23:50 2008 From: mymlreader at gmail.com (Zhongxing Xu) Date: Mon, 14 Jul 2008 20:23:50 +0800 Subject: [cfe-dev] svn does not compile In-Reply-To: <0363FC4F-A93C-413A-892D-CFC127A25E6C@swan.ac.uk> References: <4619993f0807140116h70ea8f1eq242dbffe1747c7dd@mail.gmail.com> <0363FC4F-A93C-413A-892D-CFC127A25E6C@swan.ac.uk> Message-ID: <4619993f0807140523wc8358c4j36f46bc2c1db165@mail.gmail.com> If the operator[] overloading in ilist.h is commented, it compiles. Where is the ilist::operator[] defined then? I cannot find it in std::iterator. On Mon, Jul 14, 2008 at 4:48 PM, David Chisnall wrote: > CGObjCEtoile.cpp is quite badly bit-rotted at this stage. I would > recommend deleting it from svn, and I will submit a new version soon. > > David > > > On 14 Jul 2008, at 09:16, Zhongxing Xu wrote: > > svn rev 53524 >> >> Compilation fails: >> >> CGObjCEtoile.cpp: In member function 'virtual >> llvm::Function*::CGObjCEtoile::MethodPreamble(const std::string&, >> const std::string&, const std::string&, const llvm::Type*, const >> llvm::Type*, const llvm::Type**, unsigned int, bool, bool)': >> CGObjCEtoile.cpp:240: error: ambiguous overload for 'operator[]' in >> 'AI[0]' >> CGObjCEtoile.cpp:240: note: candidates are: operator[](llvm::Argument*, >> int) >> /home/xzx/llvm/include/llvm/ADT/ilist.h:98: note: void >> llvm::ilist_iterator::operator[](unsigned int) [with NodeTy = >> llvm::Argument] >> /home/xzx/llvm/include/llvm/ADT/ilist.h:99: note: void >> llvm::ilist_iterator::operator[](unsigned int) const [with NodeTy = >> llvm::Argument] >> CGObjCEtoile.cpp:241: error: ambiguous overload for 'operator[]' in >> 'AI[1]' >> CGObjCEtoile.cpp:241: note: candidates are: operator[](llvm::Argument*, >> int) >> /home/xzx/llvm/include/llvm/ADT/ilist.h:98: note: void >> llvm::ilist_iterator::operator[](unsigned int) [with NodeTy = >> llvm::Argument] >> /home/xzx/llvm/include/llvm/ADT/ilist.h:99: note: void >> llvm::ilist_iterator::operator[](unsigned int) const [with NodeTy = >> llvm::Argument] >> make[2]: *** [/home/xzx/llvm/tools/clang/lib/CodeGen/Debug/CGObjCEtoile.o] >> Error 1 >> make[2]: Leaving directory `/home/xzx/llvm/tools/clang/lib/CodeGen' >> make[1]: *** [CodeGen/.makeall] Error 2 >> make[1]: Leaving directory `/home/xzx/llvm/tools/clang/lib' >> make: *** [all] Error 1 >> >> >> _______________________________________________ >> 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/20080714/0ba3a032/attachment.html From mymlreader at gmail.com Mon Jul 14 07:25:48 2008 From: mymlreader at gmail.com (Zhongxing Xu) Date: Mon, 14 Jul 2008 20:25:48 +0800 Subject: [cfe-dev] svn does not compile In-Reply-To: <4619993f0807140523wc8358c4j36f46bc2c1db165@mail.gmail.com> References: <4619993f0807140116h70ea8f1eq242dbffe1747c7dd@mail.gmail.com> <0363FC4F-A93C-413A-892D-CFC127A25E6C@swan.ac.uk> <4619993f0807140523wc8358c4j36f46bc2c1db165@mail.gmail.com> Message-ID: <4619993f0807140525u44852478u20080a82159549a8@mail.gmail.com> > If the operator[] overloading in ilist.h is commented, it compiles. Where > is the ilist::operator[] defined then? > Sorry, where is the ilist_iterator::operator[] defined? My system is Fedora Linux 9. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080714/c1210867/attachment.html From clattner at apple.com Mon Jul 14 13:10:34 2008 From: clattner at apple.com (Chris Lattner) Date: Mon, 14 Jul 2008 11:10:34 -0700 Subject: [cfe-dev] svn does not compile In-Reply-To: <0363FC4F-A93C-413A-892D-CFC127A25E6C@swan.ac.uk> References: <4619993f0807140116h70ea8f1eq242dbffe1747c7dd@mail.gmail.com> <0363FC4F-A93C-413A-892D-CFC127A25E6C@swan.ac.uk> Message-ID: On Jul 14, 2008, at 1:48 AM, David Chisnall wrote: > CGObjCEtoile.cpp is quite badly bit-rotted at this stage. I would > recommend deleting it from svn, and I will submit a new version soon. Done, thanks David, -Chris From kremenek at apple.com Mon Jul 14 13:53:42 2008 From: kremenek at apple.com (Ted Kremenek) Date: Mon, 14 Jul 2008 11:53:42 -0700 Subject: [cfe-dev] Second Annual LLVM Developers' Meeting (second announcement; includes selected talks) Message-ID: <02117E1B-FB7C-4845-97C0-B5A9A96C700D@apple.com> Second Annual LLVM Developers' Meeting August 1, 2008 - Apple Inc. Campus, Cupertino, California, U.S.A. The registration and hotel room block deadline (July 20, 2008) for the second annual LLVM Developers' Meeting is less than one week away! Please register via our website: http://llvm.org/devmtg/register.php This year, the Developers' Meeting will be held this year at Apple Inc.'s main campus in Cupertino, California: http://llvm.org/devmtg Like last year's inaugural meeting, the meeting serves as a forum for both LLVM developers and users to get acquainted, to learn how LLVM is used, and to exchange ideas about LLVM and its (potential) applications. The following talks have been selected: Adobe Image Foundation and Adobe PixelBender: Our Usage of LLVM Chuck Rose III, Adobe Cell Backend Scott Michel, Aerospace Clang Steve Naroff, Apple CodeGen Overview and Focus on SelectionDAGs Dan Gohman, Apple Finding Bugs with Source Code Analysis Ted Kremenek, Apple Building an Efficient JIT with LLVM Nate Begeman, Apple llvm2c - New LLVM Compiler Driver Anton Korobeynikov, Saint Petersburg State University. LLVM Hardware Backend with HW/SW Codesign Toolchain Tim Sander, University Darmstadt Register Allocation Evan Cheng, Apple Targeting the Adobe Flash Virtual Machine with LLVM Scott Peterson, Adobe The VMKit Project - Building a JVM and .Net implementation on top of LLVM Nicolas Geoffray, University of Pierre et Marie Curie, France Building a JIT compiler for PHP in 2 days Nuno Lopes, Instituto Superior Tecnico SVA: Using LLVM to Provide Memory Safety for the Entire Software Stack John Criswell, University of Illinois at Urbana-Champaign We also invite you to sign up for the official Developer Meeting mailing list to be kept informed of updates concerning the meeting: http://lists.cs.uiuc.edu/mailman/listinfo/llvm-devmeeting Last year's inaugural meeting was a success for LLVM and the LLVM community at large. We fully expect that this year's meeting will be an even greater success. Please join us! About LLVM The Low-Level Virtual Machine (LLVM) is a collection of libraries and tools that make it easy to build compilers, optimizers, Just-In-Time code generators, and many other compiler-related programs. LLVM uses a single, language-independent virtual instruction set both as an offline code representation (to communicate code between compiler phases and to run-time systems) and as the compiler internal representation (to analyze and transform programs). This persistent code representation allows a common set of sophisticated compiler techniques to be applied at compile-time, link-time, install-time, run- time, or "idle-time" (between program runs). The strengths of the LLVM infrastructure are its extremely simple design (which makes it easy to understand and use), source-language independence, powerful mid-level optimizer, automated compiler debugging support, extensibility, and its stability and reliability. LLVM is currently being used to host a wide variety of academic research projects and commercial projects. For more information, please visit http://llvm.org. About Clang Clang is a new frontend for C-based languages, targeting support for C, Objective-C, and C++. Like the rest of LLVM, Clang consists of a collection of libraries, making it versatile in its applications. The goal of Clang is to be multipurpose, allowing not only the creation of standalone compilers for C-based languages, but also intelligent IDEs, refactoring tools, source to source translators, static analysis tools, and countless others. Other design goals of Clang include 100% compatibility with GCC and a high quality of implementation that makes Clang fast, scalable, and easy to customize and expand. Clang was announced at last year's Developer Meeting. This year's meeting will include an extensive discussion of Clang and its applications (both currently existing and planned). For more information, please visit http://clang.llvm.org. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080714/f9df5624/attachment.html From filcab at gmail.com Mon Jul 14 13:57:02 2008 From: filcab at gmail.com (Filipe Cabecinhas) Date: Mon, 14 Jul 2008 19:57:02 +0100 Subject: [cfe-dev] svn does not compile In-Reply-To: <0363FC4F-A93C-413A-892D-CFC127A25E6C@swan.ac.uk> References: <4619993f0807140116h70ea8f1eq242dbffe1747c7dd@mail.gmail.com> <0363FC4F-A93C-413A-892D-CFC127A25E6C@swan.ac.uk> Message-ID: <3801D3D0-70E0-4351-99B0-B39B25121B85@gmail.com> On 14 Jul, 2008, at 09:48, David Chisnall wrote: > CGObjCEtoile.cpp is quite badly bit-rotted at this stage. I would > recommend deleting it from svn, and I will submit a new version soon. > > David Ah, nice... I thought it was a problem in my linux box but hadn't had the time to figure it out. Thanks, now clang compiles :-) - Filipe Cabecinhas From wangmp at apple.com Tue Jul 15 00:21:29 2008 From: wangmp at apple.com (Mon P Wang) Date: Mon, 14 Jul 2008 22:21:29 -0700 Subject: [cfe-dev] "generic" address space Message-ID: <46837CCD-429B-45C9-887B-0AA08813796B@apple.com> Hi, In the llvm, I'm adding support for address spaces for builtin functions that take pointers. For example, the front end will generate slightly different code if the incoming pointer to the intrinsic function comes from different address spaces, e.g., @llvm.atomic.load.add.i32.p0i32 // returns i32, i32 ptr to default address space @llvm.atomic.load.add.i32.p11i32 // return i32, i32 ptr to address space 11 To generate this in Clang, I didn't want to require the user to have to specify what specific address spaces a builtin can take, especially if the intrinsic is supported on the address space for a particular machine. So, I added the concept to ASQualType the concept of a "generic" address space that can be used in the parameter type of a function prototype. This concept is used when we checking to see if an argument and a parameter type are compatible. An argument of type pointer to an address space to a Type T1 is compatible with a parameter of type pointer to a generic space to a Type T1. When we get to code generation, we take the type of the argument account to generate the different intrinsic names. I'm also going to change clang to generate an error if the compiler needs to do an implicit cast between to pointers pointing at different address spaces. Typically, this operation doesn't make sense. Note that users can still do explicit cast between address spaces. If you have any comments or suggestions, please let me know. Thanks, -- Mon Ping From eli.friedman at gmail.com Tue Jul 15 00:46:58 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Mon, 14 Jul 2008 22:46:58 -0700 Subject: [cfe-dev] "generic" address space In-Reply-To: <46837CCD-429B-45C9-887B-0AA08813796B@apple.com> References: <46837CCD-429B-45C9-887B-0AA08813796B@apple.com> Message-ID: On Mon, Jul 14, 2008 at 10:21 PM, Mon P Wang wrote: > To generate this in Clang, I didn't want to require the user to have > to specify what specific address spaces a builtin can take, especially > if the intrinsic is supported on the address space for a particular > machine. So, I added the concept to ASQualType the concept of a > "generic" address space that can be used in the parameter type of a > function prototype. This concept is used when we checking to see if > an argument and a parameter type are compatible. I don't really like this approach: you're introducing a fake type that isn't actually usable by user code, which seems messy at best. I think it would be better to handle this like __builtin_shufflevector, where typechecking gets done by a custom validator. > I'm also going to change clang to generate an error if the compiler > needs to do an implicit cast between to pointers pointing at different > address spaces. Typically, this operation doesn't make sense. Note > that users can still do explicit cast between address spaces. I think that's fine; of course, please submit this patch separately. -Eli From monping at apple.com Tue Jul 15 01:36:27 2008 From: monping at apple.com (Mon P Wang) Date: Mon, 14 Jul 2008 23:36:27 -0700 Subject: [cfe-dev] Fwd: "generic" address space References: <16FF20FC-1BAB-4D45-85B2-E90A7593DB8B@apple.com> Message-ID: <3CFB606E-70A2-40CA-9F6D-FF6886153450@apple.com> Forgot to send it to the entire list. Begin forwarded message: > From: Mon P Wang > Date: July 14, 2008 11:22:42 PM PDT > To: Eli Friedman > Subject: Re: [cfe-dev] "generic" address space > > Hi Eli, > > On Jul 14, 2008, at 10:46 PM, Eli Friedman wrote: > >> On Mon, Jul 14, 2008 at 10:21 PM, Mon P Wang >> wrote: >>> To generate this in Clang, I didn't want to require the user to have >>> to specify what specific address spaces a builtin can take, >>> especially >>> if the intrinsic is supported on the address space for a particular >>> machine. So, I added the concept to ASQualType the concept of a >>> "generic" address space that can be used in the parameter type of a >>> function prototype. This concept is used when we checking to see >>> if >>> an argument and a parameter type are compatible. >> >> I don't really like this approach: you're introducing a fake type >> that >> isn't actually usable by user code, which seems messy at best. I >> think it would be better to handle this like __builtin_shufflevector, >> where typechecking gets done by a custom validator. > > What you suggest sounds like a reasonable alternative. I'll take a > look into doing it this way for any built-in of this flavor. > > >>> I'm also going to change clang to generate an error if the compiler >>> needs to do an implicit cast between to pointers pointing at >>> different >>> address spaces. Typically, this operation doesn't make sense. Note >>> that users can still do explicit cast between address spaces. >> >> I think that's fine; of course, please submit this patch separately. > > Sure no problem. > > > Thanks, > -- Mon Ping -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080714/f300dc8f/attachment.html From wangmp at apple.com Tue Jul 15 10:50:19 2008 From: wangmp at apple.com (Mon P Wang) Date: Tue, 15 Jul 2008 08:50:19 -0700 Subject: [cfe-dev] Fwd: "generic" address space In-Reply-To: <3CFB606E-70A2-40CA-9F6D-FF6886153450@apple.com> References: <16FF20FC-1BAB-4D45-85B2-E90A7593DB8B@apple.com> <3CFB606E-70A2-40CA-9F6D-FF6886153450@apple.com> Message-ID: Hi, I took a look at what __buildin_shufflevector does. In that case, it enforces more rules than the type system allow after checking the call. In that vein, what I could do instead of using this weird type is in ActOnCallExpr,when checking the arguments of an intrinsic call, instead of calling CheckSingleAssignmentConstraints I could call my own version, e.g., CheckBuiltinAssignmentConstraints that will allow mismatches between address spaces to go through. How does that sound? -- Mon Ping >> From: Mon P Wang >> Date: July 14, 2008 11:22:42 PM PDT >> To: Eli Friedman >> Subject: Re: [cfe-dev] "generic" address space >> >> Hi Eli, >> >> On Jul 14, 2008, at 10:46 PM, Eli Friedman wrote: >> >>> On Mon, Jul 14, 2008 at 10:21 PM, Mon P Wang >>> wrote: >>>> To generate this in Clang, I didn't want to require the user to >>>> have >>>> to specify what specific address spaces a builtin can take, >>>> especially >>>> if the intrinsic is supported on the address space for a particular >>>> machine. So, I added the concept to ASQualType the concept of a >>>> "generic" address space that can be used in the parameter type of a >>>> function prototype. This concept is used when we checking to >>>> see if >>>> an argument and a parameter type are compatible. >>> >>> I don't really like this approach: you're introducing a fake type >>> that >>> isn't actually usable by user code, which seems messy at best. I >>> think it would be better to handle this like >>> __builtin_shufflevector, >>> where typechecking gets done by a custom validator. >> >> What you suggest sounds like a reasonable alternative. I'll take a >> look into doing it this way for any built-in of this flavor. >> >> >>>> I'm also going to change clang to generate an error if the compiler >>>> needs to do an implicit cast between to pointers pointing at >>>> different >>>> address spaces. Typically, this operation doesn't make sense. >>>> Note >>>> that users can still do explicit cast between address spaces. >>> >>> I think that's fine; of course, please submit this patch separately. >> >> Sure no problem. >> >> >> Thanks, >> -- Mon Ping > > _______________________________________________ > 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/20080715/9d806929/attachment.html From eli.friedman at gmail.com Tue Jul 15 18:16:33 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Tue, 15 Jul 2008 16:16:33 -0700 Subject: [cfe-dev] Fwd: "generic" address space In-Reply-To: References: <16FF20FC-1BAB-4D45-85B2-E90A7593DB8B@apple.com> <3CFB606E-70A2-40CA-9F6D-FF6886153450@apple.com> Message-ID: On Tue, Jul 15, 2008 at 8:50 AM, Mon P Wang wrote: > Hi, > I took a look at what __buildin_shufflevector does. In that case, it > enforces more rules than the type system allow after checking the call. In > that vein, what I could do instead of using this weird type is > in ActOnCallExpr,when checking the arguments of an intrinsic call, instead > of calling > CheckSingleAssignmentConstraints > I could call my own version, e.g., CheckBuiltinAssignmentConstraints that > will allow mismatches between address spaces to go through. How does that > sound? What we do for __builtin_shufflevector does is claim the argument list is completely variable, then check the actual arguments from CheckFunctionCall. What I was thinking is that we could do the same thing for the builtins which can take alternate address spaces, i.e. __sync_*. (Are there any other builtins for which you're planning address space overloading?) That said, your approach could also work, although it doesn't seem as clean to me. -Eli From wangmp at apple.com Tue Jul 15 19:38:47 2008 From: wangmp at apple.com (Mon P Wang) Date: Tue, 15 Jul 2008 17:38:47 -0700 Subject: [cfe-dev] "generic" address space In-Reply-To: References: <16FF20FC-1BAB-4D45-85B2-E90A7593DB8B@apple.com> <3CFB606E-70A2-40CA-9F6D-FF6886153450@apple.com> Message-ID: Hi Eli, On an architecture that support address spaces, any builtins that touches memory would probably need this support. Today, I think it's mostly the sync functions. For a specific architecture, one is likely to add architecture specific built-ins to support some other operations that touches memory and I would like to use the same mechanism (e.g., specialized load/store instructions) to do the check. I rather not specifying that the argument list is completely variable because I think that means that for any such a built-in, we would need to teach clang about that operation and signature. I would prefer to teach clang that some intrinsics can take pointer to any address space but to a specific domain type and get that information from the signature of the intrinsics. I would like to keep clang as clean as possible. The only other possibility that I have though of other than loosing the parameter-argument constraint or the weird type is to generate a different built-in signature for the pointer type base on the address space of the use. I didn't like that choice as it seemed dirty without much benefit. -- Mon Ping On Jul 15, 2008, at 4:16 PM, Eli Friedman wrote: > On Tue, Jul 15, 2008 at 8:50 AM, Mon P Wang wrote: >> Hi, >> I took a look at what __buildin_shufflevector does. In that case, it >> enforces more rules than the type system allow after checking the >> call. In >> that vein, what I could do instead of using this weird type is >> in ActOnCallExpr,when checking the arguments of an intrinsic call, >> instead >> of calling >> CheckSingleAssignmentConstraints >> I could call my own version, e.g., >> CheckBuiltinAssignmentConstraints that >> will allow mismatches between address spaces to go through. How >> does that >> sound? > > What we do for __builtin_shufflevector does is claim the argument list > is completely variable, then check the actual arguments from > CheckFunctionCall. What I was thinking is that we could do the same > thing for the builtins which can take alternate address spaces, i.e. > __sync_*. (Are there any other builtins for which you're planning > address space overloading?) > > That said, your approach could also work, although it doesn't seem as > clean to me. > > -Eli From eli.friedman at gmail.com Tue Jul 15 20:42:55 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Tue, 15 Jul 2008 18:42:55 -0700 Subject: [cfe-dev] "generic" address space In-Reply-To: References: <16FF20FC-1BAB-4D45-85B2-E90A7593DB8B@apple.com> <3CFB606E-70A2-40CA-9F6D-FF6886153450@apple.com> Message-ID: On Tue, Jul 15, 2008 at 5:38 PM, Mon P Wang wrote: > Hi Eli, > > On an architecture that support address spaces, any builtins that touches > memory would probably need this support. Today, I think it's mostly the > sync functions. For a specific architecture, one is likely to add > architecture specific built-ins to support some other operations that > touches memory and I would like to use the same mechanism (e.g., specialized > load/store instructions) to do the check. Ah, I see... I hadn't really considered the arch-specific builtins part. In that case, adding some generic machinery might be appropriate. That said, I've never actually seen an architecture with multiple address spaces, so pointers to any documentation would be helpful. I don't think we should be abusing existing machinery to handle this case; therefore, I think there should be a new kind of AST expression for address-space-overloaded intrinsics. This makes it explicit that there is something unusual going on with the types for such intrinsic calls. -Eli From wangmp at apple.com Wed Jul 16 00:28:47 2008 From: wangmp at apple.com (Mon P Wang) Date: Tue, 15 Jul 2008 22:28:47 -0700 Subject: [cfe-dev] "generic" address space In-Reply-To: References: <16FF20FC-1BAB-4D45-85B2-E90A7593DB8B@apple.com> <3CFB606E-70A2-40CA-9F6D-FF6886153450@apple.com> Message-ID: Hi Eli, Whatever we do, it should be clear when examining the AST that we are matching an address space overloaded intrinsic. I'm not sure what new AST expression tree would make sense. I view it that we have an call expression to an address space overloaded intrinsic function. When we check the argument and parameter of the signature, the normal rules follow except for parameters that can accept different address space. During code generation, the different argument type will generate a slightly different intrinsic function like @llvm.atomic.load.add.i32.p0i32. It is a bit unclear to me what happens with intrinsics that can take any integer width. Looking briefily, it looks like clang will generate an implicit cast for the argument to integer. Do we always generate the 32 bit integer version of these intrinsics? Various DSPs (e.g TI TMS320C30), embedded architectures and GPUs support different address spaces. The Cell processor has local memory accessible only by the SPUs. Nvidia and AMD GPUs typically have different address spaces for things like local or textures. It is difficult to get their ISAs though AMD has released their R600 ISA (http://www.x.org/docs/AMD/r600isa.pdf ). I'll have to look to see what is available publicly. -- Mon Ping On Jul 15, 2008, at 6:42 PM, Eli Friedman wrote: > On Tue, Jul 15, 2008 at 5:38 PM, Mon P Wang wrote: >> Hi Eli, >> >> On an architecture that support address spaces, any builtins that >> touches >> memory would probably need this support. Today, I think it's >> mostly the >> sync functions. For a specific architecture, one is likely to add >> architecture specific built-ins to support some other operations that >> touches memory and I would like to use the same mechanism (e.g., >> specialized >> load/store instructions) to do the check. > > Ah, I see... I hadn't really considered the arch-specific builtins > part. In that case, adding some generic machinery might be > appropriate. That said, I've never actually seen an architecture with > multiple address spaces, so pointers to any documentation would be > helpful. > > I don't think we should be abusing existing machinery to handle this > case; therefore, I think there should be a new kind of AST expression > for address-space-overloaded intrinsics. This makes it explicit that > there is something unusual going on with the types for such intrinsic > calls. > > -Eli -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080715/4fc74c69/attachment.html From eli.friedman at gmail.com Wed Jul 16 00:56:47 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Tue, 15 Jul 2008 22:56:47 -0700 Subject: [cfe-dev] "generic" address space In-Reply-To: References: <16FF20FC-1BAB-4D45-85B2-E90A7593DB8B@apple.com> <3CFB606E-70A2-40CA-9F6D-FF6886153450@apple.com> Message-ID: On Tue, Jul 15, 2008 at 10:28 PM, Mon P Wang wrote: > Hi Eli, > Whatever we do, it should be clear when examining the AST that we are > matching an address space overloaded intrinsic. I'm not sure what new AST > expression tree would make sense. I view it that we have an call expression > to an address space overloaded intrinsic function. When we check the > argument and parameter of the signature, the normal rules follow except for > parameters that can accept different address space. The issue is that the types of the function arguments won't match the type of the call, which would be surprising for most AST consumers. > It is a bit unclear to me what happens with intrinsics that can take any > integer width. Looking briefily, it looks like clang will generate an > implicit cast for the argument to integer. Do we always generate the 32 bit > integer version of these intrinsics? Mmmm, it looks like clang's versions of the __sync_* builtins are broken in that respect. I think some custom logic is needed for the overloading. > Various DSPs (e.g TI TMS320C30), embedded architectures and GPUs support > different address spaces. The Cell processor has local > memory accessible only by the SPUs. Nvidia and AMD GPUs typically have > different address spaces for things like local or textures. It is difficult > to get their ISAs though AMD has released their R600 ISA > (http://www.x.org/docs/AMD/r600isa.pdf). I'll have to look to see what is > available publicly. Hmm, okay... I'm trying to get a feel for what sorts of intrinsics for alternate address spaces we'll want, and for which ones it's useful to overload the address space of the pointer arguments. For example, for the R600 ISA (which I skimmed), I can't think of any intrinsics for which overloading would be useful; it seems like the address spaces are implied by the instruction. Do you have any examples where it would be useful to overload the address space of platform-specific intrinsics? -Eli From clattner at apple.com Wed Jul 16 11:55:29 2008 From: clattner at apple.com (Chris Lattner) Date: Wed, 16 Jul 2008 09:55:29 -0700 Subject: [cfe-dev] "generic" address space In-Reply-To: References: <16FF20FC-1BAB-4D45-85B2-E90A7593DB8B@apple.com> <3CFB606E-70A2-40CA-9F6D-FF6886153450@apple.com> Message-ID: <311CCB01-9628-4A86-957C-CB38D907C4E0@apple.com> On Jul 15, 2008, at 10:28 PM, Mon P Wang wrote: > It is a bit unclear to me what happens with intrinsics that can take > any integer width. Looking briefily, it looks like clang will > generate an implicit cast for the argument to integer. Do we always > generate the 32 bit integer version of these intrinsics? I don't think we have any of these. However, yes by default that would happen. Sema could choose to intercept these before the implicit casts are inserted, or remove implicit casts later. -Chris From wangmp at apple.com Wed Jul 16 14:51:33 2008 From: wangmp at apple.com (Mon P Wang) Date: Wed, 16 Jul 2008 12:51:33 -0700 Subject: [cfe-dev] "generic" address space In-Reply-To: <311CCB01-9628-4A86-957C-CB38D907C4E0@apple.com> References: <16FF20FC-1BAB-4D45-85B2-E90A7593DB8B@apple.com> <3CFB606E-70A2-40CA-9F6D-FF6886153450@apple.com> <311CCB01-9628-4A86-957C-CB38D907C4E0@apple.com> Message-ID: <2ECF5ABD-3931-42C0-8AAF-D4B993E9D278@apple.com> Hi, For these type of overloaded intrinsics, I think Sema should choose to intercept these before the implicit casts are inserted as they will alter which intrinsic would be called in code generation. Whatever solution we come up with the address space might also apply to this case as well. -- Mon Ping On Jul 16, 2008, at 9:55 AM, Chris Lattner wrote: > > On Jul 15, 2008, at 10:28 PM, Mon P Wang wrote: > >> It is a bit unclear to me what happens with intrinsics that can >> take any integer width. Looking briefily, it looks like clang will >> generate an implicit cast for the argument to integer. Do we >> always generate the 32 bit integer version of these intrinsics? > > I don't think we have any of these. However, yes by default that > would happen. Sema could choose to intercept these before the > implicit casts are inserted, or remove implicit casts later. > > -Chris From wangmp at apple.com Thu Jul 17 00:34:13 2008 From: wangmp at apple.com (Mon P Wang) Date: Wed, 16 Jul 2008 22:34:13 -0700 Subject: [cfe-dev] "generic" address space In-Reply-To: References: <16FF20FC-1BAB-4D45-85B2-E90A7593DB8B@apple.com> <3CFB606E-70A2-40CA-9F6D-FF6886153450@apple.com> Message-ID: <248BD307-3E06-4924-9308-FF89606F4AB2@apple.com> Hi, I agree with you that AST should be as strongly typed as possible and be consistent. (BTW, does clang handle K&R C and formal conversions when one doesn't see the prototype, i.e., the automatic promotion to double and then converting it back to float). If we want to make it very clear on the AST, we could create a special operator that indicates that a address mismatch is allowed. I'm not sure what to call it but it is more of an type adaptor than a conversion. This would make it very clear at the AST what is going on without resorting to a weird placeholder type. Another possibility is that we could tag the ParmVarDecl to indicate that this parameter can ignore any address space differences between the argument and the parameter. -- Mon Ping On Jul 15, 2008, at 10:56 PM, Eli Friedman wrote: > On Tue, Jul 15, 2008 at 10:28 PM, Mon P Wang wrote: >> Hi Eli, >> Whatever we do, it should be clear when examining the AST that we are >> matching an address space overloaded intrinsic. I'm not sure what >> new AST >> expression tree would make sense. I view it that we have an call >> expression >> to an address space overloaded intrinsic function. When we check the >> argument and parameter of the signature, the normal rules follow >> except for >> parameters that can accept different address space. > > The issue is that the types of the function arguments won't match the > type of the call, which would be surprising for most AST consumers. > >> It is a bit unclear to me what happens with intrinsics that can >> take any >> integer width. Looking briefily, it looks like clang will generate >> an >> implicit cast for the argument to integer. Do we always generate >> the 32 bit >> integer version of these intrinsics? > > Mmmm, it looks like clang's versions of the __sync_* builtins are > broken in that respect. I think some custom logic is needed for the > overloading. > >> Various DSPs (e.g TI TMS320C30), embedded architectures and GPUs >> support >> different address spaces. The Cell processor has local >> memory accessible only by the SPUs. Nvidia and AMD GPUs typically >> have >> different address spaces for things like local or textures. It is >> difficult >> to get their ISAs though AMD has released their R600 ISA >> (http://www.x.org/docs/AMD/r600isa.pdf). I'll have to look to see >> what is >> available publicly. > > Hmm, okay... I'm trying to get a feel for what sorts of intrinsics for > alternate address spaces we'll want, and for which ones it's useful to > overload the address space of the pointer arguments. For example, for > the R600 ISA (which I skimmed), I can't think of any intrinsics for > which overloading would be useful; it seems like the address spaces > are implied by the instruction. Do you have any examples where it > would be useful to overload the address space of platform-specific > intrinsics? > > -Eli -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080716/f2a1dc27/attachment.html From eli.friedman at gmail.com Thu Jul 17 00:57:16 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Wed, 16 Jul 2008 22:57:16 -0700 Subject: [cfe-dev] "generic" address space In-Reply-To: <248BD307-3E06-4924-9308-FF89606F4AB2@apple.com> References: <16FF20FC-1BAB-4D45-85B2-E90A7593DB8B@apple.com> <3CFB606E-70A2-40CA-9F6D-FF6886153450@apple.com> <248BD307-3E06-4924-9308-FF89606F4AB2@apple.com> Message-ID: On Wed, Jul 16, 2008 at 10:34 PM, Mon P Wang wrote > (BTW, does clang handle K&R C and formal conversions when one > doesn't see the prototype, i.e., the automatic promotion to double and then > converting it back to float). clang should handle everything related to promotions and functions without prototypes correctly; please file a bug if you find any issues. > If we want to make it very clear on the AST, > we could create a special operator that indicates that a address mismatch is > allowed. I'm not sure what to call it but it is more of an type adaptor > than a conversion. This would make it very clear at the AST what is going > on without resorting to a weird placeholder type. Another possibility is > that we could tag the ParmVarDecl to indicate that this parameter can ignore > any address space differences between the argument and the parameter. All possibilities, I guess... I'm not particularly fond of any of them. I still think adding a new type of AST expression instead of the call would be better. These builtins aren't really functions at all, but overloaded function-style operators, and overloading the semantics with non-calls seems messy. I suppose another possibility (which I think you mentioned in passing) would be to synthesize decls for the various legal overloads on demand. The synthesis step is a bit messy, but the abstraction is otherwise quite clean. -Eli From wangmp at apple.com Thu Jul 17 01:36:38 2008 From: wangmp at apple.com (Mon P Wang) Date: Wed, 16 Jul 2008 23:36:38 -0700 Subject: [cfe-dev] "generic" address space In-Reply-To: References: <16FF20FC-1BAB-4D45-85B2-E90A7593DB8B@apple.com> <3CFB606E-70A2-40CA-9F6D-FF6886153450@apple.com> <248BD307-3E06-4924-9308-FF89606F4AB2@apple.com> Message-ID: By a new expr tree, do you mean that instead of creating a CallExpr, we create another node type like IntrinsicExpr and these have slightly different rules for processing? During CodeGen, both of these nodes will be process the same. If that is the case, I don't see much of a problem going this way. At the time when I first thought about synthesizing the prototype, my concern was that we will be spending some extra time to create the prototype and do some redundant work because after we create the prototype, we would check it again since we will pass it to normal processing. However, we already to create the intrinsic on the fly and when we create a custom prototype based on some call site information, we could skip the regular checks and conversions since we would have already done this. At the abstraction level, it does seem the cleanest way to go since arguments would match correctly. -- Mon Ping On Jul 16, 2008, at 10:57 PM, Eli Friedman wrote: > On Wed, Jul 16, 2008 at 10:34 PM, Mon P Wang wrote >> (BTW, does clang handle K&R C and formal conversions when one >> doesn't see the prototype, i.e., the automatic promotion to double >> and then >> converting it back to float). > > clang should handle everything related to promotions and functions > without prototypes correctly; please file a bug if you find any > issues. > >> If we want to make it very clear on the AST, >> we could create a special operator that indicates that a address >> mismatch is >> allowed. I'm not sure what to call it but it is more of an type >> adaptor >> than a conversion. This would make it very clear at the AST what >> is going >> on without resorting to a weird placeholder type. Another >> possibility is >> that we could tag the ParmVarDecl to indicate that this parameter >> can ignore >> any address space differences between the argument and the parameter. > > All possibilities, I guess... I'm not particularly fond of any of > them. I still think adding a new type of AST expression instead of > the call would be better. These builtins aren't really functions at > all, but overloaded function-style operators, and overloading the > semantics with non-calls seems messy. > > I suppose another possibility (which I think you mentioned in passing) > would be to synthesize decls for the various legal overloads on > demand. The synthesis step is a bit messy, but the abstraction is > otherwise quite clean. > > -Eli From erik at mulle-kybernetik.com Thu Jul 17 02:52:44 2008 From: erik at mulle-kybernetik.com (Erik Doernenburg) Date: Thu, 17 Jul 2008 17:52:44 +1000 Subject: [cfe-dev] Binary download Message-ID: First off, thanks for creating clang and the scan build utility. I was delighted to see how accurately it pinned down some memory problems in my code; and not so delighted that there were some... The only minor disappointment was the binary download. It says that it's for Mac OS X but that's not entirely true. It's for Mac OS X as long as you have a Mac with an Intel processor. I don't know whether it's an omission that the binary is not "universal" or whether this is something you haven't gotten around to. Thought I let you know. erik -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2026 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080717/b77fabd5/attachment.bin From snaroff at apple.com Thu Jul 17 04:59:54 2008 From: snaroff at apple.com (Steve Naroff) Date: Thu, 17 Jul 2008 05:59:54 -0400 Subject: [cfe-dev] Binary download In-Reply-To: References: Message-ID: <031C1EDA-1162-472E-B360-0C38C5C6F62B@apple.com> On Jul 17, 2008, at 3:52 AM, Erik Doernenburg wrote: > First off, thanks for creating clang and the scan build utility. I > was delighted to see how accurately it pinned down some memory > problems in my code; and not so delighted that there were some... > > The only minor disappointment was the binary download. It says that > it's for Mac OS X but that's not entirely true. It's for Mac OS X as > long as you have a Mac with an Intel processor. I don't know whether > it's an omission that the binary is not "universal" or whether this > is something you haven't gotten around to. Thought I let you know. > This is a simple omission (since most of us are developing on Intel processors). Creating a universal binary should be straightforward... Glad to hear clang is being useful to you, snaroff > erik > > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From eli.friedman at gmail.com Thu Jul 17 09:15:41 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Thu, 17 Jul 2008 07:15:41 -0700 Subject: [cfe-dev] "generic" address space In-Reply-To: References: <16FF20FC-1BAB-4D45-85B2-E90A7593DB8B@apple.com> <248BD307-3E06-4924-9308-FF89606F4AB2@apple.com> Message-ID: On Wed, Jul 16, 2008 at 11:36 PM, Mon P Wang wrote: > > By a new expr tree, do you mean that instead of creating a CallExpr, we > create another node type like IntrinsicExpr and these have slightly > different rules for processing? Yes, that's the idea. > During CodeGen, both of these nodes will be > process the same. If that is the case, I don't see much of a problem going > this way. > > At the time when I first thought about synthesizing the prototype, my > concern was that we will be spending some extra time to create the prototype > and do some redundant work because after we create the prototype, we would > check it again since we will pass it to normal processing. However, we > already to create the intrinsic on the fly and when we create a custom > prototype based on some call site information, we could skip the regular > checks and conversions since we would have already done this. At the > abstraction level, it does seem the cleanest way to go since arguments would > match correctly. Okay; I don't have a strong preference between the two approaches. -Eli From daniel at zuster.org Thu Jul 17 12:50:04 2008 From: daniel at zuster.org (Daniel Dunbar) Date: Thu, 17 Jul 2008 10:50:04 -0700 (PDT) Subject: [cfe-dev] patch: boolean bitfield init Message-ID: <872482.99710.qm@web54607.mail.re2.yahoo.com> This is a quick fix for initialization of _Bool bit-fields which have width > 1 (), as in: -- struct { _Bool a : 8; int b : 9; } x = { 1, 0 }; -- This allows test-suite/SingleSource/UnitTests/2006-01-23-InitializedBitField.c to build. - Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: bool-bitfield-init.patch Type: application/octet-stream Size: 845 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080717/656c1739/attachment.obj From clattner at apple.com Thu Jul 17 12:55:04 2008 From: clattner at apple.com (Chris Lattner) Date: Thu, 17 Jul 2008 10:55:04 -0700 Subject: [cfe-dev] patch: boolean bitfield init In-Reply-To: <872482.99710.qm@web54607.mail.re2.yahoo.com> References: <872482.99710.qm@web54607.mail.re2.yahoo.com> Message-ID: <8EA11325-4B55-4A02-961E-50EC2E58DB6C@apple.com> On Jul 17, 2008, at 10:50 AM, Daniel Dunbar wrote: > This is a quick fix for initialization of _Bool bit-fields which > have width > 1 (), as in: > -- > struct { > _Bool a : 8; > int b : 9; > } x = { 1, 0 }; > -- > > This allows test-suite/SingleSource/UnitTests/2006-01-23- > InitializedBitField.c to build. Hey Daniel, Just to clarify, what is the problem here? There are two different "get type size" predicates on ASTContext, one that returns _Bool as having size of 1 bit, and one that returns size of 8 bits (on x86-32). Is it possible the code is using the wrong one? -Chris From daniel at zuster.org Thu Jul 17 13:14:26 2008 From: daniel at zuster.org (Daniel Dunbar) Date: Thu, 17 Jul 2008 11:14:26 -0700 (PDT) Subject: [cfe-dev] patch: boolean bitfield init Message-ID: <470051.83693.qm@web54601.mail.re2.yahoo.com> > Is it possible the code is using the wrong one? Not really. There are a number of ways to look at the problem but it is hard to separate them without clarifying the invariants on bit-field initializers which at the least I don't understand (and may not exist?). The immediate problem is that the constant being used to initialize the bit-field is of type bool (this is a separate bug) even though the bit- field has width > 1. This breaks the algorithm used to initialize the struct because it expects to be able to extract all the required bits from the constant. Since it is not clear that this is an invariant that is supposed to exist my immediate goal was to just not have codegen assert on it. Most likely the more correct fix is that the initializer on the RHS for field 'a' should have type char but this is more invasive. Hence the FIXME comment. :) - Daniel ----- Original Message ---- From: Chris Lattner To: Daniel Dunbar Cc: cfe-dev at cs.uiuc.edu Sent: Thursday, July 17, 2008 10:55:04 AM Subject: Re: [cfe-dev] patch: boolean bitfield init On Jul 17, 2008, at 10:50 AM, Daniel Dunbar wrote: > This is a quick fix for initialization of _Bool bit-fields which > have width > 1 (), as in: > -- > struct { > _Bool a : 8; > int b : 9; > } x = { 1, 0 }; > -- > > This allows test-suite/SingleSource/UnitTests/2006-01-23- > InitializedBitField.c to build. Hey Daniel, Just to clarify, what is the problem here? There are two different "get type size" predicates on ASTContext, one that returns _Bool as having size of 1 bit, and one that returns size of 8 bits (on x86-32). Is it possible the code is using the wrong one? -Chris From dpatel at apple.com Thu Jul 17 13:26:42 2008 From: dpatel at apple.com (Devang Patel) Date: Thu, 17 Jul 2008 11:26:42 -0700 Subject: [cfe-dev] patch: boolean bitfield init In-Reply-To: <470051.83693.qm@web54601.mail.re2.yahoo.com> References: <470051.83693.qm@web54601.mail.re2.yahoo.com> Message-ID: <9CCCF612-F177-4DCA-A7B7-2014DD372148@apple.com> On Jul 17, 2008, at 11:14 AM, Daniel Dunbar wrote: > The immediate problem is that the constant being used to initialize > the bit-field is of type bool (this is a separate bug) even though > the bit- > field has width > 1. But the size of type bool should be 8 bits, otherwise the test case is invalid. For example, struct { int a:199; } b; - Devang From daniel at zuster.org Thu Jul 17 13:34:27 2008 From: daniel at zuster.org (Daniel Dunbar) Date: Thu, 17 Jul 2008 11:34:27 -0700 (PDT) Subject: [cfe-dev] patch: boolean bitfield init Message-ID: <765693.58045.qm@web54604.mail.re2.yahoo.com> Definitely, but until that gets fixed in the front-end I'd rather have codegen not crash. I believe various parts of the bit-field handling need to be reworked but it is easier for me to evaluate when I can look at what works and what doesn't. ----- Original Message ---- From: Devang Patel To: Daniel Dunbar Cc: Chris Lattner ; cfe-dev at cs.uiuc.edu Sent: Thursday, July 17, 2008 11:26:42 AM Subject: Re: [cfe-dev] patch: boolean bitfield init On Jul 17, 2008, at 11:14 AM, Daniel Dunbar wrote: > The immediate problem is that the constant being used to initialize > the bit-field is of type bool (this is a separate bug) even though > the bit- > field has width > 1. But the size of type bool should be 8 bits, otherwise the test case is invalid. For example, struct { int a:199; } b; - Devang From kremenek at apple.com Thu Jul 17 13:35:55 2008 From: kremenek at apple.com (Ted Kremenek) Date: Thu, 17 Jul 2008 11:35:55 -0700 Subject: [cfe-dev] Binary download In-Reply-To: References: Message-ID: <2ADD4EFB-DF87-434E-95FB-C9B89FF925BA@apple.com> On Jul 17, 2008, at 12:52 AM, Erik Doernenburg wrote: > First off, thanks for creating clang and the scan build utility. I > was delighted to see how accurately it pinned down some memory > problems in my code; and not so delighted that there were some... Hi Erik, It's great to hear that the tool has been useful. > The only minor disappointment was the binary download. It says that > it's for Mac OS X but that's not entirely true. It's for Mac OS X as > long as you have a Mac with an Intel processor. I don't know whether > it's an omission that the binary is not "universal" or whether this > is something you haven't gotten around to. Thought I let you know. I have uploaded a new checker-62.tar.gz that contains a universal binary. From now on the builds will be universal. Please let me know if you have any problems. Best, Ted From clattner at apple.com Thu Jul 17 14:43:47 2008 From: clattner at apple.com (Chris Lattner) Date: Thu, 17 Jul 2008 12:43:47 -0700 Subject: [cfe-dev] patch: boolean bitfield init In-Reply-To: <765693.58045.qm@web54604.mail.re2.yahoo.com> References: <765693.58045.qm@web54604.mail.re2.yahoo.com> Message-ID: <267C4B4C-0BD8-4090-A5B7-DA85A21BFCD6@apple.com> On Jul 17, 2008, at 11:34 AM, Daniel Dunbar wrote: > Definitely, but until that gets fixed in the front-end I'd rather > have codegen not crash. I believe various parts of the bit-field > handling need to be reworked but it is easier for me to evaluate > when I can look at what works and what doesn't. Ok. If your patch does the right thing (produces the right code) please commit it. Thanks Daniel! -Chris > > > > > ----- Original Message ---- > From: Devang Patel > To: Daniel Dunbar > Cc: Chris Lattner ; cfe-dev at cs.uiuc.edu > Sent: Thursday, July 17, 2008 11:26:42 AM > Subject: Re: [cfe-dev] patch: boolean bitfield init > > > On Jul 17, 2008, at 11:14 AM, Daniel Dunbar wrote: > >> The immediate problem is that the constant being used to initialize >> the bit-field is of type bool (this is a separate bug) even though >> the bit- >> field has width > 1. > > But the size of type bool should be 8 bits, otherwise the test case is > invalid. > For example, > struct { int a:199; } b; > > - > Devang > From daniel at zuster.org Thu Jul 17 16:51:35 2008 From: daniel at zuster.org (Daniel Dunbar) Date: Thu, 17 Jul 2008 14:51:35 -0700 (PDT) Subject: [cfe-dev] patch: don't emit llvm or bitcode on errors Message-ID: <543215.97711.qm@web54606.mail.re2.yahoo.com> Simple patch to prevent output file generation when the input has errors. Fixes - Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: no-emit-on-error.patch Type: application/octet-stream Size: 501 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080717/1af43c2a/attachment.obj From eli.friedman at gmail.com Thu Jul 17 20:03:30 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Thu, 17 Jul 2008 18:03:30 -0700 Subject: [cfe-dev] patch: boolean bitfield init In-Reply-To: <470051.83693.qm@web54601.mail.re2.yahoo.com> References: <470051.83693.qm@web54601.mail.re2.yahoo.com> Message-ID: On Thu, Jul 17, 2008 at 11:14 AM, Daniel Dunbar wrote: > The immediate problem is that the constant being used to initialize > the bit-field is of type bool (this is a separate bug) even though the bit- > field has width > 1. This breaks the algorithm used to initialize the struct > because it expects to be able to extract all the required bits from the > constant. Yeah... that algorithm is actually my code. As far as I can tell, the patch is correct, although it seems like overkill to extend the width of V all the way to the width of the bitfield. > Most likely the more correct fix is that the initializer on the RHS for field > 'a' should have type char but this is more invasive. Hence the FIXME > comment. :) Here's the situation with relation to the standards: in C99, the code is illegal, because the bit-field width exceeds the width of the type. We're missing an diagnostic in Sema for this. In C++, at least per the current C++0x draft, the extra bits are treated as padding bits, so Sema is correct as-is. The only question is, what the heck gcc is doing here? As far as I can tell, it seems to be treating the _Bool bitfield as a unsigned char bitfield. Anyone know more? -Eli From daniel at zuster.org Thu Jul 17 20:24:16 2008 From: daniel at zuster.org (Daniel Dunbar) Date: Thu, 17 Jul 2008 18:24:16 -0700 (PDT) Subject: [cfe-dev] patch: boolean bitfield init Message-ID: <999789.46318.qm@web54601.mail.re2.yahoo.com> I'm fairly sure that gcc is treating _Bool as an unsigned char as widths 1-8 work and allow the full range of values, but I haven't checked the gcc implementation yet. For C++ g++ appears to treat it as padding as you describe. ----- Original Message ---- From: Eli Friedman To: Daniel Dunbar Cc: Chris Lattner ; cfe-dev at cs.uiuc.edu Sent: Thursday, July 17, 2008 6:03:30 PM Subject: Re: [cfe-dev] patch: boolean bitfield init On Thu, Jul 17, 2008 at 11:14 AM, Daniel Dunbar wrote: > The immediate problem is that the constant being used to initialize > the bit-field is of type bool (this is a separate bug) even though the bit- > field has width > 1. This breaks the algorithm used to initialize the struct > because it expects to be able to extract all the required bits from the > constant. Yeah... that algorithm is actually my code. As far as I can tell, the patch is correct, although it seems like overkill to extend the width of V all the way to the width of the bitfield. > Most likely the more correct fix is that the initializer on the RHS for field > 'a' should have type char but this is more invasive. Hence the FIXME > comment. :) Here's the situation with relation to the standards: in C99, the code is illegal, because the bit-field width exceeds the width of the type. We're missing an diagnostic in Sema for this. In C++, at least per the current C++0x draft, the extra bits are treated as padding bits, so Sema is correct as-is. The only question is, what the heck gcc is doing here? As far as I can tell, it seems to be treating the _Bool bitfield as a unsigned char bitfield. Anyone know more? -Eli From eli.friedman at gmail.com Thu Jul 17 20:28:51 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Thu, 17 Jul 2008 18:28:51 -0700 Subject: [cfe-dev] patch: boolean bitfield init In-Reply-To: <999789.46318.qm@web54601.mail.re2.yahoo.com> References: <999789.46318.qm@web54601.mail.re2.yahoo.com> Message-ID: On Thu, Jul 17, 2008 at 6:24 PM, Daniel Dunbar wrote: > For C++ g++ appears to treat it as padding as > you describe. Which version are you using? And how does it deal with the following code? struct {bool x : 9;} x = {255}; int c() {return x.x==1;} -Eli From daniel at zuster.org Thu Jul 17 20:36:13 2008 From: daniel at zuster.org (Daniel Dunbar) Date: Thu, 17 Jul 2008 18:36:13 -0700 (PDT) Subject: [cfe-dev] patch: boolean bitfield init Message-ID: <630512.93896.qm@web54605.mail.re2.yahoo.com> g++ 4.01 on OSX, the size of the struct is 2, and x.x is 1 (also for an initializer where the low bit is 0) and remains 1 after ++x.x. ----- Original Message ---- From: Eli Friedman To: Daniel Dunbar Cc: cfe-dev at cs.uiuc.edu Sent: Thursday, July 17, 2008 6:28:51 PM Subject: Re: [cfe-dev] patch: boolean bitfield init On Thu, Jul 17, 2008 at 6:24 PM, Daniel Dunbar wrote: > For C++ g++ appears to treat it as padding as > you describe. Which version are you using? And how does it deal with the following code? struct {bool x : 9;} x = {255}; int c() {return x.x==1;} -Eli From eli.friedman at gmail.com Thu Jul 17 20:52:30 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Thu, 17 Jul 2008 18:52:30 -0700 Subject: [cfe-dev] patch: boolean bitfield init In-Reply-To: <630512.93896.qm@web54605.mail.re2.yahoo.com> References: <630512.93896.qm@web54605.mail.re2.yahoo.com> Message-ID: On Thu, Jul 17, 2008 at 6:36 PM, Daniel Dunbar wrote: > g++ 4.01 on OSX, the size of the struct is 2, and x.x is 1 (also for > an initializer where the low bit is 0) and remains 1 after ++x.x. Huh, really... all the versions of g++ I have on my system mess this up. -Eli From wilsonkk at shaw.ca Thu Jul 17 22:01:05 2008 From: wilsonkk at shaw.ca (Kelly W) Date: Thu, 17 Jul 2008 21:01:05 -0600 Subject: [cfe-dev] patch: boolean bitfield init In-Reply-To: Message-ID: <0K4600LQQLPRU430@l-daemon> Hey guys, Seems like this may be a g++ problem for 4.2.X? I get a result of '1' for function c() using the following: g++ 4.1.2 on Fedora/x86_64 g++ 3.4.2 on Aurora/Sparc64 g++ 4.1.2 on Syllable/x86 llvm-g++ 4.0.1 on Fedora/x86_64 but I get a result of '0' for: g++ 4.2.3 on Ubuntu/x86 Thanks, K.Wilson -----Original Message----- From: cfe-dev-bounces at cs.uiuc.edu [mailto:cfe-dev-bounces at cs.uiuc.edu] On Behalf Of Eli Friedman Sent: Thursday, July 17, 2008 7:53 PM To: Daniel Dunbar Cc: cfe-dev at cs.uiuc.edu Subject: Re: [cfe-dev] patch: boolean bitfield init On Thu, Jul 17, 2008 at 6:36 PM, Daniel Dunbar wrote: > g++ 4.01 on OSX, the size of the struct is 2, and x.x is 1 (also for > an initializer where the low bit is 0) and remains 1 after ++x.x. Huh, really... all the versions of g++ I have on my system mess this up. -Eli _______________________________________________ cfe-dev mailing list cfe-dev at cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.138 / Virus Database: 270.5.1/1559 - Release Date: 7/17/2008 6:08 PM From clattner at apple.com Thu Jul 17 23:14:11 2008 From: clattner at apple.com (Chris Lattner) Date: Thu, 17 Jul 2008 21:14:11 -0700 Subject: [cfe-dev] patch: boolean bitfield init In-Reply-To: <999789.46318.qm@web54601.mail.re2.yahoo.com> References: <999789.46318.qm@web54601.mail.re2.yahoo.com> Message-ID: <614575E5-12A1-4297-BA9E-DE9EAF981A64@apple.com> On Jul 17, 2008, at 6:24 PM, Daniel Dunbar wrote: > I'm fairly sure that gcc is treating _Bool as an unsigned char as > widths > 1-8 work and allow the full range of values, but I haven't checked the > gcc implementation yet. For C++ g++ appears to treat it as padding as > you describe. I think the compiler is always required to keep the bool containing 0 or 1. The bitfield width allows the user to pack them more densely. On Darwin/ppc32 for example, sizeof(_Bool) is 4, which makes bitfielding them a very useful thing :) -Chris > > > ----- Original Message ---- > From: Eli Friedman > To: Daniel Dunbar > Cc: Chris Lattner ; cfe-dev at cs.uiuc.edu > Sent: Thursday, July 17, 2008 6:03:30 PM > Subject: Re: [cfe-dev] patch: boolean bitfield init > > On Thu, Jul 17, 2008 at 11:14 AM, Daniel Dunbar > wrote: >> The immediate problem is that the constant being used to initialize >> the bit-field is of type bool (this is a separate bug) even though >> the bit- >> field has width > 1. This breaks the algorithm used to initialize >> the struct >> because it expects to be able to extract all the required bits from >> the >> constant. > > Yeah... that algorithm is actually my code. As far as I can tell, the > patch is correct, although it seems like overkill to extend the width > of V all the way to the width of the bitfield. > >> Most likely the more correct fix is that the initializer on the RHS >> for field >> 'a' should have type char but this is more invasive. Hence the FIXME >> comment. :) > > Here's the situation with relation to the standards: in C99, the code > is illegal, because the bit-field width exceeds the width of the type. > We're missing an diagnostic in Sema for this. In C++, at least per > the current C++0x draft, the extra bits are treated as padding bits, > so Sema is correct as-is. The only question is, what the heck gcc is > doing here? As far as I can tell, it seems to be treating the _Bool > bitfield as a unsigned char bitfield. Anyone know more? > > -Eli > > _______________________________________________ > 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 17 23:24:39 2008 From: clattner at apple.com (Chris Lattner) Date: Thu, 17 Jul 2008 21:24:39 -0700 Subject: [cfe-dev] patch: don't emit llvm or bitcode on errors In-Reply-To: <543215.97711.qm@web54606.mail.re2.yahoo.com> References: <543215.97711.qm@web54606.mail.re2.yahoo.com> Message-ID: <5F588D80-62A9-45BE-821E-ACB9BC97A9EC@apple.com> On Jul 17, 2008, at 2:51 PM, Daniel Dunbar wrote: > Simple patch to prevent output file generation when the input has > errors. > Fixes Looks great to me, please apply. Thanks Daniel. -Chris From matthijs at stdin.nl Fri Jul 18 02:35:27 2008 From: matthijs at stdin.nl (Matthijs Kooijman) Date: Fri, 18 Jul 2008 09:35:27 +0200 Subject: [cfe-dev] patch: don't emit llvm or bitcode on errors In-Reply-To: <543215.97711.qm@web54606.mail.re2.yahoo.com> References: <543215.97711.qm@web54606.mail.re2.yahoo.com> Message-ID: <20080718073527.GI32587@katherina.student.utwente.nl> Hi, wouldn't it make more sense to use hasErrorOccurred() instead of getNumErrors() ? Gr. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080718/71646aee/attachment.bin From daniel at zuster.org Fri Jul 18 12:40:42 2008 From: daniel at zuster.org (Daniel Dunbar) Date: Fri, 18 Jul 2008 10:40:42 -0700 (PDT) Subject: [cfe-dev] patch: keep llvm module consistent during compilationpatch: keep llvm module consistent during compilation Message-ID: <743650.24864.qm@web54601.mail.re2.yahoo.com> The attached patch creates dummy bodies for functions with internal linkage when they are created and replaces them when the definition is compiled. This helps ensure that the module is in a consistent state after processing each top level declaration and prevents crashes in the verifier on malformed inputs. See test case. This should probably be documented at another level than just a code comment but I'm not sure where... Note that this introduces a problem that modules which declare static functions but do not define them will compile (and link!) but this is a bug in sema. Maybe we should still be tracking them though to make sure none slip through to the outside. This requires CG having some way of knowing when the module is done. - Daniel p.s. Comments appreciated on a simpler way to write the DG test I want (checking that the exit code is precisely 1). -------------- next part -------------- A non-text attachment was scrubbed... Name: keep-module-consistent.patch Type: application/octet-stream Size: 1214 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080718/ad9bc8aa/attachment.obj -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 2008-07-18-verifier-failure.c Url: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080718/ad9bc8aa/attachment.c From hacim.h at gmail.com Fri Jul 18 13:52:43 2008 From: hacim.h at gmail.com (Micah Heyer) Date: Fri, 18 Jul 2008 13:52:43 -0500 Subject: [cfe-dev] adding a new AST node class Message-ID: <1216407164.384.17.camel@heyer> Hello, I have been rather excited about this project and have been keeping an eye on it for several months,myself been some what of a PL aficionado.I have tinkered around with the driver ,writing simple programs such as building a AST from scratch.But I was wondering: how do I add custom language features to the AST as if I was building another C language variant? Is it possible to make a class inherit from the 'Stmt' class and function properly without modifying the 'StmtNodes.def' and re-compiling?. If I understand right, the clang project is meant to be a highly flexible collection of libraries to be used with c/c++/obj-c/obj-c++.But has it been designed as to be extended for other languages in this closely related family? thanks in advance for your time. -micah From next_ghost at quick.cz Fri Jul 18 14:42:03 2008 From: next_ghost at quick.cz (Martin Doucha) Date: Fri, 18 Jul 2008 21:42:03 +0200 Subject: [cfe-dev] Clang segfaults in Linux kernel source code Message-ID: <4880F20B.40904@quick.cz> Hi, clang segfaults when parsing mm/slab.c from Linux kernel. The segfault happens in lib/AST/ASTContext.cpp on line 379 because ATy is NULL when parsing initialization of global structure instance using GCC extension. Sample input (shortened mm/slab.c) and backtrace is included in the attachment. Regards, Martin Doucha -------------- next part -------------- A non-text attachment was scrubbed... Name: crash.zip Type: application/zip Size: 8098 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080718/e6fd4e86/attachment.zip From pilky at mcubedsw.com Fri Jul 18 14:55:38 2008 From: pilky at mcubedsw.com (Martin Pilkington) Date: Fri, 18 Jul 2008 20:55:38 +0100 Subject: [cfe-dev] Problems getting the Static Analyser to work Message-ID: <1122575C-441B-42D2-919B-FB7AF4BCBD4A@mcubedsw.com> Hi all, I've been hearing people raving about the static analyser in clang and it does look very impressive so I've been wanting to try it out for myself. The problem is that it doesn't seem to want to compile my code. When I run the following command I get errors with my code: ./clang/scan-build -V -o /results xcodebuild -configuration "Debug" For every file it tries compiling I get the following: Traceback (most recent call last): File "/Users/martinpilkington/Personal/M3/Apps/Lighthouse Keeper/ Lighthouse Keeper/dev/clang/ccc-analyzer", line 286, in main(sys.argv[1:]) File "/Users/martinpilkington/Personal/M3/Apps/Lighthouse Keeper/ Lighthouse Keeper/dev/clang/ccc-analyzer", line 283, in main analyze(clang, analyze_args, language, output, files, verbose, htmldir, file, analysis_type) File "/Users/martinpilkington/Personal/M3/Apps/Lighthouse Keeper/ Lighthouse Keeper/dev/clang/ccc-analyzer", line 87, in analyze subprocess.call(args) File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/ python2.5/subprocess.py", line 443, in call return Popen(*popenargs, **kwargs).wait() File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/ python2.5/subprocess.py", line 593, in __init__ errread, errwrite) File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/ python2.5/subprocess.py", line 1079, in _execute_child raise child_exception OSError: [Errno 2] No such file or directory I've tried this on two machines (both running OS X 10.5.4 and Xcode 3.1). I've tried this with checker-57 and checker-60 (62 seems to have a bug that makes it not want to work at all with paths with spaces in the name). The project builds fine if I build from Xcode or run xcodebuild on its own but I get 27 failures (one for each file). Is there some sort of configuration setting or something I'm missing? Please be warned that I'm not the most command line savvy of people. Thanks --------------------------------- Martin Pilkington Writer of Weird Symbols pilky at mcubedsw.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080718/77ada142/attachment-0001.html From kremenek at apple.com Fri Jul 18 15:52:35 2008 From: kremenek at apple.com (Ted Kremenek) Date: Fri, 18 Jul 2008 13:52:35 -0700 Subject: [cfe-dev] adding a new AST node class In-Reply-To: <1216407164.384.17.camel@heyer> References: <1216407164.384.17.camel@heyer> Message-ID: <24C99A55-C623-4289-8DA4-3CD2B2EADC3E@apple.com> On Jul 18, 2008, at 11:52 AM, Micah Heyer wrote: > Hello, > I have been rather excited about this project and have been keeping > an > eye on it for several months,myself been some what of a PL > aficionado.I have tinkered around with the driver ,writing simple > programs such as building a AST from scratch.But I was wondering: > how do > I add custom language features to the AST as if I was building > another C > language variant? Is it possible to make a class inherit from the > 'Stmt' > class and function properly without modifying the 'StmtNodes.def' and > re-compiling?. > If I understand right, the clang project is meant to be a highly > flexible collection of libraries to be used with c/c++/obj-c/obj-c+ > +.But > has it been designed as to be extended for other languages in this > closely related family? > thanks in advance for your time. > -micah Hi Micah, The ASTs have been designed to be extendable by defining subclasses of Stmt or Expr. You do need to add an extra entry to StmtNodes.def, however, because that is used by the internal RTTI of Clang (all the cast<> and dyn_cast<> magic works using the values defined in StmtNodes.def). If you look at subclasses of Stmt and Expr respectively, you will see that they pass up a value defined in StmtNodes.def to the ctor of Stmt. Ted From daniel at zuster.org Fri Jul 18 15:53:18 2008 From: daniel at zuster.org (Daniel Dunbar) Date: Fri, 18 Jul 2008 13:53:18 -0700 (PDT) Subject: [cfe-dev] Clang segfaults in Linux kernel source code Message-ID: <276021.23430.qm@web54605.mail.re2.yahoo.com> Hi Martin, Thanks for the report, I'll minimize and file a bug shortly... - Daniel ----- Original Message ---- From: Martin Doucha To: cfe-dev at cs.uiuc.edu Sent: Friday, July 18, 2008 12:42:03 PM Subject: [cfe-dev] Clang segfaults in Linux kernel source code Hi, clang segfaults when parsing mm/slab.c from Linux kernel. The segfault happens in lib/AST/ASTContext.cpp on line 379 because ATy is NULL when parsing initialization of global structure instance using GCC extension. Sample input (shortened mm/slab.c) and backtrace is included in the attachment. Regards, Martin Doucha From kremenek at apple.com Fri Jul 18 15:54:04 2008 From: kremenek at apple.com (Ted Kremenek) Date: Fri, 18 Jul 2008 13:54:04 -0700 Subject: [cfe-dev] Clang segfaults in Linux kernel source code In-Reply-To: <4880F20B.40904@quick.cz> References: <4880F20B.40904@quick.cz> Message-ID: <925CE32E-F9E2-4658-91F7-16593BB08074@apple.com> Hi Martin, Could you file a bugzilla report for this? That way your bug report doesn't get lost (especially since we're so close to the weekend) and we can track the bug until it gets fixed. Best, Ted On Jul 18, 2008, at 12:42 PM, Martin Doucha wrote: > Hi, > clang segfaults when parsing mm/slab.c from Linux kernel. The > segfault happens in lib/AST/ASTContext.cpp on line 379 because ATy > is NULL when parsing initialization of global structure instance > using GCC extension. Sample input (shortened mm/slab.c) and > backtrace is included in the attachment. > > Regards, > Martin Doucha > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From kremenek at apple.com Fri Jul 18 15:58:00 2008 From: kremenek at apple.com (Ted Kremenek) Date: Fri, 18 Jul 2008 13:58:00 -0700 Subject: [cfe-dev] Problems getting the Static Analyser to work In-Reply-To: <1122575C-441B-42D2-919B-FB7AF4BCBD4A@mcubedsw.com> References: <1122575C-441B-42D2-919B-FB7AF4BCBD4A@mcubedsw.com> Message-ID: <8A172BB2-A2C2-4758-B791-E0A4C9B6234F@apple.com> Hi Martin, This looks like a problem in the python script ccc-analyzer which acts as a replacement to gcc, spawning off invocations to gcc and clang (the static analyzer) respectively. The best thing to do is probably to file a bugzilla report for this. That way we can track the progress of the bug fix. In the bug report, can you provide the output of scan-build when you use 3 "-v" options? It would be good to see the exact invocation (arguments) that are passed to ccc-analyzer that leads to this problem. Best, Ted On Jul 18, 2008, at 12:55 PM, Martin Pilkington wrote: > Hi all, > > I've been hearing people raving about the static analyser in clang > and it does look very impressive so I've been wanting to try it out > for myself. The problem is that it doesn't seem to want to compile > my code. When I run the following command I get errors with my code: > > ./clang/scan-build -V -o /results xcodebuild -configuration "Debug" > > For every file it tries compiling I get the following: > > Traceback (most recent call last): > File "/Users/martinpilkington/Personal/M3/Apps/Lighthouse Keeper/ > Lighthouse Keeper/dev/clang/ccc-analyzer", line 286, in > main(sys.argv[1:]) > File "/Users/martinpilkington/Personal/M3/Apps/Lighthouse Keeper/ > Lighthouse Keeper/dev/clang/ccc-analyzer", line 283, in main > analyze(clang, analyze_args, language, output, files, verbose, > htmldir, file, analysis_type) > File "/Users/martinpilkington/Personal/M3/Apps/Lighthouse Keeper/ > Lighthouse Keeper/dev/clang/ccc-analyzer", line 87, in analyze > subprocess.call(args) > File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/ > python2.5/subprocess.py", line 443, in call > return Popen(*popenargs, **kwargs).wait() > File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/ > python2.5/subprocess.py", line 593, in __init__ > errread, errwrite) > File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/ > python2.5/subprocess.py", line 1079, in _execute_child > raise child_exception > OSError: [Errno 2] No such file or directory > > I've tried this on two machines (both running OS X 10.5.4 and Xcode > 3.1). I've tried this with checker-57 and checker-60 (62 seems to > have a bug that makes it not want to work at all with paths with > spaces in the name). The project builds fine if I build from Xcode > or run xcodebuild on its own but I get 27 failures (one for each > file). Is there some sort of configuration setting or something I'm > missing? Please be warned that I'm not the most command line savvy > of people. > > Thanks > > --------------------------------- > Martin Pilkington > Writer of Weird Symbols > pilky at mcubedsw.com > > > _______________________________________________ > 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/20080718/dcf26467/attachment.html From kremenek at apple.com Fri Jul 18 15:58:24 2008 From: kremenek at apple.com (Ted Kremenek) Date: Fri, 18 Jul 2008 13:58:24 -0700 Subject: [cfe-dev] Clang segfaults in Linux kernel source code In-Reply-To: <925CE32E-F9E2-4658-91F7-16593BB08074@apple.com> References: <4880F20B.40904@quick.cz> <925CE32E-F9E2-4658-91F7-16593BB08074@apple.com> Message-ID: Nevermind. Daniel is already looking at it. On Jul 18, 2008, at 1:54 PM, Ted Kremenek wrote: > Hi Martin, > > Could you file a bugzilla report for this? That way your bug report > doesn't get lost (especially since we're so close to the weekend) and > we can track the bug until it gets fixed. > > Best, > Ted > > On Jul 18, 2008, at 12:42 PM, Martin Doucha wrote: > >> Hi, >> clang segfaults when parsing mm/slab.c from Linux kernel. The >> segfault happens in lib/AST/ASTContext.cpp on line 379 because ATy >> is NULL when parsing initialization of global structure instance >> using GCC extension. Sample input (shortened mm/slab.c) and >> backtrace is included in the attachment. >> >> Regards, >> Martin Doucha >> _______________________________________________ >> cfe-dev mailing list >> cfe-dev at cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From matthijs at stdin.nl Fri Jul 18 16:09:28 2008 From: matthijs at stdin.nl (Matthijs Kooijman) Date: Fri, 18 Jul 2008 23:09:28 +0200 Subject: [cfe-dev] always_inline and noinline attributes In-Reply-To: References: <20080620121519.GH3816@katherina.student.utwente.nl> Message-ID: <20080718210928.GK32587@katherina.student.utwente.nl> Hi Devang, > The correct approach is to encode these function properties in LLVM IR. > Stay tuned, I'll send out proposal on LLVM dev list in next few days. Any chance of this proposal getting finished? :-) > Once the information is encoded in the IR, the remaining issue is how to > invoke the LLVM inlining pass when at least one function is marked as > always_inline. There are two possible approaches: > > 1) Teach FE tools (e.g. clang, llvm-gcc) to insert inlining pass in the > PassManager while requesting (opt + code generation) when it least one > function with attribute always_inline is seen. Perhaps there could be a specific inliner that does only this? This prevents surprises when people didn't expect inlining? > 2) Teach the LLVM PassManager to sniff always_inline property encoded in > the LLVM IR and do the right thing. This sounds like it might also surprise people, if they only add a single pass and still things are inlined. Might not be a big problem, though. Another reason why I think encoding in the IR is necessary: If I have an always inline function defined in one module and referenced in another, I think it should still be inlined after I link the two modules together, right? Gr. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080718/2932c2b8/attachment.bin From kremenek at apple.com Fri Jul 18 16:21:35 2008 From: kremenek at apple.com (Ted Kremenek) Date: Fri, 18 Jul 2008 14:21:35 -0700 Subject: [cfe-dev] Problems getting the Static Analyser to work In-Reply-To: <1122575C-441B-42D2-919B-FB7AF4BCBD4A@mcubedsw.com> References: <1122575C-441B-42D2-919B-FB7AF4BCBD4A@mcubedsw.com> Message-ID: <9D1DD949-56A0-4FE3-8014-7051B3E5F631@apple.com> On Jul 18, 2008, at 12:55 PM, Martin Pilkington wrote: > I've tried this on two machines (both running OS X 10.5.4 and Xcode > 3.1). I've tried this with checker-57 and checker-60 (62 seems to > have a bug that makes it not want to work at all with paths with > spaces in the name). Hi Martin, I realized that the issue may be that the path to your project contains spaces. There was a bug fix that went into checker-62 (released July 15) that addressed some issues in scan-build with paths with spaces. Please try out checker-63 (released today) to see if the problem disappears. Best, Ted From dpatel at apple.com Fri Jul 18 16:23:23 2008 From: dpatel at apple.com (Devang Patel) Date: Fri, 18 Jul 2008 14:23:23 -0700 Subject: [cfe-dev] always_inline and noinline attributes In-Reply-To: <20080718210928.GK32587@katherina.student.utwente.nl> References: <20080620121519.GH3816@katherina.student.utwente.nl> <20080718210928.GK32587@katherina.student.utwente.nl> Message-ID: <1430D604-E6D4-48BA-A69B-2F0BA5BD5C7D@apple.com> Hi Matthijs, On Jul 18, 2008, at 2:09 PM, Matthijs Kooijman wrote: > Hi Devang, > >> The correct approach is to encode these function properties in LLVM >> IR. >> Stay tuned, I'll send out proposal on LLVM dev list in next few days. > Any chance of this proposal getting finished? :-) I got side tracked on other things. I'll try to get this finished soon. >> Once the information is encoded in the IR, the remaining issue is >> how to >> invoke the LLVM inlining pass when at least one function is marked as >> always_inline. There are two possible approaches: >> >> 1) Teach FE tools (e.g. clang, llvm-gcc) to insert inlining pass in >> the >> PassManager while requesting (opt + code generation) when it least >> one >> function with attribute always_inline is seen. > Perhaps there could be a specific inliner that does only this? This > prevents > surprises when people didn't expect inlining? > >> 2) Teach the LLVM PassManager to sniff always_inline property >> encoded in >> the LLVM IR and do the right thing. > This sounds like it might also surprise people, if they only add a > single pass > and still things are inlined. Might not be a big problem, though. It makes to sense have a inliner mode (or a separate pass) that only handles always_inline. > Another reason why I think encoding in the IR is necessary: If I > have an > always inline function defined in one module and referenced in > another, I > think it should still be inlined after I link the two modules > together, right? That is also my understanding. I hope, that will not surprise users. - Devang From daniel at zuster.org Fri Jul 18 18:34:30 2008 From: daniel at zuster.org (Daniel Dunbar) Date: Fri, 18 Jul 2008 16:34:30 -0700 (PDT) Subject: [cfe-dev] patch: more builtin support Message-ID: <558085.31532.qm@web54607.mail.re2.yahoo.com> This patch adds support for __builtin_{ffs[l][l], parity[l][l], popcount[l][l], huge_valf, huge_vall}. + test case nans, powi[fl], prefetch still missing (among others, no doubt). - Daniel -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: builtins-ffs_parity_popcount.c Url: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080718/121fb8ea/attachment.c -------------- next part -------------- A non-text attachment was scrubbed... Name: more-builtin-support.patch Type: application/octet-stream Size: 4612 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080718/121fb8ea/attachment.obj From nicolasweber at gmx.de Sat Jul 19 02:04:22 2008 From: nicolasweber at gmx.de (Nico Weber) Date: Sat, 19 Jul 2008 09:04:22 +0200 Subject: [cfe-dev] Patch for __builtin_bzero Message-ID: <363EB4E0-319F-4F72-A8FF-FE26DFEB5E94@gmx.de> Hi, with the attached patch, vim7 can be built with `make CC=ccc`. Linking takes about 3 minutes (with a debug build of llvm), and vim's build process runs the linker several times (at least 3 times), so total linking time is about 3 minutes. The patch adds support for __builtin_bzero. OS X' headers use that in FD_SET. __builtin_bzero() simply calls the library's bzero() in this patch. Would it be better to use the llvm.memset intrinsic instead? I believe Windows does not have bzero in its c library. Nico -------------- next part -------------- A non-text attachment was scrubbed... Name: bzero.patch Type: application/octet-stream Size: 489 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080719/b7e99191/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: builtin-bzero.c Type: application/octet-stream Size: 248 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080719/b7e99191/attachment-0001.obj From krj at rajaratnam.dk Sat Jul 19 06:41:07 2008 From: krj at rajaratnam.dk (Kovarththanan Rajaratnam) Date: Sat, 19 Jul 2008 13:41:07 +0200 Subject: [cfe-dev] [PATCH] Column number is not correctly shown Message-ID: Hello, When dumping the tokens (-dumptokens output type), the column numbers are not correctly shown. This patch fixes that issue. -- Best Regards Kovarththanan Rajaratnam -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dump_line_number.diff Url: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080719/590b26f5/attachment.pl From eli.friedman at gmail.com Sat Jul 19 13:24:20 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Sat, 19 Jul 2008 11:24:20 -0700 Subject: [cfe-dev] Patch for __builtin_bzero In-Reply-To: <363EB4E0-319F-4F72-A8FF-FE26DFEB5E94@gmx.de> References: <363EB4E0-319F-4F72-A8FF-FE26DFEB5E94@gmx.de> Message-ID: On Sat, Jul 19, 2008 at 12:04 AM, Nico Weber wrote: > Hi, > > with the attached patch, vim7 can be built with `make CC=ccc`. Linking takes > about 3 minutes (with a debug build of llvm), and vim's build process runs > the linker several times (at least 3 times), so total linking time is about > 3 minutes. Okay, cool... although the difference between debug and release is pretty big. clang is roughly 2x faster in release mode, and linking is roughly 5x faster, if I recall correctly. > __builtin_bzero() simply calls the library's bzero() in this patch. > Would it be better to use the llvm.memset intrinsic instead? I believe > Windows does not have bzero in its c library. I'd say don't bother for the moment; if it becomes an issue, we can deal with it later. -Eli From kremenek at apple.com Sat Jul 19 14:10:47 2008 From: kremenek at apple.com (Ted Kremenek) Date: Sat, 19 Jul 2008 12:10:47 -0700 Subject: [cfe-dev] [PATCH] Column number is not correctly shown In-Reply-To: References: Message-ID: <57E5E3C4-69BB-4B2D-9FCD-1879166371D6@apple.com> Applied! Thanks! On Jul 19, 2008, at 4:41 AM, Kovarththanan Rajaratnam wrote: > Hello, > > When dumping the tokens (-dumptokens output type), the column numbers > are not correctly shown. This patch fixes that issue. > > -- > Best Regards > Kovarththanan Rajaratnam > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From kremenek at apple.com Sat Jul 19 14:37:12 2008 From: kremenek at apple.com (Ted Kremenek) Date: Sat, 19 Jul 2008 12:37:12 -0700 Subject: [cfe-dev] TestRunner.sh reporting inconsistent results Message-ID: I applied Kovarththanan Rajaratnam's patch to the Preprocessor so that -dumptokens emitted proper column numbers, and his provided test case passes when TestRunner.sh is run on it directly: (kremenek at tedbook:Preprocessor)$ ../TestRunner.sh dumptokens_phyloc.c (kremenek at tedbook:Preprocessor)$ When I do 'make test', it reports a failure: (kremenek at tedbook:clang)$ make -j2 test --- Running clang tests --- .............................................. ---- CodeGen/long-double-x86.c failed ---- ............................................................................ ---- Preprocessor/dumptokens_phyloc.c failed ---- ............................................................................................................................................................................................................................................................................................................................................................ The long-double-x86.c failure is another story (I just started seeing that one). Any thoughts? Why is 'make test' reporting a failure here when TestRunner.sh does not? Incidentally, the test dumptokens_phyloc.c does the following: clang -dumptokens dumptokens_phyloc.c 2>&1 | grep "PhysLoc=[_.a-zA- Z]*:3:20" I echoed the exit status: clang -dumptokens dumptokens_phyloc.c 2>&1 | grep "PhysLoc=[_.a-zA- Z]*:3:20" ; echo $? and got 0. From wootest at gmail.com Sat Jul 19 16:23:39 2008 From: wootest at gmail.com (Jesper) Date: Sat, 19 Jul 2008 23:23:39 +0200 Subject: [cfe-dev] Theoretical question: Duff's device and AST Message-ID: <5b2e5c5a0807191423q217a60b1xdbe78bd34fc62f63@mail.gmail.com> Hello, I've been following clang with interest and will continue to do so since the potential payoffs are immense, the project is just plain cool and it's very likely to be finished with Apple backing it. The other day, a question started nagging me: How will clang represent weirdness like Duff's device[1] in AST form? [1]: http://en.wikipedia.org/wiki/Duff%27s_device As you may know, Duff's device is a famous example of a partially unrolled loop to copy a buffer, which works by interlacing the switch and do structures, like: int n = (count + 7) / 8; switch (count % 8) { case 0: do { *to = *from++; case 7: *to = *from++; case 6: *to = *from++; case 5: *to = *from++; case 4: *to = *from++; case 3: *to = *from++; case 2: *to = *from++; case 1: *to = *from++; } while (--n > 0); } Obviously, with memcpy, no one really needs to use it, but it is nonetheless part of the C language that clang endeavors to cover, and may be part of programs that clang will be asked to compile or pretty-print. I'm interested purely academically in what the answer might be. /Jesper From nunoplopes at sapo.pt Sat Jul 19 17:18:36 2008 From: nunoplopes at sapo.pt (Nuno Lopes) Date: Sat, 19 Jul 2008 23:18:36 +0100 Subject: [cfe-dev] TestRunner.sh reporting inconsistent results In-Reply-To: References: Message-ID: <7486B53CDC644C3382F8DD239C71318B@pc07654> I think I've fixed the dumptokens_phyloc.c test. The regex didn't catch the directory /. The long-double-x86.c test failure is weird, as the sizeof() value is ok. This is probably related with the new I-C-E. Nuno ----- Original Message ----- From: "Ted Kremenek" To: "cfe-dev Developers" Sent: Saturday, July 19, 2008 8:37 PM Subject: [cfe-dev] TestRunner.sh reporting inconsistent results >I applied Kovarththanan Rajaratnam's patch to the Preprocessor so that > -dumptokens emitted proper column numbers, and his provided test case > passes when TestRunner.sh is run on it directly: > > (kremenek at tedbook:Preprocessor)$ ../TestRunner.sh dumptokens_phyloc.c > (kremenek at tedbook:Preprocessor)$ > > When I do 'make test', it reports a failure: > > (kremenek at tedbook:clang)$ make -j2 test > --- Running clang tests --- > .............................................. > ---- CodeGen/long-double-x86.c failed ---- > ............................................................................ > ---- Preprocessor/dumptokens_phyloc.c failed ---- > ............................................................................................................................................................................................................................................................................................................................................................ > > The long-double-x86.c failure is another story (I just started seeing > that one). > > Any thoughts? Why is 'make test' reporting a failure here when > TestRunner.sh does not? Incidentally, the test dumptokens_phyloc.c > does the following: > > clang -dumptokens dumptokens_phyloc.c 2>&1 | grep "PhysLoc=[_.a-zA- > Z]*:3:20" > > I echoed the exit status: > > clang -dumptokens dumptokens_phyloc.c 2>&1 | grep "PhysLoc=[_.a-zA- > Z]*:3:20" ; echo $? > > and got 0. From eli.friedman at gmail.com Sat Jul 19 17:31:18 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Sat, 19 Jul 2008 15:31:18 -0700 Subject: [cfe-dev] Theoretical question: Duff's device and AST In-Reply-To: <5b2e5c5a0807191423q217a60b1xdbe78bd34fc62f63@mail.gmail.com> References: <5b2e5c5a0807191423q217a60b1xdbe78bd34fc62f63@mail.gmail.com> Message-ID: On Sat, Jul 19, 2008 at 2:23 PM, Jesper wrote: > The other day, a question started nagging me: How will clang represent > weirdness like Duff's device[1] in AST form? clang is well past the point of being able to compile something as simple as Duff's device. If you're interested in seeing what the AST looks like for such construct, build a copy (http://clang.llvm.org/get_started.html) and run clang -ast-dump over the code. -Eli From nunoplopes at sapo.pt Sat Jul 19 17:31:30 2008 From: nunoplopes at sapo.pt (Nuno Lopes) Date: Sat, 19 Jul 2008 23:31:30 +0100 Subject: [cfe-dev] TestRunner.sh reporting inconsistent results In-Reply-To: <7486B53CDC644C3382F8DD239C71318B@pc07654> References: <7486B53CDC644C3382F8DD239C71318B@pc07654> Message-ID: <702812A2D4AB4D0687435430DD35B7C4@pc07654> Ah, nevermind. The problem in long-double-x86.c is with sizeof(). It's returning 16, while the test expected 12. Nuno ----- Original Message ----- >I think I've fixed the dumptokens_phyloc.c test. The regex didn't catch the > directory /. > The long-double-x86.c test failure is weird, as the sizeof() value is ok. > This is probably related with the new I-C-E. > > Nuno > > ----- Original Message ----- > From: "Ted Kremenek" > To: "cfe-dev Developers" > Sent: Saturday, July 19, 2008 8:37 PM > Subject: [cfe-dev] TestRunner.sh reporting inconsistent results > > >>I applied Kovarththanan Rajaratnam's patch to the Preprocessor so that >> -dumptokens emitted proper column numbers, and his provided test case >> passes when TestRunner.sh is run on it directly: >> >> (kremenek at tedbook:Preprocessor)$ ../TestRunner.sh dumptokens_phyloc.c >> (kremenek at tedbook:Preprocessor)$ >> >> When I do 'make test', it reports a failure: >> >> (kremenek at tedbook:clang)$ make -j2 test >> --- Running clang tests --- >> .............................................. >> ---- CodeGen/long-double-x86.c failed ---- >> ............................................................................ >> ---- Preprocessor/dumptokens_phyloc.c failed ---- >> ............................................................................................................................................................................................................................................................................................................................................................ >> >> The long-double-x86.c failure is another story (I just started seeing >> that one). >> >> Any thoughts? Why is 'make test' reporting a failure here when >> TestRunner.sh does not? Incidentally, the test dumptokens_phyloc.c >> does the following: >> >> clang -dumptokens dumptokens_phyloc.c 2>&1 | grep "PhysLoc=[_.a-zA- >> Z]*:3:20" >> >> I echoed the exit status: >> >> clang -dumptokens dumptokens_phyloc.c 2>&1 | grep "PhysLoc=[_.a-zA- >> Z]*:3:20" ; echo $? >> >> and got 0. From filcab at gmail.com Sat Jul 19 19:07:51 2008 From: filcab at gmail.com (Filipe Cabecinhas) Date: Sun, 20 Jul 2008 01:07:51 +0100 Subject: [cfe-dev] Theoretical question: Duff's device and AST In-Reply-To: <5b2e5c5a0807191423q217a60b1xdbe78bd34fc62f63@mail.gmail.com> References: <5b2e5c5a0807191423q217a60b1xdbe78bd34fc62f63@mail.gmail.com> Message-ID: <05554CE8-CD13-4E4E-A8FE-498ECE1D62CC@gmail.com> On 19 Jul, 2008, at 22:23, Jesper wrote: > > int n = (count + 7) / 8; > switch (count % 8) { > case 0: do { *to = *from++; > case 7: *to = *from++; > case 6: *to = *from++; > case 5: *to = *from++; > case 4: *to = *from++; > case 3: *to = *from++; > case 2: *to = *from++; > case 1: *to = *from++; > } while (--n > 0); > } > > Obviously, with memcpy, no one really needs to use it, but it is > nonetheless part of the C language that clang endeavors to cover, and > may be part of programs that clang will be asked to compile or > pretty-print. I'm interested purely academically in what the answer > might be. > Why would you think that, with memcpy, you would have no need for duff's device? As you can see from the code you posted, the 'to' pointer is never changed. Normally one would use duff's device with memory mapped IO, not with memory-to-memory tranfers :-) - Filipe Cabecinhas From me22.ca at gmail.com Sat Jul 19 19:21:00 2008 From: me22.ca at gmail.com (me22) Date: Sat, 19 Jul 2008 20:21:00 -0400 Subject: [cfe-dev] Theoretical question: Duff's device and AST In-Reply-To: <05554CE8-CD13-4E4E-A8FE-498ECE1D62CC@gmail.com> References: <5b2e5c5a0807191423q217a60b1xdbe78bd34fc62f63@mail.gmail.com> <05554CE8-CD13-4E4E-A8FE-498ECE1D62CC@gmail.com> Message-ID: On Sat, Jul 19, 2008 at 20:07, Filipe Cabecinhas wrote: > > Why would you think that, with memcpy, you would have no need for > duff's device? > As you can see from the code you posted, the 'to' pointer is never > changed. Normally one would use duff's device with memory mapped IO, > not with memory-to-memory tranfers :-) > I suppose a variant of it might be useful for std::copy_n on iterators in C++, as well... From clattner at apple.com Sat Jul 19 19:23:26 2008 From: clattner at apple.com (Chris Lattner) Date: Sat, 19 Jul 2008 17:23:26 -0700 Subject: [cfe-dev] patch: more builtin support In-Reply-To: <558085.31532.qm@web54607.mail.re2.yahoo.com> References: <558085.31532.qm@web54607.mail.re2.yahoo.com> Message-ID: <7FD292A5-7D6D-4727-9FEF-4D91C289DE84@apple.com> On Jul 18, 2008, at 4:34 PM, Daniel Dunbar wrote: > This patch adds support for __builtin_{ffs[l][l], parity[l][l], > popcount[l][l], huge_valf, huge_vall}. > + test case Looks great to me with one minor change: we don't want the clang testsuite to actually execute code. Please make the test just be something like this: void test(int M, long long N) { printf("%d %lld: %d %d %d %d %d %d %d %d %d %d %d %d %d %d %d %d %d %d\n", M, N, __builtin_ffs(M), __builtin_ffsl(M), __builtin_ffsll(M), __builtin_parity(M), __builtin_parityl(M), __builtin_parityll(M), __builtin_popcount(M), __builtin_popcountl(M), __builtin_popcountll(M), __builtin_ffs(N), __builtin_ffsl(N), __builtin_ffsll(N), __builtin_parity(N), __builtin_parityl(N), __builtin_parityll(N), __builtin_popcount(N), __builtin_popcountl(N), __builtin_popcountll(N)); } with: clang -emit-llvm %s | not grep __builtin or something like that. The llvm-test suite can be used to verify that we don't miscompile them. Thanks Daniel! -Chris From kremenek at apple.com Sat Jul 19 22:31:20 2008 From: kremenek at apple.com (Ted Kremenek) Date: Sat, 19 Jul 2008 20:31:20 -0700 Subject: [cfe-dev] TestRunner.sh reporting inconsistent results In-Reply-To: <7486B53CDC644C3382F8DD239C71318B@pc07654> References: <7486B53CDC644C3382F8DD239C71318B@pc07654> Message-ID: <8D3CB253-9BCA-44A0-8E41-04D83F5571C3@apple.com> On Jul 19, 2008, at 3:18 PM, Nuno Lopes wrote: > I think I've fixed the dumptokens_phyloc.c test. The regex didn't > catch the directory /. Thanks Nuno! I'm not certain why TestRunner.sh didn't report a failure when it ran the test outside of 'make test', but I'm glad that the test passes now. From luismarques at gmail.com Mon Jul 21 11:20:48 2008 From: luismarques at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Marques?=) Date: Mon, 21 Jul 2008 17:20:48 +0100 Subject: [cfe-dev] va_arg problem on x86_64, fix and test-case Message-ID: <408520e0807210920t42345839ga6d3be85073a4f3a@mail.gmail.com> Hello, I'm new to clang. I tried compiling a code base which uses a va_list argument and got an error. The following snippet isolates the problem and complements test/varargs.c: void f4(int a, __builtin_va_list ap) { char* r = __builtin_va_arg(ap, char*); } Errors seen but not expected: Line 30: first argument to 'va_arg' is of type 'struct __va_list_tag *' and not 'va_list' This seems to be caused by either 1) a bad declaration of __va_list_tag or 2) faulty logic on Sema::ActOnVAArg() [it uses CheckAssignmentConstraints() to check the compatibility]. The "declaration" of __builtin_va_list on x86_64 is: static const char* getX86_64VAListDeclaration() { return "typedef struct __va_list_tag {" " unsigned gp_offset;" " unsigned fp_offset;" " void* overflow_arg_area;" " void* reg_save_area;" "} __builtin_va_list[1];"; } Is there a reason for it to be declared as a single element array? Removing the array declaration fixes the problem. The fix does not seem to introduce any additional problems, as tested with "make test". So, my questions are the following: - why the array? - Is reducing the declaration to a simple struct the correct fix? - The getPPCVAListDeclaration() might have the same problem. Can anyone confirm? - Is my the test case OK? - should I send a patch? - should I also try to implement/fix the following? llc: X86ISelLowering.cpp:5223: llvm::SDOperand llvm::X86TargetLowering::LowerVAARG(llvm::SDOperand, llvm::SelectionDAG&): Assertion `0 && "VAArgInst is not yet implemented for x86-64!"' failed. Thanks for your insights. -- Lu?s Marques From luismarques at gmail.com Mon Jul 21 11:20:48 2008 From: luismarques at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Marques?=) Date: Mon, 21 Jul 2008 17:20:48 +0100 Subject: [cfe-dev] va_arg problem on x86_64, fix and test-case Message-ID: <408520e0807210920t42345839ga6d3be85073a4f3a@mail.gmail.com> Hello, I'm new to clang. I tried compiling a code base which uses a va_list argument and got an error. The following snippet isolates the problem and complements test/varargs.c: void f4(int a, __builtin_va_list ap) { char* r = __builtin_va_arg(ap, char*); } Errors seen but not expected: Line 30: first argument to 'va_arg' is of type 'struct __va_list_tag *' and not 'va_list' This seems to be caused by either 1) a bad declaration of __va_list_tag or 2) faulty logic on Sema::ActOnVAArg() [it uses CheckAssignmentConstraints() to check the compatibility]. The "declaration" of __builtin_va_list on x86_64 is: static const char* getX86_64VAListDeclaration() { return "typedef struct __va_list_tag {" " unsigned gp_offset;" " unsigned fp_offset;" " void* overflow_arg_area;" " void* reg_save_area;" "} __builtin_va_list[1];"; } Is there a reason for it to be declared as a single element array? Removing the array declaration fixes the problem. The fix does not seem to introduce any additional problems, as tested with "make test". So, my questions are the following: - why the array? - Is reducing the declaration to a simple struct the correct fix? - The getPPCVAListDeclaration() might have the same problem. Can anyone confirm? - Is my the test case OK? - should I send a patch? - should I also try to implement/fix the following? llc: X86ISelLowering.cpp:5223: llvm::SDOperand llvm::X86TargetLowering::LowerVAARG(llvm::SDOperand, llvm::SelectionDAG&): Assertion `0 && "VAArgInst is not yet implemented for x86-64!"' failed. Thanks for your insights. -- Lu?s Marques From daniel at zuster.org Mon Jul 21 12:28:35 2008 From: daniel at zuster.org (Daniel Dunbar) Date: Mon, 21 Jul 2008 10:28:35 -0700 (PDT) Subject: [cfe-dev] patch: more builtin support Message-ID: <739974.58389.qm@web54604.mail.re2.yahoo.com> > Looks great to me with one minor change: we don't want the clang > testsuite to actually execute code. Please make the test just be > something like this: ... Done. The grep works in this case but this policy is going to be harder to deal with for other codegen tests -- either the test is going to be very fragile or just not written. To take a current example, how do you check that the accesses to the following bit-field are being compiled correctly without running code: -- struct { _Bool x : 2; } x; int foo () { return x.x += 1; } -- Is running code with lli verboten? - Daniel ----- Original Message ---- From: Chris Lattner To: Daniel Dunbar Cc: cfe-dev at cs.uiuc.edu Sent: Saturday, July 19, 2008 5:23:26 PM Subject: Re: [cfe-dev] patch: more builtin support On Jul 18, 2008, at 4:34 PM, Daniel Dunbar wrote: > This patch adds support for __builtin_{ffs[l][l], parity[l][l], > popcount[l][l], huge_valf, huge_vall}. > + test case Looks great to me with one minor change: we don't want the clang testsuite to actually execute code. Please make the test just be something like this: void test(int M, long long N) { printf("%d %lld: %d %d %d %d %d %d %d %d %d %d %d %d %d %d %d %d %d %d\n", M, N, __builtin_ffs(M), __builtin_ffsl(M), __builtin_ffsll(M), __builtin_parity(M), __builtin_parityl(M), __builtin_parityll(M), __builtin_popcount(M), __builtin_popcountl(M), __builtin_popcountll(M), __builtin_ffs(N), __builtin_ffsl(N), __builtin_ffsll(N), __builtin_parity(N), __builtin_parityl(N), __builtin_parityll(N), __builtin_popcount(N), __builtin_popcountl(N), __builtin_popcountll(N)); } with: clang -emit-llvm %s | not grep __builtin or something like that. The llvm-test suite can be used to verify that we don't miscompile them. Thanks Daniel! -Chris From nicolasweber at gmx.de Mon Jul 21 16:20:13 2008 From: nicolasweber at gmx.de (Nico Weber) Date: Mon, 21 Jul 2008 23:20:13 +0200 Subject: [cfe-dev] Patch for __builtin_bzero In-Reply-To: References: <363EB4E0-319F-4F72-A8FF-FE26DFEB5E94@gmx.de> Message-ID: <5FAD1D61-E49D-4FCE-8E84-B0DF4FD219BB@gmx.de> On 19.07.2008, at 20:24, Eli Friedman wrote: > On Sat, Jul 19, 2008 at 12:04 AM, Nico Weber > wrote: >> Hi, >> >> with the attached patch, vim7 can be built with `make CC=ccc`. >> Linking takes >> about 3 minutes (with a debug build of llvm), and vim's build >> process runs >> the linker several times (at least 3 times), so total linking time >> is about >> 9 minutes. > > Okay, cool... although the difference between debug and release is > pretty big. clang is roughly 2x faster in release mode, and linking > is roughly 5x faster, if I recall correctly. > >> __builtin_bzero() simply calls the library's bzero() in this patch. >> Would it be better to use the llvm.memset intrinsic instead? I >> believe >> Windows does not have bzero in its c library. > > I'd say don't bother for the moment; if it becomes an issue, we can > deal with it later. Great. Can someone commit the patch? I changed the test so that it does no longer compile and execute the code, it now uses grep. Nico -------------- next part -------------- A non-text attachment was scrubbed... Name: bzero.patch Type: application/octet-stream Size: 489 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080721/78552ce6/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: builtin-bzero.c Type: application/octet-stream Size: 140 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080721/78552ce6/attachment-0001.obj From daniel at zuster.org Mon Jul 21 16:59:46 2008 From: daniel at zuster.org (Daniel Dunbar) Date: Mon, 21 Jul 2008 14:59:46 -0700 (PDT) Subject: [cfe-dev] patch: prefetch builtin support Message-ID: <157300.17094.qm@web54606.mail.re2.yahoo.com> The attached patch implements __builtin_prefetch, including type checking since it is variadic and supports limited arguments. Feedback appreciated on the diagnostic style. I also slipped in __builtin_trap support. - Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: prefetch-and-trap-builtins.patch Type: application/octet-stream Size: 6653 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080721/0e0d18a3/attachment.obj From clattner at apple.com Mon Jul 21 17:18:31 2008 From: clattner at apple.com (Chris Lattner) Date: Mon, 21 Jul 2008 15:18:31 -0700 Subject: [cfe-dev] patch: prefetch builtin support In-Reply-To: <157300.17094.qm@web54606.mail.re2.yahoo.com> References: <157300.17094.qm@web54606.mail.re2.yahoo.com> Message-ID: Looks great to me, please commit. Thanks Daniel! On Jul 21, 2008, at 2:59 PM, Daniel Dunbar wrote: > The attached patch implements __builtin_prefetch, including type > checking since it > is variadic and supports limited arguments. Feedback appreciated on > the diagnostic > style. > > I also slipped in __builtin_trap support. > > - Daniel builtins.patch>_______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From clattner at apple.com Mon Jul 21 17:23:33 2008 From: clattner at apple.com (Chris Lattner) Date: Mon, 21 Jul 2008 15:23:33 -0700 Subject: [cfe-dev] patch: keep llvm module consistent during compilationpatch: keep llvm module consistent during compilation In-Reply-To: <743650.24864.qm@web54601.mail.re2.yahoo.com> References: <743650.24864.qm@web54601.mail.re2.yahoo.com> Message-ID: On Jul 18, 2008, at 10:40 AM, Daniel Dunbar wrote: > The attached patch creates dummy bodies for functions with internal > linkage > when they are created and replaces them when the definition is > compiled. This > helps ensure that the module is in a consistent state after > processing each top > level declaration and prevents crashes in the verifier on malformed > inputs. See > test case. This is a somewhat interesting issue. As you know, I strongly believe in having clang keep its module consistent where possible. There are two possible solutions to this issue: either give static forward decls a body or not mark them internal. Of the two, I prefer the later because it doesn't require creating blocks and instructions only to throw them away later. What do you think? > This should probably be documented at another level than just a code > comment > but I'm not sure where... Yeah, clang as a whole is not well documented from the high-level perspective. We have an internals document but it is pretty thin. > Note that this introduces a problem that modules which declare > static functions > but do not define them will compile (and link!) but this is a bug in > sema. Maybe > we should still be tracking them though to make sure none slip > through to the > outside. This requires CG having some way of knowing when the module > is done. I think we should reject this in sema. > p.s. Comments appreciated on a simpler way to write the DG test I want (checking Does it work to use "-emit-llvm -verify" and slap an "expected-error" note on the line that an error is expected? -Chris From clattner at apple.com Mon Jul 21 17:27:34 2008 From: clattner at apple.com (Chris Lattner) Date: Mon, 21 Jul 2008 15:27:34 -0700 Subject: [cfe-dev] patch: more builtin support In-Reply-To: <739974.58389.qm@web54604.mail.re2.yahoo.com> References: <739974.58389.qm@web54604.mail.re2.yahoo.com> Message-ID: <0E961CB3-34E5-42FC-8FCF-DF1CF98F6FD4@apple.com> On Jul 21, 2008, at 10:28 AM, Daniel Dunbar wrote: >> Looks great to me with one minor change: we don't want the clang >> testsuite to actually execute code. Please make the test just be >> something like this: ... > > > Done. The grep works in this case but this policy is going to be > harder > to deal with for other codegen tests -- either the test is going to > be very > fragile or just not written. > > To take a current example, how do you check that the accesses to the > following bit-field are being compiled correctly without running code: > -- > struct { > _Bool x : 2; > } x; > > int foo () { > return x.x += 1; > } > -- > > Is running code with lli verboten? I agree that this doesn't make sense to grep for, I just think execution tests should go in the llvm-test suite (where llvm-gcc will also get them), e.g. in the test/SingleSource/UnitTests directory. -Chris From clattner at apple.com Mon Jul 21 18:07:40 2008 From: clattner at apple.com (Chris Lattner) Date: Mon, 21 Jul 2008 16:07:40 -0700 Subject: [cfe-dev] always_inline and noinline attributes In-Reply-To: <20080718210928.GK32587@katherina.student.utwente.nl> References: <20080620121519.GH3816@katherina.student.utwente.nl> <20080718210928.GK32587@katherina.student.utwente.nl> Message-ID: On Jul 18, 2008, at 2:09 PM, Matthijs Kooijman wrote: >> Once the information is encoded in the IR, the remaining issue is >> how to >> invoke the LLVM inlining pass when at least one function is marked as >> always_inline. There are two possible approaches: >> >> 1) Teach FE tools (e.g. clang, llvm-gcc) to insert inlining pass in >> the >> PassManager while requesting (opt + code generation) when it least >> one >> function with attribute always_inline is seen. > Perhaps there could be a specific inliner that does only this? This > prevents > surprises when people didn't expect inlining? I'd strongly prefer to do this in the LLVM IR level instead of on clang ASTs. >> 2) Teach the LLVM PassManager to sniff always_inline property >> encoded in >> the LLVM IR and do the right thing. > This sounds like it might also surprise people, if they only add a > single pass > and still things are inlined. Might not be a big problem, though. GCC runs its inliner, even at -O0. I agree it is ugly, but seems necessary. > Another reason why I think encoding in the IR is necessary: If I > have an > always inline function defined in one module and referenced in > another, I > think it should still be inlined after I link the two modules > together, right? No, it should only happen within a translation unit. The semantics of the program should not change based on whether you're using LTO or not, and inlining can sometimes change semantics for (arguably very broken) uses. -Chris From daniel at zuster.org Mon Jul 21 19:26:50 2008 From: daniel at zuster.org (Daniel Dunbar) Date: Mon, 21 Jul 2008 17:26:50 -0700 (PDT) Subject: [cfe-dev] Patch for __builtin_bzero Message-ID: <199920.24777.qm@web54601.mail.re2.yahoo.com> Hi Nico, I just committed implementations of the bzero, memset, and memcpy builtins in terms of llvm intrinsics. This should subsume your patch. Can you confirm that this fixes your vim build? - Daniel ----- Original Message ---- From: Nico Weber To: Eli Friedman Cc: cfe-dev at cs.uiuc.edu Sent: Monday, July 21, 2008 2:20:13 PM Subject: Re: [cfe-dev] Patch for __builtin_bzero On 19.07.2008, at 20:24, Eli Friedman wrote: > On Sat, Jul 19, 2008 at 12:04 AM, Nico Weber > wrote: >> Hi, >> >> with the attached patch, vim7 can be built with `make CC=ccc`. >> Linking takes >> about 3 minutes (with a debug build of llvm), and vim's build >> process runs >> the linker several times (at least 3 times), so total linking time >> is about >> 9 minutes. > > Okay, cool... although the difference between debug and release is > pretty big. clang is roughly 2x faster in release mode, and linking > is roughly 5x faster, if I recall correctly. > >> __builtin_bzero() simply calls the library's bzero() in this patch. >> Would it be better to use the llvm.memset intrinsic instead? I >> believe >> Windows does not have bzero in its c library. > > I'd say don't bother for the moment; if it becomes an issue, we can > deal with it later. Great. Can someone commit the patch? I changed the test so that it does no longer compile and execute the code, it now uses grep. Nico From matthijs at stdin.nl Tue Jul 22 02:08:36 2008 From: matthijs at stdin.nl (Matthijs Kooijman) Date: Tue, 22 Jul 2008 09:08:36 +0200 Subject: [cfe-dev] always_inline and noinline attributes In-Reply-To: References: <20080620121519.GH3816@katherina.student.utwente.nl> <20080718210928.GK32587@katherina.student.utwente.nl> Message-ID: <20080722070836.GZ32587@katherina.student.utwente.nl> > I'd strongly prefer to do this in the LLVM IR level instead of on clang > ASTs. That was the plan, AFAIU. Yet it would make sense to have clang do it at the end of its compilation (by running an inliner over the generated IR). > No, it should only happen within a translation unit. The semantics of the > program should not change based on whether you're using LTO or not, and > inlining can sometimes change semantics for (arguably very broken) uses. Woah, you're saying to only do inlining withing a translation unit? Does this mean that inlining does not happen at all in LTO? I would say that inlining is one of the more obvious uses for LTO and IMHO it would be a waste not to do it because it would change broken programs. Could you perhaps give an example of a use that would be semantically changed by inlining? At the very least, I would make it an option whether to strip the always_inline info after compiling a single translation unit, so people can explicitely choose to still do (forced) inlining at link time. Gr. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080722/9e1d3e9a/attachment.bin From eli.friedman at gmail.com Tue Jul 22 10:11:26 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Tue, 22 Jul 2008 08:11:26 -0700 Subject: [cfe-dev] always_inline and noinline attributes In-Reply-To: <20080722070836.GZ32587@katherina.student.utwente.nl> References: <20080620121519.GH3816@katherina.student.utwente.nl> <20080718210928.GK32587@katherina.student.utwente.nl> <20080722070836.GZ32587@katherina.student.utwente.nl> Message-ID: On Tue, Jul 22, 2008 at 12:08 AM, Matthijs Kooijman wrote: >> I'd strongly prefer to do this in the LLVM IR level instead of on clang >> ASTs. > That was the plan, AFAIU. Yet it would make sense to have clang do it at the > end of its compilation (by running an inliner over the generated IR). > >> No, it should only happen within a translation unit. The semantics of the >> program should not change based on whether you're using LTO or not, and >> inlining can sometimes change semantics for (arguably very broken) uses. > At the very least, I would make it an option whether to strip the > always_inline info after compiling a single translation unit, so people can > explicitely choose to still do (forced) inlining at link time. Unless I'm mistaking the semantics of always_inline, it should be a compile-time error to take the address of an always_inline function, and always_inline functions shouldn't be exposed as external symbols. Otherwise, it's impossible for the compiler to honor the "always_inline" attribute. In any case, the issue isn't whether to do inlining with LTO, but whether to force inlining with LTO. -Eli From dpatel at apple.com Tue Jul 22 12:26:07 2008 From: dpatel at apple.com (Devang Patel) Date: Tue, 22 Jul 2008 10:26:07 -0700 Subject: [cfe-dev] always_inline and noinline attributes In-Reply-To: <20080722070836.GZ32587@katherina.student.utwente.nl> References: <20080620121519.GH3816@katherina.student.utwente.nl> <20080718210928.GK32587@katherina.student.utwente.nl> <20080722070836.GZ32587@katherina.student.utwente.nl> Message-ID: <901E4288-1B29-4051-990F-CCDDD3C297CC@apple.com> On Jul 22, 2008, at 12:08 AM, Matthijs Kooijman wrote: >> I'd strongly prefer to do this in the LLVM IR level instead of on >> clang >> ASTs. > That was the plan, AFAIU. Yet it would make sense to have clang do > it at the > end of its compilation (by running an inliner over the generated IR). > >> No, it should only happen within a translation unit. The semantics >> of the >> program should not change based on whether you're using LTO or not, >> and >> inlining can sometimes change semantics for (arguably very broken) >> uses. Chris, that's why I used the word "hope" :). I think, in real world, if a function is mark as always_inline in one translation unit, then it is always (:)) marked as always_inline in all translation unit. However, If the semantics requires always_inline to not cross translation unit limit during LTO then the optimizer needs a notion of inlining scope or something like that. >> Woah, you're saying to only do inlining withing a translation unit? >> Does this > mean that inlining does not happen at all in LTO? Matthijs, This means, always_inline is not enforced while doing inlining at LTO. In other words, inlining still happens but always_inline does not override normal inline heuristics used by the inliner. > I would say that inlining is > one of the more obvious uses for LTO and IMHO it would be a waste > not to do it > because it would change broken programs. Could you perhaps give an > example of > a use that would be semantically changed by inlining? > > At the very least, I would make it an option whether to strip the > always_inline info after compiling a single translation unit, so > people can > explicitely choose to still do (forced) inlining at link time. This may not be possible in all cases. - Devang From dpatel at apple.com Tue Jul 22 12:38:45 2008 From: dpatel at apple.com (Devang Patel) Date: Tue, 22 Jul 2008 10:38:45 -0700 Subject: [cfe-dev] always_inline and noinline attributes In-Reply-To: References: <20080620121519.GH3816@katherina.student.utwente.nl> <20080718210928.GK32587@katherina.student.utwente.nl> <20080722070836.GZ32587@katherina.student.utwente.nl> Message-ID: <276A2C8B-29C7-40B2-AD72-763B276DB77F@apple.com> On Jul 22, 2008, at 8:11 AM, Eli Friedman wrote: > Unless I'm mistaking the semantics of always_inline, it should be a > compile-time error to take the address of an always_inline function, > and always_inline functions shouldn't be exposed as external symbols. > Otherwise, it's impossible for the compiler to honor the > "always_inline" attribute. 1) inlining a function and 2) throwing away a function definition when function is inlined at all call sites are two separate operations. always_inline does not enforce 2) and always_inline does change symbol visibility. In gcc, -fvisibility-inlines-hidden enforces what you're describing. - Devang From dpatel at apple.com Tue Jul 22 12:40:11 2008 From: dpatel at apple.com (Devang Patel) Date: Tue, 22 Jul 2008 10:40:11 -0700 Subject: [cfe-dev] always_inline and noinline attributes In-Reply-To: <276A2C8B-29C7-40B2-AD72-763B276DB77F@apple.com> References: <20080620121519.GH3816@katherina.student.utwente.nl> <20080718210928.GK32587@katherina.student.utwente.nl> <20080722070836.GZ32587@katherina.student.utwente.nl> <276A2C8B-29C7-40B2-AD72-763B276DB77F@apple.com> Message-ID: On Jul 22, 2008, at 10:38 AM, Devang Patel wrote: > > On Jul 22, 2008, at 8:11 AM, Eli Friedman wrote: > >> Unless I'm mistaking the semantics of always_inline, it should be a >> compile-time error to take the address of an always_inline function, >> and always_inline functions shouldn't be exposed as external symbols. >> Otherwise, it's impossible for the compiler to honor the >> "always_inline" attribute. > > 1) inlining a function and 2) throwing away a function definition when > function is inlined at all call sites are two separate operations. > > always_inline does not enforce 2) and always_inline does change symbol > visibility. oops, I meant : "always_inline does not change symbol visibility" > > > In gcc, -fvisibility-inlines-hidden enforces what you're describing. > - > Devang > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From nicolasweber at gmx.de Tue Jul 22 16:18:27 2008 From: nicolasweber at gmx.de (Nico Weber) Date: Tue, 22 Jul 2008 23:18:27 +0200 Subject: [cfe-dev] How do I detect global variables? Message-ID: Hi, to learn more about clang, I'm trying to use it to write a small program that parses a C program and prints all global variables it finds. For now, I don't want to use Sema and AST, but do that part myself. I've got a Preprocessor and a Parser set up, and I've derived a class from MinimalAction. Now, what's the best method to find all global variable definitions? (global functions are not interesting, and I don't want to find globals form system headers). Right now, I'm trying to overwrite ActOnDeclarator. In there, I only look at variables with FileContext, and reject everything that is `extern` (I only want the definitions of globals). Furthermore, I try to skip functions by checking for PQ_FunctionSpecifier, but that does not seem to skip all functions (for example, the `main` function of my test input program). And it does not skip stuff that comes from angle- bracket includes: Action::DeclTy * ActOnDeclarator(Scope *S, Declarator &D, DeclTy *LastInGroup) { // Print names of global variables if (D.getContext() == Declarator::FileContext) { IdentifierInfo *II = D.getIdentifier(); const DeclSpec& DS = D.getDeclSpec(); if (DS.getStorageClassSpec() != DeclSpec::SCS_extern && (DS.getParsedSpecifiers() & DeclSpec::PQ_FunctionSpecifier) == 0) { cerr << "Found global declarator " << II->getName() << " " << D.getNumTypeObjects() << endl; } } Can you give me a few hints where I should look to add that functionality? Thanks, Nico From eli.friedman at gmail.com Tue Jul 22 18:56:17 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Tue, 22 Jul 2008 16:56:17 -0700 Subject: [cfe-dev] How do I detect global variables? In-Reply-To: References: Message-ID: On Tue, Jul 22, 2008 at 2:18 PM, Nico Weber wrote: > Now, what's the best method to find all global variable definitions? > (global functions are not interesting, and I don't want to find > globals form system headers). > > Right now, I'm trying to overwrite ActOnDeclarator. In there, I only > look at variables with FileContext, and reject everything that is > `extern` (I only want the definitions of globals). Furthermore, I try > to skip functions by checking for PQ_FunctionSpecifier, but that does > not seem to skip all functions (for example, the `main` function of my > test input program). Right... it would be easier to do this from an ASTConsumer, where you would have access to types. Fundamentally, in C, it's impossible to tell apart a global function declaration and a global variable declaration without resolving typedefs and __typeof expressions. Since that's beyond the scope of the parser, you'll either need to use Sema, do these yourself, or be a bit conservative about printing out things that aren't actually globals. Examples of function declarations without an explicit type declarator: typedef int x(); x z; __typeof(z) r; Also, with AST information, you can easily do other interesting things, like printing the canonical type (the type stripped of typedefs), or printing out all globals of a particular type, or pretty-printing initializers, or more easily supporting C++ namespaces/classes using a visitor pattern. If you're willing to be conservative with the cases of declaring a function with __typeof or typedef, it isn't too hard. The check you need is for whether the outermost type declarator is a function type declarator (untested, but something like "D.getTypeObject(D.getNumTypeObjects() - 1).Kind == DeclaratorChunk::Function"). PQ_FunctionSpecifier isn't even close to what you want; it essentially tracks whether "inline" was specified on the declaration. If you want to try and resolve typedefs, try looking at the implementation of MinimalAction in clang/lib/Parser/MinimalAction.cpp. Resolving __typeof would require implementing a large chunk of Sema, so that's probably not something you want to mess with. > And it does not skip stuff that comes from angle- > bracket includes: clang/lib/Sema/SemaDecl.cpp does this as follows: SourceManager &SrcMgr = Context.getSourceManager(); HeaderSearch &HdrInfo = PP.getHeaderSearchInfo(); const FileEntry *OldDeclFile = SrcMgr.getFileEntryForLoc(Old->getLocation()); if (OldDeclFile) { DirectoryLookup::DirType OldDirType = HdrInfo.getFileDirFlavor(OldDeclFile); // Allow reclarations in both SystemHeaderDir and ExternCSystemHeaderDir. if (OldDirType != DirectoryLookup::NormalHeaderDir) return New; } That said, we should probably move this into some sort of helper method on the Preprocessor class or something like that. Would someone more familiar with the Preprocessor mind commenting? > Action::DeclTy * > ActOnDeclarator(Scope *S, Declarator &D, DeclTy *LastInGroup) { > // Print names of global variables > if (D.getContext() == Declarator::FileContext) { > IdentifierInfo *II = D.getIdentifier(); > const DeclSpec& DS = D.getDeclSpec(); > > if (DS.getStorageClassSpec() != DeclSpec::SCS_extern > && (DS.getParsedSpecifiers() & > DeclSpec::PQ_FunctionSpecifier) == 0) { > cerr << "Found global declarator " << II->getName() > << " " << D.getNumTypeObjects() << endl; > } > } The last line of this method must be "return MinimalAction::ActOnDeclarator(S, D, LastInGroup);"; otherwise, you'll mess up the implementation of MinimalAction::isTypeName(), which in turn will cause parse errors. > Can you give me a few hints where I should look to add that > functionality? If you want to contribute it to clang? My first instinct is clang/Driver/ASTConsumers.cpp, assuming you wrote an implementation as an ASTConsumer. That said, I'm not sure how useful this would be; if anyone else would find this useful, please comment. -Eli From eli.friedman at gmail.com Tue Jul 22 19:10:49 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Tue, 22 Jul 2008 17:10:49 -0700 Subject: [cfe-dev] always_inline and noinline attributes In-Reply-To: <276A2C8B-29C7-40B2-AD72-763B276DB77F@apple.com> References: <20080620121519.GH3816@katherina.student.utwente.nl> <20080718210928.GK32587@katherina.student.utwente.nl> <20080722070836.GZ32587@katherina.student.utwente.nl> <276A2C8B-29C7-40B2-AD72-763B276DB77F@apple.com> Message-ID: On Tue, Jul 22, 2008 at 10:38 AM, Devang Patel wrote: > > On Jul 22, 2008, at 8:11 AM, Eli Friedman wrote: > >> Unless I'm mistaking the semantics of always_inline, it should be a >> compile-time error to take the address of an always_inline function, >> and always_inline functions shouldn't be exposed as external symbols. >> Otherwise, it's impossible for the compiler to honor the >> "always_inline" attribute. > > 1) inlining a function and 2) throwing away a function definition when > function is inlined at all call sites are two separate operations. > > always_inline does not enforce 2) and always_inline does change symbol > visibility. Oh... okay, thanks for clarifying. That said, it seems sort of silly. If the function can't be removed, doesn't always_inline just force the compiler to bloat the code? Is there some attribute that would enforce throwing away the definition? If not, would it be useful to add one? Or is always_inline along with static generally good enough? > In gcc, -fvisibility-inlines-hidden enforces what you're describing. That isn't quite the same thing; it affects all inlines, and it doesn't prevent taking the address. -Eli From dpatel at apple.com Tue Jul 22 19:38:46 2008 From: dpatel at apple.com (Devang Patel) Date: Tue, 22 Jul 2008 17:38:46 -0700 Subject: [cfe-dev] always_inline and noinline attributes In-Reply-To: References: <20080620121519.GH3816@katherina.student.utwente.nl> <20080718210928.GK32587@katherina.student.utwente.nl> <20080722070836.GZ32587@katherina.student.utwente.nl> <276A2C8B-29C7-40B2-AD72-763B276DB77F@apple.com> Message-ID: <7C183B17-B738-4619-B71F-1CA76CBCA420@apple.com> On Jul 22, 2008, at 5:10 PM, Eli Friedman wrote: > Oh... okay, thanks for clarifying. That said, it seems sort of silly. > If the function can't be removed, doesn't always_inline just force > the compiler to bloat the code? > > Is there some attribute that would enforce throwing away the > definition? If not, would it be useful to add one? Or is > always_inline along with static generally good enough? I *think* using "static" is the only option. Note, this is a gcc extension. - Devang From mrs at apple.com Tue Jul 22 20:03:53 2008 From: mrs at apple.com (Mike Stump) Date: Tue, 22 Jul 2008 18:03:53 -0700 Subject: [cfe-dev] always_inline and noinline attributes In-Reply-To: <7C183B17-B738-4619-B71F-1CA76CBCA420@apple.com> References: <20080620121519.GH3816@katherina.student.utwente.nl> <20080718210928.GK32587@katherina.student.utwente.nl> <20080722070836.GZ32587@katherina.student.utwente.nl> <276A2C8B-29C7-40B2-AD72-763B276DB77F@apple.com> <7C183B17-B738-4619-B71F-1CA76CBCA420@apple.com> Message-ID: On Jul 22, 2008, at 5:38 PM, Devang Patel wrote: > On Jul 22, 2008, at 5:10 PM, Eli Friedman wrote: >> Oh... okay, thanks for clarifying. That said, it seems sort of >> silly. >> If the function can't be removed, doesn't always_inline just force >> the compiler to bloat the code? >> >> Is there some attribute that would enforce throwing away the >> definition? If not, would it be useful to add one? Or is >> always_inline along with static generally good enough? > > I *think* using "static" is the only option. Note, this is a gcc > extension. I have a different take. gcc allows one to do: static int foo(int) __attribute__ ((always_inline)); inline int foo(int i) { return i + 1; } volatile void *vp = foo; int main() { return foo(0); } because they allow this, they have to emit the always_inline function. This goes against common sense, so, I'd argue this is a bug that should be fixed, and when fixed, there can't be any references to the always_inline function. If you want one in the file, you have to have one without always_inline, pedantically, this is even probably wrong (ODR). While I don't mind being slavishly compatible with gcc/g++, I do think we should draw the line at bug for bug compatibility. If there is a question as to wether this is a bug or feature, certainly a gcc bug report should be able to answer that. From matthijs at stdin.nl Wed Jul 23 06:43:39 2008 From: matthijs at stdin.nl (Matthijs Kooijman) Date: Wed, 23 Jul 2008 13:43:39 +0200 Subject: [cfe-dev] always_inline and noinline attributes In-Reply-To: <901E4288-1B29-4051-990F-CCDDD3C297CC@apple.com> References: <20080620121519.GH3816@katherina.student.utwente.nl> <20080718210928.GK32587@katherina.student.utwente.nl> <20080722070836.GZ32587@katherina.student.utwente.nl> <901E4288-1B29-4051-990F-CCDDD3C297CC@apple.com> Message-ID: <20080723114339.GL32587@katherina.student.utwente.nl> Hi all, I think that a lot of confusion arises from unclarity about what always_inline actually means. The gcc docs [1] say: Generally, functions are not inlined unless optimization is specified. For functions declared inline, this attribute inlines the function even if no optimization level was specified. This is not very specific on topics on taking function pointers and different translation units, though. I see roughtly two options: 1) A function marked always_inline must always be inlined. This means it cannot be used in other way, so taking the address of an always_inline function is an error. 2) A function marked always_inline must be inlined whenever possible. This means that any other uses simply won't get inlined, but are allowed. Neither of these options would actually limit the visibility of thefunction, as far as I can see. When the function is static, the function can normally be DCE'd after inlining (which will always happen for 1), but might not happen for 2)). We could make always_inline work only with static functions, but I can't really see why that would be necessary. IMHO, it would even greatly reduce the usefulness of always_inline. When the function is not static, it will still be inlined at all the callsites within the same translation unit. We then have again two interpretations: a) An always_inline attribute only works within the same translation unit. Functions that are visible outside of the unit, are treated just as any other function at link time, as if the always_inline attribute was not specified. b) An always_inline attribute stays with a function, regardless of its visibility. Any call site of the function, regardless of the translation unit in which it lives, is inlined. Option a) would be easiest to implement, but again lose a lost of usefulness compared to option b). Option b) does require that inlining happens again at link time, so any call sites in other translation units are inlined as well. Also, option b) would be slightly tricky to combine with option 1), unless the always_inline attribute is (can be) present on the definition as well as the declaration of the function. Option b) combined with option 2) shouldn't have this problem. I think that Chris is really in favour of option b) here, because "inlining can sometimes change semantics". However, I still don't really understand what kind of cases we are talking about. Chris, could you give an example? Also, is this changing of semantics specific to always_inline? From what you wrote, I would assume that this changing of semantics can happen with any inline, so you shouldn't be doing any inlining at all at link time. Nor at optimization time, for that matter, so I'm probably missing an essential point here :-) Also, Devang pointed out that inlining at link time might not be possible in all cases. Again, the only case I can think of is taking the address of a function, but this could easily be solved by using option 2), ie inline whenever possible and leave the original function otherwise. Furthermore, for our project we do actually need to have option b). AFAICS option b) is fine as the default, but apparently I'm missing something there. In any case, it would be very convenient to at least support option b), even when it is not the default. This could perhaps be done through commandline options to clang and/or the linker, or at the very least through options that we can set in our own compiler driver (which links against clang, transformation passes and the linker libraries). So, which are the semantics that always_inline imply? What does gcc do? Gr. Matthijs [1]: http://gcc.gnu.org/onlinedocs/gcc-4.0.4/gcc/Function-Attributes.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080723/3f7a1884/attachment.bin From nicolasweber at gmx.de Wed Jul 23 07:00:27 2008 From: nicolasweber at gmx.de (Nico Weber) Date: Wed, 23 Jul 2008 14:00:27 +0200 Subject: [cfe-dev] How do I detect global variables? In-Reply-To: References: Message-ID: Hi, On 23.07.2008, at 01:56, Eli Friedman wrote: > On Tue, Jul 22, 2008 at 2:18 PM, Nico Weber > wrote: >> Now, what's the best method to find all global variable definitions? >> (global functions are not interesting, and I don't want to find >> globals form system headers). >> >> Right now, I'm trying to overwrite ActOnDeclarator. In there, I only >> look at variables with FileContext, and reject everything that is >> `extern` (I only want the definitions of globals). Furthermore, I try >> to skip functions by checking for PQ_FunctionSpecifier, but that does >> not seem to skip all functions (for example, the `main` function of >> my >> test input program). > > Right... it would be easier to do this from an ASTConsumer, where you > would have access to types. Fundamentally, in C, it's impossible to > tell apart a global function declaration and a global variable > declaration without resolving typedefs and __typeof expressions. *snip* > If you want to try and resolve typedefs, try looking at the > implementation of MinimalAction in clang/lib/Parser/MinimalAction.cpp. > Resolving __typeof would require implementing a large chunk of Sema, > so that's probably not something you want to mess with. Thanks for the thorough reply. It helped a lot, my program now does what I wanted it to do. >> Can you give me a few hints where I should look to add that >> functionality? > > If you want to contribute it to clang? My first instinct is > clang/Driver/ASTConsumers.cpp, assuming you wrote an implementation as > an ASTConsumer. That said, I'm not sure how useful this would be; if > anyone else would find this useful, please comment. No, I don't want to contribute this to clang. It's just my little "get- to-know-clang" project. I don't think it's very useful myself. Thanks again, Nico From luismarques at gmail.com Wed Jul 23 08:24:22 2008 From: luismarques at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Marques?=) Date: Wed, 23 Jul 2008 14:24:22 +0100 Subject: [cfe-dev] always_inline and noinline attributes In-Reply-To: <20080723114339.GL32587@katherina.student.utwente.nl> References: <20080620121519.GH3816@katherina.student.utwente.nl> <20080718210928.GK32587@katherina.student.utwente.nl> <20080722070836.GZ32587@katherina.student.utwente.nl> <901E4288-1B29-4051-990F-CCDDD3C297CC@apple.com> <20080723114339.GL32587@katherina.student.utwente.nl> Message-ID: <408520e0807230624t4719df5bvd3b50650efa5d682@mail.gmail.com> Hi, > 1) A function marked always_inline must always be inlined. This means it > cannot be used in other way, so taking the address of an always_inline > function is an error. I have been thinking about this. Would it be too hard to make this rule more flexible, so that for instance the following case would be possible: const int CONFIG_OPTIMIZED = 1; int foo(int x) __attribute__ ((always_inline)) { if(CONFIG_OPTIMIZED) return foo_optimized(x); else return foo_fast(x); } Taking the address of foo() would return the address either foo_optimized or foo_fast. Of course this could be done with the preprocessor, but using the preprocessor has several disadvantages (in terms of maintenance). -- Lu?s Marques From matthijs at stdin.nl Wed Jul 23 10:35:32 2008 From: matthijs at stdin.nl (Matthijs Kooijman) Date: Wed, 23 Jul 2008 17:35:32 +0200 Subject: [cfe-dev] always_inline and noinline attributes In-Reply-To: <408520e0807230624t4719df5bvd3b50650efa5d682@mail.gmail.com> References: <20080620121519.GH3816@katherina.student.utwente.nl> <20080718210928.GK32587@katherina.student.utwente.nl> <20080722070836.GZ32587@katherina.student.utwente.nl> <901E4288-1B29-4051-990F-CCDDD3C297CC@apple.com> <20080723114339.GL32587@katherina.student.utwente.nl> <408520e0807230624t4719df5bvd3b50650efa5d682@mail.gmail.com> Message-ID: <20080723153532.GO32587@katherina.student.utwente.nl> Hi Lu?s, > I have been thinking about this. Would it be too hard to make this > rule more flexible, so that for instance the following case would be > possible: The following code would be valid when you use the other interpretation, that an always_inline function is inlined whenever possible. > const int CONFIG_OPTIMIZED = 1; > > int foo(int x) __attribute__ ((always_inline)) > { > if(CONFIG_OPTIMIZED) > return foo_optimized(x); > else > return foo_fast(x); > } > > Taking the address of foo() would return the address either > foo_optimized or foo_fast. Interesting case. A possible solution would be to mark foo_optimized and foo_fast as always_inline as well, so that they will be inlined here and the unused one will be removed by simplifycfg or some other pass. However, if you really want the address of foo to be replaced with the address of either foo_optimized or foo_fast, I guess you would need to use some pass to turn foo into int foo (int x) { return foo_optmized(x); } and then have some other pass (not sure which, really), to specifically look for function looking like this and replace all uses of foo with foo_optimized (possibly also direct calls). In any case, I don't think that this optimization is directly related to always_inline or inlining at all. It would be cool to support this transformation, though there might be a few tricky exception cases to be handled. Gr. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080723/34836ed5/attachment.bin From kremenek at apple.com Wed Jul 23 11:19:10 2008 From: kremenek at apple.com (Ted Kremenek) Date: Wed, 23 Jul 2008 09:19:10 -0700 Subject: [cfe-dev] Memory leak analysis and self destructing objects In-Reply-To: References: Message-ID: <92CB4AC8-B17C-437C-928F-6A5E6397B77F@apple.com> On Jun 20, 2008, at 1:42 AM, Nikita Zhuk wrote: > For example: > -(void)awakeFromNib > { > NSWindow *window = [[NSWindow alloc] > initWithContentRect:NSMakeRect(0,0,100,100) > styleMask:NSTitledWindowMask|NSClosableWindowMask backing: > NSBackingStoreBuffered defer:NO]; // isReleasedWhenClosed is set to > YES by default > [window orderFrontRegardless]; > > // False memory leak reported - window will be released when user > closes it > } I'm reopened this issue as a new Bugzilla report: http://llvm.org/bugs/show_bug.cgi?id=2588 It turns out that an NSWindow object doesn't self-own itself until it is displayed, so the code snippet above is actually a real leak. Right now the analyzer has been tweaked to consider an NSWindow object to be self-owning once it is initialized, but this is not correct. The bugzilla report has more information. Ted From dpatel at apple.com Wed Jul 23 12:21:54 2008 From: dpatel at apple.com (Devang Patel) Date: Wed, 23 Jul 2008 10:21:54 -0700 Subject: [cfe-dev] always_inline and noinline attributes In-Reply-To: <20080723114339.GL32587@katherina.student.utwente.nl> References: <20080620121519.GH3816@katherina.student.utwente.nl> <20080718210928.GK32587@katherina.student.utwente.nl> <20080722070836.GZ32587@katherina.student.utwente.nl> <901E4288-1B29-4051-990F-CCDDD3C297CC@apple.com> <20080723114339.GL32587@katherina.student.utwente.nl> Message-ID: <64694E0C-804F-4678-838B-D9E4E4582D4A@apple.com> On Jul 23, 2008, at 4:43 AM, Matthijs Kooijman wrote: > Hi all, > > I think that a lot of confusion arises from unclarity about what > always_inline > actually means. > > The gcc docs [1] say: > Generally, functions are not inlined unless optimization is > specified. For > functions declared inline, this attribute inlines the function even > if no > optimization level was specified. > > This is not very specific on topics on taking function pointers and > different > translation units, though. I see roughtly two options: > > 1) A function marked always_inline must always be inlined. This > means it > cannot be used in other way, so taking the address of an always_inline > function is an error. > 2) A function marked always_inline must be inlined whenever > possible. This > means that any other uses simply won't get inlined, but are allowed. Consider this example, --- a.c --- int foo() __attribute__((always_inline)); int foo() { return 42; } int bar() { return foo() + foo(); } --- b.c --- extern int foo(); int main() { int (*fp)() = &foo; printf("%d\n", fp()); return 0; } --- This works. While compiling and optimizing b.c, the compiler does not know that foo() is marked as always_inline. However, during LTO, the optimizer will know. > > Neither of these options would actually limit the visibility of > thefunction, > as far as I can see. When the function is static, the function can > normally be > DCE'd after inlining (which will always happen for 1), but might not > happen > for 2)). In case of 1) if a library exports always_inline function then it can not be DCE'd while building library. > > > We could make always_inline work only with static functions, but I > can't > really see why that would be necessary. IMHO, it would even greatly > reduce the > usefulness of always_inline. > > When the function is not static, it will still be inlined at all the > callsites > within the same translation unit. We then have again two > interpretations: > > a) An always_inline attribute only works within the same translation > unit. > Functions that are visible outside of the unit, are treated just as > any other > function at link time, as if the always_inline attribute was not > specified. > b) An always_inline attribute stays with a function, regardless of its > visibility. Any call site of the function, regardless of the > translation unit > in which it lives, is inlined. > > Option a) would be easiest to implement, but again lose a lost of > usefulness > compared to option b). Option b) does require that inlining happens > again at > link time, so any call sites in other translation units are inlined > as well. I think, Option b) is easier to implement. > Also, option b) would be slightly tricky to combine with option 1), > unless the > always_inline attribute is (can be) present on the definition as > well as the > declaration of the function. Option b) combined with option 2) > shouldn't have > this problem. > > I think that Chris is really in favour of option b) here, because > "inlining > can sometimes change semantics". However, I still don't really > understand what > kind of cases we are talking about. Chris, could you give an > example? Also, is > this changing of semantics specific to always_inline? From what you > wrote, I > would assume that this changing of semantics can happen with any > inline, so > you shouldn't be doing any inlining at all at link time. Nor at > optimization > time, for that matter, so I'm probably missing an essential point > here :-) > > Also, Devang pointed out that inlining at link time might not be > possible in > all cases. I did not mean this. --- quote begin --- >> At the very least, I would make it an option whether to strip the >> always_inline info after compiling a single translation unit, so >> people can >> explicitely choose to still do (forced) inlining at link time. > > This may not be possible in all cases. --- quote end --- I meant, it may not be possible to guarantee that always_inline info is stripped in a llvm module presented to the link time optimizer. Sorry for the confusion. - Devang From mrs at apple.com Wed Jul 23 14:39:10 2008 From: mrs at apple.com (Mike Stump) Date: Wed, 23 Jul 2008 12:39:10 -0700 Subject: [cfe-dev] always_inline and noinline attributes In-Reply-To: <20080723114339.GL32587@katherina.student.utwente.nl> References: <20080620121519.GH3816@katherina.student.utwente.nl> <20080718210928.GK32587@katherina.student.utwente.nl> <20080722070836.GZ32587@katherina.student.utwente.nl> <901E4288-1B29-4051-990F-CCDDD3C297CC@apple.com> <20080723114339.GL32587@katherina.student.utwente.nl> Message-ID: <50762843-4DC7-462F-AEF1-B94D1C2BA691@apple.com> On Jul 23, 2008, at 4:43 AM, Matthijs Kooijman wrote: > 1) A function marked always_inline must always be inlined. Yes. Though, seems reasonable to let this inlining happen at link time as well. > b) An always_inline attribute stays with a function, regardless of its > visibility. Any call site of the function, regardless of the > translation unit > in which it lives, is inlined. Yes. One way to look at this, is, the always_inline body is never used to generate a stand alone function. From matthijs at stdin.nl Wed Jul 23 17:10:44 2008 From: matthijs at stdin.nl (Matthijs Kooijman) Date: Thu, 24 Jul 2008 00:10:44 +0200 Subject: [cfe-dev] always_inline and noinline attributes In-Reply-To: <64694E0C-804F-4678-838B-D9E4E4582D4A@apple.com> References: <20080620121519.GH3816@katherina.student.utwente.nl> <20080718210928.GK32587@katherina.student.utwente.nl> <20080722070836.GZ32587@katherina.student.utwente.nl> <901E4288-1B29-4051-990F-CCDDD3C297CC@apple.com> <20080723114339.GL32587@katherina.student.utwente.nl> <64694E0C-804F-4678-838B-D9E4E4582D4A@apple.com> Message-ID: <20080723221044.GQ32587@katherina.student.utwente.nl> Hi Devang, >> 1) A function marked always_inline must always be inlined. This means it >> cannot be used in other way, so taking the address of an always_inline >> function is an error. > >> 2) A function marked always_inline must be inlined whenever possible. This >> means that any other uses simply won't get inlined, but are allowed. > > Consider this example, > --- a.c --- > int foo() __attribute__((always_inline)); > int foo() { return 42; } > int bar() { > return foo() + foo(); > } > --- b.c --- > extern int foo(); > int main() { > int (*fp)() = &foo; > printf("%d\n", fp()); > return 0; > } > --- > > This works. With plain gcc I assume? Or also clang and/or llvm-gcc? This would suggest that gcc uses option 2) instead of option 1) and we should probably too. > While compiling and optimizing b.c, the compiler does not know that foo() > is marked as always_inline. However, during LTO, the optimizer will know. Even if it did know, it wouldn't change anything as long as b.c didn't have the function body. During LTO, the optimizer will know if we keep the always_inline attribute in the IR (which corresponds to b) below and which we should do IMO). >> Neither of these options would actually limit the visibility of >> thefunction, as far as I can see. When the function is static, the function >> can normally be DCE'd after inlining (which will always happen for 1), but >> might not happen for 2)). > > In case of 1) if a library exports always_inline function then it can not > be DCE'd while building library. Yeah, but I was talking about a static function (which is identical to internal and thus not exported, right?) >> a) An always_inline attribute only works within the same translation unit. >> Functions that are visible outside of the unit, are treated just as any >> other function at link time, as if the always_inline attribute was not >> specified. > >> b) An always_inline attribute stays with a function, regardless of its >> visibility. Any call site of the function, regardless of the translation >> unit in which it lives, is inlined. > I think, Option b) is easier to implement. My guess was that throwing away the always_inline attribute and leaving the linker unchanged would be easier, though it doesn't really matter much. >> Also, Devang pointed out that inlining at link time might not be possible >> in all cases. > > I did not mean this. > > --- quote begin --- >>> At the very least, I would make it an option whether to strip the >>> always_inline info after compiling a single translation unit, so >>> people can >>> explicitely choose to still do (forced) inlining at link time. >> >> This may not be possible in all cases. > --- quote end --- > > I meant, it may not be possible to guarantee that always_inline info is > stripped in a llvm module presented to the link time optimizer. Sorry for > the confusion. I was thinking of doing this stripping in the tool generating the LLVM module, so opt (or perhaps clang?). It should always be able to just throw away the always_inline global and the function should then be just a normal function. I'm not sure if having such a strip-always_inline option is needed, at least not if the default is to preserve always_inline information. I was proposing this option, because IIRC someone proposed or implied throwing away the always_inline info by default. Devang, if I see this right, you agree with me that the combination of 2) and b) are the "right" ones? Gr. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080724/897347bb/attachment.bin From devlists at shadowlab.org Wed Jul 23 18:20:14 2008 From: devlists at shadowlab.org (Jean-Daniel Dupas) Date: Thu, 24 Jul 2008 01:20:14 +0200 Subject: [cfe-dev] Memory leak analysis and self destructing objects In-Reply-To: <92CB4AC8-B17C-437C-928F-6A5E6397B77F@apple.com> References: <92CB4AC8-B17C-437C-928F-6A5E6397B77F@apple.com> Message-ID: <900A02CE-F93C-4FCB-AC90-2E613A4ADC97@shadowlab.org> Le 23 juil. 08 ? 18:19, Ted Kremenek a ?crit : > > On Jun 20, 2008, at 1:42 AM, Nikita Zhuk wrote: > >> For example: >> -(void)awakeFromNib >> { >> NSWindow *window = [[NSWindow alloc] >> initWithContentRect:NSMakeRect(0,0,100,100) >> styleMask:NSTitledWindowMask|NSClosableWindowMask backing: >> NSBackingStoreBuffered defer:NO]; // isReleasedWhenClosed is set to >> YES by default >> [window orderFrontRegardless]; >> >> // False memory leak reported - window will be released when user >> closes it >> } > > I'm reopened this issue as a new Bugzilla report: > > http://llvm.org/bugs/show_bug.cgi?id=2588 > > It turns out that an NSWindow object doesn't self-own itself until it > is displayed, so the code snippet above is actually a real leak. > Right now the analyzer has been tweaked to consider an NSWindow object > to be self-owning once it is initialized, but this is not correct. > The bugzilla report has more information. > > Ted -orderFrontRegardless is a method that displays the window, so no, this code snippet is not a leak. From kremenek at apple.com Wed Jul 23 18:23:10 2008 From: kremenek at apple.com (Ted Kremenek) Date: Wed, 23 Jul 2008 16:23:10 -0700 Subject: [cfe-dev] Memory leak analysis and self destructing objects In-Reply-To: <900A02CE-F93C-4FCB-AC90-2E613A4ADC97@shadowlab.org> References: <92CB4AC8-B17C-437C-928F-6A5E6397B77F@apple.com> <900A02CE-F93C-4FCB-AC90-2E613A4ADC97@shadowlab.org> Message-ID: On Jul 23, 2008, at 4:20 PM, Jean-Daniel Dupas wrote: > > Le 23 juil. 08 ? 18:19, Ted Kremenek a ?crit : > >> >> On Jun 20, 2008, at 1:42 AM, Nikita Zhuk wrote: >> >>> For example: >>> -(void)awakeFromNib >>> { >>> NSWindow *window = [[NSWindow alloc] >>> initWithContentRect:NSMakeRect(0,0,100,100) >>> styleMask:NSTitledWindowMask|NSClosableWindowMask backing: >>> NSBackingStoreBuffered defer:NO]; // isReleasedWhenClosed is set to >>> YES by default >>> [window orderFrontRegardless]; >>> >>> // False memory leak reported - window will be released when user >>> closes it >>> } >> >> I'm reopened this issue as a new Bugzilla report: >> >> http://llvm.org/bugs/show_bug.cgi?id=2588 >> >> It turns out that an NSWindow object doesn't self-own itself until it >> is displayed, so the code snippet above is actually a real leak. >> Right now the analyzer has been tweaked to consider an NSWindow >> object >> to be self-owning once it is initialized, but this is not correct. >> The bugzilla report has more information. >> >> Ted > > -orderFrontRegardless is a method that displays the window, so no, > this code snippet is not a leak. Thanks Jean-Daniel. I had missed that method call when I glanced over the code. The analyzer still doesn't handle NSWindow properly. From dpatel at apple.com Wed Jul 23 18:46:46 2008 From: dpatel at apple.com (Devang Patel) Date: Wed, 23 Jul 2008 16:46:46 -0700 Subject: [cfe-dev] always_inline and noinline attributes In-Reply-To: <20080723221044.GQ32587@katherina.student.utwente.nl> References: <20080620121519.GH3816@katherina.student.utwente.nl> <20080718210928.GK32587@katherina.student.utwente.nl> <20080722070836.GZ32587@katherina.student.utwente.nl> <901E4288-1B29-4051-990F-CCDDD3C297CC@apple.com> <20080723114339.GL32587@katherina.student.utwente.nl> <64694E0C-804F-4678-838B-D9E4E4582D4A@apple.com> <20080723221044.GQ32587@katherina.student.utwente.nl> Message-ID: On Jul 23, 2008, at 3:10 PM, Matthijs Kooijman wrote: > With plain gcc I assume? Yes. > I was thinking of doing this stripping in the tool generating the > LLVM module, > so opt (or perhaps clang?). It should always be able to just throw > away the > always_inline global and the function should then be just a normal > function. > > I'm not sure if having such a strip-always_inline option is needed, > at least > not if the default is to preserve always_inline information. What I'm worried is - if always_inline info is not stripped away the LTO inliner will obey always_inline. In this case, it is not appropriate to say "LTO may not inline functions, marked as always_inline", across translation unit". > I was proposing > this option, because IIRC someone proposed or implied throwing away > the > always_inline info by default. > > Devang, if I see this right, you agree with me that the combination > of 2) and > b) are the "right" ones? Yes. Otherwise, if we want to restrict enforcing always_inline across translation unit then we need to encode "always_inline in module XYZ" in LLVM IR, not just "always_inline". - Devang From mymlreader at gmail.com Wed Jul 23 22:30:17 2008 From: mymlreader at gmail.com (Zhongxing Xu) Date: Thu, 24 Jul 2008 11:30:17 +0800 Subject: [cfe-dev] Small patch for driver and ccc Message-ID: <4619993f0807232030l5b5c39f7u2382fe548333cf5f@mail.gmail.com> This patch adds paths for Fedora 9 in clang.cpp and support for two preprocessor options in ccc. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080724/e77d40ad/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: patch Type: application/octet-stream Size: 1692 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080724/e77d40ad/attachment-0001.obj From kremenek at apple.com Wed Jul 23 22:50:07 2008 From: kremenek at apple.com (Ted Kremenek) Date: Wed, 23 Jul 2008 20:50:07 -0700 Subject: [cfe-dev] Small patch for driver and ccc In-Reply-To: <4619993f0807232030l5b5c39f7u2382fe548333cf5f@mail.gmail.com> References: <4619993f0807232030l5b5c39f7u2382fe548333cf5f@mail.gmail.com> Message-ID: <824F37A7-01D0-4C27-A776-68B1F890E835@apple.com> Applied! http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20080721/006654.html Thanks! On Jul 23, 2008, at 8:30 PM, Zhongxing Xu wrote: > This patch adds paths for Fedora 9 in clang.cpp and support for two > preprocessor options in ccc. > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From mymlreader at gmail.com Thu Jul 24 00:19:43 2008 From: mymlreader at gmail.com (Zhongxing Xu) Date: Thu, 24 Jul 2008 13:19:43 +0800 Subject: [cfe-dev] wait3() bug Message-ID: <4619993f0807232219x5be16c87m2c42c699910d44d0@mail.gmail.com> When compiling this program: #include #include #include #include void foo(void) { int status; int pid, options; struct rusage ru; pid = wait3(&status, options, &ru); } clang reports: wait3.c:10:15: error: incompatible type passing 'int *', expected '__WAIT_STATUS' pid = wait3(&status, options, &ru); ^~~~~~~ 1 diagnostic generated. But gcc works fine. This is the relevant code after preprocessing: # 1 "/usr/include/bits/waitflags.h" 1 3 4 # 39 "/usr/include/sys/wait.h" 2 3 4 # 63 "/usr/include/sys/wait.h" typedef union { union wait *__uptr; int *__iptr; } __WAIT_STATUS __attribute__ ((__transparent_union__)); extern __pid_t wait3 (__WAIT_STATUS __stat_loc, int __options, struct rusage * __usage) __attribute__ ((__nothrow__)); And in the man page for wait3: SYNOPSIS #include #include #include #include pid_t wait3(int *status, int options, struct rusage *rusage); How should we deal with such case? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080724/4bb17ecf/attachment.html From eli.friedman at gmail.com Thu Jul 24 00:33:50 2008 From: eli.friedman at gmail.com (Eli Friedman) Date: Wed, 23 Jul 2008 22:33:50 -0700 Subject: [cfe-dev] wait3() bug In-Reply-To: <4619993f0807232219x5be16c87m2c42c699910d44d0@mail.gmail.com> References: <4619993f0807232219x5be16c87m2c42c699910d44d0@mail.gmail.com> Message-ID: On Wed, Jul 23, 2008 at 10:19 PM, Zhongxing Xu wrote: > typedef union > { > union wait *__uptr; > int *__iptr; > } __WAIT_STATUS __attribute__ ((__transparent_union__)); > > How should we deal with such case? transparent_union is current unimplemented. -Eli From mymlreader at gmail.com Thu Jul 24 01:30:01 2008 From: mymlreader at gmail.com (Zhongxing Xu) Date: Thu, 24 Jul 2008 14:30:01 +0800 Subject: [cfe-dev] wait3() bug In-Reply-To: References: <4619993f0807232219x5be16c87m2c42c699910d44d0@mail.gmail.com> Message-ID: <4619993f0807232330x17860c74l5529e66a388ac7f4@mail.gmail.com> Thanks. On Thu, Jul 24, 2008 at 1:33 PM, Eli Friedman wrote: > On Wed, Jul 23, 2008 at 10:19 PM, Zhongxing Xu > wrote: > > typedef union > > { > > union wait *__uptr; > > int *__iptr; > > } __WAIT_STATUS __attribute__ ((__transparent_union__)); > > > > How should we deal with such case? > > transparent_union is current unimplemented. > > -Eli > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080724/9bef0996/attachment.html From mymlreader at gmail.com Thu Jul 24 01:31:08 2008 From: mymlreader at gmail.com (Zhongxing Xu) Date: Thu, 24 Jul 2008 14:31:08 +0800 Subject: [cfe-dev] wait3() bug In-Reply-To: <4619993f0807232330x17860c74l5529e66a388ac7f4@mail.gmail.com> References: <4619993f0807232219x5be16c87m2c42c699910d44d0@mail.gmail.com> <4619993f0807232330x17860c74l5529e66a388ac7f4@mail.gmail.com> Message-ID: <4619993f0807232331n7b223686r8ac83241e62fd0ab@mail.gmail.com> I didn't notice the __attribute__ ((__transparent_union__)). On Thu, Jul 24, 2008 at 2:30 PM, Zhongxing Xu wrote: > Thanks. > > > On Thu, Jul 24, 2008 at 1:33 PM, Eli Friedman > wrote: > >> On Wed, Jul 23, 2008 at 10:19 PM, Zhongxing Xu >> wrote: >> > typedef union >> > { >> > union wait *__uptr; >> > int *__iptr; >> > } __WAIT_STATUS __attribute__ ((__transparent_union__)); >> > >> > How should we deal with such case? >> >> transparent_union is current unimplemented. >> >> -Eli >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080724/8f2a7a2f/attachment.html From matthijs at stdin.nl Thu Jul 24 01:42:29 2008 From: matthijs at stdin.nl (Matthijs Kooijman) Date: Thu, 24 Jul 2008 08:42:29 +0200 Subject: [cfe-dev] always_inline and noinline attributes In-Reply-To: References: <20080620121519.GH3816@katherina.student.utwente.nl> <20080718210928.GK32587@katherina.student.utwente.nl> <20080722070836.GZ32587@katherina.student.utwente.nl> <901E4288-1B29-4051-990F-CCDDD3C297CC@apple.com> <20080723114339.GL32587@katherina.student.utwente.nl> <64694E0C-804F-4678-838B-D9E4E4582D4A@apple.com> <20080723221044.GQ32587@katherina.student.utwente.nl> Message-ID: <20080724064229.GB30161@katherina.student.utwente.nl> Hi Devang, > What I'm worried is - if always_inline info is not stripped away the LTO > inliner will obey always_inline. In this case, it is not appropriate to say > "LTO may not inline functions, marked as always_inline", across translation > unit". Ah, I see your point now. It's not easy to guarantee that all LLVM IR producing tools will strip always_inline, because they might not know the next step is linking, for example. Gr. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080724/a3ad1288/attachment.bin From matthijs at stdin.nl Thu Jul 24 01:47:19 2008 From: matthijs at stdin.nl (Matthijs Kooijman) Date: Thu, 24 Jul 2008 08:47:19 +0200 Subject: [cfe-dev] always_inline and noinline attributes In-Reply-To: <20080723114339.GL32587@katherina.student.utwente.nl> References: <20080620121519.GH3816@katherina.student.utwente.nl> <20080718210928.GK32587@katherina.student.utwente.nl> <20080722070836.GZ32587@katherina.student.utwente.nl> <901E4288-1B29-4051-990F-CCDDD3C297CC@apple.com> <20080723114339.GL32587@katherina.student.utwente.nl> Message-ID: <20080724064719.GC30161@katherina.student.utwente.nl> Hi Chris, > I think that Chris is really in favour of option b) here, because "inlining > can sometimes change semantics". However, I still don't really understand what > kind of cases we are talking about. Chris, could you give an example? Also, is > this changing of semantics specific to always_inline? From what you wrote, I > would assume that this changing of semantics can happen with any inline, so > you shouldn't be doing any inlining at all at link time. Nor at optimization > time, for that matter, so I'm probably missing an essential point here :-) I did mean in favour of option a) here, actually :-) Gr. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080724/f6e026e6/attachment.bin From clattner at apple.com Thu Jul 24 01:54:17 2008 From: clattner at apple.com (Chris Lattner) Date: Wed, 23 Jul 2008 23:54:17 -0700 Subject: [cfe-dev] always_inline and noinline attributes In-Reply-To: <20080724064719.GC30161@katherina.student.utwente.nl> References: <20080620121519.GH3816@katherina.student.utwente.nl> <20080718210928.GK32587@katherina.student.utwente.nl> <20080722070836.GZ32587@katherina.student.utwente.nl> <901E4288-1B29-4051-990F-CCDDD3C297CC@apple.com> <20080723114339.GL32587@katherina.student.utwente.nl> <20080724064719.GC30161@katherina.student.utwente.nl> Message-ID: <63B44846-2062-47CD-999F-05FFF0C92A8D@apple.com> On Jul 23, 2008, at 11:47 PM, Matthijs Kooijman wrote: > Hi Chris, > >> I think that Chris is really in favour of option b) here, because >> "inlining >> can sometimes change semantics". However, I still don't really >> understand what >> kind of cases we are talking about. Chris, could you give an >> example? Also, is >> this changing of semantics specific to always_inline? From what you >> wrote, I >> would assume that this changing of semantics can happen with any >> inline, so >> you shouldn't be doing any inlining at all at link time. Nor at >> optimization >> time, for that matter, so I'm probably missing an essential point >> here :-) > I did mean in favour of option a) here, actually :-) I haven't been following the full thread, but Matthijs asked me to opine :). I think there are two equally reasonable approaches: 1) always_inline only affects the "front-end inliner" and gets stripped out by that inliner. This means it would not survive to LTO (if run). This would be extremely compatible with GCC. 2) always_inline persists in the IR and any inliner pass would inline any direct calls to always_inline functions whenever possible. I don't have a strong opinion on which approach is taken, -Chris From mymlreader at gmail.com Thu Jul 24 02:28:03 2008 From: mymlreader at gmail.com (Zhongxing Xu) Date: Thu, 24 Jul 2008 15:28:03 +0800 Subject: [cfe-dev] svn does not compile In-Reply-To: <4619993f0807140523wc8358c4j36f46bc2c1db165@mail.gmail.com> References: <4619993f0807140116h70ea8f1eq242dbffe1747c7dd@mail.gmail.com> <0363FC4F-A93C-413A-892D-CFC127A25E6C@swan.ac.uk> <4619993f0807140523wc8358c4j36f46bc2c1db165@mail.gmail.com> Message-ID: <4619993f0807240028t6b893dcas42f5a6e12fee9ff2@mail.gmail.com> On Mon, Jul 14, 2008 at 8:23 PM, Zhongxing Xu wrote: > If the operator[] overloading in ilist.h is commented, it compiles. Where > is the ilist_iterator::operator[] defined then? > I cannot find it in std::iterator. Let me answer my silly question: If we don't define operator[] as private functions, when operator[] is called on ilist_iterator, ilist_iterator::operator pointer() will be called. So it compiles. :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080724/67de1da1/attachment.html From luismarques at gmail.com Thu Jul 24 10:21:51 2008 From: luismarques at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Marques?=) Date: Thu, 24 Jul 2008 16:21:51 +0100 Subject: [cfe-dev] building clang as a crosscompiler Message-ID: <408520e0807240821j5470529euf1c7f0e85878fd3d@mail.gmail.com> Hi, I'm having some problems building clang as a crosscompiler. What's the status on crosscompilation? Can you, say, build clang on a x86_64 to compile for powerpc? (I got error while building clang) Can you build clang to compile for pic16? I can't get configure to accept the target. Thanks, Lu?s Marques -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080724/47c378a3/attachment.html From cedric.venet at laposte.net Thu Jul 24 11:06:07 2008 From: cedric.venet at laposte.net (=?ISO-8859-1?Q?C=E9dric_Venet?=) Date: Thu, 24 Jul 2008 18:06:07 +0200 Subject: [cfe-dev] building clang as a crosscompiler In-Reply-To: <408520e0807240821j5470529euf1c7f0e85878fd3d@mail.gmail.com> References: <408520e0807240821j5470529euf1c7f0e85878fd3d@mail.gmail.com> Message-ID: <4888A86F.4050501@laposte.net> Lu?s Marques a ?crit : > Hi, > > I'm having some problems building clang as a crosscompiler. > What's the status on crosscompilation? > Can you, say, build clang on a x86_64 to compile for powerpc? (I got > error while building clang) > Can you build clang to compile for pic16? I can't get configure to > accept the target. > > Thanks, > Lu?s Marques > I think you just need to compile clang/llvm for your devel architecture (x86_64) and then you pass the correct architecture (or triple) argument to clang when exectuting. you may need to add your architecture in clang. C?dric From devlists at shadowlab.org Thu Jul 24 11:23:34 2008 From: devlists at shadowlab.org (Jean-Daniel Dupas) Date: Thu, 24 Jul 2008 18:23:34 +0200 Subject: [cfe-dev] building clang as a crosscompiler In-Reply-To: <408520e0807240821j5470529euf1c7f0e85878fd3d@mail.gmail.com> References: <408520e0807240821j5470529euf1c7f0e85878fd3d@mail.gmail.com> Message-ID: <6B05A448-97FD-4E68-8874-22AA57CC9E1C@shadowlab.org> Le 24 juil. 08 ? 17:21, Lu?s Marques a ?crit : > Hi, > > I'm having some problems building clang as a crosscompiler. > What's the status on crosscompilation? > Can you, say, build clang on a x86_64 to compile for powerpc? (I got > error while building clang) > Can you build clang to compile for pic16? I can't get configure to > accept the target. > > Thanks, > Lu?s Marques I don't know about the current status of this function but AFAK this is not a build configuration option. You can build it using a "./configure && make" command and then using it using the arch argument: clang -arch ppc myFile.c clang -arch i386 myFile.c From kremenek at apple.com Fri Jul 25 19:27:06 2008 From: kremenek at apple.com (Ted Kremenek) Date: Fri, 25 Jul 2008 17:27:06 -0700 Subject: [cfe-dev] Possible clang features In-Reply-To: <06403915-F978-40EC-ACBE-C28690DF22F9@gmail.com> References: <06403915-F978-40EC-ACBE-C28690DF22F9@gmail.com> Message-ID: <1C503408-AD84-4980-BBB7-73834856EE2F@apple.com> On Jul 23, 2008, at 6:43 PM, John Engelhart wrote: > Here's a couple of possible ideas. I'm sending them directly to you > so you can either put them on the TODO list or toss them based on > their merits. Hi John, Sorry for the late response. I've CC'ed the cfe-dev list so that others can chime in as well. > > 1) Stores that cause GC qualifications to be dropped. > > This has bitten me so many times. The gist is to catch things that > are roughly like: > > NSString *contextString = @"someContext"; > void *context = contextString; > > Ditto for returning values that drop a GC qualification, like: > > char *someFucntion(void( { > __strong char *buffer = NSAllocationCollectable(4096, NO_SCAN); > ... > return(buffer); > } Adding checks for various GC-related properties and invariants is something that we think static analysis could excel at. Several people have voiced interest in such checks. Since there are a variety of GC-related checks, I believe the best way to start implementing these to is to come up with a list of specific checks to implement and then go from there. To build such a task list of various GC checks to implement, probably the best thing to do is to start filing Bugzilla reports (feature requests) against the static analyzer. That way myself or anyone else interested in implementing a check can go to the list, see a complete specification for the check, and go and implement it. > 2) Peephole optimization recommendations. > > Since you've got a fully parsed program, it should be possible to > match some generic patterns and offer up some optimization advice. > I'm thinking of simple things like: > > for(NSUInteger x = 0; x < [anArray length]; x++) { > > } > > The '[anArray length]' can 'obviously' be hoisted out of the loop, > but the standard compiler can't make that optimization due to the > dynamic nature of method dispatch. Your tool, however, can make the > recommendation that the programmer take a look at it and offer > something like the following advice: > > Possibly rewrite this for() loop as: > > NSUInteger anArrayLength = [anArray length]; > for(NSUInteger x = 0; x < anArrayLength; x++) { > > } > > You could even have different levels of 'optimization > aggressiveness'. Another common trick I use is to replace '[anArray > objectAtIndex:X]' with 'CFArrayGetValueAtIndex(anArray, X)'. Inside > loops, this can often be a pretty big performance win. > > Heh, actually, some of these things would be ideal inside Shark. It > would have easy access to the hotspots, and it could offer this kind > of 'code cruftifying' optimization advice only in hotspot areas. > > I think you get the idea though. There's definitely a couple of > 'low hanging fruit' items that should be trivial to implement. > clang is the perfect place to put them in where they can be > consistently applied and identified. This is a great example of automatic code refactoring combined with static analysis and profiling information. Performing "unsound optimizations" by suggesting changes to the source code is something I'd like to see more of. It's a little risky, but if done right it could yield some huge performance improvements for some programs, especially those written in Objective-C (where as you said the dynamic nature of the language makes it difficult for the compiler to do the optimizations you mentioned). Although we don't have an extensive refactoring library in clang right now, we do have some pieces to support refactoring, including a textual code rewriter that can rewrite fragments of the code in place (preserving comments, macros, etc). Adding more high-level interfaces to support refactoring applications like these would be a great contribution to clang, and my design for the static analysis library in Clang is to use it for a variety of applications (not just finding bugs). This would actually be a really interesting project to work on if you (or others) were interested. > 3) Parsed code export. > > This one is sort of 'pie in the sky' idea based on a need of mine. > I mention it because I'm pretty sure you've got the bulk of the > machinery in place to do all your other checks. > > For one of my projects, RegexKit (the non-Lite version), I ended up > writing a documentation system to go along with it (http://regexkit.sourceforge.net/Documentation/index.html > ). HeaderDoc just didn't cut it for what I needed. It still > follows the header doc /*! @TAG */ style to a large degree, but I > ended up tweaking a few things here and there as the need came up. > I think you can feed RegexKit's headers in to header doc unmodified > and still get something reasonable out the other side. It wouldn't > take much to write some kind of 'scrubber' script so it was 100% > HeaderDoc compatible. > > This wasn't something that was planned out, it just sort of grew > organically as needed. One of the first needs was to be able to > generate a Table Of Contents from all the source headerdoc commented > files. Other stuff got bolted on from there, the end result being > about what you'd expect from one hack slapped on top of another hack. > > The basic idea is to stuff everything in to an SQLite database. > There's a (very messy) perl script that 'parses' header files. > Parses is used only in the loosest possible terms because what it > really is is a bunch of regex pattern matches that match things that > are 'close enough'. The headerdoc comments are easy to find (/\/\*! > (.*?)\*\//), and some of the other bits and pieces are fairly easy > to find, such as method and function prototypes. Since it's really > just a bunch of regex patterns, it can be confused easily and is > sort of fragile in the face of big changes. > > What would be nice is for a real grammar to parse the header and > spit out the parsed structure in some kind of 'easy to use' format. > You could then write a perl script that would scoop up the easy to > use output and do whatever it needed to. > > For example, a method prototype would get decoded in to it's basic > parts (I'm completely making this up as I type this, so don't expect > anything reasonable). > > - (NSArray *)componentsSeparatedByString:(NSString *)separator; > > This is a NSString instance method. To a full blown parser, it's > trivial to separate out the different parts. It returns a type of > 'NSArray *', and the parser knows that NSArray is a class. > 'separator' is an argument that is a 'NSString *' type, and NSString > is a class. > > Basically, some kind of output where all that heavy lifting is done > for you. It's also handy to have back references to where something > was defined, such as a class or typedef. > > In my particular system, this is 'approximately' what happens, > modulo the fact that it uses a couple of heuristics instead of the > actual syntax structure to derive some of its information. The > 'parse' script extracts the information and stuffs it in to an > SQLite database. HTML generation happens only after all the .h > files have been read in. > > HTML generation uses the 'parsed' structure to assist in formatting > things inside the HTML. Because everything is inside a database, > when it comes time to output a 'pretty' method prototype in the > HTML, it can scan the types for types that exist in the database and > automagically place a link around that type that points to the > documentation for that type. Other fancy bits are also possible, > such as pretty the arguments out in italic style. Here's an example > of the HTML: > >
>
name="NSMutableString_RegexKitLiteAdditions__- > replaceOccurrencesOfRegex:withString:options:range:error > :">replaceOccurrencesOfRegex:withString:options:range:error:
>
Replaces all occurrences of the regular > expression regex using class="argument">options within range span> with the contents of replacement > string after performing capture group substitutions, returning the > number of replacements made.
>
- (NSUInteger) class="selector">replaceOccurrencesOfRegex:(NSString *) class="argument">regex class="selector">options:( class="code">RKLRegexOptions)options span> class="selector">withString:(NSString *) class="argument">replacement class="hardNobr">range:(NSRange) class="argument">range class="selector">error:(NSError **) class="argument">error;
> > It's a bit messy raw, but the basics are there. CSS is used > extensively to control the visual aspect. The 'hardNobr' class is > '.hardNobr { white-space: nowrap; }', which forces the rendered > output to not be broken up. In this case, it's used to keep > 'logically similar' elements together during word breaking. It > looks kinda ugly to break on the space in '(NSString *)'. :) > > Anyways, I think you get the idea. By understanding the underlying > syntactical structure, it's much easier to automatically reformat > things in a pleasing documentation friendly way. It also means > someone can declare the method any way they want, with whatever > whitespace/newline formatting they want, and I can still squeeze > things back in to a documentation consistent form. > > I found this to be of particular use for 'enum' and 'struct' like > definitions. As an example, for enums, it becomes trivial to use a > table for the formating. The identifier goes in to one table > column, and the identifier constant goes in to another. This lays > out things in a neatly aligned and visually consistent fashion, not > just a big '
' block and hope for the best.
>
> An unexpected benefit to doing my documentation this way was that  
> when 10.5 came out with DocSet integrated documentation, it was just  
> a matter of writing up a perl script that extracted the information  
> from the database and output it in to a form docset understands.  I  
> literally had working, Xcode integrated docset documentation in  
> under a day.
>
> Again, this is 'pie in the sky' type of stuff.  It's one of those  
> things that you think 'Oh, that's trivially easy!' and you've got  
> some rough code in about 20 minutes, or it's big project.  There's  
> lots of neat things (like this documentation example) that you can  
> do if you have access to an easy to use 'parsed structure' output  
> where all the heavy lifting of parsing the file has been done for you.

Your point about 'parsed code export' I believe touches on a larger  
issue: people want to build a variety of tools that reason about or  
manipulate source code.  This has been hard in C/C++/Objective-C space  
because either the frontend technology is intertwined into the  
implementation of a larger component (e.g., a compiler) or the ASTs  
(or whatever other structured code representation) can not be  
persistently stored and used by other clients.

Clang is designed to obviate both issues.  First, Clang is built as a  
set of libraries.  The lexer, preprocessor, parser, type checking,  
ASTs --- these are all represented as libraries, modules that can be  
easily linked into any tool that wants to use them, be it a command  
line compiler driver, and IDE, or some other tool.  This design is  
intentional, and it follows the same guiding principles as the rest of  
LLVM.  By having a library based design people can use the pieces they  
want to build their own tools.

We are also working on making Clang's internal representation of its  
ASTs persistent.  We have support for pretty-printing and textual  
dumping (some of it is not completely implemented, but it's getting  
there) so that clients can view a dump of some of Clang's internal  
data structures right from the command line.  Other tools that wish to  
use information from Clang but not use its libraries directly can  
potentially use such output.  You can also define that output in any  
way you wish by adding an appropriate ASTConsumer to the clang driver.

We've also built serialization support into Clang to serialize its  
ASTs out to disk.  This isn't 100% there, but it will provide the  
basis for PCH support in Clang, and the static analyzer will also use  
serialized ASTs to perform inter-procedural analysis across files.   
Such persistent ASTs could be inserted into a database, sent across a  
network connection, etc.

Your example of building an automatic documentation generating system  
(e.g., Headerdoc or doxygen) is a great example: I think this would be  
a perfect example of a tool that reuses the Clang libraries for a  
different purpose other than compilation.  The current ASTConsumer  
interface used by the Clang driver would actually be a great place to  
start if you wanted to build such a tool, as clients are essentially  
streamed the AST of a source file and they can do what they like with  
it.  As we bring up more support for persistent ASTs on disk  
(especially for use with inter-procedural analysis), a documentation  
generating tool could use those serialized ASTs to perform accurate  
cross-referencing of function/methods/etc. across files.  This allows  
the documentation system to generate really accurate information about  
type hierarchies, implementations of classes, macro information, you  
name it.

In a similar way, I believe a whole cadre of other tools could be  
built.  We are really excited about Clang because we see it as an  
enabling technology to build great source-level tools for C/C++/ 
Objective-C.

BTW, I like the idea of a Clang-based automatic documentation system  
so much that I added it to our list of possible projects for people to  
do on the Clang website.

- Ted

From kremenek at apple.com  Fri Jul 25 20:18:16 2008
From: kremenek at apple.com (Ted Kremenek)
Date: Fri, 25 Jul 2008 18:18:16 -0700
Subject: [cfe-dev] Possible clang features
In-Reply-To: <06403915-F978-40EC-ACBE-C28690DF22F9@gmail.com>
References: <06403915-F978-40EC-ACBE-C28690DF22F9@gmail.com>
Message-ID: <34DB3884-F55C-4A96-B747-306E5902F67E@apple.com>


On Jul 23, 2008, at 6:43 PM, John Engelhart wrote:

> Here's a couple of possible ideas.  I'm sending them directly to you  
> so you can either put them on the TODO list or toss them based on  
> their merits.

Hi John,

Sorry for the late response.  I've CC'ed the cfe-dev list so that  
others can chime in as well.

>
> 1) Stores that cause GC qualifications to be dropped.
>
> This has bitten me so many times.  The gist is to catch things that  
> are roughly like:
>
> NSString *contextString = @"someContext";
> void *context = contextString;
>
> Ditto for returning values that drop a GC qualification, like:
>
> char *someFucntion(void( {
> __strong char *buffer = NSAllocationCollectable(4096, NO_SCAN);
> ...
> return(buffer);
> }

Adding checks for various GC-related properties and invariants is  
something that we think static analysis could excel at.  Several  
people have voiced interest in such checks.  Since there are a variety  
of GC-related checks, I believe the best way to start implementing  
these to is to come up with a list of specific checks to implement and  
then go from there.

To build such a task list of various GC checks to implement, probably  
the best thing to do is to start filing Bugzilla reports (feature  
requests) against the static analyzer. That way myself or anyone else  
interested in implementing a check can go to the list, see a complete  
specification for the check, and go and implement it.

> 2) Peephole optimization recommendations.
>
> Since you've got a fully parsed program, it should be possible to  
> match some generic patterns and offer up some optimization advice.   
> I'm thinking of simple things like:
>
> for(NSUInteger x = 0; x < [anArray length]; x++) {
>
> }
>
> The '[anArray length]' can 'obviously' be hoisted out of the loop,  
> but the standard compiler can't make that optimization due to the  
> dynamic nature of method dispatch.  Your tool, however, can make the  
> recommendation that the programmer take a look at it and offer  
> something like the following advice:
>
> Possibly rewrite this for() loop as:
>
> NSUInteger anArrayLength = [anArray length];
> for(NSUInteger x = 0; x < anArrayLength; x++) {
>
> }
>
> You could even have different levels of 'optimization  
> aggressiveness'.  Another common trick I use is to replace '[anArray  
> objectAtIndex:X]' with 'CFArrayGetValueAtIndex(anArray, X)'.  Inside  
> loops, this can often be a pretty big performance win.
>
> Heh, actually, some of these things would be ideal inside Shark.  It  
> would have easy access to the hotspots, and it could offer this kind  
> of 'code cruftifying' optimization advice only in hotspot areas.
>
> I think you get the idea though.  There's definitely a couple of  
> 'low hanging fruit' items that should be trivial to implement.   
> clang is the perfect place to put them in where they can be  
> consistently applied and identified.

This is a great example of automatic code refactoring combined with  
static analysis and profiling information.  Performing "unsound  
optimizations" by suggesting changes to the source code is something  
I'd like to see more of.  It's a little risky, but if done right it  
could yield some huge performance improvements for some programs,  
especially those written in Objective-C (where as you said the dynamic  
nature of the language makes it difficult for the compiler to do the  
optimizations you mentioned).

Although we don't have an extensive refactoring library in clang right  
now, we do have some pieces to support refactoring, including a  
textual code rewriter that can rewrite fragments of the code in place  
(preserving comments, macros, etc).  Adding more high-level interfaces  
to support refactoring applications like these would be a great  
contribution to clang, and my design for the static analysis library  
in Clang is to use it for a variety of applications (not just finding  
bugs).

This would actually be a really interesting project to work on if you  
(or others) were interested.

> 3) Parsed code export.
>
> This one is sort of 'pie in the sky' idea based on a need of mine.   
> I mention it because I'm pretty sure you've got the bulk of the  
> machinery in place to do all your other checks.
>
> For one of my projects, RegexKit (the non-Lite version), I ended up  
> writing a documentation system to go along with it (http://regexkit.sourceforge.net/Documentation/index.html 
> ).  HeaderDoc just didn't cut it for what I needed.  It still  
> follows the header doc /*! @TAG */ style to a large degree, but I  
> ended up tweaking a few things here and there as the need came up.   
> I think you can feed RegexKit's headers in to header doc unmodified  
> and still get something reasonable out the other side.  It wouldn't  
> take much to write some kind of 'scrubber' script so it was 100%  
> HeaderDoc compatible.
>
> This wasn't something that was planned out, it just sort of grew  
> organically as needed.  One of the first needs was to be able to  
> generate a Table Of Contents from all the source headerdoc commented  
> files.  Other stuff got bolted on from there, the end result being  
> about what you'd expect from one hack slapped on top of another hack.
>
> The basic idea is to stuff everything in to an SQLite database.   
> There's a (very messy) perl script that 'parses' header files.   
> Parses is used only in the loosest possible terms because what it  
> really is is a bunch of regex pattern matches that match things that  
> are 'close enough'.  The headerdoc comments are easy to find (/\/\*! 
> (.*?)\*\//), and some of the other bits and pieces are fairly easy  
> to find, such as method and function prototypes.  Since it's really  
> just a bunch of regex patterns, it can be confused easily and is  
> sort of fragile in the face of big changes.
>
> What would be nice is for a real grammar to parse the header and  
> spit out the parsed structure in some kind of 'easy to use' format.   
> You could then write a perl script that would scoop up the easy to  
> use output and do whatever it needed to.
>
> For example, a method prototype would get decoded in to it's basic  
> parts (I'm completely making this up as I type this, so don't expect  
> anything reasonable).
>
> - (NSArray *)componentsSeparatedByString:(NSString *)separator;
>
> This is a NSString instance method.  To a full blown parser, it's  
> trivial to separate out the different parts.  It returns a type of  
> 'NSArray *', and the parser knows that NSArray is a class.   
> 'separator' is an argument that is a 'NSString *' type, and NSString  
> is a class.
>
> Basically, some kind of output where all that heavy lifting is done  
> for you.  It's also handy to have back references to where something  
> was defined, such as a class or typedef.
>
> In my particular system, this is 'approximately' what happens,  
> modulo the fact that it uses a couple of heuristics instead of the  
> actual syntax structure to derive some of its information.  The  
> 'parse' script extracts the information and stuffs it in to an  
> SQLite database.  HTML generation happens only after all the .h  
> files have been read in.
>
> HTML generation uses the 'parsed' structure to assist in formatting  
> things inside the HTML.  Because everything is inside a database,  
> when it comes time to output a 'pretty' method prototype in the  
> HTML, it can scan the types for types that exist in the database and  
> automagically place a link around that type that points to the  
> documentation for that type. Other fancy bits are also possible,  
> such as pretty the arguments out in italic style.  Here's an example  
> of the HTML:
>
> 

> 
 name="NSMutableString_RegexKitLiteAdditions__- 
> replaceOccurrencesOfRegex:withString:options:range:error 
> :">replaceOccurrencesOfRegex:withString:options:range:error:

> 
Replaces all occurrences of the regular  
> expression regex using  class="argument">options within range span> with the contents of replacement  
> string after performing capture group substitutions, returning the  
> number of replacements made.

> 
- (NSUInteger) class="selector">replaceOccurrencesOfRegex:(NSString *) class="argument">regex  class="selector">options:( class="code">RKLRegexOptions)options span>  class="selector">withString:(NSString *) class="argument">replacement  class="hardNobr">range:(NSRange) class="argument">range  class="selector">error:(NSError **) class="argument">error;

>
> It's a bit messy raw, but the basics are there.  CSS is used  
> extensively to control the visual aspect.  The 'hardNobr' class is  
> '.hardNobr { white-space: nowrap; }', which forces the rendered  
> output to not be broken up.  In this case, it's used to keep  
> 'logically similar' elements together during word breaking.  It  
> looks kinda ugly to break on the space in '(NSString *)'.  :)
>
> Anyways, I think you get the idea.  By understanding the underlying  
> syntactical structure, it's much easier to automatically reformat  
> things in a pleasing documentation friendly way.  It also means  
> someone can declare the method any way they want, with whatever  
> whitespace/newline formatting they want, and I can still squeeze  
> things back in to a documentation consistent form.
>
> I found this to be of particular use for 'enum' and 'struct' like  
> definitions.  As an example, for enums, it becomes trivial to use a  
> table for the formating.  The identifier goes in to one table  
> column, and the identifier constant goes in to another.  This lays  
> out things in a neatly aligned and visually consistent fashion, not  
> just a big '
' block and hope for the best.
>
> An unexpected benefit to doing my documentation this way was that  
> when 10.5 came out with DocSet integrated documentation, it was just  
> a matter of writing up a perl script that extracted the information  
> from the database and output it in to a form docset understands.  I  
> literally had working, Xcode integrated docset documentation in  
> under a day.
>
> Again, this is 'pie in the sky' type of stuff.  It's one of those  
> things that you think 'Oh, that's trivially easy!' and you've got  
> some rough code in about 20 minutes, or it's big project.  There's  
> lots of neat things (like this documentation example) that you can  
> do if you have access to an easy to use 'parsed structure' output  
> where all the heavy lifting of parsing the file has been done for you.

Your point about 'parsed code export' I believe touches on a larger  
issue: people want to build a variety of tools that reason about or  
manipulate source code.  This has been hard in C/C++/Objective-C space  
because either the frontend technology is intertwined into the  
implementation of a larger component (e.g., a compiler) or the ASTs  
(or whatever other structured code representation) can not be  
persistently stored and used by other clients.

Clang is designed to obviate both issues.  First, Clang is built as a  
set of libraries.  The lexer, preprocessor, parser, type checking,  
ASTs --- these are all represented as libraries, modules that can be  
easily linked into any tool that wants to use them, be it a command  
line compiler driver, and IDE, or some other tool.  This design is  
intentional, and it follows the same guiding principles as the rest of  
LLVM.  By having a library based design people can use the pieces they  
want to build their own tools.

We are also working on making Clang's internal representation of its  
ASTs persistent.  We have support for pretty-printing and textual  
dumping (some of it is not completely implemented, but it's getting  
there) so that clients can view a dump of some of Clang's internal  
data structures right from the command line.  Other tools that wish to  
use information from Clang but not use its libraries directly can  
potentially use such output.  You can also define that output in any  
way you wish by adding an appropriate ASTConsumer to the clang driver.

We've also built serialization support into Clang to serialize its  
ASTs out to disk.  This isn't 100% there, but it will provide the  
basis for PCH support in Clang, and the static analyzer will also use  
serialized ASTs to perform inter-procedural analysis across files.   
Such persistent ASTs could be inserted into a database, sent across a  
network connection, etc.

Your example of building an automatic documentation generating system  
(e.g., Headerdoc or doxygen) is a great example: I think this would be  
a perfect example of a tool that reuses the Clang libraries for a  
different purpose other than compilation.  The current ASTConsumer  
interface used by the Clang driver would actually be a great place to  
start if you wanted to build such a tool, as clients are essentially  
streamed the AST of a source file and they can do what they like with  
it.  As we bring up more support for persistent ASTs on disk  
(especially for use with inter-procedural analysis), a documentation  
generating tool could use those serialized ASTs to perform accurate  
cross-referencing of function/methods/etc. across files.  This allows  
the documentation system to generate really accurate information about  
type hierarchies, implementations of classes, macro information, you  
name it.

In a similar way, I believe a whole cadre of other tools could be  
built.  We are really excited about Clang because we see it as an  
enabling technology to build great source-level tools for C/C++/ 
Objective-C.

BTW, I like the idea of a Clang-based automatic documentation system  
so much that I added it to our list of possible projects for people to  
do on the Clang website.

- Ted

From kremenek at apple.com  Fri Jul 25 20:28:09 2008
From: kremenek at apple.com (Ted Kremenek)
Date: Fri, 25 Jul 2008 18:28:09 -0700
Subject: [cfe-dev] Even more clang ideas
In-Reply-To: <532EF192-7C2C-4943-8803-BA307ECB55F2@gmail.com>
References: <532EF192-7C2C-4943-8803-BA307ECB55F2@gmail.com>
Message-ID: <14E54F7E-D405-4556-AEDC-4432DFCF1B6F@apple.com>


On Jul 23, 2008, at 8:36 PM, John Engelhart wrote:

> Geeze, after I sent my message I came up with a few more...
>
> Here's the -W warnings I usually (try) to run with:
>
> -Wmissing-prototypes -Wreturn-type -Wformat -Wunused-parameter - 
> Wunused-variable -Wunused-value -Wuninitialized -Wshadow -Wsign- 
> compare -Wshorten-64-to-32 -Wextra -Winit-self -Wsequence-point - 
> Wswitch-default -Wstrict-aliasing=2 -Wundef -Wpointer-arith -Wbad- 
> function-cast -Wstrict-prototypes -Wmissing-declarations -Wredundant- 
> decls -Wunreachable-code -Wcast-align -Wdiscard-qual -Wcast-qual - 
> Wstrict-overflow=5
>
> "32 <-> 64 bit issues / potential problems".
>
> The warning flag '-Wshorten-64-to-32' is a good start. '- 
> Wconversion' is also useful when switching to 64 bits.  clang can  
> leverage 'meta-information' against the problem too, like using the  
> knowledge that NS*Integer can switch sizes between 32 and 64 bits,  
> but a 32 bit in assigned/passed to a NSInteger won't scale the same  
> way.  clang can help catch this potential gotchas early before they  
> become difficult to undo/fix problems is these types of things can  
> go silently undetected and default compiler warning levels. '-Wcast- 
> align' is also something that can be checked/validated.

64 -> 32 bit issues is definitely a good source of checks, especially  
for code that must run for different archs.  Your example about  
NSInteger is especially a good one.

I actually recently implemented a simple check relating to this topic  
relating to the use of CFNumberCreate.  If one isn't careful with the  
use of this function, on a 64-bit architecture CFNumberCreate can  
actually fail to initialize some of the bits of the freshly created  
CFNumber because the integer size is greater than the integer provided  
by the programmer.  I think a lot of little simple checks like these  
would be both (a) relatively easy to implement and (b) potentially  
catch a lot of subtle bugs.

The design of the static analysis library is to help make the  
implementation of these checks relatively straightforward without any  
deep program analysis knowledge.  I myself won't be able to implement  
all of these checks, and hopefully as the tool evolves others will  
feel comfortable in implementing some of these checks as well.

> "Cross architecture issues"
>
> I can't think of any off the top of my head, but collecting possible  
> cross architecture issues patterns would be helpful.

I think this basically relates to the previous issue: APIs and type  
definitions can have different invariants or properties on different  
archs.  Some of these invariants could be checked readily with static  
analysis.

> "Possible restrict and const qualification recommendations (and  
> validation)"
>
> This really requires deep inter-procedure analysis, but if it's  
> available, then clang might be able to reason certain things about  
> the inter-procedure effects and possibilities.  Const can sometimes  
> lead to better code generation, but the real wins are usually  
> possible with restrict.  If deep inspection is possible, then some  
> degree of validation of the use of a restrict qualified pointer is  
> probably possible as well.

I don't have a reference off the top of my head, but I do know there  
was some research on doing example what you suggest.  Accurately  
inferring const and restrict may require a fairly precise points-to  
analysis, which gets tricky with all the messiness of C.  That said,  
this is something that could potentially be done, at least in some  
localized cases.

> Actually, since you're obviously deep down in the guts of the  
> grammar and compiler interactions, maybe you can offer an opinion on  
> the following:  Historically Objective-C was effectively nothing  
> more than a fancy pre-processor front end the C compiler.  In fact,  
> there was often a trivial one to one mapping from an Objective-C  
> statement to a plain C statement.
>
> @interface MyClass : ParentClass { char *buffer; } @end
> becomes something like
> typedef struct { /* ParentClass definitions */ char *buffer; }  
> MyClass;
>
> When you get right down to it, there's nothing special about a  
> 'class', it's literally nothing more than struct.
>
> Now, object oriented programming is built on polymorphic abilities,  
> each class inherits all of its super classes methods/ivars/etc.  So  
> if we have the following:
>
> @interface MyClass : ParentClass { char *buffer; } @end
> @interface MyMutableClass : MyClass { int mutationCount; } @end
>
> In code, we refer to an instantion of one of these objects with:
>
> MyClass *myClassObj;
> MyMutableClass *myMutableClassObj;
>
> OO programing (and objc) allows for the following to take place:
>
> myClassObj = myMutableClassObj;
>
> because MyMutableClass is a subclass of MyClass.  No problem, right?
>
> I'm of the opinion that this is actually a problem.  The problem has  
> nothing to do with the (correct) OO design paradigm or any  
> particular conceptual fault, but it has to do with C.
>
> Objective-C was designed a long time ago, in the pre-ANSI K&R days  
> as a matter of fact. Such assignments were possible under older K&R  
> and (I think, but may be wrong) ANSI rules.  It was frowned upon,  
> wasn't terribly good style, but you could do it and for most  
> architectures this isn't a problem because the compiler essentially  
> treated all pointers as equivalents.  Of course, the compiler is  
> free to perform pointer alignment due to the assignment, but this  
> never happened in practice (at least not for any of the main  
> architectures that are still with us today).
>
> The @interface definitions is literally like the following statements:
>
> typedef struct { char *buffer; } MyClass;
> typedef struct { char *buffer; int mutationCount; } MyMutableClass;
>
> Or, if we really wanted to, we could drop the typedef and use  
> declare it as any other struct.  Pointers to 'instantiated objects'  
> in code are either identical to their Objective-C counterparts if  
> typedefs are used, or something like the following if structs are  
> used:
>
> struct MyClass *myClassObj;
> struct MyMutableClass *myMutableClassObj;
>
> Fast forward to C99 and consider the same statement:
>
> myClassObj = myMutableClassObj;
>
> In C99, this statement is expressly forbidden as 'pointers of one  
> type may not point to a different type (except void)'.  Only  
> pointers of the same type may alias each other.  This is the 'strict  
> aliasing' rule(s).
>
> So... there's a bit of a conflict.  Such pointer aliasing is  
> permitted under the concepts of object oriented programming, but it  
> is expressly forbidden under C99 rules.  From a purely compiler  
> perspective, when you prototype a method as
>
> - (NSArray *)someMethod;
>
> you literally mean that you are returning a type of NSArray *, and  
> not any of its subclasses.

I'm not certain that the C99 rules apply in this way to Objective-C  
types, since the Objective-C type system is completely outside the  
scope of C99.  The fact that Objective-C was originally implemented as  
a layer above C just means the compiler had less information to go  
on.  One can easily get around the problem you mentioned by having the  
C implementation of Objective-C just use void* for all Objective-C  
object references (or, as you point out later, simple disable strict  
aliasing rules for Objective-C code).

>  It is, in fact, an error to return a NSMutableArray in a method  
> that's prototyped to return an NSArray due to C pointer aliasing  
> rules. The 'id' type is the closest thing that Objective-C has to a  
> 'generic object pointer type', so if a method wants to return a  
> pointer to an object of more than one type, it really should declare  
> the return type as 'id'.  Again, this is due to the C pointer  
> aliasing rules rather than any OO conceptual rules.

Again, I'm not certain how much C99's aliasing rules apply to  
Objective-C object references.  Objective-C doesn't have a formal  
specification akin to C99, so the specification (if you want to call  
it that) is whatever the current compiler implementation allows.

There are others on this list that can comment on this particular  
issue with much more authority than myself.

> It really starts to become a problem when you turn on the optimizer  
> and it begins to do optimizations that are dependent on this  
> aliasing invariant.  When I realized that this could actually be a  
> serious, very subtle problem, and started digging I found evidence  
> to support it.  For example, '-fstrict-aliasing' is disabled on  
> Apples GCC for ObjC code.

Interesting.  I think this illustrates my point that the strict  
aliasing rules in C99 don't really apply to Objective-C, at least in  
the implementation provided by GCC.  This is clearly a deliberate  
choice, likely to avoid the issues you mentioned.

>  Using '-fast' on .m files causes the compiler to emit 'cc1obj:  
> warning: command line option "-fast" is valid for C/C++ but not for  
> ObjC'
>
> I'm of the opinion that Objective-C and C are so closely linked  
> together that one can not simply say 'Pointers can not aliasing to  
> different types.  Except for ObjC class type pointer, they can alias  
> to any of their subclasses.'

It gets even more interesting when one considers categories, which  
allow one to implement essentially "open types" in Objective-C.  The  
highly dynamic nature of Objective-C allows one to change the methods  
implemented by a class at runtime, which can essentially change the  
subtyping relationships between objects at runtime.  In that sense,  
the class hierarchy is only a set of guidelines for subtyping  
relationships between Objective-C objects.  From that observation, I'm  
not certain that any conservative strict aliasing assumptions could be  
made by the compiler concerning Objective-C objects.

>  It just not possible from a practical stand point, ESPECIALLY in  
> something like GCC where it's pragmatically impossible to separate  
> out the two languages.

I'm not an expert on the GCC IR where the optimizer does much of its  
work, but the GCC frontend has a notion of the Objective-C type  
system, and uses that information to issue warnings in some cases.   
For example:

#include 

void foo() {
   NSString* s;
   NSObject* o;

   o = s;
   s = o;
}

gcc emits warning for the assignment of 'o' to 's' because the object  
referred to by 'o' may not be a subclass of NSString:

/tmp/t.m:8: warning: assignment from distinct Objective-C type

If one could use the Objective-C class hierarchy information to make  
conservative assumptions for use with strict aliasing optimizations,  
I'm not certain why you think gcc couldn't use that information.  The  
point I made above, however, means that even having the class  
hierarchy information available may not be enough make such assumptions.

- Ted

From clattner at apple.com  Sat Jul 26 00:09:36 2008
From: clattner at apple.com (Chris Lattner)
Date: Fri, 25 Jul 2008 22:09:36 -0700
Subject: [cfe-dev] Even more clang ideas
In-Reply-To: <14E54F7E-D405-4556-AEDC-4432DFCF1B6F@apple.com>
References: <532EF192-7C2C-4943-8803-BA307ECB55F2@gmail.com>
	<14E54F7E-D405-4556-AEDC-4432DFCF1B6F@apple.com>
Message-ID: 


On Jul 25, 2008, at 6:28 PM, Ted Kremenek wrote:

>>
>> It really starts to become a problem when you turn on the optimizer
>> and it begins to do optimizations that are dependent on this
>> aliasing invariant.  When I realized that this could actually be a
>> serious, very subtle problem, and started digging I found evidence
>> to support it.  For example, '-fstrict-aliasing' is disabled on
>> Apples GCC for ObjC code.
>
> Interesting.  I think this illustrates my point that the strict
> aliasing rules in C99 don't really apply to Objective-C, at least in
> the implementation provided by GCC.  This is clearly a deliberate
> choice, likely to avoid the issues you mentioned.

-fstrict-aliasing being off by default has more to do with its  
implementation in GCC than it does the objc type system.  I don't  
think that any of the things John is talking about affect -fstrict- 
aliasing.

When llvm-gcc (and eventually clang) supports type based alias  
analysis, it will almost certainly be on by default, even on the mac.

>> Using '-fast' on .m files causes the compiler to emit 'cc1obj:
>> warning: command line option "-fast" is valid for C/C++ but not for
>> ObjC'

-fast is basically the "optimize for SPEC" flag.  There are no objc  
programs in spec.

-Chris 

From cmh at me.com  Sat Jul 26 02:02:40 2008
From: cmh at me.com (Chris Hanson)
Date: Sat, 26 Jul 2008 00:02:40 -0700
Subject: [cfe-dev] Even more clang ideas
In-Reply-To: <14E54F7E-D405-4556-AEDC-4432DFCF1B6F@apple.com>
References: <532EF192-7C2C-4943-8803-BA307ECB55F2@gmail.com>
	<14E54F7E-D405-4556-AEDC-4432DFCF1B6F@apple.com>
Message-ID: <0F72A56F-2091-496E-9007-9F05D61E25AE@me.com>

On Jul 25, 2008, at 6:28 PM, Ted Kremenek wrote:

>> It is, in fact, an error to return a NSMutableArray in a method
>> that's prototyped to return an NSArray due to C pointer aliasing
>> rules. The 'id' type is the closest thing that Objective-C has to a
>> 'generic object pointer type', so if a method wants to return a
>> pointer to an object of more than one type, it really should declare
>> the return type as 'id'.  Again, this is due to the C pointer
>> aliasing rules rather than any OO conceptual rules.
>
> Again, I'm not certain how much C99's aliasing rules apply to
> Objective-C object references.  Objective-C doesn't have a formal
> specification akin to C99, so the specification (if you want to call
> it that) is whatever the current compiler implementation allows.

The current specification of Objective-C is "The Objective-C 2.0  
Programming Language" at .

John is also incorrect about the above:  It is *not* an error, in  
Objective-C, to return an instance of a subclass from a method  
prototyped as returning an instance of the superclass.

Objective-C is its own language that extends C99, not a preprocessor  
for C99, and this is one of the extensions that Objective-C adds.  In  
fact, in Objective-C it is not possible to say "this method returns an  
instance of specifically this class and no other class" -- you can  
only say "this method returns an instance of this class or any  
subclass."

That is by design, and is not just an artifact of its original  
mid-1980s implementation as a preprocessor.

   -- Chris


From kenferry at gmail.com  Sat Jul 26 03:17:33 2008
From: kenferry at gmail.com (Ken Ferry)
Date: Sat, 26 Jul 2008 01:17:33 -0700
Subject: [cfe-dev] Even more clang ideas
In-Reply-To: <0F72A56F-2091-496E-9007-9F05D61E25AE@me.com>
References: <532EF192-7C2C-4943-8803-BA307ECB55F2@gmail.com>
	<14E54F7E-D405-4556-AEDC-4432DFCF1B6F@apple.com>
	<0F72A56F-2091-496E-9007-9F05D61E25AE@me.com>
Message-ID: <8f5c05b70807260117k1e1b16a7scfc10b48535dae28@mail.gmail.com>

On Sat, Jul 26, 2008 at 12:02 AM, Chris Hanson  wrote:
> On Jul 25, 2008, at 6:28 PM, Ted Kremenek wrote:
>
>>> It is, in fact, an error to return a NSMutableArray in a method
>>> that's prototyped to return an NSArray due to C pointer aliasing
>>> rules. The 'id' type is the closest thing that Objective-C has to a
>>> 'generic object pointer type', so if a method wants to return a
>>> pointer to an object of more than one type, it really should declare
>>> the return type as 'id'.
>
> John is also incorrect about the above:  It is *not* an error, in
> Objective-C, to return an instance of a subclass from a method
> prototyped as returning an instance of the superclass.

John may be thinking of the fact that most init methods and such
return id, for example -[NSArray initWithObjects:].  This isn't
because it would be incorrect to return (NSArray *), it's because
subclassers would have to redeclare every init method, or else the
compiler would issue a warning for lines such as

NSMutableArray *mutableArray = [[NSMutableArray alloc]
initWithObjects:obj1, obj2, nil];

Actually, since the +alloc method returns id (for the same reason),
the compiler cannot even tell that -[NSMutableArray initWithObjects:]
should be preferred over -[NSArray initWithObjects:] here.

It'd be nice if Objective-C had return types that meant "instance of
receiver" and "instance of receiver's class".

-Ken

From krj at rajaratnam.dk  Sat Jul 26 05:16:19 2008
From: krj at rajaratnam.dk (Kovarththanan Rajaratnam)
Date: Sat, 26 Jul 2008 12:16:19 +0200
Subject: [cfe-dev] [PATCH] Add support for dependency files
Message-ID: 

Hello,

This patch is a first stab at implementing rudimentary support for 
generation of dependency files (-MD and -MMD). This is implemented by 
using the preprocessor callback functionality.

Feedback appreciated. Thanks.

-- 
Best Regards
Kovarththanan Rajaratnam
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dep_file.patch
Type: text/x-patch
Size: 9971 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080726/655e109b/attachment-0002.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: enhance_path.patch
Type: text/x-patch
Size: 1517 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080726/655e109b/attachment-0003.bin 

From kremenek at apple.com  Sat Jul 26 12:21:31 2008
From: kremenek at apple.com (Ted Kremenek)
Date: Sat, 26 Jul 2008 10:21:31 -0700
Subject: [cfe-dev] Even more clang ideas
In-Reply-To: <0F72A56F-2091-496E-9007-9F05D61E25AE@me.com>
References: <532EF192-7C2C-4943-8803-BA307ECB55F2@gmail.com>
	<14E54F7E-D405-4556-AEDC-4432DFCF1B6F@apple.com>
	<0F72A56F-2091-496E-9007-9F05D61E25AE@me.com>
Message-ID: 


On Jul 26, 2008, at 12:02 AM, Chris Hanson wrote:

> On Jul 25, 2008, at 6:28 PM, Ted Kremenek wrote:
>
>>> It is, in fact, an error to return a NSMutableArray in a method
>>> that's prototyped to return an NSArray due to C pointer aliasing
>>> rules. The 'id' type is the closest thing that Objective-C has to a
>>> 'generic object pointer type', so if a method wants to return a
>>> pointer to an object of more than one type, it really should declare
>>> the return type as 'id'.  Again, this is due to the C pointer
>>> aliasing rules rather than any OO conceptual rules.
>>
>> Again, I'm not certain how much C99's aliasing rules apply to
>> Objective-C object references.  Objective-C doesn't have a formal
>> specification akin to C99, so the specification (if you want to call
>> it that) is whatever the current compiler implementation allows.
>
> The current specification of Objective-C is "The Objective-C 2.0  
> Programming Language" at  >.

Thanks Chris!  What I meant by a "formal" specification is something  
with the detail to write a compiler and runtime with.  The document  
you reference (while excellent) doesn't provide that kind of detail.   
In our implementation of Objective-C support in Clang, we are really  
leaning on the knowledge of specific people who either had an hand in  
conceiving the language or implemented its support in gcc.

> John is also incorrect about the above:  It is *not* an error, in  
> Objective-C, to return an instance of a subclass from a method  
> prototyped as returning an instance of the superclass.

I don't think I addressed that point directly, and I'm glad you did  
so.  This idea follows from standard type theory for functions: the  
return type is allowed to be a covariant type.

> Objective-C is its own language that extends C99, not a preprocessor  
> for C99, and this is one of the extensions that Objective-C adds.

Exactly.

>  In fact, in Objective-C it is not possible to say "this method  
> returns an instance of specifically this class and no other class"  
> -- you can only say "this method returns an instance of this class  
> or any subclass."


Excellent point.  I don't think most standard OO languages allow you  
to express the first statement either.  (others please chime in on  
this one if you know better!)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080726/93062f29/attachment.html 

From kremenek at apple.com  Sat Jul 26 12:31:07 2008
From: kremenek at apple.com (Ted Kremenek)
Date: Sat, 26 Jul 2008 10:31:07 -0700
Subject: [cfe-dev] Even more clang ideas
In-Reply-To: <8f5c05b70807260117k1e1b16a7scfc10b48535dae28@mail.gmail.com>
References: <532EF192-7C2C-4943-8803-BA307ECB55F2@gmail.com>
	<14E54F7E-D405-4556-AEDC-4432DFCF1B6F@apple.com>
	<0F72A56F-2091-496E-9007-9F05D61E25AE@me.com>
	<8f5c05b70807260117k1e1b16a7scfc10b48535dae28@mail.gmail.com>
Message-ID: <01587397-B190-4F72-A0A9-82552B5B3B98@apple.com>


On Jul 26, 2008, at 1:17 AM, Ken Ferry wrote:

> On Sat, Jul 26, 2008 at 12:02 AM, Chris Hanson  wrote:
>> On Jul 25, 2008, at 6:28 PM, Ted Kremenek wrote:
>>
>>>> It is, in fact, an error to return a NSMutableArray in a method
>>>> that's prototyped to return an NSArray due to C pointer aliasing
>>>> rules. The 'id' type is the closest thing that Objective-C has to a
>>>> 'generic object pointer type', so if a method wants to return a
>>>> pointer to an object of more than one type, it really should  
>>>> declare
>>>> the return type as 'id'.
>>
>> John is also incorrect about the above:  It is *not* an error, in
>> Objective-C, to return an instance of a subclass from a method
>> prototyped as returning an instance of the superclass.
>
> John may be thinking of the fact that most init methods and such
> return id, for example -[NSArray initWithObjects:].  This isn't
> because it would be incorrect to return (NSArray *), it's because
> subclassers would have to redeclare every init method, or else the
> compiler would issue a warning for lines such as
>
> NSMutableArray *mutableArray = [[NSMutableArray alloc]
> initWithObjects:obj1, obj2, nil];

This limitation also exists in Java with its own collection classes  
(collections use type erasure).  Lists, Maps, etc., all contain  
objects that subclass Object (the root of the Object hierarchy).   
Clients must use downcasts when retrieving objects from collections.   
Generics in Java helps reduce the typing for this, but its just  
syntactic sugar (the compiler inserts the downcast checks):

http://java.sun.com/j2se/1.5.0/docs/guide/language/generics.html

> Actually, since the +alloc method returns id (for the same reason),
> the compiler cannot even tell that -[NSMutableArray initWithObjects:]
> should be preferred over -[NSArray initWithObjects:] here.
>
> It'd be nice if Objective-C had return types that meant "instance of
> receiver" and "instance of receiver's class".

I agree that this kind of polymorphism would be nice to have in  
Objective-C.  In many cases this kind of polymorphism can be  
implemented in C++ using templates.





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080726/70aa9c33/attachment.html 

From kremenek at apple.com  Sat Jul 26 12:34:53 2008
From: kremenek at apple.com (Ted Kremenek)
Date: Sat, 26 Jul 2008 10:34:53 -0700
Subject: [cfe-dev] Even more clang ideas
In-Reply-To: 
References: <532EF192-7C2C-4943-8803-BA307ECB55F2@gmail.com>
	<14E54F7E-D405-4556-AEDC-4432DFCF1B6F@apple.com>
	
Message-ID: <9BF6519A-F071-4EC2-BCAD-E6B10199D86D@apple.com>


On Jul 25, 2008, at 10:09 PM, Chris Lattner wrote:

>>
>> Interesting.  I think this illustrates my point that the strict
>> aliasing rules in C99 don't really apply to Objective-C, at least in
>> the implementation provided by GCC.  This is clearly a deliberate
>> choice, likely to avoid the issues you mentioned.
>
> -fstrict-aliasing being off by default has more to do with its  
> implementation in GCC than it does the objc type system.  I don't  
> think that any of the things John is talking about affect -fstrict- 
> aliasing.
>
> When llvm-gcc (and eventually clang) supports type based alias  
> analysis, it will almost certainly be on by default, even on the mac.


Cool.  In that case, will strict-aliasing support for Objective-C take  
into consideration the subtyping relationships in Objective-C?  The  
original point with regards to strict-aliasing really concerns whether  
or not C99 strict-aliasing rules apply verbatim to pointers to  
Objective-C objects.

From clattner at apple.com  Sat Jul 26 13:41:04 2008
From: clattner at apple.com (Chris Lattner)
Date: Sat, 26 Jul 2008 11:41:04 -0700
Subject: [cfe-dev] Even more clang ideas
In-Reply-To: <9BF6519A-F071-4EC2-BCAD-E6B10199D86D@apple.com>
References: <532EF192-7C2C-4943-8803-BA307ECB55F2@gmail.com>
	<14E54F7E-D405-4556-AEDC-4432DFCF1B6F@apple.com>
	
	<9BF6519A-F071-4EC2-BCAD-E6B10199D86D@apple.com>
Message-ID: <8F305467-9E6B-4769-85FE-8E65ECAFD8EA@apple.com>


On Jul 26, 2008, at 10:34 AM, Ted Kremenek wrote:

>
> On Jul 25, 2008, at 10:09 PM, Chris Lattner wrote:
>
>>>
>>> Interesting.  I think this illustrates my point that the strict
>>> aliasing rules in C99 don't really apply to Objective-C, at least in
>>> the implementation provided by GCC.  This is clearly a deliberate
>>> choice, likely to avoid the issues you mentioned.
>>
>> -fstrict-aliasing being off by default has more to do with its  
>> implementation in GCC than it does the objc type system.  I don't  
>> think that any of the things John is talking about affect -fstrict- 
>> aliasing.
>>
>> When llvm-gcc (and eventually clang) supports type based alias  
>> analysis, it will almost certainly be on by default, even on the mac.
>
>
> Cool.  In that case, will strict-aliasing support for Objective-C  
> take into consideration the subtyping relationships in Objective-C?

Almost certainly not.  I'm not an objc expert, but my understanding is  
that people often define proxy objects that don't necessarily derive  
from the specified base class.  The ObjC type system is mostly a  
"recommendation" not a "requirement" afaik.

-Chris

From tonic at nondot.org  Sat Jul 26 17:32:03 2008
From: tonic at nondot.org (Tanya Lattner)
Date: Sat, 26 Jul 2008 15:32:03 -0700
Subject: [cfe-dev] LLVM Developers' Meeting Agenda
Message-ID: <3A06EDA5-29D5-48B4-BF15-6BA02328C470@nondot.org>

Hello!

I've updated the LLVM Developers' Meeting webpage with this years  
agenda. You may view it here:
http://llvm.org/devmtg/#agenda

We plan to video tape each presentation, so we will update the website  
after the meeting with the slides and video tape.

For those attending the meeting, please check in at the front desk at  
the Infinite Loop 4 building and receive your name badge. The  
conference is held on the second floor and there will be signs to  
direct you. Parking is freely available in the lots in front of the  
building.

Lastly, the dinner held after the meeting is for attendees who opted  
for dinner when registering. I've added this information to the  
website so you can see your status (http://llvm.org/devmtg/ 
#attendees). We have given counts to the caterer, so we can not  
accommodate anyone else at this time.

We look forward to seeing you soon.

Thanks,
Tanya Lattner & Ted Kremenek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20080726/fd918a5e/attachment-0001.html 

From daniel at zuster.org  Sat Jul 26 18:52:02 2008
From: daniel at zuster.org (Daniel Dunbar)
Date: Sat, 26 Jul 2008 16:52:02 -0700 (PDT)
Subject: [cfe-dev] Doxygen
Message-ID: <704666.82899.qm@web54602.mail.re2.yahoo.com>

Configuration files for doxygen have been committed into clang/docs
and Chris has wired it up to http://clang.llvm.org/doxygen/

There are some errors with the use of doxygen directives if anyone
feels like running 'make doxygen' in the docs directory and cleaning
up the output.

 - Daniel

From dpatel at apple.com  Mon Jul 28 10:12:02 2008
From: dpatel at apple.com (Devang Patel)
Date: Mon, 28 Jul 2008 08:12:02 -0700
Subject: [cfe-dev] Even more clang ideas
In-Reply-To: <14E54F7E-D405-4556-AEDC-4432DFCF1B6F@apple.com>
References: <532EF192-7C2C-4943-8803-BA307ECB55F2@gmail.com>
	<14E54F7E-D405-4556-AEDC-4432DFCF1B6F@apple.com>
Message-ID: <52627875-05D7-45A9-9BF3-8DCD7031239C@apple.com>

>> It really starts to become a problem when you turn on the optimizer
>> and it begins to do optimizations that are dependent on this
>> aliasing invariant.  When I realized that this could actually be a
>> serious, very subtle problem, and started digging I found evidence
>> to support it.  For example, '-fstrict-aliasing' is disabled on
>> Apples GCC for ObjC code.

-fstrict-aliasing is disabled by default for all languages, not just  
ObjC, in Apple GCC.

-
Devang



From rkumar8 at cs.uiuc.edu  Tue Jul 29 10:11:55 2008
From: rkumar8 at cs.uiuc.edu (Rajesh Karmani)
Date: Tue, 29 Jul 2008 11:11:55 -0400
Subject: [cfe-dev] Parsing objective-c message expressions
Message-ID: <488F333B.2090203@cs.uiuc.edu>

Hi,
I have just started looking at Clang and found it to be a great tool.
I also came across the RewriteObjc module and wanted to play around with 
how the Objective-C messages are "rewritten".

I have not been able to figure out how an assignment statement like:

c = [obj execute];

is parsed in Clang (what functions are called?). I would like to rewrite 
such statements differently from

[obj execute];

where nothing is being returned. Could someone please guide me which 
parts of code should I be looking at?


regards,
rajesh


From kremenek at apple.com  Tue Jul 29 11:34:11 2008
From: kremenek at apple.com (Ted Kremenek)
Date: Tue, 29 Jul 2008 09:34:11 -0700
Subject: [cfe-dev] Parsing objective-c message expressions
In-Reply-To: <488F333B.2090203@cs.uiuc.edu>
References: <488F333B.2090203@cs.uiuc.edu>
Message-ID: <0621FB8D-421D-4501-8A46-29D65B7E00F5@apple.com>

On Jul 29, 2008, at 8:11 AM, Rajesh Karmani wrote:

> Hi,
> I have just started looking at Clang and found it to be a great tool.
> I also came across the RewriteObjc module and wanted to play around  
> with
> how the Objective-C messages are "rewritten".
>
> I have not been able to figure out how an assignment statement like:
>
> c = [obj execute];
>
> is parsed in Clang (what functions are called?). I would like to  
> rewrite
> such statements differently from
>
> [obj execute];
>
> where nothing is being returned. Could someone please guide me which
> parts of code should I be looking at?

Hi Rajesh,

In general, an excellent way to figure out the structure of the ASTs  
is to use the --ast-dump option:

   clang --ast-dump myfile.m

For example:

void f(NSObject *m) {
   NSObject* c = [m execute];
}

becomes:

void f(NSObject *m)
(CompoundStmt 0x2372060 <:3:21, line:5:1>
   (DeclStmt 0x2371ff0 
     0x2371fa0 "NSObject *c =
       (ImplicitCastExpr 0x236c030  'NSObject *'
         (ObjCMessageExpr 0x2372010  'id':'struct  
objc_object *' selector=execute
           (DeclRefExpr 0x2371fd0  'NSObject *' ParmVar='m'  
0x23712b0)))")

Note that assignments and variable declarations are different.   
Assignments are represented using BinaryOperator, while variable  
declarations are represented using DeclStmt.

Ted

From snaroff at apple.com  Tue Jul 29 11:53:31 2008
From: snaroff at apple.com (steve naroff)
Date: Tue, 29 Jul 2008 09:53:31 -0700
Subject: [cfe-dev] Parsing objective-c message expressions
In-Reply-To: <488F333B.2090203@cs.uiuc.edu>
References: <488F333B.2090203@cs.uiuc.edu>
Message-ID: <4C120956-F213-4B6B-8730-15DDE430FC1D@apple.com>


On Jul 29, 2008, at 8:11 AM, Rajesh Karmani wrote:

> Hi,
> I have just started looking at Clang and found it to be a great tool.
> I also came across the RewriteObjc module and wanted to play around  
> with
> how the Objective-C messages are "rewritten".
>
> I have not been able to figure out how an assignment statement like:
>
> c = [obj execute];
>
> is parsed in Clang (what functions are called?). I would like to  
> rewrite
> such statements differently from
>
> [obj execute];
>
> where nothing is being returned. Could someone please guide me which
> parts of code should I be looking at?
>
>

Here is a brief example...

snaroffBook$ cat xx.m
#import 

void f(NSObject *m) {
   NSObject* c = [m execute];
}

snaroffBook$ ../../Debug/bin/clang -rewrite-objc xx.m

#include 

void f(NSObject *m) {
   NSObject* c = ((id (*)(id, SEL, ...))(void *)objc_msgSend)((id)m,  
sel_registerName("execute"));
}

The actual rewriter code is in RewriteObjC.cpp.

snaroff

> regards,
> rajesh
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


From krj at rajaratnam.dk  Thu Jul 31 10:27:36 2008
From: krj at rajaratnam.dk (Kovarththanan Rajaratnam)
Date: Thu, 31 Jul 2008 17:27:36 +0200
Subject: [cfe-dev] [PATCH] Add support for dependency files
In-Reply-To: 
References: 
Message-ID: 

Hello,

Kovarththanan Rajaratnam wrote:
> Hello,
> 
> This patch is a first stab at implementing rudimentary support for 
> generation of dependency files (-MD and -MMD). This is implemented by 
> using the preprocessor callback functionality.
> 
> Feedback appreciated. Thanks.

I've raised a bug to make sure that this patch isn't forgotten:

http://llvm.org/bugs/show_bug.cgi?id=2618

-- 
Best Regards
Kovarththanan Rajaratnam


From clattner at apple.com  Thu Jul 31 12:22:23 2008
From: clattner at apple.com (Chris Lattner)
Date: Thu, 31 Jul 2008 10:22:23 -0700
Subject: [cfe-dev] [PATCH] Add support for dependency files
In-Reply-To: 
References:  
Message-ID: <40E6632D-550F-42F5-863F-D78D529B74BF@apple.com>


On Jul 31, 2008, at 8:27 AM, Kovarththanan Rajaratnam wrote:

> Hello,
>
> Kovarththanan Rajaratnam wrote:
>> Hello,
>>
>> This patch is a first stab at implementing rudimentary support for
>> generation of dependency files (-MD and -MMD). This is implemented by
>> using the preprocessor callback functionality.
>>
>> Feedback appreciated. Thanks.
>
> I've raised a bug to make sure that this patch isn't forgotten:
>
> http://llvm.org/bugs/show_bug.cgi?id=2618

Hi Kovarththanan,

I'm really sorry for the delay.  This is on my todo list, but I'm  
scrambling to keep up with the developer meeting looming.  I'll take a  
look at it this weekend if not sooner.   I apologize again for the  
delay, thanks for working on this!

-Chris

From nicolasweber at gmx.de  Thu Jul 31 17:44:08 2008
From: nicolasweber at gmx.de (Nico Weber)
Date: Fri, 1 Aug 2008 00:44:08 +0200
Subject: [cfe-dev] Parent of an AST node?
Message-ID: <4B3FE349-C76F-4343-8E2A-CE78B4E06479@gmx.de>

Hi,

how can I get the parent of an AST node?

I have a DeclRefExpr object and would like the name of the function  
it's contained in. Does clang offer this functionality or do I have to  
keep track of parents myself?

Thanks,
Nico

From snaroff at apple.com  Thu Jul 31 18:10:57 2008
From: snaroff at apple.com (steve naroff)
Date: Thu, 31 Jul 2008 16:10:57 -0700
Subject: [cfe-dev] Parent of an AST node?
In-Reply-To: <4B3FE349-C76F-4343-8E2A-CE78B4E06479@gmx.de>
References: <4B3FE349-C76F-4343-8E2A-CE78B4E06479@gmx.de>
Message-ID: <479A3275-D195-4C20-90E7-132DF90AC7EE@apple.com>


On Jul 31, 2008, at 3:44 PM, Nico Weber wrote:

> Hi,
>
> how can I get the parent of an AST node?
>
> I have a DeclRefExpr object and would like the name of the function
> it's contained in. Does clang offer this functionality or do I have to
> keep track of parents myself?
>

You need to keep track of it yourself...

snaroff

> Thanks,
> Nico
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


From kremenek at apple.com  Thu Jul 31 18:25:00 2008
From: kremenek at apple.com (Ted Kremenek)
Date: Thu, 31 Jul 2008 16:25:00 -0700
Subject: [cfe-dev] Parent of an AST node?
In-Reply-To: <4B3FE349-C76F-4343-8E2A-CE78B4E06479@gmx.de>
References: <4B3FE349-C76F-4343-8E2A-CE78B4E06479@gmx.de>
Message-ID: <79391D4E-2CCB-486E-8E4B-1A7197CB8D8D@apple.com>

Hi Nico,

Check out the ParentMap class in libAST.  It represents a map from  
Stmt* -> Stmt* (children to parents).  To construct it, you just  
provide the root of the AST:

   ParentMap PM(root);

To query for a parent:

   Stmt* parent = PM.getParent(child);

The parent map will only contain the backmapping from children to  
parents that are descendants of the root AST node that you specified  
when you constructed the parent map.

Ted

On Jul 31, 2008, at 3:44 PM, Nico Weber wrote:

> Hi,
>
> how can I get the parent of an AST node?
>
> I have a DeclRefExpr object and would like the name of the function
> it's contained in. Does clang offer this functionality or do I have to
> keep track of parents myself?
>
> Thanks,
> Nico
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev