From andrew.n.sutton at gmail.com Thu Jan 1 10:20:10 2009 From: andrew.n.sutton at gmail.com (Andrew Sutton) Date: Thu, 1 Jan 2009 11:20:10 -0500 Subject: [cfe-dev] Templates (again) In-Reply-To: <4BAFF16A-0DC5-4AE0-A9C7-32FFB3EE1DEB@apple.com> References: <97E885DF-D61C-4B9A-B537-5537FCF2BCF8@apple.com> <1E53323E-54ED-403A-B86A-EBC224699C26@apple.com> <3BB786B9-A035-4D7F-8292-4D33E8882976@apple.com> <4BAFF16A-0DC5-4AE0-A9C7-32FFB3EE1DEB@apple.com> Message-ID: > Is the TemplateDecl getting returned all the way through to > ParseExternalDeclaration? That's how declarations get back to the > Knowing that helps a *lot*. Here's iteration n + 1. This starts to add -ast-print support for class templates, but it doesn't print template parameters just yet. You'll get "template <...> Read top-level tag...". Getting this to work is... not very pretty. It's actually pretty tough to push the TemplateDecl all the way up to ParseExternalDeclaration since, somewhere in the call sequence, the created declaration node is wrapped in a DeclSpec (in ParseDeclarationOrFunctionDefinition IIRC) and ActOnTag only returns a TagDecl. I modified ActOnTag to return *either* a TagDecl or a TemplateDecl. This has the unfortunate side-effect of requiring you to think about DeclTy's in the Action interface as either a Tag or Template. It's easy to get the Tag from the Template, but unfortuntely you still have to perform the cast (so far only in 3 places). This also means that I'm setting the TypeRep of a DeclSpec as a TemplateDecl, which may or may not have unseen consequences down the road. It's a big patch, but I tried to make it as unintrusive as possible. Best of all, it doesn't cause any regressions on my system. Andrew Sutton andrew.n.sutton at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090101/8b478e91/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: templates.patch Type: text/x-diff Size: 61457 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090101/8b478e91/attachment-0001.bin From cristian.draghici at gmail.com Fri Jan 2 04:18:02 2009 From: cristian.draghici at gmail.com (Cristian Draghici) Date: Fri, 2 Jan 2009 12:18:02 +0200 Subject: [cfe-dev] Why does scan-build disable check for uninit values? Message-ID: <25cf7a9f0901020218q4b9aafaaq5078a068cf2e4b79@mail.gmail.com> Hi I've noticed that scan-build in the latest version of the checker (137) disables the check for uninit values (-warn-uninit-values). Is there a reason behind that? Thank you, Cristi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090102/504d00a7/attachment.html From edwintorok at gmail.com Fri Jan 2 09:28:43 2009 From: edwintorok at gmail.com (=?UTF-8?B?VMO2csO2ayBFZHdpbg==?=) Date: Fri, 02 Jan 2009 17:28:43 +0200 Subject: [cfe-dev] On sizeof char, bytes, and bits in the C99 standard Message-ID: <495E32AB.4040603@gmail.com> Hi, I always considered sizeof(char) = one byte = 8 bits. However reading the C99 standard (N1256.pdf), and especially the C99 rationale (C99RationalV5.10.pdf) I see that the intent is to allow for platforms where one byte != 8 bits. For example: "(Thus, for instance, on a machine with 36-bit words, a byte can be defined to consist or 36 bits, these numbers being all the exact divisors of 36 which are not less than 8.)" So I read several sections of the C99 standard and the rationale, and if you combine the standard with the rationale you get the only way to satisfy all the rules, is to have one byte = 8 bits. So why all this careful, generic formulations to avoid defining one byte == 8 bits, when in fact you can't have an implementation where one byte != 8 bits that conforms to the standard/rationale. Section 3.7.1 says "character single-byte character ?C? bit representation that ?ts in a byte", which is further strengthened by C99RationaleV5.10: " A char whether signed or unsigned, occupies exactly one byte.". Thus no doubt one character = one byte. Section 3.6 defines byte: "NOTE 2 A byte is composed of a contiguous sequence of bits, the number of which is implementation-de?ned. The least signi?cant bit is called the low-order bit; the most signi?cant bit is called the high-order bit." Section 7.18.1.1 defines int8_t: "Thus, int8_t denotes a signed integer type with a width of exactly 8 bits." This quote from C99Rationale V.5.10 " Thus, for instance, on a machine with 36-bit words, a byte can be defined to consist of 9, 12, 18, or 36 bits, these numbers being all the exact divisors of 36 which are not less than 8.)" shows that the intent was to allow for a definition of byte that doesn't necessarily have 8 bits. However according this quote " These strictures codify the widespread presumption that any object can be treated as an array of characters, the size of which is given by the sizeof operator with that object?s type as its operand." I should be able to treat any objects (thus including int8_t type objects) as array of characters. This implies that there exists an N such that: number_of_bits(char)*N = number_of_bits(int8_t). Given what we know about char and int8_t this means: there exists an N such that number_of_bits(byte)*N = 8, which implies number_of_bits(byte) <= 8. Now according to C99Rationale V5.10: " All objects in C must be representable as a contiguous sequence of bytes, each of which is at least 8 bits wide.", number_of_bits(byte) >= 8. Thus number_of_bits(byte) = 8. Am I right, or am I wrong? Best regards, --Edwin From sebastian.redl at getdesigned.at Fri Jan 2 09:50:59 2009 From: sebastian.redl at getdesigned.at (Sebastian Redl) Date: Fri, 02 Jan 2009 16:50:59 +0100 Subject: [cfe-dev] On sizeof char, bytes, and bits in the C99 standard In-Reply-To: <495E32AB.4040603@gmail.com> References: <495E32AB.4040603@gmail.com> Message-ID: <495E37E3.1090305@getdesigned.at> T?r?k Edwin wrote: > Section 7.18.1.1 defines int8_t: "Thus, int8_t denotes a signed integer > type with a width of exactly 8 bits." > > This quote from C99Rationale V.5.10 " Thus, for instance, on a machine > with 36-bit words, a byte can be defined to consist of 9, 12, 18, or 36 > bits, these numbers being all the exact divisors of 36 which are not > less than 8.)" shows that the intent was to allow for a definition of > byte that doesn't necessarily have 8 bits. > > However according this quote " These strictures codify the widespread > presumption that any object can be treated as an array of characters, > the size of which is given by the sizeof operator with that object?s > type as its > operand." I should be able to treat any objects (thus including int8_t > type objects) as array of characters. > This implies that there exists an N such that: number_of_bits(char)*N = > number_of_bits(int8_t). Given what we know about char and int8_t this means: > there exists an N such that number_of_bits(byte)*N = 8, which implies > number_of_bits(byte) <= 8. > > Now according to C99Rationale V5.10: " All objects in C must be > representable as a contiguous sequence of bytes, each of which is at > least 8 bits wide.", > number_of_bits(byte) >= 8. > > Thus number_of_bits(byte) = 8. > > Am I right, or am I wrong? > You're wrong. 7.8.1.1p3 says that the exact forms are optional. An implementation where CHAR_BITS is > 8 cannot provide (u)int8_t, but is nevertheless conforming. Sebastian From edwintorok at gmail.com Fri Jan 2 10:47:05 2009 From: edwintorok at gmail.com (=?UTF-8?B?VMO2csO2ayBFZHdpbg==?=) Date: Fri, 02 Jan 2009 18:47:05 +0200 Subject: [cfe-dev] On sizeof char, bytes, and bits in the C99 standard In-Reply-To: <495E37E3.1090305@getdesigned.at> References: <495E32AB.4040603@gmail.com> <495E37E3.1090305@getdesigned.at> Message-ID: <495E4509.3010806@gmail.com> On 2009-01-02 17:50, Sebastian Redl wrote: > T?r?k Edwin wrote: > >> Section 7.18.1.1 defines int8_t: "Thus, int8_t denotes a signed integer >> type with a width of exactly 8 bits." >> >> This quote from C99Rationale V.5.10 " Thus, for instance, on a machine >> with 36-bit words, a byte can be defined to consist of 9, 12, 18, or 36 >> bits, these numbers being all the exact divisors of 36 which are not >> less than 8.)" shows that the intent was to allow for a definition of >> byte that doesn't necessarily have 8 bits. >> >> However according this quote " These strictures codify the widespread >> presumption that any object can be treated as an array of characters, >> the size of which is given by the sizeof operator with that object?s >> type as its >> operand." I should be able to treat any objects (thus including int8_t >> type objects) as array of characters. >> This implies that there exists an N such that: number_of_bits(char)*N = >> number_of_bits(int8_t). Given what we know about char and int8_t this means: >> there exists an N such that number_of_bits(byte)*N = 8, which implies >> number_of_bits(byte) <= 8. >> >> Now according to C99Rationale V5.10: " All objects in C must be >> representable as a contiguous sequence of bytes, each of which is at >> least 8 bits wide.", >> number_of_bits(byte) >= 8. >> >> Thus number_of_bits(byte) = 8. >> >> Am I right, or am I wrong? >> >> > > You're wrong. 7.8.1.1p3 says that the exact forms are optional. An > implementation where CHAR_BITS is > 8 cannot provide (u)int8_t, but is > nevertheless conforming. Ok, so I may assume that on any POSIX compliant platform CHAR_BITS is 8? (POSIX requires (u)int8_t: http://www.opengroup.org/onlinepubs/000095399/basedefs/stdint.h.html) Best regards, --Edwin From sebastian.redl at getdesigned.at Fri Jan 2 10:57:25 2009 From: sebastian.redl at getdesigned.at (Sebastian Redl) Date: Fri, 02 Jan 2009 17:57:25 +0100 Subject: [cfe-dev] On sizeof char, bytes, and bits in the C99 standard In-Reply-To: <495E4509.3010806@gmail.com> References: <495E32AB.4040603@gmail.com> <495E37E3.1090305@getdesigned.at> <495E4509.3010806@gmail.com> Message-ID: <495E4775.1020801@getdesigned.at> T?r?k Edwin wrote: > On 2009-01-02 17:50, Sebastian Redl wrote: > >> You're wrong. 7.8.1.1p3 says that the exact forms are optional. An >> implementation where CHAR_BITS is > 8 cannot provide (u)int8_t, but is >> nevertheless conforming. >> > > Ok, so I may assume that on any POSIX compliant platform CHAR_BITS is 8? > (POSIX requires (u)int8_t: > http://www.opengroup.org/onlinepubs/000095399/basedefs/stdint.h.html) > That's a valid interpretation. Another is that it's an oversight. :-) I don't know. Sebastian From zaimoni at zaimoni.com Fri Jan 2 11:00:18 2009 From: zaimoni at zaimoni.com (Kenneth Boyd) Date: Fri, 02 Jan 2009 11:00:18 -0600 Subject: [cfe-dev] On sizeof char, bytes, and bits in the C99 standard In-Reply-To: <495E32AB.4040603@gmail.com> References: <495E32AB.4040603@gmail.com> Message-ID: <495E4822.3000604@zaimoni.com> T?r?k Edwin wrote: > Hi, > > I always considered sizeof(char) = one byte = 8 bits. > However reading the C99 standard (N1256.pdf), and especially the C99 > rationale (C99RationalV5.10.pdf) I see that the intent is to allow > for platforms where one byte != 8 bits. > > For example: > "(Thus, for instance, on a machine with 36-bit words, a byte can be > defined to consist or 36 bits, these numbers being all the exact > divisors of 36 which are not less than 8.)" > These machines are not hypothetical, although the standard does require, of the historical conventions, the Multics convention (4 9-bit logical chars packed into a 36-byte physical char). > .... > Section 3.6 defines byte: "NOTE 2 A byte is composed of a contiguous > sequence of bits, the number of which is implementation-de?ned. The > least signi?cant bit is called the low-order bit; the most signi?cant > bit is called the high-order bit." > > Section 7.18.1.1 defines int8_t: "Thus, int8_t denotes a signed integer > type with a width of exactly 8 bits." > Right -- when the typedef exists at all. > This quote from C99Rationale V.5.10 " Thus, for instance, on a machine > with 36-bit words, a byte can be defined to consist of 9, 12, 18, or 36 > bits, these numbers being all the exact divisors of 36 which are not > less than 8.)" shows that the intent was to allow for a definition of > byte that doesn't necessarily have 8 bits. > > However according this quote " These strictures codify the widespread > presumption that any object can be treated as an array of characters, > the size of which is given by the sizeof operator with that object?s > type as its > operand." I should be able to treat any objects (thus including int8_t > type objects) as array of characters. > Yes, but int8_t is only guaranteed to exist on CHAR_BIT 8 machines that use two's complement integers. Neither int8_t nor uint8_t are allowed to exist on machines where CHAR_BIT!=8, due to the no padding bits requirement and a rote calculation that the practical minimum possibly compliant CHAR_BIT is 7. In particular, C99 7.18.1.1p3: "These types are optional. However, if an implementation provides integer types with widths of 8, 16, 32, or 64 bits, no padding bits, and (for the signed types) that have a two?s complement representation, it shall define the corresponding typedef names." [uint8_t, uint16_t, uint32_t, int64_t, int8_t, int16_t, int32_t, int64_t]" On a machine with CHAR_BIT 9, a conforming implementation can, but need not, provide uint9_t (but I would expect it to as a quality of implementation issue). Kenneth Boyd From makslane at hotmail.com Fri Jan 2 11:18:35 2009 From: makslane at hotmail.com (=?utf-8?Q?Makslane_Ara=C3=BAjo_Rodrigues?=) Date: Fri, 2 Jan 2009 20:18:35 +0300 Subject: [cfe-dev] On sizeof char, bytes, and bits in the C99 standard In-Reply-To: <495E32AB.4040603@gmail.com> References: <495E32AB.4040603@gmail.com> Message-ID: I like this definition of Byte from the Wikipedia: "A contiguous sequence of bits within a binary computer that comprises the smallest addressable sub-field of the computer's natural word-size." Makslane > Date: Fri, 2 Jan 2009 17:28:43 +0200 > From: edwintorok at gmail.com > To: cfe-dev at cs.uiuc.edu > Subject: [cfe-dev] On sizeof char, bytes, and bits in the C99 standard > > Hi, > > I always considered sizeof(char) = one byte = 8 bits. > However reading the C99 standard (N1256.pdf), and especially the C99 > rationale (C99RationalV5.10.pdf) I see that the intent is to allow > for platforms where one byte != 8 bits. > > For example: > "(Thus, for instance, on a machine with 36-bit words, a byte can be > defined to consist or 36 bits, these numbers being all the exact > divisors of 36 which are not less than 8.)" > > So I read several sections of the C99 standard and the rationale, and if > you combine the standard with the rationale you get the only way to > satisfy all the rules, > is to have one byte = 8 bits. So why all this careful, generic > formulations to avoid defining one byte == 8 bits, when in fact you > can't have an implementation > where one byte != 8 bits that conforms to the standard/rationale. > > Section 3.7.1 says "character single-byte character ?C? bit > representation that ?ts in a byte", which is further strengthened by > C99RationaleV5.10: " A char whether signed or unsigned, occupies exactly > one byte.". > Thus no doubt one character = one byte. > > Section 3.6 defines byte: "NOTE 2 A byte is composed of a contiguous > sequence of bits, the number of which is implementation-de?ned. The > least signi?cant bit is called the low-order bit; the most signi?cant > bit is called the high-order bit." > > Section 7.18.1.1 defines int8_t: "Thus, int8_t denotes a signed integer > type with a width of exactly 8 bits." > > This quote from C99Rationale V.5.10 " Thus, for instance, on a machine > with 36-bit words, a byte can be defined to consist of 9, 12, 18, or 36 > bits, these numbers being all the exact divisors of 36 which are not > less than 8.)" shows that the intent was to allow for a definition of > byte that doesn't necessarily have 8 bits. > > However according this quote " These strictures codify the widespread > presumption that any object can be treated as an array of characters, > the size of which is given by the sizeof operator with that object?s > type as its > operand." I should be able to treat any objects (thus including int8_t > type objects) as array of characters. > This implies that there exists an N such that: number_of_bits(char)*N = > number_of_bits(int8_t). Given what we know about char and int8_t this means: > there exists an N such that number_of_bits(byte)*N = 8, which implies > number_of_bits(byte) <= 8. > > Now according to C99Rationale V5.10: " All objects in C must be > representable as a contiguous sequence of bytes, each of which is at > least 8 bits wide.", > number_of_bits(byte) >= 8. > > Thus number_of_bits(byte) = 8. > > Am I right, or am I wrong? > > Best regards, > --Edwin > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev _________________________________________________________________ Instale a Barra de Ferramentas com Desktop Search e ganhe EMOTICONS para o Messenger! ? GR?TIS! http://www.msn.com.br/emoticonpack -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090102/10895397/attachment-0001.html From sebastian.redl at getdesigned.at Fri Jan 2 11:57:05 2009 From: sebastian.redl at getdesigned.at (Sebastian Redl) Date: Fri, 02 Jan 2009 18:57:05 +0100 Subject: [cfe-dev] Review Request: Plain Old Data (POD) property of classes, and type traits basics Message-ID: <495E5571.6060107@getdesigned.at> Hi, I've implemented the POD property of classes, and (in order to test it) a basic infrastructure for GCC's type traits extensions, plus a concrete implementation of the __is_pod trait. However, I'm not quite sure about all aspects of the patch, so I'm posting it for review first. In particular, I have an enum called UnaryTypeTrait that represents the various type trait keywords. Since it is needed in the parser, the sema and the AST, I saw no other choice but to make it part of Basic. Is this the right thing to do? Patch is attached. Sebastian -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pod.patch Url: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090102/78068e5c/attachment-0001.pl From clattner at apple.com Fri Jan 2 13:27:25 2009 From: clattner at apple.com (Chris Lattner) Date: Fri, 2 Jan 2009 11:27:25 -0800 Subject: [cfe-dev] On sizeof char, bytes, and bits in the C99 standard In-Reply-To: <495E4509.3010806@gmail.com> References: <495E32AB.4040603@gmail.com> <495E37E3.1090305@getdesigned.at> <495E4509.3010806@gmail.com> Message-ID: <7158ABB4-33B9-4C54-A623-3D71CFA7361F@apple.com> On Jan 2, 2009, at 8:47 AM, T?r?k Edwin wrote: > Ok, so I may assume that on any POSIX compliant platform CHAR_BITS > is 8? > (POSIX requires (u)int8_t: > http://www.opengroup.org/onlinepubs/000095399/basedefs/stdint.h.html) I think that it is safe to say that Clang should only care about 8-bit bytes until someone comes along with a machine that has a non-8-bit byte and is willing to do the work to enhance it... -Chris From me22.ca at gmail.com Fri Jan 2 13:34:30 2009 From: me22.ca at gmail.com (me22) Date: Fri, 2 Jan 2009 14:34:30 -0500 Subject: [cfe-dev] On sizeof char, bytes, and bits in the C99 standard In-Reply-To: <495E4509.3010806@gmail.com> References: <495E32AB.4040603@gmail.com> <495E37E3.1090305@getdesigned.at> <495E4509.3010806@gmail.com> Message-ID: On Fri, Jan 2, 2009 at 11:47, T?r?k Edwin wrote: > > Ok, so I may assume that on any POSIX compliant platform CHAR_BITS is 8? > (POSIX requires (u)int8_t: > http://www.opengroup.org/onlinepubs/000095399/basedefs/stdint.h.html) > I recall reading that rather than require complicated semantics for files, sockets, and such that would allow CHAR_BIT > 8, POSIX decided just to require CHAR_BIT == 8 and be done with it. (Though all the RFC Internet Standards are specified in terms of "octets", not "bytes".) From kremenek at apple.com Fri Jan 2 15:43:44 2009 From: kremenek at apple.com (Ted Kremenek) Date: Fri, 2 Jan 2009 13:43:44 -0800 Subject: [cfe-dev] Why does scan-build disable check for uninit values? In-Reply-To: <25cf7a9f0901020218q4b9aafaaq5078a068cf2e4b79@mail.gmail.com> References: <25cf7a9f0901020218q4b9aafaaq5078a068cf2e4b79@mail.gmail.com> Message-ID: On Jan 2, 2009, at 2:18 AM, Cristian Draghici wrote: > Hi > > I've noticed that scan-build in the latest version of the checker > (137) disables the check for uninit values (-warn-uninit-values). > Is there a reason behind that? > > > Thank you, > Cristi In the static analyzer, checking for uninitialized values, just as with checking for null dereferences, is done as part of the core path- sensitive logic used for -checker-cfref and -checker-simple. It isn't controlled by -warn-uninit-values. The -warn-uninit-values option performs a fast check for uses of uninitialized values that is similar to GCC's -Wuninitialized. It should be thought of as a cheap check that can be used (one day) as a compiler warning rather than a deep check done by the static analyzer. The checking for uninitialized values done by the static analyzer is far more precise. Some of these options should probably be renamed to avoid such confusion. From mrs at apple.com Fri Jan 2 18:23:00 2009 From: mrs at apple.com (Mike Stump) Date: Fri, 2 Jan 2009 16:23:00 -0800 Subject: [cfe-dev] new warnings n -r61596 Message-ID: <0629F060-D72F-460D-9946-B283B8364735@apple.com> DeclCXX.cpp: In member function 'clang::Decl** clang::LinkageSpecDecl::decls_begin() const': DeclCXX.cpp:326: warning: dereferencing type-punned pointer will break strict-aliasing rules DeclCXX.cpp: In member function 'clang::Decl** clang::LinkageSpecDecl::decls_end() const': DeclCXX.cpp:331: warning: dereferencing type-punned pointer will break strict-aliasing rules From cristian.draghici at gmail.com Sat Jan 3 03:09:25 2009 From: cristian.draghici at gmail.com (Cristian Draghici) Date: Sat, 3 Jan 2009 11:09:25 +0200 Subject: [cfe-dev] Why does scan-build disable check for uninit values? In-Reply-To: References: <25cf7a9f0901020218q4b9aafaaq5078a068cf2e4b79@mail.gmail.com> Message-ID: <25cf7a9f0901030109p3daf8aa0o386febb9dcc50387@mail.gmail.com> On Fri, Jan 2, 2009 at 11:43 PM, Ted Kremenek wrote: > > On Jan 2, 2009, at 2:18 AM, Cristian Draghici wrote: > > Hi >> >> I've noticed that scan-build in the latest version of the checker (137) >> disables the check for uninit values (-warn-uninit-values). >> Is there a reason behind that? >> >> >> Thank you, >> Cristi >> > > In the static analyzer, checking for uninitialized values, just as with > checking for null dereferences, is done as part of the core path-sensitive > logic used for -checker-cfref and -checker-simple. It isn't controlled by > -warn-uninit-values. > > The -warn-uninit-values option performs a fast check for uses of > uninitialized values that is similar to GCC's -Wuninitialized. It should be > thought of as a cheap check that can be used (one day) as a compiler warning > rather than a deep check done by the static analyzer. The checking for > uninitialized values done by the static analyzer is far more precise. > > Some of these options should probably be renamed to avoid such confusion. My confusion was actually caused by the different output of "-checker-cfref" vs "-warn-uninit-values". In the warning below shouldn't clang say "Pass-by-value argument in function is uninitialized"? English is not my native language so I may be wrong but I tend to equate "undefined" with "undeclared" (as in lacking definition). diciu$ ~/Downloads/checker-137/clang -x c test.c -checker-cfref ANALYZE: test.c main test.c:6:2: warning: Pass-by-value argument in function is undefined. strcpy(t, g); ^ ~ 1 diagnostic generated. diciu$ ~/Downloads/checker-137/clang -x c test.c -warn-uninit-values test.c:6:9: warning: use of uninitialized variable strcpy(t, g); ^ test.c:6:12: warning: use of uninitialized variable strcpy(t, g); ^ 2 diagnostics generated. test.c is: #include int main() { char * t, * g; strcpy(t, g); return 0; } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090103/065aeeb6/attachment.html From cristian.draghici at gmail.com Sat Jan 3 03:43:18 2009 From: cristian.draghici at gmail.com (Cristian Draghici) Date: Sat, 3 Jan 2009 11:43:18 +0200 Subject: [cfe-dev] Why does scan-build disable check for uninit values? In-Reply-To: <25cf7a9f0901030109p3daf8aa0o386febb9dcc50387@mail.gmail.com> References: <25cf7a9f0901020218q4b9aafaaq5078a068cf2e4b79@mail.gmail.com> <25cf7a9f0901030109p3daf8aa0o386febb9dcc50387@mail.gmail.com> Message-ID: <25cf7a9f0901030143k76fa8cbfr425ac67f59554a22@mail.gmail.com> On Sat, Jan 3, 2009 at 11:09 AM, Cristian Draghici < cristian.draghici at gmail.com> wrote: > > > On Fri, Jan 2, 2009 at 11:43 PM, Ted Kremenek wrote: > >> >> On Jan 2, 2009, at 2:18 AM, Cristian Draghici wrote: >> >> Hi >>> >>> I've noticed that scan-build in the latest version of the checker (137) >>> disables the check for uninit values (-warn-uninit-values). >>> Is there a reason behind that? >>> >>> >>> Thank you, >>> Cristi >>> >> >> In the static analyzer, checking for uninitialized values, just as with >> checking for null dereferences, is done as part of the core path-sensitive >> logic used for -checker-cfref and -checker-simple. It isn't controlled by >> -warn-uninit-values. >> >> The -warn-uninit-values option performs a fast check for uses of >> uninitialized values that is similar to GCC's -Wuninitialized. It should be >> thought of as a cheap check that can be used (one day) as a compiler warning >> rather than a deep check done by the static analyzer. The checking for >> uninitialized values done by the static analyzer is far more precise. >> >> Some of these options should probably be renamed to avoid such confusion. > > > My confusion was actually caused by the different output of > "-checker-cfref" vs "-warn-uninit-values". > > In the warning below shouldn't clang say "Pass-by-value argument in > function is uninitialized"? > English is not my native language so I may be wrong but I tend to equate > "undefined" with "undeclared" (as in lacking definition). > > diciu$ ~/Downloads/checker-137/clang -x c test.c -checker-cfref > ANALYZE: test.c main > test.c:6:2: warning: Pass-by-value argument in function is undefined. > strcpy(t, g); > ^ ~ > 1 diagnostic generated. > > > diciu$ ~/Downloads/checker-137/clang -x c test.c -warn-uninit-values > test.c:6:9: warning: use of uninitialized variable > strcpy(t, g); > ^ > test.c:6:12: warning: use of uninitialized variable > strcpy(t, g); > ^ > 2 diagnostics generated. > > test.c is: > #include > > int main() > { > char * t, * g; > strcpy(t, g); > > return 0; > } > > > > Oh, nevermind, I get it. "Pass-by-value argument in function is undefined" probably refers to the value pointed to by the char pointer as being undefined, which it is. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090103/f8b18c3f/attachment-0001.html From EdB at sigluy.net Sat Jan 3 09:28:29 2009 From: EdB at sigluy.net (EdB) Date: Sat, 3 Jan 2009 16:28:29 +0100 Subject: [cfe-dev] [Patch] Diagnose unused declaration Message-ID: <200901031628.35933.EdB@sigluy.net> Hello Please find attached a patch in order to diagnose unused declaration. This sould solve http://llvm.org/bugs/show_bug.cgi?id=2739 As I'm new to clang, I'm not sure if I did it the right way. Comments are welcome. -------------- next part -------------- A non-text attachment was scrubbed... Name: unused.patch Type: text/x-diff Size: 6291 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090103/afd0e4b2/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090103/afd0e4b2/attachment-0001.bin From sebastian.redl at getdesigned.at Sat Jan 3 09:50:02 2009 From: sebastian.redl at getdesigned.at (Sebastian Redl) Date: Sat, 03 Jan 2009 16:50:02 +0100 Subject: [cfe-dev] [Patch] Diagnose unused declaration In-Reply-To: <200901031628.35933.EdB@sigluy.net> References: <200901031628.35933.EdB@sigluy.net> Message-ID: <495F892A.4080805@getdesigned.at> EdB wrote: > Hello > > Please find attached a patch in order to diagnose unused declaration. > This sould solve http://llvm.org/bugs/show_bug.cgi?id=2739 > > As I'm new to clang, I'm not sure if I did it the right way. > Comments are welcome. > Looks good. There seems to be a whitespace issue in ActOnEndOfTranslationUnit. Sebastian From hhinnant at apple.com Sat Jan 3 10:46:49 2009 From: hhinnant at apple.com (Howard Hinnant) Date: Sat, 3 Jan 2009 11:46:49 -0500 Subject: [cfe-dev] On sizeof char, bytes, and bits in the C99 standard In-Reply-To: <7158ABB4-33B9-4C54-A623-3D71CFA7361F@apple.com> References: <495E32AB.4040603@gmail.com> <495E37E3.1090305@getdesigned.at> <495E4509.3010806@gmail.com> <7158ABB4-33B9-4C54-A623-3D71CFA7361F@apple.com> Message-ID: <4066D4FE-D685-44FF-BCB5-C84C0A909DCF@apple.com> On Jan 2, 2009, at 2:27 PM, Chris Lattner wrote: > On Jan 2, 2009, at 8:47 AM, T?r?k Edwin wrote: >> Ok, so I may assume that on any POSIX compliant platform CHAR_BITS >> is 8? >> (POSIX requires (u)int8_t: >> http://www.opengroup.org/onlinepubs/000095399/basedefs/stdint.h.html) > > I think that it is safe to say that Clang should only care about 8-bit > bytes until someone comes along with a machine that has a non-8-bit > byte and is willing to do the work to enhance it... This seems like a reasonable strategy, but I wanted to add: 24 bit byte processors are not rare in the DSP (audio/vidio processing) arena. Typically everything (char, short, int, long) is 1 byte / 24 bits on such a platform. -Howard From EdB at sigluy.net Sat Jan 3 13:14:41 2009 From: EdB at sigluy.net (EdB) Date: Sat, 3 Jan 2009 20:14:41 +0100 Subject: [cfe-dev] [Patch] Diagnose unused declaration In-Reply-To: <495F892A.4080805@getdesigned.at> References: <200901031628.35933.EdB@sigluy.net> <495F892A.4080805@getdesigned.at> Message-ID: <200901032014.53552.EdB@sigluy.net> > Looks good. There seems to be a whitespace issue in > ActOnEndOfTranslationUnit. Pleased find attached a new version: It fixed some crash. Unused warning is no longer actived by default. You should enable it with -Wunused_declaration -------------- next part -------------- A non-text attachment was scrubbed... Name: unused.patch Type: text/x-diff Size: 7326 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090103/dfa7f29f/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090103/dfa7f29f/attachment-0001.bin From kremenek at apple.com Sat Jan 3 13:32:25 2009 From: kremenek at apple.com (Ted Kremenek) Date: Sat, 3 Jan 2009 11:32:25 -0800 Subject: [cfe-dev] Why does scan-build disable check for uninit values? In-Reply-To: <25cf7a9f0901030143k76fa8cbfr425ac67f59554a22@mail.gmail.com> References: <25cf7a9f0901020218q4b9aafaaq5078a068cf2e4b79@mail.gmail.com> <25cf7a9f0901030109p3daf8aa0o386febb9dcc50387@mail.gmail.com> <25cf7a9f0901030143k76fa8cbfr425ac67f59554a22@mail.gmail.com> Message-ID: On Jan 3, 2009, at 1:43 AM, Cristian Draghici wrote: > > > On Sat, Jan 3, 2009 at 11:09 AM, Cristian Draghici > wrote: > > > On Fri, Jan 2, 2009 at 11:43 PM, Ted Kremenek > wrote: > > On Jan 2, 2009, at 2:18 AM, Cristian Draghici wrote: > > Hi > > I've noticed that scan-build in the latest version of the checker > (137) disables the check for uninit values (-warn-uninit-values). > Is there a reason behind that? > > > Thank you, > Cristi > > In the static analyzer, checking for uninitialized values, just as > with checking for null dereferences, is done as part of the core > path-sensitive logic used for -checker-cfref and -checker-simple. > It isn't controlled by -warn-uninit-values. > > The -warn-uninit-values option performs a fast check for uses of > uninitialized values that is similar to GCC's -Wuninitialized. It > should be thought of as a cheap check that can be used (one day) as > a compiler warning rather than a deep check done by the static > analyzer. The checking for uninitialized values done by the static > analyzer is far more precise. > > Some of these options should probably be renamed to avoid such > confusion. > > My confusion was actually caused by the different output of "- > checker-cfref" vs "-warn-uninit-values". > > In the warning below shouldn't clang say "Pass-by-value argument in > function is uninitialized"? > English is not my native language so I may be wrong but I tend to > equate "undefined" with "undeclared" (as in lacking definition). > > diciu$ ~/Downloads/checker-137/clang -x c test.c -checker-cfref > ANALYZE: test.c main > test.c:6:2: warning: Pass-by-value argument in function is undefined. > strcpy(t, g); > ^ ~ > 1 diagnostic generated. > > > diciu$ ~/Downloads/checker-137/clang -x c test.c -warn-uninit-values > test.c:6:9: warning: use of uninitialized variable > strcpy(t, g); > ^ > test.c:6:12: warning: use of uninitialized variable > strcpy(t, g); > ^ > 2 diagnostics generated. > > test.c is: > > #include > > int main() > { > char * t, * g; > strcpy(t, g); > > return 0; > } > > > > > Oh, nevermind, I get it. > > "Pass-by-value argument in function is undefined" probably refers to > the value pointed to by the char pointer as being undefined, which > it is. That's it. I used the terminology "undefined" because undefined values can come from other sources other than uninitialized variables. The warning, however, could probably be worded a little more clearly. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090103/e8fee278/attachment.html From kremenek at apple.com Sat Jan 3 13:41:14 2009 From: kremenek at apple.com (Ted Kremenek) Date: Sat, 3 Jan 2009 11:41:14 -0800 Subject: [cfe-dev] [Patch] Diagnose unused declaration In-Reply-To: <200901032014.53552.EdB@sigluy.net> References: <200901031628.35933.EdB@sigluy.net> <495F892A.4080805@getdesigned.at> <200901032014.53552.EdB@sigluy.net> Message-ID: On Jan 3, 2009, at 11:14 AM, EdB wrote: >> Looks good. There seems to be a whitespace issue in >> ActOnEndOfTranslationUnit. > > Pleased find attached a new version: > It fixed some crash. > Unused warning is no longer actived by default. You should enable it > with -Wunused_declaration I'm not certain that the approach here will work. Since an IdentifierInfo is not unique to a declaration using a bit in IdentifierInfo to perform this check will be ineffective in many cases. For example: void f() { int x = ... x++; } void g() { int x; // no warning will be issued } The other thing that bothers me about this is putting this bit in IdentifierInfo in the first place. It seems like a very invasive thing to do for a simple check like this, especially one that isn't always used. Generally we like to keep such information "on the side" unless there is a good reason not to. Why not use a DenseSet to keep track (on the side) of what declarations are used? You can then do this on a declaration based (i.e., for a particular NamedDecl) rather than using IdentifierInfo's in this conflated way. From neil at daikokuya.co.uk Sat Jan 3 18:59:04 2009 From: neil at daikokuya.co.uk (Neil Booth) Date: Sun, 4 Jan 2009 09:59:04 +0900 Subject: [cfe-dev] [Patch] Diagnose unused declaration In-Reply-To: References: <200901031628.35933.EdB@sigluy.net> <495F892A.4080805@getdesigned.at> <200901032014.53552.EdB@sigluy.net> Message-ID: <20090104005904.GA521@daikokuya.co.uk> Ted Kremenek wrote:- > > On Jan 3, 2009, at 11:14 AM, EdB wrote: > > >> Looks good. There seems to be a whitespace issue in > >> ActOnEndOfTranslationUnit. > > > > Pleased find attached a new version: > > It fixed some crash. > > Unused warning is no longer actived by default. You should enable it > > with -Wunused_declaration > > I'm not certain that the approach here will work. Since an > IdentifierInfo is not unique to a declaration using a bit in > IdentifierInfo to perform this check will be ineffective in many > cases. For example: > > void f() { > int x = ... > x++; > } > > void g() { > int x; // no warning will be issued > } > > The other thing that bothers me about this is putting this bit in > IdentifierInfo in the first place. It seems like a very invasive > thing to do for a simple check like this, especially one that isn't > always used. Generally we like to keep such information "on the side" > unless there is a good reason not to. Why not use a DenseSet to keep > track (on the side) of what declarations are used? You can then do > this on a declaration based (i.e., for a particular NamedDecl) rather > than using IdentifierInfo's in this conflated way. Further, in standard C90 int z; sizeof z; z is generally not considered "used". C99 adds more complexity. In C++ the rules are vastly more complicated. Neil. From xuzhongxing at gmail.com Sun Jan 4 03:10:48 2009 From: xuzhongxing at gmail.com (Zhongxing Xu) Date: Sun, 4 Jan 2009 17:10:48 +0800 Subject: [cfe-dev] [PATCH] Extend the use of DeclGroup Message-ID: <5400aeb80901040110n64165b8ctf369fa3985b7ace@mail.gmail.com> This patch is the first step to solve the problem that no one is owning the struct decl in the following code: typedef struct s {} s_t; Later a TypeSpecifier holding this struct decl will be added to DeclGroup as discussed on the mailing list months before. The root of changes is at Sema::FinalizeDeclaratorGroup. It returns DeclGroupOwningRef instead of DeclTy*. A bunch of related methods now return DeclGroupOwningRef instead of DeclTy*. Top level declarations are DeclGroups instead of Decls. TranslationUnit uses a vector of DeclGroupOwningRef to track all Decls. Most of the dtor of TranslationUnit is disabled. The cleanup works should be done by the DeclGroup. LinkageSpecDecl now uses a DeclGroup array to track all Decls. Three ObjC static analysis test cases fail. I haven't figured out the reasons. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090104/f3e6b0ec/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: dg.patch Type: application/octet-stream Size: 42562 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090104/f3e6b0ec/attachment-0001.obj From EdB at sigluy.net Sun Jan 4 12:59:24 2009 From: EdB at sigluy.net (EdB) Date: Sun, 4 Jan 2009 19:59:24 +0100 Subject: [cfe-dev] [Patch] Diagnose unused declaration In-Reply-To: <20090104005904.GA521@daikokuya.co.uk> References: <200901031628.35933.EdB@sigluy.net> <20090104005904.GA521@daikokuya.co.uk> Message-ID: <200901041959.32196.EdB@sigluy.net> Hello This time "used" informations are keep "on the side". There is place ?for improvement but I want to be sure that information are at the right place before. -------------- next part -------------- A non-text attachment was scrubbed... Name: unused.patch Type: text/x-diff Size: 7221 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090104/b6c72c3e/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090104/b6c72c3e/attachment-0001.bin From john.graley at ntlworld.com Sun Jan 4 13:38:24 2009 From: john.graley at ntlworld.com (John Graley) Date: Sun, 4 Jan 2009 19:38:24 -0000 Subject: [cfe-dev] Assert in lexer In-Reply-To: References: <25cf7a9f0901020218q4b9aafaaq5078a068cf2e4b79@mail.gmail.com><25cf7a9f0901030109p3daf8aa0o386febb9dcc50387@mail.gmail.com><25cf7a9f0901030143k76fa8cbfr425ac67f59554a22@mail.gmail.com> Message-ID: <56D5F7BABD744450B3E6CEA5A0FF5033@kyle> Hi All I'm using clang as a parser for another project (ie I have my own Actions implementation) and I get an assert failure on the following code: int a; int main() { return ::a; } The assertion text reads: assertion "CachedTokens[CachedLexPos-1].getLocation() == Tok.getAnnotationEndLoc() && "The annotation should be until the most recent cached token"" failed: file "PPCaching.cpp", line 95 Does anyone know what this is? Also, can I turn off caching of tokens if I'm not worried about speed? Cheers, John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090104/bc15a06a/attachment.html From john.graley at ntlworld.com Sun Jan 4 14:22:29 2009 From: john.graley at ntlworld.com (John Graley) Date: Sun, 4 Jan 2009 20:22:29 -0000 Subject: [cfe-dev] Assert in lexer In-Reply-To: <56D5F7BABD744450B3E6CEA5A0FF5033@kyle> References: <25cf7a9f0901020218q4b9aafaaq5078a068cf2e4b79@mail.gmail.com><25cf7a9f0901030109p3daf8aa0o386febb9dcc50387@mail.gmail.com><25cf7a9f0901030143k76fa8cbfr425ac67f59554a22@mail.gmail.com> <56D5F7BABD744450B3E6CEA5A0FF5033@kyle> Message-ID: <716EE944529C4C7BAA554CC776FDA57D@kyle> A little more info: AnnotatePreviousCachedTokens() is called from AnnotateCachedTokens() which is called from TryAnnotateTypeOrScopeToken() in the last clause (dealing with C++ scope followed by non-typename). AnnotatePreviousCachedTokens() requires the range of the supplied annotation token to end at the last pasrsed token. This range is being set from the source range of the C++ scope. ----- Original Message ----- From: John Graley To: cfe-dev at cs.uiuc.edu Sent: Sunday, January 04, 2009 7:38 PM Subject: [cfe-dev] Assert in lexer Hi All I'm using clang as a parser for another project (ie I have my own Actions implementation) and I get an assert failure on the following code: int a; int main() { return ::a; } The assertion text reads: assertion "CachedTokens[CachedLexPos-1].getLocation() == Tok.getAnnotationEndLoc() && "The annotation should be until the most recent cached token"" failed: file "PPCaching.cpp", line 95 Does anyone know what this is? Also, can I turn off caching of tokens if I'm not worried about speed? Cheers, John ------------------------------------------------------------------------------ _______________________________________________ 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/20090104/03b03699/attachment.html From sebastian.redl at getdesigned.at Sun Jan 4 14:25:49 2009 From: sebastian.redl at getdesigned.at (Sebastian Redl) Date: Sun, 04 Jan 2009 21:25:49 +0100 Subject: [cfe-dev] Assert in lexer In-Reply-To: <716EE944529C4C7BAA554CC776FDA57D@kyle> References: <25cf7a9f0901020218q4b9aafaaq5078a068cf2e4b79@mail.gmail.com><25cf7a9f0901030109p3daf8aa0o386febb9dcc50387@mail.gmail.com><25cf7a9f0901030143k76fa8cbfr425ac67f59554a22@mail.gmail.com> <56D5F7BABD744450B3E6CEA5A0FF5033@kyle> <716EE944529C4C7BAA554CC776FDA57D@kyle> Message-ID: <49611B4D.90707@getdesigned.at> John Graley wrote: > A little more info: > > AnnotatePreviousCachedTokens() is called from AnnotateCachedTokens() > which is called from TryAnnotateTypeOrScopeToken() in the last clause > (dealing with C++ scope followed by non-typename). > > AnnotatePreviousCachedTokens() requires the range of the supplied > annotation token to end at the last pasrsed token. This range is being > set from the source range of the C++ scope. > I can reproduce the bug, but this stuff is Argiris's baby, and he's rarely available on weekends. Sebastian From clattner at apple.com Sun Jan 4 19:41:01 2009 From: clattner at apple.com (Chris Lattner) Date: Sun, 4 Jan 2009 17:41:01 -0800 Subject: [cfe-dev] Assert in lexer In-Reply-To: <56D5F7BABD744450B3E6CEA5A0FF5033@kyle> References: <25cf7a9f0901020218q4b9aafaaq5078a068cf2e4b79@mail.gmail.com> <25cf7a9f0901030109p3daf8aa0o386febb9dcc50387@mail.gmail.com> <25cf7a9f0901030143k76fa8cbfr425ac67f59554a22@mail.gmail.com> <56D5F7BABD744450B3E6CEA5A0FF5033@kyle> Message-ID: <5AF2A6A4-6B15-42C7-A636-2B135B43005A@apple.com> On Jan 4, 2009, at 11:38 AM, John Graley wrote: > Hi All > > I'm using clang as a parser for another project (ie I have my own > Actions implementation) and I get an assert failure on the following > code: > > int a; > int main() > { > return ::a; > } > The assertion text reads: > > assertion "CachedTokens[CachedLexPos-1].getLocation() == > Tok.getAnnotationEndLoc() && "The annotation should be until the > most recent cached token"" failed: file "PPCaching.cpp", line 95 > > Does anyone know what this is? Also, can I turn off caching of > tokens if I'm not worried about speed? > This should work now, please let me know if you see similar asserts, -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090104/23fce966/attachment-0001.html From dgregor at apple.com Mon Jan 5 10:51:13 2009 From: dgregor at apple.com (Douglas Gregor) Date: Mon, 5 Jan 2009 08:51:13 -0800 Subject: [cfe-dev] [Patch] Diagnose unused declaration In-Reply-To: <200901041959.32196.EdB@sigluy.net> References: <200901031628.35933.EdB@sigluy.net> <20090104005904.GA521@daikokuya.co.uk> <200901041959.32196.EdB@sigluy.net> Message-ID: <3E33F41F-8C65-4F2D-9B05-8F156C82C742@apple.com> Hello, On Jan 4, 2009, at 7:59 PM, EdB wrote: > This time "used" informations are keep "on the side". Thanks; that's much better. > There is place for improvement but I want to be sure that > information are at > the right place before. A few comments on this iteration: static llvm::cl::opt +WarnUnusedDeclaration("Wunused_declaration", + llvm::cl::desc("Warn for unused declaration")); I suggest that we use the same command-line arguments as GCC, unless there is some specific reason to deviate from them: http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/Warning-Options.html#Warning-Options In Sema::PopDeclContext(), the warning-generation code needs to be much more picky about which declarations it complains about. For example, I tried this C++ example: namespace N { int x; } namespace N { int f() { return x; } } and Clang produced 4 warnings: one each for x, f, __builtin_va_list, and N: This option should not produce warnings about any of these, because: - x is the definition of a variable that can be referred to by other translation units, so even if it isn't used within this translation unit, we should not warn about it. Plus, "x" is used later on in the program (in a different DeclContext for the namespace N). Note that GCC's -Wunused-variable documentation explicitly says that it only warns about local variables and non-constant static variables; we should do something similar. - f is the definition of a function, which could also be referenced by other translation units. Note that GCC's -Wunused-function only complains about static functions (and, presumably, functions in anonymous namespaces) because those aren't visible outside of the translation unit. - __builtin_va_list wasn't written by the user, so we shouldn't complain about it. Besides, do we even want to complain about unused typedefs? Especially in C++, there are certainly reasons to write typedefs even if they aren't used in the translation unit. - N is a namespace; do we ever want to warn about those? I see that UsedDeclaration grows throughout the processing of the translation unit, because nothing is ever removed from the set (even when it is no longer visible through name lookup). We'd like to avoid that. Does this warning work properly in C? In Sema::LookupDecl, it looks like you need to change for (; I != IdResolver.end(); ++I) if ((*I)->getIdentifierNamespace() & NS) return *I; to for (; I != IdResolver.end(); ++I) if ((*I)->getIdentifierNamespace() & NS) { UsedDeclaration.insert(*I); return *I; } ? Also in Sema::LookupDecl: - return MaybeConstructOverloadSet(Context, I, E); + Decl *D = MaybeConstructOverloadSet(Context, I, E); + UsedDeclaration.insert(static_cast(D)); + return D; The result of MaybeConstructOverloadSet could be an OverloadedFunctionDecl, which is transient and therefore should not be inserted into the UsedDeclaration set (since we'd never know to remove it). Do we need the new code in ActOnEndOfTranslationUnit? It's nearly identical to the new code in Sema::PopDeclContext, and translation units are DeclContexts. Perhaps this code could be factored out? Personally, I think that any patch introducing warnings for unused variables/parameters/functions/etc. also needs to support GCC's __attribute__((unused)) extension to turn off the warning for specific declarations. We'll get a lot of complaints from GCC users if we produce this warning when they've explicitly asked to suppress it for a declaration. You'll need to include a regression test that works with -verify along with your patch, so that we can make sure this functionality doesn't break in the future. You'll probably need at least two regression tests, one each for C and C++. Try to exercise a bunch of different language features in them, e.g., overloading in C++, uses of "extern", "inline", etc. Getting this warning right is actually far harder than it looks at first blush, but you've got a good start on it. - Doug From dgregor at apple.com Mon Jan 5 11:14:52 2009 From: dgregor at apple.com (Douglas Gregor) Date: Mon, 5 Jan 2009 09:14:52 -0800 Subject: [cfe-dev] new warnings n -r61596 In-Reply-To: <0629F060-D72F-460D-9946-B283B8364735@apple.com> References: <0629F060-D72F-460D-9946-B283B8364735@apple.com> Message-ID: <1D8A9FBC-6C08-431F-B1E7-4E0661FEA96D@apple.com> On Jan 2, 2009, at 4:23 PM, Mike Stump wrote: > DeclCXX.cpp: In member function 'clang::Decl** > clang::LinkageSpecDecl::decls_begin() const': > DeclCXX.cpp:326: warning: dereferencing type-punned pointer will break > strict-aliasing rules > DeclCXX.cpp: In member function 'clang::Decl** > clang::LinkageSpecDecl::decls_end() const': > DeclCXX.cpp:331: warning: dereferencing type-punned pointer will break > strict-aliasing rules Thanks, Mike, but I'm a bit confused: I've turned on -Wstrict-aliasing and I don't see this warning, so I don't know how to suppress it. I believe that the code itself is correct (the void* decl is either handled as a Decl* or as a Decl**, depending on the HadBraces bit). - Doug From dgregor at apple.com Mon Jan 5 12:02:59 2009 From: dgregor at apple.com (Douglas Gregor) Date: Mon, 5 Jan 2009 10:02:59 -0800 Subject: [cfe-dev] Review Request: Plain Old Data (POD) property of classes, and type traits basics In-Reply-To: <495E5571.6060107@getdesigned.at> References: <495E5571.6060107@getdesigned.at> Message-ID: <5A1F7CA0-22A8-40E3-86BE-C1BF477902B1@apple.com> Hi Sebastian, On Jan 2, 2009, at 6:57 PM, Sebastian Redl wrote: > I've implemented the POD property of classes, and (in order to test > it) > a basic infrastructure for GCC's type traits extensions, plus a > concrete > implementation of the __is_pod trait. Cool. > > However, I'm not quite sure about all aspects of the patch, so I'm > posting it for review first. In particular, I have an enum called > UnaryTypeTrait that represents the various type trait keywords. > Since it > is needed in the parser, the sema and the AST, I saw no other choice > but > to make it part of Basic. Is this the right thing to do? Yes, I think so. AccessSpecifier, which currently lives in Parse, should also be moved back to Basic (but that's my problem, not yours). +/// UnaryTypeTraitExpr - A GCC or MS unary type trait, as used in the +/// implementation of TR1/C++0x type trait templates. Please add an example to the documentation for this class. + // FIXME: Some of the type traits have requirements. Interestingly, only the + // __is_base_of requirement is explicitly stated to be diagnosed. Indeed, + // G++ accepts __is_pod(Incomplete) without complaints, and claims that the + // type is indeed a POD. Interesting. The documentation for __is_pod says: Requires: type shall be a complete type, an array type of unknown bound, or is a void type. So GCC should be diagnosing this kind of error. We should report the problem to them. However, we can address this FIXME later. The point of the patch is PODs, right? :) In Type::isPODType, could you add a FIXME for pointer-to-member types? (I almost want to just add basic pointer-to-member support now, since we seem to have lots of FIXMEs for them). Regarding the FIXME at the end of CXXRecordDecl::hasConstCopyAssignment, I think we should assert that the CXXRecordDecl itself is marked "invalid". We shouldn't get here in any well-formed program. This patch looks really good to me. Thanks! - Doug From kremenek at apple.com Mon Jan 5 12:26:34 2009 From: kremenek at apple.com (Ted Kremenek) Date: Mon, 5 Jan 2009 10:26:34 -0800 Subject: [cfe-dev] [PATCH] Extend the use of DeclGroup In-Reply-To: <5400aeb80901040110n64165b8ctf369fa3985b7ace@mail.gmail.com> References: <5400aeb80901040110n64165b8ctf369fa3985b7ace@mail.gmail.com> Message-ID: Hi Zhongxing, Thanks for taking this on! This is a big patch, so I'm taking some time to go through it. I had a quick question though about one thing that caught my attention: TranslationUnit::~TranslationUnit() { + for (std::vector::reverse_iterator + I = TopLevelDecls.rbegin(), E = TopLevelDecls.rend(); I != E; ++I) { + I->clear(); + } + +#if 0 if (OwnsDecls) { llvm::DenseSet Killed; for (std::vector::reverse_iterator I=TopLevelDecls.rbegin(), @@ -102,7 +108,7 @@ (*I)->Destroy(*Context); } } - +#endif It looks like that in your patch that Decls will not be freed in ~TranslationUnit since the "Destroy" method for each DeclGroupRef is not called. Did you decide to do this because of issues with ownership? If so, there needs to be a big FIXME comment here documenting the issue. Actually, I don't think we should have a regression in functionality here (i.e., releasing Decls) unless it is absolutely necessary. While the code in ~TranslationUnit that bends over backwards to avoid deleting a Decl more than once is gross, it also works, and IMHO shouldn't be removed until we have cleaned up the ownership issues in the AST. On Jan 4, 2009, at 1:10 AM, Zhongxing Xu wrote: > This patch is the first step to solve the problem that no one is > owning the > struct decl in the following code: > > typedef struct s {} s_t; > > Later a TypeSpecifier holding this struct decl will be added to > DeclGroup as > discussed on the mailing list months before. > > The root of changes is at Sema::FinalizeDeclaratorGroup. It returns > DeclGroupOwningRef instead of DeclTy*. A bunch of related methods > now return > DeclGroupOwningRef instead of DeclTy*. > > Top level declarations are DeclGroups instead of Decls. > TranslationUnit > uses a vector of DeclGroupOwningRef to track all Decls. Most of the > dtor of > TranslationUnit is disabled. The cleanup works should be done by the > DeclGroup. > > LinkageSpecDecl now uses a DeclGroup array to track all Decls. > > Three ObjC static analysis test cases fail. I haven't figured out > the reasons. > > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From sebastian.redl at getdesigned.at Mon Jan 5 13:37:28 2009 From: sebastian.redl at getdesigned.at (Sebastian Redl) Date: Mon, 05 Jan 2009 20:37:28 +0100 Subject: [cfe-dev] [Patch] Diagnose unused declaration In-Reply-To: <3E33F41F-8C65-4F2D-9B05-8F156C82C742@apple.com> References: <200901031628.35933.EdB@sigluy.net> <20090104005904.GA521@daikokuya.co.uk> <200901041959.32196.EdB@sigluy.net> <3E33F41F-8C65-4F2D-9B05-8F156C82C742@apple.com> Message-ID: <49626178.3070506@getdesigned.at> Douglas Gregor wrote: > Hello, > > On Jan 4, 2009, at 7:59 PM, EdB wrote: > >> There is place for improvement but I want to be sure that >> information are at >> the right place before. >> > > A few comments on this iteration: > > In Sema::PopDeclContext(), the warning-generation code needs to be > much more picky about which declarations it complains about. For > example, I tried this C++ example: > > namespace N { > int x; > } > > namespace N { > int f() { > return x; > } > } > > and Clang produced 4 warnings: one each for x, f, __builtin_va_list, > and N: > > This option should not produce warnings about any of these, because: > > - x is the definition of a variable that can be referred to by other > translation units, so even if it isn't used within this translation > unit, we should not warn about it. Plus, "x" is used later on in the > program (in a different DeclContext for the namespace N). Note that > GCC's -Wunused-variable documentation explicitly says that it only > warns about local variables and non-constant static variables; we > should do something similar. > > - f is the definition of a function, which could also be referenced > by other translation units. Note that GCC's -Wunused-function only > complains about static functions (and, presumably, functions in > anonymous namespaces) because those aren't visible outside of the > translation unit. > > - __builtin_va_list wasn't written by the user, so we shouldn't > complain about it. Besides, do we even want to complain about unused > typedefs? Especially in C++, there are certainly reasons to write > typedefs even if they aren't used in the translation unit. > > - N is a namespace; do we ever want to warn about those? > > I see that UsedDeclaration grows throughout the processing of the > translation unit, because nothing is ever removed from the set (even > when it is no longer visible through name lookup). We'd like to avoid > that. > I think both problems could be solved together by, instead of keeping track of declarations that are used, keeping track of those that are unused. In other words, the UsedDeclarations becomes UnusedDeclarations. When a new declaration is encountered, it is added to the set if 1) it is function-local or TU-local and 2) it does not have the unused attribute. When a declaration is used, it is removed from the set. When a scope is left, we check which of the declarations now going out of scope are still in the set and warn about those. Sebastian From sebastian.redl at getdesigned.at Mon Jan 5 13:38:39 2009 From: sebastian.redl at getdesigned.at (Sebastian Redl) Date: Mon, 05 Jan 2009 20:38:39 +0100 Subject: [cfe-dev] new warnings n -r61596 In-Reply-To: <1D8A9FBC-6C08-431F-B1E7-4E0661FEA96D@apple.com> References: <0629F060-D72F-460D-9946-B283B8364735@apple.com> <1D8A9FBC-6C08-431F-B1E7-4E0661FEA96D@apple.com> Message-ID: <496261BF.10502@getdesigned.at> Douglas Gregor wrote: > On Jan 2, 2009, at 4:23 PM, Mike Stump wrote: > > >> DeclCXX.cpp: In member function 'clang::Decl** >> clang::LinkageSpecDecl::decls_begin() const': >> DeclCXX.cpp:326: warning: dereferencing type-punned pointer will break >> strict-aliasing rules >> DeclCXX.cpp: In member function 'clang::Decl** >> clang::LinkageSpecDecl::decls_end() const': >> DeclCXX.cpp:331: warning: dereferencing type-punned pointer will break >> strict-aliasing rules >> > > Thanks, Mike, but I'm a bit confused: I've turned on -Wstrict-aliasing > and I don't see this warning, so I don't know how to suppress it. I > believe that the code itself is correct (the void* decl is either > handled as a Decl* or as a Decl**, depending on the HadBraces bit). > I've seen the warning, but only in a release build. Perhaps it depends on an analysis that GCC doesn't do without optimizations? Sebastian From sebastian.redl at getdesigned.at Mon Jan 5 14:16:37 2009 From: sebastian.redl at getdesigned.at (Sebastian Redl) Date: Mon, 05 Jan 2009 21:16:37 +0100 Subject: [cfe-dev] Review Request: Plain Old Data (POD) property of classes, and type traits basics In-Reply-To: <5A1F7CA0-22A8-40E3-86BE-C1BF477902B1@apple.com> References: <495E5571.6060107@getdesigned.at> <5A1F7CA0-22A8-40E3-86BE-C1BF477902B1@apple.com> Message-ID: <49626AA5.9070704@getdesigned.at> Douglas Gregor wrote: > Hi Sebastian, > > On Jan 2, 2009, at 6:57 PM, Sebastian Redl wrote: >> However, I'm not quite sure about all aspects of the patch, so I'm >> posting it for review first. In particular, I have an enum called >> UnaryTypeTrait that represents the various type trait keywords. Since it >> is needed in the parser, the sema and the AST, I saw no other choice but >> to make it part of Basic. Is this the right thing to do? > > Yes, I think so. AccessSpecifier, which currently lives in Parse, > should also be moved back to Basic (but that's my problem, not yours). OK. > > +/// UnaryTypeTraitExpr - A GCC or MS unary type trait, as used in the > +/// implementation of TR1/C++0x type trait templates. > > Please add an example to the documentation for this class. Done. > > + // FIXME: Some of the type traits have requirements. Interestingly, > only the > + // __is_base_of requirement is explicitly stated to be diagnosed. > Indeed, > + // G++ accepts __is_pod(Incomplete) without complaints, and claims > that the > + // type is indeed a POD. > > Interesting. The documentation for __is_pod says: > > Requires: type shall be a complete type, an array type of unknown > bound, or is a void type. > The candidate draft says the same thing, word for word, about std::is_pod. > So GCC should be diagnosing this kind of error. We should report the > problem to them. However, we can address this FIXME later. The point > of the patch is PODs, right? :) > > In Type::isPODType, could you add a FIXME for pointer-to-member types? > (I almost want to just add basic pointer-to-member support now, since > we seem to have lots of FIXMEs for them). Done. The FIXME, not member pointers. :-( > > Regarding the FIXME at the end of > CXXRecordDecl::hasConstCopyAssignment, I think we should assert that > the CXXRecordDecl itself is marked "invalid". We shouldn't get here in > any well-formed program. OK. > > This patch looks really good to me. Thanks! Thanks for the review. Sebastian From eli.friedman at gmail.com Mon Jan 5 14:22:42 2009 From: eli.friedman at gmail.com (Eli Friedman) Date: Mon, 5 Jan 2009 12:22:42 -0800 Subject: [cfe-dev] new warnings n -r61596 In-Reply-To: <1D8A9FBC-6C08-431F-B1E7-4E0661FEA96D@apple.com> References: <0629F060-D72F-460D-9946-B283B8364735@apple.com> <1D8A9FBC-6C08-431F-B1E7-4E0661FEA96D@apple.com> Message-ID: On Mon, Jan 5, 2009 at 9:14 AM, Douglas Gregor wrote: > > On Jan 2, 2009, at 4:23 PM, Mike Stump wrote: > >> DeclCXX.cpp: In member function 'clang::Decl** >> clang::LinkageSpecDecl::decls_begin() const': >> DeclCXX.cpp:326: warning: dereferencing type-punned pointer will break >> strict-aliasing rules >> DeclCXX.cpp: In member function 'clang::Decl** >> clang::LinkageSpecDecl::decls_end() const': >> DeclCXX.cpp:331: warning: dereferencing type-punned pointer will break >> strict-aliasing rules > > Thanks, Mike, but I'm a bit confused: I've turned on -Wstrict-aliasing > and I don't see this warning, so I don't know how to suppress it. I think you have to turn on optimizations for this warning to work. (Sucks, but that's the way gcc works...) > I believe that the code itself is correct (the void* decl is either > handled as a Decl* or as a Decl**, depending on the HadBraces bit). Not that it really matters anymore, since the code in question is gone, but the code is wrong... the issue boils down to a testcase like the following: class Decl; void* Decls; Decl** x() {return (Decl**)&Decls;} Decl* y() {return *x();} Calling y() results in undefined behavior because the Decl** points to a void*, and Decl* and void* aren't allowed to alias. One correct solution is using a declaration like "union {Decl **declArrayPtr, *declPtr} Decls;" instead of "void *Decls;". -Eli From dgregor at apple.com Mon Jan 5 15:04:39 2009 From: dgregor at apple.com (Douglas Gregor) Date: Mon, 5 Jan 2009 13:04:39 -0800 Subject: [cfe-dev] [Patch] Diagnose unused declaration In-Reply-To: <49626178.3070506@getdesigned.at> References: <200901031628.35933.EdB@sigluy.net> <20090104005904.GA521@daikokuya.co.uk> <200901041959.32196.EdB@sigluy.net> <3E33F41F-8C65-4F2D-9B05-8F156C82C742@apple.com> <49626178.3070506@getdesigned.at> Message-ID: On Jan 5, 2009, at 8:37 PM, Sebastian Redl wrote: > Douglas Gregor wrote: >> Hello, >> >> On Jan 4, 2009, at 7:59 PM, EdB wrote: >> >>> There is place for improvement but I want to be sure that >>> information are at >>> the right place before. >>> >> >> A few comments on this iteration: >> >> In Sema::PopDeclContext(), the warning-generation code needs to be >> much more picky about which declarations it complains about. For >> example, I tried this C++ example: >> >> namespace N { >> int x; >> } >> >> namespace N { >> int f() { >> return x; >> } >> } >> >> and Clang produced 4 warnings: one each for x, f, __builtin_va_list, >> and N: >> >> This option should not produce warnings about any of these, because: >> >> - x is the definition of a variable that can be referred to by other >> translation units, so even if it isn't used within this translation >> unit, we should not warn about it. Plus, "x" is used later on in the >> program (in a different DeclContext for the namespace N). Note that >> GCC's -Wunused-variable documentation explicitly says that it only >> warns about local variables and non-constant static variables; we >> should do something similar. >> >> - f is the definition of a function, which could also be referenced >> by other translation units. Note that GCC's -Wunused-function only >> complains about static functions (and, presumably, functions in >> anonymous namespaces) because those aren't visible outside of the >> translation unit. >> >> - __builtin_va_list wasn't written by the user, so we shouldn't >> complain about it. Besides, do we even want to complain about unused >> typedefs? Especially in C++, there are certainly reasons to write >> typedefs even if they aren't used in the translation unit. >> >> - N is a namespace; do we ever want to warn about those? >> >> I see that UsedDeclaration grows throughout the processing of the >> translation unit, because nothing is ever removed from the set (even >> when it is no longer visible through name lookup). We'd like to avoid >> that. >> > I think both problems could be solved together by, instead of keeping > track of declarations that are used, keeping track of those that are > unused. > In other words, the UsedDeclarations becomes UnusedDeclarations. > When a > new declaration is encountered, it is added to the set if > 1) it is function-local or TU-local and > 2) it does not have the unused attribute. > When a declaration is used, it is removed from the set. When a scope > is > left, we check which of the declarations now going out of scope are > still in the set and warn about those. Great idea! This set should also be smaller than the UsedDeclarations set would be. - Doug From bolzoni at cs.unipr.it Mon Jan 5 15:43:18 2009 From: bolzoni at cs.unipr.it (Paolo Bolzoni) Date: Mon, 5 Jan 2009 22:43:18 +0100 Subject: [cfe-dev] Strange inconsistency between sizeof/typeof and type_of_type and type_of_expr. Message-ID: <20090105224318.7a185619@cs.unipr.it> dear clang-dev, I am seeing a strange inconsistency between sizeof/typeof as expression and __typeof() as type. The former is programmed with a single class clang::SizeOfAlignOfExpr with two bool functions isSizeOf() and isArgumentType() to distinguish the four combinations. The latter is instead a pair of classes, clang::TypeOfType and clang::TypeOfExpr. Why this implementation difference? Wasn't easier implementing four classes also for the first case? Like 'sizeof_expr, sizeof_type, typeof_expr, typeof_type.' pb From snaroff at apple.com Mon Jan 5 16:22:11 2009 From: snaroff at apple.com (steve naroff) Date: Mon, 5 Jan 2009 17:22:11 -0500 Subject: [cfe-dev] Strange inconsistency between sizeof/typeof and type_of_type and type_of_expr. In-Reply-To: <20090105224318.7a185619@cs.unipr.it> References: <20090105224318.7a185619@cs.unipr.it> Message-ID: On Jan 5, 2009, at 4:43 PM, Paolo Bolzoni wrote: > > dear clang-dev, > > I am seeing a strange inconsistency between sizeof/typeof as > expression and > __typeof() as type. > > The former is programmed with a single class > clang::SizeOfAlignOfExpr with > two bool functions isSizeOf() and isArgumentType() to distinguish > the four > combinations. > > The latter is instead a pair of classes, clang::TypeOfType and > clang::TypeOfExpr. > > Why this implementation difference? No compelling reason. > > Wasn't easier implementing four classes also for the first case? From my perspective, it looks like a stylistic difference. The classes were written at different times by different people (I recall writing the TypeOfType/TypeOfExpr AST's). > > Like 'sizeof_expr, sizeof_type, typeof_expr, typeof_type.' > Unifying them is fine with me (if you'd like to pursue it). snaroff > pb > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From dgregor at apple.com Mon Jan 5 16:24:47 2009 From: dgregor at apple.com (Douglas Gregor) Date: Mon, 5 Jan 2009 14:24:47 -0800 Subject: [cfe-dev] Strange inconsistency between sizeof/typeof and type_of_type and type_of_expr. In-Reply-To: References: <20090105224318.7a185619@cs.unipr.it> Message-ID: On Jan 5, 2009, at 5:22 PM, steve naroff wrote: > > On Jan 5, 2009, at 4:43 PM, Paolo Bolzoni wrote: > >> >> dear clang-dev, >> >> I am seeing a strange inconsistency between sizeof/typeof as >> expression and >> __typeof() as type. >> >> The former is programmed with a single class >> clang::SizeOfAlignOfExpr with >> two bool functions isSizeOf() and isArgumentType() to distinguish >> the four >> combinations. >> >> The latter is instead a pair of classes, clang::TypeOfType and >> clang::TypeOfExpr. >> >> Why this implementation difference? > > No compelling reason. > >> >> Wasn't easier implementing four classes also for the first case? > > From my perspective, it looks like a stylistic difference. The > classes were written at different times by different people (I recall > writing the TypeOfType/TypeOfExpr AST's). And CXXTypeidExpr is another one of these. Unifying them would help clean things up. - Doug From sebastian.redl at getdesigned.at Mon Jan 5 18:06:06 2009 From: sebastian.redl at getdesigned.at (Sebastian Redl) Date: Tue, 06 Jan 2009 01:06:06 +0100 Subject: [cfe-dev] Strange inconsistency between sizeof/typeof and type_of_type and type_of_expr. In-Reply-To: <20090105224318.7a185619@cs.unipr.it> References: <20090105224318.7a185619@cs.unipr.it> Message-ID: <4962A06E.5050206@getdesigned.at> Paolo Bolzoni wrote: > dear clang-dev, > > I am seeing a strange inconsistency between sizeof/typeof as expression and > __typeof() as type. > > The former is programmed with a single class clang::SizeOfAlignOfExpr with > two bool functions isSizeOf() and isArgumentType() to distinguish the four > combinations. > > The latter is instead a pair of classes, clang::TypeOfType and > clang::TypeOfExpr. > > Why this implementation difference? > Historical. SizeOfAlignOfExpr was originally two classes, one for types and one for expressions (actually, it used UnaryOperatorExpr for classes). When I implemented CXXTypeIdExpr I chose to make just one class, not being aware of the others. Then I found the SizeOfAlignOf handling and didn't like that one case was its own expression node, and the other part of UnaryExpression. It also led to a lot of special cases in the handling of UnaryOperator. So, with encouragement from Chris, I moved the sizeof/alignof expr functionality from UnaryOperator to SizeOfAlignOfExpr. TypeOfType/Expr, being a Type and not an Expr and not being an UnaryOperator, didn't come up. The advantage of having separate classes is that each class is simpler. But the advantage of having merged classes is that there are fewer classes. Given the number of times there is a switch on the expression type in Clang, this leads to a lot less code duplication in various areas of the codebase. Here's the commit of TypeIdExpr: http://www.mail-archive.com/cfe-commits at cs.uiuc.edu/msg02550.html And here's the SizeOfAlignOfExpr merge: http://www.mail-archive.com/cfe-commits at cs.uiuc.edu/msg02538.html Sebastian From clattner at apple.com Mon Jan 5 18:11:01 2009 From: clattner at apple.com (Chris Lattner) Date: Mon, 5 Jan 2009 16:11:01 -0800 Subject: [cfe-dev] [Patch] Diagnose unused declaration In-Reply-To: <49626178.3070506@getdesigned.at> References: <200901031628.35933.EdB@sigluy.net> <20090104005904.GA521@daikokuya.co.uk> <200901041959.32196.EdB@sigluy.net> <3E33F41F-8C65-4F2D-9B05-8F156C82C742@apple.com> <49626178.3070506@getdesigned.at> Message-ID: <79C1B314-8940-4DBF-B86B-0D884B8D9222@apple.com> On Jan 5, 2009, at 11:37 AM, Sebastian Redl wrote: > I think both problems could be solved together by, instead of keeping > track of declarations that are used, keeping track of those that are > unused. > In other words, the UsedDeclarations becomes UnusedDeclarations. > When a > new declaration is encountered, it is added to the set if > 1) it is function-local or TU-local and > 2) it does not have the unused attribute. > When a declaration is used, it is removed from the set. When a scope > is > left, we check which of the declarations now going out of scope are > still in the set and warn about those. I agree, that is a very nice approach. -Chris From xuzhongxing at gmail.com Mon Jan 5 18:27:49 2009 From: xuzhongxing at gmail.com (Zhongxing Xu) Date: Tue, 6 Jan 2009 08:27:49 +0800 Subject: [cfe-dev] [PATCH] Extend the use of DeclGroup In-Reply-To: References: <5400aeb80901040110n64165b8ctf369fa3985b7ace@mail.gmail.com> Message-ID: <5400aeb80901051627y198b39e7vcb195f148487485f@mail.gmail.com> On Tue, Jan 6, 2009 at 2:26 AM, Ted Kremenek wrote: > Hi Zhongxing, > > Thanks for taking this on! This is a big patch, so I'm taking some time to > go through it. I had a quick question though about one thing that caught my > attention: > > TranslationUnit::~TranslationUnit() { > + for (std::vector::reverse_iterator > + I = TopLevelDecls.rbegin(), E = TopLevelDecls.rend(); I != E; > ++I) { > + I->clear(); > + } > + > +#if 0 > if (OwnsDecls) { > llvm::DenseSet Killed; > for (std::vector::reverse_iterator I=TopLevelDecls.rbegin(), > @@ -102,7 +108,7 @@ > (*I)->Destroy(*Context); > } > } > - > +#endif > > It looks like that in your patch that Decls will not be freed in > ~TranslationUnit since the "Destroy" method for each DeclGroupRef is not > called. Did you decide to do this because of issues with ownership? Yes. If so, there needs to be a big FIXME comment here documenting the issue. Yes. Actually, I don't think we should have a regression in functionality here > (i.e., releasing Decls) unless it is absolutely necessary. I tried to Destroy() the DeclGroup in both order, but both crashed on some test cases. I think there may be bugs in the DeclGroupOwningRef's Destroy() method. I didn't investigate that further because I want to keep this patch as small as possible. > While the code in ~TranslationUnit that bends over backwards to avoid > deleting a Decl more than once is gross, it also works, and IMHO shouldn't > be removed until we have cleaned up the ownership issues in the AST. May be similar code should be added to DeclGroupOwningRef::Destroy() to make it work. > > > On Jan 4, 2009, at 1:10 AM, Zhongxing Xu wrote: > > This patch is the first step to solve the problem that no one is owning >> the >> struct decl in the following code: >> >> typedef struct s {} s_t; >> >> Later a TypeSpecifier holding this struct decl will be added to DeclGroup >> as >> discussed on the mailing list months before. >> >> The root of changes is at Sema::FinalizeDeclaratorGroup. It returns >> DeclGroupOwningRef instead of DeclTy*. A bunch of related methods now >> return >> DeclGroupOwningRef instead of DeclTy*. >> >> Top level declarations are DeclGroups instead of Decls. TranslationUnit >> uses a vector of DeclGroupOwningRef to track all Decls. Most of the dtor >> of >> TranslationUnit is disabled. The cleanup works should be done by the >> DeclGroup. >> >> LinkageSpecDecl now uses a DeclGroup array to track all Decls. >> >> Three ObjC static analysis test cases fail. I haven't figured out the >> reasons. >> >> >> _______________________________________________ >> 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/20090106/7dcf0045/attachment.html From alexei.svitkine at gmail.com Mon Jan 5 19:43:25 2009 From: alexei.svitkine at gmail.com (Alexei Svitkine) Date: Mon, 5 Jan 2009 20:43:25 -0500 Subject: [cfe-dev] Return type of statement Message-ID: <62d9ffc00901051743l506d870fs1217dd92c70553dd@mail.gmail.com> I am starting a project that will use clang. I'm asking to be pointed in the right direction with a question I have. Here goes. Given a context (ie a source file) and a statement somewhere in that file, what's the easiest way to find the return type of that statement with clang? For example, for an assignment, it's the type of the variable, for a function call, it's the return type, but obviously there are more complicated examples in C semantics. Surely, clang must be aware of this information, so what's the easiest way to get at it (using code)? -Alexei Svitkine From kremenek at apple.com Mon Jan 5 20:10:52 2009 From: kremenek at apple.com (Ted Kremenek) Date: Mon, 05 Jan 2009 18:10:52 -0800 Subject: [cfe-dev] Return type of statement In-Reply-To: <62d9ffc00901051743l506d870fs1217dd92c70553dd@mail.gmail.com> References: <62d9ffc00901051743l506d870fs1217dd92c70553dd@mail.gmail.com> Message-ID: Alexei, Statements that evalute to a value are known as expressions. Expressions are represented by the Expr class (which subclasses Stmt). The method Expr::getType() will return the information you want. I recommend looking at the Clang sources for example uses of this method. On Jan 5, 2009, at 5:43 PM, Alexei Svitkine wrote: > I am starting a project that will use clang. I'm asking to be pointed > in the right direction with a question I have. Here goes. > > Given a context (ie a source file) and a statement somewhere in that > file, what's the easiest way to find the return type of that statement > with clang? > > For example, for an assignment, it's the type of the variable, for a > function call, it's the return type, but obviously there are more > complicated examples in C semantics. > > Surely, clang must be aware of this information, so what's the easiest > way to get at it (using code)? > > -Alexei Svitkine > _______________________________________________ > 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 Jan 5 20:22:01 2009 From: clattner at apple.com (Chris Lattner) Date: Mon, 5 Jan 2009 18:22:01 -0800 Subject: [cfe-dev] Return type of statement In-Reply-To: References: <62d9ffc00901051743l506d870fs1217dd92c70553dd@mail.gmail.com> Message-ID: On Jan 5, 2009, at 6:10 PM, Ted Kremenek wrote: > Alexei, > > Statements that evalute to a value are known as expressions. > Expressions are represented by the Expr class (which subclasses > Stmt). The method Expr::getType() will return the information you > want. I recommend looking at the Clang sources for example uses of > this method. Try something like: Stmt *S = ... if (Expr *E = dyn_cast(S)) if (E->getType() == ... ) ... If something is a statement but not an expr, it doesn't produce a value (things like "if" or "break"). -Chris > > > On Jan 5, 2009, at 5:43 PM, Alexei Svitkine > wrote: > >> I am starting a project that will use clang. I'm asking to be pointed >> in the right direction with a question I have. Here goes. >> >> Given a context (ie a source file) and a statement somewhere in that >> file, what's the easiest way to find the return type of that >> statement >> with clang? >> >> For example, for an assignment, it's the type of the variable, for a >> function call, it's the return type, but obviously there are more >> complicated examples in C semantics. >> >> Surely, clang must be aware of this information, so what's the >> easiest >> way to get at it (using code)? >> >> -Alexei Svitkine >> _______________________________________________ >> 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 alexei.svitkine at gmail.com Mon Jan 5 20:31:02 2009 From: alexei.svitkine at gmail.com (Alexei Svitkine) Date: Mon, 5 Jan 2009 21:31:02 -0500 Subject: [cfe-dev] Return type of statement In-Reply-To: References: <62d9ffc00901051743l506d870fs1217dd92c70553dd@mail.gmail.com> Message-ID: <62d9ffc00901051831v5217f260yae95a9694043188b@mail.gmail.com> Thanks for the pointers. What's the best way to map from a location in the source to the corresponding Stmt (and hence Expr if it is exists)? -Alexei On Mon, Jan 5, 2009 at 9:22 PM, Chris Lattner wrote: > > On Jan 5, 2009, at 6:10 PM, Ted Kremenek wrote: > >> Alexei, >> >> Statements that evalute to a value are known as expressions. >> Expressions are represented by the Expr class (which subclasses >> Stmt). The method Expr::getType() will return the information you >> want. I recommend looking at the Clang sources for example uses of >> this method. > > Try something like: > > Stmt *S = ... > > if (Expr *E = dyn_cast(S)) > if (E->getType() == ... ) > ... > > If something is a statement but not an expr, it doesn't produce a value > (things like "if" or "break"). > > -Chris > >> >> >> On Jan 5, 2009, at 5:43 PM, Alexei Svitkine >> wrote: >> >>> I am starting a project that will use clang. I'm asking to be pointed >>> in the right direction with a question I have. Here goes. >>> >>> Given a context (ie a source file) and a statement somewhere in that >>> file, what's the easiest way to find the return type of that statement >>> with clang? >>> >>> For example, for an assignment, it's the type of the variable, for a >>> function call, it's the return type, but obviously there are more >>> complicated examples in C semantics. >>> >>> Surely, clang must be aware of this information, so what's the easiest >>> way to get at it (using code)? >>> >>> -Alexei Svitkine >>> _______________________________________________ >>> 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 mrs at apple.com Mon Jan 5 20:31:33 2009 From: mrs at apple.com (Mike Stump) Date: Mon, 5 Jan 2009 18:31:33 -0800 Subject: [cfe-dev] build failure? Message-ID: <5D349B9F-58B1-48C2-B266-751758425D84@apple.com> Here is a cute one: llvm[1]: Compiling CacheTokens.cpp for Debug build /Volumes/mrs5/net/llvm/llvm/tools/clang/Driver/../include/clang/Basic/ SourceManager.h: In function ?void clang::CacheTokens (clang::Preprocessor&, const std::string&)?: /Volumes/mrs5/net/llvm/llvm/tools/clang/Driver/../include/clang/Basic/ SourceManager.h:54: error: ?const llvm::MemoryBuffer* clang::SrcMgr::ContentCache::Buffer? is private CacheTokens.cpp:350: error: within this context make[1]: *** [/Volumes/mrs5/net/llvm/llvm-build/tools/clang/Driver/ Debug/CacheTokens.o] Error 1 From xuzhongxing at gmail.com Mon Jan 5 20:42:36 2009 From: xuzhongxing at gmail.com (Zhongxing Xu) Date: Tue, 6 Jan 2009 10:42:36 +0800 Subject: [cfe-dev] [PATCH] Extend the use of DeclGroup In-Reply-To: <5400aeb80901051627y198b39e7vcb195f148487485f@mail.gmail.com> References: <5400aeb80901040110n64165b8ctf369fa3985b7ace@mail.gmail.com> <5400aeb80901051627y198b39e7vcb195f148487485f@mail.gmail.com> Message-ID: <5400aeb80901051842s672db16fpbaed02e0cdc033a0@mail.gmail.com> New patch due to the changes in r61735. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090106/2e601a70/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: dg.patch Type: application/octet-stream Size: 33423 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090106/2e601a70/attachment-0001.obj From clattner at apple.com Mon Jan 5 22:21:47 2009 From: clattner at apple.com (Chris Lattner) Date: Mon, 5 Jan 2009 20:21:47 -0800 Subject: [cfe-dev] Return type of statement In-Reply-To: <62d9ffc00901051831v5217f260yae95a9694043188b@mail.gmail.com> References: <62d9ffc00901051743l506d870fs1217dd92c70553dd@mail.gmail.com> <62d9ffc00901051831v5217f260yae95a9694043188b@mail.gmail.com> Message-ID: <9E891E8E-0D1C-49C0-B8F4-1C3712E81034@apple.com> On Jan 5, 2009, at 6:31 PM, Alexei Svitkine wrote: > Thanks for the pointers. > > What's the best way to map from a location in the source to the > corresponding Stmt (and hence Expr if it is exists)? There isn't an efficient way to do it. You'd have to walk the whole function body and look at the source ranges that each stmt covers, stopping at the smallest one that covers the point of interest. You could do this once and build a location -> stmt mapping of course. This would be useful if you do repeated queries (such as having a mouse float over code etc). -Chris From clattner at apple.com Tue Jan 6 00:13:17 2009 From: clattner at apple.com (Chris Lattner) Date: Mon, 5 Jan 2009 22:13:17 -0800 Subject: [cfe-dev] annotation token documentation Message-ID: After my little fun hacking on annotation tokens, I decided to write up some documentation so that I'd remember how they work the next time around: http://clang.llvm.org/docs/InternalsManual.html#AnnotationToken Argiris, I've come around to being a true believer in the approach, I think it is very nifty. I have a couple of concerns about the current implementation though: first it looks like the template-id handling code is not really complete. I added some FIXME's to the documentation above, I assume that the implementation is just in progress. I'd appreciate it if someone clueful could review the doc. Second, I think it would be interesting to consider handling the "negative" case (when an identifier is not a type) by turning the identifier into an annotation token as well, representing the variable it resolves to (which could be null if it refers to nothing). Right now, if we see an identifier in the token stream, we don't know if that means it is unresolved or whether it means that it is a variable and backtracking already analyzed but did not change it. Argiris, do you think it would make sense to make a new annot_variable that contains a (potentially null) pointer to a variable decl? Even without backtracking, this would reduce name lookups in C: right now we try to decide if something is a type (which requires a lookup) then decide its not, so we handle it as a variable (requiring another lookup). Specifically, things like: int x = sizeof(x); first call Sema::isTypeName then call Sema::LookupDecl. If the parser just called a "lookup the decl for this identifier" method, it could annotate it once and avoid the second lookup. -Chris From dgregor at apple.com Tue Jan 6 00:35:16 2009 From: dgregor at apple.com (Douglas Gregor) Date: Mon, 5 Jan 2009 22:35:16 -0800 Subject: [cfe-dev] annotation token documentation In-Reply-To: References: Message-ID: On Jan 5, 2009, at 10:13 PM, Chris Lattner wrote: > After my little fun hacking on annotation tokens, I decided to write > up some documentation so that I'd remember how they work the next time > around: > http://clang.llvm.org/docs/InternalsManual.html#AnnotationToken > > Argiris, I've come around to being a true believer in the approach, I > think it is very nifty. I have a couple of concerns about the current > implementation though: first it looks like the template-id handling > code is not really complete. The completely-broken template-id handling is my fault. There's a whole bunch of code that needs to get written, but it's relatively low priority (for now). > Second, I think it would be interesting to consider handling the > "negative" case (when an identifier is not a type) by turning the > identifier into an annotation token as well, representing the variable > it resolves to (which could be null if it refers to nothing). Right > now, if we see an identifier in the token stream, we don't know if > that means it is unresolved or whether it means that it is a variable > and backtracking already analyzed but did not change it. This would be great. Right now, we have isTypeName, isCurrentClassName, and isTemplateName, all of which call LookupDecl and then return a single yes or no answer. Some code paths call these routines multiple times. We'd be better off with a "what does this identifier?" action that tells us what we're looking at... and then we can store that information in an annotation token. One thing we have to be careful of is that a given identifier can be looked up in different ways in different contexts, so we have to know when to throw away the results of a previous lookup. For example, and identifier 'x' prior to a '::' is looked up differently that 'x' if it is followed by something else. - Doug From clattner at apple.com Tue Jan 6 00:52:21 2009 From: clattner at apple.com (Chris Lattner) Date: Mon, 5 Jan 2009 22:52:21 -0800 Subject: [cfe-dev] annotation token documentation In-Reply-To: References: Message-ID: <6B6A8644-A5A8-4A5B-A43C-0EB8DD0B8BF4@apple.com> On Jan 5, 2009, at 10:35 PM, Douglas Gregor wrote: >> Argiris, I've come around to being a true believer in the approach, I >> think it is very nifty. I have a couple of concerns about the >> current >> implementation though: first it looks like the template-id handling >> code is not really complete. > > The completely-broken template-id handling is my fault. There's a > whole bunch of code that needs to get written, but it's relatively > low priority (for now). Ah ok. I'm completely fine with it being broken for now, can you please review the comments I added to the internals doc and update if they are wrong? >> Second, I think it would be interesting to consider handling the >> "negative" case (when an identifier is not a type) by turning the >> identifier into an annotation token as well, representing the >> variable >> it resolves to (which could be null if it refers to nothing). Right >> now, if we see an identifier in the token stream, we don't know if >> that means it is unresolved or whether it means that it is a variable >> and backtracking already analyzed but did not change it. > > > This would be great. Right now, we have isTypeName, > isCurrentClassName, and isTemplateName, all of which call LookupDecl > and then return a single yes or no answer. Some code paths call > these routines multiple times. We'd be better off with a "what does > this identifier?" action that tells us what we're looking at... and > then we can store that information in an annotation token. Cool, I completely agree. > One thing we have to be careful of is that a given identifier can be > looked up in different ways in different contexts, so we have to > know when to throw away the results of a previous lookup. For > example, and identifier 'x' prior to a '::' is looked up differently > that 'x' if it is followed by something else. Is this a purely lexical thing? Can backtracking change the decision about what form a token is? The current code does a pretty good job (afaik) handling a different than a::b using lookahead for example, is this sufficient or are there other crazy cases beyond what we're already handling? -Chris From akyrtzi at gmail.com Wed Jan 7 00:47:06 2009 From: akyrtzi at gmail.com (Argiris Kirtzidis) Date: Tue, 06 Jan 2009 22:47:06 -0800 Subject: [cfe-dev] annotation token documentation In-Reply-To: <6B6A8644-A5A8-4A5B-A43C-0EB8DD0B8BF4@apple.com> References: <6B6A8644-A5A8-4A5B-A43C-0EB8DD0B8BF4@apple.com> Message-ID: <49644FEA.7070107@gmail.com> Hi Chris & Doug, Chris Lattner wrote: > After my little fun hacking on annotation tokens, I decided to write > up some documentation so that I'd remember how they work the next time > around: > http://clang.llvm.org/docs/InternalsManual.html#AnnotationToken Thanks a lot for documenting it! > > Second, I think it would be interesting to consider handling the > "negative" case (when an identifier is not a type) by turning the > identifier into an annotation token as well, representing the variable > it resolves to (which could be null if it refers to nothing). Right > now, if we see an identifier in the token stream, we don't know if > that means it is unresolved or whether it means that it is a variable > and backtracking already analyzed but did not change it. > > Argiris, do you think it would make sense to make a new annot_variable > that contains a (potentially null) pointer to a variable decl? Even > without backtracking, this would reduce name lookups in C: right now > we try to decide if something is a type (which requires a lookup) then > decide its not, so we handle it as a variable (requiring another > lookup). Specifically, things like: > > int x = sizeof(x); > > first call Sema::isTypeName then call Sema::LookupDecl. If the parser > just called a "lookup the decl for this identifier" method, it could > annotate it once and avoid the second lookup. This would work really well in combination with the suggestion by Doug about unifying the "identifier inquiring" methods in the Actions API. Something like "LookupIdentifier" which returns an enum describing it and optionally returning a void* through an out parameter ? Douglas Gregor wrote: > On Jan 5, 2009, at 10:13 PM, Chris Lattner wrote: > > > One thing we have to be careful of is that a given identifier can be > looked up in different ways in different contexts, so we have to know > when to throw away the results of a previous lookup. For example, and > identifier 'x' prior to a '::' is looked up differently that 'x' if it > is followed by something else. > > AFAIK an identifier followed by a '::' would always be looked up in a different context (using ActOnCXXNestedNameSpecifier) so there wouldn't be a need to change a previous annotation. -Argiris From dgregor at apple.com Tue Jan 6 10:14:43 2009 From: dgregor at apple.com (Douglas Gregor) Date: Tue, 6 Jan 2009 08:14:43 -0800 Subject: [cfe-dev] annotation token documentation In-Reply-To: <49644FEA.7070107@gmail.com> References: <6B6A8644-A5A8-4A5B-A43C-0EB8DD0B8BF4@apple.com> <49644FEA.7070107@gmail.com> Message-ID: <88927B26-DF8E-4AB6-B75F-6EB9DAF42126@apple.com> Hi Argiris, On Jan 6, 2009, at 10:47 PM, Argiris Kirtzidis wrote: > Hi Chris & Doug, > > Chris Lattner wrote: >> After my little fun hacking on annotation tokens, I decided to >> write up some documentation so that I'd remember how they work the >> next time around: >> http://clang.llvm.org/docs/InternalsManual.html#AnnotationToken > > Thanks a lot for documenting it! > >> >> Second, I think it would be interesting to consider handling the >> "negative" case (when an identifier is not a type) by turning the >> identifier into an annotation token as well, representing the >> variable it resolves to (which could be null if it refers to >> nothing). Right now, if we see an identifier in the token stream, >> we don't know if that means it is unresolved or whether it means >> that it is a variable and backtracking already analyzed but did not >> change it. >> >> Argiris, do you think it would make sense to make a new >> annot_variable that contains a (potentially null) pointer to a >> variable decl? Even without backtracking, this would reduce name >> lookups in C: right now we try to decide if something is a type >> (which requires a lookup) then decide its not, so we handle it as a >> variable (requiring another lookup). Specifically, things like: >> >> int x = sizeof(x); >> >> first call Sema::isTypeName then call Sema::LookupDecl. If the >> parser just called a "lookup the decl for this identifier" method, >> it could annotate it once and avoid the second lookup. > > This would work really well in combination with the suggestion by > Doug about unifying the "identifier inquiring" methods in the > Actions API. Something like "LookupIdentifier" which returns an enum > describing it and optionally returning a void* through an out > parameter ? Yep, that's what I had in mind. The name could be (at least) a type, an object/function, a type template, a function template, the current class name (which is also a type), or the current class template name (which is also both a type and a type template). > > > Douglas Gregor wrote: >> On Jan 5, 2009, at 10:13 PM, Chris Lattner wrote: >> >> One thing we have to be careful of is that a given identifier can >> be looked up in different ways in different contexts, so we have >> to know when to throw away the results of a previous lookup. For >> example, and identifier 'x' prior to a '::' is looked up >> differently that 'x' if it is followed by something else. >> >> > > AFAIK an identifier followed by a '::' would always be looked up in > a different context (using ActOnCXXNestedNameSpecifier) so there > wouldn't be a need to change a previous annotation. Okay. - Doug From piotr.rak at gmail.com Tue Jan 6 13:20:14 2009 From: piotr.rak at gmail.com (Piotr Rak) Date: Tue, 6 Jan 2009 20:20:14 +0100 Subject: [cfe-dev] Fwd: [cfe-commits] r61797 - /cfe/trunk/include/clang/AST/DeclBase.h In-Reply-To: <7925cd330901061119t77aa45cbx12580e9a4bf5e48f@mail.gmail.com> References: <200901060716.n067GfwI025333@zion.cs.uiuc.edu> <7925cd330901061119t77aa45cbx12580e9a4bf5e48f@mail.gmail.com> Message-ID: <7925cd330901061120g186e6cecpeb6962056422b2a@mail.gmail.com> ---------- Forwarded message ---------- From: Piotr Rak Date: 2009/1/6 Subject: Re: [cfe-commits] r61797 - /cfe/trunk/include/clang/AST/DeclBase.h To: Chris Lattner Hi, 2009/1/6 Chris Lattner : > Author: lattner > Date: Tue Jan 6 01:16:40 2009 > New Revision: 61797 > > URL: http://llvm.org/viewvc/llvm-project?rev=61797&view=rev > Log: > add a helper method. > > Modified: > cfe/trunk/include/clang/AST/DeclBase.h > > Modified: cfe/trunk/include/clang/AST/DeclBase.h > URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclBase.h?rev=61797&r1=61796&r2=61797&view=diff > > > + bool isInIdentifierNamespace(unsigned NS) const { > + return getIdentifierNamespace() & NS; > + } > + > // getBody - If this Decl represents a declaration for a body of code, > // such as a function or method definition, this method returns the top-level > // Stmt* of that body. Otherwise this method returns null. > This is fine, however we will have to check more and more conditions in LookupDecl, and it will get more arguemnts. How about passing predicate object to LookupDecl + some Sema methods creating predicates for most common cases? Piotr From alexei.svitkine at gmail.com Tue Jan 6 14:36:50 2009 From: alexei.svitkine at gmail.com (Alexei Svitkine) Date: Tue, 6 Jan 2009 15:36:50 -0500 Subject: [cfe-dev] Return type of statement In-Reply-To: <9E891E8E-0D1C-49C0-B8F4-1C3712E81034@apple.com> References: <62d9ffc00901051743l506d870fs1217dd92c70553dd@mail.gmail.com> <62d9ffc00901051831v5217f260yae95a9694043188b@mail.gmail.com> <9E891E8E-0D1C-49C0-B8F4-1C3712E81034@apple.com> Message-ID: <62d9ffc00901061236l5d28782fx960910423c83a4c9@mail.gmail.com> Thanks for info. I'm now getting a crash in getAsString() on the Expr's type: if (clang::Expr *E = dyn_cast(S)) { std::cout << "Type: '" << E->getType().getAsString() << "'\n"; } GDB prints: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0xc000000f 0x00072d8a in clang::QualType::getAsStringInternal (this=0xbffff758, S=@0xbffff754) at Type.cpp:894 894 getTypePtr()->getAsStringInternal(S); (gdb) bt #0 0x00072d8a in clang::QualType::getAsStringInternal (this=0xbffff758, S=@0xbffff754) at Type.cpp:894 #1 0x000050a8 in clang::QualType::getAsString (this=0xbffff758) at Type.h:168 Am I doing something wrong, or is this a bug I stumbled upon? Also, is there some better way to ask questions I encounter, rather than emailing each one? Like some kind of irc chat? (I joined #llvm but there didn't seem to be any clang discussion going on there...) Or is bombarding this list with questions the way to go? :P -Alexei On Mon, Jan 5, 2009 at 11:21 PM, Chris Lattner wrote: > > On Jan 5, 2009, at 6:31 PM, Alexei Svitkine wrote: > >> Thanks for the pointers. >> >> What's the best way to map from a location in the source to the >> corresponding Stmt (and hence Expr if it is exists)? > > There isn't an efficient way to do it. You'd have to walk the whole > function body and look at the source ranges that each stmt covers, stopping > at the smallest one that covers the point of interest. You could do this > once and build a location -> stmt mapping of course. This would be useful > if you do repeated queries (such as having a mouse float over code etc). > > -Chris > From snaroff at apple.com Tue Jan 6 15:50:24 2009 From: snaroff at apple.com (steve naroff) Date: Tue, 6 Jan 2009 16:50:24 -0500 Subject: [cfe-dev] Return type of statement In-Reply-To: <62d9ffc00901061236l5d28782fx960910423c83a4c9@mail.gmail.com> References: <62d9ffc00901051743l506d870fs1217dd92c70553dd@mail.gmail.com> <62d9ffc00901051831v5217f260yae95a9694043188b@mail.gmail.com> <9E891E8E-0D1C-49C0-B8F4-1C3712E81034@apple.com> <62d9ffc00901061236l5d28782fx960910423c83a4c9@mail.gmail.com> Message-ID: On Jan 6, 2009, at 3:36 PM, Alexei Svitkine wrote: > Thanks for info. > > I'm now getting a crash in getAsString() on the Expr's type: > > if (clang::Expr *E = dyn_cast(S)) { > std::cout << "Type: '" << E->getType().getAsString() << "'\n"; > } > > GDB prints: > > Program received signal EXC_BAD_ACCESS, Could not access memory. > Reason: KERN_INVALID_ADDRESS at address: 0xc000000f > 0x00072d8a in clang::QualType::getAsStringInternal (this=0xbffff758, > S=@0xbffff754) at Type.cpp:894 > 894 getTypePtr()->getAsStringInternal(S); > (gdb) bt > #0 0x00072d8a in clang::QualType::getAsStringInternal > (this=0xbffff758, S=@0xbffff754) at Type.cpp:894 > #1 0x000050a8 in clang::QualType::getAsString (this=0xbffff758) at > Type.h:168 > > Am I doing something wrong, or is this a bug I stumbled upon? > Hi Alexei, It's hard to say without seeing the code being analyzed. The ObjC rewriter uses the "getAsString()" API fairly extensively (so if there's a bug, it's not easy to diagnose without seeing the source). > Also, is there some better way to ask questions I encounter, rather > than emailing each one? Like some kind of irc chat? (I joined #llvm > but there didn't seem to be any clang discussion going on there...) > I'm not aware of any public IRC chat for clang. I believe the llvm IRC is fine for clang related stuff. In this case, however, email works fine. You could also submit a bugzilla. snaroff > Or is bombarding this list with questions the way to go? :P > -Alexei > > On Mon, Jan 5, 2009 at 11:21 PM, Chris Lattner > wrote: >> >> On Jan 5, 2009, at 6:31 PM, Alexei Svitkine wrote: >> >>> Thanks for the pointers. >>> >>> What's the best way to map from a location in the source to the >>> corresponding Stmt (and hence Expr if it is exists)? >> >> There isn't an efficient way to do it. You'd have to walk the whole >> function body and look at the source ranges that each stmt covers, >> stopping >> at the smallest one that covers the point of interest. You could >> do this >> once and build a location -> stmt mapping of course. This would be >> useful >> if you do repeated queries (such as having a mouse float over code >> etc). >> >> -Chris >> > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From clattner at apple.com Tue Jan 6 15:54:57 2009 From: clattner at apple.com (Chris Lattner) Date: Tue, 6 Jan 2009 13:54:57 -0800 Subject: [cfe-dev] Fwd: [cfe-commits] r61797 - /cfe/trunk/include/clang/AST/DeclBase.h In-Reply-To: <7925cd330901061120g186e6cecpeb6962056422b2a@mail.gmail.com> References: <200901060716.n067GfwI025333@zion.cs.uiuc.edu> <7925cd330901061119t77aa45cbx12580e9a4bf5e48f@mail.gmail.com> <7925cd330901061120g186e6cecpeb6962056422b2a@mail.gmail.com> Message-ID: <2D7FE3D4-FE8F-4CBE-BC6C-CC3320146CA5@apple.com> On Jan 6, 2009, at 11:20 AM, Piotr Rak wrote: >> >> + bool isInIdentifierNamespace(unsigned NS) const { >> + return getIdentifierNamespace() & NS; >> + } >> + >> // getBody - If this Decl represents a declaration for a body of >> code, >> // such as a function or method definition, this method returns >> the top-level >> // Stmt* of that body. Otherwise this method returns null. >> > > This is fine, however we will have to check more and more conditions > in LookupDecl, and it will get more arguemnts. How about passing > predicate object to LookupDecl + some Sema methods creating predicates > for most common cases? Are you asking about this patch or lookup decl in particular? I also agree that having tons of different flags on lookupdecl is suboptimal. Instead of having lots of bools, it would be better to use |'d together enums. It's easier to tell what LookupDecl(..., LD_NameSpaceOnly|LD_FOOBar) does than LookupDecl(..., true, false, false, true). -Chris From alexei.svitkine at gmail.com Tue Jan 6 17:59:14 2009 From: alexei.svitkine at gmail.com (Alexei Svitkine) Date: Tue, 6 Jan 2009 18:59:14 -0500 Subject: [cfe-dev] Return type of statement In-Reply-To: References: <62d9ffc00901051743l506d870fs1217dd92c70553dd@mail.gmail.com> <62d9ffc00901051831v5217f260yae95a9694043188b@mail.gmail.com> <9E891E8E-0D1C-49C0-B8F4-1C3712E81034@apple.com> <62d9ffc00901061236l5d28782fx960910423c83a4c9@mail.gmail.com> Message-ID: <62d9ffc00901061559o67eeb9cdo84825eb554e61a78@mail.gmail.com> Oops, this meant to be a reply to all: I'm attaching a sample program that demonstrates the issue. The program is not trying to parse anything complicated... only: int main(void){int i=0;i+=10;return 0;} And trying to get the type of "i+=10". However, as I've mentioned, it instead crashes when calling E->getType().getAsString(). But as Steve pointed out to me, using clang on the command line with ast-print and -ast-dump on that little program works correctly, and apparently that option does end up calling getAsString(). So I'm wondering if I'm using the API incorrectly in some way... can anyone glance over my code and possibly give me a hint of what I'm doing differently than how ast-print/ast-dump works that would cause such a crash? -Alexei On Tue, Jan 6, 2009 at 4:50 PM, steve naroff wrote: > > On Jan 6, 2009, at 3:36 PM, Alexei Svitkine wrote: > >> Thanks for info. >> >> I'm now getting a crash in getAsString() on the Expr's type: >> >> if (clang::Expr *E = dyn_cast(S)) { >> std::cout << "Type: '" << E->getType().getAsString() << "'\n"; >> } >> >> GDB prints: >> >> Program received signal EXC_BAD_ACCESS, Could not access memory. >> Reason: KERN_INVALID_ADDRESS at address: 0xc000000f >> 0x00072d8a in clang::QualType::getAsStringInternal (this=0xbffff758, >> S=@0xbffff754) at Type.cpp:894 >> 894 getTypePtr()->getAsStringInternal(S); >> (gdb) bt >> #0 0x00072d8a in clang::QualType::getAsStringInternal >> (this=0xbffff758, S=@0xbffff754) at Type.cpp:894 >> #1 0x000050a8 in clang::QualType::getAsString (this=0xbffff758) at >> Type.h:168 >> >> Am I doing something wrong, or is this a bug I stumbled upon? >> > > Hi Alexei, > > It's hard to say without seeing the code being analyzed. > > The ObjC rewriter uses the "getAsString()" API fairly extensively (so if > there's a bug, it's not easy to diagnose without seeing the source). > >> Also, is there some better way to ask questions I encounter, rather >> than emailing each one? Like some kind of irc chat? (I joined #llvm >> but there didn't seem to be any clang discussion going on there...) >> > > I'm not aware of any public IRC chat for clang. I believe the llvm IRC is > fine for clang related stuff. In this case, however, email works fine. You > could also submit a bugzilla. > > snaroff > >> Or is bombarding this list with questions the way to go? :P > > >> -Alexei >> >> On Mon, Jan 5, 2009 at 11:21 PM, Chris Lattner wrote: >>> >>> On Jan 5, 2009, at 6:31 PM, Alexei Svitkine wrote: >>> >>>> Thanks for the pointers. >>>> >>>> What's the best way to map from a location in the source to the >>>> corresponding Stmt (and hence Expr if it is exists)? >>> >>> There isn't an efficient way to do it. You'd have to walk the whole >>> function body and look at the source ranges that each stmt covers, >>> stopping >>> at the smallest one that covers the point of interest. You could do this >>> once and build a location -> stmt mapping of course. This would be >>> useful >>> if you do repeated queries (such as having a mouse float over code etc). >>> >>> -Chris >>> >> _______________________________________________ >> cfe-dev mailing list >> cfe-dev at cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > > progr -------------- next part -------------- A non-text attachment was scrubbed... Name: test2.cpp Type: application/octet-stream Size: 2577 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090106/a687ccc2/attachment.obj From kremenek at apple.com Tue Jan 6 18:29:00 2009 From: kremenek at apple.com (Ted Kremenek) Date: Tue, 6 Jan 2009 16:29:00 -0800 Subject: [cfe-dev] Return type of statement In-Reply-To: <62d9ffc00901061559o67eeb9cdo84825eb554e61a78@mail.gmail.com> References: <62d9ffc00901051743l506d870fs1217dd92c70553dd@mail.gmail.com> <62d9ffc00901051831v5217f260yae95a9694043188b@mail.gmail.com> <9E891E8E-0D1C-49C0-B8F4-1C3712E81034@apple.com> <62d9ffc00901061236l5d28782fx960910423c83a4c9@mail.gmail.com> <62d9ffc00901061559o67eeb9cdo84825eb554e61a78@mail.gmail.com> Message-ID: You're using freed memory. Change: clang::ParseAST(pp, &consumer); to: clang::ParseAST(pp, &consumer, false, false); This will disable ParseAST from destroying the ASTContext object (which includes the Types) and the statements when it completes. With this change I see the following output from your program: Type: 'int' On Jan 6, 2009, at 3:59 PM, Alexei Svitkine wrote: > Oops, this meant to be a reply to all: > > I'm attaching a sample program that demonstrates the issue. > > The program is not trying to parse anything complicated... only: > > int main(void){int i=0;i+=10;return 0;} > > And trying to get the type of "i+=10". However, as I've mentioned, it > instead crashes when calling E->getType().getAsString(). > > But as Steve pointed out to me, using clang on the command line with > ast-print and -ast-dump on that little program works correctly, and > apparently that option does end up calling getAsString(). > > So I'm wondering if I'm using the API incorrectly in some way... can > anyone glance over my code and possibly give me a hint of what I'm > doing differently than how ast-print/ast-dump works that would cause > such a crash? > > -Alexei > > On Tue, Jan 6, 2009 at 4:50 PM, steve naroff > wrote: >> >> On Jan 6, 2009, at 3:36 PM, Alexei Svitkine wrote: >> >>> Thanks for info. >>> >>> I'm now getting a crash in getAsString() on the Expr's type: >>> >>> if (clang::Expr *E = dyn_cast(S)) { >>> std::cout << "Type: '" << E->getType().getAsString() << "'\n"; >>> } >>> >>> GDB prints: >>> >>> Program received signal EXC_BAD_ACCESS, Could not access memory. >>> Reason: KERN_INVALID_ADDRESS at address: 0xc000000f >>> 0x00072d8a in clang::QualType::getAsStringInternal (this=0xbffff758, >>> S=@0xbffff754) at Type.cpp:894 >>> 894 getTypePtr()->getAsStringInternal(S); >>> (gdb) bt >>> #0 0x00072d8a in clang::QualType::getAsStringInternal >>> (this=0xbffff758, S=@0xbffff754) at Type.cpp:894 >>> #1 0x000050a8 in clang::QualType::getAsString (this=0xbffff758) at >>> Type.h:168 >>> >>> Am I doing something wrong, or is this a bug I stumbled upon? >>> >> >> Hi Alexei, >> >> It's hard to say without seeing the code being analyzed. >> >> The ObjC rewriter uses the "getAsString()" API fairly extensively >> (so if >> there's a bug, it's not easy to diagnose without seeing the source). >> >>> Also, is there some better way to ask questions I encounter, rather >>> than emailing each one? Like some kind of irc chat? (I joined #llvm >>> but there didn't seem to be any clang discussion going on there...) >>> >> >> I'm not aware of any public IRC chat for clang. I believe the llvm >> IRC is >> fine for clang related stuff. In this case, however, email works >> fine. You >> could also submit a bugzilla. >> >> snaroff >> >>> Or is bombarding this list with questions the way to go? :P >> >> >>> -Alexei >>> >>> On Mon, Jan 5, 2009 at 11:21 PM, Chris Lattner >>> wrote: >>>> >>>> On Jan 5, 2009, at 6:31 PM, Alexei Svitkine wrote: >>>> >>>>> Thanks for the pointers. >>>>> >>>>> What's the best way to map from a location in the source to the >>>>> corresponding Stmt (and hence Expr if it is exists)? >>>> >>>> There isn't an efficient way to do it. You'd have to walk the >>>> whole >>>> function body and look at the source ranges that each stmt covers, >>>> stopping >>>> at the smallest one that covers the point of interest. You could >>>> do this >>>> once and build a location -> stmt mapping of course. This would be >>>> useful >>>> if you do repeated queries (such as having a mouse float over >>>> code etc). >>>> >>>> -Chris >>>> >>> _______________________________________________ >>> cfe-dev mailing list >>> cfe-dev at cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev >> >> > > progr > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From dgregor at apple.com Tue Jan 6 20:33:22 2009 From: dgregor at apple.com (Douglas Gregor) Date: Tue, 6 Jan 2009 18:33:22 -0800 Subject: [cfe-dev] [PATCH] Extend the use of DeclGroup In-Reply-To: <5400aeb80901040110n64165b8ctf369fa3985b7ace@mail.gmail.com> References: <5400aeb80901040110n64165b8ctf369fa3985b7ace@mail.gmail.com> Message-ID: <350421A4-D7C1-4111-9CD9-725C204DA1B6@apple.com> Hello Zhongxing, Thanks for looking into this. I'm looking at your latest patch, but I'm replying to your original message because I want to discuss a few of the issues surrounding decl ownership. It's an area that's in flux right now, and in some sense the DeclContext work I've been doing is clashing with DeclGroups. On Jan 4, 2009, at 1:10 AM, Zhongxing Xu wrote: > This patch is the first step to solve the problem that no one is > owning the > struct decl in the following code: > > typedef struct s {} s_t; The result that struct s { } isn't really owned here is because, at present, we have two entities in the AST that are trying to own the declarations in the translation unit, TranslationUnit and TranslationUnitDecl, and the one that currently owns the declarations in the translation unit doesn't know about "struct s { }". With the typedef above, TranslationUnit's TopLevelDecls knows about only "s_t", not "struct s", because TranslationUnit::AddTopLevelDecl only gets called for "top-level" declarations. TranslationUnitDecl, on the other hand, is a DeclContext that knows about all declarations in the scope of the translation unit, including both "struct s" and "s_t". (It has to know about all declarations, because it's used for name lookup). My intent with DeclContexts is that a DeclContext should own all of the declarations within that context. So TranslationUnitDecl (which is a DeclContext) should own both "struct s" and "s_t". The problem, in our current state, is that TranslationUnit also tries to own top-level decls (currently, "s_t" but not "struct s") through its TopLevelDecls member, and DeclGroups try to own declarations in a declaration statement (e.g., "x" and "y" in "void f() { int x, y; }"), leading to this insanely gross hack in the serialization of DeclContexts (see DeclContext::EmitOutRec): bool Owned = ((*D)->getLexicalDeclContext() == this && DeclKind != Decl::TranslationUnit && !isFunctionOrMethod()); What's that's saying is, basically, DeclContext owns its decls except in the cases where we have DeclGroups. That's the clash between the two mechanisms that I mentioned above. I was working toward a solution that would change DeclGroups and TranslationUnit so that they don't own any decls. Instead, DeclContext would handle all of the ownership issues. The benefit of this is that there are many places where we have DeclContexts already managing ownership of their decls (namespaces, classes, linkage specifications, and enumerations come to mind), and all of those places could benefit from having support for DeclGroups to describe the syntax the user wrote. Trying to summarize: I think DeclContext should handle all of the ownership issues, DeclGroups should handle representing the syntax, and I'd like the two to work together. > > Later a TypeSpecifier holding this struct decl will be added to > DeclGroup as > discussed on the mailing list months before. > > The root of changes is at Sema::FinalizeDeclaratorGroup. It returns > DeclGroupOwningRef instead of DeclTy*. A bunch of related methods > now return > DeclGroupOwningRef instead of DeclTy*. > > Top level declarations are DeclGroups instead of Decls. > TranslationUnit > uses a vector of DeclGroupOwningRef to track all Decls. Most of the > dtor of > TranslationUnit is disabled. The cleanup works should be done by the > DeclGroup. Ah, this is the most direct place where we clash. Your patch updates TranslationUnit's vector (TopLevelDecls) to store DeclGroups rather than Decls (which is good), but my plan for DeclContexts was to eliminate TranslationUnit::TopLevelDecls entirely: clients that want to iterate through the declarations in a translation unit would, instead, use TranslationUnitDecl's decls_begin()/decls_end(). My hunch is that what we want is to find a way to iterate through a DeclContext in a way that allows us to see the DeclGroups (or, at least, see the syntactic relationship between "struct s { }" and "s_t"). However, I'd like to hear your thoughts on these ownership and representation issues. - Doug From xuzhongxing at gmail.com Tue Jan 6 21:14:58 2009 From: xuzhongxing at gmail.com (Zhongxing Xu) Date: Wed, 7 Jan 2009 11:14:58 +0800 Subject: [cfe-dev] [PATCH] Extend the use of DeclGroup In-Reply-To: <350421A4-D7C1-4111-9CD9-725C204DA1B6@apple.com> References: <5400aeb80901040110n64165b8ctf369fa3985b7ace@mail.gmail.com> <350421A4-D7C1-4111-9CD9-725C204DA1B6@apple.com> Message-ID: <5400aeb80901061914i4a35a6e8y70f5dddb06afe534@mail.gmail.com> On Wed, Jan 7, 2009 at 10:33 AM, Douglas Gregor wrote: > Hello Zhongxing, > > Thanks for looking into this. I'm looking at your latest patch, but I'm > replying to your original message because I want to discuss a few of the > issues surrounding decl ownership. It's an area that's in flux right now, > and in some sense the DeclContext work I've been doing is clashing with > DeclGroups. > > On Jan 4, 2009, at 1:10 AM, Zhongxing Xu wrote: > > This patch is the first step to solve the problem that no one is owning >> the >> struct decl in the following code: >> >> typedef struct s {} s_t; >> > > The result that struct s { } isn't really owned here is because, at > present, we have two entities in the AST that are trying to own the > declarations in the translation unit, TranslationUnit and > TranslationUnitDecl, and the one that currently owns the declarations in the > translation unit doesn't know about "struct s { }". > > With the typedef above, TranslationUnit's TopLevelDecls knows about only > "s_t", not "struct s", because TranslationUnit::AddTopLevelDecl only gets > called for "top-level" declarations. > > TranslationUnitDecl, on the other hand, is a DeclContext that knows about > all declarations in the scope of the translation unit, including both > "struct s" and "s_t". (It has to know about all declarations, because it's > used for name lookup). > > My intent with DeclContexts is that a DeclContext should own all of the > declarations within that context. So TranslationUnitDecl (which is a > DeclContext) should own both "struct s" and "s_t". The problem, in our > current state, is that TranslationUnit also tries to own top-level decls > (currently, "s_t" but not "struct s") through its TopLevelDecls member, and > DeclGroups try to own declarations in a declaration statement (e.g., "x" and > "y" in "void f() { int x, y; }"), leading to this insanely gross hack in the > serialization of DeclContexts (see DeclContext::EmitOutRec): > > bool Owned = ((*D)->getLexicalDeclContext() == this && > DeclKind != Decl::TranslationUnit && > !isFunctionOrMethod()); > > What's that's saying is, basically, DeclContext owns its decls except in > the cases where we have DeclGroups. That's the clash between the two > mechanisms that I mentioned above. > > I was working toward a solution that would change DeclGroups and > TranslationUnit so that they don't own any decls. Instead, DeclContext would > handle all of the ownership issues. The benefit of this is that there are > many places where we have DeclContexts already managing ownership of their > decls (namespaces, classes, linkage specifications, and enumerations come to > mind), and all of those places could benefit from having support for > DeclGroups to describe the syntax the user wrote. > > Trying to summarize: I think DeclContext should handle all of the ownership > issues, DeclGroups should handle representing the syntax, and I'd like the > two to work together. > > >> Later a TypeSpecifier holding this struct decl will be added to DeclGroup >> as >> discussed on the mailing list months before. >> >> The root of changes is at Sema::FinalizeDeclaratorGroup. It returns >> DeclGroupOwningRef instead of DeclTy*. A bunch of related methods now >> return >> DeclGroupOwningRef instead of DeclTy*. >> >> Top level declarations are DeclGroups instead of Decls. TranslationUnit >> uses a vector of DeclGroupOwningRef to track all Decls. Most of the dtor >> of >> TranslationUnit is disabled. The cleanup works should be done by the >> DeclGroup. >> > > Ah, this is the most direct place where we clash. Your patch updates > TranslationUnit's vector (TopLevelDecls) to store DeclGroups rather than > Decls (which is good), but my plan for DeclContexts was to eliminate > TranslationUnit::TopLevelDecls entirely: clients that want to iterate > through the declarations in a translation unit would, instead, use > TranslationUnitDecl's decls_begin()/decls_end(). > > My hunch is that what we want is to find a way to iterate through a > DeclContext in a way that allows us to see the DeclGroups (or, at least, see > the syntactic relationship between "struct s { }" and "s_t"). However, I'd > like to hear your thoughts on these ownership and representation issues. > > - Doug > Hi Doug, I'll take a deep look at all the DeclContext stuff and mechanism in the following days. But my feeling is that DeclContext should be the ultimate solution to the ownership problem. I'll wait for your progress in this area. On the other hand, as you said, we still need a mechanism to recover the original syntax structure of the source (and more ideally, the layout of the source code). I think the DeclGroup could play that role with the following structure: DeclGroup => TypeSpecifier Decls Instead of owning the decls, the DeclGroup and TypeSpecifier could only refer to the decls with a pointer. Also the TopLevelDecls in TranslationUnit probably could be kept to reflect the code layout? - Zhongxing -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090107/fee2b8d7/attachment.html From dgregor at apple.com Tue Jan 6 22:45:25 2009 From: dgregor at apple.com (Douglas Gregor) Date: Tue, 6 Jan 2009 20:45:25 -0800 Subject: [cfe-dev] [PATCH] Extend the use of DeclGroup In-Reply-To: <5400aeb80901061914i4a35a6e8y70f5dddb06afe534@mail.gmail.com> References: <5400aeb80901040110n64165b8ctf369fa3985b7ace@mail.gmail.com> <350421A4-D7C1-4111-9CD9-725C204DA1B6@apple.com> <5400aeb80901061914i4a35a6e8y70f5dddb06afe534@mail.gmail.com> Message-ID: <92F6E354-C5CA-4C3B-BD95-0000611666FC@apple.com> On Jan 6, 2009, at 7:14 PM, Zhongxing Xu wrote: > On Wed, Jan 7, 2009 at 10:33 AM, Douglas Gregor > wrote: > My hunch is that what we want is to find a way to iterate through a > DeclContext in a way that allows us to see the DeclGroups (or, at > least, see the syntactic relationship between "struct s { }" and > "s_t"). However, I'd like to hear your thoughts on these ownership > and representation issues. > > - Doug > > Hi Doug, > > I'll take a deep look at all the DeclContext stuff and mechanism in > the following days. But my feeling is that DeclContext should be the > ultimate solution to the ownership problem. I'll wait for your > progress in this area. I'll try to get this done sooner rather than later. There is documentation on DeclContexts here: http://clang.llvm.org/docs/InternalsManual.html#DeclContext > > On the other hand, as you said, we still need a mechanism to recover > the original syntax structure of the source (and more ideally, the > layout of the source code). I think the DeclGroup could play that > role with the following structure: > DeclGroup => TypeSpecifier Decls > > Instead of owning the decls, the DeclGroup and TypeSpecifier could > only refer to the decls with a pointer. Yes, I agree. > > Also the TopLevelDecls in TranslationUnit probably could be kept to > reflect the code layout? We shouldn't need it. A DeclContext's list of declarations (accessible via decls_begin/decls_end) contains all of the declarations in the order they occur within the source code, which is the same information that TopLevelDecls tries to capture now. - Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090106/f35e9e9c/attachment.html From xuzhongxing at gmail.com Wed Jan 7 00:09:50 2009 From: xuzhongxing at gmail.com (Zhongxing Xu) Date: Wed, 7 Jan 2009 14:09:50 +0800 Subject: [cfe-dev] [PATCH] Extend the use of DeclGroup In-Reply-To: <92F6E354-C5CA-4C3B-BD95-0000611666FC@apple.com> References: <5400aeb80901040110n64165b8ctf369fa3985b7ace@mail.gmail.com> <350421A4-D7C1-4111-9CD9-725C204DA1B6@apple.com> <5400aeb80901061914i4a35a6e8y70f5dddb06afe534@mail.gmail.com> <92F6E354-C5CA-4C3B-BD95-0000611666FC@apple.com> Message-ID: <5400aeb80901062209u4e35eb33he228323a8acaf0ee@mail.gmail.com> On Wed, Jan 7, 2009 at 12:45 PM, Douglas Gregor wrote: > On Jan 6, 2009, at 7:14 PM, Zhongxing Xu wrote: > > On Wed, Jan 7, 2009 at 10:33 AM, Douglas Gregor wrote: > >> My hunch is that what we want is to find a way to iterate through a >> DeclContext in a way that allows us to see the DeclGroups (or, at least, see >> the syntactic relationship between "struct s { }" and "s_t"). However, I'd >> like to hear your thoughts on these ownership and representation issues. >> >> - Doug >> > > Hi Doug, > > I'll take a deep look at all the DeclContext stuff and mechanism in the > following days. But my feeling is that DeclContext should be the ultimate > solution to the ownership problem. I'll wait for your progress in this area. > > > I'll try to get this done sooner rather than later. There is documentation > on DeclContexts here: > > http://clang.llvm.org/docs/InternalsManual.html#DeclContext > Thanks. > > > > On the other hand, as you said, we still need a mechanism to recover the > original syntax structure of the source (and more ideally, the layout of the > source code). I think the DeclGroup could play that role with the following > structure: > DeclGroup => TypeSpecifier Decls > > Instead of owning the decls, the DeclGroup and TypeSpecifier could only > refer to the decls with a pointer. > > > Yes, I agree. > > > Also the TopLevelDecls in TranslationUnit probably could be kept to reflect > the code layout? > > > We shouldn't need it. A DeclContext's list of declarations (accessible via > decls_begin/decls_end) contains all of the declarations in the order they > occur within the source code, which is the same information that > TopLevelDecls tries to capture now. > OK. > > - Doug > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090107/7c0a9320/attachment-0001.html From sebastian.redl at getdesigned.at Wed Jan 7 08:55:11 2009 From: sebastian.redl at getdesigned.at (Sebastian Redl) Date: Wed, 07 Jan 2009 15:55:11 +0100 Subject: [cfe-dev] rdar URLs Message-ID: I've been wondering for some time: what are the rdar:/problem/... URLs posted every now and then? Is this some internal bug tracker? Is there any way for external developers such as me to access this tracker? Sebastian From snaroff at apple.com Wed Jan 7 09:40:53 2009 From: snaroff at apple.com (steve naroff) Date: Wed, 7 Jan 2009 10:40:53 -0500 Subject: [cfe-dev] rdar URLs In-Reply-To: References: Message-ID: <8C09339D-F47D-4E7F-8421-41C92034624B@apple.com> Radar is Apple's internal bug tracking system. Registered Apple developers have access to some of this data via Apple's Developer Support group. Since clang hasn't been formally released, the ADS channel won't help you. Chris may be able to give us more info... snaroff On Jan 7, 2009, at 9:55 AM, Sebastian Redl wrote: > > I've been wondering for some time: what are the rdar:/problem/... URLs > posted every now and then? Is this some internal bug tracker? Is > there any > way for external developers such as me to access this tracker? > > Sebastian > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From cristian.draghici at gmail.com Wed Jan 7 11:27:09 2009 From: cristian.draghici at gmail.com (Cristian Draghici) Date: Wed, 7 Jan 2009 19:27:09 +0200 Subject: [cfe-dev] report of assertion failure in clang Message-ID: <25cf7a9f0901070927i560d353bkb5ebd5237dbff1f4@mail.gmail.com> Is this a known issue? cristi:tmp diciu$ cat test.c struct v { unsigned int m; void * ref; int z; }; int main() { short buf[1]; buf[0] = 66; struct v st2 = { .ref = buf }; st2.m = 10; short * u = (short *)st2.ref; printf("%d\n", *u); return 0; } cristi:tmp diciu$ ~/Downloads/checker-137/clang -x c test.c -checker-cfref test.c:16:10: warning: incompatible pointer to integer conversion initializing 'short [1]', expected 'unsigned int' .ref = buf ^~~ ANALYZE: test.c main Assertion failed: (T->isPointerType()), function VisitCast, file GRExprEngine.cpp, line 1738. 0 clang 0x00a84582 std::vector >::_M_insert_aux(__gnu_cxx::__normal_iterator > >, llvm::sys::Path const&) + 7746 1 libSystem.B.dylib 0x96edd2bb _sigtramp + 43 2 libSystem.B.dylib 0xffffffff _sigtramp + 1762798959 3 libSystem.B.dylib 0x96f5123a raise + 26 4 libSystem.B.dylib 0x96f5d679 abort + 73 5 libSystem.B.dylib 0x96f523db __assert_rtn + 101 6 clang 0x00311d21 clang::CFGBlock::operator[](unsigned long) const + 77345 7 clang 0x00309458 clang::CFGBlock::operator[](unsigned long) const + 42328 8 clang 0x0030a5a4 clang::CFGBlock::operator[](unsigned long) const + 46756 9 clang 0x00308f6a clang::CFGBlock::operator[](unsigned long) const + 41066 10 clang 0x00314140 clang::CFGBlock::operator[](unsigned long) const + 86592 11 clang 0x0031a741 clang::GRCoreEngine::ProcessStmt(clang::Stmt*, clang::GRStmtNodeBuilderImpl&) + 97 12 clang 0x002fe386 llvm::ImutAVLFactory >::Add_internal(std::pair const&, llvm::ImutAVLTree >*) + 9398 13 clang 0x002fe598 llvm::ImutAVLFactory >::Add_internal(std::pair const&, llvm::ImutAVLTree >*) + 9928 14 clang 0x00008d7c llvm::cast_retty::ret_type llvm::cast(clang::Type* const&) + 9836 15 clang 0x00008638 llvm::cast_retty::ret_type llvm::cast(clang::Type* const&) + 7976 16 clang 0x00008be9 llvm::cast_retty::ret_type llvm::cast(clang::Type* const&) + 9433 17 clang 0x00356d3b clang::OverloadedFunctionDecl::getDeclContext() + 587 18 clang 0x000479f2 clang::TokenRewriter::AddTokenAfter(std::_List_const_iterator, char const*) + 5586 19 clang 0x0004ab34 clang::TokenRewriter::AddTokenAfter(std::_List_const_iterator, char const*) + 18196 20 clang 0x00001936 _mh_execute_header + 2358 Abort trap -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090107/fba96932/attachment.html From snaroff at apple.com Wed Jan 7 11:34:39 2009 From: snaroff at apple.com (steve naroff) Date: Wed, 7 Jan 2009 12:34:39 -0500 Subject: [cfe-dev] report of assertion failure in clang In-Reply-To: <25cf7a9f0901070927i560d353bkb5ebd5237dbff1f4@mail.gmail.com> References: <25cf7a9f0901070927i560d353bkb5ebd5237dbff1f4@mail.gmail.com> Message-ID: <5CDB42D5-C28B-439B-8F2F-4CAE1BAC8CC9@apple.com> Known issue...clang doesn't support initializer lists that use designators (.ref notation below). The code generator is suppose to issue a diagnostic I believe. Daniel? snaroff On Jan 7, 2009, at 12:27 PM, Cristian Draghici wrote: > Is this a known issue? > > cristi:tmp diciu$ cat test.c > > struct v > { > unsigned int m; > void * ref; > int z; > }; > > int main() > { > short buf[1]; > > buf[0] = 66; > > struct v st2 = { > .ref = buf > }; > > st2.m = 10; > > short * u = (short *)st2.ref; > printf("%d\n", *u); > > return 0; > } > > > > cristi:tmp diciu$ ~/Downloads/checker-137/clang -x c test.c - > checker-cfref > test.c:16:10: warning: incompatible pointer to integer conversion > initializing 'short [1]', expected 'unsigned int' > .ref = buf > ^~~ > ANALYZE: test.c main > Assertion failed: (T->isPointerType()), function VisitCast, file > GRExprEngine.cpp, line 1738. > 0 clang 0x00a84582 std::vector std::allocator > >::_M_insert_aux(__gnu_cxx::__normal_iterator std::vector > >, > llvm::sys::Path const&) + 7746 > 1 libSystem.B.dylib 0x96edd2bb _sigtramp + 43 > 2 libSystem.B.dylib 0xffffffff _sigtramp + 1762798959 > 3 libSystem.B.dylib 0x96f5123a raise + 26 > 4 libSystem.B.dylib 0x96f5d679 abort + 73 > 5 libSystem.B.dylib 0x96f523db __assert_rtn + 101 > 6 clang 0x00311d21 clang::CFGBlock::operator[] > (unsigned long) const + 77345 > 7 clang 0x00309458 clang::CFGBlock::operator[] > (unsigned long) const + 42328 > 8 clang 0x0030a5a4 clang::CFGBlock::operator[] > (unsigned long) const + 46756 > 9 clang 0x00308f6a clang::CFGBlock::operator[] > (unsigned long) const + 41066 > 10 clang 0x00314140 clang::CFGBlock::operator[] > (unsigned long) const + 86592 > 11 clang 0x0031a741 > clang::GRCoreEngine::ProcessStmt(clang::Stmt*, > clang::GRStmtNodeBuilderImpl&) + 97 > 12 clang 0x002fe386 > llvm::ImutAVLFactory int> >::Add_internal(std::pair const&, > llvm::ImutAVLTree > >*) + 9398 > 13 clang 0x002fe598 > llvm::ImutAVLFactory int> >::Add_internal(std::pair const&, > llvm::ImutAVLTree > >*) + 9928 > 14 clang 0x00008d7c > llvm::cast_retty::ret_type > llvm::cast(clang::Type* const&) > + 9836 > 15 clang 0x00008638 > llvm::cast_retty::ret_type > llvm::cast(clang::Type* const&) > + 7976 > 16 clang 0x00008be9 > llvm::cast_retty::ret_type > llvm::cast(clang::Type* const&) > + 9433 > 17 clang 0x00356d3b > clang::OverloadedFunctionDecl::getDeclContext() + 587 > 18 clang 0x000479f2 > clang > ::TokenRewriter > ::AddTokenAfter(std::_List_const_iterator, char > const*) + 5586 > 19 clang 0x0004ab34 > clang > ::TokenRewriter > ::AddTokenAfter(std::_List_const_iterator, char > const*) + 18196 > 20 clang 0x00001936 _mh_execute_header + 2358 > Abort trap > > > > > _______________________________________________ > 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/20090107/ab552f0b/attachment-0001.html From daniel at zuster.org Wed Jan 7 12:12:36 2009 From: daniel at zuster.org (Daniel Dunbar) Date: Wed, 7 Jan 2009 10:12:36 -0800 Subject: [cfe-dev] report of assertion failure in clang In-Reply-To: <5CDB42D5-C28B-439B-8F2F-4CAE1BAC8CC9@apple.com> References: <25cf7a9f0901070927i560d353bkb5ebd5237dbff1f4@mail.gmail.com> <5CDB42D5-C28B-439B-8F2F-4CAE1BAC8CC9@apple.com> Message-ID: <6a8523d60901071012t3b33ab32wc4cd0c097d4d50fc@mail.gmail.com> Yes, the root issue here is probably lack of support for designators. However, I don't think the analyzer should be crashing unless we happen to be creating invalid ASTs. Ted? - Daniel On Wed, Jan 7, 2009 at 9:34 AM, steve naroff wrote: > Known issue...clang doesn't support initializer lists that use designators > (.ref notation below). > The code generator is suppose to issue a diagnostic I believe. Daniel? > snaroff > On Jan 7, 2009, at 12:27 PM, Cristian Draghici wrote: > > Is this a known issue? > cristi:tmp diciu$ cat test.c > struct v > { > unsigned int m; > void * ref; > int z; > }; > int main() > { > short buf[1]; > buf[0] = 66; > struct v st2 = { > .ref = buf > }; > st2.m = 10; > short * u = (short *)st2.ref; > printf("%d\n", *u); > return 0; > } > > > cristi:tmp diciu$ ~/Downloads/checker-137/clang -x c test.c -checker-cfref > test.c:16:10: warning: incompatible pointer to integer conversion > initializing 'short [1]', expected 'unsigned int' > .ref = buf > ^~~ > ANALYZE: test.c main > Assertion failed: (T->isPointerType()), function VisitCast, file > GRExprEngine.cpp, line 1738. > 0 clang 0x00a84582 std::vector std::allocator >>::_M_insert_aux(__gnu_cxx::__normal_iterator std::vector > >, > llvm::sys::Path const&) + 7746 > 1 libSystem.B.dylib 0x96edd2bb _sigtramp + 43 > 2 libSystem.B.dylib 0xffffffff _sigtramp + 1762798959 > 3 libSystem.B.dylib 0x96f5123a raise + 26 > 4 libSystem.B.dylib 0x96f5d679 abort + 73 > 5 libSystem.B.dylib 0x96f523db __assert_rtn + 101 > 6 clang 0x00311d21 clang::CFGBlock::operator[](unsigned long) > const + 77345 > 7 clang 0x00309458 clang::CFGBlock::operator[](unsigned long) > const + 42328 > 8 clang 0x0030a5a4 clang::CFGBlock::operator[](unsigned long) > const + 46756 > 9 clang 0x00308f6a clang::CFGBlock::operator[](unsigned long) > const + 41066 > 10 clang 0x00314140 clang::CFGBlock::operator[](unsigned long) > const + 86592 > 11 clang 0x0031a741 > clang::GRCoreEngine::ProcessStmt(clang::Stmt*, > clang::GRStmtNodeBuilderImpl&) + 97 > 12 clang 0x002fe386 > llvm::ImutAVLFactory >>::Add_internal(std::pair const&, > llvm::ImutAVLTree >*) + > 9398 > 13 clang 0x002fe598 > llvm::ImutAVLFactory >>::Add_internal(std::pair const&, > llvm::ImutAVLTree >*) + > 9928 > 14 clang 0x00008d7c llvm::cast_retty clang::Type*>::ret_type llvm::cast clang::Type*>(clang::Type* const&) + 9836 > 15 clang 0x00008638 llvm::cast_retty clang::Type*>::ret_type llvm::cast clang::Type*>(clang::Type* const&) + 7976 > 16 clang 0x00008be9 llvm::cast_retty clang::Type*>::ret_type llvm::cast clang::Type*>(clang::Type* const&) + 9433 > 17 clang 0x00356d3b > clang::OverloadedFunctionDecl::getDeclContext() + 587 > 18 clang 0x000479f2 > clang::TokenRewriter::AddTokenAfter(std::_List_const_iterator, > char const*) + 5586 > 19 clang 0x0004ab34 > clang::TokenRewriter::AddTokenAfter(std::_List_const_iterator, > char const*) + 18196 > 20 clang 0x00001936 _mh_execute_header + 2358 > Abort trap > > > > _______________________________________________ > 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 kremenek at apple.com Wed Jan 7 12:44:40 2009 From: kremenek at apple.com (Ted Kremenek) Date: Wed, 07 Jan 2009 10:44:40 -0800 Subject: [cfe-dev] report of assertion failure in clang In-Reply-To: <25cf7a9f0901070927i560d353bkb5ebd5237dbff1f4@mail.gmail.com> References: <25cf7a9f0901070927i560d353bkb5ebd5237dbff1f4@mail.gmail.com> Message-ID: <4D46D7C1-1059-4186-B805-576B884B3B87@apple.com> That's not a known issue. Please file a Bugzilla report (against the static analyzer) with this test case so we can keep track of it! Thanks! On Jan 7, 2009, at 9:27 AM, Cristian Draghici wrote: > Is this a known issue? > > cristi:tmp diciu$ cat test.c > > struct v > { > unsigned int m; > void * ref; > int z; > }; > > int main() > { > short buf[1]; > > buf[0] = 66; > > struct v st2 = { > .ref = buf > }; > > st2.m = 10; > > short * u = (short *)st2.ref; > printf("%d\n", *u); > > return 0; > } > > > > cristi:tmp diciu$ ~/Downloads/checker-137/clang -x c test.c - > checker-cfref > test.c:16:10: warning: incompatible pointer to integer conversion > initializing 'short [1]', expected 'unsigned int' > .ref = buf > ^~~ > ANALYZE: test.c main > Assertion failed: (T->isPointerType()), function VisitCast, file > GRExprEngine.cpp, line 1738. > 0 clang 0x00a84582 std::vector std::allocator > >::_M_insert_aux(__gnu_cxx::__normal_iterator std::vector > >, > llvm::sys::Path const&) + 7746 > 1 libSystem.B.dylib 0x96edd2bb _sigtramp + 43 > 2 libSystem.B.dylib 0xffffffff _sigtramp + 1762798959 > 3 libSystem.B.dylib 0x96f5123a raise + 26 > 4 libSystem.B.dylib 0x96f5d679 abort + 73 > 5 libSystem.B.dylib 0x96f523db __assert_rtn + 101 > 6 clang 0x00311d21 clang::CFGBlock::operator[] > (unsigned long) const + 77345 > 7 clang 0x00309458 clang::CFGBlock::operator[] > (unsigned long) const + 42328 > 8 clang 0x0030a5a4 clang::CFGBlock::operator[] > (unsigned long) const + 46756 > 9 clang 0x00308f6a clang::CFGBlock::operator[] > (unsigned long) const + 41066 > 10 clang 0x00314140 clang::CFGBlock::operator[] > (unsigned long) const + 86592 > 11 clang 0x0031a741 > clang::GRCoreEngine::ProcessStmt(clang::Stmt*, > clang::GRStmtNodeBuilderImpl&) + 97 > 12 clang 0x002fe386 > llvm::ImutAVLFactory int> >::Add_internal(std::pair const&, > llvm::ImutAVLTree > >*) + 9398 > 13 clang 0x002fe598 > llvm::ImutAVLFactory int> >::Add_internal(std::pair const&, > llvm::ImutAVLTree > >*) + 9928 > 14 clang 0x00008d7c > llvm::cast_retty::ret_type > llvm::cast(clang::Type* const&) > + 9836 > 15 clang 0x00008638 > llvm::cast_retty::ret_type > llvm::cast(clang::Type* const&) > + 7976 > 16 clang 0x00008be9 > llvm::cast_retty::ret_type > llvm::cast(clang::Type* const&) > + 9433 > 17 clang 0x00356d3b > clang::OverloadedFunctionDecl::getDeclContext() + 587 > 18 clang 0x000479f2 > clang: > :TokenRewriter: > :AddTokenAfter(std::_List_const_iterator, char const*) > + 5586 > 19 clang 0x0004ab34 > clang: > :TokenRewriter: > :AddTokenAfter(std::_List_const_iterator, char const*) > + 18196 > 20 clang 0x00001936 _mh_execute_header + 2358 > Abort trap > > > > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From kremenek at apple.com Wed Jan 7 12:50:16 2009 From: kremenek at apple.com (Ted Kremenek) Date: Wed, 07 Jan 2009 10:50:16 -0800 Subject: [cfe-dev] report of assertion failure in clang In-Reply-To: <5CDB42D5-C28B-439B-8F2F-4CAE1BAC8CC9@apple.com> References: <25cf7a9f0901070927i560d353bkb5ebd5237dbff1f4@mail.gmail.com> <5CDB42D5-C28B-439B-8F2F-4CAE1BAC8CC9@apple.com> Message-ID: <7C2325BF-CA9E-4E76-8610-409098D47762@apple.com> The assertion failure is in the static analyzer, which is why I asked Cristian to file a new Bugzilla report. If Clang doesn't reject code with designated initializers then the static analyzer should gracefully fail when it encounters them instead of crash. On Jan 7, 2009, at 9:34 AM, steve naroff wrote: > Known issue...clang doesn't support initializer lists that use > designators (.ref notation below). > > The code generator is suppose to issue a diagnostic I believe. Daniel? > > snaroff > > On Jan 7, 2009, at 12:27 PM, Cristian Draghici wrote: > >> Is this a known issue? >> >> cristi:tmp diciu$ cat test.c >> >> struct v >> { >> unsigned int m; >> void * ref; >> int z; >> }; >> >> int main() >> { >> short buf[1]; >> >> buf[0] = 66; >> >> struct v st2 = { >> .ref = buf >> }; >> >> st2.m = 10; >> >> short * u = (short *)st2.ref; >> printf("%d\n", *u); >> >> return 0; >> } >> >> >> >> cristi:tmp diciu$ ~/Downloads/checker-137/clang -x c test.c - >> checker-cfref >> test.c:16:10: warning: incompatible pointer to integer conversion >> initializing 'short [1]', expected 'unsigned int' >> .ref = buf >> ^~~ >> ANALYZE: test.c main >> Assertion failed: (T->isPointerType()), function VisitCast, file >> GRExprEngine.cpp, line 1738. >> 0 clang 0x00a84582 std::vector> std::allocator >> >::_M_insert_aux(__gnu_cxx::__normal_iterator> std::vector > >, >> llvm::sys::Path const&) + 7746 >> 1 libSystem.B.dylib 0x96edd2bb _sigtramp + 43 >> 2 libSystem.B.dylib 0xffffffff _sigtramp + 1762798959 >> 3 libSystem.B.dylib 0x96f5123a raise + 26 >> 4 libSystem.B.dylib 0x96f5d679 abort + 73 >> 5 libSystem.B.dylib 0x96f523db __assert_rtn + 101 >> 6 clang 0x00311d21 clang::CFGBlock::operator[] >> (unsigned long) const + 77345 >> 7 clang 0x00309458 clang::CFGBlock::operator[] >> (unsigned long) const + 42328 >> 8 clang 0x0030a5a4 clang::CFGBlock::operator[] >> (unsigned long) const + 46756 >> 9 clang 0x00308f6a clang::CFGBlock::operator[] >> (unsigned long) const + 41066 >> 10 clang 0x00314140 clang::CFGBlock::operator[] >> (unsigned long) const + 86592 >> 11 clang 0x0031a741 >> clang::GRCoreEngine::ProcessStmt(clang::Stmt*, >> clang::GRStmtNodeBuilderImpl&) + 97 >> 12 clang 0x002fe386 >> llvm::ImutAVLFactory> int> >::Add_internal(std::pair const&, >> llvm::ImutAVLTree> int> >*) + 9398 >> 13 clang 0x002fe598 >> llvm::ImutAVLFactory> int> >::Add_internal(std::pair const&, >> llvm::ImutAVLTree> int> >*) + 9928 >> 14 clang 0x00008d7c >> llvm::cast_retty::ret_type >> llvm::cast(clang::Type* const&) >> + 9836 >> 15 clang 0x00008638 >> llvm::cast_retty::ret_type >> llvm::cast(clang::Type* const&) >> + 7976 >> 16 clang 0x00008be9 >> llvm::cast_retty::ret_type >> llvm::cast(clang::Type* const&) >> + 9433 >> 17 clang 0x00356d3b >> clang::OverloadedFunctionDecl::getDeclContext() + 587 >> 18 clang 0x000479f2 >> clang: >> :TokenRewriter: >> :AddTokenAfter(std::_List_const_iterator, char >> const*) + 5586 >> 19 clang 0x0004ab34 >> clang: >> :TokenRewriter: >> :AddTokenAfter(std::_List_const_iterator, char >> const*) + 18196 >> 20 clang 0x00001936 _mh_execute_header + 2358 >> Abort trap >> >> >> >> >> _______________________________________________ >> 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/20090107/23020e5d/attachment-0001.html From snaroff at apple.com Wed Jan 7 12:54:40 2009 From: snaroff at apple.com (steve naroff) Date: Wed, 7 Jan 2009 13:54:40 -0500 Subject: [cfe-dev] report of assertion failure in clang In-Reply-To: <7C2325BF-CA9E-4E76-8610-409098D47762@apple.com> References: <25cf7a9f0901070927i560d353bkb5ebd5237dbff1f4@mail.gmail.com> <5CDB42D5-C28B-439B-8F2F-4CAE1BAC8CC9@apple.com> <7C2325BF-CA9E-4E76-8610-409098D47762@apple.com> Message-ID: Sure...I missed the -checker-cfref flag on the command line (should have looked more closely). Sorry for the confusion, snaroff On Jan 7, 2009, at 1:50 PM, Ted Kremenek wrote: > The assertion failure is in the static analyzer, which is why I > asked Cristian to file a new Bugzilla report. If Clang doesn't > reject code with designated initializers then the static analyzer > should gracefully fail when it encounters them instead of crash. > > On Jan 7, 2009, at 9:34 AM, steve naroff wrote: > >> Known issue...clang doesn't support initializer lists that use >> designators (.ref notation below). >> >> The code generator is suppose to issue a diagnostic I believe. >> Daniel? >> >> snaroff >> >> On Jan 7, 2009, at 12:27 PM, Cristian Draghici wrote: >> >>> Is this a known issue? >>> >>> cristi:tmp diciu$ cat test.c >>> >>> struct v >>> { >>> unsigned int m; >>> void * ref; >>> int z; >>> }; >>> >>> int main() >>> { >>> short buf[1]; >>> >>> buf[0] = 66; >>> >>> struct v st2 = { >>> .ref = buf >>> }; >>> >>> st2.m = 10; >>> >>> short * u = (short *)st2.ref; >>> printf("%d\n", *u); >>> >>> return 0; >>> } >>> >>> >>> >>> cristi:tmp diciu$ ~/Downloads/checker-137/clang -x c test.c - >>> checker-cfref >>> test.c:16:10: warning: incompatible pointer to integer conversion >>> initializing 'short [1]', expected 'unsigned int' >>> .ref = buf >>> ^~~ >>> ANALYZE: test.c main >>> Assertion failed: (T->isPointerType()), function VisitCast, file >>> GRExprEngine.cpp, line 1738. >>> 0 clang 0x00a84582 std::vector>> std::allocator >>> >::_M_insert_aux(__gnu_cxx::__normal_iterator>> std::vector > >, >>> llvm::sys::Path const&) + 7746 >>> 1 libSystem.B.dylib 0x96edd2bb _sigtramp + 43 >>> 2 libSystem.B.dylib 0xffffffff _sigtramp + 1762798959 >>> 3 libSystem.B.dylib 0x96f5123a raise + 26 >>> 4 libSystem.B.dylib 0x96f5d679 abort + 73 >>> 5 libSystem.B.dylib 0x96f523db __assert_rtn + 101 >>> 6 clang 0x00311d21 clang::CFGBlock::operator[] >>> (unsigned long) const + 77345 >>> 7 clang 0x00309458 clang::CFGBlock::operator[] >>> (unsigned long) const + 42328 >>> 8 clang 0x0030a5a4 clang::CFGBlock::operator[] >>> (unsigned long) const + 46756 >>> 9 clang 0x00308f6a clang::CFGBlock::operator[] >>> (unsigned long) const + 41066 >>> 10 clang 0x00314140 clang::CFGBlock::operator[] >>> (unsigned long) const + 86592 >>> 11 clang 0x0031a741 >>> clang >>> ::GRCoreEngine::ProcessStmt(clang::Stmt*, >>> clang::GRStmtNodeBuilderImpl&) + 97 >>> 12 clang 0x002fe386 >>> llvm::ImutAVLFactory>> int> >::Add_internal(std::pair const&, >>> llvm::ImutAVLTree>> int> >*) + 9398 >>> 13 clang 0x002fe598 >>> llvm::ImutAVLFactory>> int> >::Add_internal(std::pair const&, >>> llvm::ImutAVLTree>> int> >*) + 9928 >>> 14 clang 0x00008d7c >>> llvm::cast_retty::ret_type >>> llvm::cast(clang::Type* >>> const&) + 9836 >>> 15 clang 0x00008638 >>> llvm::cast_retty::ret_type >>> llvm::cast(clang::Type* >>> const&) + 7976 >>> 16 clang 0x00008be9 >>> llvm::cast_retty::ret_type >>> llvm::cast(clang::Type* >>> const&) + 9433 >>> 17 clang 0x00356d3b >>> clang::OverloadedFunctionDecl::getDeclContext() + 587 >>> 18 clang 0x000479f2 >>> clang >>> ::TokenRewriter >>> ::AddTokenAfter(std::_List_const_iterator, char >>> const*) + 5586 >>> 19 clang 0x0004ab34 >>> clang >>> ::TokenRewriter >>> ::AddTokenAfter(std::_List_const_iterator, char >>> const*) + 18196 >>> 20 clang 0x00001936 _mh_execute_header + 2358 >>> Abort trap >>> >>> >>> >>> >>> _______________________________________________ >>> 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/20090107/1981bb8f/attachment.html From clattner at apple.com Wed Jan 7 15:51:54 2009 From: clattner at apple.com (Chris Lattner) Date: Wed, 7 Jan 2009 13:51:54 -0800 Subject: [cfe-dev] rdar URLs In-Reply-To: <8C09339D-F47D-4E7F-8421-41C92034624B@apple.com> References: <8C09339D-F47D-4E7F-8421-41C92034624B@apple.com> Message-ID: <9F4E2F67-52C0-46ED-994B-2F5F9BD5D24D@apple.com> On Jan 7, 2009, at 7:40 AM, steve naroff wrote: > Radar is Apple's internal bug tracking system. > > Registered Apple developers have access to some of this data via > Apple's Developer Support group. > > Since clang hasn't been formally released, the ADS channel won't help > you. > > Chris may be able to give us more info... I think you can get access to some radars through bugreporter.apple.com, but probably not much. Most of the bugs filed in rdar are not particularly interesting ("foo doesn't work"). If there is a commit that fixes a bug without a testcase, feel free to demand a testcase from the committer :). The rdar:// identifiers are mostly just for interlinking the files, just like bugzilla PR numbers. Amusingly, the llvm-gcc sources are littered with rdar numbers for all the apple local changes, which is pretty useless (IMO) even for people with access to rdar. -Chris > > > snaroff > > On Jan 7, 2009, at 9:55 AM, Sebastian Redl wrote: > >> >> I've been wondering for some time: what are the rdar:/problem/... >> URLs >> posted every now and then? Is this some internal bug tracker? Is >> there any >> way for external developers such as me to access this tracker? >> >> Sebastian >> _______________________________________________ >> 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 xuzhongxing at gmail.com Wed Jan 7 21:26:32 2009 From: xuzhongxing at gmail.com (Zhongxing Xu) Date: Thu, 8 Jan 2009 11:26:32 +0800 Subject: [cfe-dev] EnumConstantDecl is added to EnumDecl twice Message-ID: <5400aeb80901071926p8df1be7o7a4f445d9d44fca1@mail.gmail.com> Hi, Currently every EnumConstantDecl is added to its EnumDecl twice: one at SemaDecl.cpp:3489, the other at SemaDecl.cpp:109. I noticed the comments said that the enumerator is stored in two DeclContexts. Maybe we should change line SemaDecl.cpp:109 : CurContext->addDecl(Context, SD); into: ((DeclContext *)S->getEntity())->addDecl(Context, SD); to make it conform to the comments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090108/9c186eeb/attachment.html From cristian.draghici at gmail.com Thu Jan 8 00:35:30 2009 From: cristian.draghici at gmail.com (Cristian Draghici) Date: Thu, 8 Jan 2009 08:35:30 +0200 Subject: [cfe-dev] report of assertion failure in clang In-Reply-To: References: <25cf7a9f0901070927i560d353bkb5ebd5237dbff1f4@mail.gmail.com> <5CDB42D5-C28B-439B-8F2F-4CAE1BAC8CC9@apple.com> <7C2325BF-CA9E-4E76-8610-409098D47762@apple.com> Message-ID: <25cf7a9f0901072235j768c5f7eg8fd1ece0f934d64b@mail.gmail.com> It's under bugzillla #3297. I've added a note on the bug entry - it looks like it's the ordering in which the designated initializers appear which matters when triggering the bug (i.e. the void * member needs to be the first). On Wed, Jan 7, 2009 at 8:54 PM, steve naroff wrote: > Sure...I missed the -checker-cfref flag on the command line (should have > looked more closely). > Sorry for the confusion, > > snaroff > > On Jan 7, 2009, at 1:50 PM, Ted Kremenek wrote: > > The assertion failure is in the static analyzer, which is why I asked > Cristian to file a new Bugzilla report. If Clang doesn't reject code with > designated initializers then the static analyzer should gracefully fail when > it encounters them instead of crash. > > On Jan 7, 2009, at 9:34 AM, steve naroff wrote: > > Known issue...clang doesn't support initializer lists that use designators > (.ref notation below). > The code generator is suppose to issue a diagnostic I believe. Daniel? > > snaroff > > On Jan 7, 2009, at 12:27 PM, Cristian Draghici wrote: > > Is this a known issue? > > cristi:tmp diciu$ cat test.c > > struct v > { > unsigned int m; > void * ref; > int z; > }; > > int main() > { > short buf[1]; > buf[0] = 66; > > struct v st2 = { > .ref = buf > }; > > st2.m = 10; > > short * u = (short *)st2.ref; > printf("%d\n", *u); > > return 0; > } > > > > cristi:tmp diciu$ ~/Downloads/checker-137/clang -x c test.c > -checker-cfref > test.c:16:10: warning: incompatible pointer to integer conversion > initializing 'short [1]', expected 'unsigned int' > .ref = buf > ^~~ > ANALYZE: test.c main > Assertion failed: (T->isPointerType()), function VisitCast, file > GRExprEngine.cpp, line 1738. > 0 clang 0x00a84582 std::vector std::allocator > >::_M_insert_aux(__gnu_cxx::__normal_iterator std::vector > >, > llvm::sys::Path const&) + 7746 > 1 libSystem.B.dylib 0x96edd2bb _sigtramp + 43 > 2 libSystem.B.dylib 0xffffffff _sigtramp + 1762798959 > 3 libSystem.B.dylib 0x96f5123a raise + 26 > 4 libSystem.B.dylib 0x96f5d679 abort + 73 > 5 libSystem.B.dylib 0x96f523db __assert_rtn + 101 > 6 clang 0x00311d21 clang::CFGBlock::operator[](unsigned long) > const + 77345 > 7 clang 0x00309458 clang::CFGBlock::operator[](unsigned long) > const + 42328 > 8 clang 0x0030a5a4 clang::CFGBlock::operator[](unsigned long) > const + 46756 > 9 clang 0x00308f6a clang::CFGBlock::operator[](unsigned long) > const + 41066 > 10 clang 0x00314140 clang::CFGBlock::operator[](unsigned long) > const + 86592 > 11 clang 0x0031a741 > clang::GRCoreEngine::ProcessStmt(clang::Stmt*, > clang::GRStmtNodeBuilderImpl&) + 97 > 12 clang 0x002fe386 > llvm::ImutAVLFactory > >::Add_internal(std::pair const&, > llvm::ImutAVLTree >*) + > 9398 > 13 clang 0x002fe598 > llvm::ImutAVLFactory > >::Add_internal(std::pair const&, > llvm::ImutAVLTree >*) + > 9928 > 14 clang 0x00008d7c llvm::cast_retty clang::Type*>::ret_type llvm::cast clang::Type*>(clang::Type* const&) + 9836 > 15 clang 0x00008638 llvm::cast_retty clang::Type*>::ret_type llvm::cast clang::Type*>(clang::Type* const&) + 7976 > 16 clang 0x00008be9 llvm::cast_retty clang::Type*>::ret_type llvm::cast clang::Type*>(clang::Type* const&) + 9433 > 17 clang 0x00356d3b > clang::OverloadedFunctionDecl::getDeclContext() + 587 > 18 clang 0x000479f2 > clang::TokenRewriter::AddTokenAfter(std::_List_const_iterator, > char const*) + 5586 > 19 clang 0x0004ab34 > clang::TokenRewriter::AddTokenAfter(std::_List_const_iterator, > char const*) + 18196 > 20 clang 0x00001936 _mh_execute_header + 2358 > Abort trap > > > > > _______________________________________________ > 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/20090108/b817d352/attachment-0001.html From xuzhongxing at gmail.com Thu Jan 8 07:21:21 2009 From: xuzhongxing at gmail.com (Zhongxing Xu) Date: Thu, 8 Jan 2009 21:21:21 +0800 Subject: [cfe-dev] [Patch] add KillStruct() to RegionStore Message-ID: <5400aeb80901080521g28edfbcehbf84a4ca7cf723fc@mail.gmail.com> This patch adds KillStruct() to region store. When we assign UnknownVal to a struct, we set the region's default value to Unknown, and remove bindings for all subregions of the struct region. -Zhongxing Xu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090108/ed223a8d/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: killstruct.patch Type: application/octet-stream Size: 2147 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090108/ed223a8d/attachment.obj From forumer at smartmobili.com Thu Jan 8 07:23:54 2009 From: forumer at smartmobili.com (forumer at smartmobili.com) Date: Thu, 08 Jan 2009 14:23:54 +0100 Subject: [cfe-dev] Clang and code transformation Message-ID: Hi, I would like to find a tool to add some trace inside some C files from GCC. I tried with some regexp but without success so I would like to know if clang would allow me to parse C files and add some frpintf() like this : c-parser.c: static void c_parser_skip_to_end_of_parameter (c_parser *parser) { fprintf(stderr, "c-parser.c: c_parser_skip_to_end_of_parameter()\n"); // ADDED by CLANG unsigned nesting_depth = 0; ... } void c_parse_file (void) { fprintf(stderr, "c-parser.c: c_parse_file()\n" ... } Thanks From forumer at smartmobili.com Thu Jan 8 07:54:38 2009 From: forumer at smartmobili.com (forumer at smartmobili.com) Date: Thu, 08 Jan 2009 14:54:38 +0100 Subject: [cfe-dev] Clang and code transformation In-Reply-To: References: Message-ID: <1b9074cdb9bcbb7be5e42952451b70ad@mail.smartmobili.com> Another question I am trying to compile clang on winXP/cygwin and it seems you are using recent GCC flags : llvm[3]: Compiling gtest.cc for Debug build cc1plus: error: unrecognized command line option "-Wno-missing-field-initializers" cc1plus: error: unrecognized command line option "-Wno-variadic-macros" Maybe you should check if it exists ... How can I remove those flags and will it work ? On Thu, 08 Jan 2009 14:23:54 +0100, wrote: > Hi, > > I would like to find a tool to add some trace inside some C files from GCC. > I tried with some regexp but without success so I would like to know if > clang > would allow me to parse C files and add some frpintf() like this : > > c-parser.c: > > > > static void > c_parser_skip_to_end_of_parameter (c_parser *parser) > { > > fprintf(stderr, "c-parser.c: c_parser_skip_to_end_of_parameter()\n"); // > ADDED by CLANG > unsigned nesting_depth = 0; > ... > > } > > void > c_parse_file (void) > { > fprintf(stderr, "c-parser.c: c_parse_file()\n" > ... > } > Thanks > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From xuzhongxing at gmail.com Thu Jan 8 08:17:18 2009 From: xuzhongxing at gmail.com (Zhongxing Xu) Date: Thu, 8 Jan 2009 22:17:18 +0800 Subject: [cfe-dev] Name lookup approach Message-ID: <5400aeb80901080617u512ebe16rb60a6cb3d3c8867f@mail.gmail.com> Hi, Currently we have two mechanisms to do name lookup: IdentifierResolver and DeclContext. In Sema::LookupDecl(), we combine the two approaches to fulfil the name lookup task. I really feel that the code in Sema::LookupDecl() logically uninituitive and error prone. Could we use DeclContext exclusively to do name lookup and eliminate the IdentifierResolver use? I think that way could make name lookup logically more clear. My only concern is if that could cause performance lost? -Zhongxing -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090108/9781593f/attachment.html From kremenek at apple.com Thu Jan 8 10:53:24 2009 From: kremenek at apple.com (Ted Kremenek) Date: Thu, 08 Jan 2009 08:53:24 -0800 Subject: [cfe-dev] report of assertion failure in clang In-Reply-To: <25cf7a9f0901072235j768c5f7eg8fd1ece0f934d64b@mail.gmail.com> References: <25cf7a9f0901070927i560d353bkb5ebd5237dbff1f4@mail.gmail.com> <5CDB42D5-C28B-439B-8F2F-4CAE1BAC8CC9@apple.com> <7C2325BF-CA9E-4E76-8610-409098D47762@apple.com> <25cf7a9f0901072235j768c5f7eg8fd1ece0f934d64b@mail.gmail.com> Message-ID: <8CA6BFFC-DCAA-42CB-AE08-08684258792A@apple.com> Thanks Cristian! On Jan 7, 2009, at 10:35 PM, Cristian Draghici wrote: > It's under bugzillla #3297. > > I've added a note on the bug entry - it looks like it's the ordering > in which the designated initializers appear which matters when > triggering the bug (i.e. the void * member needs to be the first). > > > > On Wed, Jan 7, 2009 at 8:54 PM, steve naroff > wrote: > Sure...I missed the -checker-cfref flag on the command line (should > have looked more closely). > > Sorry for the confusion, > > snaroff > > On Jan 7, 2009, at 1:50 PM, Ted Kremenek wrote: > >> The assertion failure is in the static analyzer, which is why I >> asked Cristian to file a new Bugzilla report. If Clang doesn't >> reject code with designated initializers then the static analyzer >> should gracefully fail when it encounters them instead of crash. >> >> On Jan 7, 2009, at 9:34 AM, steve naroff wrote: >> >>> Known issue...clang doesn't support initializer lists that use >>> designators (.ref notation below). >>> >>> The code generator is suppose to issue a diagnostic I believe. >>> Daniel? >>> >>> snaroff >>> >>> On Jan 7, 2009, at 12:27 PM, Cristian Draghici wrote: >>> >>>> Is this a known issue? >>>> >>>> cristi:tmp diciu$ cat test.c >>>> >>>> struct v >>>> { >>>> unsigned int m; >>>> void * ref; >>>> int z; >>>> }; >>>> >>>> int main() >>>> { >>>> short buf[1]; >>>> >>>> buf[0] = 66; >>>> >>>> struct v st2 = { >>>> .ref = buf >>>> }; >>>> >>>> st2.m = 10; >>>> >>>> short * u = (short *)st2.ref; >>>> printf("%d\n", *u); >>>> >>>> return 0; >>>> } >>>> >>>> >>>> >>>> cristi:tmp diciu$ ~/Downloads/checker-137/clang -x c test.c - >>>> checker-cfref >>>> test.c:16:10: warning: incompatible pointer to integer conversion >>>> initializing 'short [1]', expected 'unsigned int' >>>> .ref = buf >>>> ^~~ >>>> ANALYZE: test.c main >>>> Assertion failed: (T->isPointerType()), function VisitCast, file >>>> GRExprEngine.cpp, line 1738. >>>> 0 clang 0x00a84582 std::vector>>> std::allocator >>>> >::_M_insert_aux(__gnu_cxx::__normal_iterator>>> std::vector > >, >>>> llvm::sys::Path const&) + 7746 >>>> 1 libSystem.B.dylib 0x96edd2bb _sigtramp + 43 >>>> 2 libSystem.B.dylib 0xffffffff _sigtramp + 1762798959 >>>> 3 libSystem.B.dylib 0x96f5123a raise + 26 >>>> 4 libSystem.B.dylib 0x96f5d679 abort + 73 >>>> 5 libSystem.B.dylib 0x96f523db __assert_rtn + 101 >>>> 6 clang 0x00311d21 clang::CFGBlock::operator[] >>>> (unsigned long) const + 77345 >>>> 7 clang 0x00309458 clang::CFGBlock::operator[] >>>> (unsigned long) const + 42328 >>>> 8 clang 0x0030a5a4 clang::CFGBlock::operator[] >>>> (unsigned long) const + 46756 >>>> 9 clang 0x00308f6a clang::CFGBlock::operator[] >>>> (unsigned long) const + 41066 >>>> 10 clang 0x00314140 clang::CFGBlock::operator[] >>>> (unsigned long) const + 86592 >>>> 11 clang 0x0031a741 >>>> clang: >>>> :GRCoreEngine::ProcessStmt(clang::Stmt*, >>>> clang::GRStmtNodeBuilderImpl&) + 97 >>>> 12 clang 0x002fe386 >>>> llvm::ImutAVLFactory>>> unsigned int> >::Add_internal(std::pair>>> int> const&, llvm::ImutAVLTree>>> int, unsigned int> >*) + 9398 >>>> 13 clang 0x002fe598 >>>> llvm::ImutAVLFactory>>> unsigned int> >::Add_internal(std::pair>>> int> const&, llvm::ImutAVLTree>>> int, unsigned int> >*) + 9928 >>>> 14 clang 0x00008d7c >>>> llvm::cast_retty::ret_type >>>> llvm::cast(clang::Type* >>>> const&) + 9836 >>>> 15 clang 0x00008638 >>>> llvm::cast_retty::ret_type >>>> llvm::cast(clang::Type* >>>> const&) + 7976 >>>> 16 clang 0x00008be9 >>>> llvm::cast_retty::ret_type >>>> llvm::cast(clang::Type* >>>> const&) + 9433 >>>> 17 clang 0x00356d3b >>>> clang::OverloadedFunctionDecl::getDeclContext() + 587 >>>> 18 clang 0x000479f2 >>>> clang: >>>> :TokenRewriter: >>>> :AddTokenAfter(std::_List_const_iterator, char >>>> const*) + 5586 >>>> 19 clang 0x0004ab34 >>>> clang: >>>> :TokenRewriter: >>>> :AddTokenAfter(std::_List_const_iterator, char >>>> const*) + 18196 >>>> 20 clang 0x00001936 _mh_execute_header + 2358 >>>> Abort trap >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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/20090108/e964edd4/attachment-0001.html From dgregor at apple.com Thu Jan 8 11:33:35 2009 From: dgregor at apple.com (Douglas Gregor) Date: Thu, 8 Jan 2009 09:33:35 -0800 Subject: [cfe-dev] Name lookup approach In-Reply-To: <5400aeb80901080617u512ebe16rb60a6cb3d3c8867f@mail.gmail.com> References: <5400aeb80901080617u512ebe16rb60a6cb3d3c8867f@mail.gmail.com> Message-ID: <0519D6EE-13B2-4A1F-9BFE-29B32475DC20@apple.com> On Jan 8, 2009, at 6:17 AM, Zhongxing Xu wrote: > Currently we have two mechanisms to do name lookup: > IdentifierResolver and DeclContext. In Sema::LookupDecl(), we > combine the two approaches to fulfil the name lookup task. I really > feel that the code in Sema::LookupDecl() logically uninituitive and > error prone. Could we use DeclContext exclusively to do name lookup > and eliminate the IdentifierResolver use? Currently, no; the chains of declarations held in the IdentifierResolver contain information local declarations that are all in the same DeclContext. For example: void f(int x) { // #1 { int x; // #2 { int x; // #3 printf("%i", x); // this 'x' refers to #3 } } } Here, the IdentifierResolver has a chain of declarations #3 -> #2 -> #1 for the name 'x'. However, all three 'x's live in the DeclContext associated with f's FunctionDecl. Now, it is possible that we want compound statements to be DeclContexts, so that the 'x's would be be in different DeclContexts. That might be a good generalization (regardless of whether we use it for name lookup), because it would mean that more of the scope structure of the program is present in the ASTs after parsing. But, that gets to your comment below... > I think that way could make name lookup logically more clear. My > only concern is if that could cause performance lost? Yes, it would most certainly cause performance degradation if we used DeclContext for all name lookup. The beauty of IdentifierResolver is that the chain of declarations in scope for a particular name is attached to the IdentifierInfo for the name, so it's O(1) to find the first declaration with that name that's in scope. If we're using just DeclContexts, we'd have to walk the scope chain upward, checking DeclContext along the way (each check is either a search through a small array or a hash table lookup). In fact, some of the optimization comments in LookupDecl (and other optimization ideas that have yet to be written down) involve trying to skip calls to DeclContext::lookup when we know that we would have found the answer on the IdentifierResolver chain if there were an answer. So, I think the complexity of LookupDecl is inherent to solving the problem efficiently. It's also extremely important to performance: when compiling a C++ program that includes , GCC spends 26% of its time in name lookup. - Doug From dgregor at apple.com Thu Jan 8 11:52:28 2009 From: dgregor at apple.com (Douglas Gregor) Date: Thu, 8 Jan 2009 09:52:28 -0800 Subject: [cfe-dev] EnumConstantDecl is added to EnumDecl twice In-Reply-To: <5400aeb80901071926p8df1be7o7a4f445d9d44fca1@mail.gmail.com> References: <5400aeb80901071926p8df1be7o7a4f445d9d44fca1@mail.gmail.com> Message-ID: On Jan 7, 2009, at 7:26 PM, Zhongxing Xu wrote: > Hi, > > Currently every EnumConstantDecl is added to its EnumDecl twice: one > at SemaDecl.cpp:3489, the other at SemaDecl.cpp:109. > > I noticed the comments said that the enumerator is stored in two > DeclContexts. Maybe we should change line SemaDecl.cpp:109 : > > CurContext->addDecl(Context, SD); > > into: > > ((DeclContext *)S->getEntity())->addDecl(Context, SD); That's definitely the right direction to go. If we can completely decouple PushOnScopeChains from CurContext, then it will be possible to PushOnScopeChains(Decl, AnyScopeYouWantToUse), which will be very helpful when it comes to, e.g., pushing implicitly-declared entities into the translation unit's scope. Perhaps we could even get rid of CurContext entirely, in favor of finding the context based on the Scope we're given? Regarding that specific change: it isn't quite right, because the code just above it will skip through any transparent contexts, but it won't guarantee that S->getEntity() is non-NULL. From the original scope S we get, we'll need to find the first scope that has an entity (S- >getEntity() != NULL) and add the scoped declaration to that DeclContext. (That DeclContext itself might be a transparent DeclContext, like an enumeration's DeclContext). Stepping back to the comment that the enumerator is stored in two DeclContexts: we should be able to remove the addDecl and setLexicalDeclContext calls after the FIXME near line 3489 of SemaDecl.cpp, because transparent DeclContexts should already cope with this case. I actually meant to make that change as part of the transparent DeclContext patch, but it didn't seem to happen :) - Doug From dgregor at apple.com Thu Jan 8 14:49:41 2009 From: dgregor at apple.com (Douglas Gregor) Date: Thu, 8 Jan 2009 12:49:41 -0800 Subject: [cfe-dev] EnumConstantDecl is added to EnumDecl twice In-Reply-To: References: <5400aeb80901071926p8df1be7o7a4f445d9d44fca1@mail.gmail.com> Message-ID: <21673833-BBD8-47E6-A7E7-72E13D8D037C@apple.com> On Jan 8, 2009, at 9:52 AM, Douglas Gregor wrote: > Stepping back to the comment that the enumerator is stored in two > DeclContexts: we should be able to remove the addDecl and > setLexicalDeclContext calls after the FIXME near line 3489 of > SemaDecl.cpp, because transparent DeclContexts should already cope > with this case. I actually meant to make that change as part of the > transparent DeclContext patch, but it didn't seem to happen :) FWIW, this code is gone now, and transparent declcontexts are handling name lookup for enumerators. - Doug From weinig at apple.com Thu Jan 8 16:08:16 2009 From: weinig at apple.com (Sam Weinig) Date: Thu, 8 Jan 2009 14:08:16 -0800 Subject: [cfe-dev] [Patch] mm_malloc.h header Message-ID: <13C2CFC5-DD68-420F-8EE8-D6B83F2428CC@apple.com> Attached is a patch to implement the _mm_malloc() and _mm_free() methods for aligned allocations from the mm_malloc.h header. -Sam -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090108/40ca6d86/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: mm_mallocPatch.diff Type: application/octet-stream Size: 2237 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090108/40ca6d86/attachment.obj -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090108/40ca6d86/attachment-0001.html From clattner at apple.com Thu Jan 8 16:56:45 2009 From: clattner at apple.com (Chris Lattner) Date: Thu, 8 Jan 2009 14:56:45 -0800 Subject: [cfe-dev] Clang and code transformation In-Reply-To: References: Message-ID: <0B610F5C-127E-40B8-8B29-65B3D00C15A7@apple.com> On Jan 8, 2009, at 5:23 AM, forumer at smartmobili.com wrote: > Hi, > > I would like to find a tool to add some trace inside some C files > from GCC. > I tried with some regexp but without success so I would like to know > if > clang > would allow me to parse C files and add some frpintf() like this : Sure, clang can do this short of thing. It supports rewriting interfaces to insert strings into existing files. Please take a look at the ObjC->C rewriter for some examples. For example: $ cat t.m char * test() { return @encode(int); } $ clang t.m -rewrite-objc -o - ... char * test() { return "i"; } -Chris From xuzhongxing at gmail.com Thu Jan 8 18:44:42 2009 From: xuzhongxing at gmail.com (Zhongxing Xu) Date: Fri, 9 Jan 2009 08:44:42 +0800 Subject: [cfe-dev] Name lookup approach In-Reply-To: <0519D6EE-13B2-4A1F-9BFE-29B32475DC20@apple.com> References: <5400aeb80901080617u512ebe16rb60a6cb3d3c8867f@mail.gmail.com> <0519D6EE-13B2-4A1F-9BFE-29B32475DC20@apple.com> Message-ID: <5400aeb80901081644w6dcf7ca5ke6fac18fce9d21b9@mail.gmail.com> On Fri, Jan 9, 2009 at 1:33 AM, Douglas Gregor wrote: > > On Jan 8, 2009, at 6:17 AM, Zhongxing Xu wrote: > >> Currently we have two mechanisms to do name lookup: IdentifierResolver and >> DeclContext. In Sema::LookupDecl(), we combine the two approaches to fulfil >> the name lookup task. I really feel that the code in Sema::LookupDecl() >> logically uninituitive and error prone. Could we use DeclContext exclusively >> to do name lookup and eliminate the IdentifierResolver use? >> > > Currently, no; the chains of declarations held in the IdentifierResolver > contain information local declarations that are all in the same DeclContext. > For example: > > void f(int x) { // #1 > { > int x; // #2 > { > int x; // #3 > > printf("%i", x); // this 'x' refers to #3 > } > } > } > > Here, the IdentifierResolver has a chain of declarations #3 -> #2 -> #1 for > the name 'x'. However, all three 'x's live in the DeclContext associated > with f's FunctionDecl. > > Now, it is possible that we want compound statements to be DeclContexts, so > that the 'x's would be be in different DeclContexts. That might be a good > generalization (regardless of whether we use it for name lookup), because it > would mean that more of the scope structure of the program is present in the > ASTs after parsing. But, that gets to your comment below... > > I think that way could make name lookup logically more clear. My only >> concern is if that could cause performance lost? >> > > > Yes, it would most certainly cause performance degradation if we used > DeclContext for all name lookup. The beauty of IdentifierResolver is that > the chain of declarations in scope for a particular name is attached to the > IdentifierInfo for the name, so it's O(1) to find the first declaration with > that name that's in scope. If we're using just DeclContexts, we'd have to > walk the scope chain upward, checking DeclContext along the way (each check > is either a search through a small array or a hash table lookup). > > In fact, some of the optimization comments in LookupDecl (and other > optimization ideas that have yet to be written down) involve trying to skip > calls to DeclContext::lookup when we know that we would have found the > answer on the IdentifierResolver chain if there were an answer. > > So, I think the complexity of LookupDecl is inherent to solving the problem > efficiently. It's also extremely important to performance: when compiling a > C++ program that includes , GCC spends 26% of its time in name > lookup. > > - Doug > Thanks for the explanation, Doug. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090109/9d9698fb/attachment.html From kremenek at apple.com Thu Jan 8 19:02:03 2009 From: kremenek at apple.com (Ted Kremenek) Date: Thu, 8 Jan 2009 17:02:03 -0800 Subject: [cfe-dev] [Patch] add KillStruct() to RegionStore In-Reply-To: <5400aeb80901080521g28edfbcehbf84a4ca7cf723fc@mail.gmail.com> References: <5400aeb80901080521g28edfbcehbf84a4ca7cf723fc@mail.gmail.com> Message-ID: <2333ADE3-7748-4845-A256-F10D65F7744E@apple.com> On Jan 8, 2009, at 9:21 PM, Zhongxing Xu wrote: > This patch adds KillStruct() to region store. When we assign > UnknownVal to a struct, we set the region's default value to > Unknown, and remove bindings for all subregions of the struct region. Hi Zhongxing, This is nice. Could you include a test case that would trigger KillStruct? More comments below: Index: lib/Analysis/RegionStore.cpp =================================================================== --- lib/Analysis/RegionStore.cpp ??? 61900? +++ lib/Analysis/RegionStore.cpp ?????? @@ -234,6 +234,9 @@ const GRState* BindStruct(const GRState* St, const TypedRegion* R, SVal V); + /// KillStruct - Set the entire struct to unknown. + const GRState* KillStruct(const GRState* St, const TypedRegion* R); + // Utility methods. BasicValueFactory& getBasicVals() { return StateMgr.getBasicVals (); } ASTContext& getContext() { return StateMgr.getContext(); } @@ -910,6 +913,9 @@ RecordDecl* RD = RT->getDecl(); assert(RD->isDefinition()); + if (V.isUnknown()) + return KillStruct(St, R); + When precisely can V.isUnknown() be true when the value is a struct? (test case please). +const GRState* RegionStoreManager::KillStruct(const GRState* St, + const TypedRegion* R){ + GRStateRef state(St, StateMgr); + // Set the default value of the struct region to UnknownVal. + St = state.set(R, UnknownVal()); Interesting. Do we need the killset anymore, or are we going to model "killed values" in this way? + + Store store = St->getStore(); + RegionBindingsTy B = GetRegionBindings(store); + + std::vector ToBeKilled; In general, please use a llvm::SmallVector<> so that we can optimize for the case when the number of items fits on the stack. Using std::vector forces us to malloc() memory every time this method is called (which is slow). My comment below, however, illustrates why we don't need to use either in this case. + + // Remove all bindings for the subregions of the struct. + for (RegionBindingsTy::iterator I = B.begin(), E = B.end(); I != E; ++I) { + const MemRegion* r = I.getKey(); + if (const SubRegion* sr = dyn_cast(r)) + if (sr->isSubRegionOf(R)) + ToBeKilled.push_back(R); I think the region to be killed is 'r', not 'R' (since we just bound a value to it up above). + } + + for (std::vector::iterator I = ToBeKilled.begin(), + E = ToBeKilled.end(); I != E; ++I) + store = Remove(store, Loc::MakeVal(*I)); You don't need to build a vector of killed regions and then iterate through vector because 'B' is a purely functional data structure. That is, removing entries from store just creates a new store, and 'B' will continue have the same values and the iterator won't be invalidated. The following will do just fine: for (RegionBindingsTy::iterator I = B.begin(), E = B.end(); I != E; ++I) { const MemRegion* r = I.getKey(); if (const SubRegion* sr = dyn_cast(r)) if (sr->isSubRegionOf(R)) store = Remove(store, Loc::MakeVal(r)); + return StateMgr.MakeStateWithStore(St, store); Do we also need to remove region views for the regions that are killed, or should we dispense with that GDM entry entirely? +} + From xuzhongxing at gmail.com Thu Jan 8 19:36:39 2009 From: xuzhongxing at gmail.com (Zhongxing Xu) Date: Fri, 9 Jan 2009 09:36:39 +0800 Subject: [cfe-dev] [Patch] add KillStruct() to RegionStore In-Reply-To: <2333ADE3-7748-4845-A256-F10D65F7744E@apple.com> References: <5400aeb80901080521g28edfbcehbf84a4ca7cf723fc@mail.gmail.com> <2333ADE3-7748-4845-A256-F10D65F7744E@apple.com> Message-ID: <5400aeb80901081736w9e095ebk3c3195313935f50d@mail.gmail.com> On Fri, Jan 9, 2009 at 9:02 AM, Ted Kremenek wrote: > > On Jan 8, 2009, at 9:21 PM, Zhongxing Xu wrote: > > This patch adds KillStruct() to region store. When we assign UnknownVal to >> a struct, we set the region's default value to Unknown, and remove bindings >> for all subregions of the struct region. >> > > Hi Zhongxing, > > This is nice. Could you include a test case that would trigger KillStruct? > More comments below: > > > Index: lib/Analysis/RegionStore.cpp > =================================================================== > --- lib/Analysis/RegionStore.cpp ??? 61900? > +++ lib/Analysis/RegionStore.cpp ?????? > @@ -234,6 +234,9 @@ > > const GRState* BindStruct(const GRState* St, const TypedRegion* R, SVal > V); > > + /// KillStruct - Set the entire struct to unknown. > + const GRState* KillStruct(const GRState* St, const TypedRegion* R); > + > // Utility methods. > BasicValueFactory& getBasicVals() { return StateMgr.getBasicVals(); } > ASTContext& getContext() { return StateMgr.getContext(); } > @@ -910,6 +913,9 @@ > RecordDecl* RD = RT->getDecl(); > assert(RD->isDefinition()); > > + if (V.isUnknown()) > + return KillStruct(St, R); > + > > When precisely can V.isUnknown() be true when the value is a struct? (test > case please). We already have that test case. It is the f5() in test/Analysis/array-struct.c. > > > > +const GRState* RegionStoreManager::KillStruct(const GRState* St, > + const TypedRegion* R){ > + GRStateRef state(St, StateMgr); > + // Set the default value of the struct region to UnknownVal. > + St = state.set(R, UnknownVal()); > > Interesting. Do we need the killset anymore, or are we going to model > "killed values" in this way? I think we still need killset. The regions in killset are ones we query its binding directly. The regions in RegionDefaultValue are ones whose subregions we query bindings for. I haven't had a way to combine them. > > > + > + Store store = St->getStore(); > + RegionBindingsTy B = GetRegionBindings(store); > + > + std::vector ToBeKilled; > > In general, please use a llvm::SmallVector<> so that we can optimize for > the case when the number of items fits on the stack. Using std::vector > forces us to malloc() memory every time this method is called (which is > slow). My comment below, however, illustrates why we don't need to use > either in this case. OK. > > > + > + // Remove all bindings for the subregions of the struct. > + for (RegionBindingsTy::iterator I = B.begin(), E = B.end(); I != E; ++I) > { > + const MemRegion* r = I.getKey(); > + if (const SubRegion* sr = dyn_cast(r)) > + if (sr->isSubRegionOf(R)) > + ToBeKilled.push_back(R); > > I think the region to be killed is 'r', not 'R' (since we just bound a > value to it up above). Yes, my mistake (typo). > > > + } > + > + for (std::vector::iterator I = ToBeKilled.begin(), > + E = ToBeKilled.end(); I != E; ++I) > + store = Remove(store, Loc::MakeVal(*I)); > > You don't need to build a vector of killed regions and then iterate through > vector because 'B' is a purely functional data structure. That is, removing > entries from store just creates a new store, and 'B' will continue have the > same values and the iterator won't be invalidated. The following will do > just fine: > > for (RegionBindingsTy::iterator I = B.begin(), E = B.end(); I != E; ++I) { > const MemRegion* r = I.getKey(); > if (const SubRegion* sr = dyn_cast(r)) > if (sr->isSubRegionOf(R)) > store = Remove(store, Loc::MakeVal(r)); > > + return StateMgr.MakeStateWithStore(St, store); Ah, I forgot that point. Is this also known as persistent data structure? > > > Do we also need to remove region views for the regions that are killed, or > should we dispense with that GDM entry entirely? I think region views are orthogonal to this one. Region views are used to cast region back and forth between typed and untyped ones. Here we only handle the region bindings. > > +} > + > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090109/41ef4c05/attachment-0001.html From clattner at apple.com Fri Jan 9 11:46:26 2009 From: clattner at apple.com (Chris Lattner) Date: Fri, 9 Jan 2009 09:46:26 -0800 Subject: [cfe-dev] Intern opening Message-ID: Hi Everyone, The Apple compiler group is looking for an outstanding intern to fill an internship opening this summer. The position is a paid 3 month position in the Cupertino, CA area. We are looking for a candidate with Clang and/or LLVM optimizer/backend hacking experience, and strongly prefer candidates who have contributed code to the public repositories. If you are interested in the position, please send me your resume/CV and any other related info by Jan 23. Thanks! -Chris From Alireza.Moshtaghi at microchip.com Fri Jan 9 11:55:09 2009 From: Alireza.Moshtaghi at microchip.com (Alireza.Moshtaghi at microchip.com) Date: Fri, 9 Jan 2009 10:55:09 -0700 Subject: [cfe-dev] assertion on initialized struct in non zero address space Message-ID: Consider : struct _st { int var1; int var2; } s __attribute ((address_space(1))) = {1, 1}; When it gets to InitListChecker::CheckListElementTypes() DeclType->isStructureType() returns false and eventually the function asserts. How should we go about fixing this problem? Regards, Alireza Moshtaghi Senior Software Engineer Development Systems, Microchip Technology From sebastian.redl at getdesigned.at Fri Jan 9 16:52:45 2009 From: sebastian.redl at getdesigned.at (Sebastian Redl) Date: Fri, 09 Jan 2009 23:52:45 +0100 Subject: [cfe-dev] Pragma warning control Message-ID: <4967D53D.1010802@getdesigned.at> Hi, I'm thinking of implementing a pragma to control Clang warnings. This would look something like this (borrowing MS syntax because it makes sense, IMO): struct A; void f(A *a) { #pragma Clang warning(disable: warn_delete_incomplete) // This would cause the warning, but I know it to be safe: delete a; // Bring warning back to its default status so that real issues aren't missed. #pragma Clang warning(default: warn_delete_incomplete) } Alternatively, this could be done with an attribute, but I actually think that a pragma is the better choice here. (Among other things, because it can then control preprocessor, lexer and parser warnings.) Is there interest in such a feature? I know that GCC's inability to control most warnings within a source file causes problems in the Boost project from time to time. Some concrete issues I can think of: - Template instantiation would ideally save the warning status around the definition of a template and reintroduce it during instantiation; else you for example disable truncation warnings around the template definition, but instantiations cause the warning anyway. - Explicitly disabling warnings at the command line could either share status storage with this feature, but then warning(default: id) would enable warnings that were disabled at the command line. Alternatively, the feature could have its own storage, but that means doubling the required memory. - We would really need to make diagnostic continuations somehow a part of the original diagnostic, or we could get dangling notes. (Or do we get them already with -w? Do we have any warnings that have dependent notes?) - We should probably clean up the names of the diagnostics. In the long run, this means that the names of the diagnostics become part of the public interface of the compiler, which means we can't change them at will anymore. To implement this, I would create a lazily initialized map from names to the actual integers. Better, from many viewpoints, would be a sorted array of the names, searched by binary search (no initialization necessary, it's all read-only data), but that's not possible due to the lack of string processing abilities in the preprocessor and template meta-engines. (In non-pompous terms, I can't sort strings at compile-time.) Sebastian From dgregor at apple.com Fri Jan 9 18:35:58 2009 From: dgregor at apple.com (Douglas Gregor) Date: Fri, 9 Jan 2009 16:35:58 -0800 Subject: [cfe-dev] Pragma warning control In-Reply-To: <4967D53D.1010802@getdesigned.at> References: <4967D53D.1010802@getdesigned.at> Message-ID: <44ACCFEE-F477-4A28-BA23-7B53F026D3F3@apple.com> Hi Sebastian, On Jan 9, 2009, at 2:52 PM, Sebastian Redl wrote: > I'm thinking of implementing a pragma to control Clang warnings. This > would look something like this (borrowing MS syntax because it makes > sense, IMO): > > struct A; > > void f(A *a) { > #pragma Clang warning(disable: warn_delete_incomplete) > // This would cause the warning, but I know it to be safe: > delete a; > // Bring warning back to its default status so that real issues > aren't > missed. > #pragma Clang warning(default: warn_delete_incomplete) > } > > Alternatively, this could be done with an attribute, but I actually > think that a pragma is the better choice here. (Among other things, > because it can then control preprocessor, lexer and parser warnings.) I, too, prefer the pragma. Microsoft did a good job with this one. #pragma warning(push) and #pragma warning(pop) are particularly good for headers (where disabling warnings seems to matter the most to users). > > Is there interest in such a feature? Yes! > I know that GCC's inability to > control most warnings within a source file causes problems in the > Boost > project from time to time. Yes, it definitely annoys users when they can't turn off a bogus or unwanted warning. > > Some concrete issues I can think of: > - Template instantiation would ideally save the warning status around > the definition of a template and reintroduce it during instantiation; > else you for example disable truncation warnings around the template > definition, but instantiations cause the warning anyway. Yep. This probably means that these pragmas will need to be able to appear wherever (at least) declarations can appear. > - Explicitly disabling warnings at the command line could either share > status storage with this feature, but then warning(default: id) would > enable warnings that were disabled at the command line. Alternatively, > the feature could have its own storage, but that means doubling the > required memory. I think warning(default: id) should not change its behavior based on the options on the command line. > - We would really need to make diagnostic continuations somehow a part > of the original diagnostic, or we could get dangling notes. (Or do we > get them already with -w? Do we have any warnings that have dependent > notes?) There are other good reasons for doing this, too, such as providing non-terminal clients with enough information to group all of the notes as part of a single warning/error message. > - We should probably clean up the names of the diagnostics. In the > long > run, this means that the names of the diagnostics become part of the > public interface of the compiler, which means we can't change them at > will anymore. Yeah, and we'll want to try to weed out any duplicates, too (yuck). Still, this is work that we'll just have to do. > To implement this, I would create a lazily initialized map from > names to > the actual integers. Better, from many viewpoints, would be a sorted > array of the names, searched by binary search (no initialization > necessary, it's all read-only data), but that's not possible due to > the > lack of string processing abilities in the preprocessor and template > meta-engines. (In non-pompous terms, I can't sort strings at compile- > time.) We could require that the entries in DiagnosticKinds be sorted, with a Debug-only sortedness check at start-up. Actually, that would help force us to come up with more consistent diagnostic names, since getting related diagnostics together means giving them similar names. I think this would make a great addition to Clang. - Doug From me22.ca at gmail.com Fri Jan 9 21:15:41 2009 From: me22.ca at gmail.com (me22) Date: Fri, 9 Jan 2009 22:15:41 -0500 Subject: [cfe-dev] Pragma warning control In-Reply-To: <4967D53D.1010802@getdesigned.at> References: <4967D53D.1010802@getdesigned.at> Message-ID: On Fri, Jan 9, 2009 at 17:52, Sebastian Redl wrote: > > I'm thinking of implementing a pragma to control Clang warnings. This > would look something like this (borrowing MS syntax because it makes > sense, IMO): > > struct A; > > void f(A *a) { > #pragma Clang warning(disable: warn_delete_incomplete) > // This would cause the warning, but I know it to be safe: > delete a; > // Bring warning back to its default status so that real issues aren't > missed. > #pragma Clang warning(default: warn_delete_incomplete) > } > I think something like this would be better: void f(A *a) { #pragma Clang warning(--warn_delete_incomplete) delete a; #pragma Clang warning(++warn_delete_incomplete) } So that nesting them still works, which I don't think the "default" way would. Be nice for things like gcc's strict aliasing warnings, too. The build could default to the stricter, false-positive including mode, and it could be lowered to the only false negatives mode in sections of the code that need it. ~ Scott From kremenek at apple.com Sat Jan 10 01:46:16 2009 From: kremenek at apple.com (Ted Kremenek) Date: Fri, 9 Jan 2009 23:46:16 -0800 Subject: [cfe-dev] [Patch] add KillStruct() to RegionStore In-Reply-To: <5400aeb80901081736w9e095ebk3c3195313935f50d@mail.gmail.com> References: <5400aeb80901080521g28edfbcehbf84a4ca7cf723fc@mail.gmail.com> <2333ADE3-7748-4845-A256-F10D65F7744E@apple.com> <5400aeb80901081736w9e095ebk3c3195313935f50d@mail.gmail.com> Message-ID: <94BB43FA-3086-4085-866B-2E26E85C73C7@apple.com> On Jan 8, 2009, at 5:36 PM, Zhongxing Xu wrote: > Index: lib/Analysis/RegionStore.cpp > =================================================================== > --- lib/Analysis/RegionStore.cpp ??? 61900? > > > + if (V.isUnknown()) > + return KillStruct(St, R); > + > > When precisely can V.isUnknown() be true when the value is a > struct? (test case please). > > We already have that test case. It is the f5() in test/Analysis/ > array-struct.c. Great! We should add a comment to that test case the says what part of the analyzer/region store is getting tested. > +const GRState* RegionStoreManager::KillStruct(const GRState* St, > + const TypedRegion* R){ > + GRStateRef state(St, StateMgr); > + // Set the default value of the struct region to UnknownVal. > + St = state.set(R, UnknownVal()); > > Interesting. Do we need the killset anymore, or are we going to > model "killed values" in this way? > > I think we still need killset. The regions in killset are ones we > query its binding directly. The regions in RegionDefaultValue are > ones whose subregions we query bindings for. I haven't had a way to > combine them. I believe I might be confused about some basic concepts. Here is how I interpreted things. The "killset" is part of the state, and represents those regions whose values have been changed (via direct assignment) after the entry to the analyzed function. This way we don't need to explicitly bind initial values to regions and instead lazily infer their bindings. According to comments in RegionStore, the "default value" map (RegionDefaultValue) is used to track "what regions have a default value of 0 if they have no bound value and have not been killed." From the patch I see 'KillStruct' being used in the following way: const GRState* RegionStoreManager::BindStruct(const GRState* St, const TypedRegion* R, SVal V){ // FIXME: Verify that we should use getRValueType or getLValueType. QualType T = R->getRValueType(getContext()); assert(T->isStructureType()); RecordType* RT = cast(T.getTypePtr()); RecordDecl* RD = RT->getDecl(); assert(RD->isDefinition()); if (V.isUnknown()) return KillStruct(St, R) ... Two things occur to me: (1) We should always be adding any region directly assigned to the killset. Doesn't that include structs? (2) After assigning the value "unknown" to the struct, the values of its fields should not be 0 (as indicated by the comments for RegionDefaultValue). That doesn't make sense to me. Shouldn't they just be "unknown"? In other words, regardless of whether V.isUnknown() == true (in the above code snippet) we should always do (1) and then just remove any bindings to struct and it's fields. Adding entries to RegionDefaultValue (i.e., (2)) doesn't make sense to me, so I think I'm just missing something and don't really understand the overall design. > Ah, I forgot that point. Is this also known as persistent data > structure? Yes it is. The term "purely functional data structures" comes from the functional programming mindset. Okasaki has an excellent book on that topic: http://books.google.com/books?id=SxPzSTcTalAC&dq=purely+functional+data+structures&printsec=frontcover&source=bn&hl=en&sa=X&oi=book_result&resnum=4&ct=result > > Do we also need to remove region views for the regions that are > killed, or should we dispense with that GDM entry entirely? > > I think region views are orthogonal to this one. Region views are > used to cast region back and forth between typed and untyped ones. > Here we only handle the region bindings. "Views" are just a specific type of subregions (whose bindings are all getting nuked by KillStruct). The GDM entry "RegionViews" is just a back-mapping from a region to its subregions. If we remove all of those bindings why do we need to keep that backmapping around since none of them bind to any value? Removing stale data from the state allows better caching. As a meta comment, it would probably be good to add comments to the top of RegionStore that documents the overall design. More specifically, we should mention how the different GDM pieces are used, what's the overall abstraction of how regions bind to values, how we model "views" of regions (i.e., what they are and what purpose they serve) and so forth. I feel that some of my confusion is stemming from not completely understanding the design as well as I thought I did. From xuzhongxing at gmail.com Sat Jan 10 05:12:19 2009 From: xuzhongxing at gmail.com (Zhongxing Xu) Date: Sat, 10 Jan 2009 19:12:19 +0800 Subject: [cfe-dev] [Patch] add KillStruct() to RegionStore In-Reply-To: <94BB43FA-3086-4085-866B-2E26E85C73C7@apple.com> References: <5400aeb80901080521g28edfbcehbf84a4ca7cf723fc@mail.gmail.com> <2333ADE3-7748-4845-A256-F10D65F7744E@apple.com> <5400aeb80901081736w9e095ebk3c3195313935f50d@mail.gmail.com> <94BB43FA-3086-4085-866B-2E26E85C73C7@apple.com> Message-ID: <5400aeb80901100312y78d6483ap33075831b613d43@mail.gmail.com> On Sat, Jan 10, 2009 at 3:46 PM, Ted Kremenek wrote: > On Jan 8, 2009, at 5:36 PM, Zhongxing Xu wrote: > > Index: lib/Analysis/RegionStore.cpp >> =================================================================== >> --- lib/Analysis/RegionStore.cpp ??? 61900? >> >> >> + if (V.isUnknown()) >> + return KillStruct(St, R); >> + >> >> When precisely can V.isUnknown() be true when the value is a struct? >> (test case please). >> >> We already have that test case. It is the f5() in >> test/Analysis/array-struct.c. >> > > Great! We should add a comment to that test case the says what part of the > analyzer/region store is getting tested. Done. > > > +const GRState* RegionStoreManager::KillStruct(const GRState* St, >> + const TypedRegion* R){ >> + GRStateRef state(St, StateMgr); >> + // Set the default value of the struct region to UnknownVal. >> + St = state.set(R, UnknownVal()); >> >> Interesting. Do we need the killset anymore, or are we going to model >> "killed values" in this way? >> >> I think we still need killset. The regions in killset are ones we query >> its binding directly. The regions in RegionDefaultValue are ones whose >> subregions we query bindings for. I haven't had a way to combine them. >> > > I believe I might be confused about some basic concepts. Here is how I > interpreted things. > > The "killset" is part of the state, and represents those regions whose > values have been changed (via direct assignment) after the entry to the > analyzed function. This way we don't need to explicitly bind initial values > to regions and instead lazily infer their bindings. > > According to comments in RegionStore, the "default value" map > (RegionDefaultValue) is used to track "what regions have a default value of > 0 if they have no bound value and have not been killed." > > From the patch I see 'KillStruct' being used in the following way: > > const GRState* > RegionStoreManager::BindStruct(const GRState* St, const TypedRegion* R, > SVal V){ > // FIXME: Verify that we should use getRValueType or getLValueType. > QualType T = R->getRValueType(getContext()); > assert(T->isStructureType()); > > RecordType* RT = cast(T.getTypePtr()); > RecordDecl* RD = RT->getDecl(); > assert(RD->isDefinition()); > > if (V.isUnknown()) > return KillStruct(St, R) > ... > > Two things occur to me: > > (1) We should always be adding any region directly assigned to the killset. > Doesn't that include structs? Yes. I thought we would never query a struct region's binding like we never do it to an array region. But later I realized I was wrong. I've done this step in the new patch. And, I think we should add a region to the killset *only* when it is assigned "unknown" directly. Because if it is assigned other value, we would have its binding in the region bindings. It is redundant to add it to the killset. > > > (2) After assigning the value "unknown" to the struct, the values of its > fields should not be 0 (as indicated by the comments for > RegionDefaultValue). That doesn't make sense to me. Shouldn't they just be > "unknown"? > > In other words, regardless of whether V.isUnknown() == true (in the above > code snippet) we should always do (1) and then just remove any bindings to > struct and it's fields. Adding entries to RegionDefaultValue (i.e., (2)) > doesn't make sense to me, so I think I'm just missing something and don't > really understand the overall design. RegionDefaultValue was originally designed to include regions which have default values of 0. But later I find we could have default values other than 0. This is just a case that we need it, since we would query the bindings of the subregions of the struct region that is killed (assigned "unknown"). If we don't set the struct region's default value, we would have to add all subregions of the struct region to the killset. Now that we set the struct region's default value, we can just remove the subregions of the struct region from RegionBindings. > > > Ah, I forgot that point. Is this also known as persistent data structure? >> > > Yes it is. The term "purely functional data structures" comes from the > functional programming mindset. Okasaki has an excellent book on that > topic: > > > http://books.google.com/books?id=SxPzSTcTalAC&dq=purely+functional+data+structures&printsec=frontcover&source=bn&hl=en&sa=X&oi=book_result&resnum=4&ct=result Thanks. > > > > >> Do we also need to remove region views for the regions that are killed, or >> should we dispense with that GDM entry entirely? >> >> I think region views are orthogonal to this one. Region views are used to >> cast region back and forth between typed and untyped ones. Here we only >> handle the region bindings. >> > > "Views" are just a specific type of subregions (whose bindings are all > getting nuked by KillStruct). The GDM entry "RegionViews" is just a > back-mapping from a region to its subregions. If we remove all of those > bindings why do we need to keep that backmapping around since none of them > bind to any value? Removing stale data from the state allows better > caching. Yes, I've done this in the new patch. > > > As a meta comment, it would probably be good to add comments to the top of > RegionStore that documents the overall design. More specifically, we should > mention how the different GDM pieces are used, what's the overall > abstraction of how regions bind to values, how we model "views" of regions > (i.e., what they are and what purpose they serve) and so forth. I feel that > some of my confusion is stemming from not completely understanding the > design as well as I thought I did. Yes. I should have done that. But I didn't do it because I feel some designs are not fixed. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090110/d39376fc/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: killstruct2.patch Type: application/octet-stream Size: 5772 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090110/d39376fc/attachment-0001.obj From sebastian.redl at getdesigned.at Sat Jan 10 05:54:22 2009 From: sebastian.redl at getdesigned.at (Sebastian Redl) Date: Sat, 10 Jan 2009 12:54:22 +0100 Subject: [cfe-dev] Pragma warning control In-Reply-To: References: <4967D53D.1010802@getdesigned.at> Message-ID: <49688C6E.60705@getdesigned.at> me22 wrote: > On Fri, Jan 9, 2009 at 17:52, Sebastian Redl > wrote: > >> I'm thinking of implementing a pragma to control Clang warnings. This >> would look something like this (borrowing MS syntax because it makes >> sense, IMO): >> >> struct A; >> >> void f(A *a) { >> #pragma Clang warning(disable: warn_delete_incomplete) >> // This would cause the warning, but I know it to be safe: >> delete a; >> // Bring warning back to its default status so that real issues aren't >> missed. >> #pragma Clang warning(default: warn_delete_incomplete) >> } >> >> > > I think something like this would be better: > > void f(A *a) { > #pragma Clang warning(--warn_delete_incomplete) > delete a; > #pragma Clang warning(++warn_delete_incomplete) > } > > So basically, you have a counter that is initialized to 0 if the warning is disabled, and 1 if it's enabled, and the warning is emitted if its counter is >= 1? Interesting idea, but I think this would give users trying to reliably disable warnings a headache - you'd find something like // Just in case someone enabled the warning when it was already enabled: #pragma Clang warning(--warn_delete_incomplete) #pragma Clang warning(--warn_delete_incomplete) I think supporting warning(push) and warning(pop) is the better technique here. This allows proper nesting with headers. > Be nice for things like gcc's strict aliasing warnings, too. The > build could default to the stricter, false-positive including mode, > and it could be lowered to the only false negatives mode in sections > of the code that need it. > Aren't strict and weak mode different warnings? The Clang diagnostic system certainly doesn't support different warning strictness levels. Sebastian From sebastian.redl at getdesigned.at Sat Jan 10 06:05:42 2009 From: sebastian.redl at getdesigned.at (Sebastian Redl) Date: Sat, 10 Jan 2009 13:05:42 +0100 Subject: [cfe-dev] Pragma warning control In-Reply-To: <44ACCFEE-F477-4A28-BA23-7B53F026D3F3@apple.com> References: <4967D53D.1010802@getdesigned.at> <44ACCFEE-F477-4A28-BA23-7B53F026D3F3@apple.com> Message-ID: <49688F16.2010106@getdesigned.at> Douglas Gregor wrote: > Hi Sebastian, > > On Jan 9, 2009, at 2:52 PM, Sebastian Redl wrote: >> >> Some concrete issues I can think of: >> - Template instantiation would ideally save the warning status around >> the definition of a template and reintroduce it during instantiation; >> else you for example disable truncation warnings around the template >> definition, but instantiations cause the warning anyway. > > Yep. This probably means that these pragmas will need to be able to > appear wherever (at least) declarations can appear. > What do you mean? In the code? A pragma can appear anywhere. (Although - what *is* the effect of a pragma in the middle of an expression?) >> - Explicitly disabling warnings at the command line could either share >> status storage with this feature, but then warning(default: id) would >> enable warnings that were disabled at the command line. Alternatively, >> the feature could have its own storage, but that means doubling the >> required memory. > > I think warning(default: id) should not change its behavior based on > the options on the command line. > That's just a question of the definition of default's behavior. :-) Is it defined to - Enable the warning (but then it should be called 'enable') - Enable the warning if it would be enabled without any pragma (then it has to respect all command line options) - Enable the warning if it would be enabled without any pragma or command line option specific to this warning (then it has to respect general options like -pedantic or -w). The name 'default' in the MS compiler comes from their warning scheme. The MS compiler has warning levels 0-4. Every warning has an associated level and is enabled if the level is that or higher, so level 0 is no warnings, and level 4 is all warnings. 'Default' then means to reset the warning to the behavior it has at the specified warning level. But Clang doesn't have warning levels, so we have to redefine or rename default. >> - We should probably clean up the names of the diagnostics. In the long >> run, this means that the names of the diagnostics become part of the >> public interface of the compiler, which means we can't change them at >> will anymore. > > Yeah, and we'll want to try to weed out any duplicates, too (yuck). > Still, this is work that we'll just have to do. > Yes. Another boring housekeeping job. >> To implement this, I would create a lazily initialized map from names to >> the actual integers. Better, from many viewpoints, would be a sorted >> array of the names, searched by binary search (no initialization >> necessary, it's all read-only data), but that's not possible due to the >> lack of string processing abilities in the preprocessor and template >> meta-engines. (In non-pompous terms, I can't sort strings at >> compile-time.) > > We could require that the entries in DiagnosticKinds be sorted, with a > Debug-only sortedness check at start-up. Actually, that would help > force us to come up with more consistent diagnostic names, since > getting related diagnostics together means giving them similar names. That's a possibility, but it really requires a consistent naming scheme, and one that is exposed to the user, so it has to make sense for both developers and users. So I think I'll go with building the map for now. Sebastian From danchr at gmail.com Sat Jan 10 08:29:32 2009 From: danchr at gmail.com (Dan Villiom Podlaski Christiansen) Date: Sat, 10 Jan 2009 15:29:32 +0100 Subject: [cfe-dev] Pragma warning control In-Reply-To: <49688F16.2010106@getdesigned.at> References: <4967D53D.1010802@getdesigned.at> <44ACCFEE-F477-4A28-BA23-7B53F026D3F3@apple.com> <49688F16.2010106@getdesigned.at> Message-ID: <4E2ABAC0-033D-4894-8885-5D0F2233F29D@gmail.com> On 10 Jan 2009, at 13:05, Sebastian Redl wrote: > That's just a question of the definition of default's behavior. :-) Is > it defined to > - Enable the warning (but then it should be called 'enable') > - Enable the warning if it would be enabled without any pragma (then > it > has to respect all command line options) > - Enable the warning if it would be enabled without any pragma or > command line option specific to this warning (then it has to respect > general options like -pedantic or -w). > > The name 'default' in the MS compiler comes from their warning scheme. > The MS compiler has warning levels 0-4. Every warning has an > associated > level and is enabled if the level is that or higher, so level 0 is no > warnings, and level 4 is all warnings. 'Default' then means to reset > the > warning to the behavior it has at the specified warning level. > But Clang doesn't have warning levels, so we have to redefine or > rename > default. How about a stack-based approach? That is, a change is pushed on to the warning stack. A change is then reverted by popping it from the stack; either by naming it explicitly or an indiscriminate ?pop?. For example: >> // warn about these >> #pragma Clang warning(push: format-nonliteral) >> ? some code ? >> // revert this warning to its pre-specified behaviour >> #pragma Clang warning(pop: format-nonliteral) >> >> // don't warn about these >> #pragma Clang warning(push: no-dead-store) >> ? some code ? >> // revert the most recent change >> #pragma Clang warning(pop) (An alternate syntax: ?#pragma Clang push(warnings, no-dead- store)?, and so on.) Maybe strict ordering of pushes and pops should be required; I'm mostly thinking of this as a user, so I have no opinion about that :) With regards to warning names, I'd suggest changing them to match command-line options. This involves removing the ?warn? prefix ? which seems redundant to me ? and changing underscores to dashes. Combined with a change to make diagnostic names more closely match GCC warning flags, and introducing ?meta-diagnostics? (if you can say that) to match things like -Wall, -Wextra, -Wformat, -Wsecurity and so on, affecting the default values of individual diagnostics. Prefixing a diagnostic name with ?no-? would have the effect of turning it off. This might be useful for simplifying the driver, which would contain little or no information about the actual diagnostics. In the future, it might even be useful for retaining warning flags by embedding them into a serialised AST. Having tried to compile a few programs with Clang, I noticed that warning options don't match GCC. It seems to me that naming core diagnostics compatibly would be preferable to having to translate them. -- Dan Villiom Podlaski Christiansen, stud. scient., danchr at cs.au.dk, danchr at gmail.com From xuzhongxing at gmail.com Sat Jan 10 09:09:48 2009 From: xuzhongxing at gmail.com (Zhongxing Xu) Date: Sat, 10 Jan 2009 23:09:48 +0800 Subject: [cfe-dev] [Patch] DeclContext printer Message-ID: <5400aeb80901100709r509aa982nfcc216a2209b89e9@mail.gmail.com> Hi, Attached patch implements an initial framework of a DeclContextPrinter. It can print DeclContext and its Decls in indented format. An Example: $ cat 3.cpp class A { int a; void f(); }; void A::f() { a = 3; } $ clang -print-decl-contexts 3.cpp [translation unit] 0x9754d7c __builtin_va_list [class] A 0x9753310 A 0x975ce20 a f A A operator= ~A [c++ method] f [[0x9753310]] Some comments: '<>' indicates a declaration, '[]' indicates a definition, '[[ ]]' displays the semantic DeclContext which is different from the lexical DeclContext. This visualization should be helpful for DeclContext debugging. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090110/f5f2e305/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: dcprinter.patch Type: application/octet-stream Size: 8549 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090110/f5f2e305/attachment-0001.obj From danchr at gmail.com Sat Jan 10 09:33:54 2009 From: danchr at gmail.com (Dan Villiom Podlaski Christiansen) Date: Sat, 10 Jan 2009 16:33:54 +0100 Subject: [cfe-dev] =?utf-8?b?W1BBVENIXSDigJhjY2PigJkgb3ZlcmhhdWw=?= Message-ID: <349E9414-82AC-4E99-B6E8-97187AA5AEAB@gmail.com> Hi, Attached below is a patch against ?utils/ccc?. It contains the following changes: - Recognise many more options for passing to linker and compiler. - Recognise relocation modes and pass them to compiler and linker. - Use the new ability for generating native assembly code directly. - Add explicit support for ?-O4? and ?-flto?. - Make '-print-prog-name' actually work. (?g? ? ?t?) - Implement ?-pipe?. - Like GCC, default to using ['-suppress-system-warnings', '-Wno- format-nonliteral', '-tailcallopt']. -- Dan Villiom Podlaski Christiansen, stud. scient., danchr at cs.au.dk, danchr at gmail.com -------------- next part -------------- A non-text attachment was scrubbed... Name: clang-ccc.diff Type: application/octet-stream Size: 13483 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090110/8396bb75/attachment.obj From danchr at gmail.com Sat Jan 10 09:48:41 2009 From: danchr at gmail.com (Dan Villiom Podlaski Christiansen) Date: Sat, 10 Jan 2009 16:48:41 +0100 Subject: [cfe-dev] =?utf-8?b?W1BBVENIXSDigJhjY2PigJkgb3ZlcmhhdWw=?= In-Reply-To: <349E9414-82AC-4E99-B6E8-97187AA5AEAB@gmail.com> References: <349E9414-82AC-4E99-B6E8-97187AA5AEAB@gmail.com> Message-ID: <99C9F17E-91CC-485A-B966-1D3673C87615@gmail.com> This mail was supposed to have gone to ?cfe-commits?, where I hope to be sending this reply to as well? On 10 Jan 2009, at 16:33, Dan Villiom Podlaski Christiansen wrote: > Hi, > > Attached below is a patch against ?utils/ccc?. It contains the > following changes: > > - Recognise many more options for passing to linker and compiler. > - Recognise relocation modes and pass them to compiler and linker. > - Use the new ability for generating native assembly code directly. > - Add explicit support for ?-O4? and ?-flto?. > - Make '-print-prog-name' actually work. (?g? ? ?t?) > - Implement ?-pipe?. > - Like GCC, default to using ['-suppress-system-warnings', '-Wno- > format-nonliteral', '-tailcallopt']. > > -- > > Dan Villiom Podlaski Christiansen, stud. scient., > danchr at cs.au.dk, danchr at gmail.com > > -- Dan Villiom Podlaski Christiansen, stud. scient., danchr at cs.au.dk, danchr at gmail.com From clattner at apple.com Sat Jan 10 14:17:45 2009 From: clattner at apple.com (Chris Lattner) Date: Sat, 10 Jan 2009 12:17:45 -0800 Subject: [cfe-dev] Pragma warning control In-Reply-To: <4967D53D.1010802@getdesigned.at> References: <4967D53D.1010802@getdesigned.at> Message-ID: <543B07EE-BD7C-4F41-885A-98F2F1B331BB@apple.com> On Jan 9, 2009, at 2:52 PM, Sebastian Redl wrote: > > Is there interest in such a feature? I know that GCC's inability to > control most warnings within a source file causes problems in the > Boost > project from time to time. Yes, this would be a great feature! This is definitely worthwhile to work on. I also agree that pragmas are a better way to go than attributes. I wouldn't worry too much about the template issues etc, we can solve some of that through extensions to the source location mechanism. > - We should probably clean up the names of the diagnostics. In the > long > run, this means that the names of the diagnostics become part of the > public interface of the compiler, which means we can't change them at > will anymore. I really think that this problem should be tackled first as a separate project. The "enum names" in DiagnosticKinds.def are intended to be unique identifiers, but are really not intended to be "stable". In addition to warning control in the source code, we also need command-line option warning control: we already have some trivial options like -Wfloat-equal, -Wunused-macros, -Wundef, etc, but the current control over them is adhoc and controlled by C++ code in clang.cpp. Going forward, we need to support more and more of these sorts of options in a "roughly" GCC-compatible way, but we also need to support harder things like -Wall and -W, which turn on a large set of different warnings. I haven't thought too much about this, but I think it could make sense to introduce a notion of hierarchical groups of warning options. Each of these hierarchical groups could be assigned a "stable" name and could be controlled by both the command line and the #pragmas. A warning group would have its 1) stable name, 2) list of concrete diagnostics included, and 3) list of warning subgroups that it includes. This means that -Wall would just include a bunch of subgroups instead of hundreds of individual diagnostics. This structure may be a bit overwhelming to handle with a .def file, if so, we could easily make a tblgen backend to handle this. What do you think Sebastian? Do you agree that it would be good to tackle this problem before the #pragma version of it? -Chris From sebastian.redl at getdesigned.at Sun Jan 11 08:31:34 2009 From: sebastian.redl at getdesigned.at (Sebastian Redl) Date: Sun, 11 Jan 2009 15:31:34 +0100 Subject: [cfe-dev] Pragma warning control In-Reply-To: <543B07EE-BD7C-4F41-885A-98F2F1B331BB@apple.com> References: <4967D53D.1010802@getdesigned.at> <543B07EE-BD7C-4F41-885A-98F2F1B331BB@apple.com> Message-ID: <496A02C6.3080909@getdesigned.at> Chris Lattner wrote: > On Jan 9, 2009, at 2:52 PM, Sebastian Redl wrote: > >> - We should probably clean up the names of the diagnostics. In the long >> run, this means that the names of the diagnostics become part of the >> public interface of the compiler, which means we can't change them at >> will anymore. > > I really think that this problem should be tackled first as a separate > project. The "enum names" in DiagnosticKinds.def are intended to be > unique identifiers, but are really not intended to be "stable". So, we define separate stable names? > > In addition to warning control in the source code, we also need > command-line option warning control: we already have some trivial > options like -Wfloat-equal, -Wunused-macros, -Wundef, etc, but the > current control over them is adhoc and controlled by C++ code in > clang.cpp. > > Going forward, we need to support more and more of these sorts of > options in a "roughly" GCC-compatible way, but we also need to support > harder things like -Wall and -W, which turn on a large set of > different warnings. > > I haven't thought too much about this, but I think it could make sense > to introduce a notion of hierarchical groups of warning options. Each > of these hierarchical groups could be assigned a "stable" name and > could be controlled by both the command line and the #pragmas. A > warning group would have its 1) stable name, 2) list of concrete > diagnostics included, and 3) list of warning subgroups that it > includes. This means that -Wall would just include a bunch of > subgroups instead of hundreds of individual diagnostics. > This sounds like a good idea. > This structure may be a bit overwhelming to handle with a .def file, > if so, we could easily make a tblgen backend to handle this. > > What do you think Sebastian? Do you agree that it would be good to > tackle this problem before the #pragma version of it? Yes, we definitely need to tackle this first, since tackling it after would mean rewriting the whole pragma stuff. I have no idea how tblgen works, but I agree that the preprocessor is probably not powerful enough. (Well, it is powerful enough, but the definition would be close to unreadable.) Sebastian From clattner at apple.com Sun Jan 11 13:09:36 2009 From: clattner at apple.com (Chris Lattner) Date: Sun, 11 Jan 2009 11:09:36 -0800 Subject: [cfe-dev] Pragma warning control In-Reply-To: <496A02C6.3080909@getdesigned.at> References: <4967D53D.1010802@getdesigned.at> <543B07EE-BD7C-4F41-885A-98F2F1B331BB@apple.com> <496A02C6.3080909@getdesigned.at> Message-ID: On Jan 11, 2009, at 6:31 AM, Sebastian Redl wrote: > Chris Lattner wrote: >> On Jan 9, 2009, at 2:52 PM, Sebastian Redl wrote: >> >>> - We should probably clean up the names of the diagnostics. In the >>> long >>> run, this means that the names of the diagnostics become part of the >>> public interface of the compiler, which means we can't change them >>> at >>> will anymore. >> >> I really think that this problem should be tackled first as a >> separate >> project. The "enum names" in DiagnosticKinds.def are intended to be >> unique identifiers, but are really not intended to be "stable". > > So, we define separate stable names? Yes, I think so. The warning options we already support directly control exactly one diagnostic, so we basically have (in tblgen syntax): // Existing DiagnosticsKinds.def gets converted to tblgen syntax def pp_macro_not_used : Warning<"macro is not used">; def warn_floatingpoint_eq : Warning<"comparing floating point with == or != is unsafe">; ... // New warning group definitions.... def unusedmacros : Group<"unused_macros", [pp_macro_not_used]>; def floatequal : Group<"float-equal", [warn_floatingpoint_eq]>; def readonlysetterattrs : Group<"readonly-setter-attrs", [warn_objc_property_attr_mutually_exclusive]>; def formatnonliteral : Group<"format-nonliteral", [warn_printf_not_string_constant]>; def undef : Group<[warn_pp_undef_identifier]>; def implicitfunctiondeclaration : Group<"implicit-function-declaration", [warn_implicit_function_decl]>; etc. However, going forward there will be other warnings that turn on several distinct warnings in the .def file. This is where having a list of warnings is useful. After We have that, we can start aggregating them together, e.g.: def all : Group<[undef, implicitfunctiondeclaration, ....]>; Since tblgen can run arbitrary code, it can reject (or warn about) warnings that are not in a warning group etc. The code generated by tblgen could handle the -Wno-foo cases etc. I'd suggest changing the existing command line option code for -W* in clang.cpp to just use a cl::list WarningOpts("W", ...). Which will just make vector of all the -Wfoo options. The tblgen generated code can then just parse, validate and swizzle that array however it wants. >> This structure may be a bit overwhelming to handle with a .def file, >> if so, we could easily make a tblgen backend to handle this. >> >> What do you think Sebastian? Do you agree that it would be good to >> tackle this problem before the #pragma version of it? > > Yes, we definitely need to tackle this first, since tackling it after > would mean rewriting the whole pragma stuff. I have no idea how tblgen > works, but I agree that the preprocessor is probably not powerful > enough. (Well, it is powerful enough, but the definition would be > close > to unreadable.) I can probably tackle this in a couple of weeks. If you're interested at poking at it, I'd suggest taking a look at llvm/include/llvm/ Intrinsics.td. It gets tblgen'd into llvm/include/llvm/ Intrinsics.gen. The code to do this is llvm/utils/TableGen/ IntrinsicEmitter.*. The first step would be to convert the existing diagnostickinds.def file to tblgen syntax and generate an Diagnostics.inc file that contains the existing views that we get with macro expansion. -Chris From foldr at codedgers.com Sun Jan 11 15:09:54 2009 From: foldr at codedgers.com (Mikhail Glushenkov) Date: Sun, 11 Jan 2009 21:09:54 +0000 (UTC) Subject: [cfe-dev] 'llvmc --clang' vs. 'ccc' Message-ID: Hi, I noticed that there is ongoing work [1] on extending ccc with what looks like duplication of the functionality already present in llvmc [2]. I just want to remind that llvmc's clang plugin was recently rewritten [3] to make it usable as a drop-in replacement for 'ccc'. The clang plugin is now compiled in by default, so you can just alias 'ccc' to 'llvmc --clang' and use that instead of the old 'ccc' script. Feedback is very much appreciated, preferably in form of bug reports. [1] http://article.gmane.org/gmane.comp.compilers.clang.scm/4177 [2] http://llvm.org/docs/CompilerDriver.html [3] http://article.gmane.org/gmane.comp.compilers.llvm.devel/17087/ From daniel at zuster.org Sun Jan 11 18:09:34 2009 From: daniel at zuster.org (Daniel Dunbar) Date: Sun, 11 Jan 2009 16:09:34 -0800 Subject: [cfe-dev] 'llvmc --clang' vs. 'ccc' In-Reply-To: References: Message-ID: <6a8523d60901111609p7d275921xd6f7cba0327acf91@mail.gmail.com> Hi Mikhail, As you have noticed, I have been pursuing a non-llvmc based driver; the end goal is to replace ccc with a fully C++ driver. I discussed this several weeks ago with Anton and I presumed he relayed the jist of our conversation to you. I am planning on writing up some documentation on the approach and the motivation today and sending it out, including the reasons for not using llvmc. For now, the basic points are: (1) My goals are a very high level of gcc compatibility and the ability to be completely independent of the gcc driver (e.g., call cc1 directly). These goals seemed different and potentially at odds from the emphasis of llvmc on extensibility. (2) I don't agree that much of my current work is duplication of functionality already present in llvmc. A significant part of my work was trying to find an architecture which was "as clean as possible" while allowing high gcc compatibility (including, for example, integrating the Apple driver driver). I think most of my time has been spent solving problems llvmc hasn't dealt with yet; for example, llvmc uses LLVM's command line library to parse arguments, but this is fundamentally different from how gcc handles arguments. In the end, I hope that we converge to a single full featured driver, but for the time being my goal was to get a highly functional driver up and running as quickly as possible, and my judgement call was our priorities are different enough that it made sense to implement a separate tool. - Daniel On Sun, Jan 11, 2009 at 1:09 PM, Mikhail Glushenkov wrote: > Hi, > > I noticed that there is ongoing work [1] on extending ccc with > what looks like duplication of the functionality already present > in llvmc [2]. I just want to remind that llvmc's clang plugin was > recently rewritten [3] to make it usable as a drop-in replacement > for 'ccc'. The clang plugin is now compiled in by default, so you > can just alias 'ccc' to 'llvmc --clang' and use that instead of > the old 'ccc' script. Feedback is very much appreciated, > preferably in form of bug reports. > > [1] http://article.gmane.org/gmane.comp.compilers.clang.scm/4177 > [2] http://llvm.org/docs/CompilerDriver.html > [3] http://article.gmane.org/gmane.comp.compilers.llvm.devel/17087/ > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > From clattner at apple.com Sun Jan 11 18:21:19 2009 From: clattner at apple.com (Chris Lattner) Date: Sun, 11 Jan 2009 16:21:19 -0800 Subject: [cfe-dev] assertion on initialized struct in non zero address space In-Reply-To: References: Message-ID: <3A1CC3BC-9EF1-42A9-A5E1-4389FEA7A01E@apple.com> On Jan 9, 2009, at 9:55 AM, Alireza.Moshtaghi at microchip.com wrote: > Consider : > > struct _st { > int var1; > int var2; > } s __attribute ((address_space(1))) = {1, 1}; > > When it gets to InitListChecker::CheckListElementTypes() > DeclType->isStructureType() returns false and eventually the function > asserts. > > How should we go about fixing this problem? Hi Alireza, This turned out to be some bugs in the type predicates. Type::isStructureType should look through ASQualTypes to see that the underlying type is a struct. I fixed this and some other related bugs and checked in your testcase. Thanks! -Chris From piotr.rak at gmail.com Sun Jan 11 18:34:30 2009 From: piotr.rak at gmail.com (Piotr Rak) Date: Mon, 12 Jan 2009 01:34:30 +0100 Subject: [cfe-dev] [Patch] Remove AllowLookup argument to DeclContext::addDecl() Message-ID: <7925cd330901111634m4541a141td026ae3d6c07299b@mail.gmail.com> Hi, Because DeclContext::addDecl() builds lazily lookup structure, AllowLookup parameter works only when LookupPtr != 0. To fix it we would have to store it somehow in DeclContext. However, I noticed that it was no single use with other value that true. I think, the best option is to just remove it and assume it is always true. In case it would be some cases for it in future, we could just learn DeclContext::buildLookup() about them. Attached patch removes this argument. It also removes needless now ASTContext argument to DeclContext::addDecl(), and DeclContext::insert(). Piotr -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Minor-DeclContext-changes.patch Type: text/x-patch Size: 20195 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090112/c5ca7541/attachment-0001.bin From foldr at codedgers.com Mon Jan 12 06:16:39 2009 From: foldr at codedgers.com (Mikhail Glushenkov) Date: Mon, 12 Jan 2009 12:16:39 +0000 (UTC) Subject: [cfe-dev] 'llvmc --clang' vs. 'ccc' References: <6a8523d60901111609p7d275921xd6f7cba0327acf91@mail.gmail.com> Message-ID: Hi Daniel, > (2) I don't agree that much of my current work is duplication of > functionality already present in llvmc. I didn't look into it closely, so I won't argue. > A significant part of my work > was trying to find an architecture which was "as clean as possible" > while allowing high gcc compatibility (including, for example, > integrating the Apple driver driver). I think most of my time has been > spent solving problems llvmc hasn't dealt with yet; for example, llvmc > uses LLVM's command line library to parse arguments, but this is > fundamentally different from how gcc handles arguments. llvmc also strives to be a drop-in gcc replacement, and I think that CommandLine is sufficient for that. What isn't possible to do with CommandLine is cl.exe simulation; this is something we'll definitely want to tackle at some point in the future. Support for fat binaries is also on my TODO list. > [...] the > ability to be completely independent of the gcc driver (e.g., call cc1 > directly). This is certainly possible to do with llvmc, it was just easier to reuse the gcc driver. > In the end, I hope that we converge to a single full featured driver, > but for the time being my goal was to get a highly functional driver > up and running as quickly as possible, and my judgement call was our > priorities are different enough that it made sense to implement a > separate tool. OK, I see your point. If llvmc will benefit from your work, then it's all for the better. I just think that llvmc's clang plugin needs more feedback from its target audience, that's all. From bagnara at cs.unipr.it Mon Jan 12 07:08:48 2009 From: bagnara at cs.unipr.it (Roberto Bagnara) Date: Mon, 12 Jan 2009 14:08:48 +0100 Subject: [cfe-dev] Bugs 2746 and 3261 Message-ID: <496B40E0.1000909@cs.unipr.it> These are complete show-stoppers for us. Is there any hope they may be fixed soon? Are there workarounds (even dirty ones) we might use so as to proceed with our work? Many thanks, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara at cs.unipr.it From dgregor at apple.com Mon Jan 12 11:15:27 2009 From: dgregor at apple.com (Douglas Gregor) Date: Mon, 12 Jan 2009 09:15:27 -0800 Subject: [cfe-dev] Pragma warning control In-Reply-To: <49688F16.2010106@getdesigned.at> References: <4967D53D.1010802@getdesigned.at> <44ACCFEE-F477-4A28-BA23-7B53F026D3F3@apple.com> <49688F16.2010106@getdesigned.at> Message-ID: On Jan 10, 2009, at 4:05 AM, Sebastian Redl wrote: > Douglas Gregor wrote: >> Hi Sebastian, >> >> On Jan 9, 2009, at 2:52 PM, Sebastian Redl wrote: >>> >>> Some concrete issues I can think of: >>> - Template instantiation would ideally save the warning status >>> around >>> the definition of a template and reintroduce it during >>> instantiation; >>> else you for example disable truncation warnings around the template >>> definition, but instantiations cause the warning anyway. >> >> Yep. This probably means that these pragmas will need to be able to >> appear wherever (at least) declarations can appear. >> > > What do you mean? In the code? A pragma can appear anywhere. > (Although - > what *is* the effect of a pragma in the middle of an expression?) Yes, in the AST. We'd have some kind of PragmaWarningDecl/ PragmaWarningStmt that can occur wherever a declaration or statement can occur, so that the instantiation of this warning/statement could perform the appropriate state changes. If we hit a pragma in the middle of an expression, we'd just put the pragma's decl/stmt before or after the current one and produce a warning to say what we did. That said, Chris seems to have an idea about how to do this with SourceLocations, so I'd like to hear about that. >>> - Explicitly disabling warnings at the command line could either >>> share >>> status storage with this feature, but then warning(default: id) >>> would >>> enable warnings that were disabled at the command line. >>> Alternatively, >>> the feature could have its own storage, but that means doubling the >>> required memory. >> >> I think warning(default: id) should not change its behavior based on >> the options on the command line. >> > > That's just a question of the definition of default's behavior. :-) Is > it defined to > - Enable the warning (but then it should be called 'enable') This is the behavior that I would prefer. - Doug From kremenek at apple.com Mon Jan 12 12:23:14 2009 From: kremenek at apple.com (Ted Kremenek) Date: Mon, 12 Jan 2009 10:23:14 -0800 Subject: [cfe-dev] [PATCH] Extend the use of DeclGroup In-Reply-To: <5400aeb80901062209u4e35eb33he228323a8acaf0ee@mail.gmail.com> References: <5400aeb80901040110n64165b8ctf369fa3985b7ace@mail.gmail.com> <350421A4-D7C1-4111-9CD9-725C204DA1B6@apple.com> <5400aeb80901061914i4a35a6e8y70f5dddb06afe534@mail.gmail.com> <92F6E354-C5CA-4C3B-BD95-0000611666FC@apple.com> <5400aeb80901062209u4e35eb33he228323a8acaf0ee@mail.gmail.com> Message-ID: How do we want to proceed with DeclGroups? From my offline conversations my understanding is that we plan on going ahead with DeclGroups. On Jan 6, 2009, at 10:09 PM, Zhongxing Xu wrote: > > > On Wed, Jan 7, 2009 at 12:45 PM, Douglas Gregor > wrote: > On Jan 6, 2009, at 7:14 PM, Zhongxing Xu wrote: >> On Wed, Jan 7, 2009 at 10:33 AM, Douglas Gregor >> wrote: >> My hunch is that what we want is to find a way to iterate through a >> DeclContext in a way that allows us to see the DeclGroups (or, at >> least, see the syntactic relationship between "struct s { }" and >> "s_t"). However, I'd like to hear your thoughts on these ownership >> and representation issues. >> >> - Doug >> >> Hi Doug, >> >> I'll take a deep look at all the DeclContext stuff and mechanism in >> the following days. But my feeling is that DeclContext should be >> the ultimate solution to the ownership problem. I'll wait for your >> progress in this area. > > I'll try to get this done sooner rather than later. There is > documentation on DeclContexts here: > > http://clang.llvm.org/docs/InternalsManual.html#DeclContext > > Thanks. > > >> >> On the other hand, as you said, we still need a mechanism to >> recover the original syntax structure of the source (and more >> ideally, the layout of the source code). I think the DeclGroup >> could play that role with the following structure: >> DeclGroup => TypeSpecifier Decls >> >> Instead of owning the decls, the DeclGroup and TypeSpecifier could >> only refer to the decls with a pointer. > > Yes, I agree. > >> >> Also the TopLevelDecls in TranslationUnit probably could be kept to >> reflect the code layout? > > We shouldn't need it. A DeclContext's list of declarations > (accessible via decls_begin/decls_end) contains all of the > declarations in the order they occur within the source code, which > is the same information that TopLevelDecls tries to capture now. > > OK. > > > - Doug > > > _______________________________________________ > 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/20090112/036a8eae/attachment.html From dgregor at apple.com Mon Jan 12 12:28:10 2009 From: dgregor at apple.com (Douglas Gregor) Date: Mon, 12 Jan 2009 10:28:10 -0800 Subject: [cfe-dev] [PATCH] Extend the use of DeclGroup In-Reply-To: References: <5400aeb80901040110n64165b8ctf369fa3985b7ace@mail.gmail.com> <350421A4-D7C1-4111-9CD9-725C204DA1B6@apple.com> <5400aeb80901061914i4a35a6e8y70f5dddb06afe534@mail.gmail.com> <92F6E354-C5CA-4C3B-BD95-0000611666FC@apple.com> <5400aeb80901062209u4e35eb33he228323a8acaf0ee@mail.gmail.com> Message-ID: On Jan 12, 2009, at 10:23 AM, Ted Kremenek wrote: > How do we want to proceed with DeclGroups? From my offline > conversations my understanding is that we plan on going ahead with > DeclGroups. Yes. I think DeclContext needs to store DeclGroups (or, at least, provide a view so that the user sees DeclGroups), so that we'll get the benefits of DeclGroups everywhere we can store declarations. - Doug > On Jan 6, 2009, at 10:09 PM, Zhongxing Xu wrote: > >> >> >> On Wed, Jan 7, 2009 at 12:45 PM, Douglas Gregor >> wrote: >> On Jan 6, 2009, at 7:14 PM, Zhongxing Xu wrote: >>> On Wed, Jan 7, 2009 at 10:33 AM, Douglas Gregor >>> wrote: >>> My hunch is that what we want is to find a way to iterate through >>> a DeclContext in a way that allows us to see the DeclGroups (or, >>> at least, see the syntactic relationship between "struct s { }" >>> and "s_t"). However, I'd like to hear your thoughts on these >>> ownership and representation issues. >>> >>> - Doug >>> >>> Hi Doug, >>> >>> I'll take a deep look at all the DeclContext stuff and mechanism >>> in the following days. But my feeling is that DeclContext should >>> be the ultimate solution to the ownership problem. I'll wait for >>> your progress in this area. >> >> I'll try to get this done sooner rather than later. There is >> documentation on DeclContexts here: >> >> http://clang.llvm.org/docs/InternalsManual.html#DeclContext >> >> Thanks. >> >> >>> >>> On the other hand, as you said, we still need a mechanism to >>> recover the original syntax structure of the source (and more >>> ideally, the layout of the source code). I think the DeclGroup >>> could play that role with the following structure: >>> DeclGroup => TypeSpecifier Decls >>> >>> Instead of owning the decls, the DeclGroup and TypeSpecifier could >>> only refer to the decls with a pointer. >> >> Yes, I agree. >> >>> >>> Also the TopLevelDecls in TranslationUnit probably could be kept >>> to reflect the code layout? >> >> We shouldn't need it. A DeclContext's list of declarations >> (accessible via decls_begin/decls_end) contains all of the >> declarations in the order they occur within the source code, which >> is the same information that TopLevelDecls tries to capture now. >> >> OK. >> >> >> - Doug >> >> >> _______________________________________________ >> 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/20090112/fe7cbf8b/attachment.html From eli.friedman at gmail.com Mon Jan 12 12:35:48 2009 From: eli.friedman at gmail.com (Eli Friedman) Date: Mon, 12 Jan 2009 10:35:48 -0800 Subject: [cfe-dev] Bugs 2746 and 3261 In-Reply-To: <496B40E0.1000909@cs.unipr.it> References: <496B40E0.1000909@cs.unipr.it> Message-ID: On Mon, Jan 12, 2009 at 5:08 AM, Roberto Bagnara wrote: > > These are complete show-stoppers for us. Is there any hope > they may be fixed soon? Are there workarounds (even dirty > ones) we might use so as to proceed with our work? > Many thanks, PR2746 shouldn't be too hard to implement, it's just that nobody has gotten around to it yet. It's just a matter of fixing the cast code in Sema to implement additional rules when the destination type is a union, and subsequently fixing CodeGen to know how to deal with it. For PR3261, I'm not sure, but you might be able to pull some tricks with location information. -Eli From clattner at apple.com Mon Jan 12 13:35:46 2009 From: clattner at apple.com (Chris Lattner) Date: Mon, 12 Jan 2009 11:35:46 -0800 Subject: [cfe-dev] Pragma warning control In-Reply-To: References: <4967D53D.1010802@getdesigned.at> <44ACCFEE-F477-4A28-BA23-7B53F026D3F3@apple.com> <49688F16.2010106@getdesigned.at> Message-ID: <42C4626C-2D71-47B2-B905-5148A517CE5B@apple.com> On Jan 12, 2009, at 9:15 AM, Douglas Gregor wrote: > On Jan 10, 2009, at 4:05 AM, Sebastian Redl wrote: >> > That said, Chris seems to have an idea about how to do this with > SourceLocations, so I'd like to hear about that. In my planned rewrite of source locations, SLoc's will get a hierarchical structure that can be walked. It would be reasonably easy to add a "was instantiated from" level for each time a token was instantiated in a template. -Chris From fjahanian at apple.com Mon Jan 12 14:08:14 2009 From: fjahanian at apple.com (Fariborz Jahanian) Date: Mon, 12 Jan 2009 12:08:14 -0800 Subject: [cfe-dev] clang is broken In-Reply-To: <6a8523d60901111609p7d275921xd6f7cba0327acf91@mail.gmail.com> References: <6a8523d60901111609p7d275921xd6f7cba0327acf91@mail.gmail.com> Message-ID: <08EF4B64-8EB3-4903-B5CE-F414320A4765@apple.com> There was an email from Chris which mentioned this I think. Currently, cocoa.m[m] tests are broken, as are many of my private tests. Trace looks like: 0 clang 0x00c02164 + 45 1 clang 0x00c0250f + 325 2 libSystem.B.dylib 0x945f3e4b _sigtramp + 43 3 libSystem.B.dylib 0xffffffff _sigtramp + 1805697503 4 clang 0x006b0b84 clang::TranslationUnit::~TranslationUnit() + 1258 5 clang 0x005bd47e clang::ParseAST(clang::Preprocessor&, clang::ASTConsumer*, bool, bool) + 804 6 clang 0x00068b9c + 1185 7 clang 0x0006adfd main + 2053 8 clang 0x0002717d start + 53 - Fariborz From bagnara at cs.unipr.it Mon Jan 12 14:42:28 2009 From: bagnara at cs.unipr.it (Roberto Bagnara) Date: Mon, 12 Jan 2009 21:42:28 +0100 Subject: [cfe-dev] Bugs 2746 and 3261 In-Reply-To: References: <496B40E0.1000909@cs.unipr.it> Message-ID: <496BAB34.60502@cs.unipr.it> Eli Friedman wrote: > On Mon, Jan 12, 2009 at 5:08 AM, Roberto Bagnara wrote: >> These are complete show-stoppers for us. Is there any hope >> they may be fixed soon? Are there workarounds (even dirty >> ones) we might use so as to proceed with our work? >> Many thanks, > > PR2746 shouldn't be too hard to implement, it's just that nobody has > gotten around to it yet. It's just a matter of fixing the cast code > in Sema to implement additional rules when the destination type is a > union, and subsequently fixing CodeGen to know how to deal with it. Hi Eli, thanks for your message. We do not use CodeGen, so perhaps all we need is to convince Sema (on our local copy) not to reject the code. Can you please give us instructions on how to achieve that? > For PR3261, I'm not sure, but you might be able to pull some tricks > with location information. Paolo, can you please look at that? Thanks, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara at cs.unipr.it From kremenek at apple.com Mon Jan 12 16:50:29 2009 From: kremenek at apple.com (Ted Kremenek) Date: Mon, 12 Jan 2009 14:50:29 -0800 Subject: [cfe-dev] clang is broken In-Reply-To: <08EF4B64-8EB3-4903-B5CE-F414320A4765@apple.com> References: <6a8523d60901111609p7d275921xd6f7cba0327acf91@mail.gmail.com> <08EF4B64-8EB3-4903-B5CE-F414320A4765@apple.com> Message-ID: <64B2EF0E-5FA6-4D29-B3B8-45BCD55C4B8D@apple.com> Does this fix the issue for you? http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20090112/010778.html On Jan 12, 2009, at 12:08 PM, Fariborz Jahanian wrote: > > There was an email from Chris which mentioned this I think. Currently, > cocoa.m[m] tests are > broken, as are many of my private tests. > > Trace looks like: > > 0 clang 0x00c02164 + 45 > 1 clang 0x00c0250f + 325 > 2 libSystem.B.dylib 0x945f3e4b _sigtramp + 43 > 3 libSystem.B.dylib 0xffffffff _sigtramp + 1805697503 > 4 clang 0x006b0b84 > clang::TranslationUnit::~TranslationUnit() + 1258 > 5 clang 0x005bd47e clang::ParseAST(clang::Preprocessor&, > clang::ASTConsumer*, bool, bool) + 804 > 6 clang 0x00068b9c + 1185 > 7 clang 0x0006adfd main + 2053 > 8 clang 0x0002717d start + 53 > > > - Fariborz > > _______________________________________________ > 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 Jan 12 17:23:44 2009 From: kremenek at apple.com (Ted Kremenek) Date: Mon, 12 Jan 2009 15:23:44 -0800 Subject: [cfe-dev] [Patch] add KillStruct() to RegionStore In-Reply-To: <5400aeb80901100312y78d6483ap33075831b613d43@mail.gmail.com> References: <5400aeb80901080521g28edfbcehbf84a4ca7cf723fc@mail.gmail.com> <2333ADE3-7748-4845-A256-F10D65F7744E@apple.com> <5400aeb80901081736w9e095ebk3c3195313935f50d@mail.gmail.com> <94BB43FA-3086-4085-866B-2E26E85C73C7@apple.com> <5400aeb80901100312y78d6483ap33075831b613d43@mail.gmail.com> Message-ID: <93E5EFF3-729A-4D41-84A0-F2EB60324A1C@apple.com> This looks great! Two comments: +const GRState* RegionStoreManager::KillStruct(const GRState* St, + const TypedRegion* R){ + GRStateRef state(St, StateMgr); + + // Kill the struct region because it is assigned "unknown". + St = state.add(R); + + // Set the default value of the struct region to "unknown". + St = state.set(R, UnknownVal()); + + // Remove the struct region from the RegionViews. It could only be a "view" of + // its super region. + St = RemoveRegionView(St, R, R->getSuperRegion()); Hmm. I'm looking at this again, I guess removing the view of 'R' from its super region doesn't make sense. It's just the values bound to 'R' that change, not the fact that 'R' is a view of its super region. + + Store store = St->getStore(); + RegionBindingsTy B = GetRegionBindings(store); + + // Remove all bindings for the subregions of the struct. + for (RegionBindingsTy::iterator I = B.begin(), E = B.end(); I != E; ++I) { + const MemRegion* r = I.getKey(); + if (const SubRegion* sr = dyn_cast(r)) + if (sr->isSubRegionOf(R)) + store = Remove(store, Loc::MakeVal(sr)); I am wondering if we also need to remove bindings for views of 'sr'. That is, iterate over the views of 'sr' and remove any bindings from state. What do you think? I guess it depends on how we decide to bind values in weird cases where people abuse the type system. + } + + return StateMgr.MakeStateWithStore(St, store); +} + On Jan 10, 2009, at 3:12 AM, Zhongxing Xu wrote: > > > On Sat, Jan 10, 2009 at 3:46 PM, Ted Kremenek > wrote: > On Jan 8, 2009, at 5:36 PM, Zhongxing Xu wrote: > > Index: lib/Analysis/RegionStore.cpp > =================================================================== > --- lib/Analysis/RegionStore.cpp ??? 61900? > > > + if (V.isUnknown()) > + return KillStruct(St, R); > + > > When precisely can V.isUnknown() be true when the value is a > struct? (test case please). > > We already have that test case. It is the f5() in test/Analysis/ > array-struct.c. > > Great! We should add a comment to that test case the says what part > of the analyzer/region store is getting tested. > > Done. > > > > +const GRState* RegionStoreManager::KillStruct(const GRState* St, > + const TypedRegion* R){ > + GRStateRef state(St, StateMgr); > + // Set the default value of the struct region to UnknownVal. > + St = state.set(R, UnknownVal()); > > Interesting. Do we need the killset anymore, or are we going to > model "killed values" in this way? > > I think we still need killset. The regions in killset are ones we > query its binding directly. The regions in RegionDefaultValue are > ones whose subregions we query bindings for. I haven't had a way to > combine them. > > I believe I might be confused about some basic concepts. Here is > how I interpreted things. > > The "killset" is part of the state, and represents those regions > whose values have been changed (via direct assignment) after the > entry to the analyzed function. This way we don't need to > explicitly bind initial values to regions and instead lazily infer > their bindings. > > According to comments in RegionStore, the "default value" map > (RegionDefaultValue) is used to track "what regions have a default > value of 0 if they have no bound value and have not been killed." > > From the patch I see 'KillStruct' being used in the following way: > > const GRState* > RegionStoreManager::BindStruct(const GRState* St, const TypedRegion* > R, SVal V){ > // FIXME: Verify that we should use getRValueType or getLValueType. > QualType T = R->getRValueType(getContext()); > assert(T->isStructureType()); > > RecordType* RT = cast(T.getTypePtr()); > > RecordDecl* RD = RT->getDecl(); > assert(RD->isDefinition()); > > if (V.isUnknown()) > return KillStruct(St, R) > ... > > Two things occur to me: > > (1) We should always be adding any region directly assigned to the > killset. Doesn't that include structs? > > Yes. I thought we would never query a struct region's binding like > we never do it to an array region. But later I realized I was wrong. > I've done this step in the new patch. > > And, I think we should add a region to the killset *only* when it is > assigned "unknown" directly. Because if it is assigned other value, > we would have its binding in the region bindings. It is redundant to > add it to the killset. > > > > (2) After assigning the value "unknown" to the struct, the values of > its fields should not be 0 (as indicated by the comments for > RegionDefaultValue). That doesn't make sense to me. Shouldn't they > just be "unknown"? > > In other words, regardless of whether V.isUnknown() == true (in the > above code snippet) we should always do (1) and then just remove any > bindings to struct and it's fields. Adding entries to > RegionDefaultValue (i.e., (2)) doesn't make sense to me, so I think > I'm just missing something and don't really understand the overall > design. > > RegionDefaultValue was originally designed to include regions which > have default values of 0. But later I find we could have default > values other than 0. This is just a case that we need it, since we > would query the bindings of the subregions of the struct region that > is killed (assigned "unknown"). If we don't set the struct region's > default value, we would have to add all subregions of the struct > region to the killset. Now that we set the struct region's default > value, we can just remove the subregions of the struct region from > RegionBindings. > > > > Ah, I forgot that point. Is this also known as persistent data > structure? > > Yes it is. The term "purely functional data structures" comes from > the functional programming mindset. Okasaki has an excellent book > on that topic: > > http://books.google.com/books?id=SxPzSTcTalAC&dq=purely+functional+data+structures&printsec=frontcover&source=bn&hl=en&sa=X&oi=book_result&resnum=4&ct=result > > Thanks. > > > > > Do we also need to remove region views for the regions that are > killed, or should we dispense with that GDM entry entirely? > > I think region views are orthogonal to this one. Region views are > used to cast region back and forth between typed and untyped ones. > Here we only handle the region bindings. > > "Views" are just a specific type of subregions (whose bindings are > all getting nuked by KillStruct). The GDM entry "RegionViews" is > just a back-mapping from a region to its subregions. If we remove > all of those bindings why do we need to keep that backmapping around > since none of them bind to any value? Removing stale data from the > state allows better caching. > > Yes, I've done this in the new patch. > > > > As a meta comment, it would probably be good to add comments to the > top of RegionStore that documents the overall design. More > specifically, we should mention how the different GDM pieces are > used, what's the overall abstraction of how regions bind to values, > how we model "views" of regions (i.e., what they are and what > purpose they serve) and so forth. I feel that some of my confusion > is stemming from not completely understanding the design as well as > I thought I did. > > Yes. I should have done that. But I didn't do it because I feel some > designs are not fixed. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090112/449eab0f/attachment.html From dgregor at apple.com Mon Jan 12 17:27:10 2009 From: dgregor at apple.com (Douglas Gregor) Date: Mon, 12 Jan 2009 15:27:10 -0800 Subject: [cfe-dev] [Patch] Remove AllowLookup argument to DeclContext::addDecl() In-Reply-To: <7925cd330901111634m4541a141td026ae3d6c07299b@mail.gmail.com> References: <7925cd330901111634m4541a141td026ae3d6c07299b@mail.gmail.com> Message-ID: Hi Piotr, On Jan 11, 2009, at 4:34 PM, Piotr Rak wrote: > Because DeclContext::addDecl() builds lazily lookup structure, > AllowLookup parameter works only when LookupPtr != 0. > To fix it we would have to store it somehow in DeclContext. > However, I noticed that it was no single use with other value that > true. > I think, the best option is to just remove it and assume it is > always true. > In case it would be some cases for it in future, we could just learn > DeclContext::buildLookup() about them. Attached patch removes this > argument. Great, thanks! AllowLookup was a temporary hack that predated the lazy construction of the lookup table. Now, we don't need it. > It also removes needless now ASTContext argument to > DeclContext::addDecl(), > and DeclContext::insert(). Good, good. I've committed this. Thanks! - Doug From fjahanian at apple.com Mon Jan 12 17:28:14 2009 From: fjahanian at apple.com (Fariborz Jahanian) Date: Mon, 12 Jan 2009 15:28:14 -0800 Subject: [cfe-dev] clang is broken In-Reply-To: <64B2EF0E-5FA6-4D29-B3B8-45BCD55C4B8D@apple.com> References: <6a8523d60901111609p7d275921xd6f7cba0327acf91@mail.gmail.com> <08EF4B64-8EB3-4903-B5CE-F414320A4765@apple.com> <64B2EF0E-5FA6-4D29-B3B8-45BCD55C4B8D@apple.com> Message-ID: <0A6E42FD-4698-4CCF-BB41-1ABAA7261966@apple.com> On Jan 12, 2009, at 2:50 PM, Ted Kremenek wrote: > Does this fix the issue for you? Yes it did. - Thanks, Fariborz From dgregor at apple.com Mon Jan 12 17:33:36 2009 From: dgregor at apple.com (Douglas Gregor) Date: Mon, 12 Jan 2009 15:33:36 -0800 Subject: [cfe-dev] [Patch] DeclContext printer In-Reply-To: <5400aeb80901100709r509aa982nfcc216a2209b89e9@mail.gmail.com> References: <5400aeb80901100709r509aa982nfcc216a2209b89e9@mail.gmail.com> Message-ID: Hello Zhongxing, On Jan 10, 2009, at 7:09 AM, Zhongxing Xu wrote: > Hi, > > Attached patch implements an initial framework of a > DeclContextPrinter. It can print DeclContext and its Decls in > indented format. An Example: > > $ cat 3.cpp > class A { > int a; > void f(); > }; > void A::f() { > a = 3; > } > > $ clang -print-decl-contexts 3.cpp > [translation unit] 0x9754d7c > __builtin_va_list > [class] A 0x9753310 > A 0x975ce20 > a > f > A > A > operator= > ~A > [c++ method] f [[0x9753310]] > > Some comments: '<>' indicates a declaration, '[]' indicates a > definition, '[[ ]]' displays the semantic DeclContext which is > different from the lexical DeclContext. > > This visualization should be helpful for DeclContext debugging. Yes, this will definitely be useful for debugging. Please go ahead and commit! - Doug From eli.friedman at gmail.com Mon Jan 12 18:35:20 2009 From: eli.friedman at gmail.com (Eli Friedman) Date: Mon, 12 Jan 2009 16:35:20 -0800 Subject: [cfe-dev] Bugs 2746 and 3261 In-Reply-To: <496BAB34.60502@cs.unipr.it> References: <496B40E0.1000909@cs.unipr.it> <496BAB34.60502@cs.unipr.it> Message-ID: On Mon, Jan 12, 2009 at 12:42 PM, Roberto Bagnara wrote: > Eli Friedman wrote: >> >> On Mon, Jan 12, 2009 at 5:08 AM, Roberto Bagnara >> wrote: >>> >>> These are complete show-stoppers for us. Is there any hope >>> they may be fixed soon? Are there workarounds (even dirty >>> ones) we might use so as to proceed with our work? >>> Many thanks, >> >> PR2746 shouldn't be too hard to implement, it's just that nobody has >> gotten around to it yet. It's just a matter of fixing the cast code >> in Sema to implement additional rules when the destination type is a >> union, and subsequently fixing CodeGen to know how to deal with it. > > Hi Eli, > > thanks for your message. We do not use CodeGen, so perhaps all we need > is to convince Sema (on our local copy) not to reject the code. > Can you please give us instructions on how to achieve that? The relevant code is in Sema::CheckCastTypes. At a minimum, you can add a check like "if (castType->isUnionType()) return false;"; that should let through the code in question with very little work. The proper solution involves checking the legality of the cast; that requires some code to check whether the union has a member which is compatible with the type of the input expression. -Eli From xuzhongxing at gmail.com Mon Jan 12 19:13:58 2009 From: xuzhongxing at gmail.com (Zhongxing Xu) Date: Tue, 13 Jan 2009 09:13:58 +0800 Subject: [cfe-dev] [Patch] add KillStruct() to RegionStore In-Reply-To: <93E5EFF3-729A-4D41-84A0-F2EB60324A1C@apple.com> References: <5400aeb80901080521g28edfbcehbf84a4ca7cf723fc@mail.gmail.com> <2333ADE3-7748-4845-A256-F10D65F7744E@apple.com> <5400aeb80901081736w9e095ebk3c3195313935f50d@mail.gmail.com> <94BB43FA-3086-4085-866B-2E26E85C73C7@apple.com> <5400aeb80901100312y78d6483ap33075831b613d43@mail.gmail.com> <93E5EFF3-729A-4D41-84A0-F2EB60324A1C@apple.com> Message-ID: <5400aeb80901121713t3af7565bhf80a5ad0627a4729@mail.gmail.com> On Tue, Jan 13, 2009 at 7:23 AM, Ted Kremenek wrote: > This looks great! Two comments: > +const GRState* RegionStoreManager::KillStruct(const GRState* St, > + const TypedRegion* R){ > + GRStateRef state(St, StateMgr); > + > + // Kill the struct region because it is assigned "unknown". > + St = state.add(R); > + > + // Set the default value of the struct region to "unknown". > + St = state.set(R, UnknownVal()); > + > + // Remove the struct region from the RegionViews. It could only be a > "view" of > + // its super region. > + St = RemoveRegionView(St, R, R->getSuperRegion()); > > Hmm. I'm looking at this again, I guess removing the view of 'R' from its > super region doesn't make sense. It's just the values bound to 'R' that > change, not the fact that 'R' is a view of its super region. > Yes, that was my initial thought. :-) > > + > + Store store = St->getStore(); > + RegionBindingsTy B = GetRegionBindings(store); > + > + // Remove all bindings for the subregions of the struct. > + for (RegionBindingsTy::iterator I = B.begin(), E = B.end(); I != E; ++I) > { > + const MemRegion* r = I.getKey(); > + if (const SubRegion* sr = dyn_cast(r)) > + if (sr->isSubRegionOf(R)) > + store = Remove(store, Loc::MakeVal(sr)); > > I am wondering if we also need to remove bindings for views of 'sr'. That > is, iterate over the views of 'sr' and remove any bindings from state. What > do you think? I guess it depends on how we decide to bind values in weird > cases where people abuse the type system. > I am afraid the cost would be too high, and the logic be too complex for an initial implementation. After all we are doing an approximate simulation, not an exhaustive one. I suggest we leave a FIXME here and fix it when we see a real bug caused by this simplification. > > + } > + > + return StateMgr.MakeStateWithStore(St, store); > +} > + > > > > On Jan 10, 2009, at 3:12 AM, Zhongxing Xu wrote: > > > > On Sat, Jan 10, 2009 at 3:46 PM, Ted Kremenek wrote: > >> On Jan 8, 2009, at 5:36 PM, Zhongxing Xu wrote: >> >> Index: lib/Analysis/RegionStore.cpp >>> =================================================================== >>> --- lib/Analysis/RegionStore.cpp ??? 61900? >>> >>> >>> + if (V.isUnknown()) >>> + return KillStruct(St, R); >>> + >>> >>> When precisely can V.isUnknown() be true when the value is a struct? >>> (test case please). >>> >>> We already have that test case. It is the f5() in >>> test/Analysis/array-struct.c. >>> >> >> Great! We should add a comment to that test case the says what part of >> the analyzer/region store is getting tested. > > > Done. > > >> >> >> +const GRState* RegionStoreManager::KillStruct(const GRState* St, >>> + const TypedRegion* R){ >>> + GRStateRef state(St, StateMgr); >>> + // Set the default value of the struct region to UnknownVal. >>> + St = state.set(R, UnknownVal()); >>> >>> Interesting. Do we need the killset anymore, or are we going to model >>> "killed values" in this way? >>> >>> I think we still need killset. The regions in killset are ones we query >>> its binding directly. The regions in RegionDefaultValue are ones whose >>> subregions we query bindings for. I haven't had a way to combine them. >>> >> >> I believe I might be confused about some basic concepts. Here is how I >> interpreted things. >> >> The "killset" is part of the state, and represents those regions whose >> values have been changed (via direct assignment) after the entry to the >> analyzed function. This way we don't need to explicitly bind initial values >> to regions and instead lazily infer their bindings. >> >> According to comments in RegionStore, the "default value" map >> (RegionDefaultValue) is used to track "what regions have a default value of >> 0 if they have no bound value and have not been killed." >> >> From the patch I see 'KillStruct' being used in the following way: >> >> const GRState* >> RegionStoreManager::BindStruct(const GRState* St, const TypedRegion* R, >> SVal V){ >> // FIXME: Verify that we should use getRValueType or getLValueType. >> QualType T = R->getRValueType(getContext()); >> assert(T->isStructureType()); >> >> RecordType* RT = cast(T.getTypePtr()); >> RecordDecl* RD = RT->getDecl(); >> assert(RD->isDefinition()); >> >> if (V.isUnknown()) >> return KillStruct(St, R) >> ... >> >> Two things occur to me: >> >> (1) We should always be adding any region directly assigned to the >> killset. Doesn't that include structs? > > > Yes. I thought we would never query a struct region's binding like we never > do it to an array region. But later I realized I was wrong. I've done this > step in the new patch. > > And, I think we should add a region to the killset *only* when it is > assigned "unknown" directly. Because if it is assigned other value, we would > have its binding in the region bindings. It is redundant to add it to the > killset. > > >> >> >> (2) After assigning the value "unknown" to the struct, the values of its >> fields should not be 0 (as indicated by the comments for >> RegionDefaultValue). That doesn't make sense to me. Shouldn't they just be >> "unknown"? >> >> In other words, regardless of whether V.isUnknown() == true (in the above >> code snippet) we should always do (1) and then just remove any bindings to >> struct and it's fields. Adding entries to RegionDefaultValue (i.e., (2)) >> doesn't make sense to me, so I think I'm just missing something and don't >> really understand the overall design. > > > RegionDefaultValue was originally designed to include regions which have > default values of 0. But later I find we could have default values other > than 0. This is just a case that we need it, since we would query the > bindings of the subregions of the struct region that is killed (assigned > "unknown"). If we don't set the struct region's default value, we would have > to add all subregions of the struct region to the killset. Now that we set > the struct region's default value, we can just remove the subregions of the > struct region from RegionBindings. > > >> >> >> Ah, I forgot that point. Is this also known as persistent data structure? >>> >> >> Yes it is. The term "purely functional data structures" comes from the >> functional programming mindset. Okasaki has an excellent book on that >> topic: >> >> >> http://books.google.com/books?id=SxPzSTcTalAC&dq=purely+functional+data+structures&printsec=frontcover&source=bn&hl=en&sa=X&oi=book_result&resnum=4&ct=result > > > Thanks. > > >> >> >> >> >>> Do we also need to remove region views for the regions that are killed, >>> or should we dispense with that GDM entry entirely? >>> >>> I think region views are orthogonal to this one. Region views are used to >>> cast region back and forth between typed and untyped ones. Here we only >>> handle the region bindings. >>> >> >> "Views" are just a specific type of subregions (whose bindings are all >> getting nuked by KillStruct). The GDM entry "RegionViews" is just a >> back-mapping from a region to its subregions. If we remove all of those >> bindings why do we need to keep that backmapping around since none of them >> bind to any value? Removing stale data from the state allows better >> caching. > > > Yes, I've done this in the new patch. > > >> >> >> As a meta comment, it would probably be good to add comments to the top of >> RegionStore that documents the overall design. More specifically, we should >> mention how the different GDM pieces are used, what's the overall >> abstraction of how regions bind to values, how we model "views" of regions >> (i.e., what they are and what purpose they serve) and so forth. I feel that >> some of my confusion is stemming from not completely understanding the >> design as well as I thought I did. > > > Yes. I should have done that. But I didn't do it because I feel some > designs are not fixed. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090113/bb73dc99/attachment-0001.html From kremenek at apple.com Mon Jan 12 19:34:30 2009 From: kremenek at apple.com (Ted Kremenek) Date: Mon, 12 Jan 2009 17:34:30 -0800 Subject: [cfe-dev] [Patch] add KillStruct() to RegionStore In-Reply-To: <5400aeb80901121713t3af7565bhf80a5ad0627a4729@mail.gmail.com> References: <5400aeb80901080521g28edfbcehbf84a4ca7cf723fc@mail.gmail.com> <2333ADE3-7748-4845-A256-F10D65F7744E@apple.com> <5400aeb80901081736w9e095ebk3c3195313935f50d@mail.gmail.com> <94BB43FA-3086-4085-866B-2E26E85C73C7@apple.com> <5400aeb80901100312y78d6483ap33075831b613d43@mail.gmail.com> <93E5EFF3-729A-4D41-84A0-F2EB60324A1C@apple.com> <5400aeb80901121713t3af7565bhf80a5ad0627a4729@mail.gmail.com> Message-ID: <3B8D0301-7FE8-4027-9505-0F0B289818A6@apple.com> On Jan 12, 2009, at 5:13 PM, Zhongxing Xu wrote: > > On Tue, Jan 13, 2009 at 7:23 AM, Ted Kremenek > wrote: > This looks great! Two comments: > > +const GRState* RegionStoreManager::KillStruct(const GRState* St, > + const TypedRegion* R){ > + GRStateRef state(St, StateMgr); > + > + // Kill the struct region because it is assigned "unknown". > + St = state.add(R); > + > + // Set the default value of the struct region to "unknown". > + St = state.set(R, UnknownVal()); > + > + // Remove the struct region from the RegionViews. It could only > be a "view" of > + // its super region. > + St = RemoveRegionView(St, R, R->getSuperRegion()); > > Hmm. I'm looking at this again, I guess removing the view of 'R' > from its super region doesn't make sense. It's just the values > bound to 'R' that change, not the fact that 'R' is a view of its > super region. > > Yes, that was my initial thought. :-) Indeed it was. ;-) > > > > + > + Store store = St->getStore(); > + RegionBindingsTy B = GetRegionBindings(store); > + > + // Remove all bindings for the subregions of the struct. > + for (RegionBindingsTy::iterator I = B.begin(), E = B.end(); I != > E; ++I) { > + const MemRegion* r = I.getKey(); > + if (const SubRegion* sr = dyn_cast(r)) > + if (sr->isSubRegionOf(R)) > + store = Remove(store, Loc::MakeVal(sr)); > > I am wondering if we also need to remove bindings for views of > 'sr'. That is, iterate over the views of 'sr' and remove any > bindings from state. What do you think? I guess it depends on how > we decide to bind values in weird cases where people abuse the type > system. > > I am afraid the cost would be too high, and the logic be too complex > for an initial implementation. After all we are doing an approximate > simulation, not an exhaustive one. I suggest we leave a FIXME here > and fix it when we see a real bug caused by this simplification. Makes sense. Please take out the RemoveRegionView call (but go ahead and add the method itself) and commit the change. > > > > + } > + > + return StateMgr.MakeStateWithStore(St, store); > +} > + -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090112/d6d4e2ba/attachment.html From spellegrini at dps.uibk.ac.at Tue Jan 13 04:08:56 2009 From: spellegrini at dps.uibk.ac.at (Simone Pellegrini) Date: Tue, 13 Jan 2009 11:08:56 +0100 Subject: [cfe-dev] From LLVM Bytecode to C source Message-ID: <496C6838.50408@dps.uibk.ac.at> I wonder to know if there is any chance to convert back emitted LLVM bytecode into a C source file using clang (or any other existing tool) Thanks, S. Pellegrini From sebastian.redl at getdesigned.at Tue Jan 13 04:53:57 2009 From: sebastian.redl at getdesigned.at (Sebastian Redl) Date: Tue, 13 Jan 2009 11:53:57 +0100 Subject: [cfe-dev] From LLVM Bytecode to C source In-Reply-To: <496C6838.50408@dps.uibk.ac.at> References: <496C6838.50408@dps.uibk.ac.at> Message-ID: <47ac1ed0bbb1cf9714aacc455b28b881@localhost> On Tue, 13 Jan 2009 11:08:56 +0100, Simone Pellegrini wrote: > I wonder to know if there is any chance to convert back emitted LLVM > bytecode into a C source file using clang (or any other existing tool) LLVM itself can compile to C code. But you probably won't get back something that really resembles the original code. Sebastian From eli.friedman at gmail.com Tue Jan 13 04:56:00 2009 From: eli.friedman at gmail.com (Eli Friedman) Date: Tue, 13 Jan 2009 02:56:00 -0800 Subject: [cfe-dev] From LLVM Bytecode to C source In-Reply-To: <496C6838.50408@dps.uibk.ac.at> References: <496C6838.50408@dps.uibk.ac.at> Message-ID: On Tue, Jan 13, 2009 at 2:08 AM, Simone Pellegrini wrote: > I wonder to know if there is any chance to convert back emitted LLVM > bytecode into a C source file using clang (or any other existing tool) clang definitely isn't going to help you here. One thing you can do is use the LLVM C backend, which can be invoked using "llc -march=c"; the result isn't pretty, but if the original code is C code, the output is usually accurate enough that the result can be compiled and run with gcc. -Eli From lujiandong1001 at yahoo.com.cn Tue Jan 13 06:06:34 2009 From: lujiandong1001 at yahoo.com.cn (Jiandong Lu) Date: Tue, 13 Jan 2009 20:06:34 +0800 (CST) Subject: [cfe-dev] failed to compile clange on FreeBSD7.1 Message-ID: <223487.82548.qm@web15708.mail.cnb.yahoo.com> hi,everyone,as the 'getting started ' page http://clang.llvm.org/get_started.html says ,I check out llvm ,and compile it succssfully. then I checked out clang source files. I run commands: touch empty.c; gcc -v empty.c -fsyntax-only its output is : " Using built-in specs. Target: i386-undermydesk-freebsd Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 4.2.1 20070719? [FreeBSD] ?/usr/libexec/cc1 -quiet -v -D_LONGLONG empty.c -quiet -dumpbase empty.c -auxbase empty -version -fsyntax-only -o /dev/null ignoring duplicate directory "/usr/include" #include "..." search starts here: #include <...> search starts here: ?/usr/include End of search list. GNU C version 4.2.1 20070719? [FreeBSD] (i386-undermydesk-freebsd) ??????? compiled by GNU C version 4.2.1 20070719? [FreeBSD]. GGC heuristics: --param ggc-min-expand=46 --param ggc-min-heapsize=31156 Compiler executable checksum: 5208351120a90a18f603e3b485bf8c2b " I append this statement: ??? //FreeBSD ??? AddPath("/usr/include", System, true, false, false); to function void InitHeaderSearch::AddDefaultSystemIncludePaths(const LangOptions &Lang) in file clang/lib/Driver/InitHeaderSearch.cpp then gmake clang,it failed.Its output is "llvm[2]: Compiling CGExprConstant.cpp for Debug build CGExprConstant.cpp: In member function 'llvm::Constant*::ConstExprEmitter::EmitUnionInitialization(clang::InitListExpr*)': CGExprConstant.cpp:241: error: 'const class llvm::TargetData' has no member named 'getTypePaddedSize' gmake[2]: *** [/usr/home/lujd/projects/llvm/tools/clang/lib/CodeGen/Debug/CGExprConstant.o] Error 1 gmake[2]: Leaving directory `/usr/home/lujd/projects/llvm/tools/clang/lib/CodeGen' gmake[1]: *** [CodeGen/.makeall] Error 2 gmake[1]: Leaving directory `/usr/home/lujd/projects/llvm/tools/clang/lib' gmake: *** [all] Error 1" Please help me.Thanks. ___________________________________________________________ ????????????????? http://card.mail.cn.yahoo.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090113/f580dd65/attachment.html From dgregor at apple.com Tue Jan 13 10:03:20 2009 From: dgregor at apple.com (Douglas Gregor) Date: Tue, 13 Jan 2009 08:03:20 -0800 Subject: [cfe-dev] failed to compile clange on FreeBSD7.1 In-Reply-To: <223487.82548.qm@web15708.mail.cnb.yahoo.com> References: <223487.82548.qm@web15708.mail.cnb.yahoo.com> Message-ID: On Jan 13, 2009, at 4:06 AM, Jiandong Lu wrote: > > void InitHeaderSearch::AddDefaultSystemIncludePaths(const > LangOptions &Lang) > in file clang/lib/Driver/InitHeaderSearch.cpp > then gmake clang,it failed.Its output is > "llvm[2]: Compiling CGExprConstant.cpp for Debug build > CGExprConstant.cpp: In member function > 'llvm > ::Constant > *< > unnamed > >::ConstExprEmitter::EmitUnionInitialization(clang::InitListExpr*)': > CGExprConstant.cpp:241: error: 'const class llvm::TargetData' has no > member named 'getTypePaddedSize' > gmake[2]: *** [/usr/home/lujd/projects/llvm/tools/clang/lib/CodeGen/ > Debug/CGExprConstant.o] Error 1 > gmake[2]: Leaving directory `/usr/home/lujd/projects/llvm/tools/ > clang/lib/CodeGen' > gmake[1]: *** [CodeGen/.makeall] Error 2 > gmake[1]: Leaving directory `/usr/home/lujd/projects/llvm/tools/ > clang/lib' > gmake: *** [all] Error 1" You need to update to the latest LLVM in Subversion. - Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090113/d0cb3c8c/attachment-0001.html From bolzoni at cs.unipr.it Tue Jan 13 10:24:49 2009 From: bolzoni at cs.unipr.it (Paolo Bolzoni) Date: Tue, 13 Jan 2009 17:24:49 +0100 Subject: [cfe-dev] Bugs 2746 and 3261 In-Reply-To: <496BAB34.60502@cs.unipr.it> References: <496B40E0.1000909@cs.unipr.it> <496BAB34.60502@cs.unipr.it> Message-ID: <20090113172449.20cc2db3@cs.unipr.it> On Mon, 12 Jan 2009 21:42:28 +0100 Roberto Bagnara wrote: > > For PR3261, I'm not sure, but you might be able to pull some tricks > > with location information. > > Paolo, can you please look at that? I am not sure that Eli meant, types do not have location information (at least in the form of SourceLocation). So when I am visiting a enum or struct type and I use getDecl(), I can get the source location from the declaration, but I can't know if the source point is where I am or not. Am I wrong? pb From bagnara at cs.unipr.it Tue Jan 13 10:30:02 2009 From: bagnara at cs.unipr.it (Roberto Bagnara) Date: Tue, 13 Jan 2009 17:30:02 +0100 Subject: [cfe-dev] Bugs 2746 and 3261 In-Reply-To: References: <496B40E0.1000909@cs.unipr.it> <496BAB34.60502@cs.unipr.it> Message-ID: <496CC18A.8050007@cs.unipr.it> Eli Friedman wrote: > On Mon, Jan 12, 2009 at 12:42 PM, Roberto Bagnara wrote: >> Eli Friedman wrote: >>> On Mon, Jan 12, 2009 at 5:08 AM, Roberto Bagnara >>> wrote: >>>> These are complete show-stoppers for us. Is there any hope >>>> they may be fixed soon? Are there workarounds (even dirty >>>> ones) we might use so as to proceed with our work? >>>> Many thanks, >>> PR2746 shouldn't be too hard to implement, it's just that nobody has >>> gotten around to it yet. It's just a matter of fixing the cast code >>> in Sema to implement additional rules when the destination type is a >>> union, and subsequently fixing CodeGen to know how to deal with it. >> Hi Eli, >> >> thanks for your message. We do not use CodeGen, so perhaps all we need >> is to convince Sema (on our local copy) not to reject the code. >> Can you please give us instructions on how to achieve that? > > The relevant code is in Sema::CheckCastTypes. At a minimum, you can > add a check like "if (castType->isUnionType()) return false;"; that > should let through the code in question with very little work. The > proper solution involves checking the legality of the cast; that > requires some code to check whether the union has a member which is > compatible with the type of the input expression. Hi Eli, why should we restrict to unions? For instance, the following testcase is a simplified one coming from vstfpd-0.9.2: struct S { int one; int two; }; struct S const foo(void) ; struct S tmp ; void priv_sock_init() { tmp = (struct S) foo(); } All the best, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara at cs.unipr.it From andersca at mac.com Tue Jan 13 10:40:49 2009 From: andersca at mac.com (Anders Carlsson) Date: Tue, 13 Jan 2009 08:40:49 -0800 Subject: [cfe-dev] Bugs 2746 and 3261 In-Reply-To: <496CC18A.8050007@cs.unipr.it> References: <496B40E0.1000909@cs.unipr.it> <496BAB34.60502@cs.unipr.it> <496CC18A.8050007@cs.unipr.it> Message-ID: <64EA3215-E853-4818-88B2-556F11DE1E43@mac.com> 13 jan 2009 kl. 08.30 skrev Roberto Bagnara: > > Hi Eli, > > why should we restrict to unions? For instance, the following > testcase is a simplified one coming from vstfpd-0.9.2: > > struct S { > int one; > int two; > }; > > struct S const foo(void) ; > > struct S tmp ; > > void priv_sock_init() { > tmp = (struct S) foo(); > } > > All the best, > > Roberto Hi Roberto, I think the fix for the above test would be something like Index: lib/Sema/SemaExpr.cpp =================================================================== --- lib/Sema/SemaExpr.cpp (revision 62169) +++ lib/Sema/SemaExpr.cpp (working copy) @@ -1912,8 +1912,8 @@ // We can't check any more until template instantiation time. } else if (!castType->isScalarType() && !castType->isVectorType()) { // GCC struct/union extension: allow cast to self. - if (Context.getCanonicalType(castType) != - Context.getCanonicalType(castExpr->getType()) || + if (Context.getCanonicalType(castType).getUnqualifiedType() != + Context.getCanonicalType(castExpr- >getType().getUnqualifiedType()) || (!castType->isStructureType() && !castType->isUnionType())) { // Reject any other conversions to non-scalar types. return Diag(TyR.getBegin(), diag::err_typecheck_cond_expect_scalar) Anders From dgregor at apple.com Tue Jan 13 10:50:47 2009 From: dgregor at apple.com (Douglas Gregor) Date: Tue, 13 Jan 2009 08:50:47 -0800 Subject: [cfe-dev] Bugs 2746 and 3261 In-Reply-To: <64EA3215-E853-4818-88B2-556F11DE1E43@mac.com> References: <496B40E0.1000909@cs.unipr.it> <496BAB34.60502@cs.unipr.it> <496CC18A.8050007@cs.unipr.it> <64EA3215-E853-4818-88B2-556F11DE1E43@mac.com> Message-ID: <90E94F36-3038-48B2-8128-9ABBA6CE69E0@apple.com> On Jan 13, 2009, at 8:40 AM, Anders Carlsson wrote: > 13 jan 2009 kl. 08.30 skrev Roberto Bagnara: >> >> Hi Eli, >> >> why should we restrict to unions? For instance, the following >> testcase is a simplified one coming from vstfpd-0.9.2: >> >> struct S { >> int one; >> int two; >> }; >> >> struct S const foo(void) ; >> >> struct S tmp ; >> >> void priv_sock_init() { >> tmp = (struct S) foo(); >> } >> >> All the best, >> >> Roberto > > Hi Roberto, > > I think the fix for the above test would be something like > Index: lib/Sema/SemaExpr.cpp > =================================================================== > --- lib/Sema/SemaExpr.cpp (revision 62169) > +++ lib/Sema/SemaExpr.cpp (working copy) > @@ -1912,8 +1912,8 @@ > // We can't check any more until template instantiation time. > } else if (!castType->isScalarType() && !castType->isVectorType > ()) { > // GCC struct/union extension: allow cast to self. > - if (Context.getCanonicalType(castType) != > - Context.getCanonicalType(castExpr->getType()) || > + if (Context.getCanonicalType(castType).getUnqualifiedType() != > + Context.getCanonicalType(castExpr- >> getType().getUnqualifiedType()) || > (!castType->isStructureType() && !castType->isUnionType())) { > // Reject any other conversions to non-scalar types. > return Diag(TyR.getBegin(), > diag::err_typecheck_cond_expect_scalar) Yep, that'll do it. Please go ahead and commit. - Doug From alexei.svitkine at gmail.com Tue Jan 13 12:38:50 2009 From: alexei.svitkine at gmail.com (Alexei Svitkine) Date: Tue, 13 Jan 2009 13:38:50 -0500 Subject: [cfe-dev] ExprLoc of ArraySubscriptExpr wrong? Message-ID: <62d9ffc00901131038m33e66cekc7ea62a09702d55b@mail.gmail.com> I have an ArraySubscriptExpr that looks like this: argv[0]; Which becomes to: (ArraySubscriptExpr 0x1c06d70 'char *' (DeclRefExpr 0x1c06d30 'char **' ParmVar='argv' 0x1c06c50) (IntegerLiteral 0x1c06d50 'int' 0)) When I call getExprLoc().getRawFilePos() on this, I get the location that corresponds to the "]" in argv[0]; which seems inconsistent with other Exprs which give the start the of the expression instead. Is this a bug? -Alexei From eli.friedman at gmail.com Tue Jan 13 13:08:47 2009 From: eli.friedman at gmail.com (Eli Friedman) Date: Tue, 13 Jan 2009 11:08:47 -0800 Subject: [cfe-dev] Bugs 2746 and 3261 In-Reply-To: <20090113172449.20cc2db3@cs.unipr.it> References: <496B40E0.1000909@cs.unipr.it> <496BAB34.60502@cs.unipr.it> <20090113172449.20cc2db3@cs.unipr.it> Message-ID: On Tue, Jan 13, 2009 at 8:24 AM, Paolo Bolzoni wrote: > On Mon, 12 Jan 2009 21:42:28 +0100 > Roberto Bagnara wrote: > >> > For PR3261, I'm not sure, but you might be able to pull some tricks >> > with location information. >> >> Paolo, can you please look at that? > > I am not sure that Eli meant, types do not have location information (at > least in the form of SourceLocation). > > So when I am visiting a enum or struct type and I use getDecl(), I can get > the source location from the declaration, but I can't know if the source > point is where I am or not. > > Am I wrong? No, but a type doesn't exist by itself; there should be an associated declaration or expression you can get the current source location from. -Eli From clattner at apple.com Tue Jan 13 15:14:15 2009 From: clattner at apple.com (Chris Lattner) Date: Tue, 13 Jan 2009 13:14:15 -0800 Subject: [cfe-dev] ExprLoc of ArraySubscriptExpr wrong? In-Reply-To: <62d9ffc00901131038m33e66cekc7ea62a09702d55b@mail.gmail.com> References: <62d9ffc00901131038m33e66cekc7ea62a09702d55b@mail.gmail.com> Message-ID: <230751E5-3891-4385-BF82-F6E0BF3EB1B2@apple.com> On Jan 13, 2009, at 10:38 AM, Alexei Svitkine wrote: > I have an ArraySubscriptExpr that looks like this: > > argv[0]; > > Which becomes to: > > (ArraySubscriptExpr 0x1c06d70 'char *' > (DeclRefExpr 0x1c06d30 'char **' ParmVar='argv' 0x1c06c50) > (IntegerLiteral 0x1c06d50 'int' 0)) > > When I call getExprLoc().getRawFilePos() on this, I get the location > that corresponds to the "]" in argv[0]; which seems inconsistent with > other Exprs which give the start the of the expression instead. I agree that that location didn't make a lot of sense. I changed it here: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20090112/010814.html However, note that this API is pretty poorly defined. I'd strongly prefer to change the existing clients of it to pass up a reasonable location in their recursive walk when possible, and use that instead. In other words, wouldn't suggest building on this API. -Chris From alexei.svitkine at gmail.com Tue Jan 13 15:55:37 2009 From: alexei.svitkine at gmail.com (Alexei Svitkine) Date: Tue, 13 Jan 2009 16:55:37 -0500 Subject: [cfe-dev] Crash in TagType::getAsString() Message-ID: <62d9ffc00901131355v2be830b2r553963e99bf144f4@mail.gmail.com> I have the following input: int main(void) { struct X { int a, b; }; struct X x; x; return 0; } Which becomes: (CompoundStmt 0x1c087c0 (DeclStmt 0x1c086f0 0x1c08580 "struct X;" (DeclStmt 0x1c08740 0x1c08710 "struct X x" (DeclRefExpr 0x1c08770 'struct X' Var='x' 0x1c08710) (ReturnStmt 0x1c087b0 (IntegerLiteral 0x1c08790 'int' 0))) Now when I take the DeclRefExpr and call getType().getAsString(), I get a crash: clang::TagType::getAsStringInternal (this=0x1c0a080, InnerString=@0xbffff62c) at Type.cpp:1148 It seems that "getDecl()->getIdentifier()->getName()" on TagType returns something invalid. Interestingly, the dump shows "struct X" just fine, so perhaps it's another user error on my part... though this time I am retaining the AST and I am getting correct results with other inputs... -Alexei From alexei.svitkine at gmail.com Tue Jan 13 22:39:51 2009 From: alexei.svitkine at gmail.com (Alexei Svitkine) Date: Tue, 13 Jan 2009 23:39:51 -0500 Subject: [cfe-dev] Crash in TagType::getAsString() In-Reply-To: <62d9ffc00901131355v2be830b2r553963e99bf144f4@mail.gmail.com> References: <62d9ffc00901131355v2be830b2r553963e99bf144f4@mail.gmail.com> Message-ID: <62d9ffc00901132039o1a7ff92bqa6ef12962ab987fb@mail.gmail.com> As a side note: > (CompoundStmt 0x1c087c0 > (DeclStmt 0x1c086f0 > 0x1c08580 "struct X;" > (DeclStmt 0x1c08740 > 0x1c08710 "struct X x" > (DeclRefExpr 0x1c08770 'struct X' Var='x' 0x1c08710) > (ReturnStmt 0x1c087b0 > (IntegerLiteral 0x1c08790 'int' 0))) ... doesn't seem to have balanced parentheses. From alexei.svitkine at gmail.com Tue Jan 13 23:29:13 2009 From: alexei.svitkine at gmail.com (Alexei Svitkine) Date: Wed, 14 Jan 2009 00:29:13 -0500 Subject: [cfe-dev] Crash in TagType::getAsString() In-Reply-To: <62d9ffc00901132039o1a7ff92bqa6ef12962ab987fb@mail.gmail.com> References: <62d9ffc00901131355v2be830b2r553963e99bf144f4@mail.gmail.com> <62d9ffc00901132039o1a7ff92bqa6ef12962ab987fb@mail.gmail.com> Message-ID: <62d9ffc00901132129o6beed29aufcb461dffc672cda@mail.gmail.com> Ok I figured out my problem. Turns out the Preprocessor owns the IdentifierTable and I wasn't keeping the Preprocessor around. Are there any docs on what parts of the AST are owned by what? Also, is there any way to get at the objects allocated by ParseAST if the FreeMemory argument is false, so that I can delete them when I am done with them? Is there a reason that there isn't a self-contained AST object that contains and owns everything necessary, rather than having different parts of it owned by different classes? It seems weird to me that the Preprocessor would retain ownership to something used by the AST. To me, the name Preprocessor suggests that its purpose it to preprocess the code, and I shouldn't need to keep it around after that's done (but evidently that's not the case). Sorry if there is a good reason to keep it this way, and I am just missing it. -Alexei From snaroff at apple.com Wed Jan 14 00:34:29 2009 From: snaroff at apple.com (steve naroff) Date: Tue, 13 Jan 2009 22:34:29 -0800 Subject: [cfe-dev] Crash in TagType::getAsString() In-Reply-To: <62d9ffc00901132129o6beed29aufcb461dffc672cda@mail.gmail.com> References: <62d9ffc00901131355v2be830b2r553963e99bf144f4@mail.gmail.com> <62d9ffc00901132039o1a7ff92bqa6ef12962ab987fb@mail.gmail.com> <62d9ffc00901132129o6beed29aufcb461dffc672cda@mail.gmail.com> Message-ID: Hi Alexei, Some brief comments... On Jan 13, 2009, at 9:29 PM, Alexei Svitkine wrote: > Ok I figured out my problem. > > Turns out the Preprocessor owns the IdentifierTable and I wasn't > keeping the Preprocessor around. > Are there any docs on what parts of the AST are owned by what? Also, > is there any way to get at the objects allocated by ParseAST if the > FreeMemory argument is false, so that I can delete them when I am done > with them? > Nope. It looks like ASTContext and TranslationUnit should be passed into ParseAST. This would give the client much more flexibility (and enable us to remove the "FreeMemory" argument). > Is there a reason that there isn't a self-contained AST object that > contains and owns everything necessary, rather than having different > parts of it owned by different classes? > > It seems weird to me that the Preprocessor would retain ownership to > something used by the AST. To me, the name Preprocessor suggests that > its purpose it to preprocess the code, and I shouldn't need to keep it > around after that's done (but evidently that's not the case). It is weird (and needs to be refined). The good news is core objects (like ASTContext) don't depend on having a Preprocessor object. So fixing this should be straightforward/localized. snaroff > Sorry if there is a good reason to keep it this way, and I am just > missing it. > > -Alexei > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From piotr.rak at gmail.com Wed Jan 14 14:17:32 2009 From: piotr.rak at gmail.com (Piotr Rak) Date: Wed, 14 Jan 2009 21:17:32 +0100 Subject: [cfe-dev] [Patch] IDNS_NoLookup? Message-ID: <7925cd330901141217j6aa49672p4917d76b01e3fabc@mail.gmail.com> Hi, I would like to introduce new identifier namespace, which would cause ScopedDecl not be added to DeclContext lookup structure. Currently it IdentifierResolver saves us somehow from building lookup structure for TranslationUnit, however, as i mentioned few weeks earlier I store using-directives in lookup structure. This causes it to be build for TranslationUnitDecl too in my local copy. This fails for ObjCImplementation (there might be more somewhere in ObjC code, not really sure...), which has associated name but getIdentifierNamespace is not defined for it. I could probably workaround it, but this way feels `less hackish`. Please note that this change also saves from crash client code, that would call TranslationUnitDecl::lookup(), when it owns ObjCImplementationDecls. Attached tiny diff with that change. Piotr -------------- next part -------------- A non-text attachment was scrubbed... Name: IDNS_NoLookup.diff Type: text/x-patch Size: 1076 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090114/435ec023/attachment.bin From eli.friedman at gmail.com Wed Jan 14 14:59:52 2009 From: eli.friedman at gmail.com (Eli Friedman) Date: Wed, 14 Jan 2009 12:59:52 -0800 Subject: [cfe-dev] Bugs 2746 and 3261 In-Reply-To: <20090114162929.118dc9bc@cs.unipr.it> References: <496B40E0.1000909@cs.unipr.it> <496BAB34.60502@cs.unipr.it> <20090113172449.20cc2db3@cs.unipr.it> <20090114162929.118dc9bc@cs.unipr.it> Message-ID: On Wed, Jan 14, 2009 at 7:29 AM, Paolo Bolzoni wrote: > Let's see a simple but evocative example. > I have the clang AST of this code segment. > > Using the function that overrides > HandleTranslationUnit(clang::TranslationUnit&) > I want to pretty print: > > Here the code: > struct B; > > struct A { > struct B* b; > }; > > struct B { > struct A* a; > }; Okay, so at this point, all types are defined, so isDefinition() returns true, so you can't figure out whether it was defined at a certain point. > The tree has three RecordDecl, visiting the first and pretty printing is easy. > But when I am in the second, isDefinition() returns true and I loop in the > field declarations; for each I get field name, if it is a bitfield and > eventually the related expression and a type. > The type is struct B (pointer a part), even if I recall the SourceLocation of > the FieldDecl (or the including RecordDecl) while visiting the type, how can I > know that the declaration is not actually there? The approach I was thinking of is something like the following: suppose you're trying to pretty-print the "struct B* b;" bit. Let S designate the location immediately before the keyword "struct", let E designate the location immediately after the semicolon, and let D designate the beginning of the definition of struct B. We can conclude that "struct B* b;" doesn't contain the definition of B by looking at the locations: D is after E, so the field declaration cannot contain the definition. Similar reasoning applies for "struct A* a;"; let S to E be the field declaration, and let D be the beginning of the definition of struct A. D is before S, so the field declaration doesn't contain the definition. Unfortunately, though, there isn't any easy way to compare source locations like that; it should be possible, I think, but I don't know the details of how to write it. Also, I'm not sure if you can get the relevant source locations easily, particularly S. I think ongoing work with DeclGroups will help here eventually, but I'm not sure of the details. There is another possible approach: take the location of the beginning of the first declarator in the declaration (the "*b" bit), and scan backwards through the source code to see if you find a "}" before the first occurrence of the "struct" keyword. It's quite messy in terms of layering, and I'm not sure how preprocessor stuff would factor into it, but I think it's feasible. I don't know the details here either, but I remember reading that the ObjC rewriter does some similar stuff. I'm putting cfe-dev back onto the CC list so that people more familiar with this stuff can comment; this is really outside the stuff I've really tried. -Eli From snaroff at apple.com Wed Jan 14 18:09:13 2009 From: snaroff at apple.com (steve naroff) Date: Wed, 14 Jan 2009 16:09:13 -0800 Subject: [cfe-dev] win32/llvm.sln, win32/clang.sln Message-ID: Folks, Is anyone still using the Visual Studio solution files in the win32 directory? If they aren't being maintained, they should probably be removed (to avoid any confusion). Thanks for any feedback, snaroff From rmann at latencyzero.com Wed Jan 14 19:38:06 2009 From: rmann at latencyzero.com (Rick Mann) Date: Wed, 14 Jan 2009 17:38:06 -0800 Subject: [cfe-dev] Seeking guidance to implement a new __attribute__ and implicit function parameter Message-ID: <930D5983-833F-4A85-9392-E6F6BF9F261A@latencyzero.com> Hi. As an experiment, and as a way of familiarizing myself with clang's internals, I'd like to implement an extension to provide attributed functions (and methods) with call site information. The primary use for this is for diagnostic logging. What I envision is this. You declare a function with an __attribute__, perhaps like this: void FancyLog(const char* inFormat, ...) __attribute__((call_site_info(callInfo))); And in the implementation, you can reference an implicit parameter named "callInfo" (the implementor can choose whatever name they want; maybe the attribute must be repeated on the function's implementation to get the actual parameter name): 1 void FancyLog(const char* inFormat, ...) __attribute__((call_site_info(callInfo))) 2 { 3 printf("Got called from %s:%lu, func: %s: %s\n", callInfo- >file, callInfo->line, callInfo->prettyFunc, inFormat); 4 } The function is called based on its formal parameter list: 6 int main() 7 { 8 FancyLog("Now is the time %d %2\n", 1, 2); 9 } And the output generated would be something like: Got called from main.c:3 main(): Now is the time 1 2 callInfo is a pointer to a clang-provided struct that looks something like: struct __call_site_loc_info { const char* file; uint32_t line; const char* prettyFunc; }; Obviously I've left out some details, but here's what I need to do: a) parse the new attribute and store the information (the fact that a function is to get this implicit parameter, the parameter's name) with the function information within clang's state b) Parse the attribute at the function definition, to get the actual parameter name. c) At each call site, allocate a __call_site_loc_info object on the stack, set the members appropriately (not sure where the __FILE__ and __PRETTY_FUNC__ strings end up, but I'd like to use those), d) Create the implicit parameter pointing to the __call_site_loc_info struct. If someone could point me at the right parts of clang to look at, I'd love to experiment with this extension. I've had a bit of discussion with Alex Rosenberg and others on this topic, and I agree that this probably isn't the best formal solution moving forward, but I think it makes for a good experiment, and a GREAT exercise for me in clang. Any guidance would be much appreciated! Thanks! -- Rick From sanxiyn at gmail.com Wed Jan 14 20:43:08 2009 From: sanxiyn at gmail.com (Seo Sanghyeon) Date: Thu, 15 Jan 2009 11:43:08 +0900 Subject: [cfe-dev] Cast to union Message-ID: <5b0248170901141843l417650e6w95ab0b9d4ae85da9@mail.gmail.com> Attached patch implements GCC cast to union extension, fixing PR2746. -- Seo Sanghyeon -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cast-to-union.txt Url: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090115/c6cd0407/attachment.txt From eli.friedman at gmail.com Wed Jan 14 22:06:22 2009 From: eli.friedman at gmail.com (Eli Friedman) Date: Wed, 14 Jan 2009 20:06:22 -0800 Subject: [cfe-dev] Cast to union In-Reply-To: <5b0248170901141843l417650e6w95ab0b9d4ae85da9@mail.gmail.com> References: <5b0248170901141843l417650e6w95ab0b9d4ae85da9@mail.gmail.com> Message-ID: On Wed, Jan 14, 2009 at 6:43 PM, Seo Sanghyeon wrote: > Attached patch implements GCC cast to union extension, fixing PR2746. Ah, I guess it was even easier than I thought. I don't see any serious issues with the patch. Although, from visual inspection, I think your patch doesn't handle the following "correctly"; I think the call to UsualUnaryConversions at the beginning of Sema::CheckCastTypes needs to be changed to a call to DefaultFunctionArrayConversion, or some similar change. int r() { union a {unsigned short x;} x = (union a)(unsigned short)2; } -Eli From xuzhongxing at gmail.com Wed Jan 14 23:45:20 2009 From: xuzhongxing at gmail.com (Zhongxing Xu) Date: Thu, 15 Jan 2009 13:45:20 +0800 Subject: [cfe-dev] [Patch] Sema::ActOnDeclarator refactor Message-ID: <5400aeb80901142145o22d6fcf1gf055be4b066da559@mail.gmail.com> This patch extracts the code dealing with declarator of function type into a separate function Sema::ActOnFunctionDeclarator(). No functionality change. The motivation of this patch is that Sema::ActOnDeclarator() is too large. Later perhaps we should also have separate Sema::ActOnVarDeclarator(). -Zhongxing Xu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090115/0944301c/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: r.patch Type: application/octet-stream Size: 27147 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090115/0944301c/attachment-0001.obj From ofv at wanadoo.es Thu Jan 15 08:02:31 2009 From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=) Date: Thu, 15 Jan 2009 15:02:31 +0100 Subject: [cfe-dev] win32/llvm.sln, win32/clang.sln References: <009c01c976f2$5d972700$18c57500$@net> Message-ID: "Nicolas Capens" writes: > The Visual Studio solution and project files are quite handy. CMake creates > absolute paths instead of relative paths, making it cumbersome to move > things around. Also, for newcomers (e.g. students) it's really great to be > able to download the package, open the solution and compile without any > complication. > > They haven't been updated in a while, but it would be nice to have working > ones in the 2.5 release... There is a contradiction among this two paragraphs: the first one says "they are convenient" and the second one says "they are outdated". The primary goal of the LLVM CMake build system was to alleviate maintenance work, the second was to support all VS versions wich are C++ compliant enough to compile LLVM. Another nice side-effect is that now VS users can build all LLVM targets. The VS project files under win32/ are good enough as far as someone maintains them, you have the correct VS version and don't need the missing functionality. Finally, a student that works with LLVM is not a computer newbie: he knows how to follow web links, install a piece of software, and copy/paste onto a console. This process requires less time than the LLVM build itself. Of course, this requires that the LLVM CMake instructions should become integrated into the LLVM docs. I hope to do this before the 2.5 release. -- Oscar From makslane at hotmail.com Thu Jan 15 09:15:25 2009 From: makslane at hotmail.com (=?Windows-1252?Q?Makslane_Ara=FAjo_Rodrigues?=) Date: Thu, 15 Jan 2009 18:15:25 +0300 Subject: [cfe-dev] win32/llvm.sln, win32/clang.sln In-Reply-To: References: Message-ID: Please, don't remove, I'm using!!! Regards, Makslane > From: snaroff at apple.com > To: llvmdev at cs.uiuc.edu; cfe-dev at cs.uiuc.edu > Date: Wed, 14 Jan 2009 16:09:13 -0800 > Subject: [cfe-dev] win32/llvm.sln, win32/clang.sln > > Folks, > > Is anyone still using the Visual Studio solution files in the win32 > directory? > > If they aren't being maintained, they should probably be removed (to > avoid any confusion). > > Thanks for any feedback, > > snaroff > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev _________________________________________________________________ Mais do que emails! Confira tudo o que Windows Live? pode oferecer. http://www.microsoft.com/windows/windowslive/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090115/2aee967f/attachment.html From ofv at wanadoo.es Thu Jan 15 10:43:34 2009 From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=) Date: Thu, 15 Jan 2009 17:43:34 +0100 Subject: [cfe-dev] win32/llvm.sln, win32/clang.sln References: Message-ID: Makslane Ara?jo Rodrigues writes: > Please, don't remove, I'm using!!! What's preventing you from using CMake? Is there some problem we can solve? -- Oscar From dgregor at apple.com Thu Jan 15 10:58:19 2009 From: dgregor at apple.com (Douglas Gregor) Date: Thu, 15 Jan 2009 08:58:19 -0800 Subject: [cfe-dev] [Patch] Sema::ActOnDeclarator refactor In-Reply-To: <5400aeb80901142145o22d6fcf1gf055be4b066da559@mail.gmail.com> References: <5400aeb80901142145o22d6fcf1gf055be4b066da559@mail.gmail.com> Message-ID: <095F1086-30B7-4B75-B4BF-F3E428E52666@apple.com> On Jan 14, 2009, at 9:45 PM, Zhongxing Xu wrote: > This patch extracts the code dealing with declarator of function > type into a separate function Sema::ActOnFunctionDeclarator(). > > No functionality change. > > The motivation of this patch is that Sema::ActOnDeclarator() is too > large. Later perhaps we should also have separate > Sema::ActOnVarDeclarator(). Thank you! Please go ahead and commit. - Doug From dgregor at apple.com Thu Jan 15 11:03:48 2009 From: dgregor at apple.com (Douglas Gregor) Date: Thu, 15 Jan 2009 09:03:48 -0800 Subject: [cfe-dev] win32/llvm.sln, win32/clang.sln In-Reply-To: References: Message-ID: <14277C37-21BF-4930-9B15-7A6B7A7CC538@apple.com> On Jan 15, 2009, at 8:43 AM, ?scar Fuentes wrote: > Makslane Ara?jo Rodrigues > writes: > >> Please, don't remove, I'm using!!! > > What's preventing you from using CMake? > > Is there some problem we can solve? At some point, we'll need to deal with the testing issue in the CMake build system. Clang, for example, uses some GNU make magic to run its tests, which we'll need to replace with something more platform- neutral in CMake. That shouldn't prevent anyone who is using the current VS project files from switching to CMake, though. - Doug From bolzoni at cs.unipr.it Thu Jan 15 11:13:43 2009 From: bolzoni at cs.unipr.it (Paolo Bolzoni) Date: Thu, 15 Jan 2009 18:13:43 +0100 Subject: [cfe-dev] Bugs 2746 and 3261 In-Reply-To: References: <496B40E0.1000909@cs.unipr.it> <496BAB34.60502@cs.unipr.it> <20090113172449.20cc2db3@cs.unipr.it> <20090114162929.118dc9bc@cs.unipr.it> Message-ID: <20090115181343.797b613e@cs.unipr.it> On Wed, 14 Jan 2009 12:59:52 -0800 "Eli Friedman" wrote: > On Wed, Jan 14, 2009 at 7:29 AM, Paolo Bolzoni wrote: > > Let's see a simple but evocative example. > > I have the clang AST of this code segment. > > > > Using the function that overrides > > HandleTranslationUnit(clang::TranslationUnit&) > > I want to pretty print: > > > > Here the code: > > struct B; > > > > struct A { > > struct B* b; > > }; > The approach I was thinking of is something like the following: > suppose you're trying to pretty-print the "struct B* b;" bit. Let S > designate the location immediately before the keyword "struct", let E > designate the location immediately after the semicolon, and let D > designate the beginning of the definition of struct B. But declaration have only one program point, I can't have both the position of `struct' and of `;' in the line `struct B* b;' It might work if I could have both... Maybe FieldDecl and TypedefDecl should have isDefinition() like function too? So we could distinguish easily if the type inside is defined there or not. > Unfortunately, though, there isn't any easy way to compare source > locations like that; it should be possible, I think, but I don't know > the details of how to write it. Also, I'm not sure if you can get the > relevant source locations easily, particularly S. I think ongoing > work with DeclGroups will help here eventually, but I'm not sure of > the details. Since SourceLocation contains both line and column it would be easy to implement an order. It is still a problem for tokens where isValid() or isFileID()) are false, but maybe it is not possible in this context. > There is another possible approach: take the location of the beginning > of the first declarator in the declaration (the "*b" bit), and scan > backwards through the source code to see if you find a "}" before the > first occurrence of the "struct" keyword. It's quite messy in terms > of layering, and I'm not sure how preprocessor stuff would factor into > it, but I think it's feasible. I don't know the details here either, > but I remember reading that the ObjC rewriter does some similar stuff. This is indeed a problem to implement at AST level. > I'm putting cfe-dev back onto the CC list so that people more familiar > with this stuff can comment; this is really outside the stuff I've > really tried. > > -Eli Thanks! pb From ofv at wanadoo.es Thu Jan 15 11:46:34 2009 From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=) Date: Thu, 15 Jan 2009 18:46:34 +0100 Subject: [cfe-dev] Testing and CMake (was: win32/llvm.sln, win32/clang.sln) References: <14277C37-21BF-4930-9B15-7A6B7A7CC538@apple.com> Message-ID: Douglas Gregor writes: >>> Please, don't remove, I'm using!!! >> >> What's preventing you from using CMake? >> >> Is there some problem we can solve? > > At some point, we'll need to deal with the testing issue in the CMake > build system. Clang, for example, uses some GNU make magic to run its > tests, which we'll need to replace with something more platform- > neutral in CMake. Testing was (is) the big roadblock for the LLVM CMake system. It is not practical to duplicate the make-based system we have now, but I think a good compromise can be achieved by invoking a script instead of `make'. The build could use this script for doing full testing, so "make all check" would keep working, although for partial testing the script would be mandatory. If this is not already working, is due to lack of time here. OTOH, I haven't followed in detail all that discussion around a new testing framework (plus the introduction of C++ unit tests). I need to relearn was going on and see how that affects my plans. > That shouldn't prevent anyone who is using the current VS project > files from switching to CMake, though. Right. Current VS project files does not support testing at all. -- Oscar From snaroff at apple.com Thu Jan 15 12:16:27 2009 From: snaroff at apple.com (steve naroff) Date: Thu, 15 Jan 2009 10:16:27 -0800 Subject: [cfe-dev] Testing and CMake (was: win32/llvm.sln, win32/clang.sln) In-Reply-To: References: <14277C37-21BF-4930-9B15-7A6B7A7CC538@apple.com> Message-ID: <638E9AC9-088D-432E-8BB2-80B921FAC146@apple.com> Hi Oscar, For development, CMake is working great for me. I rarely get build errors related to the project file being out-of-date. Is it true that CMake only generates absolute paths? Any idea on the difficulty of generating relative paths? I consider this a pretty big obstacle... Thanks for all your hard work on this, snaroff On Jan 15, 2009, at 9:46 AM, ?scar Fuentes wrote: > Douglas Gregor writes: > >>>> Please, don't remove, I'm using!!! >>> >>> What's preventing you from using CMake? >>> >>> Is there some problem we can solve? >> >> At some point, we'll need to deal with the testing issue in the CMake >> build system. Clang, for example, uses some GNU make magic to run its >> tests, which we'll need to replace with something more platform- >> neutral in CMake. > > Testing was (is) the big roadblock for the LLVM CMake system. It is > not > practical to duplicate the make-based system we have now, but I > think a > good compromise can be achieved by invoking a script instead of > `make'. The build could use this script for doing full testing, so > > "make all check" > > would keep working, although for partial testing the script would be > mandatory. If this is not already working, is due to lack of time > here. > > OTOH, I haven't followed in detail all that discussion around a new > testing framework (plus the introduction of C++ unit tests). I need to > relearn was going on and see how that affects my plans. > >> That shouldn't prevent anyone who is using the current VS project >> files from switching to CMake, though. > > Right. Current VS project files does not support testing at all. > > -- > Oscar > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From ofv at wanadoo.es Thu Jan 15 13:38:36 2009 From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=) Date: Thu, 15 Jan 2009 20:38:36 +0100 Subject: [cfe-dev] Testing and CMake References: <14277C37-21BF-4930-9B15-7A6B7A7CC538@apple.com> <638E9AC9-088D-432E-8BB2-80B921FAC146@apple.com> Message-ID: Patrick Boettcher writes: >> For development, CMake is working great for me. I rarely get build >> errors related to the project file being out-of-date. >> >> Is it true that CMake only generates absolute paths? Any idea on the >> difficulty of generating relative paths? I consider this a pretty big >> obstacle... > > I did not follow the full-thread, just reading this Email and I hope I'm > getting it right: > > We had the same problem (relative paths) and it turned out to be > relatively (got the language joke here? ;)) easy, at least with cmake 2.6, > in a local project. > > set(CMAKE_USE_RELATIVE_PATHS ON) > > It works well for vcproj-generation. In Linux I could not test it > comprehensively yet (as to why it is possible to copy a repository and > build it in its new place w/o re-cmaking.) Hmmm... CMAKE_USE_RELATIVE_PATHS Use relative paths (May not work!). If this is set to TRUE, then the CMake will use relative paths between the source and binary tree. This option does not work for more complicated projects, and relative paths are used when possible. In general, it is not possible to move CMake generated makefiles to a different location regardless of the value of this variable. > In addition we are setting > > set(CMAKE_SUPPRESS_REGENERATION ON) > > in order to not have a dependency on the CMakeLists when creating the > vcproj-file. This looks like asking for trouble. Why are you doing this? -- Oscar From ofv at wanadoo.es Thu Jan 15 13:40:59 2009 From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=) Date: Thu, 15 Jan 2009 20:40:59 +0100 Subject: [cfe-dev] Testing and CMake References: <14277C37-21BF-4930-9B15-7A6B7A7CC538@apple.com> <638E9AC9-088D-432E-8BB2-80B921FAC146@apple.com> Message-ID: Hello Steve. steve naroff writes: > For development, CMake is working great for me. I rarely get build > errors related to the project file being out-of-date. > > Is it true that CMake only generates absolute paths? Any idea on the > difficulty of generating relative paths? I consider this a pretty big > obstacle... Well, the fact that you didn't *still* noticed this limitation makes me think that this is rarely needed :-) Can you describe on which scenario do you require to move around build trees? -- Oscar From snaroff at apple.com Thu Jan 15 14:06:11 2009 From: snaroff at apple.com (steve naroff) Date: Thu, 15 Jan 2009 12:06:11 -0800 Subject: [cfe-dev] Testing and CMake In-Reply-To: References: <14277C37-21BF-4930-9B15-7A6B7A7CC538@apple.com> <638E9AC9-088D-432E-8BB2-80B921FAC146@apple.com> Message-ID: On Jan 15, 2009, at 11:40 AM, ?scar Fuentes wrote: > Hello Steve. > > steve naroff writes: > >> For development, CMake is working great for me. I rarely get build >> errors related to the project file being out-of-date. >> >> Is it true that CMake only generates absolute paths? Any idea on the >> difficulty of generating relative paths? I consider this a pretty big >> obstacle... > > Well, the fact that you didn't *still* noticed this limitation makes > me > think that this is rarely needed :-) > I haven't noticed it because I've been on the "development" side (where the absolute paths aren't a problem). > Can you describe on which scenario do you require to move around build > trees? > Sure... As various clang features mature, we enter a "deployment" phase. As part of deployment, it is necessary to provide Apple's Build & Integration team a self-contained source tree that builds properly. This is where the rub is. It isn't appropriate to ask B&I engineers to use "cmake". That said, I want to generate the VS solution files on my local machine and then copy them to a B&I machine and have everything "just work". For example: snaroffBook% ls /Volumes/Data/WindowsShared/objc_translate-9/ llvm vs2005-build The VS solution files located in "vs2005-build" were built with the following command "cmake ../llvm". Since I am using a relative path on the command line, I assumed it would use relative paths (my bad assumption). Another point...I have no need to ever "move" the cmake generated build files away from the source tree. The source tree and the build tree will always move in lock step (which simplifies the problem I am looking to solve). Thanks for any help with this, snaroff > -- > Oscar > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From nicolas at capens.net Thu Jan 15 03:19:27 2009 From: nicolas at capens.net (Nicolas Capens) Date: Thu, 15 Jan 2009 10:19:27 +0100 Subject: [cfe-dev] [LLVMdev] win32/llvm.sln, win32/clang.sln In-Reply-To: References: Message-ID: <009c01c976f2$5d972700$18c57500$@net> Hi Steve, The Visual Studio solution and project files are quite handy. CMake creates absolute paths instead of relative paths, making it cumbersome to move things around. Also, for newcomers (e.g. students) it's really great to be able to download the package, open the solution and compile without any complication. They haven't been updated in a while, but it would be nice to have working ones in the 2.5 release... Cheers, Nicolas -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of steve naroff Sent: donderdag 15 januari 2009 1:09 To: llvmdev at cs.uiuc.edu; cfe-dev at cs.uiuc.edu Subject: [LLVMdev] win32/llvm.sln, win32/clang.sln Folks, Is anyone still using the Visual Studio solution files in the win32 directory? If they aren't being maintained, they should probably be removed (to avoid any confusion). Thanks for any feedback, snaroff _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From pb at linuxtv.org Thu Jan 15 12:48:31 2009 From: pb at linuxtv.org (Patrick Boettcher) Date: Thu, 15 Jan 2009 19:48:31 +0100 (CET) Subject: [cfe-dev] [LLVMdev] Testing and CMake (was: win32/llvm.sln, win32/clang.sln) In-Reply-To: <638E9AC9-088D-432E-8BB2-80B921FAC146@apple.com> References: <14277C37-21BF-4930-9B15-7A6B7A7CC538@apple.com> <638E9AC9-088D-432E-8BB2-80B921FAC146@apple.com> Message-ID: Hi Steve, On Thu, 15 Jan 2009, steve naroff wrote: > For development, CMake is working great for me. I rarely get build > errors related to the project file being out-of-date. > > Is it true that CMake only generates absolute paths? Any idea on the > difficulty of generating relative paths? I consider this a pretty big > obstacle... I did not follow the full-thread, just reading this Email and I hope I'm getting it right: We had the same problem (relative paths) and it turned out to be relatively (got the language joke here? ;)) easy, at least with cmake 2.6, in a local project. set(CMAKE_USE_RELATIVE_PATHS ON) It works well for vcproj-generation. In Linux I could not test it comprehensively yet (as to why it is possible to copy a repository and build it in its new place w/o re-cmaking.) In addition we are setting set(CMAKE_SUPPRESS_REGENERATION ON) in order to not have a dependency on the CMakeLists when creating the vcproj-file. HTH, Patrick. From snaroff at apple.com Thu Jan 15 17:59:20 2009 From: snaroff at apple.com (steve naroff) Date: Thu, 15 Jan 2009 15:59:20 -0800 Subject: [cfe-dev] [LLVMdev] win32/llvm.sln, win32/clang.sln In-Reply-To: <009c01c976f2$5d972700$18c57500$@net> References: <009c01c976f2$5d972700$18c57500$@net> Message-ID: On Jan 15, 2009, at 1:19 AM, Nicolas Capens wrote: > Hi Steve, > > The Visual Studio solution and project files are quite handy. CMake > creates > absolute paths instead of relative paths, making it cumbersome to move > things around. Also, for newcomers (e.g. students) it's really great > to be > able to download the package, open the solution and compile without > any > complication. > Understood, however the (unfortunate) reality is the VS solution file is not being properly maintained. As a result, any newcomer/developer is faced with updating the VS solution file (or not building at all). Over the past 6 months, I've had to personally fix many problems with the solution file. That said, I'm grateful that cmake works and the cmake.txt files are being updated/maintained. It does require an extra step, however the work is "constant time" (whereas fixing regressions without cmake could take an arbitrary amount of time). Thanks for your response... snaroff > They haven't been updated in a while, but it would be nice to have > working > ones in the 2.5 release... > Cheers, > > Nicolas > > > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev- > bounces at cs.uiuc.edu] On > Behalf Of steve naroff > Sent: donderdag 15 januari 2009 1:09 > To: llvmdev at cs.uiuc.edu; cfe-dev at cs.uiuc.edu > Subject: [LLVMdev] win32/llvm.sln, win32/clang.sln > > Folks, > > Is anyone still using the Visual Studio solution files in the win32 > directory? > > If they aren't being maintained, they should probably be removed (to > avoid any confusion). > > Thanks for any feedback, > > snaroff > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From Vasudev.Negi at microchip.com Thu Jan 15 21:12:33 2009 From: Vasudev.Negi at microchip.com (Vasudev.Negi at microchip.com) Date: Thu, 15 Jan 2009 20:12:33 -0700 Subject: [cfe-dev] pointer to variable in different address space Message-ID: I am assuming address space 1 for variables in ROM. Now if I want a pointer to contain the address the this variable then how do I declare it? In other words I want to declare rom int *ptr. Thanks Vasudev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090115/67f5085f/attachment-0001.html From clattner at apple.com Thu Jan 15 21:28:21 2009 From: clattner at apple.com (Chris Lattner) Date: Thu, 15 Jan 2009 19:28:21 -0800 Subject: [cfe-dev] pointer to variable in different address space In-Reply-To: References: Message-ID: On Jan 15, 2009, at 7:12 PM, Vasudev.Negi at microchip.com wrote: > I am assuming address space 1 for variables in ROM. Now if I want a > pointer to contain the address the this variable then how do I > declare it? In other words I want to declare rom int *ptr. > Something like this works for me: #define rom __attribute__((address_space(1))) rom int *ptr; $ clang rom.c -emit-llvm -o - ; ModuleID = 'rom.c' target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32- i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64- f80:128:128" target triple = "i386-apple-darwin9" @ptr = common global i32 addrspace(1)* null, align 4 -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090115/38ae26c3/attachment.html From ofv at wanadoo.es Thu Jan 15 22:11:32 2009 From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=) Date: Fri, 16 Jan 2009 05:11:32 +0100 Subject: [cfe-dev] Testing and CMake References: <14277C37-21BF-4930-9B15-7A6B7A7CC538@apple.com> <638E9AC9-088D-432E-8BB2-80B921FAC146@apple.com> Message-ID: steve naroff writes: >> Can you describe on which scenario do you require to move around build >> trees? > > Sure... [explanation snipped] > Thanks for any help with this, If you require this for VS only, the set(CMAKE_USE_RELATIVE_PATHS ON) trick mentioned on this thread may work, as Windows in general and the LLVM project files in particular doesn't use absolute paths as much as the POSIX platforms do (for RPATH, executing external commands, etc). Please give it a try. If there are absolute paths remaining on the VS project files, they may be the result of generating them in the LLVM CMake files with the `abspath' operator, or could come from CMake built-in variables that default to the absolute form. We could see if those could be replaced by relative paths. -- Oscar From bolzoni at cs.unipr.it Fri Jan 16 03:07:46 2009 From: bolzoni at cs.unipr.it (Paolo Bolzoni) Date: Fri, 16 Jan 2009 10:07:46 +0100 Subject: [cfe-dev] SourceLocation::isFileID() and isMacroID() ? Message-ID: <20090116100746.293654c4@cs.unipr.it> dear cfe-dev list, When visiting the clang AST of a C source, I often get SourceLocations that aren't valid or aren't FileID. Why some locations are not valid? And what does it mean that a location isn't a file ID? It seems to happen almost always in asm file scope declarations. Moreover, what does isMacroID() false or true mean? Once again, thanks. pb From bolzoni at cs.unipr.it Fri Jan 16 03:33:12 2009 From: bolzoni at cs.unipr.it (Paolo Bolzoni) Date: Fri, 16 Jan 2009 10:33:12 +0100 Subject: [cfe-dev] from source location to token? In-Reply-To: References: <20081124113808.37c7c217@cs.unipr.it> <8DC3EF2F-077F-4270-B572-66EA4EEF1F51@apple.com> <492ACDFA.7060902@cs.unipr.it> <20081210150355.170050e4@cs.unipr.it> Message-ID: <20090116103312.07983535@cs.unipr.it> On Wed, 10 Dec 2008 10:31:01 -0800 Chris Lattner wrote: > On Dec 10, 2008, at 6:03 AM, Paolo Bolzoni wrote: > > On Mon, 24 Nov 2008 10:23:12 -0800 > > Chris Lattner wrote: > > > >> The way it gets the end of the fp literal is to relex the token with > >> code in Lexer::MeasureTokenLength. > >> > >> Given a SourceLocation and the length of the token (as returned by > >> MeasureTokenLength) you can get the exact original spelling > >> (including > >> trigraphs and escaped newlines, beware). The pointer to the start of > >> the string is obtained with: > >> > >> const char *StrData = SourceMgr.getCharacterData(Loc); > > > > I have still a problem. Consider the following program: > > > > #define N_OF_ELEM 037; > > int a = N_OF_ELEM; > > > > Using the method you suggest I have that the textual representation > > of the > > integer literal in the right hand side of the assignment is > > `N_OF_ELEM'. > > > > It seems Lexer::MeasureTokenLength() automatically changes the > > SourceLocation > > using clang::SourceManager::getLogicalLoc() . In my case it shouldn't. > > > > What is the best way to obtain the token text after preprocessing? > > Use "Loc = SourceManager.getPhysicalLoc(Loc)" before calling that code, > > -Chris > I did that, and it worked well until the last update of clang. But after updating to release 62317 I get this error: ?class clang::SourceManager? has no member named ?getPhysicalLoc? what is the correct solution now? pb From makslane at hotmail.com Fri Jan 16 05:19:36 2009 From: makslane at hotmail.com (=?Windows-1252?Q?Makslane_Ara=FAjo_Rodrigues?=) Date: Fri, 16 Jan 2009 14:19:36 +0300 Subject: [cfe-dev] win32/llvm.sln, win32/clang.sln In-Reply-To: References: Message-ID: I didn't know about cmake and llvm! I will try it, thanks! Regards, Makslane > To: cfe-dev at cs.uiuc.edu > From: ofv at wanadoo.es > Date: Thu, 15 Jan 2009 17:43:34 +0100 > CC: llvmdev at cs.uiuc.edu > Subject: Re: [cfe-dev] win32/llvm.sln, win32/clang.sln > > Makslane Ara?jo Rodrigues > writes: > > > Please, don't remove, I'm using!!! > > What's preventing you from using CMake? > > Is there some problem we can solve? > > -- > Oscar > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev _________________________________________________________________ Mais do que emails! Confira tudo o que Windows Live? pode oferecer. http://www.microsoft.com/windows/windowslive/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090116/66b83f7f/attachment.html From sebastian.redl at getdesigned.at Fri Jan 16 07:01:37 2009 From: sebastian.redl at getdesigned.at (Sebastian Redl) Date: Fri, 16 Jan 2009 14:01:37 +0100 Subject: [cfe-dev] =?utf-8?q?from_source_location_to_token=3F?= In-Reply-To: <20090116103312.07983535@cs.unipr.it> References: <20081124113808.37c7c217@cs.unipr.it> <8DC3EF2F-077F-4270-B572-66EA4EEF1F51@apple.com> <492ACDFA.7060902@cs.unipr.it> <20081210150355.170050e4@cs.unipr.it> <20090116103312.07983535@cs.unipr.it> Message-ID: On Fri, 16 Jan 2009 10:33:12 +0100, Paolo Bolzoni wrote: > > I did that, and it worked well until the last update of clang. > But after updating to release 62317 I get this error: > ?class clang::SourceManager? has no member named ?getPhysicalLoc? > > what is the correct solution now? > Chris just renamed getPhysicalLoc to getSpellingLoc. Sebastian From monty at codetransform.com Fri Jan 16 10:46:39 2009 From: monty at codetransform.com (Monty Zukowski) Date: Fri, 16 Jan 2009 08:46:39 -0800 Subject: [cfe-dev] Static analysis tool development Message-ID: <73e8e3430901160846v734a65ch28dae1f04ecb7d2e@mail.gmail.com> Ben Laurie of Google has up to $50K to spend on a pilot project to improve the state of static analysis of C code for open source projects. Among other things Ben is involved with the OpenSSL project and has tried some static analyzers such as Deputy, and Cyclone (which is also a language extension of C), and has noted various problems and limitations with these tools. The goal of this pilot project is to get a static analyzer tool developed/modified so that it is truly useful to the open source community and can become a standard part of the development process. The ability to customize the analysis is strongly desired. For instance, after a security exploit is reported people might want to review the rest of the code for the same problem. An analyzer that helped do that would be quite beneficial. If the pilot project goes well then additional funding is possible. >From the research I have done, clang seems to be the best front end for this type of project. I have some questions: 1) What is the state of the static analyzer? Where do I start learning what needs done on it? Is there a long term plan for it? 2) The ability to add custom logic to the analyzer is quite desirable. Perhaps this could be made easier by integrating with a scripting language like Python. To me, even the ability to write a script to pattern match against the AST or other intermediate forms could be quite useful. 3) Simply managing the volume of warnings can be difficult. I would like to integrate some method of tracking warnings from build to build to see what's new and perhaps to be able to prioritize what should be investigated first. This would probably be separate from the analyzer, but a useful front end will help the tool get adopted more readily. 4) Annotations can be helpful to guide an analyzer. How difficult would it be to extend the parser to accept a simple annotation syntax? I am open to collaborating on this project if anyone is available. Also, if you would like to learn more about this project or submit your own proposal, feel free to contact "Ben Laurie" . Thanks for your help. Monty From monty at codetransform.com Fri Jan 16 11:19:25 2009 From: monty at codetransform.com (Monty Zukowski) Date: Fri, 16 Jan 2009 09:19:25 -0800 Subject: [cfe-dev] Static analysis tool development In-Reply-To: <73e8e3430901160846v734a65ch28dae1f04ecb7d2e@mail.gmail.com> References: <73e8e3430901160846v734a65ch28dae1f04ecb7d2e@mail.gmail.com> Message-ID: <73e8e3430901160919s403b635fi48b4c5026d23b345@mail.gmail.com> > 1) What is the state of the static analyzer? Where do I start > learning what needs done on it? Is there a long term plan for it? To answer one of my own questions, I just found the slide and video presentation on "Finding Bugs with the Clang Static Analyzer" http://llvm.org/devmtg/2008-08/ Monty From fleury at labri.fr Fri Jan 16 11:25:33 2009 From: fleury at labri.fr (Emmanuel Fleury) Date: Fri, 16 Jan 2009 18:25:33 +0100 Subject: [cfe-dev] Static analysis tool development In-Reply-To: <73e8e3430901160846v734a65ch28dae1f04ecb7d2e@mail.gmail.com> References: <73e8e3430901160846v734a65ch28dae1f04ecb7d2e@mail.gmail.com> Message-ID: <4970C30D.6040806@labri.fr> Hi all, Monty Zukowski wrote: > >>From the research I have done, clang seems to be the best front end > for this type of project. I have some questions: > > 1) What is the state of the static analyzer? Where do I start > learning what needs done on it? Is there a long term plan for it? I would strongly suggest to start with: Textbooks and introductory courses ================================== - ? Principles of Program Analysis ? by Flemming Nielson, Hanne Riis Nielson, Chris Hankin at Springer, 2005. ISBN 3-540-65410-0 - Introduction to Abstract Interpretation: http://www.di.ens.fr/~cousot/aiintro.shtml http://www.cs.mu.oz.au/~schachte/lpanalysis.html http://web.mit.edu/afs/athena.mit.edu/course/16/16.399/www/ - CEGAR and Lazy Abstraction http://www.cs.cmu.edu/~emc/papers/Papers%20In%20Refereed%20Journals/Counterexample-guided%20abstraction%20refinement.pdf http://mtc.epfl.ch/~tah/Publications/lazy_abstraction.pdf Tools and Techniques ==================== - Astr?e: http://www.astree.ens.fr/ See: http://www.di.ens.fr/~cousot/publications.www/Cousot-LNCS2000-lv-lb.pdf - TVLA: http://www.cs.tau.ac.il/~tvla/ See: http://www.cs.tau.ac.il/~tvla/ifip2004.pdf - Blast: http://mtc.epfl.ch/software-tools/blast/ See: http://www.cs.sfu.ca/~dbeyer/Publications/2007-STTT.The_Software_Model_Checker_BLAST.pdf - Slam: http://research.microsoft.com/en-us/projects/slam/ See: http://springerlink.metapress.com/content/ek3l4u815vl3aexk/ - The Magic tool: http://www.cs.cmu.edu/~chaki/magic/ See: http://www.cs.cmu.edu/~chaki/publications/TSE-2004.pdf > 2) The ability to add custom logic to the analyzer is quite desirable. > Perhaps this could be made easier by integrating with a scripting > language like Python. To me, even the ability to write a script to > pattern match against the AST or other intermediate forms could be > quite useful. Try to look at SMT solvers (see: http://en.wikipedia.org/wiki/Satisfiability_Modulo_Theories). MathSAT 4 seems to be quite efficient: http://mathsat4.disi.unitn.it/ Z3 is an attempt from Microsoft in this topic: http://research.microsoft.com/en-us/um/redmond/projects/z3/ Hope this help ! Regards -- Emmanuel Fleury Associate Professor, | Room: 261 LaBRI, Domaine Universitaire | Phone: +33 (0)5 40 00 69 34 351, Cours de la Lib?ration | Email: emmanuel.fleury at labri.fr 33405 Talence Cedex, France | URL: http://www.labri.fr/~fleury From clattner at apple.com Fri Jan 16 12:14:35 2009 From: clattner at apple.com (Chris Lattner) Date: Fri, 16 Jan 2009 10:14:35 -0800 Subject: [cfe-dev] SourceLocation::isFileID() and isMacroID() ? In-Reply-To: <20090116100746.293654c4@cs.unipr.it> References: <20090116100746.293654c4@cs.unipr.it> Message-ID: <9087A682-B4EA-4A28-8BAF-D051EC2D8E63@apple.com> On Jan 16, 2009, at 1:07 AM, Paolo Bolzoni wrote: > dear cfe-dev list, > > When visiting the clang AST of a C source, I often get > SourceLocations that > aren't valid or aren't FileID. Why some locations are not valid? Invalid source locations come from two things 1) synthesized AST objects that don't exist in the source code, and 2) bugs in the parser. > And what does it mean that a location isn't a file ID? This currently means it is coming from a macro expansion. > It seems to happen almost always in asm file scope declarations. That is probably a bug in the parser, not preserving location info correctly. > Moreover, what does isMacroID() false or true mean? By example, consider this file: #define x y x z The first token will be a SourceLocation that is a macro ID. SourceManager will be able to tell you it's "spelling" location (which is "y") as well as its "instantiation" location (which is the x before the z). The second location is a file ID. SourceManager will tell you that it's spelling and instantiation location are the same, both the z. I plan to make some major changes in this area today and over the weekend. You might want to wait until the dust settles before grinding on details of SourceLocation itself. In any case, I'd recommend using the SourceManager methods like "getInstantiationLoc" and "getSpellingLoc" rather than poking at the SourceLocation itself. -Chris From kremenek at apple.com Fri Jan 16 17:42:34 2009 From: kremenek at apple.com (Ted Kremenek) Date: Fri, 16 Jan 2009 15:42:34 -0800 Subject: [cfe-dev] Static analysis tool development In-Reply-To: <73e8e3430901160846v734a65ch28dae1f04ecb7d2e@mail.gmail.com> References: <73e8e3430901160846v734a65ch28dae1f04ecb7d2e@mail.gmail.com> Message-ID: <87373C76-C757-4921-9497-BA05F4CE977B@apple.com> On Jan 16, 2009, at 8:46 AM, Monty Zukowski wrote: > Ben Laurie of Google has up to $50K to spend on a pilot project to > improve the state of static analysis of C code for open source > projects. Among other things Ben is involved with the OpenSSL project > and has tried some static analyzers such as Deputy, and Cyclone (which > is also a language extension of C), and has noted various problems and > limitations with these tools. Hi Monty, Ben, It's great to hear about your interest! Since some of your questions are fairly broad, I have tried to respond to your questions with a varying levels of detail. Please do not hesitate to follow up with specific questions. > The goal of this pilot project is to get a static analyzer tool > developed/modified so that it is truly useful to the open source > community and can become a standard part of the development process. > The ability to customize the analysis is strongly desired. For > instance, after a security exploit is reported people might want to > review the rest of the code for the same problem. An analyzer that > helped do that would be quite beneficial. > > If the pilot project goes well then additional funding is possible. From my perspective there are three kinds of extensibility when it comes to analysis tools: [1] The analyzer core can be modified or extended with new program analysis algorithms to meet the needs of different clients (e.g., provide the flexibility to tradeoff between accuracy and computational complexity, etc.). [2] The analyzer core can be reused in a variety of contexts, such as in a standalone command-line tool or an IDE. [3] The analyzer can be extended with new sets of "checks" by not invasively modifying the analyzer internals. Such extensibility can be provided with different layers of abstraction from the core analyzer API, with very high-level checks possibly being written in a very high-level manner (e.g., declarative) while some checks requiring more direct access to the core analyzer APIs. Both ends of the spectrum are important because some checks will require sophisticated algorithms with deep reasoning about the program while others might be much simpler and just clue off of common interfaces and APIs. The analyzer core in Clang is intended to (eventually) meet all three goals. So far efforts have focused on [1] and [2], although there has been some work on [3] with regards to checks that directly use the analyzer's C++ APIs. Providing higher-level interfaces to declaring checks is a great long term goal, but my feeling is that it makes more sense to mature the core technology first. As a high-level design strategy, the analyzer core is written as a library (libAnalysis). This makes it inherently much easier to reuse in difference settings, which directly addresses goal [2]. The structure of libAnalysis is fairly modular, with a set of key abstract interfaces put in place to allow us to swap in and out different key components of the analyzer. For example, the engine that reasons about feasible paths within a function uses a "ConstraintManager" interface that is responsible for reasoning about the possible state of possible values along a path. Different implementations of ConstraintManager can be implemented to provide different levels of precision depending on the needs of clients. Another high-level goal of the analyzer is to support the relaying of rich diagnostics to end-users about how a bug manifests in their program. The diagnostic reporting mechanism in the analyzer also uses a set of abstract interfaces so that bug reports can be rendered in a variety of ways (e.g., to the console, to an HTML page, within an IDE, etc.). Providing rich diagnostics is an important goal because without them the results of a static analysis algorithm is only useful to graduate students studying program analysis techniques rather than programmers who want to fix bugs. >> From the research I have done, clang seems to be the best front end > for this type of project. I have some questions: > > 1) What is the state of the static analyzer? Where do I start > learning what needs done on it? Is there a long term plan for it? The talk I gave last August provides a broad overview of the project and its state: Finding Bugs with the Clang Static Analyzer http://llvm.org/devmtg/2008-08/ More information on using the analyzer can be found at: http://clang.llvm.org/StaticAnalysis.html There is currently no real "internals" documentation on the analyzer, which of course is something that needs to be written. Perhaps the easiest way to look at the state of the analyzer is to look at the implementation of specific checks in the lib/Analysis directory of the Clang sources. Another good starting point is the file Driver/ AnalysisConsumer.cpp; this file corresponds to the code in the driver that invokes the static analysis algorithms on a specific source file. At a high level the analyzer consists of two analysis "engines": [a] A flow-sensitive, intra-procedural dataflow engine. [b] A path-sensitive, intra-procedural (and eventually inter- procedural) dataflow engine. FLOW-SENSITIVE ENGINE Engine [a] mirrors the logic that typically goes on for flow-sensitive compiler checks, e.g.: live variables analysis, basic uninitialized variable checking, etc. The analyzer also has a "dead stores" checker that is based on [a]. The benefit of [a] is that the running type of an analysis is linear. The downside of [a] is that information can be lost where paths merge (e.g., at confluence points after branches). Information on the theory and algorithms of [a] can be found in fairly standard compiler texts such as: Advanced Compiler Design and Implementation author: Muchnick Compilers: Principles, Techniques and Tools ***Second Edition*** authors: Aho, Lam, Sethi, Ullman In libAnalysis, two analyses use [a]: LiveVariables.cpp and UninitializedValues.cpp. PATH-SENSITIVE ENGINE Engine [b] is a "path-sensitive" dataflow analysis engine which essentially is a symbolic simulator. This engine reasons about path- specific bugs such as null-dereferences, memory leaks, etc. It's basically the core technology of what we generally equate with an "advanced" static analysis tool. At a high-level, [b] reasons about the "reachable states" of a program be exploring an abstract state-space graph (represented as an "exploded graph"; ExplodedGraph.[h,cpp]). A "bug" is essentially a path that reaches a state that is considered to be "bad" (e.g., a null pointer was dereferenced). States are simply a collection of symbolic values representing an abstraction of a program's state at a particular location in the program. Operationally, the analyzer essentially interprets each expression in a program's source code and reasons about the "state transitions" by considering the effect of an expression on a given state. From dataflow theory, the theoretical parlance for this operation is called a "transfer function", but from an engineering standpoint it is essentially a visitor function that takes as input a state and an expression and returns a new state. The analyzer design is inspired and similar (but in many ways quite different) to the algorithms and ideas in several well-known papers: Precise interprocedural dataflow analysis via graph reachability http://doi.acm.org/10.1145/199448.199462 Checking system rules using system-specific, programmer-written compiler extensions http://portal.acm.org/citation.cfm?id=1251229.1251230 Symbolic path simulation in path-sensitive dataflow analysis http://doi.acm.org/10.1145/1108792.1108808 (and several others) From an engineering perspective, the trick is making the transfer function modular in construction, so that some aspects handle basic symbolic interpretation such as the manipulation of basic values (i.e., determine the result of "i + 10") while other aspects are "checker specific" and reason about things such as the state of a lock, a file handle, whether or not a piece of data is considered "unsafe", and so forth. The modular design of the transfer function interface is one important aspect of the analyzer that needs to be matured, although what's there isn't too bad of a starting point. This component is so important because it represents the core axis of flexibility with writing a diversity of checks, and thus maturing it is necessary in order to think about how to write checks using different high-level interfaces/ Other important components of the [b] include: (1) ConstraintManager - the module that reasons about constraints on symbolic values (2) StoreManager - the module that reasons about the bindings of variables to values. This is essentially the symbolic representation of the heap/stack. The current implementation of ConstraintManager is "BasicConstraintManager", which tracks only basic equality and inequality relationships (i.e., "a != 10", "b == 4"). This is suitable for most predicates in system code (and for catching things like null dereferences) but not all. One goal is to implement another ConstraintManager that does basic range analysis (i.e., track "a > b"). This would be especially useful for buffer overflow detection. For StoreManager, we are actively using BasicStoreManager, which just tracks bindings for variables on the stack. Zhongxing Xu has put a fair amount of work into developing a new StoreManager called "RegionStoreManager" that will extend the analyzer's abilities to reason about the values of fields, arrays, etc. We certainly invite anyone who is interested in helping complete this feature to get involved. Probably the other biggest point worth mentioning is that the path- sensitive engine is currently restricted to function-at-a-time analysis. Doing inter-procedural analysis is something that is definitely planned, but requires different levels of infrastructure depending on the scope of the analysis. In the most general case we need to be able to perform whole-program analysis across source files. This requires being able to build an entire image of the program (including information about linkage so we know we know the exact corresponding definitions for called functions). There are a variety of ways to tackle this task, and this is a major piece of infrastructure that certainly could benefit from anyone wishing to help get involved. > 2) The ability to add custom logic to the analyzer is quite desirable. > Perhaps this could be made easier by integrating with a scripting > language like Python. To me, even the ability to write a script to > pattern match against the AST or other intermediate forms could be > quite useful. This is a great long term goal. My feeling is that the core analyzer logic needs to converge a little further first so that checks can be readily written using the C++ API. Afterwards using a higher-level language like Python or Javascript seems like an excellent project. > 3) Simply managing the volume of warnings can be difficult. I would > like to integrate some method of tracking warnings from build to build > to see what's new and perhaps to be able to prioritize what should be > investigated first. This would probably be separate from the > analyzer, but a useful front end will help the tool get adopted more > readily. "Issue tracking" would useful for a wide range of clients. To do this well, however, I don't think it can be done completely separate from the analyzer. Issue tracking requires rich diagnostics that describe a bug but also must be insensitive to code churn that has no bearing on a particular bug or false positive. In some cases this may require issuing queries to the analyzer to extract more information. As a first cut, however, the output could be based entirely on the diagnostics. As an interesting side note, the developers of Adium (http://www.adiumx.com ) have actually been regularly scanning their sources using Clang's static analyzer. As part of their process, they wrote some scripts that inspect the emitted diagnostics (in this case HTML files) and did some munging to determine if the a report emitted on a given scan was the same as in a prior scan. Their goal is to avoid re-inspecting previously diagnosed bugs and false positives. Having a general mechanism in the analyzer library would be quite useful, and would be a good first order project for anyone who is interested in getting involved. > 4) Annotations can be helpful to guide an analyzer. How difficult > would it be to extend the parser to accept a simple annotation syntax? C and its derivatives are complex languages, so it really depends on the annotation syntax. For example, it is really easy to add GCC- style attributes to Clang (whose syntax could then be wrapped by macros): http://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html The analyzer already exploits a variety of attributes such as "nonnull", "unused", "IBOutlet" (the latter being added for an Objective-C check the analyzer performs), and new ones could readily be added as well. It all depends on what you want to express. > I am open to collaborating on this project if anyone is available. That would be wonderful. My suggestion is to start with a simple set of annotations for which the corresponding checks are not too complicated. The design can then iterate from there. There has been a lot of work on annotation systems, and probably the most traction is to start with annotations that would have the widest practical benefit (i.e., low cost of adoption, easy implementation, etc.). > Also, if you would like to learn more about this project or submit > your own proposal, feel free to contact "Ben Laurie" > . If you wish to discuss more aspects of the analyzer I highly recommend you subscribe (if you haven't already) to cfe-dev. For those who wish to get directly involved in development, we discuss patches on cfe- commits. I mentioned a fair number of points in this email regarding directions for the static analyzer. Two particularly important action points (which are fairly accessible to anyone wishing to get involved) are: 1) improving the web app to manage false positives 2) run-to-run tracking of analysis results Both points go right to the issue of user workflow and the overall usability of the analyzer, and don't require (at least initially) having an intimate knowledge of the analyzer's internals or its algorithms. If you have any specific questions, please do not hesitate to ask. Best, Ted -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090116/03582b21/attachment-0001.html From xuzhongxing at gmail.com Fri Jan 16 19:00:40 2009 From: xuzhongxing at gmail.com (Zhongxing Xu) Date: Sat, 17 Jan 2009 09:00:40 +0800 Subject: [cfe-dev] Static analysis tool development In-Reply-To: <87373C76-C757-4921-9497-BA05F4CE977B@apple.com> References: <73e8e3430901160846v734a65ch28dae1f04ecb7d2e@mail.gmail.com> <87373C76-C757-4921-9497-BA05F4CE977B@apple.com> Message-ID: <5400aeb80901161700p2d540151qf1138c676b215d94@mail.gmail.com> Hi Monty, Ben, Ted has given a detailed overview and long-term plan for the static analyzer of clang. I'll list some short-term goals of mine. 1. Consolidate the current implementation by running the analyzer on various code. There is a script called scan-build that can help integrate clang into the build process of target projects. 2. I am also writing a libc wrapper that enables us to capture the build process better. Basically we could wrap various exec() system calls and record the whole build process. Then we could replay it in various ways. 3. Finish AST serialization. This is the first step toward the whole program analysis. Also there are some aspacts of the analyzer that can be worked on independently. 1. Develop a new ConstraintManager. This could be based on basic range analysis, a SAT solver, or an SMT solver. 2. Add specific checkers to the engine. -Zhongxing -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090117/a734ccce/attachment.html From govosr at cs.rpi.edu Fri Jan 16 22:31:22 2009 From: govosr at cs.rpi.edu (Ryan Govostes) Date: Fri, 16 Jan 2009 23:31:22 -0500 Subject: [cfe-dev] Static analysis tool development In-Reply-To: References: <87373C76-C757-4921-9497-BA05F4CE977B@apple.com> Message-ID: <12107ADF-6753-4870-B8A6-E6B49212885D@cs.rpi.edu> > From: Ted Kremenek > Date: January 16, 2009 3:42:34 PM PST > To: Monty Zukowski > Cc: Ben Laurie , cfe-dev at cs.uiuc.edu > Subject: Re: [cfe-dev] Static analysis tool development > Reply-To: kremenek at apple.com > ... > > Another high-level goal of the analyzer is to support the relaying > of rich diagnostics to end-users about how a bug manifests in their > program. The diagnostic reporting mechanism in the analyzer also > uses a set of abstract interfaces so that bug reports can be > rendered in a variety of ways (e.g., to the console, to an HTML > page, within an IDE, etc.). Providing rich diagnostics is an > important goal because without them the results of a static analysis > algorithm is only useful to graduate students studying program > analysis techniques rather than programmers who want to fix bugs. > ... > > "Issue tracking" would useful for a wide range of clients. To do > this well, however, I don't think it can be done completely separate > from the analyzer. Issue tracking requires rich diagnostics that > describe a bug but also must be insensitive to code churn that has > no bearing on a particular bug or false positive. In some cases > this may require issuing queries to the analyzer to extract more > information. As a first cut, however, the output could be based > entirely on the diagnostics. > > As an interesting side note, the developers of Adium (http://www.adiumx.com > ) have actually been regularly scanning their sources using Clang's > static analyzer. As part of their process, they wrote some scripts > that inspect the emitted diagnostics (in this case HTML files) and > did some munging to determine if the a report emitted on a given > scan was the same as in a prior scan. Their goal is to avoid re- > inspecting previously diagnosed bugs and false positives. Having a > general mechanism in the analyzer library would be quite useful, and > would be a good first order project for anyone who is interested in > getting involved. > I thought I'd chime in here; I wrote the scripts we currently use in Adium for this purpose. Sources (which do not work with the latest version of Clang, to my knowledge) are at: http://trac.adiumx.com/browser/trunk/Utilities/Analyzer In response to the above paragraphs of Ted's e-mail, I thought I'd announce here that I've been working on a Trac plugin for viewing Clang reports. Recent versions of the analyzer will output to plist files, or HTML files, but not both (though this would presumably be a trivial change). The Trac plugin parses plist files to generate a file view, which is annotated with the appropriate diagnostics. Using a dynamic view (i.e., the one generated by Trac) to view the reports has some benefits over the static files. For one, we can strip parts of the code that are irrelevant to the report, instead showing only a few context lines above and below each diagnostic. Another thing we can do is add links to other pages, such as a report generated on a previous revision of the file. More importantly, however, is the possibility to automatically file tickets based on new bugs. The system can track a single bug longitudinally across several commits, using simple heuristics to decide when a report has been resolved, or merely changed. (This would integrate well with a system like Buildbot for performing scan builds and uploading new plists.) Is there any interest in a plugin like this? I'd be glad to share it on a repository if anyone would like to help flesh out the idea. --- Ryan Z. Govostes Rensselaer Polytechnic Institute Computer Science '11 Vice President RPISEC Cyber Security Club Managing Editor The Rensselaer Polytechnic Undergraduate Researcher CogWorks Laboratories Member Upsilon Pi Epsilon From monty at codetransform.com Sat Jan 17 08:53:24 2009 From: monty at codetransform.com (Monty Zukowski) Date: Sat, 17 Jan 2009 06:53:24 -0800 Subject: [cfe-dev] Static analysis tool development In-Reply-To: <87373C76-C757-4921-9497-BA05F4CE977B@apple.com> References: <73e8e3430901160846v734a65ch28dae1f04ecb7d2e@mail.gmail.com> <87373C76-C757-4921-9497-BA05F4CE977B@apple.com> Message-ID: <73e8e3430901170653hc1efd1odc11f8496ed7cb64@mail.gmail.com> I'm glad to hear all the details of your analyzer. I'll have more questions later, I'm sure, but for now this is what interests me most: > Another high-level goal of the analyzer is to support the relaying of rich > diagnostics to end-users about how a bug manifests in their program. The > diagnostic reporting mechanism in the analyzer also uses a set of abstract > interfaces so that bug reports can be rendered in a variety of ways (e.g., > to the console, to an HTML page, within an IDE, etc.). Providing rich > diagnostics is an important goal because without them the results of a > static analysis algorithm is only useful to graduate students studying > program analysis techniques rather than programmers who want to fix bugs. As you mentioned later, issue tracking is very important and the analyzer can be designed to help with that. It seems to me that that could be the best use of Google's money to get this tool into its most useful state. I can see you've put a lot of thought into the other analysis which can be added to the tool later. I'm not an expert in that area so I'll probably leave that area untouched. In any event, you've described a tool which seems to have been designed to be both extensible and useful and for that I'm very excited. It seems like such an obvious need, doesn't it? Monty P.S. I'll be offline on holiday and probably won't answer any other emails until Monday night or Tuesday. From benl at google.com Sat Jan 17 09:02:02 2009 From: benl at google.com (Ben Laurie) Date: Sat, 17 Jan 2009 15:02:02 +0000 Subject: [cfe-dev] Static analysis tool development In-Reply-To: <73e8e3430901170653hc1efd1odc11f8496ed7cb64@mail.gmail.com> References: <73e8e3430901160846v734a65ch28dae1f04ecb7d2e@mail.gmail.com> <87373C76-C757-4921-9497-BA05F4CE977B@apple.com> <73e8e3430901170653hc1efd1odc11f8496ed7cb64@mail.gmail.com> Message-ID: <1b587cab0901170702m104d99ach2e8049d74ef335b0@mail.gmail.com> On Sat, Jan 17, 2009 at 2:53 PM, Monty Zukowski wrote: > I'm glad to hear all the details of your analyzer. I'll have more > questions later, I'm sure, but for now this is what interests me most: > >> Another high-level goal of the analyzer is to support the relaying of rich >> diagnostics to end-users about how a bug manifests in their program. The >> diagnostic reporting mechanism in the analyzer also uses a set of abstract >> interfaces so that bug reports can be rendered in a variety of ways (e.g., >> to the console, to an HTML page, within an IDE, etc.). Providing rich >> diagnostics is an important goal because without them the results of a >> static analysis algorithm is only useful to graduate students studying >> program analysis techniques rather than programmers who want to fix bugs. > > As you mentioned later, issue tracking is very important and the > analyzer can be designed to help with that. I do wonder if suppression of false positives is better done by annotation than by tracking... a) The annotation can be reused by other analysers. b) The annotation works for developers who start from scratch. > It seems to me that that > could be the best use of Google's money to get this tool into its most > useful state. I can see you've put a lot of thought into the other > analysis which can be added to the tool later. I'm not an expert in > that area so I'll probably leave that area untouched. > > In any event, you've described a tool which seems to have been > designed to be both extensible and useful and for that I'm very > excited. It seems like such an obvious need, doesn't it? > > Monty > > P.S. I'll be offline on holiday and probably won't answer any other > emails until Monday night or Tuesday. > From nikita at zhuk.fi Sat Jan 17 09:05:57 2009 From: nikita at zhuk.fi (Nikita Zhuk) Date: Sat, 17 Jan 2009 17:05:57 +0200 Subject: [cfe-dev] Static analysis tool development In-Reply-To: <87373C76-C757-4921-9497-BA05F4CE977B@apple.com> References: <73e8e3430901160846v734a65ch28dae1f04ecb7d2e@mail.gmail.com> <87373C76-C757-4921-9497-BA05F4CE977B@apple.com> Message-ID: <7DC96595-C064-4368-AE67-2494E4844C85@zhuk.fi> On 17.1.2009, at 1.42, Ted Kremenek wrote: > [3] The analyzer can be extended with new sets of "checks" by not > invasively modifying the analyzer internals. Such extensibility can > be provided with different layers of abstraction from the core > analyzer API, with very high-level checks possibly being written in > a very high-level manner (e.g., declarative) while some checks > requiring more direct access to the core analyzer APIs. Both ends > of the spectrum are important because some checks will require > sophisticated algorithms with deep reasoning about the program while > others might be much simpler and just clue off of common interfaces > and APIs. I thought I could comment on that a little. As Ted said, it's possible to extend analyzer with new sets of checks without large modifications. At our company we have combined this possiblity with manual code reviews - when a bug is found during a code review, we try to implement a static analyzer check which would a) automatically check rest of the code for the same problem and b) prevent this problem in the future. I have been able to implement some basic checks without extensive compiler or C++ background fairly easily into clang itself by using the AnalysisManager API. The results have been very positive. If/when clang static analyzer will allow easy extensibility as Ted described in option [3], it would be very interesting to see if clang user community could come up with some collaborative way of sharing various custom checks as pluggable & configurable components. A wiki, perhaps? I think that sharing programming experience and knowledge as clang analyzer checks for common programming errors and best practices would be useful for open source community. From benl at google.com Sat Jan 17 09:12:14 2009 From: benl at google.com (Ben Laurie) Date: Sat, 17 Jan 2009 15:12:14 +0000 Subject: [cfe-dev] Static analysis tool development In-Reply-To: <7DC96595-C064-4368-AE67-2494E4844C85@zhuk.fi> References: <73e8e3430901160846v734a65ch28dae1f04ecb7d2e@mail.gmail.com> <87373C76-C757-4921-9497-BA05F4CE977B@apple.com> <7DC96595-C064-4368-AE67-2494E4844C85@zhuk.fi> Message-ID: <1b587cab0901170712v7e2c1d47k584f7486d4151f8e@mail.gmail.com> On Sat, Jan 17, 2009 at 3:05 PM, Nikita Zhuk wrote: > > On 17.1.2009, at 1.42, Ted Kremenek wrote: > >> [3] The analyzer can be extended with new sets of "checks" by not >> invasively modifying the analyzer internals. Such extensibility can >> be provided with different layers of abstraction from the core >> analyzer API, with very high-level checks possibly being written in >> a very high-level manner (e.g., declarative) while some checks >> requiring more direct access to the core analyzer APIs. Both ends >> of the spectrum are important because some checks will require >> sophisticated algorithms with deep reasoning about the program while >> others might be much simpler and just clue off of common interfaces >> and APIs. > > I thought I could comment on that a little. As Ted said, it's possible > to extend analyzer with new sets of checks without large > modifications. At our company we have combined this possiblity with > manual code reviews - when a bug is found during a code review, we try > to implement a static analyzer check which would a) automatically > check rest of the code for the same problem and b) prevent this > problem in the future. I have been able to implement some basic checks > without extensive compiler or C++ background fairly easily into clang > itself by using the AnalysisManager API. The results have been very > positive. > > If/when clang static analyzer will allow easy extensibility as Ted > described in option [3], it would be very interesting to see if clang > user community could come up with some collaborative way of sharing > various custom checks as pluggable & configurable components. A wiki, > perhaps? I think that sharing programming experience and knowledge as > clang analyzer checks for common programming errors and best practices > would be useful for open source community. What would be wrong with just integrating them into the source and having them invdividually enableable? From mrs at apple.com Sat Jan 17 12:05:16 2009 From: mrs at apple.com (Mike Stump) Date: Sat, 17 Jan 2009 10:05:16 -0800 Subject: [cfe-dev] Static analysis tool development In-Reply-To: <1b587cab0901170712v7e2c1d47k584f7486d4151f8e@mail.gmail.com> References: <73e8e3430901160846v734a65ch28dae1f04ecb7d2e@mail.gmail.com> <87373C76-C757-4921-9497-BA05F4CE977B@apple.com> <7DC96595-C064-4368-AE67-2494E4844C85@zhuk.fi> <1b587cab0901170712v7e2c1d47k584f7486d4151f8e@mail.gmail.com> Message-ID: <4B79325B-C1EA-4057-8C4F-15D7A40D887A@apple.com> On Jan 17, 2009, at 7:12 AM, Ben Laurie wrote: > What would be wrong with just integrating them into the source and > having them invdividually enableable? What's wrong with: #include ? :-) From sonja.zhuk at gmail.com Sat Jan 17 10:58:44 2009 From: sonja.zhuk at gmail.com (Nikita Zhuk) Date: Sat, 17 Jan 2009 18:58:44 +0200 Subject: [cfe-dev] Static analysis tool development In-Reply-To: <1b587cab0901170712v7e2c1d47k584f7486d4151f8e@mail.gmail.com> References: <73e8e3430901160846v734a65ch28dae1f04ecb7d2e@mail.gmail.com> <87373C76-C757-4921-9497-BA05F4CE977B@apple.com> <7DC96595-C064-4368-AE67-2494E4844C85@zhuk.fi> <1b587cab0901170712v7e2c1d47k584f7486d4151f8e@mail.gmail.com> Message-ID: On 17.1.2009, at 17.12, Ben Laurie wrote: > On Sat, Jan 17, 2009 at 3:05 PM, Nikita Zhuk wrote: >> >> If/when clang static analyzer will allow easy extensibility as Ted >> described in option [3], it would be very interesting to see if clang >> user community could come up with some collaborative way of sharing >> various custom checks as pluggable & configurable components. A wiki, >> perhaps? I think that sharing programming experience and knowledge as >> clang analyzer checks for common programming errors and best >> practices >> would be useful for open source community. > > What would be wrong with just integrating them into the source and > having them invdividually enableable? There's nothing wrong with integrating additional checks into clang, of course. However, as a Mac developer and clang user I would like to be able to download and install additional checks simply by dropping the downloaded binary into some directory, without recompiling clang each time I'd like to try a new check which some other developer has written. I also suspect that some checks could exist which aren't completely in line with clang's goals, e.g. which generate too many false positives for average project, but which would be beneficial in projects of a specific type. For example, I have written some specific coding convention checks which have way too high level of false positives for being included into the official clang, but which are useful for developers who follow the same conventions. From devlists at shadowlab.org Sat Jan 17 12:53:09 2009 From: devlists at shadowlab.org (Jean-Daniel Dupas) Date: Sat, 17 Jan 2009 19:53:09 +0100 Subject: [cfe-dev] Static analysis tool development In-Reply-To: References: <73e8e3430901160846v734a65ch28dae1f04ecb7d2e@mail.gmail.com> <87373C76-C757-4921-9497-BA05F4CE977B@apple.com> <7DC96595-C064-4368-AE67-2494E4844C85@zhuk.fi> <1b587cab0901170712v7e2c1d47k584f7486d4151f8e@mail.gmail.com> Message-ID: <1B704275-C552-4B34-B0C2-CD05C39A5864@shadowlab.org> Le 17 janv. 09 ? 17:58, Nikita Zhuk a ?crit : > > On 17.1.2009, at 17.12, Ben Laurie wrote: > >> On Sat, Jan 17, 2009 at 3:05 PM, Nikita Zhuk wrote: >>> >>> If/when clang static analyzer will allow easy extensibility as Ted >>> described in option [3], it would be very interesting to see if >>> clang >>> user community could come up with some collaborative way of sharing >>> various custom checks as pluggable & configurable components. A >>> wiki, >>> perhaps? I think that sharing programming experience and knowledge >>> as >>> clang analyzer checks for common programming errors and best >>> practices >>> would be useful for open source community. >> >> What would be wrong with just integrating them into the source and >> having them invdividually enableable? > > There's nothing wrong with integrating additional checks into clang, > of course. However, as a Mac developer and clang user I would like to > be able to download and install additional checks simply by dropping > the downloaded binary into some directory, without recompiling clang > each time I'd like to try a new check which some other developer has > written. I also suspect that some checks could exist which aren't > completely in line with clang's goals, e.g. which generate too many > false positives for average project, but which would be beneficial in > projects of a specific type. For example, I have written some specific > coding convention checks which have way too high level of false > positives for being included into the official clang, but which are > useful for developers who follow the same conventions. I agree. As clang is backed by Apple, it contains built-in check for specifics Apple library like Cocoa/CoreFoundation. But some other Open Source library may want to be able to also write library specific tests. This feature will be very useful to distribute package that contains a library and a clang plugin to check this library good practices. For example, it's probably possible to write test for glib or QT memory management. To be able to distribute them as plugin with the library would be a great. From benl at google.com Sat Jan 17 12:57:32 2009 From: benl at google.com (Ben Laurie) Date: Sat, 17 Jan 2009 18:57:32 +0000 Subject: [cfe-dev] Static analysis tool development In-Reply-To: References: <73e8e3430901160846v734a65ch28dae1f04ecb7d2e@mail.gmail.com> <87373C76-C757-4921-9497-BA05F4CE977B@apple.com> <7DC96595-C064-4368-AE67-2494E4844C85@zhuk.fi> <1b587cab0901170712v7e2c1d47k584f7486d4151f8e@mail.gmail.com> Message-ID: <1b587cab0901171057k7a272cccyc6392e9a7a600062@mail.gmail.com> On Sat, Jan 17, 2009 at 4:58 PM, Nikita Zhuk wrote: > > On 17.1.2009, at 17.12, Ben Laurie wrote: > >> On Sat, Jan 17, 2009 at 3:05 PM, Nikita Zhuk wrote: >>> >>> If/when clang static analyzer will allow easy extensibility as Ted >>> described in option [3], it would be very interesting to see if clang >>> user community could come up with some collaborative way of sharing >>> various custom checks as pluggable & configurable components. A wiki, >>> perhaps? I think that sharing programming experience and knowledge as >>> clang analyzer checks for common programming errors and best practices >>> would be useful for open source community. >> >> What would be wrong with just integrating them into the source and >> having them invdividually enableable? > > There's nothing wrong with integrating additional checks into clang, of > course. However, as a Mac developer and clang user I would like to be able > to download and install additional checks simply by dropping the downloaded > binary into some directory, without recompiling clang each time I'd like to > try a new check which some other developer has written. I also suspect that > some checks could exist which aren't completely in line with clang's goals, > e.g. which generate too many false positives for average project, but which > would be beneficial in projects of a specific type. For example, I have > written some specific coding convention checks which have way too high level > of false positives for being included into the official clang, but which are > useful for developers who follow the same conventions. I am totally a fan of modular plugin designs (I wrote the Apache 2 plugin management system, for example), so very much agreed. How well does the current architecture support dynamic plugins? Perhaps support for that is somewhere I could be instantly useful! :-) From benl at google.com Sat Jan 17 12:58:06 2009 From: benl at google.com (Ben Laurie) Date: Sat, 17 Jan 2009 18:58:06 +0000 Subject: [cfe-dev] Static analysis tool development In-Reply-To: <4B79325B-C1EA-4057-8C4F-15D7A40D887A@apple.com> References: <73e8e3430901160846v734a65ch28dae1f04ecb7d2e@mail.gmail.com> <87373C76-C757-4921-9497-BA05F4CE977B@apple.com> <7DC96595-C064-4368-AE67-2494E4844C85@zhuk.fi> <1b587cab0901170712v7e2c1d47k584f7486d4151f8e@mail.gmail.com> <4B79325B-C1EA-4057-8C4F-15D7A40D887A@apple.com> Message-ID: <1b587cab0901171058j5b2cb765s5367b52d65e392bc@mail.gmail.com> On Sat, Jan 17, 2009 at 6:05 PM, Mike Stump wrote: > On Jan 17, 2009, at 7:12 AM, Ben Laurie wrote: >> >> What would be wrong with just integrating them into the source and >> having them invdividually enableable? > > What's wrong with: > > #include Does that work? If so, awesome! If not, well, it should! From clattner at apple.com Sat Jan 17 13:06:30 2009 From: clattner at apple.com (Chris Lattner) Date: Sat, 17 Jan 2009 11:06:30 -0800 Subject: [cfe-dev] Static analysis tool development In-Reply-To: <1b587cab0901171057k7a272cccyc6392e9a7a600062@mail.gmail.com> References: <73e8e3430901160846v734a65ch28dae1f04ecb7d2e@mail.gmail.com> <87373C76-C757-4921-9497-BA05F4CE977B@apple.com> <7DC96595-C064-4368-AE67-2494E4844C85@zhuk.fi> <1b587cab0901170712v7e2c1d47k584f7486d4151f8e@mail.gmail.com> <1b587cab0901171057k7a272cccyc6392e9a7a600062@mail.gmail.com> Message-ID: On Jan 17, 2009, at 10:57 AM, Ben Laurie wrote: > I am totally a fan of modular plugin designs (I wrote the Apache 2 > plugin management system, for example), so very much agreed. > > How well does the current architecture support dynamic plugins? > Perhaps support for that is somewhere I could be instantly useful! :-) LLVM supports dynamically loadable optimizations, code generators, etc. It would not be hard to dlopen("mycoolanalysis.so"). However, I think there are two separate things being discussed here: 1) checks written in C++, and 2) checks written in a higher-level (e.g. scripting) language. Right now, we have none of #2, but we definitely will in the future. I think most checks will end up being built off a shared analysis core written in C++, but whose high-level logic is implemented in a scripting language. We're just not quite there yet, and getting the design of the core solid and fully featured is more important than getting the bindings going (to the current contributors). -Chris From csdavec at swansea.ac.uk Sun Jan 18 10:14:34 2009 From: csdavec at swansea.ac.uk (David Chisnall) Date: Sun, 18 Jan 2009 16:14:34 +0000 Subject: [cfe-dev] Fixing selector types on the GNU runtime Message-ID: <8518A0F5-8613-4E87-8AE7-264F547617F3@swan.ac.uk> Hi Everyone, The attached patch modifies CGObjCGNU to take the selector type from the front end. This fixes the crash caused by parts of the code expecting a packed structure and parts expecting an unpacked one for the selector type. I've also included some fixes in this patch which turn NULL into (void*)0 when it is used as a sentinel in variadic functions. This gets rid of a load of warnings when compiling and stops it breaking on 64-bit architectures. David -------------- next part -------------- A non-text attachment was scrubbed... Name: clang.diff Type: application/octet-stream Size: 9639 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090118/4a855168/attachment-0001.obj From clattner at apple.com Sun Jan 18 14:06:14 2009 From: clattner at apple.com (Chris Lattner) Date: Sun, 18 Jan 2009 12:06:14 -0800 Subject: [cfe-dev] Fixing selector types on the GNU runtime In-Reply-To: <8518A0F5-8613-4E87-8AE7-264F547617F3@swan.ac.uk> References: <8518A0F5-8613-4E87-8AE7-264F547617F3@swan.ac.uk> Message-ID: <21970411-3554-4EBE-BB30-A9F6B125029B@apple.com> On Jan 18, 2009, at 8:14 AM, David Chisnall wrote: > I've also included some fixes in this patch which turn NULL into > (void*)0 when it is used as a sentinel in variadic functions. This > gets rid of a load of warnings when compiling and stops it breaking > on 64-bit architectures. Why are you getting this? There are tons of other places that pass NULL as a sentinel. Is NULL getting defined incorrectly for that file? NULL needs to be a pointer type, so it should be fine on 64-bit systems. Passing a raw "0" would not be. -Chris From bagnara at cs.unipr.it Sun Jan 18 15:14:12 2009 From: bagnara at cs.unipr.it (Roberto Bagnara) Date: Sun, 18 Jan 2009 22:14:12 +0100 Subject: [cfe-dev] Parsing, pretty-printing, and compiling the result should work, right? Message-ID: <49739BA4.80907@cs.unipr.it> Hi there, from some of the replies we got to bug reports we submitted I gather that it is best if we ask the advice of this list concerning what we are trying to do. Our first objective is to understand whether clang can be the parser for a program analyzer we are building. In order to ascertain that, our plan was to build confidence on clang by: 1) Writing a pretty-printer that produces parsable C code from the AST. 2) Writing a driver that calls the parser, then the pretty-printer, and then invokes gcc over the pretty-printed program. In other words, this driver behaves exactly like plain gcc, with the only difference that it will compile the program produced by clang + pretty-printer instead of what gcc would normally obtain by running its own preprocessor. 3) Using this driver, compile as much code as possible (Linux, GNU software a go-go, everything we can put our hand on) and check whether the result runs as expected. Unless we have grossly misinterpreted the objectives of the clang project, this kind of exercise should be regared as valuable: right? Point 2) is basically complete. Full realization of point 1) is currently impeded by a number of problems for which we have pending bug reports. For those we are unsure whether it is best to: a) wait for a fix; b) implement a workaround in the pretty-printer. Solution b) is not very attractive, since the only solution we see for some of the open problems would be to complicate the pretty-printer to a point where it is no longer a pretty-printer (but something that, instead of working sequentially, has to walk through the entire AST in order to gather information that has been moved by clang to places that are far from where it should be printed). Please, let me know what you think about the above: perhaps we have made some wrong choices and we do not want to waste our time or the time of anyone. Thanks a lot, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara at cs.unipr.it From alexei.svitkine at gmail.com Sun Jan 18 15:27:49 2009 From: alexei.svitkine at gmail.com (Alexei Svitkine) Date: Sun, 18 Jan 2009 16:27:49 -0500 Subject: [cfe-dev] Parsing, pretty-printing, and compiling the result should work, right? In-Reply-To: <49739BA4.80907@cs.unipr.it> References: <49739BA4.80907@cs.unipr.it> Message-ID: <62d9ffc00901181327g6cbbcb6ci28387f3001362cd6@mail.gmail.com> > For those we are unsure whether it is best to: > > a) wait for a fix; > b) implement a workaround in the pretty-printer. I think you missed another possibility: c) fix it in clang and submit a patch -Alexei From clattner at apple.com Sun Jan 18 15:57:26 2009 From: clattner at apple.com (Chris Lattner) Date: Sun, 18 Jan 2009 13:57:26 -0800 Subject: [cfe-dev] Parsing, pretty-printing, and compiling the result should work, right? In-Reply-To: <49739BA4.80907@cs.unipr.it> References: <49739BA4.80907@cs.unipr.it> Message-ID: On Jan 18, 2009, at 1:14 PM, Roberto Bagnara wrote: > > Hi there, > > from some of the replies we got to bug reports we submitted I gather > that it is best if we ask the advice of this list concerning what we > are trying to do. Hi Roberto, I agree that this is a better place to discuss this than in individual bugzillas, > Our first objective is to understand whether clang can be the parser > for a program analyzer we are building. In order to ascertain that, > our plan was to build confidence on clang by: > > 1) Writing a pretty-printer that produces parsable C code from the > AST. > 2) Writing a driver that calls the parser, then the pretty-printer, > and > then invokes gcc over the pretty-printed program. In other > words, this > driver behaves exactly like plain gcc, with the only difference > that it will compile the program produced by clang + pretty-printer > instead of what gcc would normally obtain by running its own > preprocessor. > 3) Using this driver, compile as much code as possible (Linux, GNU > software > a go-go, everything we can put our hand on) and check whether the > result > runs as expected. Ok, this sounds like a great project. I don't know of anyone doing anything similar, but it seems very useful to a variety of different people. > Unless we have grossly misinterpreted the objectives of the clang > project, > this kind of exercise should be regared as valuable: right? Absolutely! > Point 2) is basically complete. Full realization of point 1) is > currently > impeded by a number of problems for which we have pending bug reports. > For those we are unsure whether it is best to: > > a) wait for a fix; > b) implement a workaround in the pretty-printer. This is a general problem with Open Source projects. You're interested in doing something that would be very valuable for Clang to do, however, Clang isn't quite there yet. Further, you are the first person to want to do this, and you're hitting problems. Unfortunately, clang is developed by volunteers, and most of them have their own specific agenda that they prioritize. For example, mine is "make clang a production quality C compiler sooner rather than later". This means that you can't really "force" someone to fix a bug or implement a feature that you're lacking. Your options basically come down to: 1) fix it yourself. The various issues you have identified would all be great to fix in clang, so I'm sure that the patches would be welcome. 2) pay someone to fix it. 3) try to stir up interest in the problem, so that someone else feels compelled to look into it. 4) find a way to work around the problem. I think your email has the effect of doing #3, as I think that many people would find this functionality useful. For #4, you might want to consider using the rewriter infrastructure, which does not suffer from the class of problem and is already in use for several projects. -Chris From sebastian.redl at getdesigned.at Sun Jan 18 16:12:52 2009 From: sebastian.redl at getdesigned.at (Sebastian Redl) Date: Sun, 18 Jan 2009 23:12:52 +0100 Subject: [cfe-dev] Fixing selector types on the GNU runtime In-Reply-To: <21970411-3554-4EBE-BB30-A9F6B125029B@apple.com> References: <8518A0F5-8613-4E87-8AE7-264F547617F3@swan.ac.uk> <21970411-3554-4EBE-BB30-A9F6B125029B@apple.com> Message-ID: <4973A964.9040800@getdesigned.at> Chris Lattner wrote: > On Jan 18, 2009, at 8:14 AM, David Chisnall wrote: > >> I've also included some fixes in this patch which turn NULL into >> (void*)0 when it is used as a sentinel in variadic functions. This >> gets rid of a load of warnings when compiling and stops it breaking >> on 64-bit architectures. >> > > Why are you getting this? There are tons of other places that pass > NULL as a sentinel. Is NULL getting defined incorrectly for that > file? NULL needs to be a pointer type, so it should be fine on 64-bit > systems. Passing a raw "0" would not be. > In C++, NULL cannot be a pointer type, because there is no implicit cast from void* to other pointers. So it is usually defined to be 0 or 0L. In GCC, it's defined to be __null, but that's just 0 with a warning when used as an integer. So some compiler might be smart enough to convert its __null equivalent to pointer size when passed as vararg, or to define NULL to an integer constant that is actually the platform pointer size (e.g. 0L for GCC, but 0LL for MSVC), but I really wouldn't rely on it. The standard fails to specify that NULL must be as wide as a pointer (a defect IMO), so you can't trust the constant. It's one of the most subtle and evil gotchas in C++, really. Sebastian From hhinnant at apple.com Sun Jan 18 16:55:37 2009 From: hhinnant at apple.com (Howard Hinnant) Date: Sun, 18 Jan 2009 17:55:37 -0500 Subject: [cfe-dev] Fixing selector types on the GNU runtime In-Reply-To: <4973A964.9040800@getdesigned.at> References: <8518A0F5-8613-4E87-8AE7-264F547617F3@swan.ac.uk> <21970411-3554-4EBE-BB30-A9F6B125029B@apple.com> <4973A964.9040800@getdesigned.at> Message-ID: On Jan 18, 2009, at 5:12 PM, Sebastian Redl wrote: > Chris Lattner wrote: >> On Jan 18, 2009, at 8:14 AM, David Chisnall wrote: >> >>> I've also included some fixes in this patch which turn NULL into >>> (void*)0 when it is used as a sentinel in variadic functions. This >>> gets rid of a load of warnings when compiling and stops it breaking >>> on 64-bit architectures. >>> >> >> Why are you getting this? There are tons of other places that pass >> NULL as a sentinel. Is NULL getting defined incorrectly for that >> file? NULL needs to be a pointer type, so it should be fine on 64- >> bit >> systems. Passing a raw "0" would not be. >> > In C++, NULL cannot be a pointer type, because there is no implicit > cast > from void* to other pointers. So it is usually defined to be 0 or > 0L. In > GCC, it's defined to be __null, but that's just 0 with a warning when > used as an integer. > > So some compiler might be smart enough to convert its __null > equivalent > to pointer size when passed as vararg, or to define NULL to an integer > constant that is actually the platform pointer size (e.g. 0L for GCC, > but 0LL for MSVC), but I really wouldn't rely on it. The standard > fails > to specify that NULL must be as wide as a pointer (a defect IMO), so > you > can't trust the constant. > > It's one of the most subtle and evil gotchas in C++, really. nullptr might be one of those C++0X features worth prioritizing. -Howard From csdavec at swansea.ac.uk Sun Jan 18 17:01:08 2009 From: csdavec at swansea.ac.uk (David Chisnall) Date: Sun, 18 Jan 2009 23:01:08 +0000 Subject: [cfe-dev] Fixing selector types on the GNU runtime In-Reply-To: <21970411-3554-4EBE-BB30-A9F6B125029B@apple.com> References: <8518A0F5-8613-4E87-8AE7-264F547617F3@swan.ac.uk> <21970411-3554-4EBE-BB30-A9F6B125029B@apple.com> Message-ID: On 18 Jan 2009, at 20:06, Chris Lattner wrote: > On Jan 18, 2009, at 8:14 AM, David Chisnall wrote: >> I've also included some fixes in this patch which turn NULL into >> (void*)0 when it is used as a sentinel in variadic functions. This >> gets rid of a load of warnings when compiling and stops it breaking >> on 64-bit architectures. > > Why are you getting this? There are tons of other places that pass > NULL as a sentinel. Is NULL getting defined incorrectly for that > file? NULL needs to be a pointer type, so it should be fine on 64- > bit systems. Passing a raw "0" would not be. NULL is #defined as 0 for C++ ((void*)0 for C) on FreeBSD. I get missing sentinels in a huge numbers of missing sentinel errors when building LLVM. When I first came across this, I assumed it was a bug in the implementation, but checking the spec apparently it can't be a void* because C++ doesn't allow the type escaping here. In other places I've worked around this by defining NULLP in C++ as a C NULL and using this in sentinels. On some 64-bit systems it will work fine, since the sentinel will be passed in a register and will be sign extended. This is somewhat dependent on the number of other arguments though - I have a couple of variadic calls here with enough arguments that the sentinel will go on the stack on at least some architectures (SPARC64, for example), at which point it will cause some stack corruption if the stack doesn't happen to have 32 0 bits immediately before the sentinel. David From sebastian.redl at getdesigned.at Sun Jan 18 17:35:27 2009 From: sebastian.redl at getdesigned.at (Sebastian Redl) Date: Mon, 19 Jan 2009 00:35:27 +0100 Subject: [cfe-dev] Fixing selector types on the GNU runtime In-Reply-To: References: <8518A0F5-8613-4E87-8AE7-264F547617F3@swan.ac.uk> <21970411-3554-4EBE-BB30-A9F6B125029B@apple.com> <4973A964.9040800@getdesigned.at> Message-ID: <4973BCBF.70807@getdesigned.at> Howard Hinnant wrote: > nullptr might be one of those C++0X features worth prioritizing. > Yes. The semantics of nullptr in the face of varargs are correct. However, prioritizing nullptr in Clang is of little use unless we can actually compile Clang with Clang, and are willing to accept that it won't compile on other compilers. I very much doubt this is the case. Sebastian From dgregor at apple.com Sun Jan 18 19:02:58 2009 From: dgregor at apple.com (Douglas Gregor) Date: Sun, 18 Jan 2009 17:02:58 -0800 Subject: [cfe-dev] [Patch] IDNS_NoLookup? In-Reply-To: <7925cd330901141217j6aa49672p4917d76b01e3fabc@mail.gmail.com> References: <7925cd330901141217j6aa49672p4917d76b01e3fabc@mail.gmail.com> Message-ID: Hi Piotr, On Jan 14, 2009, at 12:17 PM, Piotr Rak wrote: > I would like to introduce new identifier namespace, which would cause > ScopedDecl not be added to DeclContext lookup structure. Currently it > IdentifierResolver saves us somehow from building lookup structure for > TranslationUnit, however, as i mentioned few weeks earlier I store > using-directives in lookup structure. This causes it to be build for > TranslationUnitDecl too in my local copy. using-directives won't have names, right? So it doesn't really matter that they won't have any identifier namespace defined for them. > This fails for > ObjCImplementation (there might be more somewhere in ObjC code, not > really sure...), which has associated name but getIdentifierNamespace > is not defined for it. I could probably workaround it, but this way > feels `less hackish`. Please note that this change also saves from > crash client code, that would call TranslationUnitDecl::lookup(), when > it owns ObjCImplementationDecls. > Ah, so that's the issue... the ObjCImplementationDecls need to have an identifier namespace, because they have name, but they aren't supposed to be found by name lookup (rather, we see them through the ObjCInterfaceDecl). Adding another namespace will work, but I don't know if it's the best answer. Perhaps what we really mean is that ObjCImplementationDecls really don't have names at all: they're just unnamed entities that attach to other entities, and the only reason they have a name in the source code is to tie them to the appropriate interface: @interface Blah @end @implementation Blah /* ties this ObjCImplementationDecl to the ObjCInterfaceDecl above */ @end One could certainly ask an ObjCImplementationDecl what the name of its corresponding interface is, through a separate operation, even though the ObjCImplementationDecl itself is unnamed. I'm not quite sure which way to go with this. IDNS_NoLookup works, but I think an unnamed ObjCImplementationDecl will be better. Let's see if someone with a better understanding of Objective-C semantics can chime in to see if my understanding of ObjCImplementationDecl is reasonable. - Doug From clattner at apple.com Sun Jan 18 19:58:43 2009 From: clattner at apple.com (Chris Lattner) Date: Sun, 18 Jan 2009 17:58:43 -0800 Subject: [cfe-dev] [Patch] IDNS_NoLookup? In-Reply-To: References: <7925cd330901141217j6aa49672p4917d76b01e3fabc@mail.gmail.com> Message-ID: On Jan 18, 2009, at 5:02 PM, Douglas Gregor wrote: > Ah, so that's the issue... the ObjCImplementationDecls need to have an > identifier namespace, because they have name, but they aren't > supposed to be found by name lookup (rather, we see them through the > ObjCInterfaceDecl). Ah, very interesting. I think the right fix is that ObjCImplementationDecl should not be scope decls and maybe not even NamedDecls. They should never ever be "looked up". Steve, Fariborz, what do you guys think? -Chris From dgregor at apple.com Sun Jan 18 22:00:56 2009 From: dgregor at apple.com (Douglas Gregor) Date: Sun, 18 Jan 2009 20:00:56 -0800 Subject: [cfe-dev] [Patch] IDNS_NoLookup? In-Reply-To: References: <7925cd330901141217j6aa49672p4917d76b01e3fabc@mail.gmail.com> Message-ID: On Jan 18, 2009, at 5:58 PM, Chris Lattner wrote: > On Jan 18, 2009, at 5:02 PM, Douglas Gregor wrote: >> Ah, so that's the issue... the ObjCImplementationDecls need to have >> an >> identifier namespace, because they have name, but they aren't >> supposed to be found by name lookup (rather, we see them through the >> ObjCInterfaceDecl). > > Ah, very interesting. I think the right fix is that > ObjCImplementationDecl should not be scope decls and maybe not even > NamedDecls. They should never ever be "looked up". I think we should swap ScopedDecl and NamedDecl in the inheritance hierarchy. Things without names---like, perhaps, ObjCImplementationDecl---should still be ScopedDecls and live inside DeclContexts (so we know where they occur, lexically, in the program, and who their owners are) but they don't need any storage for names. So, we would just have class NamedDecl : public ScopedDecl { DeclarationName Name; public: // ... }; Right now, the only ScopedDecl that isn't a NamedDecl is OverloadedFunctionDecl, and it's probably going away in favor of Argiris' idea for an OverloadedNameExpr. As Piotr had mentioned before, using directives are also never found by name lookup, but they do have scope, so they're natural ScopedDecls but not NamedDecls. - Doug From clattner at apple.com Mon Jan 19 00:06:01 2009 From: clattner at apple.com (Chris Lattner) Date: Sun, 18 Jan 2009 22:06:01 -0800 Subject: [cfe-dev] [Patch] IDNS_NoLookup? In-Reply-To: References: <7925cd330901141217j6aa49672p4917d76b01e3fabc@mail.gmail.com> Message-ID: On Jan 18, 2009, at 8:00 PM, Douglas Gregor wrote: > > On Jan 18, 2009, at 5:58 PM, Chris Lattner wrote: > >> On Jan 18, 2009, at 5:02 PM, Douglas Gregor wrote: >>> Ah, so that's the issue... the ObjCImplementationDecls need to >>> have an >>> identifier namespace, because they have name, but they aren't >>> supposed to be found by name lookup (rather, we see them through the >>> ObjCInterfaceDecl). >> >> Ah, very interesting. I think the right fix is that >> ObjCImplementationDecl should not be scope decls and maybe not even >> NamedDecls. They should never ever be "looked up". > > I think we should swap ScopedDecl and NamedDecl in the inheritance > hierarchy. Things without names---like, perhaps, > ObjCImplementationDecl---should still be ScopedDecls and live inside > DeclContexts (so we know where they occur, lexically, in the > program, and who their owners are) but they don't need any storage > for names. So, we would just have > > class NamedDecl : public ScopedDecl { > DeclarationName Name; > public: > // ... > }; > > Right now, the only ScopedDecl that isn't a NamedDecl is > OverloadedFunctionDecl, and it's probably going away in favor of > Argiris' idea for an OverloadedNameExpr. As Piotr had mentioned > before, using directives are also never found by name lookup, but > they do have scope, so they're natural ScopedDecls but not NamedDecls. That makes a lot of sense to me! -Chris From bagnara at cs.unipr.it Mon Jan 19 02:07:26 2009 From: bagnara at cs.unipr.it (Roberto Bagnara) Date: Mon, 19 Jan 2009 09:07:26 +0100 Subject: [cfe-dev] Parsing, pretty-printing, and compiling the result should work, right? In-Reply-To: References: <49739BA4.80907@cs.unipr.it> Message-ID: <497434BE.6050504@cs.unipr.it> Chris Lattner wrote: >> Point 2) is basically complete. Full realization of point 1) is >> currently >> impeded by a number of problems for which we have pending bug reports. >> For those we are unsure whether it is best to: >> >> a) wait for a fix; >> b) implement a workaround in the pretty-printer. > > > This is a general problem with Open Source projects. You're interested > in doing something that would be very valuable for Clang to do, however, > Clang isn't quite there yet. Further, you are the first person to want > to do this, and you're hitting problems. > > Unfortunately, clang is developed by volunteers, and most of them have > their own specific agenda that they prioritize. Hi there, thanks to all who responded. Please note that we know how Open Source and Free Software projects work, and my group is actually contributing significant pieces of code to the community. So we are all volunteers. > For example, mine is > "make clang a production quality C compiler sooner rather than later". Good. But since you cannot compile what you cannot parse, our agendas have a significant overlap: actually, mine is a strict subset of yours. This was actually my argument when I convinced my group to use clang ("they certainly will want to correctly parse all the code out there"). > This means that you can't really "force" someone to fix a bug or > implement a feature that you're lacking. Of course. > Your options basically come > down to: > > 1) fix it yourself. The various issues you have identified would all be > great to fix in clang, so I'm sure that the patches would be welcome. The problem is that we do not have the manpower to do that. All the manpower we have is invested in other (Free Software) projects. > 2) pay someone to fix it. ROTFL: http://www.nature.com/nature/journal/v455/n7215/full/455835b.html Do you know that many italian universities will have serious troubles paying salaries one year from now? Really, this is not an option. > 3) try to stir up interest in the problem, so that someone else feels > compelled to look into it. For at least two bug reports, I really hope this will be the case because I really do not think a workaround exist. > 4) find a way to work around the problem. We will do that for all the remaining problems. This is actually a tough decision for me: if 2749 and 3261 are not fixed in a reasonable time frame we will have to drop clang and I will have wasted the time of several people. Cheers, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara at cs.unipr.it From lujiandong1001 at yahoo.com.cn Mon Jan 19 07:52:47 2009 From: lujiandong1001 at yahoo.com.cn (Jiandong Lu) Date: Mon, 19 Jan 2009 21:52:47 +0800 (CST) Subject: [cfe-dev] too slow to build clang Message-ID: <994042.68889.qm@web15708.mail.cnb.yahoo.com> hi,everyone. I logined llvm's bugzilla,got a bug.And I want to fix it. I add only debug statement to output something ,and than build clang in my FreeBSD 7.1 in vmware. I found it took about tens of minutes.Although my machine is a little slow (celeron 2.4 G cpu), I think it took too many minutes.Maybe there something is wrong. ? ___________________________________________________________ ????????????????? http://card.mail.cn.yahoo.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090119/5eae2950/attachment.html From dgregor at apple.com Mon Jan 19 09:44:36 2009 From: dgregor at apple.com (Douglas Gregor) Date: Mon, 19 Jan 2009 07:44:36 -0800 Subject: [cfe-dev] too slow to build clang In-Reply-To: <994042.68889.qm@web15708.mail.cnb.yahoo.com> References: <994042.68889.qm@web15708.mail.cnb.yahoo.com> Message-ID: On Jan 19, 2009, at 5:52 AM, Jiandong Lu wrote: > hi,everyone. > I logined llvm's bugzilla,got a bug.And I want to fix it. Great! > > I add only debug statement to output something ,and than build clang > in my FreeBSD 7.1 in vmware. > I found it took about tens of minutes.Although my machine is a > little slow (celeron 2.4 G cpu), > I think it took too many minutes.Maybe there something is wrong. > Clang and LLVM are relatively large, so it does take some time to compile them. The biggest issue is often memory: does your VMware virtual machine have at least 1 GB memory? Also, it helps to configure LLVM with --enable-targets=. Otherwise, you're spending a lot of time compiling and linking back-end targets you probably don't care about (Sparc, Cell, etc.). - Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090119/ac5aed49/attachment-0001.html From fjahanian at apple.com Mon Jan 19 11:42:40 2009 From: fjahanian at apple.com (Fariborz Jahanian) Date: Mon, 19 Jan 2009 09:42:40 -0800 Subject: [cfe-dev] [Patch] IDNS_NoLookup? In-Reply-To: References: <7925cd330901141217j6aa49672p4917d76b01e3fabc@mail.gmail.com> Message-ID: <5595D5A0-FB96-4283-AC9F-F6CD4472623D@apple.com> On Jan 18, 2009, at 5:02 PM, Douglas Gregor wrote: > Hi Piotr, > > On Jan 14, 2009, at 12:17 PM, Piotr Rak wrote: >> I would like to introduce new identifier namespace, which would cause >> ScopedDecl not be added to DeclContext lookup structure. Currently it >> IdentifierResolver saves us somehow from building lookup structure >> for >> TranslationUnit, however, as i mentioned few weeks earlier I store >> using-directives in lookup structure. This causes it to be build for >> TranslationUnitDecl too in my local copy. > > using-directives won't have names, right? So it doesn't really matter > that they won't have any identifier namespace defined for them. > >> This fails for >> ObjCImplementation (there might be more somewhere in ObjC code, not >> really sure...), which has associated name but getIdentifierNamespace >> is not defined for it. I could probably workaround it, but this way >> feels `less hackish`. Please note that this change also saves from >> crash client code, that would call TranslationUnitDecl::lookup(), >> when >> it owns ObjCImplementationDecls. >> > > Ah, so that's the issue... the ObjCImplementationDecls need to have an > identifier namespace, because they have name, but they aren't > supposed to be found by name lookup (rather, we see them through the > ObjCInterfaceDecl). > > Adding another namespace will work, but I don't know if it's the best > answer. Perhaps what we really mean is that ObjCImplementationDecls > really don't have names at all: they're just unnamed entities that > attach to other entities, and the only reason they have a name in the > source code is to tie them to the appropriate interface: > > @interface Blah > @end > > @implementation Blah /* ties this ObjCImplementationDecl to the > ObjCInterfaceDecl above */ > @end > > One could certainly ask an ObjCImplementationDecl what the name of its > corresponding interface is, through a separate operation, even though > the ObjCImplementationDecl itself is unnamed. > > I'm not quite sure which way to go with this. IDNS_NoLookup works, but > I think an unnamed ObjCImplementationDecl will be better. Let's see if > someone with a better understanding of Objective-C semantics can chime > in to see if my understanding of ObjCImplementationDecl is reasonable. There are couple of situations that @implementation is not tied to its interface; case of an @implementation without an interface case of a category @implementation which ties it to its category even though there must be an interface as well. But this case need go though ObjCCategoryDecl (which then has the ObjCInterfaceDecl). There might be other corner cases that I cannot recall at this time. - Fariborz > > > - Doug > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From rmann at latencyzero.com Mon Jan 19 12:09:07 2009 From: rmann at latencyzero.com (Rick Mann) Date: Mon, 19 Jan 2009 10:09:07 -0800 Subject: [cfe-dev] too slow to build clang In-Reply-To: References: <994042.68889.qm@web15708.mail.cnb.yahoo.com> Message-ID: On Jan 19, 2009, at 07:44:36, Douglas Gregor wrote: > On Jan 19, 2009, at 5:52 AM, Jiandong Lu wrote: > >> add only debug statement to output something ,and than build clang >> in my FreeBSD 7.1 in vmware. >> I found it took about tens of minutes.Although my machine is a >> little slow (celeron 2.4 G cpu), >> I think it took too many minutes.Maybe there something is wrong. >> > > Clang and LLVM are relatively large, so it does take some time to > compile them. The biggest issue is often memory: does your VMware > virtual machine have at least 1 GB memory? > > Also, it helps to configure LLVM with --enable-targets= subset of targets>. Otherwise, you're spending a lot of time > compiling and linking back-end targets you probably don't care about > (Sparc, Cell, etc.). It seemed to me like he was saying that after the initial build, changing a single file (presumably not a header file) still required a substantial rebuild. But I'm just speculating. Using the Xcode build project, I have not experienced this to be the case. -- Rick From dgregor at apple.com Mon Jan 19 12:39:34 2009 From: dgregor at apple.com (Douglas Gregor) Date: Mon, 19 Jan 2009 10:39:34 -0800 Subject: [cfe-dev] too slow to build clang In-Reply-To: References: <994042.68889.qm@web15708.mail.cnb.yahoo.com> Message-ID: On Jan 19, 2009, at 10:09 AM, Rick Mann wrote: > > On Jan 19, 2009, at 07:44:36, Douglas Gregor wrote: > >> On Jan 19, 2009, at 5:52 AM, Jiandong Lu wrote: >> >>> add only debug statement to output something ,and than build clang >>> in my FreeBSD 7.1 in vmware. >>> I found it took about tens of minutes.Although my machine is a >>> little slow (celeron 2.4 G cpu), >>> I think it took too many minutes.Maybe there something is wrong. >>> >> >> Clang and LLVM are relatively large, so it does take some time to >> compile them. The biggest issue is often memory: does your VMware >> virtual machine have at least 1 GB memory? >> >> Also, it helps to configure LLVM with --enable-targets=> subset of targets>. Otherwise, you're spending a lot of time >> compiling and linking back-end targets you probably don't care about >> (Sparc, Cell, etc.). > > It seemed to me like he was saying that after the initial build, > changing a single file (presumably not a header file) still required a > substantial rebuild. But I'm just speculating. Using the Xcode build > project, I have not experienced this to be the case. The rebuild is pretty minimal for the makefiles, too, although linking takes a while. - Doug From rmann at latencyzero.com Mon Jan 19 12:41:33 2009 From: rmann at latencyzero.com (Rick Mann) Date: Mon, 19 Jan 2009 10:41:33 -0800 Subject: [cfe-dev] too slow to build clang In-Reply-To: References: <994042.68889.qm@web15708.mail.cnb.yahoo.com> Message-ID: <62CEDDBB-DE99-4BD9-9464-1C4D63E4CC3D@latencyzero.com> On Jan 19, 2009, at 10:39:34, Douglas Gregor wrote: > The rebuild is pretty minimal for the makefiles, too, although > linking takes a while. I wonder if we could link with gold ? -- Rick From echristo at apple.com Mon Jan 19 12:50:16 2009 From: echristo at apple.com (Eric Christopher) Date: Mon, 19 Jan 2009 10:50:16 -0800 Subject: [cfe-dev] too slow to build clang In-Reply-To: <62CEDDBB-DE99-4BD9-9464-1C4D63E4CC3D@latencyzero.com> References: <994042.68889.qm@web15708.mail.cnb.yahoo.com> <62CEDDBB-DE99-4BD9-9464-1C4D63E4CC3D@latencyzero.com> Message-ID: <9AE2878C-7412-41FE-9808-51457035923B@apple.com> On Jan 19, 2009, at 10:41 AM, Rick Mann wrote: > > On Jan 19, 2009, at 10:39:34, Douglas Gregor wrote: > >> The rebuild is pretty minimal for the makefiles, too, although >> linking takes a while. > > > I wonder if we could link with gold ? Only on linux at this point. -eric From rmann at latencyzero.com Mon Jan 19 13:08:39 2009 From: rmann at latencyzero.com (Rick Mann) Date: Mon, 19 Jan 2009 11:08:39 -0800 Subject: [cfe-dev] too slow to build clang In-Reply-To: <9AE2878C-7412-41FE-9808-51457035923B@apple.com> References: <994042.68889.qm@web15708.mail.cnb.yahoo.com> <62CEDDBB-DE99-4BD9-9464-1C4D63E4CC3D@latencyzero.com> <9AE2878C-7412-41FE-9808-51457035923B@apple.com> Message-ID: <6C7AD1E6-1D5B-493E-955C-6C1EA8F54DC3@latencyzero.com> On Jan 19, 2009, at 10:50:16, Eric Christopher wrote: > > On Jan 19, 2009, at 10:41 AM, Rick Mann wrote: > >> >> On Jan 19, 2009, at 10:39:34, Douglas Gregor wrote: >> >>> The rebuild is pretty minimal for the makefiles, too, although >>> linking takes a while. >> >> >> I wonder if we could link with gold ? > > Only on linux at this point. Aww. Boo linux...always messing things up. -- Rick From rmann at latencyzero.com Mon Jan 19 13:40:20 2009 From: rmann at latencyzero.com (Rick Mann) Date: Mon, 19 Jan 2009 11:40:20 -0800 Subject: [cfe-dev] too slow to build clang In-Reply-To: <9AE2878C-7412-41FE-9808-51457035923B@apple.com> References: <994042.68889.qm@web15708.mail.cnb.yahoo.com> <62CEDDBB-DE99-4BD9-9464-1C4D63E4CC3D@latencyzero.com> <9AE2878C-7412-41FE-9808-51457035923B@apple.com> Message-ID: On Jan 19, 2009, at 10:50:16, Eric Christopher wrote: > Only on linux at this point. In more seriousness, what would it take to run gold on Mac OS X? -- Rick From echristo at apple.com Mon Jan 19 13:42:50 2009 From: echristo at apple.com (Eric Christopher) Date: Mon, 19 Jan 2009 11:42:50 -0800 Subject: [cfe-dev] too slow to build clang In-Reply-To: References: <994042.68889.qm@web15708.mail.cnb.yahoo.com> <62CEDDBB-DE99-4BD9-9464-1C4D63E4CC3D@latencyzero.com> <9AE2878C-7412-41FE-9808-51457035923B@apple.com> Message-ID: <0DA2A037-7C7E-4236-B6F1-9333807433BC@apple.com> On Jan 19, 2009, at 11:40 AM, Rick Mann wrote: > > On Jan 19, 2009, at 10:50:16, Eric Christopher wrote: > >> Only on linux at this point. > > > In more seriousness, what would it take to run gold on Mac OS X? Someone to port it to handle Mach-O. I'm not sure what this would take. ld64 isn't too bad on OSX though for link times. -eric From csdavec at swansea.ac.uk Mon Jan 19 13:47:25 2009 From: csdavec at swansea.ac.uk (David Chisnall) Date: Mon, 19 Jan 2009 19:47:25 +0000 Subject: [cfe-dev] too slow to build clang In-Reply-To: References: <994042.68889.qm@web15708.mail.cnb.yahoo.com> <62CEDDBB-DE99-4BD9-9464-1C4D63E4CC3D@latencyzero.com> <9AE2878C-7412-41FE-9808-51457035923B@apple.com> Message-ID: <39715C32-97CE-46A9-BA30-60736259C37C@swan.ac.uk> On 19 Jan 2009, at 19:40, Rick Mann wrote: > > On Jan 19, 2009, at 10:50:16, Eric Christopher wrote: > >> Only on linux at this point. > > > In more seriousness, what would it take to run gold on Mac OS X? Major and invasive changes to the OS X loader. Gold is fast because it only supports one binary format, ELF, while the older GNU ld supports a.out, ELF and COFF. OS X uses Mach-O, and is not supported by either. I don't know how Gold compares in terms of performance to the NeXT / Apple linker, but I'd be surprised if there was a big difference in performance since the Apple linker hasn't inherited the same level of cruft as the GNU linker from having multiple binary formats added over time. Porting Gold to *BSD should be relatively easy, but no one appears to have both the skill and the motivation to do so. David From brooks at freebsd.org Mon Jan 19 14:00:05 2009 From: brooks at freebsd.org (Brooks Davis) Date: Mon, 19 Jan 2009 14:00:05 -0600 Subject: [cfe-dev] too slow to build clang In-Reply-To: <39715C32-97CE-46A9-BA30-60736259C37C@swan.ac.uk> References: <994042.68889.qm@web15708.mail.cnb.yahoo.com> <62CEDDBB-DE99-4BD9-9464-1C4D63E4CC3D@latencyzero.com> <9AE2878C-7412-41FE-9808-51457035923B@apple.com> <39715C32-97CE-46A9-BA30-60736259C37C@swan.ac.uk> Message-ID: <20090119200005.GE16785@lor.one-eyed-alien.net> On Mon, Jan 19, 2009 at 07:47:25PM +0000, David Chisnall wrote: > On 19 Jan 2009, at 19:40, Rick Mann wrote: > > > > > On Jan 19, 2009, at 10:50:16, Eric Christopher wrote: > > > >> Only on linux at this point. > > > > > > In more seriousness, what would it take to run gold on Mac OS X? > > Major and invasive changes to the OS X loader. Gold is fast because > it only supports one binary format, ELF, while the older GNU ld > supports a.out, ELF and COFF. OS X uses Mach-O, and is not supported > by either. > > I don't know how Gold compares in terms of performance to the NeXT / > Apple linker, but I'd be surprised if there was a big difference in > performance since the Apple linker hasn't inherited the same level of > cruft as the GNU linker from having multiple binary formats added over > time. > > Porting Gold to *BSD should be relatively easy, but no one appears to > have both the skill and the motivation to do so. If Google hadn't signed to copyright over to the FSF and/or had released to code under a BSDL or similar license, there would probably be quite a bit of interest. At things stand, the BSD projects are trying to delay or avoid entirely the day when they have to use a GPLv3 licensed binutils. Yet another elf linker is probably more likely. :( -- Brooks -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090119/6c00d534/attachment-0001.bin From rmann at latencyzero.com Mon Jan 19 14:09:06 2009 From: rmann at latencyzero.com (Rick Mann) Date: Mon, 19 Jan 2009 12:09:06 -0800 Subject: [cfe-dev] too slow to build clang In-Reply-To: <39715C32-97CE-46A9-BA30-60736259C37C@swan.ac.uk> References: <994042.68889.qm@web15708.mail.cnb.yahoo.com> <62CEDDBB-DE99-4BD9-9464-1C4D63E4CC3D@latencyzero.com> <9AE2878C-7412-41FE-9808-51457035923B@apple.com> <39715C32-97CE-46A9-BA30-60736259C37C@swan.ac.uk> Message-ID: On Jan 19, 2009, at 11:47:25, David Chisnall wrote: > On 19 Jan 2009, at 19:40, Rick Mann wrote: > >> >> On Jan 19, 2009, at 10:50:16, Eric Christopher wrote: >> >>> Only on linux at this point. >> >> >> In more seriousness, what would it take to run gold on Mac OS X? > > Major and invasive changes to the OS X loader. Gold is fast because > it only supports one binary format, ELF, while the older GNU ld > supports a.out, ELF and COFF. OS X uses Mach-O, and is not > supported by either. > > I don't know how Gold compares in terms of performance to the NeXT / > Apple linker, but I'd be surprised if there was a big difference in > performance since the Apple linker hasn't inherited the same level > of cruft as the GNU linker from having multiple binary formats added > over time. > > Porting Gold to *BSD should be relatively easy, but no one appears > to have both the skill and the motivation to do so. Ah. I was sort-of assuming part of the bottleneck (on OS X) was gnu ld. I didn't really realize that Mac OS X had its own linker. At my day job, I suffer through horrible long gnu ld stages, so it's on my mind. -- Rick From rmann at latencyzero.com Mon Jan 19 14:10:14 2009 From: rmann at latencyzero.com (Rick Mann) Date: Mon, 19 Jan 2009 12:10:14 -0800 Subject: [cfe-dev] too slow to build clang In-Reply-To: <20090119200005.GE16785@lor.one-eyed-alien.net> References: <994042.68889.qm@web15708.mail.cnb.yahoo.com> <62CEDDBB-DE99-4BD9-9464-1C4D63E4CC3D@latencyzero.com> <9AE2878C-7412-41FE-9808-51457035923B@apple.com> <39715C32-97CE-46A9-BA30-60736259C37C@swan.ac.uk> <20090119200005.GE16785@lor.one-eyed-alien.net> Message-ID: <678572CA-1E27-415D-B273-630CC86FAFA5@latencyzero.com> On Jan 19, 2009, at 12:00:05, Brooks Davis wrote: > If Google hadn't signed to copyright over to the FSF and/or had > released > to code under a BSDL or similar license, there would probably be quite > a bit of interest. At things stand, the BSD projects are trying to > delay or avoid entirely the day when they have to use a GPLv3 licensed > binutils. Yet another elf linker is probably more likely. :( That's interesting to note. What a pity. -- Rick From clattner at apple.com Mon Jan 19 14:57:38 2009 From: clattner at apple.com (Chris Lattner) Date: Mon, 19 Jan 2009 12:57:38 -0800 Subject: [cfe-dev] too slow to build clang In-Reply-To: <39715C32-97CE-46A9-BA30-60736259C37C@swan.ac.uk> References: <994042.68889.qm@web15708.mail.cnb.yahoo.com> <62CEDDBB-DE99-4BD9-9464-1C4D63E4CC3D@latencyzero.com> <9AE2878C-7412-41FE-9808-51457035923B@apple.com> <39715C32-97CE-46A9-BA30-60736259C37C@swan.ac.uk> Message-ID: <2B683FB2-0751-490B-8C86-8AD0EBE97292@apple.com> On Jan 19, 2009, at 11:47 AM, David Chisnall wrote: > Porting Gold to *BSD should be relatively easy, but no one appears to > have both the skill and the motivation to do so. The apple linker was completely rewritten for the 10.5 tools release, if you find a case where it is slow, please email me off-list. -Chris From sebastian.redl at getdesigned.at Mon Jan 19 15:13:28 2009 From: sebastian.redl at getdesigned.at (Sebastian Redl) Date: Mon, 19 Jan 2009 22:13:28 +0100 Subject: [cfe-dev] too slow to build clang In-Reply-To: References: <994042.68889.qm@web15708.mail.cnb.yahoo.com> Message-ID: <4974ECF8.6040707@getdesigned.at> Douglas Gregor wrote: > > Clang and LLVM are relatively large, so it does take some time to > compile them. The biggest issue is often memory: does your VMware > virtual machine have at least 1 GB memory? > And more! My computer has 1GB of memory, and the linker always started swapping like crazy - took about 5-6 minutes to link Clang. I upgraded to 3GB, and now it takes 30 seconds. Sebastian From clattner at apple.com Mon Jan 19 15:23:32 2009 From: clattner at apple.com (Chris Lattner) Date: Mon, 19 Jan 2009 13:23:32 -0800 Subject: [cfe-dev] too slow to build clang In-Reply-To: <4974ECF8.6040707@getdesigned.at> References: <994042.68889.qm@web15708.mail.cnb.yahoo.com> <4974ECF8.6040707@getdesigned.at> Message-ID: On Jan 19, 2009, at 1:13 PM, Sebastian Redl wrote: > Douglas Gregor wrote: >> >> Clang and LLVM are relatively large, so it does take some time to >> compile them. The biggest issue is often memory: does your VMware >> virtual machine have at least 1 GB memory? >> > And more! My computer has 1GB of memory, and the linker always started > swapping like crazy - took about 5-6 minutes to link Clang. I upgraded > to 3GB, and now it takes 30 seconds. Note that certain versions of binutils (e.g. 2.17) are particularly bad. See http://llvm.org/docs/GettingStarted.html#brokengcc for a list. It might be worthwhile to try upgrading if you're using binutils and it is really slow. -Chirs From mrs at apple.com Mon Jan 19 15:25:37 2009 From: mrs at apple.com (Mike Stump) Date: Mon, 19 Jan 2009 13:25:37 -0800 Subject: [cfe-dev] Fixing selector types on the GNU runtime In-Reply-To: References: <8518A0F5-8613-4E87-8AE7-264F547617F3@swan.ac.uk> <21970411-3554-4EBE-BB30-A9F6B125029B@apple.com> Message-ID: <0B5D785F-C43E-49B2-BA95-58DBCAD0CEDF@apple.com> On Jan 18, 2009, at 3:01 PM, David Chisnall wrote: > NULL is #defined as 0 for C++ on FreeBSD. This is wrong. If you're using a recent g++ based compiler, NULL should be __null in g++. :-) > I get missing sentinels in a huge numbers of missing sentinel errors > when > building LLVM. And do they go away if you have NULL defined correctly? From clattner at apple.com Mon Jan 19 15:29:38 2009 From: clattner at apple.com (Chris Lattner) Date: Mon, 19 Jan 2009 13:29:38 -0800 Subject: [cfe-dev] Fixing selector types on the GNU runtime In-Reply-To: <0B5D785F-C43E-49B2-BA95-58DBCAD0CEDF@apple.com> References: <8518A0F5-8613-4E87-8AE7-264F547617F3@swan.ac.uk> <21970411-3554-4EBE-BB30-A9F6B125029B@apple.com> <0B5D785F-C43E-49B2-BA95-58DBCAD0CEDF@apple.com> Message-ID: On Jan 19, 2009, at 1:25 PM, Mike Stump wrote: > On Jan 18, 2009, at 3:01 PM, David Chisnall wrote: >> NULL is #defined as 0 for C++ on FreeBSD. > > This is wrong. If you're using a recent g++ based compiler, NULL > should be __null in g++. :-) > >> I get missing sentinels in a huge numbers of missing sentinel errors >> when >> building LLVM. > > And do they go away if you have NULL defined correctly? I agree with Mike here. FreeBSD should be using __null or 0L. I don't think we should switch CGObjCGNU to using a different idiom than the rest of the code base, and I don't want to change the entire LLVM world to avoid NULL in varargs. If FreeBSD headers are broken and they are unwilling to fix it, we can probably do a hack for FreeBSD in the makefiles. -Chris From rdivacky at freebsd.org Mon Jan 19 15:31:08 2009 From: rdivacky at freebsd.org (Roman Divacky) Date: Mon, 19 Jan 2009 22:31:08 +0100 Subject: [cfe-dev] Fixing selector types on the GNU runtime In-Reply-To: References: <8518A0F5-8613-4E87-8AE7-264F547617F3@swan.ac.uk> <21970411-3554-4EBE-BB30-A9F6B125029B@apple.com> <0B5D785F-C43E-49B2-BA95-58DBCAD0CEDF@apple.com> Message-ID: <20090119213108.GA27527@freebsd.org> On Mon, Jan 19, 2009 at 01:29:38PM -0800, Chris Lattner wrote: > > On Jan 19, 2009, at 1:25 PM, Mike Stump wrote: > > > On Jan 18, 2009, at 3:01 PM, David Chisnall wrote: > >> NULL is #defined as 0 for C++ on FreeBSD. > > > > This is wrong. If you're using a recent g++ based compiler, NULL > > should be __null in g++. :-) > > > >> I get missing sentinels in a huge numbers of missing sentinel errors > >> when > >> building LLVM. > > > > And do they go away if you have NULL defined correctly? > > I agree with Mike here. FreeBSD should be using __null or 0L. I > don't think we should switch CGObjCGNU to using a different idiom than > the rest of the code base, and I don't want to change the entire LLVM > world to avoid NULL in varargs. > > If FreeBSD headers are broken and they are unwilling to fix it, we can > probably do a hack for FreeBSD in the makefiles. I'll try to do something to fix it... thnx for noticing the bug From clattner at apple.com Mon Jan 19 15:32:54 2009 From: clattner at apple.com (Chris Lattner) Date: Mon, 19 Jan 2009 13:32:54 -0800 Subject: [cfe-dev] Parsing, pretty-printing, and compiling the result should work, right? In-Reply-To: <497434BE.6050504@cs.unipr.it> References: <49739BA4.80907@cs.unipr.it> <497434BE.6050504@cs.unipr.it> Message-ID: On Jan 19, 2009, at 12:07 AM, Roberto Bagnara wrote: >> For example, mine is >> "make clang a production quality C compiler sooner rather than >> later". > > Good. But since you cannot compile what you cannot parse, our agendas > have a significant overlap: actually, mine is a strict subset of > yours. > This was actually my argument when I convinced my group to use clang > ("they certainly will want to correctly parse all the code out > there"). Yep we do. However, while I'd love to see designated initializers happen sooner rather than later (and I'm thrilled that they may be happening soon!) I'd personally prioritize basic x86-64 codegen above designators. >> 4) find a way to work around the problem. > > We will do that for all the remaining problems. This is actually a > tough decision for me: if 2749 and 3261 are not fixed in a reasonable > time frame we will have to drop clang and I will have wasted the > time of several people. Hopefully they will get fixed then! -Chris From sebastian.redl at getdesigned.at Mon Jan 19 16:05:19 2009 From: sebastian.redl at getdesigned.at (Sebastian Redl) Date: Mon, 19 Jan 2009 23:05:19 +0100 Subject: [cfe-dev] Fixing selector types on the GNU runtime In-Reply-To: References: <8518A0F5-8613-4E87-8AE7-264F547617F3@swan.ac.uk> <21970411-3554-4EBE-BB30-A9F6B125029B@apple.com> <0B5D785F-C43E-49B2-BA95-58DBCAD0CEDF@apple.com> Message-ID: <4974F91F.60602@getdesigned.at> Chris Lattner wrote: > I agree with Mike here. FreeBSD should be using __null or 0L. I > don't think we should switch CGObjCGNU to using a different idiom than > the rest of the code base, and I don't want to change the entire LLVM > world to avoid NULL in varargs. > > If FreeBSD headers are broken and they are unwilling to fix it, we can > probably do a hack for FreeBSD in the makefiles. > > You'll have to do that for Win64 anyway. From what I can see in VC++ 2008 Express, it defines NULL as 0, period. Do we have anyone testing Win64? Sebastian From kremenek at apple.com Mon Jan 19 19:29:12 2009 From: kremenek at apple.com (Ted Kremenek) Date: Mon, 19 Jan 2009 17:29:12 -0800 Subject: [cfe-dev] Static analysis tool development In-Reply-To: <12107ADF-6753-4870-B8A6-E6B49212885D@cs.rpi.edu> References: <87373C76-C757-4921-9497-BA05F4CE977B@apple.com> <12107ADF-6753-4870-B8A6-E6B49212885D@cs.rpi.edu> Message-ID: On Jan 16, 2009, at 8:31 PM, Ryan Govostes wrote: >> As an interesting side note, the developers of Adium (http://www.adiumx.com >> ) have actually been regularly scanning their sources using Clang's >> static analyzer. As part of their process, they wrote some scripts >> that inspect the emitted diagnostics (in this case HTML files) and >> did some munging to determine if the a report emitted on a given >> scan was the same as in a prior scan. Their goal is to avoid re- >> inspecting previously diagnosed bugs and false positives. Having a >> general mechanism in the analyzer library would be quite useful, >> and would be a good first order project for anyone who is >> interested in getting involved. >> > > I thought I'd chime in here; I wrote the scripts we currently use in > Adium for this purpose. Sources (which do not work with the latest > version of Clang, to my knowledge) are at:http://trac.adiumx.com/browser/trunk/Utilities/Analyzer > > In response to the above paragraphs of Ted's e-mail, I thought I'd > announce here that I've been working on a Trac plugin for viewing > Clang reports. Recent versions of the analyzer will output to plist > files, or HTML files, but not both (though this would presumably be > a trivial change). The Trac plugin parses plist files to generate a > file view, which is annotated with the appropriate diagnostics. That's awesome! > Using a dynamic view (i.e., the one generated by Trac) to view the > reports has some benefits over the static files. For one, we can > strip parts of the code that are irrelevant to the report, instead > showing only a few context lines above and below each diagnostic. > Another thing we can do is add links to other pages, such as a > report generated on a previous revision of the file. I honestly would like to go to a completely dynamic view model. This was the reason for introducing 'scan-view' to view error reports so that we could eventually move to this model completely. The idea would be (more or less) to generate all error reports as plist files and then use clang on the side to generate syntax-highlighted HTML. This would be far more scalable; it would take less disk space (syntax- highlighted HTML files can get big) and it allows a diversity of rendering of the reports. Of course we still want to support the model where we can get self-contained report files that users can attach to emails, etc., but a dynamic tracking system inherently allows us to do more things: track false positives and bugs across runs, measure interesting statistics, etc. I personally think a Trac plugin is a great idea. I would like to see some general infrastructure for building different dynamic interfaces (e.g., the Trac plugin, scan-view) to facilitate the construction of different interfaces that tailor to different tastes/workflows/ development processes. > More importantly, however, is the possibility to automatically file > tickets based on new bugs. The system can track a single bug > longitudinally across several commits, using simple heuristics to > decide when a report has been resolved, or merely changed. (This > would integrate well with a system like Buildbot for performing scan > builds and uploading new plists.) > > Is there any interest in a plugin like this? I'd be glad to share it > on a repository if anyone would like to help flesh out the idea. I personally wouldn't have much time to work on a Trac plugin, but I would love to see open development on this feature. We can also link to it from the Clang web page. Per my earlier statement, I would like to see some of the logic for tracking issues across runs put into a common library that could be used by multiple interfaces. Some of this logic could be specific to a particular interface (e.g., Trac) while the rest of it would be more generic and reusable. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090119/f090cc31/attachment.html From kremenek at apple.com Mon Jan 19 19:34:27 2009 From: kremenek at apple.com (Ted Kremenek) Date: Mon, 19 Jan 2009 17:34:27 -0800 Subject: [cfe-dev] Static analysis tool development In-Reply-To: <73e8e3430901170653hc1efd1odc11f8496ed7cb64@mail.gmail.com> References: <73e8e3430901160846v734a65ch28dae1f04ecb7d2e@mail.gmail.com> <87373C76-C757-4921-9497-BA05F4CE977B@apple.com> <73e8e3430901170653hc1efd1odc11f8496ed7cb64@mail.gmail.com> Message-ID: <5133982E-6008-4E36-A209-42E07CC3F6DF@apple.com> On Jan 17, 2009, at 6:53 AM, Monty Zukowski wrote: > I'm glad to hear all the details of your analyzer. I'll have more > questions later, I'm sure, but for now this is what interests me most: > >> Another high-level goal of the analyzer is to support the relaying >> of rich >> diagnostics to end-users about how a bug manifests in their >> program. The >> diagnostic reporting mechanism in the analyzer also uses a set of >> abstract >> interfaces so that bug reports can be rendered in a variety of ways >> (e.g., >> to the console, to an HTML page, within an IDE, etc.). Providing >> rich >> diagnostics is an important goal because without them the results >> of a >> static analysis algorithm is only useful to graduate students >> studying >> program analysis techniques rather than programmers who want to fix >> bugs. > > As you mentioned later, issue tracking is very important and the > analyzer can be designed to help with that. It seems to me that that > could be the best use of Google's money to get this tool into its most > useful state. I think having good issue tracking and improving the general infrastructure for the analyzer would expand its usefulness to more users. Improving the UI and workflow would greatly improve its usability to more developers. Among other issues that I didn't mention was a better way of "intercepting the build" so that the analyzer scans every file that the compiler does (and with the same flags, include paths, etc.). Currently 'scan-build' just overrides CC to be a "fake compiler" that forwards its arguments onto gcc and clang. This solution doesn't work in many cases and could be greatly improved. > I can see you've put a lot of thought into the other > analysis which can be added to the tool later. I'm not an expert in > that area so I'll probably leave that area untouched. > > In any event, you've described a tool which seems to have been > designed to be both extensible and useful and for that I'm very > excited. It seems like such an obvious need, doesn't it? I certainly think so. ;-) From kremenek at apple.com Mon Jan 19 19:39:13 2009 From: kremenek at apple.com (Ted Kremenek) Date: Mon, 19 Jan 2009 17:39:13 -0800 Subject: [cfe-dev] Static analysis tool development In-Reply-To: <1b587cab0901170702m104d99ach2e8049d74ef335b0@mail.gmail.com> References: <73e8e3430901160846v734a65ch28dae1f04ecb7d2e@mail.gmail.com> <87373C76-C757-4921-9497-BA05F4CE977B@apple.com> <73e8e3430901170653hc1efd1odc11f8496ed7cb64@mail.gmail.com> <1b587cab0901170702m104d99ach2e8049d74ef335b0@mail.gmail.com> Message-ID: On Jan 17, 2009, at 7:02 AM, Ben Laurie wrote: > On Sat, Jan 17, 2009 at 2:53 PM, Monty Zukowski > wrote: >> I'm glad to hear all the details of your analyzer. I'll have more >> questions later, I'm sure, but for now this is what interests me >> most: >> >>> Another high-level goal of the analyzer is to support the relaying >>> of rich >>> diagnostics to end-users about how a bug manifests in their >>> program. The >>> diagnostic reporting mechanism in the analyzer also uses a set of >>> abstract >>> interfaces so that bug reports can be rendered in a variety of >>> ways (e.g., >>> to the console, to an HTML page, within an IDE, etc.). Providing >>> rich >>> diagnostics is an important goal because without them the results >>> of a >>> static analysis algorithm is only useful to graduate students >>> studying >>> program analysis techniques rather than programmers who want to >>> fix bugs. >> >> As you mentioned later, issue tracking is very important and the >> analyzer can be designed to help with that. > > I do wonder if suppression of false positives is better done by > annotation than by tracking... > > a) The annotation can be reused by other analysers. > > b) The annotation works for developers who start from scratch. I personally like annotations. They represent "actionable documentation" that can be leveraged by multiple tools. That said, in my own conversations with different developers I have seen cases where annotations directly in the source code are completely taboo. Probably the best example is source code that is under a tight "change control" process where only critical changes can be made to the source code. Being able to "annotate" code, be it for issue tracking or enhancing a tool's knowledge of the code, without actually *modifying* the code is really useful in such circumstances. This allows code to be actively scanned and "annotated" without source modifications. Alternatively, one may wish to back-scan previous versions of a code base to determine when certain issues appeared. Earlier versions of a code base wouldn't certainly lack any annotations embedded in the code itself. That said, source-level annotations are the easiest to support (from an engineering perspective) and probably most accurate form of documentation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090119/8dd58888/attachment-0001.html From kremenek at apple.com Mon Jan 19 19:40:48 2009 From: kremenek at apple.com (Ted Kremenek) Date: Mon, 19 Jan 2009 17:40:48 -0800 Subject: [cfe-dev] Static analysis tool development In-Reply-To: <7DC96595-C064-4368-AE67-2494E4844C85@zhuk.fi> References: <73e8e3430901160846v734a65ch28dae1f04ecb7d2e@mail.gmail.com> <87373C76-C757-4921-9497-BA05F4CE977B@apple.com> <7DC96595-C064-4368-AE67-2494E4844C85@zhuk.fi> Message-ID: On Jan 17, 2009, at 7:05 AM, Nikita Zhuk wrote: > > On 17.1.2009, at 1.42, Ted Kremenek wrote: > >> [3] The analyzer can be extended with new sets of "checks" by not >> invasively modifying the analyzer internals. Such extensibility can >> be provided with different layers of abstraction from the core >> analyzer API, with very high-level checks possibly being written in >> a very high-level manner (e.g., declarative) while some checks >> requiring more direct access to the core analyzer APIs. Both ends >> of the spectrum are important because some checks will require >> sophisticated algorithms with deep reasoning about the program while >> others might be much simpler and just clue off of common interfaces >> and APIs. > > I thought I could comment on that a little. As Ted said, it's possible > to extend analyzer with new sets of checks without large > modifications. At our company we have combined this possiblity with > manual code reviews - when a bug is found during a code review, we try > to implement a static analyzer check which would a) automatically > check rest of the code for the same problem and b) prevent this > problem in the future. I have been able to implement some basic checks > without extensive compiler or C++ background fairly easily into clang > itself by using the AnalysisManager API. The results have been very > positive. > > If/when clang static analyzer will allow easy extensibility as Ted > described in option [3], it would be very interesting to see if clang > user community could come up with some collaborative way of sharing > various custom checks as pluggable & configurable components. > A wiki, > perhaps? I think that sharing programming experience and knowledge as > clang analyzer checks for common programming errors and best practices > would be useful for open source community. This would be really useful, especially for people wishing to write both custom checks for their own APIs/software or wishing to contribute back to the general community. From kremenek at apple.com Mon Jan 19 19:45:08 2009 From: kremenek at apple.com (Ted Kremenek) Date: Mon, 19 Jan 2009 17:45:08 -0800 Subject: [cfe-dev] Static analysis tool development In-Reply-To: References: <73e8e3430901160846v734a65ch28dae1f04ecb7d2e@mail.gmail.com> <87373C76-C757-4921-9497-BA05F4CE977B@apple.com> <7DC96595-C064-4368-AE67-2494E4844C85@zhuk.fi> <1b587cab0901170712v7e2c1d47k584f7486d4151f8e@mail.gmail.com> Message-ID: On Jan 17, 2009, at 8:58 AM, Nikita Zhuk wrote: >>> If/when clang static analyzer will allow easy extensibility as Ted >>> described in option [3], it would be very interesting to see if >>> clang >>> user community could come up with some collaborative way of sharing >>> various custom checks as pluggable & configurable components. A >>> wiki, >>> perhaps? I think that sharing programming experience and knowledge >>> as >>> clang analyzer checks for common programming errors and best >>> practices >>> would be useful for open source community. >> >> What would be wrong with just integrating them into the source and >> having them invdividually enableable? > > There's nothing wrong with integrating additional checks into clang, > of course. However, as a Mac developer and clang user I would like to > be able to download and install additional checks simply by dropping > the downloaded binary into some directory, without recompiling clang > each time I'd like to try a new check which some other developer has > written. I also suspect that some checks could exist which aren't > completely in line with clang's goals, e.g. which generate too many > false positives for average project, but which would be beneficial in > projects of a specific type. For example, I have written some specific > coding convention checks which have way too high level of false > positives for being included into the official clang, but which are > useful for developers who follow the same conventions. I agree with Nikita. Theoretically one could write a set of checks for every API that is out there. Not everyone cares about all checks, and since many important APIs are private (or just not relevant outside the scope of a given piece of software) it makes sense to provide an extensible system where people can define their own checks without worrying about directly incorporating it into the analyzer binary. Further, a plug-in model enforces modularity in the static analyzer's logic that I think is very beneficial to its overall quality of implementation, extensibility and reusability. From dgregor at apple.com Tue Jan 20 10:11:17 2009 From: dgregor at apple.com (Douglas Gregor) Date: Tue, 20 Jan 2009 08:11:17 -0800 Subject: [cfe-dev] [Patch] IDNS_NoLookup? In-Reply-To: References: <7925cd330901141217j6aa49672p4917d76b01e3fabc@mail.gmail.com> Message-ID: On Jan 18, 2009, at 8:00 PM, Douglas Gregor wrote: > On Jan 18, 2009, at 5:58 PM, Chris Lattner wrote: > >> On Jan 18, 2009, at 5:02 PM, Douglas Gregor wrote: >>> Ah, so that's the issue... the ObjCImplementationDecls need to have >>> an >>> identifier namespace, because they have name, but they aren't >>> supposed to be found by name lookup (rather, we see them through the >>> ObjCInterfaceDecl). >> >> Ah, very interesting. I think the right fix is that >> ObjCImplementationDecl should not be scope decls and maybe not even >> NamedDecls. They should never ever be "looked up". > > I think we should swap ScopedDecl and NamedDecl in the inheritance > hierarchy. Things without names---like, perhaps, > ObjCImplementationDecl---should still be ScopedDecls and live inside > DeclContexts (so we know where they occur, lexically, in the program, > and who their owners are) but they don't need any storage for names. For everyone who doesn't watch commits: we've gone slightly further this with, removing ScopedDecl entirely and collapsing its fields into Decl so that *every* declaration lives within a DeclContext. That way, traversing through the various DeclContexts in a program will (eventually) visit every declaration in the program. Many *Decl nodes inherit from NamedDecl, meaning that they can have a name and therefore can be found by name lookup. To address the problem that Piotr found, we've taken some *Decl nodes that used to be NamedDecls (ObjCImplementationDecl and LinkageSpecDecl, for example) and made them inherit directly from Decl so that they don't ever have names and can't ever be inserted for name lookup to find. - Doug From dgregor at apple.com Tue Jan 20 11:46:06 2009 From: dgregor at apple.com (Douglas Gregor) Date: Tue, 20 Jan 2009 09:46:06 -0800 Subject: [cfe-dev] Notes on Doxygen documentation style Message-ID: <55D39A9B-235A-42E0-A0FF-7926AF72A911@apple.com> I'm a documentation nut, and there are some places in Clang's internal documentation that I think we can do even better. Here are some comments on the subject. Coverage ======== Naturally, every data type and non-private function should be documented. Most important for clients of Clang are the AST nodes: we should strive to have good documentation for each Expr, Stmt, and Decl node, including code examples illustrating where these kinds of declarations will show up in the source code. I don't have any concerns about this in particular: we have decent documentation coverage, and we'll keep improving it as we go. Style ==== In my view, good documentation always includes a brief one-sentence description (so the reader can answer the question "does this look like what I want?") followed by an in-depth description of the routine's behavior and its parameters and (often) language-standard citations and examples. Our current style of documentation doesn't fit this quite so well; picking one example of many, Action::isTypeName is documented like this: /// isTypeName - Return non-null if the specified identifier is a type name /// in the current scope. /// An optional CXXScopeSpec can be passed to indicate the C++ scope (class or /// namespace) that the identifier must be a member of. /// i.e. for "foo::bar", 'II' will be "bar" and 'SS' will be "foo::". virtual TypeTy *isTypeName(IdentifierInfo &II, Scope *S, const CXXScopeSpec *SS = 0) = 0; That says what we need, but it doesn't format well with Doxygen: http://clang.llvm.org/doxygen/classclang_1_1Sema.html#6dc9964792711aab89e41067aca3581c Also, scroll down to isTypeName within Sema's documentation: http://clang.llvm.org/doxygen/classclang_1_1Sema.html Then, scroll down a little further to "LookupName". This is how I, personally, would like to see documentation for a function. First of all, we've used Doxygen to give a one-sentence description of what LookupName does, and it shows up under the declaration of LookupName: that's great for finding what operation we need, quickly. Clicking on LookupName, we get the lengthier description with an example, specific information about the parameters, language citations, etc. It takes some extra Doxygen markup to do this, but in my opinion it's absolutely worth it. Here's how LookupName is written: /// @brief Perform unqualified name lookup starting from a given /// scope. /// /// Unqualified name lookup (C++ [basic.lookup.unqual], C99 6.2.1) is /// used to find names within the current scope. For example, 'x' in /// @code /// int x; /// int f() { /// return x; // unqualified name look finds 'x' in the global scope /// } /// @endcode /// /// Different lookup criteria can find different names. For example, a /// particular scope can have both a struct and a function of the same /// name, and each can be found by certain lookup criteria. For more /// information about lookup criteria, see the documentation for the /// class LookupCriteria. /// /// @param S The scope from which unqualified name lookup will /// begin. If the lookup criteria permits, name lookup may also search /// in the parent scopes. /// /// @param Name The name of the entity that we are searching for. /// /// @param Criteria The criteria that this routine will use to /// determine which names are visible and which names will be /// found. Note that name lookup will find a name that is visible by /// the given criteria, but the entity itself may not be semantically /// correct or even the kind of entity expected based on the /// lookup. For example, searching for a nested-name-specifier name /// might result in an EnumDecl, which is visible but is not permitted /// as a nested-name-specifier in C++03. /// /// @returns The result of name lookup, which includes zero or more /// declarations and possibly additional information used to diagnose /// ambiguities. Sema::LookupResult Sema::LookupName(Scope *S, DeclarationName Name, LookupCriteria Criteria) { The important bits are @brief (for the one-sentence description), @param (for parameter documentation) and @code/@endcode (for examples). Grouping ======= Sema::LookupName was also an experiment with grouping routines together. The Sema class is large, but we can give it structure using Doxygen's //@{ and //@} grouping constructs. If you look back at http://clang.llvm.org/doxygen/classclang_1_1Sema.html and search for "Name lookup", you'll come across a grouping of the various name-lookup routines. I really like this style: it logically groups related pieces of the (large!) Sema class, and puts them all in context together. It also gives some guidance for someone who knows they need name lookup but doesn't necessarily know what kind. Groups are easy to make. The heading of the group should use @name or \name, then provide documentation for the group as a whole: /// \name Name lookup /// /// These routines provide name lookup that is used during semantic /// analysis to resolve the various kinds of names (identifiers, and so on Then, //@{ starts grouping all of the methods, classes, etc., that will be documented together. Terminate the group with //@} Not all of the groups will be obvious, but there are some sets of routines that really need it, such as C++ function overloading. Architectural Descriptions ==================== We currently have a Clang "internals" manual, with documentation about various subsystems within Clang: http://clang.llvm.org/docs/InternalsManual.html We could consider bringing this documentation in with the rest of the Doxygen documentation using, e.g., Doxygen's \page and \newpage markup. The benefit of bringing all of the internals documentation into Doxygen is that we can more easily cross-link between specific function/class documentation and the more general, architectural information. - Doug From clattner at apple.com Tue Jan 20 16:13:24 2009 From: clattner at apple.com (Chris Lattner) Date: Tue, 20 Jan 2009 14:13:24 -0800 Subject: [cfe-dev] Notes on Doxygen documentation style In-Reply-To: <55D39A9B-235A-42E0-A0FF-7926AF72A911@apple.com> References: <55D39A9B-235A-42E0-A0FF-7926AF72A911@apple.com> Message-ID: <8C0449FA-4C82-448A-84E0-5A6A99994009@apple.com> On Jan 20, 2009, at 9:46 AM, Douglas Gregor wrote: > I'm a documentation nut, and there are some places in Clang's internal > documentation that I think we can do even better. Here are some > comments on the subject. Hey Doug, I agree that this is great to do and makes the doxygen output very nice. There is a tender balance between getting people to document stuff at all and making the documentation truly beautiful, but I agree that very common/popular APIs should be well documented. > Architectural Descriptions > ==================== > > We currently have a Clang "internals" manual, with documentation about > various subsystems within Clang: > > http://clang.llvm.org/docs/InternalsManual.html > > We could consider bringing this documentation in with the rest of the > Doxygen documentation using, e.g., Doxygen's \page and \newpage > markup. The benefit of bringing all of the internals documentation > into Doxygen is that we can more easily cross-link between specific > function/class documentation and the more general, architectural > information. This is one thing that I don't agree with. I think it is fine to link from the internals manual to the doxygen (we do this in other LLVM dox) just using normal links. "Hiding" the documentation in the code makes it harder to find IMO. -Chris From piotr.rak at gmail.com Tue Jan 20 16:43:54 2009 From: piotr.rak at gmail.com (Piotr Rak) Date: Tue, 20 Jan 2009 23:43:54 +0100 Subject: [cfe-dev] Notes on Doxygen documentation style In-Reply-To: <8C0449FA-4C82-448A-84E0-5A6A99994009@apple.com> References: <55D39A9B-235A-42E0-A0FF-7926AF72A911@apple.com> <8C0449FA-4C82-448A-84E0-5A6A99994009@apple.com> Message-ID: <7925cd330901201443i53e0a85bu93461b388694a975@mail.gmail.com> Hi Chris, 2009/1/20 Chris Lattner : > > On Jan 20, 2009, at 9:46 AM, Douglas Gregor wrote: > >> Architectural Descriptions >> ==================== >> >> We currently have a Clang "internals" manual, with documentation about >> various subsystems within Clang: >> >> http://clang.llvm.org/docs/InternalsManual.html >> >> We could consider bringing this documentation in with the rest of the >> Doxygen documentation using, e.g., Doxygen's \page and \newpage >> markup. The benefit of bringing all of the internals documentation >> into Doxygen is that we can more easily cross-link between specific >> function/class documentation and the more general, architectural >> information. > > This is one thing that I don't agree with. I think it is fine to link > from the internals manual to the doxygen (we do this in other LLVM > dox) just using normal links. "Hiding" the documentation in the code > makes it harder to find IMO. This is ok, as long url mangling doesn't change between Doxygen versions. I am not sure, if it is case or not. How about, putting internals manual in some lets say *.doc files, inline html there, and adjust Doxygen's config to include those files? Piotr > -Chris > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > From dgregor at apple.com Tue Jan 20 16:48:03 2009 From: dgregor at apple.com (Douglas Gregor) Date: Tue, 20 Jan 2009 14:48:03 -0800 Subject: [cfe-dev] Notes on Doxygen documentation style In-Reply-To: <8C0449FA-4C82-448A-84E0-5A6A99994009@apple.com> References: <55D39A9B-235A-42E0-A0FF-7926AF72A911@apple.com> <8C0449FA-4C82-448A-84E0-5A6A99994009@apple.com> Message-ID: On Jan 20, 2009, at 2:13 PM, Chris Lattner wrote: > On Jan 20, 2009, at 9:46 AM, Douglas Gregor wrote: >> Architectural Descriptions >> ==================== >> >> We currently have a Clang "internals" manual, with documentation >> about >> various subsystems within Clang: >> >> http://clang.llvm.org/docs/InternalsManual.html >> >> We could consider bringing this documentation in with the rest of the >> Doxygen documentation using, e.g., Doxygen's \page and \newpage >> markup. The benefit of bringing all of the internals documentation >> into Doxygen is that we can more easily cross-link between specific >> function/class documentation and the more general, architectural >> information. > > This is one thing that I don't agree with. I think it is fine to > link from the internals manual to the doxygen (we do this in other > LLVM dox) just using normal links. "Hiding" the documentation in > the code makes it harder to find IMO. Yep, that's a reasonable concern. Let's not do this, then. - Doug From daniel at zuster.org Tue Jan 20 17:21:15 2009 From: daniel at zuster.org (Daniel Dunbar) Date: Tue, 20 Jan 2009 15:21:15 -0800 Subject: [cfe-dev] clang driver command line interface change Message-ID: <6a8523d60901201521l7db60dd4kdfe0f222dfa02579@mail.gmail.com> Hi all, For those using the as-yet-unnamed clang static analyzer, I have change the command line interface so that it requires an explicit -analyze option. I updated the test cases but those using clang directly will need to pass '-analyze' (just as one would pass -fsyntax-only, -emit-llvm, etc.) to set the program action. The motivation & goal is to have clang take "explicit" arguments instead of inferring what to do; this is consistent with the idea that the clang executable is a backend tool and will almost always be being driven by some other tool. - Daniel From csdavec at swansea.ac.uk Tue Jan 20 18:51:46 2009 From: csdavec at swansea.ac.uk (David Chisnall) Date: Wed, 21 Jan 2009 00:51:46 +0000 Subject: [cfe-dev] Fixing selector types on the GNU runtime In-Reply-To: References: <8518A0F5-8613-4E87-8AE7-264F547617F3@swan.ac.uk> <21970411-3554-4EBE-BB30-A9F6B125029B@apple.com> <0B5D785F-C43E-49B2-BA95-58DBCAD0CEDF@apple.com> Message-ID: <42B356CD-9EFA-429F-A33A-3E6F3A11E18C@swan.ac.uk> On 19 Jan 2009, at 21:29, Chris Lattner wrote: > > On Jan 19, 2009, at 1:25 PM, Mike Stump wrote: > >> On Jan 18, 2009, at 3:01 PM, David Chisnall wrote: >>> NULL is #defined as 0 for C++ on FreeBSD. >> >> This is wrong. If you're using a recent g++ based compiler, NULL >> should be __null in g++. :-) >> >>> I get missing sentinels in a huge numbers of missing sentinel errors >>> when >>> building LLVM. >> >> And do they go away if you have NULL defined correctly? > > I agree with Mike here. FreeBSD should be using __null or 0L. I > don't think we should switch CGObjCGNU to using a different idiom > than the rest of the code base, and I don't want to change the > entire LLVM world to avoid NULL in varargs. I can't find a copy of the spec online (and I leant my paper copy to someone a while ago), but every reference I can find says that NULL may be a #define for 0 or 0L. Neither of these is guaranteed to be pointer sized or bigger (although 0L is on most platforms, with Win64 being the most notable exception that springs to mind and caused a lot of breakage for code that assumed sizeof(long) >= sizeof(void*)). As I recall, the rationale for NULL in C++ was compatibility with C code, and its use was discourage in new C++ code. If NULL is #define'd to __null on some platforms, then this is great, but isn't it a GCC extension? I was under the impression that the LLVM coding conventions stated that GCC extensions were to be avoided so that it could be easily portable to compilers. I don't really care whether this part of the diff is committed - the part I am interested in is the part that makes clang able to compile Objective-C code on non-Apple platforms again - but it would be nice to be able to compile both clang and LLVM without myriad warnings. David From kremenek at apple.com Tue Jan 20 19:12:10 2009 From: kremenek at apple.com (Ted Kremenek) Date: Tue, 20 Jan 2009 17:12:10 -0800 Subject: [cfe-dev] clang driver command line interface change In-Reply-To: <6a8523d60901201521l7db60dd4kdfe0f222dfa02579@mail.gmail.com> References: <6a8523d60901201521l7db60dd4kdfe0f222dfa02579@mail.gmail.com> Message-ID: Daniel's email was pretty clear, but just to reiterate this only applies when you use the 'clang' executable directly to run analyses. 'scan-build' and 'ccc-analyzer' will do the right thing by default. On Jan 20, 2009, at 3:21 PM, Daniel Dunbar wrote: > Hi all, > > For those using the as-yet-unnamed clang static analyzer, I have > change the command line interface so that it requires an explicit > -analyze option. I updated the test cases but those using clang > directly will need to pass '-analyze' (just as one would pass > -fsyntax-only, -emit-llvm, etc.) to set the program action. > > The motivation & goal is to have clang take "explicit" arguments > instead of inferring what to do; this is consistent with the idea that > the clang executable is a backend tool and will almost always be being > driven by some other tool. > > - Daniel > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From kremenek at apple.com Tue Jan 20 19:23:46 2009 From: kremenek at apple.com (Ted Kremenek) Date: Tue, 20 Jan 2009 17:23:46 -0800 Subject: [cfe-dev] SelectorTable and IdentifierTable Message-ID: Is there a specific reason why we need both IdentifierTable and SelectorTable? Why not just have IdentifierTable use SelectorTable as an internal data structure, and have all selector creation go through IdentifierTable? It seems to buy us nothing that have two separate concepts from the perspective of clients. From mrs at apple.com Tue Jan 20 19:35:08 2009 From: mrs at apple.com (Mike Stump) Date: Tue, 20 Jan 2009 17:35:08 -0800 Subject: [cfe-dev] Fixing selector types on the GNU runtime In-Reply-To: <42B356CD-9EFA-429F-A33A-3E6F3A11E18C@swan.ac.uk> References: <8518A0F5-8613-4E87-8AE7-264F547617F3@swan.ac.uk> <21970411-3554-4EBE-BB30-A9F6B125029B@apple.com> <0B5D785F-C43E-49B2-BA95-58DBCAD0CEDF@apple.com> <42B356CD-9EFA-429F-A33A-3E6F3A11E18C@swan.ac.uk> Message-ID: On Jan 20, 2009, at 4:51 PM, David Chisnall wrote: > I can't find a copy of the spec online (and I leant my paper copy to > someone a while ago), but every reference I can find says that NULL > may be a #define for 0 or 0L. Fine, but this is irrelevant to the question at hand. The question at hand is an internal implementation detail of a particular compiler, that compiler being g++ on FreeBSD. They apparently goofed. That's a bug in FreeBSD, and it needs to be fixed. Once fixed, there is no issue here. > If NULL is #define'd to __null on some platforms, then this is > great, but isn't it a GCC extension? I'd call it a private internal implementation detail of the compiler. The compiler is implemented such that for proper operation, NULL _must_ be __null. > I was under the impression that the LLVM coding conventions stated > that GCC extensions were to be avoided so that it could be easily > portable to compilers. llvm uses NULL. NULL is not a gcc extension. From csdavec at swansea.ac.uk Tue Jan 20 19:46:57 2009 From: csdavec at swansea.ac.uk (David Chisnall) Date: Wed, 21 Jan 2009 01:46:57 +0000 Subject: [cfe-dev] Fixing selector types on the GNU runtime In-Reply-To: References: <8518A0F5-8613-4E87-8AE7-264F547617F3@swan.ac.uk> <21970411-3554-4EBE-BB30-A9F6B125029B@apple.com> <0B5D785F-C43E-49B2-BA95-58DBCAD0CEDF@apple.com> <42B356CD-9EFA-429F-A33A-3E6F3A11E18C@swan.ac.uk> Message-ID: On 21 Jan 2009, at 01:35, Mike Stump wrote: > On Jan 20, 2009, at 4:51 PM, David Chisnall wrote: >> I can't find a copy of the spec online (and I leant my paper copy >> to someone a while ago), but every reference I can find says that >> NULL may be a #define for 0 or 0L. > > Fine, but this is irrelevant to the question at hand. The question > at hand is an internal implementation detail of a particular > compiler, that compiler being g++ on FreeBSD. They apparently > goofed. That's a bug in FreeBSD, and it needs to be fixed. Once > fixed, there is no issue here. The question at hand is whether, according to the C++ spec, NULL, when passed to a variadic function, will always be a 0 pointer. I can't find a single reference to support this. If you have one, then it's a bug in g++ combined with the FreeBSD headers. If you don't, then it's a fault in LLVM's usage of NULL, which happens not to matter on some platforms. >> If NULL is #define'd to __null on some platforms, then this is >> great, but isn't it a GCC extension? > > I'd call it a private internal implementation detail of the > compiler. The compiler is implemented such that for proper > operation, NULL _must_ be __null. No, the compiler is implemented such that, for NULL to be a pointer when passed as an argument to a variadic function it must be __null. Since the C++ spec appears to allow NULL to be 0 or 0L, for compatibility with C code and the C++ type system, this means that passing NULL as a pointer when it is an argument to variadic functions is either a special case in the spec or a GCC extension. I have never heard of NULL having any special behaviour when passed as an argument to variadic functions (it is a preprocessor macro - the compiler shouldn't need to be aware of it at all after the source is preprocessed). The fact that there is no such behaviour was cited as the main motivation for the introduction of one of the extensions added in C++0x. >> I was under the impression that the LLVM coding conventions stated >> that GCC extensions were to be avoided so that it could be easily >> portable to compilers. > > llvm uses NULL. NULL is not a gcc extension. Totally irrelevant. Once again, the question is whether NULL is guaranteed to be a type which will be passed as a pointer or a pointer- sized integer to variadic functions, not whether NULL is in the standard. David From snaroff at apple.com Tue Jan 20 19:53:29 2009 From: snaroff at apple.com (steve naroff) Date: Tue, 20 Jan 2009 17:53:29 -0800 Subject: [cfe-dev] SelectorTable and IdentifierTable In-Reply-To: References: Message-ID: <999A9354-7E07-4B58-88D7-E072D98B87D3@apple.com> On Jan 20, 2009, at 5:23 PM, Ted Kremenek wrote: > Is there a specific reason why we need both IdentifierTable and > SelectorTable? Why not just have IdentifierTable use SelectorTable as > an internal data structure, and have all selector creation go through > IdentifierTable? It seems to buy us nothing that have two separate > concepts from the perspective of clients. > ______ Hey Ted, What's the benefit of unifying them? (other than removing some API/ code). Having two separate table's that model the C/ObjC namespaces may be better from a lookup perspective (fewer hash collisions). There may be some size reduction I imagine (however I believe it would be quite small). Unless you see a performance win, I'm not sure fiddling with this level of clang is important (for now, at least). My 2$, snaroff > _________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From kremenek at apple.com Tue Jan 20 20:17:02 2009 From: kremenek at apple.com (Ted Kremenek) Date: Tue, 20 Jan 2009 18:17:02 -0800 Subject: [cfe-dev] SelectorTable and IdentifierTable In-Reply-To: <999A9354-7E07-4B58-88D7-E072D98B87D3@apple.com> References: <999A9354-7E07-4B58-88D7-E072D98B87D3@apple.com> Message-ID: <6F3357B7-EF03-4301-A39C-3C90F7E8E9D5@apple.com> On Jan 20, 2009, at 5:53 PM, steve naroff wrote: > > On Jan 20, 2009, at 5:23 PM, Ted Kremenek wrote: > >> Is there a specific reason why we need both IdentifierTable and >> SelectorTable? Why not just have IdentifierTable use SelectorTable >> as >> an internal data structure, and have all selector creation go through >> IdentifierTable? It seems to buy us nothing that have two separate >> concepts from the perspective of clients. >> ______ > > Hey Ted, > > What's the benefit of unifying them? (other than removing some API/ > code). > > Having two separate table's that model the C/ObjC namespaces may be > better from a lookup perspective (fewer hash collisions). There may > be some size reduction I imagine (however I believe it would be > quite small). > > Unless you see a performance win, I'm not sure fiddling with this > level of clang is important (for now, at least). I wasn't thinking of combining their lookup tables. That isn't even possible; one uses a StringMap and the other a FoldingSet. What I was thing was: 1) Make SelectorTable an internal implementation class of IdentifierTable. 2) Have the getSelector() methods be in IdentifierTable. 3) Allocate all MultiKeywordSelector objects using the same BumpPtrAllocator used by IdentifierTable. Currently these objects are being malloc'ed and then always leaked (~SelectorTable doesn't free them). Conceptually both IdentifierTable and SelectorTable reason about identifiers. Why not just have one IdentifierManager? SelectorTable is basically a shim on top of IdentifierTable anyway. Combining the two makes the API a little simpler since clients don't have to create yet another book-keeping object that they must properly dispose. From snaroff at apple.com Tue Jan 20 20:47:21 2009 From: snaroff at apple.com (steve naroff) Date: Tue, 20 Jan 2009 18:47:21 -0800 Subject: [cfe-dev] SelectorTable and IdentifierTable In-Reply-To: <6F3357B7-EF03-4301-A39C-3C90F7E8E9D5@apple.com> References: <999A9354-7E07-4B58-88D7-E072D98B87D3@apple.com> <6F3357B7-EF03-4301-A39C-3C90F7E8E9D5@apple.com> Message-ID: <737F6342-4588-4589-9EB2-7B50EC2ED132@apple.com> On Jan 20, 2009, at 6:17 PM, Ted Kremenek wrote: > On Jan 20, 2009, at 5:53 PM, steve naroff wrote: > >> >> On Jan 20, 2009, at 5:23 PM, Ted Kremenek wrote: >> >>> Is there a specific reason why we need both IdentifierTable and >>> SelectorTable? Why not just have IdentifierTable use >>> SelectorTable as >>> an internal data structure, and have all selector creation go >>> through >>> IdentifierTable? It seems to buy us nothing that have two separate >>> concepts from the perspective of clients. >>> ______ >> >> Hey Ted, >> >> What's the benefit of unifying them? (other than removing some API/ >> code). >> >> Having two separate table's that model the C/ObjC namespaces may be >> better from a lookup perspective (fewer hash collisions). There may >> be some size reduction I imagine (however I believe it would be >> quite small). >> >> Unless you see a performance win, I'm not sure fiddling with this >> level of clang is important (for now, at least). > > I wasn't thinking of combining their lookup tables. That isn't even > possible; one uses a StringMap and the other a FoldingSet. What I > was thing was: > > 1) Make SelectorTable an internal implementation class of > IdentifierTable. > > 2) Have the getSelector() methods be in IdentifierTable. > > 3) Allocate all MultiKeywordSelector objects using the same > BumpPtrAllocator used by IdentifierTable. Currently these objects > are being malloc'ed and then always leaked (~SelectorTable doesn't > free them). > Got it (I thought you were talking about combining the lookup tables). > Conceptually both IdentifierTable and SelectorTable reason about > identifiers. Why not just have one IdentifierManager? Since many selectors contain colons, I don't think of them as identifiers (since C identifiers can't contain colons). > SelectorTable is basically a shim on top of IdentifierTable anyway. > Combining the two makes the API a little simpler since clients don't > have to create yet another book-keeping object that they must > properly dispose. I agree. I think combining them makes sense, I just don't see it as a big win (since not many clients use the SelectorTable API). snaroff From me22.ca at gmail.com Tue Jan 20 20:49:20 2009 From: me22.ca at gmail.com (me22) Date: Tue, 20 Jan 2009 21:49:20 -0500 Subject: [cfe-dev] Fixing selector types on the GNU runtime In-Reply-To: References: <8518A0F5-8613-4E87-8AE7-264F547617F3@swan.ac.uk> <21970411-3554-4EBE-BB30-A9F6B125029B@apple.com> <0B5D785F-C43E-49B2-BA95-58DBCAD0CEDF@apple.com> <42B356CD-9EFA-429F-A33A-3E6F3A11E18C@swan.ac.uk> Message-ID: On Tue, Jan 20, 2009 at 20:46, David Chisnall wrote: > > The question at hand is whether, according to the C++ spec, NULL, when > passed to a variadic function, will always be a 0 pointer. I can't > find a single reference to support this. If you have one, then it's a > bug in g++ combined with the FreeBSD headers. If you don't, then it's > a fault in LLVM's usage of NULL, which happens not to matter on some > platforms. > The only description of NULL that I can find is 18.1/4: "The macro NULL is an implementation-defined C++ null pointer constant in this International Standard (4.10).[footnote: Possible definitions include 0 and 0L, but not (void*)0.]" A "null pointer constant" is, by 4.10, is an integral constant rvalue expression that evaluates to zero. Since variable argument don't trigger any implicit conversions, NULL has no reason to become a pointer. (Especially since, as you mentioned, the NULL macro is expanded in translation phase 4, well before the syntactic and semantic analysis and translation of phase 7.) ~ Scott #define NULL (3/2-1) P.S. If you're looking for a legal electronic copy, consider the 1997 public review version ( http://www.open-std.org/jtc1/sc22/open/n2356/ ) and the april 2004 draft ( http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1638.pdf ), a combination of which should give a good picture of C++2003. From mrs at apple.com Tue Jan 20 21:14:38 2009 From: mrs at apple.com (Mike Stump) Date: Tue, 20 Jan 2009 19:14:38 -0800 Subject: [cfe-dev] Fixing selector types on the GNU runtime In-Reply-To: References: <8518A0F5-8613-4E87-8AE7-264F547617F3@swan.ac.uk> <21970411-3554-4EBE-BB30-A9F6B125029B@apple.com> <0B5D785F-C43E-49B2-BA95-58DBCAD0CEDF@apple.com> <42B356CD-9EFA-429F-A33A-3E6F3A11E18C@swan.ac.uk> Message-ID: On Jan 20, 2009, at 5:46 PM, David Chisnall wrote: > The question at hand is whether, according to the C++ spec, NULL, > when passed to a variadic function, will always be a 0 pointer. Odd, the issue you seemed to have raised was relating to warnings on freebsd, not some theoretic point about NULL. Anyway, technically, no. However, dusty deck code requires this of implementations. The standard arguably should just require this. I'm surprised posix didn't just insist, sometimes they do. > If you have one, then it's a bug in g++ combined with the FreeBSD > headers. One doesn't need a reference for this to be a bug in FreeBSD. > If you don't, then it's a fault in LLVM's usage of NULL, which > happens not to matter on some platforms. Arguably, the usage of NULL is theoretically bad: http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/nullptr But, I'm deeply against causing major pains for 99% of the people that can manage to work on a quality implementation, just because someone can pedantically come up with a broken system that trivially can just be fixed: #ifdef FreeBSD #ifdef __GNUG__ #undef NULL #define NULL __null #endif #endif even if we needed to do this on the client side. However, if you want llvm's sources to be pedantically correct, just turn on -Wstrict-null-sentinel and prest, everyone will be hit by this, not just you. I'm not advocating that however. >>> If NULL is #define'd to __null on some platforms, then this is >>> great, but isn't it a GCC extension? >> >> I'd call it a private internal implementation detail of the >> compiler. The compiler is implemented such that for proper >> operation, NULL _must_ be __null. > > No, the compiler is implemented such that, for NULL to be a pointer > when passed as an argument to a variadic function it must be __null. No, the compiler is implemented such that NULL is __null. Honest. > Since the C++ spec appears to allow NULL to be 0 or 0L, No, it does allow that. Read the standard again. The specs says that g++ gets to define it, and g++ defines it as __null. Since it is defined to be __null, it _cannot_ be any other value, including 0 or 0L. > for compatibility with C code and the C++ type system, this means > that passing NULL as a pointer when it is an argument to variadic > functions is either a special case in the spec or a GCC extension. We call it a quality of implementation. > I have never heard of NULL having any special behaviour Welcome to g++. > The fact that there is no such behaviour was cited as the main > motivation for the introduction of one of the extensions added in C+ > +0x. :-( I'm skeptical that nullptr is the right solution. >>> I was under the impression that the LLVM coding conventions stated >>> that GCC extensions were to be avoided so that it could be easily >>> portable to compilers. >> >> llvm uses NULL. NULL is not a gcc extension. > > Totally irrelevant. Once again, the question is whether NULL is > guaranteed to be a type which will be passed as a pointer or a > pointer-sized integer to variadic functions, not whether NULL is in > the standard. No, technically you need to do: (char *)NULL. So, what are you interested in, the theoretics of hard core pedantictry or the engineering realities of having FreeBSD be warning free? From markleone at gmail.com Tue Jan 20 22:54:29 2009 From: markleone at gmail.com (Mark Leone) Date: Tue, 20 Jan 2009 20:54:29 -0800 Subject: [cfe-dev] From LLVM Bytecode to C source In-Reply-To: <496C6838.50408@dps.uibk.ac.at> References: <496C6838.50408@dps.uibk.ac.at> Message-ID: <761659910901202054i24dd701dlc10ffd5712df0842@mail.gmail.com> On Tue, Jan 13, 2009 at 2:08 AM, Simone Pellegrini wrote: > > I wonder to know if there is any chance to convert back emitted LLVM > bytecode into a C source file using clang (or any other existing tool) > You would essentially need a decompiler. Here's a good reference that describes what would be involved: Krakatoa: Decompilation in Java by Todd A. Proebsting, Scott A. Watterson http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.39.5640 - Mark From csdavec at swansea.ac.uk Wed Jan 21 06:18:05 2009 From: csdavec at swansea.ac.uk (David Chisnall) Date: Wed, 21 Jan 2009 12:18:05 +0000 Subject: [cfe-dev] Fixing selector types on the GNU runtime In-Reply-To: References: <8518A0F5-8613-4E87-8AE7-264F547617F3@swan.ac.uk> <21970411-3554-4EBE-BB30-A9F6B125029B@apple.com> <0B5D785F-C43E-49B2-BA95-58DBCAD0CEDF@apple.com> <42B356CD-9EFA-429F-A33A-3E6F3A11E18C@swan.ac.uk> Message-ID: <96A70BD4-AC9D-4098-8362-A020C85EB3EF@swan.ac.uk> On 21 Jan 2009, at 03:14, Mike Stump wrote: > So, what are you interested in, the theoretics of hard core > pedantictry or the engineering realities of having FreeBSD be warning > free? I'm interested in fixing the warning only in as far as the warning indicates potentially unsafe code. The code, as written and according to the language specification, says pass a zero integer value of some indeterminate size to terminate the variadic function. The callee expects a zero pointer value. This is categorically wrong. If some compilers on some architectures do the right thing, then that's a nice bonus. On x86/FreeBSD, the compiler does the right thing (since NULL is a pointer-sized int) but it warns that this is a coincidence. The #ifdef block you suggest makes the warning go away on FreeBSD/x86, but this is not a platform where the real problem actually occurs, just one which notices that the code is wrong and issues a warning. Warning that the code does not say what you think it does is not a bug, it is a (useful) feature. The diff I submitted does the right thing, according to the standard. If this is not what you want, then please update the coding conventions to specify this exemption. As it stands, my diff will avoid real issues on platforms like Win64, where 0 and 0L, the two suggested definitions of NULL from the standard, are both smaller than pointers. I have variadic function calls in this file with more pointer arguments than there are integer registers on x86-64 for argument passing, so the 0 will be passed on the stack on this platform and not extended to 64-bits. Honestly, the amount of effort people have put in to arguing against fixing this one file is less than the amount of effort it would have taken to make the change everywhere in LLVM. I put these changes in with the fixing the type conversion diff because I assumed there would be no debate about fixing incorrect code. It seems I was wrong, so have attached a diff that only fixes the type conversion error, and leaves the unsafe variadic function calls in. David -------------- next part -------------- A non-text attachment was scrubbed... Name: clang.diff Type: application/octet-stream Size: 1386 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090121/9efccadc/attachment-0001.obj -------------- next part -------------- From monty at codetransform.com Wed Jan 21 11:30:31 2009 From: monty at codetransform.com (Monty Zukowski) Date: Wed, 21 Jan 2009 09:30:31 -0800 Subject: [cfe-dev] Static analysis tool development In-Reply-To: References: <73e8e3430901160846v734a65ch28dae1f04ecb7d2e@mail.gmail.com> <87373C76-C757-4921-9497-BA05F4CE977B@apple.com> <73e8e3430901170653hc1efd1odc11f8496ed7cb64@mail.gmail.com> <1b587cab0901170702m104d99ach2e8049d74ef335b0@mail.gmail.com> Message-ID: <73e8e3430901210930v7b8966eav7ec7b81189794358@mail.gmail.com> I love the idea of the trac plugin as well. Annotations have their place, but oftentimes when I start to look into a huge amount of warnings I want to defer them instead of mark them as OK. I also want to see any new ones that come up. In any event I agree with Ted that the best use of someone's time external to the project would be on issue tracking instead of actual analysis algorithms. I still need to sit down and digest the comments in this thread and see if I can come up with a reasonable plan of action. If anyone out there is available to do some of this work (for money) let me know and I'll see if I can work you into the proposal. Monty From vandungto at gmail.com Wed Jan 21 11:39:05 2009 From: vandungto at gmail.com (VanDung To) Date: Wed, 21 Jan 2009 11:39:05 -0600 Subject: [cfe-dev] automatic include Message-ID: Hello, I'm not sure if there's a way in clang to do this, however, I'd like to automatically include a header file every time I compiles a program. What would be the best way to do this? Can I do this externally to the compiler or do I need to modify the compiler. Also, I'd like to have my header files precompiled. Where can I find the documentation on how to do this. Thank you for all your help, Van To -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090121/880de161/attachment.html From clattner at apple.com Wed Jan 21 11:42:21 2009 From: clattner at apple.com (Chris Lattner) Date: Wed, 21 Jan 2009 09:42:21 -0800 Subject: [cfe-dev] automatic include In-Reply-To: References: Message-ID: <95620157-AA8B-46EA-B02F-A8280AF8F310@apple.com> On Jan 21, 2009, at 9:39 AM, VanDung To wrote: > Hello, > > I'm not sure if there's a way in clang to do this, however, I'd like > to automatically include a header file every time I compiles a > program. What would be the best way to do this? Can I do this > externally to the compiler or do I need to modify the compiler. You can use the -include option, it works just like gcc: $ echo "typedef int x;" > t.h $ echo "x y;" > t.c $ clang t.c -include t.h -I. > > Also, I'd like to have my header files precompiled. Where can I find > the documentation on how to do this. PCH is still under active development, the command line options are the same as those used by gcc. -Chris From sebastian.redl at getdesigned.at Wed Jan 21 11:43:16 2009 From: sebastian.redl at getdesigned.at (Sebastian Redl) Date: Wed, 21 Jan 2009 18:43:16 +0100 Subject: [cfe-dev] automatic include In-Reply-To: References: Message-ID: <49775EB4.7090302@getdesigned.at> VanDung To wrote: > Hello, > > I'm not sure if there's a way in clang to do this, however, I'd like > to automatically include a header file every time I compiles a > program. What would be the best way to do this? Can I do this > externally to the compiler or do I need to modify the compiler. See the -include option. > > Also, I'd like to have my header files precompiled. Where can I find > the documentation on how to do this. > We don't yet have support for real pre-compiled headers. Support for pre-tokenized headers is in development and, from what I've seen, usable, but probably not production-quality (but then, Clang as a whole isn't there yet). Sebastian From vandungto at gmail.com Wed Jan 21 11:48:00 2009 From: vandungto at gmail.com (VanDung To) Date: Wed, 21 Jan 2009 11:48:00 -0600 Subject: [cfe-dev] automatic include In-Reply-To: <95620157-AA8B-46EA-B02F-A8280AF8F310@apple.com> References: <95620157-AA8B-46EA-B02F-A8280AF8F310@apple.com> Message-ID: Thanks for the quick response. I'm not looking for a compile time option (-include -I). In the environment I'm looking at, it is very awkward to force the user to specify the include file every time. Is there a way for clang to do this without using the compile time option? I'm willing to modify/hack some code. Sincerely, On Wed, Jan 21, 2009 at 11:42 AM, Chris Lattner wrote: > > On Jan 21, 2009, at 9:39 AM, VanDung To wrote: > > Hello, >> >> I'm not sure if there's a way in clang to do this, however, I'd like to >> automatically include a header file every time I compiles a program. What >> would be the best way to do this? Can I do this externally to the compiler >> or do I need to modify the compiler. >> > > You can use the -include option, it works just like gcc: > > $ echo "typedef int x;" > t.h > $ echo "x y;" > t.c > $ clang t.c -include t.h -I. > > >> Also, I'd like to have my header files precompiled. Where can I find the >> documentation on how to do this. >> > > PCH is still under active development, the command line options are the > same as those used by gcc. > > -Chris > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090121/d0b50a68/attachment.html From clattner at apple.com Wed Jan 21 11:50:08 2009 From: clattner at apple.com (Chris Lattner) Date: Wed, 21 Jan 2009 09:50:08 -0800 Subject: [cfe-dev] automatic include In-Reply-To: References: <95620157-AA8B-46EA-B02F-A8280AF8F310@apple.com> Message-ID: <1DD41562-3829-4DCF-AF81-140CC12162A6@apple.com> On Jan 21, 2009, at 9:48 AM, VanDung To wrote: > Thanks for the quick response. > > I'm not looking for a compile time option (-include -I). In the > environment I'm looking at, it is very awkward to force the user to > specify the include file every time. Is there a way for clang to do > this without using the compile time option? I'm willing to modify/ > hack some code. Sure, the "-include" option just adds a #include to the predefines buffer. If you look at how -include is implemented, you can see this in action and do something similar. -Chris > > > Sincerely, > > On Wed, Jan 21, 2009 at 11:42 AM, Chris Lattner > wrote: > > On Jan 21, 2009, at 9:39 AM, VanDung To wrote: > > Hello, > > I'm not sure if there's a way in clang to do this, however, I'd like > to automatically include a header file every time I compiles a > program. What would be the best way to do this? Can I do this > externally to the compiler or do I need to modify the compiler. > > You can use the -include option, it works just like gcc: > > $ echo "typedef int x;" > t.h > $ echo "x y;" > t.c > $ clang t.c -include t.h -I. > > > > Also, I'd like to have my header files precompiled. Where can I find > the documentation on how to do this. > > PCH is still under active development, the command line options are > the same as those used by gcc. > > -Chris > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090121/a8328265/attachment.html From vandungto at gmail.com Wed Jan 21 11:52:40 2009 From: vandungto at gmail.com (VanDung To) Date: Wed, 21 Jan 2009 11:52:40 -0600 Subject: [cfe-dev] automatic include In-Reply-To: <1DD41562-3829-4DCF-AF81-140CC12162A6@apple.com> References: <95620157-AA8B-46EA-B02F-A8280AF8F310@apple.com> <1DD41562-3829-4DCF-AF81-140CC12162A6@apple.com> Message-ID: Thank you, I found the code to do that. On Wed, Jan 21, 2009 at 11:50 AM, Chris Lattner wrote: > > On Jan 21, 2009, at 9:48 AM, VanDung To wrote: > > Thanks for the quick response. > > I'm not looking for a compile time option (-include -I). In the > environment I'm looking at, it is very awkward to force the user to specify > the include file every time. Is there a way for clang to do this without > using the compile time option? I'm willing to modify/hack some code. > > > Sure, the "-include" option just adds a #include to the predefines buffer. > If you look at how -include is implemented, you can see this in action and > do something similar. > > -Chris > > > > Sincerely, > > On Wed, Jan 21, 2009 at 11:42 AM, Chris Lattner wrote: > >> >> On Jan 21, 2009, at 9:39 AM, VanDung To wrote: >> >> Hello, >>> >>> I'm not sure if there's a way in clang to do this, however, I'd like to >>> automatically include a header file every time I compiles a program. What >>> would be the best way to do this? Can I do this externally to the compiler >>> or do I need to modify the compiler. >>> >> >> You can use the -include option, it works just like gcc: >> >> $ echo "typedef int x;" > t.h >> $ echo "x y;" > t.c >> $ clang t.c -include t.h -I. >> >> >>> Also, I'd like to have my header files precompiled. Where can I find the >>> documentation on how to do this. >>> >> >> PCH is still under active development, the command line options are the >> same as those used by gcc. >> >> -Chris >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090121/ad231771/attachment-0001.html From clattner at apple.com Wed Jan 21 12:27:36 2009 From: clattner at apple.com (Chris Lattner) Date: Wed, 21 Jan 2009 10:27:36 -0800 Subject: [cfe-dev] Fixing selector types on the GNU runtime In-Reply-To: <96A70BD4-AC9D-4098-8362-A020C85EB3EF@swan.ac.uk> References: <8518A0F5-8613-4E87-8AE7-264F547617F3@swan.ac.uk> <21970411-3554-4EBE-BB30-A9F6B125029B@apple.com> <0B5D785F-C43E-49B2-BA95-58DBCAD0CEDF@apple.com> <42B356CD-9EFA-429F-A33A-3E6F3A11E18C@swan.ac.uk> <96A70BD4-AC9D-4098-8362-A020C85EB3EF@swan.ac.uk> Message-ID: On Jan 21, 2009, at 4:18 AM, David Chisnall wrote: > have attached a diff that only fixes the type conversion error, and > leaves the unsafe variadic function calls in. This patch doesn't apply for me: patching file lib/CodeGen/CGObjCGNU.cpp patch: **** malformed patch at line 33: @@ -797,6 +800,9 @@ -Chris From csdavec at swansea.ac.uk Wed Jan 21 12:37:09 2009 From: csdavec at swansea.ac.uk (David Chisnall) Date: Wed, 21 Jan 2009 18:37:09 +0000 Subject: [cfe-dev] Fixing selector types on the GNU runtime In-Reply-To: References: <8518A0F5-8613-4E87-8AE7-264F547617F3@swan.ac.uk> <21970411-3554-4EBE-BB30-A9F6B125029B@apple.com> <0B5D785F-C43E-49B2-BA95-58DBCAD0CEDF@apple.com> <42B356CD-9EFA-429F-A33A-3E6F3A11E18C@swan.ac.uk> <96A70BD4-AC9D-4098-8362-A020C85EB3EF@swan.ac.uk> Message-ID: <901E932B-33A8-41B1-9B8D-0039630F902B@swan.ac.uk> On 21 Jan 2009, at 18:27, Chris Lattner wrote: > > On Jan 21, 2009, at 4:18 AM, David Chisnall wrote: >> have attached a diff that only fixes the type conversion error, and >> leaves the unsafe variadic function calls in. > > This patch doesn't apply for me: > > patching file lib/CodeGen/CGObjCGNU.cpp > patch: **** malformed patch at line 33: @@ -797,6 +800,9 @@ > > -Chris Ooops. I deleted a bit in the middle of a chunk. Fixed. David -------------- next part -------------- A non-text attachment was scrubbed... Name: clang.diff Type: application/octet-stream Size: 1536 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090121/02d7c22d/attachment.obj From clattner at apple.com Wed Jan 21 12:53:27 2009 From: clattner at apple.com (Chris Lattner) Date: Wed, 21 Jan 2009 10:53:27 -0800 Subject: [cfe-dev] Fixing selector types on the GNU runtime In-Reply-To: <901E932B-33A8-41B1-9B8D-0039630F902B@swan.ac.uk> References: <8518A0F5-8613-4E87-8AE7-264F547617F3@swan.ac.uk> <21970411-3554-4EBE-BB30-A9F6B125029B@apple.com> <0B5D785F-C43E-49B2-BA95-58DBCAD0CEDF@apple.com> <42B356CD-9EFA-429F-A33A-3E6F3A11E18C@swan.ac.uk> <96A70BD4-AC9D-4098-8362-A020C85EB3EF@swan.ac.uk> <901E932B-33A8-41B1-9B8D-0039630F902B@swan.ac.uk> Message-ID: <0BEFB8AC-9F3A-4E97-9F15-7F0F0345C70D@apple.com> On Jan 21, 2009, at 10:37 AM, David Chisnall wrote: > > On 21 Jan 2009, at 18:27, Chris Lattner wrote: > >> >> On Jan 21, 2009, at 4:18 AM, David Chisnall wrote: >>> have attached a diff that only fixes the type conversion error, >>> and leaves the unsafe variadic function calls in. >> >> This patch doesn't apply for me: >> >> patching file lib/CodeGen/CGObjCGNU.cpp >> patch: **** malformed patch at line 33: @@ -797,6 +800,9 @@ >> >> -Chris > > Ooops. I deleted a bit in the middle of a chunk. Fixed. This didn't apply either, but I did it manually: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20090119/011121.html However, why are you using 'getTypeAtIndex'? That always returns i64 for a pointer, it is not returning the first element of the struct. Is that what you want? -Chris From mrs at apple.com Wed Jan 21 13:04:56 2009 From: mrs at apple.com (Mike Stump) Date: Wed, 21 Jan 2009 11:04:56 -0800 Subject: [cfe-dev] Fixing selector types on the GNU runtime In-Reply-To: <96A70BD4-AC9D-4098-8362-A020C85EB3EF@swan.ac.uk> References: <8518A0F5-8613-4E87-8AE7-264F547617F3@swan.ac.uk> <21970411-3554-4EBE-BB30-A9F6B125029B@apple.com> <0B5D785F-C43E-49B2-BA95-58DBCAD0CEDF@apple.com> <42B356CD-9EFA-429F-A33A-3E6F3A11E18C@swan.ac.uk> <96A70BD4-AC9D-4098-8362-A020C85EB3EF@swan.ac.uk> Message-ID: <2F10AFEB-ADBF-4058-819C-D2A4B0376993@apple.com> On Jan 21, 2009, at 4:18 AM, David Chisnall wrote: > my diff will avoid real issues on platforms like Win64, where 0 and > 0L, the two suggested definitions of NULL from the standard, are > both smaller than pointers. What _is_ NULL defined to on Win64? From csdavec at swansea.ac.uk Wed Jan 21 13:07:15 2009 From: csdavec at swansea.ac.uk (David Chisnall) Date: Wed, 21 Jan 2009 19:07:15 +0000 Subject: [cfe-dev] Fixing selector types on the GNU runtime In-Reply-To: <2F10AFEB-ADBF-4058-819C-D2A4B0376993@apple.com> References: <8518A0F5-8613-4E87-8AE7-264F547617F3@swan.ac.uk> <21970411-3554-4EBE-BB30-A9F6B125029B@apple.com> <0B5D785F-C43E-49B2-BA95-58DBCAD0CEDF@apple.com> <42B356CD-9EFA-429F-A33A-3E6F3A11E18C@swan.ac.uk> <96A70BD4-AC9D-4098-8362-A020C85EB3EF@swan.ac.uk> <2F10AFEB-ADBF-4058-819C-D2A4B0376993@apple.com> Message-ID: On 21 Jan 2009, at 19:04, Mike Stump wrote: > On Jan 21, 2009, at 4:18 AM, David Chisnall wrote: >> my diff will avoid real issues on platforms like Win64, where 0 and >> 0L, the two suggested definitions of NULL from the standard, are >> both smaller than pointers. > > What _is_ NULL defined to on Win64? I presume that depends on the compiler you use and the headers you include... David From mrs at apple.com Wed Jan 21 13:18:47 2009 From: mrs at apple.com (Mike Stump) Date: Wed, 21 Jan 2009 11:18:47 -0800 Subject: [cfe-dev] Fixing selector types on the GNU runtime In-Reply-To: References: <8518A0F5-8613-4E87-8AE7-264F547617F3@swan.ac.uk> <21970411-3554-4EBE-BB30-A9F6B125029B@apple.com> <0B5D785F-C43E-49B2-BA95-58DBCAD0CEDF@apple.com> <42B356CD-9EFA-429F-A33A-3E6F3A11E18C@swan.ac.uk> <96A70BD4-AC9D-4098-8362-A020C85EB3EF@swan.ac.uk> <2F10AFEB-ADBF-4058-819C-D2A4B0376993@apple.com> Message-ID: On Jan 21, 2009, at 11:07 AM, David Chisnall wrote: > On 21 Jan 2009, at 19:04, Mike Stump wrote: > >> On Jan 21, 2009, at 4:18 AM, David Chisnall wrote: >>> my diff will avoid real issues on platforms like Win64, where 0 >>> and 0L, the two suggested definitions of NULL from the standard, >>> are both smaller than pointers. >> >> What _is_ NULL defined to on Win64? > > I presume that depends on the compiler you use and the headers you > include... On those platforms for which it will fix real issues as quoted above. This excludes clang, g++, llvm-g++ to name a few where I'm reasonably certain there will be no problems. I'm trying to ascertain if you are raising a theoretic point, or a real issue. Anyway, seems more reliable to just redefine NULL on those platforms that define it incorrectly for our needs, as otherwise people will put in NULL, and people will likely miss converting it. To help ensure we never have an issue, we could: assert (sizeof (NULL) == sizeof (void *)); someplace. From sebastian.redl at getdesigned.at Wed Jan 21 15:24:27 2009 From: sebastian.redl at getdesigned.at (Sebastian Redl) Date: Wed, 21 Jan 2009 22:24:27 +0100 Subject: [cfe-dev] Fixing selector types on the GNU runtime In-Reply-To: References: <8518A0F5-8613-4E87-8AE7-264F547617F3@swan.ac.uk> <21970411-3554-4EBE-BB30-A9F6B125029B@apple.com> <0B5D785F-C43E-49B2-BA95-58DBCAD0CEDF@apple.com> <42B356CD-9EFA-429F-A33A-3E6F3A11E18C@swan.ac.uk> <96A70BD4-AC9D-4098-8362-A020C85EB3EF@swan.ac.uk> <2F10AFEB-ADBF-4058-819C-D2A4B0376993@apple.com> Message-ID: <4977928B.2050608@getdesigned.at> Mike Stump wrote: > On Jan 21, 2009, at 11:07 AM, David Chisnall wrote: > >> On 21 Jan 2009, at 19:04, Mike Stump wrote: >> >> >>> On Jan 21, 2009, at 4:18 AM, David Chisnall wrote: >>> >>>> my diff will avoid real issues on platforms like Win64, where 0 >>>> and 0L, the two suggested definitions of NULL from the standard, >>>> are both smaller than pointers. >>>> >>> What _is_ NULL defined to on Win64? >>> All the VC++ headers I have available currently define it as 0, regardless of platform. However, these are variants that do not really support 64-bit compilation. I can look tomorrow at a definitely 64-bit capable version. On the other hand, I don't think MS changes the CRT headers between the Express and the Professional edition. >> I presume that depends on the compiler you use and the headers you >> include... >> > > On those platforms for which it will fix real issues as quoted above. > This excludes clang, g++, llvm-g++ to name a few where I'm reasonably > certain there will be no problems. I'm trying to ascertain if you are > raising a theoretic point, or a real issue. Anyway, seems more > reliable to just redefine NULL on those platforms that define it > incorrectly for our needs, as otherwise people will put in NULL, and > people will likely miss converting it. > > To help ensure we never have an issue, we could: > > assert (sizeof (NULL) == sizeof (void *)); > > someplace. > Better yet, assert this statically: typedef int null_must_have_pointer_size[sizeof(NULL) == sizeof(void*)]; Sebastian From clattner at apple.com Thu Jan 22 00:03:24 2009 From: clattner at apple.com (Chris Lattner) Date: Wed, 21 Jan 2009 22:03:24 -0800 Subject: [cfe-dev] [cfe-commits] r62192 - in /cfe/trunk: include/clang/Basic/DiagnosticKinds.def lib/Sema/SemaDecl.cpp In-Reply-To: <200901132310.n0DNApga014749@zion.cs.uiuc.edu> References: <200901132310.n0DNApga014749@zion.cs.uiuc.edu> Message-ID: <9035CE9F-500E-4EA7-9BFF-2817487016CC@apple.com> On Jan 13, 2009, at 3:10 PM, Douglas Gregor wrote: > URL: http://llvm.org/viewvc/llvm-project?rev=62192&view=rev > Log: > Permitting typedefs without a name is a Microsoft/GNU extension Hey Doug, > +++ cfe/trunk/include/clang/Basic/DiagnosticKinds.def Tue Jan 13 > 17:10:51 2009 > @@ -593,6 +593,8 @@ > "expected unqualified-id") > DIAG(err_no_declarators, ERROR, > "declaration does not declare anything") > +DIAG(ext_no_declarators, EXTENSION, > + "typedef without a name is a Microsoft extension") Should this be an EXTWARN so that it warns by default? > + // Permit typedefs without declarators as a Microsoft extension. > if (!DS.isMissingDeclaratorOk()) { > + if (getLangOptions().Microsoft && > + DS.getStorageClassSpec() == DeclSpec::SCS_typedef) { > + Diag(DS.getSourceRange().getBegin(), diag::ext_no_declarators) > + << DS.getSourceRange(); > + return Tag; > + } This touches on meta-design issues, but do you think it is better to test for getLangOptions.MS here, or do you think it is better to have the Clang driver map this onto ERROR by default when not is ms extensions mode? Both approaches work, but they have different tradeoffs. I'm curious what you (and others!) think. -Chris From dgregor at apple.com Thu Jan 22 10:16:28 2009 From: dgregor at apple.com (Douglas Gregor) Date: Thu, 22 Jan 2009 08:16:28 -0800 Subject: [cfe-dev] [cfe-commits] r62192 - in /cfe/trunk: include/clang/Basic/DiagnosticKinds.def lib/Sema/SemaDecl.cpp In-Reply-To: <9035CE9F-500E-4EA7-9BFF-2817487016CC@apple.com> References: <200901132310.n0DNApga014749@zion.cs.uiuc.edu> <9035CE9F-500E-4EA7-9BFF-2817487016CC@apple.com> Message-ID: <06A68CA9-320A-4FA2-879D-46770CE856CB@apple.com> Hi Chris, On Jan 21, 2009, at 10:03 PM, Chris Lattner wrote: > > On Jan 13, 2009, at 3:10 PM, Douglas Gregor wrote: >> URL: http://llvm.org/viewvc/llvm-project?rev=62192&view=rev >> Log: >> Permitting typedefs without a name is a Microsoft/GNU extension > > Hey Doug, Hi Chris! > >> +++ cfe/trunk/include/clang/Basic/DiagnosticKinds.def Tue Jan 13 >> 17:10:51 2009 >> @@ -593,6 +593,8 @@ >> "expected unqualified-id") >> DIAG(err_no_declarators, ERROR, >> "declaration does not declare anything") >> +DIAG(ext_no_declarators, EXTENSION, >> + "typedef without a name is a Microsoft extension") > > Should this be an EXTWARN so that it warns by default? Yes. I'd changed it to WARNING when we found that GNU also had the same extensions (used in system headers nonetheless), but EXTWARN is the right thing. I'll fix it. > >> + // Permit typedefs without declarators as a Microsoft extension. >> if (!DS.isMissingDeclaratorOk()) { >> + if (getLangOptions().Microsoft && >> + DS.getStorageClassSpec() == DeclSpec::SCS_typedef) { >> + Diag(DS.getSourceRange().getBegin(), diag::ext_no_declarators) >> + << DS.getSourceRange(); >> + return Tag; >> + } > > This touches on meta-design issues, but do you think it is better to > test for getLangOptions.MS here, or do you think it is better to > have the Clang driver map this onto ERROR by default when not is ms > extensions mode? Both approaches work, but they have different > tradeoffs. I'm curious what you (and others!) think. It's an apt meta-issue, but I think in this case, since it's also a GNU extension, it should be an EXTWARN regardless of dialect. On the meta-issue itself, I think I like having the Clang driver make decisions between WARNING/EXTWARN/EXTENSION, but to me it seems like switching a diagnostic from or to ERROR is just asking for trouble: even if it works when we initially do it, we're likely to evolve Sema or the Parser to assume that an error really is an error, and screw up processing when that error turns out not to be an error. - Doug From clattner at apple.com Thu Jan 22 20:08:08 2009 From: clattner at apple.com (Chris Lattner) Date: Thu, 22 Jan 2009 18:08:08 -0800 Subject: [cfe-dev] [cfe-commits] r62192 - in /cfe/trunk: include/clang/Basic/DiagnosticKinds.def lib/Sema/SemaDecl.cpp In-Reply-To: <06A68CA9-320A-4FA2-879D-46770CE856CB@apple.com> References: <200901132310.n0DNApga014749@zion.cs.uiuc.edu> <9035CE9F-500E-4EA7-9BFF-2817487016CC@apple.com> <06A68CA9-320A-4FA2-879D-46770CE856CB@apple.com> Message-ID: On Jan 22, 2009, at 8:16 AM, Douglas Gregor wrote: >>> +++ cfe/trunk/include/clang/Basic/DiagnosticKinds.def Tue Jan 13 >>> 17:10:51 2009 >>> @@ -593,6 +593,8 @@ >>> "expected unqualified-id") >>> DIAG(err_no_declarators, ERROR, >>> "declaration does not declare anything") >>> +DIAG(ext_no_declarators, EXTENSION, >>> + "typedef without a name is a Microsoft extension") >> >> Should this be an EXTWARN so that it warns by default? > > Yes. I'd changed it to WARNING when we found that GNU also had the > same extensions (used in system headers nonetheless), but EXTWARN is > the right thing. I'll fix it. Thanks, ok. >>> + // Permit typedefs without declarators as a Microsoft extension. >>> if (!DS.isMissingDeclaratorOk()) { >>> + if (getLangOptions().Microsoft && >>> + DS.getStorageClassSpec() == DeclSpec::SCS_typedef) { >>> + Diag(DS.getSourceRange().getBegin(), >>> diag::ext_no_declarators) >>> + << DS.getSourceRange(); >>> + return Tag; >>> + } >> >> This touches on meta-design issues, but do you think it is better >> to test for getLangOptions.MS here, or do you think it is better to >> have the Clang driver map this onto ERROR by default when not is ms >> extensions mode? Both approaches work, but they have different >> tradeoffs. I'm curious what you (and others!) think. > > It's an apt meta-issue, but I think in this case, since it's also a > GNU extension, it should be an EXTWARN regardless of dialect. On the > meta-issue itself, I think I like having the Clang driver make > decisions between WARNING/EXTWARN/EXTENSION, but to me it seems like > switching a diagnostic from or to ERROR is just asking for trouble: > even if it works when we initially do it, we're likely to evolve > Sema or the Parser to assume that an error really is an error, and > screw up processing when that error turns out not to be an error. It doesn't matter in this case anymore, however, the point that I was trying to make was that LangOptions and fine-grain warning control are very similar in some cases. In this case, the compiler (including down-stream clients) clearly has to be able to handle this feature. Using a langoption to control a warning just seems strange... -Chris From Axel.Naumann at cern.ch Fri Jan 23 03:55:53 2009 From: Axel.Naumann at cern.ch (Axel Naumann) Date: Fri, 23 Jan 2009 10:55:53 +0100 Subject: [cfe-dev] Preprocessor c'tor taking IdentifierInfoLookup* Message-ID: <49799429.3080708@cern.ch> Hi, could this patch be applied to make r62273's change backward compatible and to clarify that this argument is not needed for PP to work? Or did I misread the code and log? Cheers, Axel. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: clang_Lex_PP_ctor_IdentLookup_def.diff Url: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090123/63a7487a/attachment.pl From spellegrini at dps.uibk.ac.at Fri Jan 23 04:26:56 2009 From: spellegrini at dps.uibk.ac.at (Simone Pellegrini) Date: Fri, 23 Jan 2009 11:26:56 +0100 Subject: [cfe-dev] DataFlowAnalysis in Clang Message-ID: <49799B70.7090906@dps.uibk.ac.at> Dear all, I am currently evaluating tools to implement some high level-code-transformations directly in the source code. Clang seems to be a very nice platform for doing that, the only thing which is lacking is Data Dependency Analysis. I really need to have stuff like DefUse chains... and so on! As I cannot see anything like that in the Analysis module I wanted to start to implement them from scratch by myself. Before start this adventure I want to be sure such structures aren't already implemented in clang. I guess that this kind of analysis is not inline with the philosophy of the clang project, I saw that most of the transformations (loop transformations/constants propagation) are meant to be applied at LLVM bytecode level. However for the transformation I am interested in I really need to work at source code level; lot of information is lost when it's converted (like openmp pragmas... and so on) and that's not good for us! :) If you have any kind of pointer about the implementation of dataflow analysis in clang... you are really welcome! many thanks for the awesome work you are doing with clang, Simone From csdavec at swansea.ac.uk Fri Jan 23 07:19:54 2009 From: csdavec at swansea.ac.uk (David Chisnall) Date: Fri, 23 Jan 2009 13:19:54 +0000 Subject: [cfe-dev] Mac-specific code in CGObjC.cpp Message-ID: <77191E84-92BF-45A8-A99B-35D914140EBD@swan.ac.uk> Hi, I was looking at the declared properties implementation in clang and it seems that CGObjC.cpp, which should be runtime-agnostic, is making calls to objc_setProperty() and , which is an undocumented Apple- specific function. Is it possible to move the code for emitting the setters / getters for retain/copy properties into the runtime-specific code classes? David From spellegrini at dps.uibk.ac.at Fri Jan 23 10:42:41 2009 From: spellegrini at dps.uibk.ac.at (Simone Pellegrini) Date: Fri, 23 Jan 2009 17:42:41 +0100 Subject: [cfe-dev] About AST rewriting / manipulation Message-ID: <4979F381.9040409@dps.uibk.ac.at> Hello everyone, I am trying to use Clang as a source-to-source compiler. Through the API I've found the way to rewrite back the syntax tree into source code, and that's not difficult. However, before writing back the syntax tree I would like to manipulate the syntax tree in order to apply some code transformations. For example I would like to rewrite something like f(a,b) into g(b, a, c) Now I guess I should create the AST nodes I need (building a new CallExpr... object and so on...) and then substitute the old f(...) with the new g(...). The Clang API for creating AST nodes is nevertheless quite complex to use, it's really too demanding. Now, I am wonder that It would be very nice if I could write the statement I want to substitute (or to add) as a string and then use the the Clang parser to create the syntax tree of the piece of code I have written in a way it can be easily plugged in the old main syntax tree (of course the new instance of the parser should be invoked considering the previous context...). Is it possible to have this kind of behavior? Or my imagination simply went too far? :) Any pointers / references related to this kind of topic are really welcome! regards, Simone From dgregor at apple.com Fri Jan 23 11:09:06 2009 From: dgregor at apple.com (Douglas Gregor) Date: Fri, 23 Jan 2009 09:09:06 -0800 Subject: [cfe-dev] About AST rewriting / manipulation In-Reply-To: <4979F381.9040409@dps.uibk.ac.at> References: <4979F381.9040409@dps.uibk.ac.at> Message-ID: Hello Simone, On Jan 23, 2009, at 8:42 AM, Simone Pellegrini wrote: > I am trying to use Clang as a source-to-source compiler. Through the > API > I've found the way to rewrite back the syntax tree into source code, > and > that's not difficult. However, before writing back the syntax tree I > would like to manipulate the syntax tree in order to apply some code > transformations. > > For example I would like to rewrite something like f(a,b) into g(b, > a, c) Okay. > Now I guess I should create the AST nodes I need (building a new > CallExpr... object and so on...) and then substitute the old f(...) > with > the new g(...). The Clang API for creating AST nodes is nevertheless > quite complex to use, it's really too demanding. Interesting. I guess the demanding part of the API is that you need to be careful to ensure that you build semantically-correct ASTs. > Now, I am wonder that It would be very nice if I could write the > statement I want to substitute (or to add) as a string and then use > the > the Clang parser to create the syntax tree of the piece of code I have > written in a way it can be easily plugged in the old main syntax tree > (of course the new instance of the parser should be invoked > considering > the previous context...). Is it possible to have this kind of > behavior? I believe it is possible to extend Clang to do this, but there is no API to do so right now. The parser can be handed a set of tokens and told to "go parse these" by calling into the appropriate parse function; we do this to implement some C++ semantics, such as inline definitions of member functions. However, the hard part---that nobody has even thought about how to implement---is that you would need to be able to take an AST node and instruct the parser *and semantic analysis* to set its internal state to the point where that AST node was parsed. That means reconstructing the scope stack, the information about which identifiers bind to which declarations, and so on. Not all of this information is present in the AST, so this is a major undertaking. - Doug From dgregor at apple.com Fri Jan 23 11:11:50 2009 From: dgregor at apple.com (Douglas Gregor) Date: Fri, 23 Jan 2009 09:11:50 -0800 Subject: [cfe-dev] [cfe-commits] r62192 - in /cfe/trunk: include/clang/Basic/DiagnosticKinds.def lib/Sema/SemaDecl.cpp In-Reply-To: References: <200901132310.n0DNApga014749@zion.cs.uiuc.edu> <9035CE9F-500E-4EA7-9BFF-2817487016CC@apple.com> <06A68CA9-320A-4FA2-879D-46770CE856CB@apple.com> Message-ID: <67AFFBD7-6813-4392-9D1E-76F32D995F1E@apple.com> On Jan 22, 2009, at 6:08 PM, Chris Lattner wrote: > On Jan 22, 2009, at 8:16 AM, Douglas Gregor wrote: >>>> + // Permit typedefs without declarators as a Microsoft extension. >>>> if (!DS.isMissingDeclaratorOk()) { >>>> + if (getLangOptions().Microsoft && >>>> + DS.getStorageClassSpec() == DeclSpec::SCS_typedef) { >>>> + Diag(DS.getSourceRange().getBegin(), >>>> diag::ext_no_declarators) >>>> + << DS.getSourceRange(); >>>> + return Tag; >>>> + } >>> >>> This touches on meta-design issues, but do you think it is better >>> to test for getLangOptions.MS here, or do you think it is better >>> to have the Clang driver map this onto ERROR by default when not >>> is ms extensions mode? Both approaches work, but they have >>> different tradeoffs. I'm curious what you (and others!) think. >> >> It's an apt meta-issue, but I think in this case, since it's also a >> GNU extension, it should be an EXTWARN regardless of dialect. On >> the meta-issue itself, I think I like having the Clang driver make >> decisions between WARNING/EXTWARN/EXTENSION, but to me it seems >> like switching a diagnostic from or to ERROR is just asking for >> trouble: even if it works when we initially do it, we're likely to >> evolve Sema or the Parser to assume that an error really is an >> error, and screw up processing when that error turns out not to be >> an error. > > It doesn't matter in this case anymore, however, the point that I > was trying to make was that LangOptions and fine-grain warning > control are very similar in some cases. In this case, the compiler > (including down-stream clients) clearly has to be able to handle > this feature. Using a langoption to control a warning just seems > strange... Yeah, I agree with that. When a diagnostic doesn't actually effect what the compiler is going to do, we shouldn't be checking LangOptions to decide whether to emit the warning; the diagnostics system can make that decision. - Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090123/f48ac454/attachment-0001.html From cedomir.segulja at gmail.com Fri Jan 23 11:30:28 2009 From: cedomir.segulja at gmail.com (Cedomir Segulja) Date: Fri, 23 Jan 2009 12:30:28 -0500 Subject: [cfe-dev] pragmas, source-to-source Message-ID: Hi all, I've just started using clang. I would like to use it for source-to-source transformations. For start, I would like to do the following: If a #pragma precedes a function call, then change the name of the function to be called. For example: input: ... #pragma <...> my_func(...) ... output: ... my_function_NEW(...) ... I've been looking at the objC->C example and I understand (to limited extent tho, how to use Rewriter class to modify the input file). Also, I've familiarize myself with HandlePragma mechanism, and I am able to indentify that there is a #pragma <...> in the code. The thing that I don't know is how to pass the information from lexical/syntax anlysis to the ASTConsumer, i.e how do I say (in this example) that specific call to my_func() should be renamed? Should I use SourceLocation or there is a better way? Thanks. Cedomir. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090123/3c533042/attachment.html From clattner at apple.com Fri Jan 23 12:01:10 2009 From: clattner at apple.com (Chris Lattner) Date: Fri, 23 Jan 2009 10:01:10 -0800 Subject: [cfe-dev] Preprocessor c'tor taking IdentifierInfoLookup* In-Reply-To: <49799429.3080708@cern.ch> References: <49799429.3080708@cern.ch> Message-ID: On Jan 23, 2009, at 1:55 AM, Axel Naumann wrote: > Hi, > > could this patch be applied to make r62273's change backward > compatible and to > clarify that this argument is not needed for PP to work? Or did I > misread the > code and log? You're right, applied thanks! http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20090119/011240.html -Chris From dgregor at apple.com Fri Jan 23 12:43:14 2009 From: dgregor at apple.com (Douglas Gregor) Date: Fri, 23 Jan 2009 10:43:14 -0800 Subject: [cfe-dev] Review of transparent_union patch Message-ID: <46C549EF-B1F1-46BB-A96F-FB11DD2CB5DE@apple.com> Anders Johnsen submitted a patch to implement semantic analysis for transparent_union in http://llvm.org/bugs/show_bug.cgi?id=2015 Here's a review of that patch, which is almost ready to go in. Could you include a test-case as part of your patch? + // FIXME: Corredt behaviour for no-definition unions? + if (!RD->isDefinition()) + return; Typo "corredt". Also, I don't think this is the behavior we want. If the union is forward-declared with the transparent_union attribute, we should keep that attribute, as in this example: union wait { float *fp; double *dp; }; union wait_status_ptr_t __attribute__ ((__transparent_union__)); union wait_status_ptr_t { int *__ip; union wait *__up; }; int wait (union wait_status_ptr_t); int w1 () { int w; return wait (&w); } int w2 () { union wait w; return wait (&w); } GCC fails on this example. We also fail, because when there is no definition of the union, we silently ignore the attribute. We either need to (a) produce a warning saying that this attribute is ignored if it isn't on the definition, or (b) add the attribute, then make sure it gets processed properly when the union is defined, later. While I like (b) better, GCC seems to be doing (a) without warning about it, so I suggest we do (a) with the warning. + // Ignore anonymous unions. + if (RD->isAnonymousStructOrUnion()) + return; Here, again, we should produce a warning saying that we're ignoring this attribute, since it can't apply to anonymous structs/unions. + if (ArgType->isUnionType()) { + const RecordType *UT = ArgType->getAsUnionType(); Please replace this with: if (const RecordType *UT = ArgType->getAsUnionType()) That way, we only walk through typedefs once. GCC completely ignores the transparent_union attribute in C++ mode. I suggest that we do the same (and produce a warning to say we did it!). With those (few) tweaks, this is ready to go in. Thanks! - Doug From skabet at gmail.com Fri Jan 23 13:33:41 2009 From: skabet at gmail.com (Anders Johnsen) Date: Fri, 23 Jan 2009 20:33:41 +0100 Subject: [cfe-dev] Fwd: Review of transparent_union patch In-Reply-To: <5be2d90901231125h1deccc8cm302c8559974fbd14@mail.gmail.com> References: <46C549EF-B1F1-46BB-A96F-FB11DD2CB5DE@apple.com> <5be2d90901231125h1deccc8cm302c8559974fbd14@mail.gmail.com> Message-ID: <5be2d90901231133x249f01eo42df50ac6d4697ff@mail.gmail.com> Hi, Thank you for the review. I've attached a corrected patch. Anders On Fri, Jan 23, 2009 at 7:43 PM, Douglas Gregor wrote: > Anders Johnsen submitted a patch to implement semantic analysis for > transparent_union in > > http://llvm.org/bugs/show_bug.cgi?id=2015 > > Here's a review of that patch, which is almost ready to go in. > > Could you include a test-case as part of your patch? > > + // FIXME: Corredt behaviour for no-definition unions? > + if (!RD->isDefinition()) > + return; > > Typo "corredt". > > Also, I don't think this is the behavior we want. If the union is > forward-declared with the transparent_union attribute, we should keep > that attribute, as in this example: > > union wait { float *fp; double *dp; }; > > union wait_status_ptr_t __attribute__ ((__transparent_union__)); > > union wait_status_ptr_t > { > int *__ip; > union wait *__up; > }; > > int wait (union wait_status_ptr_t); > > int w1 () { int w; return wait (&w); } > int w2 () { union wait w; return wait (&w); } > > GCC fails on this example. We also fail, because when there is no > definition of the union, we silently ignore the attribute. We either > need to (a) produce a warning saying that this attribute is ignored if > it isn't on the definition, or (b) add the attribute, then make sure > it gets processed properly when the union is defined, later. While I > like (b) better, GCC seems to be doing (a) without warning about it, > so I suggest we do (a) with the warning. > > + // Ignore anonymous unions. > + if (RD->isAnonymousStructOrUnion()) > + return; > > Here, again, we should produce a warning saying that we're ignoring > this attribute, since it can't apply to anonymous structs/unions. > > + if (ArgType->isUnionType()) { > + const RecordType *UT = ArgType->getAsUnionType(); > > Please replace this with: > > if (const RecordType *UT = ArgType->getAsUnionType()) > > That way, we only walk through typedefs once. > > GCC completely ignores the transparent_union attribute in C++ mode. I > suggest that we do the same (and produce a warning to say we did it!). > > With those (few) tweaks, this is ready to go in. Thanks! > > - Doug > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: transparent_union.patch Type: text/x-diff Size: 8454 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090123/2743c743/attachment.bin From kremenek at apple.com Fri Jan 23 14:39:00 2009 From: kremenek at apple.com (Ted Kremenek) Date: Fri, 23 Jan 2009 12:39:00 -0800 Subject: [cfe-dev] DataFlowAnalysis in Clang In-Reply-To: <49799B70.7090906@dps.uibk.ac.at> References: <49799B70.7090906@dps.uibk.ac.at> Message-ID: On Jan 23, 2009, at 2:26 AM, Simone Pellegrini wrote: > Dear all, > I am currently evaluating tools to implement some high > level-code-transformations directly in the source code. Clang seems to > be a very nice platform for doing that, the only thing which is > lacking > is Data Dependency Analysis. I really need to have stuff like DefUse > chains... and so on! As I cannot see anything like that in the > Analysis > module I wanted to start to implement them from scratch by myself. > > Before start this adventure I want to be sure such structures aren't > already implemented in clang. I guess that this kind of analysis is > not > inline with the philosophy of the clang project, I saw that most of > the > transformations (loop transformations/constants propagation) are meant > to be applied at LLVM bytecode level. However for the transformation I > am interested in I really need to work at source code level; lot of > information is lost when it's converted (like openmp pragmas... and so > on) and that's not good for us! :) If you have any kind of pointer > about > the implementation of dataflow analysis in clang... you are really > welcome! > > many thanks for the awesome work you are doing with clang, Simone Clang contains both flow-sensitive and path-sensitive dataflow analysis engines. They can be found in include/clang/Analysis. The flow-sensitive engine is used by LiveVariables.cpp and UninitializedValues.cpp respectively. Both dataflow analysis engines use source-level CFGs that model both the explicit and implicit control-flow of C. The flow-sensitive engine associates dataflow values with "block-level expressions" (which are expressions that appear as a "top-level" expression in the basic block of the source-level CFG). Using -cfg- dump and -cfg-view on a source file will give you a better idea of what these concepts mean. The dataflow solver uses a merge operate to merge values at confluence points and uses a worklist algorithm to compute dataflow values. The flow-sensitive solver is functional; it definitely works and has been tested, but it has been highly optimized for performance (there simply hasn't been a need yet). The path-sensitive engine is used by the static analyzer, is fairly complicated. It uses the notion of transfer functions to update dataflow state, but the program analysis task is modeled as a graph reachability problem in the state space graph of a program rather than associating dataflow values with sections of the CFG. From eli.friedman at gmail.com Fri Jan 23 15:08:28 2009 From: eli.friedman at gmail.com (Eli Friedman) Date: Fri, 23 Jan 2009 13:08:28 -0800 Subject: [cfe-dev] Fwd: Review of transparent_union patch In-Reply-To: <5be2d90901231133x249f01eo42df50ac6d4697ff@mail.gmail.com> References: <46C549EF-B1F1-46BB-A96F-FB11DD2CB5DE@apple.com> <5be2d90901231125h1deccc8cm302c8559974fbd14@mail.gmail.com> <5be2d90901231133x249f01eo42df50ac6d4697ff@mail.gmail.com> Message-ID: On Fri, Jan 23, 2009 at 11:33 AM, Anders Johnsen wrote: > Hi, > > Thank you for the review. I've attached a corrected patch. A few notes: 1. This breaks CodeGen for transparent unions, which was working before; it seems like this will be a large regression for CodeGen for many programs. 2. The way the attribute is getting attached looks wrong; this is a union attribute, so it's required to appear immediately after the definition of the union. I suppose that's mostly orthogonal to this patch, though. 3. + // Ignore anonymous unions. + if (RD->isAnonymousStructOrUnion()) { + S.Diag(Attr.getLoc(), + diag::warn_transparent_union_attribute_anonymous); + return; + } Why exactly are we ignoring anonymous structs/unions? gcc seems to support them; here's a testcase: void a(union {int a; int* b;} __attribute((transparent_union)) x); void b() {a(1);} 4. It looks like this allows floating-point types where gcc doesn't; testcase: union x {float a;int* b;} __attribute((transparent_union)); void a(union x a); void b() {a(1.0f);} -Eli From skabet at gmail.com Fri Jan 23 15:52:00 2009 From: skabet at gmail.com (Anders Johnsen) Date: Fri, 23 Jan 2009 22:52:00 +0100 Subject: [cfe-dev] Fwd: Review of transparent_union patch In-Reply-To: References: <46C549EF-B1F1-46BB-A96F-FB11DD2CB5DE@apple.com> <5be2d90901231125h1deccc8cm302c8559974fbd14@mail.gmail.com> <5be2d90901231133x249f01eo42df50ac6d4697ff@mail.gmail.com> Message-ID: <5be2d90901231352y39b675aav744fc05bc4855e1f@mail.gmail.com> Hi, On Fri, Jan 23, 2009 at 10:08 PM, Eli Friedman wrote: > On Fri, Jan 23, 2009 at 11:33 AM, Anders Johnsen wrote: >> Hi, >> >> Thank you for the review. I've attached a corrected patch. > > A few notes: > > 1. This breaks CodeGen for transparent unions, which was working > before; it seems like this will be a large regression for CodeGen for > many programs. Yes. I'm not sure where in CodeGen I should add support for this. But the other way was limited to pointer-types only and was using the wrong CC(should be as first type *i8, but was handled as [x * i8] afaik. > > 2. The way the attribute is getting attached looks wrong; this is a > union attribute, so it's required to appear immediately after the > definition of the union. I suppose that's mostly orthogonal to this > patch, though. What exactly do you mean by this? > > 3. > + // Ignore anonymous unions. > + if (RD->isAnonymousStructOrUnion()) { > + S.Diag(Attr.getLoc(), > + diag::warn_transparent_union_attribute_anonymous); > + return; > + } > Why exactly are we ignoring anonymous structs/unions? gcc seems to > support them; here's a testcase: > void a(union {int a; int* b;} __attribute((transparent_union)) x); > void b() {a(1);} You are right. Fixed > > 4. It looks like this allows floating-point types where gcc doesn't; testcase: > > union x {float a;int* b;} __attribute((transparent_union)); > void a(union x a); > void b() {a(1.0f);} > > -Eli > I've not handled the case where the first element is a floating point or vector. Is fixed in patch. I've also added a check for a empty union. Thanks you for the comments! Anders -------------- next part -------------- A non-text attachment was scrubbed... Name: transparent_union.patch Type: text/x-diff Size: 8821 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090123/9a9cd9f5/attachment.bin From sebastian.redl at getdesigned.at Sat Jan 24 09:16:58 2009 From: sebastian.redl at getdesigned.at (Sebastian Redl) Date: Sat, 24 Jan 2009 16:16:58 +0100 Subject: [cfe-dev] Where to put member pointers in the type hierarchy? Message-ID: <497B30EA.808@getdesigned.at> Hi, I'm currently implementing pointers-to-members, and now that I can parse the declaration, I need to extend the AST type hierarchy. So I'm wondering where to put member pointers. Should they be a subclass of PointerType, of PointerLikeType, or just of Type? Doug, I'm sure you've already thought about this. Sebastian From alexei.svitkine at gmail.com Sat Jan 24 10:02:22 2009 From: alexei.svitkine at gmail.com (Alexei Svitkine) Date: Sat, 24 Jan 2009 11:02:22 -0500 Subject: [cfe-dev] [Patch] Make ParseAST() take ASTContext and TU params Message-ID: <62d9ffc00901240802l312e8ek17de6d0f0b301995@mail.gmail.com> Hi, Attached is a patch to make ParseAST() take ASTContext and TranslationUnit as parameters, as suggested by Steve Naroff. This makes the FreeMemory parameter obsolete, so it is removed. The motivation is that clients are now responsible for owning those objects, and are also able to free them themselves, rather than leaking memory like before (when FreeMemory was false). I've made the new parameters default to 0, and if they are null then ParseAST will allocate them on its own and dispose of them after (the same functionality as when FreeMemory was false previously). -Alexei -------------- next part -------------- A non-text attachment was scrubbed... Name: ParseAST.diff Type: application/octet-stream Size: 3465 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090124/88cf23d8/attachment.obj From sebastian.redl at getdesigned.at Sat Jan 24 10:19:35 2009 From: sebastian.redl at getdesigned.at (Sebastian Redl) Date: Sat, 24 Jan 2009 17:19:35 +0100 Subject: [cfe-dev] [Patch] Make ParseAST() take ASTContext and TU params In-Reply-To: <62d9ffc00901240802l312e8ek17de6d0f0b301995@mail.gmail.com> References: <62d9ffc00901240802l312e8ek17de6d0f0b301995@mail.gmail.com> Message-ID: <497B3F97.8020908@getdesigned.at> Alexei Svitkine wrote: > Hi, > > Attached is a patch to make ParseAST() take ASTContext and > TranslationUnit as parameters, as suggested by Steve Naroff. > The double negative in the code confuses me somewhat, but isn't this condition the wrong way round? > + if (!DisableFree) { > + Context = new ASTContext(PP.getLangOptions(), > PP.getSourceManager(), > + PP.getTargetInfo(), > + PP.getIdentifierTable(), > PP.getSelectorTable()); > + TU = new TranslationUnit(*Context); > + } > + ParseAST(PP, Consumer.get(), Context, TU, Stats); Previously, if DisableFree was true, FreeMemory was false, and ParseAST didn't free the objects. Now, if DisableFree is true, the driver doesn't allocate objects, so ParseAST does and will free them. Sebastian From dgregor at apple.com Sat Jan 24 11:08:59 2009 From: dgregor at apple.com (Douglas Gregor) Date: Sat, 24 Jan 2009 09:08:59 -0800 Subject: [cfe-dev] Where to put member pointers in the type hierarchy? In-Reply-To: <497B30EA.808@getdesigned.at> References: <497B30EA.808@getdesigned.at> Message-ID: <322ADC66-7BE4-45D7-9A27-064CC8A82D1A@apple.com> On Jan 24, 2009, at 7:16 AM, Sebastian Redl wrote: > I'm currently implementing pointers-to-members, and now that I can > parse > the declaration, Cool! > I need to extend the AST type hierarchy. So I'm > wondering where to put member pointers. Should they be a subclass of > PointerType, of PointerLikeType, or just of Type? In standards parlance, member pointers are not actually pointers, so they should subclass "Type". - Doug From sebastian.redl at getdesigned.at Sat Jan 24 11:18:03 2009 From: sebastian.redl at getdesigned.at (Sebastian Redl) Date: Sat, 24 Jan 2009 18:18:03 +0100 Subject: [cfe-dev] Where to put member pointers in the type hierarchy? In-Reply-To: <322ADC66-7BE4-45D7-9A27-064CC8A82D1A@apple.com> References: <497B30EA.808@getdesigned.at> <322ADC66-7BE4-45D7-9A27-064CC8A82D1A@apple.com> Message-ID: <497B4D4B.6080808@getdesigned.at> Douglas Gregor wrote: > On Jan 24, 2009, at 7:16 AM, Sebastian Redl wrote: > >> I need to extend the AST type hierarchy. So I'm >> wondering where to put member pointers. Should they be a subclass of >> PointerType, of PointerLikeType, or just of Type? > > In standards parlance, member pointers are not actually pointers, so > they should subclass "Type". So Pointer is out. But PointerLike is our own invention. (I believe you're not a fan of this class, though.) Sebastian From dgregor at apple.com Sat Jan 24 12:02:15 2009 From: dgregor at apple.com (Douglas Gregor) Date: Sat, 24 Jan 2009 10:02:15 -0800 Subject: [cfe-dev] Where to put member pointers in the type hierarchy? In-Reply-To: <497B4D4B.6080808@getdesigned.at> References: <497B30EA.808@getdesigned.at> <322ADC66-7BE4-45D7-9A27-064CC8A82D1A@apple.com> <497B4D4B.6080808@getdesigned.at> Message-ID: <927883AD-BB75-4D9D-8C86-50692CBC87C4@apple.com> On Jan 24, 2009, at 9:18 AM, Sebastian Redl wrote: > Douglas Gregor wrote: >> On Jan 24, 2009, at 7:16 AM, Sebastian Redl wrote: >> >>> I need to extend the AST type hierarchy. So I'm >>> wondering where to put member pointers. Should they be a subclass of >>> PointerType, of PointerLikeType, or just of Type? >> >> In standards parlance, member pointers are not actually pointers, so >> they should subclass "Type". > > So Pointer is out. But PointerLike is our own invention. (I believe > you're not a fan of this class, though.) No, I don't particularly like PointerLike. It's only really useful for CodeGen, IMHO, and it doesn't even save that much effort their. Member pointers are their own kind of beast, that should subclass Type. - Doug From clattner at apple.com Sat Jan 24 12:54:18 2009 From: clattner at apple.com (Chris Lattner) Date: Sat, 24 Jan 2009 10:54:18 -0800 Subject: [cfe-dev] Where to put member pointers in the type hierarchy? In-Reply-To: <927883AD-BB75-4D9D-8C86-50692CBC87C4@apple.com> References: <497B30EA.808@getdesigned.at> <322ADC66-7BE4-45D7-9A27-064CC8A82D1A@apple.com> <497B4D4B.6080808@getdesigned.at> <927883AD-BB75-4D9D-8C86-50692CBC87C4@apple.com> Message-ID: <22DDE93D-D440-473D-8B99-76C9ADDF8F04@apple.com> On Jan 24, 2009, at 10:02 AM, Douglas Gregor wrote: > > On Jan 24, 2009, at 9:18 AM, Sebastian Redl wrote: > >> Douglas Gregor wrote: >>> On Jan 24, 2009, at 7:16 AM, Sebastian Redl wrote: >>> >>>> I need to extend the AST type hierarchy. So I'm >>>> wondering where to put member pointers. Should they be a subclass >>>> of >>>> PointerType, of PointerLikeType, or just of Type? >>> >>> In standards parlance, member pointers are not actually pointers, so >>> they should subclass "Type". >> >> So Pointer is out. But PointerLike is our own invention. (I believe >> you're not a fan of this class, though.) > > > No, I don't particularly like PointerLike. It's only really useful for > CodeGen, IMHO, and it doesn't even save that much effort their. Member > pointers are their own kind of beast, that should subclass Type. FWIW, I agree, -Chris From alexei.svitkine at gmail.com Sat Jan 24 13:51:31 2009 From: alexei.svitkine at gmail.com (Alexei Svitkine) Date: Sat, 24 Jan 2009 14:51:31 -0500 Subject: [cfe-dev] [Patch] Make ParseAST() take ASTContext and TU params In-Reply-To: <497B3F97.8020908@getdesigned.at> References: <62d9ffc00901240802l312e8ek17de6d0f0b301995@mail.gmail.com> <497B3F97.8020908@getdesigned.at> Message-ID: <62d9ffc00901241151u69da5620q87ae555ddb61c358@mail.gmail.com> You are right. Here's a revised patch. -Alexei On Sat, Jan 24, 2009 at 11:19 AM, Sebastian Redl wrote: > Alexei Svitkine wrote: >> Hi, >> >> Attached is a patch to make ParseAST() take ASTContext and >> TranslationUnit as parameters, as suggested by Steve Naroff. >> > > The double negative in the code confuses me somewhat, but isn't this > condition the wrong way round? > >> + if (!DisableFree) { >> + Context = new ASTContext(PP.getLangOptions(), >> PP.getSourceManager(), >> + PP.getTargetInfo(), >> + PP.getIdentifierTable(), >> PP.getSelectorTable()); >> + TU = new TranslationUnit(*Context); >> + } >> + ParseAST(PP, Consumer.get(), Context, TU, Stats); > > Previously, if DisableFree was true, FreeMemory was false, and ParseAST > didn't free the objects. > Now, if DisableFree is true, the driver doesn't allocate objects, so > ParseAST does and will free them. > > Sebastian > -------------- next part -------------- A non-text attachment was scrubbed... Name: ParseAST2.diff Type: application/octet-stream Size: 3464 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090124/a81b9cd2/attachment.obj From eli.friedman at gmail.com Sat Jan 24 14:57:04 2009 From: eli.friedman at gmail.com (Eli Friedman) Date: Sat, 24 Jan 2009 12:57:04 -0800 Subject: [cfe-dev] Fwd: Review of transparent_union patch In-Reply-To: <5be2d90901231352y39b675aav744fc05bc4855e1f@mail.gmail.com> References: <46C549EF-B1F1-46BB-A96F-FB11DD2CB5DE@apple.com> <5be2d90901231125h1deccc8cm302c8559974fbd14@mail.gmail.com> <5be2d90901231133x249f01eo42df50ac6d4697ff@mail.gmail.com> <5be2d90901231352y39b675aav744fc05bc4855e1f@mail.gmail.com> Message-ID: On Fri, Jan 23, 2009 at 1:52 PM, Anders Johnsen wrote: >> 2. The way the attribute is getting attached looks wrong; this is a >> union attribute, so it's required to appear immediately after the >> definition of the union. I suppose that's mostly orthogonal to this >> patch, though. > > What exactly do you mean by this? Something like the following: struct x {int x; int* y;}; typedef struct x a __attribute((transparent_union)); This isn't valid, but it looks like your patch accepts it. -Eli From mrs at apple.com Sat Jan 24 20:57:59 2009 From: mrs at apple.com (Mike Stump) Date: Sat, 24 Jan 2009 18:57:59 -0800 Subject: [cfe-dev] new warning Message-ID: <4A820770-0903-4349-816F-E5B2067EFEDC@apple.com> CodeGenTypes.cpp: In member function 'const llvm::Type* clang::CodeGen::CodeGenTypes::ConvertNewType(clang::QualType)': CodeGenTypes.cpp:176: warning: enumeration value 'MemberPointer' not handled in switch :-) From sebastian.redl at getdesigned.at Sun Jan 25 05:47:51 2009 From: sebastian.redl at getdesigned.at (Sebastian Redl) Date: Sun, 25 Jan 2009 12:47:51 +0100 Subject: [cfe-dev] new warning In-Reply-To: <4A820770-0903-4349-816F-E5B2067EFEDC@apple.com> References: <4A820770-0903-4349-816F-E5B2067EFEDC@apple.com> Message-ID: <497C5167.9050209@getdesigned.at> Mike Stump wrote: > CodeGenTypes.cpp: In member function 'const llvm::Type* > clang::CodeGen::CodeGenTypes::ConvertNewType(clang::QualType)': > CodeGenTypes.cpp:176: warning: enumeration value 'MemberPointer' not > handled in switch > So either someone who knows CodeGen teaches it to deal with member pointers, or I'll have to learn CodeGen. Sebastian From mrs at apple.com Sun Jan 25 10:54:52 2009 From: mrs at apple.com (Mike Stump) Date: Sun, 25 Jan 2009 08:54:52 -0800 Subject: [cfe-dev] new warning In-Reply-To: <497C5167.9050209@getdesigned.at> References: <4A820770-0903-4349-816F-E5B2067EFEDC@apple.com> <497C5167.9050209@getdesigned.at> Message-ID: <11B04AC7-C5A3-4C8B-BCC5-B9A6EBB36793@apple.com> On Jan 25, 2009, at 3:47 AM, Sebastian Redl wrote: > So either someone who knows CodeGen teaches it to deal with member > pointers, or I'll have to learn CodeGen. Oh, I'd just put it in the switch statement as a new case, and put a fixme, sorry style diagnostic on it for now. I'd rather have you make progress on the things you like to do, more progress that way. From catfish.man at gmail.com Sun Jan 25 17:35:17 2009 From: catfish.man at gmail.com (David Smith) Date: Sun, 25 Jan 2009 15:35:17 -0800 Subject: [cfe-dev] Success compiling Adium Message-ID: <5DF25ADB-7BDF-4081-8FFC-26CDB656B23F@gmail.com> I just successfully compiled and ran Adium for the first time using ccc. Thanks to everyone involved for the huge progress that's been made :) At the moment compile times are around 50% slower than GCC 4.2 for the whole project, but I haven't yet investigated why that is. The next thing I plan to try is compiling with precompiled headers disabled to see how much that changes the ratio. David Smith From snaroff at apple.com Sun Jan 25 17:44:19 2009 From: snaroff at apple.com (steve naroff) Date: Sun, 25 Jan 2009 18:44:19 -0500 Subject: [cfe-dev] Success compiling Adium In-Reply-To: <5DF25ADB-7BDF-4081-8FFC-26CDB656B23F@gmail.com> References: <5DF25ADB-7BDF-4081-8FFC-26CDB656B23F@gmail.com> Message-ID: On Jan 25, 2009, at 6:35 PM, David Smith wrote: > I just successfully compiled and ran Adium for the first time using > ccc. Thanks to everyone involved for the huge progress that's been > made :) At the moment compile times are around 50% slower than GCC 4.2 > for the whole project, but I haven't yet investigated why that is. The > next thing I plan to try is compiling with precompiled headers > disabled to see how much that changes the ratio. > Thanks for the update/info! Two things to verify... #1: Make sure you are running "Release" build of clang. #2: You might try using clang's recently added "token cache" feature. snaroff > David Smith > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From catfish.man at gmail.com Sun Jan 25 18:03:29 2009 From: catfish.man at gmail.com (David Smith) Date: Sun, 25 Jan 2009 16:03:29 -0800 Subject: [cfe-dev] Success compiling Adium In-Reply-To: References: <5DF25ADB-7BDF-4081-8FFC-26CDB656B23F@gmail.com> Message-ID: On Jan 25, 2009, at 3:44 PM, steve naroff wrote: > > On Jan 25, 2009, at 6:35 PM, David Smith wrote: > >> I just successfully compiled and ran Adium for the first time using >> ccc. Thanks to everyone involved for the huge progress that's been >> made :) At the moment compile times are around 50% slower than GCC >> 4.2 >> for the whole project, but I haven't yet investigated why that is. >> The >> next thing I plan to try is compiling with precompiled headers >> disabled to see how much that changes the ratio. >> > > Thanks for the update/info! > > Two things to verify... > > #1: Make sure you are running "Release" build of clang. > #2: You might try using clang's recently added "token cache" feature. > > snaroff I did make ENABLE_OPTIMIZED=1 when building llvm, then did: export PATH=/Volumes/Other/llvm/Release/bin/:$PATH export CCC=/Volumes/Other/llvm/tools/clang/tools/ccc/ccc time xcodebuild -parallelizeTargets CC=$CCC LD=$CCC So I believe that should be with a release build of clang. However, it didn't feel as much faster than the debug build I had as I would have expected, so I will double check that. How would I go about using the token cache? Looking at Tools.py, it seems to attempt to do some things with it automatically, but it's not completely clear to me that what I'm doing would be sufficient to trigger that. David From snaroff at apple.com Sun Jan 25 18:18:46 2009 From: snaroff at apple.com (steve naroff) Date: Sun, 25 Jan 2009 19:18:46 -0500 Subject: [cfe-dev] Success compiling Adium In-Reply-To: References: <5DF25ADB-7BDF-4081-8FFC-26CDB656B23F@gmail.com> Message-ID: On Jan 25, 2009, at 7:03 PM, David Smith wrote: > > On Jan 25, 2009, at 3:44 PM, steve naroff wrote: > >> >> On Jan 25, 2009, at 6:35 PM, David Smith wrote: >> >>> I just successfully compiled and ran Adium for the first time using >>> ccc. Thanks to everyone involved for the huge progress that's been >>> made :) At the moment compile times are around 50% slower than GCC >>> 4.2 >>> for the whole project, but I haven't yet investigated why that is. >>> The >>> next thing I plan to try is compiling with precompiled headers >>> disabled to see how much that changes the ratio. >>> >> >> Thanks for the update/info! >> >> Two things to verify... >> >> #1: Make sure you are running "Release" build of clang. >> #2: You might try using clang's recently added "token cache" feature. >> >> snaroff > > I did make ENABLE_OPTIMIZED=1 when building llvm, then did: > export PATH=/Volumes/Other/llvm/Release/bin/:$PATH > export CCC=/Volumes/Other/llvm/tools/clang/tools/ccc/ccc > time xcodebuild -parallelizeTargets CC=$CCC LD=$CCC > So I believe that should be with a release build of clang. However, > it didn't feel as much faster than the debug build I had as I would > have expected, so I will double check that. > It should feel much faster. If I recall, the release build is 5-10x faster than the debug build. > How would I go about using the token cache? Looking at Tools.py, it > seems to attempt to do some things with it automatically, but it's > not completely clear to me that what I'm doing would be sufficient > to trigger that. If your project is set up to use a pre-compiled prefix header (with GCC), then it should be straightforward. Here is an example using clang directly (I don't have any experience with using Tools.py): clang -x c-header PrefixHeader.h -o /tmp/PrefixHeader.pth clang -token-cache /tmp/PrefixHeader.pth SomeModule.m snaroff > > > David From kremenek at apple.com Sun Jan 25 19:53:37 2009 From: kremenek at apple.com (Ted Kremenek) Date: Sun, 25 Jan 2009 17:53:37 -0800 Subject: [cfe-dev] Success compiling Adium In-Reply-To: References: <5DF25ADB-7BDF-4081-8FFC-26CDB656B23F@gmail.com> Message-ID: <4D5FC50A-F0A4-4A1F-A923-F43686681642@apple.com> On Jan 25, 2009, at 4:18 PM, steve naroff wrote: >> >> I did make ENABLE_OPTIMIZED=1 when building llvm, then did: >> export PATH=/Volumes/Other/llvm/Release/bin/:$PATH >> export CCC=/Volumes/Other/llvm/tools/clang/tools/ccc/ccc >> time xcodebuild -parallelizeTargets CC=$CCC LD=$CCC >> So I believe that should be with a release build of clang. However, >> it didn't feel as much faster than the debug build I had as I would >> have expected, so I will double check that. >> > > It should feel much faster. If I recall, the release build is 5-10x > faster than the debug build. There are actually three kinds of builds: Debug, Release, Release- Asserts (which should be read as Release build without asserts). CCC probably grabs the clang binary from your path, so its worth checking that its grabbing the right binary. Debug builds go in llvm/Debug, Release builds in llvm/Release, etc. BTW, to perform a Release-Asserts build (which is the fastest build you'll get, and would be considered a production build), do: make ENABLE_OPTIMIZED=1 DISABLE_ASSERTIONS=1 From daniel at zuster.org Sun Jan 25 20:55:06 2009 From: daniel at zuster.org (Daniel Dunbar) Date: Sun, 25 Jan 2009 18:55:06 -0800 Subject: [cfe-dev] Success compiling Adium In-Reply-To: <5DF25ADB-7BDF-4081-8FFC-26CDB656B23F@gmail.com> References: <5DF25ADB-7BDF-4081-8FFC-26CDB656B23F@gmail.com> Message-ID: <6a8523d60901251855qd60fa88nc7ba973cd5d86258@mail.gmail.com> Hi David, That's great news! Just to confirm, but you did set CCC_CLANG right? As currently set up, the new ccc driver doesn't default to calling clang, and for now even with it it only calls clang on x86/32/Darwin! :) Otherwise, ccc should do that magic to invoke clang using PTH, assuming the Xcode project is already set up to use precompiled headers. This is a bit of a hack currently and is done in a way so that Xcode will always rebuild the full project, but assuming you are timing full builds this shouldn't impact that build time. ccc will search in a limited set of paths for the clang binary (most notably the directly that ccc itself is in). This does the right thing generally if you have done a make install and are using the installed ccc, but otherwise as Ted noted you may be running a clang from your path. If you set CCC_ECHO=1 during the build ccc will echo the command it is running and you can tell which clang it is using (if it doesn't have an absolute path, it is the one from the path). Note that ccc being written in Python *does* effect the build time quite a bit; if Adium consists of a large number of relatively small files then this could have a significant impact (although not 50%). Also, you can easily test compiling w/o PCH from the command line by passing GCC_PRECOMPILE_PREFIX_HEADER=NO to Xcode. - Daniel On Sun, Jan 25, 2009 at 3:35 PM, David Smith wrote: > I just successfully compiled and ran Adium for the first time using > ccc. Thanks to everyone involved for the huge progress that's been > made :) At the moment compile times are around 50% slower than GCC 4.2 > for the whole project, but I haven't yet investigated why that is. The > next thing I plan to try is compiling with precompiled headers > disabled to see how much that changes the ratio. > > David Smith > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > From catfish.man at gmail.com Mon Jan 26 02:21:40 2009 From: catfish.man at gmail.com (David Smith) Date: Mon, 26 Jan 2009 00:21:40 -0800 Subject: [cfe-dev] Success compiling Adium In-Reply-To: <6a8523d60901251855qd60fa88nc7ba973cd5d86258@mail.gmail.com> References: <5DF25ADB-7BDF-4081-8FFC-26CDB656B23F@gmail.com> <6a8523d60901251855qd60fa88nc7ba973cd5d86258@mail.gmail.com> Message-ID: On Jan 25, 2009, at 6:55 PM, Daniel Dunbar wrote: > Hi David, > > That's great news! Just to confirm, but you did set CCC_CLANG right? > As currently set up, the new ccc driver doesn't default to calling > clang, and for now even with it it only calls clang on x86/32/Darwin! > :) Heh, actually I wasn't aware of that flag. Sounds like perhaps my rejoicing was premature. I'll retry later and let you know how it goes. David From catfish.man at gmail.com Mon Jan 26 02:49:23 2009 From: catfish.man at gmail.com (David Smith) Date: Mon, 26 Jan 2009 00:49:23 -0800 Subject: [cfe-dev] Success compiling Adium In-Reply-To: <6a8523d60901251855qd60fa88nc7ba973cd5d86258@mail.gmail.com> References: <5DF25ADB-7BDF-4081-8FFC-26CDB656B23F@gmail.com> <6a8523d60901251855qd60fa88nc7ba973cd5d86258@mail.gmail.com> Message-ID: On Jan 25, 2009, at 6:55 PM, Daniel Dunbar wrote: > Hi David, > > That's great news! Just to confirm, but you did set CCC_CLANG right? > As currently set up, the new ccc driver doesn't default to calling > clang, and for now even with it it only calls clang on x86/32/Darwin! > :) I retried with that, and it definitely wasn't using clang previously. Sorry about that; still a ways to go after all. I'll see if I can pin down some of the specific issues I'm seeing and file bugs tomorrow for ones that don't already have them. David From dgregor at apple.com Mon Jan 26 09:56:39 2009 From: dgregor at apple.com (Douglas Gregor) Date: Mon, 26 Jan 2009 07:56:39 -0800 Subject: [cfe-dev] new warning In-Reply-To: <11B04AC7-C5A3-4C8B-BCC5-B9A6EBB36793@apple.com> References: <4A820770-0903-4349-816F-E5B2067EFEDC@apple.com> <497C5167.9050209@getdesigned.at> <11B04AC7-C5A3-4C8B-BCC5-B9A6EBB36793@apple.com> Message-ID: <97418D9D-C6F9-4B72-9DD0-1E31EE14F5FB@apple.com> On Jan 25, 2009, at 8:54 AM, Mike Stump wrote: > On Jan 25, 2009, at 3:47 AM, Sebastian Redl wrote: >> So either someone who knows CodeGen teaches it to deal with member >> pointers, or I'll have to learn CodeGen. > > Oh, I'd just put it in the switch statement as a new case, and put a > fixme, sorry style diagnostic on it for now. I'd rather have you make > progress on the things you like to do, more progress that way. Definitely. Plus, C++ codegen currently has so many holes in it that nobody could notice that member pointers are missing :) - Doug From alexei.svitkine at gmail.com Mon Jan 26 13:29:03 2009 From: alexei.svitkine at gmail.com (Alexei Svitkine) Date: Mon, 26 Jan 2009 14:29:03 -0500 Subject: [cfe-dev] [Patch] Make ParseAST() take ASTContext and TU params In-Reply-To: <62d9ffc00901241151u69da5620q87ae555ddb61c358@mail.gmail.com> References: <62d9ffc00901240802l312e8ek17de6d0f0b301995@mail.gmail.com> <497B3F97.8020908@getdesigned.at> <62d9ffc00901241151u69da5620q87ae555ddb61c358@mail.gmail.com> Message-ID: <62d9ffc00901261129m24b05955m5dd20255230d46ea@mail.gmail.com> Here's an updated patch that also removes the comment about the FreeMemory param which no longer exists. -Alexei On Sat, Jan 24, 2009 at 2:51 PM, Alexei Svitkine wrote: > You are right. Here's a revised patch. > > -Alexei > > On Sat, Jan 24, 2009 at 11:19 AM, Sebastian Redl > wrote: >> Alexei Svitkine wrote: >>> Hi, >>> >>> Attached is a patch to make ParseAST() take ASTContext and >>> TranslationUnit as parameters, as suggested by Steve Naroff. >>> >> >> The double negative in the code confuses me somewhat, but isn't this >> condition the wrong way round? >> >>> + if (!DisableFree) { >>> + Context = new ASTContext(PP.getLangOptions(), >>> PP.getSourceManager(), >>> + PP.getTargetInfo(), >>> + PP.getIdentifierTable(), >>> PP.getSelectorTable()); >>> + TU = new TranslationUnit(*Context); >>> + } >>> + ParseAST(PP, Consumer.get(), Context, TU, Stats); >> >> Previously, if DisableFree was true, FreeMemory was false, and ParseAST >> didn't free the objects. >> Now, if DisableFree is true, the driver doesn't allocate objects, so >> ParseAST does and will free them. >> >> Sebastian >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: ParseAST3.diff Type: application/octet-stream Size: 3569 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090126/a9541b4c/attachment.obj From skabet at gmail.com Mon Jan 26 13:45:13 2009 From: skabet at gmail.com (Anders Johnsen) Date: Mon, 26 Jan 2009 20:45:13 +0100 Subject: [cfe-dev] Fwd: Review of transparent_union patch In-Reply-To: References: <46C549EF-B1F1-46BB-A96F-FB11DD2CB5DE@apple.com> <5be2d90901231125h1deccc8cm302c8559974fbd14@mail.gmail.com> <5be2d90901231133x249f01eo42df50ac6d4697ff@mail.gmail.com> <5be2d90901231352y39b675aav744fc05bc4855e1f@mail.gmail.com> Message-ID: <5be2d90901261145q45e414c6r93c3823fd29c1cdb@mail.gmail.com> > Something like the following: > struct x {int x; int* y;}; > typedef struct x a __attribute((transparent_union)); > > This isn't valid, but it looks like your patch accepts it. I just tested this, and it looks like it worked: test/Sema/transparent-union-pointer.c:3:33: warning: 'transparent_union' attribute only applies to union types typedef struct x a __attribute((transparent_union)); ^ > > -Eli > Anders From eli.friedman at gmail.com Mon Jan 26 22:21:17 2009 From: eli.friedman at gmail.com (Eli Friedman) Date: Mon, 26 Jan 2009 20:21:17 -0800 Subject: [cfe-dev] Fwd: Review of transparent_union patch In-Reply-To: <5be2d90901261145q45e414c6r93c3823fd29c1cdb@mail.gmail.com> References: <46C549EF-B1F1-46BB-A96F-FB11DD2CB5DE@apple.com> <5be2d90901231125h1deccc8cm302c8559974fbd14@mail.gmail.com> <5be2d90901231133x249f01eo42df50ac6d4697ff@mail.gmail.com> <5be2d90901231352y39b675aav744fc05bc4855e1f@mail.gmail.com> <5be2d90901261145q45e414c6r93c3823fd29c1cdb@mail.gmail.com> Message-ID: On Mon, Jan 26, 2009 at 11:45 AM, Anders Johnsen wrote: >> Something like the following: >> struct x {int x; int* y;}; >> typedef struct x a __attribute((transparent_union)); >> >> This isn't valid, but it looks like your patch accepts it. > > I just tested this, and it looks like it worked: Oh, oops, make that "union x". -Eli From skabet at gmail.com Tue Jan 27 01:52:54 2009 From: skabet at gmail.com (Anders Johnsen) Date: Tue, 27 Jan 2009 08:52:54 +0100 Subject: [cfe-dev] Fwd: Review of transparent_union patch In-Reply-To: References: <46C549EF-B1F1-46BB-A96F-FB11DD2CB5DE@apple.com> <5be2d90901231125h1deccc8cm302c8559974fbd14@mail.gmail.com> <5be2d90901231133x249f01eo42df50ac6d4697ff@mail.gmail.com> <5be2d90901231352y39b675aav744fc05bc4855e1f@mail.gmail.com> <5be2d90901261145q45e414c6r93c3823fd29c1cdb@mail.gmail.com> Message-ID: <5be2d90901262352w16cec8eekb0e4357c5083af9@mail.gmail.com> On Tue, Jan 27, 2009 at 5:21 AM, Eli Friedman wrote: > On Mon, Jan 26, 2009 at 11:45 AM, Anders Johnsen wrote: >>> Something like the following: >>> struct x {int x; int* y;}; >>> typedef struct x a __attribute((transparent_union)); >>> >>> This isn't valid, but it looks like your patch accepts it. >> >> I just tested this, and it looks like it worked: > > Oh, oops, make that "union x". gcc does't complain. I'm not sure if i should do anything? Where have you read that it shouldn't allow such things? > > -Eli > Anders From eli.friedman at gmail.com Tue Jan 27 02:30:29 2009 From: eli.friedman at gmail.com (Eli Friedman) Date: Tue, 27 Jan 2009 00:30:29 -0800 Subject: [cfe-dev] Fwd: Review of transparent_union patch In-Reply-To: <5be2d90901262352w16cec8eekb0e4357c5083af9@mail.gmail.com> References: <46C549EF-B1F1-46BB-A96F-FB11DD2CB5DE@apple.com> <5be2d90901231125h1deccc8cm302c8559974fbd14@mail.gmail.com> <5be2d90901231133x249f01eo42df50ac6d4697ff@mail.gmail.com> <5be2d90901231352y39b675aav744fc05bc4855e1f@mail.gmail.com> <5be2d90901261145q45e414c6r93c3823fd29c1cdb@mail.gmail.com> <5be2d90901262352w16cec8eekb0e4357c5083af9@mail.gmail.com> Message-ID: On Mon, Jan 26, 2009 at 11:52 PM, Anders Johnsen wrote: > On Tue, Jan 27, 2009 at 5:21 AM, Eli Friedman wrote: >> On Mon, Jan 26, 2009 at 11:45 AM, Anders Johnsen wrote: >>>> Something like the following: >>>> struct x {int x; int* y;}; >>>> typedef struct x a __attribute((transparent_union)); >>>> >>>> This isn't valid, but it looks like your patch accepts it. >>> >>> I just tested this, and it looks like it worked: >> >> Oh, oops, make that "union x". > > gcc does't complain. I'm not sure if i should do anything? Where have > you read that it shouldn't allow such things? Hmm, I don't remember the details... if gcc accepts it, I suppose I must be mistaken. -Eli From eli.friedman at gmail.com Tue Jan 27 08:04:58 2009 From: eli.friedman at gmail.com (Eli Friedman) Date: Tue, 27 Jan 2009 06:04:58 -0800 Subject: [cfe-dev] Compiling gcc with clang Message-ID: So I figured it might be an interesting experiment to compile gcc with clang. Not surprisingly, there were a number of issues, but there's a positive result at the end. The first couple of issues I found were missing CodeGen for designators and incomplete CodeGen for VLAs; these were easy to work around in the gcc code because there were already alternate codepaths for compilers without C99 support. Next couple of issues were a couple issues with __extension__, which I fixed with r63100 and r63101. The next issue was a misdetection of the target, which leads to a funny compile error; this is probably a bug in ccc (the old version, not the new fancy version), but forcing the target is easy enough. The next issue was an instance of PR3307; I now have a patch in my tree, which I'll try to finish/commit soon. The next issue I ran into was a mysterious parse error; this one took me a while to figure out, but it turned out not to be a clang bug at all. Instead, it was an LLVM miscompilation of one of the build utilities; I filed PR3421 on that, and hacked the relevant generated file to work around it. The next issue I ran into is an instance of PR3341; I worked around that in the gcc code. The next issue is an issue I found with the way clang merges function declarations; I filed this as PR3425. And with all that done, I got a kind-of-working stage 1 gcc; it could compile simple programs, but the optimizers were completely broken. For the next step, I tried changing ccc (again, the old version) to add "-fast" to the llc command line. This gives significantly better results: the build process reaches the end of a three-stage optimized bootstrap with a few bootstrap comparison failures. Not perfect, but not bad. -Eli From makslane at hotmail.com Tue Jan 27 09:30:21 2009 From: makslane at hotmail.com (=?iso-8859-1?Q?Makslane_Ara=FAjo_Rodrigues?=) Date: Tue, 27 Jan 2009 18:30:21 +0300 Subject: [cfe-dev] clang, ccc, llvmc Message-ID: Can someone tell me the relationship between clang, ccc and llvmc? Thanks, Makslane _________________________________________________________________ Cansado de espa?o para s? 50 fotos? Conhe?a o Spaces, o site de relacionamentos com at? 6,000 fotos! http://www.amigosdomessenger.com.br -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090127/4c0cf18b/attachment.html From alexei.svitkine at gmail.com Tue Jan 27 09:31:57 2009 From: alexei.svitkine at gmail.com (Alexei Svitkine) Date: Tue, 27 Jan 2009 10:31:57 -0500 Subject: [cfe-dev] [Patch] Make ParseAST() take ASTContext and TU params In-Reply-To: <62d9ffc00901261129m24b05955m5dd20255230d46ea@mail.gmail.com> References: <62d9ffc00901240802l312e8ek17de6d0f0b301995@mail.gmail.com> <497B3F97.8020908@getdesigned.at> <62d9ffc00901241151u69da5620q87ae555ddb61c358@mail.gmail.com> <62d9ffc00901261129m24b05955m5dd20255230d46ea@mail.gmail.com> Message-ID: <62d9ffc00901270731l6a42728cv27ece2cbfbfe4149@mail.gmail.com> On Mon, Jan 26, 2009 at 2:29 PM, Alexei Svitkine wrote: > Here's an updated patch that also removes the comment about the > FreeMemory param which no longer exists. > > -Alexei > > On Sat, Jan 24, 2009 at 2:51 PM, Alexei Svitkine > wrote: >> You are right. Here's a revised patch. >> >> -Alexei >> >> On Sat, Jan 24, 2009 at 11:19 AM, Sebastian Redl >> wrote: >>> Alexei Svitkine wrote: >>>> Hi, >>>> >>>> Attached is a patch to make ParseAST() take ASTContext and >>>> TranslationUnit as parameters, as suggested by Steve Naroff. >>>> >>> >>> The double negative in the code confuses me somewhat, but isn't this >>> condition the wrong way round? >>> >>>> + if (!DisableFree) { >>>> + Context = new ASTContext(PP.getLangOptions(), >>>> PP.getSourceManager(), >>>> + PP.getTargetInfo(), >>>> + PP.getIdentifierTable(), >>>> PP.getSelectorTable()); >>>> + TU = new TranslationUnit(*Context); >>>> + } >>>> + ParseAST(PP, Consumer.get(), Context, TU, Stats); >>> >>> Previously, if DisableFree was true, FreeMemory was false, and ParseAST >>> didn't free the objects. >>> Now, if DisableFree is true, the driver doesn't allocate objects, so >>> ParseAST does and will free them. >>> >>> Sebastian >>> >> > From dgregor at apple.com Tue Jan 27 10:10:10 2009 From: dgregor at apple.com (Douglas Gregor) Date: Tue, 27 Jan 2009 08:10:10 -0800 Subject: [cfe-dev] Fwd: Review of transparent_union patch In-Reply-To: References: <46C549EF-B1F1-46BB-A96F-FB11DD2CB5DE@apple.com> <5be2d90901231125h1deccc8cm302c8559974fbd14@mail.gmail.com> <5be2d90901231133x249f01eo42df50ac6d4697ff@mail.gmail.com> <5be2d90901231352y39b675aav744fc05bc4855e1f@mail.gmail.com> <5be2d90901261145q45e414c6r93c3823fd29c1cdb@mail.gmail.com> <5be2d90901262352w16cec8eekb0e4357c5083af9@mail.gmail.com> Message-ID: On Jan 27, 2009, at 12:30 AM, Eli Friedman wrote: > On Mon, Jan 26, 2009 at 11:52 PM, Anders Johnsen > wrote: >> On Tue, Jan 27, 2009 at 5:21 AM, Eli Friedman >> wrote: >>> On Mon, Jan 26, 2009 at 11:45 AM, Anders Johnsen >>> wrote: >>>>> Something like the following: >>>>> struct x {int x; int* y;}; >>>>> typedef struct x a __attribute((transparent_union)); >>>>> >>>>> This isn't valid, but it looks like your patch accepts it. >>>> >>>> I just tested this, and it looks like it worked: >>> >>> Oh, oops, make that "union x". >> >> gcc does't complain. I'm not sure if i should do anything? Where have >> you read that it shouldn't allow such things? > > Hmm, I don't remember the details... if gcc accepts it, I suppose I > must be mistaken. GCC's attributes aren't handle consistently in the type system. Try this example: union x {int x; int* y;}; typedef union x a __attribute((transparent_union)); void foo(union x); void bar(a); void test(int i) { foo(i); // fails bar(i); // okay } So, a typedef of "union x" has different semantics from "union x", despite the fact that those types should be identical. The GCC guys know about these problems; see the discussion at http://gcc.gnu.org/ml/gcc/2006-10/msg00318.html I think that Clang should warn about the addition of "semantic" attributes (to steal Mark M.'s terminology) via typedefs, and say something about the typedef behaving differently from the original type due to the attribute. In C++ this is particularly important, since template instantiation needs to be based on the original type, even when one uses the typedef to name the instantiation (this is a particularly messy area in GCC). However, it seems to me that this patch is ready to go in. Any other issues we need to address first? - Doug From eli.friedman at gmail.com Tue Jan 27 12:47:57 2009 From: eli.friedman at gmail.com (Eli Friedman) Date: Tue, 27 Jan 2009 10:47:57 -0800 Subject: [cfe-dev] Compiling gcc with clang In-Reply-To: References: Message-ID: On Tue, Jan 27, 2009 at 6:04 AM, Eli Friedman wrote: > So I figured it might be an interesting experiment to compile gcc with > clang. Not surprisingly, there were a number of issues, but there's a > positive result at the end. And a slight update: turns out I had some changes in my LLVM tree that I hadn't considered which were causing PR3421 and the bootstrap comparison failures. Taking out those changes, it bootstraps flawlessly! -Eli From dgregor at apple.com Tue Jan 27 12:50:13 2009 From: dgregor at apple.com (Douglas Gregor) Date: Tue, 27 Jan 2009 10:50:13 -0800 Subject: [cfe-dev] Compiling gcc with clang In-Reply-To: References: Message-ID: <5D509D4F-F832-4C17-837A-75D11FF746DA@apple.com> On Jan 27, 2009, at 10:47 AM, Eli Friedman wrote: > On Tue, Jan 27, 2009 at 6:04 AM, Eli Friedman > wrote: >> So I figured it might be an interesting experiment to compile gcc >> with >> clang. Not surprisingly, there were a number of issues, but >> there's a >> positive result at the end. > > And a slight update: turns out I had some changes in my LLVM tree that > I hadn't considered which were causing PR3421 and the bootstrap > comparison failures. Taking out those changes, it bootstraps > flawlessly! Great! We still have some work to do for the other PRs, but this is good news indeed. - Doug From alexei.svitkine at gmail.com Tue Jan 27 13:49:22 2009 From: alexei.svitkine at gmail.com (Alexei Svitkine) Date: Tue, 27 Jan 2009 14:49:22 -0500 Subject: [cfe-dev] [Patch] Make ParseAST() take ASTContext and TU params In-Reply-To: <62d9ffc00901270731l6a42728cv27ece2cbfbfe4149@mail.gmail.com> References: <62d9ffc00901240802l312e8ek17de6d0f0b301995@mail.gmail.com> <497B3F97.8020908@getdesigned.at> <62d9ffc00901241151u69da5620q87ae555ddb61c358@mail.gmail.com> <62d9ffc00901261129m24b05955m5dd20255230d46ea@mail.gmail.com> <62d9ffc00901270731l6a42728cv27ece2cbfbfe4149@mail.gmail.com> Message-ID: <62d9ffc00901271149j76a35dffr5d9d504117ac4857@mail.gmail.com> If no one objects to these changes, can someone commit this to the repository? -Alexei On Tue, Jan 27, 2009 at 10:31 AM, Alexei Svitkine wrote: > On Mon, Jan 26, 2009 at 2:29 PM, Alexei Svitkine > wrote: >> Here's an updated patch that also removes the comment about the >> FreeMemory param which no longer exists. >> >> -Alexei >> >> On Sat, Jan 24, 2009 at 2:51 PM, Alexei Svitkine >> wrote: >>> You are right. Here's a revised patch. >>> >>> -Alexei >>> >>> On Sat, Jan 24, 2009 at 11:19 AM, Sebastian Redl >>> wrote: >>>> Alexei Svitkine wrote: >>>>> Hi, >>>>> >>>>> Attached is a patch to make ParseAST() take ASTContext and >>>>> TranslationUnit as parameters, as suggested by Steve Naroff. >>>>> >>>> >>>> The double negative in the code confuses me somewhat, but isn't this >>>> condition the wrong way round? >>>> >>>>> + if (!DisableFree) { >>>>> + Context = new ASTContext(PP.getLangOptions(), >>>>> PP.getSourceManager(), >>>>> + PP.getTargetInfo(), >>>>> + PP.getIdentifierTable(), >>>>> PP.getSelectorTable()); >>>>> + TU = new TranslationUnit(*Context); >>>>> + } >>>>> + ParseAST(PP, Consumer.get(), Context, TU, Stats); >>>> >>>> Previously, if DisableFree was true, FreeMemory was false, and ParseAST >>>> didn't free the objects. >>>> Now, if DisableFree is true, the driver doesn't allocate objects, so >>>> ParseAST does and will free them. >>>> >>>> Sebastian >>>> >>> >> > From kremenek at apple.com Tue Jan 27 16:44:53 2009 From: kremenek at apple.com (Ted Kremenek) Date: Tue, 27 Jan 2009 14:44:53 -0800 Subject: [cfe-dev] InitListExpr with void type Message-ID: Today I was running the latest build of the static analyzer over the Wine sources and noticed a crash in its handling of InitListExprs. I won't go into the gory details; essentially there are cases where an InitListExpr can have type 'void' and this is a case the analyzer does not (yet) handle. My question is whether or not it is valid for InitListExprs to have a 'void' type, and if so, how should they be interpreted? Here is an example (reduced test case from wine): struct _D3DMATRIX { union { float m[4][4]; }; }; typedef struct _D3DMATRIX D3DXMATRIX; int compare_matrix(const D3DXMATRIX *m1, const D3DXMATRIX *m2) { const D3DXMATRIX mat1 = { { { 1.0f, 2.0f, 3.0f, 4.0f, 5.0f, 6.0f, 7.0f, 8.0f, 9.0f, 10.0f, 11.0f, 12.0f, 13.0f, 14.0f, 15.0f, 16.0f } } }; } And the ast dump: (CompoundStmt 0x1d03ef0 (DeclStmt 0x1d03dc0 0x1d04880 "D3DXMATRIX const mat1 = (InitListExpr 0x1d04c60 'D3DXMATRIX const':'struct _D3DMATRIX const' (InitListExpr 0x1d04c30 'void' (InitListExpr 0x1d04bc0 'void' (FloatingLiteral 0x1d03d60 'float' 1.000000) (FloatingLiteral 0x1d03d90 'float' 2.000000) ... Notice that the two nested InitListExprs have a 'void' type. How are clients suppose to interpret this? Incidentally, clang generates a warning for the above (and the original) code: $ clang t.c t.c:5:5: warning: excess elements in array initializer { { 1.0f, 2.0f, 3.0f, 4.0f, ^~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 diagnostic generated. Is this correct behavior, or is there a bug in the ASTs? From kremenek at apple.com Tue Jan 27 17:06:32 2009 From: kremenek at apple.com (Ted Kremenek) Date: Tue, 27 Jan 2009 15:06:32 -0800 Subject: [cfe-dev] [Patch] Make ParseAST() take ASTContext and TU params In-Reply-To: <62d9ffc00901271149j76a35dffr5d9d504117ac4857@mail.gmail.com> References: <62d9ffc00901240802l312e8ek17de6d0f0b301995@mail.gmail.com> <497B3F97.8020908@getdesigned.at> <62d9ffc00901241151u69da5620q87ae555ddb61c358@mail.gmail.com> <62d9ffc00901261129m24b05955m5dd20255230d46ea@mail.gmail.com> <62d9ffc00901270731l6a42728cv27ece2cbfbfe4149@mail.gmail.com> <62d9ffc00901271149j76a35dffr5d9d504117ac4857@mail.gmail.com> Message-ID: <42841C5A-B311-4B1A-AB1C-F6B37CF99998@apple.com> Hi Alex, Sorry for not looking at this sooner. The patch looks good, but I have two additional nits. First, could you possibly add a comment to the prototype and definition of ParseAST indicating what is the behavior of TranslationUnit and ASTContext are null? The postcondition for this situation is that once ParseAST completes then any subsequent accesses to the ASTs it provided is no longer valid (because they are reclaimed). This should be explicitly stated, since the ASTConsumer (which lives beyond the call to ParseAST) could potentially have dangling references to the ASTs. Second, does it make sense to pass in both a TranslationUnit and an ASTContext pointer? Since TranslationUnit holds a reference to ASTContext, I think we only need a single argument. If the TranslationUnit* is null then the ASTContext* is null as well. Ted On Jan 27, 2009, at 11:49 AM, Alexei Svitkine wrote: > If no one objects to these changes, can someone commit this to the > repository? > > -Alexei > > On Tue, Jan 27, 2009 at 10:31 AM, Alexei Svitkine > wrote: >> On Mon, Jan 26, 2009 at 2:29 PM, Alexei Svitkine >> wrote: >>> Here's an updated patch that also removes the comment about the >>> FreeMemory param which no longer exists. >>> >>> -Alexei >>> >>> On Sat, Jan 24, 2009 at 2:51 PM, Alexei Svitkine >>> wrote: >>>> You are right. Here's a revised patch. >>>> >>>> -Alexei >>>> >>>> On Sat, Jan 24, 2009 at 11:19 AM, Sebastian Redl >>>> wrote: >>>>> Alexei Svitkine wrote: >>>>>> Hi, >>>>>> >>>>>> Attached is a patch to make ParseAST() take ASTContext and >>>>>> TranslationUnit as parameters, as suggested by Steve Naroff. >>>>>> >>>>> >>>>> The double negative in the code confuses me somewhat, but isn't >>>>> this >>>>> condition the wrong way round? >>>>> >>>>>> + if (!DisableFree) { >>>>>> + Context = new ASTContext(PP.getLangOptions(), >>>>>> PP.getSourceManager(), >>>>>> + PP.getTargetInfo(), >>>>>> + PP.getIdentifierTable(), >>>>>> PP.getSelectorTable()); >>>>>> + TU = new TranslationUnit(*Context); >>>>>> + } >>>>>> + ParseAST(PP, Consumer.get(), Context, TU, Stats); >>>>> >>>>> Previously, if DisableFree was true, FreeMemory was false, and >>>>> ParseAST >>>>> didn't free the objects. >>>>> Now, if DisableFree is true, the driver doesn't allocate >>>>> objects, so >>>>> ParseAST does and will free them. >>>>> >>>>> Sebastian >>>>> >>>> >>> >> > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From sebastian.redl at getdesigned.at Tue Jan 27 17:06:38 2009 From: sebastian.redl at getdesigned.at (Sebastian Redl) Date: Wed, 28 Jan 2009 00:06:38 +0100 Subject: [cfe-dev] InitListExpr with void type In-Reply-To: References: Message-ID: <497F937E.8000204@getdesigned.at> Ted Kremenek wrote: > Today I was running the latest build of the static analyzer over the > Wine sources and noticed a crash in its handling of InitListExprs. I > won't go into the gory details; essentially there are cases where an > InitListExpr can have type 'void' and this is a case the analyzer does > not (yet) handle. > > My question is whether or not it is valid for InitListExprs to have a > 'void' type, and if so, how should they be interpreted? > I'm pretty sure InitListExprs pretty much *always* have void type, due to these lines in Sema::ActOnInitList: > InitListExpr *E = new (Context) InitListExpr(LBraceLoc, InitList, > NumInit, > RBraceLoc, > Designators.hasAnyDesignators()); > E->setType(Context.VoidTy); // FIXME: just a place holder for now. Sebastian From dgregor at apple.com Tue Jan 27 17:14:46 2009 From: dgregor at apple.com (Douglas Gregor) Date: Tue, 27 Jan 2009 15:14:46 -0800 Subject: [cfe-dev] InitListExpr with void type In-Reply-To: References: Message-ID: On Jan 27, 2009, at 2:44 PM, Ted Kremenek wrote: > Today I was running the latest build of the static analyzer over the > Wine sources and noticed a crash in its handling of InitListExprs. I > won't go into the gory details; essentially there are cases where an > InitListExpr can have type 'void' and this is a case the analyzer does > not (yet) handle. Blech. > My question is whether or not it is valid for InitListExprs to have a > 'void' type, and if so, how should they be interpreted? IMO, it isn't valid. After semantic analysis of the initializer list, all InitListExprs should have the type of the object they initialize. If the InitListExpr still has void type, then either (1) it's an invalid AST node and we shouldn't be looking at it, or (2) there's a bug in semantic analysis of initializer lists. > Here is an example (reduced test case from wine): > > struct _D3DMATRIX { union { float m[4][4]; }; }; > typedef struct _D3DMATRIX D3DXMATRIX; > int compare_matrix(const D3DXMATRIX *m1, const D3DXMATRIX *m2) { > const D3DXMATRIX mat1 = { > { { 1.0f, 2.0f, 3.0f, 4.0f, > 5.0f, 6.0f, 7.0f, 8.0f, > 9.0f, 10.0f, 11.0f, 12.0f, > 13.0f, 14.0f, 15.0f, 16.0f } } > }; > } Oh, fun. The initialization code doesn't handle anonymous unions properly (it skips them). > And the ast dump: > > (CompoundStmt 0x1d03ef0 > (DeclStmt 0x1d03dc0 > 0x1d04880 "D3DXMATRIX const mat1 = > (InitListExpr 0x1d04c60 'D3DXMATRIX > const':'struct _D3DMATRIX const' > (InitListExpr 0x1d04c30 'void' > (InitListExpr 0x1d04bc0 'void' > (FloatingLiteral 0x1d03d60 'float' 1.000000) > (FloatingLiteral 0x1d03d90 'float' 2.000000) > ... > > Notice that the two nested InitListExprs have a 'void' type. How are > clients suppose to interpret this? They shouldn't have to. > Incidentally, clang generates a warning for the above (and the > original) code: > > $ clang t.c > t.c:5:5: warning: excess elements in array initializer > { { 1.0f, 2.0f, 3.0f, 4.0f, > ^~~~~~~~~~~~~~~~~~~~~~~~~~~ > 1 diagnostic generated. That warning is bogus, and it shows that we're handling this initializer list improperly. I'm tackling the initializer-list stuff as part of CodeGen for designated initializers, and this example is (now) working in my local tree. If you've filed a bug, feel free to kick it over to me to get the InitListExpr types straightened out as part of this work. - Doug From kremenek at apple.com Tue Jan 27 17:22:25 2009 From: kremenek at apple.com (Ted Kremenek) Date: Tue, 27 Jan 2009 15:22:25 -0800 Subject: [cfe-dev] [Patch] Make ParseAST() take ASTContext and TU params In-Reply-To: <42841C5A-B311-4B1A-AB1C-F6B37CF99998@apple.com> References: <62d9ffc00901240802l312e8ek17de6d0f0b301995@mail.gmail.com> <497B3F97.8020908@getdesigned.at> <62d9ffc00901241151u69da5620q87ae555ddb61c358@mail.gmail.com> <62d9ffc00901261129m24b05955m5dd20255230d46ea@mail.gmail.com> <62d9ffc00901270731l6a42728cv27ece2cbfbfe4149@mail.gmail.com> <62d9ffc00901271149j76a35dffr5d9d504117ac4857@mail.gmail.com> <42841C5A-B311-4B1A-AB1C-F6B37CF99998@apple.com> Message-ID: <218EE9BA-B005-4840-B223-D182A7C60F46@apple.com> Hi Alexei, I apologize, I left the "ei" off your name. On Jan 27, 2009, at 3:06 PM, Ted Kremenek wrote: > Hi Alex, > > Sorry for not looking at this sooner. The patch looks good, but I > have two additional nits. > > First, could you possibly add a comment to the prototype and > definition of ParseAST indicating what is the behavior of > TranslationUnit and ASTContext are null? The postcondition for this > situation is that once ParseAST completes then any subsequent accesses > to the ASTs it provided is no longer valid (because they are > reclaimed). This should be explicitly stated, since the ASTConsumer > (which lives beyond the call to ParseAST) could potentially have > dangling references to the ASTs. > > Second, does it make sense to pass in both a TranslationUnit and an > ASTContext pointer? Since TranslationUnit holds a reference to > ASTContext, I think we only need a single argument. If the > TranslationUnit* is null then the ASTContext* is null as well. > > Ted > > On Jan 27, 2009, at 11:49 AM, Alexei Svitkine wrote: > >> If no one objects to these changes, can someone commit this to the >> repository? >> >> -Alexei >> >> On Tue, Jan 27, 2009 at 10:31 AM, Alexei Svitkine >> wrote: >>> On Mon, Jan 26, 2009 at 2:29 PM, Alexei Svitkine >>> wrote: >>>> Here's an updated patch that also removes the comment about the >>>> FreeMemory param which no longer exists. >>>> >>>> -Alexei >>>> >>>> On Sat, Jan 24, 2009 at 2:51 PM, Alexei Svitkine >>>> wrote: >>>>> You are right. Here's a revised patch. >>>>> >>>>> -Alexei >>>>> >>>>> On Sat, Jan 24, 2009 at 11:19 AM, Sebastian Redl >>>>> wrote: >>>>>> Alexei Svitkine wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Attached is a patch to make ParseAST() take ASTContext and >>>>>>> TranslationUnit as parameters, as suggested by Steve Naroff. >>>>>>> >>>>>> >>>>>> The double negative in the code confuses me somewhat, but isn't >>>>>> this >>>>>> condition the wrong way round? >>>>>> >>>>>>> + if (!DisableFree) { >>>>>>> + Context = new ASTContext(PP.getLangOptions(), >>>>>>> PP.getSourceManager(), >>>>>>> + PP.getTargetInfo(), >>>>>>> + PP.getIdentifierTable(), >>>>>>> PP.getSelectorTable()); >>>>>>> + TU = new TranslationUnit(*Context); >>>>>>> + } >>>>>>> + ParseAST(PP, Consumer.get(), Context, TU, Stats); >>>>>> >>>>>> Previously, if DisableFree was true, FreeMemory was false, and >>>>>> ParseAST >>>>>> didn't free the objects. >>>>>> Now, if DisableFree is true, the driver doesn't allocate >>>>>> objects, so >>>>>> ParseAST does and will free them. >>>>>> >>>>>> Sebastian >>>>>> >>>>> >>>> >>> >> _______________________________________________ >> 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 kremenek at apple.com Tue Jan 27 17:24:03 2009 From: kremenek at apple.com (Ted Kremenek) Date: Tue, 27 Jan 2009 15:24:03 -0800 Subject: [cfe-dev] InitListExpr with void type In-Reply-To: References: Message-ID: On Jan 27, 2009, at 3:14 PM, Douglas Gregor wrote: >> >> Incidentally, clang generates a warning for the above (and the >> original) code: >> >> $ clang t.c >> t.c:5:5: warning: excess elements in array initializer >> { { 1.0f, 2.0f, 3.0f, 4.0f, >> ^~~~~~~~~~~~~~~~~~~~~~~~~~~ >> 1 diagnostic generated. > > That warning is bogus, and it shows that we're handling this > initializer list improperly. > > I'm tackling the initializer-list stuff as part of CodeGen for > designated initializers, and this example is (now) working in my > local tree. If you've filed a bug, feel free to kick it over to me > to get the InitListExpr types straightened out as part of this work. > > - Doug Thanks Doug. I haven't filed a bug yet. I would be more than happy to if that helps anyone. From kremenek at apple.com Tue Jan 27 17:26:44 2009 From: kremenek at apple.com (Ted Kremenek) Date: Tue, 27 Jan 2009 15:26:44 -0800 Subject: [cfe-dev] InitListExpr with void type In-Reply-To: References: Message-ID: On Jan 27, 2009, at 3:14 PM, Douglas Gregor wrote: > On Jan 27, 2009, at 2:44 PM, Ted Kremenek wrote: >> Today I was running the latest build of the static analyzer over the >> Wine sources and noticed a crash in its handling of InitListExprs. I >> won't go into the gory details; essentially there are cases where an >> InitListExpr can have type 'void' and this is a case the analyzer >> does >> not (yet) handle. > > Blech. > >> My question is whether or not it is valid for InitListExprs to have a >> 'void' type, and if so, how should they be interpreted? > > IMO, it isn't valid. After semantic analysis of the initializer > list, all InitListExprs should have the type of the object they > initialize. If the InitListExpr still has void type, then either (1) > it's an invalid AST node and we shouldn't be looking at it, or (2) > there's a bug in semantic analysis of initializer lists. That's what I thought. If it an invalid AST node, should we just reject the file? If we don't build the InitListExpr correctly because of [insert some feature not implemented yet] it seems that we should just abort with a fail-stop error in Sema rather than having unpredictable behavior in clients that assume the ASTs are kosher. From dgregor at apple.com Tue Jan 27 17:32:03 2009 From: dgregor at apple.com (Douglas Gregor) Date: Tue, 27 Jan 2009 15:32:03 -0800 Subject: [cfe-dev] InitListExpr with void type In-Reply-To: References: Message-ID: <2937064F-D585-4396-8019-2D80EACAC1A1@apple.com> On Jan 27, 2009, at 3:26 PM, Ted Kremenek wrote: > > On Jan 27, 2009, at 3:14 PM, Douglas Gregor wrote: > >> On Jan 27, 2009, at 2:44 PM, Ted Kremenek wrote: >>> Today I was running the latest build of the static analyzer over the >>> Wine sources and noticed a crash in its handling of >>> InitListExprs. I >>> won't go into the gory details; essentially there are cases where an >>> InitListExpr can have type 'void' and this is a case the analyzer >>> does >>> not (yet) handle. >> >> Blech. >> >>> My question is whether or not it is valid for InitListExprs to >>> have a >>> 'void' type, and if so, how should they be interpreted? >> >> IMO, it isn't valid. After semantic analysis of the initializer >> list, all InitListExprs should have the type of the object they >> initialize. If the InitListExpr still has void type, then either >> (1) it's an invalid AST node and we shouldn't be looking at it, or >> (2) there's a bug in semantic analysis of initializer lists. > > That's what I thought. If it an invalid AST node, should we just > reject the file? Yes. We should error and then not link the invalid AST node into the AST produced. > If we don't build the InitListExpr correctly because of [insert > some feature not implemented yet] it seems that we should just abort > with a fail-stop error in Sema rather than having unpredictable > behavior in clients that assume the ASTs are kosher. In this case, our misinterpretation of the initializer resulted in a warning, not a hard error, so it thought the AST was valid. The real issue is that we need an assert that says: after we've processed the initializer list, we either had an error or our InitListExpr type is not void. No path should sneak through the semantic analysis without setting the type or reporting an error. - Doug From alexei.svitkine at gmail.com Tue Jan 27 17:32:51 2009 From: alexei.svitkine at gmail.com (Alexei Svitkine) Date: Tue, 27 Jan 2009 18:32:51 -0500 Subject: [cfe-dev] [Patch] Make ParseAST() take ASTContext and TU params In-Reply-To: <218EE9BA-B005-4840-B223-D182A7C60F46@apple.com> References: <62d9ffc00901240802l312e8ek17de6d0f0b301995@mail.gmail.com> <497B3F97.8020908@getdesigned.at> <62d9ffc00901241151u69da5620q87ae555ddb61c358@mail.gmail.com> <62d9ffc00901261129m24b05955m5dd20255230d46ea@mail.gmail.com> <62d9ffc00901270731l6a42728cv27ece2cbfbfe4149@mail.gmail.com> <62d9ffc00901271149j76a35dffr5d9d504117ac4857@mail.gmail.com> <42841C5A-B311-4B1A-AB1C-F6B37CF99998@apple.com> <218EE9BA-B005-4840-B223-D182A7C60F46@apple.com> Message-ID: <62d9ffc00901271532g720e652fkaaec8b0f711417d7@mail.gmail.com> Thanks for the comments! Here's a revised patch. -Alexei On Tue, Jan 27, 2009 at 6:22 PM, Ted Kremenek wrote: > Hi Alexei, > > I apologize, I left the "ei" off your name. > > On Jan 27, 2009, at 3:06 PM, Ted Kremenek wrote: > >> Hi Alex, >> >> Sorry for not looking at this sooner. The patch looks good, but I >> have two additional nits. >> >> First, could you possibly add a comment to the prototype and >> definition of ParseAST indicating what is the behavior of >> TranslationUnit and ASTContext are null? The postcondition for this >> situation is that once ParseAST completes then any subsequent accesses >> to the ASTs it provided is no longer valid (because they are >> reclaimed). This should be explicitly stated, since the ASTConsumer >> (which lives beyond the call to ParseAST) could potentially have >> dangling references to the ASTs. >> >> Second, does it make sense to pass in both a TranslationUnit and an >> ASTContext pointer? Since TranslationUnit holds a reference to >> ASTContext, I think we only need a single argument. If the >> TranslationUnit* is null then the ASTContext* is null as well. >> >> Ted >> >> On Jan 27, 2009, at 11:49 AM, Alexei Svitkine wrote: >> >>> If no one objects to these changes, can someone commit this to the >>> repository? >>> >>> -Alexei >>> >>> On Tue, Jan 27, 2009 at 10:31 AM, Alexei Svitkine >>> wrote: >>>> >>>> On Mon, Jan 26, 2009 at 2:29 PM, Alexei Svitkine >>>> wrote: >>>>> >>>>> Here's an updated patch that also removes the comment about the >>>>> FreeMemory param which no longer exists. >>>>> >>>>> -Alexei >>>>> >>>>> On Sat, Jan 24, 2009 at 2:51 PM, Alexei Svitkine >>>>> wrote: >>>>>> >>>>>> You are right. Here's a revised patch. >>>>>> >>>>>> -Alexei >>>>>> >>>>>> On Sat, Jan 24, 2009 at 11:19 AM, Sebastian Redl >>>>>> wrote: >>>>>>> >>>>>>> Alexei Svitkine wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Attached is a patch to make ParseAST() take ASTContext and >>>>>>>> TranslationUnit as parameters, as suggested by Steve Naroff. >>>>>>>> >>>>>>> >>>>>>> The double negative in the code confuses me somewhat, but isn't >>>>>>> this >>>>>>> condition the wrong way round? >>>>>>> >>>>>>>> + if (!DisableFree) { >>>>>>>> + Context = new ASTContext(PP.getLangOptions(), >>>>>>>> PP.getSourceManager(), >>>>>>>> + PP.getTargetInfo(), >>>>>>>> + PP.getIdentifierTable(), >>>>>>>> PP.getSelectorTable()); >>>>>>>> + TU = new TranslationUnit(*Context); >>>>>>>> + } >>>>>>>> + ParseAST(PP, Consumer.get(), Context, TU, Stats); >>>>>>> >>>>>>> Previously, if DisableFree was true, FreeMemory was false, and >>>>>>> ParseAST >>>>>>> didn't free the objects. >>>>>>> Now, if DisableFree is true, the driver doesn't allocate >>>>>>> objects, so >>>>>>> ParseAST does and will free them. >>>>>>> >>>>>>> Sebastian >>>>>>> >>>>>> >>>>> >>>> >>> _______________________________________________ >>> 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 -------------- A non-text attachment was scrubbed... Name: ParseAST4.diff Type: application/octet-stream Size: 4530 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090127/eb4a0523/attachment.obj From alexei.svitkine at gmail.com Tue Jan 27 17:35:06 2009 From: alexei.svitkine at gmail.com (Alexei Svitkine) Date: Tue, 27 Jan 2009 18:35:06 -0500 Subject: [cfe-dev] [Patch] Make ParseAST() take ASTContext and TU params In-Reply-To: <62d9ffc00901271532g720e652fkaaec8b0f711417d7@mail.gmail.com> References: <62d9ffc00901240802l312e8ek17de6d0f0b301995@mail.gmail.com> <497B3F97.8020908@getdesigned.at> <62d9ffc00901241151u69da5620q87ae555ddb61c358@mail.gmail.com> <62d9ffc00901261129m24b05955m5dd20255230d46ea@mail.gmail.com> <62d9ffc00901270731l6a42728cv27ece2cbfbfe4149@mail.gmail.com> <62d9ffc00901271149j76a35dffr5d9d504117ac4857@mail.gmail.com> <42841C5A-B311-4B1A-AB1C-F6B37CF99998@apple.com> <218EE9BA-B005-4840-B223-D182A7C60F46@apple.com> <62d9ffc00901271532g720e652fkaaec8b0f711417d7@mail.gmail.com> Message-ID: <62d9ffc00901271535k206be7b4q5a155b7cb42355ef@mail.gmail.com> Oops some tabs made it into the previous one. Here's the same thing with correct whitespace. -Alexei On Tue, Jan 27, 2009 at 6:32 PM, Alexei Svitkine wrote: > Thanks for the comments! > > Here's a revised patch. > > -Alexei > > On Tue, Jan 27, 2009 at 6:22 PM, Ted Kremenek wrote: >> Hi Alexei, >> >> I apologize, I left the "ei" off your name. >> >> On Jan 27, 2009, at 3:06 PM, Ted Kremenek wrote: >> >>> Hi Alex, >>> >>> Sorry for not looking at this sooner. The patch looks good, but I >>> have two additional nits. >>> >>> First, could you possibly add a comment to the prototype and >>> definition of ParseAST indicating what is the behavior of >>> TranslationUnit and ASTContext are null? The postcondition for this >>> situation is that once ParseAST completes then any subsequent accesses >>> to the ASTs it provided is no longer valid (because they are >>> reclaimed). This should be explicitly stated, since the ASTConsumer >>> (which lives beyond the call to ParseAST) could potentially have >>> dangling references to the ASTs. >>> >>> Second, does it make sense to pass in both a TranslationUnit and an >>> ASTContext pointer? Since TranslationUnit holds a reference to >>> ASTContext, I think we only need a single argument. If the >>> TranslationUnit* is null then the ASTContext* is null as well. >>> >>> Ted >>> >>> On Jan 27, 2009, at 11:49 AM, Alexei Svitkine wrote: >>> >>>> If no one objects to these changes, can someone commit this to the >>>> repository? >>>> >>>> -Alexei >>>> >>>> On Tue, Jan 27, 2009 at 10:31 AM, Alexei Svitkine >>>> wrote: >>>>> >>>>> On Mon, Jan 26, 2009 at 2:29 PM, Alexei Svitkine >>>>> wrote: >>>>>> >>>>>> Here's an updated patch that also removes the comment about the >>>>>> FreeMemory param which no longer exists. >>>>>> >>>>>> -Alexei >>>>>> >>>>>> On Sat, Jan 24, 2009 at 2:51 PM, Alexei Svitkine >>>>>> wrote: >>>>>>> >>>>>>> You are right. Here's a revised patch. >>>>>>> >>>>>>> -Alexei >>>>>>> >>>>>>> On Sat, Jan 24, 2009 at 11:19 AM, Sebastian Redl >>>>>>> wrote: >>>>>>>> >>>>>>>> Alexei Svitkine wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Attached is a patch to make ParseAST() take ASTContext and >>>>>>>>> TranslationUnit as parameters, as suggested by Steve Naroff. >>>>>>>>> >>>>>>>> >>>>>>>> The double negative in the code confuses me somewhat, but isn't >>>>>>>> this >>>>>>>> condition the wrong way round? >>>>>>>> >>>>>>>>> + if (!DisableFree) { >>>>>>>>> + Context = new ASTContext(PP.getLangOptions(), >>>>>>>>> PP.getSourceManager(), >>>>>>>>> + PP.getTargetInfo(), >>>>>>>>> + PP.getIdentifierTable(), >>>>>>>>> PP.getSelectorTable()); >>>>>>>>> + TU = new TranslationUnit(*Context); >>>>>>>>> + } >>>>>>>>> + ParseAST(PP, Consumer.get(), Context, TU, Stats); >>>>>>>> >>>>>>>> Previously, if DisableFree was true, FreeMemory was false, and >>>>>>>> ParseAST >>>>>>>> didn't free the objects. >>>>>>>> Now, if DisableFree is true, the driver doesn't allocate >>>>>>>> objects, so >>>>>>>> ParseAST does and will free them. >>>>>>>> >>>>>>>> Sebastian >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> _______________________________________________ >>>> 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 -------------- A non-text attachment was scrubbed... Name: ParseAST5.diff Type: application/octet-stream Size: 4527 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090127/d18ccc56/attachment-0001.obj From kremenek at apple.com Tue Jan 27 17:42:34 2009 From: kremenek at apple.com (Ted Kremenek) Date: Tue, 27 Jan 2009 15:42:34 -0800 Subject: [cfe-dev] [Patch] Make ParseAST() take ASTContext and TU params In-Reply-To: <62d9ffc00901271535k206be7b4q5a155b7cb42355ef@mail.gmail.com> References: <62d9ffc00901240802l312e8ek17de6d0f0b301995@mail.gmail.com> <497B3F97.8020908@getdesigned.at> <62d9ffc00901241151u69da5620q87ae555ddb61c358@mail.gmail.com> <62d9ffc00901261129m24b05955m5dd20255230d46ea@mail.gmail.com> <62d9ffc00901270731l6a42728cv27ece2cbfbfe4149@mail.gmail.com> <62d9ffc00901271149j76a35dffr5d9d504117ac4857@mail.gmail.com> <42841C5A-B311-4B1A-AB1C-F6B37CF99998@apple.com> <218EE9BA-B005-4840-B223-D182A7C60F46@apple.com> <62d9ffc00901271532g720e652fkaaec8b0f711417d7@mail.gmail.com> <62d9ffc00901271535k206be7b4q5a155b7cb42355ef@mail.gmail.com> Message-ID: <429FB7C0-B7EC-4CB6-A207-5D5DDECDBE97@apple.com> Hi Alexei, Looks great! I'm actually having difficulty applying the patch. Did you generate it against top-of-tree clang? Ted On Jan 27, 2009, at 3:35 PM, Alexei Svitkine wrote: > Oops some tabs made it into the previous one. > > Here's the same thing with correct whitespace. > > -Alexei > > On Tue, Jan 27, 2009 at 6:32 PM, Alexei Svitkine > wrote: >> Thanks for the comments! >> >> Here's a revised patch. >> >> -Alexei >> >> On Tue, Jan 27, 2009 at 6:22 PM, Ted Kremenek >> wrote: >>> Hi Alexei, >>> >>> I apologize, I left the "ei" off your name. >>> >>> On Jan 27, 2009, at 3:06 PM, Ted Kremenek wrote: >>> >>>> Hi Alex, >>>> >>>> Sorry for not looking at this sooner. The patch looks good, but I >>>> have two additional nits. >>>> >>>> First, could you possibly add a comment to the prototype and >>>> definition of ParseAST indicating what is the behavior of >>>> TranslationUnit and ASTContext are null? The postcondition for >>>> this >>>> situation is that once ParseAST completes then any subsequent >>>> accesses >>>> to the ASTs it provided is no longer valid (because they are >>>> reclaimed). This should be explicitly stated, since the >>>> ASTConsumer >>>> (which lives beyond the call to ParseAST) could potentially have >>>> dangling references to the ASTs. >>>> >>>> Second, does it make sense to pass in both a TranslationUnit and an >>>> ASTContext pointer? Since TranslationUnit holds a reference to >>>> ASTContext, I think we only need a single argument. If the >>>> TranslationUnit* is null then the ASTContext* is null as well. >>>> >>>> Ted >>>> >>>> On Jan 27, 2009, at 11:49 AM, Alexei Svitkine wrote: >>>> >>>>> If no one objects to these changes, can someone commit this to the >>>>> repository? >>>>> >>>>> -Alexei >>>>> >>>>> On Tue, Jan 27, 2009 at 10:31 AM, Alexei Svitkine >>>>> wrote: >>>>>> >>>>>> On Mon, Jan 26, 2009 at 2:29 PM, Alexei Svitkine >>>>>> wrote: >>>>>>> >>>>>>> Here's an updated patch that also removes the comment about the >>>>>>> FreeMemory param which no longer exists. >>>>>>> >>>>>>> -Alexei >>>>>>> >>>>>>> On Sat, Jan 24, 2009 at 2:51 PM, Alexei Svitkine >>>>>>> wrote: >>>>>>>> >>>>>>>> You are right. Here's a revised patch. >>>>>>>> >>>>>>>> -Alexei >>>>>>>> >>>>>>>> On Sat, Jan 24, 2009 at 11:19 AM, Sebastian Redl >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Alexei Svitkine wrote: >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Attached is a patch to make ParseAST() take ASTContext and >>>>>>>>>> TranslationUnit as parameters, as suggested by Steve Naroff. >>>>>>>>>> >>>>>>>>> >>>>>>>>> The double negative in the code confuses me somewhat, but >>>>>>>>> isn't >>>>>>>>> this >>>>>>>>> condition the wrong way round? >>>>>>>>> >>>>>>>>>> + if (!DisableFree) { >>>>>>>>>> + Context = new ASTContext(PP.getLangOptions(), >>>>>>>>>> PP.getSourceManager(), >>>>>>>>>> + PP.getTargetInfo(), >>>>>>>>>> + PP.getIdentifierTable(), >>>>>>>>>> PP.getSelectorTable()); >>>>>>>>>> + TU = new TranslationUnit(*Context); >>>>>>>>>> + } >>>>>>>>>> + ParseAST(PP, Consumer.get(), Context, TU, Stats); >>>>>>>>> >>>>>>>>> Previously, if DisableFree was true, FreeMemory was false, and >>>>>>>>> ParseAST >>>>>>>>> didn't free the objects. >>>>>>>>> Now, if DisableFree is true, the driver doesn't allocate >>>>>>>>> objects, so >>>>>>>>> ParseAST does and will free them. >>>>>>>>> >>>>>>>>> Sebastian >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> _______________________________________________ >>>>> 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 alexei.svitkine at gmail.com Tue Jan 27 17:51:41 2009 From: alexei.svitkine at gmail.com (Alexei Svitkine) Date: Tue, 27 Jan 2009 18:51:41 -0500 Subject: [cfe-dev] [Patch] Make ParseAST() take ASTContext and TU params In-Reply-To: <429FB7C0-B7EC-4CB6-A207-5D5DDECDBE97@apple.com> References: <62d9ffc00901240802l312e8ek17de6d0f0b301995@mail.gmail.com> <62d9ffc00901241151u69da5620q87ae555ddb61c358@mail.gmail.com> <62d9ffc00901261129m24b05955m5dd20255230d46ea@mail.gmail.com> <62d9ffc00901270731l6a42728cv27ece2cbfbfe4149@mail.gmail.com> <62d9ffc00901271149j76a35dffr5d9d504117ac4857@mail.gmail.com> <42841C5A-B311-4B1A-AB1C-F6B37CF99998@apple.com> <218EE9BA-B005-4840-B223-D182A7C60F46@apple.com> <62d9ffc00901271532g720e652fkaaec8b0f711417d7@mail.gmail.com> <62d9ffc00901271535k206be7b4q5a155b7cb42355ef@mail.gmail.com> <429FB7C0-B7EC-4CB6-A207-5D5DDECDBE97@apple.com> Message-ID: <62d9ffc00901271551w57ed263cub213267df916a405@mail.gmail.com> Oops - it looks like there was a change to ParseAST() earlier that I wasn't up to date with. This one: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20090126/011412.html That change involves propagating the FreeMemory param to the ASTContext constructor... which is problematic with my change which gets rid of that param entirely. I'm not sure how to handle this. What is the purpose of -disable-free in the context of the command-line clang tool? -Alexei On Tue, Jan 27, 2009 at 6:42 PM, Ted Kremenek wrote: > Hi Alexei, > > Looks great! > > I'm actually having difficulty applying the patch. Did you generate it > against top-of-tree clang? > > Ted > > On Jan 27, 2009, at 3:35 PM, Alexei Svitkine wrote: > >> Oops some tabs made it into the previous one. >> >> Here's the same thing with correct whitespace. >> >> -Alexei >> >> On Tue, Jan 27, 2009 at 6:32 PM, Alexei Svitkine >> wrote: >>> >>> Thanks for the comments! >>> >>> Here's a revised patch. >>> >>> -Alexei >>> >>> On Tue, Jan 27, 2009 at 6:22 PM, Ted Kremenek wrote: >>>> >>>> Hi Alexei, >>>> >>>> I apologize, I left the "ei" off your name. >>>> >>>> On Jan 27, 2009, at 3:06 PM, Ted Kremenek wrote: >>>> >>>>> Hi Alex, >>>>> >>>>> Sorry for not looking at this sooner. The patch looks good, but I >>>>> have two additional nits. >>>>> >>>>> First, could you possibly add a comment to the prototype and >>>>> definition of ParseAST indicating what is the behavior of >>>>> TranslationUnit and ASTContext are null? The postcondition for this >>>>> situation is that once ParseAST completes then any subsequent accesses >>>>> to the ASTs it provided is no longer valid (because they are >>>>> reclaimed). This should be explicitly stated, since the ASTConsumer >>>>> (which lives beyond the call to ParseAST) could potentially have >>>>> dangling references to the ASTs. >>>>> >>>>> Second, does it make sense to pass in both a TranslationUnit and an >>>>> ASTContext pointer? Since TranslationUnit holds a reference to >>>>> ASTContext, I think we only need a single argument. If the >>>>> TranslationUnit* is null then the ASTContext* is null as well. >>>>> >>>>> Ted >>>>> >>>>> On Jan 27, 2009, at 11:49 AM, Alexei Svitkine wrote: >>>>> >>>>>> If no one objects to these changes, can someone commit this to the >>>>>> repository? >>>>>> >>>>>> -Alexei >>>>>> >>>>>> On Tue, Jan 27, 2009 at 10:31 AM, Alexei Svitkine >>>>>> wrote: >>>>>>> >>>>>>> On Mon, Jan 26, 2009 at 2:29 PM, Alexei Svitkine >>>>>>> wrote: >>>>>>>> >>>>>>>> Here's an updated patch that also removes the comment about the >>>>>>>> FreeMemory param which no longer exists. >>>>>>>> >>>>>>>> -Alexei >>>>>>>> >>>>>>>> On Sat, Jan 24, 2009 at 2:51 PM, Alexei Svitkine >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> You are right. Here's a revised patch. >>>>>>>>> >>>>>>>>> -Alexei >>>>>>>>> >>>>>>>>> On Sat, Jan 24, 2009 at 11:19 AM, Sebastian Redl >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Alexei Svitkine wrote: >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Attached is a patch to make ParseAST() take ASTContext and >>>>>>>>>>> TranslationUnit as parameters, as suggested by Steve Naroff. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The double negative in the code confuses me somewhat, but isn't >>>>>>>>>> this >>>>>>>>>> condition the wrong way round? >>>>>>>>>> >>>>>>>>>>> + if (!DisableFree) { >>>>>>>>>>> + Context = new ASTContext(PP.getLangOptions(), >>>>>>>>>>> PP.getSourceManager(), >>>>>>>>>>> + PP.getTargetInfo(), >>>>>>>>>>> + PP.getIdentifierTable(), >>>>>>>>>>> PP.getSelectorTable()); >>>>>>>>>>> + TU = new TranslationUnit(*Context); >>>>>>>>>>> + } >>>>>>>>>>> + ParseAST(PP, Consumer.get(), Context, TU, Stats); >>>>>>>>>> >>>>>>>>>> Previously, if DisableFree was true, FreeMemory was false, and >>>>>>>>>> ParseAST >>>>>>>>>> didn't free the objects. >>>>>>>>>> Now, if DisableFree is true, the driver doesn't allocate >>>>>>>>>> objects, so >>>>>>>>>> ParseAST does and will free them. >>>>>>>>>> >>>>>>>>>> Sebastian >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> 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 kremenek at apple.com Tue Jan 27 17:59:17 2009 From: kremenek at apple.com (Ted Kremenek) Date: Tue, 27 Jan 2009 15:59:17 -0800 Subject: [cfe-dev] [Patch] Make ParseAST() take ASTContext and TU params In-Reply-To: <62d9ffc00901271551w57ed263cub213267df916a405@mail.gmail.com> References: <62d9ffc00901240802l312e8ek17de6d0f0b301995@mail.gmail.com> <62d9ffc00901241151u69da5620q87ae555ddb61c358@mail.gmail.com> <62d9ffc00901261129m24b05955m5dd20255230d46ea@mail.gmail.com> <62d9ffc00901270731l6a42728cv27ece2cbfbfe4149@mail.gmail.com> <62d9ffc00901271149j76a35dffr5d9d504117ac4857@mail.gmail.com> <42841C5A-B311-4B1A-AB1C-F6B37CF99998@apple.com> <218EE9BA-B005-4840-B223-D182A7C60F46@apple.com> <62d9ffc00901271532g720e652fkaaec8b0f711417d7@mail.gmail.com> <62d9ffc00901271535k206be7b4q5a155b7cb42355ef@mail.gmail.com> <429FB7C0-B7EC-4CB6-A207-5D5DDECDBE97@apple.com> <62d9ffc00901271551w57ed263cub213267df916a405@mail.gmail.com> Message-ID: <37FF591E-7115-4D88-ABF2-61DC205C5D95@apple.com> On Jan 27, 2009, at 3:51 PM, Alexei Svitkine wrote: > Oops - it looks like there was a change to ParseAST() earlier that I > wasn't up to date with. This one: > > http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20090126/011412.html > > That change involves propagating the FreeMemory param to the > ASTContext constructor... which is problematic with my change which > gets rid of that param entirely. I'm not sure how to handle this. The "FreeMemory" argument to ASTContext is a little of a misnomer. It's more a selector of which Allocator that ASTContext uses to allocate ASTs (i.e., MallocAllocator or BumpPtrAllocator). Calling ~ASTContext() will *always* release memory. Feel free to rename that parameter to something more appropriate. Much of your patch is orthogonal to these changes. Your patch is about creating a new interface for ParseAST that allows clients to hold on the TranslationUnit/ASTContext after ParseAST has completed. > What is the purpose of -disable-free in the context of the > command-line clang tool? Our timings show that a significant amount of time is spent in clang freeing ASTs. When invoking 'clang' for compilation from the command-line, freeing ASTs is a waste of time since the OS will automatically reclaim that memory. Providing -disable-free from the command line allows us to experiment with the performance of just having the OS free memory versus freeing the memory directly. Moreover, having it as a command-line option (rather than hard-coded) allows us to free memory ASTs manually for debugging (to make sure all the ownership issues are correct) but still have the --disable-free option for production releases. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090127/a88c0e50/attachment.html From alexei.svitkine at gmail.com Tue Jan 27 19:20:31 2009 From: alexei.svitkine at gmail.com (Alexei Svitkine) Date: Tue, 27 Jan 2009 20:20:31 -0500 Subject: [cfe-dev] [Patch] Make ParseAST() take ASTContext and TU params In-Reply-To: <37FF591E-7115-4D88-ABF2-61DC205C5D95@apple.com> References: <62d9ffc00901240802l312e8ek17de6d0f0b301995@mail.gmail.com> <62d9ffc00901270731l6a42728cv27ece2cbfbfe4149@mail.gmail.com> <62d9ffc00901271149j76a35dffr5d9d504117ac4857@mail.gmail.com> <42841C5A-B311-4B1A-AB1C-F6B37CF99998@apple.com> <218EE9BA-B005-4840-B223-D182A7C60F46@apple.com> <62d9ffc00901271532g720e652fkaaec8b0f711417d7@mail.gmail.com> <62d9ffc00901271535k206be7b4q5a155b7cb42355ef@mail.gmail.com> <429FB7C0-B7EC-4CB6-A207-5D5DDECDBE97@apple.com> <62d9ffc00901271551w57ed263cub213267df916a405@mail.gmail.com> <37FF591E-7115-4D88-ABF2-61DC205C5D95@apple.com> Message-ID: <62d9ffc00901271720y399e53e0g6441c720417ada88@mail.gmail.com> Ah, thanks for the clarification. Here's an updated patch that passes the correct parameters to the ASTContext() constructor under each case. I didn't rename the parameter in ASTContext however - since it actually does not call Deallocate when FreeMemory is false. -Alexei On Tue, Jan 27, 2009 at 6:59 PM, Ted Kremenek wrote: > On Jan 27, 2009, at 3:51 PM, Alexei Svitkine wrote: > > Oops - it looks like there was a change to ParseAST() earlier that I > wasn't up to date with. This one: > > http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20090126/011412.html > > That change involves propagating the FreeMemory param to the > ASTContext constructor... which is problematic with my change which > gets rid of that param entirely. I'm not sure how to handle this. > > The "FreeMemory" argument to ASTContext is a little of a misnomer. It's > more a selector of which Allocator that ASTContext uses to allocate ASTs > (i.e., MallocAllocator or BumpPtrAllocator). Calling ~ASTContext() will > *always* release memory. Feel free to rename that parameter to something > more appropriate. > Much of your patch is orthogonal to these changes. Your patch is about > creating a new interface for ParseAST that allows clients to hold on the > TranslationUnit/ASTContext after ParseAST has completed. > > What is the purpose of -disable-free in the context of the > command-line clang tool? > > Our timings show that a significant amount of time is spent in clang freeing > ASTs. > When invoking 'clang' for compilation from the command-line, freeing ASTs is > a waste of time since the OS will automatically reclaim that memory. > Providing -disable-free from the command line allows us to experiment with > the performance of just having the OS free memory versus freeing the memory > directly. > Moreover, having it as a command-line option (rather than hard-coded) allows > us to free memory ASTs manually for debugging (to make sure all the > ownership issues are correct) but still have the --disable-free option for > production releases. -------------- next part -------------- A non-text attachment was scrubbed... Name: ParseAST6.diff Type: application/octet-stream Size: 4631 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090127/205f97f9/attachment-0001.obj From vandungto at gmail.com Tue Jan 27 19:34:20 2009 From: vandungto at gmail.com (VanDung To) Date: Tue, 27 Jan 2009 19:34:20 -0600 Subject: [cfe-dev] inline functions Message-ID: Hi, Does clang have any feature for automatic inlining of functions? If I have functions that are not declared with static inline, is there any way I could get the front end to inline some of the functions (based on size) using command line options? Thank you, -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090127/029cbbd9/attachment.html From kremenek at apple.com Tue Jan 27 22:29:54 2009 From: kremenek at apple.com (Ted Kremenek) Date: Tue, 27 Jan 2009 20:29:54 -0800 Subject: [cfe-dev] [Patch] Make ParseAST() take ASTContext and TU params In-Reply-To: <62d9ffc00901271720y399e53e0g6441c720417ada88@mail.gmail.com> References: <62d9ffc00901240802l312e8ek17de6d0f0b301995@mail.gmail.com> <62d9ffc00901270731l6a42728cv27ece2cbfbfe4149@mail.gmail.com> <62d9ffc00901271149j76a35dffr5d9d504117ac4857@mail.gmail.com> <42841C5A-B311-4B1A-AB1C-F6B37CF99998@apple.com> <218EE9BA-B005-4840-B223-D182A7C60F46@apple.com> <62d9ffc00901271532g720e652fkaaec8b0f711417d7@mail.gmail.com> <62d9ffc00901271535k206be7b4q5a155b7cb42355ef@mail.gmail.com> <429FB7C0-B7EC-4CB6-A207-5D5DDECDBE97@apple.com> <62d9ffc00901271551w57ed263cub213267df916a405@mail.gmail.com> <37FF591E-7115-4D88-ABF2-61DC205C5D95@apple.com> <62d9ffc00901271720y399e53e0g6441c720417ada88@mail.gmail.com> Message-ID: <54654B1A-DBFD-4B15-AF81-AD7B6CFDDF26@apple.com> Applied! http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20090126/011422.html On Jan 27, 2009, at 5:20 PM, Alexei Svitkine wrote: > Ah, thanks for the clarification. > > Here's an updated patch that passes the correct parameters to the > ASTContext() constructor under each case. I didn't rename the > parameter in ASTContext however - since it actually does not call > Deallocate when FreeMemory is false. > > -Alexei > > On Tue, Jan 27, 2009 at 6:59 PM, Ted Kremenek > wrote: >> On Jan 27, 2009, at 3:51 PM, Alexei Svitkine wrote: >> >> Oops - it looks like there was a change to ParseAST() earlier that I >> wasn't up to date with. This one: >> >> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20090126/011412.html >> >> That change involves propagating the FreeMemory param to the >> ASTContext constructor... which is problematic with my change which >> gets rid of that param entirely. I'm not sure how to handle this. >> >> The "FreeMemory" argument to ASTContext is a little of a misnomer. >> It's >> more a selector of which Allocator that ASTContext uses to allocate >> ASTs >> (i.e., MallocAllocator or BumpPtrAllocator). Calling ~ASTContext() >> will >> *always* release memory. Feel free to rename that parameter to >> something >> more appropriate. >> Much of your patch is orthogonal to these changes. Your patch is >> about >> creating a new interface for ParseAST that allows clients to hold >> on the >> TranslationUnit/ASTContext after ParseAST has completed. >> >> What is the purpose of -disable-free in the context of the >> command-line clang tool? >> >> Our timings show that a significant amount of time is spent in >> clang freeing >> ASTs. >> When invoking 'clang' for compilation from the command-line, >> freeing ASTs is >> a waste of time since the OS will automatically reclaim that memory. >> Providing -disable-free from the command line allows us to >> experiment with >> the performance of just having the OS free memory versus freeing >> the memory >> directly. >> Moreover, having it as a command-line option (rather than hard- >> coded) allows >> us to free memory ASTs manually for debugging (to make sure all the >> ownership issues are correct) but still have the --disable-free >> option for >> production releases. > From eli.friedman at gmail.com Tue Jan 27 22:40:49 2009 From: eli.friedman at gmail.com (Eli Friedman) Date: Tue, 27 Jan 2009 20:40:49 -0800 Subject: [cfe-dev] inline functions In-Reply-To: References: Message-ID: On Tue, Jan 27, 2009 at 5:34 PM, VanDung To wrote: > Does clang have any feature for automatic inlining of functions? If I have > functions that are not declared with static inline, is there any way I could > get the front end to inline some of the functions (based on size) using > command line options? If you're using the clang executable, it does automatic inlining as long as you turn on the optimizers. You can tweak how aggressive the inliner is with the -inline-threshold command-line parameter; the default value is 200. If you're writing your own program using the clang libraries, you'll have to invoke the inliner yourself; http://llvm.org/docs/ would be helpful for that. That said, what are you planning to do with clang? We're always interested in hearing about new users. -Eli From clattner at apple.com Wed Jan 28 00:07:42 2009 From: clattner at apple.com (Chris Lattner) Date: Tue, 27 Jan 2009 22:07:42 -0800 Subject: [cfe-dev] clang, ccc, llvmc In-Reply-To: References: Message-ID: On Jan 27, 2009, at 7:30 AM, Makslane Ara?jo Rodrigues wrote: > Can someone tell me the relationship between clang, ccc and llvmc? You forgot xcc :) clang -> low-level executable for testing and underlies compilation and static analysis. ccc/xcc -> compiler driver. xcc is the new one that will eventually replace ccc. We expect users to actually use ccc, not the clang executable directly. llvmc -> a generalized compiler driver that can drive many things including clang. None of the clang developer's are currently using it yet afaik, -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090127/34af67e3/attachment.html From clattner at apple.com Wed Jan 28 00:35:06 2009 From: clattner at apple.com (Chris Lattner) Date: Tue, 27 Jan 2009 22:35:06 -0800 Subject: [cfe-dev] diagnostics spliting Message-ID: <9ABCCEED-77E8-40BB-ADDD-5640F22F6845@apple.com> Hi Anders, Thanks for working on the diagnostics split-up patch. Now that the initial patch went into the tree, are you willing to do some cleanup? In particular, I think that the per-library headers (but not the .def files) should move into the per-library header dir. For example DiagnosticSema.h should be in include/clang/Sema instead of clang/ Basic. Also, I think that the number of #includes can now go way down. In sema, for example, I see: $ grep DiagnosticSema.h lib/*/* lib/Sema/Sema.cpp:#include "clang/Basic/DiagnosticSema.h" lib/Sema/Sema.h:#include "clang/Basic/DiagnosticSema.h" lib/Sema/SemaCXXScopeSpec.cpp:#include "clang/Basic/DiagnosticSema.h" lib/Sema/SemaChecking.cpp:#include "clang/Basic/DiagnosticSema.h" lib/Sema/SemaDecl.cpp:#include "clang/Basic/DiagnosticSema.h" lib/Sema/SemaDeclAttr.cpp:#include "clang/Basic/DiagnosticSema.h" lib/Sema/SemaDeclCXX.cpp:#include "clang/Basic/DiagnosticSema.h" lib/Sema/SemaDeclObjC.cpp:#include "clang/Basic/DiagnosticSema.h" lib/Sema/SemaExpr.cpp:#include "clang/Basic/DiagnosticSema.h" lib/Sema/SemaExprCXX.cpp:#include "clang/Basic/DiagnosticSema.h" lib/Sema/SemaExprObjC.cpp:#include "clang/Basic/DiagnosticSema.h" lib/Sema/SemaInherit.cpp:#include "clang/Basic/DiagnosticSema.h" lib/Sema/SemaInit.cpp:#include "clang/Basic/DiagnosticSema.h" lib/Sema/SemaNamedCast.cpp:#include "clang/Basic/DiagnosticSema.h" lib/Sema/SemaStmt.cpp:#include "clang/Basic/DiagnosticSema.h" lib/Sema/SemaType.cpp:#include "clang/Basic/DiagnosticSema.h" I think that all of those can be removed except Sema.h, since they all include sema.h. I'm sure other libraries can also be simplified along similar lines. Thank you for working on this! -Chris From makslane at hotmail.com Wed Jan 28 05:12:30 2009 From: makslane at hotmail.com (=?iso-8859-1?Q?Makslane_Ara=FAjo_Rodrigues?=) Date: Wed, 28 Jan 2009 14:12:30 +0300 Subject: [cfe-dev] clang, ccc, llvmc In-Reply-To: References: Message-ID: Thanks, Chris! CC: cfe-dev at cs.uiuc.eduFrom: clattner at apple.comTo: makslane at hotmail.comSubject: Re: [cfe-dev] clang, ccc, llvmcDate: Tue, 27 Jan 2009 22:07:42 -0800 On Jan 27, 2009, at 7:30 AM, Makslane Ara?jo Rodrigues wrote: Can someone tell me the relationship between clang, ccc and llvmc? You forgot xcc :) clang -> low-level executable for testing and underlies compilation and static analysis. ccc/xcc -> compiler driver. xcc is the new one that will eventually replace ccc. We expect users to actually use ccc, not the clang executable directly. llvmc -> a generalized compiler driver that can drive many things including clang. None of the clang developer's are currently using it yet afaik, -Chris _________________________________________________________________ Receba GR?TIS as mensagens do Messenger no seu celular quando voc? estiver offline. Conhe?a o MSN Mobile! http://mobile.live.com/signup/signup2.aspx?lc=pt-br -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090128/dc66beea/attachment.html From alexei.svitkine at gmail.com Wed Jan 28 16:09:52 2009 From: alexei.svitkine at gmail.com (Alexei Svitkine) Date: Wed, 28 Jan 2009 17:09:52 -0500 Subject: [cfe-dev] -Wimplicit-function-declaration doesn't work? Message-ID: <62d9ffc00901281409l11412f37ndb103c313f302d6@mail.gmail.com> I'm trying to get the warning output of the code: int main(void) { strcmp("abc","def"); return 0; } However, running "clang -Wimplicit-function-declaration" doesn't seem to produce any output. Am I doing something wrong? -Alexei From dgregor at apple.com Wed Jan 28 18:48:57 2009 From: dgregor at apple.com (Douglas Gregor) Date: Wed, 28 Jan 2009 16:48:57 -0800 Subject: [cfe-dev] -Wimplicit-function-declaration doesn't work? In-Reply-To: <62d9ffc00901281409l11412f37ndb103c313f302d6@mail.gmail.com> References: <62d9ffc00901281409l11412f37ndb103c313f302d6@mail.gmail.com> Message-ID: <4294D537-FD33-4762-A496-D24BF482D299@apple.com> On Jan 28, 2009, at 2:09 PM, Alexei Svitkine wrote: > I'm trying to get the warning output of the code: > > int main(void) > { > strcmp("abc","def"); > return 0; > } > > However, running "clang -Wimplicit-function-declaration" doesn't seem > to produce any output. > > Am I doing something wrong? With -pedantic, I see: /Users/dgregor/foo.c:3:2: warning: implicit declaration of function 'strcmp' is invalid in C99 strcmp("abc","def"); ^ 1 diagnostic generated. - Doug From alexei.svitkine at gmail.com Wed Jan 28 20:39:30 2009 From: alexei.svitkine at gmail.com (Alexei Svitkine) Date: Wed, 28 Jan 2009 21:39:30 -0500 Subject: [cfe-dev] -Wimplicit-function-declaration doesn't work? In-Reply-To: <4294D537-FD33-4762-A496-D24BF482D299@apple.com> References: <62d9ffc00901281409l11412f37ndb103c313f302d6@mail.gmail.com> <4294D537-FD33-4762-A496-D24BF482D299@apple.com> Message-ID: <62d9ffc00901281839u576a607y15b43e1066e952b4@mail.gmail.com> Thanks. Shouldn't the other option work as intended, though? I see in clang.cpp: static llvm::cl::opt WarnImplicitFunctionDeclaration("Wimplicit-function-declaration", llvm::cl::desc("Warn about uses of implicitly defined functions")); Which seems to describe exactly the case I'm testing for... but that option seems to have no effect. -Alexei On Wed, Jan 28, 2009 at 7:48 PM, Douglas Gregor wrote: > > On Jan 28, 2009, at 2:09 PM, Alexei Svitkine wrote: > >> I'm trying to get the warning output of the code: >> >> int main(void) >> { >> strcmp("abc","def"); >> return 0; >> } >> >> However, running "clang -Wimplicit-function-declaration" doesn't seem >> to produce any output. >> >> Am I doing something wrong? > > With -pedantic, I see: > > /Users/dgregor/foo.c:3:2: warning: implicit declaration of function 'strcmp' > is invalid in C99 > strcmp("abc","def"); > ^ > 1 diagnostic generated. > > > - Doug > From clattner at apple.com Thu Jan 29 01:13:42 2009 From: clattner at apple.com (Chris Lattner) Date: Wed, 28 Jan 2009 23:13:42 -0800 Subject: [cfe-dev] -Wimplicit-function-declaration doesn't work? In-Reply-To: <62d9ffc00901281839u576a607y15b43e1066e952b4@mail.gmail.com> References: <62d9ffc00901281409l11412f37ndb103c313f302d6@mail.gmail.com> <4294D537-FD33-4762-A496-D24BF482D299@apple.com> <62d9ffc00901281839u576a607y15b43e1066e952b4@mail.gmail.com> Message-ID: <16E2BCEE-BC99-403C-A2ED-ED36542DF3C8@apple.com> On Jan 28, 2009, at 6:39 PM, Alexei Svitkine wrote: > Thanks. Shouldn't the other option work as intended, though? Yes, this should be fixed on mainline now, thanks for the report. -Chris > > > I see in clang.cpp: > > static llvm::cl::opt > WarnImplicitFunctionDeclaration("Wimplicit-function-declaration", > llvm::cl::desc("Warn about uses of implicitly defined functions")); > > Which seems to describe exactly the case I'm testing for... but that > option seems to have no effect. > > -Alexei > > On Wed, Jan 28, 2009 at 7:48 PM, Douglas Gregor > wrote: >> >> On Jan 28, 2009, at 2:09 PM, Alexei Svitkine wrote: >> >>> I'm trying to get the warning output of the code: >>> >>> int main(void) >>> { >>> strcmp("abc","def"); >>> return 0; >>> } >>> >>> However, running "clang -Wimplicit-function-declaration" doesn't >>> seem >>> to produce any output. >>> >>> Am I doing something wrong? >> >> With -pedantic, I see: >> >> /Users/dgregor/foo.c:3:2: warning: implicit declaration of function >> 'strcmp' >> is invalid in C99 >> strcmp("abc","def"); >> ^ >> 1 diagnostic generated. >> >> >> - Doug >> > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From max at duempel.org Thu Jan 29 03:19:23 2009 From: max at duempel.org (Max Kellermann) Date: Thu, 29 Jan 2009 10:19:23 +0100 Subject: [cfe-dev] Bug: assertion "only C++ supports non-constant static initializers!" Message-ID: <20090129091922.GA28917@squirrel.roonstrasse.net> Hi, with clang r63301, I get the following assertion failure: clang: CGDecl.cpp:93: llvm::GlobalValue* clang::CodeGen::CodeGenFunction::GenerateStaticBlockVarDecl(const clang::VarDecl&, bool, const char*): Assertion `getContext().getLangOptions().CPlusPlus && "only C++ supports non-constant static initializers!"' failed. A test source and the full error message is attached. The error occurs only if the first element of "struct foo" is a pointer and only the second one gets explicitly initialized. Max -------------- next part -------------- A non-text attachment was scrubbed... Name: test.c Type: text/x-csrc Size: 133 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090129/31e30df4/attachment.bin -------------- next part -------------- clang: CGDecl.cpp:93: llvm::GlobalValue* clang::CodeGen::CodeGenFunction::GenerateStaticBlockVarDecl(const clang::VarDecl&, bool, const char*): Assertion `getContext().getLangOptions().CPlusPlus && "only C++ supports non-constant static initializers!"' failed. 0 clang 0x00000000017eed9e 1 clang 0x00000000017ef0d4 2 libc.so.6 0x00007fb12bdc4110 3 libc.so.6 0x00007fb12bdc407b gsignal + 59 4 libc.so.6 0x00007fb12bdc584e abort + 270 5 libc.so.6 0x00007fb12bdbdaf4 __assert_fail + 260 6 clang 0x00000000010b4165 clang::CodeGen::CodeGenFunction::GenerateStaticBlockVarDecl(clang::VarDecl const&, bool, char const*) + 405 7 clang 0x00000000010b4b1b clang::CodeGen::CodeGenFunction::EmitStaticBlockVarDecl(clang::VarDecl const&) + 109 8 clang 0x00000000010b4c67 clang::CodeGen::CodeGenFunction::EmitBlockVarDecl(clang::VarDecl const&) + 55 9 clang 0x00000000010b4d4a clang::CodeGen::CodeGenFunction::EmitDecl(clang::Decl const&) + 142 10 clang 0x00000000010f81fb clang::CodeGen::CodeGenFunction::EmitDeclStmt(clang::DeclStmt const&) + 65 11 clang 0x00000000010f8cd4 clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 502 12 clang 0x00000000010f9d03 clang::CodeGen::CodeGenFunction::EmitCompoundStmt(clang::CompoundStmt const&, bool, llvm::Value*, bool) + 253 13 clang 0x00000000010f9f43 clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 101 14 clang 0x00000000010f8b1d clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 63 15 clang 0x00000000010fee86 clang::CodeGen::CodeGenFunction::GenerateCode(clang::FunctionDecl const*, llvm::Function*) + 424 16 clang 0x0000000001097c8e clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::FunctionDecl const*) + 442 17 clang 0x0000000001097d53 clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::ValueDecl const*) + 49 18 clang 0x0000000001097f0d clang::CodeGen::CodeGenModule::EmitGlobal(clang::ValueDecl const*) + 377 19 clang 0x000000000109815d clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) + 127 20 clang 0x0000000001094faa 21 clang 0x0000000000bab0f8 22 clang 0x00000000011a38a6 clang::ParseAST(clang::Preprocessor&, clang::ASTConsumer*, clang::TranslationUnit*, bool) + 490 23 clang 0x0000000000be9192 24 clang 0x0000000000be9eb5 main + 1431 25 libc.so.6 0x00007fb12bdb14ca __libc_start_main + 218 26 clang 0x0000000000b9bb3a fmod + 186 From rdivacky at freebsd.org Thu Jan 29 09:23:45 2009 From: rdivacky at freebsd.org (Roman Divacky) Date: Thu, 29 Jan 2009 16:23:45 +0100 Subject: [cfe-dev] compilation of FreeBSD kernel Message-ID: <20090129152345.GA70479@freebsd.org> hi I just tried to compile freebsd kernel after the designated initializers went in. Those are the results: Compilation errors of GENERIC with clang: 1) error: cannot codegen this constant expression yet 74x 2) Assertion failed: ((i >= FTy->getNumParams() || FTy->getParamType(i) == Params[i]->getType()) && "Calling a function with a bad signature!"), function init, file Instructions.cpp, line 294. 2x 3) Assertion failed: (0 && "VAArgInst is not yet implemented for x86-64!"), function LowerVAARG, file X86ISelLowering.cpp, line 5766. 6x 4) ../../../dev/txp/if_txp.c:1379:1: error: conflicting types for 'txp_command' 3x 5) Assertion failed: (S1->getType() == S2->getType() && "Cannot create binary operator with two operands of differing type!"), function Create, file Instructions.cpp, line 1575. *** Error code 250 1x 6) ../../../vm/vm_object.c:919:4: error: cannot codegen this return inside scope with VLA yet 2x out of 1211 files the (1) is Bug 3436, so once you fix that we're much closer :) I am going to fill in bugs for every problem here later... anyway, great result! 88 failures for 1211 files (some are .S but not more than 10) thnx, roman -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090129/11d8bba2/attachment.bin From spellegrini at dps.uibk.ac.at Thu Jan 29 09:55:07 2009 From: spellegrini at dps.uibk.ac.at (Simone Pellegrini) Date: Thu, 29 Jan 2009 16:55:07 +0100 Subject: [cfe-dev] Back-navigation of the Syntax Tree! Message-ID: <4981D15B.3050100@dps.uibk.ac.at> Dear all, I need to make some kind of manipulation of a syntax tree in Clang. Actually what I want to do is just move some statement (mainly the entire line... until the ';' which enclose a statement I want to move). Apparently this kind of work is more complex than what I thought. At the beginning I perform a simple data-flow analysis to determine the positions where the statement can be placed (and that's is quite trivial). It can be easily done by using a visitor of the AST, but for example when I found, let's say a DeclRefExpr I'd like to have the possibility to access to the statement that encloses the var reference. Practically, what I need is the possibility from a statement to access to the PARENT! I know that I can manually save a reference to the parent node before entering into a node and that will solve my problem but it is ugly! :) Is this possible with the current API to access the parent of a node? I searched a lot and there is no way to get this information. regards Simone From snaroff at apple.com Thu Jan 29 10:03:43 2009 From: snaroff at apple.com (steve naroff) Date: Thu, 29 Jan 2009 11:03:43 -0500 Subject: [cfe-dev] Back-navigation of the Syntax Tree! In-Reply-To: <4981D15B.3050100@dps.uibk.ac.at> References: <4981D15B.3050100@dps.uibk.ac.at> Message-ID: Hi Simone, Check out ParentMap (and it's various clients). snaroff On Jan 29, 2009, at 10:55 AM, Simone Pellegrini wrote: > Dear all, > I need to make some kind of manipulation of a syntax tree in Clang. > > Actually what I want to do is just move some statement (mainly the > entire line... until the ';' which enclose a statement I want to > move). > Apparently this kind of work is more complex than what I thought. > > At the beginning I perform a simple data-flow analysis to determine > the > positions where the statement can be placed (and that's is quite > trivial). It can be easily done by using a visitor of the AST, but for > example when I found, let's say a DeclRefExpr I'd like to have the > possibility to access to the statement that encloses the var > reference. > Practically, what I need is the possibility from a statement to access > to the PARENT! I know that I can manually save a reference to the > parent > node before entering into a node and that will solve my problem but it > is ugly! :) Is this possible with the current API to access the parent > of a node? I searched a lot and there is no way to get this > information. > > regards Simone > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From sebastian.redl at getdesigned.at Thu Jan 29 10:10:00 2009 From: sebastian.redl at getdesigned.at (Sebastian Redl) Date: Thu, 29 Jan 2009 17:10:00 +0100 Subject: [cfe-dev] Back-navigation of the Syntax Tree! In-Reply-To: <4981D15B.3050100@dps.uibk.ac.at> References: <4981D15B.3050100@dps.uibk.ac.at> Message-ID: <4981D4D8.5050908@getdesigned.at> Simone Pellegrini wrote: > Practically, what I need is the possibility from a statement to access > to the PARENT! I know that I can manually save a reference to the parent > node before entering into a node and that will solve my problem but it > is ugly! :) Is this possible with the current API to access the parent > of a node? I searched a lot and there is no way to get this information. > Your search result is correct. AST nodes do not save their parents, so there is no way of getting the parent of a node save by iterating the tree and looking. The reason is that we try to keep the AST nodes as small as possible, and an additional pointer in every node that is not needed by the most common use cases (code generation, analysis, and the rewriter - the users in the Clang repository) makes a very big difference. Sebastian From sebastian.redl at getdesigned.at Thu Jan 29 10:14:52 2009 From: sebastian.redl at getdesigned.at (Sebastian Redl) Date: Thu, 29 Jan 2009 17:14:52 +0100 Subject: [cfe-dev] Back-navigation of the Syntax Tree! In-Reply-To: <4981D4D8.5050908@getdesigned.at> References: <4981D15B.3050100@dps.uibk.ac.at> <4981D4D8.5050908@getdesigned.at> Message-ID: <4981D5FC.6060504@getdesigned.at> Sebastian Redl wrote: > Your search result is correct. AST nodes do not save their parents, so > there is no way of getting the parent of a node save by iterating the > tree and looking. > Apparently I'm talking out of my ass. Well, good to know that there is a solution available. Sebastian From alexei.svitkine at gmail.com Thu Jan 29 10:47:42 2009 From: alexei.svitkine at gmail.com (Alexei Svitkine) Date: Thu, 29 Jan 2009 11:47:42 -0500 Subject: [cfe-dev] What's the best way to...? Message-ID: <62d9ffc00901290847l7249d620jfa56c42623d47170@mail.gmail.com> Hi, I'm looking to determine if some given code fragment is "complete" - and by that I mean that, for example, it can be completely enclosed by an AST node if parsed in-context. For example, printf("%d\n", is not complete by my definition. But "printf("%d\n", i);" is. Similarly, "if (blah) {" is not. But "if (blah) { doStuff(); }" is. Or likewise "int fib(int n)" is not complete - but with a semicolon at the end, its a function declaration, or with a function body following, it's a function definition - and thus complete. I'm looking at what's the best way to do such an analysis using the clang libraries. I have some ideas, but I thought I'd ask the list to make sure I'm not missing some better way... One way I thought about is using the Lexer to lex it into a list of tokens, then use a stack to match {}, [], etc. If the code fragment is balanced, then look at the last non-comment token and check if its either a "}" or a ";", in which case the fragment is complete. Otherwise it's not. Obviously, this technique is just an approximation - and there's probably edge cases it does not cover. Ideally, it would be nice to re-use logic from the Parser - but looking at the public APIs - I didn't see an easy way to accomplish this. Any suggestions would be appreciated. Thanks. -Alexei From clattner at apple.com Thu Jan 29 11:17:53 2009 From: clattner at apple.com (Chris Lattner) Date: Thu, 29 Jan 2009 09:17:53 -0800 Subject: [cfe-dev] Interesting related work Message-ID: "Semantic patching with Coccinelle" http://lwn.net/Articles/315686/ http://www.emn.fr/x-info/coccinelle/ http://www.emn.fr/x-info/coccinelle/ols07-padioleau.pdf The comments are fairly useless, but it looks like interesting related work for pattern matching on ASTs, code rewriting, etc. -Chris From snaroff at apple.com Thu Jan 29 11:22:30 2009 From: snaroff at apple.com (steve naroff) Date: Thu, 29 Jan 2009 12:22:30 -0500 Subject: [cfe-dev] Back-navigation of the Syntax Tree! In-Reply-To: <4981D5FC.6060504@getdesigned.at> References: <4981D15B.3050100@dps.uibk.ac.at> <4981D4D8.5050908@getdesigned.at> <4981D5FC.6060504@getdesigned.at> Message-ID: On Jan 29, 2009, at 11:14 AM, Sebastian Redl wrote: > Sebastian Redl wrote: >> Your search result is correct. AST nodes do not save their parents, >> so >> there is no way of getting the parent of a node save by iterating the >> tree and looking. >> > > Apparently I'm talking out of my ass. Well, good to know that there > is a > solution available. > Everything you said was actually true! The surface area of the API has gotten quite large...don't beat yourself up for not knowing every API:-) snaroff > Sebastian > _______________________________________________ > 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 Jan 29 11:33:46 2009 From: kremenek at apple.com (Ted Kremenek) Date: Thu, 29 Jan 2009 09:33:46 -0800 Subject: [cfe-dev] Bug: assertion "only C++ supports non-constant static initializers!" In-Reply-To: <20090129091922.GA28917@squirrel.roonstrasse.net> References: <20090129091922.GA28917@squirrel.roonstrasse.net> Message-ID: On Jan 29, 2009, at 10:19 AM, Max Kellermann wrote: > Hi, > > with clang r63301, I get the following assertion failure: > > clang: CGDecl.cpp:93: llvm::GlobalValue* > clang::CodeGen::CodeGenFunction::GenerateStaticBlockVarDecl(const > clang::VarDecl&, bool, const char*): Assertion > `getContext().getLangOptions().CPlusPlus && "only C++ supports > non-constant static initializers!"' failed. > > A test source and the full error message is attached. > > The error occurs only if the first element of "struct foo" is a > pointer and only the second one gets explicitly initialized. > > Max Hi Max, Thanks for the bug report. If it is no trouble, please file an actual Bugzilla PR (link off the clang website) so that we can track the resolution of this issue. While sending these reports to the mailing lists is fine, if the issue isn't resolve immediately it can easily get forgotten. Ted From dgregor at apple.com Thu Jan 29 11:58:31 2009 From: dgregor at apple.com (Douglas Gregor) Date: Thu, 29 Jan 2009 09:58:31 -0800 Subject: [cfe-dev] Bug: assertion "only C++ supports non-constant static initializers!" In-Reply-To: <20090129091922.GA28917@squirrel.roonstrasse.net> References: <20090129091922.GA28917@squirrel.roonstrasse.net> Message-ID: <5EB0DF3B-7955-48B1-9677-6437277FFF90@apple.com> On Jan 29, 2009, at 1:19 AM, Max Kellermann wrote: > with clang r63301, I get the following assertion failure: > > clang: CGDecl.cpp:93: llvm::GlobalValue* > clang::CodeGen::CodeGenFunction::GenerateStaticBlockVarDecl(const > clang::VarDecl&, bool, const char*): Assertion > `getContext().getLangOptions().CPlusPlus && "only C++ supports > non-constant static initializers!"' failed. > > A test source and the full error message is attached. Thanks! > The error occurs only if the first element of "struct foo" is a > pointer and only the second one gets explicitly initialized. This is related to my changes to semantic analysis for designated initializers. I've fixed the assertion here: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20090126/011516.html However, this code now gives an error: cannot codegen this constant expression yet since we're missing codegen for this case. - Doug From sebastian.redl at getdesigned.at Thu Jan 29 12:04:20 2009 From: sebastian.redl at getdesigned.at (Sebastian Redl) Date: Thu, 29 Jan 2009 19:04:20 +0100 Subject: [cfe-dev] What's the best way to...? In-Reply-To: <62d9ffc00901290847l7249d620jfa56c42623d47170@mail.gmail.com> References: <62d9ffc00901290847l7249d620jfa56c42623d47170@mail.gmail.com> Message-ID: <4981EFA4.9040504@getdesigned.at> Alexei Svitkine wrote: > Hi, > > I'm looking to determine if some given code fragment is "complete" - > and by that I mean that, for example, it can be completely enclosed by > an AST node if parsed in-context. > > For example, > > printf("%d\n", > > is not complete by my definition. > > But "printf("%d\n", i);" is. Similarly, "if (blah) {" is not. But "if > (blah) { doStuff(); }" is. Or likewise "int fib(int n)" is not > complete - but with a semicolon at the end, its a function > declaration, or with a function body following, it's a function > definition - and thus complete. > > I'm looking at what's the best way to do such an analysis using the > clang libraries. I have some ideas, but I thought I'd ask the list to > make sure I'm not missing some better way... > Very wild idea, and probably not practicable: put a layer between lexer and parser. Usually it just forwards tokens, but when the lexer runs out of tokens, you do a stack trace to find out what part of the parser called you. Then you know what the parser would now expect. Of course, that probably requires careful analysis of the parser and some huge state tables, not to mention that stack tracing as part of the normal program flow is simply impracticable. Sebastian From alexei.svitkine at gmail.com Thu Jan 29 12:31:55 2009 From: alexei.svitkine at gmail.com (Alexei Svitkine) Date: Thu, 29 Jan 2009 13:31:55 -0500 Subject: [cfe-dev] What's the best way to...? In-Reply-To: <4981EFA4.9040504@getdesigned.at> References: <62d9ffc00901290847l7249d620jfa56c42623d47170@mail.gmail.com> <4981EFA4.9040504@getdesigned.at> Message-ID: <62d9ffc00901291031n76119983u3cf5291fa62b4a55@mail.gmail.com> > Very wild idea, and probably not practicable: put a layer between lexer > and parser. Usually it just forwards tokens, but when the lexer runs out > of tokens, you do a stack trace to find out what part of the parser > called you. Then you know what the parser would now expect. Hmm.. Perhaps if the Parser was made to pass a constant that says what type of thing is being parsed to the Lexer when asking for the next token, the stack trace voodoo can be avoided. The Lexer would then need to be decoupled from the Parser to make this possible... perhaps the Parser would use a LexerProvider or something which just wraps the Lexer and takes the extra parameter. Then I could derive from LexerProvider and intercept that... Seems like it would require a lot of (small) changes to the Parser to do this... and I can understand that there might be resistance against this approach since it would add a level of indirection and thus decrease performance (though a smart compiler/linker could optimize that out?). -Alexei From alexei.svitkine at gmail.com Thu Jan 29 12:32:58 2009 From: alexei.svitkine at gmail.com (Alexei Svitkine) Date: Thu, 29 Jan 2009 13:32:58 -0500 Subject: [cfe-dev] What's the best way to...? In-Reply-To: <62d9ffc00901291031n76119983u3cf5291fa62b4a55@mail.gmail.com> References: <62d9ffc00901290847l7249d620jfa56c42623d47170@mail.gmail.com> <4981EFA4.9040504@getdesigned.at> <62d9ffc00901291031n76119983u3cf5291fa62b4a55@mail.gmail.com> Message-ID: <62d9ffc00901291032h55dadc22h62759942b50520a7@mail.gmail.com> >> though a smart compiler/linker could optimize that out? I meant inline. -Alexei From alexei.svitkine at gmail.com Thu Jan 29 13:56:50 2009 From: alexei.svitkine at gmail.com (Alexei Svitkine) Date: Thu, 29 Jan 2009 14:56:50 -0500 Subject: [cfe-dev] "error: expected ';' after expression" caret diagnostic Message-ID: <62d9ffc00901291156w7bbb6211x56ac2b27964cf3fa@mail.gmail.com> When a semicolon is missing, clang correctly diagnoses the error. However, the diagnostic caret is shown at the beginning of the next line, rather than at the end of the line missing the semicolon. For example: int main(void) { int i = 1; return i -1 } Results in: abc.c:5:1: error: expected ';' after return statement } ^ That doesn't seem very helpful - wouldn't it be better to have the caret point to the end of "return i - 1"? -Alexei From max at duempel.org Thu Jan 29 14:09:26 2009 From: max at duempel.org (Max Kellermann) Date: Thu, 29 Jan 2009 21:09:26 +0100 Subject: [cfe-dev] Bug: assertion "only C++ supports non-constant static initializers!" In-Reply-To: <5EB0DF3B-7955-48B1-9677-6437277FFF90@apple.com> References: <20090129091922.GA28917@squirrel.roonstrasse.net> <5EB0DF3B-7955-48B1-9677-6437277FFF90@apple.com> Message-ID: <20090129200926.GA13386@squirrel.roonstrasse.net> On 2009/01/29 18:58, Douglas Gregor wrote: > This is related to my changes to semantic analysis for designated > initializers. I've fixed the assertion here: Confirmed, this is fixed, replaced by the other error message! Will use Bugzilla next time, didn't notice that you have one... Anyway, keep up the good work, I hope clang will be a full-featured gcc replacement one day, sounds like a very interesting project. Max From eli.friedman at gmail.com Thu Jan 29 14:08:33 2009 From: eli.friedman at gmail.com (Eli Friedman) Date: Thu, 29 Jan 2009 12:08:33 -0800 Subject: [cfe-dev] "error: expected '; ' after expression" caret diagnostic In-Reply-To: <62d9ffc00901291156w7bbb6211x56ac2b27964cf3fa@mail.gmail.com> References: <62d9ffc00901291156w7bbb6211x56ac2b27964cf3fa@mail.gmail.com> Message-ID: On Thu, Jan 29, 2009 at 11:56 AM, Alexei Svitkine wrote: > That doesn't seem very helpful - wouldn't it be better to have the > caret point to the end of "return i - 1"? http://llvm.org/bugs/show_bug.cgi?id=3410 -Eli From alexei.svitkine at gmail.com Thu Jan 29 14:13:24 2009 From: alexei.svitkine at gmail.com (Alexei Svitkine) Date: Thu, 29 Jan 2009 15:13:24 -0500 Subject: [cfe-dev] TextDiagnosticPrinter small patch Message-ID: <62d9ffc00901291213y447c8515i9e2574c9c7eebfa4@mail.gmail.com> Hi, Attached is a patch for TextDiagnosticPrinter that adds an optional parameter that allows users to omit the printing of the source location on a diagnostic. So basically it would omit the "abc.c:5:1: " at the beginning of the line. If it can be added to the codebase, then it would make things easier for me as I wouldn't need to make my own fork of that class with that change. :) -Alexei -------------- next part -------------- A non-text attachment was scrubbed... Name: TextDiagnosticPrinter.diff Type: application/octet-stream Size: 1490 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090129/5fa963c8/attachment.obj From akyrtzi at gmail.com Thu Jan 29 16:34:43 2009 From: akyrtzi at gmail.com (Argiris Kirtzidis) Date: Thu, 29 Jan 2009 14:34:43 -0800 Subject: [cfe-dev] What's the best way to...? In-Reply-To: <62d9ffc00901290847l7249d620jfa56c42623d47170@mail.gmail.com> References: <62d9ffc00901290847l7249d620jfa56c42623d47170@mail.gmail.com> Message-ID: <49822F03.80207@gmail.com> Hi Alexei, Alexei Svitkine wrote: > Hi, > > I'm looking to determine if some given code fragment is "complete" - > and by that I mean that, for example, it can be completely enclosed by > an AST node if parsed in-context. > > For example, > > printf("%d\n", > > is not complete by my definition. > > But "printf("%d\n", i);" is. Similarly, "if (blah) {" is not. But "if > (blah) { doStuff(); }" is. Or likewise "int fib(int n)" is not > complete - but with a semicolon at the end, its a function > declaration, or with a function body following, it's a function > definition - and thus complete. > Here's an idea, not sure how well it will work or whether it suits your purposes. The preprocessor has a "FileChanged" callback, look in "Lex/PPCallbacks.h". The idea is that you "intercept" that callback (using Preprocessor::setPPCallbacks) and enter the code fragment using something like: llvm::MemoryBuffer *SB = llvm::MemoryBuffer::getMemBufferCopy(buf, buf_len); // buf contains the code fragment string unsigned FileID = SourceMgr.createFileIDForMemBuffer(SB); PP.EnterSourceFile(FileID, 0); // PP is the Preprocessor Then you call "Parser::ParseTopLevelDecl". If the code fragment is incomplete, the FileChanged callback will be invoked (the preprocessor will close the "file" trying to consume more tokens), otherwise ParseTopLevelDecl will return the AST node (or null in case of error). Also, you will probably need to make some Parser methods like "ParseExpression" public so that you can use them. -Argiris > I'm looking at what's the best way to do such an analysis using the > clang libraries. I have some ideas, but I thought I'd ask the list to > make sure I'm not missing some better way... > > One way I thought about is using the Lexer to lex it into a list of > tokens, then use a stack to match {}, [], etc. If the code fragment is > balanced, then look at the last non-comment token and check if its > either a "}" or a ";", in which case the fragment is complete. > Otherwise it's not. > > Obviously, this technique is just an approximation - and there's > probably edge cases it does not cover. Ideally, it would be nice to > re-use logic from the Parser - but looking at the public APIs - I > didn't see an easy way to accomplish this. > > Any suggestions would be appreciated. Thanks. > > -Alexei > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > > From spellegrini at dps.uibk.ac.at Fri Jan 30 03:41:32 2009 From: spellegrini at dps.uibk.ac.at (Simone Pellegrini) Date: Fri, 30 Jan 2009 10:41:32 +0100 Subject: [cfe-dev] Back-navigation of the Syntax Tree! In-Reply-To: References: <4981D15B.3050100@dps.uibk.ac.at> <4981D4D8.5050908@getdesigned.at> <4981D5FC.6060504@getdesigned.at> Message-ID: <4982CB4C.3000400@dps.uibk.ac.at> Anyway, the ParentMap definitely solved my problem! And actually the implementation/idea is very nice! you CLANG guys kick ass! :P regards, Simone steve naroff wrote: > > On Jan 29, 2009, at 11:14 AM, Sebastian Redl wrote: > >> Sebastian Redl wrote: >>> Your search result is correct. AST nodes do not save their parents, so >>> there is no way of getting the parent of a node save by iterating the >>> tree and looking. >>> >> >> Apparently I'm talking out of my ass. Well, good to know that there is a >> solution available. >> > > Everything you said was actually true! > > The surface area of the API has gotten quite large...don't beat > yourself up for not knowing every API:-) > > snaroff > >> Sebastian >> _______________________________________________ >> cfe-dev mailing list >> cfe-dev at cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > From rdivacky at freebsd.org Fri Jan 30 04:25:14 2009 From: rdivacky at freebsd.org (Roman Divacky) Date: Fri, 30 Jan 2009 11:25:14 +0100 Subject: [cfe-dev] compilation of FreeBSD kernel In-Reply-To: <20090129152345.GA70479@freebsd.org> References: <20090129152345.GA70479@freebsd.org> Message-ID: <20090130102514.GA54285@freebsd.org> here's an update as bug 3436 seems to be fixed(is it fixed?): Compilation errors of GENERIC with clang: 1) Assertion failed: ((i >= FTy->getNumParams() || FTy->getParamType(i) == Params[i]->getType()) && "Calling a function with a bad signature!"), function init, file Instructions.cpp, line 294. 2x (aic7x) 2) Assertion failed: (0 && "VAArgInst is not yet implemented for x86-64!"), function LowerVAARG, file X86ISelLowering.cpp, line 5766. 8x 3) ../../../dev/txp/if_txp.c:1379:1: error: conflicting types for 'txp_command' 3x 4) Assertion failed: (S1->getType() == S2->getType() && "Cannot create binary operator with two operands of differing type!"), function Create, file Instructions.cpp, line 1575. *** Error code 250 1x (msdosfs_conv.c) 5) ../../../vm/vm_object.c:919:4: error: cannot codegen this return inside scope with VLA yet 2x 16 out of 1211 files (that's 1.32%) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090130/ac6bc48c/attachment.bin From swildner at erpicon.de Fri Jan 30 04:45:21 2009 From: swildner at erpicon.de (Sascha Wildner) Date: Fri, 30 Jan 2009 11:45:21 +0100 Subject: [cfe-dev] compilation of FreeBSD kernel In-Reply-To: <20090130102514.GA54285@freebsd.org> References: <20090129152345.GA70479@freebsd.org> <20090130102514.GA54285@freebsd.org> Message-ID: <4982DA41.7050504@erpicon.de> Roman Divacky schrieb: > here's an update as bug 3436 seems to be fixed(is it fixed?): > > Compilation errors of GENERIC with clang: > [...] Roman, that's great news! I guess it's time to seriously look into getting the DragonFly kernel compiled. :-) Best regards, -- Sascha Wildner erpicon Software Development GmbH Neusser Str. 724-726 50737 K?ln Germany Phone: +49 221 9746089 Fax: +49 221 9746099 Mobile: +49 174 9887655 eMail: swildner at erpicon.de From nunoplopes at sapo.pt Fri Jan 30 06:31:11 2009 From: nunoplopes at sapo.pt (Nuno Lopes) Date: Fri, 30 Jan 2009 12:31:11 -0000 Subject: [cfe-dev] compilation of FreeBSD kernel In-Reply-To: <20090130102514.GA54285@freebsd.org> References: <20090129152345.GA70479@freebsd.org> <20090130102514.GA54285@freebsd.org> Message-ID: <62B2E42F6E694D2180E2210CC54862E8@pc07654> Hi, Great news! Please submit a preprocessed file of each type of bug to http://llvm.org/bugs . If possible please also reduce the file; if not I'll reduce them for you. Thanks, Nuno ----- Original Message ----- From: "Roman Divacky" To: Sent: Friday, January 30, 2009 10:25 AM Subject: Re: [cfe-dev] compilation of FreeBSD kernel here's an update as bug 3436 seems to be fixed(is it fixed?): Compilation errors of GENERIC with clang: 1) Assertion failed: ((i >= FTy->getNumParams() || FTy->getParamType(i) == Params[i]->getType()) && "Calling a function with a bad signature!"), function init, file Instructions.cpp, line 294. 2x (aic7x) 2) Assertion failed: (0 && "VAArgInst is not yet implemented for x86-64!"), function LowerVAARG, file X86ISelLowering.cpp, line 5766. 8x 3) ../../../dev/txp/if_txp.c:1379:1: error: conflicting types for 'txp_command' 3x 4) Assertion failed: (S1->getType() == S2->getType() && "Cannot create binary operator with two operands of differing type!"), function Create, file Instructions.cpp, line 1575. *** Error code 250 1x (msdosfs_conv.c) 5) ../../../vm/vm_object.c:919:4: error: cannot codegen this return inside scope with VLA yet 2x 16 out of 1211 files (that's 1.32%) From clattner at apple.com Fri Jan 30 11:42:35 2009 From: clattner at apple.com (Chris Lattner) Date: Fri, 30 Jan 2009 09:42:35 -0800 Subject: [cfe-dev] TextDiagnosticPrinter small patch In-Reply-To: <62d9ffc00901291213y447c8515i9e2574c9c7eebfa4@mail.gmail.com> References: <62d9ffc00901291213y447c8515i9e2574c9c7eebfa4@mail.gmail.com> Message-ID: <7D61CB06-F41C-40FA-95DB-99F3A27EB961@apple.com> On Jan 29, 2009, at 12:13 PM, Alexei Svitkine wrote: > Hi, > > Attached is a patch for TextDiagnosticPrinter that adds an optional > parameter that allows users to omit the printing of the source > location on a diagnostic. So basically it would omit the "abc.c:5:1: " > at the beginning of the line. Ok, applied here: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20090126/011568.html Please provide a patch to add a command line option that controls this though, I prefer not to have dead code in the codebase, thanks! -Chris From alexei.svitkine at gmail.com Fri Jan 30 12:54:06 2009 From: alexei.svitkine at gmail.com (Alexei Svitkine) Date: Fri, 30 Jan 2009 13:54:06 -0500 Subject: [cfe-dev] TextDiagnosticPrinter small patch In-Reply-To: <7D61CB06-F41C-40FA-95DB-99F3A27EB961@apple.com> References: <62d9ffc00901291213y447c8515i9e2574c9c7eebfa4@mail.gmail.com> <7D61CB06-F41C-40FA-95DB-99F3A27EB961@apple.com> Message-ID: <62d9ffc00901301054m1ae1c3a1me5c856f897e2baeb@mail.gmail.com> Thanks. Here's a patch that adds -fno-show-source-location. -Alexei On Fri, Jan 30, 2009 at 12:42 PM, Chris Lattner wrote: > > On Jan 29, 2009, at 12:13 PM, Alexei Svitkine wrote: > >> Hi, >> >> Attached is a patch for TextDiagnosticPrinter that adds an optional >> parameter that allows users to omit the printing of the source >> location on a diagnostic. So basically it would omit the "abc.c:5:1: " >> at the beginning of the line. > > Ok, applied here: > http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20090126/011568.html > > Please provide a patch to add a command line option that controls this > though, I prefer not to have dead code in the codebase, thanks! > > -Chris > > -------------- next part -------------- A non-text attachment was scrubbed... Name: NoShowLocation.diff Type: application/octet-stream Size: 1193 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090130/520251f4/attachment.obj From clattner at apple.com Fri Jan 30 13:02:06 2009 From: clattner at apple.com (Chris Lattner) Date: Fri, 30 Jan 2009 11:02:06 -0800 Subject: [cfe-dev] TextDiagnosticPrinter small patch In-Reply-To: <62d9ffc00901301054m1ae1c3a1me5c856f897e2baeb@mail.gmail.com> References: <62d9ffc00901291213y447c8515i9e2574c9c7eebfa4@mail.gmail.com> <7D61CB06-F41C-40FA-95DB-99F3A27EB961@apple.com> <62d9ffc00901301054m1ae1c3a1me5c856f897e2baeb@mail.gmail.com> Message-ID: <5667583B-6093-414A-8CC9-725C1CD02487@apple.com> On Jan 30, 2009, at 10:54 AM, Alexei Svitkine wrote: > Thanks. Here's a patch that adds -fno-show-source-location. Thanks! http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20090126/011576.html From sebastian.redl at getdesigned.at Fri Jan 30 13:58:42 2009 From: sebastian.redl at getdesigned.at (Sebastian Redl) Date: Fri, 30 Jan 2009 20:58:42 +0100 Subject: [cfe-dev] Bug 3444: Switch and cases Message-ID: <49835BF2.3020103@getdesigned.at> Hi, I'd like to get your input on bug 3444[1]. Short summary: when an error during the parsing of the compound statement occurs (mainly a missing end brace), it is deallocated, and all contained statements too. This means that the case statements are deallocated, but they're still referenced by the switch's case list. So when it comes to the switch statement examining these case statements, there's trouble. Clang crashes. In the bug discussion, we've identified three possible approaches. 1) Pass Action::OnFinishSwitchStmt a null pointer as the body instead of a null statement. This causes Sema to just pop the switch stack and return immediately. 2) Have ParseCompoundStmtBody return a valid statement even if there is an error, thus keeping the cases alive. 3) Make the switch case chain a double-linked list so that case statements can unhook themselves when they get destroyed. The problem with option 1 is that it's not entirely clear that it is a sufficient solution. Are there any circumstances where a case statement could be thrown away, but the final compound statement appears valid? The problem with option 2 is that it messes with other stuff using compound statements. In particular, do...while statements start emitting previously suppressed errors about missing the while clause if the compound statement fails to be parsed. Also, the approach is fragile, because some other part of validation could then throw the compound statement away. The problem with option 3 is that it is the biggest intrusion into the system. The other two are 5-line patches that I had written within a minute each. This one is big, because it requires some slight restructuring of the AST hierarchy so that unlinking really works. Also, it adds another pointer to switches, cases and default cases. Chris also raised a concern about the destructor not being called when the bump allocator is used and smart pointers are disabled, but this is not a problem, since in that case the case statements aren't deallocated anyway. Do you have comments about these options or further ideas? [1] http://llvm.org/bugs/show_bug.cgi?id=3444 From piotr.rak at gmail.com Fri Jan 30 21:53:50 2009 From: piotr.rak at gmail.com (Piotr Rak) Date: Sat, 31 Jan 2009 04:53:50 +0100 Subject: [cfe-dev] [Patch] AST support, and unqualified name lookup for using-directives Message-ID: <7925cd330901301953h40e257e2j80648051c46f4f0b@mail.gmail.com> Hi, I have played bit more with using-directives. Attached adds AST support for using-directives (no serialization still), and makes Sema::LookupName look ugly:) I may split it into two separated patches(AST and lookup), if it is needed. I would also want to also ask, if there is any master plan how to get rid of OverloadedFunctionDecl yet, or anyone actively working on it now? Piotr -------------- next part -------------- A non-text attachment was scrubbed... Name: decl.udir.diff Type: text/x-patch Size: 57143 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090131/ad981697/attachment-0001.bin From piotr.rak at gmail.com Sat Jan 31 06:00:18 2009 From: piotr.rak at gmail.com (Piotr Rak) Date: Sat, 31 Jan 2009 13:00:18 +0100 Subject: [cfe-dev] [Patch] AST support, and unqualified name lookup for using-directives In-Reply-To: <7925cd330901301953h40e257e2j80648051c46f4f0b@mail.gmail.com> References: <7925cd330901301953h40e257e2j80648051c46f4f0b@mail.gmail.com> Message-ID: <7925cd330901310400w43d69e5bn26193076575bd048@mail.gmail.com> Hi, Sorry, I have just noticed crash on valid code caused by this patch, and not handling ambiguous name lookup results properly in Sema::ActOnUsingDirective :( Attached diff to previous, and also updated version, fixing this crash, and extending tests. Piotr -------------- next part -------------- A non-text attachment was scrubbed... Name: ambig-ns.diff Type: text/x-patch Size: 2089 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090131/84a44cde/attachment-0002.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: decl.udir.v2.diff Type: text/x-patch Size: 57850 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20090131/84a44cde/attachment-0003.bin From dgregor at apple.com Sat Jan 31 14:42:41 2009 From: dgregor at apple.com (Douglas Gregor) Date: Sat, 31 Jan 2009 12:42:41 -0800 Subject: [cfe-dev] [Patch] AST support, and unqualified name lookup for using-directives In-Reply-To: <7925cd330901301953h40e257e2j80648051c46f4f0b@mail.gmail.com> References: <7925cd330901301953h40e257e2j80648051c46f4f0b@mail.gmail.com> Message-ID: <3C5A14E2-0905-4C47-8DE8-FAD918363939@apple.com> On Jan 30, 2009, at 7:53 PM, Piotr Rak wrote: > I have played bit more with using-directives. Attached adds AST > support for using-directives (no serialization still), and makes > Sema::LookupName look ugly:) I may split it into two separated > patches(AST and lookup), if it is needed. This is a big undertaking; thank you! I'll do a detailed review later, but one thing in particular caught me eye: that sort_heap in CppLookupName is really going to hurt performance. Could you give me a short description of why we need it? (Or should I just wait until I do that detailed review to get the big picture?) > I would also want to also ask, if there is any master plan how to get > rid of OverloadedFunctionDecl yet, or anyone actively working on it > now? The master plan is for LookupResult to provide an easy way to iterate over the set of overloaded functions that it found, which means providing a LookupResult::iterator that understands how LookupResult stores overloaded functions (as a pair of iterators into a DeclContext or into an IdentifierResolver chain). If it would help with using- directives, I could implement LookupResult::iterator relatively soon. Right now, OverloadedFunctionDecl is only created "on demand" by LookupResult when the caller requests a Decl*. Callers should be migrated to look at the kind of LookupResult they receive from Lookup*Name, so that they can handle both ambiguities and overloaded functions. This change can happen gradually, and at some point none of the callers will need OverloadedFunctionDecl. I haven't been actively working on doing this, but for the most part it also isn't hard. The trickiest part is deciding what to do with DeclRefExpr's that refer to overloaded functions. - Doug From piotr.rak at gmail.com Sat Jan 31 15:46:00 2009 From: piotr.rak at gmail.com (Piotr Rak) Date: Sat, 31 Jan 2009 22:46:00 +0100 Subject: [cfe-dev] [Patch] AST support, and unqualified name lookup for using-directives In-Reply-To: <3C5A14E2-0905-4C47-8DE8-FAD918363939@apple.com> References: <7925cd330901301953h40e257e2j80648051c46f4f0b@mail.gmail.com> <3C5A14E2-0905-4C47-8DE8-FAD918363939@apple.com> Message-ID: <7925cd330901311346y6559befbg1252b47b010d8c8d@mail.gmail.com> Hi Dough, 2009/1/31 Douglas Gregor : > > On Jan 30, 2009, at 7:53 PM, Piotr Rak wrote: >> >> I have played bit more with using-directives. Attached adds AST >> support for using-directives (no serialization still), and makes >> Sema::LookupName look ugly:) I may split it into two separated >> patches(AST and lookup), if it is needed. > > This is a big undertaking; thank you! > > I'll do a detailed review later, but one thing in particular caught me eye: > that sort_heap in CppLookupName is really going to hurt performance. Could > you give me a short description of why we need it? (Or should I just wait > until I do that detailed review to get the big picture?) > For each Scope (namespace/translation-unit), we need to consider all using-directives which have common ancestor (of nominated namespace, and context containing using-directive). I see few ways to solve it: - sort by common ancestor, use binary search to find range (we do that now, we can check other sort algorithms, qsort might be bad, since memory allocation often creates increasing addresses) - use multiset/hashset - use linear search (gcc does that) Which is faster for real code? I don't know, have not messured it honestly, I tend to belive it will be bit faster than gcc for larger number of using-directives, or similar..., for small number we lose now for sure. I would like to play with it, and tweak it at later point, but I don't think microbenchmarks are way to go. Moreover, I consider caching this sorted list in Scope structure (probably not updating online, just invalidating), then it will always be a win over gcc in terms of time. There is still other issue, hurting lookup, not addressed by this patch too, ie. looking in same DeclContext many times. >> I would also want to also ask, if there is any master plan how to get >> rid of OverloadedFunctionDecl yet, or anyone actively working on it >> now? > > The master plan is for LookupResult to provide an easy way to iterate over > the set of overloaded functions that it found, which means providing a > LookupResult::iterator that understands how LookupResult stores overloaded > functions (as a pair of iterators into a DeclContext or into an > IdentifierResolver chain). If it would help with using-directives, I could > implement LookupResult::iterator relatively soon. It is not essential now, but at later point I could avoid few allocations! while merging multiple OverloadedFunctionDecls (now I reuse first found OverloadedFunctionDecl, and free other). > Right now, OverloadedFunctionDecl is only created "on demand" by > LookupResult when the caller requests a Decl*. Callers should be migrated to > look at the kind of LookupResult they receive from Lookup*Name, so that they > can handle both ambiguities and overloaded functions. This change can happen > gradually, and at some point none of the callers will need > OverloadedFunctionDecl. I haven't been actively working on doing this, but > for the most part it also isn't hard. The trickiest part is deciding what to > do with DeclRefExpr's that refer to overloaded functions. Access to stored FunctionDecls avoiding allocation of OverloadedFunctionDecl would improve performance in same cases, but that would be not be big change. > > - Doug > Piotr From piotr.rak at gmail.com Sat Jan 31 15:49:57 2009 From: piotr.rak at gmail.com (Piotr Rak) Date: Sat, 31 Jan 2009 22:49:57 +0100 Subject: [cfe-dev] [Patch] AST support, and unqualified name lookup for using-directives In-Reply-To: <7925cd330901311346y6559befbg1252b47b010d8c8d@mail.gmail.com> References: <7925cd330901301953h40e257e2j80648051c46f4f0b@mail.gmail.com> <3C5A14E2-0905-4C47-8DE8-FAD918363939@apple.com> <7925cd330901311346y6559befbg1252b47b010d8c8d@mail.gmail.com> Message-ID: <7925cd330901311349q1882cd53paea1c892eee17b4a@mail.gmail.com> 2009/1/31 Piotr Rak : > > Access to stored FunctionDecls avoiding allocation of > OverloadedFunctionDecl would improve performance in same cases, but > that would be not be big change. > I should clarify, that I mean 'code change' here. Piotr From swildner at erpicon.de Sat Jan 31 18:45:41 2009 From: swildner at erpicon.de (Sascha Wildner) Date: Sun, 01 Feb 2009 01:45:41 +0100 Subject: [cfe-dev] scan-build -analyze-headers issue? Message-ID: <4984F0B5.6070200@erpicon.de> Hi, scan-build with the -analyze-headers option will not analyze foo() if defined as follows. Code compiles fine with gcc. test.h: ------------------------ void FUNCTIONNAME(void) { return; } ------------------------ test.c: ------------------------ #define FUNCTIONNAME foo #include "test.h" int main(void) { foo(); } ------------------------ Regards, Sascha