From Michael.Han at autodesk.com Fri Jul 1 01:37:22 2011 From: Michael.Han at autodesk.com (Michael Han) Date: Fri, 1 Jul 2011 06:37:22 +0000 Subject: [cfe-dev] Proposal for thread safety attributes for Clang In-Reply-To: References: Message-ID: <2C9935343FDB104E8F3175A2729BC31402C22B@005-TK5MPN1-011.MGDADSK.autodesk.com> We have implemented a tool based on clang at Autodesk to help developers express their design decisions. The basic idea is the design decisions implemented as a set of customized GNU style attributes can serve as metadta to the fuctions, classes, etc and these metadata could be checked by clang static analyzer to enforce specific data access pattern and call graph for functions. We use this tool to help us parallelize some of our legacy C++ code base, for example, by enforcing a specific code is purely functinal style thus by definition is trivially thread safe. Our implementation touches many pieces of clang as we don't find a less intrusive way to get the attributes / metadata into clang's type system and AST. As a result we have to periodically merge our code base with Clang official trunk, which sometimes is quite touch. The checker is easy to write as it is very well decoupled from the rest of the system. I am wondering if this project would lead to an extensible annotation framework for Clang so user could encode arbitary metadata into Clang AST. That would be very useful and powerful for analysis code as it would involve develpers more intimately by capturing the design decisions eariler. Cheers ~Michael From: cfe-dev-bounces at cs.uiuc.edu [mailto:cfe-dev-bounces at cs.uiuc.edu] On Behalf Of Caitlin Sadowski Sent: Friday, July 01, 2011 8:58 AM To: cfe-dev at cs.uiuc.edu; Delesley Hutchins; Jaeheon Yi; Jeffrey Yasskin; cormac at cs.ucsc.edu Subject: [cfe-dev] Proposal for thread safety attributes for Clang The following is a proposal for a project we would like to contribute to Clang. Feel free to discuss. Cheers, Caitlin Sadowski Google & University of California at Santa Cruz Thread Safety Attributes for Clang Summary We would like to add a set of thread safety attributes to Clang. These attributes, based on a prior GCC implementation, will allow for checkable documentation of basic locking policies in multithreaded programs. Background The synchronization policies in modern multithreaded code may be poorly documented, and incorrectly inferred by new developers. Furthermore, when these policies are improperly followed they often lead to bugs which are difficult to reproduce and diagnose. One strategy for avoiding concurrency bugs is formal documentation of these synchronization policies. By writing this documentation using attribute-based annotations, Clang can mechanically check and warn about issues that could potentially result in race conditions and deadlocks. Example A code sample which demonstrates two of the proposed annotations is below. In this code sample, variables are protected by locks from the Mutex class. This class has been annotated to specify the API used to lock and unlock. * GUARDED_BY specifies a particular lock should be held when accessing the annotated variable. Violations of this locking policy may lead to data races. * ACQUIRED_AFTER annotations document the acquisition order between locks that can be held simultaneously by a thread, by specify the locks that need to be acquired before the annotated lock. Violations of this locking policy may lead to deadlocks. 1 #include "thread_annotations.h" 2 #define GUARDED_BY(x) __attribute__((GUARDED_BY(x))) 3 #define ACQUIRED_AFTER(x) __attribute__((ACQUIRED_AFTER(x))) 4 5 Mutex mu1; 6 Mutex mu2 ACQUIRED_AFTER(mu1); 7 8 int x GUARDED_BY(mu1); 9 int a GUARDED_BY(mu2); 10 11 void foo() 12 { 13 mu2.Lock(); 14 mu1.Lock(); 15 if (x > 2) 16 a = x + 1; 17 else 18 a = x - 1; 19 mu1.Unlock(); 20 mu2.Unlock(); 21 } Sample compiler output: ex.cc: In function 'void foo()': ex.cc:12: warning: Lock 'mu1' is acquired after lock 'mu2' (acquired at line 14) but is annotated otherwise Previous Work As mentioned, thread safety annotations have been implemented in GCC. A full list of the annotations and descriptions for them can be found here: http://gcc.gnu.org/wiki/ThreadSafetyAnnotation https://docs.google.com/a/google.com/Doc?id=ddqtfwhb_0c49t6zgr These annotations have been in active use in Google's C++ codebase for a couple of years, so there is a large informal case study of their usefulness. The ideas behind many of these annotations come originally from a research paper [1]. Plan We are planning to re-implement the GCC thread safety attributes in Clang. We will submit a series of patches to the cfe-commits mailing list. Our current plan for this serie is as follows: 1) Basic parsing and semantic checking of the attributes which do not take arguments. In other words, checking whether the attribute is applied in the appropriate context (e.g. to a field, with no arguments). 2) Basic parsing and semantic checking of the attributes which do take arguments, but without parsing or checking the arguments themselves. At this point, we will simply discard the tokens making up the arguments. 3) Attribute argument parsing. 4) Adding the thread safety analysis checks. We will teach the static analysis-based warnings layer to warn for violations of the annotations discussed on the links above. Future Projects Once we have this core set of thread safety annotations implemented, we have several directions for future work we would like to pursue. These include supporting additional types of annotations. For example, we would like to extend the system to support annotations for functions which only touch thread-local data and atomic functions which always execute as if they are not interleaved with operations of other threads. We would also like to build an annotation inference system; this system would enable application of the thread safety analysis to large amounts of legacy code. [1] C. Flanagan and S. N. Freund. Type-based race detection for Java. In Programming Language Design and Implementation (PLDI), June 2000. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110701/9dc0db84/attachment-0001.html From eli.friedman at gmail.com Fri Jul 1 03:18:02 2011 From: eli.friedman at gmail.com (Eli Friedman) Date: Fri, 1 Jul 2011 01:18:02 -0700 Subject: [cfe-dev] Possible incompatible gcc attribute parsing with GCC In-Reply-To: References: Message-ID: On Wed, Jun 29, 2011 at 2:32 PM, Xiaolong Tang wrote: > > Hi all, > > I am trying to see how far clang supports GNU attributes. It seems to > me that clang does not support declare attributes for members of > templates. Following is what I found: > > I use a very simple test code (in template_attribute.cpp): > > ?template class vector { > ?private: > ? ?T rep[10]; > ?public: > ? ?T top() { return rep[0]; } > ?}; > > ?template T vector::top() __attribute__ ((pure)); > > ?int main() > ?{ > ? ?vector a; > ? ?int r = a.top(); > ? ?int t = a.top(); > ? ?return r + t; > ?} > > With this command: > > ?g++ -O2 -cse -fno-inline -fdump-tree-all-all template_attribute.cpp > > the above code gets compiled and optimized (CSE works here). > > However, trying to compile the code with clang generates the following > message: > > ?16:15:55->clang++ -c template_attribute.cpp > > ?template_attribute.cpp:9:35: error: out-of-line declaration of a member must be > ? ? ? ?a definition [-Wout-of-line-declaration] > ?template T vector::top() __attribute__ ((pure)); > ? ? ? ? ? ? ? ? ? ? ? ? ~~~~~~~~~~~^ > ?template_attribute.cpp:9:35: warning: attribute declaration must precede > ? ? ? ?definition > ?template_attribute.cpp:5:5: note: previous definition is here > ? ?T top() { return rep[0]; } > ? ? ?^ > ?1 warning and 1 error generated. > > PS: clang version 2.9 (trunk 126848) Like the error says, your template declaration is at the very least strange... the more usual way to do what you're trying to do is to change the definition to "__attribute__ ((pure)) T top() { return rep[0]; }". -Eli From eliben at gmail.com Fri Jul 1 05:26:13 2011 From: eliben at gmail.com (Eli Bendersky) Date: Fri, 1 Jul 2011 13:26:13 +0300 Subject: [cfe-dev] libIndex documentation missing online Message-ID: Hello, The index library documentation (http://clang.llvm.org/docs/libIndex.html) returns a 404. I attempted to reach it via the link that exists in the internals manual (http://clang.llvm.org/docs/InternalsManual.html). Eli -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110701/f72aa062/attachment.html From xiaolong.snake at gmail.com Fri Jul 1 07:37:40 2011 From: xiaolong.snake at gmail.com (Xiaolong Tang) Date: Fri, 01 Jul 2011 07:37:40 -0500 Subject: [cfe-dev] Possible incompatible gcc attribute parsing with GCC In-Reply-To: References: Message-ID: Hi Eli, > > > > Hi all, > > > > I am trying to see how far clang supports GNU attributes. It seems to > > me that clang does not support declare attributes for members of > > templates. Following is what I found: > > > > I use a very simple test code (in template_attribute.cpp): > > > > ?template class vector { > > ?private: > > ? ?T rep[10]; > > ?public: > > ? ?T top() { return rep[0]; } > > ?}; > > > > ?template T vector::top() __attribute__ ((pure)); > > > > ?int main() > > ?{ > > ? ?vector a; > > ? ?int r = a.top(); > > ? ?int t = a.top(); > > ? ?return r + t; > > ?} > > > > With this command: > > > > ?g++ -O2 -cse -fno-inline -fdump-tree-all-all template_attribute.cpp > > > > the above code gets compiled and optimized (CSE works here). > > > > However, trying to compile the code with clang generates the following > > message: > > > > ?16:15:55->clang++ -c template_attribute.cpp > > > > ?template_attribute.cpp:9:35: error: out-of-line declaration of a member must be > > ? ? ? ?a definition [-Wout-of-line-declaration] > > ?template T vector::top() __attribute__ ((pure)); > > ? ? ? ? ? ? ? ? ? ? ? ? ~~~~~~~~~~~^ > > ?template_attribute.cpp:9:35: warning: attribute declaration must precede > > ? ? ? ?definition > > ?template_attribute.cpp:5:5: note: previous definition is here > > ? ?T top() { return rep[0]; } > > ? ? ?^ > > ?1 warning and 1 error generated. > > > > PS: clang version 2.9 (trunk 126848) > > Like the error says, your template declaration is at the very least > strange... the more usual way to do what you're trying to do is to > change the definition to "__attribute__ ((pure)) T top() { return > rep[0]; }". > Maybe I am abusing the attributes construct. However, we may need the ability to specify additional attributes for procedures outside the definition of classes in some cases, e.g., when the user who declares attributes for a class's procedures is not the class designer. Best, Xiaolong From harshgupta1992 at hotmail.com Fri Jul 1 08:54:57 2011 From: harshgupta1992 at hotmail.com (harsh gupta) Date: Fri, 1 Jul 2011 19:24:57 +0530 Subject: [cfe-dev] preprocessing and then deducing source location Message-ID: I am trying to infer some information about the location of a declaration in the source file. If i dont provide paths to the system headers, the source locations provided via the SourceLocation class are correct. However if i provide the paths to the system headers, then the line numbers that are provided seem to be of the preprocessed file. Is it possible to get the SourceLocation of declarations in the original file even after providing the system include paths ? If so how? Harsh Gupta -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110701/78f67041/attachment.html From dgregor at apple.com Fri Jul 1 11:36:18 2011 From: dgregor at apple.com (Douglas Gregor) Date: Fri, 01 Jul 2011 09:36:18 -0700 Subject: [cfe-dev] libIndex documentation missing online In-Reply-To: References: Message-ID: <9A209257-6AAA-4FBD-BC65-084F42931B12@apple.com> On Jul 1, 2011, at 3:26 AM, Eli Bendersky wrote: > Hello, > > The index library documentation (http://clang.llvm.org/docs/libIndex.html) returns a 404. I attempted to reach it via the link that exists in the internals manual (http://clang.llvm.org/docs/InternalsManual.html). Ah, sorry about that. The Index library is gone; I've removed this link to it. - Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110701/ae87815d/attachment.html From delesley at google.com Fri Jul 1 11:56:34 2011 From: delesley at google.com (Delesley Hutchins) Date: Fri, 1 Jul 2011 09:56:34 -0700 Subject: [cfe-dev] Proposal for thread safety attributes for Clang In-Reply-To: <2C9935343FDB104E8F3175A2729BC31402C22B@005-TK5MPN1-011.MGDADSK.autodesk.com> References: <2C9935343FDB104E8F3175A2729BC31402C22B@005-TK5MPN1-011.MGDADSK.autodesk.com> Message-ID: An extensible annotation framework would indeed be very useful. One of my long-term goals for the project is to implement something along the lines of "pluggable type systems", e.g. http://portal.acm.org/citation.cfm?id=1167479 http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.87.9425&rep=rep1&type=pdf in which various forms of static analysis could be implemented as independent "type-checking" passes which make use of annotations in the source code. Such a system would require an extensible annotation framework, along the lines of what you are describing. Our more immediate goal, of course, is to add support for a particular set of annotations, and a particular form of analysis, which is already used in a number of important projects here at Google. Once that has been implemented, we can look at how best to generalize it. -DeLesley On Thu, Jun 30, 2011 at 11:37 PM, Michael Han wrote: > We have implemented a tool based on clang at Autodesk to help developers > express their design decisions. The basic idea is the design decisions > implemented as a set of customized GNU style attributes can serve as metadta > to the fuctions, classes, etc and these metadata could be checked by clang > static analyzer to enforce specific data access pattern and call graph for > functions. We use this tool to help us parallelize some of our legacy C++ > code base, for example, by enforcing a specific code is purely functinal > style thus by definition is trivially thread safe. > > > > Our implementation touches many pieces of clang as we don?t find a less > intrusive way to get the attributes / metadata into clang?s type system and > AST. As a result we have to periodically merge our code base with Clang > official trunk, which sometimes is quite touch. The checker is easy to write > as it is very well decoupled from the rest of the system. > > > > I am wondering if this project would lead to an extensible annotation > framework for Clang so user could encode arbitary metadata into Clang AST. > That would be very useful and powerful for analysis code as it would involve > develpers more intimately by capturing the design decisions eariler. > > > > Cheers > > ~Michael > > From: cfe-dev-bounces at cs.uiuc.edu [mailto:cfe-dev-bounces at cs.uiuc.edu] On > Behalf Of Caitlin Sadowski > Sent: Friday, July 01, 2011 8:58 AM > To: cfe-dev at cs.uiuc.edu; Delesley Hutchins; Jaeheon Yi; Jeffrey Yasskin; > cormac at cs.ucsc.edu > Subject: [cfe-dev] Proposal for thread safety attributes for Clang > > > > The following is a proposal for a project we would like to contribute to > Clang. Feel free to discuss. > > > > Cheers, > > Caitlin Sadowski > > Google & University of California at Santa Cruz > > > > Thread Safety Attributes for Clang > > Summary > > We would like to add a set of thread safety attributes to Clang. These > attributes, based on a prior GCC implementation, will allow for checkable > documentation of basic locking policies in multithreaded programs. > > Background > The synchronization policies in modern multithreaded code may be poorly > documented, and incorrectly inferred by new developers. Furthermore, when > these policies are improperly followed they often lead to bugs which are > difficult to reproduce and diagnose. One strategy for avoiding concurrency > bugs is formal documentation of these synchronization policies. By writing > this documentation using attribute-based annotations, Clang can mechanically > check and warn about issues that could potentially result in race conditions > and deadlocks. > > Example > > A code sample which demonstrates two of the proposed annotations is below. > In this code sample, variables are protected by locks from the Mutex class. > This class has been annotated to specify the API used to lock and unlock. > > * GUARDED_BY specifies a particular lock should be held when accessing the > annotated variable. Violations of this locking policy may lead to data > races. > * ?ACQUIRED_AFTER annotations document the acquisition order between locks > that can be held simultaneously by a thread, by specify the locks that need > to be acquired before the annotated lock. Violations of this locking policy > may lead to deadlocks. > > ?1 #include "thread_annotations.h" > ?2 #define GUARDED_BY(x) __attribute__((GUARDED_BY(x))) > ?3 #define ACQUIRED_AFTER(x) __attribute__((ACQUIRED_AFTER(x))) > ?4 > ?5 Mutex mu1; > ?6 Mutex mu2 ACQUIRED_AFTER(mu1); > ?7 > ?8 int x GUARDED_BY(mu1); > ?9 int a GUARDED_BY(mu2); > ?10 > ?11 void foo() > ?12 { > 13 ??mu2.Lock(); > 14 ??mu1.Lock(); > 15 ??if (x > 2) > 16 ????a = x + 1; > 17 ??else > 18 ????a = x - 1; > 19 ??mu1.Unlock(); > 20 ??mu2.Unlock(); > 21 } > > Sample compiler output: > ex.cc: In function 'void foo()': > ex.cc:12: warning: Lock 'mu1' is acquired after lock 'mu2' (acquired at line > 14) but is annotated otherwise > > Previous Work > > As mentioned, thread safety annotations have been implemented in GCC. A full > list of the annotations and descriptions for them can be found here: > > http://gcc.gnu.org/wiki/ThreadSafetyAnnotation > https://docs.google.com/a/google.com/Doc?id=ddqtfwhb_0c49t6zgr > > These annotations have been in active use in Google?s C++ codebase for a > couple of years, so there is a large informal case study of their > usefulness. The ideas behind many of these annotations come originally from > a research paper [1]. > > Plan > > We are planning to re-implement the GCC thread safety attributes in Clang. > We will submit a series of patches to the cfe-commits mailing list. Our > current plan for this serie is as follows: > > 1) Basic parsing and semantic checking of the attributes which do not take > arguments. In other words, checking whether the attribute is applied in the > appropriate context (e.g. to a field, with no arguments). > 2) Basic parsing and semantic checking of the attributes which do take > arguments, but without parsing or checking the arguments themselves. At this > point, we will simply discard the tokens making up the arguments. > 3) Attribute argument parsing. > 4) Adding the thread safety analysis checks. We will teach the static > analysis-based warnings layer to warn for violations of the annotations > discussed on the links above. > > Future Projects > > Once we have this core set of thread safety annotations implemented, we have > several directions for future work we would like to pursue. These include > supporting additional types of annotations. For example, we would like to > extend the system to support annotations for functions which only touch > thread-local data and atomic functions which always execute as if they are > not interleaved with operations of other threads. We would also like to > build an annotation inference system; this system would enable application > of the thread safety analysis to large amounts of legacy code. > > [1] C. Flanagan and S. N. Freund. Type-based race detection for Java. In > Programming Language Design and Implementation (PLDI), June 2000. -- DeLesley Hutchins | Software Engineer | delesley at google.com | 505-206-0315 From eliben at gmail.com Fri Jul 1 12:14:44 2011 From: eliben at gmail.com (Eli Bendersky) Date: Fri, 1 Jul 2011 20:14:44 +0300 Subject: [cfe-dev] libIndex documentation missing online In-Reply-To: <9A209257-6AAA-4FBD-BC65-084F42931B12@apple.com> References: <9A209257-6AAA-4FBD-BC65-084F42931B12@apple.com> Message-ID: Thanks Doug, A short follow-up question - I assume it was formally replaced with the CIndex library (libclang). Is there any documentation for that planned or somewhere in preparation? Eli On Fri, Jul 1, 2011 at 19:36, Douglas Gregor wrote: > > On Jul 1, 2011, at 3:26 AM, Eli Bendersky wrote: > > Hello, > > The index library documentation (http://clang.llvm.org/docs/libIndex.html) > returns a 404. I attempted to reach it via the link that exists in the > internals manual (http://clang.llvm.org/docs/InternalsManual.html). > > > Ah, sorry about that. The Index library is gone; I've removed this link to > it. > > - Doug > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110701/0f8113ca/attachment.html From dgregor at apple.com Fri Jul 1 12:15:45 2011 From: dgregor at apple.com (Douglas Gregor) Date: Fri, 01 Jul 2011 10:15:45 -0700 Subject: [cfe-dev] libIndex documentation missing online In-Reply-To: References: <9A209257-6AAA-4FBD-BC65-084F42931B12@apple.com> Message-ID: <0E8E53BE-F276-4AFF-9034-6B899463ECBB@apple.com> On Jul 1, 2011, at 10:14 AM, Eli Bendersky wrote: > Thanks Doug, > A short follow-up question - I assume it was formally replaced with the CIndex library (libclang). Is there any documentation for that planned or somewhere in preparation? Yes, that's correct. See http://clang.llvm.org/doxygen/group__CINDEX.html - Doug > Eli > > > On Fri, Jul 1, 2011 at 19:36, Douglas Gregor wrote: > > On Jul 1, 2011, at 3:26 AM, Eli Bendersky wrote: > >> Hello, >> >> The index library documentation (http://clang.llvm.org/docs/libIndex.html) returns a 404. I attempted to reach it via the link that exists in the internals manual (http://clang.llvm.org/docs/InternalsManual.html). > > > Ah, sorry about that. The Index library is gone; I've removed this link to it. > > - Doug > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110701/4f697f97/attachment.html From zachw.foss at gmail.com Fri Jul 1 13:26:34 2011 From: zachw.foss at gmail.com (Zach Wheeler) Date: Fri, 1 Jul 2011 14:26:34 -0400 Subject: [cfe-dev] StringRef'ize APIs Message-ID: Can anyone suggest some APIs in Clang that particularly need StringRef'izing? ZJ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110701/17d82a8f/attachment.html From jediknil at belkadan.com Fri Jul 1 13:44:22 2011 From: jediknil at belkadan.com (Jordy Rose) Date: Fri, 1 Jul 2011 11:44:22 -0700 Subject: [cfe-dev] StringRef'ize APIs In-Reply-To: References: Message-ID: <16FD97E4-33C1-4BF9-A01F-13E4A0253160@belkadan.com> I'd suggest looking for places that use std::string. C++ strings are about as expensive as StringRefs to build from a char*, and (IIRC) aren't stack-based if you mutate them (unlike llvm::SmallString). In addition, methods that have std::string or const char * /arguments/ are probably more interesting than those that have std::string or const char * /return values/. A return value is just delaying a conversion until later, but an argument could be forcing a conversion that isn't necessary. (Of course, if a string is in StringRef form and then is returned as a std::string, that's just as bad.) It's definitely cool that you're doing this, but if you get bored, you can always look for low-hanging fruit in Bugzilla (http://llvm.org/bugs) to give yourself an excuse to learn about a specific part of Clang. (That's how I got started. *grin*) Jordy On Jul 1, 2011, at 11:26, Zach Wheeler wrote: > Can anyone suggest some APIs in Clang that particularly need StringRef'izing? > > ZJ > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From afish at apple.com Fri Jul 1 14:59:51 2011 From: afish at apple.com (Andrew Fish) Date: Fri, 01 Jul 2011 12:59:51 -0700 Subject: [cfe-dev] should -mno-sse -mno-mmx -msse -mmmx work? Message-ID: We are using clang for EFI firmware and in general it is a lot like a kernel and we turn off floating point. So the default build flags for our project set -mno-sse -mno-mmx. I'm trying to compile a standard C library that has a few functions with double in it, so I tried to reenable the floating point on the command line for just that package. I thought if you had -mno* and -m the last one wins? It does not seem to work? ~/work/Compiler>cat float.c double ErrorInBackEnd () { return 1.0; } ~/work/Compiler>clang -mno-sse -mno-mmx -msse -mmmx float.c fatal error: error in backend: SSE2 register return with SSE2 disabled Is this a bug? Or functioning as intended Andrew Fish From evan.cheng at apple.com Fri Jul 1 15:12:37 2011 From: evan.cheng at apple.com (Evan Cheng) Date: Fri, 01 Jul 2011 13:12:37 -0700 Subject: [cfe-dev] should -mno-sse -mno-mmx -msse -mmmx work? In-Reply-To: References: Message-ID: <130E89DB-FD23-4793-A017-79048B39AE4A@apple.com> SSE register return with SSE disabled Evan On Jul 1, 2011, at 12:59 PM, Andrew Fish wrote: > We are using clang for EFI firmware and in general it is a lot like a kernel and we turn off floating point. So the default build flags for our project set -mno-sse -mno-mmx. I'm trying to compile a standard C library that has a few functions with double in it, so I tried to reenable the floating point on the command line for just that package. I thought if you had -mno* and -m the last one wins? It does not seem to work? > > ~/work/Compiler>cat float.c > double > ErrorInBackEnd () > { > return 1.0; > } > ~/work/Compiler>clang -mno-sse -mno-mmx -msse -mmmx float.c > fatal error: error in backend: SSE2 register return with SSE2 disabled > > Is this a bug? Or functioning as intended > > Andrew Fish > > > > > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From dgregor at apple.com Fri Jul 1 17:41:29 2011 From: dgregor at apple.com (Douglas Gregor) Date: Fri, 01 Jul 2011 15:41:29 -0700 Subject: [cfe-dev] Initial *-rtems* Target Support In-Reply-To: <4E0CE57D.7030400@oarcorp.com> References: <4E0CE57D.7030400@oarcorp.com> Message-ID: <824EBF49-4D9E-483E-B636-15BEC92C9CD2@apple.com> On Jun 30, 2011, at 2:07 PM, Joel Sherrill wrote: > Hi, > > Some of us over in the RTEMS community > (http://www.rtems.org) are curious about the > possibility of using clang to compile RTEMS. > For those who don't know RTEMS is an embedded > real-time operating system which targets about > 15 architectures and many more CPU models. > So this is the beginnings of investigating using > clang on RTEMS. Very cool. > As background, the RTEMS targets in gcc are usually > very close cousins to the bare metal targets like > CPU-*-elf* or CPU-*-eabi*. We use newlib and build > newlib at the same time as gcc. > > clang does not support most of the architectures > supported by RTEMS. The intersection is x86, > mips, powerpc, sparc, sparcv9, arm, thumb, and blackfin. > Iin some cases, it does not cover the architectural > variants we care most about. For example, the > space community uses hardened SPARC V7 CPUs a lot > with RTEMS and only V8 is supported by clang right now. > The first goal is to get RTEMS itself to compile > with clang targeting i386 w/FPU. > > I have managed to get newlib built and installed using > clang to target i386-rtems4.11. Building RTEMS is next > on the list and I will need assistance from others to > get through this hurdle. In the interest of being open > and hopefully getting help, I am submitting patches > which should be OK to merge. I don't think they are > too radical. :) > > The attached patches add initial *-*-rtems* target > support. I modelled it after the FreeBSD support > which supports multiple architectures. > > I don't know what format you want commit logs in but > this is the information: > > Add initial *-*-rtems* target. > > The only tricky part to the patch is that RTEMS tools > are never self-hosted so we do NOT want /usr/include > ever added to an include search path. That's in > lib/Frontend/InitHeaderSearch.cpp around line 590. > > Hopefully this isn't too bad to get merged. :) Looks fine to me. I've committee the patches to LLVM (r134282) and Clang (r134283). - Doug From supertri at google.com Fri Jul 1 17:48:30 2011 From: supertri at google.com (Caitlin Sadowski) Date: Fri, 1 Jul 2011 15:48:30 -0700 Subject: [cfe-dev] Proposal for thread safety attributes for Clang In-Reply-To: References: Message-ID: Here is the first thread safety patch. Note that this patch depends on prior refactoring patches I sent out. If you want to review it, you can go to: http://codereview.appspot.com/4667054 Cheers, Caitlin On Thu, Jun 30, 2011 at 5:57 PM, Caitlin Sadowski wrote: > The following is a proposal for a project we would like to contribute to > Clang. Feel free to discuss. > > Cheers, > > Caitlin Sadowski > Google & University of California at Santa Cruz > > Thread Safety Attributes for Clang > > Summary > > We would like to add a set of thread safety attributes to Clang. These > attributes, based on a prior GCC implementation, will allow for checkable > documentation of basic locking policies in multithreaded programs. > > Background > The synchronization policies in modern multithreaded code may be poorly > documented, and incorrectly inferred by new developers. Furthermore, when > these policies are improperly followed they often lead to bugs which are > difficult to reproduce and diagnose. One strategy for avoiding concurrency > bugs is formal documentation of these synchronization policies. By writing > this documentation using attribute-based annotations, Clang can mechanically > check and warn about issues that could potentially result in race > conditions and deadlocks. > > Example > > A code sample which demonstrates two of the proposed annotations is below. > In this code sample, variables are protected by locks from the Mutex class. > This class has been annotated to specify the API used to lock and unlock. > > * GUARDED_BY specifies a particular lock should be held when accessing the > annotated variable. Violations of this locking policy may lead to data > races. > * ACQUIRED_AFTER annotations document the acquisition order between locks > that can be held simultaneously by a thread, by specify the locks that need > to be acquired before the annotated lock. Violations of this locking policy > may lead to deadlocks. > > 1 #include "thread_annotations.h" > 2 #define GUARDED_BY(x) __attribute__((GUARDED_BY(x))) > 3 #define ACQUIRED_AFTER(x) __attribute__((ACQUIRED_AFTER(x))) > 4 > 5 Mutex mu1; > 6 Mutex mu2 ACQUIRED_AFTER(mu1); > 7 > 8 int x GUARDED_BY(mu1); > 9 int a GUARDED_BY(mu2); > 10 > 11 void foo() > 12 { > 13 mu2.Lock(); > 14 mu1.Lock(); > 15 if (x > 2) > 16 a = x + 1; > 17 else > 18 a = x - 1; > 19 mu1.Unlock(); > 20 mu2.Unlock(); > 21 } > > Sample compiler output: > ex.cc: In function 'void foo()': > ex.cc:12: warning: Lock 'mu1' is acquired after lock 'mu2' (acquired at > line 14) but is annotated otherwise > > Previous Work > > As mentioned, thread safety annotations have been implemented in GCC. A > full list of the annotations and descriptions for them can be found here: > > http://gcc.gnu.org/wiki/ThreadSafetyAnnotation > https://docs.google.com/a/google.com/Doc?id=ddqtfwhb_0c49t6zgr > > These annotations have been in active use in Google?s C++ codebase for a > couple of years, so there is a large informal case study of their > usefulness. The ideas behind many of these annotations come originally from > a research paper [1]. > > Plan > > We are planning to re-implement the GCC thread safety attributes in Clang. > We will submit a series of patches to the cfe-commits mailing list. Our > current plan for this serie is as follows: > > 1) Basic parsing and semantic checking of the attributes which do not take > arguments. In other words, checking whether the attribute is applied in the > appropriate context (e.g. to a field, with no arguments). > 2) Basic parsing and semantic checking of the attributes which do take > arguments, but without parsing or checking the arguments themselves. At this > point, we will simply discard the tokens making up the arguments. > 3) Attribute argument parsing. > 4) Adding the thread safety analysis checks. We will teach the static > analysis-based warnings layer to warn for violations of the annotations > discussed on the links above. > > Future Projects > > Once we have this core set of thread safety annotations implemented, we > have several directions for future work we would like to pursue. These > include supporting additional types of annotations. For example, we would > like to extend the system to support annotations for functions which only > touch thread-local data and atomic functions which always execute as if they > are not interleaved with operations of other threads. We would also like to > build an annotation inference system; this system would enable application > of the thread safety analysis to large amounts of legacy code. > > [1] C. Flanagan and S. N. Freund. Type-based race detection for Java. In > Programming Language Design and Implementation (PLDI), June 2000. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110701/49cd7a15/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: threadsafety_parsing_easyattrs.patch Type: text/x-patch Size: 16979 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110701/49cd7a15/attachment-0001.bin From eli.friedman at gmail.com Fri Jul 1 19:36:30 2011 From: eli.friedman at gmail.com (Eli Friedman) Date: Fri, 1 Jul 2011 17:36:30 -0700 Subject: [cfe-dev] should -mno-sse -mno-mmx -msse -mmmx work? In-Reply-To: References: Message-ID: On Fri, Jul 1, 2011 at 12:59 PM, Andrew Fish wrote: > We are using clang for EFI firmware and in general it is a lot like a kernel and we turn off floating point. So the default build flags for our project set -mno-sse -mno-mmx. I'm trying to compile a standard C library that has a few functions with double in it, so I tried to reenable the floating point on the command line for just that package. I thought if you had -mno* and -m the last one wins? ?It does not seem to work? > > ~/work/Compiler>cat float.c > double > ErrorInBackEnd () > { > ?return 1.0; > } > ~/work/Compiler>clang -mno-sse -mno-mmx -msse -mmmx float.c > fatal error: error in backend: SSE2 register return with SSE2 disabled > > Is this a bug? Or functioning as intended Bug, at least in the sense that we weren't gcc-compatible; r134296. (As a workaround, you could specify -msse2.) -Eli From ryuuta at gmail.com Fri Jul 1 21:09:20 2011 From: ryuuta at gmail.com (ryuuta) Date: Sat, 2 Jul 2011 11:09:20 +0900 Subject: [cfe-dev] [libc++] clang / libc++ fail to compile the code with boost Message-ID: Hi, I bet the problem is in boost implementation but I'm not 100% sure whether the issue is really on boost side or not. Compiling the following code $ cat boost_thread.cpp #include int main() { return 0; } $ clang++ -stdlib=libc++ ./boost_thread.cpp In file included from ./boost_thread.cpp:1: In file included from /usr/include/boost/thread.hpp:24: In file included from /usr/include/boost/thread/future.hpp:14: In file included from /usr/include/boost/exception_ptr.hpp:9: In file included from /usr/include/boost/exception/detail/exception_ptr.hpp:19: In file included from /usr/include/boost/exception/info.hpp:15: In file included from /usr/include/boost/exception/to_string_stub.hpp:15: In file included from /usr/include/boost/exception/detail/object_hex_dump.hpp:14: /usr/include/boost/exception/detail/type_info.hpp:53:9: error: cannot define the implicit default assignment operator for 'boost::exception_detail::type_info_', because non-static reference member 'type_' can't use default assignment operator type_info_ ^ /usr/include/c++/v1/__tree:1244:35: note: in instantiation of member function 'std::__1::pair >::operator=' requested here __cache->__value_ = *__first; ^ /usr/include/c++/v1/__tree:1185:9: note: in instantiation of function template specialization 'std::__1::__tree >, std::__1::__map_value_compare, std::__1::less, true>, std::__1::allocator > > >::__assign_multi >, const std::__1::__tree_node >, void *> *, long> >' requested here __assign_multi(__t.begin(), __t.end()); ^ /usr/include/c++/v1/map:760:21: note: in instantiation of member function 'std::__1::__tree >, std::__1::__map_value_compare, std::__1::less, true>, std::__1::allocator > > >::operator=' requested here __tree_ = __m.__tree_; ^ /usr/include/boost/exception/info.hpp:160:26: note: in instantiation of member function 'std::__1::map, std::__1::less, std::__1::allocator > > >::operator=' requested here c->info_ = info_; ^ /usr/include/boost/exception/detail/type_info.hpp:55:41: note: declared here detail::sp_typeinfo const & type_; ^ /usr/include/c++/v1/utility:247:15: note: implicit default copy assignment operator for 'boost::exception_detail::type_info_' first required here first = __p.first; ^ 1 error generated. =================================== Since $ clang++ -stdlib=libstdc++ ./boost_thread.cpp has worked perfectly fine my guess is that boost_thread.hpp doesn't strictly conform to the standard. Any comment will be appreciated. Thanks, Ryuta p.s. My boost library is 1.46.1. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110702/2570db39/attachment.html From eli.friedman at gmail.com Fri Jul 1 21:55:55 2011 From: eli.friedman at gmail.com (Eli Friedman) Date: Fri, 1 Jul 2011 19:55:55 -0700 Subject: [cfe-dev] [libc++] clang / libc++ fail to compile the code with boost In-Reply-To: References: Message-ID: On Fri, Jul 1, 2011 at 7:09 PM, ryuuta wrote: > Hi, > I bet the problem is in boost implementation but > I'm not 100% sure whether the issue is really on boost side or not. > Compiling the following code > $ cat boost_thread.cpp > #include > int main() > { > ? return 0; > } > $?clang++ -stdlib=libc++ ./boost_thread.cpp > In file included from ./boost_thread.cpp:1: > In file included from /usr/include/boost/thread.hpp:24: > In file included from /usr/include/boost/thread/future.hpp:14: > In file included from /usr/include/boost/exception_ptr.hpp:9: > In file included from > /usr/include/boost/exception/detail/exception_ptr.hpp:19: > In file included from /usr/include/boost/exception/info.hpp:15: > In file included from /usr/include/boost/exception/to_string_stub.hpp:15: > In file included from > /usr/include/boost/exception/detail/object_hex_dump.hpp:14: > /usr/include/boost/exception/detail/type_info.hpp:53:9: error: cannot define > the implicit default assignment operator for > ? ? ? 'boost::exception_detail::type_info_', because non-static reference > member 'type_' can't use default assignment operator > ? ? ? ? type_info_ > ? ? ? ? ^ > /usr/include/c++/v1/__tree:1244:35: note: in instantiation of member > function 'std::__1::pair ? ? ? boost::shared_ptr >>::operator=' requested here > ? ? ? ? ? ? ? ? __cache->__value_ = *__first; > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ^ > /usr/include/c++/v1/__tree:1185:9: note: in instantiation of function > template specialization > ? ? ? 'std::__1::__tree boost::shared_ptr >, > ? ? ? std::__1::__map_value_compare boost::shared_ptr, > ? ? ? std::__1::less, true>, > std::__1::allocator ? ? ? boost::shared_ptr > > > >>::__assign_multi ? ? ? boost::shared_ptr >, const > std::__1::__tree_node ? ? ? boost::shared_ptr >, void *> > *, long> >' requested here > ? ? ? ? __assign_multi(__t.begin(), __t.end()); > ? ? ? ? ^ > /usr/include/c++/v1/map:760:21: note: in instantiation of member function > 'std::__1::__tree ? ? ? boost::shared_ptr >, > std::__1::__map_value_compare ? ? ? boost::shared_ptr, > std::__1::less, true>, > > std::__1::allocator boost::shared_ptr > > >>::operator=' > ? ? ? requested here > ? ? ? ? ? ? __tree_ = __m.__tree_; > ? ? ? ? ? ? ? ? ? ? ^ > /usr/include/boost/exception/info.hpp:160:26: note: in instantiation of > member function 'std::__1::map ? ? ? boost::shared_ptr, > std::__1::less, > ? ? ? std::__1::allocator boost::exception_detail::type_info_, > boost::shared_ptr > > > ? ? ? >::operator=' requested here > ? ? ? ? ? ? ? ? c->info_ = info_; > ? ? ? ? ? ? ? ? ? ? ? ? ?^ > /usr/include/boost/exception/detail/type_info.hpp:55:41: note: declared here > ? ? ? ? ? ? detail::sp_typeinfo const & type_; > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ^ > /usr/include/c++/v1/utility:247:15: note: implicit default copy assignment > operator for 'boost::exception_detail::type_info_' first required here > ? ? ? ? first = __p.first; > ? ? ? ? ? ? ? ^ > 1 error generated. > =================================== > Since > $ clang++ -stdlib=libstdc++ ./boost_thread.cpp > has worked perfectly fine my guess is that boost_thread.hpp doesn't strictly > conform to the standard. > Any comment will be appreciated. > Thanks, > Ryuta > p.s. > My boost library is 1.46.1. Testcase without boost: #include struct A { int& x; explicit A(int); public: bool operator<(const A& other) const {return x < other.x; }}; void f(A* x) { std::map y, z; z = y; } This looks like a boost bug to me... as far as I can tell, the Key type of an std::map is required to be assignable if you're assigning one map to another (although the implementation isn't required to actually use that assignment operator). -Eli From eli.friedman at gmail.com Sat Jul 2 00:40:11 2011 From: eli.friedman at gmail.com (Eli Friedman) Date: Fri, 1 Jul 2011 22:40:11 -0700 Subject: [cfe-dev] [libc++] clang / libc++ fail to compile the code with boost In-Reply-To: References: Message-ID: On Fri, Jul 1, 2011 at 7:55 PM, Eli Friedman wrote: > On Fri, Jul 1, 2011 at 7:09 PM, ryuuta wrote: >> Hi, >> I bet the problem is in boost implementation but >> I'm not 100% sure whether the issue is really on boost side or not. >> Compiling the following code >> $ cat boost_thread.cpp >> #include >> int main() >> { >> ? return 0; >> } >> $?clang++ -stdlib=libc++ ./boost_thread.cpp >> In file included from ./boost_thread.cpp:1: >> In file included from /usr/include/boost/thread.hpp:24: >> In file included from /usr/include/boost/thread/future.hpp:14: >> In file included from /usr/include/boost/exception_ptr.hpp:9: >> In file included from >> /usr/include/boost/exception/detail/exception_ptr.hpp:19: >> In file included from /usr/include/boost/exception/info.hpp:15: >> In file included from /usr/include/boost/exception/to_string_stub.hpp:15: >> In file included from >> /usr/include/boost/exception/detail/object_hex_dump.hpp:14: >> /usr/include/boost/exception/detail/type_info.hpp:53:9: error: cannot define >> the implicit default assignment operator for >> ? ? ? 'boost::exception_detail::type_info_', because non-static reference >> member 'type_' can't use default assignment operator >> ? ? ? ? type_info_ >> ? ? ? ? ^ >> /usr/include/c++/v1/__tree:1244:35: note: in instantiation of member >> function 'std::__1::pair> ? ? ? boost::shared_ptr >>>::operator=' requested here >> ? ? ? ? ? ? ? ? __cache->__value_ = *__first; >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ^ >> /usr/include/c++/v1/__tree:1185:9: note: in instantiation of function >> template specialization >> ? ? ? 'std::__1::__tree> boost::shared_ptr >, >> ? ? ? std::__1::__map_value_compare> boost::shared_ptr, >> ? ? ? std::__1::less, true>, >> std::__1::allocator> ? ? ? boost::shared_ptr > > >> >>>::__assign_multi> ? ? ? boost::shared_ptr >, const >> std::__1::__tree_node> ? ? ? boost::shared_ptr >, void *> >> *, long> >' requested here >> ? ? ? ? __assign_multi(__t.begin(), __t.end()); >> ? ? ? ? ^ >> /usr/include/c++/v1/map:760:21: note: in instantiation of member function >> 'std::__1::__tree> ? ? ? boost::shared_ptr >, >> std::__1::__map_value_compare> ? ? ? boost::shared_ptr, >> std::__1::less, true>, >> >> std::__1::allocator> boost::shared_ptr > > >>>::operator=' >> ? ? ? requested here >> ? ? ? ? ? ? __tree_ = __m.__tree_; >> ? ? ? ? ? ? ? ? ? ? ^ >> /usr/include/boost/exception/info.hpp:160:26: note: in instantiation of >> member function 'std::__1::map> ? ? ? boost::shared_ptr, >> std::__1::less, >> ? ? ? std::__1::allocator> boost::exception_detail::type_info_, >> boost::shared_ptr > > >> ? ? ? >::operator=' requested here >> ? ? ? ? ? ? ? ? c->info_ = info_; >> ? ? ? ? ? ? ? ? ? ? ? ? ?^ >> /usr/include/boost/exception/detail/type_info.hpp:55:41: note: declared here >> ? ? ? ? ? ? detail::sp_typeinfo const & type_; >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ^ >> /usr/include/c++/v1/utility:247:15: note: implicit default copy assignment >> operator for 'boost::exception_detail::type_info_' first required here >> ? ? ? ? first = __p.first; >> ? ? ? ? ? ? ? ^ >> 1 error generated. >> =================================== >> Since >> $ clang++ -stdlib=libstdc++ ./boost_thread.cpp >> has worked perfectly fine my guess is that boost_thread.hpp doesn't strictly >> conform to the standard. >> Any comment will be appreciated. >> Thanks, >> Ryuta >> p.s. >> My boost library is 1.46.1. > > Testcase without boost: > > #include > struct A { int& x; explicit A(int); public: bool operator<(const A& > other) const {return x < other.x; }}; > void f(A* x) { std::map y, z; z = y; } > > This looks like a boost bug to me... as far as I can tell, the Key > type of an std::map is required to be assignable if you're assigning > one map to another (although the implementation isn't required to > actually use that assignment operator). Err, I take that back... I really have no clue whether it's required. -Eli From eliben at gmail.com Sat Jul 2 01:14:04 2011 From: eliben at gmail.com (Eli Bendersky) Date: Sat, 2 Jul 2011 09:14:04 +0300 Subject: [cfe-dev] tests of bindings/python fail? Message-ID: On a clean checkout + build of Clang from trunk, taken yesterday, I run: ~/test/llvm/tools/clang/bindings/python$ nosetests -v tests.cindex.test_cursor.test_get_children ... FAIL tests.cindex.test_cursor_kind.test_name ... ok tests.cindex.test_cursor_kind.test_get_all_kinds ... ok Check that every kind classifies to exactly one group. ... FAIL tests.cindex.test_diagnostics.test_diagnostic_warning ... ok tests.cindex.test_diagnostics.test_diagnostic_note ... ok tests.cindex.test_diagnostics.test_diagnostic_fixit ... ok tests.cindex.test_diagnostics.test_diagnostic_range ... ok tests.cindex.test_index.test_create ... ok tests.cindex.test_index.test_parse ... ok tests.cindex.test_translation_unit.test_spelling ... ok tests.cindex.test_translation_unit.test_cursor ... ok tests.cindex.test_translation_unit.test_parse_arguments ... ok tests.cindex.test_translation_unit.test_reparse_arguments ... ok tests.cindex.test_translation_unit.test_unsaved_files ... ok tests.cindex.test_translation_unit.test_unsaved_files_2 ... ok tests.cindex.test_translation_unit.test_includes ... FAIL ... Is this something with my setup, or do others see these failures as well? Eli -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110702/72c7dbc7/attachment.html From jonathan.sauer at gmx.de Sat Jul 2 01:53:28 2011 From: jonathan.sauer at gmx.de (Jonathan Sauer) Date: Sat, 2 Jul 2011 08:53:28 +0200 Subject: [cfe-dev] [cfe-commits] r134302 - /cfe/trunk/lib/Sema/AnalysisBasedWarnings.cpp In-Reply-To: <20110702005918.F37CF2A6C12C@llvm.org> References: <20110702005918.F37CF2A6C12C@llvm.org> Message-ID: <7529ED41-3592-4ADB-BE44-F7C4FD3A9DCC@gmx.de> Am 02.07.2011 um 02:59 schrieb Douglas Gregor: > When producing -Wuninitialized Fix-Its for pointers, prefer " = NULL" > over "= 0". Fixes . What about when in C++0x mode, suggest "nullptr" (which is always defined) instead of "NULL"? nullptr is C++0x's safer alternative to NULL, so it would make sense to recommend it. Jonathan From breese at mail1.stofanet.dk Sat Jul 2 04:24:07 2011 From: breese at mail1.stofanet.dk (Bjorn Reese) Date: Sat, 02 Jul 2011 11:24:07 +0200 Subject: [cfe-dev] Proposal for thread safety attributes for Clang In-Reply-To: References: Message-ID: <4E0EE3B7.7020103@mail1.stofanet.dk> Caitlin. The two problems you address can be handled with templates instead of annotations. While the techniques mentioned below do not solve all thread-safety problems, they do solve the most common ones that I have encountered. And none of them requires extensions to the compiler. ACQUIRED_AFTER: Some deadlocks occur because you need to lock two mutexes, A and B, and you accidentially lock A before B in one function and B before A in another function. Such deadlocks can be avoided with the Boost.Thread locking functions [1], as it guarantees that a list of mutexes always is locked in the same order, regardless of the order you list them. GUARDED_BY: It is true that the C++ compiler does not know which mutex guards what variables, and therefore cannot alert you if you, say, use a variable without locking its mutex. I solved this problem in a commercial project by defining two templates: a guard and an accessor. The guard contained the mutex and the variable (or struct of variables) as a private member, and only the accessor could access it. The accessor would lock and unlock the mutex in a RAII manner. An example using this technique could look like this: class Alpha { public: int GetValue() const { const_unique_access value(valueGuard); return *value; } void SetValue(int v) { unique_access value(valueGuard); *value = v; } private: unique_access_guard valueGuard; }; This solution shares some traits with Anthony Williams' Synchronized Values [2]. [1] http://www.boost.org/doc/libs/1_46_1/doc/html/thread/synchronization.html#thread.synchronization.lock_functions [2] http://drdobbs.com/cpp/225200269 From vanboxem.ruben at gmail.com Sat Jul 2 08:08:03 2011 From: vanboxem.ruben at gmail.com (Ruben Van Boxem) Date: Sat, 2 Jul 2011 15:08:03 +0200 Subject: [cfe-dev] MinGW(-w64) fixes to InitHeaderSearch.cpp and float.h In-Reply-To: References: <3ECBA685-F064-4107-A4B5-454CE4E40BAB@apple.com> Message-ID: 2011/6/27 Ruben Van Boxem : > Op 27 jun. 2011 17:51 schreef "Douglas Gregor" het volgende: >> >> On Jun 25, 2011, at 7:51 AM, Ruben Van Boxem wrote: >> >>> Hi, >>> >>> I bring fixes for MinGW(-w64) Clang users: >>> >>> 1. InitHeaderSearch.cpp: add a HeaderSearchOptions argument to >>> AddDefaultCXXIncludePaths (AddDefaultCIncludePaths already had this, >>> seems only logical to have it here) and use ResourceDir to find the >>> sysroot of where Clang.exe is located. From there, add the >>> x86_64-w64-mingw32 and i686-w64-mingw32 include paths for C and C++. >>> All mingw-w64 toolchains are built --with-sysroot, and thus >>> relocatable, so this change will always find the accompanying headers. >> >> I've committed this part as r133911. >> >>> 2. float.h: MinGW needs an #include_next, because as described on this >>> page (http://msdn.microsoft.com/en-us/library/y0ybw9fy.aspx) there are >>> non-standard extensions to float.h which are expected on Windows, and >>> MinGW provides these declarations in their system header. GCC's >>> float.h is "fixinclude"d to include_next the system header. Note that >>> a trivial change is needed in mingw-w64's float.h, and that change >>> will be committed as soon as Clang's header does what it's supposed to >>> do. >> >> >> If we're including MinGW's float.h first, then our own definitions of all of the standard float.h macros are going to stomp on the ones that come from MinGW's float.h. I think that's a reasonable thing to do, but if that's the intent, I'd prefer to have #undef's in our own float.h to make it explicit that this is what we're doing (and so that our own headers don't generate warnings, even if they're suppressed). > > I just copied that behavior (and the comment) from , but I > know that mingw-w64's float.h header does #undef everything it > redefines, so it would perhaps be better if the #include_next in > Clang's float.h came at the end. Then nothing else needs to change > much. > > Ruben > I have attached a new patch with two new GCC versions for the include paths, and I moved the #include_next to the end. My previous testing proved this would work if the mingw-w64 headers is adapted to detect Clang as well (will happen as soon as Clang's header is patched). If someone would be so kind to apply these minor changes, I'd be very happy. Thanks! Ruben PS: And once these changes are in, you can expect a CLang package to be provided by me here for use with mingw-w64: http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/rubenvb/ -------------- next part -------------- A non-text attachment was scrubbed... Name: mingw.patch Type: application/octet-stream Size: 1088 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110702/8da0fb83/attachment.obj From dgregor at apple.com Sat Jul 2 10:02:46 2011 From: dgregor at apple.com (Douglas Gregor) Date: Sat, 02 Jul 2011 08:02:46 -0700 Subject: [cfe-dev] MinGW(-w64) fixes to InitHeaderSearch.cpp and float.h In-Reply-To: References: <3ECBA685-F064-4107-A4B5-454CE4E40BAB@apple.com> Message-ID: <0F8A7282-8FCF-41CB-B73E-4DB7FAD04754@apple.com> On Jul 2, 2011, at 6:08 AM, Ruben Van Boxem wrote: > 2011/6/27 Ruben Van Boxem : >> Op 27 jun. 2011 17:51 schreef "Douglas Gregor" het volgende: >>> >>> On Jun 25, 2011, at 7:51 AM, Ruben Van Boxem wrote: >>> >>>> Hi, >>>> >>>> I bring fixes for MinGW(-w64) Clang users: >>>> >>>> 1. InitHeaderSearch.cpp: add a HeaderSearchOptions argument to >>>> AddDefaultCXXIncludePaths (AddDefaultCIncludePaths already had this, >>>> seems only logical to have it here) and use ResourceDir to find the >>>> sysroot of where Clang.exe is located. From there, add the >>>> x86_64-w64-mingw32 and i686-w64-mingw32 include paths for C and C++. >>>> All mingw-w64 toolchains are built --with-sysroot, and thus >>>> relocatable, so this change will always find the accompanying headers. >>> >>> I've committed this part as r133911. >>> >>>> 2. float.h: MinGW needs an #include_next, because as described on this >>>> page (http://msdn.microsoft.com/en-us/library/y0ybw9fy.aspx) there are >>>> non-standard extensions to float.h which are expected on Windows, and >>>> MinGW provides these declarations in their system header. GCC's >>>> float.h is "fixinclude"d to include_next the system header. Note that >>>> a trivial change is needed in mingw-w64's float.h, and that change >>>> will be committed as soon as Clang's header does what it's supposed to >>>> do. >>> >>> >>> If we're including MinGW's float.h first, then our own definitions of all of the standard float.h macros are going to stomp on the ones that come from MinGW's float.h. I think that's a reasonable thing to do, but if that's the intent, I'd prefer to have #undef's in our own float.h to make it explicit that this is what we're doing (and so that our own headers don't generate warnings, even if they're suppressed). >> >> I just copied that behavior (and the comment) from , but I >> know that mingw-w64's float.h header does #undef everything it >> redefines, so it would perhaps be better if the #include_next in >> Clang's float.h came at the end. Then nothing else needs to change >> much. >> >> Ruben >> > > I have attached a new patch with two new GCC versions for the include > paths, and I moved the #include_next to the end. My previous > testing proved this would work if the mingw-w64 headers is adapted to > detect Clang as well (will happen as soon as Clang's header is > patched). If someone would be so kind to apply these minor changes, > I'd be very happy. My suggestion would have been to #include_next at the beginning, then #undef everything that Clang's is going to define, so that Clang is guaranteed to get its own definitions of the standard macros. Did this not work? The patch you attached is something different (a CMake change for TableGen). Is that change still necessary? - Doug > Thanks! > > Ruben > > PS: And once these changes are in, you can expect a CLang package to > be provided by me here for use with mingw-w64: > http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/rubenvb/ > From dgregor at apple.com Sat Jul 2 10:10:18 2011 From: dgregor at apple.com (Douglas Gregor) Date: Sat, 02 Jul 2011 08:10:18 -0700 Subject: [cfe-dev] [libc++] clang / libc++ fail to compile the code with boost In-Reply-To: References: Message-ID: <699E04A3-DD73-4E47-A297-9AB252E813D7@apple.com> On Jul 1, 2011, at 7:55 PM, Eli Friedman wrote: > On Fri, Jul 1, 2011 at 7:09 PM, ryuuta wrote: >> Hi, >> I bet the problem is in boost implementation but >> I'm not 100% sure whether the issue is really on boost side or not. >> Compiling the following code >> $ cat boost_thread.cpp >> #include >> int main() >> { >> return 0; >> } >> $ clang++ -stdlib=libc++ ./boost_thread.cpp >> In file included from ./boost_thread.cpp:1: >> In file included from /usr/include/boost/thread.hpp:24: >> In file included from /usr/include/boost/thread/future.hpp:14: >> In file included from /usr/include/boost/exception_ptr.hpp:9: >> In file included from >> /usr/include/boost/exception/detail/exception_ptr.hpp:19: >> In file included from /usr/include/boost/exception/info.hpp:15: >> In file included from /usr/include/boost/exception/to_string_stub.hpp:15: >> In file included from >> /usr/include/boost/exception/detail/object_hex_dump.hpp:14: >> /usr/include/boost/exception/detail/type_info.hpp:53:9: error: cannot define >> the implicit default assignment operator for >> 'boost::exception_detail::type_info_', because non-static reference >> member 'type_' can't use default assignment operator >> type_info_ >> ^ >> /usr/include/c++/v1/__tree:1244:35: note: in instantiation of member >> function 'std::__1::pair> boost::shared_ptr >>> ::operator=' requested here >> __cache->__value_ = *__first; >> ^ >> /usr/include/c++/v1/__tree:1185:9: note: in instantiation of function >> template specialization >> 'std::__1::__tree> boost::shared_ptr >, >> std::__1::__map_value_compare> boost::shared_ptr, >> std::__1::less, true>, >> std::__1::allocator> boost::shared_ptr > > >> >>> ::__assign_multi> boost::shared_ptr >, const >> std::__1::__tree_node> boost::shared_ptr >, void *> >> *, long> >' requested here >> __assign_multi(__t.begin(), __t.end()); >> ^ >> /usr/include/c++/v1/map:760:21: note: in instantiation of member function >> 'std::__1::__tree> boost::shared_ptr >, >> std::__1::__map_value_compare> boost::shared_ptr, >> std::__1::less, true>, >> >> std::__1::allocator> boost::shared_ptr > > >>> ::operator=' >> requested here >> __tree_ = __m.__tree_; >> ^ >> /usr/include/boost/exception/info.hpp:160:26: note: in instantiation of >> member function 'std::__1::map> boost::shared_ptr, >> std::__1::less, >> std::__1::allocator> boost::exception_detail::type_info_, >> boost::shared_ptr > > >> >::operator=' requested here >> c->info_ = info_; >> ^ >> /usr/include/boost/exception/detail/type_info.hpp:55:41: note: declared here >> detail::sp_typeinfo const & type_; >> ^ >> /usr/include/c++/v1/utility:247:15: note: implicit default copy assignment >> operator for 'boost::exception_detail::type_info_' first required here >> first = __p.first; >> ^ >> 1 error generated. >> =================================== >> Since >> $ clang++ -stdlib=libstdc++ ./boost_thread.cpp >> has worked perfectly fine my guess is that boost_thread.hpp doesn't strictly >> conform to the standard. >> Any comment will be appreciated. >> Thanks, >> Ryuta >> p.s. >> My boost library is 1.46.1. > > Testcase without boost: > > #include > struct A { int& x; explicit A(int); public: bool operator<(const A& > other) const {return x < other.x; }}; > void f(A* x) { std::map y, z; z = y; } > > This looks like a boost bug to me... as far as I can tell, the Key > type of an std::map is required to be assignable if you're assigning > one map to another (although the implementation isn't required to > actually use that assignment operator). C++0x [container.requirements.general] is fairly clear that assigning a container requires the element type to be move assignable. This is a Boost bug. - Doug From dgregor at apple.com Sat Jul 2 10:16:13 2011 From: dgregor at apple.com (Douglas Gregor) Date: Sat, 02 Jul 2011 08:16:13 -0700 Subject: [cfe-dev] tests of bindings/python fail? In-Reply-To: References: Message-ID: <312F99EC-8D56-4143-BC73-6837DE54BEAE@apple.com> On Jul 1, 2011, at 11:14 PM, Eli Bendersky wrote: > On a clean checkout + build of Clang from trunk, taken yesterday, I run: > > ~/test/llvm/tools/clang/bindings/python$ nosetests -v > > tests.cindex.test_cursor.test_get_children ... FAIL > tests.cindex.test_cursor_kind.test_name ... ok > tests.cindex.test_cursor_kind.test_get_all_kinds ... ok > Check that every kind classifies to exactly one group. ... FAIL > tests.cindex.test_diagnostics.test_diagnostic_warning ... ok > tests.cindex.test_diagnostics.test_diagnostic_note ... ok > tests.cindex.test_diagnostics.test_diagnostic_fixit ... ok > tests.cindex.test_diagnostics.test_diagnostic_range ... ok > tests.cindex.test_index.test_create ... ok > tests.cindex.test_index.test_parse ... ok > tests.cindex.test_translation_unit.test_spelling ... ok > tests.cindex.test_translation_unit.test_cursor ... ok > tests.cindex.test_translation_unit.test_parse_arguments ... ok > tests.cindex.test_translation_unit.test_reparse_arguments ... ok > tests.cindex.test_translation_unit.test_unsaved_files ... ok > tests.cindex.test_translation_unit.test_unsaved_files_2 ... ok > tests.cindex.test_translation_unit.test_includes ... FAIL > ... > > > Is this something with my setup, or do others see these failures as well? I see the same failures. The Python bindings haven't been maintained and aren't regularly tested, so they've suffered some bit-rot. - Doug From hhinnant at apple.com Sat Jul 2 10:29:05 2011 From: hhinnant at apple.com (Howard Hinnant) Date: Sat, 02 Jul 2011 11:29:05 -0400 Subject: [cfe-dev] [libc++] clang / libc++ fail to compile the code with boost In-Reply-To: <699E04A3-DD73-4E47-A297-9AB252E813D7@apple.com> References: <699E04A3-DD73-4E47-A297-9AB252E813D7@apple.com> Message-ID: <0E6B42F3-4D15-4985-ABAB-265939E5F928@apple.com> On Jul 2, 2011, at 11:10 AM, Douglas Gregor wrote: > > On Jul 1, 2011, at 7:55 PM, Eli Friedman wrote: > >> On Fri, Jul 1, 2011 at 7:09 PM, ryuuta wrote: >>> Hi, >>> I bet the problem is in boost implementation but >>> I'm not 100% sure whether the issue is really on boost side or not. >> Testcase without boost: >> >> #include >> struct A { int& x; explicit A(int); public: bool operator<(const A& >> other) const {return x < other.x; }}; >> void f(A* x) { std::map y, z; z = y; } >> >> This looks like a boost bug to me... as far as I can tell, the Key >> type of an std::map is required to be assignable if you're assigning >> one map to another (although the implementation isn't required to >> actually use that assignment operator). > > > C++0x [container.requirements.general] is fairly clear that assigning a container requires the element type to be move assignable. This is a Boost bug. Strongly agree. Especially if you s/copy/move. ;-) And include the reference [associative.reqmts]/p7: > The associative containers meet all the requirements of Allocator-aware containers (23.2.1), except that for map and multimap, the requirements placed on value_type in Table 96 apply instead to key_type and mapped_type. [Note: For example, in some cases key_type and mapped_type are required to be CopyAssignable even though the associated value_type, pair, is not CopyAssignable. ?endnote] To be fair to boost, this was at best unspecified in C++03 and no implementation of map took advantage of it (erase/insert was/is a common algorithm for assignment). libc++ is probably the first std::lib to recycle nodes under associative container assignment. This can be a huge performance win for copy assignment. Howard From vanboxem.ruben at gmail.com Sat Jul 2 11:17:15 2011 From: vanboxem.ruben at gmail.com (Ruben Van Boxem) Date: Sat, 2 Jul 2011 18:17:15 +0200 Subject: [cfe-dev] MinGW(-w64) fixes to InitHeaderSearch.cpp and float.h In-Reply-To: <0F8A7282-8FCF-41CB-B73E-4DB7FAD04754@apple.com> References: <3ECBA685-F064-4107-A4B5-454CE4E40BAB@apple.com> <0F8A7282-8FCF-41CB-B73E-4DB7FAD04754@apple.com> Message-ID: 2011/7/2 Douglas Gregor : > > On Jul 2, 2011, at 6:08 AM, Ruben Van Boxem wrote: > >> 2011/6/27 Ruben Van Boxem : >>> Op 27 jun. 2011 17:51 schreef "Douglas Gregor" het volgende: >>>> >>>> On Jun 25, 2011, at 7:51 AM, Ruben Van Boxem wrote: >>>> >>>>> Hi, >>>>> >>>>> I bring fixes for MinGW(-w64) Clang users: >>>>> >>>>> 1. InitHeaderSearch.cpp: add a HeaderSearchOptions argument to >>>>> AddDefaultCXXIncludePaths (AddDefaultCIncludePaths already had this, >>>>> seems only logical to have it here) and use ResourceDir to find the >>>>> sysroot of where Clang.exe is located. From there, add the >>>>> x86_64-w64-mingw32 and i686-w64-mingw32 include paths for C and C++. >>>>> All mingw-w64 toolchains are built --with-sysroot, and thus >>>>> relocatable, so this change will always find the accompanying headers. >>>> >>>> I've committed this part as r133911. >>>> >>>>> 2. float.h: MinGW needs an #include_next, because as described on this >>>>> page (http://msdn.microsoft.com/en-us/library/y0ybw9fy.aspx) there are >>>>> non-standard extensions to float.h which are expected on Windows, and >>>>> MinGW provides these declarations in their system header. GCC's >>>>> float.h is "fixinclude"d to include_next the system header. Note that >>>>> a trivial change is needed in mingw-w64's float.h, and that change >>>>> will be committed as soon as Clang's header does what it's supposed to >>>>> do. >>>> >>>> >>>> If we're including MinGW's float.h first, then our own definitions of all of the standard float.h macros are going to stomp on the ones that come from MinGW's float.h. I think that's a reasonable thing to do, but if that's the intent, I'd prefer to have #undef's in our own float.h to make it explicit that this is what we're doing (and so that our own headers don't generate warnings, even if they're suppressed). >>> >>> I just copied that behavior (and the comment) from , but I >>> know that mingw-w64's float.h header does #undef everything it >>> redefines, so it would perhaps be better if the #include_next in >>> Clang's float.h came at the end. Then nothing else needs to change >>> much. >>> >>> Ruben >>> >> >> I have attached a new patch with two new GCC versions for the include >> paths, and I moved the #include_next to the end. My previous >> testing proved this would work if the mingw-w64 headers is adapted to >> detect Clang as well (will happen as soon as Clang's header is >> patched). If someone would be so kind to apply these minor changes, >> I'd be very happy. > > My suggestion would have been to #include_next at the beginning, then #undef everything that Clang's is going to define, so that Clang is guaranteed to get its own definitions of the standard macros. Did this not work? It does, I just tested it. Attached is your change. > > The patch you attached is something different (a CMake change for TableGen). Is that change still necessary? Yes, terribly sorry for the bad attachment, I took the LLVM directory instead of LLVM/tools/clang directory. Should have double-checked. Ruben -------------- next part -------------- A non-text attachment was scrubbed... Name: mingw.patch Type: application/octet-stream Size: 3134 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110702/9d18f603/attachment.obj From eliben at gmail.com Sat Jul 2 11:42:18 2011 From: eliben at gmail.com (Eli Bendersky) Date: Sat, 2 Jul 2011 19:42:18 +0300 Subject: [cfe-dev] tests of bindings/python fail? In-Reply-To: <312F99EC-8D56-4143-BC73-6837DE54BEAE@apple.com> References: <312F99EC-8D56-4143-BC73-6837DE54BEAE@apple.com> Message-ID: > > > > > > Is this something with my setup, or do others see these failures as well? > > > I see the same failures. > > The Python bindings haven't been maintained and aren't regularly tested, so > they've suffered some bit-rot. > > - Doug > Hi Doug, Is there an intention to keep them maintained, however? I.e. if I send patches, are there core devs interested enough to commit them? Eli -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110702/85369411/attachment.html From clattner at apple.com Sat Jul 2 15:04:57 2011 From: clattner at apple.com (Chris Lattner) Date: Sat, 02 Jul 2011 13:04:57 -0700 Subject: [cfe-dev] Make macro instantiation more memory efficient In-Reply-To: <2343817F-E5F2-4B0B-9728-1903A5454FC0@apple.com> References: <2343817F-E5F2-4B0B-9728-1903A5454FC0@apple.com> Message-ID: <171CFF8A-CFD8-4BA8-AAA2-DE47D2E7811C@apple.com> Sounds great, very nice solution! -Chris On Jun 30, 2011, at 1:28 PM, Argyrios Kyrtzidis wrote: > First, let me start with a biblical tale. > > In the beginning there was nothing. Then Chris said "Let there be a preprocessor!" and a preprocessor was formed. And Chris looked upon macro instantiation and said, "It is good!". But an evil boost library came along and blew up the memory that the preprocessor was consuming.. (ok, the tale's starting to not make sense). > > Currently when we are instantiating a macro, each token that comes out reserves a chunk in the "source address space" by adding a new entry to the SLocEntry table. This works great up until you start abusing the preprocessor, like that boost library which ended up creating ~ 36M entries, blowing up memory and PCH file to > 1 GB. > > I'd like to suggest a slightly different and more memory efficient way: > When a macro instantiation occurs, we reserve a SLocEntry chunk with length the full length of the macro definition source. We set the spelling location of this chunk to point to the start of the macro definition and any subsequent tokens that were lexed directly from the macro definition will get a location from this chunk with the appropriate offset. > When expanding macro arguments we can always use a new chunk for each token as we are currently doing or we can do the same optimization for arguments whose input comes directly from a FileID, in which case we will again reserve a single chunk for the full extent of the arguments and assign locations to tokens relative to that. > > I don't anticipate this change to be too intrusive, I think the only functions that will be affected and need to change are SourceManager::isBeforeInTranslationUnit and SourceManager::isAtEndOfMacroInstantiation which both assume that 2 macro tokens are always ordered in the "source address space" according to their offset. > > Does it seem reasonable ? Speak now or forever hold your peace.. From clattner at apple.com Sat Jul 2 15:12:02 2011 From: clattner at apple.com (Chris Lattner) Date: Sat, 02 Jul 2011 13:12:02 -0700 Subject: [cfe-dev] Proposal for thread safety attributes for Clang In-Reply-To: <2C9935343FDB104E8F3175A2729BC31402C22B@005-TK5MPN1-011.MGDADSK.autodesk.com> References: <2C9935343FDB104E8F3175A2729BC31402C22B@005-TK5MPN1-011.MGDADSK.autodesk.com> Message-ID: <8F6D6D3E-A06A-4E88-A983-25E66B084A42@apple.com> Hi Michael, This sounds very interesting. Do you have any documentation that explains the model that this exposes to programmers? -Chris On Jun 30, 2011, at 11:37 PM, Michael Han wrote: > We have implemented a tool based on clang at Autodesk to help developers express their design decisions. The basic idea is the design decisions implemented as a set of customized GNU style attributes can serve as metadta to the fuctions, classes, etc and these metadata could be checked by clang static analyzer to enforce specific data access pattern and call graph for functions. We use this tool to help us parallelize some of our legacy C++ code base, for example, by enforcing a specific code is purely functinal style thus by definition is trivially thread safe. > > > > Our implementation touches many pieces of clang as we don?t find a less intrusive way to get the attributes / metadata into clang?s type system and AST. As a result we have to periodically merge our code base with Clang official trunk, which sometimes is quite touch. The checker is easy to write as it is very well decoupled from the rest of the system. > > > > I am wondering if this project would lead to an extensible annotation framework for Clang so user could encode arbitary metadata into Clang AST. That would be very useful and powerful for analysis code as it would involve develpers more intimately by capturing the design decisions eariler. > > > > Cheers > > ~Michael > > From: cfe-dev-bounces at cs.uiuc.edu [mailto:cfe-dev-bounces at cs.uiuc.edu] On Behalf Of Caitlin Sadowski > Sent: Friday, July 01, 2011 8:58 AM > To: cfe-dev at cs.uiuc.edu; Delesley Hutchins; Jaeheon Yi; Jeffrey Yasskin; cormac at cs.ucsc.edu > Subject: [cfe-dev] Proposal for thread safety attributes for Clang > > > > The following is a proposal for a project we would like to contribute to Clang. Feel free to discuss. > > > > Cheers, > > > Caitlin Sadowski > > Google & University of California at Santa Cruz > > > > Thread Safety Attributes for Clang > > Summary > > We would like to add a set of thread safety attributes to Clang. These attributes, based on a prior GCC implementation, will allow for checkable documentation of basic locking policies in multithreaded programs. > > Background > The synchronization policies in modern multithreaded code may be poorly documented, and incorrectly inferred by new developers. Furthermore, when these policies are improperly followed they often lead to bugs which are difficult to reproduce and diagnose. One strategy for avoiding concurrency bugs is formal documentation of these synchronization policies. By writing this documentation using attribute-based annotations, Clang can mechanically check and warn about issues that could potentially result in race conditions and deadlocks. > > Example > > A code sample which demonstrates two of the proposed annotations is below. In this code sample, variables are protected by locks from the Mutex class. This class has been annotated to specify the API used to lock and unlock. > > * GUARDED_BY specifies a particular lock should be held when accessing the annotated variable. Violations of this locking policy may lead to data races. > * ACQUIRED_AFTER annotations document the acquisition order between locks that can be held simultaneously by a thread, by specify the locks that need to be acquired before the annotated lock. Violations of this locking policy may lead to deadlocks. > > 1 #include "thread_annotations.h" > 2 #define GUARDED_BY(x) __attribute__((GUARDED_BY(x))) > 3 #define ACQUIRED_AFTER(x) __attribute__((ACQUIRED_AFTER(x))) > 4 > 5 Mutex mu1; > 6 Mutex mu2 ACQUIRED_AFTER(mu1); > 7 > 8 int x GUARDED_BY(mu1); > 9 int a GUARDED_BY(mu2); > 10 > 11 void foo() > 12 { > 13 mu2.Lock(); > 14 mu1.Lock(); > 15 if (x > 2) > 16 a = x + 1; > 17 else > 18 a = x - 1; > 19 mu1.Unlock(); > 20 mu2.Unlock(); > 21 } > > Sample compiler output: > ex.cc: In function 'void foo()': > ex.cc:12: warning: Lock 'mu1' is acquired after lock 'mu2' (acquired at line 14) but is annotated otherwise > > Previous Work > > As mentioned, thread safety annotations have been implemented in GCC. A full list of the annotations and descriptions for them can be found here: > > http://gcc.gnu.org/wiki/ThreadSafetyAnnotation > https://docs.google.com/a/google.com/Doc?id=ddqtfwhb_0c49t6zgr > > These annotations have been in active use in Google?s C++ codebase for a couple of years, so there is a large informal case study of their usefulness. The ideas behind many of these annotations come originally from a research paper [1]. > > Plan > > We are planning to re-implement the GCC thread safety attributes in Clang. We will submit a series of patches to the cfe-commits mailing list. Our current plan for this serie is as follows: > > 1) Basic parsing and semantic checking of the attributes which do not take arguments. In other words, checking whether the attribute is applied in the appropriate context (e.g. to a field, with no arguments). > 2) Basic parsing and semantic checking of the attributes which do take arguments, but without parsing or checking the arguments themselves. At this point, we will simply discard the tokens making up the arguments. > 3) Attribute argument parsing. > 4) Adding the thread safety analysis checks. We will teach the static analysis-based warnings layer to warn for violations of the annotations discussed on the links above. > > Future Projects > > Once we have this core set of thread safety annotations implemented, we have several directions for future work we would like to pursue. These include supporting additional types of annotations. For example, we would like to extend the system to support annotations for functions which only touch thread-local data and atomic functions which always execute as if they are not interleaved with operations of other threads. We would also like to build an annotation inference system; this system would enable application of the thread safety analysis to large amounts of legacy code. > > [1] C. Flanagan and S. N. Freund. Type-based race detection for Java. In Programming Language Design and Implementation (PLDI), June 2000. > > _______________________________________________ > 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/20110702/8a95f3dc/attachment-0001.html From dgregor at apple.com Sat Jul 2 17:16:19 2011 From: dgregor at apple.com (Douglas Gregor) Date: Sat, 02 Jul 2011 15:16:19 -0700 Subject: [cfe-dev] tests of bindings/python fail? In-Reply-To: References: <312F99EC-8D56-4143-BC73-6837DE54BEAE@apple.com> Message-ID: Sent from my iPhone On Jul 2, 2011, at 9:42 AM, Eli Bendersky wrote: > > > > > > > Is this something with my setup, or do others see these failures as well? > > > I see the same failures. > > The Python bindings haven't been maintained and aren't regularly tested, so they've suffered some bit-rot. > > - Doug > > > Hi Doug, > > Is there an intention to keep them maintained, however? I.e. if I send patches, are there core devs interested enough to commit them? We'll happily commit patches to keep the Python bindings working. - Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110702/46467916/attachment.html From stevenward666 at hotmail.com Sat Jul 2 17:34:20 2011 From: stevenward666 at hotmail.com (STEVEN WARD) Date: Sat, 2 Jul 2011 23:34:20 +0100 Subject: [cfe-dev] Compiling a linux-kernel Message-ID: Hi to all. I have built my linux kernel using GCC many times. However,it takes me three hours to build the whole thing with my AMD XP 2,000+ processor. I am curious on how to build my kernel using Llvm-Clang instead. I want to know exactly how to do that(doing bzImage,make modules,make modules_install,make install) I can invoke "/usr/bin/clang from the directory where the kernel I'm building is,but it doesn't seem to do anything. Any help would be greatly appreciated. Regards, Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110702/5a51c61b/attachment.html From dblaikie at gmail.com Sat Jul 2 19:40:56 2011 From: dblaikie at gmail.com (David Blaikie) Date: Sat, 2 Jul 2011 17:40:56 -0700 Subject: [cfe-dev] Proposal for thread safety attributes for Clang In-Reply-To: <4E0EE3B7.7020103@mail1.stofanet.dk> References: <4E0EE3B7.7020103@mail1.stofanet.dk> Message-ID: > > GUARDED_BY: It is true that the C++ compiler does not know which mutex > guards what variables, and therefore cannot alert you if you, say, use > a variable without locking its mutex. I solved this problem in a > commercial project by defining two templates: a guard and an accessor. > The guard contained the mutex and the variable (or struct of > variables) as a private member, and only the accessor could access it. > The accessor would lock and unlock the mutex in a RAII manner. An > example using this technique could look like this: > > class Alpha > { > public: > int GetValue() const > { > const_unique_access value(valueGuard); > return *value; > } > void SetValue(int v) > { > unique_access value(valueGuard); > *value = v; > } > private: > unique_access_guard valueGuard; > }; > Interesting idea - it has some parallels with a lambda-based more functional-programming inspired device similar to boost::optional I've been toying with. Using that type of technique you could do something like this: uniquely_accessed value; ... value.Access([](const int& i) { ... }); ... value.Mutate([](int& i) { ... }); Just as another take on the same construct. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110702/2aec5e23/attachment.html From clattner at apple.com Sat Jul 2 21:43:07 2011 From: clattner at apple.com (Chris Lattner) Date: Sat, 02 Jul 2011 19:43:07 -0700 Subject: [cfe-dev] Automatic Reference Counting for Objective-C In-Reply-To: <40A2FE01-1383-41BA-A7F2-A7104B1DFF20@shadowlab.org> References: <839A0B23-47BC-4A8F-A25A-C9945F855BEC@apple.com> <12B0FF9A-5D3C-4831-8A1E-16D0F10C7C05@swan.ac.uk> <40A2FE01-1383-41BA-A7F2-A7104B1DFF20@shadowlab.org> Message-ID: On Jun 30, 2011, at 1:04 AM, Jean-Daniel Dupas wrote: >> The migration tool isn't expected to be generally useful outside of Xcode, and the interfaces continue to change and evolve over time. ARR was an earlier name for the feature before we standardized on ARC. Expect change in the migrator, don't get too comfortable with it :) > > Not only the migrator uses it. The __has_feature tag use to detect if arc is enabled used arr too (it is objc_arr). Yes, but it will be removed. Please use __has_feature(objc_arc) instead. -Chris From eliben at gmail.com Sat Jul 2 22:20:34 2011 From: eliben at gmail.com (Eli Bendersky) Date: Sun, 3 Jul 2011 06:20:34 +0300 Subject: [cfe-dev] libIndex documentation missing online In-Reply-To: <0E8E53BE-F276-4AFF-9034-6B899463ECBB@apple.com> References: <9A209257-6AAA-4FBD-BC65-084F42931B12@apple.com> <0E8E53BE-F276-4AFF-9034-6B899463ECBB@apple.com> Message-ID: Yes, that's correct. See > > > http://clang.llvm.org/doxygen/group__CINDEX.html > > - Doug > > I was kind-of worried you might say that :-) Anyway, after a weekend of tinkering with libclang and its Python bindings, I've written a longish article on my blog about its usage ( http://eli.thegreenplace.net/2011/07/03/parsing-c-in-python-with-clang/). Hopefully it can serve as a basic tutorial to libclang through the Python bindings. Eli -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110703/cfa73726/attachment.html From dgregor at apple.com Sun Jul 3 00:24:31 2011 From: dgregor at apple.com (Douglas Gregor) Date: Sat, 02 Jul 2011 22:24:31 -0700 Subject: [cfe-dev] libIndex documentation missing online In-Reply-To: References: <9A209257-6AAA-4FBD-BC65-084F42931B12@apple.com> <0E8E53BE-F276-4AFF-9034-6B899463ECBB@apple.com> Message-ID: <5EE4AB59-DBDF-4AD2-8CB2-80A880F3FFD1@apple.com> Sent from my iPhone On Jul 2, 2011, at 8:20 PM, Eli Bendersky wrote: > Yes, that's correct. See > > > http://clang.llvm.org/doxygen/group__CINDEX.html > > > > - Doug > > > I was kind-of worried you might say that :-) > Anyway, after a weekend of tinkering with libclang and its Python bindings, I've written a longish article on my blog about its usage (http://eli.thegreenplace.net/2011/07/03/parsing-c-in-python-with-clang/). > Hopefully it can serve as a basic tutorial to libclang through the Python bindings. Very nice! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110702/fe7a24d7/attachment.html From craig.topper at gmail.com Sun Jul 3 00:26:57 2011 From: craig.topper at gmail.com (Craig Topper) Date: Sat, 2 Jul 2011 22:26:57 -0700 Subject: [cfe-dev] Handling of UCNs >256 in narrow character literals Message-ID: UCN values >256 in narrow character literals are not checked at all to see if they will fit in a character. They can be silently stored in a char without warning about any loss of data. The UCN's lower byte will be sign extended, corrupting the upper bits of the UCN value, but again with no warning. Also if you were to put multiple characters in a narrow character literal with the second being a UCN, the earlier character will be corrupted because the UCN value is ADDed to the original character shifted 8 bits to the left without clipping to only a byte. GCC seems to handle UCNs in narrow character literals by converting to UTF-8 and treating them as a multiple character value. Should clang match GCC here or at the very least clip the UCN and issue a warning that the UCN was too large? -- ~Craig From Michael.Han at autodesk.com Sun Jul 3 04:48:23 2011 From: Michael.Han at autodesk.com (Michael Han) Date: Sun, 3 Jul 2011 09:48:23 +0000 Subject: [cfe-dev] Proposal for thread safety attributes for Clang In-Reply-To: <8F6D6D3E-A06A-4E88-A983-25E66B084A42@apple.com> References: <2C9935343FDB104E8F3175A2729BC31402C22B@005-TK5MPN1-011.MGDADSK.autodesk.com> <8F6D6D3E-A06A-4E88-A983-25E66B084A42@apple.com> Message-ID: <2C9935343FDB104E8F3175A2729BC31402D03E@005-TK5MPN1-011.MGDADSK.autodesk.com> Hi Chris, I sent you a presentation which describes the project design and some of its implementation details, please check. Also Francesco is collaborating with Vikram?s group at UPCRC to evaluate to use our tool as a base for the deterministic parallel C++ project (http://dpj.cs.uiuc.edu/DPJ/Future_Directions.html), which devises a set of annotations to document low level properties of functions in a more finely grained approach than our ?high level? annotation of function properties like reentrancy. Francesco can provide more details if you are interested. Cheers ~Michael From: Chris Lattner [mailto:clattner at apple.com] Sent: Sunday, July 03, 2011 4:12 AM To: Michael Han Cc: Caitlin Sadowski; cfe-dev at cs.uiuc.edu; Delesley Hutchins; Jaeheon Yi; Jeffrey Yasskin; cormac at cs.ucsc.edu; Benoit Belley; Francesco Iorio Subject: Re: [cfe-dev] Proposal for thread safety attributes for Clang Hi Michael, This sounds very interesting. Do you have any documentation that explains the model that this exposes to programmers? -Chris On Jun 30, 2011, at 11:37 PM, Michael Han > wrote: We have implemented a tool based on clang at Autodesk to help developers express their design decisions. The basic idea is the design decisions implemented as a set of customized GNU style attributes can serve as metadta to the fuctions, classes, etc and these metadata could be checked by clang static analyzer to enforce specific data access pattern and call graph for functions. We use this tool to help us parallelize some of our legacy C++ code base, for example, by enforcing a specific code is purely functinal style thus by definition is trivially thread safe. Our implementation touches many pieces of clang as we don?t find a less intrusive way to get the attributes / metadata into clang?s type system and AST. As a result we have to periodically merge our code base with Clang official trunk, which sometimes is quite touch. The checker is easy to write as it is very well decoupled from the rest of the system. I am wondering if this project would lead to an extensible annotation framework for Clang so user could encode arbitary metadata into Clang AST. That would be very useful and powerful for analysis code as it would involve develpers more intimately by capturing the design decisions eariler. Cheers ~Michael From: cfe-dev-bounces at cs.uiuc.edu [mailto:cfe-dev-bounces at cs.uiuc.edu] On Behalf Of Caitlin Sadowski Sent: Friday, July 01, 2011 8:58 AM To: cfe-dev at cs.uiuc.edu; Delesley Hutchins; Jaeheon Yi; Jeffrey Yasskin; cormac at cs.ucsc.edu Subject: [cfe-dev] Proposal for thread safety attributes for Clang The following is a proposal for a project we would like to contribute to Clang. Feel free to discuss. Cheers, Caitlin Sadowski Google & University of California at Santa Cruz Thread Safety Attributes for Clang Summary We would like to add a set of thread safety attributes to Clang. These attributes, based on a prior GCC implementation, will allow for checkable documentation of basic locking policies in multithreaded programs. Background The synchronization policies in modern multithreaded code may be poorly documented, and incorrectly inferred by new developers. Furthermore, when these policies are improperly followed they often lead to bugs which are difficult to reproduce and diagnose. One strategy for avoiding concurrency bugs is formal documentation of these synchronization policies. By writing this documentation using attribute-based annotations, Clang can mechanically check and warn about issues that could potentially result in race conditions and deadlocks. Example A code sample which demonstrates two of the proposed annotations is below. In this code sample, variables are protected by locks from the Mutex class. This class has been annotated to specify the API used to lock and unlock. * GUARDED_BY specifies a particular lock should be held when accessing the annotated variable. Violations of this locking policy may lead to data races. * ACQUIRED_AFTER annotations document the acquisition order between locks that can be held simultaneously by a thread, by specify the locks that need to be acquired before the annotated lock. Violations of this locking policy may lead to deadlocks. 1 #include "thread_annotations.h" 2 #define GUARDED_BY(x) __attribute__((GUARDED_BY(x))) 3 #define ACQUIRED_AFTER(x) __attribute__((ACQUIRED_AFTER(x))) 4 5 Mutex mu1; 6 Mutex mu2 ACQUIRED_AFTER(mu1); 7 8 int x GUARDED_BY(mu1); 9 int a GUARDED_BY(mu2); 10 11 void foo() 12 { 13 mu2.Lock(); 14 mu1.Lock(); 15 if (x > 2) 16 a = x + 1; 17 else 18 a = x - 1; 19 mu1.Unlock(); 20 mu2.Unlock(); 21 } Sample compiler output: ex.cc: In function 'void foo()': ex.cc:12: warning: Lock 'mu1' is acquired after lock 'mu2' (acquired at line 14) but is annotated otherwise Previous Work As mentioned, thread safety annotations have been implemented in GCC. A full list of the annotations and descriptions for them can be found here: http://gcc.gnu.org/wiki/ThreadSafetyAnnotation https://docs.google.com/a/google.com/Doc?id=ddqtfwhb_0c49t6zgr These annotations have been in active use in Google?s C++ codebase for a couple of years, so there is a large informal case study of their usefulness. The ideas behind many of these annotations come originally from a research paper [1]. Plan We are planning to re-implement the GCC thread safety attributes in Clang. We will submit a series of patches to the cfe-commits mailing list. Our current plan for this serie is as follows: 1) Basic parsing and semantic checking of the attributes which do not take arguments. In other words, checking whether the attribute is applied in the appropriate context (e.g. to a field, with no arguments). 2) Basic parsing and semantic checking of the attributes which do take arguments, but without parsing or checking the arguments themselves. At this point, we will simply discard the tokens making up the arguments. 3) Attribute argument parsing. 4) Adding the thread safety analysis checks. We will teach the static analysis-based warnings layer to warn for violations of the annotations discussed on the links above. Future Projects Once we have this core set of thread safety annotations implemented, we have several directions for future work we would like to pursue. These include supporting additional types of annotations. For example, we would like to extend the system to support annotations for functions which only touch thread-local data and atomic functions which always execute as if they are not interleaved with operations of other threads. We would also like to build an annotation inference system; this system would enable application of the thread safety analysis to large amounts of legacy code. [1] C. Flanagan and S. N. Freund. Type-based race detection for Java. In Programming Language Design and Implementation (PLDI), June 2000. _______________________________________________ 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/20110703/05619574/attachment-0001.html From davekeck at gmail.com Sun Jul 3 06:15:26 2011 From: davekeck at gmail.com (Dave Keck) Date: Sun, 3 Jul 2011 01:15:26 -1000 Subject: [cfe-dev] Objc, cannot cast 'super' error Message-ID: Hey list, Clang doesn't allow super to be casted; I'd like to present my use-case demonstrating why I think this should be allowed, or get some feedback on why Clang is right and my design is wrong: I have two classes, ClassA and ClassB. ClassB inherits from ClassA, and ClassB alone implements MyProtocol: @protocol MyProtocol - (void)handleToken: (id)token; @end The contract for MyProtocol is that if you don't recognize 'token', you send -handleToken: to super. If no superclass implements -handleToken:, then a runtime exception is correctly generated since no one could handle the token. (This is exactly the same as KVO's -observeValueForKeyPath: contract.) ClassB's implementation of -handleToken: triggers the "'ClassA' may not respond to 'handleToken:'" warning on the call to super: - (void)handleToken: (id)token { if (token == myToken) ... handle token ... else [super handleToken: token]; } Without the ability to cast super, I have the following options, none of which are optimal: 1. Add the following code to ClassB.m: @interface ClassA (Stub) @end This option is bad because it'll need changing if ClassB's superclass changes, and will have to be separated from the code that triggers the warning. 2. Omit the [super handleToken: call], since (at present) no other superclass actually implements -handleToken:. This option is bad because it'll break if a superclass starts implementing -handleToken:. 3. Make MyProtocol an informal protocol on NSObject instead. This option is bad because a formal protocol is the correct abstraction for my use-case. 4. Use objc_msgSendSuper directly. This option is just ugly and inconsistent with the rest of my code. Why is my design wrong? Thanks! David From csdavec at swan.ac.uk Sun Jul 3 06:55:45 2011 From: csdavec at swan.ac.uk (David Chisnall) Date: Sun, 3 Jul 2011 12:55:45 +0100 Subject: [cfe-dev] Objc, cannot cast 'super' error In-Reply-To: References: Message-ID: On 3 Jul 2011, at 12:15, Dave Keck wrote: > 3. Make MyProtocol an informal protocol on NSObject instead. > > This option is bad because a formal protocol is the correct > abstraction for my use-case. No it isn't. If you are explicitly sending messages that a class does not respond to then an informal protocol is exactly what you want. Note that there is nothing stopping you from using both a formal and informal protocol, if you wish for explicit testing. Using these exceptions is very bad style for several reasons: 1) Exceptions in Objective-C are intended to indicate programmer error and are very slow. Using them for a recoverable error is bad. 2) You are overloading the meaning of an exception, making it difficult to distinguish between a real error and this error. 3) Code that assumes 1) (i.e. most Cocoa code, including code compiled with ARC enabled) will leak memory if it's in any intervening stack frames. If you really must use exceptions, a better way of doing it would be something like: @implementation NSObject (MyProtocol) - (void)handleToken: (id) token { NSString *reason = [NSString stringWithFormat: @"Unhandled token %@", token]; NSDictionary *userInfo = [NSDictionary dictionaryWithObject: token forKey: kMyProtocolUnhandledToken] [[NSException exceptionWithName: MyProtocolUnhandledTokenException reason: reason userInfo: userInfo] raise]; } @end This would then ensure that you had a meaningful exception to catch, rather than doing something ugly and hackish. David -- This email complies with ISO 3103 From devlists at shadowlab.org Sun Jul 3 10:58:46 2011 From: devlists at shadowlab.org (Jean-Daniel Dupas) Date: Sun, 3 Jul 2011 17:58:46 +0200 Subject: [cfe-dev] Automatic Reference Counting for Objective-C In-Reply-To: References: <839A0B23-47BC-4A8F-A25A-C9945F855BEC@apple.com> <12B0FF9A-5D3C-4831-8A1E-16D0F10C7C05@swan.ac.uk> <40A2FE01-1383-41BA-A7F2-A7104B1DFF20@shadowlab.org> Message-ID: <444FBBEA-109B-465F-88C5-06BD370355F5@shadowlab.org> Le 3 juil. 2011 ? 04:43, Chris Lattner a ?crit : > > On Jun 30, 2011, at 1:04 AM, Jean-Daniel Dupas wrote: >>> The migration tool isn't expected to be generally useful outside of Xcode, and the interfaces continue to change and evolve over time. ARR was an earlier name for the feature before we standardized on ARC. Expect change in the migrator, don't get too comfortable with it :) >> >> Not only the migrator uses it. The __has_feature tag use to detect if arc is enabled used arr too (it is objc_arr). > > Yes, but it will be removed. Please use __has_feature(objc_arc) instead. > Yes. I noticed after positing this message that objc_arc was already defined in clang and even documented on the clang web site. -- Jean-Daniel From eldlistmailingz at tropicsoft.com Sun Jul 3 13:14:39 2011 From: eldlistmailingz at tropicsoft.com (Edward Diener) Date: Sun, 03 Jul 2011 14:14:39 -0400 Subject: [cfe-dev] Clang and MingW32 In-Reply-To: References: Message-ID: On 6/26/2011 7:53 PM, NAKAMURA Takumi wrote: > Edward, > > If you don't use CMake, you should take MSYS environments. > FYI, I am using "msysgit" distributions. Using MSYS I followed the instructions. After running ../llvm/configure from the /build directory, I ran make which gives me: Makefile:139: /Makefile.rules: No such file or directory make: *** No rule to make target `/Makefile.rules'. Stop. From marcel.weiher at gmail.com Sun Jul 3 16:33:25 2011 From: marcel.weiher at gmail.com (Marcel Weiher) Date: Sun, 3 Jul 2011 23:33:25 +0200 Subject: [cfe-dev] Instance variables in implementation error? Message-ID: <035E4741-4D85-4B98-83E7-F2FFCD967751@gmail.com> Hi folks, I am working on a code-base that for various reasons has instance variables declared in both the @interface and the @implementation section. Using gcc 4.2, this is OK, but clang in 64 bit aborts with the following error: [elided] ../../src/Error.m:13:10: error: instance variable is already declared [3] BOOL _isExceptional; ^ Which is true, that is exactly what's happening, it was just OK (if questionable) before. In 32 bit mode, clang is OK with this, as is gcc 4.2 in both 32 bit and 64 bit mode. Any way to turn this error off in clang 64 bit mode? I tried setting the Objective-C language level using the (gcc) flag '-fobjc-std=objc1' but that doesn't seem to make a difference. I did a search of the clang pages at http://clang.llvm.org/docs/UsersManual.html but the link to "Objective-C language features" is a dead link ( http://clang.llvm.org/docs/UsersManual.html#objc ), as is the C++ link. The C language features link works. I also tried to search the code via the error message, but that wasn't too illuminating either. For now, I can probably get by with using gcc 4.2, but I'd much prefer to use clang. Thanks! Marcel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110703/06dbabd8/attachment.html From ryuuta at gmail.com Sun Jul 3 17:03:58 2011 From: ryuuta at gmail.com (Ryuta Suzuki) Date: Mon, 4 Jul 2011 07:03:58 +0900 Subject: [cfe-dev] [libc++] clang / libc++ fail to compile the code with boost In-Reply-To: <0E6B42F3-4D15-4985-ABAB-265939E5F928@apple.com> References: <699E04A3-DD73-4E47-A297-9AB252E813D7@apple.com> <0E6B42F3-4D15-4985-ABAB-265939E5F928@apple.com> Message-ID: Thank you all for your comments and diagnosis. It sounds like I have to file a bug report to the boost developers. Cheers, Ryuta On Sun, Jul 3, 2011 at 12:29 AM, Howard Hinnant wrote: > On Jul 2, 2011, at 11:10 AM, Douglas Gregor wrote: > > > > > On Jul 1, 2011, at 7:55 PM, Eli Friedman wrote: > > > >> On Fri, Jul 1, 2011 at 7:09 PM, ryuuta wrote: > >>> Hi, > >>> I bet the problem is in boost implementation but > >>> I'm not 100% sure whether the issue is really on boost side or not. > > >> Testcase without boost: > >> > >> #include > >> struct A { int& x; explicit A(int); public: bool operator<(const A& > >> other) const {return x < other.x; }}; > >> void f(A* x) { std::map y, z; z = y; } > >> > >> This looks like a boost bug to me... as far as I can tell, the Key > >> type of an std::map is required to be assignable if you're assigning > >> one map to another (although the implementation isn't required to > >> actually use that assignment operator). > > > > > > C++0x [container.requirements.general] is fairly clear that assigning a > container requires the element type to be move assignable. This is a Boost > bug. > > Strongly agree. Especially if you s/copy/move. ;-) And include the > reference [associative.reqmts]/p7: > > > The associative containers meet all the requirements of Allocator-aware > containers (23.2.1), except that for map and multimap, the requirements > placed on value_type in Table 96 apply instead to key_type and mapped_type. > [Note: For example, in some cases key_type and mapped_type are required to > be CopyAssignable even though the associated value_type, pair key_type, mapped_type>, is not CopyAssignable. ?endnote] > > > To be fair to boost, this was at best unspecified in C++03 and no > implementation of map took advantage of it (erase/insert was/is a common > algorithm for assignment). libc++ is probably the first std::lib to recycle > nodes under associative container assignment. This can be a huge > performance win for copy assignment. > > Howard > > > _______________________________________________ > 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/20110704/a7bdae51/attachment.html From csdavec at swan.ac.uk Sun Jul 3 17:43:37 2011 From: csdavec at swan.ac.uk (David Chisnall) Date: Sun, 3 Jul 2011 23:43:37 +0100 Subject: [cfe-dev] Instance variables in implementation error? In-Reply-To: <035E4741-4D85-4B98-83E7-F2FFCD967751@gmail.com> References: <035E4741-4D85-4B98-83E7-F2FFCD967751@gmail.com> Message-ID: <6DCC6ECE-24FC-4649-A555-15A596A4DE47@swan.ac.uk> On 3 Jul 2011, at 22:33, Marcel Weiher wrote: > I am working on a code-base that for various reasons has instance variables declared in both the @interface and the @implementation section How old is this codebase? That was never allowed in Objective-C 4: GCC just accepts it to ease migration of legacy Objective-C 3.3 code (yes, Objective-C 2.0 is the one that comes after Objective-C 4. Blame Apple marketing for that one). Since Objective-C 4 was released about 20 years ago, that's expected to be long enough for most people to update their code... If you're on Darwin, then 64-bit mode is enabling the non-fragile ABI implicitly. This means that defining instance variables in @implementation contexts actually does define new instance variables. Can you not simply delete them from the @implementation? They aren't actually doing anything there - GCC and clang with the fragile ABI will not accept definitions of new ivars there, because without the non-fragile ABI class layouts had to be public so that each class new where its superclass's ivars were. David From davekeck at gmail.com Sun Jul 3 18:54:02 2011 From: davekeck at gmail.com (Dave Keck) Date: Sun, 3 Jul 2011 13:54:02 -1000 Subject: [cfe-dev] Objc, cannot cast 'super' error In-Reply-To: References: Message-ID: Hi David, > No it isn't. ?If you are explicitly sending messages that a class does not respond to then an informal protocol is exactly what you want. I consider informal protocols as workarounds created before formal protocols supported @optional methods, which is why I avoided option 3. Am I wrong in that assessment? > Note that there is nothing stopping you from using both a formal and informal protocol, if you wish for explicit testing. I ended up doing something close to that; I still have the mentioned MyProtocol, but also MyCategory on NSObject that implements MyProtocol as the base case, by simply throwing a custom exception as you describe. A much cleaner approach indeed, and it gets rid of the warning. > Using these exceptions is very bad style for several reasons: > > 1) Exceptions in Objective-C are intended to indicate programmer error and are very slow. ?Using them for a recoverable error is bad. > > 2) You are overloading the meaning of an exception, making it difficult to distinguish between a real error and this error. > > 3) Code that assumes 1) (i.e. most Cocoa code, including code compiled with ARC enabled) will leak memory if it's in any intervening stack frames. I consider my use of exceptions to be in-line with what you describe: some programmer made an error and isn't handling a token as they should. Thanks for your insight! David From eldlistmailingz at tropicsoft.com Sun Jul 3 19:39:54 2011 From: eldlistmailingz at tropicsoft.com (Edward Diener) Date: Sun, 03 Jul 2011 20:39:54 -0400 Subject: [cfe-dev] Building clang with MSYS under Windows Message-ID: I follow the instructions for building clang with MSYS under Windows given on the clang web site. The 'configure' command runs to completion without any problems. When I invoke 'make' I get: 'Makefile:139: /Makefile.rules: No such file or directory make: *** No rule to make target `/Makefile.rules'. Stop.' In the generated at line 139 I see: 'include $(LLVM_SRC_ROOT)/Makefile.rules' What has gone wrong ? From eliben at gmail.com Sun Jul 3 22:16:57 2011 From: eliben at gmail.com (Eli Bendersky) Date: Mon, 4 Jul 2011 06:16:57 +0300 Subject: [cfe-dev] tests of bindings/python fail? In-Reply-To: References: <312F99EC-8D56-4143-BC73-6837DE54BEAE@apple.com> Message-ID: | We'll happily commit patches to keep the Python bindings working. > > - Doug > I'm attaching a patch (diffed against trunk) with some fixes to the Python bindings, making its tests pass again (on Linux and Windows). Some details of the patch: * Implemented a new function in libclang: clang_isAttr - it is similar to existing clang_Is* functions. Also exposed it to the Python bindings as the is_attr method of Cursor * Fixing TranslationUnit.get_includes to only go through the argument buffer when it contains something. This fixed a crash on Windows * clang_getFileName returns CXString, not char*. Made appropriate fixes in cindex.py - now the relevant tests pass and we can see the full locations correctly again (previously there was garbage in place of the file name) * Exposed clang_getCursorDisplayName to the python bindings P.S. the patch file was created with 'svn diff' in the root of clang, so it should be applied as 'patch -p0' there. I hope this is an accepted way to submit patches - if something different is required, I'll gladly fix. Eli -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110704/92229e5f/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: pybindings_fixes.patch Type: text/x-patch Size: 6158 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110704/92229e5f/attachment-0001.bin From marcel.weiher at gmail.com Mon Jul 4 00:12:00 2011 From: marcel.weiher at gmail.com (Marcel Weiher) Date: Mon, 4 Jul 2011 07:12:00 +0200 Subject: [cfe-dev] Instance variables in implementation error? In-Reply-To: <6DCC6ECE-24FC-4649-A555-15A596A4DE47@swan.ac.uk> References: <035E4741-4D85-4B98-83E7-F2FFCD967751@gmail.com> <6DCC6ECE-24FC-4649-A555-15A596A4DE47@swan.ac.uk> Message-ID: On Jul 4, 2011, at 0:43 , David Chisnall wrote: > On 3 Jul 2011, at 22:33, Marcel Weiher wrote: > >> I am working on a code-base that for various reasons has instance variables declared in both the @interface and the @implementation section > > > How old is this codebase? Its origins are mid 90-ies, so quite old, but actively developed, if not on OSX. > That was never allowed in Objective-C 4: GCC just accepts it to ease migration of legacy Objective-C 3.3 code (yes, Objective-C 2.0 is the one that comes after Objective-C 4. Blame Apple marketing for that one). Since Objective-C 4 was released about 20 years ago, that's expected to be long enough for most people to update their code... :) > If you're on Darwin, then 64-bit mode is enabling the non-fragile ABI implicitly. This means that defining instance variables in @implementation contexts actually does define new instance variables. Yep. The question is wether I can undo/override the implicit enabling explicitly, for example by using '-fobjc-std=objc1'. > Can you not simply delete them from the @implementation? Not simply, no, although that would be my goal. The reason is that the headers with the interfaces are actually generated from the .m files (which also means there can't be conflicts). This has some interesting benefits, though I myself found the costs to outweigh the benefits and abandoned the practice years ago. > They aren't actually doing anything there - GCC and clang with the fragile ABI will not accept definitions of new ivars there, because without the non-fragile ABI class layouts had to be public so that each class new where its superclass's ivars were. Yep. One solution would be to have the header-generator skip generating the variables for the @interfaces when compiling for 64 bit, and maintain the generation of the variables for 32 bit, but that's also pretty nasty. Thanks, Marcel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110704/5a671fe4/attachment.html From mailing-lists.jens at ayton.se Mon Jul 4 01:59:42 2011 From: mailing-lists.jens at ayton.se (Jens Ayton) Date: Mon, 4 Jul 2011 08:59:42 +0200 Subject: [cfe-dev] Instance variables in implementation error? In-Reply-To: References: <035E4741-4D85-4B98-83E7-F2FFCD967751@gmail.com> <6DCC6ECE-24FC-4649-A555-15A596A4DE47@swan.ac.uk> Message-ID: On Jul 4, 2011, at 07:12, Marcel Weiher wrote: > > > Yep. One solution would be to have the header-generator skip generating the variables for the @interfaces when compiling for 64 bit, and maintain the generation of the variables for 32 bit, but that's also pretty nasty. Two quasi-solutions: 1. Generate #ifndef __OBJC2__ around the generated ivar section, for maximum simplicity. 2. Use #if HEADER_GENERATOR around the ivar section in the @implementation, for cleaner headers. -- Jens Ayton From rcsaba at gmail.com Mon Jul 4 03:00:21 2011 From: rcsaba at gmail.com (Csaba Raduly) Date: Mon, 4 Jul 2011 10:00:21 +0200 Subject: [cfe-dev] Building clang with MSYS under Windows In-Reply-To: References: Message-ID: On Mon, Jul 4, 2011 at 2:39 AM, Edward Diener wrote: > I follow the instructions for building clang with MSYS under Windows > given on the clang web site. > > The 'configure' command runs to completion without any problems. > > When I invoke 'make' I get: > > 'Makefile:139: /Makefile.rules: No such file or directory > make: *** No rule to make target `/Makefile.rules'. ?Stop.' > > In the generated at line 139 I see: > > 'include $(LLVM_SRC_ROOT)/Makefile.rules' > > What has gone wrong ? LLVM_SRC_ROOT was not set correctly. Run "make -p" and check the output to see whether LLVM_SRC_ROOT is undefined or maybe defined as empty. (Redirect the output or pipe into 'less' for easier handling). Csaba -- GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++ The Tao of math: The numbers you can count are not the real numbers. Life is complex, with real and imaginary parts. "Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds "People disagree with me. I just ignore them." -- Linus Torvalds From mjklaim at gmail.com Mon Jul 4 04:13:16 2011 From: mjklaim at gmail.com (=?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?=) Date: Mon, 4 Jul 2011 11:13:16 +0200 Subject: [cfe-dev] C++ status page needs an update? In-Reply-To: References: Message-ID: Hi, On Wed, Jun 15, 2011 at 20:00, austin seipp wrote: > > Perhaps 6840 should stay open, but Clang most certainly builds Qt > these days from the looks of it, so I'm inclined to agree the page > should be updated to reflect that. > > I thought the page would have been updated since this mail but it don't seem to be. Are there plans to udpate it after reaching a milestone? More precisely I just wanted to know if lambdas are availble in the current trunk (or maybe in a specific tag?) I've seen mails about an implementation but don't know if it's integrated. Jo?l Lamotte -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110704/0a8d7e6f/attachment.html From csdavec at swan.ac.uk Mon Jul 4 04:39:17 2011 From: csdavec at swan.ac.uk (David Chisnall) Date: Mon, 4 Jul 2011 10:39:17 +0100 Subject: [cfe-dev] Instance variables in implementation error? In-Reply-To: References: <035E4741-4D85-4B98-83E7-F2FFCD967751@gmail.com> <6DCC6ECE-24FC-4649-A555-15A596A4DE47@swan.ac.uk> Message-ID: <78426491-7805-4F2D-AC87-5089AE804162@swan.ac.uk> On 4 Jul 2011, at 07:59, Jens Ayton wrote: > On Jul 4, 2011, at 07:12, Marcel Weiher wrote: >> >> >> Yep. One solution would be to have the header-generator skip generating the variables for the @interfaces when compiling for 64 bit, and maintain the generation of the variables for 32 bit, but that's also pretty nasty. > > Two quasi-solutions: > 1. Generate #ifndef __OBJC2__ around the generated ivar section, for maximum simplicity. Wouldn't #if !__has_feature(objc_nonfragile_abi) be better? We use something similar for ABI-breaking changes in classes via some horrible macros. This has the advantage that it lets you incrementally migrate to the non-fragile ABI - eventually you can just drop the ivar generating part of the header generator entirely, unless you have some ivars that are supposed to be shared. Wrapping the ivars in the @implementation in the same conditional would have the same effect. David -- Sent from my brain From joel.sherrill at OARcorp.com Mon Jul 4 09:30:21 2011 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Mon, 4 Jul 2011 09:30:21 -0500 Subject: [cfe-dev] Initial *-rtems* Target Support In-Reply-To: <824EBF49-4D9E-483E-B636-15BEC92C9CD2@apple.com> References: <4E0CE57D.7030400@oarcorp.com> <824EBF49-4D9E-483E-B636-15BEC92C9CD2@apple.com> Message-ID: <4E11CE7D.7000502@oarcorp.com> On 07/01/2011 05:41 PM, Douglas Gregor wrote: > On Jun 30, 2011, at 2:07 PM, Joel Sherrill wrote: > >> Hi, >> >> Some of us over in the RTEMS community >> (http://www.rtems.org) are curious about the >> possibility of using clang to compile RTEMS. >> For those who don't know RTEMS is an embedded >> real-time operating system which targets about >> 15 architectures and many more CPU models. >> So this is the beginnings of investigating using >> clang on RTEMS. > Very cool. > >> As background, the RTEMS targets in gcc are usually >> very close cousins to the bare metal targets like >> CPU-*-elf* or CPU-*-eabi*. We use newlib and build >> newlib at the same time as gcc. >> >> clang does not support most of the architectures >> supported by RTEMS. The intersection is x86, >> mips, powerpc, sparc, sparcv9, arm, thumb, and blackfin. >> Iin some cases, it does not cover the architectural >> variants we care most about. For example, the >> space community uses hardened SPARC V7 CPUs a lot >> with RTEMS and only V8 is supported by clang right now. >> The first goal is to get RTEMS itself to compile >> with clang targeting i386 w/FPU. >> >> I have managed to get newlib built and installed using >> clang to target i386-rtems4.11. Building RTEMS is next >> on the list and I will need assistance from others to >> get through this hurdle. In the interest of being open >> and hopefully getting help, I am submitting patches >> which should be OK to merge. I don't think they are >> too radical. :) >> >> The attached patches add initial *-*-rtems* target >> support. I modelled it after the FreeBSD support >> which supports multiple architectures. >> >> I don't know what format you want commit logs in but >> this is the information: >> >> Add initial *-*-rtems* target. >> >> The only tricky part to the patch is that RTEMS tools >> are never self-hosted so we do NOT want /usr/include >> ever added to an include search path. That's in >> lib/Frontend/InitHeaderSearch.cpp around line 590. >> >> Hopefully this isn't too bad to get merged. :) > > Looks fine to me. I've committee the patches to LLVM (r134282) and Clang (r134283). > Well there appears to be one issue. __rtems__ is not showing up as defined. :( Hopefully this is the correct way to see the cpp predefines. $ clang -ccc-host-triple i386-rtems4.11 -ccc-gcc-name i386-rtems4.11-gcc -dM -E - - Doug -- Joel Sherrill, Ph.D. Director of Research& Development joel.sherrill at OARcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985 From dgregor at apple.com Mon Jul 4 09:57:03 2011 From: dgregor at apple.com (Douglas Gregor) Date: Mon, 04 Jul 2011 07:57:03 -0700 Subject: [cfe-dev] C++ status page needs an update? In-Reply-To: References: Message-ID: <63C7ECE8-068A-4293-BE66-F0BC99BC6133@apple.com> On Jul 4, 2011, at 2:13 AM, Klaim - Jo?l Lamotte wrote: > Hi, > > On Wed, Jun 15, 2011 at 20:00, austin seipp wrote: > > Perhaps 6840 should stay open, but Clang most certainly builds Qt > these days from the looks of it, so I'm inclined to agree the page > should be updated to reflect that. > > > I thought the page would have been updated since this mail but it don't seem to be. > Are there plans to udpate it after reaching a milestone? The C++0x part of the page gets updated as soon as a new feature is "done". The introductory material is a bit stale, and will be updated. > More precisely I just wanted to know if lambdas are availble in the current trunk (or maybe in a specific tag?) I've seen mails about an implementation but don't know if it's integrated. Lambdas have not been implemented. - Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110704/e334fcdc/attachment-0001.html From harshgupta1992 at hotmail.com Mon Jul 4 10:34:55 2011 From: harshgupta1992 at hotmail.com (harsh gupta) Date: Mon, 4 Jul 2011 21:04:55 +0530 Subject: [cfe-dev] segfault in lexing Message-ID: I am using the lexer to get a stream of tokens for a file. However if there is a nested block comment, for eg /* some comment /*This is a nested comment*/ some more comment */ Then the lexer gives a segmentation fault. Is there any way to avoid this segmentation fault? The code that i am using is: clang::DiagnosticOptions diagnosticOptions; clang::TextDiagnosticPrinter *pTextDiagnosticPrinter = new clang::TextDiagnosticPrinter( llvm::outs(), diagnosticOptions); llvm::IntrusiveRefCntPtr pDiagIDs; clang::Diagnostic diagnostic(pDiagIDs,pTextDiagnosticPrinter); clang::LangOptions languageOptions; clang::FileSystemOptions fileSystemOptions; clang::FileManager fileManager(fileSystemOptions); clang::SourceManager sourceManager( diagnostic, fileManager); clang::HeaderSearch headerSearch(fileManager); clang::TargetOptions targetOptions; targetOptions.Triple = llvm::sys::getHostTriple(); clang::TargetInfo *pTargetInfo = clang::TargetInfo::CreateTargetInfo( diagnostic, targetOptions); clang::Preprocessor preprocessor( diagnostic, languageOptions, *pTargetInfo, sourceManager, headerSearch); const clang::FileEntry *pFile = fileManager.getFile( _outFilename); sourceManager.createMainFileID(pFile); preprocessor.EnterMainSourceFile(); std::vector cmdvect; GeneralCommand cmd; clang::Token token; do { preprocessor.Lex(token); if( diagnostic.hasErrorOccurred()) { break; } } while(token.isNot(clang::tok::eof)); And the backtrace is: Program received signal SIGSEGV, Segmentation fault.0x00000000004708fc in clang::LangOptions::LangOptions (this=0x7fffffffbc38) at /home/harsh/Desktop/llvm/tools/clang/lib/Sema/../../include/clang/Basic/LangOptions.h:2424 class LangOptions {(gdb) bt#0 0x00000000004708fc in clang::LangOptions::LangOptions (this=0x7fffffffbc38) at /home/harsh/Desktop/llvm/tools/clang/lib/Sema/../../include/clang/Basic/LangOptions.h:24#1 0x00000000007502c2 in clang::Lexer::Lexer (this=0x7fffffffbbb0, fileloc=..., features=..., BufStart=0x12a32cc8 "\n//#include \n\n\n//#include \n//#include \n//#include \n//#include \n//#include \n//#include \n//#include \n//#include ) at /home/harsh/Desktop/llvm/tools/clang/lib/Sema/../../include/clang/Basic/Diagnostic.h:696#9 0x000000000075369d in clang::Lexer::SkipBlockComment (this=0x129db190, Result=..., CurPtr=0x12a338c5 "*printf(\"God mode wasted \\n\")*/;\n/*\n\tswitch (gbuf[0]) \n\t\t{\n\t\t\tcase('h') :\n\t\t\t\tread(0,gbuf,6);\n\t\t\t\twrite(harpipe[1],gbuf,6);\n\t\t\tcase('t') :\n\t\t\t\tread(0,gbuf,6);\n\t\t\t\twrite(turpipe[1],gbuf,6);\n\t\t\tdefault "...) at Lexer.cpp:1629#10 0x0000000000754fd8 in clang::Lexer::LexTokenInternal (this=0x129db190, Result=...) at Lexer.cpp:2248#11 0x00000000007101e8 in clang::Lexer::Lex (this=0x129db190, Result=...) at /home/harsh/Desktop/llvm/tools/clang/lib/Frontend/../../include/clang/Lex/Lexer.h:131#12 0x00000000007102d5 in clang::Preprocessor::Lex (this=0x7fffffffc650, Result=...) at /home/harsh/Desktop/llvm/tools/clang/lib/Frontend/../../include/clang/Lex/Preprocessor.h:507#13 0x00000000007c2c84 in MyRewriter::getLexerTokens (this=0x7fffffffd750) at MyRewriter.cpp:304#14 0x00000000007c2847 in MyRewriter::getParseTrees (this=0x7fffffffd750) at MyRewriter.cpp:263#15 0x00000000007bdf26 in GeneralCandidate::parse (this=0xff09160) at GeneralCandidate.cpp:15#16 0x00000000007e3a10 in main () at CPPMain.cpp:1111 Harsh Gupta -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110704/68126f3f/attachment.html From mamuelle at niebuhrt.de Mon Jul 4 10:44:50 2011 From: mamuelle at niebuhrt.de (Toralf Niebuhr) Date: Mon, 4 Jul 2011 17:44:50 +0200 Subject: [cfe-dev] clang c++0x template function declaration error Message-ID: Hey, I am trying to get the following code to compile and I am not sure wether this is my mistake or a compiler bug: --------------------------------- test.cpp template class X { }; template auto type_constructor( void (T::*f)() ) -> X< T, f >; class Y { public: void bar() {}; }; int main () { decltype( type_constructor( &Y::bar ) ) x; } --------------------------------- It fails with the following message, which doesn't explain what went wrong: $ clang++ -c test.cpp -std=c++0x test.cpp:14:15: error: no matching function for call to 'type_constructor' decltype( type_constructor( &Y::bar ) ) x; ^~~~~~~~~~~~~~~~ test.cpp:4:6: note: candidate template ignored: substitution failure [with T = Y] auto type_constructor( void (T::*f)() ) -> X< T, f >; ^ test.cpp:14:45: error: C++ requires a type specifier for all declarations decltype( type_constructor( &Y::bar ) ) x; ~~~~~~~~ ^ 2 errors generated. Can I give you more information? From fjahanian at apple.com Mon Jul 4 11:41:13 2011 From: fjahanian at apple.com (Fariborz Jahanian) Date: Mon, 04 Jul 2011 09:41:13 -0700 Subject: [cfe-dev] Instance variables in implementation error? In-Reply-To: <035E4741-4D85-4B98-83E7-F2FFCD967751@gmail.com> References: <035E4741-4D85-4B98-83E7-F2FFCD967751@gmail.com> Message-ID: On Jul 3, 2011, at 2:33 PM, Marcel Weiher wrote: > Hi folks, > > I am working on a code-base that for various reasons has instance variables declared in both the @interface and the @implementation section. Using gcc 4.2, this is OK, but clang in 64 bit aborts with the following error: > > [elided] ../../src/Error.m:13:10: error: instance variable is already declared [3] > BOOL _isExceptional; > ^ > > Which is true, that is exactly what's happening, it was just OK (if questionable) before. > > In 32 bit mode, clang is OK with this, as is gcc 4.2 in both 32 bit and 64 bit mode. Any way to turn this error off in clang 64 bit mode? -m64 uses the non-fragile abi. This mode has a few language extensions, one of which is allowing to add 'private' ivars to the class via @implementation. So, each ivar is checked against existing ivars and diagnostic is issued for a redeclaration. You can work around this problem by adding -fno-objc-nonfragile-abi to your command line. But I should caution that we don't test nonfragile-abi in 64bit mode. And you may likely run into other issues. - fariborz > > I tried setting the Objective-C language level using the (gcc) flag '-fobjc-std=objc1' but that doesn't seem to make a difference. I did a search of the clang pages at http://clang.llvm.org/docs/UsersManual.html but the link to "Objective-C language features" is a dead link ( http://clang.llvm.org/docs/UsersManual.html#objc ), as is the C++ link. The C language features link works. > > I also tried to search the code via the error message, but that wasn't too illuminating either. > > For now, I can probably get by with using gcc 4.2, but I'd much prefer to use clang. > > Thanks! > > Marcel > > _______________________________________________ > 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/20110704/8a7507af/attachment.html From fjahanian at apple.com Mon Jul 4 11:44:55 2011 From: fjahanian at apple.com (Fariborz Jahanian) Date: Mon, 04 Jul 2011 09:44:55 -0700 Subject: [cfe-dev] Instance variables in implementation error? In-Reply-To: References: <035E4741-4D85-4B98-83E7-F2FFCD967751@gmail.com> Message-ID: On Jul 4, 2011, at 9:41 AM, Fariborz Jahanian wrote: > > On Jul 3, 2011, at 2:33 PM, Marcel Weiher wrote: > >> Hi folks, >> >> I am working on a code-base that for various reasons has instance variables declared in both the @interface and the @implementation section. Using gcc 4.2, this is OK, but clang in 64 bit aborts with the following error: >> >> [elided] ../../src/Error.m:13:10: error: instance variable is already declared [3] >> BOOL _isExceptional; >> ^ >> >> Which is true, that is exactly what's happening, it was just OK (if questionable) before. >> >> In 32 bit mode, clang is OK with this, as is gcc 4.2 in both 32 bit and 64 bit mode. Any way to turn this error off in clang 64 bit mode? > > -m64 uses the non-fragile abi. This mode has a few language extensions, one of which is allowing to add 'private' ivars > to the class via @implementation. So, each ivar is checked against existing ivars and diagnostic is issued for a redeclaration. > You can work around this problem by adding -fno-objc-nonfragile-abi to your command line. But I should caution that > we don't test nonfragile-abi in 64bit mode. And you may likely run into other issues. Meant to say with don't check fragile-abi (usually 32bit abi) in 64bit mode. - Fariborz > > - fariborz > > > >> >> I tried setting the Objective-C language level using the (gcc) flag '-fobjc-std=objc1' but that doesn't seem to make a difference. I did a search of the clang pages at http://clang.llvm.org/docs/UsersManual.html but the link to "Objective-C language features" is a dead link ( http://clang.llvm.org/docs/UsersManual.html#objc ), as is the C++ link. The C language features link works. >> >> I also tried to search the code via the error message, but that wasn't too illuminating either. >> >> For now, I can probably get by with using gcc 4.2, but I'd much prefer to use clang. >> >> Thanks! >> >> Marcel >> >> _______________________________________________ >> 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/20110704/9eb0d1b7/attachment-0001.html From tarasevich.andrey at googlemail.com Mon Jul 4 12:41:58 2011 From: tarasevich.andrey at googlemail.com (Andrey Tarasevich) Date: Mon, 4 Jul 2011 19:41:58 +0200 Subject: [cfe-dev] Get macro name or its length In-Reply-To: <7B62E9D1-D990-425F-BF4E-90A66DE4E61B@apple.com> References: <7B62E9D1-D990-425F-BF4E-90A66DE4E61B@apple.com> Message-ID: Thank you very much! It works perfect. 2011/6/30 Douglas Gregor : > > On Jun 30, 2011, at 11:17 AM, Andrey Tarasevich wrote: > >> Hello >> >> assume following code; >> >> #define MACRO ((void*)0) >> >> int main() >> { >> ? ?int n; >> ? ?int* p; >> ? ?if(p == MACRO) >> ? ? ? n = 1; >> } >> >> During the AST generation I can get the expression p == MACRO and its >> SourceLocation. The Begin and End of the SourceLocation will be >> following 80 and 2147487899. Then I can get InstantiationInfo about >> macro and begging and end of this info will be the same 85 and 85 >> according to the SourceManager class. >> So my question is the following - is there any way to retrieve the >> name of the MACRO? > > Lexer::getSpelling() > >> Or its length? > > Lexer::MeasureTokenLength() > >> How can I get position of the last >> symbol of "MACRO" word in source file? > > Preprocessor::getLocForEndOfToken() > > ? ? ? ?- Doug > > From eli.friedman at gmail.com Mon Jul 4 13:03:46 2011 From: eli.friedman at gmail.com (Eli Friedman) Date: Mon, 4 Jul 2011 11:03:46 -0700 Subject: [cfe-dev] clang c++0x template function declaration error In-Reply-To: References: Message-ID: On Mon, Jul 4, 2011 at 8:44 AM, Toralf Niebuhr wrote: > Hey, > > > I am trying to get the following code to compile and I am not sure > wether this is my mistake or a compiler bug: > > --------------------------------- test.cpp > template class X { }; > > template > auto type_constructor( void (T::*f)() ) -> X< T, f >; > > > class Y > { > ? public: > ? ? ? void bar() {}; > }; > > int main () { > ? decltype( type_constructor( &Y::bar ) ) x; > } > --------------------------------- > > It fails with the following message, which doesn't explain what went > wrong: > > $ clang++ -c test.cpp -std=c++0x > > test.cpp:14:15: error: no matching function for call to > 'type_constructor' decltype( type_constructor( &Y::bar ) ) x; > ? ? ? ? ? ? ^~~~~~~~~~~~~~~~ > test.cpp:4:6: note: candidate template ignored: substitution failure > [with T = Y] auto type_constructor( void (T::*f)() ) -> X< T, f >; > ? ?^ > test.cpp:14:45: error: C++ requires a type specifier for all > declarations decltype( type_constructor( &Y::bar ) ) x; > ? ~~~~~~~~ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?^ > 2 errors generated. > > > Can I give you more information? The declaration of the template type_constructor is broken. Think about it this way: type_constructor has one template parameter, so type_constructor should refer to a single function; however, you're trying to specify it as returning multiple types. -Eli From jfreeman at cse.tamu.edu Mon Jul 4 13:31:40 2011 From: jfreeman at cse.tamu.edu (John Freeman) Date: Mon, 04 Jul 2011 13:31:40 -0500 Subject: [cfe-dev] clang c++0x template function declaration error In-Reply-To: References: Message-ID: <4E12070C.80002@cse.tamu.edu> On 7/4/2011 1:03 PM, Eli Friedman wrote: > The declaration of the template type_constructor is broken. Think > about it this way: type_constructor has one template parameter, so > type_constructor should refer to a single function; however, you're > trying to specify it as returning multiple types. Or put another way, the second template argument for X, "foo", should be a constant function pointer, but the parameter to type_constructor, "f", is not. - John From tarasevich.andrey at googlemail.com Mon Jul 4 14:09:45 2011 From: tarasevich.andrey at googlemail.com (Andrey Tarasevich) Date: Mon, 4 Jul 2011 21:09:45 +0200 Subject: [cfe-dev] Clang and linux kernel. What include path do I need? Message-ID: Hello. I'm parsing linux kernel source code with clang in order to build correct AST. To be specific, it is Chromium OS kernel. but they are using slightly modified version of the linux kernel 2.6.32. I'm running Ubuntu 10.04 x86_64 with kernel 2.6.32-32 The problem is I can not build correct AST since clang always fires me errors, where it states, that some types are not defined although I checked the includes manually and the type definitions are correct. Include path I'm using for clang: /usr/lib/gcc/x86_64-linux-gnu/4.4/include/ /usr/src/linux-headers-2.6.32-32/include/ /usr/src/linux-headers-2.6.32-32/arch/x86/include/ /usr/src/linux-headers-2.6.32-32-generic/include/ for instance the error message I get from clang: In file included from /some_path_here/acct.c:47: In file included from /usr/src/linux-headers-2.6.32-32/include//linux/slab.h:12: In file included from /usr/src/linux-headers-2.6.32-32/include//linux/gfp.h:4: In file included from /usr/src/linux-headers-2.6.32-32/include//linux/mmzone.h:7: In file included from /usr/src/linux-headers-2.6.32-32/include//linux/spinlock.h:50: In file included from /usr/src/linux-headers-2.6.32-32/include//linux/preempt.h:9: /usr/src/linux-headers-2.6.32-32/include//linux/thread_info.h:26:4: error: unknown type name 'u32' u32 *uaddr; ^ /usr/src/linux-headers-2.6.32-32/include//linux/thread_info.h:27:4: error: unknown type name 'u32' u32 val; ^ /usr/src/linux-headers-2.6.32-32/include//linux/thread_info.h:28:4: error: unknown type name 'u32' u32 flags; ^ /usr/src/linux-headers-2.6.32-32/include//linux/thread_info.h:29:4: error: unknown type name 'u32' u32 bitset; ^ I checked the include paths and type 'u32' is defined in file /usr/src/linux-headers-2.6.32-32/include/asm-generic/int-ll64.h So my question is following am I missing some include paths or should I pass some extra compiler options for the clang? with best regards, Andrey Tarasevich From vanboxem.ruben at gmail.com Mon Jul 4 14:30:11 2011 From: vanboxem.ruben at gmail.com (Ruben Van Boxem) Date: Mon, 4 Jul 2011 21:30:11 +0200 Subject: [cfe-dev] MinGW(-w64) fixes to InitHeaderSearch.cpp and float.h In-Reply-To: References: <3ECBA685-F064-4107-A4B5-454CE4E40BAB@apple.com> <0F8A7282-8FCF-41CB-B73E-4DB7FAD04754@apple.com> Message-ID: 2011/7/2 Ruben Van Boxem : > 2011/7/2 Douglas Gregor : >> >> On Jul 2, 2011, at 6:08 AM, Ruben Van Boxem wrote: >> >>> 2011/6/27 Ruben Van Boxem : >>>> Op 27 jun. 2011 17:51 schreef "Douglas Gregor" het volgende: >>>>> >>>>> On Jun 25, 2011, at 7:51 AM, Ruben Van Boxem wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I bring fixes for MinGW(-w64) Clang users: >>>>>> >>>>>> 1. InitHeaderSearch.cpp: add a HeaderSearchOptions argument to >>>>>> AddDefaultCXXIncludePaths (AddDefaultCIncludePaths already had this, >>>>>> seems only logical to have it here) and use ResourceDir to find the >>>>>> sysroot of where Clang.exe is located. From there, add the >>>>>> x86_64-w64-mingw32 and i686-w64-mingw32 include paths for C and C++. >>>>>> All mingw-w64 toolchains are built --with-sysroot, and thus >>>>>> relocatable, so this change will always find the accompanying headers. >>>>> >>>>> I've committed this part as r133911. >>>>> >>>>>> 2. float.h: MinGW needs an #include_next, because as described on this >>>>>> page (http://msdn.microsoft.com/en-us/library/y0ybw9fy.aspx) there are >>>>>> non-standard extensions to float.h which are expected on Windows, and >>>>>> MinGW provides these declarations in their system header. GCC's >>>>>> float.h is "fixinclude"d to include_next the system header. Note that >>>>>> a trivial change is needed in mingw-w64's float.h, and that change >>>>>> will be committed as soon as Clang's header does what it's supposed to >>>>>> do. >>>>> >>>>> >>>>> If we're including MinGW's float.h first, then our own definitions of all of the standard float.h macros are going to stomp on the ones that come from MinGW's float.h. I think that's a reasonable thing to do, but if that's the intent, I'd prefer to have #undef's in our own float.h to make it explicit that this is what we're doing (and so that our own headers don't generate warnings, even if they're suppressed). >>>> >>>> I just copied that behavior (and the comment) from , but I >>>> know that mingw-w64's float.h header does #undef everything it >>>> redefines, so it would perhaps be better if the #include_next in >>>> Clang's float.h came at the end. Then nothing else needs to change >>>> much. >>>> >>>> Ruben >>>> >>> >>> I have attached a new patch with two new GCC versions for the include >>> paths, and I moved the #include_next to the end. My previous >>> testing proved this would work if the mingw-w64 headers is adapted to >>> detect Clang as well (will happen as soon as Clang's header is >>> patched). If someone would be so kind to apply these minor changes, >>> I'd be very happy. >> >> My suggestion would have been to #include_next at the beginning, then #undef everything that Clang's is going to define, so that Clang is guaranteed to get its own definitions of the standard macros. Did this not work? > > It does, I just tested it. Attached is your change. > >> >> The patch you attached is something different (a CMake change for TableGen). Is that change still necessary? > > Yes, terribly sorry for the bad attachment, I took the LLVM directory > instead of LLVM/tools/clang directory. Should have double-checked. > > Ruben > Sorry to be such a pain in the *ss, but I'd really like this patch in. Then I can build/release a mingw-w64 Clang build and you'll have a lot more testers for that platform (I hope). Thanks! Ruben -------------- next part -------------- A non-text attachment was scrubbed... Name: mingw.patch Type: application/octet-stream Size: 3134 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110704/6d5b73f1/attachment.obj From anton at korobeynikov.info Tue Jul 5 01:43:11 2011 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Tue, 5 Jul 2011 10:43:11 +0400 Subject: [cfe-dev] GSoC midterms Message-ID: Dear GSoC Students and Mentors, This is just a reminder about midterm evaluations which start on next week. So, starting from 19:00 UTC July, 11 till 19:00 UTC July, 15 you can submit your midterm evaluation forms. If you will be unable due to some reason to fill the midterm evaluation form, please let me know asap. Thanks! -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From devlists at shadowlab.org Tue Jul 5 02:56:40 2011 From: devlists at shadowlab.org (Jean-Daniel Dupas) Date: Tue, 5 Jul 2011 09:56:40 +0200 Subject: [cfe-dev] =?iso-8859-1?q?=5Bpatch=5D=A0-fno-constant-cfstrings_is?= =?iso-8859-1?q?sue?= Message-ID: <0BB1AE82-41D4-441C-8B5C-A56DFED1CFC1@shadowlab.org> Hello, I have a problem trying to compile unload able bundle with clang. According to CoreFoundation reference (1), when writing such bundle, you should the -fno-constant-cfstrings option to prevent issue with dandling CFStringRef pointer. Actually, clang completely ignore this flag and always define the __CONSTANT_CFSTRINGS__ macro, used by the CoreFoundation header to conditionally generate constant strings. I attached a patch to not define this macro when -fno-constant-cfstrings is passed to the compiler. (1): The last section of this page http://developer.apple.com/library/mac/#documentation/CoreFoundation/Conceptual/CFBundles/AccessingaBundlesContents/AccessingaBundlesContents.html -- Jean-Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: constcfstrings.patch Type: application/octet-stream Size: 606 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110705/fe4610df/attachment-0001.obj From marcel.weiher at gmail.com Tue Jul 5 04:03:28 2011 From: marcel.weiher at gmail.com (Marcel Weiher) Date: Tue, 5 Jul 2011 11:03:28 +0200 Subject: [cfe-dev] Instance variables in implementation error? In-Reply-To: References: <035E4741-4D85-4B98-83E7-F2FFCD967751@gmail.com> Message-ID: <8461F0B0-5C43-42AC-ADF8-F7249C3ABA68@gmail.com> On Jul 4, 2011, at 18:41 , Fariborz Jahanian wrote: >> I am working on a code-base that for various reasons has instance variables declared in both the @interface and the @implementation section. Using gcc 4.2, this is OK, but clang in 64 bit aborts with the following error: >> >> [..] >> In 32 bit mode, clang is OK with this, as is gcc 4.2 in both 32 bit and 64 bit mode. Any way to turn this error off in clang 64 bit mode? > > -m64 uses the non-fragile abi. This mode has a few language extensions, one of which is allowing to add 'private' ivars > to the class via @implementation. So, each ivar is checked against existing ivars and diagnostic is issued for a redeclaration. Yep. > You can work around this problem by adding -fno-objc-nonfragile-abi to your command line. But I should caution that > we don't test nonfragile-abi in 64bit mode. And you may likely run into other issues. Ahh, that was the flag I was looking for! Tried it and the errors go away, except that the linker now fails (without even an error message). Which makes sense considering all the libs it is trying to link against were almost certainly compiled with the non-fragile ABI...so I guess I should have seen that one coming. Thanks for the pointer, learn something new every day! Marcel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110705/b97d276f/attachment.html From jason.wangz at gmail.com Tue Jul 5 06:14:02 2011 From: jason.wangz at gmail.com (Zheng Wang) Date: Tue, 5 Jul 2011 12:14:02 +0100 Subject: [cfe-dev] Print Double Precision Values Message-ID: Hi, The VisitFloatingLiteral in StmtPrint is defined as: // FIXME: print value more precisely. OS << Node->getValueAsApproximateDouble(); This may result in lost of precision when printing double precision value. For example, "-3.247834652034740e3" will be printed as "-3.247835e+03" Is there any way to *precisely* print out a double precision value (i.e., the same as it appears in the source code)? Cheers, Zheng -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110705/27520ce1/attachment.html From dgregor at apple.com Tue Jul 5 09:18:09 2011 From: dgregor at apple.com (Douglas Gregor) Date: Tue, 05 Jul 2011 07:18:09 -0700 Subject: [cfe-dev] MinGW(-w64) fixes to InitHeaderSearch.cpp and float.h In-Reply-To: References: <3ECBA685-F064-4107-A4B5-454CE4E40BAB@apple.com> <0F8A7282-8FCF-41CB-B73E-4DB7FAD04754@apple.com> Message-ID: <6EF1D836-6956-4684-80DD-CD10AAD1ACA1@apple.com> On Jul 4, 2011, at 12:30 PM, Ruben Van Boxem wrote: > 2011/7/2 Ruben Van Boxem : >> 2011/7/2 Douglas Gregor : >>> >>> On Jul 2, 2011, at 6:08 AM, Ruben Van Boxem wrote: >>> >>>> 2011/6/27 Ruben Van Boxem : >>>>> Op 27 jun. 2011 17:51 schreef "Douglas Gregor" het volgende: >>>>>> >>>>>> On Jun 25, 2011, at 7:51 AM, Ruben Van Boxem wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I bring fixes for MinGW(-w64) Clang users: >>>>>>> >>>>>>> 1. InitHeaderSearch.cpp: add a HeaderSearchOptions argument to >>>>>>> AddDefaultCXXIncludePaths (AddDefaultCIncludePaths already had this, >>>>>>> seems only logical to have it here) and use ResourceDir to find the >>>>>>> sysroot of where Clang.exe is located. From there, add the >>>>>>> x86_64-w64-mingw32 and i686-w64-mingw32 include paths for C and C++. >>>>>>> All mingw-w64 toolchains are built --with-sysroot, and thus >>>>>>> relocatable, so this change will always find the accompanying headers. >>>>>> >>>>>> I've committed this part as r133911. >>>>>> >>>>>>> 2. float.h: MinGW needs an #include_next, because as described on this >>>>>>> page (http://msdn.microsoft.com/en-us/library/y0ybw9fy.aspx) there are >>>>>>> non-standard extensions to float.h which are expected on Windows, and >>>>>>> MinGW provides these declarations in their system header. GCC's >>>>>>> float.h is "fixinclude"d to include_next the system header. Note that >>>>>>> a trivial change is needed in mingw-w64's float.h, and that change >>>>>>> will be committed as soon as Clang's header does what it's supposed to >>>>>>> do. >>>>>> >>>>>> >>>>>> If we're including MinGW's float.h first, then our own definitions of all of the standard float.h macros are going to stomp on the ones that come from MinGW's float.h. I think that's a reasonable thing to do, but if that's the intent, I'd prefer to have #undef's in our own float.h to make it explicit that this is what we're doing (and so that our own headers don't generate warnings, even if they're suppressed). >>>>> >>>>> I just copied that behavior (and the comment) from , but I >>>>> know that mingw-w64's float.h header does #undef everything it >>>>> redefines, so it would perhaps be better if the #include_next in >>>>> Clang's float.h came at the end. Then nothing else needs to change >>>>> much. >>>>> >>>>> Ruben >>>>> >>>> >>>> I have attached a new patch with two new GCC versions for the include >>>> paths, and I moved the #include_next to the end. My previous >>>> testing proved this would work if the mingw-w64 headers is adapted to >>>> detect Clang as well (will happen as soon as Clang's header is >>>> patched). If someone would be so kind to apply these minor changes, >>>> I'd be very happy. >>> >>> My suggestion would have been to #include_next at the beginning, then #undef everything that Clang's is going to define, so that Clang is guaranteed to get its own definitions of the standard macros. Did this not work? >> >> It does, I just tested it. Attached is your change. >> >>> >>> The patch you attached is something different (a CMake change for TableGen). Is that change still necessary? >> >> Yes, terribly sorry for the bad attachment, I took the LLVM directory >> instead of LLVM/tools/clang directory. Should have double-checked. >> >> Ruben >> > > Sorry to be such a pain in the *ss, but I'd really like this patch in. > Then I can build/release a mingw-w64 Clang build and you'll have a lot > more testers for that platform (I hope). It *is* a holiday weekend in the United States, where most of the code owners are located. Committed as r134406 and r134407. - Doug From dgregor at apple.com Tue Jul 5 09:45:57 2011 From: dgregor at apple.com (Douglas Gregor) Date: Tue, 05 Jul 2011 07:45:57 -0700 Subject: [cfe-dev] tests of bindings/python fail? In-Reply-To: References: <312F99EC-8D56-4143-BC73-6837DE54BEAE@apple.com> Message-ID: <55A4A341-DD52-4AF6-ADC0-F43644C1793F@apple.com> On Jul 3, 2011, at 8:16 PM, Eli Bendersky wrote: > | We'll happily commit patches to keep the Python bindings working. > > - Doug > > I'm attaching a patch (diffed against trunk) with some fixes to the Python bindings, making its tests pass again (on Linux and Windows). > > Some details of the patch: > > * Implemented a new function in libclang: clang_isAttr - it is similar to existing clang_Is* functions. Also exposed it to the Python bindings as the is_attr method of Cursor > * Fixing TranslationUnit.get_includes to only go through the argument buffer when it contains something. This fixed a crash on Windows > * clang_getFileName returns CXString, not char*. Made appropriate fixes in cindex.py - now the relevant tests pass and we can see the full locations correctly again (previously there was garbage in place of the file name) > * Exposed clang_getCursorDisplayName to the python bindings Very nice. > P.S. the patch file was created with 'svn diff' in the root of clang, so it should be applied as 'patch -p0' there. I hope this is an accepted way to submit patches - if something different is required, I'll gladly fix. Yes, this is the right way to submit patches, thanks for working on this! A few minor comments: Index: include/clang-c/Index.h =================================================================== --- include/clang-c/Index.h (revision 134366) +++ include/clang-c/Index.h (working copy) @@ -1474,6 +1474,11 @@ CINDEX_LINKAGE unsigned clang_isStatement(enum CXCursorKind); /** + * \brief Determine whether the given cursor kind represents an attribute. + */ +CINDEX_LINKAGE unsigned clang_isAttr(enum CXCursorKind); + +/** Please name this "clang_isAttribute" to be more consistent with the naming of similar functions. Index: tools/libclang/libclang.exports =================================================================== --- tools/libclang/libclang.exports (revision 134366) +++ tools/libclang/libclang.exports (working copy) @@ -123,6 +123,7 @@ clang_isReference clang_isRestrictQualifiedType clang_isStatement +clang_isAttr clang_isTranslationUnit clang_isUnexposed clang_isVirtualBase This list is meant to be sorted. Also, please update libclang.darwin.exports as well. - Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110705/2a08b066/attachment.html From vanboxem.ruben at gmail.com Tue Jul 5 10:06:48 2011 From: vanboxem.ruben at gmail.com (Ruben Van Boxem) Date: Tue, 5 Jul 2011 17:06:48 +0200 Subject: [cfe-dev] MinGW(-w64) fixes to InitHeaderSearch.cpp and float.h In-Reply-To: <6EF1D836-6956-4684-80DD-CD10AAD1ACA1@apple.com> References: <3ECBA685-F064-4107-A4B5-454CE4E40BAB@apple.com> <0F8A7282-8FCF-41CB-B73E-4DB7FAD04754@apple.com> <6EF1D836-6956-4684-80DD-CD10AAD1ACA1@apple.com> Message-ID: 2011/7/5 Douglas Gregor : > > On Jul 4, 2011, at 12:30 PM, Ruben Van Boxem wrote: > >> 2011/7/2 Ruben Van Boxem : >>> 2011/7/2 Douglas Gregor : >>>> >>>> On Jul 2, 2011, at 6:08 AM, Ruben Van Boxem wrote: >>>> >>>>> 2011/6/27 Ruben Van Boxem : >>>>>> Op 27 jun. 2011 17:51 schreef "Douglas Gregor" het volgende: >>>>>>> >>>>>>> On Jun 25, 2011, at 7:51 AM, Ruben Van Boxem wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I bring fixes for MinGW(-w64) Clang users: >>>>>>>> >>>>>>>> 1. InitHeaderSearch.cpp: add a HeaderSearchOptions argument to >>>>>>>> AddDefaultCXXIncludePaths (AddDefaultCIncludePaths already had this, >>>>>>>> seems only logical to have it here) and use ResourceDir to find the >>>>>>>> sysroot of where Clang.exe is located. From there, add the >>>>>>>> x86_64-w64-mingw32 and i686-w64-mingw32 include paths for C and C++. >>>>>>>> All mingw-w64 toolchains are built --with-sysroot, and thus >>>>>>>> relocatable, so this change will always find the accompanying headers. >>>>>>> >>>>>>> I've committed this part as r133911. >>>>>>> >>>>>>>> 2. float.h: MinGW needs an #include_next, because as described on this >>>>>>>> page (http://msdn.microsoft.com/en-us/library/y0ybw9fy.aspx) there are >>>>>>>> non-standard extensions to float.h which are expected on Windows, and >>>>>>>> MinGW provides these declarations in their system header. GCC's >>>>>>>> float.h is "fixinclude"d to include_next the system header. Note that >>>>>>>> a trivial change is needed in mingw-w64's float.h, and that change >>>>>>>> will be committed as soon as Clang's header does what it's supposed to >>>>>>>> do. >>>>>>> >>>>>>> >>>>>>> If we're including MinGW's float.h first, then our own definitions of all of the standard float.h macros are going to stomp on the ones that come from MinGW's float.h. I think that's a reasonable thing to do, but if that's the intent, I'd prefer to have #undef's in our own float.h to make it explicit that this is what we're doing (and so that our own headers don't generate warnings, even if they're suppressed). >>>>>> >>>>>> I just copied that behavior (and the comment) from , but I >>>>>> know that mingw-w64's float.h header does #undef everything it >>>>>> redefines, so it would perhaps be better if the #include_next in >>>>>> Clang's float.h came at the end. Then nothing else needs to change >>>>>> much. >>>>>> >>>>>> Ruben >>>>>> >>>>> >>>>> I have attached a new patch with two new GCC versions for the include >>>>> paths, and I moved the #include_next to the end. My previous >>>>> testing proved this would work if the mingw-w64 headers is adapted to >>>>> detect Clang as well (will happen as soon as Clang's header is >>>>> patched). If someone would be so kind to apply these minor changes, >>>>> I'd be very happy. >>>> >>>> My suggestion would have been to #include_next at the beginning, then #undef everything that Clang's is going to define, so that Clang is guaranteed to get its own definitions of the standard macros. Did this not work? >>> >>> It does, I just tested it. Attached is your change. >>> >>>> >>>> The patch you attached is something different (a CMake change for TableGen). Is that change still necessary? >>> >>> Yes, terribly sorry for the bad attachment, I took the LLVM directory >>> instead of LLVM/tools/clang directory. Should have double-checked. >>> >>> Ruben >>> >> >> Sorry to be such a pain in the *ss, but I'd really like this patch in. >> Then I can build/release a mingw-w64 Clang build and you'll have a lot >> more testers for that platform (I hope). > > It *is* a holiday weekend in the United States, where most of the code owners are located. So it is :) must have forgotten about that :s At least I know I'm a pain in the *ss. Thanks *very* much! Ruben From eldlistmailingz at tropicsoft.com Tue Jul 5 10:13:08 2011 From: eldlistmailingz at tropicsoft.com (Edward Diener) Date: Tue, 05 Jul 2011 11:13:08 -0400 Subject: [cfe-dev] Building clang encounters llvm samples.c problem Message-ID: I am building clang on Mingw in Windows. I was able to straighten out an earlier problem and now everything in clang appears to build correctly. Near the end of "make" processing, it seems, I eventually ran into this error: "llvm[4]: Compiling sample.c for Debug+Asserts build C:/Programming/VersionControl/llvm/projects/sample/lib/sample/sample.c:18:20: fatal error: sample.h: No such file or directory compilation terminated." Looking at sample.c I see: #include "sample.h" but there is no sample.h in the same directory as sample.c but only in the llvm/projects/sample/include directory. Is this an LLVM problem or is it related to clang in some way ? Should not it be '#include ' instead ? Has clang completely finished building once this occurs ? It does look like everything else built OK and the error is only occuring trying to build the sample program for LLVM. From fjahanian at apple.com Tue Jul 5 11:01:34 2011 From: fjahanian at apple.com (jahanian) Date: Tue, 05 Jul 2011 09:01:34 -0700 Subject: [cfe-dev] =?iso-8859-1?q?=5Bpatch=5D=A0-fno-constant-cfstrings_is?= =?iso-8859-1?q?sue?= In-Reply-To: <0BB1AE82-41D4-441C-8B5C-A56DFED1CFC1@shadowlab.org> References: <0BB1AE82-41D4-441C-8B5C-A56DFED1CFC1@shadowlab.org> Message-ID: Thanks. Patch checked in r134414. - fariborz On Jul 5, 2011, at 12:56 AM, Jean-Daniel Dupas wrote: > Hello, > > I have a problem trying to compile unload able bundle with clang. According to CoreFoundation reference (1), when writing such bundle, you should the -fno-constant-cfstrings option to prevent issue with dandling CFStringRef pointer. > > Actually, clang completely ignore this flag and always define the __CONSTANT_CFSTRINGS__ macro, used by the CoreFoundation header to conditionally generate constant strings. > > I attached a patch to not define this macro when -fno-constant-cfstrings is passed to the compiler. > > > > (1): The last section of this page http://developer.apple.com/library/mac/#documentation/CoreFoundation/Conceptual/CFBundles/AccessingaBundlesContents/AccessingaBundlesContents.html > > > -- Jean-Daniel > > > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From vanboxem.ruben at gmail.com Tue Jul 5 11:07:29 2011 From: vanboxem.ruben at gmail.com (Ruben Van Boxem) Date: Tue, 5 Jul 2011 18:07:29 +0200 Subject: [cfe-dev] MinGW(-w64) fixes to InitHeaderSearch.cpp and float.h In-Reply-To: References: <3ECBA685-F064-4107-A4B5-454CE4E40BAB@apple.com> <0F8A7282-8FCF-41CB-B73E-4DB7FAD04754@apple.com> <6EF1D836-6956-4684-80DD-CD10AAD1ACA1@apple.com> Message-ID: 2011/7/5 Ruben Van Boxem : > 2011/7/5 Douglas Gregor : >> >> On Jul 4, 2011, at 12:30 PM, Ruben Van Boxem wrote: >> >>> 2011/7/2 Ruben Van Boxem : >>>> 2011/7/2 Douglas Gregor : >>>>> >>>>> On Jul 2, 2011, at 6:08 AM, Ruben Van Boxem wrote: >>>>> >>>>>> 2011/6/27 Ruben Van Boxem : >>>>>>> Op 27 jun. 2011 17:51 schreef "Douglas Gregor" het volgende: >>>>>>>> >>>>>>>> On Jun 25, 2011, at 7:51 AM, Ruben Van Boxem wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I bring fixes for MinGW(-w64) Clang users: >>>>>>>>> >>>>>>>>> 1. InitHeaderSearch.cpp: add a HeaderSearchOptions argument to >>>>>>>>> AddDefaultCXXIncludePaths (AddDefaultCIncludePaths already had this, >>>>>>>>> seems only logical to have it here) and use ResourceDir to find the >>>>>>>>> sysroot of where Clang.exe is located. From there, add the >>>>>>>>> x86_64-w64-mingw32 and i686-w64-mingw32 include paths for C and C++. >>>>>>>>> All mingw-w64 toolchains are built --with-sysroot, and thus >>>>>>>>> relocatable, so this change will always find the accompanying headers. >>>>>>>> >>>>>>>> I've committed this part as r133911. >>>>>>>> >>>>>>>>> 2. float.h: MinGW needs an #include_next, because as described on this >>>>>>>>> page (http://msdn.microsoft.com/en-us/library/y0ybw9fy.aspx) there are >>>>>>>>> non-standard extensions to float.h which are expected on Windows, and >>>>>>>>> MinGW provides these declarations in their system header. GCC's >>>>>>>>> float.h is "fixinclude"d to include_next the system header. Note that >>>>>>>>> a trivial change is needed in mingw-w64's float.h, and that change >>>>>>>>> will be committed as soon as Clang's header does what it's supposed to >>>>>>>>> do. >>>>>>>> >>>>>>>> >>>>>>>> If we're including MinGW's float.h first, then our own definitions of all of the standard float.h macros are going to stomp on the ones that come from MinGW's float.h. I think that's a reasonable thing to do, but if that's the intent, I'd prefer to have #undef's in our own float.h to make it explicit that this is what we're doing (and so that our own headers don't generate warnings, even if they're suppressed). >>>>>>> >>>>>>> I just copied that behavior (and the comment) from , but I >>>>>>> know that mingw-w64's float.h header does #undef everything it >>>>>>> redefines, so it would perhaps be better if the #include_next in >>>>>>> Clang's float.h came at the end. Then nothing else needs to change >>>>>>> much. >>>>>>> >>>>>>> Ruben >>>>>>> >>>>>> >>>>>> I have attached a new patch with two new GCC versions for the include >>>>>> paths, and I moved the #include_next to the end. My previous >>>>>> testing proved this would work if the mingw-w64 headers is adapted to >>>>>> detect Clang as well (will happen as soon as Clang's header is >>>>>> patched). If someone would be so kind to apply these minor changes, >>>>>> I'd be very happy. >>>>> >>>>> My suggestion would have been to #include_next at the beginning, then #undef everything that Clang's is going to define, so that Clang is guaranteed to get its own definitions of the standard macros. Did this not work? >>>> >>>> It does, I just tested it. Attached is your change. >>>> >>>>> >>>>> The patch you attached is something different (a CMake change for TableGen). Is that change still necessary? >>>> >>>> Yes, terribly sorry for the bad attachment, I took the LLVM directory >>>> instead of LLVM/tools/clang directory. Should have double-checked. >>>> >>>> Ruben >>>> >>> >>> Sorry to be such a pain in the *ss, but I'd really like this patch in. >>> Then I can build/release a mingw-w64 Clang build and you'll have a lot >>> more testers for that platform (I hope). >> >> It *is* a holiday weekend in the United States, where most of the code owners are located. > > So it is :) must have forgotten about that :s At least I know I'm a > pain in the *ss. Thanks *very* much! > > Ruben > I just noticed the new float.h undef's everything twice if __MINGW32__ is defined. I assume it was the idea to remove the undef's outside of the __MINGW32__ ifdef? From dgregor at apple.com Tue Jul 5 11:09:31 2011 From: dgregor at apple.com (Douglas Gregor) Date: Tue, 05 Jul 2011 09:09:31 -0700 Subject: [cfe-dev] MinGW(-w64) fixes to InitHeaderSearch.cpp and float.h In-Reply-To: References: <3ECBA685-F064-4107-A4B5-454CE4E40BAB@apple.com> <0F8A7282-8FCF-41CB-B73E-4DB7FAD04754@apple.com> <6EF1D836-6956-4684-80DD-CD10AAD1ACA1@apple.com> Message-ID: On Jul 5, 2011, at 9:07 AM, Ruben Van Boxem wrote: > 2011/7/5 Ruben Van Boxem : >> 2011/7/5 Douglas Gregor : >>> >>> On Jul 4, 2011, at 12:30 PM, Ruben Van Boxem wrote: >>> >>>> 2011/7/2 Ruben Van Boxem : >>>>> 2011/7/2 Douglas Gregor : >>>>>> >>>>>> On Jul 2, 2011, at 6:08 AM, Ruben Van Boxem wrote: >>>>>> >>>>>>> 2011/6/27 Ruben Van Boxem : >>>>>>>> Op 27 jun. 2011 17:51 schreef "Douglas Gregor" het volgende: >>>>>>>>> >>>>>>>>> On Jun 25, 2011, at 7:51 AM, Ruben Van Boxem wrote: >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I bring fixes for MinGW(-w64) Clang users: >>>>>>>>>> >>>>>>>>>> 1. InitHeaderSearch.cpp: add a HeaderSearchOptions argument to >>>>>>>>>> AddDefaultCXXIncludePaths (AddDefaultCIncludePaths already had this, >>>>>>>>>> seems only logical to have it here) and use ResourceDir to find the >>>>>>>>>> sysroot of where Clang.exe is located. From there, add the >>>>>>>>>> x86_64-w64-mingw32 and i686-w64-mingw32 include paths for C and C++. >>>>>>>>>> All mingw-w64 toolchains are built --with-sysroot, and thus >>>>>>>>>> relocatable, so this change will always find the accompanying headers. >>>>>>>>> >>>>>>>>> I've committed this part as r133911. >>>>>>>>> >>>>>>>>>> 2. float.h: MinGW needs an #include_next, because as described on this >>>>>>>>>> page (http://msdn.microsoft.com/en-us/library/y0ybw9fy.aspx) there are >>>>>>>>>> non-standard extensions to float.h which are expected on Windows, and >>>>>>>>>> MinGW provides these declarations in their system header. GCC's >>>>>>>>>> float.h is "fixinclude"d to include_next the system header. Note that >>>>>>>>>> a trivial change is needed in mingw-w64's float.h, and that change >>>>>>>>>> will be committed as soon as Clang's header does what it's supposed to >>>>>>>>>> do. >>>>>>>>> >>>>>>>>> >>>>>>>>> If we're including MinGW's float.h first, then our own definitions of all of the standard float.h macros are going to stomp on the ones that come from MinGW's float.h. I think that's a reasonable thing to do, but if that's the intent, I'd prefer to have #undef's in our own float.h to make it explicit that this is what we're doing (and so that our own headers don't generate warnings, even if they're suppressed). >>>>>>>> >>>>>>>> I just copied that behavior (and the comment) from , but I >>>>>>>> know that mingw-w64's float.h header does #undef everything it >>>>>>>> redefines, so it would perhaps be better if the #include_next in >>>>>>>> Clang's float.h came at the end. Then nothing else needs to change >>>>>>>> much. >>>>>>>> >>>>>>>> Ruben >>>>>>>> >>>>>>> >>>>>>> I have attached a new patch with two new GCC versions for the include >>>>>>> paths, and I moved the #include_next to the end. My previous >>>>>>> testing proved this would work if the mingw-w64 headers is adapted to >>>>>>> detect Clang as well (will happen as soon as Clang's header is >>>>>>> patched). If someone would be so kind to apply these minor changes, >>>>>>> I'd be very happy. >>>>>> >>>>>> My suggestion would have been to #include_next at the beginning, then #undef everything that Clang's is going to define, so that Clang is guaranteed to get its own definitions of the standard macros. Did this not work? >>>>> >>>>> It does, I just tested it. Attached is your change. >>>>> >>>>>> >>>>>> The patch you attached is something different (a CMake change for TableGen). Is that change still necessary? >>>>> >>>>> Yes, terribly sorry for the bad attachment, I took the LLVM directory >>>>> instead of LLVM/tools/clang directory. Should have double-checked. >>>>> >>>>> Ruben >>>>> >>>> >>>> Sorry to be such a pain in the *ss, but I'd really like this patch in. >>>> Then I can build/release a mingw-w64 Clang build and you'll have a lot >>>> more testers for that platform (I hope). >>> >>> It *is* a holiday weekend in the United States, where most of the code owners are located. >> >> So it is :) must have forgotten about that :s At least I know I'm a >> pain in the *ss. Thanks *very* much! >> >> Ruben >> > > I just noticed the new float.h undef's everything twice if __MINGW32__ > is defined. I assume it was the idea to remove the undef's outside of > the __MINGW32__ ifdef? Please "svn revert" your float.h; I moved the undefs inside of the __MINGW32__ ifdef. - Doug From vanboxem.ruben at gmail.com Tue Jul 5 11:18:58 2011 From: vanboxem.ruben at gmail.com (Ruben Van Boxem) Date: Tue, 5 Jul 2011 18:18:58 +0200 Subject: [cfe-dev] MinGW(-w64) fixes to InitHeaderSearch.cpp and float.h In-Reply-To: References: <3ECBA685-F064-4107-A4B5-454CE4E40BAB@apple.com> <0F8A7282-8FCF-41CB-B73E-4DB7FAD04754@apple.com> <6EF1D836-6956-4684-80DD-CD10AAD1ACA1@apple.com> Message-ID: 2011/7/5 Douglas Gregor : > > On Jul 5, 2011, at 9:07 AM, Ruben Van Boxem wrote: > >> 2011/7/5 Ruben Van Boxem : >>> 2011/7/5 Douglas Gregor : >>>> >>>> On Jul 4, 2011, at 12:30 PM, Ruben Van Boxem wrote: >>>> >>>>> 2011/7/2 Ruben Van Boxem : >>>>>> 2011/7/2 Douglas Gregor : >>>>>>> >>>>>>> On Jul 2, 2011, at 6:08 AM, Ruben Van Boxem wrote: >>>>>>> >>>>>>>> 2011/6/27 Ruben Van Boxem : >>>>>>>>> Op 27 jun. 2011 17:51 schreef "Douglas Gregor" het volgende: >>>>>>>>>> >>>>>>>>>> On Jun 25, 2011, at 7:51 AM, Ruben Van Boxem wrote: >>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I bring fixes for MinGW(-w64) Clang users: >>>>>>>>>>> >>>>>>>>>>> 1. InitHeaderSearch.cpp: add a HeaderSearchOptions argument to >>>>>>>>>>> AddDefaultCXXIncludePaths (AddDefaultCIncludePaths already had this, >>>>>>>>>>> seems only logical to have it here) and use ResourceDir to find the >>>>>>>>>>> sysroot of where Clang.exe is located. From there, add the >>>>>>>>>>> x86_64-w64-mingw32 and i686-w64-mingw32 include paths for C and C++. >>>>>>>>>>> All mingw-w64 toolchains are built --with-sysroot, and thus >>>>>>>>>>> relocatable, so this change will always find the accompanying headers. >>>>>>>>>> >>>>>>>>>> I've committed this part as r133911. >>>>>>>>>> >>>>>>>>>>> 2. float.h: MinGW needs an #include_next, because as described on this >>>>>>>>>>> page (http://msdn.microsoft.com/en-us/library/y0ybw9fy.aspx) there are >>>>>>>>>>> non-standard extensions to float.h which are expected on Windows, and >>>>>>>>>>> MinGW provides these declarations in their system header. GCC's >>>>>>>>>>> float.h is "fixinclude"d to include_next the system header. Note that >>>>>>>>>>> a trivial change is needed in mingw-w64's float.h, and that change >>>>>>>>>>> will be committed as soon as Clang's header does what it's supposed to >>>>>>>>>>> do. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> If we're including MinGW's float.h first, then our own definitions of all of the standard float.h macros are going to stomp on the ones that come from MinGW's float.h. I think that's a reasonable thing to do, but if that's the intent, I'd prefer to have #undef's in our own float.h to make it explicit that this is what we're doing (and so that our own headers don't generate warnings, even if they're suppressed). >>>>>>>>> >>>>>>>>> I just copied that behavior (and the comment) from , but I >>>>>>>>> know that mingw-w64's float.h header does #undef everything it >>>>>>>>> redefines, so it would perhaps be better if the #include_next in >>>>>>>>> Clang's float.h came at the end. Then nothing else needs to change >>>>>>>>> much. >>>>>>>>> >>>>>>>>> Ruben >>>>>>>>> >>>>>>>> >>>>>>>> I have attached a new patch with two new GCC versions for the include >>>>>>>> paths, and I moved the #include_next to the end. My previous >>>>>>>> testing proved this would work if the mingw-w64 headers is adapted to >>>>>>>> detect Clang as well (will happen as soon as Clang's header is >>>>>>>> patched). If someone would be so kind to apply these minor changes, >>>>>>>> I'd be very happy. >>>>>>> >>>>>>> My suggestion would have been to #include_next at the beginning, then #undef everything that Clang's is going to define, so that Clang is guaranteed to get its own definitions of the standard macros. Did this not work? >>>>>> >>>>>> It does, I just tested it. Attached is your change. >>>>>> >>>>>>> >>>>>>> The patch you attached is something different (a CMake change for TableGen). Is that change still necessary? >>>>>> >>>>>> Yes, terribly sorry for the bad attachment, I took the LLVM directory >>>>>> instead of LLVM/tools/clang directory. Should have double-checked. >>>>>> >>>>>> Ruben >>>>>> >>>>> >>>>> Sorry to be such a pain in the *ss, but I'd really like this patch in. >>>>> Then I can build/release a mingw-w64 Clang build and you'll have a lot >>>>> more testers for that platform (I hope). >>>> >>>> It *is* a holiday weekend in the United States, where most of the code owners are located. >>> >>> So it is :) must have forgotten about that :s At least I know I'm a >>> pain in the *ss. Thanks *very* much! >>> >>> Ruben >>> >> >> I just noticed the new float.h undef's everything twice if __MINGW32__ >> is defined. I assume it was the idea to remove the undef's outside of >> the __MINGW32__ ifdef? > > Please "svn revert" your float.h; I moved the undefs inside of the __MINGW32__ ifdef. > > ? ? ? ?- Doug > I see, sorry for the noise. From bigeric144 at gmail.com Tue Jul 5 13:20:36 2011 From: bigeric144 at gmail.com (bigeric144) Date: Tue, 5 Jul 2011 11:20:36 -0700 (PDT) Subject: [cfe-dev] Cannot run Clang Analyzer Message-ID: <1309890036913-3141859.post@n3.nabble.com> Hi All, I am new to the development side of Clang, I have built from source and am trying to run the static analyzer on the test files included in the clang source. I'm using the arguments within each test file but I am not able to get anything specific to work. Example: I run the following command clang -cc1 -analyze -analyzer-checker=core,core.experimental.CastToStruct And get this error in return: Argument unused during compilation: '-analyze' Argument unused during compilation: '-analyze-checker' It appears to me that the checkers are not being ran at all. Any advice on how to rectify this problem? Thank you for your time! Eric -- View this message in context: http://clang-developers.42468.n3.nabble.com/Cannot-run-Clang-Analyzer-tp3141859p3141859.html Sent from the Clang Developers mailing list archive at Nabble.com. From as at hacks.yi.org Tue Jul 5 13:32:43 2011 From: as at hacks.yi.org (austin seipp) Date: Tue, 5 Jul 2011 13:32:43 -0500 Subject: [cfe-dev] Cannot run Clang Analyzer In-Reply-To: <1309890036913-3141859.post@n3.nabble.com> References: <1309890036913-3141859.post@n3.nabble.com> Message-ID: Right now the recommended way to run the checkers for external projects is using the 'scan-build' tool (located under ./llvm/tools/clang/tools/scan-build, and its cousin, scan-view for viewing reports.) It's basically a hack^H^H^H^H perl script that transposes the clang analyzer into your build, followed by running your real compiler (like gcc) over it. So it really makes the analysis 'transparent' to your regular build system. You can effectively just put the 'scan-build' command in front of your regular build system command, and the script will 'do the rest' (by properly setting CC vars, etc..) The situation isn't optimal since scan-build isn't full proof, but it works in a surprising amount of situations (I've had success with make, xcodebuild, waf, etc etc.) There are outstanding bugs on the tracker related to moving scan-build functionality into the clang driver, but I there are probably still some issues to work out relating to the design before that can be done (like how the user should invoke the driver, should compilation proceed with the analyzer, or do you only want to run the analyzer and abandon actual codegen? etc.) scan-build also does not enable all checkers (such as experimental ones) by default. If you run 'scan-build -h' you can see the list of available checkers and what's enabled by default, and you can use '-enable-checker ' to enable an extra one. If you're curious, you can also invoke 'scan-build -v' when you run it and it'll show you the list of arguments it directly passes to the clang -cc1 driver during the compilation, so you can see the 'real' command line needed to invoke the analyzer. Last time I tried this the arguments were somewhat involved, so if possible it'd probably be best to just use scan-build and save yourself the trouble (or if that doesn't work, perhaps help move scan-build into the compiler driver...) On Tue, Jul 5, 2011 at 1:20 PM, bigeric144 wrote: > Hi All, > > > I am new to the development side of Clang, I have built from source and am > trying to run the static analyzer on the test files included in the clang > source. I'm using the arguments within each test file but I am not able to > get anything specific to work. > Example: I run the following command > ?clang -cc1 -analyze -analyzer-checker=core,core.experimental.CastToStruct > > And get this error in return: > Argument unused during compilation: '-analyze' > Argument unused during compilation: '-analyze-checker' > > > > It appears to me that the checkers are not being ran at all. Any advice on > how to rectify this problem? Thank you for your time! > > > Eric > > -- > View this message in context: http://clang-developers.42468.n3.nabble.com/Cannot-run-Clang-Analyzer-tp3141859p3141859.html > Sent from the Clang Developers mailing list archive at Nabble.com. > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > -- Regards, Austin From clattner at apple.com Tue Jul 5 13:44:26 2011 From: clattner at apple.com (Chris Lattner) Date: Tue, 05 Jul 2011 11:44:26 -0700 Subject: [cfe-dev] segfault in lexing In-Reply-To: References: Message-ID: On Jul 4, 2011, at 8:34 AM, harsh gupta wrote: > I am using the lexer to get a stream of tokens for a file. However if there is a nested block comment, > > for eg /* some comment /*This is a nested comment*/ some more comment */ > > Then the lexer gives a segmentation fault. Is there any way to avoid this segmentation fault? It's hard to tell without more information, you probably don't have diagnostics set up right. Note that this is *not* a nested block comment, C doesn't have any such thing. If you run this through 'clang -E' you'll see this warning: t.c:1:24: warning: '/*' within block comment [-Wcomment] which is probably being mishandled. -Chris > > The code that i am using is: > clang::DiagnosticOptions diagnosticOptions; > clang::TextDiagnosticPrinter *pTextDiagnosticPrinter = new clang::TextDiagnosticPrinter( llvm::outs(), diagnosticOptions); > llvm::IntrusiveRefCntPtr pDiagIDs; > clang::Diagnostic diagnostic(pDiagIDs,pTextDiagnosticPrinter); > > clang::LangOptions languageOptions; > clang::FileSystemOptions fileSystemOptions; > clang::FileManager fileManager(fileSystemOptions); > > > clang::SourceManager sourceManager( diagnostic, fileManager); > clang::HeaderSearch headerSearch(fileManager); > > clang::TargetOptions targetOptions; > targetOptions.Triple = llvm::sys::getHostTriple(); > > clang::TargetInfo *pTargetInfo = > clang::TargetInfo::CreateTargetInfo( diagnostic, targetOptions); > > clang::Preprocessor preprocessor( diagnostic, languageOptions, *pTargetInfo, sourceManager, headerSearch); > > const clang::FileEntry *pFile = fileManager.getFile( _outFilename); > sourceManager.createMainFileID(pFile); > preprocessor.EnterMainSourceFile(); > > std::vector cmdvect; > GeneralCommand cmd; > clang::Token token; > do { > preprocessor.Lex(token); > if( diagnostic.hasErrorOccurred()) > { > break; > } > > } while(token.isNot(clang::tok::eof)); > > > > And the backtrace is: > > Program received signal SIGSEGV, Segmentation fault. > 0x00000000004708fc in clang::LangOptions::LangOptions (this=0x7fffffffbc38) at /home/harsh/Desktop/llvm/tools/clang/lib/Sema/../../include/clang/Basic/LangOptions.h:24 > 24 class LangOptions { > (gdb) bt > #0 0x00000000004708fc in clang::LangOptions::LangOptions (this=0x7fffffffbc38) at /home/harsh/Desktop/llvm/tools/clang/lib/Sema/../../include/clang/Basic/LangOptions.h:24 > #1 0x00000000007502c2 in clang::Lexer::Lexer (this=0x7fffffffbbb0, fileloc=..., features=..., > BufStart=0x12a32cc8 "\n//#include \n\n\n//#include \n//#include \n//#include \n//#include \n//#include \n//#include \n//#include \n//#include BufPtr=0x12a338c4 "/*printf(\"God mode wasted \\n\")*/;\n/*\n\tswitch (gbuf[0]) \n\t\t{\n\t\t\tcase('h') :\n\t\t\t\tread(0,gbuf,6);\n\t\t\t\twrite(harpipe[1],gbuf,6);\n\t\t\tcase('t') :\n\t\t\t\tread(0,gbuf,6);\n\t\t\t\twrite(turpipe[1],gbuf,6);\n\t\t\tdefault"..., BufEnd=0x12a3411a "") at Lexer.cpp:117 > #2 0x0000000000750ae8 in clang::Lexer::MeasureTokenLength (Loc=..., SM=..., LangOpts=...) at Lexer.cpp:349 > #3 0x0000000000744116 in clang::TextDiagnosticPrinter::EmitCaretDiagnostic (this=0x12a0ab30, Loc=..., Ranges=0x7fffffffc010, NumRanges=0, SM=..., Hints=0x0, NumHints=0, Columns=0, OnMacroInst=0, > MacroSkipStart=0, MacroSkipEnd=0) at TextDiagnosticPrinter.cpp:382 > #4 0x0000000000746a4d in clang::TextDiagnosticPrinter::HandleDiagnostic (this=0x12a0ab30, Level=clang::Diagnostic::Warning, Info=...) at TextDiagnosticPrinter.cpp:1041 > #5 0x0000000000921c04 in clang::DiagnosticIDs::ProcessDiag (this=0x0, Diag=...) at DiagnosticIDs.cpp:582 > #6 0x000000000091cc03 in clang::Diagnostic::ProcessDiag (this=0x7fffffffd410) at /home/harsh/Desktop/llvm/tools/clang/lib/Basic/../../include/clang/Basic/Diagnostic.h:608 > #7 0x000000000091b4a2 in clang::DiagnosticBuilder::Emit (this=0x7fffffffc460) at Diagnostic.cpp:225 > #8 0x0000000000421ee2 in clang::DiagnosticBuilder::~DiagnosticBuilder (this=0x7fffffffc460, __in_chrg=) > at /home/harsh/Desktop/llvm/tools/clang/lib/Sema/../../include/clang/Basic/Diagnostic.h:696 > #9 0x000000000075369d in clang::Lexer::SkipBlockComment (this=0x129db190, Result=..., > CurPtr=0x12a338c5 "*printf(\"God mode wasted \\n\")*/;\n/*\n\tswitch (gbuf[0]) \n\t\t{\n\t\t\tcase('h') :\n\t\t\t\tread(0,gbuf,6);\n\t\t\t\twrite(harpipe[1],gbuf,6);\n\t\t\tcase('t') :\n\t\t\t\tread(0,gbuf,6);\n\t\t\t\twrite(turpipe[1],gbuf,6);\n\t\t\tdefault "...) at Lexer.cpp:1629 > #10 0x0000000000754fd8 in clang::Lexer::LexTokenInternal (this=0x129db190, Result=...) at Lexer.cpp:2248 > #11 0x00000000007101e8 in clang::Lexer::Lex (this=0x129db190, Result=...) at /home/harsh/Desktop/llvm/tools/clang/lib/Frontend/../../include/clang/Lex/Lexer.h:131 > #12 0x00000000007102d5 in clang::Preprocessor::Lex (this=0x7fffffffc650, Result=...) at /home/harsh/Desktop/llvm/tools/clang/lib/Frontend/../../include/clang/Lex/Preprocessor.h:507 > #13 0x00000000007c2c84 in MyRewriter::getLexerTokens (this=0x7fffffffd750) at MyRewriter.cpp:304 > #14 0x00000000007c2847 in MyRewriter::getParseTrees (this=0x7fffffffd750) at MyRewriter.cpp:263 > #15 0x00000000007bdf26 in GeneralCandidate::parse (this=0xff09160) at GeneralCandidate.cpp:15 > #16 0x00000000007e3a10 in main () at CPPMain.cpp:1111 > > Harsh Gupta > > > _______________________________________________ > 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/20110705/533d65b7/attachment.html From bigeric144 at gmail.com Tue Jul 5 13:52:31 2011 From: bigeric144 at gmail.com (bigeric144) Date: Tue, 5 Jul 2011 11:52:31 -0700 (PDT) Subject: [cfe-dev] Cannot run Clang Analyzer In-Reply-To: References: <1309890036913-3141859.post@n3.nabble.com> Message-ID: <1309891951732-3141983.post@n3.nabble.com> Thanks for the quick response Austin! The main reason why I have rebuilt Clang in the first place was because I created a new checker and I wanted to test it out on some code that I wrote. Is there any way to get scan-build to point to my executable of clang in my build directory? Just for some context, I created the checker.cpp file, added it to checker directory and added a new line in checkers.td then subsequently built llvm+clang. All and all, my primary goal is to extend clang in terms of new checkers and have been trying to get the analysis to run with these new checkers. If there is any advice or guidance it would be greatly appreciated! Thanks again for taking your time to help! Eric -- View this message in context: http://clang-developers.42468.n3.nabble.com/Cannot-run-Clang-Analyzer-tp3141859p3141983.html Sent from the Clang Developers mailing list archive at Nabble.com. From nickwalters99 at gmail.com Tue Jul 5 13:53:34 2011 From: nickwalters99 at gmail.com (Nick Walters) Date: Tue, 5 Jul 2011 12:53:34 -0600 Subject: [cfe-dev] Adding new keywords to the lexer Message-ID: Hello, I am attempting to modify Clang to add a simple language extension which requires, as a first step, adding a few additional keywords to the lexer. I have modified: ./include/clang/Basic/TokenKinds.def To add my keywords, e.g: KEYWORD(myfirstkeyword , KEYALL) KEYWORD(mysecondkeyword , KEYALL) After recompiling, I try to run clang with this simple C++ program to verify that clang still works on source files that do not use these keywords: #include using namespace std; int main(int argc, char** argv){ cout << "Hello, Clang!" << endl; return 0; } $ clang++ hello.cpp And the command fails with the following assertion / stack trace: Assertion failed: (isAnnotation() && "Used AnnotVal on non-annotation token"), function setAnnotationValue, file /Users/nickw/llvm/tools/clang/lib/Parse/../../include/clang/Lex/Token.h, line 209. 0 clang 0x0000000101a0f0d0 PrintStackTrace(void*) + 38 1 clang 0x0000000101a0f7bd SignalHandler(int) + 254 2 libSystem.B.dylib 0x00007fff80af51ba _sigtramp + 26 3 clang 0x000000010040704d bool llvm::isa(clang::NamedDecl* const&) + 21 4 clang 0x0000000101a0f00d raise + 27 5 clang 0x0000000101a0f01d abort + 14 6 clang 0x0000000101a0f0aa PrintStackTrace(void*) + 0 7 clang 0x000000010035c3b2 clang::Token::setAnnotationValue(void*) + 156 8 clang 0x000000010034a46e clang::Parser::setExprAnnotation(clang::Token&, clang::ActionResult) + 66 9 clang 0x000000010034521c clang::Parser::ParseStatementOrDeclaration(clang::ASTOwningVector&, bool) + 1344 10 clang 0x00000001003488a6 clang::Parser::ParseCompoundStatementBody(bool) + 932 11 clang 0x0000000100348e2d clang::Parser::ParseCompoundStatement(clang::ParsedAttributes&, bool) + 131 12 clang 0x000000010034561c clang::Parser::ParseStatementOrDeclaration(clang::ASTOwningVector&, bool) + 2368 13 clang 0x000000010034a4b2 clang::Parser::ParseStatement() + 66 14 clang 0x00000001003473e2 clang::Parser::ParseIfStatement(clang::ParsedAttributes&) + 626 15 clang 0x00000001003456a1 clang::Parser::ParseStatementOrDeclaration(clang::ASTOwningVector&, bool) + 2501 16 clang 0x00000001003488a6 clang::Parser::ParseCompoundStatementBody(bool) + 932 17 clang 0x0000000100348d27 clang::Parser::ParseFunctionStatementBody(clang::Decl*, clang::Parser::ParseScope&) + 211 18 clang 0x00000001003568fd clang::Parser::ParseFunctionDefinition(clang::Parser::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&) + 2291 19 clang 0x000000010030df99 clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec&, unsigned int, bool, clang::SourceLocation*, clang::Parser::ForRangeInit*) + 499 20 clang 0x0000000100353b91 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&, clang::AccessSpecifier) + 959 21 clang 0x0000000100353c09 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes&, clang::AccessSpecifier) + 95 22 clang 0x0000000100354562 clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::Parser::ParsingDeclSpec*) + 2364 23 clang 0x0000000100320b9c clang::Parser::ParseInnerNamespace(std::__debug::vector >&, std::__debug::vector >&, std::__debug::vector >&, unsigned int, clang::SourceLocation&, clang::SourceLocation&, clang::ParsedAttributes&, clang::SourceLocation&) + 162 24 clang 0x0000000100321866 clang::Parser::ParseNamespace(unsigned int, clang::SourceLocation&, clang::SourceLocation) + 2844 25 clang 0x00000001003159ba clang::Parser::ParseDeclaration(clang::ASTOwningVector&, unsigned int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) + 658 26 clang 0x00000001003541da clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::Parser::ParsingDeclSpec*) + 1460 27 clang 0x00000001003548a2 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) + 256 28 clang 0x0000000100304b30 clang::ParseAST(clang::Sema&, bool) + 340 29 clang 0x000000010007ec71 clang::ASTFrontendAction::ExecuteAction() + 233 30 clang 0x00000001002d1977 clang::CodeGenAction::ExecuteAction() + 793 31 clang 0x000000010007ed7e clang::FrontendAction::Execute() + 262 32 clang 0x000000010006272e clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 710 33 clang 0x0000000100010219 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 787 34 clang 0x0000000100001cb0 cc1_main(char const**, char const**, char const*, void*) + 897 35 clang 0x000000010000b852 main + 500 36 clang 0x0000000100001434 start + 52 37 clang 0x0000000000000025 start + 4294962213 Stack dump: 0. Program arguments: /Users/nickw/llvm-run/bin/clang -cc1 -triple x86_64-apple-macosx10.6.8 -emit-obj -mrelax-all -disable-free -main-file-name hello.cpp -pic-level 1 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 123.2 -resource-dir /Users/nickw/llvm-run/bin/../lib/clang/3.0 -fdeprecated-macro -ferror-limit 19 -fmessage-length 80 -stack-protector 1 -fblocks -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /var/folders/5m/5m7eYxMpHliIX3JMlBEiH++++TI/-Tmp-/cc-1XdoBa.o -x c++ hello.cpp 1. /usr/include/c++/4.2.1/i686-apple-darwin10/x86_64/bits/c++locale.h:70:2: current parser token '__sav' 2. /usr/include/c++/4.2.1/i686-apple-darwin10/x86_64/bits/c++locale.h:53:1 : parsing namespace 'std' 3. /usr/include/c++/4.2.1/i686-apple-darwin10/x86_64/bits/c++locale.h:65:3: parsing function body '__convert_from_v' 4. /usr/include/c++/4.2.1/i686-apple-darwin10/x86_64/bits/c++locale.h:65:3: in compound statement ('{}') 5. /usr/include/c++/4.2.1/i686-apple-darwin10/x86_64/bits/c++locale.h:69:7: in compound statement ('{}') clang: error: unable to execute command: Illegal instruction clang: error: clang frontend command failed due to signal 2 (use -v to see invocation) I added some additional debug output, and the token in question at which this fails is the ?unknown? token. I have grepped around the clang codebase to find if there is any other areas I have to modify when adding new keywords and I have tried everything I can think of at this point. I have tried several variations of modifying TokenKinds.def, and it doesn?t seem to matter what the keywords I add to TokenKinds.def are ? when I add two new keywords, it breaks clang?s ability to compile a simple test source like the above. I greatly appreciate any help / insights on this. Thanks! Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110705/a9d34c64/attachment.html From as at hacks.yi.org Tue Jul 5 14:06:02 2011 From: as at hacks.yi.org (austin seipp) Date: Tue, 5 Jul 2011 14:06:02 -0500 Subject: [cfe-dev] Cannot run Clang Analyzer In-Reply-To: <1309891951732-3141983.post@n3.nabble.com> References: <1309890036913-3141859.post@n3.nabble.com> <1309891951732-3141983.post@n3.nabble.com> Message-ID: > The main reason why I have rebuilt Clang in the first place was because I > created a new checker and I wanted to test it out on some code that I wrote. > Is there any way to get scan-build to point to my executable of clang in my > build directory? I'd guess that scan-build will use whatever clang executable it finds first on your PATH. Perhaps just set your PATH to point to your clang build before any other, and then try? Note: I can't verify this, it's just reasonable speculation. Ted or someone would have to chime in to tell you the truth with any confidence. > Just for some context, I created the checker.cpp file, > added it to checker directory and added a new line in checkers.td then > subsequently built llvm+clang. All and all, my primary goal is to extend > clang in terms of new checkers and have been trying to get the analysis to > run with these new checkers. If there is any advice or guidance it would be > greatly appreciated! Thanks again for taking your time to help! > I've written a few checkers in my spare time too and honestly I normally end up putting them in the 'Core' package (in Checkers.td) during development so they are always on by default and I can just use 'scan-build,' and move them to other packages (like core.experimental) later once I'm done. Granted I only wrote tiny ones that I didn't push upstream (because coincidentally, other people ended up re-implementing them within the same day or two. :) -- Regards, Austin From greened at obbligato.org Tue Jul 5 15:43:06 2011 From: greened at obbligato.org (David A. Greene) Date: Tue, 05 Jul 2011 15:43:06 -0500 Subject: [cfe-dev] [LLVMdev] Introduction to git-bisect with "llvm-project.git" In-Reply-To: (NAKAMURA Takumi's message of "Thu, 30 Jun 2011 12:57:38 +0900") References: Message-ID: NAKAMURA Takumi writes: > I am making a submodule-based metaproject "llvm-project.git" for > bisecting clang. > I will introduce it to help you developers. > Unfortunately, submodule is not useful to manage your branches. :/ I'm working on a similar thing, actually, Unfortunately, my server has atrocious upstream bandwidth. ADSL is not kind to developers. :( I started off using git-submodule but found it unintuitive and annoying due to its use of detached head states. git-subtree is much, much better. :) http://apenwarr.ca/log/?m=200904 -Dave From eldlistmailingz at tropicsoft.com Tue Jul 5 17:22:44 2011 From: eldlistmailingz at tropicsoft.com (Edward Diener) Date: Tue, 05 Jul 2011 18:22:44 -0400 Subject: [cfe-dev] Using clang built with MSYS/Mingw on Windows Message-ID: I have been able to build clang using MSYS using the instructions on the clang web site. Everything appears to have built correctly except for a problem building the llvm sample program which I reported, and nobody has responded to. So I will ignore the problem as I see I have a clang.exe and a clang++.exe in the build/llvm/Debug+Asserts/bin directory. I have a number of questions: 1) Do I need to re-run 'configure' followed by 'make' each time I get the latest llvm and clang from SVN, or is running 'make' good enough. 2) How does clang find its headers and libraries ? In the clang User Manual under "Operating System Features and Limitations" for Mingw32 it says: "MinGW32 Clang works on some mingw32 distributions. Clang assumes directories as below; C:/mingw/include C:/mingw/lib C:/mingw/lib/gcc/mingw32/4.[3-5].0/include/c++" This is a little confusing to me. When running clang, built through MSYS, does clang understands Windows paths or does it need to be run from within MSYS and therefore understand only Linux-like paths ? The note suggests the former. 3) Can clang handle the Windows header files used by gcc in its include directory as specified above ? 4) What is the difference between clang and clang++.exe ? I do not mean to be critical because I know that many developers are working to make clang better, but the online Users Manual is pretty sparse in information, so I am hoping someone can help me here or point me to better explanations. I want to use clang to test out Boost libraries on which I am working. I heavily prefer staying on Windows so I am hoping I can use clang there. Thanks ! From ofv at wanadoo.es Tue Jul 5 18:22:55 2011 From: ofv at wanadoo.es (=?utf-8?Q?=C3=93scar_Fuentes?=) Date: Wed, 06 Jul 2011 01:22:55 +0200 Subject: [cfe-dev] Using clang built with MSYS/Mingw on Windows References: Message-ID: <8739ikpb1s.fsf@wanadoo.es> Edward Diener writes: > I have been able to build clang using MSYS using the instructions on the > clang web site. Everything appears to have built correctly except for a > problem building the llvm sample program which I reported, and nobody > has responded to. So I will ignore the problem as I see I have a > clang.exe and a clang++.exe in the build/llvm/Debug+Asserts/bin directory. > > I have a number of questions: > > 1) Do I need to re-run 'configure' followed by 'make' each time I get > the latest llvm and clang from SVN, or is running 'make' good enough. After you executed `configure' for the first time, the makefiles will automatically run `configure' whenever necessary. > 2) How does clang find its headers and libraries ? In the clang User > Manual under "Operating System Features and Limitations" for Mingw32 it > says: > > "MinGW32 > > Clang works on some mingw32 distributions. Clang assumes directories as > below; > > C:/mingw/include > C:/mingw/lib > C:/mingw/lib/gcc/mingw32/4.[3-5].0/include/c++" > > This is a little confusing to me. I think that clang has the paths hard-coded for MinGW. > When running clang, built through MSYS, does clang understands Windows > paths or does it need to be run from within MSYS and therefore > understand only Linux-like paths ? The note suggests the former. The paths you quoted are not unix-like paths. Lots of Windows functionality handle `/' as path separator quite fine. MSYS is required only for building clang (if you build with configure+make) not for executing it. > 3) Can clang handle the Windows header files used by gcc in its include > directory as specified above ? AFAIK yes. > 4) What is the difference between clang and clang++.exe ? Just the name. When the executable starts it reads its own name from argv[0]. If it is clang++.exe, several options for compiling and linking C++ programs are automatically added. You can use clang.exe for compiling C++ sources, but then you need to add lots of options to the command line for correctly handling C++ programs. > I do not mean to be critical because I know that many developers are > working to make clang better, but the online Users Manual is pretty > sparse in information, so I am hoping someone can help me here or point > me to better explanations. I don't use clang on Windows, but once you are confident with it, if you submit a documentation patch that would be a good contribution. [snip] From ppelletier at oblong.com Tue Jul 5 18:26:40 2011 From: ppelletier at oblong.com (Patrick Pelletier) Date: Tue, 05 Jul 2011 16:26:40 -0700 Subject: [cfe-dev] ::delete behaves differently in clang and gcc when class has a virtual destructor Message-ID: <4E139DB0.8000201@oblong.com> I'm reluctant to allege a bug in clang, since so far my experience has been that when clang's behavior differs from gcc, clang is being more standards-compliant than gcc. However, in this particular case, I haven't been able to find any documentation that indicates that Standard C++ is supposed to do what clang seems to be doing. So, I'd like to ask whether there's a possibility that this is a clang bug, or whether it's just a very obscure corner of the standard that I haven't been able to find any mention of. First of all, here are the assumptions I'm starting with: a) the "delete" expression calls the object's destructor, followed by calling "operator delete" on the object b) "::delete" is the same as "delete", except that instead of calling "operator delete", it calls "::operator delete" If these assumptions are correct, then in the program below, I would expect case 1 to call Foo's operator delete, but I would not expect case 2 or case 3 to call Foo's operator delete. (Indeed, based on my assumptions above, I would expect case 2 and case 3 to be identical; my belief is that case 3 is just a manual de-sugaring of case 2.) When compiled with gcc, the program below behaves as I would expect. However, when compiled with clang, the program as written (i. e. with the virtual destructor) does not behave as I expect, in that Foo's operator delete is called in case 2. (Although still not in case 3.) The presence of the virtual destructor is important. If I simply remove the word "virtual" from the declaration of ~Foo(), then the program behaves identically in clang and gcc, and both are what I expect. (i. e. case 1 is the only case that calls Foo's operator delete.) Thanks for any light you can shed on this behavior, and my apologies if this is indeed expected behavior that I am unaware of. --Patrick ppelletier at pumpkin:~/misc$ uname -a Linux pumpkin 2.6.32-21-generic #32-Ubuntu SMP Fri Apr 16 08:09:38 UTC 2010 x86_64 GNU/Linux ppelletier at pumpkin:~/misc$ cat delete-test.C #include static const char *msg; class Foo { const int n; public: Foo (int n_in); virtual ~Foo (); void operator delete (void *); }; Foo::Foo (int n_in) : n (n_in) { } Foo::~Foo () { std::cerr << "destructor for " << n << std::endl; } void Foo::operator delete (void *) { std::cerr << msg << std::endl; } int main (int argc, char **argv) { msg = "[1] I would expect this to be printed (and it is)"; Foo *f1 = new Foo (1); delete f1; msg = "[2] I would not expect this to be printed (gcc doesn't, clang does)"; Foo *f2 = new Foo (2); ::delete f2; msg = "[3] This should not be printed either (and it isn't)"; Foo *f3 = new Foo (3); f3 -> ~Foo (); ::operator delete (f3); return 0; } ppelletier at pumpkin:~/misc$ /home/ppelletier/src/asan/asan_clang_Linux/bin/clang++ --version clang version 3.0 (trunk 133511) Target: x86_64-unknown-linux-gnu Thread model: posix ppelletier at pumpkin:~/misc$ g++ --version g++ (Ubuntu 4.4.3-4ubuntu5) 4.4.3 Copyright (C) 2009 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ppelletier at pumpkin:~/misc$ /home/ppelletier/src/asan/asan_clang_Linux/bin/clang++ -O3 -Wall -o delete-test-clang delete-test.C ppelletier at pumpkin:~/misc$ g++ -O3 -Wall -o delete-test-gcc delete-test.C ppelletier at pumpkin:~/misc$ ./delete-test-clang destructor for 1 [1] I would expect this to be printed (and it is) destructor for 2 [2] I would not expect this to be printed (gcc doesn't, clang does) destructor for 3 ppelletier at pumpkin:~/misc$ ./delete-test-gcc destructor for 1 [1] I would expect this to be printed (and it is) destructor for 2 destructor for 3 ppelletier at pumpkin:~/misc$ From eliben at gmail.com Tue Jul 5 20:47:13 2011 From: eliben at gmail.com (Eli Bendersky) Date: Wed, 6 Jul 2011 04:47:13 +0300 Subject: [cfe-dev] tests of bindings/python fail? In-Reply-To: <55A4A341-DD52-4AF6-ADC0-F43644C1793F@apple.com> References: <312F99EC-8D56-4143-BC73-6837DE54BEAE@apple.com> <55A4A341-DD52-4AF6-ADC0-F43644C1793F@apple.com> Message-ID: On Tue, Jul 5, 2011 at 17:45, Douglas Gregor wrote: > > On Jul 3, 2011, at 8:16 PM, Eli Bendersky wrote: > > | We'll happily commit patches to keep the Python bindings working. > >> >> - Doug >> > > I'm attaching a patch (diffed against trunk) with some fixes to the Python > bindings, making its tests pass again (on Linux and Windows). > > Some details of the patch: > > * Implemented a new function in libclang: clang_isAttr - it is similar to > existing clang_Is* functions. Also exposed it to the Python bindings as the > is_attr method of Cursor > * Fixing TranslationUnit.get_includes to only go through the argument > buffer when it contains something. This fixed a crash on Windows > * clang_getFileName returns CXString, not char*. Made appropriate fixes in > cindex.py - now the relevant tests pass and we can see the full locations > correctly again (previously there was garbage in place of the file name) > * Exposed clang_getCursorDisplayName to the python bindings > > > Very nice. > > P.S. the patch file was created with 'svn diff' in the root of clang, so it > should be applied as 'patch -p0' there. I hope this is an accepted way to > submit patches - if something different is required, I'll gladly fix. > > > Yes, this is the right way to submit patches, thanks for working on this! > > A few minor comments: > > Index: include/clang-c/Index.h > =================================================================== > --- include/clang-c/Index.h (revision 134366) > +++ include/clang-c/Index.h (working copy) > @@ -1474,6 +1474,11 @@ > CINDEX_LINKAGE unsigned clang_isStatement(enum CXCursorKind); > > /** > + * \brief Determine whether the given cursor kind represents an attribute. > + */ > +CINDEX_LINKAGE unsigned clang_isAttr(enum CXCursorKind); > + > +/** > > Please name this "clang_isAttribute" to be more consistent with the naming > of similar functions. > > Index: tools/libclang/libclang.exports > =================================================================== > --- tools/libclang/libclang.exports (revision 134366) > +++ tools/libclang/libclang.exports (working copy) > @@ -123,6 +123,7 @@ > clang_isReference > clang_isRestrictQualifiedType > clang_isStatement > +clang_isAttr > clang_isTranslationUnit > clang_isUnexposed > clang_isVirtualBase > > This list is meant to be sorted. Also, please update > libclang.darwin.exports as well. > > Hi Doug, thanks for the review. I'm attaching an updated patch with fixes for all your comments. Eli -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110706/506065e5/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: pybindings_fixes.2.patch Type: application/octet-stream Size: 6650 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110706/506065e5/attachment-0001.obj From dgregor at apple.com Tue Jul 5 22:01:25 2011 From: dgregor at apple.com (Douglas Gregor) Date: Tue, 05 Jul 2011 20:01:25 -0700 Subject: [cfe-dev] tests of bindings/python fail? In-Reply-To: References: <312F99EC-8D56-4143-BC73-6837DE54BEAE@apple.com> <55A4A341-DD52-4AF6-ADC0-F43644C1793F@apple.com> Message-ID: <6F5A66CF-F310-4AC4-8B64-44B571B5F0BE@apple.com> On Jul 5, 2011, at 6:47 PM, Eli Bendersky wrote: > > > On Tue, Jul 5, 2011 at 17:45, Douglas Gregor wrote: > > On Jul 3, 2011, at 8:16 PM, Eli Bendersky wrote: > >> | We'll happily commit patches to keep the Python bindings working. >> >> - Doug >> >> I'm attaching a patch (diffed against trunk) with some fixes to the Python bindings, making its tests pass again (on Linux and Windows). >> >> Some details of the patch: >> >> * Implemented a new function in libclang: clang_isAttr - it is similar to existing clang_Is* functions. Also exposed it to the Python bindings as the is_attr method of Cursor >> * Fixing TranslationUnit.get_includes to only go through the argument buffer when it contains something. This fixed a crash on Windows >> * clang_getFileName returns CXString, not char*. Made appropriate fixes in cindex.py - now the relevant tests pass and we can see the full locations correctly again (previously there was garbage in place of the file name) >> * Exposed clang_getCursorDisplayName to the python bindings > > Very nice. > >> P.S. the patch file was created with 'svn diff' in the root of clang, so it should be applied as 'patch -p0' there. I hope this is an accepted way to submit patches - if something different is required, I'll gladly fix. > > Yes, this is the right way to submit patches, thanks for working on this! > > A few minor comments: > > Index: include/clang-c/Index.h > =================================================================== > --- include/clang-c/Index.h (revision 134366) > +++ include/clang-c/Index.h (working copy) > @@ -1474,6 +1474,11 @@ > CINDEX_LINKAGE unsigned clang_isStatement(enum CXCursorKind); > > /** > + * \brief Determine whether the given cursor kind represents an attribute. > + */ > +CINDEX_LINKAGE unsigned clang_isAttr(enum CXCursorKind); > + > +/** > > Please name this "clang_isAttribute" to be more consistent with the naming of similar functions. > > Index: tools/libclang/libclang.exports > =================================================================== > --- tools/libclang/libclang.exports (revision 134366) > +++ tools/libclang/libclang.exports (working copy) > @@ -123,6 +123,7 @@ > clang_isReference > clang_isRestrictQualifiedType > clang_isStatement > +clang_isAttr > clang_isTranslationUnit > clang_isUnexposed > clang_isVirtualBase > > This list is meant to be sorted. Also, please update libclang.darwin.exports as well. > > > Hi Doug, thanks for the review. I'm attaching an updated patch with fixes for all your comments. Committed as r134460, thanks! I forgot to mention it before, but please send future patches to the cfe-commits mailing list. - Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110705/7e6db5be/attachment.html From jfreeman at cse.tamu.edu Tue Jul 5 22:56:44 2011 From: jfreeman at cse.tamu.edu (John Freeman) Date: Tue, 05 Jul 2011 22:56:44 -0500 Subject: [cfe-dev] Lookahead vs. Tentative Parsing Message-ID: <4E13DCFC.7090808@cse.tamu.edu> Since C++ lambda expressions and Objective-C message expressions can each start with the same two tokens (l_square followed by identifier), it can take a lookahead of three tokens to differentiate the two cases. There are other instances, especially in C++, where further lookahead, or even semantic analysis, may be required. In the case above, I guess that lookahead is enough to decide which parsing path to take, but in general, what are the criteria for deciding to use lookahead vs. tentative parsing? With tentative parsing, are diagnostics suppressed until the parsing has been committed? - John From eliben at gmail.com Tue Jul 5 23:07:54 2011 From: eliben at gmail.com (Eli Bendersky) Date: Wed, 6 Jul 2011 07:07:54 +0300 Subject: [cfe-dev] tests of bindings/python fail? In-Reply-To: <6F5A66CF-F310-4AC4-8B64-44B571B5F0BE@apple.com> References: <312F99EC-8D56-4143-BC73-6837DE54BEAE@apple.com> <55A4A341-DD52-4AF6-ADC0-F43644C1793F@apple.com> <6F5A66CF-F310-4AC4-8B64-44B571B5F0BE@apple.com> Message-ID: > > > Hi Doug, thanks for the review. I'm attaching an updated patch with fixes > for all your comments. > > > Committed as r134460, thanks! > > I forgot to mention it before, but please send future patches to the > cfe-commits mailing list. > > Thanks. Will do. Eli -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110706/a2db6d63/attachment.html From dblaikie at gmail.com Tue Jul 5 23:22:14 2011 From: dblaikie at gmail.com (David Blaikie) Date: Tue, 5 Jul 2011 21:22:14 -0700 Subject: [cfe-dev] Lookahead vs. Tentative Parsing In-Reply-To: <4E13DCFC.7090808@cse.tamu.edu> References: <4E13DCFC.7090808@cse.tamu.edu> Message-ID: > > Since C++ lambda expressions and Objective-C message expressions can > each start with the same two tokens (l_square followed by identifier), > it can take a lookahead of three tokens to differentiate the two cases. > I'm playing around with implementing this myself. But why would you need a lookahead when these only appear in distinct languages? Currently there's a "if objective C, start parsing a message" I was just going to add an "if C++, start parsing a lambda" after that. Are you working on this too? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110705/5ce943e2/attachment.html From rjmccall at apple.com Tue Jul 5 23:33:12 2011 From: rjmccall at apple.com (John McCall) Date: Tue, 05 Jul 2011 21:33:12 -0700 Subject: [cfe-dev] Lookahead vs. Tentative Parsing In-Reply-To: References: <4E13DCFC.7090808@cse.tamu.edu> Message-ID: On Jul 5, 2011, at 9:22 PM, David Blaikie wrote: > Since C++ lambda expressions and Objective-C message expressions can > each start with the same two tokens (l_square followed by identifier), > it can take a lookahead of three tokens to differentiate the two cases. > > I'm playing around with implementing this myself. But why would you need a lookahead when these only appear in distinct languages? Currently there's a "if objective C, start parsing a message" I was just going to add an "if C++, start parsing a lambda" after that. Objective-C++ exists and is important to a lot of our developers; any implementation of lambdas in Clang will eventually need to handle both. John. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110705/86a2c362/attachment.html From eliben at gmail.com Tue Jul 5 23:38:15 2011 From: eliben at gmail.com (Eli Bendersky) Date: Wed, 6 Jul 2011 07:38:15 +0300 Subject: [cfe-dev] tests of bindings/python fail? In-Reply-To: <6F5A66CF-F310-4AC4-8B64-44B571B5F0BE@apple.com> References: <312F99EC-8D56-4143-BC73-6837DE54BEAE@apple.com> <55A4A341-DD52-4AF6-ADC0-F43644C1793F@apple.com> <6F5A66CF-F310-4AC4-8B64-44B571B5F0BE@apple.com> Message-ID: Hi Doug, thanks for the review. I'm attaching an updated patch with fixes for all your comments. > Committed as r134460, thanks! > > I forgot to mention it before, but please send future patches to the > cfe-commits mailing list. > > - Doug > Hi Doug, Another related question: I would like to expose the various statement kinds in libclang, to allow client code to reason based on the type of statement it encounters. Currently none of the statement kinds (except labels) is exposed. Would it be acceptable to submit a fix for this, or is the statement kind enumeration kept intentionally minimal? Eli -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110706/b6d891a4/attachment-0001.html From dblaikie at gmail.com Tue Jul 5 23:41:54 2011 From: dblaikie at gmail.com (David Blaikie) Date: Tue, 5 Jul 2011 21:41:54 -0700 Subject: [cfe-dev] Lookahead vs. Tentative Parsing In-Reply-To: References: <4E13DCFC.7090808@cse.tamu.edu> Message-ID: > > Objective-C++ exists and is important to a lot of our developers; any > implementation of lambdas in Clang will eventually need to handle both. > Ah, Ok then. Though I assume lambdas aren't a high priority for Apple at the moment, given the presence of Blocks. Is that the case? That's why I thought I'd start looking at it myself as it seems like a feature the wider community might have more interest/motivation to work on than the Apple folks. (I at least assume that a solution similar to the one I outlined wouldn't make it terribly inconvenient to improve later to allow for ObjC++ lambdas) I suppose the question is whether "getLang().CPlusPlus0x" is true for Objective-C++, or only actual C++0x? Well for now the ObjC case for messages comes first - so it won't pollute the C++0x lambda case until someone wants to add in Obj-C++ lambdas. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110705/cd6f5905/attachment.html From rjmccall at apple.com Tue Jul 5 23:54:40 2011 From: rjmccall at apple.com (John McCall) Date: Tue, 05 Jul 2011 21:54:40 -0700 Subject: [cfe-dev] Lookahead vs. Tentative Parsing In-Reply-To: References: <4E13DCFC.7090808@cse.tamu.edu> Message-ID: <529C63F2-8F2E-463E-A693-0120092D8A13@apple.com> On Jul 5, 2011, at 9:41 PM, David Blaikie wrote: > Objective-C++ exists and is important to a lot of our developers; any implementation of lambdas in Clang will eventually need to handle both. > > Ah, Ok then. Though I assume lambdas aren't a high priority for Apple at the moment, given the presence of Blocks. Is that the case? That's why I thought I'd start looking at it myself as it seems like a feature the wider community might have more interest/motivation to work on than the Apple folks. I don't think we'll openly weep if the first patches we see don't work in Objective-C++, but don't do anything that would it impossible. > I suppose the question is whether "getLang().CPlusPlus0x" is true for Objective-C++, or only actual C++0x? Objective-C (and its revisions and supplements) is orthogonal to C++. We can and do support using the Objective-C extensions in code whose "base" standard is C++0x. > Well for now the ObjC case for messages comes first - so it won't pollute the C++0x lambda case until someone wants to add in Obj-C++ lambdas. That seems like a reasonable approach. John. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110705/45e4ccef/attachment.html From dgregor at apple.com Tue Jul 5 23:54:53 2011 From: dgregor at apple.com (Douglas Gregor) Date: Tue, 05 Jul 2011 21:54:53 -0700 Subject: [cfe-dev] tests of bindings/python fail? In-Reply-To: References: <312F99EC-8D56-4143-BC73-6837DE54BEAE@apple.com> <55A4A341-DD52-4AF6-ADC0-F43644C1793F@apple.com> <6F5A66CF-F310-4AC4-8B64-44B571B5F0BE@apple.com> Message-ID: On Jul 5, 2011, at 9:38 PM, Eli Bendersky wrote: > >> Hi Doug, thanks for the review. I'm attaching an updated patch with fixes for all your comments. > > Committed as r134460, thanks! > > I forgot to mention it before, but please send future patches to the cfe-commits mailing list. > > - Doug > > Hi Doug, > Another related question: I would like to expose the various statement kinds in libclang, to allow client code to reason based on the type of statement it encounters. Currently none of the statement kinds (except labels) is exposed. Would it be acceptable to submit a fix for this, or is the statement kind enumeration kept intentionally minimal? It's fine to submit a fix for this, as long as the exposed cursor kinds map to language constructs and not Clang internal implementation details. - Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110705/5dad926d/attachment.html From dblaikie at gmail.com Wed Jul 6 00:00:02 2011 From: dblaikie at gmail.com (David Blaikie) Date: Tue, 5 Jul 2011 22:00:02 -0700 Subject: [cfe-dev] Lookahead vs. Tentative Parsing In-Reply-To: <529C63F2-8F2E-463E-A693-0120092D8A13@apple.com> References: <4E13DCFC.7090808@cse.tamu.edu> <529C63F2-8F2E-463E-A693-0120092D8A13@apple.com> Message-ID: > > I suppose the question is whether "getLang().CPlusPlus0x" is true for > Objective-C++, or only actual C++0x? > > > Objective-C (and its revisions and supplements) is orthogonal to C++. We > can and do support using the Objective-C extensions in code whose "base" > standard is C++0x. > More formally, that is to say that getLang().CPlusPlus0x and getLang().ObjC can both be true at the same time? > Well for now the ObjC case for messages comes first - so it won't pollute > the C++0x lambda case until someone wants to add in Obj-C++ lambdas. > > > That seems like a reasonable approach. > Great - thanks. (but perhaps John will get there before me - we'll see. I've just been looking at it the last few days as an experiment/foray into the Clang/LLVM codebase) - David -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110705/ca0eedb6/attachment.html From rjmccall at apple.com Wed Jul 6 00:01:26 2011 From: rjmccall at apple.com (John McCall) Date: Tue, 05 Jul 2011 22:01:26 -0700 Subject: [cfe-dev] Lookahead vs. Tentative Parsing In-Reply-To: References: <4E13DCFC.7090808@cse.tamu.edu> <529C63F2-8F2E-463E-A693-0120092D8A13@apple.com> Message-ID: On Jul 5, 2011, at 10:00 PM, David Blaikie wrote: >> I suppose the question is whether "getLang().CPlusPlus0x" is true for Objective-C++, or only actual C++0x? > > Objective-C (and its revisions and supplements) is orthogonal to C++. We can and do support using the Objective-C extensions in code whose "base" standard is C++0x. > > More formally, that is to say that getLang().CPlusPlus0x and getLang().ObjC can both be true at the same time? Yes. John. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110705/6370dec0/attachment.html From clattner at apple.com Wed Jul 6 00:33:57 2011 From: clattner at apple.com (Chris Lattner) Date: Tue, 05 Jul 2011 22:33:57 -0700 Subject: [cfe-dev] Lookahead vs. Tentative Parsing In-Reply-To: References: <4E13DCFC.7090808@cse.tamu.edu> <529C63F2-8F2E-463E-A693-0120092D8A13@apple.com> Message-ID: <3C599427-1D02-4B30-8C0C-2FE7B5C21DB2@apple.com> On Jul 5, 2011, at 10:01 PM, John McCall wrote: > On Jul 5, 2011, at 10:00 PM, David Blaikie wrote: >>> I suppose the question is whether "getLang().CPlusPlus0x" is true for Objective-C++, or only actual C++0x? >> >> Objective-C (and its revisions and supplements) is orthogonal to C++. We can and do support using the Objective-C extensions in code whose "base" standard is C++0x. >> >> More formally, that is to say that getLang().CPlusPlus0x and getLang().ObjC can both be true at the same time? > > Yes. We even support the new ARC Objective-C feature in all modes as well, meaning that folks can write code in Objective-ARC++'0x if they so choose. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110705/9b6d8d3b/attachment-0001.html From dlmeetei at gmail.com Wed Jul 6 01:30:00 2011 From: dlmeetei at gmail.com (Devchandra L Meetei) Date: Wed, 6 Jul 2011 12:00:00 +0530 Subject: [cfe-dev] Mac OS default compiler Message-ID: Hi All Is clang default compiler for C/C++ in Mac Os? if so, is gcc still supported in Mac? The reason for the questions is to know if it is ok to support clang for a open source project which already supports gcc under Mac Os Regards --Dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110706/28428d55/attachment.html From echristo at apple.com Wed Jul 6 03:41:22 2011 From: echristo at apple.com (Eric Christopher) Date: Wed, 06 Jul 2011 01:41:22 -0700 Subject: [cfe-dev] Mac OS default compiler In-Reply-To: References: Message-ID: <4267564A-0363-4F69-91BB-C343B0B27336@apple.com> On Jul 5, 2011, at 11:30 PM, Devchandra L Meetei wrote: > Hi All > Is clang default compiler for C/C++ in Mac Os? > if so, is gcc still supported in Mac? > These are more complicated questions depending on OS X version, however... > The reason for the questions is to know if it is ok to support clang for a open source project > which already supports gcc under Mac Os > this is much easier. Yes, it's quite OK to use clang to compile for OS X. -eric From puurtuur at me.com Wed Jul 6 05:42:14 2011 From: puurtuur at me.com (Arthur Langereis) Date: Wed, 06 Jul 2011 12:42:14 +0200 Subject: [cfe-dev] C++ memory analysis In-Reply-To: References: Message-ID: <84C41F2F-2802-4A84-8799-16E35A424A18@me.com> > On Jul 5, 2011, at 22:33 PM, Chris Lattner wrote: > > We even support the new ARC Objective-C feature in all modes as well, meaning that folks can write code in Objective-ARC++'0x if they so choose. > > -Chris Objarcox, I choose you! Specifically, I'm trying out the analyzer and 0xB features and it was mentioned that all the analyzer notes now work in C++ mode as well and many do, but not memory management issues it seems. Code like: int main(int argc, char *argv[]) { int *x = new int; *x = 5; // suppress dead store / not initialized warnings return 0; } yields no warnings from the analyzer. Same result with member vars, etc, Is this just a bridge too far (for now)? Best, Arthur -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110706/f0cdf900/attachment.html From jfreeman at cse.tamu.edu Wed Jul 6 08:00:31 2011 From: jfreeman at cse.tamu.edu (John Freeman) Date: Wed, 06 Jul 2011 08:00:31 -0500 Subject: [cfe-dev] Lookahead vs. Tentative Parsing In-Reply-To: References: <4E13DCFC.7090808@cse.tamu.edu> Message-ID: <4E145C6F.2010000@cse.tamu.edu> On 7/5/2011 11:22 PM, David Blaikie wrote: > Are you working on this too? Yes. My parsing patch will be ready for review today, and next is AST generation. From clattner at apple.com Wed Jul 6 12:05:50 2011 From: clattner at apple.com (Chris Lattner) Date: Wed, 06 Jul 2011 10:05:50 -0700 Subject: [cfe-dev] C++ memory analysis In-Reply-To: <84C41F2F-2802-4A84-8799-16E35A424A18@me.com> References: <84C41F2F-2802-4A84-8799-16E35A424A18@me.com> Message-ID: <47C57AA8-5087-40A9-A00B-EB8D1B439369@apple.com> On Jul 6, 2011, at 3:42 AM, Arthur Langereis wrote: >> On Jul 5, 2011, at 22:33 PM, Chris Lattner wrote: >> >> We even support the new ARC Objective-C feature in all modes as well, meaning that folks can write code in Objective-ARC++'0x if they so choose. >> >> -Chris > > Objarcox, I choose you! > > Specifically, I'm trying out the analyzer and 0xB features and it was mentioned that all the analyzer notes now work in C++ mode as well and many do, but not memory management issues it seems. > > Code like: > > int main(int argc, char *argv[]) { > int *x = new int; > *x = 5; // suppress dead store / not initialized warnings > return 0; > } > > yields no warnings from the analyzer. Same result with member vars, etc, Is this just a bridge too far (for now)? The static analyzer has its existing checks and they work in [Obj]C++ code now. However, it isn't finding all possible C++ bugs yet :) -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110706/4d4f92fe/attachment.html From vanboxem.ruben at gmail.com Wed Jul 6 12:16:42 2011 From: vanboxem.ruben at gmail.com (Ruben Van Boxem) Date: Wed, 6 Jul 2011 19:16:42 +0200 Subject: [cfe-dev] Clang for MinGW package Message-ID: Hi everyone, Since recently, Clang has been slightly adapted to work with mingw-w64's crt (by me :) ). I have, as promised, built a Clang addon package for the Personal Builds I provide at mingw-w64.sourceforge.net. This project provide headers and libraries for GCC, but of course they also work with Clang. I have included an optional download for the Clang part, and it works out of the box. They are available as native Windows x86 or x86 binaries. If you need support, please send an email to mingw-w64-public at lists.sourceforge.net, mentioning these builds. If the problem lies with Clang (and you're sure) please report it here, then Windows can get some more attention :) I will update these regularly, when I have time or I see a reason to. If something significant was fixed on Clang trunk and you want an update, feel free to ask, I'll see what I can do. Links are here: Source package with build scripts: http://sourceforge.net/projects/mingw-w64/files/Toolchain%20sources/Personal%20Builds/rubenvb/ 32-bit toolchain producing 32-bit binaries: http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb/ 64-bit toolchain producing 64-bit binaries: http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/rubenvb/ (Note the linux toolchains you might see do not include LLVM/Clang, because, well, I forgot and didn't test that combination. They are also 64-bit hosted, so you'll need a 64-bit linux to use them.) Enjoy, Ruben From joel.sherrill at OARcorp.com Wed Jul 6 15:31:28 2011 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Wed, 6 Jul 2011 15:31:28 -0500 Subject: [cfe-dev] *-*-rtems* missing cpp define Message-ID: <4E14C620.8090806@oarcorp.com> Hi, The *-*-rtems* patches are checked in now. Thanks. But there is a minor issue. __rtems__ is not defined. clang -ccc-host-triple i386-rtems4.11 -ccc-gcc-name i386-rtems4.11-gcc -dM -E - References: <4E14C620.8090806@oarcorp.com> Message-ID: On Wed, Jul 6, 2011 at 1:31 PM, Joel Sherrill wrote: > Hi, > > The *-*-rtems* patches are checked in now. > Thanks. ?But there is a minor issue. > __rtems__ is not defined. > > clang -ccc-host-triple i386-rtems4.11 -ccc-gcc-name i386-rtems4.11-gcc > -dM -E - > The code in question is in > tools/clang/lib/Basic/Targets.cpp around line > 1670. ?I have checked it against what other > OSes do and don't see anything obvious. > > Does anyone see what is wrong? Try r134532. -Eli From dgregor at apple.com Wed Jul 6 16:10:19 2011 From: dgregor at apple.com (Douglas Gregor) Date: Wed, 06 Jul 2011 14:10:19 -0700 Subject: [cfe-dev] Lookahead vs. Tentative Parsing In-Reply-To: <4E13DCFC.7090808@cse.tamu.edu> References: <4E13DCFC.7090808@cse.tamu.edu> Message-ID: <547A05A5-605D-4E4D-95D9-8F4FC3F6FDC9@apple.com> On Jul 5, 2011, at 8:56 PM, John Freeman wrote: > Since C++ lambda expressions and Objective-C message expressions can > each start with the same two tokens (l_square followed by identifier), > it can take a lookahead of three tokens to differentiate the two cases. > There are other instances, especially in C++, where further lookahead, > or even semantic analysis, may be required. In the case above, I guess > that lookahead is enough to decide which parsing path to take, but in > general, what are the criteria for deciding to use lookahead vs. > tentative parsing? Lookahead ahead is more efficient than tentative parsing. Typically, do lookahead if possible, to to catch all of the common cases. Then, fall back to tentative parsing if it's a tricky case. > With tentative parsing, are diagnostics suppressed until the parsing has > been committed? No. Make sure that tentative parsing doesn't generate any diagnostics or perform any semantic analysis. - Doug From nickwalters99 at gmail.com Wed Jul 6 16:27:22 2011 From: nickwalters99 at gmail.com (Nick Walters) Date: Wed, 6 Jul 2011 15:27:22 -0600 Subject: [cfe-dev] Adding new keywords to the lexer In-Reply-To: References: Message-ID: Never mind. I figured it out. I had to change the size of Token's Kind field in Token.h to accommodate my added keywords. Nick On Tue, Jul 5, 2011 at 12:53 PM, Nick Walters wrote: > Hello, > > > I am attempting to modify Clang to add a simple language extension which > requires, as a first step, adding a few additional keywords to the lexer. I > have modified: > > > ./include/clang/Basic/TokenKinds.def > > > To add my keywords, e.g: > > > KEYWORD(myfirstkeyword , KEYALL) > > KEYWORD(mysecondkeyword , KEYALL) > > > After recompiling, I try to run clang with this simple C++ program to > verify that clang still works on source files that do not use these > keywords: > > > #include > > > using namespace std; > > > int main(int argc, char** argv){ > > cout << "Hello, Clang!" << endl; > > return 0; > > } > > > $ clang++ hello.cpp > > > And the command fails with the following assertion / stack trace: > > > Assertion failed: (isAnnotation() && "Used AnnotVal on non-annotation > token"), function setAnnotationValue, file > /Users/nickw/llvm/tools/clang/lib/Parse/../../include/clang/Lex/Token.h, > line 209. > > 0 clang 0x0000000101a0f0d0 PrintStackTrace(void*) + 38 > > 1 clang 0x0000000101a0f7bd SignalHandler(int) + 254 > > 2 libSystem.B.dylib 0x00007fff80af51ba _sigtramp + 26 > > 3 clang 0x000000010040704d bool > llvm::isa clang::NamedDecl*>(clang::NamedDecl* const&) + 21 > > 4 clang 0x0000000101a0f00d raise + 27 > > 5 clang 0x0000000101a0f01d abort + 14 > > 6 clang 0x0000000101a0f0aa PrintStackTrace(void*) + 0 > > 7 clang 0x000000010035c3b2 > clang::Token::setAnnotationValue(void*) + 156 > > 8 clang 0x000000010034a46e > clang::Parser::setExprAnnotation(clang::Token&, > clang::ActionResult) + 66 > > 9 clang 0x000000010034521c > clang::Parser::ParseStatementOrDeclaration(clang::ASTOwningVector 32u>&, bool) + 1344 > > 10 clang 0x00000001003488a6 > clang::Parser::ParseCompoundStatementBody(bool) + 932 > > 11 clang 0x0000000100348e2d > clang::Parser::ParseCompoundStatement(clang::ParsedAttributes&, bool) + 131 > > 12 clang 0x000000010034561c > clang::Parser::ParseStatementOrDeclaration(clang::ASTOwningVector 32u>&, bool) + 2368 > > 13 clang 0x000000010034a4b2 clang::Parser::ParseStatement() + > 66 > > 14 clang 0x00000001003473e2 > clang::Parser::ParseIfStatement(clang::ParsedAttributes&) + 626 > > 15 clang 0x00000001003456a1 > clang::Parser::ParseStatementOrDeclaration(clang::ASTOwningVector 32u>&, bool) + 2501 > > 16 clang 0x00000001003488a6 > clang::Parser::ParseCompoundStatementBody(bool) + 932 > > 17 clang 0x0000000100348d27 > clang::Parser::ParseFunctionStatementBody(clang::Decl*, > clang::Parser::ParseScope&) + 211 > > 18 clang 0x00000001003568fd > clang::Parser::ParseFunctionDefinition(clang::Parser::ParsingDeclarator&, > clang::Parser::ParsedTemplateInfo const&) + 2291 > > 19 clang 0x000000010030df99 > clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec&, unsigned int, > bool, clang::SourceLocation*, clang::Parser::ForRangeInit*) + 499 > > 20 clang 0x0000000100353b91 > clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&, > clang::AccessSpecifier) + 959 > > 21 clang 0x0000000100353c09 > clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes&, > clang::AccessSpecifier) + 95 > > 22 clang 0x0000000100354562 > clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, > clang::Parser::ParsingDeclSpec*) + 2364 > > 23 clang 0x0000000100320b9c > clang::Parser::ParseInnerNamespace(std::__debug::vector std::allocator >&, > std::__debug::vector std::allocator >&, > std::__debug::vector std::allocator >&, unsigned int, > clang::SourceLocation&, clang::SourceLocation&, clang::ParsedAttributes&, > clang::SourceLocation&) + 162 > > 24 clang 0x0000000100321866 > clang::Parser::ParseNamespace(unsigned int, clang::SourceLocation&, > clang::SourceLocation) + 2844 > > 25 clang 0x00000001003159ba > clang::Parser::ParseDeclaration(clang::ASTOwningVector&, > unsigned int, clang::SourceLocation&, > clang::Parser::ParsedAttributesWithRange&) + 658 > > 26 clang 0x00000001003541da > clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, > clang::Parser::ParsingDeclSpec*) + 1460 > > 27 clang 0x00000001003548a2 > clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&) + > 256 > > 28 clang 0x0000000100304b30 clang::ParseAST(clang::Sema&, bool) > + 340 > > 29 clang 0x000000010007ec71 > clang::ASTFrontendAction::ExecuteAction() + 233 > > 30 clang 0x00000001002d1977 > clang::CodeGenAction::ExecuteAction() + 793 > > 31 clang 0x000000010007ed7e clang::FrontendAction::Execute() + > 262 > > 32 clang 0x000000010006272e > clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 710 > > 33 clang 0x0000000100010219 > clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 787 > > 34 clang 0x0000000100001cb0 cc1_main(char const**, char > const**, char const*, void*) + 897 > > 35 clang 0x000000010000b852 main + 500 > > 36 clang 0x0000000100001434 start + 52 > > 37 clang 0x0000000000000025 start + 4294962213 > > Stack dump: > > 0. Program arguments: /Users/nickw/llvm-run/bin/clang -cc1 -triple > x86_64-apple-macosx10.6.8 -emit-obj -mrelax-all -disable-free > -main-file-name hello.cpp -pic-level 1 -mdisable-fp-elim -masm-verbose > -munwind-tables -target-cpu core2 -target-linker-version 123.2 -resource-dir > /Users/nickw/llvm-run/bin/../lib/clang/3.0 -fdeprecated-macro -ferror-limit > 19 -fmessage-length 80 -stack-protector 1 -fblocks -fcxx-exceptions > -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o > /var/folders/5m/5m7eYxMpHliIX3JMlBEiH++++TI/-Tmp-/cc-1XdoBa.o -x c++ > hello.cpp > > 1. /usr/include/c++/4.2.1/i686-apple-darwin10/x86_64/bits/c++locale.h:70:2: > current parser token '__sav' > > 2. /usr/include/c++/4.2.1/i686-apple-darwin10/x86_64/bits/c++locale.h:53:1 > : > parsing namespace 'std' > > 3. /usr/include/c++/4.2.1/i686-apple-darwin10/x86_64/bits/c++locale.h:65:3: > parsing function body '__convert_from_v' > > 4. /usr/include/c++/4.2.1/i686-apple-darwin10/x86_64/bits/c++locale.h:65:3: > in compound statement ('{}') > > 5. /usr/include/c++/4.2.1/i686-apple-darwin10/x86_64/bits/c++locale.h:69:7: > in compound statement ('{}') > > clang: error: unable to execute command: Illegal instruction > > clang: error: clang frontend command failed due to signal 2 (use -v to see > invocation) > > > I added some additional debug output, and the token in question at which > this fails is the ?unknown? token. I have grepped around the clang codebase > to find if there is any other areas I have to modify when adding new > keywords and I have tried everything I can think of at this point. I have > tried several variations of modifying TokenKinds.def, and it doesn?t seem to > matter what the keywords I add to TokenKinds.def are ? when I add two new > keywords, it breaks clang?s ability to compile a simple test source like the > above. > > > I greatly appreciate any help / insights on this. Thanks! > > > Nick > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110706/fa118237/attachment-0001.html From vanboxem.ruben at gmail.com Wed Jul 6 16:37:04 2011 From: vanboxem.ruben at gmail.com (Ruben Van Boxem) Date: Wed, 6 Jul 2011 23:37:04 +0200 Subject: [cfe-dev] MinGW problem with GSL Message-ID: Hi, Clang seems to have a problem with some assembler files when building GSL (configured with --host=x86_64-w64-mingw32 CC="clang -v"): > libtool: compile: ?clang -v -DHAVE_CONFIG_H -I. -I/m/Development/Source/gsl-1.15/specfunc -I.. -I/m/Development/Source/gsl-1.15 -g -O2 -MT hyperg_1F1.lo -MD -MP -MF .deps/hyperg_1F1.Tpo -c /m/Development/Source/gsl-1.15/specfunc/hyperg_1F1.c > clang version 3.0 (http://llvm.org/git/clang.git 5cbe101b502e06d16bc77df45a27ce8bc13f33c8) > Target: x86_64-w64-mingw32 > Thread model: posix > "m:/Development/mingw64/bin/clang.exe" -cc1 -triple x86_64-w64-mingw32 -S -disable-free -disable-llvm-verifier -main-file-name hyperg_1F1.c -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.21.1.20110627 -momit-leaf-frame-pointer -v -g -coverage-file C:/Users/Ruben/AppData/Local/Temp/cc-236916.s -resource-dir m:/Development/mingw64/bin\..\lib\clang\3.0 -dependency-file .deps/hyperg_1F1.Tpo -sys-header-deps -MP -MT hyperg_1F1.lo -D HAVE_CONFIG_H -I . -I m:/Development/Source/gsl-1.15/specfunc -I .. -I m:/Development/Source/gsl-1.15 -O2 -ferror-limit 19 -fmessage-length 500 -fno-use-cxa-atexit -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o C:/Users/Ruben/AppData/Local/Temp/cc-236916.s -x c m:/Development/Source/gsl-1.15/specfunc/hyperg_1F1.c > clang -cc1 version 3.0 based upon llvm 3.0svn hosted on x86_64-w64-mingw32 > ignoring nonexistent directory "/usr/local/include" > ignoring nonexistent directory "m:/Development/mingw64/bin/../lib/clang/3.0/../../../i686-w64-mingw32/include" > ignoring nonexistent directory "/mingw/include" > ignoring nonexistent directory "c:/mingw/include" > ignoring nonexistent directory "/usr/include" > #include "..." search starts here: > #include <...> search starts here: > . > m:/Development/Source/gsl-1.15/specfunc > .. > m:/Development/Source/gsl-1.15 > m:/Development/mingw64/bin/../lib/clang/3.0/include > m:/Development/mingw64/bin/../lib/clang/3.0/../../../x86_64-w64-mingw32/include > m:/Development/mingw64/bin/../lib/clang/3.0/../../../include > End of search list. > "m:/Development/mingw64/bin/gcc.exe" -v -D HAVE_CONFIG_H -I . -I m:/Development/Source/gsl-1.15/specfunc -I .. -I m:/Development/Source/gsl-1.15 -O2 -MT hyperg_1F1.lo -MD -MP -MF .deps/hyperg_1F1.Tpo -c -m64 -o hyperg_1F1.o -x assembler C:/Users/Ruben/AppData/Local/Temp/cc-236916.s > Using built-in specs. > COLLECT_GCC=m:/Development/mingw64/bin/gcc.exe > COLLECT_LTO_WRAPPER=m:/development/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.6.2/lto-wrapper.exe > Target: x86_64-w64-mingw32 > Configured with: /home/ruben/mingw-w64/toolchain/src/gcc/configure --host=x86_64-w64-mingw32 --build=x86_64-gnu-linux --target=x86_64-w64-mingw32 --with-sysroot=/home/ruben/mingw-w64/toolchain/mingw64/mingw64 --prefix=/home/ruben/mingw-w64/toolchain/mingw64/mingw64 --with-libiconv-prefix=/home/ruben/mingw-w64/toolchain/mingw64/libs --with-libexpat-prefix=/home/ruben/mingw-w64/toolchain/mingw64/libs --with-gmp=/home/ruben/mingw-w64/toolchain/mingw64/libs --with-mpfr=/home/ruben/mingw-w64/toolchain enable-lto --disable-multilib --disable-win32-registry --disable-rpath --disable-werror CFLAGS='-O2 -mtune=core2 -fomit-frame-pointer -momit-leaf-frame-pointer -fgraphite-identity -floop-interchange -floop-block -floop-parallelize-all' LDFLAGS= > Thread model: win32 > gcc version 4.6.2 20110705 (prerelease) (GCC) > COLLECT_GCC_OPTIONS='-v' '-D' 'HAVE_CONFIG_H' '-I' '.' '-I' 'm:/Development/Source/gsl-1.15/specfunc' '-I' '..' '-I' 'm:/Development/Source/gsl-1.15' '-O2' '-MT' 'hyperg_1F1.lo' '-MD' '-MP' '-MF' '.deps/hyperg_1F1.Tpo' '-c' '-m64' '-o' 'hyperg_1F1.o' '-mtune=generic' '-march=x86-64' > m:/development/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.6.2/../../../../x86_64-w64-mingw32/bin/as.exe --64 -o hyperg_1F1.o C:/Users/Ruben/AppData/Local/Temp/cc-236916.s > C:/Users/Ruben/AppData/Local/Temp/cc-236916.s: Assembler messages: > C:/Users/Ruben/AppData/Local/Temp/cc-236916.s:1198: Error: operand type mismatch for `fld' > C:/Users/Ruben/AppData/Local/Temp/cc-236916.s:2824: Error: operand type mismatch for `fld' > clang: error: assembler (via gcc) command failed with exit code 1 (use -v to see invocation) > make[2]: *** [hyperg_1F1.lo] Error 1 > make[2]: Leaving directory `/home/Ruben/gsl/specfunc' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/Ruben/gsl' > make: *** [all] Error 2 GCC does not have this problem. I can't discern any notable difference in config.log. Could it be something wrt passing options down to the GNU tools? Ruben From echristo at apple.com Wed Jul 6 16:40:23 2011 From: echristo at apple.com (Eric Christopher) Date: Wed, 06 Jul 2011 14:40:23 -0700 Subject: [cfe-dev] MinGW problem with GSL In-Reply-To: References: Message-ID: On Jul 6, 2011, at 2:37 PM, Ruben Van Boxem wrote: > GCC does not have this problem. I can't discern any notable difference > in config.log. Could it be something wrt passing options down to the > GNU tools? Two things: a) try passing -no-integrated-as to see if it's a problem with passing down arguments b) try to get a testcase of the failing instructions Thanks! -eric From vanboxem.ruben at gmail.com Wed Jul 6 17:21:23 2011 From: vanboxem.ruben at gmail.com (Ruben Van Boxem) Date: Thu, 7 Jul 2011 00:21:23 +0200 Subject: [cfe-dev] MinGW problem with GSL In-Reply-To: References: Message-ID: 2011/7/6 Eric Christopher : > > On Jul 6, 2011, at 2:37 PM, Ruben Van Boxem wrote: > >> GCC does not have this problem. I can't discern any notable difference >> in config.log. Could it be something wrt passing options down to the >> GNU tools? > > Two things: > > a) try passing -no-integrated-as to see if it's a problem with passing down arguments Same problem. I have also verified all the commands being run against a matching GCC install. > b) try to get a testcase of the failing instructions Heh, well, yeah. Euhm... My assembly isn't that... good, and that's being optimistic. As in, I know *nothing* about it, except that it exists. So here I go: The bits of assembly causing the problem are these: .Ltmp224: .loc 4 129 5 movsd %xmm6, -616(%rbp) fldl -616(%rbp) fstpt -772(%rbp) fld %ss #APP fabs; #NO_APP fstpl -624(%rbp) movsd .LCPI3_10(%rip), %xmm0 ... .Ltmp521: fstpt -656(%rbp) fld %ss #APP fabs; #NO_APP I can't find these or even similar bits in GCC's output, which probably isn't surprising. The source file this comes from is pretty big, with a lot of GSL specific functionality being used (kind of expected). I do know GCC does not have a "fld" instruction anywhere in its version of the assembler output. Would this have anything to do with the header? This is used when Clang is used, but a mingw-w64 (which provides the header) dev told me it includes ansidecl.h which is a GCC internal header. It defines (among a *lot* of other things) some va_args things, but there's no error when clang parses this file, so it probably is not causing the issue. Plus, the only place where it's being used is GSL's sys/infnan.c (grep -r , which couldn't possibly be included in the file causing the error. I also tried a i686-w64-mingw32 built Clang with matching mingw-w64 CRT and GCC. It hits the same problem. Any tips on what simple testcase couldd produce an fld instruction? GCC doesn't in this case, which only adds to the oddity. Thanks, Ruben From lattner at apple.com Wed Jul 6 19:44:52 2011 From: lattner at apple.com (Tanya Lattner) Date: Wed, 06 Jul 2011 17:44:52 -0700 Subject: [cfe-dev] OpenCL patch: vector literals In-Reply-To: <000001cc371d$e2322c60$a6968520$%Lokhmotov@arm.com> References: <000001cc371d$e2322c60$a6968520$%Lokhmotov@arm.com> Message-ID: <9FDE1029-AFCA-4021-B1A1-9BC9E1952B27@apple.com> Anton, I do not this is all necessary. All the support already exists for all the valid test cases except the last one ((float4)( float )). One just has to modify ActOnCastOfParenListExpr which is now BuildVectorLiteral to handle the splat case. I have not modified our patch to match the recent changes in TOT, but will do shortly. For the invalid cases, I don't see why one needs to modify the parser, but the last invalid case does crash the compiler which shouldn't ever happen. Also, I'd really appreciate if you didn't just remove regression tests. Yes, you are 100% right that the test violates the OpenCL spec (my mistake and haste in making a patch), but its catching a nasty compiler crash and I'd rather try to modify the test instead of just removing it. I've fixed this in TOT. Lastly, please make sure any unrelated code is not included (ie. lib/Frontend/CompilerInvocation.cpp changes). Thanks, Tanya On Jun 30, 2011, at 5:04 AM, Anton Lokhmotov wrote: > Please find attached the patch providing support for vector literals in > OpenCL. > > Two files with test cases are provided: > CodeGenOpenCL/vector_literals_valid.cl and > SemaOpenCL/vector_literals_invalid.cl. One file is removed: > CodeGenOpenCL/2011-04-15-vec-init-from-vec.cl, because it contained invalid > OpenCL code (cast between vectors of different types: int2 and uchar8). > > Please review! > > Many thanks, > Anton. > > P.S. The quote below is on page 164 in opencl-1.1-rev44 > (http://www.khronos.org/registry/cl/specs/opencl-1.1.pdf). > >> Date: Wed, 1 Jun 2011 11:13:10 +0200 >> From: Alberto Magni >> Subject: Re: [cfe-dev] OpenCL vector initialization >> To: Anton.Lokhmotov at arm.com >> Cc: cfe-dev at cs.uiuc.edu >> Message-ID: >> Content-Type: text/plain; charset=ISO-8859-1 >> >> Ok, thank you Anton. >> >> I'll wait for your patch. >> >> Bye >> >> 2011/6/1 Anton Lokhmotov : >>> Hi Alberto, >>> >>> Thanks for working on OpenCL support in Clang. It's an important >>> area we should aim to enable for the 3.0 release. >>> >>> The OpenCL requirement for vector literals is actually quite >>> involved. To quote from a recent revision of the spec >>> (to which you don't have access yet): >>> >>> "A vector literal is written as a parenthesized vector type followed >>> by a parenthesized comma delimited list of parameters. A vector >>> literal operates as an overloaded function. The forms of the function >>> that are available is the set of possible argument lists for which all >>> arguments have the same element type as the result vector, and the >>> total number of elements is equal to the number of elements in the >>> result vector. In addition, a form with a single scalar of the same >>> type as the element type of the vector is available." >>> >>> "For example, the following forms are available for float4: >>> (float4)( float, float, float, float ) >>> (float4)( float2, float, float ) >>> (float4)( float, float2, float ) >>> (float4)( float, float, float2 ) >>> (float4)( float2, float2 ) >>> (float4)( float3, float ) >>> (float4)( float, float3 ) >>> (float4)( float )" >>> >>> As I understand, your patch handles only the last case. We are going >>> to submit a patch shortly to accept valid cases and reject invalid >>> >>> Thanks, >>> Anton. > _______________________________________________ > 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/20110706/ffb1c662/attachment.html From akyrtzi at gmail.com Thu Jul 7 01:51:21 2011 From: akyrtzi at gmail.com (Argyrios Kyrtzidis) Date: Wed, 6 Jul 2011 23:51:21 -0700 Subject: [cfe-dev] Lookahead vs. Tentative Parsing In-Reply-To: <547A05A5-605D-4E4D-95D9-8F4FC3F6FDC9@apple.com> References: <4E13DCFC.7090808@cse.tamu.edu> <547A05A5-605D-4E4D-95D9-8F4FC3F6FDC9@apple.com> Message-ID: On Jul 6, 2011, at 2:10 PM, Douglas Gregor wrote: > > On Jul 5, 2011, at 8:56 PM, John Freeman wrote: > >> Since C++ lambda expressions and Objective-C message expressions can >> each start with the same two tokens (l_square followed by identifier), >> it can take a lookahead of three tokens to differentiate the two cases. >> There are other instances, especially in C++, where further lookahead, >> or even semantic analysis, may be required. In the case above, I guess >> that lookahead is enough to decide which parsing path to take, but in >> general, what are the criteria for deciding to use lookahead vs. >> tentative parsing? > > Lookahead ahead is more efficient than tentative parsing. Actually there's not much difference in efficiency, they use the same preprocessor cache. The important thing is how many tokens you are going ahead, it doesn't matter what way you are using to get the tokens. -Argiris > Typically, do lookahead if possible, to to catch all of the common cases. Then, fall back to tentative parsing if it's a tricky case. > >> With tentative parsing, are diagnostics suppressed until the parsing has >> been committed? > > No. Make sure that tentative parsing doesn't generate any diagnostics or perform any semantic analysis. > > - Doug > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From Olaf.Krzikalla at tu-dresden.de Thu Jul 7 06:18:49 2011 From: Olaf.Krzikalla at tu-dresden.de (Olaf Krzikalla) Date: Thu, 07 Jul 2011 13:18:49 +0200 Subject: [cfe-dev] Back to work: attributes Message-ID: <4E159619.8050303@tu-dresden.de> Hi @clang, it's been a while that we discussed the implementation of attributes. Since Sean didn't chime I guess he doesn't work on attributes anymore. Now hopefully I've found the week I've planned to need to get that stuff on the right track. But before I start there are a lot of questions and issues to clarify. 1. How resilient ought to be the PCH serialization? Suppose a user-defined attribute that is supported by a particular plugin. The interesting cases are when the plugin is loaded only either during PCH generation or usage. Currently attributes are serialized by their actual semantic properties. But a more resilient implementation would just store a (simplified) token stream and regenerate the attributes from that stream during PCH loading. This approach has the additional benefit that user-defined attributes don't need to define serialization functions. 2. What is the point of InheritableAttr? The Inherited property is already in Attr, we could also stream it for every attr (e.g. by bit-masking it with Attr::Kind). On the other hand it seems to be used only with DLLImportAttr, so actually we could also remove InheritableAttr altogether (and move the property to DLLImportAttr). 3. Just btw: If I haven't overlooked something, then openmp pragmas are still a TODO. It would be interesting to see them working in clang because in the end they have to solve the same problem that I actually have (and that is the root for my efforts on attributes): parse an expression inside a pragma. What are the plans regarding openmp? OK, the rest seems rather clear to me. The current implementation is quite incomplete and I guess I have to put some work in ClangAttrEmitter too in order to get proper parsing and semantic checking generated by tblgen. Best regards Olaf Krzikalla From raptorfactor at raptorfactor.com Thu Jul 7 08:11:43 2011 From: raptorfactor at raptorfactor.com (Joshua Boyce) Date: Thu, 7 Jul 2011 23:11:43 +1000 Subject: [cfe-dev] Clang for MinGW package In-Reply-To: References: Message-ID: Thanks so much for providing these packages! One small issue though. The following DLLs are missing from the package: libgcc_s_sjlj-1.dll libstdc++-6.dll Other than that though it seems to be working. (I copied the above files from the MinGW-w64 GCC libexec folder.) Can't wait till the STL, Boost, etc is working... ;) On Thu, Jul 7, 2011 at 3:16 AM, Ruben Van Boxem wrote: > Hi everyone, > > Since recently, Clang has been slightly adapted to work with > mingw-w64's crt (by me :) ). I have, as promised, built a Clang addon > package for the Personal Builds I provide at > mingw-w64.sourceforge.net. This project provide headers and libraries > for GCC, but of course they also work with Clang. I have included an > optional download for the Clang part, and it works out of the box. > They are available as native Windows x86 or x86 binaries. > > If you need support, please send an email to > mingw-w64-public at lists.sourceforge.net, mentioning these builds. If > the problem lies with Clang (and you're sure) please report it here, > then Windows can get some more attention :) I will update these > regularly, when I have time or I see a reason to. If something > significant was fixed on Clang trunk and you want an update, feel free > to ask, I'll see what I can do. > > Links are here: > Source package with build scripts: > > http://sourceforge.net/projects/mingw-w64/files/Toolchain%20sources/Personal%20Builds/rubenvb/ > 32-bit toolchain producing 32-bit binaries: > > http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb/ > 64-bit toolchain producing 64-bit binaries: > > http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/rubenvb/ > > (Note the linux toolchains you might see do not include LLVM/Clang, > because, well, I forgot and didn't test that combination. They are > also 64-bit hosted, so you'll need a 64-bit linux to use them.) > > Enjoy, > > Ruben > _______________________________________________ > 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/20110707/497383e0/attachment.html From howarth at bromo.med.uc.edu Thu Jul 7 08:14:29 2011 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Thu, 7 Jul 2011 09:14:29 -0400 Subject: [cfe-dev] clang vs LIBRARY_PATH Message-ID: <20110707131429.GA22460@bromo.med.uc.edu> While clang seems to honor CPATH, it doesn't seem to do the same for LIBRARY_PATH. For example, when building guile 1.8.8 under fink, in order to insure that guile links against the newly built copy, we don't pass -L/sw/lib to LDFLAGS or -I/sw/include to CPPFLAGS. Instead fink has been using... setenv CPATH /sw/include setenv LIBRARY_PATH /sw/lib which compiles the conftest for __gmpz_init in -lgmp fine under gcc or llvm-gcc in configure... [MacPro:guile18-1.8.8-3/guile-1.8.8/build] root# gcc -o conftest -g -O2 -Dmacosx conftest.c -lgmp -lm -lltdl however clang doesn't find libgmp via LIBRARY_PATH... [MacPro:guile18-1.8.8-3/guile-1.8.8/build] root# clang -o conftest -g -O2 -Dmacosx conftest.c -lgmp -lm -lltdl ld: library not found for -lgmp clang: error: linker command failed with exit code 1 (use -v to see invocation) Is this expected behavior for clang or should I open a PR? Jack From vanboxem.ruben at gmail.com Thu Jul 7 08:18:23 2011 From: vanboxem.ruben at gmail.com (Ruben Van Boxem) Date: Thu, 7 Jul 2011 15:18:23 +0200 Subject: [cfe-dev] Clang for MinGW package In-Reply-To: References: Message-ID: 2011/7/7 Joshua Boyce : > Thanks so much for providing these packages! You're welcome! > One small issue though.?The following DLLs are missing from the package: > libgcc_s_sjlj-1.dll > libstdc++-6.dll > Other than that though it seems to be working. (I copied the above files > from the MinGW-w64 GCC libexec folder.) > Can't wait till the STL, Boost, etc is working... ;) No, I'm quite sure they're present in the packages. I just redownloaded http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/rubenvb/4.6.2/x86_64-w64-mingw32-gcc-4.6.2_rubenvb.7z and it's in the mingw64/bin directory. Must be something with your download/unzipping gone wrong. Be sure to use 9.20 or later. Ruben From joel.sherrill at OARcorp.com Thu Jul 7 09:49:40 2011 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Thu, 7 Jul 2011 09:49:40 -0500 Subject: [cfe-dev] cpp difference between gcc and clang? Message-ID: <4E15C784.2010107@oarcorp.com> Hi, RTEMS uses preprocessed assembly files (.S). I have a small test case which compiles with i386 gcc and not with clang from the svn head. ======================== #define __USER_LABEL_PREFIX__ #define EXPAND0(x) x #define CONCAT0(a,b) EXPAND0(a)EXPAND0(b) #define SYM(x) CONCAT0 (__USER_LABEL_PREFIX__, x) .text .set RUNCONTEXT_ARG, 4 /* save context argument */ .set HEIRCONTEXT_ARG, 8 /* restore context argument */ SYM(_label): nop ======================== $ clang -c set_asm.S /tmp/cc-Y6Q2YB.s:14:24: error: unexpected token in assignment .set HEIRCONTEXT_ARG, 8_label: This is a cut down and if I simplify it much more, it works. -- Joel Sherrill, Ph.D. Director of Research& Development joel.sherrill at OARcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985 From Anton.Lokhmotov at arm.com Thu Jul 7 10:17:48 2011 From: Anton.Lokhmotov at arm.com (Anton Lokhmotov) Date: Thu, 7 Jul 2011 16:17:48 +0100 Subject: [cfe-dev] OpenCL patch: vector literals In-Reply-To: <9FDE1029-AFCA-4021-B1A1-9BC9E1952B27@apple.com> References: <000001cc371d$e2322c60$a6968520$%Lokhmotov@arm.com> <9FDE1029-AFCA-4021-B1A1-9BC9E1952B27@apple.com> Message-ID: <000001cc3cb9$07cc7d40$176577c0$@Lokhmotov@arm.com> Hi Tanya, Many thanks for your prompt review! > All the support already exists for all the valid test cases > except the last one ((float4)( float )). One just has to modify > ActOnCastOfParenListExpr which is now BuildVectorLiteral to handle > the splat case. I have not modified our patch to match the recent > changes in TOT, but will do shortly. We would be happy with minimal changes to Clang provided that the OpenCL requirements are properly met, including handling invalid code. We specifically avoided using/modifying/breaking the existing functionality for AltiVec because the OpenCL syntax is quite different. Thus, we believe that for OpenCL CompilerInvocation::setLangDefaults() should disable Opts.AltiVec (and OTOH enable Opts.Bool - but sorry about that slipping into this patch). > Yes, you are 100% right that the test violates the OpenCL spec > (my mistake and haste in making a patch), but its catching a nasty > compiler crash and I'd rather try to modify the test instead of just > removing it. I've fixed this in TOT. Unfortunately, void foo( uchar8 x ) { uchar4 val[4] = {{(uchar4){x.lo}}}; } is still invalid in OpenCL C. In particular, OpenCL doesn't allow using braces {} in vector literals. [Actually, I'm quite confused by this test. Since x.lo produces uchar4, the cast is superfluous? And then it attempts to initialize an array of vectors val[] from vector x.lo. But I actually would expect only val[0] to be initialized (backed by my experiments with gcc). But if it's just ensuring that the compiler doesn't crash, that's fine (in the AltiVec mode).] > For the invalid cases, I don't see why one needs to modify the parser, > but the last invalid case does crash the compiler which shouldn't ever > happen. Could you please ensure that the patch is applied correctly? It works fine with r134483. Specifically, this modification prevents the compiler from crashing: [11:17:50] Vitaly Lugovskiy: diff --git a/lib/Sema/SemaInit.cpp b/lib/Sema/SemaInit.cpp index 16ba2a2..17af145 100644 --- a/lib/Sema/SemaInit.cpp +++ b/lib/Sema/SemaInit.cpp @@ -769,7 +769,8 @@ void InitListChecker::CheckSubElementType(const InitializedEntity &Entity, // subaggregate, brace elision is assumed and the initializer is // considered for the initialization of the first member of // the subaggregate. - if (ElemType->isAggregateType() || ElemType->isVectorType()) { + if (!SemaRef.getLangOptions().OpenCL && + (ElemType->isAggregateType() || ElemType->isVectorType())) { CheckImplicitInitList(Entity, IList, ElemType, Index, StructuredList, StructuredIndex); ++StructuredIndex; If you provide your modifications to support vector literals, we will run our test cases with combinatorial coverage to ensure that the OpenCL requirements are met. Best wishes, Anton. From joel.sherrill at OARcorp.com Thu Jul 7 10:46:04 2011 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Thu, 7 Jul 2011 10:46:04 -0500 Subject: [cfe-dev] Unknown pragma warning in newlib Message-ID: <4E15D4BC.8010709@oarcorp.com> Hi, Pushing more on *-*-rtems*, I came across a pragma in newlib that apparently gcc knows that clang does not. $ cat j.c char * mktemp (char *) __attribute__ ((__warning__ ("the use of `mktemp' is dangerous; use `mkstemp' instead"))); $ gcc -c -Wall j.c $ clang -c j.c j.c:1:40: warning: unknown attribute '__warning__' ignored [-Wattributes] char * mktemp (char *) __attribute__ ((__warning__ ("the use of ... ^ 1 warning generated. Thanks. -- Joel Sherrill, Ph.D. Director of Research& Development joel.sherrill at OARcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985 From joel.sherrill at OARcorp.com Thu Jul 7 10:57:16 2011 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Thu, 7 Jul 2011 10:57:16 -0500 Subject: [cfe-dev] FP register unknown to clang in inline asm Message-ID: <4E15D75C.4060901@oarcorp.com> Hi, Yet another couple of cases from the *-*-rtems* work. These are both from inline assembly on our floating point context code when SSE is enabled. $ gcc -c j1.c $ clang -c j1.c clang doesn't appear to know a couple of fp register names that gcc does. -- Joel Sherrill, Ph.D. Director of Research& Development joel.sherrill at OARcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985 -------------- next part -------------- A non-text attachment was scrubbed... Name: j1.c Type: text/x-csrc Size: 579 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110707/718da3fc/attachment-0002.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: j2.c Type: text/x-csrc Size: 701 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110707/718da3fc/attachment-0003.bin From akyrtzi at gmail.com Thu Jul 7 11:06:54 2011 From: akyrtzi at gmail.com (Argyrios Kyrtzidis) Date: Thu, 7 Jul 2011 09:06:54 -0700 Subject: [cfe-dev] cpp difference between gcc and clang? In-Reply-To: <4E15C784.2010107@oarcorp.com> References: <4E15C784.2010107@oarcorp.com> Message-ID: Please file a bug report. -Argiris On Jul 7, 2011, at 7:49 AM, Joel Sherrill wrote: > Hi, > > RTEMS uses preprocessed assembly files (.S). > I have a small test case which compiles > with i386 gcc and not with clang from the svn > head. > > ======================== > #define __USER_LABEL_PREFIX__ > #define EXPAND0(x) x > #define CONCAT0(a,b) EXPAND0(a)EXPAND0(b) > > #define SYM(x) CONCAT0 (__USER_LABEL_PREFIX__, x) > > .text > > .set RUNCONTEXT_ARG, 4 /* save context argument */ > .set HEIRCONTEXT_ARG, 8 /* restore context argument */ > > SYM(_label): > nop > ======================== > > $ clang -c set_asm.S > /tmp/cc-Y6Q2YB.s:14:24: error: unexpected token in assignment > .set HEIRCONTEXT_ARG, 8_label: > > This is a cut down and if I simplify it much more, > it works. > > -- > Joel Sherrill, Ph.D. Director of Research& Development > joel.sherrill at OARcorp.com On-Line Applications Research > Ask me about RTEMS: a free RTOS Huntsville AL 35805 > Support Available (256) 722-9985 > > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From joel.sherrill at OARcorp.com Thu Jul 7 11:18:19 2011 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Thu, 7 Jul 2011 11:18:19 -0500 Subject: [cfe-dev] cpp difference between gcc and clang? In-Reply-To: References: <4E15C784.2010107@oarcorp.com> Message-ID: <4E15DC4B.2040105@oarcorp.com> On 07/07/2011 11:06 AM, Argyrios Kyrtzidis wrote: > Please file a bug report. > Done. http://llvm.org/bugs/show_bug.cgi?id=10298 Thanks. --joel > -Argiris > > On Jul 7, 2011, at 7:49 AM, Joel Sherrill wrote: > >> Hi, >> >> RTEMS uses preprocessed assembly files (.S). >> I have a small test case which compiles >> with i386 gcc and not with clang from the svn >> head. >> >> ======================== >> #define __USER_LABEL_PREFIX__ >> #define EXPAND0(x) x >> #define CONCAT0(a,b) EXPAND0(a)EXPAND0(b) >> >> #define SYM(x) CONCAT0 (__USER_LABEL_PREFIX__, x) >> >> .text >> >> .set RUNCONTEXT_ARG, 4 /* save context argument */ >> .set HEIRCONTEXT_ARG, 8 /* restore context argument */ >> >> SYM(_label): >> nop >> ======================== >> >> $ clang -c set_asm.S >> /tmp/cc-Y6Q2YB.s:14:24: error: unexpected token in assignment >> .set HEIRCONTEXT_ARG, 8_label: >> >> This is a cut down and if I simplify it much more, >> it works. >> >> -- >> Joel Sherrill, Ph.D. Director of Research& Development >> joel.sherrill at OARcorp.com On-Line Applications Research >> Ask me about RTEMS: a free RTOS Huntsville AL 35805 >> Support Available (256) 722-9985 >> >> >> _______________________________________________ >> cfe-dev mailing list >> cfe-dev at cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev -- Joel Sherrill, Ph.D. Director of Research& Development joel.sherrill at OARcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985 From clattner at apple.com Thu Jul 7 11:39:57 2011 From: clattner at apple.com (Chris Lattner) Date: Thu, 07 Jul 2011 09:39:57 -0700 Subject: [cfe-dev] Unknown pragma warning in newlib In-Reply-To: <4E15D4BC.8010709@oarcorp.com> References: <4E15D4BC.8010709@oarcorp.com> Message-ID: On Jul 7, 2011, at 8:46 AM, Joel Sherrill wrote: > Hi, > > Pushing more on *-*-rtems*, I came across > a pragma in newlib that apparently gcc > knows that clang does not. > > $ cat j.c > char * mktemp (char *) __attribute__ ((__warning__ ("the use of `mktemp' > is dangerous; use `mkstemp' instead"))); Hi Joel, Please file a bugzilla @ http://llvm.org/bugs/ to track this feature request. Better yet, send in a patch :). It would be very straight-forward to accept and ignore this attribute. -Chris From echristo at apple.com Thu Jul 7 12:06:36 2011 From: echristo at apple.com (Eric Christopher) Date: Thu, 07 Jul 2011 10:06:36 -0700 Subject: [cfe-dev] MinGW problem with GSL In-Reply-To: References: Message-ID: <5BE2F5F9-7FE7-42C8-BA28-6A46EEA81ADF@apple.com> >> >> >> a) try passing -no-integrated-as to see if it's a problem with passing down arguments > > Same problem. I have also verified all the commands being run against > a matching GCC install. Good to know. > >> b) try to get a testcase of the failing instructions > > Heh, well, yeah. Euhm... My assembly isn't that... good, and that's > being optimistic. As in, I know *nothing* about it, except that it > exists. So here I go: > > The bits of assembly causing the problem are these: > > .Ltmp224: > .loc 4 129 5 > movsd %xmm6, -616(%rbp) > fldl -616(%rbp) > fstpt -772(%rbp) > fld %ss > #APP > fabs; > #NO_APP > fstpl -624(%rbp) > movsd .LCPI3_10(%rip), %xmm0 > ... > .Ltmp521: > fstpt -656(%rbp) > fld %ss > #APP > fabs; > #NO_APP > > I can't find these or even similar bits in GCC's output, which > probably isn't surprising. > > The source file this comes from is pretty big, with a lot of GSL > specific functionality being used (kind of expected). I do know GCC > does not have a "fld" instruction anywhere in its version of the > assembler output. > > Would this have anything to do with the header? This is > used when Clang is used, but a mingw-w64 (which provides the header) > dev told me it includes ansidecl.h which is a GCC internal header. It > defines (among a *lot* of other things) some va_args things, but > there's no error when clang parses this file, so it probably is not > causing the issue. Plus, the only place where it's being used is GSL's > sys/infnan.c (grep -r , which couldn't possibly be included in the > file causing the error. > > I also tried a i686-w64-mingw32 built Clang with matching mingw-w64 > CRT and GCC. It hits the same problem. > > Any tips on what simple testcase couldd produce an fld instruction? > GCC doesn't in this case, which only adds to the oddity. Not sure that's really important at the moment, it might be nice to get you to file a bug report with a preprocessed source file testcase and the command line that'll get this to show. Thanks! -eric From theraven at sucs.org Thu Jul 7 12:20:55 2011 From: theraven at sucs.org (David Chisnall) Date: Thu, 7 Jul 2011 18:20:55 +0100 Subject: [cfe-dev] Unknown pragma warning in newlib In-Reply-To: References: <4E15D4BC.8010709@oarcorp.com> Message-ID: <0A08B5B3-D25B-4D2E-8B31-96B8493E7C0B@sucs.org> On 7 Jul 2011, at 17:39, Chris Lattner wrote: > Better yet, send in a patch :). It would be very straight-forward to accept and ignore this attribute. The semantics seem to be almost identical to the deprecated attribute, so it should be fairly trivial to implement it properly. David -- Sent from my Difference Engine From echristo at apple.com Thu Jul 7 12:21:42 2011 From: echristo at apple.com (Eric Christopher) Date: Thu, 07 Jul 2011 10:21:42 -0700 Subject: [cfe-dev] FP register unknown to clang in inline asm In-Reply-To: <4E15D75C.4060901@oarcorp.com> References: <4E15D75C.4060901@oarcorp.com> Message-ID: <809A1774-C5F4-4D61-96F7-27FE28F5E2E1@apple.com> On Jul 7, 2011, at 8:57 AM, Joel Sherrill wrote: > Hi, > > Yet another couple of cases from the > *-*-rtems* work. These are both > from inline assembly on our floating > point context code when SSE is enabled. > > $ gcc -c j1.c > $ clang -c j1.c > > clang doesn't appear to know a couple > of fp register names that gcc does. Excellent, thanks for the testcases. Mind filing a couple of bugs? -eric From joel.sherrill at OARcorp.com Thu Jul 7 12:37:55 2011 From: joel.sherrill at OARcorp.com (Joel Sherrill) Date: Thu, 7 Jul 2011 12:37:55 -0500 Subject: [cfe-dev] FP register unknown to clang in inline asm In-Reply-To: <809A1774-C5F4-4D61-96F7-27FE28F5E2E1@apple.com> References: <4E15D75C.4060901@oarcorp.com> <809A1774-C5F4-4D61-96F7-27FE28F5E2E1@apple.com> Message-ID: <4E15EEF3.7060504@oarcorp.com> On 07/07/2011 12:21 PM, Eric Christopher wrote: > On Jul 7, 2011, at 8:57 AM, Joel Sherrill wrote: > >> Hi, >> >> Yet another couple of cases from the >> *-*-rtems* work. These are both >> from inline assembly on our floating >> point context code when SSE is enabled. >> >> $ gcc -c j1.c >> $ clang -c j1.c >> >> clang doesn't appear to know a couple >> of fp register names that gcc does. > Excellent, thanks for the testcases. Mind filing a couple > of bugs? > http://llvm.org/bugs/show_bug.cgi?id=10299 for this one. http://llvm.org/bugs/show_bug.cgi?id=10300 for the warning pragma. We have a couple of clang things to work through on our side. I would appreciate a pointer on one of them. We need to start adding to the standard include path. The first directory is: ${prefix}/${target}/include which for an install from our RPMs results in this for i386 and rtems4.11 /opt/rtems-4.11/i386-rtems4.11/include Any pointers on constructing that path and where to place the code so it can be one once for all RTEMS targets would be appreciated. NOTE: One great thing about RTEMS is that we are very consistent in how things are done across targets. Differences cause us pain with 15 target architectures. So once I battle through the i386, other targets should be nearly complete. :) > -eric -- Joel Sherrill, Ph.D. Director of Research& Development joel.sherrill at OARcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985 From lattner at apple.com Thu Jul 7 13:05:14 2011 From: lattner at apple.com (Tanya Lattner) Date: Thu, 07 Jul 2011 11:05:14 -0700 Subject: [cfe-dev] OpenCL patch: vector literals In-Reply-To: <000001cc3cb9$07cc7d40$176577c0$%Lokhmotov@arm.com> References: <000001cc371d$e2322c60$a6968520$%Lokhmotov@arm.com> <9FDE1029-AFCA-4021-B1A1-9BC9E1952B27@apple.com> <000001cc3cb9$07cc7d40$176577c0$%Lokhmotov@arm.com> Message-ID: <37138B08-9F02-4071-A09C-A12DC149649C@apple.com> On Jul 7, 2011, at 8:17 AM, Anton Lokhmotov wrote: > Hi Tanya, > > Many thanks for your prompt review! > >> All the support already exists for all the valid test cases >> except the last one ((float4)( float )). One just has to modify >> ActOnCastOfParenListExpr which is now BuildVectorLiteral to handle >> the splat case. I have not modified our patch to match the recent >> changes in TOT, but will do shortly. > > We would be happy with minimal changes to Clang provided that the OpenCL > requirements are properly met, including handling invalid code. We > specifically avoided using/modifying/breaking the existing functionality for > AltiVec because the OpenCL syntax is quite different. Thus, we believe that > for OpenCL CompilerInvocation::setLangDefaults() should disable Opts.AltiVec > (and OTOH enable Opts.Bool - but sorry about that slipping into this patch). > I actually agree that OpenCL should not reply on the Altivec flag and its something we have disabled in our implementation. There aren't too many places where this is a problem thankfully. >> Yes, you are 100% right that the test violates the OpenCL spec >> (my mistake and haste in making a patch), but its catching a nasty >> compiler crash and I'd rather try to modify the test instead of just >> removing it. I've fixed this in TOT. > > Unfortunately, > > void foo( uchar8 x ) > { > uchar4 val[4] = {{(uchar4){x.lo}}}; > } > > is still invalid in OpenCL C. In particular, OpenCL doesn't allow using > braces {} in vector literals. > Well, its an array of uchar4's. So its using {} to initialize the array. Can you point me to where in the spec it says I can't do this? I'm not familiar with this rule. > [Actually, I'm quite confused by this test. Since x.lo produces uchar4, the > cast is superfluous? And then it attempts to initialize an array of vectors > val[] from vector x.lo. But I actually would expect only val[0] to be > initialized (backed by my experiments with gcc). But if it's just ensuring > that the compiler doesn't crash, that's fine (in the AltiVec mode).] > The test is funky I agree, but it should be valid syntax. It came from another larger CL example, which I unfortunately don't have anymore. >> For the invalid cases, I don't see why one needs to modify the parser, >> but the last invalid case does crash the compiler which shouldn't ever >> happen. > > Could you please ensure that the patch is applied correctly? It works fine > with r134483. Specifically, this modification prevents the compiler from > crashing: > I was just saying that without your changes, and simply modifying BuildVectorLiteral to handle the splat case, there would be a crash on one of the invalid cases. I'll try your change below. > [11:17:50] Vitaly Lugovskiy: diff --git a/lib/Sema/SemaInit.cpp > b/lib/Sema/SemaInit.cpp > index 16ba2a2..17af145 100644 > --- a/lib/Sema/SemaInit.cpp > +++ b/lib/Sema/SemaInit.cpp > @@ -769,7 +769,8 @@ void InitListChecker::CheckSubElementType(const > InitializedEntity &Entity, > // subaggregate, brace elision is assumed and the initializer is > // considered for the initialization of the first member of > // the subaggregate. > - if (ElemType->isAggregateType() || ElemType->isVectorType()) { > + if (!SemaRef.getLangOptions().OpenCL && > + (ElemType->isAggregateType() || ElemType->isVectorType())) { > CheckImplicitInitList(Entity, IList, ElemType, Index, StructuredList, > StructuredIndex); > ++StructuredIndex; > > If you provide your modifications to support vector literals, we will run > our test cases with combinatorial coverage to ensure that the OpenCL > requirements are met. > Alright. If you have additional test cases, please send me a patch with them for the tree. I think its great to have more test cases in TOT. -Tanya From jfreeman at cse.tamu.edu Thu Jul 7 13:35:46 2011 From: jfreeman at cse.tamu.edu (John Freeman) Date: Thu, 07 Jul 2011 13:35:46 -0500 Subject: [cfe-dev] [cfe-commits] [PATCH] Parsing C++0x lambda expressions In-Reply-To: <136B65C1-41E5-4989-A47E-E1D1D9FE0D3C@apple.com> References: <4E149900.9000001@cse.tamu.edu> <136B65C1-41E5-4989-A47E-E1D1D9FE0D3C@apple.com> Message-ID: <4E15FC82.9070209@cse.tamu.edu> On 7/6/2011 2:59 PM, Douglas Gregor wrote: > + // Parse lambda-declarator[opt]. > + // FIXME: Should we default the type quals, or store mutability in this? > + DeclSpec DS(AttrFactory); > > Parse as it's written, and let Sema/AST deal with the mutability. > > + // Parse 'mutable'[opt]. > + if (Tok.is(tok::kw_mutable)) { > + // FIXME: How should we add this to the declarator? Should we instead > + // add const-ness if we do not see 'mutable'? > + ConsumeToken(); > + } > > Just extend the Declarator class with a location for the lambda 'mutable' and Sema will deal with it. What is the best place to keep the lambda 'mutable' location? Declarator, or perhaps DeclSpec, or DeclaratorChunk::FunctionTypeInfo (my best guess)? Also, there is an EllipsisLoc in Declarator. I don't see any code using it in either DeclSpec.h or DeclSpec.cpp. Is it used? - John From rjmccall at apple.com Thu Jul 7 13:36:15 2011 From: rjmccall at apple.com (John McCall) Date: Thu, 07 Jul 2011 11:36:15 -0700 Subject: [cfe-dev] OpenCL patch: vector literals In-Reply-To: <37138B08-9F02-4071-A09C-A12DC149649C@apple.com> References: <000001cc371d$e2322c60$a6968520$%Lokhmotov@arm.com> <9FDE1029-AFCA-4021-B1A1-9BC9E1952B27@apple.com> <000001cc3cb9$07cc7d40$176577c0$%Lokhmotov@arm.com> <37138B08-9F02-4071-A09C-A12DC149649C@apple.com> Message-ID: <0BF47EED-5F49-42A8-9BF0-79A5CAEB3012@apple.com> On Jul 7, 2011, at 11:05 AM, Tanya Lattner wrote: > On Jul 7, 2011, at 8:17 AM, Anton Lokhmotov wrote: >>> Yes, you are 100% right that the test violates the OpenCL spec >>> (my mistake and haste in making a patch), but its catching a nasty >>> compiler crash and I'd rather try to modify the test instead of just >>> removing it. I've fixed this in TOT. >> >> Unfortunately, >> >> void foo( uchar8 x ) >> { >> uchar4 val[4] = {{(uchar4){x.lo}}}; >> } >> >> is still invalid in OpenCL C. In particular, OpenCL doesn't allow using >> braces {} in vector literals. >> > > Well, its an array of uchar4's. So its using {} to initialize the array. Can you point me to where in the spec it says I can't do this? > I'm not familiar with this rule. I don't know what the base language for OpenCL is supposed to be, but this is C99 compound literal syntax, and: [C99 6.5.2.5] All the semantic rules and constraints for initializer lists in 6.7.8 are applicable to compound literals. So this should be legal if C99 is an acceptable base language for OpenCL and the following is valid: uchar4 vec = { x.lo }; >> [Actually, I'm quite confused by this test. Since x.lo produces uchar4, the >> cast is superfluous? And then it attempts to initialize an array of vectors >> val[] from vector x.lo. But I actually would expect only val[0] to be >> initialized (backed by my experiments with gcc). When an aggregate has any initializer at all, missing elements are implicitly zero-initialized. John. From howarth at bromo.med.uc.edu Thu Jul 7 13:46:02 2011 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Thu, 7 Jul 2011 14:46:02 -0400 Subject: [cfe-dev] clang vs LIBRARY_PATH Message-ID: <20110707184602.GA24799@bromo.med.uc.edu> After I opened PR10296 for LIBRARY_PATH not being honored and PR10297 for CPATH not being honored, I noticed http://llvm.org/bugs/show_bug.cgi?id=8971 with the proposed solutions in http://llvm.org/bugs/show_bug.cgi?id=8971#c2. Is there a reason why the fourth option... 4. Leave the environment variable inclusion in the Frontend, and just replace the FIXME at CompilerInvocation.cpp:1330 with the following: Opts.EnvIncPath = ::getenv("CPATH"); Opts.CEnvIncPath = ::getenv("C_INCLUDE_PATH"); Opts.ObjCEnvIncPath = ::getenv("OBJC_INCLUDE_PATH"); Opts.CXXEnvIncPath = ::getenv("CPLUS_INCLUDE_PATH"); Opts.ObjCXXEnvIncPath = ::getenv("OBJCPLUS_INCLUDE_PATH"); ...hasn't been implemented? This would need to be expanded to solve PR10296 for LIBRARY_PATH and the null checks added of course. From phoolimin at gmail.com Thu Jul 7 16:51:52 2011 From: phoolimin at gmail.com (Limin Fu) Date: Thu, 7 Jul 2011 14:51:52 -0700 Subject: [cfe-dev] Confused by getPointOfInstantiation() of ClassTemplateSpecializationDecl Message-ID: Hello, I am trying to handle C++ templates in my automatic binding tool based on Clang. I run into a problem that requires to determine the location of the first instantiation of a template class. Basically, I have a file that declares a function with parameter of type "std::vector". From the FunctionDecl of that function, I get a TemplateSpecializationType object and then a ClassTemplateSpecializationDecl object for the parameter type. I thought method getPointOfInstantiation() of ClassTemplateSpecializationDecl will give a location in my file, but instead, it gives a location from stl_vector.h. Isn't the instantiation point supposed to be located in my file? Or am I understanding something wrong here? Thanks a lot. Limin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110707/8a51b8c8/attachment.html From rjmccall at apple.com Thu Jul 7 17:03:43 2011 From: rjmccall at apple.com (John McCall) Date: Thu, 07 Jul 2011 15:03:43 -0700 Subject: [cfe-dev] Confused by getPointOfInstantiation() of ClassTemplateSpecializationDecl In-Reply-To: References: Message-ID: On Jul 7, 2011, at 2:51 PM, Limin Fu wrote: > Hello, > > I am trying to handle C++ templates in my automatic binding tool based on Clang. I run into a problem that requires to determine the location of the first instantiation of a template class. > > Basically, I have a file that declares a function with parameter of type "std::vector". From the FunctionDecl of that function, I get a TemplateSpecializationType object and then a ClassTemplateSpecializationDecl object for the parameter type. I thought method getPointOfInstantiation() of ClassTemplateSpecializationDecl will give a location in my file, but instead, it gives a location from stl_vector.h. > > Isn't the instantiation point supposed to be located in my file? Or am I understanding something wrong here? Thanks a lot. The point of instantiation is the location that actually first forced your template to be instantiated. Just writing the template specialization type won't do that ? it can stay an incomplete type up until something actually tries to look at its members or bases. John. From phoolimin at gmail.com Thu Jul 7 17:21:10 2011 From: phoolimin at gmail.com (Limin Fu) Date: Thu, 7 Jul 2011 15:21:10 -0700 Subject: [cfe-dev] Confused by getPointOfInstantiation() of ClassTemplateSpecializationDecl In-Reply-To: References: Message-ID: Hi John, Thank you for the explanation. It's clear now. I will use the ParmVarDecl::getLocation() for the parameter instead. Limin On Thu, Jul 7, 2011 at 3:03 PM, John McCall wrote: > > On Jul 7, 2011, at 2:51 PM, Limin Fu wrote: > > > Hello, > > > > I am trying to handle C++ templates in my automatic binding tool based on > Clang. I run into a problem that requires to determine the location of the > first instantiation of a template class. > > > > Basically, I have a file that declares a function with parameter of type > "std::vector". From the FunctionDecl of that function, I get a > TemplateSpecializationType object and then a ClassTemplateSpecializationDecl > object for the parameter type. I thought method getPointOfInstantiation() of > ClassTemplateSpecializationDecl will give a location in my file, but > instead, it gives a location from stl_vector.h. > > > > Isn't the instantiation point supposed to be located in my file? Or am I > understanding something wrong here? Thanks a lot. > > The point of instantiation is the location that actually first forced your > template to be instantiated. Just writing the template specialization type > won't do that ? it can stay an incomplete type up until something actually > tries to look at its members or bases. > > John. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110707/19577136/attachment.html From god.son2046 at yahoo.com.cn Thu Jul 7 18:12:33 2011 From: god.son2046 at yahoo.com.cn (hunter) Date: Thu, 7 Jul 2011 16:12:33 -0700 (PDT) Subject: [cfe-dev] How to design my own annotation language? Message-ID: <1310080353270-3149984.post@n3.nabble.com> Hi All, I hope to have a try to design some annotations for C or C++. But I am new to Clang and wandering where I should start with, e.g. how to parse the annotations and how the compiler react at compiler-time when it sees the annotations. Could anyone give some advice? Thanks in advance! Best, Chen -- View this message in context: http://clang-developers.42468.n3.nabble.com/How-to-design-my-own-annotation-language-tp3149984p3149984.html Sent from the Clang Developers mailing list archive at Nabble.com. From lattner at apple.com Thu Jul 7 18:41:57 2011 From: lattner at apple.com (Tanya Lattner) Date: Thu, 07 Jul 2011 16:41:57 -0700 Subject: [cfe-dev] OpenCL patch: vector literals (alternative patch) In-Reply-To: <000001cc3cb9$07cc7d40$176577c0$%Lokhmotov@arm.com> References: <000001cc371d$e2322c60$a6968520$%Lokhmotov@arm.com> <9FDE1029-AFCA-4021-B1A1-9BC9E1952B27@apple.com> <000001cc3cb9$07cc7d40$176577c0$%Lokhmotov@arm.com> Message-ID: <225FC18A-3EA1-40BD-B22D-874FAA4E6F60@apple.com> I'm attaching an alternative patch which handles the missing vector splat case. It passes all the valid and invalid test cases you provided and I included those tests in the patch. It also uses the fix in SemaInit that you included which handles the crash for one invalid case. Thanks, Tanya -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenCL-VectorLiterals.patch Type: application/octet-stream Size: 2855 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110707/c1e1313d/attachment.obj -------------- next part -------------- On Jul 7, 2011, at 8:17 AM, Anton Lokhmotov wrote: > Hi Tanya, > > Many thanks for your prompt review! > >> All the support already exists for all the valid test cases >> except the last one ((float4)( float )). One just has to modify >> ActOnCastOfParenListExpr which is now BuildVectorLiteral to handle >> the splat case. I have not modified our patch to match the recent >> changes in TOT, but will do shortly. > > We would be happy with minimal changes to Clang provided that the OpenCL > requirements are properly met, including handling invalid code. We > specifically avoided using/modifying/breaking the existing functionality for > AltiVec because the OpenCL syntax is quite different. Thus, we believe that > for OpenCL CompilerInvocation::setLangDefaults() should disable Opts.AltiVec > (and OTOH enable Opts.Bool - but sorry about that slipping into this patch). > >> Yes, you are 100% right that the test violates the OpenCL spec >> (my mistake and haste in making a patch), but its catching a nasty >> compiler crash and I'd rather try to modify the test instead of just >> removing it. I've fixed this in TOT. > > Unfortunately, > > void foo( uchar8 x ) > { > uchar4 val[4] = {{(uchar4){x.lo}}}; > } > > is still invalid in OpenCL C. In particular, OpenCL doesn't allow using > braces {} in vector literals. > > [Actually, I'm quite confused by this test. Since x.lo produces uchar4, the > cast is superfluous? And then it attempts to initialize an array of vectors > val[] from vector x.lo. But I actually would expect only val[0] to be > initialized (backed by my experiments with gcc). But if it's just ensuring > that the compiler doesn't crash, that's fine (in the AltiVec mode).] > >> For the invalid cases, I don't see why one needs to modify the parser, >> but the last invalid case does crash the compiler which shouldn't ever >> happen. > > Could you please ensure that the patch is applied correctly? It works fine > with r134483. Specifically, this modification prevents the compiler from > crashing: > > [11:17:50] Vitaly Lugovskiy: diff --git a/lib/Sema/SemaInit.cpp > b/lib/Sema/SemaInit.cpp > index 16ba2a2..17af145 100644 > --- a/lib/Sema/SemaInit.cpp > +++ b/lib/Sema/SemaInit.cpp > @@ -769,7 +769,8 @@ void InitListChecker::CheckSubElementType(const > InitializedEntity &Entity, > // subaggregate, brace elision is assumed and the initializer is > // considered for the initialization of the first member of > // the subaggregate. > - if (ElemType->isAggregateType() || ElemType->isVectorType()) { > + if (!SemaRef.getLangOptions().OpenCL && > + (ElemType->isAggregateType() || ElemType->isVectorType())) { > CheckImplicitInitList(Entity, IList, ElemType, Index, StructuredList, > StructuredIndex); > ++StructuredIndex; > > If you provide your modifications to support vector literals, we will run > our test cases with combinatorial coverage to ensure that the OpenCL > requirements are met. > > Best wishes, > Anton. > > > From konstantin.weitz at googlemail.com Thu Jul 7 18:57:09 2011 From: konstantin.weitz at googlemail.com (Konstantin Weitz) Date: Thu, 7 Jul 2011 16:57:09 -0700 Subject: [cfe-dev] Finding members in a translation unit Message-ID: Greetings, I posted the same question earlier today on the IRC channel but nobody was able to answer it. My goal is to find all member functions in a translation unit. I was advised, that I can use CXXRecordDecl to iterate over the members of one class. In order to get the CXXRecordDecl object for each class in a translation unit, I'm overriding RecursiveASTVisitor's VisitCXXRecordDecl member function. I would expect to get called for each class. What actually happens is that the VisitVarDecl member is called instead. Any idea why this is happening and how I can fix it? If you would like to reproduce my results, here is my code http://pastebin.com/eFhBfDzb Thanks in advance Konstantin Weitz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110707/faffeb34/attachment-0001.html From chandlerc at google.com Thu Jul 7 20:49:39 2011 From: chandlerc at google.com (Chandler Carruth) Date: Thu, 7 Jul 2011 18:49:39 -0700 Subject: [cfe-dev] Switching terminology from 'instantiation' to 'expansion' for macros? Message-ID: This is something that came up some time ago on IRC, and several (myself, John McCall, and maybe others) really liked the idea of: systematically switch from 'instantiation' to 'expansion' in terminology relating to macros and the preprocessor. (Is there a better word than 'expand'? I couldn't come up with one. The following argument should be independent of what wording is actually chosen, except that it be different from 'instantiation'.) The reasoning is two fold: 1) It more accurately describes the underlying process (token expansion), including the fact that the process happens on each use of a macro, not just on the first with a particular set of arguments, etc. 2) It helps users (and likely developers) distinguish between diagnostics and systems relating to macros vs. templates. I think the second point is perhaps the most important here. As a bit of an extreme case, consider the following code: % cat t5.cc struct S1; struct S2; template struct X1 { T value; }; template struct X2 { X1 value; }; #define M0 X2().value; #define M1(x, y, z) X2 foo = y #define M2(x, y, z) M1(x, y, z) M2(1, M0, 3); % ./bin/clang -fsyntax-only t5.cc t5.cc:3:37: error: field has incomplete type 'S1' template struct X1 { T value; }; ^ t5.cc:4:41: note: in instantiation of template class 'X1' requested here template struct X2 { X1 value; }; ^ t5.cc:8:7: note: in instantiation of template class 'X2' requested here M2(1, M0, 3); ^ t5.cc:5:12: note: instantiated from: #define M0 X2().value; ^ t5.cc:7:27: note: instantiated from: #define M2(x, y, z) M1(x, y, z) ^ t5.cc:6:34: note: instantiated from: #define M1(x, y, z) X2 foo = y ^ I think it's very nice to have different wording for the macro back traces. As a bit of a straw-man, I've just replaced 'instantiated' with 'expanded' and I already find the result somewhat better: % ./bin/clang -fsyntax-only t5.cc t5.cc:3:37: error: field has incomplete type 'S1' template struct X1 { T value; }; ^ t5.cc:4:41: note: in instantiation of template class 'X1' requested here template struct X2 { X1 value; }; ^ t5.cc:8:7: note: in instantiation of template class 'X2' requested here M2(1, M0, 3); ^ t5.cc:5:12: note: expanded from: #define M0 X2().value; ^ t5.cc:7:27: note: expanded from: #define M2(x, y, z) M1(x, y, z) ^ t5.cc:6:34: note: expanded from: #define M1(x, y, z) X2 foo = y ^ I'd like to slowly work to move the note text to be instead: % ./bin/clang -fsyntax-only t5.cc t5.cc:3:37: error: field has incomplete type 'S1' template struct X1 { T value; }; ^ t5.cc:4:41: note: in instantiation of template class 'X1' requested here template struct X2 { X1 value; }; ^ t5.cc:8:7: note: in instantiation of template class 'X2' requested here M2(1, M0, 3); ^ t5.cc:5:12: note: 'M0' expanded from the macro defined here: #define M0 X2().value; ^ t5.cc:7:27: note: 'M2(...)' expanded from the macro defined here: #define M2(x, y, z) M1(x, y, z) ^ t5.cc:6:34: note: 'M1(...)' expanded from the macro defined here: #define M1(x, y, z) X2 foo = y ^ What do folks think? Would it be OK to work toward this in increments, starting with 'expanded from the macro defined here', and then working on a patch to add the name of the macro that we're showing the definition for? As a related, but not necessary additional step, how do folks feel about moving the APIs, comments, etc inside of Clang's code itself to use the same nomenclature? I'd really like to see this as it would make reading these parts of the codebase easier in the same way I think it makes reading the diagnostics above easier. Thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110707/47430e7f/attachment.html From raptorfactor at raptorfactor.com Thu Jul 7 21:53:16 2011 From: raptorfactor at raptorfactor.com (Joshua Boyce) Date: Fri, 8 Jul 2011 12:53:16 +1000 Subject: [cfe-dev] Clang for MinGW package In-Reply-To: References: Message-ID: Isn't the package that you linked the GCC package not the Clang package? Thanks again. On Thu, Jul 7, 2011 at 11:18 PM, Ruben Van Boxem wrote: > 2011/7/7 Joshua Boyce : > > Thanks so much for providing these packages! > > You're welcome! > > > One small issue though. The following DLLs are missing from the package: > > libgcc_s_sjlj-1.dll > > libstdc++-6.dll > > Other than that though it seems to be working. (I copied the above files > > from the MinGW-w64 GCC libexec folder.) > > Can't wait till the STL, Boost, etc is working... ;) > > No, I'm quite sure they're present in the packages. I just redownloaded > > http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/rubenvb/4.6.2/x86_64-w64-mingw32-gcc-4.6.2_rubenvb.7z > > and it's in the mingw64/bin directory. Must be something with your > download/unzipping gone wrong. Be sure to use 9.20 or later. > > Ruben > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110708/49f85539/attachment.html From raptorfactor at raptorfactor.com Thu Jul 7 22:01:15 2011 From: raptorfactor at raptorfactor.com (Joshua Boyce) Date: Fri, 8 Jul 2011 13:01:15 +1000 Subject: [cfe-dev] Clang for MinGW package In-Reply-To: References: Message-ID: Oh I see, you're supposed to extract both packages into the same directory. I feel silly now. Sorry for the noise. On Fri, Jul 8, 2011 at 12:53 PM, Joshua Boyce wrote: > Isn't the package that you linked the GCC package not the Clang package? > > Thanks again. > > > On Thu, Jul 7, 2011 at 11:18 PM, Ruben Van Boxem > wrote: > >> 2011/7/7 Joshua Boyce : >> > Thanks so much for providing these packages! >> >> You're welcome! >> >> > One small issue though. The following DLLs are missing from the package: >> > libgcc_s_sjlj-1.dll >> > libstdc++-6.dll >> > Other than that though it seems to be working. (I copied the above files >> > from the MinGW-w64 GCC libexec folder.) >> > Can't wait till the STL, Boost, etc is working... ;) >> >> No, I'm quite sure they're present in the packages. I just redownloaded >> >> http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/rubenvb/4.6.2/x86_64-w64-mingw32-gcc-4.6.2_rubenvb.7z >> >> and it's in the mingw64/bin directory. Must be something with your >> download/unzipping gone wrong. Be sure to use 9.20 or later. >> >> Ruben >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110708/8ecbae26/attachment.html From jfreeman at cse.tamu.edu Thu Jul 7 22:45:22 2011 From: jfreeman at cse.tamu.edu (John Freeman) Date: Thu, 07 Jul 2011 22:45:22 -0500 Subject: [cfe-dev] Switching terminology from 'instantiation' to 'expansion' for macros? In-Reply-To: References: Message-ID: <4E167D52.8000509@cse.tamu.edu> On 7/7/11 8:49 PM, Chandler Carruth wrote: > Thoughts? I like all of it. I do have a question: is the term "expansion" also used in another case involving templates, like parameter packs? Should we try to use a third term for macros in that case, like "substitution" (which is also used for templates (think "SFINAE"); maybe there is no winning this battle)? - John From chandlerc at google.com Thu Jul 7 23:10:39 2011 From: chandlerc at google.com (Chandler Carruth) Date: Thu, 7 Jul 2011 21:10:39 -0700 Subject: [cfe-dev] Switching terminology from 'instantiation' to 'expansion' for macros? In-Reply-To: <4E167D52.8000509@cse.tamu.edu> References: <4E167D52.8000509@cse.tamu.edu> Message-ID: On Thu, Jul 7, 2011 at 8:45 PM, John Freeman wrote: > On 7/7/11 8:49 PM, Chandler Carruth wrote: > > Thoughts? > > I like all of it. I do have a question: is the term "expansion" also > used in another case involving templates, like parameter packs? Oof, yea, it is. On the good side, the standard uses 'expansion' in that context almost exclusively as 'pack expansion', a term defined in the standard. I suspect any use we made of it in diagnostics could also be profitably tied to the word 'pack'. Also, both the C and C++ standards refer to 'macro expansion' to mean this. Should > we try to use a third term for macros in that case, like "substitution" > (which is also used for templates (think "SFINAE"); Good idea, the C standard uses 'substitution' to describe the process through which arguments to function-style macros are substituted into the macro body (C99 6.10.3.1). We should at the least try to use 'substitution' in the code surrounding this process in Clang IMO. However, I don't think there are many contexts where we need or want to distinguish between macro expansion and argument substitution, but i'd not be opposed to using those two compound terms if that situation arises. maybe there is no > winning this battle)? > I'm fairly certain there is no perfect word. ;] That said, I like that both macro expansion and argument substitution are mentioned in the standard. The only other term I've thought about is 'replacement' as that's what the standard uses in most cases. However, for diagnostics and thinking about how the preprocessor works, I actually find 'expansion' much more helpful. However, if others like the C standard's 'replacement' terminology, I'd be down with that. =] -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110707/84b3e132/attachment-0001.html From zaffanella at cs.unipr.it Fri Jul 8 01:22:18 2011 From: zaffanella at cs.unipr.it (Enea Zaffanella) Date: Fri, 08 Jul 2011 08:22:18 +0200 Subject: [cfe-dev] Re-setting a bitfield width expression. Message-ID: <4E16A21A.80707@cs.unipr.it> We have a question regarding the current interface for FieldDecl. For the case of in-class member initializers, we have the following methods: bool hasInClassInitializer(); Expr *getInClassInitializer() const; void setInClassInitializer(Expr *Init); void removeInClassInitializer(); The last method is needed because setInClassInitializer has an assertion preventing resetting the expression if it was already set. For the case of bitfields, we have: bool isBitField() const; Expr *getBitWidth() const; void setBitWidth(Expr *BW); Method setBitWidth has a similar assertion preventing a reset, but in this case there is no method removeBitWidth: once the bitfield width is set, there is no way (in debugging mode) to reset it. In our application (working at the source code level) we sometimes replace expressions in the AST by equivalent ones and this also happens for bitfield width expressions. Would it be OK if we add in a method such as the following: void removeBitWidth() { assert(isBitField() && "no bitwidth to remove"); InitializerOrBitWidth.setPointer(0); } As an alternative (which is enough for our purposes), we could weaken the assertion in setBitWidth as follows: void setBitWidth(Expr *BW) { assert(!hasInClassInitializer() && "in-class initializer already set"); InitializerOrBitWidth.setPointer(BW); InitializerOrBitWidth.setInt(1); } While at it, we noted a naming mismatch between methods isBitField (Field is capitalized here) and isUnnamedBitfield (field is not capitalized). It looks like elsewhere the second form was preferred. Is it OK if we change isBitField to isBitfield for consistency? Regards, Enea. From dgregor at apple.com Fri Jul 8 01:26:03 2011 From: dgregor at apple.com (Douglas Gregor) Date: Thu, 07 Jul 2011 23:26:03 -0700 Subject: [cfe-dev] [cfe-commits] [PATCH] Parsing C++0x lambda expressions In-Reply-To: <4E15FC82.9070209@cse.tamu.edu> References: <4E149900.9000001@cse.tamu.edu> <136B65C1-41E5-4989-A47E-E1D1D9FE0D3C@apple.com> <4E15FC82.9070209@cse.tamu.edu> Message-ID: <3497C908-451C-441B-BF2C-24E0D7B7B836@apple.com> Sent from my iPhone On Jul 7, 2011, at 11:35 AM, John Freeman wrote: > On 7/6/2011 2:59 PM, Douglas Gregor wrote: >> + // Parse lambda-declarator[opt]. >> + // FIXME: Should we default the type quals, or store mutability in this? >> + DeclSpec DS(AttrFactory); >> >> Parse as it's written, and let Sema/AST deal with the mutability. >> >> + // Parse 'mutable'[opt]. >> + if (Tok.is(tok::kw_mutable)) { >> + // FIXME: How should we add this to the declarator? Should we instead >> + // add const-ness if we do not see 'mutable'? >> + ConsumeToken(); >> + } >> >> Just extend the Declarator class with a location for the lambda 'mutable' and Sema will deal with it. > > What is the best place to keep the lambda 'mutable' location? Declarator, or perhaps DeclSpec, or DeclaratorChunk::FunctionTypeInfo (my best guess)? DeclaratorChunk::FunctionTypeInfo is fine. > Also, there is an EllipsisLoc in Declarator. I don't see any code using it in either DeclSpec.h or DeclSpec.cpp. Is it used? Parameter packs use it. From rjmccall at apple.com Fri Jul 8 02:30:04 2011 From: rjmccall at apple.com (John McCall) Date: Fri, 08 Jul 2011 00:30:04 -0700 Subject: [cfe-dev] Switching terminology from 'instantiation' to 'expansion' for macros? In-Reply-To: References: <4E167D52.8000509@cse.tamu.edu> Message-ID: <14CE0BFF-5D16-4517-8514-83E9A6014CCC@apple.com> On Jul 7, 2011, at 9:10 PM, Chandler Carruth wrote: > The only other term I've thought about is 'replacement' as that's what the standard uses in most cases. However, for diagnostics and thinking about how the preprocessor works, I actually find 'expansion' much more helpful. However, if others like the C standard's 'replacement' terminology, I'd be down with that. =] I like 'expansion'. Specifically, I like "expanded from macro here", or something like that. I wouldn't try to call out specific cases of where the text came from; there's a lot of value in having a consistent message for these, because users can recognize the shape of a macro-expansion note at a glance without having to actually read it. It is not worth trying to avoid the name collision with variadic template parameter packs. Thanks for doing this! John. From rjmccall at apple.com Fri Jul 8 02:32:13 2011 From: rjmccall at apple.com (John McCall) Date: Fri, 08 Jul 2011 00:32:13 -0700 Subject: [cfe-dev] Re-setting a bitfield width expression. In-Reply-To: <4E16A21A.80707@cs.unipr.it> References: <4E16A21A.80707@cs.unipr.it> Message-ID: On Jul 7, 2011, at 11:22 PM, Enea Zaffanella wrote: > In our application (working at the source code level) we sometimes > replace expressions in the AST by equivalent ones and this also happens > for bitfield width expressions. > Would it be OK if we add in a method such as the following: > > void removeBitWidth() { > assert(isBitField() && "no bitwidth to remove"); > InitializerOrBitWidth.setPointer(0); > } > > As an alternative (which is enough for our purposes), we could weaken > the assertion in setBitWidth as follows: I like the remove option. > While at it, we noted a naming mismatch between methods isBitField > (Field is capitalized here) and isUnnamedBitfield (field is not > capitalized). It looks like elsewhere the second form was preferred. > Is it OK if we change isBitField to isBitfield for consistency? Fine by me. John. From chandlerc at google.com Fri Jul 8 03:15:37 2011 From: chandlerc at google.com (Chandler Carruth) Date: Fri, 8 Jul 2011 01:15:37 -0700 Subject: [cfe-dev] Switching terminology from 'instantiation' to 'expansion' for macros? In-Reply-To: <14CE0BFF-5D16-4517-8514-83E9A6014CCC@apple.com> References: <4E167D52.8000509@cse.tamu.edu> <14CE0BFF-5D16-4517-8514-83E9A6014CCC@apple.com> Message-ID: On Fri, Jul 8, 2011 at 12:30 AM, John McCall wrote: > On Jul 7, 2011, at 9:10 PM, Chandler Carruth wrote: > > The only other term I've thought about is 'replacement' as that's what > the standard uses in most cases. However, for diagnostics and thinking about > how the preprocessor works, I actually find 'expansion' much more helpful. > However, if others like the C standard's 'replacement' terminology, I'd be > down with that. =] > > I like 'expansion'. Specifically, I like "expanded from macro here", or > something like that. I wouldn't try to call out specific cases of where the > text came from; there's a lot of value in having a consistent message for > these, because users can recognize the shape of a macro-expansion note at a > glance without having to actually read it. John and I chatted on IRC about various wordings for these notes. He was particularly concerned about keeping them short and concise, which I agree with, and hopefully the macro name itself won't negatively impact that too much. Based on your suggestion my two candidate wordings would be: "note: expanded from macro 'foo':" and "note: expanded from macro 'foo' defined here:" The latter is a bit wordy, but helps give context to the snippet that follows, and has good structural similarity to the template message: "note: in instantiation of template class 'foo' requested here:" One concern with just removing "defined" is the ambiguity of "here" referring to either where the expansion occurs or the definition. Without the "here", the snippet would hopefully associate with the "macro 'foo'", but it's still a touch vague... More thoughts on wording welcome! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110708/47e8eac3/attachment.html From renato.golin at arm.com Fri Jul 8 06:06:45 2011 From: renato.golin at arm.com (Renato Golin) Date: Fri, 8 Jul 2011 12:06:45 +0100 Subject: [cfe-dev] LLVM European User Group Meeting 2011 - Call For Participation Message-ID: Dear LLVM users, ARM Ltd. is proud to sponsor the first European LLVM User Group Meeting, in London, UK, on the afternoon of Friday, 16th September, 2011. This will be a half-day meeting for LLVM users to exchange ideas, expose new developments and generally strengthen the network of LLVM developers in and around Europe. The meeting is open to anyone, from corporate to academia, professionals to enthusiasts. While this is not a full conference like the US LLVM Developers' Meeting, we plan to have talks, posters, demonstrations and a lot of discussion. We hope that those most active in LLVM development will consider attending both meetings. The topic themes for the September 2011 meeting include: * CPU architecture support, code generation, generic optimizations * OpenCL and graphics processing * Interesting research and projects using the LLVM infrastructure * Current developments and the future of LLVM (MC, JIT, vectorisation, &c.) Call for Speakers, Posters, Demos: We are looking for speakers to cover these topic themes. Speakers may represent research, hobbyist, or commercial activity. All are welcome. For this initial meeting we are planning to have only 3-4 presentation slots and place for a couple posters, so we shall choose papers/posters/demos breadth first, to cover as many topic themes as possible. The deadline for receiving an extended abstract is 09:00 BST 1st of August, 2011. Speakers will notified of acceptance or rejection before 17:30 BST 9th August 2011. The final submission deadline is 09:00 BST 12th September 2011. Slides and posters must be in PDF format and will be published electronically via the LLVM web presence after the meeting. Organisation We'll be discussing the organisation of the event on the main LLVM mailing list (llvmdev at cs.uiuc.edu), and we welcome suggestions and help. The event will take place during the afternoon and we'll provide dinner and some beer at the end to complement the networking. Registration: Registration is via email (Euro-LLVM at arm.com), on a first-come-first-serve basis, free of charge. Please, send your details (name, email, company/institution) and we'll publish this in the official LLVM website (unless requested otherwise). Attendance will be limited to about 60 people, depending on the venue. Financial Support: At this time, we cannot be sure if there will be funding for active contributors and students to attend the event. However, we are hopeful that we will have company sponsorship to make this happen. Those who are funded are required to present at the meeting and may have other requirements from their sponsor (i.e. writing a blog post, etc). If you need funding to attend the meeting, or can help sponsor, please tell us in your registration email (to Euro-LLVM at arm.com). About LLVM: The Low-Level Virtual Machine (LLVM) is a collection of libraries and tools that make it easy to build compilers, optimizers, Just-In-Time code generators, and many other compiler-related programs. LLVM uses a single, language-independent virtual instruction set both as an offline code representation (to communicate code between compiler phases and to run-time systems) and as the compiler internal representation (to analyse and transform programs). This persistent code representation allows a common set of sophisticated compiler techniques to be applied at compile-time, link-time, install-time, run- time, or "idle-time" (between program runs). The strengths of the LLVM infrastructure are its extremely simple design (which makes it easy to understand and use), source-language independence, powerful mid-level optimizer, automated compiler debugging support, extensibility, and its stability and reliability. LLVM is currently being used to host a wide variety of academic research projects and commercial projects. For more information, please visit: http://llvm.org/ From dgregor at apple.com Fri Jul 8 10:16:51 2011 From: dgregor at apple.com (Douglas Gregor) Date: Fri, 08 Jul 2011 08:16:51 -0700 Subject: [cfe-dev] Switching terminology from 'instantiation' to 'expansion' for macros? In-Reply-To: <14CE0BFF-5D16-4517-8514-83E9A6014CCC@apple.com> References: <4E167D52.8000509@cse.tamu.edu> <14CE0BFF-5D16-4517-8514-83E9A6014CCC@apple.com> Message-ID: On Jul 8, 2011, at 12:30 AM, John McCall wrote: > On Jul 7, 2011, at 9:10 PM, Chandler Carruth wrote: >> The only other term I've thought about is 'replacement' as that's what the standard uses in most cases. However, for diagnostics and thinking about how the preprocessor works, I actually find 'expansion' much more helpful. However, if others like the C standard's 'replacement' terminology, I'd be down with that. =] > > I like 'expansion'. Specifically, I like "expanded from macro here", or something like that. I wouldn't try to call out specific cases of where the text came from; there's a lot of value in having a consistent message for these, because users can recognize the shape of a macro-expansion note at a glance without having to actually read it. > > It is not worth trying to avoid the name collision with variadic template parameter packs. Agreed on all points. - Doug From dblaikie at gmail.com Fri Jul 8 10:28:02 2011 From: dblaikie at gmail.com (David Blaikie) Date: Fri, 8 Jul 2011 08:28:02 -0700 Subject: [cfe-dev] [cfe-commits] r134697 - /cfe/trunk/lib/Analysis/UninitializedValues.cpp Message-ID: <168982537275046849@unknownmsgid> Is there a bug for why this scenario happened at all, given that the variables in the switch were locally scoped to each case, or is that by design for some reason? From: Chandler Carruth Sent: Friday, July 08, 2011 4:20 AM To: cfe-commits at cs.uiuc.edu Subject: [cfe-commits] r134697 - /cfe/trunk/lib/Analysis/UninitializedValues.cpp Author: chandlerc Date: Fri Jul 8 06:19:06 2011 New Revision: 134697 URL: http://llvm.org/viewvc/llvm-project?rev=134697&view=rev Log: Make the worklist in the uninitialized values checker actually a queue. Previously, despite the names 'enqueue' and 'dequeue', it behaved as a stack and visited blocks in a LIFO fashion. This interacts badly with extremely broad CFGs *inside* of a loop (such as a large switch inside a state machine) where every block updates a different variable. When encountering such a CFG, the checker visited blocks in essentially a "depth first" order due to the stack-like behavior of the work list. Combined with each block updating a different variable, the saturation logic of the checker caused it to re-traverse blocks [1,N-1] of the broad CFG inside the loop after traversing block N. These re-traversals were to propagate the variable values derived from block N. Assuming approximately the same number of variables as inner blocks exist, the end result is O(N^2) updates. By making this a queue, we also make the traversal essentially "breadth-first" across each of the N inner blocks of the loop. Then all of this state is propagated around to all N inner blocks of the loop. The result is O(N) updates. The truth is in the numbers: Before, gcc.c: 96409 block visits (max: 61546, avg: 591) After, gcc.c: 69958 block visits (max: 33090, avg: 429) Before, PR10183: 2540494 block vists (max: 2536495, avg: 37360) After, PR10183: 137803 block visits (max: 134406, avg: 2026) The nearly 20x reduction in work for PR10183 corresponds to a roughly 100x speedup in compile time. I've tested it on all the code I can get my hands on, and I've seen no slowdowns due to this change. Where I've collected stats, the ammount of work done is on average less. I'll also commit shortly some synthetic test cases useful in analyzing the performance of CFG-based warnings. Submitting this based on Doug's feedback that post-commit review should be good. Ted, please review! Hopefully this helps compile times until then. Modified: cfe/trunk/lib/Analysis/UninitializedValues.cpp Modified: cfe/trunk/lib/Analysis/UninitializedValues.cpp URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Analysis/UninitializedValues.cpp?rev=134697&r1=134696&r2=134697&view=diff ============================================================================== --- cfe/trunk/lib/Analysis/UninitializedValues.cpp (original) +++ cfe/trunk/lib/Analysis/UninitializedValues.cpp Fri Jul 8 06:19:06 2011 @@ -288,28 +288,28 @@ public: DataflowWorklist(const CFG &cfg) : enqueuedBlocks(cfg.getNumBlockIDs()) {} - void enqueue(const CFGBlock *block); void enqueueSuccessors(const CFGBlock *block); const CFGBlock *dequeue(); - }; } -void DataflowWorklist::enqueue(const CFGBlock *block) { - if (!block) - return; - unsigned idx = block->getBlockID(); - if (enqueuedBlocks[idx]) - return; - worklist.push_back(block); - enqueuedBlocks[idx] = true; -} - void DataflowWorklist::enqueueSuccessors(const clang::CFGBlock *block) { + unsigned OldWorklistSize = worklist.size(); for (CFGBlock::const_succ_iterator I = block->succ_begin(), E = block->succ_end(); I != E; ++I) { - enqueue(*I); + const CFGBlock *Successor = *I; + if (!Successor || enqueuedBlocks[Successor->getBlockID()]) + continue; + worklist.push_back(Successor); + enqueuedBlocks[Successor->getBlockID()] = true; } + if (OldWorklistSize == 0 || OldWorklistSize == worklist.size()) + return; + + // Rotate the newly added blocks to the start of the worklist so that it forms + // a proper queue when we pop off the end of the worklist. + std::rotate(worklist.begin(), worklist.begin() + OldWorklistSize, + worklist.end()); } const CFGBlock *DataflowWorklist::dequeue() { _______________________________________________ cfe-commits mailing list cfe-commits at cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits From xiaolong.snake at gmail.com Fri Jul 8 10:38:31 2011 From: xiaolong.snake at gmail.com (Xiaolong Tang) Date: Fri, 08 Jul 2011 10:38:31 -0500 Subject: [cfe-dev] How to ouput the AST of the instantiated function template Message-ID: Hi all, I am interested to check the AST of the instantiated template function. Is there a way to do so? The command "clang++ -cc1 XX.cpp -ast-print" only outputs the AST of the source language. The command "clang++ -emit-ast ..." does not work either. Best, Xiaolong From clattner at apple.com Fri Jul 8 11:20:38 2011 From: clattner at apple.com (Chris Lattner) Date: Fri, 08 Jul 2011 09:20:38 -0700 Subject: [cfe-dev] Switching terminology from 'instantiation' to 'expansion' for macros? In-Reply-To: References: <4E167D52.8000509@cse.tamu.edu> <14CE0BFF-5D16-4517-8514-83E9A6014CCC@apple.com> Message-ID: On Jul 8, 2011, at 8:16 AM, Douglas Gregor wrote: > > On Jul 8, 2011, at 12:30 AM, John McCall wrote: > >> On Jul 7, 2011, at 9:10 PM, Chandler Carruth wrote: >>> The only other term I've thought about is 'replacement' as that's what the standard uses in most cases. However, for diagnostics and thinking about how the preprocessor works, I actually find 'expansion' much more helpful. However, if others like the C standard's 'replacement' terminology, I'd be down with that. =] >> >> I like 'expansion'. Specifically, I like "expanded from macro here", or something like that. I wouldn't try to call out specific cases of where the text came from; there's a lot of value in having a consistent message for these, because users can recognize the shape of a macro-expansion note at a glance without having to actually read it. >> >> It is not worth trying to avoid the name collision with variadic template parameter packs. > > Agreed on all points. +1 -Chris From chandlerc at google.com Fri Jul 8 12:03:07 2011 From: chandlerc at google.com (Chandler Carruth) Date: Fri, 8 Jul 2011 10:03:07 -0700 Subject: [cfe-dev] Switching terminology from 'instantiation' to 'expansion' for macros? In-Reply-To: References: <4E167D52.8000509@cse.tamu.edu> <14CE0BFF-5D16-4517-8514-83E9A6014CCC@apple.com> Message-ID: On Fri, Jul 8, 2011 at 8:16 AM, Douglas Gregor wrote: > Agreed on all points. Thoughts on my second question (that of the names used in the actual code of Clang)? I'll start on fixing the diagnostics based on this plan today. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110708/27981a20/attachment.html From kyrtzidis at apple.com Fri Jul 8 12:24:29 2011 From: kyrtzidis at apple.com (Argyrios Kyrtzidis) Date: Fri, 08 Jul 2011 10:24:29 -0700 Subject: [cfe-dev] Switching terminology from 'instantiation' to 'expansion' for macros? In-Reply-To: References: <4E167D52.8000509@cse.tamu.edu> <14CE0BFF-5D16-4517-8514-83E9A6014CCC@apple.com> Message-ID: <322B0A16-CD9E-4525-A315-42E7492BBD8A@apple.com> On Jul 8, 2011, at 10:03 AM, Chandler Carruth wrote: > On Fri, Jul 8, 2011 at 8:16 AM, Douglas Gregor wrote: > Agreed on all points. > > Thoughts on my second question (that of the names used in the actual code of Clang)? I'll start on fixing the diagnostics based on this plan today. I like the whole proposal, and having the name change reflected in clang source code would be ideal, thanks for your work! > _______________________________________________ > 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/20110708/6a97fb89/attachment.html From saraslogo at gmail.com Fri Jul 8 18:53:18 2011 From: saraslogo at gmail.com (Loganathan L.) Date: Fri, 8 Jul 2011 16:53:18 -0700 Subject: [cfe-dev] clang build error Message-ID: Hi, While building clang and llvm, I get the following error: llvm[4]: Compiling HeaderSearch.cpp for Debug+Asserts build llvm[4]: Compiling Lexer.cpp for Debug+Asserts build In file included from /usr/pkgs/gcc/3.4.2/lib/gcc/x86_64-suse-linux/3.4.2/include/emmintrin.h:34, from /nfs/user/Clang/llvm/tools/clang/lib/Lex/Lexer.cpp:16 41: /usr/pkgs/gcc/3.4.2/lib/gcc/x86_64-suse-linux/3.4.2/include/xmmintrin.h: In function `float __vector__ _mm_set_ps(float, float, float, float)': /usr/pkgs/gcc/3.4.2/lib/gcc/x86_64-suse-linux/3.4.2/include/xmmintrin.h:894: error: ISO C++ forbids com pound-literals In file included from /nfs/user/Clang/llvm/tools/clang/lib/Lex/Lexer.cpp:16 41: /usr/pkgs/gcc/3.4.2/lib/gcc/x86_64-suse-linux/3.4.2/include/emmintrin.h: In function `double __vector__ _mm_set_pd(double, double)': /usr/pkgs/gcc/3.4.2/lib/gcc/x86_64-suse-linux/3.4.2/include/emmintrin.h:118: error: ISO C++ forbids com pound-literals I just did a ./configure before calling make. There was an earlier post indicating that clang comes with it own library. Is there a configure option to use this library instead? Thanks, Loganathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110708/bf114ed0/attachment.html From peter at 2ndquadrant.com Sat Jul 9 05:47:43 2011 From: peter at 2ndquadrant.com (Peter Geoghegan) Date: Sat, 9 Jul 2011 11:47:43 +0100 Subject: [cfe-dev] Error when building Clang from SVN tip on Linux Message-ID: Hi, I find that when building Clang on this system from SVN tip: [peter at peter build]$ uname -a Linux peter.laptop 2.6.38.8-32.fc15.x86_64 #1 SMP Mon Jun 13 19:49:05 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux I get the following error message: llvm[4]: Compiling IdentifierTable.cpp for Debug+Asserts build llvm[4]: Compiling SourceManager.cpp for Debug+Asserts build llvm[4]: Compiling TargetInfo.cpp for Debug+Asserts build llvm[4]: Compiling Targets.cpp for Debug+Asserts build /home/peter/llvm/tools/clang/lib/Basic/Targets.cpp: In constructor ?{anonymous}::DarwinTargetInfo::DarwinTargetInfo(const string&)?: /home/peter/llvm/tools/clang/lib/Basic/Targets.cpp:192:49: error: ?class llvm::Triple? has no member named ?getDarwinMajorNumber? /bin/rm: cannot remove `/home/peter/build/tools/clang/lib/Basic/Debug+Asserts/Targets.d.tmp': No such file or directory make[4]: *** [/home/peter/build/tools/clang/lib/Basic/Debug+Asserts/Targets.o] Error 1 make[4]: Leaving directory `/home/peter/build/tools/clang/lib/Basic' make[3]: *** [Basic/.makeall] Error 2 make[3]: Leaving directory `/home/peter/build/tools/clang/lib' make[2]: *** [all] Error 1 make[2]: Leaving directory `/home/peter/build/tools/clang' make[1]: *** [clang/.makeall] Error 2 make[1]: Leaving directory `/home/peter/build/tools' make: *** [all] Error 1 [peter at peter build]$ What's the problem here? Can someone fix it please? -- Peter Geoghegan ? ? ? http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services From hhinnant at apple.com Sat Jul 9 10:54:14 2011 From: hhinnant at apple.com (Howard Hinnant) Date: Sat, 09 Jul 2011 11:54:14 -0400 Subject: [cfe-dev] [libc++]: vector::const_reference and bitset::const_reference Message-ID: <27580602-54B7-499F-97C8-46C91057AEB8@apple.com> For those interested in libc++ issues, I'd like to draw your attention to: http://llvm.org/bugs/show_bug.cgi?id=10314 and request comments on the issue. Howard From clattner at apple.com Sat Jul 9 11:30:02 2011 From: clattner at apple.com (Chris Lattner) Date: Sat, 09 Jul 2011 09:30:02 -0700 Subject: [cfe-dev] Error when building Clang from SVN tip on Linux In-Reply-To: References: Message-ID: On Jul 9, 2011, at 3:47 AM, Peter Geoghegan wrote: > Hi, > > I find that when building Clang on this system from SVN tip: > > [peter at peter build]$ uname -a > Linux peter.laptop 2.6.38.8-32.fc15.x86_64 #1 SMP Mon Jun 13 19:49:05 > UTC 2011 x86_64 x86_64 x86_64 GNU/Linux > > I get the following error message: hi Peter, Make sure to keep llvm and clang in synch with each other. This looks like you updated clang but not llvm. -chris > > llvm[4]: Compiling IdentifierTable.cpp for Debug+Asserts build > llvm[4]: Compiling SourceManager.cpp for Debug+Asserts build > llvm[4]: Compiling TargetInfo.cpp for Debug+Asserts build > llvm[4]: Compiling Targets.cpp for Debug+Asserts build > /home/peter/llvm/tools/clang/lib/Basic/Targets.cpp: In constructor > ?{anonymous}::DarwinTargetInfo::DarwinTargetInfo(const > string&)?: > /home/peter/llvm/tools/clang/lib/Basic/Targets.cpp:192:49: error: > ?class llvm::Triple? has no member named ?getDarwinMajorNumber? > /bin/rm: cannot remove > `/home/peter/build/tools/clang/lib/Basic/Debug+Asserts/Targets.d.tmp': > No such file or directory > make[4]: *** [/home/peter/build/tools/clang/lib/Basic/Debug+Asserts/Targets.o] > Error 1 > make[4]: Leaving directory `/home/peter/build/tools/clang/lib/Basic' > make[3]: *** [Basic/.makeall] Error 2 > make[3]: Leaving directory `/home/peter/build/tools/clang/lib' > make[2]: *** [all] Error 1 > make[2]: Leaving directory `/home/peter/build/tools/clang' > make[1]: *** [clang/.makeall] Error 2 > make[1]: Leaving directory `/home/peter/build/tools' > make: *** [all] Error 1 > [peter at peter build]$ > > What's the problem here? Can someone fix it please? > > -- > Peter Geoghegan http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Training and Services > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From ismail at namtrac.org Sat Jul 9 11:37:42 2011 From: ismail at namtrac.org (=?UTF-8?B?xLBzbWFpbCBEw7ZubWV6?=) Date: Sat, 9 Jul 2011 18:37:42 +0200 Subject: [cfe-dev] Error when building Clang from SVN tip on Linux In-Reply-To: References: Message-ID: On Sat, Jul 9, 2011 at 6:30 PM, Chris Lattner wrote: > > On Jul 9, 2011, at 3:47 AM, Peter Geoghegan wrote: > > > Hi, > > > > I find that when building Clang on this system from SVN tip: > > > > [peter at peter build]$ uname -a > > Linux peter.laptop 2.6.38.8-32.fc15.x86_64 #1 SMP Mon Jun 13 19:49:05 > > UTC 2011 x86_64 x86_64 x86_64 GNU/Linux > > > > I get the following error message: > > hi Peter, > > Make sure to keep llvm and clang in synch with each other. This looks like > you updated clang but not llvm. And by that Chris means use "make update" instead of doing it by hand. ismail -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110709/9e341359/attachment-0001.html From jbytheway+llvm at gmail.com Sat Jul 9 12:34:18 2011 From: jbytheway+llvm at gmail.com (John Bytheway) Date: Sat, 09 Jul 2011 18:34:18 +0100 Subject: [cfe-dev] [libc++]: vector::const_reference and bitset::const_reference In-Reply-To: <27580602-54B7-499F-97C8-46C91057AEB8@apple.com> References: <27580602-54B7-499F-97C8-46C91057AEB8@apple.com> Message-ID: On 09/07/11 16:54, Howard Hinnant wrote: > For those interested in libc++ issues, I'd like to draw your attention to: > > http://llvm.org/bugs/show_bug.cgi?id=10314 > > and request comments on the issue. Exactly how to handle reference types in these containers has been a blight on the standard for a long time. I think it would be unwise to further muddy the waters. Deviating from the standard in these corner cases is exactly the sort of thing that comes back to bite you later. If other popular standard library implementations made the same change then that might be reason enough to do it, but glancing at libstdc++, it seems that uses the standard definitions. John Bytheway From peter at 2ndquadrant.com Sat Jul 9 12:45:27 2011 From: peter at 2ndquadrant.com (Peter Geoghegan) Date: Sat, 9 Jul 2011 18:45:27 +0100 Subject: [cfe-dev] Error when building Clang from SVN tip on Linux In-Reply-To: References: Message-ID: Hi Chris, On 9 July 2011 17:30, Chris Lattner wrote: > Make sure to keep llvm and clang in synch with each other. ?This looks like you updated clang but not llvm. It appears you were right. Thank you. -- Peter Geoghegan ? ? ? http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services From niebuhr at niebuhrt.de Sat Jul 9 14:29:36 2011 From: niebuhr at niebuhrt.de (Toralf Niebuhr) Date: Sat, 9 Jul 2011 21:29:36 +0200 Subject: [cfe-dev] trivial libc++ patch Message-ID: <8520D83C-3BF6-498D-A1BD-766A469D97EF@niebuhrt.de> Hi, This is just a tiny patch fixing some small (probably copy & paste) errors. Toralf Niebuhr -------------- next part -------------- A non-text attachment was scrubbed... Name: libcxx.diff Type: application/octet-stream Size: 935 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110709/be1c9d67/attachment.obj From eli.friedman at gmail.com Sat Jul 9 15:59:51 2011 From: eli.friedman at gmail.com (Eli Friedman) Date: Sat, 9 Jul 2011 13:59:51 -0700 Subject: [cfe-dev] clang build error In-Reply-To: References: Message-ID: On Fri, Jul 8, 2011 at 4:53 PM, Loganathan L. wrote: > Hi, > While building clang and llvm, I get the following error: > llvm[4]: Compiling HeaderSearch.cpp for Debug+Asserts build > llvm[4]: Compiling Lexer.cpp for Debug+Asserts build > In file included from > /usr/pkgs/gcc/3.4.2/lib/gcc/x86_64-suse-linux/3.4.2/include/emmintrin.h:34, > ? ? ? ? ? ? ? ? ?from /nfs/user/Clang/llvm/tools/clang/lib/Lex/Lexer.cpp:16 > 41: > /usr/pkgs/gcc/3.4.2/lib/gcc/x86_64-suse-linux/3.4.2/include/xmmintrin.h: In > function `float __vector__ _mm_set_ps(float, float, float, float)': > /usr/pkgs/gcc/3.4.2/lib/gcc/x86_64-suse-linux/3.4.2/include/xmmintrin.h:894: > error: ISO C++ forbids com pound-literals > In file included from /nfs/user/Clang/llvm/tools/clang/lib/Lex/Lexer.cpp:16 > 41: > /usr/pkgs/gcc/3.4.2/lib/gcc/x86_64-suse-linux/3.4.2/include/emmintrin.h: In > function `double __vector__ ?_mm_set_pd(double, double)': > /usr/pkgs/gcc/3.4.2/lib/gcc/x86_64-suse-linux/3.4.2/include/emmintrin.h:118: > error: ISO C++ forbids com pound-literals > I just did a ./configure before calling make. There was an earlier post > indicating that clang comes with it own library. Is there a configure option > to use this library instead? > Thanks, > Loganathan That looks like your system compiler is broken. Try a newer gcc version. -Eli From thakis at chromium.org Sat Jul 9 19:34:48 2011 From: thakis at chromium.org (Nico Weber) Date: Sat, 9 Jul 2011 17:34:48 -0700 Subject: [cfe-dev] Using clang as production compiler for chrome/mac Message-ID: Hi, we're currently using clang for its diagnostics in chromium land, but we'd like to use it to build our shipping binary in the future too. One thing we're wondering about is which clang version to use for this. Currently, we're pulling a fixed revision from the llvm svn server and I update that revision about once a week. One of the alternatives is to use trunk for our shipping binaries as well. Chromium has three different channels ? dev, beta, stable ? and we could use trunk for the dev channel and then branch clang with the rest of our source for the beta and stable channels and only merge "important" clang/llvm changes to there. Shipping a product that's built with a potentially unstable compiler sounds a bit risky, so why haven't I discarded this alternative already? I imagine that it might be useful for the clang project, since we have quite a bit of monitoring in chromium land (automated perf graphs, compile time graphs, crash reporting that $many users have opted in to), so that we could find and report regressions in clang reasonably quickly. Do you think this is interesting at all? Nico From chandlerc at google.com Sun Jul 10 04:41:34 2011 From: chandlerc at google.com (Chandler Carruth) Date: Sun, 10 Jul 2011 02:41:34 -0700 Subject: [cfe-dev] Switching terminology from 'instantiation' to 'expansion' for macros? In-Reply-To: <322B0A16-CD9E-4525-A315-42E7492BBD8A@apple.com> References: <4E167D52.8000509@cse.tamu.edu> <14CE0BFF-5D16-4517-8514-83E9A6014CCC@apple.com> <322B0A16-CD9E-4525-A315-42E7492BBD8A@apple.com> Message-ID: On Fri, Jul 8, 2011 at 10:24 AM, Argyrios Kyrtzidis wrote: > On Jul 8, 2011, at 10:03 AM, Chandler Carruth wrote: > > On Fri, Jul 8, 2011 at 8:16 AM, Douglas Gregor wrote: > >> Agreed on all points. > > > Thoughts on my second question (that of the names used in the actual code > of Clang)? I'll start on fixing the diagnostics based on this plan today. > > > I like the whole proposal, and having the name change reflected in clang > source code would be ideal, thanks for your work! > Cool, here is the first patch which just changes the word in the diagnostics (none of the fancy new diagnostics I'd like to get to yet...) and the first 4 patches in moving the code over. This moves essentially all of the code local to the preprocessor and the diagnostic printer over. How is this looking? Can I rely on post-commit review for the rest of the terminology switch? That would be really useful as several of those are going to be massive, but entirely mechanical patches (SourceManager cleanup... ugh...). Do we want to add the new terms to libclang's C interface? (they're currently only used for the names of enums, so we should be able to leave the old names in with the same value for compatibility) Finally, the change to introduce the more detailed note diagnostic text will require a bit of re-working the infrastructure in TextDiagnosticPrinter. I'd like to generally refactor how some of that file is implemented. Can I just commit those refactorings, and then the changes to implement the new functionality, or would you like pre-commit review there? (I'm fine either way, just trying to plan out my work.) Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110710/0ed51755/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-switch-diagnostic-messages.patch Type: application/octet-stream Size: 8599 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110710/0ed51755/attachment-0005.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-switch-test-diagnostic-printer.patch Type: application/octet-stream Size: 5163 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110710/0ed51755/attachment-0006.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-switch-token-lexer.patch Type: application/octet-stream Size: 9788 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110710/0ed51755/attachment-0007.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-switch-lexer.patch Type: application/octet-stream Size: 13519 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110710/0ed51755/attachment-0008.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-switch-lex.patch Type: application/octet-stream Size: 24507 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110710/0ed51755/attachment-0009.obj From t_guen03 at uni-muenster.de Sun Jul 10 11:16:55 2011 From: t_guen03 at uni-muenster.de (Tobias Guennewig) Date: Sun, 10 Jul 2011 18:16:55 +0200 Subject: [cfe-dev] Result Type of a Template Function In-Reply-To: <23305472-36A2-41EF-9E4E-0F518CB7A8BC@gmail.com> References: <5E4C8A20-2A3D-4B88-83CA-DC0615252777@gmail.com> <89ABDCA1-EDFD-47D5-A2F1-0EA852FB7846@apple.com> <23305472-36A2-41EF-9E4E-0F518CB7A8BC@gmail.com> Message-ID: <1310314615.2861.8.camel@tobias> Hi, i wonder if there is a way to retrieve the return type of a template function. The function clang_getResultType works for cursors, whose 'kind' property is CXCursor_FunctionDecl. For a CXCursor_FunctionTemplate it says, 'CXType_Invalid'. Can someone tell me the reason for this behavior? Thanks, Tobias From craig.topper at gmail.com Sun Jul 10 15:46:17 2011 From: craig.topper at gmail.com (Craig Topper) Date: Sun, 10 Jul 2011 13:46:17 -0700 Subject: [cfe-dev] [Review request] C++0x unicode string and character literals Message-ID: This patch adds support for string and character literals. It still treats the source file as ASCII like the original code did. Some of the warnings and error messages probably need to be adjusted to not say "wide" for the new types. I also need to add some tests. -- ~Craig -------------- next part -------------- A non-text attachment was scrubbed... Name: newest_unicode_strings.patch Type: application/octet-stream Size: 59816 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110710/5e311e64/attachment-0001.obj From sebastian.redl at getdesigned.at Mon Jul 11 02:59:43 2011 From: sebastian.redl at getdesigned.at (Sebastian Redl) Date: Mon, 11 Jul 2011 09:59:43 +0200 Subject: [cfe-dev] ::delete behaves differently in clang and gcc when class has a virtual destructor In-Reply-To: <4E139DB0.8000201@oblong.com> References: <4E139DB0.8000201@oblong.com> Message-ID: <4E1AAD6F.1010109@getdesigned.at> On 06.07.2011 01:26, Patrick Pelletier wrote: > First of all, here are the assumptions I'm starting with: > > a) the "delete" expression calls the object's destructor, followed by > calling "operator delete" on the object > > b) "::delete" is the same as "delete", except that instead of calling > "operator delete", it calls "::operator delete" > > If these assumptions are correct, then in the program below, I would > expect case 1 to call Foo's operator delete, but I would not expect case > 2 or case 3 to call Foo's operator delete. (Indeed, based on my > assumptions above, I would expect case 2 and case 3 to be identical; my > belief is that case 3 is just a manual de-sugaring of case 2.) Exception handling is different in case 2 than 3, and null pointers are treated differently, but for the simple case, that's correct. > When compiled with gcc, the program below behaves as I would expect. > However, when compiled with clang, the program as written (i. e. with > the virtual destructor) does not behave as I expect, in that Foo's > operator delete is called in case 2. (Although still not in case 3.) > > The presence of the virtual destructor is important. If I simply remove > the word "virtual" from the declaration of ~Foo(), then the program > behaves identically in clang and gcc, and both are what I expect. (i. > e. case 1 is the only case that calls Foo's operator delete.) > > Thanks for any light you can shed on this behavior, and my apologies if > this is indeed expected behavior that I am unaware of. No, I believe you found a genuine bug. Please file it. Sebastian From csdavec at swan.ac.uk Mon Jul 11 06:05:29 2011 From: csdavec at swan.ac.uk (David Chisnall) Date: Mon, 11 Jul 2011 12:05:29 +0100 Subject: [cfe-dev] Lookahead vs. Tentative Parsing In-Reply-To: <3C599427-1D02-4B30-8C0C-2FE7B5C21DB2@apple.com> References: <4E13DCFC.7090808@cse.tamu.edu> <529C63F2-8F2E-463E-A693-0120092D8A13@apple.com> <3C599427-1D02-4B30-8C0C-2FE7B5C21DB2@apple.com> Message-ID: <2AB7E1BD-29C8-447F-B947-52B3B6084E65@swan.ac.uk> On 6 Jul 2011, at 06:33, Chris Lattner wrote: > We even support the new ARC Objective-C feature in all modes as well, meaning that folks can write code in Objective-ARC++'0x if they so choose. I've been playing with this over the weekend. Many thanks to everyone who worked on it. Being able to put Objective-C objects in C++ collections and have memory management (even with weak references) Just Work? is amazing! It's probably going to let me delete about a thousand lines of code. David From echristo at apple.com Mon Jul 11 11:11:47 2011 From: echristo at apple.com (Eric Christopher) Date: Mon, 11 Jul 2011 09:11:47 -0700 Subject: [cfe-dev] Using clang as production compiler for chrome/mac In-Reply-To: References: Message-ID: <8D720D4E-1F0D-4A02-8D3C-27A3B6A43075@apple.com> On Jul 9, 2011, at 5:34 PM, Nico Weber wrote: > I imagine that it might be useful for the clang project, since we have > quite a bit of monitoring in chromium land (automated perf graphs, > compile time graphs, crash reporting that $many users have opted in > to), so that we could find and report regressions in clang reasonably > quickly. Do you think this is interesting at all? I do think this is interesting. It shouldn't be too bad since one of the goals we have for clang is to keep it roughly shippable at all times on ToT. -eric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110711/45d8c248/attachment.html From dgregor at apple.com Mon Jul 11 15:08:05 2011 From: dgregor at apple.com (Douglas Gregor) Date: Mon, 11 Jul 2011 13:08:05 -0700 Subject: [cfe-dev] Switching terminology from 'instantiation' to 'expansion' for macros? In-Reply-To: References: <4E167D52.8000509@cse.tamu.edu> <14CE0BFF-5D16-4517-8514-83E9A6014CCC@apple.com> Message-ID: <75196723-9A5B-4DB7-B20F-415CF214FF20@apple.com> On Jul 8, 2011, at 10:03 AM, Chandler Carruth wrote: > On Fri, Jul 8, 2011 at 8:16 AM, Douglas Gregor wrote: > Agreed on all points. > > Thoughts on my second question (that of the names used in the actual code of Clang)? I'll start on fixing the diagnostics based on this plan today. Yes, it makes sense to update the names used in Clang's code as well as the diagnostics. Thanks for doing this! - Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110711/f3087f67/attachment.html From scshunt at csclub.uwaterloo.ca Mon Jul 11 15:22:16 2011 From: scshunt at csclub.uwaterloo.ca (Sean Hunt) Date: Mon, 11 Jul 2011 13:22:16 -0700 Subject: [cfe-dev] trivial libc++ patch In-Reply-To: <8520D83C-3BF6-498D-A1BD-766A469D97EF@niebuhrt.de> References: <8520D83C-3BF6-498D-A1BD-766A469D97EF@niebuhrt.de> Message-ID: <4E1B5B78.30401@csclub.uwaterloo.ca> On 07/09/11 12:29, Toralf Niebuhr wrote: > Hi, > > This is just a tiny patch fixing some small (probably copy& paste) errors. > > Toralf Niebuhr Thanks! Cross-platform includes always wreak havoc on code testing. Sean From dgregor at apple.com Mon Jul 11 16:00:15 2011 From: dgregor at apple.com (Douglas Gregor) Date: Mon, 11 Jul 2011 14:00:15 -0700 Subject: [cfe-dev] Switching terminology from 'instantiation' to 'expansion' for macros? In-Reply-To: References: <4E167D52.8000509@cse.tamu.edu> <14CE0BFF-5D16-4517-8514-83E9A6014CCC@apple.com> <322B0A16-CD9E-4525-A315-42E7492BBD8A@apple.com> Message-ID: <863CE7BE-5E81-4763-A820-798E3F6E30B9@apple.com> On Jul 10, 2011, at 2:41 AM, Chandler Carruth wrote: > On Fri, Jul 8, 2011 at 10:24 AM, Argyrios Kyrtzidis wrote: > On Jul 8, 2011, at 10:03 AM, Chandler Carruth wrote: > >> On Fri, Jul 8, 2011 at 8:16 AM, Douglas Gregor wrote: >> Agreed on all points. >> >> Thoughts on my second question (that of the names used in the actual code of Clang)? I'll start on fixing the diagnostics based on this plan today. > > I like the whole proposal, and having the name change reflected in clang source code would be ideal, thanks for your work! > > Cool, here is the first patch which just changes the word in the diagnostics (none of the fancy new diagnostics I'd like to get to yet...) and the first 4 patches in moving the code over. This moves essentially all of the code local to the preprocessor and the diagnostic printer over. How is this looking? They all look good to me. > Can I rely on post-commit review for the rest of the terminology switch? That would be really useful as several of those are going to be massive, but entirely mechanical patches (SourceManager cleanup... ugh?). Yes, post-commit review is fine. > Do we want to add the new terms to libclang's C interface? (they're currently only used for the names of enums, so we should be able to leave the old names in with the same value for compatibility) Yes, it makes sense to add these new terms to libclang's C interface, so long as we keep the old ones in place. > Finally, the change to introduce the more detailed note diagnostic text will require a bit of re-working the infrastructure in TextDiagnosticPrinter. I'd like to generally refactor how some of that file is implemented. Can I just commit those refactorings, and then the changes to implement the new functionality, or would you like pre-commit review there? (I'm fine either way, just trying to plan out my work.) Refactoring in TextDiagnosticPrinter seems like something that can be post-commit reviewed. - Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110711/4e6e48aa/attachment.html From dgregor at apple.com Mon Jul 11 16:02:46 2011 From: dgregor at apple.com (Douglas Gregor) Date: Mon, 11 Jul 2011 14:02:46 -0700 Subject: [cfe-dev] How to ouput the AST of the instantiated function template In-Reply-To: References: Message-ID: On Jul 8, 2011, at 8:38 AM, Xiaolong Tang wrote: > > Hi all, > > I am interested to check the AST of the instantiated template > function. Is there a way to do so? Not from the command line. In a debugger, you can of course dump() the instantiated declaration. - Doug From anton.yartsev at gmail.com Mon Jul 11 16:22:21 2011 From: anton.yartsev at gmail.com (Anton Yartsev) Date: Tue, 12 Jul 2011 01:22:21 +0400 Subject: [cfe-dev] aligned 'new' In-Reply-To: <4E03EBCB.8090905@Gmail.com> References: <4DE313C8.6070303@Gmail.com> <2606C766-FBC5-462E-AD16-5FE67BC28549@apple.com> <4E03EBCB.8090905@Gmail.com> Message-ID: <4E1B698D.2070701@Gmail.com> On 24.06.2011 5:43, Anton Yartsev wrote: > On 30.05.2011 8:35, Chris Lattner wrote: >> On May 29, 2011, at 8:49 PM, Anton Yartsev wrote: >> >>> Hi all, >>> >>> I am thinking of the ability of operator new to return memory aligned >>> according to the alignment of the type passed to it (at least of >>> AltiVec >>> vector types whose proper alignment is essential). >>> The proposed implementation is: >>> 1) clang: add -fstrict-aligned option. When the option is set it cause >>> clang to define the built-in macro "__STRICT_ALIGNED" >>> 2) libcxx: add additional placement new declarations to >>> libcxx\include\new with the additional argument - alignment. Make this >>> declarations conditionalized on the "__STRICT_ALIGNED". Add new >>> definitions to libcxx\src\new.cpp. >>> 3) clang: if -fstrict-aligned option is set, when clang sees a new of a >>> type which either has an inherent alignment, or has an explicit >>> alignment specified by __attribute__((__aligned__(x))), it will >>> transform the standard new call to a call to the aligned version of >>> new. >>> >>> Am i on the right way? Any thoughts? >> I don't think that this is the right way to go. Instead, you'd want >> "new foo" to automatically detect that the alignment of "foo" is >> greater than the alignment guaranteed by the system malloc. In this >> case, and if using the default operator new, you'd generate a call to >> memalign instead of to operator new (something like that). >> >> It isn't clear to me how generally useful this is though, and we tend >> to avoid adding tons of language extensions to Clang. >> >> -Chris > Attached is the the patch that substitutes calls to default new > operators with calls to functions - aligned analogs of default new > operators. This functions may live in the clang's mm_malloc.h header > where aligned malloc lives. The patch is partial, it does not affect > deletes and do not contain substituting functions yet. Please review > and direct! > Ping! -- Anton From dgregor at apple.com Mon Jul 11 16:48:54 2011 From: dgregor at apple.com (Douglas Gregor) Date: Mon, 11 Jul 2011 14:48:54 -0700 Subject: [cfe-dev] Back to work: attributes In-Reply-To: <4E159619.8050303@tu-dresden.de> References: <4E159619.8050303@tu-dresden.de> Message-ID: <33EAEA98-7E5B-411A-905A-656947A68528@apple.com> On Jul 7, 2011, at 4:18 AM, Olaf Krzikalla wrote: > Hi @clang, > > it's been a while that we discussed the implementation of attributes. > Since Sean didn't chime I guess he doesn't work on attributes anymore. > Now hopefully I've found the week I've planned to need to get that stuff on the right track. But before I start there are a lot of questions and issues to clarify. > > 1. How resilient ought to be the PCH serialization? Suppose a user-defined attribute that is supported by a particular plugin. The interesting cases are when the plugin is loaded only either during PCH generation or usage. Currently attributes are serialized by their actual semantic properties. But a more resilient implementation would just store a (simplified) token stream and regenerate the attributes from that stream during PCH loading. This approach has the additional benefit that user-defined attributes don't need to define serialization functions. A simplified token stream feels like overkill for user-defined attributes. The bitcode format can already handle variable-length records of arbitrary data, so if we serialize user-defined attributes the same way as we currently serialize built-in attributes (albeit with some more general attribute naming scheme), that will be sufficient to skip any unrecognized attributes. > 2. What is the point of InheritableAttr? The Inherited property is already in Attr, we could also stream it for every attr (e.g. by bit-masking it with Attr::Kind). On the other hand it seems to be used only with DLLImportAttr, so actually we could also remove InheritableAttr altogether (and move the property to DLLImportAttr). Attributes that are inheritable (i.e., derive from InheritableAttr) are automatically merged from a prior declaration of an entity to a later declaration; see SemaDecl.cpp's mergeDeclAttributes(). The Inherited property says whether that instance of the attribute was inherited from a previous declaration (rather than being written directly in the source). > 3. Just btw: If I haven't overlooked something, then openmp pragmas are still a TODO. It would be interesting to see them working in clang because in the end they have to solve the same problem that I actually have (and that is the root for my efforts on attributes): parse an expression inside a pragma. What are the plans regarding openmp? There are no plans for OpenMP per se, and I don't know of anyone else working on OpenMP support. - Doug From supertri at google.com Mon Jul 11 18:19:30 2011 From: supertri at google.com (Caitlin Sadowski) Date: Mon, 11 Jul 2011 16:19:30 -0700 Subject: [cfe-dev] Proposal for thread safety attributes for Clang In-Reply-To: <4E0EE3B7.7020103@mail1.stofanet.dk> References: <4E0EE3B7.7020103@mail1.stofanet.dk> Message-ID: Bjorn, There are many reasons why not to use templates for a similar thread safety analysis. These issues include the fact that templates can complicate the program, but may not be able to handle more complicated locking scenarios. Given a particular locking strategy, the use of templates forces the specification of that strategy to be closely tied to the implementation details. If we wished to change how locking works in a piece of code, the template system may not easily support the new mechanism. Also, templates do not work for C code. The attribute-based system provides an extensible way of supporting future work, such as running more advanced analyses with the static analyzer framework, new types of annotations that may be difficult to implement with templates (such as cooperability yield points [1, 2]), and?annotation inference. We have some evidence that this approach works well: we previously implemented this proposal in GCC, and the use of attributes allowed us to annotate large parts of Google's pre-existing codebase without having to rearchitect it. Cheers, Caitlin [1] Effects for Cooperable and Serializable Threads. Jaeheon Yi and Cormac Flanagan. Workshop on types in Language Design and Implementation (TLDI) 2010. [2]?Applying Usability Studies to Correctness Conditions: A Case Study of Cooperability.?Caitlin Sadowski?and?Jaeheon Yi. Onward! Workshop on Evaluation and Usability of Programming Languages and Tools (PLATEAU), 2010. On Sat, Jul 2, 2011 at 2:24 AM, Bjorn Reese wrote: > > Caitlin. > > The two problems you address can be handled with templates instead of > annotations. While the techniques mentioned below do not solve all > thread-safety problems, they do solve the most common ones that I have > encountered. And none of them requires extensions to the compiler. > > ACQUIRED_AFTER: Some deadlocks occur because you need to lock two > mutexes, A and B, and you accidentially lock A before B in one function > and B before A in another function. Such deadlocks can be avoided with > the Boost.Thread locking functions [1], as it guarantees that a list of > mutexes always is locked in the same order, regardless of the order you > list them. > > GUARDED_BY: It is true that the C++ compiler does not know which mutex > guards what variables, and therefore cannot alert you if you, say, use > a variable without locking its mutex. I solved this problem in a > commercial project by defining two templates: a guard and an accessor. > The guard contained the mutex and the variable (or struct of > variables) as a private member, and only the accessor could access it. > The accessor would lock and unlock the mutex in a RAII manner. An > example using this technique could look like this: > > ?class Alpha > ?{ > ?public: > ? ?int GetValue() const > ? ?{ > ? ? ?const_unique_access value(valueGuard); > ? ? ?return *value; > ? ?} > ? ?void SetValue(int v) > ? ?{ > ? ? ?unique_access value(valueGuard); > ? ? ?*value = v; > ? ?} > ?private: > ? ?unique_access_guard valueGuard; > ?}; > > This solution shares some traits with Anthony Williams' Synchronized > Values [2]. > > [1] http://www.boost.org/doc/libs/1_46_1/doc/html/thread/synchronization.html#thread.synchronization.lock_functions > [2] http://drdobbs.com/cpp/225200269 From jediknil at belkadan.com Tue Jul 12 02:06:39 2011 From: jediknil at belkadan.com (Jordy Rose) Date: Tue, 12 Jul 2011 00:06:39 -0700 Subject: [cfe-dev] Removing "TransferFuncs" from the analyzer In-Reply-To: References: Message-ID: Looking at this some more, it seems the only information the function summaries provide that aren't also available through RefVals are: 1. Treating [object dealloc] differently from [object release]. This could be replaced by examining the current ExplodedNode's Stmt every time we hit a Released RefVal, or by adding a ReleasedByDeallocation RefVal::Kind. Or we could ignore it since it is so rare in Cocoa code. (I suppose non-Cocoa code doesn't have to be ref-counted for the RetainReleaseChecker to catch alloc/dealloc balances.) 2. Noting that (NS|CF)MakeCollectable is ignored in non-GC mode. This is definitely nice QoI-wise but isn't (IMHO) a critical part of the bug report's usefulness. 3. Noting that -autorelease, -retain, and -release are ignored in GC mode. Same as above. Noting that X is ignored is something that's a little annoying to do while trying to keep GRState explosion down. My initial thought was to add a counter to RefVal for these messages, but that would mean that something like this would create two states after the branch is done (i.e. no uniquing the states). id object = getObject(); if (arbitraryCondition()) { [object retain]; doSomethingWith(object); [object release]; } Another possibility is a simple single-bit toggle; that way any ignored messages will still show up as a change in the state of the referred variable, and only branches with an odd number of ignored messages will result in distinct GRStates. This feels like more of a hack, but it costs less in memory (it could even be combined in a bitfield with the object kind). With either way of forcing a change, we'd then examine the current ExplodedNode's statement to see what was wrong. I'm going to start working on this soon, using the bit toggle for the ignored messages, and try to come up with orthogonal patches that chip away at TransferFuncs and CFRefCount! Jordy On Jun 27, 2011, at 19:35, Jordy Rose wrote: > Hi Ted and cfe-dev. In my free time I've been looking into the issue of "transfer functions" in the analyzer ? a supposedly swappable implementation of logic for evaluating function calls and Objective-C messages, among other things. As the Checker infrastructure has grown, almost all of the once-unique transfer function logic can now be implemented using essentially-pluggable Checkers. > > That wouldn't be such a problem, except that in reality the implementation of TransferFuncs in the analyzer is CFRefCount, which mixes in a whole bunch of logic for tracking retain counts and Cocoa conventions. We shouldn't need to run that with every run of the analyzer (though most of the code will early-exit when it realizes it's not relevant). Some of the code has already been extracted to a class called RetainReleaseChecker, but at this point we can do a lot more. > > This e-mail is recording my thoughts on this and how far I got; it's not intended as an immediate call to action. > > In fact, the behavior of a hypothetical SimpleTransferFuncs only includes this: > - Invalidating ivars of ObjC message receiver > - Invalidating ivars of 'this' for C++ method call > - Invalidating function/method args > - Invalidating globals if necessary > - Conjuring return values > > And these effects only happen if no checker claims "evalCall" for a given function call. > > > On the other hand, a fully-fledged RetainReleaseChecker with all existing functionality isn't quite possible because of four things: > > - CFBugReports use function call summaries to show the retain/release history of a leaked object. Function summaries are currently associated with ExplodedNodes in a DenseMap. In addition to being somewhat inefficient (summaries for calls that have nothing to do with ref-counting are also saved), Checkers are const, and so can't store summaries in a mutable data structure. (Marking the map 'mutable' doesn't feel like the right solution.) I don't have a solution for this. > > - There's no evalObjCMessage, for the very sensible reason that overriding a method can make its behavior totally different. Nevertheless, there are a few messages we /do/ want to model in a RetainReleaseChecker: -[NSAutoreleasePool init], -[NSAutoreleasePool addObject:], -retain, -release, and -autorelease. Fortunately, pretty much everything else would fit in a PostObjCMessage implementation. > > - When function/method arguments are invalidated, their reference counts persist. But any other sort of invalidation does destroy reference count records. Currently this uses a whitelist built before invalidating the various regions referenced in a call, but with no special consideration given to RetainReleaseChecker, that'd be a little strange. I can think of two ways around this: reconstruct the whitelist on every region invalidation if we're in a function call (probably not a good idea) and reconstruct the reference bindings in a post-call check (by walking backwards through ExplodedNodes to the pre-call state). > > - CFRefCount currently registers a GRState::Printer for printing the retain count info in a state. Checkers currently have no way to register printers for custom state info, and that should probably be fixed anyway. > > Everything else that CFRefCount currently does can be done using the current Checker architecture. (For more detailed but less structured notes on this, see attached .) > > > As for what I /did/ accomplish, evalBind and evalAssume can be migrated to RetainReleaseChecker almost without changes: > > Everything /other/ than evalCall, evalObjCMessage, and evalSummary can be moved to RetainReleaseChecker, but that leaves plenty of hackery behind: > > > I'm going to stop this work here...it's where it crosses the line from "simple migration" to "design decisions". Once the four issues above are resolved, it should actually be pretty straightforward to eliminate TransferFuncs and CFRefCount from the analyzer and make RetainReleaseChecker optional. Which would be great, right? > > Jordy From peter at 2ndquadrant.com Tue Jul 12 09:46:06 2011 From: peter at 2ndquadrant.com (Peter Geoghegan) Date: Tue, 12 Jul 2011 15:46:06 +0100 Subject: [cfe-dev] -Warray-bounds seems over-zealous on Clang Message-ID: Hello, Consider the common idiom in C, of a struct with its last declared type is an array like this: typedef struct { int id; int values[1]; } my_struct; This will be stored in dynamically allocated memory. Memory will be allocated for my_struct, in addition to however many additional integers must be stored. Despite how frequently this is seen, Clang doesn't seem to like this. In particular, it over-zealously complains about assigning past the end of "values" when that can be statically determined (because an int rvalue is used), when the -Warray flag is given. GCC, on the other hand, does not. This is of particular concern when hacking on the PostgreSQL code, that makes extensive use of this idiom: /home/peter/build/Release/bin/clang -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wformat-security -fno-strict-aliasing -fwrapv -I../../../src/include -D_GNU_SOURCE -c -o namespace.o namespace.c namespace.c:1497:29: warning: array index of '1' indexes past the end of an array (that contains 1 elements) [-Warray-bounds] operform->oprright == resultList->args[1]) ^ ~ ../../../src/include/catalog/namespace.h:37:2: note: array 'args' declared here Oid args[1]; /* arg types --- VARIABLE LENGTH ARRAY */ ^ namespace.c:1509:30: warning: array index of '1' indexes past the end of an array (that contains 1 elements) [-Warray-bounds] operform->oprright == prevResult->args[1]) ^ ~ ../../../src/include/catalog/namespace.h:37:2: note: array 'args' declared here Oid args[1]; /* arg types --- VARIABLE LENGTH ARRAY */ ^ namespace.c:1540:3: warning: array index of '1' indexes past the end of an array (that contains 1 elements) [-Warray-bounds] newResult->args[1] = operform->oprright; ^ ~ ../../../src/include/catalog/namespace.h:37:2: note: array 'args' declared here Oid args[1]; /* arg types --- VARIABLE LENGTH ARRAY */ ^ This seems like a bug to me. What's the consensus view on this? -- Peter Geoghegan ? ? ? http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services From dgregor at apple.com Tue Jul 12 10:02:45 2011 From: dgregor at apple.com (Douglas Gregor) Date: Tue, 12 Jul 2011 08:02:45 -0700 Subject: [cfe-dev] -Warray-bounds seems over-zealous on Clang In-Reply-To: References: Message-ID: <6B3BE5B0-D03A-4B68-A973-D8C249E833A4@apple.com> On Jul 12, 2011, at 7:46 AM, Peter Geoghegan wrote: > Hello, > > Consider the common idiom in C, of a struct with its last declared > type is an array like this: > > typedef struct > { > int id; > int values[1]; > } my_struct; > > This will be stored in dynamically allocated memory. Memory will be > allocated for my_struct, in addition to however many additional > integers must be stored. Despite how frequently this is seen, Clang > doesn't seem to like this. In particular, it over-zealously complains > about assigning past the end of "values" when that can be statically > determined (because an int rvalue is used), when the -Warray flag is > given. GCC, on the other hand, does not. This is of particular concern > when hacking on the PostgreSQL code, that makes extensive use of this > idiom: > > /home/peter/build/Release/bin/clang -O2 -Wall -Wmissing-prototypes > -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels > -Wformat-security -fno-strict-aliasing -fwrapv -I../../../src/include > -D_GNU_SOURCE -c -o namespace.o namespace.c > namespace.c:1497:29: warning: array index of '1' indexes past the end > of an array (that contains 1 elements) [-Warray-bounds] > operform->oprright == > resultList->args[1]) > > ^ ~ > ../../../src/include/catalog/namespace.h:37:2: note: array 'args' declared here > Oid args[1]; /* arg types > --- VARIABLE LENGTH ARRAY */ > ^ > namespace.c:1509:30: warning: array index of '1' indexes past the end > of an array (that contains 1 elements) [-Warray-bounds] > > operform->oprright == prevResult->args[1]) > > ^ ~ > ../../../src/include/catalog/namespace.h:37:2: note: array 'args' declared here > Oid args[1]; /* arg types > --- VARIABLE LENGTH ARRAY */ > ^ > namespace.c:1540:3: warning: array index of '1' indexes past the end > of an array (that contains 1 elements) [-Warray-bounds] > newResult->args[1] = operform->oprright; > ^ ~ > ../../../src/include/catalog/namespace.h:37:2: note: array 'args' declared here > Oid args[1]; /* arg types > --- VARIABLE LENGTH ARRAY */ > ^ > > This seems like a bug to me. What's the consensus view on this? I suggest using a C99 flexible array member, e.g., > typedef struct > { > int id; > int values[]; > } my_struct; which is designed for specifically this use case. - Doug From joerg at britannica.bec.de Tue Jul 12 10:07:48 2011 From: joerg at britannica.bec.de (Joerg Sonnenberger) Date: Tue, 12 Jul 2011 17:07:48 +0200 Subject: [cfe-dev] -Warray-bounds seems over-zealous on Clang In-Reply-To: References: Message-ID: <20110712150748.GA4913@britannica.bec.de> On Tue, Jul 12, 2011 at 03:46:06PM +0100, Peter Geoghegan wrote: > Consider the common idiom in C, of a struct with its last declared > type is an array like this: > > typedef struct > { > int id; > int values[1]; > } my_struct; C99 explicitly allows declaring values without a size for cases like this. E.g. use typedef struct { int id; int values[]; } my_struct; I consider this warning completely acceptable and correct, even if it takes a bit to clean up old source code. Joerg From jfreeman at cse.tamu.edu Tue Jul 12 10:13:58 2011 From: jfreeman at cse.tamu.edu (John Freeman) Date: Tue, 12 Jul 2011 10:13:58 -0500 Subject: [cfe-dev] Disambiguating C++ Lambdas and Objective-C Messages Message-ID: <4E1C64B6.8020103@cse.tamu.edu> Howdy Doug, Based on recommendations, I'm looking at the following decision tree after seeing a '['. if lang = C++ if lang = Objective-C if lookahead indicates lambda parse_lambda else if lookahead indicates message parse_message else allocate lambda capture list if tentative parse of lambda successful finish_parse_lambda(list) else parse_message else parse_lambda else if lang = Objective-C parse_message else error The parse_lambda and finish_parse_lambda functions will need to be different, although the first function could call the second. Is it too much? Should I try something simpler? Should I try an alternative structure, like this: if lang = C++ && lang != Objective-C parse_lambda else if lang != C++ && lang = Objective-C parse_message else if lang = C++ && lang = Objective-C if lookahead indicates lambda parse_lambda else if lookahead indicates message parse_message else allocate lambda capture list if tentative parse of lambda successful finish_parse_lambda(list) else parse_message else error Should I wrap the lookahead and the tentative parsing into a single TryParse* function? Perhaps it could return a valid but unusable ExprResult upon parsing a lambda with unrecoverable errors, and an invalid ExprResult when lookahead or tentative parsing indicated a message. If that does not fit within the convention for invalid/usable, could you please explain it? - John From peter at 2ndquadrant.com Tue Jul 12 10:54:05 2011 From: peter at 2ndquadrant.com (Peter Geoghegan) Date: Tue, 12 Jul 2011 16:54:05 +0100 Subject: [cfe-dev] -Warray-bounds seems over-zealous on Clang In-Reply-To: <20110712150748.GA4913@britannica.bec.de> References: <20110712150748.GA4913@britannica.bec.de> Message-ID: Saying "just use C99" isn't a practical solution. This is a mature project with a large codebase, that targets many compilers, including, for a large number of reasons, Visual Studio - Microsoft have absolutely no interest in pursuing C99 support. Besides, the chances of Clang actually helpfully diagnosing a problem with the delta between how GCC does -Warray-bounds and how Clang does it are slim - how often are these problems statically detectable? This is C. Even if your position wasn't unreasonable, which it is, Clang still gives this warning when the -c89 flag is given. -- Peter Geoghegan ? ? ? http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services From joerg at britannica.bec.de Tue Jul 12 11:45:06 2011 From: joerg at britannica.bec.de (Joerg Sonnenberger) Date: Tue, 12 Jul 2011 18:45:06 +0200 Subject: [cfe-dev] -Warray-bounds seems over-zealous on Clang In-Reply-To: References: <20110712150748.GA4913@britannica.bec.de> Message-ID: <20110712164506.GA9713@britannica.bec.de> On Tue, Jul 12, 2011 at 04:54:05PM +0100, Peter Geoghegan wrote: > Saying "just use C99" isn't a practical solution. This is a mature > project with a large codebase, that targets many compilers, including, > for a large number of reasons, Visual Studio - Microsoft have > absolutely no interest in pursuing C99 support. Then disable the warning. It's an option for a reason. > Besides, the chances of Clang actually helpfully diagnosing a problem > with the delta between how GCC does -Warray-bounds and how Clang does > it are slim - how often are these problems statically detectable? This > is C. I know at least one bug found with handling of [1] sized arrays and GCC 4.5 warned about that too. > Even if your position wasn't unreasonable, which it is, Clang still > gives this warning when the -c89 flag is given. Just because you don't agree doesn't make it unreasonable. The behavior of the code doesn't change with the standard level -- you are still declaring an array and overflowing it. Joerg From dgregor at apple.com Tue Jul 12 11:50:40 2011 From: dgregor at apple.com (Douglas Gregor) Date: Tue, 12 Jul 2011 09:50:40 -0700 Subject: [cfe-dev] -Warray-bounds seems over-zealous on Clang In-Reply-To: References: <20110712150748.GA4913@britannica.bec.de> Message-ID: <0F9FF1EB-96F2-4ACB-8070-32EFD6B23CD4@apple.com> On Jul 12, 2011, at 8:54 AM, Peter Geoghegan wrote: > Saying "just use C99" isn't a practical solution. This is a mature > project with a large codebase, that targets many compilers, including, > for a large number of reasons, Visual Studio - Microsoft have > absolutely no interest in pursuing C99 support. Flexibly array members are a common extension, as are zero-length arrays, specifically for this purpose. I'm guessing that you didn't try our suggestion before dismissing it out of hand. > Besides, the chances of Clang actually helpfully diagnosing a problem > with the delta between how GCC does -Warray-bounds and how Clang does > it are slim - how often are these problems statically detectable? This > is C. We have empirical evidence that it *does* find bugs, otherwise we wouldn't still have the warning. > Even if your position wasn't unreasonable, which it is, Clang still > gives this warning when the -c89 flag is given. Asking you to consider using a feature from a 12-year-old standard that was specifically designed for what you're trying to do hardly falls into the category of "unreasonable", even if you consider it to be impractical. The *practical* solution for you is to turn off the warning with -Wno-array-bounds. - Doug From afish at apple.com Tue Jul 12 11:52:36 2011 From: afish at apple.com (Andrew Fish) Date: Tue, 12 Jul 2011 09:52:36 -0700 Subject: [cfe-dev] -Warray-bounds seems over-zealous on Clang In-Reply-To: References: <20110712150748.GA4913@britannica.bec.de> Message-ID: On Jul 12, 2011, at 8:54 AM, Peter Geoghegan wrote: > Saying "just use C99" isn't a practical solution. This is a mature > project with a large codebase, that targets many compilers, including, > for a large number of reasons, Visual Studio - Microsoft have > absolutely no interest in pursuing C99 support. > We have had the same problem in the EFI firmware open source project (edk2). The edk2 project supports Visual Studio 20XX, gcc, RVCT, clang, ... > Besides, the chances of Clang actually helpfully diagnosing a problem > with the delta between how GCC does -Warray-bounds and how Clang does > it are slim - how often are these problems statically detectable? This > is C. We have found real bugs in chipset and driver code with clangs -Warray-bounds, that the other compilers did not find. So, given it is C, we just add a int *value = &A.value[0], and replace A.value[n] with value[n]. Luckily for us the case of the value[1] variable length array were mostly in regards to processing data structures from specifications and we had a single C function per instance that was doing the parsing. The changes were accepted to the open source project, so we did not have to turn off -Warray-bounds. > > Even if your position wasn't unreasonable, which it is, Clang still > gives this warning when the -c89 flag is given. > > -- > Peter Geoghegan http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Training and Services > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From cg.wowus.cg at gmail.com Tue Jul 12 11:53:06 2011 From: cg.wowus.cg at gmail.com (Clark Gaebel) Date: Tue, 12 Jul 2011 12:53:06 -0400 Subject: [cfe-dev] -Warray-bounds seems over-zealous on Clang In-Reply-To: References: <20110712150748.GA4913@britannica.bec.de> Message-ID: I don't see what you expect Clang to do about this. The warning is perfectly accurate. The array is declared as size 1, and you're indexing past it. If you have a function like struct S { int a[1]; }; int get_second(struct S* s) { return s->a[1]; } That's very clearly an out of bounds error unless very specific conditions are met (heap allocated with enough space after the struct...) I feel like it would be impossible to prove this in every case. So that just leaves us with turning the warning off. (Which you can do yourself with -Wno-array-bounds) I wouldn't want this off by default if that's what you're suggesting, since it's a silver bullet for off-by-one bugs: void iterate() { int a[4]; for(size_t i = 0; i <= 4; i++) a[i] += 4; } I want a warning for that! Thanks, -- Clark On Tue, Jul 12, 2011 at 11:54 AM, Peter Geoghegan wrote: > Saying "just use C99" isn't a practical solution. This is a mature > project with a large codebase, that targets many compilers, including, > for a large number of reasons, Visual Studio - Microsoft have > absolutely no interest in pursuing C99 support. > > Besides, the chances of Clang actually helpfully diagnosing a problem > with the delta between how GCC does -Warray-bounds and how Clang does > it are slim - how often are these problems statically detectable? This > is C. > > Even if your position wasn't unreasonable, which it is, Clang still > gives this warning when the -c89 flag is given. > > -- > Peter Geoghegan ? ? ? http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Training and Services > > _______________________________________________ > 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 Jul 12 12:29:18 2011 From: clattner at apple.com (Chris Lattner) Date: Tue, 12 Jul 2011 10:29:18 -0700 Subject: [cfe-dev] -Warray-bounds seems over-zealous on Clang In-Reply-To: <0F9FF1EB-96F2-4ACB-8070-32EFD6B23CD4@apple.com> References: <20110712150748.GA4913@britannica.bec.de> <0F9FF1EB-96F2-4ACB-8070-32EFD6B23CD4@apple.com> Message-ID: <372E1D9D-8435-427E-9122-94A81E046187@apple.com> On Jul 12, 2011, at 9:50 AM, Douglas Gregor wrote: >> Besides, the chances of Clang actually helpfully diagnosing a problem >> with the delta between how GCC does -Warray-bounds and how Clang does >> it are slim - how often are these problems statically detectable? This >> is C. > > We have empirical evidence that it *does* find bugs, otherwise we wouldn't still have the warning. Do we have empirical evidence that it finds bugs in arrays with exactly 1 element? I think we should just disable it in the case that the array has a single element. This really is a common pattern. -Chris From thakis at chromium.org Tue Jul 12 14:16:06 2011 From: thakis at chromium.org (Nico Weber) Date: Tue, 12 Jul 2011 12:16:06 -0700 Subject: [cfe-dev] -Warray-bounds seems over-zealous on Clang In-Reply-To: <372E1D9D-8435-427E-9122-94A81E046187@apple.com> References: <20110712150748.GA4913@britannica.bec.de> <0F9FF1EB-96F2-4ACB-8070-32EFD6B23CD4@apple.com> <372E1D9D-8435-427E-9122-94A81E046187@apple.com> Message-ID: On Tue, Jul 12, 2011 at 10:29 AM, Chris Lattner wrote: > > On Jul 12, 2011, at 9:50 AM, Douglas Gregor wrote: > >>> Besides, the chances of Clang actually helpfully diagnosing a problem >>> with the delta between how GCC does -Warray-bounds and how Clang does >>> it are slim - how often are these problems statically detectable? This >>> is C. >> >> We have empirical evidence that it *does* find bugs, otherwise we wouldn't still have the warning. > > Do we have empirical evidence that it finds bugs in arrays with exactly 1 element? ?I think we should just disable it in the case that the array has a single element. ?This really is a common pattern. FWIW, here's an example where the warning found a bug and the array had 1 element: http://crbug.com/84851 > > -Chris > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > From chandlerc at google.com Tue Jul 12 15:08:28 2011 From: chandlerc at google.com (Chandler Carruth) Date: Tue, 12 Jul 2011 13:08:28 -0700 Subject: [cfe-dev] -Warray-bounds seems over-zealous on Clang In-Reply-To: <372E1D9D-8435-427E-9122-94A81E046187@apple.com> References: <20110712150748.GA4913@britannica.bec.de> <0F9FF1EB-96F2-4ACB-8070-32EFD6B23CD4@apple.com> <372E1D9D-8435-427E-9122-94A81E046187@apple.com> Message-ID: On Tue, Jul 12, 2011 at 10:29 AM, Chris Lattner wrote: > > On Jul 12, 2011, at 9:50 AM, Douglas Gregor wrote: > > >> Besides, the chances of Clang actually helpfully diagnosing a problem > >> with the delta between how GCC does -Warray-bounds and how Clang does > >> it are slim - how often are these problems statically detectable? This > >> is C. > > > > We have empirical evidence that it *does* find bugs, otherwise we > wouldn't still have the warning. > > Do we have empirical evidence that it finds bugs in arrays with exactly 1 > element? I think we should just disable it in the case that the array has a > single element. This really is a common pattern. I tend to agree, but maybe there is a good compromise. What about changing this warning to whitelist only one-element arrays which are inside of some record type? That would still catch local arrays, global arrays, etc. We could even then add a special (extension?) warning for one-element arrays inside of record types which are accessed passed the bounds only in modes where flexible array members are available, maybe even with a fixit note that converts the declaration. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110712/7e0c330d/attachment.html From supertri at google.com Tue Jul 12 15:46:46 2011 From: supertri at google.com (Caitlin Sadowski) Date: Tue, 12 Jul 2011 13:46:46 -0700 Subject: [cfe-dev] Proposal for thread safety attributes for Clang In-Reply-To: References: Message-ID: Hey all, Any other thoughts on this? Can we commit the first patch? Also, here a fresh copy of the first patch, which fixes a name changed since the time I initially emailed it out. Cheers, Caitlin On Fri, Jul 1, 2011 at 3:48 PM, Caitlin Sadowski wrote: > Here is the first thread safety patch. Note that this patch depends on > ?prior refactoring patches I sent out. If you want to review it, you can go > to: > http://codereview.appspot.com/4667054 > Cheers, > Caitlin > On Thu, Jun 30, 2011 at 5:57 PM, Caitlin Sadowski > wrote: >> >> The following is a proposal for a project we would like to contribute to >> Clang. Feel free to discuss. >> Cheers, >> Caitlin Sadowski >> Google & University of California at Santa Cruz >> >> Thread Safety Attributes for Clang >> >> Summary >> >> We would like to add a set of thread safety attributes to Clang. These >> attributes, based on a prior GCC implementation, will allow for checkable >> documentation of basic locking policies in multithreaded programs. >> >> Background >> The synchronization policies in modern multithreaded code may be poorly >> documented, and incorrectly inferred by new developers. Furthermore, when >> these policies are improperly followed they often lead to bugs which are >> difficult to reproduce and diagnose. One strategy for avoiding concurrency >> bugs is formal documentation of these synchronization policies. By writing >> this documentation using attribute-based annotations, Clang can mechanically >> check and warn about issues that could potentially result in race conditions >> and deadlocks. >> >> Example >> >> A code sample which demonstrates two of the proposed annotations is below. >> In this code sample, variables are protected by locks from the Mutex class. >> This class has been annotated to specify the API used to lock and unlock. >> >> * GUARDED_BY specifies a particular lock should be held when accessing the >> annotated variable. Violations of this locking policy may lead to data >> races. >> * ?ACQUIRED_AFTER annotations document the acquisition order between locks >> that can be held simultaneously by a thread, by specify the locks that need >> to be acquired before the annotated lock. Violations of this locking policy >> may lead to deadlocks. >> >> ?1 #include "thread_annotations.h" >> ?2 #define GUARDED_BY(x) __attribute__((GUARDED_BY(x))) >> ?3 #define ACQUIRED_AFTER(x) __attribute__((ACQUIRED_AFTER(x))) >> ?4 >> ?5 Mutex mu1; >> ?6 Mutex mu2 ACQUIRED_AFTER(mu1); >> ?7 >> ?8 int x GUARDED_BY(mu1); >> ?9 int a GUARDED_BY(mu2); >> ?10 >> ?11 void foo() >> ?12 { >> 13 ??mu2.Lock(); >> 14 ??mu1.Lock(); >> 15 ??if (x > 2) >> 16 ????a = x + 1; >> 17 ??else >> 18 ????a = x - 1; >> 19 ??mu1.Unlock(); >> 20 ??mu2.Unlock(); >> 21 } >> >> Sample compiler output: >> ex.cc: In function 'void foo()': >> ex.cc:12: warning: Lock 'mu1' is acquired after lock 'mu2' (acquired at >> line 14) but is annotated otherwise >> >> Previous Work >> >> As mentioned, thread safety annotations have been implemented in GCC. A >> full list of the annotations and descriptions for them can be found here: >> >> http://gcc.gnu.org/wiki/ThreadSafetyAnnotation >> https://docs.google.com/a/google.com/Doc?id=ddqtfwhb_0c49t6zgr >> >> These annotations have been in active use in Google?s C++ codebase for a >> couple of years, so there is a large informal case study of their >> usefulness. The ideas behind many of these annotations come originally from >> a research paper [1]. >> >> Plan >> >> We are planning to re-implement the GCC thread safety attributes in Clang. >> We will submit a series of patches to the cfe-commits mailing list. Our >> current plan for this serie is as follows: >> >> 1) Basic parsing and semantic checking of the attributes which do not take >> arguments. In other words, checking whether the attribute is applied in the >> appropriate context (e.g. to a field, with no arguments). >> 2) Basic parsing and semantic checking of the attributes which do take >> arguments, but without parsing or checking the arguments themselves. At this >> point, we will simply discard the tokens making up the arguments. >> 3) Attribute argument parsing. >> 4) Adding the thread safety analysis checks. We will teach the static >> analysis-based warnings layer to warn for violations of the annotations >> discussed on the links above. >> >> Future Projects >> >> Once we have this core set of thread safety annotations implemented, we >> have several directions for future work we would like to pursue. These >> include supporting additional types of annotations. For example, we would >> like to extend the system to support annotations for functions which only >> touch thread-local data and atomic functions which always execute as if they >> are not interleaved with operations of other threads. We would also like to >> build an annotation inference system; this system would enable application >> of the thread safety analysis to large amounts of legacy code. >> >> [1] C. Flanagan and S. N. Freund. Type-based race detection for Java. In >> Programming Language Design and Implementation (PLDI), June 2000. > -------------- next part -------------- A non-text attachment was scrubbed... Name: threadsafety_parsing_easyattrs_2.patch Type: text/x-patch Size: 16426 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110712/3b058e27/attachment-0001.bin From scott.conger at gmail.com Tue Jul 12 15:53:31 2011 From: scott.conger at gmail.com (Scott Conger) Date: Tue, 12 Jul 2011 13:53:31 -0700 Subject: [cfe-dev] -Warray-bounds seems over-zealous on Clang In-Reply-To: References: <20110712150748.GA4913@britannica.bec.de> <0F9FF1EB-96F2-4ACB-8070-32EFD6B23CD4@apple.com> <372E1D9D-8435-427E-9122-94A81E046187@apple.com> Message-ID: On Tue, Jul 12, 2011 at 1:08 PM, Chandler Carruth wrote: > On Tue, Jul 12, 2011 at 10:29 AM, Chris Lattner wrote: >> >> On Jul 12, 2011, at 9:50 AM, Douglas Gregor wrote: >> >> >> Besides, the chances of Clang actually helpfully diagnosing a problem >> >> with the delta between how GCC does -Warray-bounds and how Clang does >> >> it are slim - how often are these problems statically detectable? This >> >> is C. >> > >> > We have empirical evidence that it *does* find bugs, otherwise we >> > wouldn't still have the warning. >> >> Do we have empirical evidence that it finds bugs in arrays with exactly 1 >> element? ?I think we should just disable it in the case that the array has a >> single element. ?This really is a common pattern. > > I tend to agree, but maybe there is a good compromise. What about changing > this warning to whitelist only one-element arrays which are inside of some > record type? That would still catch local arrays, global arrays, etc. > We could even then add a special (extension?) warning for one-element arrays > inside of record types which are accessed passed the bounds only in modes > where flexible array members are available, maybe even with a fixit note > that converts the declaration. Couldn't we be even more specific and require it to be the last member of the struct/class? From chandlerc at google.com Tue Jul 12 15:58:13 2011 From: chandlerc at google.com (Chandler Carruth) Date: Tue, 12 Jul 2011 13:58:13 -0700 Subject: [cfe-dev] -Warray-bounds seems over-zealous on Clang In-Reply-To: References: <20110712150748.GA4913@britannica.bec.de> <0F9FF1EB-96F2-4ACB-8070-32EFD6B23CD4@apple.com> <372E1D9D-8435-427E-9122-94A81E046187@apple.com> Message-ID: On Tue, Jul 12, 2011 at 1:53 PM, Scott Conger wrote: > Couldn't we be even more specific and require it to be the last member > of the struct/class? > Yes, sorry I should have been more precise. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110712/f58bd675/attachment.html From thakis at chromium.org Tue Jul 12 16:02:11 2011 From: thakis at chromium.org (Nico Weber) Date: Tue, 12 Jul 2011 14:02:11 -0700 Subject: [cfe-dev] -Warray-bounds seems over-zealous on Clang In-Reply-To: References: <20110712150748.GA4913@britannica.bec.de> <0F9FF1EB-96F2-4ACB-8070-32EFD6B23CD4@apple.com> <372E1D9D-8435-427E-9122-94A81E046187@apple.com> Message-ID: FWIW the bug I linked to earlier had the array as the last member of a struct :-) On Tue, Jul 12, 2011 at 1:58 PM, Chandler Carruth wrote: > On Tue, Jul 12, 2011 at 1:53 PM, Scott Conger > wrote: >> >> Couldn't we be even more specific and require it to be the last member >> of the struct/class? > > Yes, sorry I should have been more precise. > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > > From peter at 2ndquadrant.com Tue Jul 12 17:39:18 2011 From: peter at 2ndquadrant.com (Peter Geoghegan) Date: Tue, 12 Jul 2011 23:39:18 +0100 Subject: [cfe-dev] -Warray-bounds seems over-zealous on Clang In-Reply-To: <372E1D9D-8435-427E-9122-94A81E046187@apple.com> References: <20110712150748.GA4913@britannica.bec.de> <0F9FF1EB-96F2-4ACB-8070-32EFD6B23CD4@apple.com> <372E1D9D-8435-427E-9122-94A81E046187@apple.com> Message-ID: On 12 July 2011 18:29, Chris Lattner wrote: > Do we have empirical evidence that it finds bugs in arrays with exactly 1 element? ?I think we should just disable it in the case that the array has a single element. ?This really is a common pattern. I would think it reasonable if the warning was disabled for this exact pattern only. Disabling -Wno-array-bounds clearly isn't a practical measure, as most of the ways that that can trigger a warning are perfectly valid. I wouldn't be opposed to showing the warning where the struct is known to have been declared on the stack, but going that far probably isn't worth the effort. On 12 July 2011 17:45, Joerg Sonnenberger wrote: > Just because you don't agree doesn't make it unreasonable. The behavior > of the code doesn't change with the standard level -- you are still > declaring an array and overflowing it. I agree, it doesn't. The fact that this causes warnings for a very common pattern makes it unreasonable. -- Peter Geoghegan ? ? ? http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services From reid.kleckner at gmail.com Tue Jul 12 17:52:48 2011 From: reid.kleckner at gmail.com (Reid Kleckner) Date: Tue, 12 Jul 2011 18:52:48 -0400 Subject: [cfe-dev] -Warray-bounds seems over-zealous on Clang In-Reply-To: References: <20110712150748.GA4913@britannica.bec.de> <0F9FF1EB-96F2-4ACB-8070-32EFD6B23CD4@apple.com> <372E1D9D-8435-427E-9122-94A81E046187@apple.com> Message-ID: On Tue, Jul 12, 2011 at 6:39 PM, Peter Geoghegan wrote: > On 12 July 2011 18:29, Chris Lattner wrote: >> Do we have empirical evidence that it finds bugs in arrays with exactly 1 element? ?I think we should just disable it in the case that the array has a single element. ?This really is a common pattern. > > I would think it reasonable if the warning was disabled for this exact > pattern only. > > Disabling -Wno-array-bounds clearly isn't a practical measure, as most > of the ways that that can trigger a warning are perfectly valid. I > wouldn't be opposed to showing the warning where the struct is known > to have been declared on the stack, but going that far probably isn't > worth the effort. > > On 12 July 2011 17:45, Joerg Sonnenberger wrote: >> Just because you don't agree doesn't make it unreasonable. The behavior >> of the code doesn't change with the standard level -- you are still >> declaring an array and overflowing it. > > I agree, it doesn't. The fact that this causes warnings for a very > common pattern makes it unreasonable. My inclination and I believe the inclination of others is that, if it catches real bugs, which Nico has shown it has, then it's worth having the warning. Another compromise would be to have a flag about bounds checks warnings for size 1 arrays at the end of structs (phew). =P If you can't use C99, are flexible arrays available as an extension in clang, either in gnu89 or via some flag? If so, you could use ifdefs like this: #ifdef __GNUC__ /* or some other condition, __has_feature or what have you */ #define FLEXIBLE_ARRAY #else #define FLEXIBLE_ARRAY 1 #endif struct Buffer { int len; char bytes[FLEXIBLE_ARRAY]; }; It's even self-documenting. Reid From peter at 2ndquadrant.com Tue Jul 12 18:17:43 2011 From: peter at 2ndquadrant.com (Peter Geoghegan) Date: Wed, 13 Jul 2011 00:17:43 +0100 Subject: [cfe-dev] -Warray-bounds seems over-zealous on Clang In-Reply-To: References: <20110712150748.GA4913@britannica.bec.de> <0F9FF1EB-96F2-4ACB-8070-32EFD6B23CD4@apple.com> <372E1D9D-8435-427E-9122-94A81E046187@apple.com> Message-ID: On 12 July 2011 23:52, Reid Kleckner wrote: > My inclination and I believe the inclination of others is that, if it > catches real bugs, which Nico has shown it has, then it's worth having > the warning. It's going to cause spurious warnings for a large number of real-world applications. Do you think that that will endear developers of those applications to Clang? The fact that it may catch bugs in some extremely unlikely scenario (recall that I only want to avoid the warning for this very specific case) should not outweigh this. Isn't that obvious? > Another compromise would be to have a flag about bounds > checks warnings for size 1 arrays at the end of structs (phew). ?=P As I said, I would think it reasonable if the warning was disabled for this exact pattern only, so that for example it would not occur if the array had more than 1 element, or wasn't the last piece of data in the struct. > If you can't use C99, are flexible arrays available as an extension in > clang, either in gnu89 or via some flag? ?If so, you could use ifdefs > like this: > > #ifdef __GNUC__ > /* or some other condition, __has_feature or what have you */ > #define FLEXIBLE_ARRAY > #else > #define FLEXIBLE_ARRAY 1 > #endif > > struct Buffer { > ?int len; > ?char bytes[FLEXIBLE_ARRAY]; > }; > > It's even self-documenting. It's gross. Our community is obsessed with code hygiene, and that will never fly just to get Clang to stop complaining while every single other compiler, of which there are quite a few (PostgreSQL is supposed to be highly portable), will not complain. -- Peter Geoghegan ? ? ? http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services From dblaikie at gmail.com Tue Jul 12 18:28:45 2011 From: dblaikie at gmail.com (David Blaikie) Date: Tue, 12 Jul 2011 16:28:45 -0700 Subject: [cfe-dev] -Warray-bounds seems over-zealous on Clang In-Reply-To: References: <20110712150748.GA4913@britannica.bec.de> <0F9FF1EB-96F2-4ACB-8070-32EFD6B23CD4@apple.com> <372E1D9D-8435-427E-9122-94A81E046187@apple.com> Message-ID: > > > #ifdef __GNUC__ > > /* or some other condition, __has_feature or what have you */ > > #define FLEXIBLE_ARRAY > > #else > > #define FLEXIBLE_ARRAY 1 > > #endif > > > > struct Buffer { > > int len; > > char bytes[FLEXIBLE_ARRAY]; > > }; > > > > It's even self-documenting. > > It's gross. Our community is obsessed with code hygiene, and that will > never fly just to get Clang to stop complaining while every single > other compiler, of which there are quite a few (PostgreSQL is supposed > to be highly portable), will not complain. > What exactly do you mean by code hygiene in this regard? Why would the above be unhygienic? I think someone mentioned the idea of adding a separate warning for this narrower case and, in the case of compiling for c99, suggesting a fixup of using a flexible array. In the case of c89 at least it'd be a separate warning that, if the pattern is used extensively in the codebase, could be disabled separately from the more general warning (which would be adjusted to ignore these cases). This would allow for the bug that was mentioned to have been found, while allowing you to disable this warning if you don't think the chance of such bugs coming up is worth the code hygiene cost of the above construct or the move to c99 would be worthwhile in your case. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110712/00aae29a/attachment-0001.html From peter at 2ndquadrant.com Tue Jul 12 18:59:22 2011 From: peter at 2ndquadrant.com (Peter Geoghegan) Date: Wed, 13 Jul 2011 00:59:22 +0100 Subject: [cfe-dev] -Warray-bounds seems over-zealous on Clang In-Reply-To: References: <20110712150748.GA4913@britannica.bec.de> <0F9FF1EB-96F2-4ACB-8070-32EFD6B23CD4@apple.com> <372E1D9D-8435-427E-9122-94A81E046187@apple.com> Message-ID: On 13 July 2011 00:28, David Blaikie wrote: > I think someone mentioned the idea of adding a separate warning for this > narrower case and, in the case of compiling for c99, suggesting a fixup of > using a flexible array. In the case of c89 at least it'd be a separate > warning that, if the pattern is used extensively in the codebase, could be > disabled separately from the more general warning (which would be adjusted > to ignore these cases). > > This would allow for the bug that was mentioned to have been found, while > allowing you to disable this warning if you don't think the chance of such > bugs coming up is worth the code hygiene cost of the above construct or the > move to c99 would be worthwhile in your case. While strictly speaking that would be a valid solution, it would also be overly-complex considering the benefits IMHO. I'd now have a flag to pass to Clang, but only to Clang, despite the fact that it's supposed to be a drop-in replacement for GCC. I'd now have to explicitly indicate that I was using C89. Once again, the burden would be on application developers who are just using a demonstrably mainstream idiom, all to prevent obvious bugs in poorly written applications under very specific circumstances, that will only occur a vanishingly small number of times, and will never be noticed by GCC either. -- Peter Geoghegan ? ? ? http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services From thakis at chromium.org Tue Jul 12 19:06:22 2011 From: thakis at chromium.org (Nico Weber) Date: Tue, 12 Jul 2011 17:06:22 -0700 Subject: [cfe-dev] -Warray-bounds seems over-zealous on Clang In-Reply-To: References: <20110712150748.GA4913@britannica.bec.de> <0F9FF1EB-96F2-4ACB-8070-32EFD6B23CD4@apple.com> <372E1D9D-8435-427E-9122-94A81E046187@apple.com> Message-ID: On Tue, Jul 12, 2011 at 4:59 PM, Peter Geoghegan wrote: > On 13 July 2011 00:28, David Blaikie wrote: > >> I think someone mentioned the idea of adding a separate warning for this >> narrower case and, in the case of compiling for c99, suggesting a fixup of >> using a flexible array. In the case of c89 at least it'd be a separate >> warning that, if the pattern is used extensively in the codebase, could be >> disabled separately from the more general warning (which would be adjusted >> to ignore these cases). >> >> This would allow for the bug that was mentioned to have been found, while >> allowing you to disable this warning if you don't think the chance of such >> bugs coming up is worth the code hygiene cost of the above construct or the >> move to c99 would be worthwhile in your case. > > While strictly speaking that would be a valid solution, it would also > be overly-complex considering the benefits IMHO. I'd now have a flag > to pass to Clang, but only to Clang, despite the fact that it's > supposed to be a drop-in replacement for GCC. I'd now have to > explicitly indicate that I was using C89. In the past, warnings that warns about a common pattern but also find bugs have been kept on-by-default. Search this list for -Wdelete-non-virtual-dtor. > Once again, the burden would be on application developers who are just > using a demonstrably mainstream idiom, all to prevent obvious bugs in > poorly written applications under very specific circumstances, that > will only occur a vanishingly small number of times, and will never be > noticed by GCC either. This bug is in ICU, which is pretty commonly used. Someone (me) posted an example where this warning found a bug within 2h of Chris asking for it, so maybe it's not as vanishingly small as you think. Nico > > -- > Peter Geoghegan ? ? ? http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Training and Services > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > From rjmccall at apple.com Tue Jul 12 19:15:24 2011 From: rjmccall at apple.com (John McCall) Date: Tue, 12 Jul 2011 17:15:24 -0700 Subject: [cfe-dev] -Warray-bounds seems over-zealous on Clang In-Reply-To: References: <20110712150748.GA4913@britannica.bec.de> <0F9FF1EB-96F2-4ACB-8070-32EFD6B23CD4@apple.com> <372E1D9D-8435-427E-9122-94A81E046187@apple.com> Message-ID: <9875D18C-FE6B-4F7C-9885-137C2BAE63EE@apple.com> Gentlemen, this is Clang; we can differentiate between '1' as a literal value and '1' resulting from a template- or macro-metaprogrammed computation. The former case has no legitimate examples and can be safely assumed to be a pre-C99 flexible array member. The latter case should still be diagnosed using -Warray-bounds. John. From dblaikie at gmail.com Tue Jul 12 20:58:48 2011 From: dblaikie at gmail.com (David Blaikie) Date: Tue, 12 Jul 2011 18:58:48 -0700 Subject: [cfe-dev] Disambiguating C++ Lambdas and Objective-C Messages In-Reply-To: <4E1C64B6.8020103@cse.tamu.edu> References: <4E1C64B6.8020103@cse.tamu.edu> Message-ID: > Based on recommendations, I'm looking at the following decision tree > after seeing a '['. > Hi John, Slightly tangential, but given a recent thread on llvm-commits about CR size - I only recently subscribed to the cfe-commits list, so I might've missed any CRs you've sent out for this so far, but I was wondering if you're sending this lambda work out incrementally as it sort of sounds like you're working on one big patch (at least for the parser stage, for example) when it might be possible to break this up into some very small chunks which would help development, review, & might allow more collaborative work (ie: I'd like to be able to write some small parts of this work, perhaps, without going blind for large periods of time & duplicating your work). For example, I was thinking of starting with parsing of only C++0x without ObjC support, as per the previous email thread we had going. And in that instance only parsing the simplest of C++0x lambdas possible: [] {} - then work could potentially continue in multiple directions, both enhancing the parsing to handle arguments, captures, return values - as well as going deeper & implementing some of the semantic analysis, etc, at the same time, in small steps. Just some thoughts - realistically I'm not sure how much I'd be able to contribute to the effort, but thought these ideas might help. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110712/bdee6d19/attachment.html From jfreeman at cse.tamu.edu Tue Jul 12 21:17:41 2011 From: jfreeman at cse.tamu.edu (John Freeman) Date: Tue, 12 Jul 2011 21:17:41 -0500 Subject: [cfe-dev] Disambiguating C++ Lambdas and Objective-C Messages In-Reply-To: References: <4E1C64B6.8020103@cse.tamu.edu> Message-ID: <4E1D0045.5060903@cse.tamu.edu> On 7/12/11 8:58 PM, David Blaikie wrote: > I was > wondering if you're sending this lambda work out incrementally as it > sort of sounds like you're working on one big patch (at least for the > parser stage, for example) when it might be possible to break this up > into some very small chunks which would help development, review, & > might allow more collaborative work I guess I thought parsing would be a small enough chunk. I've already got most of that done already, but I'll try to break my work into smaller pieces going forward. > For example, I was thinking of starting with parsing of only C++0x > without ObjC support, as per the previous email thread we had going. I had submitted a patch for parsing lambdas last week with a small amount of disambiguation, and it got a comment that it would not be enough for the general case, so I just went ahead and tried to handle it. - John From clattner at apple.com Tue Jul 12 22:39:19 2011 From: clattner at apple.com (Chris Lattner) Date: Tue, 12 Jul 2011 20:39:19 -0700 Subject: [cfe-dev] -Warray-bounds seems over-zealous on Clang In-Reply-To: <9875D18C-FE6B-4F7C-9885-137C2BAE63EE@apple.com> References: <20110712150748.GA4913@britannica.bec.de> <0F9FF1EB-96F2-4ACB-8070-32EFD6B23CD4@apple.com> <372E1D9D-8435-427E-9122-94A81E046187@apple.com> <9875D18C-FE6B-4F7C-9885-137C2BAE63EE@apple.com> Message-ID: <0E79DD0F-EDDC-4E1E-8601-DABB4F3AD46A@apple.com> On Jul 12, 2011, at 5:15 PM, John McCall wrote: > Gentlemen, this is Clang; we can differentiate between '1' as a literal > value and '1' resulting from a template- or macro-metaprogrammed > computation. The former case has no legitimate examples and can > be safely assumed to be a pre-C99 flexible array member. The latter > case should still be diagnosed using -Warray-bounds. +1. The point of a warning is to be useful, not abusive. If going to extreme measures makes the warning more useful and causes it to be more useful by default, then I think it is worth it. Clang needs to be tolerant of different programming styles and constraints. While it is never possible to make everyone happy, disabling the warning in a very-likely false positive, or splitting that case out into a sub -W flag is the right way to go. -Warray-bounds-single-element seems like overkill to me, but is completely feasible. -Chris From kremenek at apple.com Wed Jul 13 01:10:19 2011 From: kremenek at apple.com (Ted Kremenek) Date: Tue, 12 Jul 2011 23:10:19 -0700 Subject: [cfe-dev] Removing "TransferFuncs" from the analyzer In-Reply-To: References: Message-ID: <7466F426-4056-4C55-A132-DA1B1294674A@apple.com> On Jul 12, 2011, at 12:06 AM, Jordy Rose wrote: > Looking at this some more, it seems the only information the function summaries provide that aren't also available through RefVals are: Hi Jordy, The main role of the summaries is to memoize the computation of the transfer function logic. Those should stay around primarily to make the checker faster. You are correct, however, that they are currently used for generating the diagnostics > > 1. Treating [object dealloc] differently from [object release]. This could be replaced by examining the current ExplodedNode's Stmt every time we hit a Released RefVal, or by adding a ReleasedByDeallocation RefVal::Kind. Or we could ignore it since it is so rare in Cocoa code. (I suppose non-Cocoa code doesn't have to be ref-counted for the RetainReleaseChecker to catch alloc/dealloc balances.) This is a QOI thing, and I think it is worth keeping. Adding a new RefVal::Kind seems inexpensive. All of the QOI in the retain/release checker is there for a reason (because users have explicitly requested them). I see no reason to regress on functionality here, especially when we have a way to represent them in a cleaner model. > > 2. Noting that (NS|CF)MakeCollectable is ignored in non-GC mode. This is definitely nice QoI-wise but isn't (IMHO) a critical part of the bug report's usefulness. > > 3. Noting that -autorelease, -retain, and -release are ignored in GC mode. Same as above. > > Noting that X is ignored is something that's a little annoying to do while trying to keep GRState explosion down. My initial thought was to add a counter to RefVal for these messages, but that would mean that something like this would create two states after the branch is done (i.e. no uniquing the states). > > id object = getObject(); > if (arbitraryCondition()) { > [object retain]; > doSomethingWith(object); > [object release]; > } > > Another possibility is a simple single-bit toggle; that way any ignored messages will still show up as a change in the state of the referred variable, and only branches with an odd number of ignored messages will result in distinct GRStates. This feels like more of a hack, but it costs less in memory (it could even be combined in a bitfield with the object kind). I have another suggestion that avoids the state explosion problem, but it requires more infrastructure: annotated GRStates. Essentially we are trying to reconstruct information here on how a GRState was constructed at a particular program point along a specific path. The problem is that recording path-specific information in a GRState is dangerous because it can lead to state bifurcation. Consider a new concept: AnnotatedGRState. In pseudo-code: class AnnotatedGRState { const GRState *state; const Annotations *annotations; public: AnnotatedGRState(const GRState *st, const Annotations *annots = 0) : state(st), annotations(annots) {} operator const GRState*() const { return state; } }; and the following modification to ExplodedGraph: ExplodedNode* getNode(const ProgramPoint& L, const GRState *State, bool* IsNew = 0); becomes ExplodedNode* getNode(const ProgramPoint& L, const AnnotatedGRState &State, bool* IsNew = 0); The main change is that getNode() accepts a GRState with optional annotations. Those annotations aren't stored directly in ExplodedNode (we just keep a GRState*), but in a side-table in ExplodedGraph because annotations will be so rare. We can then query the ExplodedGraph for the annotations for a given ExplodedNode. Of course I've left the definition of "Annotations" ambiguous; the idea is to provide something that a checker can scribble on top of a state that can be preserved in the ExplodedGraph but does *not* taint the GRState with path-specific information that we wouldn't want in subsequent nodes in the ExplodedGraph. This approach solves a variety of problems: (1) CFRefCount doesn't need to grovel through the AST when generating diagnostics, like it does right now, to infer "what happened" in a state transition to generate the right diagnostic. It just generates an annotation up front when it does the state transition (for those cases where we need to record more information), which gets stuck on the ExplodedNode. Subsequent ExplodedNodes don't inherit the annotations; they just get the GRState. (2) This is a general problem that all checkers need to be able to solve. Most checkers want to have rich diagnostics, but shouldn't need to go through the same kind of complexity that CFRefCount does to generate good diagnostics. (3) Annotations have a variety of possible implications besides just better diagnostics; they are a way of tagging points along paths that are of interest to a checker. What do you think of this approach? > > With either way of forcing a change, we'd then examine the current ExplodedNode's statement to see what was wrong. > > I'm going to start working on this soon, using the bit toggle for the ignored messages, and try to come up with orthogonal patches that chip away at TransferFuncs and CFRefCount! I won't mince words here: I really am opposed to the bit toggle approach. It doesn't feel clean, and I think there overall is a much better general approach (e.g., annotated states) that will be useful for a wider range of checkers. We shouldn't go down the path of stuffing *transient* information into a GRState that has the possibility of bifurcating the exploded graph. If we find ourselves tempted to do that, it seems to me that we are lacking the needed infrastructure to do the right thing. From clattner at apple.com Wed Jul 13 01:18:06 2011 From: clattner at apple.com (Chris Lattner) Date: Tue, 12 Jul 2011 23:18:06 -0700 Subject: [cfe-dev] Proposal for thread safety attributes for Clang In-Reply-To: References: Message-ID: <63C66C00-8996-4CC2-855A-76CA19678D1A@apple.com> On Jul 1, 2011, at 3:48 PM, Caitlin Sadowski wrote: > Here is the first thread safety patch. Note that this patch depends on prior refactoring patches I sent out. If you want to review it, you can go to: > > http://codereview.appspot.com/4667054 Hi Caitlin, A few questions: > Summary > > We would like to add a set of thread safety attributes to Clang. These attributes, based on a prior GCC implementation, will allow for checkable documentation of basic locking policies in multithreaded programs. Are these in mainline GCC or just a branch? If they are in mainline GCC and have shipped in a release, then taking them into Clang makes sense for compatibility reasons. If they are a research project that is in development, then the bar to getting it into mainline clang is much higher, because adding attributes is tantamount to a language extension. > Plan > > We are planning to re-implement the GCC thread safety attributes in Clang. We will submit a series of patches to the cfe-commits mailing list. Our current plan for this serie is as follows: > > 1) Basic parsing and semantic checking of the attributes which do not take arguments. In other words, checking whether the attribute is applied in the appropriate context (e.g. to a field, with no arguments). > 2) Basic parsing and semantic checking of the attributes which do take arguments, but without parsing or checking the arguments themselves. At this point, we will simply discard the tokens making up the arguments. > 3) Attribute argument parsing. > 4) Adding the thread safety analysis checks. We will teach the static analysis-based warnings layer to warn for violations of the annotations discussed on the links above. This sounds like a very reasonable breakdown. Please start with #0 though, which is "gain consensus that this is a good thing to take into mainline" :) I'm specifically concerned on a number of fronts here: 1. Are these annotations general enough to apply to many common lock-based APIs? 2. How do the annotations handle aliasing of lock objects? 3. How many bugs have been found in practice? 4. Have you considered doing this as a static analysis (where the bar is much lower to get things into mainline) instead of as a language change? -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110712/d39247bf/attachment.html From niebuhr at niebuhrt.de Wed Jul 13 04:03:12 2011 From: niebuhr at niebuhrt.de (Toralf Niebuhr) Date: Wed, 13 Jul 2011 11:03:12 +0200 Subject: [cfe-dev] small Mac OS lib++ fixes Message-ID: Hi, these are just two small patches fixing the libc++ build for Mac OS X. The first patch replaces an "#ifndef LIBCPP_STABLE_APPLE_ABI" with "#ifdef LIBCPP_STABLE_APPLE_ABI". This is probably a copy and paste error as it's usually used with "#ifndef" The second patch replaces "__funcs()" with "func()". The underscore calls are encapsulated with the calls without underscores in the "locale" header. -------------- next part -------------- A non-text attachment was scrubbed... Name: use-func-instead-of__func.diff Type: application/octet-stream Size: 12096 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110713/4d03e012/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: use-LIBCPP_STABLE_APPLE_ABI-flag.diff Type: application/octet-stream Size: 337 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110713/4d03e012/attachment-0001.obj -------------- next part -------------- Toralf Niebuhr From peter at 2ndquadrant.com Wed Jul 13 04:13:29 2011 From: peter at 2ndquadrant.com (Peter Geoghegan) Date: Wed, 13 Jul 2011 10:13:29 +0100 Subject: [cfe-dev] -Warray-bounds seems over-zealous on Clang In-Reply-To: <0E79DD0F-EDDC-4E1E-8601-DABB4F3AD46A@apple.com> References: <20110712150748.GA4913@britannica.bec.de> <0F9FF1EB-96F2-4ACB-8070-32EFD6B23CD4@apple.com> <372E1D9D-8435-427E-9122-94A81E046187@apple.com> <9875D18C-FE6B-4F7C-9885-137C2BAE63EE@apple.com> <0E79DD0F-EDDC-4E1E-8601-DABB4F3AD46A@apple.com> Message-ID: On 13 July 2011 01:06, Nico Weber wrote: > In the past, warnings that warns about a common pattern but also find > bugs have been kept on-by-default. Search this list for > -Wdelete-non-virtual-dtor. I don't have time to review Clang's exact behavior there right now, but my guess is that this is a false equivalency. Code that causes that warning at the class definition (which I think is what you allude to - no delete is required) is inherently wrong according to the C++ intelligentsia, unless the base dtor is declared protected per an idiom described by Herb Sutter. No one would ever encourage virtual functions with a non-virtual public dtor (some styleguides go so far as to require all dtors be virtual, which even the std lib violates), whereas what I describe is in various text books. > This bug is in ICU, which is pretty commonly used. Someone (me) posted > an example where this warning found a bug within 2h of Chris asking > for it, so maybe it's not as vanishingly small as you think. That bug was really obvious, and was a narrow case of someone misusing a struct that used this idiom. I doubt the developer of that app would thank you for your attitude - you just saved them this one bug, but you probably created a whole bunch of spurious warnings at other parts of their codebase in the process. Why should they even think that it's valid in this one place anyway, where it is only valid by dumb luck? They weren't clued-in enough to catch a really obvious bug in the first place. On 13 July 2011 04:39, Chris Lattner wrote: > -Warray-bounds-single-element seems like overkill to me, but is completely feasible. Right. Let the extremely paranoid individuals (avionics engineers, medical equipment engineers) throw every single flag that produces additional warnings at Clang, which they're quite happy to do their homework on. Let the vast majority of developers have sane, non-annoying behaviour without any burden to pass additional flags. -- Peter Geoghegan ? ? ? http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services From titus at v9g.de Wed Jul 13 06:06:04 2011 From: titus at v9g.de (Titus von Boxberg) Date: Wed, 13 Jul 2011 13:06:04 +0200 Subject: [cfe-dev] -Warray-bounds seems over-zealous on Clang In-Reply-To: References: <20110712150748.GA4913@britannica.bec.de> <0F9FF1EB-96F2-4ACB-8070-32EFD6B23CD4@apple.com> <372E1D9D-8435-427E-9122-94A81E046187@apple.com> <9875D18C-FE6B-4F7C-9885-137C2BAE63EE@apple.com> <0E79DD0F-EDDC-4E1E-8601-DABB4F3AD46A@apple.com> Message-ID: <8EB36E28-54C5-4EC8-A06F-62491CDAAC6F@v9g.de> Am 13.07.2011 um 11:13 schrieb Peter Geoghegan: > On 13 July 2011 01:06, Nico Weber wrote: >> In the past, warnings that warns about a common pattern but also find >> bugs have been kept on-by-default. Search this list for >> -Wdelete-non-virtual-dtor. > > I don't have time to review Clang's exact behavior there right now, > but my guess is that this is a false equivalency. Code that causes > that warning at the class definition (which I think is what you allude > to - no delete is required) is inherently wrong according to the C++ > intelligentsia, unless the base dtor is declared protected per an > idiom described by Herb Sutter. No one would ever encourage virtual > functions with a non-virtual public dtor (some styleguides go so far > as to require all dtors be virtual, which even the std lib violates), > whereas what I describe is in various text books. > >> This bug is in ICU, which is pretty commonly used. Someone (me) posted >> an example where this warning found a bug within 2h of Chris asking >> for it, so maybe it's not as vanishingly small as you think. > > That bug was really obvious, and was a narrow case of someone misusing > a struct that used this idiom. I doubt the developer of that app would > thank you for your attitude - you just saved them this one bug, but > you probably created a whole bunch of spurious warnings at other parts > of their codebase in the process. Why should they even think that it's > valid in this one place anyway, where it is only valid by dumb luck? > They weren't clued-in enough to catch a really obvious bug in the > first place. > > On 13 July 2011 04:39, Chris Lattner wrote: > >> -Warray-bounds-single-element seems like overkill to me, but is completely feasible. > > Right. Let the extremely paranoid individuals (avionics engineers, > medical equipment engineers) throw every single flag that produces > additional warnings at Clang, which they're quite happy to do their > homework on. Let the vast majority of developers have sane, > non-annoying behaviour without any burden to pass additional flags. A small meta comment: Your complaints would be less annyoing to read if you'd stop using cheap rhetorical tricks like displaying your use case as "sane", "reasonable", representing the "vast majority", etc.; and others as "paranoid", "burdened with passing additional compiler flags" (WOW! that's something I have to remember as a nifty excuse for the next time the delivery date is missed! Sorry, I was so burdened passing all the additional compiler flags, really, I couldn't make it! sorry, I'm using cheap rhetorical tricks ;-), "gross", "unhygienic" etc. But, alas!, speaking as a "paranoid avionics engineer", being expected to happily carry the compiler flag burden home with me, I can only recommend being compliant with latest language standards, in this case C99. Shouldn't be too bad for postgresql to target a now already aging standard. Also the software I'm working on suffered some from some non-standard extensions that we took as granted, but were marked as an error or were given a warning by clang. So, I did not see an argument why using the "unhygienic" suggestion of C99 variable length arrays isn't viable; if MS cl.exe does not support this (which I don't know), I'd see this as an insufficient standards implementation and regard this as the problem of this compiler, not of clang. In this case, I'd recommend to use the "gross" suggestion of Reid Kleckner. This is analogous to what e.g. boost does for portability to older non compliant compilers, and in most cases I wouldn't attribute the boost libs with any of the fancy negative words you brought up so far. And I'd regard the fact that this expression of the idiom is - as Reid pointed out - self-documenting as adhering to very high hygienic standards. Regards Titus From peter at 2ndquadrant.com Wed Jul 13 06:46:20 2011 From: peter at 2ndquadrant.com (Peter Geoghegan) Date: Wed, 13 Jul 2011 12:46:20 +0100 Subject: [cfe-dev] -Warray-bounds seems over-zealous on Clang In-Reply-To: <8EB36E28-54C5-4EC8-A06F-62491CDAAC6F@v9g.de> References: <20110712150748.GA4913@britannica.bec.de> <0F9FF1EB-96F2-4ACB-8070-32EFD6B23CD4@apple.com> <372E1D9D-8435-427E-9122-94A81E046187@apple.com> <9875D18C-FE6B-4F7C-9885-137C2BAE63EE@apple.com> <0E79DD0F-EDDC-4E1E-8601-DABB4F3AD46A@apple.com> <8EB36E28-54C5-4EC8-A06F-62491CDAAC6F@v9g.de> Message-ID: On 13 July 2011 12:06, Titus von Boxberg wrote: > A small meta comment: > Your complaints would be less annyoing to read if you'd > stop using cheap rhetorical tricks like displaying your use case > as "sane", "reasonable", representing the "vast majority", etc.; > and others as "paranoid", "burdened with passing additional compiler flags" > (WOW! that's something I have to remember as a nifty excuse for the next time the > delivery date is missed! Sorry, I was so burdened passing all the additional > compiler flags, really, I couldn't make it! > sorry, I'm using cheap rhetorical tricks ;-), > "gross", "unhygienic" etc. > > But, alas!, speaking as a "paranoid avionics engineer", being expected > to happily carry the compiler flag burden home with me, I can only recommend being > compliant with latest language standards, in this case C99. > Shouldn't be too bad for postgresql to target a now > already aging standard. > Also the software I'm working on suffered some from some non-standard > extensions that we took as granted, but were marked as an error or were > given a warning by clang. > > So, I did not see an argument why using the "unhygienic" suggestion > of C99 variable length arrays isn't viable; if MS cl.exe does not support > this (which I don't know), I'd see this as an insufficient standards > implementation and regard this as the problem of this compiler, not of clang. Please stop putting words in my mouth. I never called anything unhygienic. Any of the adjectives I used were my opinion. I really don't see how you could consider that a cheap rhetorical trick. If you'd like me to demonstrate that I represent a large segment of people by taking issue with the way Clang currently deals with this, I'd be happy to. I consider that unnecessary though, as it has already been acknowledged by Chris and Chandler. It would be nice if we could move to C99; I'd be the first to support such a move, if it was practical. It is not practical for highly portable software such as PostgreSQL to move to C99, probably for more reasons than MSVC compatibility, although we do already use some widely supported C99 features. Uptake of C99 just hasn't been what I'm sure we'd all like it to be. Pretending that this isn't the case isn't going to help C99's cause, or Clang's. -- Peter Geoghegan ? ? ? http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services From t_guen03 at uni-muenster.de Wed Jul 13 08:29:06 2011 From: t_guen03 at uni-muenster.de (Tobias Guennewig) Date: Wed, 13 Jul 2011 15:29:06 +0200 Subject: [cfe-dev] Result Type of a Template Function Message-ID: <1310563746.5162.1.camel@tobias> Hi, i wonder if there is a way to retrieve the return type of a template function. The function clang_getResultType works for cursors, whose 'kind' property is CXCursor_FunctionDecl. For a CXCursor_FunctionTemplate it says, 'CXType_Invalid'. Can someone tell me the reason for this behavior? Thanks, Tobias From dblaikie at gmail.com Wed Jul 13 10:05:13 2011 From: dblaikie at gmail.com (David Blaikie) Date: Wed, 13 Jul 2011 08:05:13 -0700 Subject: [cfe-dev] -Warray-bounds seems over-zealous on Clang In-Reply-To: References: <20110712150748.GA4913@britannica.bec.de> <0F9FF1EB-96F2-4ACB-8070-32EFD6B23CD4@apple.com> <372E1D9D-8435-427E-9122-94A81E046187@apple.com> Message-ID: On Tue, Jul 12, 2011 at 4:59 PM, Peter Geoghegan wrote: > On 13 July 2011 00:28, David Blaikie wrote: > > > I think someone mentioned the idea of adding a separate warning for this > > narrower case and, in the case of compiling for c99, suggesting a fixup > of > > using a flexible array. In the case of c89 at least it'd be a separate > > warning that, if the pattern is used extensively in the codebase, could > be > > disabled separately from the more general warning (which would be > adjusted > > to ignore these cases). > > > > This would allow for the bug that was mentioned to have been found, while > > allowing you to disable this warning if you don't think the chance of > such > > bugs coming up is worth the code hygiene cost of the above construct or > the > > move to c99 would be worthwhile in your case. > > While strictly speaking that would be a valid solution, it would also > be overly-complex considering the benefits IMHO. I'd now have a flag > to pass to Clang, but only to Clang, despite the fact that it's > supposed to be a drop-in replacement for GCC. I'd now have to > explicitly indicate that I was using C89. > If you are compiling c89, that doesn't seem onerous - perhaps one day GCC could get smarter & start warning you about this or other superseded constructs if you continue to compile as c99 but avoid c99 features. So, options that seem to be being discussed include: 1) suppress this warning in all cases where the array is of length 1 and the last element in a struct 1.1) refinement: only when the length is specified explicitly and not via macro expansion, etc. (as John suggested) 1.2) refinement: under c99 recommend a fixup to use flexible arrays 2) split the warning in two, the second being the cases suppressed by the above option (probably less interesting if 1.1 is implemented) > Once again, the burden would be on application developers who are just > using a demonstrably mainstream idiom, > Mainstream in c89 with better alternatives in c99. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110713/2a99829e/attachment.html From kremenek at apple.com Wed Jul 13 10:49:04 2011 From: kremenek at apple.com (Ted Kremenek) Date: Wed, 13 Jul 2011 08:49:04 -0700 Subject: [cfe-dev] -Warray-bounds seems over-zealous on Clang In-Reply-To: References: <20110712150748.GA4913@britannica.bec.de> <0F9FF1EB-96F2-4ACB-8070-32EFD6B23CD4@apple.com> <372E1D9D-8435-427E-9122-94A81E046187@apple.com> Message-ID: <09911FA8-1679-4FDA-B363-5211C44A3DDE@apple.com> On Jul 13, 2011, at 8:05 AM, David Blaikie wrote: > So, options that seem to be being discussed include: > > 1) suppress this warning in all cases where the array is of length 1 and the last element in a struct > 1.1) refinement: only when the length is specified explicitly and not via macro expansion, etc. (as John suggested) > 1.2) refinement: under c99 recommend a fixup to use flexible arrays > 2) split the warning in two, the second being the cases suppressed by the above option (probably less interesting if 1.1 is implemented) > (1) and (2) aren't mutually exclusive. (2) is still useful when the heuristics implied by 1.1 and 1.2 aren't good enough. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110713/bf0abc77/attachment-0001.html From hhinnant at apple.com Wed Jul 13 10:51:40 2011 From: hhinnant at apple.com (Howard Hinnant) Date: Wed, 13 Jul 2011 11:51:40 -0400 Subject: [cfe-dev] small Mac OS lib++ fixes In-Reply-To: References: Message-ID: <4CBCD254-15EC-4BB4-B09D-8A07319B7CAB@apple.com> Thanks Toralf. For now I've reverted Sean's commit. Your patch looks to me like the right way to fix that commit, but I'd like Sean to look at it to ensure that it fits with where he's going with it. Howard On Jul 13, 2011, at 5:03 AM, Toralf Niebuhr wrote: > Hi, > > these are just two small patches fixing the libc++ build for Mac OS X. > > The first patch replaces an "#ifndef LIBCPP_STABLE_APPLE_ABI" with "#ifdef LIBCPP_STABLE_APPLE_ABI". > This is probably a copy and paste error as it's usually used with "#ifndef" > > The second patch replaces "__funcs()" with "func()". The underscore calls are encapsulated with the calls without underscores in the "locale" header. > > > > Toralf Niebuhr_______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From lattner at apple.com Wed Jul 13 12:44:57 2011 From: lattner at apple.com (Tanya Lattner) Date: Wed, 13 Jul 2011 10:44:57 -0700 Subject: [cfe-dev] OpenCL patch: vector literals (alternative patch) In-Reply-To: <225FC18A-3EA1-40BD-B22D-874FAA4E6F60@apple.com> References: <000001cc371d$e2322c60$a6968520$%Lokhmotov@arm.com> <9FDE1029-AFCA-4021-B1A1-9BC9E1952B27@apple.com> <000001cc3cb9$07cc7d40$176577c0$%Lokhmotov@arm.com> <225FC18A-3EA1-40BD-B22D-874FAA4E6F60@apple.com> Message-ID: <8B63AB54-1797-45B1-9A80-B864DB030D44@apple.com> Any other comments on this patch? I'd like to commit. -Tanya On Jul 7, 2011, at 4:41 PM, Tanya Lattner wrote: > I'm attaching an alternative patch which handles the missing vector splat case. It passes all the valid and invalid test cases you provided and I included those tests in the patch. It also uses the fix in SemaInit that you included which handles the crash for one invalid case. > > Thanks, > Tanya > > > On Jul 7, 2011, at 8:17 AM, Anton Lokhmotov wrote: > >> Hi Tanya, >> >> Many thanks for your prompt review! >> >>> All the support already exists for all the valid test cases >>> except the last one ((float4)( float )). One just has to modify >>> ActOnCastOfParenListExpr which is now BuildVectorLiteral to handle >>> the splat case. I have not modified our patch to match the recent >>> changes in TOT, but will do shortly. >> >> We would be happy with minimal changes to Clang provided that the OpenCL >> requirements are properly met, including handling invalid code. We >> specifically avoided using/modifying/breaking the existing functionality for >> AltiVec because the OpenCL syntax is quite different. Thus, we believe that >> for OpenCL CompilerInvocation::setLangDefaults() should disable Opts.AltiVec >> (and OTOH enable Opts.Bool - but sorry about that slipping into this patch). >> >>> Yes, you are 100% right that the test violates the OpenCL spec >>> (my mistake and haste in making a patch), but its catching a nasty >>> compiler crash and I'd rather try to modify the test instead of just >>> removing it. I've fixed this in TOT. >> >> Unfortunately, >> > >> void foo( uchar8 x ) >> { >> uchar4 val[4] = {{(uchar4){x.lo}}}; >> } >> >> is still invalid in OpenCL C. In particular, OpenCL doesn't allow using >> braces {} in vector literals. >> >> [Actually, I'm quite confused by this test. Since x.lo produces uchar4, the >> cast is superfluous? And then it attempts to initialize an array of vectors >> val[] from vector x.lo. But I actually would expect only val[0] to be >> initialized (backed by my experiments with gcc). But if it's just ensuring >> that the compiler doesn't crash, that's fine (in the AltiVec mode).] >> >>> For the invalid cases, I don't see why one needs to modify the parser, >>> but the last invalid case does crash the compiler which shouldn't ever >>> happen. >> >> Could you please ensure that the patch is applied correctly? It works fine >> with r134483. Specifically, this modification prevents the compiler from >> crashing: >> >> [11:17:50] Vitaly Lugovskiy: diff --git a/lib/Sema/SemaInit.cpp >> b/lib/Sema/SemaInit.cpp >> index 16ba2a2..17af145 100644 >> --- a/lib/Sema/SemaInit.cpp >> +++ b/lib/Sema/SemaInit.cpp >> @@ -769,7 +769,8 @@ void InitListChecker::CheckSubElementType(const >> InitializedEntity &Entity, >> // subaggregate, brace elision is assumed and the initializer is >> // considered for the initialization of the first member of >> // the subaggregate. >> - if (ElemType->isAggregateType() || ElemType->isVectorType()) { >> + if (!SemaRef.getLangOptions().OpenCL && >> + (ElemType->isAggregateType() || ElemType->isVectorType())) { >> CheckImplicitInitList(Entity, IList, ElemType, Index, StructuredList, >> StructuredIndex); >> ++StructuredIndex; >> >> If you provide your modifications to support vector literals, we will run >> our test cases with combinatorial coverage to ensure that the OpenCL >> requirements are met. >> >> Best wishes, >> Anton. >> >> >> > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From konstantin.weitz at googlemail.com Wed Jul 13 12:46:31 2011 From: konstantin.weitz at googlemail.com (Konstantin Weitz) Date: Wed, 13 Jul 2011 10:46:31 -0700 Subject: [cfe-dev] Finding members in a translation unit In-Reply-To: References: Message-ID: The solution is to set _langOpts.CPlusPlus = 1; On Thu, Jul 7, 2011 at 4:57 PM, Konstantin Weitz < konstantin.weitz at googlemail.com> wrote: > Greetings, > I posted the same question earlier today on the IRC channel but nobody was > able to answer it. > My goal is to find all member functions in a translation unit. > I was advised, that I can use CXXRecordDecl to iterate over the members of > one class. > > In order to get the CXXRecordDecl object for each class in a translation > unit, I'm overriding RecursiveASTVisitor's > VisitCXXRecordDecl member function. I would expect to get called for each > class. What actually happens is that > the VisitVarDecl member is called instead. > > Any idea why this is happening and how I can fix it? > > If you would like to reproduce my results, here is my code > > http://pastebin.com/eFhBfDzb > > Thanks in advance > Konstantin Weitz > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110713/e2ef9991/attachment.html From clattner at apple.com Wed Jul 13 13:11:37 2011 From: clattner at apple.com (Chris Lattner) Date: Wed, 13 Jul 2011 11:11:37 -0700 Subject: [cfe-dev] OpenCL patch: vector literals (alternative patch) In-Reply-To: <8B63AB54-1797-45B1-9A80-B864DB030D44@apple.com> References: <000001cc371d$e2322c60$a6968520$%Lokhmotov@arm.com> <9FDE1029-AFCA-4021-B1A1-9BC9E1952B27@apple.com> <000001cc3cb9$07cc7d40$176577c0$%Lokhmotov@arm.com> <225FC18A-3EA1-40BD-B22D-874FAA4E6F60@apple.com> <8B63AB54-1797-45B1-9A80-B864DB030D44@apple.com> Message-ID: Seems reasonable to me, but needs a testcase. -Chris On Jul 13, 2011, at 10:44 AM, Tanya Lattner wrote: > Any other comments on this patch? I'd like to commit. > > -Tanya > > On Jul 7, 2011, at 4:41 PM, Tanya Lattner wrote: > >> I'm attaching an alternative patch which handles the missing vector splat case. It passes all the valid and invalid test cases you provided and I included those tests in the patch. It also uses the fix in SemaInit that you included which handles the crash for one invalid case. >> >> Thanks, >> Tanya >> >> >> On Jul 7, 2011, at 8:17 AM, Anton Lokhmotov wrote: >> >>> Hi Tanya, >>> >>> Many thanks for your prompt review! >>> >>>> All the support already exists for all the valid test cases >>>> except the last one ((float4)( float )). One just has to modify >>>> ActOnCastOfParenListExpr which is now BuildVectorLiteral to handle >>>> the splat case. I have not modified our patch to match the recent >>>> changes in TOT, but will do shortly. >>> >>> We would be happy with minimal changes to Clang provided that the OpenCL >>> requirements are properly met, including handling invalid code. We >>> specifically avoided using/modifying/breaking the existing functionality for >>> AltiVec because the OpenCL syntax is quite different. Thus, we believe that >>> for OpenCL CompilerInvocation::setLangDefaults() should disable Opts.AltiVec >>> (and OTOH enable Opts.Bool - but sorry about that slipping into this patch). >>> >>>> Yes, you are 100% right that the test violates the OpenCL spec >>>> (my mistake and haste in making a patch), but its catching a nasty >>>> compiler crash and I'd rather try to modify the test instead of just >>>> removing it. I've fixed this in TOT. >>> >>> Unfortunately, >>> >> >>> void foo( uchar8 x ) >>> { >>> uchar4 val[4] = {{(uchar4){x.lo}}}; >>> } >>> >>> is still invalid in OpenCL C. In particular, OpenCL doesn't allow using >>> braces {} in vector literals. >>> >>> [Actually, I'm quite confused by this test. Since x.lo produces uchar4, the >>> cast is superfluous? And then it attempts to initialize an array of vectors >>> val[] from vector x.lo. But I actually would expect only val[0] to be >>> initialized (backed by my experiments with gcc). But if it's just ensuring >>> that the compiler doesn't crash, that's fine (in the AltiVec mode).] >>> >>>> For the invalid cases, I don't see why one needs to modify the parser, >>>> but the last invalid case does crash the compiler which shouldn't ever >>>> happen. >>> >>> Could you please ensure that the patch is applied correctly? It works fine >>> with r134483. Specifically, this modification prevents the compiler from >>> crashing: >>> >>> [11:17:50] Vitaly Lugovskiy: diff --git a/lib/Sema/SemaInit.cpp >>> b/lib/Sema/SemaInit.cpp >>> index 16ba2a2..17af145 100644 >>> --- a/lib/Sema/SemaInit.cpp >>> +++ b/lib/Sema/SemaInit.cpp >>> @@ -769,7 +769,8 @@ void InitListChecker::CheckSubElementType(const >>> InitializedEntity &Entity, >>> // subaggregate, brace elision is assumed and the initializer is >>> // considered for the initialization of the first member of >>> // the subaggregate. >>> - if (ElemType->isAggregateType() || ElemType->isVectorType()) { >>> + if (!SemaRef.getLangOptions().OpenCL && >>> + (ElemType->isAggregateType() || ElemType->isVectorType())) { >>> CheckImplicitInitList(Entity, IList, ElemType, Index, StructuredList, >>> StructuredIndex); >>> ++StructuredIndex; >>> >>> If you provide your modifications to support vector literals, we will run >>> our test cases with combinatorial coverage to ensure that the OpenCL >>> requirements are met. >>> >>> Best wishes, >>> Anton. >>> >>> >>> >> >> _______________________________________________ >> 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 Anton.Lokhmotov at arm.com Wed Jul 13 13:14:28 2011 From: Anton.Lokhmotov at arm.com (Anton Lokhmotov) Date: Wed, 13 Jul 2011 19:14:28 +0100 Subject: [cfe-dev] OpenCL patch: vector literals (alternative patch) In-Reply-To: <8B63AB54-1797-45B1-9A80-B864DB030D44@apple.com> References: <000001cc371d$e2322c60$a6968520$%Lokhmotov@arm.com> <9FDE1029-AFCA-4021-B1A1-9BC9E1952B27@apple.com> <000001cc3cb9$07cc7d40$176577c0$%Lokhmotov@arm.com> <225FC18A-3EA1-40BD-B22D-874FAA4E6F60@apple.com> <8B63AB54-1797-45B1-9A80-B864DB030D44@apple.com> Message-ID: <000401cc4188$b4b21870$1e164950$@Lokhmotov@arm.com> Hi Tanya, We have merged your patch and ours. It seems to work fine for both valid and invalid test cases. John McCall wrote: > So this should be legal if C99 is an acceptable base language for > OpenCL and the following is valid: > uchar4 vec = { x.lo }; OpenCL is a superset of a subset of C99, so the fist condition is met. However, section 6.1.6 of the OpenCL specification says that only (typen)(...) is valid syntax for initializing vector literals, not {...}. So ideally Clang would reject it (but I appreciate this is undesirable for legacy reasons). Thanks, Anton. -------------- next part -------------- A non-text attachment was scrubbed... Name: vector-literals.patch Type: application/octet-stream Size: 9245 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110713/c759d9f1/attachment-0001.obj From lattner at apple.com Wed Jul 13 13:18:21 2011 From: lattner at apple.com (Tanya Lattner) Date: Wed, 13 Jul 2011 11:18:21 -0700 Subject: [cfe-dev] OpenCL patch: vector literals (alternative patch) In-Reply-To: References: <000001cc371d$e2322c60$a6968520$%Lokhmotov@arm.com> <9FDE1029-AFCA-4021-B1A1-9BC9E1952B27@apple.com> <000001cc3cb9$07cc7d40$176577c0$%Lokhmotov@arm.com> <225FC18A-3EA1-40BD-B22D-874FAA4E6F60@apple.com> <8B63AB54-1797-45B1-9A80-B864DB030D44@apple.com> Message-ID: <87377883-3FCF-43F9-B277-C0B86898B15A@apple.com> Ah, the test cases somehow didn't end up in the patch, but they are the same as in Anton's patch. -Tanya On Jul 13, 2011, at 11:11 AM, Chris Lattner wrote: > Seems reasonable to me, but needs a testcase. > > -Chris > > On Jul 13, 2011, at 10:44 AM, Tanya Lattner wrote: > >> Any other comments on this patch? I'd like to commit. >> >> -Tanya >> >> On Jul 7, 2011, at 4:41 PM, Tanya Lattner wrote: >> >>> I'm attaching an alternative patch which handles the missing vector splat case. It passes all the valid and invalid test cases you provided and I included those tests in the patch. It also uses the fix in SemaInit that you included which handles the crash for one invalid case. >>> >>> Thanks, >>> Tanya >>> >>> >>> On Jul 7, 2011, at 8:17 AM, Anton Lokhmotov wrote: >>> >>>> Hi Tanya, >>>> >>>> Many thanks for your prompt review! >>>> >>>>> All the support already exists for all the valid test cases >>>>> except the last one ((float4)( float )). One just has to modify >>>>> ActOnCastOfParenListExpr which is now BuildVectorLiteral to handle >>>>> the splat case. I have not modified our patch to match the recent >>>>> changes in TOT, but will do shortly. >>>> >>>> We would be happy with minimal changes to Clang provided that the OpenCL >>>> requirements are properly met, including handling invalid code. We >>>> specifically avoided using/modifying/breaking the existing functionality for >>>> AltiVec because the OpenCL syntax is quite different. Thus, we believe that >>>> for OpenCL CompilerInvocation::setLangDefaults() should disable Opts.AltiVec >>>> (and OTOH enable Opts.Bool - but sorry about that slipping into this patch). >>>> >>>>> Yes, you are 100% right that the test violates the OpenCL spec >>>>> (my mistake and haste in making a patch), but its catching a nasty >>>>> compiler crash and I'd rather try to modify the test instead of just >>>>> removing it. I've fixed this in TOT. >>>> >>>> Unfortunately, >>>> >>> >>>> void foo( uchar8 x ) >>>> { >>>> uchar4 val[4] = {{(uchar4){x.lo}}}; >>>> } >>>> >>>> is still invalid in OpenCL C. In particular, OpenCL doesn't allow using >>>> braces {} in vector literals. >>>> >>>> [Actually, I'm quite confused by this test. Since x.lo produces uchar4, the >>>> cast is superfluous? And then it attempts to initialize an array of vectors >>>> val[] from vector x.lo. But I actually would expect only val[0] to be >>>> initialized (backed by my experiments with gcc). But if it's just ensuring >>>> that the compiler doesn't crash, that's fine (in the AltiVec mode).] >>>> >>>>> For the invalid cases, I don't see why one needs to modify the parser, >>>>> but the last invalid case does crash the compiler which shouldn't ever >>>>> happen. >>>> >>>> Could you please ensure that the patch is applied correctly? It works fine >>>> with r134483. Specifically, this modification prevents the compiler from >>>> crashing: >>>> >>>> [11:17:50] Vitaly Lugovskiy: diff --git a/lib/Sema/SemaInit.cpp >>>> b/lib/Sema/SemaInit.cpp >>>> index 16ba2a2..17af145 100644 >>>> --- a/lib/Sema/SemaInit.cpp >>>> +++ b/lib/Sema/SemaInit.cpp >>>> @@ -769,7 +769,8 @@ void InitListChecker::CheckSubElementType(const >>>> InitializedEntity &Entity, >>>> // subaggregate, brace elision is assumed and the initializer is >>>> // considered for the initialization of the first member of >>>> // the subaggregate. >>>> - if (ElemType->isAggregateType() || ElemType->isVectorType()) { >>>> + if (!SemaRef.getLangOptions().OpenCL && >>>> + (ElemType->isAggregateType() || ElemType->isVectorType())) { >>>> CheckImplicitInitList(Entity, IList, ElemType, Index, StructuredList, >>>> StructuredIndex); >>>> ++StructuredIndex; >>>> >>>> If you provide your modifications to support vector literals, we will run >>>> our test cases with combinatorial coverage to ensure that the OpenCL >>>> requirements are met. >>>> >>>> Best wishes, >>>> Anton. >>>> >>>> >>>> >>> >>> _______________________________________________ >>> 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 rjmccall at apple.com Wed Jul 13 13:19:05 2011 From: rjmccall at apple.com (John McCall) Date: Wed, 13 Jul 2011 11:19:05 -0700 Subject: [cfe-dev] OpenCL patch: vector literals (alternative patch) In-Reply-To: <000401cc4188$b4b21870$1e164950$%Lokhmotov@arm.com> References: <000001cc371d$e2322c60$a6968520$%Lokhmotov@arm.com> <9FDE1029-AFCA-4021-B1A1-9BC9E1952B27@apple.com> <000001cc3cb9$07cc7d40$176577c0$%Lokhmotov@arm.com> <225FC18A-3EA1-40BD-B22D-874FAA4E6F60@apple.com> <8B63AB54-1797-45B1-9A80-B864DB030D44@apple.com> <000401cc4188$b4b21870$1e164950$%Lokhmotov@arm.com> Message-ID: <81D86CF8-C6AD-4540-9FF4-C0DC36350B72@apple.com> On Jul 13, 2011, at 11:14 AM, Anton Lokhmotov wrote: > John McCall wrote: >> So this should be legal if C99 is an acceptable base language for >> OpenCL and the following is valid: >> uchar4 vec = { x.lo }; > OpenCL is a superset of a subset of C99, so the fist condition is met. > However, section 6.1.6 of the OpenCL specification says that only > (typen)(...) is valid syntax for initializing vector literals, not {...}. I read this section as specifying a new kind of expression, the OpenCL vector literal, rather than prohibiting forming a vector in other ways. The standard doesn't lay down rules for initializing vectors as aggregates, but as you say, we clearly already permit it and should not go back on it. I'll let Tanya review the merged patch. John. From lattner at apple.com Wed Jul 13 13:21:49 2011 From: lattner at apple.com (Tanya Lattner) Date: Wed, 13 Jul 2011 11:21:49 -0700 Subject: [cfe-dev] OpenCL patch: vector literals (alternative patch) In-Reply-To: <000401cc4188$b4b21870$1e164950$%Lokhmotov@arm.com> References: <000001cc371d$e2322c60$a6968520$%Lokhmotov@arm.com> <9FDE1029-AFCA-4021-B1A1-9BC9E1952B27@apple.com> <000001cc3cb9$07cc7d40$176577c0$%Lokhmotov@arm.com> <225FC18A-3EA1-40BD-B22D-874FAA4E6F60@apple.com> <8B63AB54-1797-45B1-9A80-B864DB030D44@apple.com> <000401cc4188$b4b21870$1e164950$%Lokhmotov@arm.com> Message-ID: <99318B7C-E4C7-4C1F-96C3-911C501F20F4@apple.com> Anton, You shouldn't need to add anything from your patch to mine to get the test cases to work. Why do you think this extra code is necessary? Do you have a test case that isn't in the invalid/valid files that fails? -Tanya On Jul 13, 2011, at 11:14 AM, Anton Lokhmotov wrote: > Hi Tanya, > > We have merged your patch and ours. It seems to work fine for both valid > and invalid test cases. > > John McCall wrote: >> So this should be legal if C99 is an acceptable base language for >> OpenCL and the following is valid: >> uchar4 vec = { x.lo }; > OpenCL is a superset of a subset of C99, so the fist condition is met. > However, section 6.1.6 of the OpenCL specification says that only > (typen)(...) is valid syntax for initializing vector literals, not {...}. > So ideally Clang would reject it (but I appreciate this is undesirable for > legacy reasons). > > Thanks, > Anton. From lattner at apple.com Wed Jul 13 13:26:36 2011 From: lattner at apple.com (Tanya Lattner) Date: Wed, 13 Jul 2011 11:26:36 -0700 Subject: [cfe-dev] OpenCL patch: vector literals (alternative patch) In-Reply-To: References: <000001cc371d$e2322c60$a6968520$%Lokhmotov@arm.com> <9FDE1029-AFCA-4021-B1A1-9BC9E1952B27@apple.com> <000001cc3cb9$07cc7d40$176577c0$%Lokhmotov@arm.com> <225FC18A-3EA1-40BD-B22D-874FAA4E6F60@apple.com> <8B63AB54-1797-45B1-9A80-B864DB030D44@apple.com> Message-ID: <81723D5B-FB39-40A1-8782-06018705F09B@apple.com> Attaching patch that actually has the test cases that Anton wrote: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenCL-VectorLiterals1.patch Type: application/octet-stream Size: 4718 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110713/7bd1630b/attachment.obj -------------- next part -------------- -Tanya On Jul 13, 2011, at 11:11 AM, Chris Lattner wrote: > Seems reasonable to me, but needs a testcase. > > -Chris > > On Jul 13, 2011, at 10:44 AM, Tanya Lattner wrote: > >> Any other comments on this patch? I'd like to commit. >> >> -Tanya >> >> On Jul 7, 2011, at 4:41 PM, Tanya Lattner wrote: >> >>> I'm attaching an alternative patch which handles the missing vector splat case. It passes all the valid and invalid test cases you provided and I included those tests in the patch. It also uses the fix in SemaInit that you included which handles the crash for one invalid case. >>> >>> Thanks, >>> Tanya >>> >>> >>> On Jul 7, 2011, at 8:17 AM, Anton Lokhmotov wrote: >>> >>>> Hi Tanya, >>>> >>>> Many thanks for your prompt review! >>>> >>>>> All the support already exists for all the valid test cases >>>>> except the last one ((float4)( float )). One just has to modify >>>>> ActOnCastOfParenListExpr which is now BuildVectorLiteral to handle >>>>> the splat case. I have not modified our patch to match the recent >>>>> changes in TOT, but will do shortly. >>>> >>>> We would be happy with minimal changes to Clang provided that the OpenCL >>>> requirements are properly met, including handling invalid code. We >>>> specifically avoided using/modifying/breaking the existing functionality for >>>> AltiVec because the OpenCL syntax is quite different. Thus, we believe that >>>> for OpenCL CompilerInvocation::setLangDefaults() should disable Opts.AltiVec >>>> (and OTOH enable Opts.Bool - but sorry about that slipping into this patch). >>>> >>>>> Yes, you are 100% right that the test violates the OpenCL spec >>>>> (my mistake and haste in making a patch), but its catching a nasty >>>>> compiler crash and I'd rather try to modify the test instead of just >>>>> removing it. I've fixed this in TOT. >>>> >>>> Unfortunately, >>>> >>> >>>> void foo( uchar8 x ) >>>> { >>>> uchar4 val[4] = {{(uchar4){x.lo}}}; >>>> } >>>> >>>> is still invalid in OpenCL C. In particular, OpenCL doesn't allow using >>>> braces {} in vector literals. >>>> >>>> [Actually, I'm quite confused by this test. Since x.lo produces uchar4, the >>>> cast is superfluous? And then it attempts to initialize an array of vectors >>>> val[] from vector x.lo. But I actually would expect only val[0] to be >>>> initialized (backed by my experiments with gcc). But if it's just ensuring >>>> that the compiler doesn't crash, that's fine (in the AltiVec mode).] >>>> >>>>> For the invalid cases, I don't see why one needs to modify the parser, >>>>> but the last invalid case does crash the compiler which shouldn't ever >>>>> happen. >>>> >>>> Could you please ensure that the patch is applied correctly? It works fine >>>> with r134483. Specifically, this modification prevents the compiler from >>>> crashing: >>>> >>>> [11:17:50] Vitaly Lugovskiy: diff --git a/lib/Sema/SemaInit.cpp >>>> b/lib/Sema/SemaInit.cpp >>>> index 16ba2a2..17af145 100644 >>>> --- a/lib/Sema/SemaInit.cpp >>>> +++ b/lib/Sema/SemaInit.cpp >>>> @@ -769,7 +769,8 @@ void InitListChecker::CheckSubElementType(const >>>> InitializedEntity &Entity, >>>> // subaggregate, brace elision is assumed and the initializer is >>>> // considered for the initialization of the first member of >>>> // the subaggregate. >>>> - if (ElemType->isAggregateType() || ElemType->isVectorType()) { >>>> + if (!SemaRef.getLangOptions().OpenCL && >>>> + (ElemType->isAggregateType() || ElemType->isVectorType())) { >>>> CheckImplicitInitList(Entity, IList, ElemType, Index, StructuredList, >>>> StructuredIndex); >>>> ++StructuredIndex; >>>> >>>> If you provide your modifications to support vector literals, we will run >>>> our test cases with combinatorial coverage to ensure that the OpenCL >>>> requirements are met. >>>> >>>> Best wishes, >>>> Anton. >>>> >>>> >>>> >>> >>> _______________________________________________ >>> 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 Anton.Lokhmotov at arm.com Wed Jul 13 13:40:34 2011 From: Anton.Lokhmotov at arm.com (Anton Lokhmotov) Date: Wed, 13 Jul 2011 19:40:34 +0100 Subject: [cfe-dev] OpenCL patch: vector literals (alternative patch) In-Reply-To: <99318B7C-E4C7-4C1F-96C3-911C501F20F4@apple.com> References: <000001cc371d$e2322c60$a6968520$%Lokhmotov@arm.com> <9FDE1029-AFCA-4021-B1A1-9BC9E1952B27@apple.com> <000001cc3cb9$07cc7d40$176577c0$%Lokhmotov@arm.com> <225FC18A-3EA1-40BD-B22D-874FAA4E6F60@apple.com> <8B63AB54-1797-45B1-9A80-B864DB030D44@apple.com> <000401cc4188$b4b21870$1e164950$%Lokhmotov@arm.com> <99318B7C-E4C7-4C1F-96C3-911C501F20F4@apple.com> Message-ID: <000801cc418c$59c03f60$0d40be20$@Lokhmotov@arm.com> Hi Tanya, > You shouldn't need to add anything from your patch to mine to get the > test cases to work. Why do you think this extra code is necessary? Do > you have a test case that isn't in the invalid/valid files that fails? I'm a bit surprised this test passes without our modifications: > ((float4)(1.0f))++; // expected-error{{expression is not assignable}} Also, I was in a hurry and didn't include invalid tests for explicit and implicit conversions between vector types, e.g. uint4 u = (uint4)(1); int4 i = u; // invalid implicit conversion int4 e = (int4)u; // invalid explicit conversion Best regards, Anton. P.S. I won't be able to reply until early next week - apologies in advance. From lattner at apple.com Wed Jul 13 13:43:58 2011 From: lattner at apple.com (Tanya Lattner) Date: Wed, 13 Jul 2011 11:43:58 -0700 Subject: [cfe-dev] OpenCL patch: vector literals (alternative patch) In-Reply-To: <000801cc418c$59c03f60$0d40be20$%Lokhmotov@arm.com> References: <000001cc371d$e2322c60$a6968520$%Lokhmotov@arm.com> <9FDE1029-AFCA-4021-B1A1-9BC9E1952B27@apple.com> <000001cc3cb9$07cc7d40$176577c0$%Lokhmotov@arm.com> <225FC18A-3EA1-40BD-B22D-874FAA4E6F60@apple.com> <8B63AB54-1797-45B1-9A80-B864DB030D44@apple.com> <000401cc4188$b4b21870$1e164950$%Lokhmotov@arm.com> <99318B7C-E4C7-4C1F-96C3-911C501F20F4@apple.com> <000801cc418c$59c03f60$0d40be20$%Lokhmotov@arm.com> Message-ID: <364997A5-35A0-47A8-BEDE-025E5512C935@apple.com> Anton, I'll commit what I have, and when you get more time next week, you can re-evaluate if the additional work is needed. This obviously doesn't have to be the final patch if there are indeed outstanding issues. Hopefully thats sounds fair to you. -Tanya On Jul 13, 2011, at 11:40 AM, Anton Lokhmotov wrote: > Hi Tanya, > >> You shouldn't need to add anything from your patch to mine to get the >> test cases to work. Why do you think this extra code is necessary? Do >> you have a test case that isn't in the invalid/valid files that fails? > I'm a bit surprised this test passes without our modifications: >> ((float4)(1.0f))++; // expected-error{{expression is not assignable}} > > Also, I was in a hurry and didn't include invalid tests for explicit and > implicit conversions between vector types, e.g. > > uint4 u = (uint4)(1); > int4 i = u; // invalid implicit conversion > int4 e = (int4)u; // invalid explicit conversion > > Best regards, > Anton. > > P.S. I won't be able to reply until early next week - apologies in advance. > > > From nicola.gigante at gmail.com Wed Jul 13 15:10:59 2011 From: nicola.gigante at gmail.com (Nicola Gigante) Date: Wed, 13 Jul 2011 22:10:59 +0200 Subject: [cfe-dev] -Warray-bounds seems over-zealous on Clang In-Reply-To: <09911FA8-1679-4FDA-B363-5211C44A3DDE@apple.com> References: <20110712150748.GA4913@britannica.bec.de> <0F9FF1EB-96F2-4ACB-8070-32EFD6B23CD4@apple.com> <372E1D9D-8435-427E-9122-94A81E046187@apple.com> <09911FA8-1679-4FDA-B363-5211C44A3DDE@apple.com> Message-ID: <6CB2BAE3-D4D3-4299-A526-916B51FBD9D0@gmail.com> Hello Il giorno 13/lug/2011, alle ore 17.49, Ted Kremenek ha scritto: > On Jul 13, 2011, at 8:05 AM, David Blaikie wrote: > >> So, options that seem to be being discussed include: >> >> 1) suppress this warning in all cases where the array is of length 1 and the last element in a struct >> 1.1) refinement: only when the length is specified explicitly and not via macro expansion, etc. (as John suggested) >> 1.2) refinement: under c99 recommend a fixup to use flexible arrays >> 2) split the warning in two, the second being the cases suppressed by the above option (probably less interesting if 1.1 is implemented) >> > > (1) and (2) aren't mutually exclusive. (2) is still useful when the heuristics implied by 1.1 and 1.2 aren't good enough. I've tried to write such a patch, as it seemed simple, but I'm stuck because I don't know enough about internal clang's APIs yet. Until now, I've come up with the simple patch attached, that disables the warning if the array is declared inside a record type and the size is one. Questions: - From the NamedDecl* object representing the array declaration, how do I know if it's declared last in the struct? - From the NamedDecl*, how do I know if the size of the member declaration comes from a macro expansion? Thanks, Nicola -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110713/eed6b8b5/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: pgsql_warning.patch Type: application/octet-stream Size: 698 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110713/eed6b8b5/attachment.obj -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110713/eed6b8b5/attachment-0001.html From rjmccall at apple.com Wed Jul 13 15:21:31 2011 From: rjmccall at apple.com (John McCall) Date: Wed, 13 Jul 2011 13:21:31 -0700 Subject: [cfe-dev] -Warray-bounds seems over-zealous on Clang In-Reply-To: <6CB2BAE3-D4D3-4299-A526-916B51FBD9D0@gmail.com> References: <20110712150748.GA4913@britannica.bec.de> <0F9FF1EB-96F2-4ACB-8070-32EFD6B23CD4@apple.com> <372E1D9D-8435-427E-9122-94A81E046187@apple.com> <09911FA8-1679-4FDA-B363-5211C44A3DDE@apple.com> <6CB2BAE3-D4D3-4299-A526-916B51FBD9D0@gmail.com> Message-ID: On Jul 13, 2011, at 1:10 PM, Nicola Gigante wrote: > Il giorno 13/lug/2011, alle ore 17.49, Ted Kremenek ha scritto: >> On Jul 13, 2011, at 8:05 AM, David Blaikie wrote: >> >>> So, options that seem to be being discussed include: >>> >>> 1) suppress this warning in all cases where the array is of length 1 and the last element in a struct >>> 1.1) refinement: only when the length is specified explicitly and not via macro expansion, etc. (as John suggested) >>> 1.2) refinement: under c99 recommend a fixup to use flexible arrays >>> 2) split the warning in two, the second being the cases suppressed by the above option (probably less interesting if 1.1 is implemented) >>> >> >> (1) and (2) aren't mutually exclusive. (2) is still useful when the heuristics implied by 1.1 and 1.2 aren't good enough. > > I've tried to write such a patch, as it seemed simple, but I'm stuck because I don't know enough > about internal clang's APIs yet. > Until now, I've come up with the simple patch attached, that disables the warning if > the array is declared inside a record type and the size is one. > Questions: > - From the NamedDecl* object representing the array declaration, how do I know if it's declared last in the struct? It should be a FieldDecl, and its parent should be a RecordDecl. I don't think there's a cleaner solution than just iterating through the fields of the record and complaining if it's not the last one. > - From the NamedDecl*, how do I know if the size of the member declaration comes from a macro expansion? The exception should apply to: - a field of a struct, where - the field's TypeLoc is a (possibly parenthesized) ConstantArrayTypeLoc and - the size expression in that TypeLoc is a (possibly parenthesized) IntegerLiteral and - the source location of that literal is not a macro ID. John. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110713/ecb18a5d/attachment.html From rjmccall at apple.com Wed Jul 13 15:27:10 2011 From: rjmccall at apple.com (John McCall) Date: Wed, 13 Jul 2011 13:27:10 -0700 Subject: [cfe-dev] -Warray-bounds seems over-zealous on Clang In-Reply-To: References: <20110712150748.GA4913@britannica.bec.de> <0F9FF1EB-96F2-4ACB-8070-32EFD6B23CD4@apple.com> <372E1D9D-8435-427E-9122-94A81E046187@apple.com> <09911FA8-1679-4FDA-B363-5211C44A3DDE@apple.com> <6CB2BAE3-D4D3-4299-A526-916B51FBD9D0@gmail.com> Message-ID: <2B2063DE-0ED0-412B-9343-FBB7F0A15FB1@apple.com> On Jul 13, 2011, at 1:21 PM, John McCall wrote: > On Jul 13, 2011, at 1:10 PM, Nicola Gigante wrote: >> Il giorno 13/lug/2011, alle ore 17.49, Ted Kremenek ha scritto: >>> On Jul 13, 2011, at 8:05 AM, David Blaikie wrote: >>> >>>> So, options that seem to be being discussed include: >>>> >>>> 1) suppress this warning in all cases where the array is of length 1 and the last element in a struct >>>> 1.1) refinement: only when the length is specified explicitly and not via macro expansion, etc. (as John suggested) >>>> 1.2) refinement: under c99 recommend a fixup to use flexible arrays >>>> 2) split the warning in two, the second being the cases suppressed by the above option (probably less interesting if 1.1 is implemented) >>>> >>> >>> (1) and (2) aren't mutually exclusive. (2) is still useful when the heuristics implied by 1.1 and 1.2 aren't good enough. >> >> I've tried to write such a patch, as it seemed simple, but I'm stuck because I don't know enough >> about internal clang's APIs yet. >> Until now, I've come up with the simple patch attached, that disables the warning if >> the array is declared inside a record type and the size is one. >> Questions: >> - From the NamedDecl* object representing the array declaration, how do I know if it's declared last in the struct? > > It should be a FieldDecl, and its parent should be a RecordDecl. I don't think there's a cleaner solution than just iterating through the fields of the record and complaining if it's not the last one. Oh, of course there's getNextDeclInContext(); you could just walk those (until you get a null pointer back) and make sure there aren't any FieldDecls. John. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110713/f500cf90/attachment-0001.html From peter at 2ndquadrant.com Wed Jul 13 17:23:18 2011 From: peter at 2ndquadrant.com (Peter Geoghegan) Date: Wed, 13 Jul 2011 23:23:18 +0100 Subject: [cfe-dev] -Warray-bounds seems over-zealous on Clang In-Reply-To: <6CB2BAE3-D4D3-4299-A526-916B51FBD9D0@gmail.com> References: <20110712150748.GA4913@britannica.bec.de> <0F9FF1EB-96F2-4ACB-8070-32EFD6B23CD4@apple.com> <372E1D9D-8435-427E-9122-94A81E046187@apple.com> <09911FA8-1679-4FDA-B363-5211C44A3DDE@apple.com> <6CB2BAE3-D4D3-4299-A526-916B51FBD9D0@gmail.com> Message-ID: On 13 July 2011 21:10, Nicola Gigante wrote: > I've tried to write such a patch, as it seemed simple, but I'm stuck because > I don't know enough > about internal clang's APIs yet. > Until now, I've come up with the simple patch attached, that disables the > warning if > the array is declared inside a record type and the size is one. Thanks for your efforts. I wish I was familiar enough with the Clang code base to help. -- Peter Geoghegan ? ? ? http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services From rtrieu at google.com Wed Jul 13 19:15:13 2011 From: rtrieu at google.com (Richard Trieu) Date: Wed, 13 Jul 2011 17:15:13 -0700 Subject: [cfe-dev] -Wsign-compare warns on different signs of operands for ?: Message-ID: For code such as: void f(unsigned int u, int i) { (void) (true ? u : i); } When run with -Wsign-compare, Clang gives the following warning. warning: operands of ? are integers of different signs: 'unsigned int' and 'int' [-Wsign-compare] (void) (true ? u : i); ^ ~ ~ Yet, no comparison is going on between u and i, so the warning seems out of place for grouping with -Wsign-compare. I think that it would be better is this warning was pulled out of the -Wsign-compare diagnostic group. Also, gcc's -Wsign-compare does not warn on this code, so this change will make Clang's sign compare closer to gcc's. Does this seem reasonable? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110713/bbd18d72/attachment.html From rjmccall at apple.com Thu Jul 14 00:08:19 2011 From: rjmccall at apple.com (John McCall) Date: Wed, 13 Jul 2011 22:08:19 -0700 Subject: [cfe-dev] -Wsign-compare warns on different signs of operands for ?: In-Reply-To: References: Message-ID: On Jul 13, 2011, at 5:15 PM, Richard Trieu wrote: > For code such as: > > void f(unsigned int u, int i) { > (void) (true ? u : i); > } > > When run with -Wsign-compare, Clang gives the following warning. > > warning: operands of ? are integers of different signs: > 'unsigned int' and 'int' [-Wsign-compare] > (void) (true ? u : i); > ^ ~ ~ > > Yet, no comparison is going on between u and i, so the warning seems out of place for grouping with -Wsign-compare. I think that it would be better is this warning was pulled out of the -Wsign-compare diagnostic group. Also, gcc's -Wsign-compare does not warn on this code, so this change will make Clang's sign compare closer to gcc's. Does this seem reasonable? gcc's -Wsign-compare does warn on this code if you make the condition non-trivial. Clang is just missing that special case. John. From nicola.gigante at gmail.com Thu Jul 14 03:28:48 2011 From: nicola.gigante at gmail.com (Nicola Gigante) Date: Thu, 14 Jul 2011 10:28:48 +0200 Subject: [cfe-dev] -Warray-bounds seems over-zealous on Clang In-Reply-To: References: <20110712150748.GA4913@britannica.bec.de> <0F9FF1EB-96F2-4ACB-8070-32EFD6B23CD4@apple.com> <372E1D9D-8435-427E-9122-94A81E046187@apple.com> <09911FA8-1679-4FDA-B363-5211C44A3DDE@apple.com> <6CB2BAE3-D4D3-4299-A526-916B51FBD9D0@gmail.com> Message-ID: <7E1AE439-EDFC-4B68-A438-B7A45A1FBD35@gmail.com> Il giorno 13/lug/2011, alle ore 22.21, John McCall ha scritto: > > The exception should apply to: > - a field of a struct, where ok > - the field's TypeLoc is a (possibly parenthesized) ConstantArrayTypeLoc and ok, do you mean that getTypeLocClass() == ConstantArray? > - the size expression in that TypeLoc is a (possibly parenthesized) IntegerLiteral and where do I get the size expression from the typeloc? > - the source location of that literal is not a macro ID. > > John. Nicola From rjmccall at apple.com Thu Jul 14 12:05:30 2011 From: rjmccall at apple.com (John McCall) Date: Thu, 14 Jul 2011 10:05:30 -0700 Subject: [cfe-dev] -Warray-bounds seems over-zealous on Clang In-Reply-To: <7E1AE439-EDFC-4B68-A438-B7A45A1FBD35@gmail.com> References: <20110712150748.GA4913@britannica.bec.de> <0F9FF1EB-96F2-4ACB-8070-32EFD6B23CD4@apple.com> <372E1D9D-8435-427E-9122-94A81E046187@apple.com> <09911FA8-1679-4FDA-B363-5211C44A3DDE@apple.com> <6CB2BAE3-D4D3-4299-A526-916B51FBD9D0@gmail.com> <7E1AE439-EDFC-4B68-A438-B7A45A1FBD35@gmail.com> Message-ID: <695AF2B1-3555-4AF7-B475-3776BBEAC82D@apple.com> On Jul 14, 2011, at 1:28 AM, Nicola Gigante wrote: >> - the field's TypeLoc is a (possibly parenthesized) ConstantArrayTypeLoc and > ok, do you mean that getTypeLocClass() == ConstantArray? isa, please, but that's the idea. >> - the size expression in that TypeLoc is a (possibly parenthesized) IntegerLiteral and > where do I get the size expression from the typeloc? Look at the methods on ArrayTypeLoc. John. From matthieu.monrocq at gmail.com Thu Jul 14 14:34:14 2011 From: matthieu.monrocq at gmail.com (Matthieu Monrocq) Date: Thu, 14 Jul 2011 21:34:14 +0200 Subject: [cfe-dev] Spurious warning: unused parameter when used only in an expression error-ing out Message-ID: Hello clang, I made a strange discovery with a small helper function I wrote: If one test the following (short) program: struct A; void sink(A,int); void func(A const& a, int x, int y) { sink(a + x, y); } The following errors get emitted: $ clang -fsyntax-only -Wunused-parameter unused_parameter.cpp unused_parameter.cpp:15:11: error: invalid operands to binary expression ('const A' and 'int') sink(a + x, y); ~ ^ ~ unused_parameter.cpp:14:34: warning: unused parameter 'y' [-Wunused-parameter] void func(A const& a, int x, int y) { ^ 1 warning and 1 error generated. The first one is expected, however it seems its presence somehow short-circuit the analysis of the whole expression and as a result we get the spurious warning... I feel that this is unwelcome, because it obfuscates the true error (especially since I tend to compile with -Werror). For reference, I use the following version of Clang: $ clang --version clang version 3.0 (trunk 132889) Target: i686-pc-mingw32 Thread model: posix I could not find any mention of such an issue with my Google-fu in the cfe-dev archive, so please let me know if it already came up and it was deemed unimportant. -- Matthieu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110714/908e5437/attachment.html From rtrieu at google.com Thu Jul 14 14:58:09 2011 From: rtrieu at google.com (Richard Trieu) Date: Thu, 14 Jul 2011 12:58:09 -0700 Subject: [cfe-dev] -Wsign-compare warns on different signs of operands for ?: In-Reply-To: References: Message-ID: On Wed, Jul 13, 2011 at 10:08 PM, John McCall wrote: > > On Jul 13, 2011, at 5:15 PM, Richard Trieu wrote: > > > For code such as: > > > > void f(unsigned int u, int i) { > > (void) (true ? u : i); > > } > > > > When run with -Wsign-compare, Clang gives the following warning. > > > > warning: operands of ? are integers of different signs: > > 'unsigned int' and 'int' [-Wsign-compare] > > (void) (true ? u : i); > > ^ ~ ~ > > > > Yet, no comparison is going on between u and i, so the warning seems out > of place for grouping with -Wsign-compare. I think that it would be better > is this warning was pulled out of the -Wsign-compare diagnostic group. > Also, gcc's -Wsign-compare does not warn on this code, so this change will > make Clang's sign compare closer to gcc's. Does this seem reasonable? > > gcc's -Wsign-compare does warn on this code if you make the condition > non-trivial. Clang is just missing that special case. > > John. > Could you give an example of a non-trivial case that gcc does warn on? I've tried: void f(bool b, unsigned int u, int i) { (void) (b ? u : i); } void f(unsigned int u, int i) { (void) ((i > 5) ? u : i); } but both don't give an warning from gcc -Wsign-compare. Clang's -Wsign-compare warns on both. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110714/14318de2/attachment.html From rjmccall at apple.com Thu Jul 14 15:11:17 2011 From: rjmccall at apple.com (John McCall) Date: Thu, 14 Jul 2011 13:11:17 -0700 Subject: [cfe-dev] -Wsign-compare warns on different signs of operands for ?: In-Reply-To: References: Message-ID: On Jul 14, 2011, at 12:58 PM, Richard Trieu wrote: > On Wed, Jul 13, 2011 at 10:08 PM, John McCall wrote: > > On Jul 13, 2011, at 5:15 PM, Richard Trieu wrote: > > > For code such as: > > > > void f(unsigned int u, int i) { > > (void) (true ? u : i); > > } > > > > When run with -Wsign-compare, Clang gives the following warning. > > > > warning: operands of ? are integers of different signs: > > 'unsigned int' and 'int' [-Wsign-compare] > > (void) (true ? u : i); > > ^ ~ ~ > > > > Yet, no comparison is going on between u and i, so the warning seems out of place for grouping with -Wsign-compare. I think that it would be better is this warning was pulled out of the -Wsign-compare diagnostic group. Also, gcc's -Wsign-compare does not warn on this code, so this change will make Clang's sign compare closer to gcc's. Does this seem reasonable? > > gcc's -Wsign-compare does warn on this code if you make the condition non-trivial. Clang is just missing that special case. > > John. > > Could you give an example of a non-trivial case that gcc does warn on? I've tried: > > void f(bool b, unsigned int u, int i) { > (void) (b ? u : i); > } > > void f(unsigned int u, int i) { > (void) ((i > 5) ? u : i); > } > > but both don't give an warning from gcc -Wsign-compare. Clang's -Wsign-compare warns on both. Aha. From 'bool' I take it that you're talking about C++. You're correct that G++'s -Wsign-compare does not warn about conditional operators. GCC's does. In clang, we decided that that inconsistency wasn't worth emulating. John. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110714/0bc588d7/attachment.html From rtrieu at google.com Thu Jul 14 15:32:15 2011 From: rtrieu at google.com (Richard Trieu) Date: Thu, 14 Jul 2011 13:32:15 -0700 Subject: [cfe-dev] -Wsign-compare warns on different signs of operands for ?: In-Reply-To: References: Message-ID: On Thu, Jul 14, 2011 at 1:11 PM, John McCall wrote: > > On Jul 14, 2011, at 12:58 PM, Richard Trieu wrote: > > On Wed, Jul 13, 2011 at 10:08 PM, John McCall wrote: > >> >> On Jul 13, 2011, at 5:15 PM, Richard Trieu wrote: >> >> > For code such as: >> > >> > void f(unsigned int u, int i) { >> > (void) (true ? u : i); >> > } >> > >> > When run with -Wsign-compare, Clang gives the following warning. >> > >> > warning: operands of ? are integers of different signs: >> > 'unsigned int' and 'int' [-Wsign-compare] >> > (void) (true ? u : i); >> > ^ ~ ~ >> > >> > Yet, no comparison is going on between u and i, so the warning seems out >> of place for grouping with -Wsign-compare. I think that it would be better >> is this warning was pulled out of the -Wsign-compare diagnostic group. >> Also, gcc's -Wsign-compare does not warn on this code, so this change will >> make Clang's sign compare closer to gcc's. Does this seem reasonable? >> >> gcc's -Wsign-compare does warn on this code if you make the condition >> non-trivial. Clang is just missing that special case. >> >> John. >> > > Could you give an example of a non-trivial case that gcc does warn on? > I've tried: > > void f(bool b, unsigned int u, int i) { > (void) (b ? u : i); > } > > void f(unsigned int u, int i) { > (void) ((i > 5) ? u : i); > } > > but both don't give an warning from gcc -Wsign-compare. Clang's > -Wsign-compare warns on both. > > > Aha. From 'bool' I take it that you're talking about C++. You're correct > that G++'s -Wsign-compare does not warn about conditional operators. GCC's > does. In clang, we decided that that inconsistency wasn't worth emulating. > > John. > Sorry for the confusion. If we don't care about consistency in this case, can we remove this warning so that our -Wsign-compare will only be about signed comparisons? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110714/da035261/attachment-0001.html From samuraileumas at yahoo.com Thu Jul 14 15:34:16 2011 From: samuraileumas at yahoo.com (Samuel Crow) Date: Thu, 14 Jul 2011 13:34:16 -0700 (PDT) Subject: [cfe-dev] -Wsign-compare warns on different signs of operands for ?: In-Reply-To: References: Message-ID: <1310675656.36033.YahooMailNeo@web125412.mail.ne1.yahoo.com> >________________________________ >From: John McCall >To: Richard Trieu >Cc: cfe-dev at cs.uiuc.edu >Sent: Thursday, July 14, 2011 3:11 PM >Subject: Re: [cfe-dev] -Wsign-compare warns on different signs of operands for ?: > > > > >On Jul 14, 2011, at 12:58 PM, Richard Trieu wrote: > >On Wed, Jul 13, 2011 at 10:08 PM, John McCall wrote: >> >> >>>On Jul 13, 2011, at 5:15 PM, Richard Trieu wrote: >>> >>>> For code such as: >>>> >>>> void f(unsigned int u, int i) { >>>> ? (void) (true ? u : i); >>>> } >>>> >>>> When run with -Wsign-compare, Clang gives the following warning. >>>> >>>> warning: operands of ? are integers of different signs: >>>> ? ? ? 'unsigned int' and 'int' [-Wsign-compare] >>>> ? (void) (true ? u : i); >>>> ? ? ? ? ? ? ? ?^ ~ ? ~ >>>> >>>> Yet, no comparison is going on between u and i, so the warning seems out of place for grouping with -Wsign-compare. ?I think that it would be better is this warning was pulled out of the -Wsign-compare diagnostic group. ?Also, gcc's -Wsign-compare does not warn on this code, so this change will make Clang's sign compare closer to gcc's. ?Does this seem reasonable? >>> >>>gcc's -Wsign-compare does warn on this code if you make the condition non-trivial. ?Clang is just missing that special case. >>> >>>John. >>> >> >>Could you give an example of a non-trivial case that gcc does warn on? ?I've tried: >> >> >>void f(bool b, unsigned int u, int i) { >>? (void) (b ? u : i); >>} >> >> >>void f(unsigned int u, int i) { >>? (void) ((i > 5) ? u : i); >>} >> >> >>but both don't give an warning from gcc -Wsign-compare. ?Clang's -Wsign-compare warns on both. > >Aha. ?From 'bool' I take it that you're talking about C++. ?You're correct that G++'s -Wsign-compare does not warn about conditional operators. ?GCC's does. ?In clang, we decided that that inconsistency wasn't worth emulating. > > >John. Hi John, Either that, or he's used #inlcude from C99. ?I've used that in C before. ?That may be beside the point, however. --Sam From ajotwani85 at gmail.com Thu Jul 14 15:34:21 2011 From: ajotwani85 at gmail.com (ajotwani) Date: Thu, 14 Jul 2011 13:34:21 -0700 (PDT) Subject: [cfe-dev] Clang Checker for Import Statements Message-ID: <1310675661480-3170252.post@n3.nabble.com> I want to write a checker that will analyze the #import statements within Objective-C files and issue a warning when a certain file is included in the import directive. For example if I have: #import "x.h" and x.h is the file name I am looking for then the checker would issue a warning that x.h is being used when it comes across this import statement. What would be the best way to go about doing this? Using the InclusionDirective class? Thanks -- View this message in context: http://clang-developers.42468.n3.nabble.com/Clang-Checker-for-Import-Statements-tp3170252p3170252.html Sent from the Clang Developers mailing list archive at Nabble.com. From rjmccall at apple.com Thu Jul 14 15:39:30 2011 From: rjmccall at apple.com (John McCall) Date: Thu, 14 Jul 2011 13:39:30 -0700 Subject: [cfe-dev] -Wsign-compare warns on different signs of operands for ?: In-Reply-To: References: Message-ID: <04E85036-FE6F-48EB-AE42-C0E31FDB7317@apple.com> On Jul 14, 2011, at 1:32 PM, Richard Trieu wrote: > On Thu, Jul 14, 2011 at 1:11 PM, John McCall wrote: > On Jul 14, 2011, at 12:58 PM, Richard Trieu wrote: >> On Wed, Jul 13, 2011 at 10:08 PM, John McCall wrote: >> >> On Jul 13, 2011, at 5:15 PM, Richard Trieu wrote: >> >> > For code such as: >> > >> > void f(unsigned int u, int i) { >> > (void) (true ? u : i); >> > } >> > >> > When run with -Wsign-compare, Clang gives the following warning. >> > >> > warning: operands of ? are integers of different signs: >> > 'unsigned int' and 'int' [-Wsign-compare] >> > (void) (true ? u : i); >> > ^ ~ ~ >> > >> > Yet, no comparison is going on between u and i, so the warning seems out of place for grouping with -Wsign-compare. I think that it would be better is this warning was pulled out of the -Wsign-compare diagnostic group. Also, gcc's -Wsign-compare does not warn on this code, so this change will make Clang's sign compare closer to gcc's. Does this seem reasonable? >> >> gcc's -Wsign-compare does warn on this code if you make the condition non-trivial. Clang is just missing that special case. >> >> John. >> >> Could you give an example of a non-trivial case that gcc does warn on? I've tried: >> >> void f(bool b, unsigned int u, int i) { >> (void) (b ? u : i); >> } >> >> void f(unsigned int u, int i) { >> (void) ((i > 5) ? u : i); >> } >> >> but both don't give an warning from gcc -Wsign-compare. Clang's -Wsign-compare warns on both. > > Aha. From 'bool' I take it that you're talking about C++. You're correct that G++'s -Wsign-compare does not warn about conditional operators. GCC's does. In clang, we decided that that inconsistency wasn't worth emulating. > > John. > > Sorry for the confusion. If we don't care about consistency in this case, can we remove this warning so that our -Wsign-compare will only be about signed comparisons? I have no problem with that; just don't tell me it's about consistency with what GCC does. :) John. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110714/b473b153/attachment.html From kremenek at apple.com Thu Jul 14 15:44:28 2011 From: kremenek at apple.com (Ted Kremenek) Date: Thu, 14 Jul 2011 13:44:28 -0700 Subject: [cfe-dev] Spurious warning: unused parameter when used only in an expression error-ing out In-Reply-To: References: Message-ID: <1A296920-4197-48CC-A3EF-371FC60BCA0A@apple.com> We should probably not emit a -Wunused-[x] warning in cases where a function doesn't fully parse correctly. Please file a bug. On Jul 14, 2011, at 12:34 PM, Matthieu Monrocq wrote: > Hello clang, > > I made a strange discovery with a small helper function I wrote: > > If one test the following (short) program: > > struct A; > > void sink(A,int); > > void func(A const& a, int x, int y) { > sink(a + x, y); > } > > The following errors get emitted: > > $ clang -fsyntax-only -Wunused-parameter unused_parameter.cpp > unused_parameter.cpp:15:11: error: invalid operands to binary expression ('const A' and 'int') > sink(a + x, y); > ~ ^ ~ > unused_parameter.cpp:14:34: warning: unused parameter 'y' [-Wunused-parameter] > void func(A const& a, int x, int y) { > ^ > 1 warning and 1 error generated. > > > The first one is expected, however it seems its presence somehow short-circuit the analysis of the whole expression and as a result we get the spurious warning... > > I feel that this is unwelcome, because it obfuscates the true error (especially since I tend to compile with -Werror). > > > For reference, I use the following version of Clang: > > $ clang --version > clang version 3.0 (trunk 132889) > Target: i686-pc-mingw32 > Thread model: posix > > I could not find any mention of such an issue with my Google-fu in the cfe-dev archive, so please let me know if it already came up and it was deemed unimportant. > > -- Matthieu > _______________________________________________ > 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/20110714/3549b4d9/attachment.html From supertri at google.com Thu Jul 14 15:51:45 2011 From: supertri at google.com (Caitlin Sadowski) Date: Thu, 14 Jul 2011 13:51:45 -0700 Subject: [cfe-dev] How to design my own annotation language? In-Reply-To: <1310080353270-3149984.post@n3.nabble.com> References: <1310080353270-3149984.post@n3.nabble.com> Message-ID: You may find the following link helpful: http://clang.llvm.org/docs/InternalsManual.html#AddingAttributes Cheers, Caitlin On Thu, Jul 7, 2011 at 4:12 PM, hunter wrote: > Hi All, > > I hope to have a try to design some annotations for C or C++. But I am new > to Clang and wandering where I should start with, e.g. how to parse the > annotations and how the compiler react at compiler-time when it sees the > annotations. Could anyone give some advice? > > Thanks in advance! > > Best, > Chen > > -- > View this message in context: http://clang-developers.42468.n3.nabble.com/How-to-design-my-own-annotation-language-tp3149984p3149984.html > Sent from the Clang Developers mailing list archive at Nabble.com. > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > From supertri at google.com Thu Jul 14 17:09:36 2011 From: supertri at google.com (Caitlin Sadowski) Date: Thu, 14 Jul 2011 15:09:36 -0700 Subject: [cfe-dev] Proposal for thread safety attributes for Clang In-Reply-To: <63C66C00-8996-4CC2-855A-76CA19678D1A@apple.com> References: <63C66C00-8996-4CC2-855A-76CA19678D1A@apple.com> Message-ID: Chris, > Are these in mainline GCC or just a branch? ?If they are in mainline GCC and > have shipped in a release, then taking them into Clang makes sense for > compatibility reasons. ?If they are a research project that is in > development, then the bar to getting it into mainline clang is much higher, > because adding attributes is tantamount to a language extension. These annotations are in between the two extremes listed above. They have gone beyond the initial research project stage, as they have multiple years of use in production code. They are currently not in mainline GCC (they are in a full-fledged development branch). However, the only reasons for not including the annotations in mainline GCC are the result of implementation concerns: the GCC implementation involves invasive changes throughout the GCC parser and depends on specific details of the lowering to GIMPLE. The general consensus seems to be that the annotation system should be in mainline GCC, after changing how they are implemented (unless Clang gets there first). > I'm specifically concerned on a number of fronts here: > 1. Are these annotations general enough to apply to many common lock-based > APIs? The annotations themselves are general enough (the paper I cited earlier actually contains an entire sound type-system based on a subset of these annotations). Within the implementation, there are tricky cases (like aliasing of lock objects) that lead to difficulties in the application. However, our core synchronization libraries have been successfully annotated, and it looks like less than 15% of annotated code is impacted by these limitations. > 2. How do the annotations handle aliasing of lock objects? Right now they do not handle this. However, we would like eventually support this feature. > 3. How many bugs have been found in practice? In a (relatively small) subsection of code at Google that has thread safety annotations, I looked at one month of commit activity and found 18 bug-fixing commits (not including commits which just fix the annotations) that cited these annotations explicitly as the way the bug was found. Also, the thread safety annotations are useful beyond just bug fixing. At Google, the web search frontend team refused to write multithreaded code until these thread-safety warnings were made available (through that GCC branch) due to the number of bugs and difficulty of tracking them down. > 4. Have you considered doing this as a static analysis (where the bar is > much lower to get things into mainline) instead of as a language change? The attribute system and the most fundamental analyses are things we would like to see in the main compiler (after years of experience successfully using these annotations in GCC). Plus, having this starting point checked in will make it easier to build off and improve the analysis. We are planning to have future analyses that build off of these foundations start in the static analzyer. Cheers, Caitlin From jediknil at belkadan.com Thu Jul 14 17:39:11 2011 From: jediknil at belkadan.com (Jordy Rose) Date: Thu, 14 Jul 2011 15:39:11 -0700 Subject: [cfe-dev] Clang Checker for Import Statements In-Reply-To: <1310675661480-3170252.post@n3.nabble.com> References: <1310675661480-3170252.post@n3.nabble.com> Message-ID: <3C5431DE-E96C-410E-9D75-38A0537B6D5B@belkadan.com> As I understand it, #import is completely taken care of in the preprocessing phase...you won't see it in the AST. That means that writing a static analysis checker won't work. If you really wanted to do this in code, you'd probably be modifying code in the Lex library (which I'm not so familiar with). But an easier way to solve your problem might be to just use the #warning extension: if you put a #warning in x.h, you'll get a warning whenever x.h is included. If you don't have control over x.h, or you want the warning every time x.h is referenced, you could make a wrapper that looks like this: #warning "Use of x.h" #import "x.h" ...and then *#include* your wrapper. Admittedly, that requires a little more intrusion into your project, but it /doesn't/ require a custom compiler build. :-) Jordy On Jul 14, 2011, at 13:34, ajotwani wrote: > I want to write a checker that will analyze the #import statements within > Objective-C files and issue a warning when a certain file is included in the > import directive. For example if I have: > > #import "x.h" > > and x.h is the file name I am looking for then the checker would issue a > warning that x.h is being used when it comes across this import statement. > > What would be the best way to go about doing this? Using the > InclusionDirective class? > > Thanks > > -- > View this message in context: http://clang-developers.42468.n3.nabble.com/Clang-Checker-for-Import-Statements-tp3170252p3170252.html > Sent from the Clang Developers mailing list archive at Nabble.com. > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From chandlerc at google.com Thu Jul 14 17:46:53 2011 From: chandlerc at google.com (Chandler Carruth) Date: Thu, 14 Jul 2011 15:46:53 -0700 Subject: [cfe-dev] Proposal for thread safety attributes for Clang In-Reply-To: References: <63C66C00-8996-4CC2-855A-76CA19678D1A@apple.com> Message-ID: To clarify one particular (but hopefully small) point... On Thu, Jul 14, 2011 at 3:09 PM, Caitlin Sadowski wrote: > However, our core synchronization libraries have > been successfully annotated, and it looks like less than 15% of > annotated code is impacted by these limitations. > The limitations should take the form of "we can't provide warnings for improper locking", not false positives. My hope is that work on more advanced and thorough checking of these locking behaviors can be implemented in the static analyzer, based on the core attributes, but using more expensive analysis techniques and showing possible errors as well as definite errors. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110714/fd7892b2/attachment.html From kremenek at apple.com Thu Jul 14 18:15:00 2011 From: kremenek at apple.com (Ted Kremenek) Date: Thu, 14 Jul 2011 16:15:00 -0700 Subject: [cfe-dev] Clang Checker for Import Statements In-Reply-To: <3C5431DE-E96C-410E-9D75-38A0537B6D5B@belkadan.com> References: <1310675661480-3170252.post@n3.nabble.com> <3C5431DE-E96C-410E-9D75-38A0537B6D5B@belkadan.com> Message-ID: <09AEDD00-0592-45A2-9651-63093844A050@apple.com> This information can possibly be groveled through in the SourceManager (so it could be a static analysis check, at least partially), but I don't think we get SourceLocations when we include (say) an empty header or we #include the same header again that we know has include guards. On Jul 14, 2011, at 3:39 PM, Jordy Rose wrote: > As I understand it, #import is completely taken care of in the preprocessing phase...you won't see it in the AST. That means that writing a static analysis checker won't work. > > If you really wanted to do this in code, you'd probably be modifying code in the Lex library (which I'm not so familiar with). But an easier way to solve your problem might be to just use the #warning extension: if you put a #warning in x.h, you'll get a warning whenever x.h is included. If you don't have control over x.h, or you want the warning every time x.h is referenced, you could make a wrapper that looks like this: > > #warning "Use of x.h" > #import "x.h" > > ...and then *#include* your wrapper. Admittedly, that requires a little more intrusion into your project, but it /doesn't/ require a custom compiler build. :-) > > Jordy > > > On Jul 14, 2011, at 13:34, ajotwani wrote: > >> I want to write a checker that will analyze the #import statements within >> Objective-C files and issue a warning when a certain file is included in the >> import directive. For example if I have: >> >> #import "x.h" >> >> and x.h is the file name I am looking for then the checker would issue a >> warning that x.h is being used when it comes across this import statement. >> >> What would be the best way to go about doing this? Using the >> InclusionDirective class? >> >> Thanks >> >> -- >> View this message in context: http://clang-developers.42468.n3.nabble.com/Clang-Checker-for-Import-Statements-tp3170252p3170252.html >> Sent from the Clang Developers mailing list archive at Nabble.com. >> _______________________________________________ >> 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 scott.conger at gmail.com Thu Jul 14 18:25:58 2011 From: scott.conger at gmail.com (Scott Conger) Date: Thu, 14 Jul 2011 16:25:58 -0700 Subject: [cfe-dev] Clang Checker for Import Statements In-Reply-To: <09AEDD00-0592-45A2-9651-63093844A050@apple.com> References: <1310675661480-3170252.post@n3.nabble.com> <3C5431DE-E96C-410E-9D75-38A0537B6D5B@belkadan.com> <09AEDD00-0592-45A2-9651-63093844A050@apple.com> Message-ID: If you don't want to touch the code itself, you can still go with Jordy's solution below and just update the include paths. You can perhaps even avoid touching makefiles if you use environment variables. -Scott On Thu, Jul 14, 2011 at 4:15 PM, Ted Kremenek wrote: > This information can possibly be groveled through in the SourceManager (so it could be a static analysis check, at least partially), but I don't think we get SourceLocations when we include (say) an empty header or we #include the same header again that we know has include guards. > > On Jul 14, 2011, at 3:39 PM, Jordy Rose wrote: > >> As I understand it, #import is completely taken care of in the preprocessing phase...you won't see it in the AST. That means that writing a static analysis checker won't work. >> >> If you really wanted to do this in code, you'd probably be modifying code in the Lex library (which I'm not so familiar with). But an easier way to solve your problem might be to just use the #warning extension: if you put a #warning in x.h, you'll get a warning whenever x.h is included. If you don't have control over x.h, or you want the warning every time x.h is referenced, you could make a wrapper that looks like this: >> >> #warning "Use of x.h" >> #import "x.h" >> >> ...and then *#include* your wrapper. Admittedly, that requires a little more intrusion into your project, but it /doesn't/ require a custom compiler build. :-) >> >> Jordy >> >> >> On Jul 14, 2011, at 13:34, ajotwani wrote: >> >>> I want to write a checker that will analyze the #import statements within >>> Objective-C files and issue a warning when a certain file is included in the >>> import directive. For example if I have: >>> >>> #import "x.h" >>> >>> and x.h is the file name I am looking for then the checker would issue a >>> warning that x.h is being used when it comes across this import statement. >>> >>> What would be the best way to go about doing this? Using the >>> InclusionDirective class? >>> >>> Thanks >>> >>> -- >>> View this message in context: http://clang-developers.42468.n3.nabble.com/Clang-Checker-for-Import-Statements-tp3170252p3170252.html >>> Sent from the Clang Developers mailing list archive at Nabble.com. >>> _______________________________________________ >>> 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 > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > From rtrieu at google.com Thu Jul 14 18:57:57 2011 From: rtrieu at google.com (Richard Trieu) Date: Thu, 14 Jul 2011 16:57:57 -0700 Subject: [cfe-dev] -Wsign-compare warns on different signs of operands for ?: In-Reply-To: <04E85036-FE6F-48EB-AE42-C0E31FDB7317@apple.com> References: <04E85036-FE6F-48EB-AE42-C0E31FDB7317@apple.com> Message-ID: On Thu, Jul 14, 2011 at 1:39 PM, John McCall wrote: > On Jul 14, 2011, at 1:32 PM, Richard Trieu wrote: > > On Thu, Jul 14, 2011 at 1:11 PM, John McCall wrote: >> >> On Jul 14, 2011, at 12:58 PM, Richard Trieu wrote: >> >> On Wed, Jul 13, 2011 at 10:08 PM, John McCall wrote: >> >>> >>> On Jul 13, 2011, at 5:15 PM, Richard Trieu wrote: >>> >>> > For code such as: >>> > >>> > void f(unsigned int u, int i) { >>> > (void) (true ? u : i); >>> > } >>> > >>> > When run with -Wsign-compare, Clang gives the following warning. >>> > >>> > warning: operands of ? are integers of different signs: >>> > 'unsigned int' and 'int' [-Wsign-compare] >>> > (void) (true ? u : i); >>> > ^ ~ ~ >>> > >>> > Yet, no comparison is going on between u and i, so the warning seems >>> out of place for grouping with -Wsign-compare. I think that it would be >>> better is this warning was pulled out of the -Wsign-compare diagnostic >>> group. Also, gcc's -Wsign-compare does not warn on this code, so this >>> change will make Clang's sign compare closer to gcc's. Does this seem >>> reasonable? >>> >>> gcc's -Wsign-compare does warn on this code if you make the condition >>> non-trivial. Clang is just missing that special case. >>> >>> John. >>> >> >> Could you give an example of a non-trivial case that gcc does warn on? >> I've tried: >> >> void f(bool b, unsigned int u, int i) { >> (void) (b ? u : i); >> } >> >> void f(unsigned int u, int i) { >> (void) ((i > 5) ? u : i); >> } >> >> but both don't give an warning from gcc -Wsign-compare. Clang's >> -Wsign-compare warns on both. >> >> >> Aha. From 'bool' I take it that you're talking about C++. You're correct >> that G++'s -Wsign-compare does not warn about conditional operators. GCC's >> does. In clang, we decided that that inconsistency wasn't worth emulating. >> >> John. >> > > Sorry for the confusion. If we don't care about consistency in this case, > can we remove this warning so that our -Wsign-compare will only be about > signed comparisons? > > > I have no problem with that; just don't tell me it's about consistency > with what GCC does. :) > > John. > Originally, I was going to move this warning (operands of different signs) out to its own flag. However, a similar warning (? operand conversion) exists in -Wsign-conversion which will warn on the same case as this warning (operands of different signs) does. Since this case is covered under (? operand conversion), should this warning (operands of different signs) be completely removed from Clang? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110714/2a3d75c7/attachment.html From jediknil at belkadan.com Thu Jul 14 18:58:09 2011 From: jediknil at belkadan.com (Jordy Rose) Date: Thu, 14 Jul 2011 16:58:09 -0700 Subject: [cfe-dev] Proposal for thread safety attributes for Clang In-Reply-To: References: <63C66C00-8996-4CC2-855A-76CA19678D1A@apple.com> Message-ID: It's worth noting that Rui Paulo was also working on at least a simple form of lock analysis for the static analyzer. Unfortunately my mail filters seemed to have thrown away some replies to my messages, so I only just responded to his latest patch. The subject line (on cfe-commits) is "PthreadLock Checker enhancements". Jordy On Jul 14, 2011, at 15:46, Chandler Carruth wrote: > To clarify one particular (but hopefully small) point... > > On Thu, Jul 14, 2011 at 3:09 PM, Caitlin Sadowski wrote: >> However, our core synchronization libraries have >> been successfully annotated, and it looks like less than 15% of >> annotated code is impacted by these limitations. > > The limitations should take the form of "we can't provide warnings for improper locking", not false positives. > > My hope is that work on more advanced and thorough checking of these locking behaviors can be implemented in the static analyzer, based on the core attributes, but using more expensive analysis techniques and showing possible errors as well as definite errors. > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From rjmccall at apple.com Thu Jul 14 19:17:13 2011 From: rjmccall at apple.com (John McCall) Date: Thu, 14 Jul 2011 17:17:13 -0700 Subject: [cfe-dev] -Wsign-compare warns on different signs of operands for ?: In-Reply-To: References: <04E85036-FE6F-48EB-AE42-C0E31FDB7317@apple.com> Message-ID: On Jul 14, 2011, at 4:57 PM, Richard Trieu wrote: > On Thu, Jul 14, 2011 at 1:39 PM, John McCall wrote: > On Jul 14, 2011, at 1:32 PM, Richard Trieu wrote: >> On Thu, Jul 14, 2011 at 1:11 PM, John McCall wrote: >> On Jul 14, 2011, at 12:58 PM, Richard Trieu wrote: >>> On Wed, Jul 13, 2011 at 10:08 PM, John McCall wrote: >>> >>> On Jul 13, 2011, at 5:15 PM, Richard Trieu wrote: >>> >>> > For code such as: >>> > >>> > void f(unsigned int u, int i) { >>> > (void) (true ? u : i); >>> > } >>> > >>> > When run with -Wsign-compare, Clang gives the following warning. >>> > >>> > warning: operands of ? are integers of different signs: >>> > 'unsigned int' and 'int' [-Wsign-compare] >>> > (void) (true ? u : i); >>> > ^ ~ ~ >>> > >>> > Yet, no comparison is going on between u and i, so the warning seems out of place for grouping with -Wsign-compare. I think that it would be better is this warning was pulled out of the -Wsign-compare diagnostic group. Also, gcc's -Wsign-compare does not warn on this code, so this change will make Clang's sign compare closer to gcc's. Does this seem reasonable? >>> >>> gcc's -Wsign-compare does warn on this code if you make the condition non-trivial. Clang is just missing that special case. >>> >>> John. >>> >>> Could you give an example of a non-trivial case that gcc does warn on? I've tried: >>> >>> void f(bool b, unsigned int u, int i) { >>> (void) (b ? u : i); >>> } >>> >>> void f(unsigned int u, int i) { >>> (void) ((i > 5) ? u : i); >>> } >>> >>> but both don't give an warning from gcc -Wsign-compare. Clang's -Wsign-compare warns on both. >> >> Aha. From 'bool' I take it that you're talking about C++. You're correct that G++'s -Wsign-compare does not warn about conditional operators. GCC's does. In clang, we decided that that inconsistency wasn't worth emulating. >> >> John. >> >> Sorry for the confusion. If we don't care about consistency in this case, can we remove this warning so that our -Wsign-compare will only be about signed comparisons? > > I have no problem with that; just don't tell me it's about consistency with what GCC does. :) > > John. > > Originally, I was going to move this warning (operands of different signs) out to its own flag. However, a similar warning (? operand conversion) exists in -Wsign-conversion which will warn on the same case as this warning (operands of different signs) does. Since this case is covered under (? operand conversion), should this warning (operands of different signs) be completely removed from Clang? I think that was just a hack so that it would appear under both flags. John. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110714/ad636db9/attachment.html From rtrieu at google.com Thu Jul 14 19:40:35 2011 From: rtrieu at google.com (Richard Trieu) Date: Thu, 14 Jul 2011 17:40:35 -0700 Subject: [cfe-dev] -Wsign-compare warns on different signs of operands for ?: In-Reply-To: References: <04E85036-FE6F-48EB-AE42-C0E31FDB7317@apple.com> Message-ID: On Thu, Jul 14, 2011 at 5:17 PM, John McCall wrote: > On Jul 14, 2011, at 4:57 PM, Richard Trieu wrote: > > On Thu, Jul 14, 2011 at 1:39 PM, John McCall wrote: > >> On Jul 14, 2011, at 1:32 PM, Richard Trieu wrote: >> >> On Thu, Jul 14, 2011 at 1:11 PM, John McCall wrote: >>> >>> On Jul 14, 2011, at 12:58 PM, Richard Trieu wrote: >>> >>> On Wed, Jul 13, 2011 at 10:08 PM, John McCall wrote: >>> >>>> >>>> On Jul 13, 2011, at 5:15 PM, Richard Trieu wrote: >>>> >>>> > For code such as: >>>> > >>>> > void f(unsigned int u, int i) { >>>> > (void) (true ? u : i); >>>> > } >>>> > >>>> > When run with -Wsign-compare, Clang gives the following warning. >>>> > >>>> > warning: operands of ? are integers of different signs: >>>> > 'unsigned int' and 'int' [-Wsign-compare] >>>> > (void) (true ? u : i); >>>> > ^ ~ ~ >>>> > >>>> > Yet, no comparison is going on between u and i, so the warning seems >>>> out of place for grouping with -Wsign-compare. I think that it would be >>>> better is this warning was pulled out of the -Wsign-compare diagnostic >>>> group. Also, gcc's -Wsign-compare does not warn on this code, so this >>>> change will make Clang's sign compare closer to gcc's. Does this seem >>>> reasonable? >>>> >>>> gcc's -Wsign-compare does warn on this code if you make the condition >>>> non-trivial. Clang is just missing that special case. >>>> >>>> John. >>>> >>> >>> Could you give an example of a non-trivial case that gcc does warn on? >>> I've tried: >>> >>> void f(bool b, unsigned int u, int i) { >>> (void) (b ? u : i); >>> } >>> >>> void f(unsigned int u, int i) { >>> (void) ((i > 5) ? u : i); >>> } >>> >>> but both don't give an warning from gcc -Wsign-compare. Clang's >>> -Wsign-compare warns on both. >>> >>> >>> Aha. From 'bool' I take it that you're talking about C++. You're >>> correct that G++'s -Wsign-compare does not warn about conditional operators. >>> GCC's does. In clang, we decided that that inconsistency wasn't worth >>> emulating. >>> >>> John. >>> >> >> Sorry for the confusion. If we don't care about consistency in this case, >> can we remove this warning so that our -Wsign-compare will only be about >> signed comparisons? >> >> >> I have no problem with that; just don't tell me it's about consistency >> with what GCC does. :) >> >> John. >> > > Originally, I was going to move this warning (operands of different signs) > out to its own flag. However, a similar warning (? operand conversion) > exists in -Wsign-conversion which will warn on the same case as this > warning (operands of different signs) does. Since this case is covered > under (? operand conversion), should this warning (operands of different > signs) be completely removed from Clang? > > > I think that was just a hack so that it would appear under both flags. > > John. > Guess I'll go remove that hack. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110714/9b1eb513/attachment.html From jediknil at belkadan.com Thu Jul 14 22:48:36 2011 From: jediknil at belkadan.com (Jordy Rose) Date: Thu, 14 Jul 2011 20:48:36 -0700 Subject: [cfe-dev] Removing "TransferFuncs" from the analyzer In-Reply-To: References: Message-ID: <4BEED18C-9590-4DAD-AF05-85B598D0C8D3@belkadan.com> > The main role of the summaries is to memoize the computation of the transfer function logic. Those should stay around primarily to make the checker faster. You are correct, however, that they are currently used for generating the diagnostics Oops, right, I meant why the summaries have to be attached to ExplodedNodes -- the only time they're used once attached is for bug reports, and only in those three cases (-dealloc, MakeCollectable in non-GC, and retain/release in GC). Which, actually, is something we could change right now, by only attaching summaries if they have interesting ArgEffects. The actual RetainSummaryManager can still live on RetainReleaseChecker when everything blows over. For AnnotatedGRState, I think if we're going to add new infrastructure this isn't a bad way to go. I would think Annotations would be a lot like a GRState's GDM, a wrapper around some kind of tag-keyed map (though it doesn't have to be immutable until it goes into an AnnotatedGRState. How do annotations interact with ExplodedNodes being FoldingSetNodes? Are annotations merged, or do they make two different nodes unique? (If they make the nodes unique, does that mean all annotation data?which I'm currently thinking of like a GRState's GDM?has to be profileable?) Lastly, I'm a little wary of using AnnotatedGRState to carry around a state+annotations, rather than just adding an Annotations parameter to getNode, but I guess it makes things easier for existing code. We'll probably have to look at all the callers of getNode either way if we make this change. I guess the big question is whether or not this is actually necessary: will checkers need a way to associate information with certain nodes /besides/ RetainReleaseChecker? Probably yes, but there should probably be a guideline to avoid over-using annotations, putting off most of the work until you know there's a diagnostic. Or not. Maybe we decide annotations are cheap, and that checkers should go ahead and use them for better diagnostics. Jordy From jediknil at belkadan.com Thu Jul 14 23:11:15 2011 From: jediknil at belkadan.com (Jordy Rose) Date: Thu, 14 Jul 2011 21:11:15 -0700 Subject: [cfe-dev] Removing "TransferFuncs" from the analyzer In-Reply-To: References: Message-ID: <763DC236-9891-45E1-B072-5602ABF012C1@belkadan.com> Separately, there is one last thing CFRefCount does that I missed my first time around: it determines whether we're running a GC or non-GC analysis when we're in a hybrid mode. This is something that has to be dealt with at the same time as moving what's currently in evalCall and evalObjCMessage to RetainReleaseChecker. Now, we could just move the flag to AnalysisContextManager or ExprEngine, but neither of those feel right ? is this ever going to matter to anyone besides RetainReleaseChecker? (Currently it's limited to CFRefCount.cpp.) My alternative is to bifurcate the GRState at the start of each code body. This limits the split to when RetainReleaseChecker is active. We could even go further and make it split the state on demand, with something like this: > std::pair splitGC (const GRState *state) { > switch (langOpts.getGCMode()) { > case LangOptions::NonGC: > return pair(state, NULL); > > case LangOptions::GCOnly: > return pair(NULL, state); > > case LangOptions::HybridGC: > // See if we've picked a mode yet. If not, the default is HybridGC. > switch (state->get()) { > case LangOptions::NonGC: > return pair(state, NULL); > case LangOptions::GCOnly: > return pair(NULL, state); > case LangOptions::HybridGC: { > const GRState *withoutGC = state->set(LangOptions::NonGC); > const GRState *withGC = state->set(LangOptions::GCOnly); > return pair(withoutGC, withGC); > } > } > } > } > > // later... > llvm::tie(stateNoGC, stateGC) = splitGC(state); That way, it'll choose whether or not to analyze a function under GC as soon as it needs to, but no sooner. (Since this is an optimization, it'd be something to add after the CFRefCount migration is done.) The downside of bifurcating states instead of running two analyses is increased memory usage; the upside is a probable minor speed benefit from only having to do path-insensitive checks once, walk the AST once, etc. And of course, less target-specific information in the analyzer infrastructure. We can hold off on this piece for a while longer, though. :-) Jordy From jediknil at belkadan.com Thu Jul 14 23:56:39 2011 From: jediknil at belkadan.com (Jordy Rose) Date: Thu, 14 Jul 2011 21:56:39 -0700 Subject: [cfe-dev] Checker Plugins In-Reply-To: <31345B0A-C56D-48D6-8635-D7280183777A@belkadan.com> References: <31345B0A-C56D-48D6-8635-D7280183777A@belkadan.com> Message-ID: <695AA918-DADA-4A7E-8515-E87B2D7CE903@belkadan.com> Sorry for not responding to this for a month...my mail filters decided to throw away replies that also showed up on cfe lists. I think I have it fixed now... > I'd personally prefer to move away from static registration for the checker plugins but, instead, use an exported C function that has a "standardized" name. This function will return a CheckerProvider which we can use during checker registration. Moving away from static registration objects gives us much more precise control of the lifetime of CheckerProviders and is more portable (easier to work on windows as well). The "easier to work on Windows" is the clincher here for me, even though I develop on a Mac! > Currently the CheckerProvider interface is very minimal and it doesn't enforce any specific naming organization for checkers. I kinda like it this way but then we have the issue of not easily allowing plugins to use the group/package system. What if we made CheckerProvider instances one-to-one with packages? We could make the osx.cocoa package map to OSX_Cocoa (or osx::Cocoa, but I don't think we want to rely on namespace mangling being consistent). Then we have getCheckerProvider_OSX_Cocoa, or whatever?not particularly pretty, but not hard, either. It wouldn't be hard to maintain the hierarchy part, either: just include a list of subpackages in the parent provider. As a bonus, this means that groups and packages can have a single common lookup path, even if we want to keep them distinct in the help output. The problem with all of this is that loading a plugin won't actually add anything to -analyzer-checker-help without some kind of registration. Maybe that has to stay on llvm::Registry...and once that's true, there's no reason not to make the main CheckerProviders use the same registration. Alternately, we require a -checker-load (instead of plain -load), which uses the name of the *plugin file* to find the provider in it. Or providers. I guess the CheckerProvider-equals-package proposal is a little orthogonal to the plugin architecture. > I'd suggest that we provide 2 kinds of examples for plugins. > > One should be in the 'examples' directory and it should do the minimum work necessary to get an example checker plugin up & running (e.g. it will just look for one specific checker string in order to be enabled and it will have a very simple printHelp). > > Apart from that, we create a directory for a dynamically loaded plugin inside the lib/StaticAnalyzer hierarchy that will contain the required [c]make files to allow using the package system. Also we would need to expose some functions from ClangSACheckerProvider.cpp to avoid duplication of registration/help printing when using the package system. If we can come up with a naming-scheme-based package system, it would probably work for external plug-ins as well as internal ones. Then we can pretty much just make ClangSACheckerProvider into a subclass of CheckerProvider with no customization. Or generate subclasses of CheckerProvider from Checkers.td and ditch ClangSACheckerProvider entirely. If we pull *current* analyzer plugins (besides LLVMConventionsChecker) into dynamic libraries, how does that affect distribution? Do they go in /usr/lib/clang/checkers, or something? Jordy On Jun 4, 2011, at 19:25, Jordy Rose wrote: > The idea's come up before, right? I feel like having pluggable check-ins is one of the goals of the analyzer, even as everything is refactored over and over. It would be convenient for organizations to make their own API checks, like we do for Unix and Cocoa (a little). Right? Attributes only go so far. > > Anyway, I hacked up a quick plug-in system over the last few days. It approximates Argyrios' very nice group/package system with a poor text-matching version of the registration system, and supports multiple new checkers in one loadable library. > > I'm not suggesting that this is code that should go into trunk now, or even that this is the right approach to checker plug-ins, but I wanted to bring it up again, to see if there's any way to make progress on it. > > (At the very least we'd want some kind of "checker API version" token, so that when we make massive refactorings, we can invalidate old plug-ins.) > > Comments? > Jordy > > P.S. Why is the static analyzer "ento"? *grin* From kremenek at apple.com Fri Jul 15 00:21:05 2011 From: kremenek at apple.com (Ted Kremenek) Date: Thu, 14 Jul 2011 22:21:05 -0700 Subject: [cfe-dev] Removing "TransferFuncs" from the analyzer In-Reply-To: References: Message-ID: Hi Jordy, Sorry I took so long to reply to this. As you know I've been occupied these last few weeks. This email also touched on some really core topics in the analyzer's design, so I wanted to take the proper time to respond to it in detail. Comments inline. On Jun 27, 2011, at 7:35 PM, Jordy Rose wrote: > Hi Ted and cfe-dev. In my free time I've been looking into the issue of "transfer functions" in the analyzer ? a supposedly swappable implementation of logic for evaluating function calls and Objective-C messages, among other things. As the Checker infrastructure has grown, almost all of the once-unique transfer function logic can now be implemented using essentially-pluggable Checkers. > > That wouldn't be such a problem, except that in reality the implementation of TransferFuncs in the analyzer is CFRefCount, which mixes in a whole bunch of logic for tracking retain counts and Cocoa conventions. We shouldn't need to run that with every run of the analyzer (though most of the code will early-exit when it realizes it's not relevant). Some of the code has already been extracted to a class called RetainReleaseChecker, but at this point we can do a lot more. A bit of history first. GRTransferFuncs was the original "checker" interface. It was the plugin callback logic from GRExprEngine to something outside that defined the domain-specific checker logic. I knew it would one day grow into something else, but I wanted to keep the checker logic separate from the core analysis engine, and GRTransferFuncs was a nice abstraction that serviced to provide the hooks for abstracting out checker logic. Now we have the Checker interface, would allows us to define multiple checkers that run together. The Checker interface doesn't fully replace GRTransferFuncs, but I don't think it should. I see two possible directions: (a) Move all retain/release checker logic out of a GRTransferFuncs subclass (where it is now) into RetainReleaseChecker. The remaining logic, which really concerns core analysis logic (e.g., ivar invalidation), gets moved to GRExprEngine. We then remove GRTransferFuncs entirely. (b) Move all retain/release checker logic out of a GRTransferFuncs subclass into RetainReleaseChecker. Instead of moving the remaining logic into GRExprEngine, however, we keep a simplified GRTransferFuncs around. Personally, I think we should move in the direction of (a), because what will be left in the GRTransferFuncs subclass after we move all the retain/release logic out of it will be fairly fundamental stuff to the analyzer. I also think (b) adds another conceptual entity to the codebase that isn't necessarily needed. That said, let's explore more what you propose, and go from there. > > This e-mail is recording my thoughts on this and how far I got; it's not intended as an immediate call to action. > > In fact, the behavior of a hypothetical SimpleTransferFuncs only includes this: > - Invalidating ivars of ObjC message receiver > - Invalidating ivars of 'this' for C++ method call > - Invalidating function/method args > - Invalidating globals if necessary > - Conjuring return values > > And these effects only happen if no checker claims "evalCall" for a given function call. Indeed, but why not just move these into GRExprEngine entirely? Why do we even need a SimpleTransferFuncs? The only reason to have a GRTransferFuncs interface is if we want the option to swap something else in its place in the future. So why might we want to do this? Well, there is the open issue of inter-procedural analysis. One way to do that would be to swap in a different GRTransferFuncs. But I honestly don't think that's the right direction. I think inter-procedural analysis will be a core part of the analyzer engine. Yes, we will likely modularize it, perhaps making the inter-procedural analysis configurable, but GRTransferFuncs isn't that mechanism. GRTransferFuncs was meant to capture domain-specific checker reasoning, and we have something better for that now: the Checker interface. > > > On the other hand, a fully-fledged RetainReleaseChecker with all existing functionality isn't quite possible because of four things: > > - CFBugReports use function call summaries to show the retain/release history of a leaked object. Function summaries are currently associated with ExplodedNodes in a DenseMap. In addition to being somewhat inefficient (summaries for calls that have nothing to do with ref-counting are also saved), Checkers are const, and so can't store summaries in a mutable data structure. (Marking the map 'mutable' doesn't feel like the right solution.) I don't have a solution for this. I don't actually see an issue here, but I recognize your concerns. Let's separate your two statements. First, the primary and original role of the function summaries is to memoize the behavior of a function/method call for quick application during evalCall. It's a computational hack. I should add that Checkers are not strictly const. They are allowed to contain data. What they shouldn't record is data specific to analyzing a given function or path. All that data should be in GRState. There is no reason, however, that Checkers cannot have any on-the-side data to cache computation that they do over and over again, particularly if it has nothing to do with a specific path. Note that we will likely continue to add new ways for Checkers to have on-the-side *context-sensitive* data without having to include them in the Checker object itself. In the case of path-specific data, Checker state is stored in GRStates via the GDM. There is no reason we couldn't extend this concept to allowing checkers to associate data with (say) LocationContexts if we wanted them to be able to cache some data local to the analysis of a specific function or method. We haven't needed that yet, but we have all sorts of ways for Checkers to potentially store data. Data that goes into the Checker object, however, really should be something general that is useful for the entire lifetime of the checker. The function summaries used by CFRefCount fall into that category. So from the perspective of a design argument, there is no reason why these couldn't be moved to the RetainReleaseChecker. Now what about the mapping of ExplodedNodes to function summaries? That is indeed a hack, because we don't have ways to annotate ExplodedNodes with information that checkers could use to reconstruct critical information for generating diagnostics. If we had proper annotations for ExplodedNodes, we would be able to attach this information in a structured way to nodes. That said, what would those annotations look like? All the summaries do is record what transfer function logic was used at a given point. That might not be the most efficient annotation, but that's a fairly basic one. Moreover, summaries are reused, so we don't necessarily create many of them. In the end you are just talking about a mapping from ExplodedNodes to a handful of commonly used summaries. I'm not convinced that is a serious scalability issue. > > - There's no evalObjCMessage, for the very sensible reason that overriding a method can make its behavior totally different. Nevertheless, there are a few messages we /do/ want to model in a RetainReleaseChecker: -[NSAutoreleasePool init], -[NSAutoreleasePool addObject:], -retain, -release, and -autorelease. Fortunately, pretty much everything else would fit in a PostObjCMessage implementation. I'm not convinced that these couldn't be modeled using a PostObjCMessage implementation as well. There's nothing really special about them, and really we want to move to a place where all domain-specific knowledge can be modeled in checkers. Consider -retain. All it does is add a +1 retain count. That could easily be a post condition. The only other thing that is hard here is that -retain returns an alias to the receiver. We don't have a good way right now for a checker to articulate that except with an evalObjCMessage, but I can envision other strategies. For example, a checker should be able to say (for many reasons) that the return value aliases the receiver, and articulate that as a /constraint/ to the ConstraintManager. This requires the ability to possibly unify symbols (i.e., the symbol for the receiver's value and the symbol for the return value), but it is really powerful. I also think this generalizes well to inter-procedural analysis. For example, suppose we had *both* domain-specific knowledge from a checker about a given function as well as information garnered from analyzing the function's implementation. That means we have two sources of information about the return value of the function call. The ability to articulate domain-specific knowledge using *declarative* constraints is really the only way to naturally unify such information. In the absence of symbol unification, however, we can probably special case the aliasing issue, at least for this specific case. For example, we can create another (perhaps transient) Checker callback that asks: does this function/method return an alias? Then ExprEngine can get in the business of doing the aliasing, and the checker just handles the truly checker-specific stuff (e.g., the reference counts). > - When function/method arguments are invalidated, their reference counts persist. But any other sort of invalidation does destroy reference count records. Currently this uses a whitelist built before invalidating the various regions referenced in a call, but with no special consideration given to RetainReleaseChecker, that'd be a little strange. I can think of two ways around this: reconstruct the whitelist on every region invalidation if we're in a function call (probably not a good idea) and reconstruct the reference bindings in a post-call check (by walking backwards through ExplodedNodes to the pre-call state). I think reconstructing the bindings would be extremely gross. You'd basically be hacking on semantics in what's in the Store. Unless the checker is trying to simulate a function call that has "writes" in the background, we shouldn't go this way. I have a conflicting opinion, in that I think we just don't have the right APIs right now to express a dialog between the invalidation and the checker logic. In the case of the RetainReleaseChecker, we have information when we desire not to invalidate specific symbol values, and we do that with a whitelist. But region invalidation should only happen in a few contexts. When we invalidate regions, we can make it a cooperative process between the StoreManager and the checkers. The checkers are told what regions are being invalidated, and *why*, and the checkers should have enough information to determine if that reason is sufficient to invalidate whatever checker-specific state they are tracking. For example, suppose we have: id x = [[? alloc] init] foo(x) In the RetainReleaseChecker, currently we whitelist the parameter value of 'x' because it is a top-level parameter value, and we know the retain/release conventions. Thus even though the transitive values reachable through 'x' are invalidated (e.g., containing ivars), we don't need to drop the refcount information on that symbol. However, consider: y->x = [? alloc] init] bar(y) In this case, the value in the field 'x' wouldn't be whitelisted. This is because it is a nested value, and we really have no idea what bar() will do to it. So what's the purpose of the whitelist? It's to capture context-specific information of how values were being used in a function call when they (or their sub values) were invalidated. But this is all just context. I don't have a concrete proposal, but essentially if the region invalidation logic communicated to the checkers what was getting invalidated, and in what contexts, the checkers could make the appropriate decision on whether or not to invalidate their associated state. Anyhow, this is just a brain dump, but I really think this just comes down to having more declarative APIs: we are invalidating a region, so tell the checkers we are invalidating it, and the checkers are given enough context to decide what they want to do with that and modify the state accordingly. The whitelist is just a hack to construct this context. While this is similar to what you propose, there is no back-patching of the reference bindings, and the checkers stay completely out of the business of manipulating the symbolic store. > > - CFRefCount currently registers a GRState::Printer for printing the retain count info in a state. Checkers currently have no way to register printers for custom state info, and that should probably be fixed anyway. Agreed. > > Everything else that CFRefCount currently does can be done using the current Checker architecture. (For more detailed but less structured notes on this, see attached .) Absolutely. I'll follow up on your notes in a separate email (possibly off the list). I don't want to derail the focus of this first high-level response before diving into more details. > > > As for what I /did/ accomplish, evalBind and evalAssume can be migrated to RetainReleaseChecker almost without changes: This looks good. > > Everything /other/ than evalCall, evalObjCMessage, and evalSummary can be moved to RetainReleaseChecker, but that leaves plenty of hackery behind: This also looks great. The hackery that remains looks like it falls into the talking points above: essentially what to do with GRTransferFuncs. I personally believe with the right additional APIs, we can migrate this logic to the analyzer core, and give checkers the right tools to do what they want without needing to implement these methods or have a GRTransferFuncs class at all. I'm interested in hearing more of your opinions here. > I'm going to stop this work here...it's where it crosses the line from "simple migration" to "design decisions". Once the four issues above are resolved, it should actually be pretty straightforward to eliminate TransferFuncs and CFRefCount from the analyzer and make RetainReleaseChecker optional. Which would be great, right? Agreed whole-heartedly. Thanks so much for spear heading this! From kremenek at apple.com Fri Jul 15 00:50:00 2011 From: kremenek at apple.com (Ted Kremenek) Date: Thu, 14 Jul 2011 22:50:00 -0700 Subject: [cfe-dev] Removing "TransferFuncs" from the analyzer In-Reply-To: <4BEED18C-9590-4DAD-AF05-85B598D0C8D3@belkadan.com> References: <4BEED18C-9590-4DAD-AF05-85B598D0C8D3@belkadan.com> Message-ID: On Jul 14, 2011, at 8:48 PM, Jordy Rose wrote: > > Oops, right, I meant why the summaries have to be attached to ExplodedNodes -- the only time they're used once attached is for bug reports, and only in those three cases (-dealloc, MakeCollectable in non-GC, and retain/release in GC). Which, actually, is something we could change right now, by only attaching summaries if they have interesting ArgEffects. The actual RetainSummaryManager can still live on RetainReleaseChecker when everything blows over. > > For AnnotatedGRState, I think if we're going to add new infrastructure this isn't a bad way to go. I would think Annotations would be a lot like a GRState's GDM, a wrapper around some kind of tag-keyed map (though it doesn't have to be immutable until it goes into an AnnotatedGRState. > > How do annotations interact with ExplodedNodes being FoldingSetNodes? Are annotations merged, or do they make two different nodes unique? (If they make the nodes unique, does that mean all annotation data?which I'm currently thinking of like a GRState's GDM?has to be profile able?) I was thinking something very simple. First, the design is that annotations are sparse. They rarely happen, so there is no reason to put them in the ExplodedNodes themselves. I was just thinking of ExplodedGraph of having an side table from ExplodedNodes to (optional) annotations. Basically, when ExplodedGraph::getNode() is called, it is passed an AnnotatedGRState. An AnnotatedGRState is just a package for GRState and annotations (that are somehow managed). Think of AnnotatedGRState as a value object, like SVal. ExplodedGraph::getNode() then just unpacks the GRState, does what it does now, and if the AnnotatedGRState had an annotation we just plop it in the side table. That said, you are right about ExplodedNodes being FoldingSetNodes. Annotations really have more to do with the *transition* between two nodes, so perhaps the annotation should be associated with the edge between the predecessor and the successor node? That way you can have multiple annotations associated with an ExplodedNode, but those annotations are contextual to the transition. If we did this, then maybe ExplodedNode:;getNode() wouldn't reason about annotations at all. Instead, Checker::addTransition() could call generate the new node, and then tell ExplodedGraph to add an annotation between the predecessor node (which CheckerContext knows about) and the new node. The annotation would then go into a side table. I actually really like this idea. Right now CFRefCount (and possibly other checkers) need to walk the ExplodedGraph path to *infer* transition information. Annotations just record that information for transition. If we got clever with our representation, and we wanted the option to have annotations be lightweight but possibly prolific, we can possibly optimize how edge sets are represented in ExplodedNode to better store annotations. I see that as an optimization problem. I really believe that the majority of nodes, which are not checker generated, would not have annotations. > > Lastly, I'm a little wary of using AnnotatedGRState to carry around a state+annotations, rather than just adding an Annotations parameter to getNode, but I guess it makes things easier for existing code. We'll probably have to look at all the callers of getNode either way if we make this change. Understood. My idea for AnnotatedGRState was to provide a way to accrue annotations while manipulating a GRState, but it really is just packaging. I'm fine with not introducing a class like this for starters, and just working with some basic APIs as you suggest. There is value in keeping the APIs simple, and building up what we actually need. > > I guess the big question is whether or not this is actually necessary: will checkers need a way to associate information with certain nodes /besides/ RetainReleaseChecker? Probably yes, but there should probably be a guideline to avoid over-using annotations, putting off most of the work until you know there's a diagnostic. I think this would be useful for a variety of checkers. The retain release checker would make use of it, and so would a general malloc/free checker, or really any type state checker (including the PthreadLockChecker). Type state checking is one of the most frequent checking we can do. Another thing we could possibly provide are "implicit annotations." For example, suppose we provide an API to query the annotations for an pair. Some of those could be explicitly recorded in a side table, and some of those could be lazily generated from a Checker via a callback. For example, this is essentially what CFRefCount does: it reverse engineers state transitions when generating diagnostics. For most cases it doesn't need the function summary (which could be captured by an explicit annotation recorded in the ExplodedGraph), and for those cases the annotation could be generated lazily and on-demand. Mechanically, much of the logic in the RetainReleaseChecker for generating diagnostics would be the same, but it could be modularized based on a generic, and extensible annotation API for node transitions. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110714/81bf27e2/attachment-0001.html From jediknil at belkadan.com Fri Jul 15 02:14:28 2011 From: jediknil at belkadan.com (Jordy Rose) Date: Fri, 15 Jul 2011 00:14:28 -0700 Subject: [cfe-dev] Removing "TransferFuncs" from the analyzer In-Reply-To: References: <4BEED18C-9590-4DAD-AF05-85B598D0C8D3@belkadan.com> Message-ID: <746ACF09-17B5-4222-B075-2A7D166B31CD@belkadan.com> On Jul 14, 2011, at 22:50, Ted Kremenek wrote: > That said, you are right about ExplodedNodes being FoldingSetNodes. Annotations really have more to do with the *transition* between two nodes, so perhaps the annotation should be associated with the edge between the predecessor and the successor node? That way you can have multiple annotations associated with an ExplodedNode, but those annotations are contextual to the transition. If we did this, then maybe ExplodedNode:;getNode() wouldn't reason about annotations at all. Instead, Checker::addTransition() could call generate the new node, and then tell ExplodedGraph to add an annotation between the predecessor node (which CheckerContext knows about) and the new node. The annotation would then go into a side table. > > I actually really like this idea. Right now CFRefCount (and possibly other checkers) need to walk the ExplodedGraph path to *infer* transition information. Annotations just record that information for transition. I like this too. Most BugReporterVisitors are looking for the first state where some condition holds, but that's implemented by comparing a node and its predecessor. Having methods explicitly reasoning about at edges could make this a lot easier. On the other hand, can two checkers generate the same edge, differing only in annotation data? Since ExplodedNodes are uniqued, and their pred/succ sets are uniqued, my guess is that this is entirely possible. That seems to make the difference between an edge and a node much less interesting. > If we got clever with our representation, and we wanted the option to have annotations be lightweight but possibly prolific, we can possibly optimize how edge sets are represented in ExplodedNode to better store annotations. I see that as an optimization problem. I really believe that the majority of nodes, which are not checker generated, would not have annotations. The dumb way seems to be a DenseMap, Annotation>, where Annotation is some kind of small map data structure. Alternately, Annotation could be a simple tag-value pair?if checkers want to store more than one annotation in a single edge, they have to do it manually, under a single tag. I think the "two checkers, same edge" problem is going to rule this out though. (This has echoes of the SummaryMap in CFRefCount now, but available to all checkers. I guess that's all right.) >> I guess the big question is whether or not this is actually necessary: will checkers need a way to associate information with certain nodes /besides/ RetainReleaseChecker? Probably yes, but there should probably be a guideline to avoid over-using annotations, putting off most of the work until you know there's a diagnostic. > > I think this would be useful for a variety of checkers. The retain release checker would make use of it, and so would a general malloc/free checker, or really any type state checker (including the PthreadLockChecker). Type state checking is one of the most frequent checking we can do. I'm guessing you mean /diagnostics/ for type state checkers, because the actual type state /is/ path-sensitive non-transient information. I can't think of a time when a checker needs to look at a past node /except/ when reverse-walking the graph, and I don't know when checkers reverse-walk the graph besides emitting path diagnostics. Oh wait, I can think of one: persisting the retain-release whitelist across evalCall. :-) But that's even more transient than usual, and shouldn't stay in the graph after evalCall finishes. So, just kidding. > Another thing we could possibly provide are "implicit annotations." For example, suppose we provide an API to query the annotations for an pair. Some of those could be explicitly recorded in a side table, and some of those could be lazily generated from a Checker via a callback. For example, this is essentially what CFRefCount does: it reverse engineers state transitions when generating diagnostics. For most cases it doesn't need the function summary (which could be captured by an explicit annotation recorded in the ExplodedGraph), and for those cases the annotation could be generated lazily and on-demand. Mechanically, much of the logic in the RetainReleaseChecker for generating diagnostics would be the same, but it could be modularized based on a generic, and extensible annotation API for node transitions. Would this be where you can ask a checker to get an annotation for /any/ edge? Or where a checker registers an annotation on a specific edge, but with a callback rather than an immediate value? (The former seems to have little benefit over explicitly calling a helper function.) What do you see as a "usual" annotation? A direct translation of CFRefCount would be "any function summary", possibly optimized to "any function summary that affects ref counts". My original plan was "events that can't (easily) be inferred from a change in RefVal". It sounds like you might be suggesting "all changes in RefVals", so that we can directly ask something like graph->getAnnotation(edge, symbol); I'll admit that looks pretty, but I'm not sure I'd want to be recording that much information in the table when you really can just compare the two nodes' states' RefVals. And if this calls a callback on RetainReleaseChecker, well, why not just do that to begin with? this->getChange(edge, symbol); ...but mostly I'm just trying to play devil's advocate so that we don't pick something because it's the /only/ idea. (I'm glad you think adding the new infrastructure is worth not abusing the path-sensitive data; that's a call I wouldn't make.) Jordy From kremenek at apple.com Fri Jul 15 02:14:43 2011 From: kremenek at apple.com (Ted Kremenek) Date: Fri, 15 Jul 2011 00:14:43 -0700 Subject: [cfe-dev] Removing "TransferFuncs" from the analyzer In-Reply-To: References: Message-ID: <9D662FF8-4D60-4B1F-BDBF-B11E666F7640@apple.com> On Jul 14, 2011, at 10:21 PM, Ted Kremenek wrote: >> - CFBugReports use function call summaries to show the retain/release history of a leaked object. Function summaries are currently associated with ExplodedNodes in a DenseMap. In addition to being somewhat inefficient (summaries for calls that have nothing to do with ref-counting are also saved), Checkers are const, and so can't store summaries in a mutable data structure. (Marking the map 'mutable' doesn't feel like the right solution.) I don't have a solution for this. > > I don't actually see an issue here, but I recognize your concerns. Let's separate your two statements. > > First, the primary and original role of the function summaries is to memoize the behavior of a function/method call for quick application during evalCall. It's a computational hack. I should add that Checkers are not strictly const. They are allowed to contain data. What they shouldn't record is data specific to analyzing a given function or path. All that data should be in GRState. There is no reason, however, that Checkers cannot have any on-the-side data to cache computation that they do over and over again, particularly if it has nothing to do with a specific path. One amendment: I do recognize that the checker call backs are currently marked 'const'. I took this road to enforce a mentality that the checker writers should think about keeping state in GRState, and not in the checker itself. First-time checker writers often don't understand why keeping information specific to a path in GRState is so critical. This decision can always be revisited. My point, however, was that the idea of keeping data associated with a Checker is not strictly taboo if done correctly. If we want to enforce the 'const'ness strictly, then it may be worthwhile to provide checkers a way to store other side data. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110715/c4e95b3e/attachment.html From jediknil at belkadan.com Fri Jul 15 03:11:55 2011 From: jediknil at belkadan.com (Jordy Rose) Date: Fri, 15 Jul 2011 01:11:55 -0700 Subject: [cfe-dev] Removing "TransferFuncs" from the analyzer In-Reply-To: References: Message-ID: <03F4E785-0672-4D0C-A352-CCC9212601EE@belkadan.com> On Jul 14, 2011, at 22:21, Ted Kremenek wrote: > On Jun 27, 2011, at 7:35 PM, Jordy Rose wrote: > >> In fact, the behavior of a hypothetical SimpleTransferFuncs only includes this: >> - Invalidating ivars of ObjC message receiver >> - Invalidating ivars of 'this' for C++ method call >> - Invalidating function/method args >> - Invalidating globals if necessary >> - Conjuring return values >> >> And these effects only happen if no checker claims "evalCall" for a given function call. > > Indeed, but why not just move these into GRExprEngine entirely? Why do we even need a SimpleTransferFuncs? The only reason to have a GRTransferFuncs interface is if we want the option to swap something else in its place in the future. Hm, good point. I don't think we'd be replacing the current transfer funcs anytime soon, so we probably wouldn't need to keep them around in the future. > So why might we want to do this? Well, there is the open issue of inter-procedural analysis. One way to do that would be to swap in a different GRTransferFuncs. But I honestly don't think that's the right direction. I think inter-procedural analysis will be a core part of the analyzer engine. Yes, we will likely modularize it, perhaps making the inter-procedural analysis configurable, but GRTransferFuncs isn't that mechanism. GRTransferFuncs was meant to capture domain-specific checker reasoning, and we have something better for that now: the Checker interface. > Now what about the mapping of ExplodedNodes to function summaries? That is indeed a hack, because we don't have ways to annotate ExplodedNodes with information that checkers could use to reconstruct critical information for generating diagnostics. If we had proper annotations for ExplodedNodes, we would be able to attach this information in a structured way to nodes. That said, what would those annotations look like? All the summaries do is record what transfer function logic was used at a given point. That might not be the most efficient annotation, but that's a fairly basic one. Moreover, summaries are reused, so we don't necessarily create many of them. In the end you are just talking about a mapping from ExplodedNodes to a handful of commonly used summaries. I'm not convinced that is a serious scalability issue. I suppose it's not: in a 2000-node stress test this probably maxes out at 16~32KB to store the map; much less to store the cache of summaries. Hardly a big memory drain (numbers totally made up, though). The discussion of ExplodedNode- or ExplodedGraph-edge-associated annotations should probably stay in the other thread fork. RetainReleaseChecker would most likely keep the summary manager code as is for its regular work; sorry to be unclear. >> - There's no evalObjCMessage, for the very sensible reason that overriding a method can make its behavior totally different. Nevertheless, there are a few messages we /do/ want to model in a RetainReleaseChecker: -[NSAutoreleasePool init], -[NSAutoreleasePool addObject:], -retain, -release, and -autorelease. Fortunately, pretty much everything else would fit in a PostObjCMessage implementation. > > I'm not convinced that these couldn't be modeled using a PostObjCMessage implementation as well. There's nothing really special about them, and really we want to move to a place where all domain-specific knowledge can be modeled in checkers. > > Consider -retain. All it does is add a +1 retain count. That could easily be a post condition. The only other thing that is hard here is that -retain returns an alias to the receiver. We don't have a good way right now for a checker to articulate that except with an evalObjCMessage, but I can envision other strategies. For example, a checker should be able to say (for many reasons) that the return value aliases the receiver, and articulate that as a /constraint/ to the ConstraintManager. This requires the ability to possibly unify symbols (i.e., the symbol for the receiver's value and the symbol for the return value), but it is really powerful. I also think this generalizes well to inter-procedural analysis. For example, suppose we had *both* domain-specific knowledge from a checker about a given function as well as information garnered from analyzing the function's implementation. That means we have two sources of information about the return value of the function call. The ability to articulate domain-specific knowledge using *declarative* constraints is really the only way to naturally unify such information. IPA's going to wreak havoc on our current evalCall-based checkers. :-) I agree that the 'retain' effect is easy to model post-call, but the aliasing thing is a problem. A postExpr-based checker can't even assume that a conjured return value hasn't already been squirrelled away in some other checker's slice of the GDM. Even if we tag it with a FIXME and/or limit evalObjCMessage to RetainReleaseChecker, I think we should take the shortcut for now and save the aliasing problem for later. Though we should probably /only/ use it for receiver-aliasing -retain and -autorelease, and use postExpr for everything else (including the other effects of -retain and -autorelease). > In the absence of symbol unification, however, we can probably special case the aliasing issue, at least for this specific case. For example, we can create another (perhaps transient) Checker callback that asks: does this function/method return an alias? Then ExprEngine can get in the business of doing the aliasing, and the checker just handles the truly checker-specific stuff (e.g., the reference counts). That seems like a very specific check that would only be useful until we got a [[return_alias]] attribute, then got it into all the frameworks. :-) But it would solve the problem. >> - When function/method arguments are invalidated, their reference counts persist. But any other sort of invalidation does destroy reference count records. Currently this uses a whitelist built before invalidating the various regions referenced in a call, but with no special consideration given to RetainReleaseChecker, that'd be a little strange. I can think of two ways around this: reconstruct the whitelist on every region invalidation if we're in a function call (probably not a good idea) and reconstruct the reference bindings in a post-call check (by walking backwards through ExplodedNodes to the pre-call state). > > I think reconstructing the bindings would be extremely gross. You'd basically be hacking on semantics in what's in the Store. Unless the checker is trying to simulate a function call that has "writes" in the background, we shouldn't go this way. > > I have a conflicting opinion, in that I think we just don't have the right APIs right now to express a dialog between the invalidation and the checker logic. In the case of the RetainReleaseChecker, we have information when we desire not to invalidate specific symbol values, and we do that with a whitelist. But region invalidation should only happen in a few contexts. When we invalidate regions, we can make it a cooperative process between the StoreManager and the checkers. The checkers are told what regions are being invalidated, and *why*, and the checkers should have enough information to determine if that reason is sufficient to invalidate whatever checker-specific state they are tracking. That's not a bad idea, but it's hard to do. Currently, the StoreManager has no idea why things are invalidated, either; it just has a "current expr" pointer. (It's worth noting that currently we /only/ invalidate regions due to function or methods calls, including C++ 'new' calls and constructors...and also including CStringChecker::evalCall. So maybe passing the current expr down would be "good enough".) Hm, maybe I should stop forking the threads of conversation, and stick to one issue at a time. Though it might be worth checking in the "free" changes that can be migrated cleanly out of CFRefCount, so that all that's left is the actual problems. Thanks for your patience and all the help with this. :-) Jordy From nicola.gigante at gmail.com Fri Jul 15 05:24:53 2011 From: nicola.gigante at gmail.com (Nicola Gigante) Date: Fri, 15 Jul 2011 12:24:53 +0200 Subject: [cfe-dev] -Warray-bounds seems over-zealous on Clang In-Reply-To: References: <20110712150748.GA4913@britannica.bec.de> <0F9FF1EB-96F2-4ACB-8070-32EFD6B23CD4@apple.com> <372E1D9D-8435-427E-9122-94A81E046187@apple.com> <09911FA8-1679-4FDA-B363-5211C44A3DDE@apple.com> <6CB2BAE3-D4D3-4299-A526-916B51FBD9D0@gmail.com> Message-ID: <1FFBA94C-191A-466B-90B8-EABC654736BB@gmail.com> Il giorno 13/lug/2011, alle ore 22.21, John McCall ha scritto: > On Jul 13, 2011, at 1:10 PM, Nicola Gigante wrote: >> Il giorno 13/lug/2011, alle ore 17.49, Ted Kremenek ha scritto: >>> On Jul 13, 2011, at 8:05 AM, David Blaikie wrote: >>> >>>> So, options that seem to be being discussed include: >>>> >>>> 1) suppress this warning in all cases where the array is of length 1 and the last element in a struct >>>> 1.1) refinement: only when the length is specified explicitly and not via macro expansion, etc. (as John suggested) >>>> 1.2) refinement: under c99 recommend a fixup to use flexible arrays >>>> 2) split the warning in two, the second being the cases suppressed by the above option (probably less interesting if 1.1 is implemented) >>>> >>> >>> (1) and (2) aren't mutually exclusive. (2) is still useful when the heuristics implied by 1.1 and 1.2 aren't good enough. >> >> I've tried to write such a patch, as it seemed simple, but I'm stuck because I don't know enough >> about internal clang's APIs yet. >> Until now, I've come up with the simple patch attached, that disables the warning if >> the array is declared inside a record type and the size is one. >> Questions: >> - From the NamedDecl* object representing the array declaration, how do I know if it's declared last in the struct? > > It should be a FieldDecl, and its parent should be a RecordDecl. I don't think there's a cleaner solution than just iterating through the fields of the record and complaining if it's not the last one. > >> - From the NamedDecl*, how do I know if the size of the member declaration comes from a macro expansion? > > The exception should apply to: > - a field of a struct, where > - the field's TypeLoc is a (possibly parenthesized) ConstantArrayTypeLoc and > - the size expression in that TypeLoc is a (possibly parenthesized) IntegerLiteral and > - the source location of that literal is not a macro ID. > Hello. I've attached the patch. It seems to work as intended. The only thing missing is to split up the warning. How to do it? Also what do you mean by "possibly parenthesized" ConstantArrayTypeLoc and IntegerLiteral? > John. Nicola -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110715/e603d3f6/attachment-0002.html -------------- next part -------------- A non-text attachment was scrubbed... Name: pgsql_warning.patch Type: application/octet-stream Size: 3741 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110715/e603d3f6/attachment-0001.obj -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110715/e603d3f6/attachment-0003.html From peter at 2ndquadrant.com Fri Jul 15 07:24:03 2011 From: peter at 2ndquadrant.com (Peter Geoghegan) Date: Fri, 15 Jul 2011 13:24:03 +0100 Subject: [cfe-dev] -Warray-bounds seems over-zealous on Clang In-Reply-To: <1FFBA94C-191A-466B-90B8-EABC654736BB@gmail.com> References: <20110712150748.GA4913@britannica.bec.de> <0F9FF1EB-96F2-4ACB-8070-32EFD6B23CD4@apple.com> <372E1D9D-8435-427E-9122-94A81E046187@apple.com> <09911FA8-1679-4FDA-B363-5211C44A3DDE@apple.com> <6CB2BAE3-D4D3-4299-A526-916B51FBD9D0@gmail.com> <1FFBA94C-191A-466B-90B8-EABC654736BB@gmail.com> Message-ID: On 15 July 2011 11:24, Nicola Gigante wrote: > > Il giorno 13/lug/2011, alle ore 22.21, John McCall ha scritto: > > On Jul 13, 2011, at 1:10 PM, Nicola Gigante wrote: > > Il giorno 13/lug/2011, alle ore 17.49, Ted Kremenek ha scritto: > > On Jul 13, 2011, at 8:05 AM, David Blaikie wrote: > > So, options that seem to be being discussed include: > > 1) suppress this warning in all cases where the array is of length 1 and the > last element in a struct > ? 1.1) refinement: only when the length is specified explicitly and not via > macro expansion, etc. (as John suggested) > ? 1.2) refinement: under c99 recommend a fixup to use flexible arrays > 2) split the warning in two, the second being the cases suppressed by the > above option (probably less interesting if 1.1 is implemented) > > > (1) and (2) aren't mutually exclusive. ?(2) is still useful when the > heuristics implied by 1.1 and 1.2 aren't good enough. > > I've tried to write such a patch, as it seemed simple, but I'm stuck because > I don't know enough > about internal clang's APIs yet. > Until now, I've come up with the simple patch attached, that disables the > warning if > the array is declared inside a record type and the size is one. > Questions: > - From the NamedDecl* object representing the array declaration, how do I > know if it's declared last in the struct? > > It should be a FieldDecl, and its parent should be a RecordDecl. ?I don't > think there's a cleaner solution than just iterating through the?fields of > the record and complaining if it's not the last one. > > - From the NamedDecl*, how do I know if the size of the member declaration > comes from a macro expansion? > > The exception should apply to: > ??- a field of a struct, where > ??- the field's TypeLoc is a (possibly parenthesized) ConstantArrayTypeLoc > and > ??- the size expression in that TypeLoc is a (possibly parenthesized) > IntegerLiteral and > ??- the source location of that literal is not a macro ID. > > Hello. > I've attached the patch. It seems to work as intended. The only thing > missing is to split up > the warning. How to do it? > Also what do you mean by "possibly parenthesized" ConstantArrayTypeLoc and > IntegerLiteral? While I thank you for your efforts, I don't see why we have to explicitly use C89 to avoid the warning, since we're only avoiding the warning under circumstances exactly consistent with the use of the idiom. What's valid in C89 is valid in C99, with very few exceptions. Just because this is arguably bad style in C99 does not mean that we should see a warning - warnings are supposed to prevent downright errors that are still valid code. No one would seriously suggest that we should have warnings when C style casts are used in C++ on non-POD types, even though they're extremely hazardous there. Precedent matters. Consider that in PostgreSQL, a large C application with almost 1000 C files, we only see this warning 4 or 5 times. The sorts of errors we hope to protect people from with this warning are very unlikely to be statically detectable. -- Peter Geoghegan ? ? ? http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services From kremenek at apple.com Fri Jul 15 10:13:21 2011 From: kremenek at apple.com (Ted Kremenek) Date: Fri, 15 Jul 2011 08:13:21 -0700 Subject: [cfe-dev] Removing "TransferFuncs" from the analyzer In-Reply-To: <03F4E785-0672-4D0C-A352-CCC9212601EE@belkadan.com> References: <03F4E785-0672-4D0C-A352-CCC9212601EE@belkadan.com> Message-ID: <9C0BFA37-24CD-44C2-82C7-DC7C4F8B1057@apple.com> On Jul 15, 2011, at 1:11 AM, Jordy Rose wrote: >> In the absence of symbol unification, however, we can probably special case the aliasing issue, at least for this specific case. For example, we can create another (perhaps transient) Checker callback that asks: does this function/method return an alias? Then ExprEngine can get in the business of doing the aliasing, and the checker just handles the truly checker-specific stuff (e.g., the reference counts). > > That seems like a very specific check that would only be useful until we got a [[return_alias]] attribute, then got it into all the frameworks. :-) But it would solve the problem. Just to pull this one out with a brief comment: this isn't specific to checkers. For example, if we see: void foo(int *a, int *b) { ? if (a == b) { ? } } We currently don't have a good way to reason about the case where "a == b". If we have acquired constraints on the symbols referenced by 'a' and 'b', then they have to be unified on the true branch (and if the constraints are incompatible, the branch is infeasible). This pops up more times than one might think. I agree that this is something to explore as a separate discussion in its own right, but it is a key piece of missing analyzer functionality. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110715/fdf7e5c1/attachment.html From michael.b.price.dev at gmail.com Fri Jul 15 11:11:59 2011 From: michael.b.price.dev at gmail.com (Michael Price) Date: Fri, 15 Jul 2011 11:11:59 -0500 Subject: [cfe-dev] auto and decltype availability Message-ID: Does anyone know which released version first had the auto and decltype features 'turned on'? And generally speaking, is there an easy way to determine this for any given C++0x feature? For some background, I'm working on a series of C++0x presentations at the company I work for, and at the end of every presentation I have a chart that shows the availability of the features I discussed that day. Currently we are not using clang, but I have an entry for it because I want to show that clang is trying to keeping pace with GCC and surpassing IBM XL C/C++ and Sun Studio. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110715/50433d0d/attachment.html From nicola.gigante at gmail.com Fri Jul 15 11:39:23 2011 From: nicola.gigante at gmail.com (Nicola Gigante) Date: Fri, 15 Jul 2011 18:39:23 +0200 Subject: [cfe-dev] -Warray-bounds seems over-zealous on Clang In-Reply-To: References: <20110712150748.GA4913@britannica.bec.de> <0F9FF1EB-96F2-4ACB-8070-32EFD6B23CD4@apple.com> <372E1D9D-8435-427E-9122-94A81E046187@apple.com> <09911FA8-1679-4FDA-B363-5211C44A3DDE@apple.com> <6CB2BAE3-D4D3-4299-A526-916B51FBD9D0@gmail.com> <1FFBA94C-191A-466B-90B8-EABC654736BB@gmail.com> Message-ID: Il giorno 15/lug/2011, alle ore 14.24, Peter Geoghegan ha scritto: > > While I thank you for your efforts, I don't see why we have to > explicitly use C89 to avoid the warning, since we're only avoiding the > warning under circumstances exactly consistent with the use of the > idiom. > > What's valid in C89 is valid in C99, with very few exceptions. Just > because this is arguably bad style in C99 does not mean that we should > see a warning - warnings are supposed to prevent downright errors that > are still valid code. No one would seriously suggest that we should > have warnings when C style casts are used in C++ on non-POD types, > even though they're extremely hazardous there. Precedent matters. > Hm, I just tried to implement what seemed to be the general accepted solution to your problem. That said, if I understand your point, you want to develop a huge crossplatform codebase written in C, but: - You can't fully use C99 because some compilers won't support it (MSVC). - So your code is C89, but you can force C89 compliance because you rely on some widely supported C99 feature (I suppose these are trivial things like mixing declarations and code or //-style comments, or the scope of the for() initializers, what else?) - You want to support a lot of platforms and compilers, but you're reluctant to tune your build system for specific compilers - You don't want to deal with compilers differences with macro tricks because of "code hygiene" - You want your code to compile warning-clean on all the compilers you support, but without disabling warnings from the command line. Clang or not, I don't think these requirements are generally easy to fulfill, you need to make a choice. Anyway, this patch suppress the warning also in -std=gnu89 mode, which is the default for gcc, so you could simply pass -std=gnu89 to both compilers and you'll have true drop-in compatibility. > -- > Peter Geoghegan http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Training and Services Bye, Nicola P.S. this was just an exercise to me, so reviews for the patch are welcomed anyway P.P.S. clang accepts flexibles arrays also with -std=c89 -pedantic. Is it compliant? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110715/f3e00465/attachment.html From matthieu.monrocq at gmail.com Fri Jul 15 11:52:17 2011 From: matthieu.monrocq at gmail.com (Matthieu Monrocq) Date: Fri, 15 Jul 2011 18:52:17 +0200 Subject: [cfe-dev] Spurious warning: unused parameter when used only in an expression error-ing out In-Reply-To: <1A296920-4197-48CC-A3EF-371FC60BCA0A@apple.com> References: <1A296920-4197-48CC-A3EF-371FC60BCA0A@apple.com> Message-ID: 2011/7/14 Ted Kremenek > We should probably not emit a -Wunused-[x] warning in cases where a > function doesn't fully parse correctly. Please file a bug. > > Done: http://llvm.org/bugs/show_bug.cgi?id=10371 > On Jul 14, 2011, at 12:34 PM, Matthieu Monrocq wrote: > > Hello clang, > > I made a strange discovery with a small helper function I wrote: > > If one test the following (short) program: > > struct A; > > void sink(A,int); > > void func(A const& a, int x, int y) { > sink(a + x, y); > } > > The following errors get emitted: > > $ clang -fsyntax-only -Wunused-parameter unused_parameter.cpp > unused_parameter.cpp:15:11: error: invalid operands to binary expression > ('const A' and 'int') > sink(a + x, y); > ~ ^ ~ > unused_parameter.cpp:14:34: warning: unused parameter 'y' > [-Wunused-parameter] > void func(A const& a, int x, int y) { > ^ > 1 warning and 1 error generated. > > > The first one is expected, however it seems its presence somehow > short-circuit the analysis of the whole expression and as a result we get > the spurious warning... > > I feel that this is unwelcome, because it obfuscates the true error > (especially since I tend to compile with -Werror). > > > For reference, I use the following version of Clang: > > $ clang --version > clang version 3.0 (trunk 132889) > Target: i686-pc-mingw32 > Thread model: posix > > I could not find any mention of such an issue with my Google-fu in the > cfe-dev archive, so please let me know if it already came up and it was > deemed unimportant. > > -- Matthieu > _______________________________________________ > 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/20110715/5bd41c5c/attachment-0001.html From thakis at chromium.org Fri Jul 15 12:28:34 2011 From: thakis at chromium.org (Nico Weber) Date: Fri, 15 Jul 2011 10:28:34 -0700 Subject: [cfe-dev] Using clang as production compiler for chrome/mac In-Reply-To: <8D720D4E-1F0D-4A02-8D3C-27A3B6A43075@apple.com> References: <8D720D4E-1F0D-4A02-8D3C-27A3B6A43075@apple.com> Message-ID: On Mon, Jul 11, 2011 at 9:11 AM, Eric Christopher wrote: > > On Jul 9, 2011, at 5:34 PM, Nico Weber wrote: > > I imagine that it might be useful for the clang project, since we have > quite a bit of monitoring in chromium land (automated perf graphs, > compile time graphs, crash reporting that $many users have opted in > to), so that we could find and report regressions in clang reasonably > quickly. Do you think this is interesting at all? > > I do think this is interesting. It shouldn't be too bad since one of the > goals > we have for clang is to keep it roughly shippable at all times on ToT. Would you mind if we keep our branches in the upstream llvm svn repo? They would be numerous (we typically start a new stable release every six weeks) but wouldn't see much traffic. Nico From echristo at apple.com Fri Jul 15 12:30:51 2011 From: echristo at apple.com (Eric Christopher) Date: Fri, 15 Jul 2011 10:30:51 -0700 Subject: [cfe-dev] Using clang as production compiler for chrome/mac In-Reply-To: References: <8D720D4E-1F0D-4A02-8D3C-27A3B6A43075@apple.com> Message-ID: <599A0F9B-0163-4029-BCE3-E74F72D5A6B3@apple.com> On Jul 15, 2011, at 10:28 AM, Nico Weber wrote: > On Mon, Jul 11, 2011 at 9:11 AM, Eric Christopher wrote: >> >> On Jul 9, 2011, at 5:34 PM, Nico Weber wrote: >> >> I imagine that it might be useful for the clang project, since we have >> quite a bit of monitoring in chromium land (automated perf graphs, >> compile time graphs, crash reporting that $many users have opted in >> to), so that we could find and report regressions in clang reasonably >> quickly. Do you think this is interesting at all? >> >> I do think this is interesting. It shouldn't be too bad since one of the >> goals >> we have for clang is to keep it roughly shippable at all times on ToT. > > Would you mind if we keep our branches in the upstream llvm svn repo? > They would be numerous (we typically start a new stable release every > six weeks) but wouldn't see much traffic. I don't think it would be much of a problem, branches are cheap. :) You'll want to make a "chromium" branch directory to mirror the existing apple one. -eric From jediknil at belkadan.com Fri Jul 15 13:21:04 2011 From: jediknil at belkadan.com (Jordy Rose) Date: Fri, 15 Jul 2011 11:21:04 -0700 Subject: [cfe-dev] Removing "TransferFuncs" from the analyzer In-Reply-To: <9C0BFA37-24CD-44C2-82C7-DC7C4F8B1057@apple.com> References: <03F4E785-0672-4D0C-A352-CCC9212601EE@belkadan.com> <9C0BFA37-24CD-44C2-82C7-DC7C4F8B1057@apple.com> Message-ID: On Jul 15, 2011, at 8:13, Ted Kremenek wrote: > > On Jul 15, 2011, at 1:11 AM, Jordy Rose wrote: > >>> In the absence of symbol unification, however, we can probably special case the aliasing issue, at least for this specific case. For example, we can create another (perhaps transient) Checker callback that asks: does this function/method return an alias? Then ExprEngine can get in the business of doing the aliasing, and the checker just handles the truly checker-specific stuff (e.g., the reference counts). >> >> That seems like a very specific check that would only be useful until we got a [[return_alias]] attribute, then got it into all the frameworks. :-) But it would solve the problem. > > Just to pull this one out with a brief comment: this isn't specific to checkers. For example, if we see: > > void foo(int *a, int *b) { > ? > if (a == b) { > ? > } > } > > We currently don't have a good way to reason about the case where "a == b". If we have acquired constraints on the symbols referenced by 'a' and 'b', then they have to be unified on the true branch (and if the constraints are incompatible, the branch is infeasible). This pops up more times than one might think. > > I agree that this is something to explore as a separate discussion in its own right, but it is a key piece of missing analyzer functionality. Oh, yes, aliasing is very important. Whether or not a specific function/method call returns an alias seems less so, since eventually a postCall checker could do that naively with assumeEQ. But I suppose "eventually" might be "in a month" or it might be "years from now when someone else is looking for a GSoC project", so maybe a temporary returnsArgAlias check is better than a temporary evalObjCMessage check. From clattner at apple.com Fri Jul 15 13:36:51 2011 From: clattner at apple.com (Chris Lattner) Date: Fri, 15 Jul 2011 11:36:51 -0700 Subject: [cfe-dev] Using clang as production compiler for chrome/mac In-Reply-To: <599A0F9B-0163-4029-BCE3-E74F72D5A6B3@apple.com> References: <8D720D4E-1F0D-4A02-8D3C-27A3B6A43075@apple.com> <599A0F9B-0163-4029-BCE3-E74F72D5A6B3@apple.com> Message-ID: <76F23148-FC8C-4C44-B6FD-3389DA682F42@apple.com> On Jul 15, 2011, at 10:30 AM, Eric Christopher wrote: > > On Jul 15, 2011, at 10:28 AM, Nico Weber wrote: > >> On Mon, Jul 11, 2011 at 9:11 AM, Eric Christopher wrote: >>> >>> On Jul 9, 2011, at 5:34 PM, Nico Weber wrote: >>> >>> I imagine that it might be useful for the clang project, since we have >>> quite a bit of monitoring in chromium land (automated perf graphs, >>> compile time graphs, crash reporting that $many users have opted in >>> to), so that we could find and report regressions in clang reasonably >>> quickly. Do you think this is interesting at all? >>> >>> I do think this is interesting. It shouldn't be too bad since one of the >>> goals >>> we have for clang is to keep it roughly shippable at all times on ToT. >> >> Would you mind if we keep our branches in the upstream llvm svn repo? >> They would be numerous (we typically start a new stable release every >> six weeks) but wouldn't see much traffic. > > I don't think it would be much of a problem, branches are cheap. :) > > You'll want to make a "chromium" branch directory to mirror the existing apple one. Makes sense to me. -Chris From clattner at apple.com Fri Jul 15 13:38:01 2011 From: clattner at apple.com (Chris Lattner) Date: Fri, 15 Jul 2011 11:38:01 -0700 Subject: [cfe-dev] auto and decltype availability In-Reply-To: References: Message-ID: <7095410B-7639-4E57-BB54-E7AF516236A5@apple.com> On Jul 15, 2011, at 9:11 AM, Michael Price wrote: > Does anyone know which released version first had the auto and decltype features 'turned on'? And generally speaking, is there an easy way to determine this for any given C++0x feature? > > For some background, I'm working on a series of C++0x presentations at the company I work for, and at the end of every presentation I have a chart that shows the availability of the features I discussed that day. Currently we are not using clang, but I have an entry for it because I want to show that clang is trying to keeping pace with GCC and surpassing IBM XL C/C++ and Sun Studio. Hi Michael, We recommend that people write code that uses __has_feature to check for a feature, not compare against a compiler version number. These are documented here: http://clang.llvm.org/docs/LanguageExtensions.html#feature_check -Chris From jfreeman at cse.tamu.edu Fri Jul 15 15:02:54 2011 From: jfreeman at cse.tamu.edu (John Freeman) Date: Fri, 15 Jul 2011 15:02:54 -0500 Subject: [cfe-dev] Test Design Message-ID: <4E209CEE.6050009@cse.tamu.edu> How are tests designed in Clang? More specifically: - How should a test file be named? For tests in CXX/, it seems to be named after a paragraph in the standard, with "-0x" for C++0x feature testing, and placed in a directory named after the section in the standard. If so, what document are we using for the C++0x standard? I thought it might be N3242, but there is a test named clang/test/CXX/expr/expr.prim/p12-0x.cpp, and I don't see a paragraph 12 in section 5.1 [expr.prim]. - What should go in the test? For C++, I'm guessing we test parsing diagnostics in CXX/ and sema diagnostics in SemaCXX/? Most tests in CXX/ are run with "-fsyntax-only -verify", but some aren't. How do I determine the best way to run the test? From vanboxem.ruben at gmail.com Fri Jul 15 15:59:33 2011 From: vanboxem.ruben at gmail.com (Ruben Van Boxem) Date: Fri, 15 Jul 2011 22:59:33 +0200 Subject: [cfe-dev] x64 windows (MinGW) and "__declspec(dllimport)" emits a "unknown attribute warning" Message-ID: Hi, This small piece of code: > int main() {} > __declspec(dllexport) void foo (int); void bar (void) { foo (0); } emits following warning when Clang is built for x86_64-w64-mingw32, but not when built for i686-w64-mingw32: > foo.c:3:12: warning: unknown attribute 'dllexport' ignored [-Wattributes] > __declspec(dllexport) void foo (int); void bar (void) { foo (0); } > ?????????? ^ > :128:38: note: expanded from: > #define __declspec(a) __attribute__((a)) > ???????????????????????????????????? ^ > 1 warning generated. Note that this code has an undefined reference, that's not the point. I tried looking through Clang's code where this warning is emitted, but can't find anything relevant. The code differentiating x86 and x64 (or most likely just "forgetting" x64 mingw) is probably deeper in the code. Any help is appreciated. Ruben From vanboxem.ruben at gmail.com Fri Jul 15 16:00:59 2011 From: vanboxem.ruben at gmail.com (Ruben Van Boxem) Date: Fri, 15 Jul 2011 23:00:59 +0200 Subject: [cfe-dev] MinGW problem with GSL In-Reply-To: <5BE2F5F9-7FE7-42C8-BA28-6A46EEA81ADF@apple.com> References: <5BE2F5F9-7FE7-42C8-BA28-6A46EEA81ADF@apple.com> Message-ID: 2011/7/7 Eric Christopher : >>> >>> >>> a) try passing -no-integrated-as to see if it's a problem with passing down arguments >> >> Same problem. I have also verified all the commands being run against >> a matching GCC install. > > Good to know. > >> >>> b) try to get a testcase of the failing instructions >> >> Heh, well, yeah. Euhm... My assembly isn't that... good, and that's >> being optimistic. As in, I know *nothing* about it, except that it >> exists. So here I go: >> >> The bits of assembly causing the problem are these: >> >> .Ltmp224: >> ? ? ? .loc ? ?4 129 5 >> ? ? ? movsd ? %xmm6, -616(%rbp) >> ? ? ? fldl ? ?-616(%rbp) >> ? ? ? fstpt ? -772(%rbp) >> ? ? ? fld ? ? %ss >> ? ? ? #APP >> ? ? ? fabs; >> ? ? ? #NO_APP >> ? ? ? fstpl ? -624(%rbp) >> ? ? ? movsd ? .LCPI3_10(%rip), %xmm0 >> ... >> .Ltmp521: >> ? ? ? fstpt ? -656(%rbp) >> ? ? ? fld ? ? %ss >> ? ? ? #APP >> ? ? ? fabs; >> ? ? ? #NO_APP >> >> I can't find these or even similar bits in GCC's output, which >> probably isn't surprising. >> >> The source file this comes from is pretty big, with a lot of GSL >> specific functionality being used (kind of expected). I do know GCC >> does not have a "fld" instruction anywhere in its version of the >> assembler output. >> >> Would this have anything to do with the header? This is >> used when Clang is used, but a mingw-w64 (which provides the header) >> dev told me it includes ansidecl.h which is a GCC internal header. It >> defines (among a *lot* of other things) some va_args things, but >> there's no error when clang parses this file, so it probably is not >> causing the issue. Plus, the only place where it's being used is GSL's >> sys/infnan.c (grep -r , which couldn't possibly be included in the >> file causing the error. >> >> I also tried a i686-w64-mingw32 built Clang with matching mingw-w64 >> CRT and GCC. It hits the same problem. >> >> Any tips on what simple testcase couldd produce an fld instruction? >> GCC doesn't in this case, which only adds to the oddity. > > Not sure that's really important at the moment, it might be nice to get > you to file a bug report with a preprocessed source file testcase > and the command line that'll get this to show. Sorry for the delay in getting these files to you, but since then the problem has gone away. GSL compiles fine, although the first test fails (keeps running endlessly). But I will investigate the cause here. Ruben From echristo at apple.com Fri Jul 15 16:01:42 2011 From: echristo at apple.com (Eric Christopher) Date: Fri, 15 Jul 2011 14:01:42 -0700 Subject: [cfe-dev] MinGW problem with GSL In-Reply-To: References: <5BE2F5F9-7FE7-42C8-BA28-6A46EEA81ADF@apple.com> Message-ID: <0DF02E28-155E-4E68-A6FC-F461E3BEED4D@apple.com> > > Sorry for the delay in getting these files to you, but since then the > problem has gone away. GSL compiles fine, although the first test > fails (keeps running endlessly). But I will investigate the cause > here. Excellent. Thanks! -eric From michael.b.price.dev at gmail.com Fri Jul 15 16:05:08 2011 From: michael.b.price.dev at gmail.com (Michael Price) Date: Fri, 15 Jul 2011 16:05:08 -0500 Subject: [cfe-dev] auto and decltype availability In-Reply-To: <7095410B-7639-4E57-BB54-E7AF516236A5@apple.com> References: <7095410B-7639-4E57-BB54-E7AF516236A5@apple.com> Message-ID: I think that is a perfectly fine recommendation, but this isn't for writing code. This is for letting people know which version of the compiler first introduced a certain feature. For instance, if we want to use static_assert, we may (depending on other feature availability) only want to update to the version of clang that supported the features that we desire. It's hard to convince managers that we should update (or even switch compilers) if we have to respond with "use __has_feature in the code". On Fri, Jul 15, 2011 at 1:38 PM, Chris Lattner wrote: > > On Jul 15, 2011, at 9:11 AM, Michael Price wrote: > > > Does anyone know which released version first had the auto and decltype > features 'turned on'? And generally speaking, is there an easy way to > determine this for any given C++0x feature? > > > > For some background, I'm working on a series of C++0x presentations at > the company I work for, and at the end of every presentation I have a chart > that shows the availability of the features I discussed that day. Currently > we are not using clang, but I have an entry for it because I want to show > that clang is trying to keeping pace with GCC and surpassing IBM XL C/C++ > and Sun Studio. > > Hi Michael, > > We recommend that people write code that uses __has_feature to check for a > feature, not compare against a compiler version number. These are > documented here: > http://clang.llvm.org/docs/LanguageExtensions.html#feature_check > > -Chris > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110715/b21d9765/attachment.html From dgregor at apple.com Fri Jul 15 16:09:01 2011 From: dgregor at apple.com (Douglas Gregor) Date: Fri, 15 Jul 2011 14:09:01 -0700 Subject: [cfe-dev] Test Design In-Reply-To: <4E209CEE.6050009@cse.tamu.edu> References: <4E209CEE.6050009@cse.tamu.edu> Message-ID: On Jul 15, 2011, at 1:02 PM, John Freeman wrote: > How are tests designed in Clang? More specifically: > > - How should a test file be named? > > For tests in CXX/, it seems to be named after a paragraph in the > standard, with "-0x" for C++0x feature testing, and placed in a > directory named after the section in the standard. If so, what document > are we using for the C++0x standard? I thought it might be N3242, but > there is a test named clang/test/CXX/expr/expr.prim/p12-0x.cpp, and I > don't see a paragraph 12 in section 5.1 [expr.prim]. Use the FDIS as your guide. Many tests predate the FDIS, and paragraphs have moved around, so the test paragraph numbers are out of date. > - What should go in the test? > > For C++, I'm guessing we test parsing diagnostics in CXX/ and sema > diagnostics in SemaCXX/? Parsing tests can also go into test/Parse. test/CXX is meant for general testing. Some parsing, mostly semantic analysis. > Most tests in CXX/ are run with "-fsyntax-only -verify", but some > aren't. How do I determine the best way to run the test? If it doesn't require code generation, use -fsyntax-only -verify. - Doug From supertri at google.com Fri Jul 15 18:01:21 2011 From: supertri at google.com (Caitlin Sadowski) Date: Fri, 15 Jul 2011 16:01:21 -0700 Subject: [cfe-dev] Proposal for thread safety attributes for Clang In-Reply-To: References: <63C66C00-8996-4CC2-855A-76CA19678D1A@apple.com> Message-ID: Jordy/Rui, Ah, interesting! Of course, the two are somewhat orthogonal since the thread safety attribute proposal is annotation-based (and hence are able to deal with a larger set of issues). Cheers, Caitlin On Thu, Jul 14, 2011 at 4:58 PM, Jordy Rose wrote: > It's worth noting that Rui Paulo was also working on at least a simple form of lock analysis for the static analyzer. Unfortunately my mail filters seemed to have thrown away some replies to my messages, so I only just responded to his latest patch. The subject line (on cfe-commits) is "PthreadLock Checker enhancements". > > Jordy > > > On Jul 14, 2011, at 15:46, Chandler Carruth wrote: > >> To clarify one particular (but hopefully small) point... >> >> On Thu, Jul 14, 2011 at 3:09 PM, Caitlin Sadowski wrote: >>> However, our core synchronization libraries have >>> been successfully annotated, and it looks like less than 15% of >>> annotated code is impacted by these limitations. >> >> The limitations should take the form of "we can't provide warnings for improper locking", not false positives. >> >> My hope is that work on more advanced and thorough checking of these locking behaviors can be implemented in the static analyzer, based on the core attributes, but using more expensive analysis techniques and showing possible errors as well as definite errors. >> _______________________________________________ >> cfe-dev mailing list >> cfe-dev at cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > > From clattner at apple.com Fri Jul 15 18:40:40 2011 From: clattner at apple.com (Chris Lattner) Date: Fri, 15 Jul 2011 16:40:40 -0700 Subject: [cfe-dev] auto and decltype availability In-Reply-To: References: <7095410B-7639-4E57-BB54-E7AF516236A5@apple.com> Message-ID: <4659FD8F-BAE5-4E1E-83BD-22AA6A49DC68@apple.com> On Jul 15, 2011, at 2:05 PM, Michael Price wrote: > I think that is a perfectly fine recommendation, but this isn't for writing code. This is for letting people know which version of the compiler first introduced a certain feature. For instance, if we want to use static_assert, we may (depending on other feature availability) only want to update to the version of clang that supported the features that we desire. > > It's hard to convince managers that we should update (or even switch compilers) if we have to respond with "use __has_feature in the code". Ok, are you asking about llvm.org compilers, apple compilers, someone else's compilers? Everyone has their own versioning scheme :). -Chris > > On Fri, Jul 15, 2011 at 1:38 PM, Chris Lattner wrote: > > On Jul 15, 2011, at 9:11 AM, Michael Price wrote: > > > Does anyone know which released version first had the auto and decltype features 'turned on'? And generally speaking, is there an easy way to determine this for any given C++0x feature? > > > > For some background, I'm working on a series of C++0x presentations at the company I work for, and at the end of every presentation I have a chart that shows the availability of the features I discussed that day. Currently we are not using clang, but I have an entry for it because I want to show that clang is trying to keeping pace with GCC and surpassing IBM XL C/C++ and Sun Studio. > > Hi Michael, > > We recommend that people write code that uses __has_feature to check for a feature, not compare against a compiler version number. These are documented here: > http://clang.llvm.org/docs/LanguageExtensions.html#feature_check > > -Chris > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110715/3cc89a1c/attachment.html From howarth at bromo.med.uc.edu Fri Jul 15 19:56:34 2011 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Fri, 15 Jul 2011 20:56:34 -0400 Subject: [cfe-dev] return statements without expressions in non-void functions revisited Message-ID: <20110716005634.GA23585@bromo.med.uc.edu> In porting texlive under clang for fink, we have run into the same issue from this thread... http://comments.gmane.org/gmane.comp.compilers.clang.devel/10688 In that thread it was suggested that -std=c89 might be modified to convert the error into a warning for... [MacPro:~] howarth% clang -std=gnu89 -c type1_test.c -fno-strict-aliasing type1_test.c:24:8: error: non-void function 'PSFakePop' should return a value [-Wreturn-type] else Error0("PSFakePop: Stack empty\n"); ^ type1_test.c:13:54: note: instantiated from: #define Error0(errmsg) { CC; IfTrace0(TRUE, errmsg); Error;} ^ type1_test.c:11:32: note: instantiated from: #define Error {errflag = TRUE; return;} ^ 1 error generated. This appears to never have been implemented however. Any suggestions on the best approach to revise the following testcase to avoid the error under clang (which I also see under icc but not gcc trunk even with -std=c90)? -------------------- type1_test.c ----------------------- #define TRUE (1) typedef double DOUBLE; /* 64 bits */ int currentchar = -1; /* for error reporting */ static int errflag; #define MAXPSFAKESTACK 32 /* Max depth of fake PostScript stack (local) */ static DOUBLE PSFakeStack[MAXPSFAKESTACK]; #define CC IfTrace1(TRUE, "'%03o ", currentchar) #define Error {errflag = TRUE; return;} #define Error0(errmsg) { CC; IfTrace0(TRUE, errmsg); Error;} #define Error1(errmsg,arg) { CC; IfTrace1(TRUE, errmsg, arg); Error;} static DOUBLE PSFakePop(void); static int PSFakeTop; /* PSFakePop: Removes a number from the top of the fake PostScript stack */ static DOUBLE PSFakePop () { if (PSFakeTop >= 0) return(PSFakeStack[PSFakeTop--]); else Error0("PSFakePop: Stack empty\n"); /*NOTREACHED*/ } ---------------------------------------------------------- From michael.b.price.dev at gmail.com Fri Jul 15 20:11:14 2011 From: michael.b.price.dev at gmail.com (Michael Price - Dev) Date: Fri, 15 Jul 2011 20:11:14 -0500 Subject: [cfe-dev] auto and decltype availability In-Reply-To: <4659FD8F-BAE5-4E1E-83BD-22AA6A49DC68@apple.com> References: <7095410B-7639-4E57-BB54-E7AF516236A5@apple.com> <4659FD8F-BAE5-4E1E-83BD-22AA6A49DC68@apple.com> Message-ID: <205150D8-6036-4622-951C-E729B8624EDB@gmail.com> I guess I'll be verbose then. :-) What is the release version number(s) of the LLVM project that first included a clang frontend that linked in a version of libclang that was able to correctly (according to a reasonably recent draft of the C+ +0x standard) handle the 'auto' and 'decltype' keywords? Sent from my iPhone On Jul 15, 2011, at 6:40 PM, Chris Lattner wrote: > > On Jul 15, 2011, at 2:05 PM, Michael Price wrote: > >> I think that is a perfectly fine recommendation, but this isn't for >> writing code. This is for letting people know which version of the >> compiler first introduced a certain feature. For instance, if we >> want to use static_assert, we may (depending on other feature >> availability) only want to update to the version of clang that >> supported the features that we desire. >> >> It's hard to convince managers that we should update (or even >> switch compilers) if we have to respond with "use __has_feature in >> the code". > > Ok, are you asking about llvm.org compilers, apple compilers, > someone else's compilers? Everyone has their own versioning > scheme :). > > -Chris > >> >> On Fri, Jul 15, 2011 at 1:38 PM, Chris Lattner >> wrote: >> >> On Jul 15, 2011, at 9:11 AM, Michael Price wrote: >> >> > Does anyone know which released version first had the auto and >> decltype features 'turned on'? And generally speaking, is there an >> easy way to determine this for any given C++0x feature? >> > >> > For some background, I'm working on a series of C++0x >> presentations at the company I work for, and at the end of every >> presentation I have a chart that shows the availability of the >> features I discussed that day. Currently we are not using clang, >> but I have an entry for it because I want to show that clang is >> trying to keeping pace with GCC and surpassing IBM XL C/C++ and Sun >> Studio. >> >> Hi Michael, >> >> We recommend that people write code that uses __has_feature to >> check for a feature, not compare against a compiler version >> number. These are documented here: >> http://clang.llvm.org/docs/LanguageExtensions.html#feature_check >> >> -Chris >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110715/1bf22916/attachment.html From thakis at google.com Fri Jul 15 20:24:40 2011 From: thakis at google.com (Nico Weber) Date: Fri, 15 Jul 2011 18:24:40 -0700 Subject: [cfe-dev] auto and decltype availability In-Reply-To: <205150D8-6036-4622-951C-E729B8624EDB@gmail.com> References: <7095410B-7639-4E57-BB54-E7AF516236A5@apple.com> <4659FD8F-BAE5-4E1E-83BD-22AA6A49DC68@apple.com> <205150D8-6036-4622-951C-E729B8624EDB@gmail.com> Message-ID: Probably either 2.9 or none yet. Try it? :-) Nico Brevity due to phone On Jul 15, 2011 6:11 PM, "Michael Price - Dev" < michael.b.price.dev at gmail.com> wrote: > I guess I'll be verbose then. :-) > > What is the release version number(s) of the LLVM project that first > included a clang frontend that linked in a version of libclang that > was able to correctly (according to a reasonably recent draft of the C+ > +0x standard) handle the 'auto' and 'decltype' keywords? > > Sent from my iPhone > > On Jul 15, 2011, at 6:40 PM, Chris Lattner wrote: > >> >> On Jul 15, 2011, at 2:05 PM, Michael Price wrote: >> >>> I think that is a perfectly fine recommendation, but this isn't for >>> writing code. This is for letting people know which version of the >>> compiler first introduced a certain feature. For instance, if we >>> want to use static_assert, we may (depending on other feature >>> availability) only want to update to the version of clang that >>> supported the features that we desire. >>> >>> It's hard to convince managers that we should update (or even >>> switch compilers) if we have to respond with "use __has_feature in >>> the code". >> >> Ok, are you asking about llvm.org compilers, apple compilers, >> someone else's compilers? Everyone has their own versioning >> scheme :). >> >> -Chris >> >>> >>> On Fri, Jul 15, 2011 at 1:38 PM, Chris Lattner >>> wrote: >>> >>> On Jul 15, 2011, at 9:11 AM, Michael Price wrote: >>> >>> > Does anyone know which released version first had the auto and >>> decltype features 'turned on'? And generally speaking, is there an >>> easy way to determine this for any given C++0x feature? >>> > >>> > For some background, I'm working on a series of C++0x >>> presentations at the company I work for, and at the end of every >>> presentation I have a chart that shows the availability of the >>> features I discussed that day. Currently we are not using clang, >>> but I have an entry for it because I want to show that clang is >>> trying to keeping pace with GCC and surpassing IBM XL C/C++ and Sun >>> Studio. >>> >>> Hi Michael, >>> >>> We recommend that people write code that uses __has_feature to >>> check for a feature, not compare against a compiler version >>> number. These are documented here: >>> http://clang.llvm.org/docs/LanguageExtensions.html#feature_check >>> >>> -Chris >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110715/d3aeab83/attachment.html From csilvers at google.com Fri Jul 15 20:42:27 2011 From: csilvers at google.com (Craig Silverstein) Date: Fri, 15 Jul 2011 18:42:27 -0700 Subject: [cfe-dev] auto and decltype availability In-Reply-To: <205150D8-6036-4622-951C-E729B8624EDB@gmail.com> (Michael Price's message of "Fri\, 15 Jul 2011 20\:11\:14 -0500") References: <7095410B-7639-4E57-BB54-E7AF516236A5@apple.com> <4659FD8F-BAE5-4E1E-83BD-22AA6A49DC68@apple.com> <205150D8-6036-4622-951C-E729B8624EDB@gmail.com> Message-ID: } What is the release version number(s) of the LLVM project that first } included a clang frontend that linked in a version of libclang that } was able to correctly (according to a reasonably recent draft of the } C++0x standard) handle the 'auto' and 'decltype' keywords? In my limited experience, llvm releases are pretty far apart. You may be better served by just saying the date that the completed functionality was submitted to top-of-tree clang. How I would do it (caveat: I'm no expert on clang nor llvm), would be to look for commits that updated http://clang.llvm.org/cxx_status.html. One way to do that would be here: http://llvm.org/viewvc/llvm-project/cfe/trunk/www/cxx_status.html?view=log craig From howarth at bromo.med.uc.edu Fri Jul 15 21:30:02 2011 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Fri, 15 Jul 2011 22:30:02 -0400 Subject: [cfe-dev] return statements without expressions in non-void functions revisited Message-ID: <20110716023002.GA24079@bromo.med.uc.edu> A more complete test case of the issue we are faced with in compiling texlive with the strict treatment of return statements without expressions in non-void functions is attached. Any chance that the previously proposed -std=c89 warning behavior will be implemented for clang 3.0? Jack -------------- next part -------------- #include #define IfTrace0(condition,model) \ {if (condition) printf(model);} #define IfTrace1(condition,model,arg0) \ {if (condition) printf(model,arg0);} #define TRUE (1) typedef double DOUBLE; /* 64 bits */ int currentchar = -1; /* for error reporting */ static int errflag; #define MAXPSFAKESTACK 32 /* Max depth of fake PostScript stack (local) */ static DOUBLE PSFakeStack[MAXPSFAKESTACK]; #define CC IfTrace1(TRUE, "'%03o ", currentchar) #define Error {errflag = TRUE; return;} #define Error0(errmsg) { CC; IfTrace0(TRUE, errmsg); Error;} #define Error1(errmsg,arg) { CC; IfTrace1(TRUE, errmsg, arg); Error;} static DOUBLE PSFakePop(void); static int PSFakeTop; /* PSFakePop: Removes a number from the top of the fake PostScript stack */ static DOUBLE PSFakePop () { if (PSFakeTop >= 0) return(PSFakeStack[PSFakeTop--]); else Error0("PSFakePop: Stack empty\n"); /*NOTREACHED*/ } From tydeman at tybor.com Sat Jul 16 00:47:13 2011 From: tydeman at tybor.com (Fred J. Tydeman) Date: Fri, 15 Jul 2011 22:47:13 -0700 (PDT) Subject: [cfe-dev] New user: Linux: undefined reference to fetestexcept Message-ID: <020.b84c0a00e125214e.004@tybor.com> On Intel x86_64, running Linux Fedora 15 x86_64, after using Add Software of 'clang' and 'clang-doc', (which got version 2.8.11) when I try to compile and run the program http://www.tybor.com/tflt2int.c via the command line: clang -std=c99 tflt2int.c I am getting undefined references to both fetestexcept and feclearexcept Are there headers or libraries that I need to tell the compiler about? --- Fred J. Tydeman Tydeman Consulting tydeman at tybor.com Testing, numerics, programming +1 (775) 358-9748 Vice-chair of PL22.11 (ANSI "C") Sample C99+FPCE tests: http://www.tybor.com Savers sleep well, investors eat well, spenders work forever. From devlists at shadowlab.org Sat Jul 16 04:54:17 2011 From: devlists at shadowlab.org (Jean-Daniel Dupas) Date: Sat, 16 Jul 2011 11:54:17 +0200 Subject: [cfe-dev] auto and decltype availability In-Reply-To: References: <7095410B-7639-4E57-BB54-E7AF516236A5@apple.com> <4659FD8F-BAE5-4E1E-83BD-22AA6A49DC68@apple.com> <205150D8-6036-4622-951C-E729B8624EDB@gmail.com> Message-ID: <8FB2944C-FC02-4A1B-AF11-B4CC7FF4D1FD@shadowlab.org> Le 16 juil. 2011 ? 03:42, Craig Silverstein a ?crit : > } What is the release version number(s) of the LLVM project that first > } included a clang frontend that linked in a version of libclang that > } was able to correctly (according to a reasonably recent draft of the > } C++0x standard) handle the 'auto' and 'decltype' keywords? > > In my limited experience, llvm releases are pretty far apart. You may > be better served by just saying the date that the completed > functionality was submitted to top-of-tree clang. > > How I would do it (caveat: I'm no expert on clang nor llvm), would be > to look for commits that updated http://clang.llvm.org/cxx_status.html. > One way to do that would be here: > http://llvm.org/viewvc/llvm-project/cfe/trunk/www/cxx_status.html?view=log You suggestion make me think about an other file that let you know the exact revision that enabled a c++0x feature. clang/test/Lexer/has_feature_cxx0x.cpp This is the test files which test the __has_feature() macro for each c++0x feature. http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Lexer/has_feature_cxx0x.cpp?view=log For instance, auto_type was enabled in commit r126078 -- Jean-Daniel From richard at metafoo.co.uk Sat Jul 16 05:19:33 2011 From: richard at metafoo.co.uk (Richard Smith) Date: Sat, 16 Jul 2011 11:19:33 +0100 (BST) Subject: [cfe-dev] auto and decltype availability In-Reply-To: <8FB2944C-FC02-4A1B-AF11-B4CC7FF4D1FD@shadowlab.org> References: <8FB2944C-FC02-4A1B-AF11-B4CC7FF4D1FD@shadowlab.org> Message-ID: <51088.10.0.16.53.1310811573.squirrel@webmail.cantab.net> On Sat, July 16, 2011 10:54, Jean-Daniel Dupas wrote: > Le 16 juil. 2011 ? 03:42, Craig Silverstein a ?crit : >> } What is the release version number(s) of the LLVM project that first >> } included a clang frontend that linked in a version of libclang that >> } was able to correctly (according to a reasonably recent draft of the >> } C++0x standard) handle the 'auto' and 'decltype' keywords? >> >> >> In my limited experience, llvm releases are pretty far apart. You may >> be better served by just saying the date that the completed functionality >> was submitted to top-of-tree clang. >> >> How I would do it (caveat: I'm no expert on clang nor llvm), would be >> to look for commits that updated http://clang.llvm.org/cxx_status.html. >> One way to do that would be here: >> http://llvm.org/viewvc/llvm-project/cfe/trunk/www/cxx_status.html?view=l >> og > > > You suggestion make me think about an other file that let you know the > exact revision that enabled a c++0x feature. > > clang/test/Lexer/has_feature_cxx0x.cpp > > This is the test files which test the __has_feature() macro for each > c++0x feature. > > http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Lexer/has_feature_cxx0 > x.cpp?view=log > > For instance, auto_type was enabled in commit r126078 The 'auto' type specifier became available in version 2.9. Some auto-related issues were fixed in r126166, and cxx_status.html was updated in r128787 in preparation for the 2.9 release. Full support for 'decltype' in the type of a function template required tracking instantiation dependence, which we did not yet do in version 2.9. However, 'decltype' in other contexts was working in 2.9 (and quite possibly in several earlier releases). Richard From seth.cantrell at gmail.com Sat Jul 16 11:31:36 2011 From: seth.cantrell at gmail.com (Seth Cantrell) Date: Sat, 16 Jul 2011 12:31:36 -0400 Subject: [cfe-dev] clang c++0x template function declaration error In-Reply-To: <4E12070C.80002@cse.tamu.edu> References: <4E12070C.80002@cse.tamu.edu> Message-ID: Could the diagnostics be improved over > test.cpp:4:6: note: candidate template ignored: substitution failure > [with T = Y] > auto type_constructor( void (T::*f)() ) -> X< T, f >; > ^ ? Maybe an added note that points at the f in X to say that that's why the substitution failed? Here's an example of a similar mistake: > #include > > template > void get(T const &t,size_t N) { > std::get(t); > } > > int main () { > get(std::make_tuple(1,'a',1.2),2); > } When compiling this the diagnostics include several notes like the following > /usr/include/c++/v1/__tuple:104:1: note: candidate template ignored: invalid explicitly-specified > argument for template parameter '_Ip' > get(array<_Tp, _Size>&) _NOEXCEPT; "invalid explicitly-specified argument for template parameter" is a little better but it'd be nice to see something pointing directly at the 'N' in std::get(t) saying it's not legal to use arguments as template parameters. Would this be hard to add? Maybe I can give it a try. On Jul 4, 2011, at 2:31 PM, John Freeman wrote: > On 7/4/2011 1:03 PM, Eli Friedman wrote: >> The declaration of the template type_constructor is broken. Think >> about it this way: type_constructor has one template parameter, so >> type_constructor should refer to a single function; however, you're >> trying to specify it as returning multiple types. > > Or put another way, the second template argument for X, "foo", should be > a constant function pointer, but the parameter to type_constructor, "f", > is not. > > - John > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From rjmccall at apple.com Sat Jul 16 13:45:45 2011 From: rjmccall at apple.com (John McCall) Date: Sat, 16 Jul 2011 11:45:45 -0700 Subject: [cfe-dev] clang c++0x template function declaration error In-Reply-To: References: <4E12070C.80002@cse.tamu.edu> Message-ID: <4A00250F-EF04-4B0C-AD62-47E959A2E5D0@apple.com> On Jul 16, 2011, at 9:31 AM, Seth Cantrell wrote: > Could the diagnostics be improved over > >> test.cpp:4:6: note: candidate template ignored: substitution failure >> [with T = Y] >> auto type_constructor( void (T::*f)() ) -> X< T, f >; >> ^ > > ? > > Maybe an added note that points at the f in X to say that that's why the substitution failed? While I agree that 'substitution failure' by itself is not very helpful, I'm very reluctant to use multiple notes per failed overload candidate, at least for the default console diagnostics. Is there a good way to explain the problem based on the kind of substitution failure? > Here's an example of a similar mistake: > >> #include >> >> template >> void get(T const &t,size_t N) { >> std::get(t); >> } >> >> int main () { >> get(std::make_tuple(1,'a',1.2),2); >> } > > When compiling this the diagnostics include several notes like the following > >> /usr/include/c++/v1/__tuple:104:1: note: candidate template ignored: invalid explicitly-specified >> argument for template parameter '_Ip' >> get(array<_Tp, _Size>&) _NOEXCEPT; > > "invalid explicitly-specified argument for template parameter" is a little better but it'd be nice to see something pointing directly at the 'N' in std::get(t) saying it's not legal to use arguments as template parameters. Would this be hard to add? Maybe I can give it a try. Again, we'd rather not introduce extra notes, but it would be fine to just specialize this note for common problems. For example, here you could say: note: candidate template ignored: explicit argument for template parameter '_lp' is not a type or maybe even note: candidate template ignored: explicit argument 'N' for template parameter '_lp' is not a type where N is a string derived from pretty-printing the argument expression. John. From seth.cantrell at gmail.com Sat Jul 16 22:04:13 2011 From: seth.cantrell at gmail.com (Seth Cantrell) Date: Sat, 16 Jul 2011 23:04:13 -0400 Subject: [cfe-dev] clang c++0x template function declaration error In-Reply-To: <4A00250F-EF04-4B0C-AD62-47E959A2E5D0@apple.com> References: <4E12070C.80002@cse.tamu.edu> <4A00250F-EF04-4B0C-AD62-47E959A2E5D0@apple.com> Message-ID: <2ED1EF1A-1E28-4590-9691-7AF80D9524CC@gmail.com> On Jul 16, 2011, at 2:45 PM, John McCall wrote: > On Jul 16, 2011, at 9:31 AM, Seth Cantrell wrote: >> Could the diagnostics be improved over >> >>> test.cpp:4:6: note: candidate template ignored: substitution failure >>> [with T = Y] >>> auto type_constructor( void (T::*f)() ) -> X< T, f >; >>> ^ >> >> ? >> >> Maybe an added note that points at the f in X to say that that's why the substitution failed? > > While I agree that 'substitution failure' by itself is not very helpful, I'm very reluctant to use multiple notes per failed overload candidate, at least for the default console diagnostics. Is there a good way to explain the problem based on the kind of substitution failure? Okay, I think not multiplying notes that way is good. Thinking about it more, it seems like this shouldn't even be a note attached to an error because I don't think there's any way the template could ever be instantiated. Instead as soon as clang sees: > template > auto type_constructor( void (T::*f)() ) -> X< T, f >; it seems like it should pop out an error declaring that the template is invalid (and explaining why by stating that the function's parameter 'f' can't be used as a non-type template parameter in X). I'm not exactly sure what the restrictions are on what values can be used as non-type template parameters, but it's obvious that the value has to be available at compile time. So later on, when the code tries to use this template the note can say something like this: > test.cpp:4:6: note: candidate template ignored: invalid template > template auto type_constructor( void (T::*f)() ) -> X< T, f >; > >> Here's an example of a similar mistake: >> >>> #include >>> >>> template >>> void get(T const &t,size_t N) { >>> std::get(t); >>> } >>> >>> int main () { >>> get(std::make_tuple(1,'a',1.2),2); >>> } >> >> When compiling this the diagnostics include several notes like the following >> >>> /usr/include/c++/v1/__tuple:104:1: note: candidate template ignored: invalid explicitly-specified >>> argument for template parameter '_Ip' >>> get(array<_Tp, _Size>&) _NOEXCEPT; >> >> "invalid explicitly-specified argument for template parameter" is a little better but it'd be nice to see something pointing directly at the 'N' in std::get(t) saying it's not legal to use arguments as template parameters. Would this be hard to add? Maybe I can give it a try. > > Again, we'd rather not introduce extra notes, but it would be fine to just specialize this note for common problems. For example, here you could say: > note: candidate template ignored: explicit argument for template parameter '_lp' is not a type > or maybe even > note: candidate template ignored: explicit argument 'N' for template parameter '_lp' is not a type > where N is a string derived from pretty-printing the argument expression. > > John. Similarly, instead of attaching extra notes to the error clang should be able to recognize that this case is an invalid use of a non-type template parameter. This way there wouldn't even be a reason to look at any candidate templates and all of the (possibly many) notes about failed candidate templates can be eliminated. All the developer needs to know is that you can't pass runtime values to template parameters, and clang can point him directly at the spot where he's trying to do that. > test.cpp:5:5: error: cannot instantiate templates using function parameter values. > std::get(t); > ^ > test.cpp:4:28: note: 'N' declared here > void get(T const &t,size_t N) { > ^~~~~~~~ From ppelletier at oblong.com Sat Jul 16 22:47:26 2011 From: ppelletier at oblong.com (Patrick Pelletier) Date: Sat, 16 Jul 2011 20:47:26 -0700 Subject: [cfe-dev] New user: Linux: undefined reference to fetestexcept In-Reply-To: <020.b84c0a00e125214e.004@tybor.com> References: <020.b84c0a00e125214e.004@tybor.com> Message-ID: <4E225B4E.1010003@oblong.com> Fred J. Tydeman wrote: > I am getting undefined references to both > fetestexcept and feclearexcept > > Are there headers or libraries that I need to tell > the compiler about? > You probably need "-lm". Not a clang-specific thing, though; you'd need that for gcc, too. --Patrick From dgregor at apple.com Sun Jul 17 00:09:16 2011 From: dgregor at apple.com (Douglas Gregor) Date: Sat, 16 Jul 2011 22:09:16 -0700 Subject: [cfe-dev] clang c++0x template function declaration error In-Reply-To: <2ED1EF1A-1E28-4590-9691-7AF80D9524CC@gmail.com> References: <4E12070C.80002@cse.tamu.edu> <4A00250F-EF04-4B0C-AD62-47E959A2E5D0@apple.com> <2ED1EF1A-1E28-4590-9691-7AF80D9524CC@gmail.com> Message-ID: <15A2BC9C-2CE2-411C-9109-6B99CB4ADC41@apple.com> On Jul 16, 2011, at 8:04 PM, Seth Cantrell wrote: > > On Jul 16, 2011, at 2:45 PM, John McCall wrote: > >> On Jul 16, 2011, at 9:31 AM, Seth Cantrell wrote: >>> Could the diagnostics be improved over >>> >>>> test.cpp:4:6: note: candidate template ignored: substitution failure >>>> [with T = Y] >>>> auto type_constructor( void (T::*f)() ) -> X< T, f >; >>>> ^ >>> >>> ? >>> >>> Maybe an added note that points at the f in X to say that that's why the substitution failed? >> >> While I agree that 'substitution failure' by itself is not very helpful, I'm very reluctant to use multiple notes per failed overload candidate, at least for the default console diagnostics. Is there a good way to explain the problem based on the kind of substitution failure? > > Okay, I think not multiplying notes that way is good. Thinking about it more, it seems like this shouldn't even be a note attached to an error because I don't think there's any way the template could ever be instantiated. Instead as soon as clang sees: > >> template >> auto type_constructor( void (T::*f)() ) -> X< T, f >; > > it seems like it should pop out an error declaring that the template is invalid (and explaining why by stating that the function's parameter 'f' can't be used as a non-type template parameter in X). I'm not exactly sure what the restrictions are on what values can be used as non-type template parameters, but it's obvious that the value has to be available at compile time. This is certainly something that Clang could detect by looking at the form of the declaration. The compiler is allowed (but not required) to reject this template (since there are no valid instantiations of the template). As for the more general case... it would be great to give more information about why a particular candidate failed during substitution, perhaps by trapping the diagnostic generated while performing the substitution and adding its text at the end of the "substitution failure" note. We certainly can't have multiple notes, though. - Doug From dgregor at apple.com Sun Jul 17 00:13:30 2011 From: dgregor at apple.com (Douglas Gregor) Date: Sat, 16 Jul 2011 22:13:30 -0700 Subject: [cfe-dev] auto and decltype availability In-Reply-To: <51088.10.0.16.53.1310811573.squirrel@webmail.cantab.net> References: <8FB2944C-FC02-4A1B-AF11-B4CC7FF4D1FD@shadowlab.org> <51088.10.0.16.53.1310811573.squirrel@webmail.cantab.net> Message-ID: <28CC7672-4086-4F34-B0D0-20B1A635EC38@apple.com> On Jul 16, 2011, at 3:19 AM, Richard Smith wrote: > On Sat, July 16, 2011 10:54, Jean-Daniel Dupas wrote: >> Le 16 juil. 2011 ? 03:42, Craig Silverstein a ?crit : >>> } What is the release version number(s) of the LLVM project that first >>> } included a clang frontend that linked in a version of libclang that >>> } was able to correctly (according to a reasonably recent draft of the >>> } C++0x standard) handle the 'auto' and 'decltype' keywords? >>> >>> >>> In my limited experience, llvm releases are pretty far apart. You may >>> be better served by just saying the date that the completed functionality >>> was submitted to top-of-tree clang. >>> >>> How I would do it (caveat: I'm no expert on clang nor llvm), would be >>> to look for commits that updated http://clang.llvm.org/cxx_status.html. >>> One way to do that would be here: >>> http://llvm.org/viewvc/llvm-project/cfe/trunk/www/cxx_status.html?view=l >>> og >> >> >> You suggestion make me think about an other file that let you know the >> exact revision that enabled a c++0x feature. >> >> clang/test/Lexer/has_feature_cxx0x.cpp >> >> This is the test files which test the __has_feature() macro for each >> c++0x feature. >> >> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Lexer/has_feature_cxx0 >> x.cpp?view=log >> >> For instance, auto_type was enabled in commit r126078 > > The 'auto' type specifier became available in version 2.9. Some > auto-related issues were fixed in r126166, and cxx_status.html was updated > in r128787 in preparation for the 2.9 release. > > Full support for 'decltype' in the type of a function template required > tracking instantiation dependence, which we did not yet do in version 2.9. > However, 'decltype' in other contexts was working in 2.9 (and quite > possibly in several earlier releases). Thank you, Richard. For (almost) all practical purposes, auto and decltype were in LLVM/Clang 2.9. Instantiation dependence only affects name mangling at this point. The meta-point here is that we should certainly track this better. GCC's C++0x status page shows which GCC version introduced each C++0x feature. We should do the same (for llvm.org's releases; vendors can communicate with their customers through their own channels). - Doug From ryuuta at gmail.com Sun Jul 17 08:43:25 2011 From: ryuuta at gmail.com (Ryuta Suzuki) Date: Sun, 17 Jul 2011 22:43:25 +0900 Subject: [cfe-dev] Compiling boost with -std=c++0x (and -stdlib=libc++) Message-ID: Hi, I have trouble compiling the following trivial boost program #include int main() { return 0; } Actually, clang and libc++ work perfectly fine: [ryuta at oroppas]$ clang++ -stdlib=libc++ ./boost_thread.cpp However, once we deploy -std=c++0x flag, [ryuta at oroppas]$ clang++ -std=c++0x -stdlib=libc++ ./boost_thread.cpp In file included from ./boost_thread.cpp:1: In file included from /usr/include/boost/thread/thread.hpp:17: /usr/include/boost/thread/pthread/thread_data.hpp:36:17: error: call to deleted constructor of 'boost::shared_ptr' func(func_),value(value_) ^ ~~~~~ /usr/include/boost/smart_ptr/shared_ptr.hpp:164:25: note: function has been explicitly marked deleted here template class shared_ptr ^ In file included from ./boost_thread.cpp:1: In file included from /usr/include/boost/thread/thread.hpp:22: /usr/include/boost/thread/detail/thread.hpp:395:13: error: call to deleted constructor of 'detail::thread_data_ptr' (aka 'shared_ptr') thread_data(thread_data_) ^ ~~~~~~~~~~~~ /usr/include/boost/smart_ptr/shared_ptr.hpp:464:36: note: function has been explicitly marked deleted here template friend class shared_ptr; ^ /usr/include/boost/smart_ptr/shared_ptr.hpp:301:9: error: functional-style cast from 'const boost::shared_ptr' to 'this_type' (aka 'shared_ptr') uses deleted function this_type(r).swap(*this); ^~~~~~~~~~~ /usr/include/boost/thread/detail/thread.hpp:181:24: note: in instantiation of member function 'boost::shared_ptr::operator=' requested here thread_info=other.thread_info; ^ /usr/include/boost/smart_ptr/shared_ptr.hpp:464:36: note: candidate constructor (the implicit copy constructor) has been explicitly deleted template friend class shared_ptr; ^ /usr/include/boost/smart_ptr/shared_ptr.hpp:227:5: note: candidate constructor [with Y = boost::detail::thread_data_base] shared_ptr( shared_ptr const & r, typename boost::detail::sp_enable_if_convertible::type = boost::detail::sp_empty() ) ^ 3 errors generated. I'm not sure if this could be a boost / clang / libc++ bug. Any comment will be greatly appreciated. Thanks, Ryuta -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110717/94f30fc7/attachment-0001.html From jonathan.sauer at gmx.de Sun Jul 17 09:48:16 2011 From: jonathan.sauer at gmx.de (Jonathan Sauer) Date: Sun, 17 Jul 2011 16:48:16 +0200 Subject: [cfe-dev] Compiling boost with -std=c++0x (and -stdlib=libc++) In-Reply-To: References: Message-ID: Hello, > #include > > int main() > { > return 0; > } > > Actually, clang and libc++ work perfectly fine: > > [ryuta at oroppas]$ clang++ -stdlib=libc++ ./boost_thread.cpp > > However, once we deploy -std=c++0x flag, > > [ryuta at oroppas]$ clang++ -std=c++0x -stdlib=libc++ ./boost_thread.cpp > In file included from ./boost_thread.cpp:1: > In file included from /usr/include/boost/thread/thread.hpp:17: > /usr/include/boost/thread/pthread/thread_data.hpp:36:17: error: call to deleted constructor of 'boost::shared_ptr' > func(func_),value(value_) > ^ ~~~~~ > /usr/include/boost/smart_ptr/shared_ptr.hpp:164:25: note: function has been explicitly marked deleted here > template class shared_ptr This has to do with FDIS 12.8p18 (implicitely generated copy constructors are marked as deleted if the class provides a move constructor). After adding this constructor to boost::shared_ptr, the code compiles: shared_ptr( shared_ptr const & r ) : px( r.px ), pn( r.pn ) // never throws { } Out-of-the-box, Boost 1.46.1's shared_ptr does not provide a copy constructor such as the one above; indeed, on line 210 of boost/smart_ptr/shared_ptr.hpp, there is the comment stating: // generated copy constructor, destructor are fine Boost's shared_ptr only provides the following: template shared_ptr( shared_ptr const & r ) : px( r.px ), pn( r.pn ) // never throws { } >From my reading of 12.8, this is not considered to be a copy constructor, as according to p2, only *non-template* constructors can be copy constructors. So clang tries to generate an implicit one, but that one already has been deleted by the move constructor shared_ptr provides. This is not fixed in Boost's current trunk, so I guess you should file a bug with Boost. Jonathan From howarth at bromo.med.uc.edu Sun Jul 17 11:04:24 2011 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sun, 17 Jul 2011 12:04:24 -0400 Subject: [cfe-dev] return statements without expressions in non-void functions revisited Message-ID: <20110717160424.GA24162@bromo.med.uc.edu> FYI, the texlive developers recommend the following change to solve the strictness of clang on this issue... --- texlive.orig/texk/ps2pkm/type1.c 2011-07-17 10:56:13.000000000 -0400 +++ texlive/texk/ps2pkm/type1.c 2011-07-17 10:57:31.000000000 -0400 @@ -127,6 +127,8 @@ #define Error {errflag = TRUE; return;} #define Error0(errmsg) { CC; IfTrace0(TRUE, errmsg); Error;} + +#define Error01(errmsg) { CC; IfTrace0(TRUE, errmsg); errflag = TRUE; return -1.0;} #define Error1(errmsg,arg) { CC; IfTrace1(TRUE, errmsg, arg); Error;} @@ -780,7 +782,7 @@ static DOUBLE PSFakePop () { if (PSFakeTop >= 0) return(PSFakeStack[PSFakeTop--]); - else Error0("PSFakePop : Stack empty\n"); + else Error01("PSFakePop : Stack empty\n"); /*NOTREACHED*/ } With that change, texlive from 20100720 compiles fine against clang3.0svn. Jack ps It still would be nice to have the option of -std=c89 converting the non-void function should return a value error into a warning. From ahaas at impactweather.com Sun Jul 17 08:10:56 2011 From: ahaas at impactweather.com (Art Haas) Date: Sun, 17 Jul 2011 13:10:56 +0000 Subject: [cfe-dev] [PATCH] Fix CMake build on Solaris Message-ID: Hi. The patch below fixes a problem when buildin LLVM/Clang on Solaris. The generated makefiles would have an extraneous semi-colon character in them prior to this change due to the way the 'CMAKE_CXX_FLAGS' variable was defined. Simply adjusting the definition by moving the current CMAKE_CXX_FLAGS value within the quotes solves the problem. Art Haas Index: CMakeLists.txt =================================================================== --- CMakeLists.txt (revision 135345) +++ CMakeLists.txt (working copy) @@ -181,7 +181,7 @@ include_directories( ${LLVM_BINARY_DIR}/include ${LLVM_MAIN_INCLUDE_DIR}) if( ${CMAKE_SYSTEM_NAME} MATCHES SunOS ) - SET(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} "-include llvm/Support/Solaris.h") + SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -include llvm/Support/Solaris.h") endif( ${CMAKE_SYSTEM_NAME} MATCHES SunOS ) include(AddLLVM) From ofv at wanadoo.es Sun Jul 17 12:36:45 2011 From: ofv at wanadoo.es (=?utf-8?Q?=C3=93scar_Fuentes?=) Date: Sun, 17 Jul 2011 19:36:45 +0200 Subject: [cfe-dev] [PATCH] Fix CMake build on Solaris References: Message-ID: <87vcv0kdw2.fsf@wanadoo.es> Art Haas writes: > The patch below fixes a problem when buildin LLVM/Clang on Solaris. [snip] Applied in r135361. Thanks! From craig.topper at gmail.com Sun Jul 17 22:47:40 2011 From: craig.topper at gmail.com (Craig Topper) Date: Sun, 17 Jul 2011 20:47:40 -0700 Subject: [cfe-dev] [PATCH] C++0x unicode string and character literals now with test cases Message-ID: Hello, Attached is a new patch that fixes a few bugs in the patch I posted last week. It also converts the multiple bool flags I was using into an enum. I've updated existing char literal and string literal tests and a few others to cover the new types. Hopefully someone can review. Thanks, ~Craig Topper -------------- next part -------------- A non-text attachment was scrubbed... Name: unicode_strings.patch Type: application/octet-stream Size: 77210 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110717/5cd77410/attachment-0001.obj From ryuuta at gmail.com Mon Jul 18 00:19:04 2011 From: ryuuta at gmail.com (Ryuta Suzuki) Date: Mon, 18 Jul 2011 14:19:04 +0900 Subject: [cfe-dev] Compiling boost with -std=c++0x (and -stdlib=libc++) In-Reply-To: References: Message-ID: Hi Jonathan, Thanks for the fix and info. I'll file a bug report to the boost developers. Ryuta On Sun, Jul 17, 2011 at 11:48 PM, Jonathan Sauer wrote: > Hello, > > > #include > > > > int main() > > { > > return 0; > > } > > > > Actually, clang and libc++ work perfectly fine: > > > > [ryuta at oroppas]$ clang++ -stdlib=libc++ ./boost_thread.cpp > > > > However, once we deploy -std=c++0x flag, > > > > [ryuta at oroppas]$ clang++ -std=c++0x -stdlib=libc++ ./boost_thread.cpp > > In file included from ./boost_thread.cpp:1: > > In file included from /usr/include/boost/thread/thread.hpp:17: > > /usr/include/boost/thread/pthread/thread_data.hpp:36:17: error: call to > deleted constructor of > 'boost::shared_ptr' > > func(func_),value(value_) > > ^ ~~~~~ > > /usr/include/boost/smart_ptr/shared_ptr.hpp:164:25: note: function has > been explicitly marked deleted here > > template class shared_ptr > > This has to do with FDIS 12.8p18 (implicitely generated copy constructors > are marked as deleted if the class > provides a move constructor). After adding this constructor to > boost::shared_ptr, the code compiles: > > shared_ptr( shared_ptr const & r ) > : px( r.px ), pn( r.pn ) // never throws > { > } > > Out-of-the-box, Boost 1.46.1's shared_ptr does not provide a copy > constructor such as the one above; indeed, > on line 210 of boost/smart_ptr/shared_ptr.hpp, there is the comment > stating: > > // generated copy constructor, destructor are fine > > Boost's shared_ptr only provides the following: > > template > shared_ptr( shared_ptr const & r ) > : px( r.px ), pn( r.pn ) // never throws > { > } > > >From my reading of 12.8, this is not considered to be a copy constructor, > as according to p2, only *non-template* > constructors can be copy constructors. So clang tries to generate an > implicit one, but that one already has been > deleted by the move constructor shared_ptr provides. > > This is not fixed in Boost's current trunk, so I guess you should file a > bug with Boost. > > > Jonathan > > > _______________________________________________ > 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/20110718/edc89d2a/attachment.html From lvoufo at cs.indiana.edu Mon Jul 18 09:14:31 2011 From: lvoufo at cs.indiana.edu (Larisse Voufo) Date: Mon, 18 Jul 2011 10:14:31 -0400 Subject: [cfe-dev] Compiling latest clang... Message-ID: In trying to compile the latest version of clang with the latest version of llvm, I have been getting the compilation error below. It seems it is not a new issue (see http://permalink.gmane.org/gmane.comp.compilers.llvm.bugs/13921). However, I can't tell if it's been resolved or not. I am working from a Mac OS X 10.6.8. Could somebody please tell me the latest version of clang that is guaranteed to be working with a latest of llvm? Thanks, -- Larisse. --------------------------------------------------------------------------------------- Assertion failed: (Arg), function run, file ClangAttrEmitter.cpp, line 479. 0 tblgen 0x000000010018ba4c PrintStackTrace(void*) + 38 1 tblgen 0x000000010018c007 SignalHandler(int) + 254 2 libSystem.B.dylib 0x00007fff8674d1ba _sigtramp + 26 3 libSystem.B.dylib 0x0000000000000010 _sigtramp + 2039164528 4 tblgen 0x0000000100006e47 raise + 27 5 tblgen 0x0000000100006e57 abort + 14 6 tblgen 0x0000000100006ee4 __gnu_cxx::new_allocator::new_allocator() + 0 7 tblgen 0x0000000100051e32 llvm::ClangAttrClassEmitter::run(llvm::raw_ostream&) + 736 8 tblgen 0x00000001001567d5 main + 1927 9 tblgen 0x00000001000080fc start + 52 Stack dump: 0. Program arguments: /Users/annlarysm/llvm/Debug+Asserts/bin/tblgen -I /Users/annlarysm/llvm/tools/clang/include/clang/AST -I /Users/annlarysm/llvm/include -I /Users/annlarysm/llvm/include -I /Users/annlarysm/llvm/lib/Target -gen-clang-attr-classes -o /Users/annlarysm/llvm/tools/clang/include/clang/AST/Debug+Asserts/Attrs.inc.tmp -I /Users/annlarysm/llvm/tools/clang/include/clang/AST/../../ /Users/annlarysm/llvm/tools/clang/include/clang/AST/../Basic/Attr.td make[5]: *** [/Users/annlarysm/llvm/tools/clang/include/clang/AST/Debug+Asserts/Attrs.inc.tmp] Illegal instruction make[4]: *** [all] Error 1 make[3]: *** [all] Error 1 make[2]: *** [all] Error 1 make[1]: *** [clang/.makeall] Error 2 make[1]: *** Waiting for unfinished jobs.... llvm[2]: ======= Finished Linking Debug+Asserts Executable bugpoint make: *** [all] Error 1 --------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110718/263f69ff/attachment.html From jonathan.sauer at gmx.de Mon Jul 18 10:00:06 2011 From: jonathan.sauer at gmx.de (Jonathan Sauer) Date: Mon, 18 Jul 2011 17:00:06 +0200 Subject: [cfe-dev] Compiling latest clang... In-Reply-To: References: Message-ID: Hello, > In trying to compile the latest version of clang with the latest version of llvm, I have been getting the compilation error below. > It seems it is not a new issue (see http://permalink.gmane.org/gmane.comp.compilers.llvm.bugs/13921). However, I can't tell if it's been resolved or not. According to , it seems to be somewhat in limbo. > I am working from a Mac OS X 10.6.8. > > Could somebody please tell me the latest version of clang that is guaranteed to be working with a latest of llvm? This morning, I got clang+LLVM r135379 from subversion and compiled (and used) it successfully using Mac OS X 10.6.7 and Apple's GCC 4.2.1 build 5666 (part of XCode 3.2.6). I did: $ make update $ make clean $ make Did you try cleaning the build directory? I once had problems linking after somehow stale object files were left around. Hope that helps, Jonathan From tydeman at tybor.com Mon Jul 18 10:20:34 2011 From: tydeman at tybor.com (Fred J. Tydeman) Date: Mon, 18 Jul 2011 08:20:34 -0700 (PDT) Subject: [cfe-dev] New user: Linux: undefined reference to fetestexcept In-Reply-To: <4E225B4E.1010003@oblong.com> References: <020.b84c0a00e125214e.004@tybor.com> <4E225B4E.1010003@oblong.com> Message-ID: <020.b0060800424f244e.001@tybor.com> On Sat, 16 Jul 2011 20:47:26 -0700 Patrick Pelletier wrote: > >>Are there headers or libraries that I need to tell >>the compiler about? >> >You probably need "-lm". Not a clang-specific thing, though; >you'd need that for gcc, too. You are correct. Thanks. When I see -lm, I think math library, which to me is just . But, it is probably also and , and maybe others. --- Fred J. Tydeman Tydeman Consulting tydeman at tybor.com Testing, numerics, programming +1 (775) 358-9748 Vice-chair of PL22.11 (ANSI "C") Sample C99+FPCE tests: http://www.tybor.com Savers sleep well, investors eat well, spenders work forever. From felix.schmitt at zih.tu-dresden.de Mon Jul 18 04:37:42 2011 From: felix.schmitt at zih.tu-dresden.de (Felix Schmitt) Date: Mon, 18 Jul 2011 09:37:42 +0000 (UTC) Subject: [cfe-dev] =?utf-8?q?clang_parsing=3A_find_cuda_specific_statement?= =?utf-8?b?cyAoX19zeW5jdGhyZWFkcygpKQ==?= Message-ID: Hi, I wondered how to find CUDA specific statements (such as __syncthreads) in a parsed kernel file. This should be possible as the ptx-backend seems to support those. However, I couldn't get it by traversing the AST (not listed there). I am using the clang API for parsing and transforming the code. Any hints would be very helpful. Thanks, Felix From gwk.lists at gmail.com Mon Jul 18 11:18:21 2011 From: gwk.lists at gmail.com (George King) Date: Mon, 18 Jul 2011 12:18:21 -0400 Subject: [cfe-dev] ARC and refcount semantics attributes Message-ID: Hi list, I just discovered these attributes on a page about the static analyzer: __attribute((ns_return_retained)) __attribute((ns_consumed)) I am curious whether the current implementation of ARC respects these attributes, or if there are plans to support them. It seems important that it would for cases where autorelease pools are not practical. Thanks! George From clattner at apple.com Mon Jul 18 11:23:36 2011 From: clattner at apple.com (Chris Lattner) Date: Mon, 18 Jul 2011 09:23:36 -0700 Subject: [cfe-dev] ARC and refcount semantics attributes In-Reply-To: References: Message-ID: On Jul 18, 2011, at 9:18 AM, George King wrote: > Hi list, I just discovered these attributes on a page about the static analyzer: > > __attribute((ns_return_retained)) > __attribute((ns_consumed)) > > I am curious whether the current implementation of ARC respects these attributes, or if there are plans to support them. Yep, they are. More information about ARC is here: http://clang.llvm.org/docs/AutomaticReferenceCounting.html > It seems important that it would for cases where autorelease pools are not practical. What do you mean? -Chris From csdavec at swan.ac.uk Mon Jul 18 12:09:21 2011 From: csdavec at swan.ac.uk (David Chisnall) Date: Mon, 18 Jul 2011 18:09:21 +0100 Subject: [cfe-dev] ARC and refcount semantics attributes In-Reply-To: References: Message-ID: <4061600B-488B-4718-AC11-2BA21D4415EC@swan.ac.uk> On 18 Jul 2011, at 17:18, George King wrote: > Hi list, I just discovered these attributes on a page about the static analyzer: > > __attribute((ns_return_retained)) > __attribute((ns_consumed)) Incorrect spelling aside, this is easy for you to check: $ cat arc.m id unretained(void); __attribute((ns_returns_retained)) id retained(void) { return unretained(); } void consume(__attribute((ns_consumed)) id y){} $ clang -fobjc-nonfragile-abi -fobjc-arc -S -emit-llvm arc.m The resulting file is arc.s. Snipping some irrelevant details, we're left with: define i8* @retained() { %1 = call i8* @unretained() %2 = call i8* @objc_retainAutoreleasedReturnValue(i8* %1) nounwind ret i8* %2 } As you can see, the function with the ns_returns_retained attribute that returns the result of a call to a function without this attribute (which, implicitly, returns an autoreleased object) retains the value. objc_retainAutoreleasedReturnValue() is a special case of -retain that is faster if the object has just been autoreleased with objc_autoreleaseReturnValue(). Now what about the other function: define void @consume(i8* %y) nounwind { %1 = alloca i8*, align 4 store i8* %y, i8** %1, align 4 %2 = load i8** %1 call void @objc_release(i8* %2) nounwind, !clang.imprecise_release !0 ret void } As you can see, this function implicitly releases the argument by calling objc_release() on it. > I am curious whether the current implementation of ARC respects these attributes, or if there are plans to support them. It seems important that it would for cases where autorelease pools are not practical. I'm not sure what you mean by 'where autorelease pools are not practical'. ARC requires autorelease pools to work... David -- Sent from my Apple II From lvoufo at cs.indiana.edu Mon Jul 18 12:29:53 2011 From: lvoufo at cs.indiana.edu (Larisse Voufo) Date: Mon, 18 Jul 2011 13:29:53 -0400 Subject: [cfe-dev] Compiling latest clang... In-Reply-To: References: Message-ID: So... 'make update' did help the installation from SVN. However, it does not help the installation from the Git mirrors: git://repo.or.cz/llvm.git git://repo.or.cz/clang.git On Mon, Jul 18, 2011 at 11:00 AM, Jonathan Sauer wrote: > Hello, > > > In trying to compile the latest version of clang with the latest version > of llvm, I have been getting the compilation error below. > > It seems it is not a new issue (see > http://permalink.gmane.org/gmane.comp.compilers.llvm.bugs/13921). However, > I can't tell if it's been resolved or not. > > According to , it seems to be > somewhat in limbo. > > > I am working from a Mac OS X 10.6.8. > > > > Could somebody please tell me the latest version of clang that is > guaranteed to be working with a latest of llvm? > > This morning, I got clang+LLVM r135379 from subversion and compiled (and > used) it successfully using Mac OS X 10.6.7 > and Apple's GCC 4.2.1 build 5666 (part of XCode 3.2.6). I did: > > $ make update > $ make clean > $ make > > Did you try cleaning the build directory? I once had problems linking after > somehow stale object files were left > around. > > > Hope that helps, > Jonathan > > > _______________________________________________ > 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/20110718/0ca43b98/attachment.html From echristo at apple.com Mon Jul 18 13:34:54 2011 From: echristo at apple.com (Eric Christopher) Date: Mon, 18 Jul 2011 11:34:54 -0700 Subject: [cfe-dev] [PATCH] C++0x unicode string and character literals now with test cases In-Reply-To: References: Message-ID: On Jul 17, 2011, at 8:47 PM, Craig Topper wrote: > Hello, > > Attached is a new patch that fixes a few bugs in the patch I posted > last week. It also converts the multiple bool flags I was using into > an enum. I've updated existing char literal and string literal tests > and a few others to cover the new types. > > Hopefully someone can review. I took a quick look at it and it looks pretty good. You'll want to watch long (> 80 character) lines. Someone more familiar with the code will have to approve it though. Thanks! -eric From craig.topper at gmail.com Mon Jul 18 13:50:10 2011 From: craig.topper at gmail.com (Craig Topper) Date: Mon, 18 Jul 2011 11:50:10 -0700 Subject: [cfe-dev] [PATCH] C++0x unicode string and character literals now with test cases In-Reply-To: References: Message-ID: Thanks for the review! I'll fix the line lengths tonight. Do you know who is more familiar with the code? Thanks, ~Craig On Mon, Jul 18, 2011 at 11:34 AM, Eric Christopher wrote: > > On Jul 17, 2011, at 8:47 PM, Craig Topper wrote: > >> Hello, >> >> Attached is a new patch that fixes a few bugs in the patch I posted >> last week. It also converts the multiple bool flags I was using into >> an enum. I've updated existing char literal and string literal tests >> and a few others to cover the new types. >> >> Hopefully someone can review. > > I took a quick look at it and it looks pretty good. You'll want to watch > long (> 80 character) lines. Someone more familiar with the code will > have to approve it though. > > Thanks! > > -eric > -- ~Craig From popizdeh at gmail.com Mon Jul 18 14:32:10 2011 From: popizdeh at gmail.com (Nikola Smiljanic) Date: Mon, 18 Jul 2011 21:32:10 +0200 Subject: [cfe-dev] Any hints on how to solve crash 10131? Message-ID: I'm investigating crash 10131 and I managed to reduce the test case to this: #include class StringRef { public: StringRef(std::string const& s) : length(s.size() {} size_t length; }; Here is what I have so far. The execution reaches this far (see abbreviated call stack) and then returns to Parser::ParseCXXMemberSpecification. At the end of this method ParsingDef.Pop() is called and it clears the SmallVector holding tokens (I think it's the CachedTokens member inside LexedMethod), execution returns to first ParseDeclarationOrFunctionDefinition where ConsumeToken is called. This ends up inside TokenLexer::Lex that tries accessing Tokens member pointing to now deleted tokens. I don't really understand the code in order to fix it but I'm not ready to surrender yet. Any hints? TokenLexer::Lex Preprocessor::Lex Parser::ConsumeToken Parser::SkipUntil Parser::SkipUntil Parser::MatchRHSPunctuation Parser::ParseMemInitializer Parser::ParseConstructorInitializer Parser::ParseLexedMethodDef Parser::LexedMethod::ParseLexedMethodDefs Parser::ParseLexedMethodDefs Parser::ParseCXXMemberSpecification Parser::ParseClassSpecifier Parser::ParseDeclarationSpecifiers Parser::ParseDeclarationOrFunctionDefinition Parser::ParseDeclarationOrFunctionDefinition Parser::ParseExternalDeclaration Parser::ParseTopLevelDecl ParseAST -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110718/1f976a28/attachment.html From supertri at google.com Mon Jul 18 14:48:39 2011 From: supertri at google.com (Caitlin Sadowski) Date: Mon, 18 Jul 2011 12:48:39 -0700 Subject: [cfe-dev] Proposal for thread safety attributes for Clang In-Reply-To: References: <63C66C00-8996-4CC2-855A-76CA19678D1A@apple.com> Message-ID: Chris, Any additional thoughts/questions? Cheers, Caitlin On Thu, Jul 14, 2011 at 3:09 PM, Caitlin Sadowski wrote: > Chris, > >> Are these in mainline GCC or just a branch? ?If they are in mainline GCC and >> have shipped in a release, then taking them into Clang makes sense for >> compatibility reasons. ?If they are a research project that is in >> development, then the bar to getting it into mainline clang is much higher, >> because adding attributes is tantamount to a language extension. > > These annotations are in between the two extremes listed above. They > have gone beyond the initial research project stage, as they have > multiple years of use in production code. > > They are currently not in mainline GCC (they are in a full-fledged > development branch). However, the only reasons for not including the > annotations in mainline GCC are the result of implementation concerns: > the GCC implementation involves invasive changes throughout the GCC > parser and depends on specific details of the lowering to GIMPLE. The > general consensus seems to be that the annotation system should be in > mainline GCC, after changing how they are implemented (unless Clang > gets there first). > >> I'm specifically concerned on a number of fronts here: >> 1. Are these annotations general enough to apply to many common lock-based >> APIs? > > The annotations themselves are general enough (the paper I cited > earlier actually contains an entire sound type-system based on a > subset of these annotations). Within the implementation, there are > tricky cases (like aliasing of lock objects) that lead to difficulties > in the application. However, our core synchronization libraries have > been successfully annotated, and it looks like less than 15% of > annotated code is impacted by these limitations. > >> 2. How do the annotations handle aliasing of lock objects? > > Right now they do not handle this. However, we would like eventually > support this feature. > >> 3. How many bugs have been found in practice? > > In a (relatively small) subsection of code at Google that has thread > safety annotations, I looked at one month of commit activity and found > 18 bug-fixing commits (not including commits which just fix the > annotations) that cited these annotations explicitly as the way the > bug was found. > > Also, the thread safety annotations are useful beyond just bug fixing. > At Google, the web search frontend team refused to write multithreaded > code until these thread-safety warnings were made available (through > that GCC branch) due to the number of bugs and difficulty of tracking > them down. > >> 4. Have you considered doing this as a static analysis (where the bar is >> much lower to get things into mainline) instead of as a language change? > > The attribute system and the most fundamental analyses are things we > would like to see in the main compiler (after years of experience > successfully using these annotations in GCC). Plus, having this > starting point checked in will make it easier to build off and improve > the analysis. We are planning to have future analyses that build off > of these foundations start in the static analzyer. > > Cheers, > > Caitlin > From echristo at apple.com Mon Jul 18 15:16:12 2011 From: echristo at apple.com (Eric Christopher) Date: Mon, 18 Jul 2011 13:16:12 -0700 Subject: [cfe-dev] [PATCH] C++0x unicode string and character literals now with test cases In-Reply-To: References: Message-ID: On Jul 18, 2011, at 11:50 AM, Craig Topper wrote: > Thanks for the review! I'll fix the line lengths tonight. Do you know > who is more familiar with the code? Chris or Doug would be the two people most likely to approve it. Had a couple of thoughts that I figured I'd ask about: a) the enum for character and string is almost identical, any reason not to make them identical b) any reason not to have the string literal creation machinery just default to ascii and not need the changes in most of the use cases? -eric From geek4civic at gmail.com Mon Jul 18 18:07:16 2011 From: geek4civic at gmail.com (NAKAMURA Takumi) Date: Tue, 19 Jul 2011 08:07:16 +0900 Subject: [cfe-dev] x64 windows (MinGW) and "__declspec(dllimport)" emits a "unknown attribute warning" In-Reply-To: References: Message-ID: Ruben, It must be a bug even if __attribute__((dllexport)) is not accepted on x86_64-mingw32. > This small piece of code: > >> int main() {} >> __declspec(dllexport) void foo (int); void bar (void) { foo (0); } > > emits following warning when Clang is built for x86_64-w64-mingw32, > but not when built for i686-w64-mingw32: Interesting. Note, __declspec(dllexport) can be accepted (w/o macro substitution) with -fms-extensions. (FYI, IIRC, cygming-gcc does not accept __declspec. cygming header should have the macro def) ...Takumi From eli.friedman at gmail.com Mon Jul 18 18:22:29 2011 From: eli.friedman at gmail.com (Eli Friedman) Date: Mon, 18 Jul 2011 16:22:29 -0700 Subject: [cfe-dev] x64 windows (MinGW) and "__declspec(dllimport)" emits a "unknown attribute warning" In-Reply-To: References: Message-ID: On Fri, Jul 15, 2011 at 1:59 PM, Ruben Van Boxem wrote: > Hi, > > This small piece of code: > >> int main() {} >> __declspec(dllexport) void foo (int); void bar (void) { foo (0); } > > emits following warning when Clang is built for x86_64-w64-mingw32, > but not when built for i686-w64-mingw32: > >> foo.c:3:12: warning: unknown attribute 'dllexport' ignored [-Wattributes] >> __declspec(dllexport) void foo (int); void bar (void) { foo (0); } >> ?????????? ^ >> :128:38: note: expanded from: >> #define __declspec(a) __attribute__((a)) >> ???????????????????????????????????? ^ >> 1 warning generated. > > Note that this code has an undefined reference, that's not the point. > > I tried looking through Clang's code where this warning is emitted, > but can't find anything relevant. The code differentiating x86 and x64 > (or most likely just "forgetting" x64 mingw) is probably deeper in the > code. > > Any help is appreciated. Try lib/Sema/TargetAttributesSema.cpp. -Eli From craig.topper at gmail.com Mon Jul 18 21:13:50 2011 From: craig.topper at gmail.com (Craig Topper) Date: Mon, 18 Jul 2011 19:13:50 -0700 Subject: [cfe-dev] [PATCH] C++0x unicode string and character literals now with test cases In-Reply-To: References: Message-ID: On Mon, Jul 18, 2011 at 1:16 PM, Eric Christopher wrote: > > On Jul 18, 2011, at 11:50 AM, Craig Topper wrote: > >> Thanks for the review! I'll fix the line lengths tonight. Do you know >> who is more familiar with the code? > > Chris or Doug would be the two people most likely to approve it. > > Had a couple of thoughts that I figured I'd ask about: > > a) the enum for character and string is almost identical, any reason > not to make them identical I mainly didn't make them identical cause I put them inside the CharacterLiteral and StringLiteral classes. Wasn't sure were an appropriate home would be if they were shared. > > b) any reason not to have the string literal creation machinery just > default to ascii and not need the changes in most of the use cases? I don't follow. > > -eric > -- ~Craig From geek4civic at gmail.com Mon Jul 18 22:16:55 2011 From: geek4civic at gmail.com (NAKAMURA Takumi) Date: Tue, 19 Jul 2011 12:16:55 +0900 Subject: [cfe-dev] x64 windows (MinGW) and "__declspec(dllimport)" emits a "unknown attribute warning" In-Reply-To: References: Message-ID: Eli, > Try lib/Sema/TargetAttributesSema.cpp. The last modification to the stuff was I. :D Ruben, What is defined to LLVM_HOSTTRIPLE in your (builddir)/include/llvm/Config/*config.h? I am afraid Triple cannot parse "x86_64-w64-mingw32" correctly... ...Takumi From craig.topper at gmail.com Tue Jul 19 02:08:40 2011 From: craig.topper at gmail.com (Craig Topper) Date: Tue, 19 Jul 2011 00:08:40 -0700 Subject: [cfe-dev] [PATCH] C++0x unicode string and character literals now with test cases In-Reply-To: References: Message-ID: Here's a new patch that fixes the line lengths. Also widens to the token kind in the Identifier table because 8-bits wasn't enough anymore so kw_unknown_anytype was being truncated from 256 to 0. On Mon, Jul 18, 2011 at 7:13 PM, Craig Topper wrote: > On Mon, Jul 18, 2011 at 1:16 PM, Eric Christopher wrote: >> >> On Jul 18, 2011, at 11:50 AM, Craig Topper wrote: >> >>> Thanks for the review! I'll fix the line lengths tonight. Do you know >>> who is more familiar with the code? >> >> Chris or Doug would be the two people most likely to approve it. >> >> Had a couple of thoughts that I figured I'd ask about: >> >> a) the enum for character and string is almost identical, any reason >> not to make them identical > > I mainly didn't make them identical cause I put them inside the > CharacterLiteral and StringLiteral classes. Wasn't sure were an > appropriate home would be if they were shared. > >> >> b) any reason not to have the string literal creation machinery just >> default to ascii and not need the changes in most of the use cases? > > I don't follow. > >> >> -eric >> > > > > -- > ~Craig > -- ~Craig -------------- next part -------------- A non-text attachment was scrubbed... Name: unicode_strings.patch Type: application/octet-stream Size: 78943 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110719/82214bcb/attachment-0001.obj From scshunt at csclub.uwaterloo.ca Tue Jul 19 02:17:48 2011 From: scshunt at csclub.uwaterloo.ca (Sean Hunt) Date: Tue, 19 Jul 2011 00:17:48 -0700 Subject: [cfe-dev] [PATCH] C++0x unicode string and character literals now with test cases In-Reply-To: References: Message-ID: <4E252F9C.9070702@csclub.uwaterloo.ca> On 11-07-19 12:08 AM, Craig Topper wrote: > Here's a new patch that fixes the line lengths. Also widens to the > token kind in the Identifier table because 8-bits wasn't enough > anymore so kw_unknown_anytype was being truncated from 256 to 0. IsIdentifierStringPrefix should be language-sensitive. Other than that, nothing more stands out to me. Sean From vanboxem.ruben at gmail.com Tue Jul 19 07:52:59 2011 From: vanboxem.ruben at gmail.com (Ruben Van Boxem) Date: Tue, 19 Jul 2011 14:52:59 +0200 Subject: [cfe-dev] x64 windows (MinGW) and "__declspec(dllimport)" emits a "unknown attribute warning" In-Reply-To: References: Message-ID: 2011/7/19 NAKAMURA Takumi : > Eli, > >> Try lib/Sema/TargetAttributesSema.cpp. > > The last modification to the stuff was I. :D > > Ruben, > > What is defined to LLVM_HOSTTRIPLE in your > (builddir)/include/llvm/Config/*config.h? > I am afraid Triple cannot parse "x86_64-w64-mingw32" correctly... Both in config.h and llvm-config.h it is defined as "x86_64-w64-mingw32". I also had a brief look at LLVM/lib/Support/Triple.cpp and can't find anything that stands out (except for the fact that the *-w64-* vs *-pc-* isn't handled, but as far as I know, that's only used by GCC itself to differentiate certain low-level aspects like library/crt/header locations when it builds itself, nothing Clang needs to worry about yet). Ruben From lvoufo at cs.indiana.edu Tue Jul 19 09:26:30 2011 From: lvoufo at cs.indiana.edu (Larisse Voufo) Date: Tue, 19 Jul 2011 10:26:30 -0400 Subject: [cfe-dev] Compiling latest clang... In-Reply-To: References: Message-ID: Any one familiar with the trouble from the git mirrors? My project depends on those being synchronized properly... :-/ How are they actually managed if I may ask? Thanks a bunch! -- Larisse. On Mon, Jul 18, 2011 at 1:29 PM, Larisse Voufo wrote: > So... 'make update' did help the installation from SVN. However, it does > not help the installation from the Git mirrors: > git://repo.or.cz/llvm.git > git://repo.or.cz/clang.git > > > On Mon, Jul 18, 2011 at 11:00 AM, Jonathan Sauer wrote: > >> Hello, >> >> > In trying to compile the latest version of clang with the latest version >> of llvm, I have been getting the compilation error below. >> > It seems it is not a new issue (see >> http://permalink.gmane.org/gmane.comp.compilers.llvm.bugs/13921). >> However, I can't tell if it's been resolved or not. >> >> According to , it seems to be >> somewhat in limbo. >> >> > I am working from a Mac OS X 10.6.8. >> > >> > Could somebody please tell me the latest version of clang that is >> guaranteed to be working with a latest of llvm? >> >> This morning, I got clang+LLVM r135379 from subversion and compiled (and >> used) it successfully using Mac OS X 10.6.7 >> and Apple's GCC 4.2.1 build 5666 (part of XCode 3.2.6). I did: >> >> $ make update >> $ make clean >> $ make >> >> Did you try cleaning the build directory? I once had problems linking >> after somehow stale object files were left >> around. >> >> >> Hope that helps, >> Jonathan >> >> >> _______________________________________________ >> 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/20110719/1ba8c562/attachment.html From howarth at bromo.med.uc.edu Tue Jul 19 09:57:45 2011 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Tue, 19 Jul 2011 10:57:45 -0400 Subject: [cfe-dev] default arguments cannot be added to an out-of-line definition of a member of a class template Message-ID: <20110719145745.GA8284@bromo.med.uc.edu> While trying to compile ccp4 with clang, I ran into the following error in the test case... ------------- outofline.cpp -------------------- template class covar_matrix { public: void SetZeroRows(int,int,int,int,int,int); // specifies the order numbers of rows(=columns) for which the covariances should be 0. private: }; // defines zero rows. If the first argument is negative, resets all no non-zero. template void covar_matrix::SetZeroRows( int r1=-1, int r2=-1, int r3=-1, int r4=-1, int r5=-1, int r6=-1 ) { int r[6] = {r1,r2,r3,r4,r5,r6}; int i=0; } ------------------------------------------------ [MacPro:~] howarth% clang -c outofline.cpp outofline.cpp:16:46: error: default arguments cannot be added to an out-of-line definition of a member of a class template void covar_matrix::SetZeroRows( int r1=-1, int r2=-1, int r3=-1, int r4=-1, int r5=-1, int r6=-1 ) ^ ~~ outofline.cpp:16:57: error: default arguments cannot be added to an out-of-line definition of a member of a class template void covar_matrix::SetZeroRows( int r1=-1, int r2=-1, int r3=-1, int r4=-1, int r5=-1, int r6=-1 ) ^ ~~ outofline.cpp:16:68: error: default arguments cannot be added to an out-of-line definition of a member of a class template void covar_matrix::SetZeroRows( int r1=-1, int r2=-1, int r3=-1, int r4=-1, int r5=-1, int r6=-1 ) ^ ~~ outofline.cpp:16:79: error: default arguments cannot be added to an out-of-line definition of a member of a class template void covar_matrix::SetZeroRows( int r1=-1, int r2=-1, int r3=-1, int r4=-1, int r5=-1, int r6=-1 ) ^ ~~ outofline.cpp:16:90: error: default arguments cannot be added to an out-of-line definition of a member of a class template void covar_matrix::SetZeroRows( int r1=-1, int r2=-1, int r3=-1, int r4=-1, int r5=-1, int r6=-1 ) ^ ~~ outofline.cpp:16:101: error: default arguments cannot be added to an out-of-line definition of a member of a class template void covar_matrix::SetZeroRows( int r1=-1, int r2=-1, int r3=-1, int r4=-1, int r5=-1, int r6=-1 ) ^ ~~ 6 errors generated. I assume this isn't a bug in clang. If so, what is the proper solution? Is it this change? --------------- outofline2.cpp --------------- template class covar_matrix { public: void SetZeroRows(int,int,int,int,int,int); // specifies the order numbers of rows(=columns) for which the covariances should be 0. private: }; // defines zero rows. If the first argument is negative, resets all no non-zero. template void covar_matrix::SetZeroRows( int r1, int r2, int r3, int r4, int r5, int r6 ) { int r[6] = {r1,r2,r3,r4,r5,r6}; int i=0; r1=-1; r2=-1; r3=-1; r4=-1; r5=-1; r6=-1; } ---------------------------------------------- This compiles without complaint in clang. Thanks in advance for any clarifications. Jack From jonathan.sauer at gmx.de Tue Jul 19 10:33:24 2011 From: jonathan.sauer at gmx.de (Jonathan Sauer) Date: Tue, 19 Jul 2011 17:33:24 +0200 Subject: [cfe-dev] default arguments cannot be added to an out-of-line definition of a member of a class template In-Reply-To: <20110719145745.GA8284@bromo.med.uc.edu> References: <20110719145745.GA8284@bromo.med.uc.edu> Message-ID: <300760AD-312C-43FF-A67D-93D8E5B8B6CC@gmx.de> Hello, > While trying to compile ccp4 with clang, I ran into the following error in the test case... > > ------------- outofline.cpp -------------------- > template > class covar_matrix > { > public: > > void SetZeroRows(int,int,int,int,int,int); // specifies the order numbers of rows(=columns) for which the covariances should be 0. > > private: > > }; > > > > // defines zero rows. If the first argument is negative, resets all no non-zero. > template > void covar_matrix::SetZeroRows( int r1=-1, int r2=-1, int r3=-1, int r4=-1, int r5=-1, int r6=-1 ) > { > int r[6] = {r1,r2,r3,r4,r5,r6}; > int i=0; > } > > ------------------------------------------------ > > [MacPro:~] howarth% clang -c outofline.cpp > outofline.cpp:16:46: error: default arguments cannot be added to an out-of-line definition of a member of a class template > void covar_matrix::SetZeroRows( int r1=-1, int r2=-1, int r3=-1, int r4=-1, int r5=-1, int r6=-1 ) > [...] > > I assume this isn't a bug in clang. If so, what is the proper solution? Is it this change? It is not a clang bug, at least not from my reading of the standard (FDIS 8.3.6p4: Adding default arguments later on is only valid with *non-template* functions. Here we have a function template, since SetZeroRows is part of a class template). The solution is to add the default parameters (the "-1" in your example) to the declaration of the function and to remove them from its definition. This compiles with the current clang: template class covar_matrix { public: void SetZeroRows(int = -1,int = -1,int = -1,int = -1,int = -1,int = -1); // specifies the order numbers of rows(=columns) for which the covariances should be 0. private: }; // defines zero rows. If the first argument is negative, resets all no non-zero. template void covar_matrix::SetZeroRows( int r1, int r2, int r3, int r4, int r5, int r6 ) { int r[6] = {r1,r2,r3,r4,r5,r6}; int i=0; } > // defines zero rows. If the first argument is negative, resets all no non-zero. > template > void covar_matrix::SetZeroRows( int r1, int r2, int r3, int r4, int r5, int r6 ) > { > int r[6] = {r1,r2,r3,r4,r5,r6}; > int i=0; > r1=-1; > r2=-1; > r3=-1; > r4=-1; > r5=-1; > r6=-1; > } This most likely does not what you want: It does not specify default parameters, but sets r0-6 to -1 after using them to initialize r. In my opinion, this is a bug in ccp4. You should file a bug report there (with the above solution). Hope that helps, Jonathan From gwk.lists at gmail.com Tue Jul 19 11:26:12 2011 From: gwk.lists at gmail.com (George King) Date: Tue, 19 Jul 2011 12:26:12 -0400 Subject: [cfe-dev] ARC and refcount semantics attributes In-Reply-To: <4061600B-488B-4718-AC11-2BA21D4415EC@swan.ac.uk> References: <4061600B-488B-4718-AC11-2BA21D4415EC@swan.ac.uk> Message-ID: <7E7A4120-26BC-4022-B728-78763A6188DF@gmail.com> > Incorrect spelling aside, this is easy for you to check: My mistake - typing code questions on a phone is error-prone! > I'm not sure what you mean by 'where autorelease pools are not practical'. ARC requires autorelease pools to work... In fact I had missed a documentation detail. I am passing objects between threads using performSelector:onThread:withObject:waitUntilDone: and did not see that the argument is retained until after the target thread performs the selector. I was concerned that the caller's run loop pool would drain before the target thread got the message. Sorry for the noise, and thanks for the detailed explanation - it was very informative! From echristo at apple.com Tue Jul 19 11:29:42 2011 From: echristo at apple.com (Eric Christopher) Date: Tue, 19 Jul 2011 09:29:42 -0700 Subject: [cfe-dev] Compiling latest clang... In-Reply-To: References: Message-ID: On Jul 19, 2011, at 7:26 AM, Larisse Voufo wrote: > Any one familiar with the trouble from the git mirrors? My project depends on those being synchronized properly... :-/ How are they actually managed if I may ask? What trouble from the git mirrors? As far as synchronization between clang and llvm - they should almost always be synchronized. They are in different repositories so a commit that needs to happen concurrently to both repositories will happen in sequence, but that should be a matter of minutes at most. There are very few commits like this. -eric From saurav.muralidharan at gmail.com Tue Jul 19 12:29:22 2011 From: saurav.muralidharan at gmail.com (Saurav Muralidharan) Date: Tue, 19 Jul 2011 11:29:22 -0600 Subject: [cfe-dev] Using TreeTransform for AST Transformations Message-ID: Hi, I am working on a project which involves reading in a C source file, doing some analysis (mainly on loops), reordering the code and then generating transformed C code at the end. I have been using Clang to do the analysis part and thus far it has worked out well (I'm following the usual path of deriving from ASTConsumer). For the transform part, however, I am not clear on how to proceed. After reading up on the threads related to source-to-source transforms and about AST transformations, it seems I have two options: (1) Use the Rewriter or (2) Modify the AST itself and then pretty-print it. I would like to do the latter and from what I've seen, using Sema's TreeTransform class seems to be the most elegant solution. I have been playing around with the code and trying to use TreeTransform in some useful way, but I would be glad if somebody briefly explained how it is supposed to be used with the ASTConsumer that I already have (for example, how do I replace a loop node in the AST with a new, transformed loop node such that it doesn't break any semantics?). I'm relatively new to Clang and any help would be greatly appreciated. Cheers, Saurav From devlists at shadowlab.org Tue Jul 19 13:46:53 2011 From: devlists at shadowlab.org (Jean-Daniel Dupas) Date: Tue, 19 Jul 2011 20:46:53 +0200 Subject: [cfe-dev] ARC and @synthesize of read only property Message-ID: <370D5D91-4737-4AB3-B111-6D16E92CFE88@shadowlab.org> When I'm trying to synthesize a read only property in obj-c, I get the following error. error: ARC forbids synthesizing a property of an Objective-C object with unspecified storage attribute [4] I understand why it is necessary to specify storage attribute to generate a setter, but why is it relevant to generate a getter ? Just in case, here is a simple test case: @interface Foo { id _ivar; } @property(nonatomic, readonly) id ivar; @end @implementation Foo @synthesize ivar = _ivar; @end Trying to compile this code using -fobjc-arc fails. -- Jean-Daniel From csdavec at swan.ac.uk Tue Jul 19 14:50:36 2011 From: csdavec at swan.ac.uk (David Chisnall) Date: Tue, 19 Jul 2011 20:50:36 +0100 Subject: [cfe-dev] ARC and @synthesize of read only property In-Reply-To: <370D5D91-4737-4AB3-B111-6D16E92CFE88@shadowlab.org> References: <370D5D91-4737-4AB3-B111-6D16E92CFE88@shadowlab.org> Message-ID: <3DA507E0-A124-4FEF-AE8C-A74F78E845E0@swan.ac.uk> On 19 Jul 2011, at 19:46, Jean-Daniel Dupas wrote: > When I'm trying to synthesize a read only property in obj-c, I get the following error. > > error: ARC forbids synthesizing a property of an Objective-C object with unspecified storage attribute [4] > > I understand why it is necessary to specify storage attribute to generate a setter, but why is it relevant to generate a getter ? The getter semantics also change: - If the property is retained, then it will retain / autorelease the object, to ensure that it is not deallocated prematurely. - If the property is weak, then it must use the weak read barrier function - If the property is unsafe_unretained, then the getter will just return it directly. Even in ARC mode, the compiler can't magically guess what you mean. David From devlists at shadowlab.org Tue Jul 19 15:06:37 2011 From: devlists at shadowlab.org (Jean-Daniel Dupas) Date: Tue, 19 Jul 2011 22:06:37 +0200 Subject: [cfe-dev] ARC and @synthesize of read only property In-Reply-To: <3DA507E0-A124-4FEF-AE8C-A74F78E845E0@swan.ac.uk> References: <370D5D91-4737-4AB3-B111-6D16E92CFE88@shadowlab.org> <3DA507E0-A124-4FEF-AE8C-A74F78E845E0@swan.ac.uk> Message-ID: <9A22BF15-B888-4E3C-94ED-A8F58117FE99@shadowlab.org> Le 19 juil. 2011 ? 21:50, David Chisnall a ?crit : > On 19 Jul 2011, at 19:46, Jean-Daniel Dupas wrote: > >> When I'm trying to synthesize a read only property in obj-c, I get the following error. >> >> error: ARC forbids synthesizing a property of an Objective-C object with unspecified storage attribute [4] >> >> I understand why it is necessary to specify storage attribute to generate a setter, but why is it relevant to generate a getter ? > > The getter semantics also change: > > - If the property is retained, then it will retain / autorelease the object, to ensure that it is not deallocated prematurely. > > - If the property is weak, then it must use the weak read barrier function > > - If the property is unsafe_unretained, then the getter will just return it directly. > Thank you for the explanation. So the retained/autorelease is a new behavior introduced with ARC. AFAIK, the getter did this only for atomic properties in non ARC mode. > Even in ARC mode, the compiler can't magically guess what you mean. While it cannot always guess, when the @synthezise directive specify an ivar, it can default to the ivar ownership, as this is the only acceptable value. -- Jean-Daniel From retval386 at gmail.com Tue Jul 19 18:44:59 2011 From: retval386 at gmail.com (ret val) Date: Tue, 19 Jul 2011 19:44:59 -0400 Subject: [cfe-dev] determining Decl's source Message-ID: I am using RecursiveASTVistor and implementing the VisitDecl() method. While trying to collect all the Decs for function calls and function pointers, I also collect those from standard libraries. I would like to skip these and only look at Decs from the input files. I am wondering what a good way to go about this is. Decl::hasBody() looks interested, but wouldnt account for inline functions. Could this be fixed? Some one in IRC mentioned using SourceManager to check the file it is in it looks like I would have todo something like Decl::getLocation() dyn_cast to a FullSourceLoc and use FullSourceLoc::getFileID() SourceManager::getFileEntryForID() FileEntry::getName() But I'm having problems with the dyn_cast, my nonfunctional one looks like this and I'm not sure how to correct it. FullSourceLoc &loc = dyn_cast(D->getLocation()); Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110719/eda5f0d9/attachment.html From Pidgeot18 at verizon.net Tue Jul 19 18:54:27 2011 From: Pidgeot18 at verizon.net (Joshua Cranmer) Date: Tue, 19 Jul 2011 16:54:27 -0700 Subject: [cfe-dev] determining Decl's source In-Reply-To: References: Message-ID: <4E261933.7070704@verizon.net> On 7/19/2011 4:44 PM, ret val wrote: > I am using RecursiveASTVistor and implementing the VisitDecl() > method. While trying to collect all the Decs for function calls and > function pointers, I also collect those from standard libraries. I > would like to skip these and only look at Decs from the input files. The way I've been doing this is the following: bool interestingLocation(SourceLocation loc) { // If we don't have a valid location... it's probably not interesting. if (loc.isInvalid()) return false; // I'm not sure this is the best, since it's affected by #line and #file // et al. On the other hand, if I just do spelling, I get really wrong // values for locations in macros, especially when ## is involved. std::string filename = sm.getPresumedLoc(loc).getFilename(); // Invalid locations and built-ins: not interesting at all if (filename[0] == '<') return false; return /* filename is in a directory I want */ } (I actually end up having a full hashtable of the returned filenames to the absolute path filename, since filenames are a lot more important to me than just skipping the "is this interesting") -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth From csilvers at google.com Tue Jul 19 19:03:48 2011 From: csilvers at google.com (Craig Silverstein) Date: Tue, 19 Jul 2011 17:03:48 -0700 Subject: [cfe-dev] determining Decl's source In-Reply-To: (ret val's message of "Tue\, 19 Jul 2011 19\:44\:59 -0400") References: Message-ID: } Some one in IRC mentioned using SourceManager to check the file it } is in it Yes, that's the right approach. } looks like I would have todo something like } Decl::getLocation() } dyn_cast to a FullSourceLoc and use FullSourceLoc::getFileID() } SourceManager::getFileEntryForID() } FileEntry::getName() You don't want to dyn_cast. You want to create a FullSourceLocation using a SourceLocation and a SourceManager. Look at http://code.google.com/p/include-what-you-use/source/browse/trunk/iwyu_location_util.h to see how we do this in include-what-you-use. craig From lvoufo at cs.indiana.edu Tue Jul 19 20:15:15 2011 From: lvoufo at cs.indiana.edu (Larisse Voufo) Date: Tue, 19 Jul 2011 21:15:15 -0400 Subject: [cfe-dev] Compiling latest clang... In-Reply-To: References: Message-ID: It looks like I was pulling implementations from conflicting mirrors: git://repo.or.cz/llvm.git and http://llvm.org/git/clang.git (Strange that it's worked well so far.) I am resetting things properly, and I'll let you know how it goes. Thanks, -- Larisse. On Tue, Jul 19, 2011 at 12:29 PM, Eric Christopher wrote: > > On Jul 19, 2011, at 7:26 AM, Larisse Voufo wrote: > > > Any one familiar with the trouble from the git mirrors? My project > depends on those being synchronized properly... :-/ How are they actually > managed if I may ask? > > What trouble from the git mirrors? > > As far as synchronization between clang and llvm - they should almost > always be synchronized. They are in different repositories so a commit that > needs to happen concurrently to both repositories will happen in sequence, > but that should be a matter of minutes at most. There are very few commits > like this. > > -eric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110719/51a231a1/attachment-0001.html From clattner at apple.com Tue Jul 19 21:04:17 2011 From: clattner at apple.com (Chris Lattner) Date: Tue, 19 Jul 2011 19:04:17 -0700 Subject: [cfe-dev] ARC and @synthesize of read only property In-Reply-To: <370D5D91-4737-4AB3-B111-6D16E92CFE88@shadowlab.org> References: <370D5D91-4737-4AB3-B111-6D16E92CFE88@shadowlab.org> Message-ID: <8E101FD7-8BFE-46F4-BE63-0C2FD6E8C7C9@apple.com> On Jul 19, 2011, at 11:46 AM, Jean-Daniel Dupas wrote: > When I'm trying to synthesize a read only property in obj-c, I get the following error. > > error: ARC forbids synthesizing a property of an Objective-C object with unspecified storage attribute [4] > > I understand why it is necessary to specify storage attribute to generate a setter, but why is it relevant to generate a getter ? > > > Just in case, here is a simple test case: > > @interface Foo { id _ivar; } > @property(nonatomic, readonly) id ivar; The simple answer is that this code defaulted to being an "assign" property before, and that dangerous because it quickly leads to a dangling pointer. ARC forces you to make a choice: strong, weak, unsafe_unretain, etc. -Chris From retval386 at gmail.com Tue Jul 19 21:05:42 2011 From: retval386 at gmail.com (ret val) Date: Tue, 19 Jul 2011 22:05:42 -0400 Subject: [cfe-dev] determine scope in a RecursiveASTVistor Message-ID: While Looking at function pointer declarations with a RecursiveASTVistor I'm trying to keep track of their scope. My original plan was to delimit scope based on Entering/Leaving a CompoundStmt since it looks like its a nice logical grouping, but I noticed in the Doxygen docs nothing inherits this class. I was expecting functions and loops to inherit this. So now I'm wondering what a good way to go about this is, hopefully still using a RecursiveASTVistor. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110719/087f1492/attachment.html From tydeman at tybor.com Wed Jul 20 00:27:02 2011 From: tydeman at tybor.com (Fred J. Tydeman) Date: Tue, 19 Jul 2011 22:27:02 -0700 (PDT) Subject: [cfe-dev] Intel: x87 vs sse Message-ID: <020.802604002667264e.002@tybor.com> For C programs, is there a way to tell the compiler what kind of floating-point unit (FPU) to generate code for? I am thinking of Intel CPUs with x87 versus sse. This is for Linux. --- Fred J. Tydeman Tydeman Consulting tydeman at tybor.com Testing, numerics, programming +1 (775) 358-9748 Vice-chair of PL22.11 (ANSI "C") Sample C99+FPCE tests: http://www.tybor.com Savers sleep well, investors eat well, spenders work forever. From craig.topper at gmail.com Wed Jul 20 02:27:25 2011 From: craig.topper at gmail.com (Craig Topper) Date: Wed, 20 Jul 2011 00:27:25 -0700 Subject: [cfe-dev] [PATCH] C++0x unicode string and character literals now with test cases In-Reply-To: References: Message-ID: Reverted TokenConcatenation::IsIdentifierL and added a new method specifically for detecting identifiers of "u8", "u", or "U". This new method is qualified with CPlusPlus0x check so that we won't avoid the concat when Unicode string literals aren't supported. Used a separate method just to make it cleaner than scattering C++0x checks throughout the method. On Tue, Jul 19, 2011 at 12:08 AM, Craig Topper wrote: > Here's a new patch that fixes the line lengths. Also widens to the > token kind in the Identifier table because 8-bits wasn't enough > anymore so kw_unknown_anytype was being truncated from 256 to 0. > > On Mon, Jul 18, 2011 at 7:13 PM, Craig Topper wrote: >> On Mon, Jul 18, 2011 at 1:16 PM, Eric Christopher wrote: >>> >>> On Jul 18, 2011, at 11:50 AM, Craig Topper wrote: >>> >>>> Thanks for the review! I'll fix the line lengths tonight. Do you know >>>> who is more familiar with the code? >>> >>> Chris or Doug would be the two people most likely to approve it. >>> >>> Had a couple of thoughts that I figured I'd ask about: >>> >>> a) the enum for character and string is almost identical, any reason >>> not to make them identical >> >> I mainly didn't make them identical cause I put them inside the >> CharacterLiteral and StringLiteral classes. Wasn't sure were an >> appropriate home would be if they were shared. >> >>> >>> b) any reason not to have the string literal creation machinery just >>> default to ascii and not need the changes in most of the use cases? >> >> I don't follow. >> >>> >>> -eric >>> >> >> >> >> -- >> ~Craig >> > > > > -- > ~Craig > -- ~Craig -------------- next part -------------- A non-text attachment was scrubbed... Name: unicode_strings.patch Type: application/octet-stream Size: 79324 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110720/29878d3b/attachment-0001.obj From eli.friedman at gmail.com Wed Jul 20 02:37:27 2011 From: eli.friedman at gmail.com (Eli Friedman) Date: Wed, 20 Jul 2011 00:37:27 -0700 Subject: [cfe-dev] Intel: x87 vs sse In-Reply-To: <020.802604002667264e.002@tybor.com> References: <020.802604002667264e.002@tybor.com> Message-ID: On Tue, Jul 19, 2011 at 10:27 PM, Fred J. Tydeman wrote: > For C programs, is there a way to tell the compiler what > kind of floating-point unit (FPU) to generate code for? > I am thinking of Intel CPUs with x87 versus sse. > This is for Linux. clang doesn't support an explicit flag; it will use SSE/SSE2 where available, and x87 otherwise. Note that clang will always use x87 for arithmetic on anything using the type "long double". -Eli From listrp at gmail.com Wed Jul 20 03:45:29 2011 From: listrp at gmail.com (Robert Purves) Date: Wed, 20 Jul 2011 20:45:29 +1200 Subject: [cfe-dev] Intel: x87 vs sse In-Reply-To: References: Message-ID: <1D7A847D-0B4F-4D21-A168-DCB562657B2A@gmail.com> Eli Friedman wrote: >> Fred J. Tydeman wrote: >> For C programs, is there a way to tell the compiler what kind of floating-point unit (FPU) to generate code for? >> I am thinking of Intel CPUs with x87 versus sse. > clang doesn't support an explicit flag; it will use SSE/SSE2 where available, and x87 otherwise. You can force x87 with -mno-sse. Robert P. From csdavec at swan.ac.uk Wed Jul 20 03:57:11 2011 From: csdavec at swan.ac.uk (David Chisnall) Date: Wed, 20 Jul 2011 09:57:11 +0100 Subject: [cfe-dev] ARC and @synthesize of read only property In-Reply-To: <9A22BF15-B888-4E3C-94ED-A8F58117FE99@shadowlab.org> References: <370D5D91-4737-4AB3-B111-6D16E92CFE88@shadowlab.org> <3DA507E0-A124-4FEF-AE8C-A74F78E845E0@swan.ac.uk> <9A22BF15-B888-4E3C-94ED-A8F58117FE99@shadowlab.org> Message-ID: On 19 Jul 2011, at 21:06, Jean-Daniel Dupas wrote: > Thank you for the explanation. So the retained/autorelease is a new behavior introduced with ARC. AFAIK, the getter did this only for atomic properties in non ARC mode. You can check the generated IR. In ARC mode, it calls objc_getProperty() for atomic properties. For nonatomic properties, it accesses the ivar directly and calls objc_retainAutoreleaseReturnValue(). If you do something like: id o = [object synthesizedNonatomicProperty]; Then ARC will translate this into something like: o = objc_retainAutoreleasedReturnValue([object synthesizedNonatomicProperty]); This skips the autorelease pool, so the object is now retained in the caller but not present in the autorelease pool. ARC will then objc_release() it at the end of the scope of o. This means that you get a lot less redundant autorelease pool churn in ARC mode. >> Even in ARC mode, the compiler can't magically guess what you mean. > > While it cannot always guess, when the @synthezise directive specify an ivar, it can default to the ivar ownership, as this is the only acceptable value. Ivars all default to __strong, but it sounds like you actually want unsafe_unretained (which would then simply be objc_retain()'d in the caller in ARC mode). David From peter at 2ndquadrant.com Wed Jul 20 04:41:34 2011 From: peter at 2ndquadrant.com (Peter Geoghegan) Date: Wed, 20 Jul 2011 10:41:34 +0100 Subject: [cfe-dev] -Warray-bounds seems over-zealous on Clang In-Reply-To: References: <20110712150748.GA4913@britannica.bec.de> <0F9FF1EB-96F2-4ACB-8070-32EFD6B23CD4@apple.com> <372E1D9D-8435-427E-9122-94A81E046187@apple.com> <09911FA8-1679-4FDA-B363-5211C44A3DDE@apple.com> <6CB2BAE3-D4D3-4299-A526-916B51FBD9D0@gmail.com> <1FFBA94C-191A-466B-90B8-EABC654736BB@gmail.com> Message-ID: So, is there any chance of getting Nicola's patch committed in some form? -- Peter Geoghegan ? ? ? http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services From chandlerc at google.com Wed Jul 20 04:48:05 2011 From: chandlerc at google.com (Chandler Carruth) Date: Wed, 20 Jul 2011 02:48:05 -0700 Subject: [cfe-dev] -Warray-bounds seems over-zealous on Clang In-Reply-To: References: <20110712150748.GA4913@britannica.bec.de> <0F9FF1EB-96F2-4ACB-8070-32EFD6B23CD4@apple.com> <372E1D9D-8435-427E-9122-94A81E046187@apple.com> <09911FA8-1679-4FDA-B363-5211C44A3DDE@apple.com> <6CB2BAE3-D4D3-4299-A526-916B51FBD9D0@gmail.com> <1FFBA94C-191A-466B-90B8-EABC654736BB@gmail.com> Message-ID: On Wed, Jul 20, 2011 at 2:41 AM, Peter Geoghegan wrote: > So, is there any chance of getting Nicola's patch committed in some form? I'm planning to look at this tomorrow. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110720/4ea44473/attachment.html From anton at korobeynikov.info Wed Jul 20 04:51:49 2011 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Wed, 20 Jul 2011 13:51:49 +0400 Subject: [cfe-dev] Compiling latest clang... In-Reply-To: References: Message-ID: > git://repo.or.cz/llvm.git Given that we have git mirrors on llvm.org, repo.or.cz mirrors are not updated for a long time (~5 months already). It's pretty strange that you haven't noticed this :) -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From devlists at shadowlab.org Wed Jul 20 05:19:24 2011 From: devlists at shadowlab.org (Jean-Daniel Dupas) Date: Wed, 20 Jul 2011 12:19:24 +0200 Subject: [cfe-dev] ARC and @synthesize of read only property In-Reply-To: References: <370D5D91-4737-4AB3-B111-6D16E92CFE88@shadowlab.org> <3DA507E0-A124-4FEF-AE8C-A74F78E845E0@swan.ac.uk> <9A22BF15-B888-4E3C-94ED-A8F58117FE99@shadowlab.org> Message-ID: <1307209B-BF19-4261-99A8-B90AE2BDA7D3@shadowlab.org> Le 20 juil. 2011 ? 10:57, David Chisnall a ?crit : > On 19 Jul 2011, at 21:06, Jean-Daniel Dupas wrote: > >> Thank you for the explanation. So the retained/autorelease is a new behavior introduced with ARC. AFAIK, the getter did this only for atomic properties in non ARC mode. > > You can check the generated IR. In ARC mode, it calls objc_getProperty() for atomic properties. For nonatomic properties, it accesses the ivar directly and calls objc_retainAutoreleaseReturnValue(). If you do something like: > > id o = [object synthesizedNonatomicProperty]; > > Then ARC will translate this into something like: > > o = objc_retainAutoreleasedReturnValue([object synthesizedNonatomicProperty]); > > This skips the autorelease pool, so the object is now retained in the caller but not present in the autorelease pool. ARC will then objc_release() it at the end of the scope of o. This means that you get a lot less redundant autorelease pool churn in ARC mode. That make sense. Thanks again. > >>> Even in ARC mode, the compiler can't magically guess what you mean. >> >> While it cannot always guess, when the @synthezise directive specify an ivar, it can default to the ivar ownership, as this is the only acceptable value. > > Ivars all default to __strong, but it sounds like you actually want unsafe_unretained (which would then simply be objc_retain()'d in the caller in ARC mode). I really have and want a strong ivar. Declaring it as 'unsafe_unretained' will prevent its releasing in the generated object's destructor. So the solution in my case it to change the property declaration to tell the compiler it is a retained property. -- Jean-Daniel From peter at 2ndquadrant.com Wed Jul 20 05:42:02 2011 From: peter at 2ndquadrant.com (Peter Geoghegan) Date: Wed, 20 Jul 2011 11:42:02 +0100 Subject: [cfe-dev] -Warray-bounds seems over-zealous on Clang In-Reply-To: References: <20110712150748.GA4913@britannica.bec.de> <0F9FF1EB-96F2-4ACB-8070-32EFD6B23CD4@apple.com> <372E1D9D-8435-427E-9122-94A81E046187@apple.com> <09911FA8-1679-4FDA-B363-5211C44A3DDE@apple.com> <6CB2BAE3-D4D3-4299-A526-916B51FBD9D0@gmail.com> <1FFBA94C-191A-466B-90B8-EABC654736BB@gmail.com> Message-ID: On 20 July 2011 10:48, Chandler Carruth wrote: >> >> So, is there any chance of getting Nicola's patch committed in some form? > > I'm planning to look at this tomorrow. Thanks. I urge you to take a pragmatic view when considering when a warning should still be displayed. I really don't think you'll be doing affected developers any favours by showing a "consider flexible arrays" warning when C99 is used - in most cases, given the reality of how slow the adoption of C99 has been, you'll just be hectoring them rather than telling them something that they didn't know. I'd have a lot more sympathy for the view that such a warning should be seen if C99 wasn't Clang's default way of building C, but it is. The reality is that most C projects are using C89 with various very common extensions that made it into C99. I think that Clang should do what is most useful for the largest number of people, even if that comes at the expense of an ivory tower notion of correctness. I'm sorry if some people disliked how I expressed my views on this issue - I felt strongly that Clang should go a certain way, and so used correspondingly strong language. I really just want the best outcome for both Clang and PostgreSQL. -- Peter Geoghegan ? ? ? http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services From erik.verbruggen at me.com Wed Jul 20 08:47:51 2011 From: erik.verbruggen at me.com (Erik Verbruggen) Date: Wed, 20 Jul 2011 13:47:51 +0000 (GMT) Subject: [cfe-dev] Clang and MSVC headers Message-ID: <20b35c12-6777-43bf-c5d8-af4184f1ac4d@me.com> Hello, I was wondering what the status is for Clang w.r.t. parsing MSVC headers. I tried to use Clang's code completion today with MSVC, but the issue of name resolution in type-independant functions in templates popped up. So, is somebody working on this, or how far along is it? Regards, Erik. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110720/e7071824/attachment.html From pichet2000 at gmail.com Wed Jul 20 09:07:19 2011 From: pichet2000 at gmail.com (Francois Pichet) Date: Wed, 20 Jul 2011 10:07:19 -0400 Subject: [cfe-dev] Clang and MSVC headers In-Reply-To: <20b35c12-6777-43bf-c5d8-af4184f1ac4d@me.com> References: <20b35c12-6777-43bf-c5d8-af4184f1ac4d@me.com> Message-ID: On Wed, Jul 20, 2011 at 9:47 AM, Erik Verbruggen wrote: > Hello, > I was wondering what the status is for Clang w.r.t. parsing MSVC headers. I > tried to use Clang's code completion today with MSVC, but the issue of name > resolution in type-independant functions in templates popped up. So, is > somebody working on this, or how far along is it? > Regards, > Erik. hi, I suppose you mean "Unqualified lookup into dependent bases of class templates"? As in http://clang.llvm.org/compatibility.html#dep_lookup_bases. That issue is at the top of my todo list. I did some investigation but haven't started the coding really. Feel free to hijack that feature from me if you feel motivated. From erik.verbruggen at me.com Wed Jul 20 09:39:34 2011 From: erik.verbruggen at me.com (Erik Verbruggen) Date: Wed, 20 Jul 2011 14:39:34 +0000 (GMT) Subject: [cfe-dev] Clang and MSVC headers In-Reply-To: Message-ID: On 20 Jul, 2011,at 04:07 PM, Francois Pichet wrote: On Wed, Jul 20, 2011 at 9:47 AM, Erik Verbruggen wrote: > Hello, > I was wondering what the status is for Clang wr.t. parsing MSVC headers. I > tried to use Clang's code completion today with MSVC, but the issue of name > resolution in type-independant functions in templates popped up. So, is > somebody working on this, or how far along is it? > Regards, > Erik. hi, I suppose you mean "Unqualified lookup into dependent bases of class templates"? As in http://clang.llvm.org/compatibility.html#dep_lookup_bases. That issue is at the top of my todo list. I did some investigation but haven't started the coding really. Feel free to hijack that feature from me if you feel motivated. ? No, I mean the (probably well-known) error: C:\Program Files\Microsoft Visual Studio 9.0\VC\include/iosfwd(219) :?error: no member named '_invalid_parameter_noinfo' in the global namespace;?did you mean '_invalid_parameter_handler'? ? ? ? ? ? ? ? ? _SCL_SECURE_CRT_VALIDATE(_Dest_size >= _Count, NULL); ? ? ? ? ? ? ? ? ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ So where MSVC postpones name resolution for methods in templates classes until instantiation time. -- Erik. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110720/93ea4616/attachment.html From pichet2000 at gmail.com Wed Jul 20 09:48:16 2011 From: pichet2000 at gmail.com (Francois Pichet) Date: Wed, 20 Jul 2011 10:48:16 -0400 Subject: [cfe-dev] Clang and MSVC headers In-Reply-To: References: Message-ID: On Wed, Jul 20, 2011 at 10:39 AM, Erik Verbruggen wrote: > On 20 Jul, 2011,at 04:07 PM, Francois Pichet wrote: > > On Wed, Jul 20, 2011 at 9:47 AM, Erik Verbruggen > wrote: >> Hello, >> I was wondering what the status is for Clang w.r.t. parsing MSVC headers. >> I >> tried to use Clang's code completion today with MSVC, but the issue of >> name >> resolution in type-independant functions in templates popped up. So, is >> somebody working on this, or how far along is it? >> Regards, >> Erik. > > hi, > > I suppose you mean "Unqualified lookup into dependent bases of class > templates"? > As in http://clang.llvm.org/compatibility.html#dep_lookup_bases. > > That issue is at the top of my todo list. I did some investigation but > haven't started the coding really. > Feel free to hijack that feature from me if you feel motivated. > > > No, I mean the (probably well-known) error: > C:\Program Files\Microsoft Visual Studio 9.0\VC\include/iosfwd(219) :?error: > no member named '_invalid_parameter_noinfo' in the global namespace;?did you > mean '_invalid_parameter_handler'? > ? ? ? ? ? ? ? ? _SCL_SECURE_CRT_VALIDATE(_Dest_size >= _Count, NULL); > ? ? ? ? ? ? ? ? ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > So where MSVC postpones name resolution for methods in templates classes > until instantiation time. try -fdelayed-template-parsing to get around this problem. I think -fdelayed-template-parsing should be there by default if clang is built with MSVC. I'll see what I can do. Beside that, since you are using the MSVC 2008 headers, you might get 2-3 errors because of missing typename. (Depending on which files you include), Don't try MFC or ATL headers, we are not there yet. From jonathan.sauer at gmx.de Wed Jul 20 11:19:56 2011 From: jonathan.sauer at gmx.de (Jonathan Sauer) Date: Wed, 20 Jul 2011 18:19:56 +0200 Subject: [cfe-dev] Status of explicit conversion operators and nullptr Message-ID: <704D0EEF-CD4C-443B-B4FF-F7E72147F1CF@gmx.de> Hello, according to , explicit conversion operators are currently not really functional: | No name mangling; ASTs don't contain calls to conversion operators I just tried using them and to my delight they worked: Not only did the code compile (after I inserted the missing explicit casts), the resulting application ran without a hitch. To whomever implemented it: THANK YOU! :-) The code I used them in was: template class Fixed { ... // Convert to a float explicit inline operator float() const; // Convert to any integer template ::value, int>::type = 0> explicit inline operator U() const; }; I therefore think that the above status page should be updated at least to yellow ("many examples work"). The same goes for nullptr support: I have been using it successfully for weeks now (almost) without problems. Code generation most certainly isn't "broken". __has_feature(cxx_nullptr) also evaluates to "1". Are these assessments correct (and should I send a patch for the status page), or am I overlooking something? With many thanks in advance, Jonathan From fjahanian at apple.com Wed Jul 20 12:25:39 2011 From: fjahanian at apple.com (jahanian) Date: Wed, 20 Jul 2011 10:25:39 -0700 Subject: [cfe-dev] clang test failures In-Reply-To: <704D0EEF-CD4C-443B-B4FF-F7E72147F1CF@gmx.de> References: <704D0EEF-CD4C-443B-B4FF-F7E72147F1CF@gmx.de> Message-ID: Hi All, I am seeing three new failures today after I did an llvm update and built it for apple-darwin. Failing Tests (3): Clang :: CodeGenCXX/vtable-debug-info.cpp Clang :: CodeGenObjC/debug-info-getter-name.m Clang :: Driver/hello.c - Fariborz From dgregor at apple.com Wed Jul 20 12:51:28 2011 From: dgregor at apple.com (Douglas Gregor) Date: Wed, 20 Jul 2011 10:51:28 -0700 Subject: [cfe-dev] Status of explicit conversion operators and nullptr In-Reply-To: <704D0EEF-CD4C-443B-B4FF-F7E72147F1CF@gmx.de> References: <704D0EEF-CD4C-443B-B4FF-F7E72147F1CF@gmx.de> Message-ID: <5B3266BE-B178-4B70-89AA-3C1EB1423E3C@apple.com> On Jul 20, 2011, at 9:19 AM, Jonathan Sauer wrote: > Hello, > > according to , explicit conversion operators are currently > not really functional: > > | No name mangling; ASTs don't contain calls to conversion operators > > I just tried using them and to my delight they worked: Not only did the code compile (after I inserted > the missing explicit casts), the resulting application ran without a hitch. To whomever implemented it: > THANK YOU! :-) > > The code I used them in was: > > template > class Fixed { > ... > > // Convert to a float > explicit inline operator float() const; > > // Convert to any integer > template ::value, int>::type = 0> > explicit inline operator U() const; > }; > > > I therefore think that the above status page should be updated at least to yellow ("many examples > work"). > > The same goes for nullptr support: I have been using it successfully for weeks now (almost) without > problems. Code generation most certainly isn't "broken". __has_feature(cxx_nullptr) also evaluates > to "1". > > Are these assessments correct (and should I send a patch for the status page), or am I overlooking > something? I don't believe that explicit conversions are fully implemented. At the very least, we need an audit + test cases for all of the places where we look at implicit conversions, to ensure that we're properly enabling/disabling explicit conversion functions at the right times. nullptr is basically fully implemented. The only remaining issue I know of is that a thrown std::nullptr won't be caught as a T*, which is rather minor and might be more of a runtime issue . I'd appreciate it if you could send a patch for the status page! - Doug From jonathan_d_turner at apple.com Wed Jul 20 12:53:34 2011 From: jonathan_d_turner at apple.com (Jonathan Turner) Date: Wed, 20 Jul 2011 10:53:34 -0700 Subject: [cfe-dev] clang test failures In-Reply-To: References: <704D0EEF-CD4C-443B-B4FF-F7E72147F1CF@gmx.de> Message-ID: It looks like this might be related to compiling clang with gcc vs. with clang. Seems that if you compile the latest clang with gcc, the resulting compiler has problems. Jonathan On Jul 20, 2011, at 10:25 AM, jahanian wrote: > Hi All, > > I am seeing three new failures today after I did an llvm update and built it for apple-darwin. > > Failing Tests (3): > Clang :: CodeGenCXX/vtable-debug-info.cpp > Clang :: CodeGenObjC/debug-info-getter-name.m > Clang :: Driver/hello.c > > - Fariborz > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From benny.kra at googlemail.com Wed Jul 20 13:22:40 2011 From: benny.kra at googlemail.com (Benjamin Kramer) Date: Wed, 20 Jul 2011 11:22:40 -0700 Subject: [cfe-dev] clang test failures In-Reply-To: References: <704D0EEF-CD4C-443B-B4FF-F7E72147F1CF@gmx.de> Message-ID: On Wed, Jul 20, 2011 at 10:25, jahanian wrote: > Hi All, > > I am seeing three new failures today after I did an llvm update and built it for apple-darwin. > > Failing Tests (3): > ? ?Clang :: CodeGenCXX/vtable-debug-info.cpp > ? ?Clang :: CodeGenObjC/debug-info-getter-name.m > ? ?Clang :: Driver/hello.c Try again with r135594 :) - Ben From eli.friedman at gmail.com Wed Jul 20 13:24:57 2011 From: eli.friedman at gmail.com (Eli Friedman) Date: Wed, 20 Jul 2011 11:24:57 -0700 Subject: [cfe-dev] clang test failures In-Reply-To: References: <704D0EEF-CD4C-443B-B4FF-F7E72147F1CF@gmx.de> Message-ID: On Wed, Jul 20, 2011 at 10:25 AM, jahanian wrote: > Hi All, > > I am seeing three new failures today after I did an llvm update and built it for apple-darwin. > > Failing Tests (3): > ? ?Clang :: CodeGenCXX/vtable-debug-info.cpp > ? ?Clang :: CodeGenObjC/debug-info-getter-name.m > ? ?Clang :: Driver/hello.c Try updating to r135594 or later. -Eli From jonathan_d_turner at apple.com Wed Jul 20 13:33:33 2011 From: jonathan_d_turner at apple.com (Jonathan Turner) Date: Wed, 20 Jul 2011 11:33:33 -0700 Subject: [cfe-dev] clang test failures In-Reply-To: References: <704D0EEF-CD4C-443B-B4FF-F7E72147F1CF@gmx.de> Message-ID: <08FA4EDB-CF32-41BF-86AB-6727FC90F926@apple.com> Thanks! That fixes it for me. Jonathan On Jul 20, 2011, at 11:22 AM, Benjamin Kramer wrote: > On Wed, Jul 20, 2011 at 10:25, jahanian wrote: >> Hi All, >> >> I am seeing three new failures today after I did an llvm update and built it for apple-darwin. >> >> Failing Tests (3): >> Clang :: CodeGenCXX/vtable-debug-info.cpp >> Clang :: CodeGenObjC/debug-info-getter-name.m >> Clang :: Driver/hello.c > > Try again with r135594 :) > > - Ben > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From fjahanian at apple.com Wed Jul 20 13:34:17 2011 From: fjahanian at apple.com (jahanian) Date: Wed, 20 Jul 2011 11:34:17 -0700 Subject: [cfe-dev] clang test failures In-Reply-To: References: <704D0EEF-CD4C-443B-B4FF-F7E72147F1CF@gmx.de> Message-ID: Thanks to all who responded. TOT has since fixed the bug. - Fariborz On Jul 20, 2011, at 11:24 AM, Eli Friedman wrote: > On Wed, Jul 20, 2011 at 10:25 AM, jahanian wrote: >> Hi All, >> >> I am seeing three new failures today after I did an llvm update and built it for apple-darwin. >> >> Failing Tests (3): >> Clang :: CodeGenCXX/vtable-debug-info.cpp >> Clang :: CodeGenObjC/debug-info-getter-name.m >> Clang :: Driver/hello.c > > Try updating to r135594 or later. > > -Eli From wendling at apple.com Wed Jul 20 13:52:00 2011 From: wendling at apple.com (Bill Wendling) Date: Wed, 20 Jul 2011 11:52:00 -0700 Subject: [cfe-dev] Bogus Warnings Message-ID: <1CB4F1B8-5EE7-4FEE-9203-641DAC8F0AC5@apple.com> Since yesterday, I've been getting a lot of bogus warnings about uninitialized variables (see below). These are bogus because they're initialized via reference in another function. -bw /Volumes/Sandbox/llvm/llvm.src/lib/Target/ARM/AsmParser/ARMAsmParser.cpp:2106:29: warning: variable 'CarrySetting' is uninitialized when used here [-Wuninitialized] if (!CanAcceptCarrySet && CarrySetting) { ^~~~~~~~~~~~ /Volumes/Sandbox/llvm/llvm.src/lib/Target/ARM/AsmParser/ARMAsmParser.cpp:2085:3: note: variable 'CarrySetting' is declared here bool CarrySetting; ^ /Volumes/Sandbox/llvm/llvm.src/lib/Target/ARM/AsmParser/ARMAsmParser.cpp:2085:20: note: add initialization to silence this warning bool CarrySetting; ^ = false /Volumes/Sandbox/llvm/llvm.src/lib/Target/ARM/AsmParser/ARMAsmParser.cpp:2133:7: warning: variable 'ProcessorIMod' is uninitialized when used here [-Wuninitialized] if (ProcessorIMod) { ^~~~~~~~~~~~~ /Volumes/Sandbox/llvm/llvm.src/lib/Target/ARM/AsmParser/ARMAsmParser.cpp:2084:3: note: variable 'ProcessorIMod' is declared here unsigned ProcessorIMod; ^ /Volumes/Sandbox/llvm/llvm.src/lib/Target/ARM/AsmParser/ARMAsmParser.cpp:2084:25: note: add initialization to silence this warning unsigned ProcessorIMod; ^ = 0 /Volumes/Sandbox/llvm/llvm.src/lib/Target/ARM/AsmParser/ARMAsmParser.cpp:2122:7: warning: variable 'CanAcceptPredicationCode' is uninitialized when used here [-Wuninitialized] if (CanAcceptPredicationCode) { ^~~~~~~~~~~~~~~~~~~~~~~~ /Volumes/Sandbox/llvm/llvm.src/lib/Target/ARM/AsmParser/ARMAsmParser.cpp:2101:3: note: variable 'CanAcceptPredicationCode' is declared here bool CanAcceptCarrySet, CanAcceptPredicationCode; ^ /Volumes/Sandbox/llvm/llvm.src/lib/Target/ARM/AsmParser/ARMAsmParser.cpp:2101:51: note: add initialization to silence this warning bool CanAcceptCarrySet, CanAcceptPredicationCode; ^ = false From kremenek at apple.com Wed Jul 20 14:13:03 2011 From: kremenek at apple.com (Ted Kremenek) Date: Wed, 20 Jul 2011 12:13:03 -0700 Subject: [cfe-dev] Bogus Warnings In-Reply-To: <1CB4F1B8-5EE7-4FEE-9203-641DAC8F0AC5@apple.com> References: <1CB4F1B8-5EE7-4FEE-9203-641DAC8F0AC5@apple.com> Message-ID: This is due to changes in -Wuninitialized. I'm looking into it today. On Jul 20, 2011, at 11:52 AM, Bill Wendling wrote: > Since yesterday, I've been getting a lot of bogus warnings about uninitialized variables (see below). These are bogus because they're initialized via reference in another function. > > -bw > > /Volumes/Sandbox/llvm/llvm.src/lib/Target/ARM/AsmParser/ARMAsmParser.cpp:2106:29: warning: variable 'CarrySetting' is uninitialized when used here [-Wuninitialized] > if (!CanAcceptCarrySet && CarrySetting) { > ^~~~~~~~~~~~ > /Volumes/Sandbox/llvm/llvm.src/lib/Target/ARM/AsmParser/ARMAsmParser.cpp:2085:3: note: variable 'CarrySetting' is declared here > bool CarrySetting; > ^ > /Volumes/Sandbox/llvm/llvm.src/lib/Target/ARM/AsmParser/ARMAsmParser.cpp:2085:20: note: add initialization to silence this warning > bool CarrySetting; > ^ > = false > /Volumes/Sandbox/llvm/llvm.src/lib/Target/ARM/AsmParser/ARMAsmParser.cpp:2133:7: warning: variable 'ProcessorIMod' is uninitialized when used here [-Wuninitialized] > if (ProcessorIMod) { > ^~~~~~~~~~~~~ > /Volumes/Sandbox/llvm/llvm.src/lib/Target/ARM/AsmParser/ARMAsmParser.cpp:2084:3: note: variable 'ProcessorIMod' is declared here > unsigned ProcessorIMod; > ^ > /Volumes/Sandbox/llvm/llvm.src/lib/Target/ARM/AsmParser/ARMAsmParser.cpp:2084:25: note: add initialization to silence this warning > unsigned ProcessorIMod; > ^ > = 0 > /Volumes/Sandbox/llvm/llvm.src/lib/Target/ARM/AsmParser/ARMAsmParser.cpp:2122:7: warning: variable 'CanAcceptPredicationCode' is uninitialized when used here [-Wuninitialized] > if (CanAcceptPredicationCode) { > ^~~~~~~~~~~~~~~~~~~~~~~~ > /Volumes/Sandbox/llvm/llvm.src/lib/Target/ARM/AsmParser/ARMAsmParser.cpp:2101:3: note: variable 'CanAcceptPredicationCode' is declared here > bool CanAcceptCarrySet, CanAcceptPredicationCode; > ^ > /Volumes/Sandbox/llvm/llvm.src/lib/Target/ARM/AsmParser/ARMAsmParser.cpp:2101:51: note: add initialization to silence this warning > bool CanAcceptCarrySet, CanAcceptPredicationCode; > ^ > = false > > _______________________________________________ > 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 Jul 20 14:52:32 2011 From: kremenek at apple.com (Ted Kremenek) Date: Wed, 20 Jul 2011 12:52:32 -0700 Subject: [cfe-dev] Bogus Warnings In-Reply-To: <1CB4F1B8-5EE7-4FEE-9203-641DAC8F0AC5@apple.com> References: <1CB4F1B8-5EE7-4FEE-9203-641DAC8F0AC5@apple.com> Message-ID: <94EF1F0F-FCDF-4F2B-9A18-27F86749B688@apple.com> Now fixed in r135610. On Jul 20, 2011, at 11:52 AM, Bill Wendling wrote: > Since yesterday, I've been getting a lot of bogus warnings about uninitialized variables (see below). These are bogus because they're initialized via reference in another function. > > -bw > > /Volumes/Sandbox/llvm/llvm.src/lib/Target/ARM/AsmParser/ARMAsmParser.cpp:2106:29: warning: variable 'CarrySetting' is uninitialized when used here [-Wuninitialized] > if (!CanAcceptCarrySet && CarrySetting) { > ^~~~~~~~~~~~ > /Volumes/Sandbox/llvm/llvm.src/lib/Target/ARM/AsmParser/ARMAsmParser.cpp:2085:3: note: variable 'CarrySetting' is declared here > bool CarrySetting; > ^ > /Volumes/Sandbox/llvm/llvm.src/lib/Target/ARM/AsmParser/ARMAsmParser.cpp:2085:20: note: add initialization to silence this warning > bool CarrySetting; > ^ > = false > /Volumes/Sandbox/llvm/llvm.src/lib/Target/ARM/AsmParser/ARMAsmParser.cpp:2133:7: warning: variable 'ProcessorIMod' is uninitialized when used here [-Wuninitialized] > if (ProcessorIMod) { > ^~~~~~~~~~~~~ > /Volumes/Sandbox/llvm/llvm.src/lib/Target/ARM/AsmParser/ARMAsmParser.cpp:2084:3: note: variable 'ProcessorIMod' is declared here > unsigned ProcessorIMod; > ^ > /Volumes/Sandbox/llvm/llvm.src/lib/Target/ARM/AsmParser/ARMAsmParser.cpp:2084:25: note: add initialization to silence this warning > unsigned ProcessorIMod; > ^ > = 0 > /Volumes/Sandbox/llvm/llvm.src/lib/Target/ARM/AsmParser/ARMAsmParser.cpp:2122:7: warning: variable 'CanAcceptPredicationCode' is uninitialized when used here [-Wuninitialized] > if (CanAcceptPredicationCode) { > ^~~~~~~~~~~~~~~~~~~~~~~~ > /Volumes/Sandbox/llvm/llvm.src/lib/Target/ARM/AsmParser/ARMAsmParser.cpp:2101:3: note: variable 'CanAcceptPredicationCode' is declared here > bool CanAcceptCarrySet, CanAcceptPredicationCode; > ^ > /Volumes/Sandbox/llvm/llvm.src/lib/Target/ARM/AsmParser/ARMAsmParser.cpp:2101:51: note: add initialization to silence this warning > bool CanAcceptCarrySet, CanAcceptPredicationCode; > ^ > = false > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From wendling at apple.com Wed Jul 20 15:37:27 2011 From: wendling at apple.com (Bill Wendling) Date: Wed, 20 Jul 2011 13:37:27 -0700 Subject: [cfe-dev] Bogus Warnings In-Reply-To: <94EF1F0F-FCDF-4F2B-9A18-27F86749B688@apple.com> References: <1CB4F1B8-5EE7-4FEE-9203-641DAC8F0AC5@apple.com> <94EF1F0F-FCDF-4F2B-9A18-27F86749B688@apple.com> Message-ID: <34744F3F-ED18-47B8-AA16-9361C629EFCB@apple.com> Thanks! -bw On Jul 20, 2011, at 12:52 PM, Ted Kremenek wrote: > Now fixed in r135610. > > On Jul 20, 2011, at 11:52 AM, Bill Wendling wrote: > >> Since yesterday, I've been getting a lot of bogus warnings about uninitialized variables (see below). These are bogus because they're initialized via reference in another function. >> >> -bw >> >> /Volumes/Sandbox/llvm/llvm.src/lib/Target/ARM/AsmParser/ARMAsmParser.cpp:2106:29: warning: variable 'CarrySetting' is uninitialized when used here [-Wuninitialized] >> if (!CanAcceptCarrySet && CarrySetting) { >> ^~~~~~~~~~~~ >> /Volumes/Sandbox/llvm/llvm.src/lib/Target/ARM/AsmParser/ARMAsmParser.cpp:2085:3: note: variable 'CarrySetting' is declared here >> bool CarrySetting; >> ^ >> /Volumes/Sandbox/llvm/llvm.src/lib/Target/ARM/AsmParser/ARMAsmParser.cpp:2085:20: note: add initialization to silence this warning >> bool CarrySetting; >> ^ >> = false >> /Volumes/Sandbox/llvm/llvm.src/lib/Target/ARM/AsmParser/ARMAsmParser.cpp:2133:7: warning: variable 'ProcessorIMod' is uninitialized when used here [-Wuninitialized] >> if (ProcessorIMod) { >> ^~~~~~~~~~~~~ >> /Volumes/Sandbox/llvm/llvm.src/lib/Target/ARM/AsmParser/ARMAsmParser.cpp:2084:3: note: variable 'ProcessorIMod' is declared here >> unsigned ProcessorIMod; >> ^ >> /Volumes/Sandbox/llvm/llvm.src/lib/Target/ARM/AsmParser/ARMAsmParser.cpp:2084:25: note: add initialization to silence this warning >> unsigned ProcessorIMod; >> ^ >> = 0 >> /Volumes/Sandbox/llvm/llvm.src/lib/Target/ARM/AsmParser/ARMAsmParser.cpp:2122:7: warning: variable 'CanAcceptPredicationCode' is uninitialized when used here [-Wuninitialized] >> if (CanAcceptPredicationCode) { >> ^~~~~~~~~~~~~~~~~~~~~~~~ >> /Volumes/Sandbox/llvm/llvm.src/lib/Target/ARM/AsmParser/ARMAsmParser.cpp:2101:3: note: variable 'CanAcceptPredicationCode' is declared here >> bool CanAcceptCarrySet, CanAcceptPredicationCode; >> ^ >> /Volumes/Sandbox/llvm/llvm.src/lib/Target/ARM/AsmParser/ARMAsmParser.cpp:2101:51: note: add initialization to silence this warning >> bool CanAcceptCarrySet, CanAcceptPredicationCode; >> ^ >> = false >> >> _______________________________________________ >> cfe-dev mailing list >> cfe-dev at cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > From anton.yartsev at gmail.com Wed Jul 20 15:58:36 2011 From: anton.yartsev at gmail.com (Anton Yartsev) Date: Thu, 21 Jul 2011 00:58:36 +0400 Subject: [cfe-dev] aligned 'new' In-Reply-To: <4E1B698D.2070701@Gmail.com> References: <4DE313C8.6070303@Gmail.com> <2606C766-FBC5-462E-AD16-5FE67BC28549@apple.com> <4E03EBCB.8090905@Gmail.com> <4E1B698D.2070701@Gmail.com> Message-ID: <4E27417C.9010508@Gmail.com> On 12.07.2011 1:22, Anton Yartsev wrote: > On 24.06.2011 5:43, Anton Yartsev wrote: >> On 30.05.2011 8:35, Chris Lattner wrote: >>> On May 29, 2011, at 8:49 PM, Anton Yartsev wrote: >>> >>>> Hi all, >>>> >>>> I am thinking of the ability of operator new to return memory aligned >>>> according to the alignment of the type passed to it (at least of >>>> AltiVec >>>> vector types whose proper alignment is essential). >>>> The proposed implementation is: >>>> 1) clang: add -fstrict-aligned option. When the option is set it cause >>>> clang to define the built-in macro "__STRICT_ALIGNED" >>>> 2) libcxx: add additional placement new declarations to >>>> libcxx\include\new with the additional argument - alignment. Make this >>>> declarations conditionalized on the "__STRICT_ALIGNED". Add new >>>> definitions to libcxx\src\new.cpp. >>>> 3) clang: if -fstrict-aligned option is set, when clang sees a new >>>> of a >>>> type which either has an inherent alignment, or has an explicit >>>> alignment specified by __attribute__((__aligned__(x))), it will >>>> transform the standard new call to a call to the aligned version of >>>> new. >>>> >>>> Am i on the right way? Any thoughts? >>> I don't think that this is the right way to go. Instead, you'd want >>> "new foo" to automatically detect that the alignment of "foo" is >>> greater than the alignment guaranteed by the system malloc. In this >>> case, and if using the default operator new, you'd generate a call >>> to memalign instead of to operator new (something like that). >>> >>> It isn't clear to me how generally useful this is though, and we >>> tend to avoid adding tons of language extensions to Clang. >>> >>> -Chris >> Attached is the the patch that substitutes calls to default new >> operators with calls to functions - aligned analogs of default new >> operators. This functions may live in the clang's mm_malloc.h header >> where aligned malloc lives. The patch is partial, it does not affect >> deletes and do not contain substituting functions yet. Please review >> and direct! >> > Ping! > Hi, here is the updated patch that substitute both news and deletes, please review! -- Anton -------------- next part -------------- A non-text attachment was scrubbed... Name: aligned_new_part1.patch Type: text/x-diff Size: 11648 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110721/fa7d0ba4/attachment-0001.bin From retval386 at gmail.com Wed Jul 20 19:14:32 2011 From: retval386 at gmail.com (ret val) Date: Wed, 20 Jul 2011 20:14:32 -0400 Subject: [cfe-dev] mark variables and functions to later get their address? Message-ID: As a plugin I used the ASTConsumer and RecusiveASTVisitor class to find "interesting" variables and functions. Ultimately I want the address of these either in the object file or resulting elf. >From the IRC channel it sounds like this is currently impossible, if not Id love to hear how I could do this. Now I would like to know what exactly would need to be edited so while in the AST so I could "flag" these interesting things(metadata), so when the codegen routines runs I could add something(like a comment maybe). Can anyone give me a hand with how to begin? After browsing these files for awhile now I'm not even sure what the key functions would be. Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110720/093b2c3a/attachment.html From retval386 at gmail.com Wed Jul 20 21:17:52 2011 From: retval386 at gmail.com (ret val) Date: Wed, 20 Jul 2011 22:17:52 -0400 Subject: [cfe-dev] mark variables and functions to later get their address? In-Reply-To: References: Message-ID: Forgot mention, being able to see these flags at the IR level in a pass would also help me greatly. Thanks again On Wed, Jul 20, 2011 at 8:14 PM, ret val wrote: > As a plugin I used the ASTConsumer and RecusiveASTVisitor class to find > "interesting" variables and functions. Ultimately I want the address of > these either in the object file or resulting elf. > > From the IRC channel it sounds like this is currently impossible, if not Id > love to hear how I could do this. > > Now I would like to know what exactly would need to be edited so while in > the AST so I could "flag" these interesting things(metadata), so when the > codegen routines runs I could add something(like a comment maybe). Can > anyone give me a hand with how to begin? After browsing these files for > awhile now I'm not even sure what the key functions would be. > > Thank you > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110720/a025a3cf/attachment.html From fvbommel at gmail.com Thu Jul 21 00:41:11 2011 From: fvbommel at gmail.com (Frits van Bommel) Date: Thu, 21 Jul 2011 07:41:11 +0200 Subject: [cfe-dev] [LLVMdev] Use of -mllvm -debug (clang) In-Reply-To: References: Message-ID: On 20 July 2011 20:24, Bhandarkar, Pranav wrote: > I have been trying to use the -mllvm -debug option for clang but without much success. Do I need to build in any specific manner for this to work ? You need to build LLVM with assertions enabled. From panbalag1 at gmail.com Thu Jul 21 09:46:41 2011 From: panbalag1 at gmail.com (Prasanth Anbalagan) Date: Thu, 21 Jul 2011 10:46:41 -0400 Subject: [cfe-dev] Build Error In-Reply-To: References: Message-ID: Hi, I'm trying to build Clang on Redhat Linux. I recevied the following error llvm[3]: Compiling SimplifyLibCalls.cpp for Debug+Asserts build llvm[3]: Compiling Sink.cpp for Debug+Asserts build llvm[3]: Compiling TailDuplication.cpp for Debug+Asserts build llvm[3]: Compiling TailRecursionElimination.cpp for Debug+Asserts build llvm[3]: Building Debug+Asserts Archive Library libLLVMScalarOpts.a make[3]: *** [/root/llvm/Debug+Asserts/lib/libLLVMScalarOpts.a] Error 1 make[3]: Leaving directory `/root/llvm/lib/Transforms/Scalar' make[2]: *** [Scalar/.makeall] Error 2 make[2]: Leaving directory `/root/llvm/lib/Transforms' make[1]: *** [Transforms/.makeall] Error 2 make[1]: Leaving directory `/root/llvm/lib' make: *** [all] Error 1 -Any suggestions on how I could resolve this? Thanks, Prasanth -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110721/100f20cc/attachment.html From pranavb at codeaurora.org Thu Jul 21 10:43:20 2011 From: pranavb at codeaurora.org (Pranav Bhandarkar) Date: Thu, 21 Jul 2011 10:43:20 -0500 Subject: [cfe-dev] [LLVMdev] Use of -mllvm -debug (clang) In-Reply-To: References: Message-ID: <003901cc47bc$eb3080f0$c19182d0$@org> > You need to build LLVM with assertions enabled. Ok. Thanks for the information. Pranav _______________________________________________ cfe-dev mailing list cfe-dev at cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From benjamin.orgogozo at normalesup.org Thu Jul 21 10:50:36 2011 From: benjamin.orgogozo at normalesup.org (Benjamin Orgogozo) Date: Thu, 21 Jul 2011 15:50:36 +0000 (UTC) Subject: [cfe-dev] Adding C++ code with a plugin Message-ID: Hello, I'm new to this mailing-list and to CLANG in general so please forgive me if I ask a quite stupid question... I've been reading a few mailing lists and webpages on CLANG now but I can't find a clear answer to my question so I hope someone here could at least point me to the correct resource. My goal is simple: I want to compile a C++ code but after automatically adding a few lines of code. Here are my question: - can (or want) I do that with a plugin? At the beginning I wanted to write a plugin to the front-end and change the AST but it seems (but I hope I'm wrong) that when I use the "load" and "plugin" command line option, I can't generate code at the end. Is it true or not? - How should I do this transformation? The code I want to add is really simple: I just want to add function calls in the constructor of classes with specific class members as parameters. For example, I want to transform: class A { float f; }; class foo { int bar; foo() {} }; into class A { float f; }; class foo { int bar; foo() {baz(bar);} }; It seems that I have two options: * use a rewriter to add nodes within the AST, but it seems that it's only for source to source transformation (and I would like to avoid that if possible). * use a TreeTransform which looks fine but I think I read somewhere that it modifiying the AST for compiling it later wasn't always a good idea. >From what I understood, it seems that I want to use treetransform, but I wonder if I can use it within a plugin *and* generate code with only one call to clang. Any comment and pointer is more than welcome! Thanks, -- Benjamin Orgogozo From benjamin.orgogozo at normalesup.org Thu Jul 21 10:52:52 2011 From: benjamin.orgogozo at normalesup.org (Benjamin Orgogozo) Date: Thu, 21 Jul 2011 17:52:52 +0200 Subject: [cfe-dev] Adding C++ code with a plugin Message-ID: <20110721155252.GA30427@phare.normalesup.org> Hello, I'm new to this mailing-list and to CLANG in general so please forgive me if I ask a quite stupid question... I've been reading a few mailing lists and webpages on CLANG now but I can't find a clear answer to my question so I hope someone here could at least point me to the correct resource. My goal is simple: I want to compile a C++ code but after automatically adding a few lines of code. Here are my question: - can (or want) I do that with a plugin? At the beginning I wanted to write a plugin to the front-end and change the AST but it seems (but I hope I'm wrong) that when I use the "load" and "plugin" command line option, I can't generate code at the end. Is it true or not? - How should I do this transformation? The code I want to add is really simple: I just want to add function calls in the constructor of classes with specific class members as parameters. For example, I want to transform: class A { float f; }; class foo { int bar; foo() {} }; into class A { float f; }; class foo { int bar; foo() {baz(bar);} }; It seems that I have two options: * use a rewriter to add nodes within the AST, but it seems that it's only for source to source transformation (and I would like to avoid that if possible). * use a TreeTransform which looks fine but I think I read somewhere that it modifiying the AST for compiling it later wasn't always a good idea. >From what I understood, it seems that I want to use treetransform, but I wonder if I can use it within a plugin *and* generate code with only one call to clang. Any comment and pointer is more than welcome! Thanks, -- Benjamin Orgogozo From rkotler at mips.com Thu Jul 21 11:22:42 2011 From: rkotler at mips.com (reed kotler) Date: Thu, 21 Jul 2011 09:22:42 -0700 Subject: [cfe-dev] clang driver warnings Message-ID: <4E285252.1060305@mips.com> -w works okay for compiler warnings but does not turn off warnings from the driver. does anybody know how to turn off driver warnings? for example: clang: warning: unknown platform, assuming -mfloat-abi=soft clang: warning: argument unused during compilation: '-funroll-all-loops' From anton at korobeynikov.info Thu Jul 21 11:47:19 2011 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Thu, 21 Jul 2011 20:47:19 +0400 Subject: [cfe-dev] clang driver warnings In-Reply-To: <4E285252.1060305@mips.com> References: <4E285252.1060305@mips.com> Message-ID: Hello > clang: warning: unknown platform, assuming -mfloat-abi=soft > clang: warning: argument unused during compilation: '-funroll-all-loops' Just do not pass this options to clang and you'll done. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From rkotler at mips.com Thu Jul 21 11:54:18 2011 From: rkotler at mips.com (reed kotler) Date: Thu, 21 Jul 2011 09:54:18 -0700 Subject: [cfe-dev] clang driver warnings In-Reply-To: References: <4E285252.1060305@mips.com> Message-ID: <4E2859BA.9090406@mips.com> On 07/21/2011 09:47 AM, Anton Korobeynikov wrote: > Hello > >> clang: warning: unknown platform, assuming -mfloat-abi=soft >> clang: warning: argument unused during compilation: '-funroll-all-loops' > Just do not pass this options to clang and you'll done. > not a good answer. i'm trying to run dejagnu for gcc against clang and many things will fail if there are warnings being put out by the compiler. i consider it a compiler but because "-w" is not working. Reed From rkotler at mips.com Thu Jul 21 11:55:13 2011 From: rkotler at mips.com (reed kotler) Date: Thu, 21 Jul 2011 09:55:13 -0700 Subject: [cfe-dev] clang driver warnings In-Reply-To: <4E2859BA.9090406@mips.com> References: <4E285252.1060305@mips.com> <4E2859BA.9090406@mips.com> Message-ID: <4E2859F1.70504@mips.com> On 07/21/2011 09:54 AM, reed kotler wrote: > On 07/21/2011 09:47 AM, Anton Korobeynikov wrote: >> Hello >> >>> clang: warning: unknown platform, assuming -mfloat-abi=soft >>> clang: warning: argument unused during compilation: >>> '-funroll-all-loops' >> Just do not pass this options to clang and you'll done. >> > not a good answer. > > i'm trying to run dejagnu for gcc against clang and many things will > fail if there are warnings being put out by the compiler. > > i consider it a compiler but because "-w" is not working. > > Reed > dejagnu relies on "-w" working From joerg at britannica.bec.de Thu Jul 21 12:16:50 2011 From: joerg at britannica.bec.de (Joerg Sonnenberger) Date: Thu, 21 Jul 2011 19:16:50 +0200 Subject: [cfe-dev] clang driver warnings In-Reply-To: <4E285252.1060305@mips.com> References: <4E285252.1060305@mips.com> Message-ID: <20110721171650.GA15381@britannica.bec.de> On Thu, Jul 21, 2011 at 09:22:42AM -0700, reed kotler wrote: > -w works okay for compiler warnings but does not turn off warnings from > the driver. > > does anybody know how to turn off driver warnings? > > for example: > > clang: warning: unknown platform, assuming -mfloat-abi=soft Pass down the float abi explicitly. > clang: warning: argument unused during compilation: '-funroll-all-loops' -Qunused-args Joerg From dgregor at apple.com Thu Jul 21 12:40:09 2011 From: dgregor at apple.com (Douglas Gregor) Date: Thu, 21 Jul 2011 10:40:09 -0700 Subject: [cfe-dev] Criteria for Accepting Language Extensions into Clang Message-ID: <46FA9918-1E7D-4DCF-938F-1910127F1FC8@apple.com> For the last several years of Clang's development, our community has focused primarily on implementing existing language standards (C, C++, Objective-C) and improving compatibility with existing compilers (GCC, Visual C++). More recently, we've moved on to emerging standards (C++0x, C1x) and even started introducing significant language extensions not available in other compilers (e.g., Objective-C Automatic Reference Counting). Clang has always been designed as a platform for experimentation, and my hope is that Clang will be the premier vehicle for innovation in the C family of languages, establishing existing practice for the various standards committees. Sooner or later, the successful experiments will become proposed extensions for Clang, at which point we either fully commit to the extension--adding it into the tree and supporting it for many years ahead--or we must decide that the extension is not suitable for inclusion in Clang at this time. To aid in that decision, I propose the following seven criteria: 1) Evidence of a significant user community: This is based on a number of factors, including an actual, existing user community, the perceived likelihood that users would adopt such a feature if it were available, and any "trickle-down" effects that come from, e.g., a library adopting the feature and providing benefits to its users. 2) A specific need to reside within the Clang tree: There are some extensions that would be better expressed as a separate tool, and should remain as separate tools even if they end up being hosted as part of the LLVM umbrella project. 3) A complete specification: The specification must be sufficient to understand the design of the feature as well as interpret the meaning of specific examples. The specification should be detailed enough that another compiler vendor could conceivably implement the feature. 4) Representation within the appropriate governing organization: For extensions to a language governed by a standards committee (C, C++, OpenCL), the extension itself must have an active proposal and proponent within that committee and have a reasonable chance of acceptance. Clang should drive the standard, not diverge from it. 5) A long-term support plan: Contributing a non-trivial extension to Clang implies a commitment to supporting that extension, improving the implementation and specification as Clang evolves. The capacity of the contributor to make that commitment is as important as the commitment itself. 6) A high-quality implementation: Naturally, the implementation must fit well into Clang's architecture, follow LLVM's coding conventions, and meet Clang's quality standards, including high-quality diagnostics and rich AST representations. This is particularly important for language extensions, because users will learn how those extensions work through the behavior of the compiler. 7) A proper test suite: Extensive testing is crucial to ensure that the language extension is not broken by ongoing maintenance in Clang. The test suite should be complete enough that another compiler vendor could conceivably validate their implementation of the feature against it. We intentionally set the bar high for language extensions because we *have* to set the bar high. A half-baked language extension is a cancer on the code base, and having many such extensions would threaten Clang's long-term growth. These criteria are intended to help potential contributors better prepare their extensions for inclusion in Clang, while helping the Clang project grow in a sustainable manner. - Doug Gregor, Code Owner - Clang Frontend From csdavec at swan.ac.uk Thu Jul 21 13:12:06 2011 From: csdavec at swan.ac.uk (David Chisnall) Date: Thu, 21 Jul 2011 19:12:06 +0100 Subject: [cfe-dev] Criteria for Accepting Language Extensions into Clang In-Reply-To: <46FA9918-1E7D-4DCF-938F-1910127F1FC8@apple.com> References: <46FA9918-1E7D-4DCF-938F-1910127F1FC8@apple.com> Message-ID: <03504B33-033C-4823-8D02-CDC9271E0498@swan.ac.uk> Sounds good, but I'd like one clarification: On 21 Jul 2011, at 18:40, Douglas Gregor wrote: > 4) Representation within the appropriate governing organization: For extensions to a language governed by a standards committee (C, C++, OpenCL), the extension itself must have an active proposal and proponent within that committee and have a reasonable chance of acceptance. Clang should drive the standard, not diverge from it. How does this mesh with extensions that don't affect standards compliance, such as attributes and pragmas? Most of the attributes that we support for C are not part of any standard - they're explicitly extensions that most likely will not be added to a standard. According to this criterion, we should not accept any more attributes or pragmas along the lines of 90% of the ones that we already have... David From dgregor at apple.com Thu Jul 21 13:13:30 2011 From: dgregor at apple.com (Douglas Gregor) Date: Thu, 21 Jul 2011 11:13:30 -0700 Subject: [cfe-dev] Criteria for Accepting Language Extensions into Clang In-Reply-To: <03504B33-033C-4823-8D02-CDC9271E0498@swan.ac.uk> References: <46FA9918-1E7D-4DCF-938F-1910127F1FC8@apple.com> <03504B33-033C-4823-8D02-CDC9271E0498@swan.ac.uk> Message-ID: On Jul 21, 2011, at 11:12 AM, David Chisnall wrote: > Sounds good, but I'd like one clarification: > > On 21 Jul 2011, at 18:40, Douglas Gregor wrote: > >> 4) Representation within the appropriate governing organization: For extensions to a language governed by a standards committee (C, C++, OpenCL), the extension itself must have an active proposal and proponent within that committee and have a reasonable chance of acceptance. Clang should drive the standard, not diverge from it. > > > How does this mesh with extensions that don't affect standards compliance, such as attributes and pragmas? Most of the attributes that we support for C are not part of any standard - they're explicitly extensions that most likely will not be added to a standard. According to this criterion, we should not accept any more attributes or pragmas along the lines of 90% of the ones that we already have... This criterion doesn't apply to attributes and pragmas. Instead, we'll have to rely on our own judgment (even more) regarding the proper design of the feature. - Doug From annulen at yandex.ru Thu Jul 21 13:23:33 2011 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 21 Jul 2011 22:23:33 +0400 Subject: [cfe-dev] Criteria for Accepting Language Extensions into Clang In-Reply-To: <46FA9918-1E7D-4DCF-938F-1910127F1FC8@apple.com> References: <46FA9918-1E7D-4DCF-938F-1910127F1FC8@apple.com> Message-ID: <208531311272613@web84.yandex.ru> 21.07.2011, 21:40, "Douglas Gregor" : > For the last several years of Clang's development, our community has focused primarily on implementing existing language standards (C, C++, Objective-C) and improving compatibility with existing compilers (GCC, Visual C++). More recently, we've moved on to emerging standards (C++0x, C1x) and even started introducing significant language extensions not available in other compilers (e.g., Objective-C Automatic Reference Counting). > > Clang has always been designed as a platform for experimentation, and my hope is that Clang will be the premier vehicle for innovation in the C family of languages, establishing existing practice for the various standards committees. Sooner or later, the successful experiments will become proposed extensions for Clang, at which point we either fully commit to the extension--adding it into the tree and supporting it for many years ahead--or we must decide that the extension is not suitable for inclusion in Clang at this time. To aid in that decision, I propose the following seven criteria: > > 1) Evidence of a significant user community: This is based on a number of factors, including an actual, existing user community, the perceived likelihood that users would adopt such a feature if it were available, and any "trickle-down" effects that come from, e.g., a library adopting the feature and providing benefits to its users. > > 2) A specific need to reside within the Clang tree: There are some extensions that would be better expressed as a separate tool, and should remain as separate tools even if they end up being hosted as part of the LLVM umbrella project. > > 3) A complete specification: The specification must be sufficient to understand the design of the feature as well as interpret the meaning of specific examples. The specification should be detailed enough that another compiler vendor could conceivably implement the feature. > > 4) Representation within the appropriate governing organization: For extensions to a language governed by a standards committee (C, C++, OpenCL), the extension itself must have an active proposal and proponent within that committee and have a reasonable chance of acceptance. Clang should drive the standard, not diverge from it. > > 5) A long-term support plan: Contributing a non-trivial extension to Clang implies a commitment to supporting that extension, improving the implementation and specification as Clang evolves. The capacity of the contributor to make that commitment is as important as the commitment itself. > > 6) A high-quality implementation: Naturally, the implementation must fit well into Clang's architecture, follow LLVM's coding conventions, and meet Clang's quality standards, including high-quality diagnostics and rich AST representations. This is particularly important for language extensions, because users will learn how those extensions work through the behavior of the compiler. > > 7) A proper test suite: Extensive testing is crucial to ensure that the language extension is not broken by ongoing maintenance in Clang. The test suite should be complete enough that another compiler vendor could conceivably validate their implementation of the feature against it. > > We intentionally set the bar high for language extensions because we *have* to set the bar high. A half-baked language extension is a cancer on the code base, and having many such extensions would threaten Clang's long-term growth. These criteria are intended to help potential contributors better prepare their extensions for inclusion in Clang, while helping the Clang project grow in a sustainable manner. Thanks for clarification. However, it would be great if it was easier to develop front-ends with language extensions without patching Clang code. -- Regards, Konstantin From dgregor at apple.com Thu Jul 21 13:36:14 2011 From: dgregor at apple.com (Douglas Gregor) Date: Thu, 21 Jul 2011 11:36:14 -0700 Subject: [cfe-dev] Criteria for Accepting Language Extensions into Clang In-Reply-To: <208531311272613@web84.yandex.ru> References: <46FA9918-1E7D-4DCF-938F-1910127F1FC8@apple.com> <208531311272613@web84.yandex.ru> Message-ID: On Jul 21, 2011, at 11:23 AM, Konstantin Tokarev wrote: > > > 21.07.2011, 21:40, "Douglas Gregor" : >> For the last several years of Clang's development, our community has focused primarily on implementing existing language standards (C, C++, Objective-C) and improving compatibility with existing compilers (GCC, Visual C++). More recently, we've moved on to emerging standards (C++0x, C1x) and even started introducing significant language extensions not available in other compilers (e.g., Objective-C Automatic Reference Counting). >> >> Clang has always been designed as a platform for experimentation, and my hope is that Clang will be the premier vehicle for innovation in the C family of languages, establishing existing practice for the various standards committees. Sooner or later, the successful experiments will become proposed extensions for Clang, at which point we either fully commit to the extension--adding it into the tree and supporting it for many years ahead--or we must decide that the extension is not suitable for inclusion in Clang at this time. To aid in that decision, I propose the following seven criteria: >> >> 1) Evidence of a significant user community: This is based on a number of factors, including an actual, existing user community, the perceived likelihood that users would adopt such a feature if it were available, and any "trickle-down" effects that come from, e.g., a library adopting the feature and providing benefits to its users. >> >> 2) A specific need to reside within the Clang tree: There are some extensions that would be better expressed as a separate tool, and should remain as separate tools even if they end up being hosted as part of the LLVM umbrella project. >> >> 3) A complete specification: The specification must be sufficient to understand the design of the feature as well as interpret the meaning of specific examples. The specification should be detailed enough that another compiler vendor could conceivably implement the feature. >> >> 4) Representation within the appropriate governing organization: For extensions to a language governed by a standards committee (C, C++, OpenCL), the extension itself must have an active proposal and proponent within that committee and have a reasonable chance of acceptance. Clang should drive the standard, not diverge from it. >> >> 5) A long-term support plan: Contributing a non-trivial extension to Clang implies a commitment to supporting that extension, improving the implementation and specification as Clang evolves. The capacity of the contributor to make that commitment is as important as the commitment itself. >> >> 6) A high-quality implementation: Naturally, the implementation must fit well into Clang's architecture, follow LLVM's coding conventions, and meet Clang's quality standards, including high-quality diagnostics and rich AST representations. This is particularly important for language extensions, because users will learn how those extensions work through the behavior of the compiler. >> >> 7) A proper test suite: Extensive testing is crucial to ensure that the language extension is not broken by ongoing maintenance in Clang. The test suite should be complete enough that another compiler vendor could conceivably validate their implementation of the feature against it. >> >> We intentionally set the bar high for language extensions because we *have* to set the bar high. A half-baked language extension is a cancer on the code base, and having many such extensions would threaten Clang's long-term growth. These criteria are intended to help potential contributors better prepare their extensions for inclusion in Clang, while helping the Clang project grow in a sustainable manner. > > > Thanks for clarification. > > However, it would be great if it was easier to develop front-ends with language extensions without patching Clang code. I fully agree! We should make it easier both for people to add simple extensions and to keep those extensions outside of the tree. - Doug From todd.a.anderson at intel.com Thu Jul 21 13:43:28 2011 From: todd.a.anderson at intel.com (Anderson, Todd A) Date: Thu, 21 Jul 2011 11:43:28 -0700 Subject: [cfe-dev] new calling convention pragma Message-ID: <1DB50624F8348F48840F2E2CF6040A9D019060D684@orsmsx508.amr.corp.intel.com> I'm experimenting with adding two new pragmas of the form #pragma push_cc(calling_convention) and #pragma pop_cc. Basically, I want to keep a stack of default calling conventions. You can change the default from cdecl by doing a push_cc and specifying a different calling convention like __stdcall. Then, you can pop the stack with #pragma pop_cc. A function which does not specify a calling convention would then get the calling at the top of the stack. Any ideas on the best way to approach this modification? Thanks, Todd From joerg at britannica.bec.de Thu Jul 21 14:00:20 2011 From: joerg at britannica.bec.de (Joerg Sonnenberger) Date: Thu, 21 Jul 2011 21:00:20 +0200 Subject: [cfe-dev] new calling convention pragma In-Reply-To: <1DB50624F8348F48840F2E2CF6040A9D019060D684@orsmsx508.amr.corp.intel.com> References: <1DB50624F8348F48840F2E2CF6040A9D019060D684@orsmsx508.amr.corp.intel.com> Message-ID: <20110721190020.GA19974@britannica.bec.de> On Thu, Jul 21, 2011 at 11:43:28AM -0700, Anderson, Todd A wrote: > Any ideas on the best way to approach this modification? Start from the handling of #pragma GCC visibility. I think that's very similiar to your problem. Joerg From clattner at apple.com Thu Jul 21 15:18:45 2011 From: clattner at apple.com (Chris Lattner) Date: Thu, 21 Jul 2011 13:18:45 -0700 Subject: [cfe-dev] Build Error In-Reply-To: References: Message-ID: <085E83DD-C1D0-472E-B02E-DBC111F431CE@apple.com> On Jul 21, 2011, at 7:46 AM, Prasanth Anbalagan wrote: > Hi, > > I'm trying to build Clang on Redhat Linux. I recevied the following error > > llvm[3]: Compiling SimplifyLibCalls.cpp for Debug+Asserts build > llvm[3]: Compiling Sink.cpp for Debug+Asserts build > llvm[3]: Compiling TailDuplication.cpp for Debug+Asserts build > llvm[3]: Compiling TailRecursionElimination.cpp for Debug+Asserts build > llvm[3]: Building Debug+Asserts Archive Library libLLVMScalarOpts.a > make[3]: *** [/root/llvm/Debug+Asserts/lib/libLLVMScalarOpts.a] Error 1 > make[3]: Leaving directory `/root/llvm/lib/Transforms/Scalar' > make[2]: *** [Scalar/.makeall] Error 2 > make[2]: Leaving directory `/root/llvm/lib/Transforms' > make[1]: *** [Transforms/.makeall] Error 2 > make[1]: Leaving directory `/root/llvm/lib' > make: *** [all] Error 1 Hard to say, because it doesn't say what the failure is. I'd try make clean and then rebuild. -Chris From rcsaba at gmail.com Thu Jul 21 15:30:25 2011 From: rcsaba at gmail.com (Csaba Raduly) Date: Thu, 21 Jul 2011 22:30:25 +0200 Subject: [cfe-dev] Build Error In-Reply-To: References: Message-ID: On Thu, Jul 21, 2011 at 4:46 PM, Prasanth Anbalagan wrote: > Hi, > I'm trying to build Clang on Redhat Linux. I recevied the following error > llvm[3]: Compiling SimplifyLibCalls.cpp for Debug+Asserts build > llvm[3]: Compiling Sink.cpp for Debug+Asserts build > llvm[3]: Compiling TailDuplication.cpp for Debug+Asserts build > llvm[3]: Compiling TailRecursionElimination.cpp for Debug+Asserts build > llvm[3]: Building Debug+Asserts Archive Library libLLVMScalarOpts.a > make[3]: *** [/root/llvm/Debug+Asserts/lib/libLLVMScalarOpts.a] Error 1 > make[3]: Leaving directory `/root/llvm/lib/Transforms/Scalar' > make[2]: *** [Scalar/.makeall] Error 2 > make[2]: Leaving directory `/root/llvm/lib/Transforms' > make[1]: *** [Transforms/.makeall] Error 2 > make[1]: Leaving directory `/root/llvm/lib' > make: *** [all] Error 1 Hi Prasanth, There isn't enough information in your mail. We don't even know how you ran make. If you run make VERBOSE=1 it will display the commands executed by make. Perhaps that would give an indication as to what the problem is. Csaba -- GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++ The Tao of math: The numbers you can count are not the real numbers. Life is complex, with real and imaginary parts. "Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds "People disagree with me. I just ignore them." -- Linus Torvalds From dblaikie at gmail.com Thu Jul 21 15:31:29 2011 From: dblaikie at gmail.com (David Blaikie) Date: Thu, 21 Jul 2011 13:31:29 -0700 Subject: [cfe-dev] Switching http://llvm.org/demo to clang or providing a separate clang demo Message-ID: I was hoping to show a friend some examples of clang's excellent diagnostic output (& try out the spellcheck/typo cases) but it seems that the llvm demo still uses llvm-gcc. What would it take to switch it over to clang? Is it just a matter of changing the cgi script to point to clang instead of llvm-gcc, or will the actual demo machine need configuration changes ( http://llvm.org/viewvc/llvm-project/cfe/trunk/www/demo/index.cgi?view=markup refers to vadve's home directory (/home/vadve/shared/llvm-gcc4.0-2.1/bin/)) I wouldn't mind adding some compiler flags there too - especially C++0x, warning levels, etc. It also looks like this is pointing to a rather old build of LLVM (2.1). From lattner at apple.com Thu Jul 21 15:40:52 2011 From: lattner at apple.com (Tanya Lattner) Date: Thu, 21 Jul 2011 13:40:52 -0700 Subject: [cfe-dev] Switching http://llvm.org/demo to clang or providing a separate clang demo In-Reply-To: References: Message-ID: <68AB12BE-B2C6-48C5-883F-3E63DC6C1F3B@apple.com> On Jul 21, 2011, at 1:31 PM, David Blaikie wrote: > I was hoping to show a friend some examples of clang's excellent > diagnostic output (& try out the spellcheck/typo cases) but it seems > that the llvm demo still uses llvm-gcc. Yup, and its several releases old (basically since I stopped being release manager). > > What would it take to switch it over to clang? Is it just a matter of > changing the cgi script to point to clang instead of llvm-gcc, or will > the actual demo machine need configuration changes It takes building and install clang on llvm.org and updating the script. > ( > http://llvm.org/viewvc/llvm-project/cfe/trunk/www/demo/index.cgi?view=markup > refers to vadve's home directory > (/home/vadve/shared/llvm-gcc4.0-2.1/bin/)) I wouldn't mind adding some > compiler flags there too - especially C++0x, warning levels, etc. > > It also looks like this is pointing to a rather old build of LLVM (2.1). That is not the the right script. Regardless, I'll try to do this in the next week. I have a busy schedule for the next 2 weeks, so feel free to ping me if I havent done it in a week. Thanks, Tanya From clattner at apple.com Thu Jul 21 15:42:12 2011 From: clattner at apple.com (Chris Lattner) Date: Thu, 21 Jul 2011 13:42:12 -0700 Subject: [cfe-dev] Switching http://llvm.org/demo to clang or providing a separate clang demo In-Reply-To: References: Message-ID: On Jul 21, 2011, at 1:31 PM, David Blaikie wrote: > I was hoping to show a friend some examples of clang's excellent > diagnostic output (& try out the spellcheck/typo cases) but it seems > that the llvm demo still uses llvm-gcc. > > What would it take to switch it over to clang? Is it just a matter of > changing the cgi script to point to clang instead of llvm-gcc, or will > the actual demo machine need configuration changes ( > http://llvm.org/viewvc/llvm-project/cfe/trunk/www/demo/index.cgi?view=markup > refers to vadve's home directory > (/home/vadve/shared/llvm-gcc4.0-2.1/bin/)) I wouldn't mind adding some > compiler flags there too - especially C++0x, warning levels, etc. > > It also looks like this is pointing to a rather old build of LLVM (2.1). Hey David, This would be really really great, the demo page is long need for a rewrite. FYI the right path to the demo page is here: http://llvm.org/viewvc/llvm-project/www/trunk/demo/ -Chris From popizdeh at gmail.com Thu Jul 21 16:10:58 2011 From: popizdeh at gmail.com (Nikola Smiljanic) Date: Thu, 21 Jul 2011 23:10:58 +0200 Subject: [cfe-dev] Switching http://llvm.org/demo to clang or providing a separate clang demo In-Reply-To: References: Message-ID: I just noticed that going from the Demo page to Hints section and then to llvm2cpp gives an error (404 Not Found). On Thu, Jul 21, 2011 at 10:31 PM, David Blaikie wrote: > I was hoping to show a friend some examples of clang's excellent > diagnostic output (& try out the spellcheck/typo cases) but it seems > that the llvm demo still uses llvm-gcc. > > What would it take to switch it over to clang? Is it just a matter of > changing the cgi script to point to clang instead of llvm-gcc, or will > the actual demo machine need configuration changes ( > > http://llvm.org/viewvc/llvm-project/cfe/trunk/www/demo/index.cgi?view=markup > refers to vadve's home directory > (/home/vadve/shared/llvm-gcc4.0-2.1/bin/)) I wouldn't mind adding some > compiler flags there too - especially C++0x, warning levels, etc. > > It also looks like this is pointing to a rather old build of LLVM (2.1). > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110721/cd744756/attachment-0001.html From dblaikie at gmail.com Thu Jul 21 16:16:26 2011 From: dblaikie at gmail.com (David Blaikie) Date: Thu, 21 Jul 2011 14:16:26 -0700 Subject: [cfe-dev] Switching http://llvm.org/demo to clang or providing a separate clang demo In-Reply-To: <68AB12BE-B2C6-48C5-883F-3E63DC6C1F3B@apple.com> References: <68AB12BE-B2C6-48C5-883F-3E63DC6C1F3B@apple.com> Message-ID: > It takes building and install clang on llvm.org and updating the script. > ... I'll try to do this in the next week. Cool - thanks. Strangely the (correct) script that Chris linked to his reply has a clang path in PREPENDPATHDIRS but I don't really know what it does with it. It looks like, potentially, clang could just be added as an alternative without any changes to the machine itself (if that path, /opt/clang-releases/llvm/bin, is usable) though given llvm-gcc's limited future it might as well be removed. [Chris] > This would be really really great, the demo page is long need for a rewrite. FYI the right path to the demo page is here: > http://llvm.org/viewvc/llvm-project/www/trunk/demo/ Thanks - I'd gotten the link (& started thinking about the demo page to see if it had 0x support, etc) from a recent clang checkin. It looks like it's a clang copy & there's this file: http://clang.llvm.org/demo/what%20is%20this%20directory.txt It seems like that directory's a bit redundant & rather than having a separate clang demo, we'd just update the llvm demo to use clang instead of llvm-gcc, yes? I'm wondering what would be the most practical way to work on improvements. Small ones that don't require testing (if there's already support for one command line argument, say, then adding more shouldn't be painful/hard/risky) I can submit patches for & wait for them to go live, but I wouldn't want to burden the list with lots of patches as a means of developing/debugging/fixing changes when they go live. I guess it would be easier for someone with direct access to the machine to just hack at the script & check the changes live, then checkin the result. But I'm happy to have a crack at blind/unvalidated patches to improve the functionality if that's useful. - David From clattner at apple.com Thu Jul 21 16:19:41 2011 From: clattner at apple.com (Chris Lattner) Date: Thu, 21 Jul 2011 14:19:41 -0700 Subject: [cfe-dev] Switching http://llvm.org/demo to clang or providing a separate clang demo In-Reply-To: References: <68AB12BE-B2C6-48C5-883F-3E63DC6C1F3B@apple.com> Message-ID: <1ED9477B-F151-4752-8DC1-5771DFBCBA68@apple.com> > >> This would be really really great, the demo page is long need for a rewrite. FYI the right path to the demo page is here: >> http://llvm.org/viewvc/llvm-project/www/trunk/demo/ > > Thanks - I'd gotten the link (& started thinking about the demo page > to see if it had 0x support, etc) from a recent clang checkin. It > looks like it's a clang copy & there's this file: > http://clang.llvm.org/demo/what%20is%20this%20directory.txt > > It seems like that directory's a bit redundant & rather than having a > separate clang demo, we'd just update the llvm demo to use clang > instead of llvm-gcc, yes? yes, I had no idea we had a clang/demo. We should just make it be the llvm demo page. > I'm wondering what would be the most practical way to work on > improvements. Small ones that don't require testing (if there's > already support for one command line argument, say, then adding more > shouldn't be painful/hard/risky) I can submit patches for & wait for > them to go live, but I wouldn't want to burden the list with lots of > patches as a means of developing/debugging/fixing changes when they go > live. I guess it would be easier for someone with direct access to the > machine to just hack at the script & check the changes live, then > checkin the result. I'd suggest copying this to "demo/index2.cgi" and leaving the original alone. Hack it up all you want, and play with it live. When you're happy with it, we can talk about switching it over as the default, replacing the old one. Seem reasonable? -Chris From dblaikie at gmail.com Thu Jul 21 16:30:25 2011 From: dblaikie at gmail.com (David Blaikie) Date: Thu, 21 Jul 2011 14:30:25 -0700 Subject: [cfe-dev] Switching http://llvm.org/demo to clang or providing a separate clang demo In-Reply-To: <1ED9477B-F151-4752-8DC1-5771DFBCBA68@apple.com> References: <68AB12BE-B2C6-48C5-883F-3E63DC6C1F3B@apple.com> <1ED9477B-F151-4752-8DC1-5771DFBCBA68@apple.com> Message-ID: > I'd suggest copying this to "demo/index2.cgi" and leaving the original alone. ?Hack it up all you want, and play with it live. ?When you're happy with it, we can talk about switching it over as the default, replacing the old one. ?Seem reasonable? Sure - works for me. Though it'll be a little noisy to the commits list, perhaps - and I'll likely need commit privileges to make the most of it. Another minor detail: How does the llvm.org website get updated from svn submissions? Some kind of trigger? - David From clattner at apple.com Thu Jul 21 17:05:56 2011 From: clattner at apple.com (Chris Lattner) Date: Thu, 21 Jul 2011 15:05:56 -0700 Subject: [cfe-dev] Switching http://llvm.org/demo to clang or providing a separate clang demo In-Reply-To: References: <68AB12BE-B2C6-48C5-883F-3E63DC6C1F3B@apple.com> <1ED9477B-F151-4752-8DC1-5771DFBCBA68@apple.com> Message-ID: On Jul 21, 2011, at 2:30 PM, David Blaikie wrote: >> I'd suggest copying this to "demo/index2.cgi" and leaving the original alone. Hack it up all you want, and play with it live. When you're happy with it, we can talk about switching it over as the default, replacing the old one. Seem reasonable? > > Sure - works for me. Though it'll be a little noisy to the commits > list, perhaps - and I'll likely need commit privileges to make the > most of it. Okay, this is a good point, it's probably best to try to do most of this locally, then push out tested patches. It can still be to an alternate version of the script until it's ready to go, but it would be best to avoid the thrash. > Another minor detail: How does the llvm.org website get updated from > svn submissions? Some kind of trigger? It's auto-updated as a post-commit hook. -Chris From dblaikie at gmail.com Thu Jul 21 17:09:41 2011 From: dblaikie at gmail.com (David Blaikie) Date: Thu, 21 Jul 2011 15:09:41 -0700 Subject: [cfe-dev] Switching http://llvm.org/demo to clang or providing a separate clang demo In-Reply-To: References: <68AB12BE-B2C6-48C5-883F-3E63DC6C1F3B@apple.com> <1ED9477B-F151-4752-8DC1-5771DFBCBA68@apple.com> Message-ID: > Okay, this is a good point, it's probably best to try to do most of this locally, then push out tested patches. ?It can still be to an alternate version of the script until it's ready to go, but it would be best to avoid the thrash. Ok - I'll see about setting up a local mirror/experimental area locally when I get a chance. Thanks, - David From ryuuta at gmail.com Thu Jul 21 17:13:24 2011 From: ryuuta at gmail.com (Ryuta Suzuki) Date: Fri, 22 Jul 2011 07:13:24 +0900 Subject: [cfe-dev] libclangAST.so: undefined reference Message-ID: Hi, I've seen the the following undefined reference error for a while: [ 94%] Built target gtest_main Linking CXX executable AST/ASTTests ../../../lib/libclangAST.so: undefined reference to `clang::Lexer::AdvanceToTokenCharacter(clang::SourceLocation, unsigned int, clang::SourceManager const&, clang::LangOptions const&)' ../../../lib/libclangAST.so: undefined reference to `clang::Lexer::LexTokenInternal(clang::Token&)' ../../../lib/libclangAST.so: undefined reference to `clang::StringLiteralParser::init(clang::Token const*, unsigned int)' ../../../lib/libclangAST.so: undefined reference to `clang::Lexer::getSourceLocation(char const*, unsigned int) const' ../../../lib/libclangAST.so: undefined reference to `clang::Lexer::Lexer(clang::SourceLocation, clang::LangOptions const&, char const*, char const*, char const*)' ../../../lib/libclangAST.so: undefined reference to `clang::StringLiteralParser::getOffsetOfStringByte(clang::Token const&, unsigned int) const' collect2: ld returned 1 exit status make[2]: *** [tools/clang/unittests/AST/ASTTests] Error 1 make[1]: *** [tools/clang/unittests/CMakeFiles/ASTTests.dir/all] Error 2 LLVM_USED_LIBS in clang/lib/AST/CMakeLists.txt may need to be updated? Thanks, Ryuta -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110722/12ce4161/attachment.html From devlists at shadowlab.org Fri Jul 22 01:56:20 2011 From: devlists at shadowlab.org (Jean-Daniel Dupas) Date: Fri, 22 Jul 2011 08:56:20 +0200 Subject: [cfe-dev] ARC and @synthesize of read only property In-Reply-To: References: <370D5D91-4737-4AB3-B111-6D16E92CFE88@shadowlab.org> <3DA507E0-A124-4FEF-AE8C-A74F78E845E0@swan.ac.uk> <9A22BF15-B888-4E3C-94ED-A8F58117FE99@shadowlab.org> Message-ID: <25CCB94F-4B51-4D9B-A9FB-48A44A88E905@shadowlab.org> Le 20 juil. 2011 ? 10:57, David Chisnall a ?crit : > On 19 Jul 2011, at 21:06, Jean-Daniel Dupas wrote: > >> Thank you for the explanation. So the retained/autorelease is a new behavior introduced with ARC. AFAIK, the getter did this only for atomic properties in non ARC mode. > > You can check the generated IR. In ARC mode, it calls objc_getProperty() for atomic properties. For nonatomic properties, it accesses the ivar directly and calls objc_retainAutoreleaseReturnValue(). If you do something like: > > id o = [object synthesizedNonatomicProperty]; > > Then ARC will translate this into something like: > > o = objc_retainAutoreleasedReturnValue([object synthesizedNonatomicProperty]); > > This skips the autorelease pool, so the object is now retained in the caller but not present in the autorelease pool. ARC will then objc_release() it at the end of the scope of o. This means that you get a lot less redundant autorelease pool churn in ARC mode. Look like commit 135747 changed this behavior for nonatomic (and non-weak) property. They now have the same behavior in ARC mode than in non-ARC mode. They are simply returned. -- Jean-Daniel From 6yearold at gmail.com Fri Jul 22 02:06:58 2011 From: 6yearold at gmail.com (arrowdodger) Date: Fri, 22 Jul 2011 11:06:58 +0400 Subject: [cfe-dev] Build Error In-Reply-To: References: Message-ID: On Thu, Jul 21, 2011 at 6:46 PM, Prasanth Anbalagan wrote: > Hi, > > I'm trying to build Clang on Redhat Linux. I recevied the following error > > llvm[3]: Compiling SimplifyLibCalls.cpp for Debug+Asserts build > llvm[3]: Compiling Sink.cpp for Debug+Asserts build > llvm[3]: Compiling TailDuplication.cpp for Debug+Asserts build > llvm[3]: Compiling TailRecursionElimination.cpp for Debug+Asserts build > llvm[3]: Building Debug+Asserts Archive Library libLLVMScalarOpts.a > make[3]: *** [/root/llvm/Debug+Asserts/lib/libLLVMScalarOpts.a] Error 1 > make[3]: Leaving directory `/root/llvm/lib/Transforms/Scalar' > make[2]: *** [Scalar/.makeall] Error 2 > make[2]: Leaving directory `/root/llvm/lib/Transforms' > make[1]: *** [Transforms/.makeall] Error 2 > make[1]: Leaving directory `/root/llvm/lib' > make: *** [all] Error 1 > > > -Any suggestions on how I could resolve this? > > Thanks, > Prasanth > It seems, you've ran make with -jN. One thread failed compiling and printed error, but other threads continued working and printing stuff. So, the error message was left somewhere earlier. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110722/67330efd/attachment-0001.html From criswell at illinois.edu Fri Jul 22 14:55:34 2011 From: criswell at illinois.edu (John Criswell) Date: Fri, 22 Jul 2011 14:55:34 -0500 Subject: [cfe-dev] Clang Plugins Message-ID: <4E29D5B6.2060209@illinois.edu> Dear All, We're looking to integrate our memory safety transforms into Clang so that a simple command-line option to Clang will compile code with memory safety checks. We had originally believed that we would need to modify Clang, but Chris Lattner suggested that we investigate a new plugin infrastructure that is in development in Clang by Doug (I think it has something to do with PassManagerBuilder.h). Is there documentation on this infrastructure, and if so, where can we find it? Thanks in advance, -- John T. From dgregor at apple.com Fri Jul 22 15:15:00 2011 From: dgregor at apple.com (Douglas Gregor) Date: Fri, 22 Jul 2011 13:15:00 -0700 Subject: [cfe-dev] Clang Plugins In-Reply-To: <4E29D5B6.2060209@illinois.edu> References: <4E29D5B6.2060209@illinois.edu> Message-ID: <5B31B899-4170-49B4-96BB-C2231D760D10@apple.com> On Jul 22, 2011, at 12:55 PM, John Criswell wrote: > Dear All, > > We're looking to integrate our memory safety transforms into Clang so > that a simple command-line option to Clang will compile code with memory > safety checks. > > We had originally believed that we would need to modify Clang, but Chris > Lattner suggested that we investigate a new plugin infrastructure that > is in development in Clang by Doug (I think it has something to do with > PassManagerBuilder.h). As much as I'd love to see an improved plugin framework, I'm not actively working on one. - Doug From criswell at illinois.edu Fri Jul 22 15:21:56 2011 From: criswell at illinois.edu (John Criswell) Date: Fri, 22 Jul 2011 15:21:56 -0500 Subject: [cfe-dev] Clang Plugins In-Reply-To: <5B31B899-4170-49B4-96BB-C2231D760D10@apple.com> References: <4E29D5B6.2060209@illinois.edu> <5B31B899-4170-49B4-96BB-C2231D760D10@apple.com> Message-ID: <4E29DBE4.1090902@illinois.edu> On 7/22/11 3:15 PM, Douglas Gregor wrote: > On Jul 22, 2011, at 12:55 PM, John Criswell wrote: > >> Dear All, >> >> We're looking to integrate our memory safety transforms into Clang so >> that a simple command-line option to Clang will compile code with memory >> safety checks. >> >> We had originally believed that we would need to modify Clang, but Chris >> Lattner suggested that we investigate a new plugin infrastructure that >> is in development in Clang by Doug (I think it has something to do with >> PassManagerBuilder.h). > > As much as I'd love to see an improved plugin framework, I'm not actively working on one. To quote Chris, "Doug gave a talk at boostcon about doing ast transformations with it, but no it is not very mature at all. The static analyzer is moving to it, but there are no widely used plugins yet." [1] Are you the Doug that discussed the Clang plugin infrastructure at boostcon? If so, did I misunderstand Chris when he said that work had started on it but that it was in the early stages? -- John T. [1] http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110718/124614.html > > - Doug From dgregor at apple.com Fri Jul 22 15:27:45 2011 From: dgregor at apple.com (Douglas Gregor) Date: Fri, 22 Jul 2011 13:27:45 -0700 Subject: [cfe-dev] Clang Plugins In-Reply-To: <4E29DBE4.1090902@illinois.edu> References: <4E29D5B6.2060209@illinois.edu> <5B31B899-4170-49B4-96BB-C2231D760D10@apple.com> <4E29DBE4.1090902@illinois.edu> Message-ID: On Jul 22, 2011, at 1:21 PM, John Criswell wrote: > On 7/22/11 3:15 PM, Douglas Gregor wrote: >> On Jul 22, 2011, at 12:55 PM, John Criswell wrote: >> >>> Dear All, >>> >>> We're looking to integrate our memory safety transforms into Clang so >>> that a simple command-line option to Clang will compile code with memory >>> safety checks. >>> >>> We had originally believed that we would need to modify Clang, but Chris >>> Lattner suggested that we investigate a new plugin infrastructure that >>> is in development in Clang by Doug (I think it has something to do with >>> PassManagerBuilder.h). >> >> As much as I'd love to see an improved plugin framework, I'm not actively working on one. > > To quote Chris, "Doug gave a talk at boostcon about doing ast transformations with it, but no it is not very mature at all. The static analyzer is moving to it, but there are no widely used plugins yet." [1] > > Are you the Doug that discussed the Clang plugin infrastructure at boostcon? If so, did I misunderstand Chris when he said that work had started on it but that it was in the early stages? There's not much work going on in that area now, although you can check out the examples in the Clang tree for plugins that do currently exist, and how they fit in. There is much to be improved. - Doug From criswell at illinois.edu Fri Jul 22 15:39:47 2011 From: criswell at illinois.edu (John Criswell) Date: Fri, 22 Jul 2011 15:39:47 -0500 Subject: [cfe-dev] Clang Plugins In-Reply-To: References: <4E29D5B6.2060209@illinois.edu> <5B31B899-4170-49B4-96BB-C2231D760D10@apple.com> <4E29DBE4.1090902@illinois.edu> Message-ID: <4E29E013.9050703@illinois.edu> On 7/22/11 3:27 PM, Douglas Gregor wrote: > On Jul 22, 2011, at 1:21 PM, John Criswell wrote: > >> snip] > > There's not much work going on in that area now, although you can check out the examples in the Clang tree for plugins that do currently exist, and how they fit in. There is much to be improved. Where can I find these examples in the Clang source tree? Is there a class whose name I can grep for in the source code to help locate these examples? -- John T. > > - Doug From dgregor at apple.com Fri Jul 22 15:41:07 2011 From: dgregor at apple.com (Douglas Gregor) Date: Fri, 22 Jul 2011 13:41:07 -0700 Subject: [cfe-dev] Clang Plugins In-Reply-To: <4E29E013.9050703@illinois.edu> References: <4E29D5B6.2060209@illinois.edu> <5B31B899-4170-49B4-96BB-C2231D760D10@apple.com> <4E29DBE4.1090902@illinois.edu> <4E29E013.9050703@illinois.edu> Message-ID: <092590E9-C157-4BEB-8EC7-2CC448AEAD23@apple.com> On Jul 22, 2011, at 1:39 PM, John Criswell wrote: > On 7/22/11 3:27 PM, Douglas Gregor wrote: >> On Jul 22, 2011, at 1:21 PM, John Criswell wrote: >> >>> snip] >> >> There's not much work going on in that area now, although you can check out the examples in the Clang tree for plugins that do currently exist, and how they fit in. There is much to be improved. > > Where can I find these examples in the Clang source tree? Is there a class whose name I can grep for in the source code to help locate these examples? examples/PrintFunctionNames is the example I had in mind. It shows how to introduce a new ASTConsumer via a plugin. - Doug From criswell at illinois.edu Fri Jul 22 15:46:52 2011 From: criswell at illinois.edu (John Criswell) Date: Fri, 22 Jul 2011 15:46:52 -0500 Subject: [cfe-dev] Clang Plugins In-Reply-To: <092590E9-C157-4BEB-8EC7-2CC448AEAD23@apple.com> References: <4E29D5B6.2060209@illinois.edu> <5B31B899-4170-49B4-96BB-C2231D760D10@apple.com> <4E29DBE4.1090902@illinois.edu> <4E29E013.9050703@illinois.edu> <092590E9-C157-4BEB-8EC7-2CC448AEAD23@apple.com> Message-ID: <4E29E1BC.7050005@illinois.edu> On 7/22/11 3:41 PM, Douglas Gregor wrote: > On Jul 22, 2011, at 1:39 PM, John Criswell wrote: > >> On 7/22/11 3:27 PM, Douglas Gregor wrote: >>> On Jul 22, 2011, at 1:21 PM, John Criswell wrote: >>> >>>> snip] >>> There's not much work going on in that area now, although you can check out the examples in the Clang tree for plugins that do currently exist, and how they fit in. There is much to be improved. >> Where can I find these examples in the Clang source tree? Is there a class whose name I can grep for in the source code to help locate these examples? > examples/PrintFunctionNames is the example I had in mind. It shows how to introduce a new ASTConsumer via a plugin. Okay. Thanks. -- John T. > > - Doug From dgregor at apple.com Fri Jul 22 16:00:57 2011 From: dgregor at apple.com (Douglas Gregor) Date: Fri, 22 Jul 2011 14:00:57 -0700 Subject: [cfe-dev] Proposal for thread safety attributes for Clang In-Reply-To: References: Message-ID: <5E23CA0D-1A55-4ADF-B591-DA52324A1AF1@apple.com> Hello Caitlin, On Jun 30, 2011, at 5:57 PM, Caitlin Sadowski wrote: > Thread Safety Attributes for Clang > > Summary > > We would like to add a set of thread safety attributes to Clang. These attributes, based on a prior GCC implementation, will allow for checkable documentation of basic locking policies in multithreaded programs. > > Background > The synchronization policies in modern multithreaded code may be poorly documented, and incorrectly inferred by new developers. Furthermore, when these policies are improperly followed they often lead to bugs which are difficult to reproduce and diagnose. One strategy for avoiding concurrency bugs is formal documentation of these synchronization policies. By writing this documentation using attribute-based annotations, Clang can mechanically check and warn about issues that could potentially result in race conditions and deadlocks. > > Example > > A code sample which demonstrates two of the proposed annotations is below. In this code sample, variables are protected by locks from the Mutex class. This class has been annotated to specify the API used to lock and unlock. > > * GUARDED_BY specifies a particular lock should be held when accessing the annotated variable. Violations of this locking policy may lead to data races. > * ACQUIRED_AFTER annotations document the acquisition order between locks that can be held simultaneously by a thread, by specify the locks that need to be acquired before the annotated lock. Violations of this locking policy may lead to deadlocks. > > [snip example] > > Previous Work > > As mentioned, thread safety annotations have been implemented in GCC. A full list of the annotations and descriptions for them can be found here: > > http://gcc.gnu.org/wiki/ThreadSafetyAnnotation > https://docs.google.com/a/google.com/Doc?id=ddqtfwhb_0c49t6zgr > > These annotations have been in active use in Google?s C++ codebase for a couple of years, so there is a large informal case study of their usefulness. The ideas behind many of these annotations come originally from a research paper [1]. > > Plan > > We are planning to re-implement the GCC thread safety attributes in Clang. We will submit a series of patches to the cfe-commits mailing list. Our current plan for this serie is as follows: > > 1) Basic parsing and semantic checking of the attributes which do not take arguments. In other words, checking whether the attribute is applied in the appropriate context (e.g. to a field, with no arguments). > 2) Basic parsing and semantic checking of the attributes which do take arguments, but without parsing or checking the arguments themselves. At this point, we will simply discard the tokens making up the arguments. > 3) Attribute argument parsing. > 4) Adding the thread safety analysis checks. We will teach the static analysis-based warnings layer to warn for violations of the annotations discussed on the links above. By "static analysis-based warnings layer" are you referring to Sema's CFG-base warnings, or a new checker for the static analyzer? Sorry for the delayed response. This looks like an excellent addition to Clang. The attributes themselves appear general enough to apply to a wide range of locking APIs, so it's general enough to be useful, and I'm glad to hear that there's significant experience with these annotations in the GCC world. Your first patch is fine to commit, with one addition: please also provide documentation for the attributes you're adding (it's fine for it to be based on the text in the C/C++ Thread Safety Annotations doc. you link to above), which should go here: http://clang.llvm.org/docs/LanguageExtensions.html in its own, new section. That way, we'll have a single point of reference on the Clang site for this feature, and it can be updated as you add more features. - Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110722/2c4670a4/attachment-0001.html From supertri at google.com Fri Jul 22 17:05:30 2011 From: supertri at google.com (Caitlin Sadowski) Date: Fri, 22 Jul 2011 15:05:30 -0700 Subject: [cfe-dev] Proposal for thread safety attributes for Clang In-Reply-To: <5E23CA0D-1A55-4ADF-B591-DA52324A1AF1@apple.com> References: <5E23CA0D-1A55-4ADF-B591-DA52324A1AF1@apple.com> Message-ID: > By "static analysis-based warnings layer" are you referring to Sema's > CFG-base warnings, or a new checker for the static analyzer? We are currently implementing the existing GCC checks with Sema's CFG-based warnings. Future warnings and checks (e.g. which we do not have a large amount of previous experience using) will start as checkers in the static analyzer while they are being evaluated (and only migrate into the compiler proper upon consensus). > Your first patch is fine to commit, with one addition: please also provide > documentation for the attributes you're adding (it's fine for it to be based > on the text in the C/C++ Thread Safety Annotations doc. you link to above), Great! Thanks! Cheers, Caitlin Sadowski From ryuuta at gmail.com Fri Jul 22 19:18:42 2011 From: ryuuta at gmail.com (Ryuta Suzuki) Date: Sat, 23 Jul 2011 09:18:42 +0900 Subject: [cfe-dev] libclangAST.so: undefined reference In-Reply-To: References: Message-ID: I fix it by this patch: Index: lib/AST/CMakeLists.txt =================================================================== --- lib/AST/CMakeLists.txt (revision 135826) +++ lib/AST/CMakeLists.txt (working copy) @@ -1,6 +1,6 @@ set(LLVM_LINK_COMPONENTS support) -set(LLVM_USED_LIBS clangBasic) +set(LLVM_USED_LIBS clangBasic clangLex) add_clang_library(clangAST APValue.cpp On Fri, Jul 22, 2011 at 7:13 AM, Ryuta Suzuki wrote: > Hi, > > I've seen the the following undefined reference error for a while: > > [ 94%] Built target gtest_main > Linking CXX executable AST/ASTTests > ../../../lib/libclangAST.so: undefined reference to > `clang::Lexer::AdvanceToTokenCharacter(clang::SourceLocation, unsigned int, > clang::SourceManager const&, clang::LangOptions const&)' > ../../../lib/libclangAST.so: undefined reference to > `clang::Lexer::LexTokenInternal(clang::Token&)' > ../../../lib/libclangAST.so: undefined reference to > `clang::StringLiteralParser::init(clang::Token const*, unsigned int)' > ../../../lib/libclangAST.so: undefined reference to > `clang::Lexer::getSourceLocation(char const*, unsigned int) const' > ../../../lib/libclangAST.so: undefined reference to > `clang::Lexer::Lexer(clang::SourceLocation, clang::LangOptions const&, char > const*, char const*, char const*)' > ../../../lib/libclangAST.so: undefined reference to > `clang::StringLiteralParser::getOffsetOfStringByte(clang::Token const&, > unsigned int) const' > collect2: ld returned 1 exit status > make[2]: *** [tools/clang/unittests/AST/ASTTests] Error 1 > make[1]: *** [tools/clang/unittests/CMakeFiles/ASTTests.dir/all] Error 2 > > LLVM_USED_LIBS in clang/lib/AST/CMakeLists.txt may need to be updated? > > Thanks, > > Ryuta > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110723/a68dc49e/attachment.html From Pidgeot18 at gmail.com Fri Jul 22 19:19:49 2011 From: Pidgeot18 at gmail.com (Joshua Cranmer) Date: Fri, 22 Jul 2011 17:19:49 -0700 Subject: [cfe-dev] Viewing clang ASTs Message-ID: <4E2A13A5.8040902@gmail.com> In my ongoing attempt to use clang as a source of information to build DXR output, I have often found that the online documentation for most of the stuff, well, sucks. The biggest pain point is that the doxygen just completely fails to figure out what I can visit using RecursiveASTVisitor, and, on top of it, manages to not think that DeclCXX.h contains anything documentable. I've gotten around these bugs by hosting an index of clang on DXR (), but that still leaves me in the lurch if I'm trying to understand why one line mysteriously fails to produce the correct output even when the previous line is correct. My solution for this was to put a simple web frontend around a tool which just dumps the TranslationUnit in a JSON-ish format. For lack of better naming, I've called it "viewsource", and you can find a version at . The source code is located on github at if you want to look at it. It's nowhere near complete--I've only managed to dump out Decl statements as well as TypeLoc (though that's not in the online version yet), although I hope to handle Types, Stmts, and Exprs before long. The tool works by building up the information into something akin to a JS object tree internally and then dumps it out, with hooks to handle cycles a bit more gracefully than infinitely looping; with some tweaks, this same basic format could probably be used to build bindings for $DYNAMIC_LANGUAGE to allow people to write compiler plugins in languages other than C++. I apologize for the crappy UI, but polishing web UI is a low priority for me right now. Incidentally, the tool also has support for displaying equivalent Dehydra information for gcc as well as dumping the parse tree (according to Mozilla's implementation) for JavaScript source code. Incidentally, I'd also like to ask if there is the potential for an easier way to represent AST node metadata than reading off all of the method names and hoping that everyone uses the same naming convention (I have to special case a few people who don't follow the same convention). -- Joshua Cranmer News submodule owner DXR coauthor From ryuuta at gmail.com Sat Jul 23 00:29:32 2011 From: ryuuta at gmail.com (Ryuta Suzuki) Date: Sat, 23 Jul 2011 14:29:32 +0900 Subject: [cfe-dev] [libc++] Comparing vector::iterator to vector::const_iterator& Message-ID: Hi, The following program cannot be compiled with libc++ #include #include typedef std::vector KernelVector; typedef std::unordered_map KernelVectorMap; int main() { KernelVectorMap::const_iterator kernel; KernelVector::const_iterator subkernel = kernel->second.begin(); std::distance( kernel->second.begin(), subkernel ); return 0; } clang++ -std=c++0x -stdlib=libc++ ./const_iterator.cpp ./const_iterator.cpp:12:3: error: no matching function for call to 'distance' std::distance( kernel->second.begin(), subkernel ); ^~~~~~~~~~~~~ /usr/include/c++/v1/iterator:478:1: note: candidate template ignored: deduced conflicting types for parameter '_InputIter' ('std::__1::__wrap_iter' vs. 'std::__1::__wrap_iter') distance(_InputIter __first, _InputIter __last) ^ 1 error generated. or g++ -std=c++0x -I /usr/include/c++/v1/ ./const_iterator.cpp ./const_iterator.cpp: In function ?int main()?: ./const_iterator.cpp:12:52: error: no matching function for call to ?distance(std::__1::vector::iterator, std::__1::vector::const_iterator&)? ./const_iterator.cpp:12:52: note: candidate is: /usr/include/c++/v1/iterator:479:47: note: template typename std::__1::iterator_traits::difference_type std::__1::distance(_InputIter, _InputIter) Please note that there's no error produced when libstdc++ used. My expectation was that libc++ silently convert iterator to const_iterator if necessary, but I guess I'm wrong. Any comments will be greatly appreciated. Thanks, Ryuta -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110723/6e2b05ac/attachment.html From dblaikie at gmail.com Sat Jul 23 01:41:41 2011 From: dblaikie at gmail.com (David Blaikie) Date: Fri, 22 Jul 2011 23:41:41 -0700 Subject: [cfe-dev] [libc++] Comparing vector::iterator to vector::const_iterator& In-Reply-To: References: Message-ID: > My expectation was that libc++ silently convert iterator to const_iterator > if necessary, but I guess I'm wrong. > Any comments will be greatly appreciated. Looks like you're right to expect that, by my reading: 23.2.1\4, Table 96, row 3: Expression: X::iterator ... Assertion/note pre-/post-condition: .... convertible to X::const_iterator. From dblaikie at gmail.com Sat Jul 23 02:16:32 2011 From: dblaikie at gmail.com (David Blaikie) Date: Sat, 23 Jul 2011 00:16:32 -0700 Subject: [cfe-dev] Switching http://llvm.org/demo to clang or providing a separate clang demo In-Reply-To: References: <68AB12BE-B2C6-48C5-883F-3E63DC6C1F3B@apple.com> <1ED9477B-F151-4752-8DC1-5771DFBCBA68@apple.com> Message-ID: >> Okay, this is a good point, it's probably best to try to do most of this locally, then push out tested patches. ?It can still be to an alternate version of the script until it's ready to go, but it would be best to avoid the thrash. > > Ok - I'll see about setting up a local mirror/experimental area > locally when I get a chance. Seems someone else got to this a while ago, but perhaps didn't quite get enough feedback or have enough time to see it through: http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-March/038828.html http://llvm.org/bugs/show_bug.cgi?id=1440 If someone wants to give feedback on the changes posted in the bug I can try to update it, or we can start again from scratch. I'm just working on getting this setup myself so I can see how it looks/works locally. - David From ryuuta at gmail.com Sat Jul 23 08:05:01 2011 From: ryuuta at gmail.com (Ryuta Suzuki) Date: Sat, 23 Jul 2011 22:05:01 +0900 Subject: [cfe-dev] [libc++] Comparing vector::iterator to vector::const_iterator& In-Reply-To: References: Message-ID: Hi David, Thanks for the info. I filed the bug report. Regards, Ryuta On Sat, Jul 23, 2011 at 3:41 PM, David Blaikie wrote: > > My expectation was that libc++ silently convert iterator to > const_iterator > > if necessary, but I guess I'm wrong. > > Any comments will be greatly appreciated. > > Looks like you're right to expect that, by my reading: 23.2.1\4, Table > 96, row 3: > > Expression: X::iterator > ... > Assertion/note pre-/post-condition: .... convertible to X::const_iterator. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110723/8cbf66ce/attachment-0001.html From popizdeh at gmail.com Sat Jul 23 08:14:04 2011 From: popizdeh at gmail.com (Nikola Smiljanic) Date: Sat, 23 Jul 2011 15:14:04 +0200 Subject: [cfe-dev] Easier debugging with Visual Studio Visualizers Message-ID: Hello everyone, I've spent the last couple of days debugging Clang and peeking inside SmallVector and Token really annoyed me so I decided to write some visualizers to make my life easier. I hope somebody else finds this useful and if you have any ideas about other types that should be supported just ask and I'll try to add them. There are two ways to make this work: 1. Put the path to clangVisualizer.txt in the environmental variable called _vcee_autoexp and restart your Visual Studio. This method should work for Visual Studio 2008 and 2010 and is less invasive. 2. Copy everything except the [Visualizer] tag from clangVisualizers.txt to C:\Program Files\Microsoft Visual Studio 10.0\Common7\Packages\Debugger\autoexp.dat. Make sure you backup your original autoexp.dat first. This should work for Visual Studio 2005 and above. Here are the visualizers in action: Token Visualizer SmallVector Visualizer (It works just like the one for std::vector, displays size, capacity and elements) If you'd like to disable the visualizer for a specific variable just type variable_name,! inside the watch window. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110723/a77acffc/attachment.html -------------- next part -------------- [Visualizer] llvm::SmallVector<*,*>{ preview ( #( "[", ($T1*)$e.EndX - ($T1*)$e.BeginX, "](", #array( expr: (($T1*)$e.BeginX)[$i], size: ($T1*)$e.EndX - ($T1*)$e.BeginX ), ")" ) ) children ( #( #([size] : ($T1*)$e.EndX - ($T1*)$e.BeginX), #([capacity] : ($T1*)$e.CapacityX - ($T1*)$e.BeginX), #array( expr: (($T1*)$e.BeginX)[$i], size: ($T1*)$e.EndX - ($T1*)$e.BeginX ) ) ) } clang::Token{ preview((clang::tok::TokenKind)(int)$e.Kind) } From hhinnant at apple.com Sat Jul 23 11:18:42 2011 From: hhinnant at apple.com (Howard Hinnant) Date: Sat, 23 Jul 2011 12:18:42 -0400 Subject: [cfe-dev] [libc++] Comparing vector::iterator to vector::const_iterator& In-Reply-To: References: Message-ID: <7472183C-D4F8-4F3E-8375-D74F316EA991@apple.com> Thanks! Fix committed revision 135854. It was a problem with the pointer type of unordered_map::const_iterator. It was value_type* and should have been const value_type*. Howard On Jul 23, 2011, at 9:05 AM, Ryuta Suzuki wrote: > Hi David, > > Thanks for the info. I filed the bug report. > > Regards, > > Ryuta > > On Sat, Jul 23, 2011 at 3:41 PM, David Blaikie wrote: > > My expectation was that libc++ silently convert iterator to const_iterator > > if necessary, but I guess I'm wrong. > > Any comments will be greatly appreciated. > > Looks like you're right to expect that, by my reading: 23.2.1\4, Table > 96, row 3: > > Expression: X::iterator > ... > Assertion/note pre-/post-condition: .... convertible to X::const_iterator. > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From geek4civic at gmail.com Sat Jul 23 18:32:30 2011 From: geek4civic at gmail.com (NAKAMURA Takumi) Date: Sun, 24 Jul 2011 08:32:30 +0900 Subject: [cfe-dev] libclangAST.so: undefined reference In-Reply-To: References: Message-ID: Suzuki san, applied in r135864, though I have not tested with shared libs. > +set(LLVM_USED_LIBS clangBasic clangLex) Thank you. ...Takumi From ryuuta at gmail.com Sat Jul 23 19:26:39 2011 From: ryuuta at gmail.com (Ryuta Suzuki) Date: Sun, 24 Jul 2011 09:26:39 +0900 Subject: [cfe-dev] [libc++] Comparing vector::iterator to vector::const_iterator& In-Reply-To: <7472183C-D4F8-4F3E-8375-D74F316EA991@apple.com> References: <7472183C-D4F8-4F3E-8375-D74F316EA991@apple.com> Message-ID: Hi Howard, I verified the fix worked. Thanks! Regards, Ryuta On Sun, Jul 24, 2011 at 1:18 AM, Howard Hinnant wrote: > Thanks! Fix committed revision 135854. > > It was a problem with the pointer type of unordered_map::const_iterator. > It was value_type* and should have been const value_type*. > > Howard > > On Jul 23, 2011, at 9:05 AM, Ryuta Suzuki wrote: > > > Hi David, > > > > Thanks for the info. I filed the bug report. > > > > Regards, > > > > Ryuta > > > > On Sat, Jul 23, 2011 at 3:41 PM, David Blaikie > wrote: > > > My expectation was that libc++ silently convert iterator to > const_iterator > > > if necessary, but I guess I'm wrong. > > > Any comments will be greatly appreciated. > > > > Looks like you're right to expect that, by my reading: 23.2.1\4, Table > > 96, row 3: > > > > Expression: X::iterator > > ... > > Assertion/note pre-/post-condition: .... convertible to > X::const_iterator. > > > > _______________________________________________ > > 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/20110724/029e3843/attachment.html From craig.topper at gmail.com Mon Jul 25 00:28:46 2011 From: craig.topper at gmail.com (Craig Topper) Date: Sun, 24 Jul 2011 22:28:46 -0700 Subject: [cfe-dev] [PATCH] C++0x unicode string and character literals now with test cases In-Reply-To: References: Message-ID: Previous patch doesn't apply cleanly anymore so here's a new version. Chris or Doug, if you're reading this can I get a review as suggested by Eric? Thanks, ~Craig -------------- next part -------------- A non-text attachment was scrubbed... Name: unicode_strings.patch Type: application/octet-stream Size: 79199 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110724/d96672fd/attachment-0001.obj From retval386 at gmail.com Mon Jul 25 09:31:11 2011 From: retval386 at gmail.com (ret val) Date: Mon, 25 Jul 2011 10:31:11 -0400 Subject: [cfe-dev] using CodeGenOptions::EmitDeclMetadata()? Message-ID: Does anyone know how to take advantage of this? The header file has a comment that reads "Only useful when running CodeGen as a subroutine", I would like to use this feature in a Pass and don't know where to begin. Is there example code somewhere? Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110725/c5496836/attachment.html From rjmccall at apple.com Mon Jul 25 12:34:18 2011 From: rjmccall at apple.com (John McCall) Date: Mon, 25 Jul 2011 10:34:18 -0700 Subject: [cfe-dev] using CodeGenOptions::EmitDeclMetadata()? In-Reply-To: References: Message-ID: On Jul 25, 2011, at 7:31 AM, ret val wrote: > Does anyone know how to take advantage of this? The header file has a comment that reads "Only useful when running CodeGen as a subroutine", I would like to use this feature in a Pass and don't know where to begin. > > Is there example code somewhere? LLDB uses it; you can check out their code and see the details. Essentially, if you set the flag, alloca instructions and global declarations will be marked with a metadata whose argument is the integral value of some corresponding Decl*. I would not count on this information surviving arbitrary optimizations, though. John. From retval386 at gmail.com Mon Jul 25 12:46:54 2011 From: retval386 at gmail.com (ret val) Date: Mon, 25 Jul 2011 13:46:54 -0400 Subject: [cfe-dev] using CodeGenOptions::EmitDeclMetadata()? In-Reply-To: References: Message-ID: Only global declarations? Thats not good... I need some simple way of marking function pointers and functions at the AST level(with a Plugin) and having it survive to the IR level(as a Pass). Thanks On Mon, Jul 25, 2011 at 1:34 PM, John McCall wrote: > On Jul 25, 2011, at 7:31 AM, ret val wrote: > > Does anyone know how to take advantage of this? The header file has a > comment that reads "Only useful when running CodeGen as a subroutine", I > would like to use this feature in a Pass and don't know where to begin. > > > > Is there example code somewhere? > > LLDB uses it; you can check out their code and see the details. > Essentially, if you set the flag, alloca instructions and global > declarations will be marked with a metadata whose argument is the integral > value of some corresponding Decl*. I would not count on this information > surviving arbitrary optimizations, though. > > John. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110725/79a0374b/attachment.html From rjmccall at apple.com Mon Jul 25 12:50:52 2011 From: rjmccall at apple.com (John McCall) Date: Mon, 25 Jul 2011 10:50:52 -0700 Subject: [cfe-dev] using CodeGenOptions::EmitDeclMetadata()? In-Reply-To: References: Message-ID: <1A708775-88CB-4D5A-B12E-3548EAED0AC9@apple.com> On Jul 25, 2011, at 10:46 AM, ret val wrote: > Only global declarations? Thats not good... I very clearly said "alloca instructions and global declarations". These are the most obvious IR products corresponding to individual decls. John. From retval386 at gmail.com Mon Jul 25 12:56:03 2011 From: retval386 at gmail.com (ret val) Date: Mon, 25 Jul 2011 13:56:03 -0400 Subject: [cfe-dev] using CodeGenOptions::EmitDeclMetadata()? In-Reply-To: <1A708775-88CB-4D5A-B12E-3548EAED0AC9@apple.com> References: <1A708775-88CB-4D5A-B12E-3548EAED0AC9@apple.com> Message-ID: I was more concerned about VarDecls created inside functions and if there was any possibility of getting those. I don't know if that would be a reasonable thing to add, horrible idea, or very difficult. On Mon, Jul 25, 2011 at 1:50 PM, John McCall wrote: > On Jul 25, 2011, at 10:46 AM, ret val wrote: > > Only global declarations? Thats not good... > > I very clearly said "alloca instructions and global declarations". These > are the most obvious IR products corresponding to individual decls. > > John. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110725/707a10c1/attachment.html From rjmccall at apple.com Mon Jul 25 13:01:26 2011 From: rjmccall at apple.com (John McCall) Date: Mon, 25 Jul 2011 11:01:26 -0700 Subject: [cfe-dev] using CodeGenOptions::EmitDeclMetadata()? In-Reply-To: References: <1A708775-88CB-4D5A-B12E-3548EAED0AC9@apple.com> Message-ID: On Jul 25, 2011, at 10:56 AM, ret val wrote: > I was more concerned about VarDecls created inside functions and if there was any possibility of getting those. I don't know if that would be a reasonable thing to add, horrible idea, or very difficult. If you don't recognize "alloca instructions" as pertaining to local variables, I think you might be in over your head. John. From dgregor at apple.com Mon Jul 25 13:44:54 2011 From: dgregor at apple.com (Douglas Gregor) Date: Mon, 25 Jul 2011 11:44:54 -0700 Subject: [cfe-dev] [PATCH] C++0x unicode string and character literals now with test cases In-Reply-To: References: Message-ID: On Jul 24, 2011, at 10:28 PM, Craig Topper wrote: > Previous patch doesn't apply cleanly anymore so here's a new version. > > Chris or Doug, if you're reading this can I get a review as suggested by Eric? Index: lib/Sema/SemaExprCXX.cpp =================================================================== --- lib/Sema/SemaExprCXX.cpp (revision 135897) +++ lib/Sema/SemaExprCXX.cpp (working copy) @@ -2026,12 +2026,21 @@ = ToPtrType->getPointeeType()->getAs()) { // This conversion is considered only when there is an // explicit appropriate pointer target type (C++ 4.2p2). - if (!ToPtrType->getPointeeType().hasQualifiers() && - ((StrLit->isWide() && ToPointeeType->isWideCharType()) || - (!StrLit->isWide() && - (ToPointeeType->getKind() == BuiltinType::Char_U || - ToPointeeType->getKind() == BuiltinType::Char_S)))) - return true; + if (!ToPtrType->getPointeeType().hasQualifiers()) { + switch (StrLit->getKind()) { + default: assert(0 && "Unknown case"); + case StringLiteral::Ascii: + case StringLiteral::UTF8: + return (ToPointeeType->getKind() == BuiltinType::Char_U || + ToPointeeType->getKind() == BuiltinType::Char_S); + case StringLiteral::Wide: + return ToPointeeType->isWideCharType(); + case StringLiteral::UTF16: + return ToPointeeType->getKind() == BuiltinType::Char16; + case StringLiteral::UTF32: + return ToPointeeType->getKind() == BuiltinType::Char32; + } + } } This routine handles the C++98/03 deprecated string literal -> non-const character* conversion, which should not apply to the new C++0x character types. Or did I miss something in the C++0x FDIS? Also, please remove the 'default' case; it's enough that the switch statement is exhaustive. Index: lib/Sema/SemaInit.cpp =================================================================== --- lib/Sema/SemaInit.cpp (revision 135897) +++ lib/Sema/SemaInit.cpp (working copy) @@ -48,20 +48,29 @@ if (SL == 0) return 0; QualType ElemTy = Context.getCanonicalType(AT->getElementType()); - // char array can be initialized with a narrow string. - // Only allow char x[] = "foo"; not char x[] = L"foo"; - if (!SL->isWide()) + + switch (SL->getKind()) { + default: assert(0 && "Unknown string literal kind"); + case StringLiteral::Ascii: + case StringLiteral::UTF8: + // char array can be initialized with a narrow string. + // Only allow char x[] = "foo"; not char x[] = L"foo"; return ElemTy->isCharType() ? Init : 0; + case StringLiteral::UTF16: + return ElemTy->isChar16Type() ? Init : 0; + case StringLiteral::UTF32: + return ElemTy->isChar32Type() ? Init : 0; Please remove the "default" here. (And the other "default" cases when the switch statement is exhaustive). Overall, this patch is looking great to me. Once we resolve the deprecated conversion stuff, I think we'll be ready to put it in. Thanks! (and sorry for the delay) - Doug From peter at 2ndquadrant.com Mon Jul 25 13:53:21 2011 From: peter at 2ndquadrant.com (Peter Geoghegan) Date: Mon, 25 Jul 2011 19:53:21 +0100 Subject: [cfe-dev] -Warray-bounds seems over-zealous on Clang In-Reply-To: References: <20110712150748.GA4913@britannica.bec.de> <0F9FF1EB-96F2-4ACB-8070-32EFD6B23CD4@apple.com> <372E1D9D-8435-427E-9122-94A81E046187@apple.com> <09911FA8-1679-4FDA-B363-5211C44A3DDE@apple.com> <6CB2BAE3-D4D3-4299-A526-916B51FBD9D0@gmail.com> <1FFBA94C-191A-466B-90B8-EABC654736BB@gmail.com> Message-ID: Hi Chandler On 20 July 2011 10:48, Chandler Carruth wrote: > I'm planning to look at this tomorrow. Did you get a chance to look at it? It will interest some of you to know that I've created a blog post on my experiences with the Clang community, which have been very positive. The post is also a general Clang advocacy piece. It says that it was posted on Saturday, although it wasn't syndicated on planet Postgresql today and I just started blogging, so it was effectively made public 3 hours ago: http://pgeoghegan.blogspot.com/2011/07/could-clang-displace-gcc-among.html I think that the yet-to-be-published follow-up blog post, which explains some work I did in co-operation with a colleague of mine, Greg Smith, will generate a lot of interest. He is probably the world's foremost authority on PostgreSQL performance, in part because he wrote an extremely well received book on the subject. -- Peter Geoghegan ? ? ? http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services From scshunt at csclub.uwaterloo.ca Mon Jul 25 14:14:40 2011 From: scshunt at csclub.uwaterloo.ca (Sean Hunt) Date: Mon, 25 Jul 2011 12:14:40 -0700 Subject: [cfe-dev] [PATCH] C++0x unicode string and character literals now with test cases In-Reply-To: References: Message-ID: On Mon, Jul 25, 2011 at 11:44, Douglas Gregor wrote: > Also, please remove the 'default' case; it's enough that the switch statement is exhaustive. What if the value is outside the range of enumerators? This could certainly happen due to, say, a PCH bug. I would point out that we prefer llvm_unreachable for impossible cases though. In either case, there ought to be no real cost since this will all get elided in release mode. Sean From Axel.Naumann at cern.ch Mon Jul 25 14:28:17 2011 From: Axel.Naumann at cern.ch (Axel Naumann) Date: Mon, 25 Jul 2011 21:28:17 +0200 Subject: [cfe-dev] cling Message-ID: <4E2DC3D1.4000402@cern.ch> Hi, As we announced before , we (people from CERN and Fermilab) are working on the C++ interpreter(*) cling that's based on clang and llvm. This is in the context of ROOT and CINT , our current C++ interpreter. We have gotten to a stage where we believe cling is actually useful: it behaves like a regular interpreter! [cling]$ #include [cling]$ double x = std::sin(3.1) (double) 4.158066e-02 [cling]$ .L libz [cling]$ #include "zlib.h" [cling]$ zlibVersion() (const char * const) "1.2.3.4" or simply $ echo 'extern "C" const char* zlibVersion(); zlibVersion()' | cling -lz (const char * const) "1.2.3.4" and even $ cat t.cxx #include "cling/Interpreter/Interpreter.h" void t() { gCling->processLine("gCling->getVersion()"); } $ cling [cling]$ .x t.cxx (const char * const) "$Id: Interpreter.cpp 40322 2011-07-21 14:20:14Z axel $" We would like to know whether it's just us finding this spectacular :-) or whether there is general interest. Our aim is to get it included in the clang repository. For us, this is just the first step; we need to integrate it into the rest of our software wildlife here at CERN, and we need to continue to work on robustness and features, e.g. reloading of code. I.e. I expect we will maintain and continue to develop it for years to come. Here is the code: svn co http://root.cern.ch/svn/root/branches/dev/cling Let us know what you think! Best regards, the cling team (Vassil, Philippe, Paul, Lukasz and Axel). (*) Yes, it's not an interpreter, it's really an incremental compiler with an interactive shell with (eventually) features like automatic library loading and late variable binding. But it smells like an interpreter :-) From dgregor at apple.com Mon Jul 25 14:44:28 2011 From: dgregor at apple.com (Douglas Gregor) Date: Mon, 25 Jul 2011 12:44:28 -0700 Subject: [cfe-dev] [PATCH] C++0x unicode string and character literals now with test cases In-Reply-To: References: Message-ID: <387A85B6-1485-4CEE-9E99-F9DB8B20BD7E@apple.com> On Jul 25, 2011, at 12:14 PM, Sean Hunt wrote: > On Mon, Jul 25, 2011 at 11:44, Douglas Gregor wrote: >> Also, please remove the 'default' case; it's enough that the switch statement is exhaustive. > > What if the value is outside the range of enumerators? This could > certainly happen due to, say, a PCH bug. In that case, we'd find it and fix PCH. > I would point out that we > prefer llvm_unreachable for impossible cases though. In either case, > there ought to be no real cost since this will all get elided in > release mode. If you leave the 'default' case in there, it silences warnings about missing enumerators when switching on an enum type. That's Very Very Bad. - Doug From dgregor at apple.com Mon Jul 25 14:48:31 2011 From: dgregor at apple.com (Douglas Gregor) Date: Mon, 25 Jul 2011 12:48:31 -0700 Subject: [cfe-dev] Easier debugging with Visual Studio Visualizers In-Reply-To: References: Message-ID: On Jul 23, 2011, at 6:14 AM, Nikola Smiljanic wrote: > Hello everyone, I've spent the last couple of days debugging Clang and peeking inside SmallVector and Token really annoyed me so I decided to write some visualizers to make my life easier. I hope somebody else finds this useful and if you have any ideas about other types that should be supported just ask and I'll try to add them. > > There are two ways to make this work: > > 1. Put the path to clangVisualizer.txt in the environmental variable called _vcee_autoexp and restart your Visual Studio. This method should work for Visual Studio 2008 and 2010 and is less invasive. > 2. Copy everything except the [Visualizer] tag from clangVisualizers.txt to C:\Program Files\Microsoft Visual Studio 10.0\Common7\Packages\Debugger\autoexp.dat. Make sure you backup your original autoexp.dat first. This should work for Visual Studio 2005 and above. Cool. Could you turn these instructions into a patch against http://clang.llvm.org/hacking.html#debugging ? I'd like for this to go into the Clang tree so everyone can get to it, but we need documentation for people to find it. - Doug From dgregor at apple.com Mon Jul 25 14:50:01 2011 From: dgregor at apple.com (Douglas Gregor) Date: Mon, 25 Jul 2011 12:50:01 -0700 Subject: [cfe-dev] return statements without expressions in non-void functions revisited In-Reply-To: <20110716005634.GA23585@bromo.med.uc.edu> References: <20110716005634.GA23585@bromo.med.uc.edu> Message-ID: On Jul 15, 2011, at 5:56 PM, Jack Howarth wrote: > In porting texlive under clang for fink, we have run into the same issue from this thread... > > http://comments.gmane.org/gmane.comp.compilers.clang.devel/10688 > > In that thread it was suggested that -std=c89 might be modified to convert the error into > a warning for... > > [MacPro:~] howarth% clang -std=gnu89 -c type1_test.c -fno-strict-aliasing > type1_test.c:24:8: error: non-void function 'PSFakePop' should return a value [-Wreturn-type] > else Error0("PSFakePop: Stack empty\n"); > ^ > type1_test.c:13:54: note: instantiated from: > #define Error0(errmsg) { CC; IfTrace0(TRUE, errmsg); Error;} > ^ > type1_test.c:11:32: note: instantiated from: > #define Error {errflag = TRUE; return;} > ^ > 1 error generated. > > This appears to never have been implemented however. Any suggestions on the best approach to > revise the following testcase to avoid the error under clang (which I also see under icc > but not gcc trunk even with -std=c90)? The flag -Wno-error=return-type will downgrade this error to a warning. -Wno-return-type will turn off the warning/error entirely. - Doug From gvenn.cfe.dev at gmail.com Mon Jul 25 14:59:06 2011 From: gvenn.cfe.dev at gmail.com (Garrison Venn) Date: Mon, 25 Jul 2011 15:59:06 -0400 Subject: [cfe-dev] cling In-Reply-To: <4E2DC3D1.4000402@cern.ch> References: <4E2DC3D1.4000402@cern.ch> Message-ID: <43861DF5-250D-444C-BE9C-51E53D6B3F18@gmail.com> I think this is very cool! So how well will it scale? For example can we use it to run on/with LLVM/Clang source? Sorry I have only briefly read through your links. Keep it up Garrison On Jul 25, 2011, at 15:28, Axel Naumann wrote: > Hi, > > As we announced before > , we (people from > CERN and Fermilab) are working on the C++ interpreter(*) cling > that's based on clang and llvm. This is in the > context of ROOT and CINT > , our current C++ interpreter. > > We have gotten to a stage where we believe cling is actually useful: it > behaves like a regular interpreter! > > [cling]$ #include > [cling]$ double x = std::sin(3.1) > (double) 4.158066e-02 > [cling]$ .L libz > [cling]$ #include "zlib.h" > [cling]$ zlibVersion() > (const char * const) "1.2.3.4" > > or simply > > $ echo 'extern "C" const char* zlibVersion(); > zlibVersion()' | cling -lz > > (const char * const) "1.2.3.4" > > and even > > $ cat t.cxx > #include "cling/Interpreter/Interpreter.h" > void t() { > gCling->processLine("gCling->getVersion()"); > } > $ cling > [cling]$ .x t.cxx > (const char * const) "$Id: Interpreter.cpp 40322 2011-07-21 14:20:14Z > axel $" > > We would like to know whether it's just us finding this spectacular :-) > or whether there is general interest. Our aim is to get it included in > the clang repository. > > For us, this is just the first step; we need to integrate it into the > rest of our software wildlife here at CERN, and we need to continue to > work on robustness and features, e.g. reloading of code. I.e. I expect > we will maintain and continue to develop it for years to come. > > Here is the code: > svn co http://root.cern.ch/svn/root/branches/dev/cling > > Let us know what you think! > > Best regards, > the cling team (Vassil, Philippe, Paul, Lukasz and Axel). > > (*) Yes, it's not an interpreter, it's really an incremental compiler > with an interactive shell with (eventually) features like automatic > library loading and late variable binding. But it smells like an > interpreter :-) > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From george at codeplay.com Mon Jul 25 15:23:08 2011 From: george at codeplay.com (George Russell) Date: Mon, 25 Jul 2011 22:23:08 +0200 Subject: [cfe-dev] Criteria for Accepting Language Extensions into Clang In-Reply-To: <46FA9918-1E7D-4DCF-938F-1910127F1FC8@apple.com> References: <46FA9918-1E7D-4DCF-938F-1910127F1FC8@apple.com> Message-ID: <4E2DD0AC.6090506@codeplay.com> Hi, I have implemented a small language extension to C++, which motivates my interest in Clang + language extensions (https://bitbucket.org/grrussel/constcpp/wiki/Home) - which I would like to make available to a wider user base (if there is, in fact, interest in it) without being required to myself replicate the Clang / LLVM projects packaging work. On 21/07/2011 19:40, Douglas Gregor wrote: > Clang has always been designed as a platform for experimentation, and my hope is that Clang will be the premier vehicle for innovation in the C family of languages, establishing existing practice for the various standards committees. Sooner or later, the successful experiments will become proposed extensions for Clang, at which point we either fully commit to the extension--adding it into the tree and supporting it for many years ahead--or we must decide that the extension is not suitable for inclusion in Clang at this time. To aid in that decision, I propose the following seven criteria: > I wonder if there is any potential for what I have seen in LLVM - e.g. back-ends that are marked as unsupported, experimental; or of features / extensions being dropped if there is not an active maintainer. In other words, does inclusion necessarily require the unambiguous commitment to future support? Is there any potential for features explicitly marked as experimental and with the potential for future changes (including loss of backwards compatibility) and which could, at the discretion of core developers, simply be dropped between releases? > 1) Evidence of a significant user community: This is based on a number of factors, including an actual, existing user community, the perceived likelihood that users would adopt such a feature if it were available, and any "trickle-down" effects that come from, e.g., a library adopting the feature and providing benefits to its users. One motivation for getting an extension into Clang / LLVM is the ability to attract a larger community of users - it would be very easy to say, if you want to try "language extension X" it is available in some given Clang release for the range of platforms and targets it supports, as opposed to saying a) build it yourself, to a potential user or b) building + distributing the equivalent to a Clang / LLVM release yourself. > 2) A specific need to reside within the Clang tree: There are some extensions that would be better expressed as a separate tool, and should remain as separate tools even if they end up being hosted as part of the LLVM umbrella project. > In my case, I didn't see an existing mechanism to plug in the changes I wanted to make, short of directly changing the code. The changes are however, quite small; a pair of pragmas, a new language option, some additional changes in Sema etc executed only if enabled explicitly on the command line or via a pragma. > 4) Representation within the appropriate governing organization: For extensions to a language governed by a standards committee (C, C++, OpenCL), the extension itself must have an active proposal and proponent within that committee and have a reasonable chance of acceptance. Clang should drive the standard, not diverge from it. Is there any potential for an extension that is not intended to become a feature of language X version current + 1? I am aware of several extensions to various languages not intended to be such. > 6) A high-quality implementation: Naturally, the implementation must fit well into Clang's architecture, follow LLVM's coding conventions, and meet Clang's quality standards, including high-quality diagnostics and rich AST representations. This is particularly important for language extensions, because users will learn how those extensions work through the behavior of the compiler. > Yes; I would not argue that my extension is of such a quality, being at present a proof of concept; Is there scope for an incremental process where implemented extensions that the implementer desires to be merged could be reviewed, to allow feedback from the core developers of Clang etc to increase the quality of the implementation? Regards, George Russell From Axel.Naumann at cern.ch Mon Jul 25 15:33:21 2011 From: Axel.Naumann at cern.ch (Axel Naumann) Date: Mon, 25 Jul 2011 22:33:21 +0200 Subject: [cfe-dev] cling In-Reply-To: <43861DF5-250D-444C-BE9C-51E53D6B3F18@gmail.com> References: <4E2DC3D1.4000402@cern.ch> <43861DF5-250D-444C-BE9C-51E53D6B3F18@gmail.com> Message-ID: <4E2DD311.2020307@cern.ch> Hi Garrison, On 07/25/2011 09:59 PM, Garrison Venn wrote: > I think this is very cool! Thanks :-) > So how well will it scale? For example can we use it to run on/with LLVM/Clang > source? It scales like a traditional translation unit. I.e. I wouldn't #include all of clang's sources but pull clang in through shared libraries and headers. As the example I sent shows, cling can load and reference shared libs. Cheers, Axel. > > On Jul 25, 2011, at 15:28, Axel Naumann wrote: > >> Hi, >> >> As we announced before >> , we (people from >> CERN and Fermilab) are working on the C++ interpreter(*) cling >> that's based on clang and llvm. This is in the >> context of ROOT and CINT >> , our current C++ interpreter. >> >> We have gotten to a stage where we believe cling is actually useful: it >> behaves like a regular interpreter! >> >> [cling]$ #include >> [cling]$ double x = std::sin(3.1) >> (double) 4.158066e-02 >> [cling]$ .L libz >> [cling]$ #include "zlib.h" >> [cling]$ zlibVersion() >> (const char * const) "1.2.3.4" >> >> or simply >> >> $ echo 'extern "C" const char* zlibVersion(); >> zlibVersion()' | cling -lz >> >> (const char * const) "1.2.3.4" >> >> and even >> >> $ cat t.cxx >> #include "cling/Interpreter/Interpreter.h" >> void t() { >> gCling->processLine("gCling->getVersion()"); >> } >> $ cling >> [cling]$ .x t.cxx >> (const char * const) "$Id: Interpreter.cpp 40322 2011-07-21 14:20:14Z >> axel $" >> >> We would like to know whether it's just us finding this spectacular :-) >> or whether there is general interest. Our aim is to get it included in >> the clang repository. >> >> For us, this is just the first step; we need to integrate it into the >> rest of our software wildlife here at CERN, and we need to continue to >> work on robustness and features, e.g. reloading of code. I.e. I expect >> we will maintain and continue to develop it for years to come. >> >> Here is the code: >> svn co http://root.cern.ch/svn/root/branches/dev/cling >> >> Let us know what you think! >> >> Best regards, >> the cling team (Vassil, Philippe, Paul, Lukasz and Axel). >> >> (*) Yes, it's not an interpreter, it's really an incremental compiler >> with an interactive shell with (eventually) features like automatic >> library loading and late variable binding. But it smells like an >> interpreter :-) >> _______________________________________________ >> cfe-dev mailing list >> cfe-dev at cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > > From gvenn.cfe.dev at gmail.com Mon Jul 25 15:38:59 2011 From: gvenn.cfe.dev at gmail.com (Garrison Venn) Date: Mon, 25 Jul 2011 16:38:59 -0400 Subject: [cfe-dev] cling In-Reply-To: <4E2DD311.2020307@cern.ch> References: <4E2DC3D1.4000402@cern.ch> <43861DF5-250D-444C-BE9C-51E53D6B3F18@gmail.com> <4E2DD311.2020307@cern.ch> Message-ID: I'll definitely have to check this out! Thanks for the work Garrison On Jul 25, 2011, at 16:33, Axel Naumann wrote: > Hi Garrison, > > On 07/25/2011 09:59 PM, Garrison Venn wrote: >> I think this is very cool! > > Thanks :-) > >> So how well will it scale? For example can we use it to run on/with LLVM/Clang >> source? > > It scales like a traditional translation unit. I.e. I wouldn't #include > all of clang's sources but pull clang in through shared libraries and > headers. As the example I sent shows, cling can load and reference > shared libs. > > Cheers, Axel. > > >> >> On Jul 25, 2011, at 15:28, Axel Naumann wrote: >> >>> Hi, >>> >>> As we announced before >>> , we (people from >>> CERN and Fermilab) are working on the C++ interpreter(*) cling >>> that's based on clang and llvm. This is in the >>> context of ROOT and CINT >>> , our current C++ interpreter. >>> >>> We have gotten to a stage where we believe cling is actually useful: it >>> behaves like a regular interpreter! >>> >>> [cling]$ #include >>> [cling]$ double x = std::sin(3.1) >>> (double) 4.158066e-02 >>> [cling]$ .L libz >>> [cling]$ #include "zlib.h" >>> [cling]$ zlibVersion() >>> (const char * const) "1.2.3.4" >>> >>> or simply >>> >>> $ echo 'extern "C" const char* zlibVersion(); >>> zlibVersion()' | cling -lz >>> >>> (const char * const) "1.2.3.4" >>> >>> and even >>> >>> $ cat t.cxx >>> #include "cling/Interpreter/Interpreter.h" >>> void t() { >>> gCling->processLine("gCling->getVersion()"); >>> } >>> $ cling >>> [cling]$ .x t.cxx >>> (const char * const) "$Id: Interpreter.cpp 40322 2011-07-21 14:20:14Z >>> axel $" >>> >>> We would like to know whether it's just us finding this spectacular :-) >>> or whether there is general interest. Our aim is to get it included in >>> the clang repository. >>> >>> For us, this is just the first step; we need to integrate it into the >>> rest of our software wildlife here at CERN, and we need to continue to >>> work on robustness and features, e.g. reloading of code. I.e. I expect >>> we will maintain and continue to develop it for years to come. >>> >>> Here is the code: >>> svn co http://root.cern.ch/svn/root/branches/dev/cling >>> >>> Let us know what you think! >>> >>> Best regards, >>> the cling team (Vassil, Philippe, Paul, Lukasz and Axel). >>> >>> (*) Yes, it's not an interpreter, it's really an incremental compiler >>> with an interactive shell with (eventually) features like automatic >>> library loading and late variable binding. But it smells like an >>> interpreter :-) >>> _______________________________________________ >>> cfe-dev mailing list >>> cfe-dev at cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev >> >> > From howarth at bromo.med.uc.edu Mon Jul 25 16:09:18 2011 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Mon, 25 Jul 2011 17:09:18 -0400 Subject: [cfe-dev] return statements without expressions in non-void functions revisited In-Reply-To: References: <20110716005634.GA23585@bromo.med.uc.edu> Message-ID: <20110725210918.GA23666@bromo.med.uc.edu> On Mon, Jul 25, 2011 at 12:50:01PM -0700, Douglas Gregor wrote: > > On Jul 15, 2011, at 5:56 PM, Jack Howarth wrote: > > > In porting texlive under clang for fink, we have run into the same issue from this thread... > > > > http://comments.gmane.org/gmane.comp.compilers.clang.devel/10688 > > > > In that thread it was suggested that -std=c89 might be modified to convert the error into > > a warning for... > > > > [MacPro:~] howarth% clang -std=gnu89 -c type1_test.c -fno-strict-aliasing > > type1_test.c:24:8: error: non-void function 'PSFakePop' should return a value [-Wreturn-type] > > else Error0("PSFakePop: Stack empty\n"); > > ^ > > type1_test.c:13:54: note: instantiated from: > > #define Error0(errmsg) { CC; IfTrace0(TRUE, errmsg); Error;} > > ^ > > type1_test.c:11:32: note: instantiated from: > > #define Error {errflag = TRUE; return;} > > ^ > > 1 error generated. > > > > This appears to never have been implemented however. Any suggestions on the best approach to > > revise the following testcase to avoid the error under clang (which I also see under icc > > but not gcc trunk even with -std=c90)? > > The flag -Wno-error=return-type will downgrade this error to a warning. -Wno-return-type will turn off the warning/error entirely. > > - Doug Doug, Is there any documentation of the full set of warnings which are treated as errors that can be suppressed with -Wno-error in this manner? Jack From eli.friedman at gmail.com Mon Jul 25 16:52:18 2011 From: eli.friedman at gmail.com (Eli Friedman) Date: Mon, 25 Jul 2011 14:52:18 -0700 Subject: [cfe-dev] return statements without expressions in non-void functions revisited In-Reply-To: <20110725210918.GA23666@bromo.med.uc.edu> References: <20110716005634.GA23585@bromo.med.uc.edu> <20110725210918.GA23666@bromo.med.uc.edu> Message-ID: On Mon, Jul 25, 2011 at 2:09 PM, Jack Howarth wrote: > On Mon, Jul 25, 2011 at 12:50:01PM -0700, Douglas Gregor wrote: >> >> On Jul 15, 2011, at 5:56 PM, Jack Howarth wrote: >> >> > ? In porting texlive under clang for fink, we have run into the same issue from this thread... >> > >> > http://comments.gmane.org/gmane.comp.compilers.clang.devel/10688 >> > >> > In that thread it was suggested that -std=c89 might be modified to convert the error into >> > a warning for... >> > >> > [MacPro:~] howarth% clang -std=gnu89 -c type1_test.c -fno-strict-aliasing >> > type1_test.c:24:8: error: non-void function 'PSFakePop' should return a value [-Wreturn-type] >> > ?else Error0("PSFakePop: Stack empty\n"); >> > ? ? ? ^ >> > type1_test.c:13:54: note: instantiated from: >> > #define Error0(errmsg) { CC; IfTrace0(TRUE, errmsg); Error;} >> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ^ >> > type1_test.c:11:32: note: instantiated from: >> > #define Error {errflag = TRUE; return;} >> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ^ >> > 1 error generated. >> > >> > This appears to never have been implemented however. Any suggestions on the best approach to >> > revise the following testcase to avoid the error under clang (which I also see under icc >> > but not gcc trunk even with -std=c90)? >> >> The flag -Wno-error=return-type will downgrade this error to a warning. -Wno-return-type will turn off the warning/error entirely. >> >> ? ? ? - Doug > > Doug, > ? Is there any documentation of the full set of warnings which are treated > as errors that can be suppressed with -Wno-error in this manner? There isn't a complete list anywhere (outside the source), but if you're seeing some particular warning, and there is such a flag, it will be listed after the warning (like -Wreturn-type is listed in the given example). -Eli From dgregor at apple.com Mon Jul 25 16:57:16 2011 From: dgregor at apple.com (Douglas Gregor) Date: Mon, 25 Jul 2011 14:57:16 -0700 Subject: [cfe-dev] return statements without expressions in non-void functions revisited In-Reply-To: <20110725210918.GA23666@bromo.med.uc.edu> References: <20110716005634.GA23585@bromo.med.uc.edu> <20110725210918.GA23666@bromo.med.uc.edu> Message-ID: Sent from my iPhone On Jul 25, 2011, at 2:09 PM, Jack Howarth wrote: > On Mon, Jul 25, 2011 at 12:50:01PM -0700, Douglas Gregor wrote: >> >> On Jul 15, 2011, at 5:56 PM, Jack Howarth wrote: >> >>> In porting texlive under clang for fink, we have run into the same issue from this thread... >>> >>> http://comments.gmane.org/gmane.comp.compilers.clang.devel/10688 >>> >>> In that thread it was suggested that -std=c89 might be modified to convert the error into >>> a warning for... >>> >>> [MacPro:~] howarth% clang -std=gnu89 -c type1_test.c -fno-strict-aliasing >>> type1_test.c:24:8: error: non-void function 'PSFakePop' should return a value [-Wreturn-type] >>> else Error0("PSFakePop: Stack empty\n"); >>> ^ >>> type1_test.c:13:54: note: instantiated from: >>> #define Error0(errmsg) { CC; IfTrace0(TRUE, errmsg); Error;} >>> ^ >>> type1_test.c:11:32: note: instantiated from: >>> #define Error {errflag = TRUE; return;} >>> ^ >>> 1 error generated. >>> >>> This appears to never have been implemented however. Any suggestions on the best approach to >>> revise the following testcase to avoid the error under clang (which I also see under icc >>> but not gcc trunk even with -std=c90)? >> >> The flag -Wno-error=return-type will downgrade this error to a warning. -Wno-return-type will turn off the warning/error entirely. >> >> - Doug > > Doug, > Is there any documentation of the full set of warnings which are treated > as errors that can be suppressed with -Wno-error in this manner? No documentation per se. However, every warning/error that is remappable displays the corresponding flag as part of the diagnostic. Note the [-Wreturn-type] in the diagnostic you pasted. -Doug From cedric.teyton at gmail.com Mon Jul 25 17:25:21 2011 From: cedric.teyton at gmail.com (Cedric Teyton) Date: Tue, 26 Jul 2011 00:25:21 +0200 Subject: [cfe-dev] Weird error during Clang execution Message-ID: Hi everybody, I'm new with clang as i'm using it for few days only. I did set up llvm and clang 2.9 and when i used clang command for analyze c++ files it worked almost correctly (since i had bugs but related to my machine i think). I took recent versions of llvm and clang on SVN repository. And now it does not work, and here are the errors i obtain when i attempt an analysis on a file called "list.cpp": 0 clang 0x0a308fd6 1 clang 0x0a308d63 2 0x0023d400 __kernel_sigreturn + 0 3 clang 0x08d2c54f clang::FrontendAction::BeginSourceFile(clang::CompilerInstance&, llvm::StringRef, clang::InputKind) + 1329 4 clang 0x08d14930 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 758 5 clang 0x08cbbf52 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 835 6 clang 0x08cadd45 cc1_main(char const**, char const**, char const*, void*) + 1014 7 clang 0x08cb7a33 main + 521 8 libc.so.6 0x00764e37 __libc_start_main + 231 9 clang 0x08cad421 Stack dump: 0. Program arguments: /home/cedric/llvm/Debug+Asserts/bin/clang -cc1 -triple i386-pc-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name list.cpp -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu pentium4 -target-linker-version 2.21 -momit-leaf-frame-pointer -resource-dir /home/cedric/llvm/Debug+Asserts/bin/../lib/clang/3.0 -fdeprecated-macro -ferror-limit 19 -fmessage-length 168 -fgnu-runtime -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -load /home/cedric/dxr/dxr-clang/xref-tools/cxx-clang/libclang-index-plugin.so -add-plugin dxr-index -plugin-arg-dxr-index ../CodeCPP/ -o /tmp/cc-00ZhSs.o -x c++ list.cpp clang: error: unable to execute command: Segmentation fault clang: error: clang frontend command failed due to signal 2 (use -v to see invocation) --> Anybody can say something about it ? I don't really get what occurs there. thank you. Regards, C?dric Teyton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110726/408dabb5/attachment-0001.html From jediknil at belkadan.com Mon Jul 25 18:03:06 2011 From: jediknil at belkadan.com (Jordy Rose) Date: Mon, 25 Jul 2011 16:03:06 -0700 Subject: [cfe-dev] Using custom Clang builds in Xcode Message-ID: In case anyone's interested, I just wrote a blog post on how to add a custom Clang build as a compiler in Xcode. http://belkadan.com/blog/2011/07/Using-Clang-from-SVN-in-Xcode/ Note that this is not the same as using a custom *analyzer*. For that, you still want to use the set-xcode-analyzer script in tools/scan-build. The two procedures are orthogonal. Best, Jordy From johnw at boostpro.com Mon Jul 25 18:56:33 2011 From: johnw at boostpro.com (John Wiegley) Date: Mon, 25 Jul 2011 18:56:33 -0500 Subject: [cfe-dev] Win7 VS2008/2010 builds are broken Message-ID: Hello, I'm building the current Git version using Windows 7 x64, and both Visual Studio 2008 and 2010. The commits I'm building are: LLVM 3ef750d Clang 822f54a With Visual Studio 2008, Clang builds, but it fails 100 tests, all in the "test/Index" directory. With Visual Studio 2010, Clang fails to build with this error: Build FAILED. "C:\build\llvm\tools\clang\test\clang-test.vcxproj" (default target) (1) -> "C:\build\llvm\tools\clang\test\clang-test.deps.vcxproj" (default target) (3) - > "C:\build\llvm\tools\clang\tools\c-arcmt-test\c-arcmt-test.vcxproj" (default ta rget) (44) -> "C:\build\llvm\tools\clang\tools\libclang\libclang.vcxproj" (default target) (4 5) -> (ClCompile target) -> ..\..\..\..\..\..\src\llvm\tools\clang\tools\libclang\CIndex.cpp(4261): error C2526: 'buildPieces' : C linkage function cannot return C++ class 'llvm::Small Vector' [C:\build\llvm\tools\clang\tools\libclang\libclang.vcxproj] ..\..\..\..\..\..\src\llvm\tools\clang\tools\libclang\CIndex.cpp(4293): error C2562: '`anonymous-namespace'::buildPieces' : 'void' function returning a valu e [C:\build\llvm\tools\clang\tools\libclang\libclang.vcxproj] ..\..\..\..\..\..\src\llvm\tools\clang\tools\libclang\CIndex.cpp(4305): error C2679: binary '=' : no operator found which takes a right-hand operand of type 'void' (or there is no acceptable conversion) [C:\build\llvm\tools\clang\tools \libclang\libclang.vcxproj] ..\..\..\..\..\..\src\llvm\tools\clang\tools\libclang\CIndex.cpp(4312): error C2679: binary '=' : no operator found which takes a right-hand operand of type 'void' (or there is no acceptable conversion) [C:\build\llvm\tools\clang\tools \libclang\libclang.vcxproj] ..\..\..\..\..\..\src\llvm\tools\clang\tools\libclang\CIndex.cpp(4324): error C2679: binary '=' : no operator found which takes a right-hand operand of type 'void' (or there is no acceptable conversion) [C:\build\llvm\tools\clang\tools \libclang\libclang.vcxproj] 0 Warning(s) 5 Error(s) I'm posting this to see if others are aware of this problem, as it happened sometime between today and July 22nd. Thanks, John From pichet2000 at gmail.com Mon Jul 25 20:10:16 2011 From: pichet2000 at gmail.com (Francois Pichet) Date: Mon, 25 Jul 2011 21:10:16 -0400 Subject: [cfe-dev] Win7 VS2008/2010 builds are broken In-Reply-To: References: Message-ID: On Mon, Jul 25, 2011 at 7:56 PM, John Wiegley wrote: > Hello, > > I'm building the current Git version using Windows 7 x64, and both Visual > Studio 2008 and 2010. ?The commits I'm building are: > > ?LLVM ?3ef750d > ?Clang 822f54a > > With Visual Studio 2008, Clang builds, but it fails 100 tests, all in the > "test/Index" directory. > > With Visual Studio 2010, Clang fails to build with this error: > > Build FAILED. > > "C:\build\llvm\tools\clang\test\clang-test.vcxproj" (default target) (1) -> > "C:\build\llvm\tools\clang\test\clang-test.deps.vcxproj" (default target) (3) - >> > "C:\build\llvm\tools\clang\tools\c-arcmt-test\c-arcmt-test.vcxproj" (default ta > rget) (44) -> > "C:\build\llvm\tools\clang\tools\libclang\libclang.vcxproj" (default target) (4 > 5) -> > (ClCompile target) -> > ?..\..\..\..\..\..\src\llvm\tools\clang\tools\libclang\CIndex.cpp(4261): error > ?C2526: 'buildPieces' : C linkage function cannot return C++ class 'llvm::Small > Vector' [C:\build\llvm\tools\clang\tools\libclang\libclang.vcxproj] > ?..\..\..\..\..\..\src\llvm\tools\clang\tools\libclang\CIndex.cpp(4293): error > ?C2562: '`anonymous-namespace'::buildPieces' : 'void' function returning a valu > e [C:\build\llvm\tools\clang\tools\libclang\libclang.vcxproj] > ?..\..\..\..\..\..\src\llvm\tools\clang\tools\libclang\CIndex.cpp(4305): error > ?C2679: binary '=' : no operator found which takes a right-hand operand of type > ?'void' (or there is no acceptable conversion) [C:\build\llvm\tools\clang\tools > \libclang\libclang.vcxproj] > ?..\..\..\..\..\..\src\llvm\tools\clang\tools\libclang\CIndex.cpp(4312): error > ?C2679: binary '=' : no operator found which takes a right-hand operand of type > ?'void' (or there is no acceptable conversion) [C:\build\llvm\tools\clang\tools > \libclang\libclang.vcxproj] > ?..\..\..\..\..\..\src\llvm\tools\clang\tools\libclang\CIndex.cpp(4324): error > ?C2679: binary '=' : no operator found which takes a right-hand operand of type > ?'void' (or there is no acceptable conversion) [C:\build\llvm\tools\clang\tools > \libclang\libclang.vcxproj] > > ? ?0 Warning(s) > ? ?5 Error(s) > > I'm posting this to see if others are aware of this problem, as it happened > sometime between today and July 22nd. For VS 2010 compile error, try to update svn. For VS 2008 I don't know what is wrong. From craig.topper at gmail.com Mon Jul 25 20:36:52 2011 From: craig.topper at gmail.com (Craig Topper) Date: Mon, 25 Jul 2011 18:36:52 -0700 Subject: [cfe-dev] [PATCH] C++0x unicode string and character literals now with test cases In-Reply-To: <387A85B6-1485-4CEE-9E99-F9DB8B20BD7E@apple.com> References: <387A85B6-1485-4CEE-9E99-F9DB8B20BD7E@apple.com> Message-ID: As far as the const conversion for the new string literal types, gcc 4.5.2 allows it and throws a warning. Looks like the standard may consider these cases to be illegal now instead of deprecated for even the old cases. Google found this page which documents discussion on this topic. Look for "693. New string types and deprecated conversion " http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3007.html ~Craig On Mon, Jul 25, 2011 at 12:44 PM, Douglas Gregor wrote: > > On Jul 25, 2011, at 12:14 PM, Sean Hunt wrote: > >> On Mon, Jul 25, 2011 at 11:44, Douglas Gregor wrote: >>> Also, please remove the 'default' case; it's enough that the switch statement is exhaustive. >> >> What if the value is outside the range of enumerators? This could >> certainly happen due to, say, a PCH bug. > > In that case, we'd find it and fix PCH. > >> I would point out that we >> prefer llvm_unreachable for impossible cases though. In either case, >> there ought to be no real cost since this will all get elided in >> release mode. > > > If you leave the 'default' case in there, it silences warnings about missing enumerators when switching on an enum type. That's Very Very Bad. > > ? ? ? ?- Doug > From scshunt at csclub.uwaterloo.ca Mon Jul 25 20:45:21 2011 From: scshunt at csclub.uwaterloo.ca (Sean Hunt) Date: Mon, 25 Jul 2011 18:45:21 -0700 Subject: [cfe-dev] [PATCH] C++0x unicode string and character literals now with test cases In-Reply-To: References: <387A85B6-1485-4CEE-9E99-F9DB8B20BD7E@apple.com> Message-ID: On Mon, Jul 25, 2011 at 18:36, Craig Topper wrote: > As far as the const conversion for the new string literal types, gcc > 4.5.2 allows it and throws a warning. Looks like the standard may > consider these cases to be illegal now instead of deprecated for even > the old cases. > > Google found this page which documents discussion on this topic. Look > for "693. New string types and deprecated conversion " > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3007.html > > ~Craig I think we should follow the CWG's direction here. The reason it was not added, even as a deprecated conversion, was to avoid people relying on a brand new deprecated conversion which would make it more difficult to remove later when it could have been nipped in the bud. So for consistency, the deprecated conversion for char* was removed. In my opinion, given that the committee decided on this specific issue, we should follow the committee's direction and reject this conversion, certainly for the new types but probably char* as well given the committee's explicit decision in that regard (and update the compatibility docs). Sean From craig.topper at gmail.com Mon Jul 25 20:55:55 2011 From: craig.topper at gmail.com (Craig Topper) Date: Mon, 25 Jul 2011 18:55:55 -0700 Subject: [cfe-dev] [PATCH] C++0x unicode string and character literals now with test cases In-Reply-To: References: <387A85B6-1485-4CEE-9E99-F9DB8B20BD7E@apple.com> Message-ID: Ok. I'll remove the conversions I added. Once this patch is in I'll submit something separate for removing the old conversions. ~Craig On Mon, Jul 25, 2011 at 6:45 PM, Sean Hunt wrote: > On Mon, Jul 25, 2011 at 18:36, Craig Topper wrote: >> As far as the const conversion for the new string literal types, gcc >> 4.5.2 allows it and throws a warning. Looks like the standard may >> consider these cases to be illegal now instead of deprecated for even >> the old cases. >> >> Google found this page which documents discussion on this topic. Look >> for "693. New string types and deprecated conversion " >> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3007.html >> >> ~Craig > > I think we should follow the CWG's direction here. The reason it was > not added, even as a deprecated conversion, was to avoid people > relying on a brand new deprecated conversion which would make it more > difficult to remove later when it could have been nipped in the bud. > So for consistency, the deprecated conversion for char* was removed. > In my opinion, given that the committee decided on this specific > issue, we should follow the committee's direction and reject this > conversion, certainly for the new types but probably char* as well > given the committee's explicit decision in that regard (and update the > compatibility docs). > > Sean > From dgregor at apple.com Mon Jul 25 23:16:03 2011 From: dgregor at apple.com (Douglas Gregor) Date: Mon, 25 Jul 2011 21:16:03 -0700 Subject: [cfe-dev] [PATCH] C++0x unicode string and character literals now with test cases In-Reply-To: References: <387A85B6-1485-4CEE-9E99-F9DB8B20BD7E@apple.com> Message-ID: <394914D2-D194-4778-A246-8F913CD37E7B@apple.com> On Jul 25, 2011, at 6:45 PM, Sean Hunt wrote: > On Mon, Jul 25, 2011 at 18:36, Craig Topper wrote: >> As far as the const conversion for the new string literal types, gcc >> 4.5.2 allows it and throws a warning. Looks like the standard may >> consider these cases to be illegal now instead of deprecated for even >> the old cases. >> >> Google found this page which documents discussion on this topic. Look >> for "693. New string types and deprecated conversion " >> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3007.html >> >> ~Craig > > I think we should follow the CWG's direction here. The reason it was > not added, even as a deprecated conversion, was to avoid people > relying on a brand new deprecated conversion which would make it more > difficult to remove later when it could have been nipped in the bud. > So for consistency, the deprecated conversion for char* was removed. > In my opinion, given that the committee decided on this specific > issue, we should follow the committee's direction and reject this > conversion, certainly for the new types but probably char* as well > given the committee's explicit decision in that regard (and update the > compatibility docs). I have a sinking feeling that rejecting the string literal to char* conversion is going to break a lot of existing code. We'll have to do it eventually, but we'll need *excellent* recovery when we do. - Doug From craig.topper at gmail.com Mon Jul 25 23:43:10 2011 From: craig.topper at gmail.com (Craig Topper) Date: Mon, 25 Jul 2011 21:43:10 -0700 Subject: [cfe-dev] [PATCH] C++0x unicode string and character literals now with test cases In-Reply-To: <394914D2-D194-4778-A246-8F913CD37E7B@apple.com> References: <387A85B6-1485-4CEE-9E99-F9DB8B20BD7E@apple.com> <394914D2-D194-4778-A246-8F913CD37E7B@apple.com> Message-ID: Ok I've removed the defaults that I could and removed the implicit const conversion stuff. ~Craig On Mon, Jul 25, 2011 at 9:16 PM, Douglas Gregor wrote: > > On Jul 25, 2011, at 6:45 PM, Sean Hunt wrote: > >> On Mon, Jul 25, 2011 at 18:36, Craig Topper wrote: >>> As far as the const conversion for the new string literal types, gcc >>> 4.5.2 allows it and throws a warning. Looks like the standard may >>> consider these cases to be illegal now instead of deprecated for even >>> the old cases. >>> >>> Google found this page which documents discussion on this topic. Look >>> for "693. New string types and deprecated conversion " >>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3007.html >>> >>> ~Craig >> >> I think we should follow the CWG's direction here. The reason it was >> not added, even as a deprecated conversion, was to avoid people >> relying on a brand new deprecated conversion which would make it more >> difficult to remove later when it could have been nipped in the bud. >> So for consistency, the deprecated conversion for char* was removed. >> In my opinion, given that the committee decided on this specific >> issue, we should follow the committee's direction and reject this >> conversion, certainly for the new types but probably char* as well >> given the committee's explicit decision in that regard (and update the >> compatibility docs). > > > I have a sinking feeling that rejecting the string literal to char* conversion is going to break a lot of existing code. We'll have to do it eventually, but we'll need *excellent* recovery when we do. > > ? ? ? ?- Doug -------------- next part -------------- A non-text attachment was scrubbed... Name: unicode_strings.patch Type: application/octet-stream Size: 78890 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110725/4046a5b4/attachment-0001.obj From dgregor at apple.com Tue Jul 26 00:07:36 2011 From: dgregor at apple.com (Douglas Gregor) Date: Mon, 25 Jul 2011 22:07:36 -0700 Subject: [cfe-dev] Criteria for Accepting Language Extensions into Clang In-Reply-To: <4E2DD0AC.6090506@codeplay.com> References: <46FA9918-1E7D-4DCF-938F-1910127F1FC8@apple.com> <4E2DD0AC.6090506@codeplay.com> Message-ID: On Jul 25, 2011, at 1:23 PM, George Russell wrote: > Hi, > > I have implemented a small language extension to C++, which motivates my > interest in Clang + language extensions > (https://bitbucket.org/grrussel/constcpp/wiki/Home) - which I would like > to make available to a wider user base (if there is, in fact, interest > in it) without being required to myself replicate the Clang / LLVM > projects packaging work. > > On 21/07/2011 19:40, Douglas Gregor wrote: >> Clang has always been designed as a platform for experimentation, and my hope is that Clang will be the premier vehicle for innovation in the C family of languages, establishing existing practice for the various standards committees. Sooner or later, the successful experiments will become proposed extensions for Clang, at which point we either fully commit to the extension--adding it into the tree and supporting it for many years ahead--or we must decide that the extension is not suitable for inclusion in Clang at this time. To aid in that decision, I propose the following seven criteria: >> > I wonder if there is any potential for what I have seen in LLVM - e.g. > back-ends that are marked as unsupported, experimental; or of features / > extensions being dropped if there is not an active maintainer. This works extremely well when the code is isolated. In LLVM land, for example, we can easily just delete an unmaintained back-end. Moreover, it's far simpler to communicate this to users: "there is no more Itanium back end as of version x.y" vs. "your code may break if compiled with version x.y if you happened to rely on this extension." > In other > words, does inclusion necessarily require the unambiguous commitment to > future support? Yes, it does require a commitment for long-term support. We maintain a *lot* of baggage we've inherited from other compilers' extensions (including some truly horrible, half-baked ones), and we can't afford to make the situation works. > Is there any potential for features explicitly marked as > experimental and with the potential for future changes (including loss > of backwards compatibility) and which could, at the discretion of core > developers, simply be dropped between releases? The problem with experimental features is that users come to rely on them (often accidentally), so removing them later on becomes very, very tricky. >> 1) Evidence of a significant user community: This is based on a number of factors, including an actual, existing user community, the perceived likelihood that users would adopt such a feature if it were available, and any "trickle-down" effects that come from, e.g., a library adopting the feature and providing benefits to its users. > > One motivation for getting an extension into Clang / LLVM is the ability > to attract a larger community of users - it would be very easy to say, > if you want to try "language extension X" it is available in some given > Clang release for the range of platforms and targets it supports, as > opposed to saying a) build it yourself, to a potential user or b) > building + distributing the equivalent to a Clang / LLVM release yourself. Yes, there is a well-known chicken-and-egg problem here. How to attract a larger user base, if the feature isn't in a compiler they have? But how can we commit to putting a feature in the compiler, if there is no user base? I don't have a good answer for this, except to hope that truly compelling features will get people excited enough to patch their Clang and get coding. >> 4) Representation within the appropriate governing organization: For extensions to a language governed by a standards committee (C, C++, OpenCL), the extension itself must have an active proposal and proponent within that committee and have a reasonable chance of acceptance. Clang should drive the standard, not diverge from it. > Is there any potential for an extension that is not intended to become a > feature of language X version current + 1? I am aware of several > extensions to various languages not intended to be such. In my opinion, no. A new C or C++ feature is only truly useful if it's on track to be standardized by the committee. A Clang-only C or C++ feature serves only a small (but growing!) slice of the C/C++ user base, and, worse, may eventually end up conflicting with features added by the appropriate standardization committee. >> 6) A high-quality implementation: Naturally, the implementation must fit well into Clang's architecture, follow LLVM's coding conventions, and meet Clang's quality standards, including high-quality diagnostics and rich AST representations. This is particularly important for language extensions, because users will learn how those extensions work through the behavior of the compiler. >> > Yes; I would not argue that my extension is of such a quality, being at > present a proof of concept; Is there scope for an incremental process > where implemented extensions that the implementer desires to be merged > could be reviewed, to allow feedback from the core developers of Clang > etc to increase the quality of the implementation? You can always solicit feedback on the mailing lists, but it's no sure thing: if someone is interested in your extension enough to dig into the implementation, you could get some great feedback. Core developers will weigh in if they can. We have talked about the general issue that it's fairly hard to get any real usage experience for a feature until it's inside the Clang tree, yet we can't add a feature into the Clang tree until it's proven itself. One idea that comes up from time to time is to have an experimental Clang branch where the rules are greatly relaxed: people can add features and incrementally improve them. If they prove themselves, we can consider merging the implementation over to the main Clang branch. I would consider having such a branch, but I personally do not have the time to maintain it. Someone else would need to handle period (daily?) merges from trunk to that branch, keep the compiler usable, etc. - Doug From craig.topper at gmail.com Tue Jul 26 00:52:28 2011 From: craig.topper at gmail.com (Craig Topper) Date: Mon, 25 Jul 2011 22:52:28 -0700 Subject: [cfe-dev] [PATCH] C++0x unicode string and character literals now with test cases In-Reply-To: References: <387A85B6-1485-4CEE-9E99-F9DB8B20BD7E@apple.com> <394914D2-D194-4778-A246-8F913CD37E7B@apple.com> Message-ID: Doh! I accidentally warned on UCNs larger than 0xffff in UTF-32 character literals. This patch fixes that. On Mon, Jul 25, 2011 at 9:43 PM, Craig Topper wrote: > Ok I've removed the defaults that I could and removed the implicit > const conversion stuff. > > ~Craig > > On Mon, Jul 25, 2011 at 9:16 PM, Douglas Gregor wrote: >> >> On Jul 25, 2011, at 6:45 PM, Sean Hunt wrote: >> >>> On Mon, Jul 25, 2011 at 18:36, Craig Topper wrote: >>>> As far as the const conversion for the new string literal types, gcc >>>> 4.5.2 allows it and throws a warning. Looks like the standard may >>>> consider these cases to be illegal now instead of deprecated for even >>>> the old cases. >>>> >>>> Google found this page which documents discussion on this topic. Look >>>> for "693. New string types and deprecated conversion " >>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3007.html >>>> >>>> ~Craig >>> >>> I think we should follow the CWG's direction here. The reason it was >>> not added, even as a deprecated conversion, was to avoid people >>> relying on a brand new deprecated conversion which would make it more >>> difficult to remove later when it could have been nipped in the bud. >>> So for consistency, the deprecated conversion for char* was removed. >>> In my opinion, given that the committee decided on this specific >>> issue, we should follow the committee's direction and reject this >>> conversion, certainly for the new types but probably char* as well >>> given the committee's explicit decision in that regard (and update the >>> compatibility docs). >> >> >> I have a sinking feeling that rejecting the string literal to char* conversion is going to break a lot of existing code. We'll have to do it eventually, but we'll need *excellent* recovery when we do. >> >> ? ? ? ?- Doug > -- ~Craig -------------- next part -------------- A non-text attachment was scrubbed... Name: unicode_strings.patch Type: application/octet-stream Size: 78876 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110725/0c13152f/attachment-0001.obj From clattner at apple.com Tue Jul 26 00:58:37 2011 From: clattner at apple.com (Chris Lattner) Date: Mon, 25 Jul 2011 22:58:37 -0700 Subject: [cfe-dev] Switching http://llvm.org/demo to clang or providing a separate clang demo In-Reply-To: References: <68AB12BE-B2C6-48C5-883F-3E63DC6C1F3B@apple.com> <1ED9477B-F151-4752-8DC1-5771DFBCBA68@apple.com> Message-ID: <1085AAF7-91F5-4CAB-8991-1EE314380490@apple.com> On Jul 23, 2011, at 12:16 AM, David Blaikie wrote: >>> Okay, this is a good point, it's probably best to try to do most of this locally, then push out tested patches. It can still be to an alternate version of the script until it's ready to go, but it would be best to avoid the thrash. >> >> Ok - I'll see about setting up a local mirror/experimental area >> locally when I get a chance. > > Seems someone else got to this a while ago, but perhaps didn't quite > get enough feedback or have enough time to see it through: > > http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-March/038828.html > http://llvm.org/bugs/show_bug.cgi?id=1440 > > If someone wants to give feedback on the changes posted in the bug I > can try to update it, or we can start again from scratch. > > I'm just working on getting this setup myself so I can see how it > looks/works locally. Aha, this is the problem with attaching patches to bugs: noone sees them. It is *much much* better to send patches to a -commits list. The patch looks like reasonable progress to me! -Chris From clattner at apple.com Tue Jul 26 01:14:03 2011 From: clattner at apple.com (Chris Lattner) Date: Mon, 25 Jul 2011 23:14:03 -0700 Subject: [cfe-dev] [PATCH] C++0x unicode string and character literals now with test cases In-Reply-To: References: <387A85B6-1485-4CEE-9E99-F9DB8B20BD7E@apple.com> <394914D2-D194-4778-A246-8F913CD37E7B@apple.com> Message-ID: <99C53C09-3999-42B3-8E81-8B05435EAB73@apple.com> On Jul 25, 2011, at 10:52 PM, Craig Topper wrote: > Doh! I accidentally warned on UCNs larger than 0xffff in UTF-32 > character literals. This patch fixes that. Hi Craig, Doug is definitely the best one to review the semantics of this. Some minor comments: IdentifierInfo &get(StringRef Name, tok::TokenKind TokenCode) { IdentifierInfo &II = get(Name); + assert(TokenCode < 512 && "TokenCode too large"); II.TokenID = TokenCode; return II; I would suggest instead: IdentifierInfo &get(StringRef Name, tok::TokenKind TokenCode) { IdentifierInfo &II = get(Name); II.TokenID = TokenCode; + assert(II.TokenID == TokenCode && "TokenCode too large"); return II; to avoid tying the '9' bit bitfield size to the magic 512 constant. class StringLiteral : public Expr { ... unsigned ByteLength; - bool IsWide; + StringKind Kind; bool IsPascal; unsigned NumConcatenated; sizeof(StringKind) is likely to be 4, wasting space. I'd suggest making it an 8 bit bitfield or something. In SemaDeclAttr etc: - if (Str == 0 || Str->isWide()) { + if (Str == 0 || Str->getKind() != StringLiteral::Ascii) { S.Diag(Attr.getLoc(), diag::err_attribute_argument_n_not_string) << "weakref" << 1; I'd suggest introducing the proper helper methods and using: - if (Str == 0 || Str->isWide()) { + if (Str == 0 || !Str->isAscii()) { S.Diag(Attr.getLoc(), diag::err_attribute_argument_n_not_string) << "weakref" << 1; In Lexer.cpp: + // treat U like the start of an identifier. + goto StartIdentifier; Instead of doing this, I'd replace the gotos with just "return LexIdentifier(Result, CurPtr);" since "MIOpt.ReadToken" has already been done. I would suggest fusing IsIdentifierL and IsIdentifierUTFStringPrefix into one function. Otherwise, LGTM! -Chris From wendling at apple.com Tue Jul 26 06:16:13 2011 From: wendling at apple.com (Bill Wendling) Date: Tue, 26 Jul 2011 04:16:13 -0700 Subject: [cfe-dev] Exception Handling Rewrite Branch Message-ID: For those who are playing along, I've started on the exception handling rewrite following the document and comments from this thread: http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-July/041748.html The repositories are: http://llvm.org/svn/llvm-project/llvm/branches/exception-handling-rewrite http://llvm.org/svn/llvm-project/cfe/branches/exception-handling-rewrite Progress Report: I created the two new instructions: landingpad and resume. Hand-modified code can run through the assembler and disassembler and emit the same code. The verifier can verify basic properties of the landingpad instruction. Next: I'll be working on getting inlining to work. Feel free to respond with questions, comments, and concerns about the design. Also, please take some time to review the patches I submit. -bw From andreas.bittel at cdn-automotive.com Tue Jul 26 06:33:45 2011 From: andreas.bittel at cdn-automotive.com (Andreas Bittel) Date: Tue, 26 Jul 2011 13:33:45 +0200 Subject: [cfe-dev] Installation of llvm Correct? Message-ID: Dear Others, I searched for "llvm.sln" and I found it in C:\Programme\LLVM\build I opended it found the windows mentioned in the Attachment. (I pressed "OK" or "ESC" and received many of such windows). Is this behavior also correct? Please give me a message if this ok or not. Tia Kind regards Andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: ProjectFileFolders_are_not_supported_in_this_version_of_application.doc Type: application/msword Size: 41472 bytes Desc: ProjectFileFolders_are_not_supported_in_this_version_of_application.doc Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110726/565627f7/attachment-0001.doc From andreas.bittel at cdn-automotive.com Tue Jul 26 06:36:58 2011 From: andreas.bittel at cdn-automotive.com (Andreas Bittel) Date: Tue, 26 Jul 2011 13:36:58 +0200 Subject: [cfe-dev] Create hello.exe via Microsoft link Message-ID: Dear Others, if I add the path for libcmt I receive another link error: C:\Programme\LLVM>"C:\Programme\Microsoft Visual Studio 9.0\VC\bin\link" hello.obj -defaultlib:C:\Programme\Microsoft Visual Studio 9.0\VC\lib\libcmt LINK : fatal error LNK1181: Eingabedatei "Visual.obj" kann nicht ge?ffnet werden. I cannot find Visual.obj neither in C:\Programme\Microsoft Visual Studio 9.0 nor in C:\Programme\LLVM ... If I do C:\Programme\LLVM>"C:\Programme\Microsoft Visual Studio 9.0\VC\bin\link" hello.obj -defaultlib:"C:\Programme\Microsoft Visual Studio 9.0\VC\lib\libcmt" I receive this LINK : fatal error LNK1104: Datei "kernel32.lib" kann nicht ge?ffnet werden. What do I have to do to create hello.exe correctly? Kind regards Andreas From andreas.bittel at cdn-automotive.com Tue Jul 26 06:39:57 2011 From: andreas.bittel at cdn-automotive.com (Andreas Bittel) Date: Tue, 26 Jul 2011 13:39:57 +0200 Subject: [cfe-dev] Direct creation of hello.exe creates error message Message-ID: Dear Others, I wanted to create hello.exe like it is mentioned in http://llvm.org/docs/GettingStartedVS.html in step 2 second part. But I did the following: C:\Programme\LLVM>build\bin\Debug\clang -c hello.c -o hello.exe C:\Programme\LLVM>hello.exe After that I received the error message (see attachment): English translation: 16-Bit-MS-DOS-Part System C:\WINDOWS\system32\cmd.exe - hello.exe The NTVDM-CPU has discovered an invalid command. CS:0ffc IP:ffc OP:0f 0f 85 01 00 Click on "close", to terminate application Close / Ignore What do I have to do to create a "hello.exe" which works without errors? The following was possible: % clang -c hello.c -emit-llvm -o hello.bc % lli hello.bc "hello world" was printed. Tia Kind regards Andreas ------------------------------------------------------------- CDN automotive AG Dr.-Ing. Andreas Bittel Im Gewerbepark C 27 93059 Regensburg Tel: +49.941.646888.144 Fax: +49.941.646888.100 Mobil: +49.176 291 555 69 E-Mail: andreas.bittel at cdn-automotive.com Website: www.cdn-automotive.com ************************************************************* Diese E-Mail kann vertrauliche und/oder rechtlich geschuetzte Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. ************************************************************* CDN automotive AG Vorstand: Gitta Bremer Vorsitzender des Aufsichtsrates: Hilmar Lesch Sitz der Gesellschaft: Wolfratshausen Amtsgericht Muenchen: HRB 175083 UST-ID: DE 233263317 ------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: English_translation_Error_Message.doc Type: application/msword Size: 28160 bytes Desc: English_translation_Error_Message.doc Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110726/9cea9139/attachment-0001.doc -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT418485.txt Url: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110726/9cea9139/attachment-0001.txt From vanboxem.ruben at gmail.com Tue Jul 26 09:19:10 2011 From: vanboxem.ruben at gmail.com (Ruben Van Boxem) Date: Tue, 26 Jul 2011 16:19:10 +0200 Subject: [cfe-dev] Polly and OpenMP Message-ID: Hi, I was looking at the Polly project page and it seemed to imply Polly would be able to generate code for OpenMP. Does this mean, that once Polly gets of its feet, we will see OpenMP support in Clang/LLVM with a bit more work (mostly parsing in Clang)? Thanks, Ruben From erik.verbruggen at me.com Tue Jul 26 09:32:57 2011 From: erik.verbruggen at me.com (Erik Verbruggen) Date: Tue, 26 Jul 2011 14:32:57 +0000 (GMT) Subject: [cfe-dev] libclang crash when reparsing Message-ID: Hello, I'm using libclang, and when using?clang_reparseTranslationUnit method, I (nearly?) always get a crash: Assertion failed: ((LatestDecl->getLocation().isInvalid() || NewLatest->getLocation().isInvalid() || !Reader.SourceMgr.isBeforeInTranslationUnit( NewLatest->getLocation(), LatestDecl->getLocation())) && "The new latest is supposed to come after the previous latest"), function VisitRedeclarableTemplateDecl, file /data/clang-llvm/llvm/tools/clang/lib/Serialization/ASTReaderDecl.cpp, line 1094. libclang: crash detected during reparsing When I turn off?CXTranslationUnit_CXXPrecompiledPreamble, things work fine (although quite a bit slower). Does anybody have an idea how I can debug this, or in which direction I should look? Regards, Erik. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110726/706d1574/attachment.html From dgregor at apple.com Tue Jul 26 09:57:29 2011 From: dgregor at apple.com (Douglas Gregor) Date: Tue, 26 Jul 2011 07:57:29 -0700 Subject: [cfe-dev] libclang crash when reparsing In-Reply-To: References: Message-ID: On Jul 26, 2011, at 7:32 AM, Erik Verbruggen wrote: > Hello, > > I'm using libclang, and when using clang_reparseTranslationUnit method, I (nearly?) always get a crash: > > Assertion failed: ((LatestDecl->getLocation().isInvalid() || NewLatest->getLocation().isInvalid() || !Reader.SourceMgr.isBeforeInTranslationUnit( NewLatest->getLocation(), LatestDecl->getLocation())) && "The new latest is supposed to come after the previous latest"), function VisitRedeclarableTemplateDecl, file /data/clang-llvm/llvm/tools/clang/lib/Serialization/ASTReaderDecl.cpp, line 1094. > libclang: crash detected during reparsing > > When I turn off CXTranslationUnit_CXXPrecompiledPreamble, things work fine (although quite a bit slower). > > Does anybody have an idea how I can debug this, or in which direction I should look? That sounds like a serious bug in the AST reader or writer. Debugging these can be fairly tricky; in this case, watching how that particular declaration ends up getting deserialized. If you could file a bug with reduced source code detailing the problem (which can be tricky, when dealing with preambles), we'd greatly appreciate it. - Doug From craig.topper at gmail.com Tue Jul 26 10:39:11 2011 From: craig.topper at gmail.com (Craig Topper) Date: Tue, 26 Jul 2011 08:39:11 -0700 Subject: [cfe-dev] [PATCH] C++0x unicode string and character literals now with test cases In-Reply-To: <99C53C09-3999-42B3-8E81-8B05435EAB73@apple.com> References: <387A85B6-1485-4CEE-9E99-F9DB8B20BD7E@apple.com> <394914D2-D194-4778-A246-8F913CD37E7B@apple.com> <99C53C09-3999-42B3-8E81-8B05435EAB73@apple.com> Message-ID: Here's a new patch addressing Chris' suggestions. ~Craig On Mon, Jul 25, 2011 at 11:14 PM, Chris Lattner wrote: > > On Jul 25, 2011, at 10:52 PM, Craig Topper wrote: > >> Doh! I accidentally warned on UCNs larger than 0xffff in UTF-32 >> character literals. This patch fixes that. > > Hi Craig, > > Doug is definitely the best one to review the semantics of this. ?Some minor comments: > > ? IdentifierInfo &get(StringRef Name, tok::TokenKind TokenCode) { > ? ? IdentifierInfo &II = get(Name); > + ? ?assert(TokenCode < 512 && "TokenCode too large"); > ? ? II.TokenID = TokenCode; > ? ? return II; > > I would suggest instead: > > ? IdentifierInfo &get(StringRef Name, tok::TokenKind TokenCode) { > ? ? IdentifierInfo &II = get(Name); > ? ? II.TokenID = TokenCode; > + ? ?assert(II.TokenID == TokenCode && "TokenCode too large"); > ? ? return II; > > to avoid tying the '9' bit bitfield size to the magic 512 constant. > > > ?class StringLiteral : public Expr { > ... > ? unsigned ByteLength; > - ?bool IsWide; > + ?StringKind Kind; > ? bool IsPascal; > ? unsigned NumConcatenated; > > sizeof(StringKind) is likely to be 4, wasting space. ?I'd suggest making it an 8 bit bitfield or something. > > > In SemaDeclAttr etc: > > - ? ?if (Str == 0 || Str->isWide()) { > + ? ?if (Str == 0 || Str->getKind() != StringLiteral::Ascii) { > ? ? ? S.Diag(Attr.getLoc(), diag::err_attribute_argument_n_not_string) > ? ? ? ? ? << "weakref" << 1; > > I'd suggest introducing the proper helper methods and using: > > - ? ?if (Str == 0 || Str->isWide()) { > + ? ?if (Str == 0 || !Str->isAscii()) { > ? ? ? S.Diag(Attr.getLoc(), diag::err_attribute_argument_n_not_string) > ? ? ? ? ? << "weakref" << 1; > > In Lexer.cpp: > > + ? ?// treat U like the start of an identifier. > + ? ?goto StartIdentifier; > > Instead of doing this, I'd replace the gotos with just "return LexIdentifier(Result, CurPtr);" since "MIOpt.ReadToken" has already been done. > > I would suggest fusing IsIdentifierL and IsIdentifierUTFStringPrefix into one function. > > Otherwise, LGTM! > > -Chris > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: unicode_strings.patch Type: application/octet-stream Size: 78680 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110726/56669e9e/attachment-0001.obj From clattner at apple.com Tue Jul 26 12:05:14 2011 From: clattner at apple.com (Chris Lattner) Date: Tue, 26 Jul 2011 10:05:14 -0700 Subject: [cfe-dev] [PATCH] C++0x unicode string and character literals now with test cases In-Reply-To: References: <387A85B6-1485-4CEE-9E99-F9DB8B20BD7E@apple.com> <394914D2-D194-4778-A246-8F913CD37E7B@apple.com> Message-ID: <9B894CC7-5BB8-481F-BFE5-4FDA16FA4168@apple.com> On Jul 26, 2011, at 8:39 AM, Craig Topper wrote: > Here's a new patch addressing Chris' suggestions. Looks good to me if Doug is fine with it, -Chris From popizdeh at gmail.com Tue Jul 26 12:06:38 2011 From: popizdeh at gmail.com (Nikola Smiljanic) Date: Tue, 26 Jul 2011 19:06:38 +0200 Subject: [cfe-dev] Easier debugging with Visual Studio Visualizers In-Reply-To: References: Message-ID: On Mon, Jul 25, 2011 at 9:48 PM, Douglas Gregor wrote: > > Could you turn these instructions into a patch against > > http://clang.llvm.org/hacking.html#debugging Here's a patch. You might want to change the beginning to include the full path to clangVisualizers.txt. I would've done this myself but I have no idea where will this file end up inside the source tree :) Added visualizer for StringRef (assumes null terminated string which I know isn't the case always, but I don't think there's a way around this) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110726/e895fd42/attachment.html -------------- next part -------------- [Visualizer] llvm::SmallVector<*,*>{ preview ( #( "[", ($T1*)$e.EndX - ($T1*)$e.BeginX, "](", #array( expr: (($T1*)$e.BeginX)[$i], size: ($T1*)$e.EndX - ($T1*)$e.BeginX ), ")" ) ) children ( #( #([size] : ($T1*)$e.EndX - ($T1*)$e.BeginX), #([capacity] : ($T1*)$e.CapacityX - ($T1*)$e.BeginX), #array( expr: (($T1*)$e.BeginX)[$i], size: ($T1*)$e.EndX - ($T1*)$e.BeginX ) ) ) } llvm::StringRef{ preview ([$e.Data,s]) stringview ([$e.Data,sb]) children ( #( #([size] : $e.Length), #array(expr: $e.Data[$i], size: $e.Length) ) ) } clang::Token{ preview((clang::tok::TokenKind)(int)$e.Kind) } -------------- next part -------------- A non-text attachment was scrubbed... Name: hacking.html.patch Type: application/octet-stream Size: 1422 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110726/e895fd42/attachment.obj From dblaikie at gmail.com Tue Jul 26 12:19:23 2011 From: dblaikie at gmail.com (David Blaikie) Date: Tue, 26 Jul 2011 10:19:23 -0700 Subject: [cfe-dev] Easier debugging with Visual Studio Visualizers In-Reply-To: References: Message-ID: > Added visualizer for StringRef (assumes null terminated string which I know > isn't the case always, but I don't think there's a way around this) That's curious - though I just verified that even VS2010's std::basic_string visualizer has the same limitation. Pity. int main() { const char xs[] = "foo\0bar"; std::string x(xs, xs + sizeof(xs)); } (mouseover at 'x' shows only "foo" in the preview, though the details show a size of 8 & both null characters in there) From popizdeh at gmail.com Tue Jul 26 12:44:59 2011 From: popizdeh at gmail.com (Nikola Smiljanic) Date: Tue, 26 Jul 2011 19:44:59 +0200 Subject: [cfe-dev] Easier debugging with Visual Studio Visualizers In-Reply-To: References: Message-ID: On Tue, Jul 26, 2011 at 7:19 PM, David Blaikie wrote: > > Added visualizer for StringRef (assumes null terminated string which I > know > > isn't the case always, but I don't think there's a way around this) > > That's curious - though I just verified that even VS2010's > std::basic_string visualizer has the same limitation. Pity. > > int main() > { > const char xs[] = "foo\0bar"; > std::string x(xs, xs + sizeof(xs)); > } > > (mouseover at 'x' shows only "foo" in the preview, though the details > show a size of 8 & both null characters in there) > This is because tooltip (preview section) is evaluated using format specifiers and they only support null-terminated strings (there is more about this inside autoexp.dat). Details are evaluated using #array and correct size, so there is at least a way to get to all the characters. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110726/47634a3e/attachment.html From jon at jonshier.com Tue Jul 26 14:01:40 2011 From: jon at jonshier.com (Jon Shier) Date: Tue, 26 Jul 2011 15:01:40 -0400 Subject: [cfe-dev] Exception Handling Rewrite Branch In-Reply-To: References: Message-ID: <1D40803A-0146-4BEA-BD19-A5F0C7EF443B@jonshier.com> I have nothing to contribute other than to ask if this rewrite will bring clang's -fno-exceptions behavior inline with GCC's. According to this comment: http://llvm.org/bugs/show_bug.cgi?id=9171#c5 clang disables both C++ and Objective-C exceptions with that option whereas GCC only disables them for C++. Of course, this may have already been fixed in clang in the 5 months since I reported that bug, and WebKit fixed the issue where it was cropping up for them, but I just wanted to bring it to your attention if you're going to specifically change how exceptions are implemented in clang. Of course this could be completely irrelevant, so carry on. Jon Shier From dgregor at apple.com Tue Jul 26 15:12:56 2011 From: dgregor at apple.com (Douglas Gregor) Date: Tue, 26 Jul 2011 13:12:56 -0700 Subject: [cfe-dev] Exception Handling Rewrite Branch In-Reply-To: <1D40803A-0146-4BEA-BD19-A5F0C7EF443B@jonshier.com> References: <1D40803A-0146-4BEA-BD19-A5F0C7EF443B@jonshier.com> Message-ID: <6D9F56F4-3616-431D-B72D-35CE057446F9@apple.com> On Jul 26, 2011, at 12:01 PM, Jon Shier wrote: > I have nothing to contribute other than to ask if this rewrite will bring clang's -fno-exceptions behavior inline with GCC's. According to this comment: http://llvm.org/bugs/show_bug.cgi?id=9171#c5 clang disables both C++ and Objective-C exceptions with that option whereas GCC only disables them for C++. Of course, this may have already been fixed in clang in the 5 months since I reported that bug, and WebKit fixed the issue where it was cropping up for them, but I just wanted to bring it to your attention if you're going to specifically change how exceptions are implemented in clang. > > Of course this could be completely irrelevant, so carry on. It is :) The exceptions rewrite concerns how exceptions are expressed in LLVM IR. It will have no effect on Clang's behavior, except hopefully to eliminate some miscompiles that have resisted our previous attempts to fix them. - Doug From echristo at apple.com Tue Jul 26 15:23:20 2011 From: echristo at apple.com (Eric Christopher) Date: Tue, 26 Jul 2011 13:23:20 -0700 Subject: [cfe-dev] Polly and OpenMP In-Reply-To: References: Message-ID: On Jul 26, 2011, at 7:19 AM, Ruben Van Boxem wrote: > Hi, > > I was looking at the Polly project page and it seemed to imply Polly > would be able to generate code for OpenMP. Does this mean, that once > Polly gets of its feet, we will see OpenMP support in Clang/LLVM with > a bit more work (mostly parsing in Clang)? Generating code for OpenMP really isn't the problem. The parser changes are quite a bit more work and are unlikely to happen unless someone does the work. There are currently no volunteers to do any of this work. -eric From narinder.claire at gmail.com Tue Jul 26 15:48:33 2011 From: narinder.claire at gmail.com (Narinder Claire) Date: Tue, 26 Jul 2011 21:48:33 +0100 Subject: [cfe-dev] clang, -fvisibility=hidden, static class method Message-ID: Hello, I am seeing some unexpected (unwanted) behaviour from clang concerning -fvisibility=hidden and static class method. When I build a shared library with -fvisibility=hidden consisting of a function with a static variable as expected the static variable is NOT exported. However if I build the same library with -fvisibility=hidden but modified so that the same function is now a static method method is a method of a class, the static variable IS exported. I am NOT decorating anything with : __attribute__ ((visibility("default"))) To better illustrate I have pasted the code below My dev environment has the following components: OS ----- Ubuntu 11.04 x64 g++ ------ Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.5.2-8ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.5 --enable-shared --enable-multiarch --with-multiarch-defaults=x86_64-linux-gnu --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib/x86_64-linux-gnu --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.5 --libdir=/usr/lib/x86_64-linux-gnu --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default --with-plugin-ld=ld.gold --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4) clang --------- clang version 2.8 (branches/release_28) Target: x86_64-pc-linux-gnu Thread model: posix The source code an makefile are shown below: makefile ------------ CXX = clang++ VISIBILITY = -fvisibility=hidden MODE = AS_NAMESPACE all: clean $(CXX) -D$(MODE) $(VISIBILITY) dll.cpp -I./ -fPIC -shared -o libdll.so $(CXX) -D$(MODE) $(VISIBILITY) main.cpp -I./ -fPIC -ldl -o main clean: rm -fr *.so *.o main klass.h ---------- #ifndef KLASS_HEADER_GUARD #define KLASS_HEADER_GUARD #include #include typedef std::set::const_iterator const_iterator ; #ifdef AS_CLASS class scope { public: static #else namespace scope { #endif std::set& Instance() { static std::set inst; return inst; } } #ifdef AS_CLASS ; #endif struct Insert { Insert(const std::string & x) { scope::Instance().insert(x); } }; #endif dll.cpp --------- #include"klass.h" namespace { Insert x("SHOULD NOT SEE THIS INSERTION"); } main.cpp ------------- #include #include #include"klass.h" using namespace std; typedef const_iterator Iterator; int main() { void* D = dlopen("libdll.so",RTLD_LOCAL|RTLD_LAZY); if(!D) { throw("Cannot load DLL\n"); } if(scope::Instance().empty()) { cout << "Set is empty\n"; } else { cout << "CONTENTS OF SET\n"; for(Iterator theIterator = scope::Instance().begin(); theIterator != scope::Instance().end(); theIterator++) { cout << *theIterator << "\n"; } } } ------------------------------------------------------------------------------------------------------------------- To see the unexpected behaviour we first set LD_LIBRARY_PATH export LD_LIBRARY_PATH=./:$LD_LIBRARY_PATH and then 'make' the exectuable with the following variations: Test 1: `````````` make MODE=AS_NAMESPACE output is from the executable is: Set is empty make CXX=g++ MODE=AS_NAMESPACE output is from the executable is: Set is empty As expected ( and wanted) the output between clang and g++ is consistent. Test 2 ````````` make MODE=AS_CLASS output is from the executable is: CONTENTS OF SET SHOULD NOT SEE THIS INSERTION make CXX=g++ MODE=AS_CLASS output is from the executable is: Set is empty Unexpected (and unwanted) the output is inconsistent between clang and g++. The behaviour from g++ appears correct whereas the behaviour from clang appears incorrect since it seems to be exporting a static variable inside a static method of a class that was never designated to have default visibility. I have seen one other email from a few months ago concerning unexpected behaviour of clang concerning visibility but from what I understand it doesn't look the same. Any help or explanation would be appreciated. Regards Narinder From rjmccall at apple.com Tue Jul 26 16:13:40 2011 From: rjmccall at apple.com (John McCall) Date: Tue, 26 Jul 2011 14:13:40 -0700 Subject: [cfe-dev] clang, -fvisibility=hidden, static class method In-Reply-To: References: Message-ID: <4CC27CE9-9B39-430F-A5D1-51124C52645C@apple.com> On Jul 26, 2011, at 1:48 PM, Narinder Claire wrote: > clang > --------- > clang version 2.8 (branches/release_28) > Target: x86_64-pc-linux-gnu > Thread model: posix There have been a lot of visibility fixes in the last year; please try again with a relatively recent clang. John. From ryuuta at gmail.com Tue Jul 26 16:23:58 2011 From: ryuuta at gmail.com (Ryuta Suzuki) Date: Wed, 27 Jul 2011 06:23:58 +0900 Subject: [cfe-dev] Implicit conversion of enum to int within an initializer list Message-ID: Hi, I'm curious if the enum values can be put in initializer list of st::vector, #include int main() { enum Type { None = 0x0, A = 0x1, B = 0x2, C = 0x4 }; typedef std::vector TypeVector; TypeVector types = { Type::A, Type::B, Type::C }; return 0; } g++ can compile it but clang++ can't: $ g++ -Wall -Wextra -std=c++0x ./classes_vector.cpp $ clang++ -Wall -Wextra -std=c++0x -stdlib=libc++ ./classes_vector.cpp ./classes_vector.cpp:14:14: error: non-aggregate type 'TypeVector' (aka 'vector') cannot be initialized with an initializer list TypeVector types = { Type::A, Type::B, Type::C }; ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 error generated. Could this be clang bug? Thanks, Ryuta -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110727/d246f2e9/attachment.html From dgregor at apple.com Tue Jul 26 16:26:36 2011 From: dgregor at apple.com (Douglas Gregor) Date: Tue, 26 Jul 2011 14:26:36 -0700 Subject: [cfe-dev] Implicit conversion of enum to int within an initializer list In-Reply-To: References: Message-ID: <55E6B3EC-C0E7-4B5D-87EA-57D000101D29@apple.com> On Jul 26, 2011, at 2:23 PM, Ryuta Suzuki wrote: > Hi, > > I'm curious if the enum values can be put in initializer list of st::vector, > > #include > > int main() > { > enum Type > { > None = 0x0, > A = 0x1, > B = 0x2, > C = 0x4 > }; > > typedef std::vector TypeVector; > TypeVector types = { Type::A, Type::B, Type::C }; > > return 0; > } > > g++ can compile it but clang++ can't: > > $ g++ -Wall -Wextra -std=c++0x ./classes_vector.cpp > > $ clang++ -Wall -Wextra -std=c++0x -stdlib=libc++ ./classes_vector.cpp > ./classes_vector.cpp:14:14: error: non-aggregate type 'TypeVector' (aka 'vector') cannot be initialized with an initializer list > TypeVector types = { Type::A, Type::B, Type::C }; > ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 1 error generated. > > Could this be clang bug? It's not a bug; C++0x generalized initializer lists haven't been implemented in Clang yet. - Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110726/e635cd3e/attachment.html From ryuuta at gmail.com Tue Jul 26 16:33:52 2011 From: ryuuta at gmail.com (Ryuta Suzuki) Date: Wed, 27 Jul 2011 06:33:52 +0900 Subject: [cfe-dev] Implicit conversion of enum to int within an initializer list In-Reply-To: <55E6B3EC-C0E7-4B5D-87EA-57D000101D29@apple.com> References: <55E6B3EC-C0E7-4B5D-87EA-57D000101D29@apple.com> Message-ID: Oh, I thought it was implemented in clang already. Thanks for the info, Doug. Regards, Ryuta On Wed, Jul 27, 2011 at 6:26 AM, Douglas Gregor wrote: > > On Jul 26, 2011, at 2:23 PM, Ryuta Suzuki wrote: > > Hi, > > I'm curious if the enum values can be put in initializer list of > st::vector, > > #include > > int main() > { > enum Type > { > None = 0x0, > A = 0x1, > B = 0x2, > C = 0x4 > }; > > typedef std::vector TypeVector; > TypeVector types = { Type::A, Type::B, Type::C }; > > return 0; > } > > g++ can compile it but clang++ can't: > > $ g++ -Wall -Wextra -std=c++0x ./classes_vector.cpp > > $ clang++ -Wall -Wextra -std=c++0x -stdlib=libc++ ./classes_vector.cpp > ./classes_vector.cpp:14:14: error: non-aggregate type 'TypeVector' (aka > 'vector') cannot be initialized with an initializer list > TypeVector types = { Type::A, Type::B, Type::C }; > ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 1 error generated. > > Could this be clang bug? > > > It's not a bug; C++0x generalized initializer lists haven't been > implemented in Clang yet. > > - Doug > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110727/e5c86f98/attachment.html From narinder.claire at gmail.com Tue Jul 26 16:43:26 2011 From: narinder.claire at gmail.com (Narinder Claire) Date: Tue, 26 Jul 2011 22:43:26 +0100 Subject: [cfe-dev] clang, -fvisibility=hidden, static class method In-Reply-To: References: <4CC27CE9-9B39-430F-A5D1-51124C52645C@apple.com> Message-ID: - Hide quoted text - On 26 July 2011 22:13, John McCall wrote: > On Jul 26, 2011, at 1:48 PM, Narinder Claire wrote: >> clang >> --------- >> clang version 2.8 (branches/release_28) >> Target: x86_64-pc-linux-gnu >> Thread model: posix > > There have been a lot of visibility fixes in the last year; please try again with a relatively recent clang. > > John. > Ok, thanks I will look into doing that. I had assumed that Ubuntu 11.04 released, released relatively recently would be reasonably up today. Regards Narinder. From panbalag1 at gmail.com Thu Jul 21 09:25:06 2011 From: panbalag1 at gmail.com (Prasanth Anbalagan) Date: Thu, 21 Jul 2011 10:25:06 -0400 Subject: [cfe-dev] Build Error Message-ID: Hi, I'm trying to build Clang on Redhat Linux. I recevied the following error llvm[3]: Compiling SimplifyLibCalls.cpp for Debug+Asserts build llvm[3]: Compiling Sink.cpp for Debug+Asserts build llvm[3]: Compiling TailDuplication.cpp for Debug+Asserts build llvm[3]: Compiling TailRecursionElimination.cpp for Debug+Asserts build llvm[3]: Building Debug+Asserts Archive Library libLLVMScalarOpts.a make[3]: *** [/root/llvm/Debug+Asserts/lib/libLLVMScalarOpts.a] Error 1 make[3]: Leaving directory `/root/llvm/lib/Transforms/Scalar' make[2]: *** [Scalar/.makeall] Error 2 make[2]: Leaving directory `/root/llvm/lib/Transforms' make[1]: *** [Transforms/.makeall] Error 2 make[1]: Leaving directory `/root/llvm/lib' make: *** [all] Error 1 -Any suggestions on how I could resolve this? Thanks, Prasanth -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110721/eeee5624/attachment.html From tobias at grosser.es Tue Jul 26 16:49:21 2011 From: tobias at grosser.es (Tobias Grosser) Date: Tue, 26 Jul 2011 23:49:21 +0200 Subject: [cfe-dev] Polly and OpenMP In-Reply-To: References: Message-ID: <4E2F3661.1090105@grosser.es> On 07/26/2011 04:19 PM, Ruben Van Boxem wrote: > Hi, > > I was looking at the Polly project page and it seemed to imply Polly > would be able to generate code for OpenMP. Does this mean, that once > Polly gets of its feet, we will see OpenMP support in Clang/LLVM with > a bit more work (mostly parsing in Clang)? Hi Ruben, OpenMP support in Polly means basically that we can transform loops, for which we can prove that there are no problematic dependences, into loops that are executed in parallel. This parallel execution takes advantage of the GNU OpenMP run time library. Polly itself uses just a small part of the GNU OpenMP run time library. Getting OpenMP support into Clang/LLVM is not very closely related to the OpenMP code generation support in Polly. For OpenMP support in clang we need OpenMP parsing in clang as Eric pointed out. This parsing needs to support the whole OpenMP standard and not only the very limited subset Polly is using. Beyond parsing we need efficient code generation support for OpenMP and furthermore we need a run time library. Polly uses currently libgomp from the GNU project, however for official integration into LLVM, we most probably want to have a different license. mpc [1] may be an option. If you are interested into OpenMP support in clang, the first step would probably be to extend clang to parse OpenMP directives. I know that there are several implementations available, however unfortunately none of them was every contributed back to clang. Cheers Tobi [1] http://mpc.sf.net From echristo at apple.com Tue Jul 26 18:15:22 2011 From: echristo at apple.com (Eric Christopher) Date: Tue, 26 Jul 2011 16:15:22 -0700 Subject: [cfe-dev] Build Error In-Reply-To: References: Message-ID: <9EE7FF4D-2D87-4C96-85B7-298F142B63B2@apple.com> On Jul 21, 2011, at 7:25 AM, Prasanth Anbalagan wrote: > Hi, > > I'm trying to build Clang on Redhat Linux. I recevied the following error > > llvm[3]: Compiling SimplifyLibCalls.cpp for Debug+Asserts build > llvm[3]: Compiling Sink.cpp for Debug+Asserts build > llvm[3]: Compiling TailDuplication.cpp for Debug+Asserts build > llvm[3]: Compiling TailRecursionElimination.cpp for Debug+Asserts build > llvm[3]: Building Debug+Asserts Archive Library libLLVMScalarOpts.a > make[3]: *** [/root/llvm/Debug+Asserts/lib/libLLVMScalarOpts.a] Error 1 > make[3]: Leaving directory `/root/llvm/lib/Transforms/Scalar' > make[2]: *** [Scalar/.makeall] Error 2 > make[2]: Leaving directory `/root/llvm/lib/Transforms' > make[1]: *** [Transforms/.makeall] Error 2 > make[1]: Leaving directory `/root/llvm/lib' > make: *** [all] Error 1 > > > -Any suggestions on how I could resolve this? Yes. Look earlier for the actual error. -eric From todd.a.anderson at intel.com Tue Jul 26 18:36:44 2011 From: todd.a.anderson at intel.com (Anderson, Todd A) Date: Tue, 26 Jul 2011 16:36:44 -0700 Subject: [cfe-dev] How to change calling convention. Message-ID: <1DB50624F8348F48840F2E2CF6040A9D0190695801@orsmsx508.amr.corp.intel.com> >From within HandleTopLevelDecl, I'm trying to modify a function's calling convention if it is not explicitly given. getType() returns a const though. Any suggestions how to modify the underlying type? Also, what would be the best way to call a method on the Lexer from BackendConsumer::HandleTopLevelDecl? Thanks, Todd -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110726/bd55521a/attachment.html From eli.friedman at gmail.com Tue Jul 26 18:50:24 2011 From: eli.friedman at gmail.com (Eli Friedman) Date: Tue, 26 Jul 2011 16:50:24 -0700 Subject: [cfe-dev] How to change calling convention. In-Reply-To: <1DB50624F8348F48840F2E2CF6040A9D0190695801@orsmsx508.amr.corp.intel.com> References: <1DB50624F8348F48840F2E2CF6040A9D0190695801@orsmsx508.amr.corp.intel.com> Message-ID: On Tue, Jul 26, 2011 at 4:36 PM, Anderson, Todd A wrote: > From within HandleTopLevelDecl, I?m trying to modify a function?s calling > convention if it is not explicitly given.? getType() returns a const > though.? Any suggestions how to modify the underlying type? Types are immutable, but FunctionDecl's do have a setType method. > Also, what would be the best way to call a method on the Lexer from > BackendConsumer::HandleTopLevelDecl? What are you trying to do? -Eli From cbergstrom at pathscale.com Tue Jul 26 21:27:48 2011 From: cbergstrom at pathscale.com (=?ISO-8859-1?Q?=22C=2E_Bergstr=F6m=22?=) Date: Wed, 27 Jul 2011 09:27:48 +0700 Subject: [cfe-dev] Polly and OpenMP In-Reply-To: <4E2F3661.1090105@grosser.es> References: <4E2F3661.1090105@grosser.es> Message-ID: <4E2F77A4.4040807@pathscale.com> On 07/27/11 04:49 AM, Tobias Grosser wrote: > On 07/26/2011 04:19 PM, Ruben Van Boxem wrote: >> Hi, >> >> I was looking at the Polly project page and it seemed to imply Polly >> would be able to generate code for OpenMP. Does this mean, that once >> Polly gets of its feet, we will see OpenMP support in Clang/LLVM with >> a bit more work (mostly parsing in Clang)? > Hi Ruben, > > OpenMP support in Polly means basically that we can transform loops, for > which we can prove that there are no problematic dependences, into loops > that are executed in parallel. This parallel execution takes advantage > of the GNU OpenMP run time library. Polly itself uses just a small part > of the GNU OpenMP run time library. > > Getting OpenMP support into Clang/LLVM is not very closely related to > the OpenMP code generation support in Polly. For OpenMP support in clang > we need OpenMP parsing in clang as Eric pointed out. This parsing needs > to support the whole OpenMP standard and not only the very limited > subset Polly is using. Beyond parsing we need efficient code generation > support for OpenMP and furthermore we need a run time library. Polly > uses currently libgomp from the GNU project, however for official > integration into LLVM, we most probably want to have a different > license. mpc [1] may be an option. > > If you are interested into OpenMP support in clang, the first step would > probably be to extend clang to parse OpenMP directives. I know that > there are several implementations available, however unfortunately none > of them was every contributed back to clang. Sorry MPC is not a very good recommendation for runtime because 1) It's basically still LGPL 2) It's only OMP-2.5 3) Can it actually demonstrate scalable performance and production quality? OMP 3.x as a whole is a pretty big chunk of work and parsing is the smallest part of it imho. It would take months and months of work for someone to get it all together to what effect? How many people would use it? Is there also Fortran support? /* Disclaimer - I'm biased - The company I work for has clang parsing OpenMP and an OMP/HMPP compiler */ -------- Further I'd argue against OMP *entirely* 1) It's evolving at a slug rate 2) If you actually go to those meetings where they discuss the "future" it's nearly comical. 2.a) The proposed standards will have really ugly parsing/semantic analysis if accepted 2.b) Everything they are trying to steal from others is more or less available today (OpenHMPP[1]) 2.c) Today it's GPGPU support sucks and I'm not convinced that will change 3) Instead of being an elegant design it's getting bigger and bigger With OpenHMPP you should be able to get 1) equal or greater scalability vs OMP *now* 2) The model also works for NVIDIA GPU *today* 3) It has a simple/elegant design which is relatively easy to parse/sema Anyone who thinks OpenHMPP would be useful to them/clang ping me off list. ./C [1] http://www.openhmpp.org/en/OpenHMPP-directive-based-programming-model.aspx From tmcclory at udel.edu Tue Jul 26 23:08:32 2011 From: tmcclory at udel.edu (Timothy McClory) Date: Wed, 27 Jul 2011 04:08:32 +0000 Subject: [cfe-dev] Detecting Macro Expansions Message-ID: How can I determine if an IntegerLiteral comes from a macro expansion? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110727/63fd8b51/attachment.html From thakis at chromium.org Tue Jul 26 23:17:09 2011 From: thakis at chromium.org (Nico Weber) Date: Tue, 26 Jul 2011 21:17:09 -0700 Subject: [cfe-dev] Detecting Macro Expansions In-Reply-To: References: Message-ID: Try integerLiteral->getLocation().isMacroID() (untested) Nico On Tue, Jul 26, 2011 at 9:08 PM, Timothy McClory wrote: > How can I determine if an IntegerLiteral comes from a macro expansion? > > Thanks > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > > From dgregor at apple.com Wed Jul 27 00:23:30 2011 From: dgregor at apple.com (Douglas Gregor) Date: Tue, 26 Jul 2011 22:23:30 -0700 Subject: [cfe-dev] Easier debugging with Visual Studio Visualizers In-Reply-To: References: Message-ID: <4CB46E01-1D67-4D08-9F9C-033CB166036A@apple.com> On Jul 26, 2011, at 10:06 AM, Nikola Smiljanic wrote: > On Mon, Jul 25, 2011 at 9:48 PM, Douglas Gregor wrote: > > Could you turn these instructions into a patch against > > http://clang.llvm.org/hacking.html#debugging > > > Here's a patch. You might want to change the beginning to include the full path to clangVisualizers.txt. I would've done this myself but I have no idea where will this file end up inside the source tree :) > > Added visualizer for StringRef (assumes null terminated string which I know isn't the case always, but I don't think there's a way around this) > Committed as r136207, thanks! - Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110726/c0dc567c/attachment.html From dgregor at apple.com Wed Jul 27 00:41:25 2011 From: dgregor at apple.com (Douglas Gregor) Date: Tue, 26 Jul 2011 22:41:25 -0700 Subject: [cfe-dev] [PATCH] C++0x unicode string and character literals now with test cases In-Reply-To: References: <387A85B6-1485-4CEE-9E99-F9DB8B20BD7E@apple.com> <394914D2-D194-4778-A246-8F913CD37E7B@apple.com> Message-ID: <5440B681-917E-4522-9DD9-DC80A5C35A01@apple.com> On Jul 26, 2011, at 8:39 AM, Craig Topper wrote: > Here's a new patch addressing Chris' suggestions. Great! I've committed this as r136210, thanks so much! - Doug > > On Mon, Jul 25, 2011 at 11:14 PM, Chris Lattner wrote: >> >> On Jul 25, 2011, at 10:52 PM, Craig Topper wrote: >> >>> Doh! I accidentally warned on UCNs larger than 0xffff in UTF-32 >>> character literals. This patch fixes that. >> >> Hi Craig, >> >> Doug is definitely the best one to review the semantics of this. Some minor comments: >> >> IdentifierInfo &get(StringRef Name, tok::TokenKind TokenCode) { >> IdentifierInfo &II = get(Name); >> + assert(TokenCode < 512 && "TokenCode too large"); >> II.TokenID = TokenCode; >> return II; >> >> I would suggest instead: >> >> IdentifierInfo &get(StringRef Name, tok::TokenKind TokenCode) { >> IdentifierInfo &II = get(Name); >> II.TokenID = TokenCode; >> + assert(II.TokenID == TokenCode && "TokenCode too large"); >> return II; >> >> to avoid tying the '9' bit bitfield size to the magic 512 constant. >> >> >> class StringLiteral : public Expr { >> ... >> unsigned ByteLength; >> - bool IsWide; >> + StringKind Kind; >> bool IsPascal; >> unsigned NumConcatenated; >> >> sizeof(StringKind) is likely to be 4, wasting space. I'd suggest making it an 8 bit bitfield or something. >> >> >> In SemaDeclAttr etc: >> >> - if (Str == 0 || Str->isWide()) { >> + if (Str == 0 || Str->getKind() != StringLiteral::Ascii) { >> S.Diag(Attr.getLoc(), diag::err_attribute_argument_n_not_string) >> << "weakref" << 1; >> >> I'd suggest introducing the proper helper methods and using: >> >> - if (Str == 0 || Str->isWide()) { >> + if (Str == 0 || !Str->isAscii()) { >> S.Diag(Attr.getLoc(), diag::err_attribute_argument_n_not_string) >> << "weakref" << 1; >> >> In Lexer.cpp: >> >> + // treat U like the start of an identifier. >> + goto StartIdentifier; >> >> Instead of doing this, I'd replace the gotos with just "return LexIdentifier(Result, CurPtr);" since "MIOpt.ReadToken" has already been done. >> >> I would suggest fusing IsIdentifierL and IsIdentifierUTFStringPrefix into one function. >> >> Otherwise, LGTM! >> >> -Chris >> >> >> > From craig.topper at gmail.com Wed Jul 27 01:07:49 2011 From: craig.topper at gmail.com (Craig Topper) Date: Tue, 26 Jul 2011 23:07:49 -0700 Subject: [cfe-dev] [PATCH] C++0x unicode string and character literals now with test cases In-Reply-To: <5440B681-917E-4522-9DD9-DC80A5C35A01@apple.com> References: <387A85B6-1485-4CEE-9E99-F9DB8B20BD7E@apple.com> <394914D2-D194-4778-A246-8F913CD37E7B@apple.com> <5440B681-917E-4522-9DD9-DC80A5C35A01@apple.com> Message-ID: Here's the patch to update the support page. On Tue, Jul 26, 2011 at 10:41 PM, Douglas Gregor wrote: > > On Jul 26, 2011, at 8:39 AM, Craig Topper wrote: > >> Here's a new patch addressing Chris' suggestions. > > Great! I've committed this as r136210, thanks so much! > > ? ? ? ?- Doug > >> >> On Mon, Jul 25, 2011 at 11:14 PM, Chris Lattner wrote: >>> >>> On Jul 25, 2011, at 10:52 PM, Craig Topper wrote: >>> >>>> Doh! I accidentally warned on UCNs larger than 0xffff in UTF-32 >>>> character literals. This patch fixes that. >>> >>> Hi Craig, >>> >>> Doug is definitely the best one to review the semantics of this. ?Some minor comments: >>> >>> ? IdentifierInfo &get(StringRef Name, tok::TokenKind TokenCode) { >>> ? ? IdentifierInfo &II = get(Name); >>> + ? ?assert(TokenCode < 512 && "TokenCode too large"); >>> ? ? II.TokenID = TokenCode; >>> ? ? return II; >>> >>> I would suggest instead: >>> >>> ? IdentifierInfo &get(StringRef Name, tok::TokenKind TokenCode) { >>> ? ? IdentifierInfo &II = get(Name); >>> ? ? II.TokenID = TokenCode; >>> + ? ?assert(II.TokenID == TokenCode && "TokenCode too large"); >>> ? ? return II; >>> >>> to avoid tying the '9' bit bitfield size to the magic 512 constant. >>> >>> >>> ?class StringLiteral : public Expr { >>> ... >>> ? unsigned ByteLength; >>> - ?bool IsWide; >>> + ?StringKind Kind; >>> ? bool IsPascal; >>> ? unsigned NumConcatenated; >>> >>> sizeof(StringKind) is likely to be 4, wasting space. ?I'd suggest making it an 8 bit bitfield or something. >>> >>> >>> In SemaDeclAttr etc: >>> >>> - ? ?if (Str == 0 || Str->isWide()) { >>> + ? ?if (Str == 0 || Str->getKind() != StringLiteral::Ascii) { >>> ? ? ? S.Diag(Attr.getLoc(), diag::err_attribute_argument_n_not_string) >>> ? ? ? ? ? << "weakref" << 1; >>> >>> I'd suggest introducing the proper helper methods and using: >>> >>> - ? ?if (Str == 0 || Str->isWide()) { >>> + ? ?if (Str == 0 || !Str->isAscii()) { >>> ? ? ? S.Diag(Attr.getLoc(), diag::err_attribute_argument_n_not_string) >>> ? ? ? ? ? << "weakref" << 1; >>> >>> In Lexer.cpp: >>> >>> + ? ?// treat U like the start of an identifier. >>> + ? ?goto StartIdentifier; >>> >>> Instead of doing this, I'd replace the gotos with just "return LexIdentifier(Result, CurPtr);" since "MIOpt.ReadToken" has already been done. >>> >>> I would suggest fusing IsIdentifierL and IsIdentifierUTFStringPrefix into one function. >>> >>> Otherwise, LGTM! >>> >>> -Chris >>> >>> >>> >> > > -- ~Craig -------------- next part -------------- A non-text attachment was scrubbed... Name: unicode_support.patch Type: application/octet-stream Size: 470 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20110726/a8a5f959/attachment.obj From dgregor at apple.com Wed Jul 27 10:22:49 2011 From: dgregor at apple.com (Douglas Gregor) Date: Wed, 27 Jul 2011 08:22:49 -0700 Subject: [cfe-dev] [PATCH] C++0x unicode string and character literals now with test cases In-Reply-To: References: <387A85B6-1485-4CEE-9E99-F9DB8B20BD7E@apple.com> <394914D2-D194-4778-A246-8F913CD37E7B@apple.com> Message-ID: On Jul 26, 2011, at 11:07 PM, Craig Topper wrote: > Here's the patch to update the support page. r136216, thanks! - Doug > On Tue, Jul 26, 2011 at 10:41 PM, Douglas Gregor wrote: >> >> On Jul 26, 2011, at 8:39 AM, Craig Topper wrote: >> >>> Here's a new patch addressing Chris' suggestions. >> >> Great! I've committed this as r136210, thanks so much! >> >> - Doug >> >>> >>> On Mon, Jul 25, 2011 at 11:14 PM, Chris Lattner wrote: >>>> >>>> On Jul 25, 2011, at 10:52 PM, Craig Topper wrote: >>>> >>>>> Doh! I accidentally warned on UCNs larger than 0xffff in UTF-32 >>>>> character literals. This patch fixes that. >>>> >>>> Hi Craig, >>>> >>>> Doug is definitely the best one to review the semantics of this. Some minor comments: >>>> >>>> IdentifierInfo &get(StringRef Name, tok::TokenKind TokenCode) { >>>> IdentifierInfo &II = get(Name); >>>> + assert(TokenCode < 512 && "TokenCode too large"); >>>> II.TokenID = TokenCode; >>>> return II; >>>> >>>> I would suggest instead: >>>> >>>> IdentifierInfo &get(StringRef Name, tok::TokenKind TokenCode) { >>>> IdentifierInfo &II = get(Name); >>>> II.TokenID = TokenCode; >>>> + assert(II.TokenID == TokenCode && "TokenCode too large"); >>>> return II; >>>> >>>> to avoid tying the '9' bit bitfield size to the magic 512 constant. >>>> >>>> >>>> class StringLiteral : public Expr { >>>> ... >>>> unsigned ByteLength; >>>> - bool IsWide; >>>> + StringKind Kind; >>>> bool IsPascal; >>>> unsigned NumConcatenated; >>>> >>>> sizeof(StringKind) is likely to be 4, wasting space. I'd suggest making it an 8 bit bitfield or something. >>>> >>>> >>>> In SemaDeclAttr etc: >>>> >>>> - if (Str == 0 || Str->isWide()) { >>>> + if (Str == 0 || Str->getKind() != StringLiteral::Ascii) { >>>> S.Diag(Attr.getLoc(), diag::err_attribute_argument_n_not_string) >>>> << "weakref" << 1; >>>> >>>> I'd suggest introducing the proper helper methods and using: >>>> >>>> - if (Str == 0 || Str->isWide()) { >>>> + if (Str == 0 || !Str->isAscii()) { >>>> S.Diag(Attr.getLoc(), diag::err_attribute_argument_n_not_string) >>>> << "weakref" << 1; >>>> >>>> In Lexer.cpp: >>>> >>>> + // treat U like the start of an identifier. >>>> + goto StartIdentifier; >>>> >>>> Instead of doing this, I'd replace the gotos with just "return LexIdentifier(Result, CurPtr);" since "MIOpt.ReadToken" has already been done. >>>> >>>> I would suggest fusing IsIdentifierL and IsIdentifierUTFStringPrefix into one function. >>>> >>>> Otherwise, LGTM! >>>> >>>> -Chris >>>> >>>> >>>> >>> >> >> > > > > -- > ~Craig > From todd.a.anderson at intel.com Wed Jul 27 11:09:35 2011 From: todd.a.anderson at intel.com (Anderson, Todd A) Date: Wed, 27 Jul 2011 09:09:35 -0700 Subject: [cfe-dev] How to change calling convention. In-Reply-To: References: <1DB50624F8348F48840F2E2CF6040A9D0190695801@orsmsx508.amr.corp.intel.com> Message-ID: <1DB50624F8348F48840F2E2CF6040A9D0190695972@orsmsx508.amr.corp.intel.com> I tried creating a copy of the type using the copy constructor of FunctionType but that just gave me a bunch of compile errors about the Type constructor being private. Then I wanted to change the calling convention of that copied type and call setType. I'm currently trying to construct a new FunctionType using get methods on the previous type to fill in the parts that remain constant. The problem at the moment is that isVariadic() seems to be private but I presume that function types cannot be Variadic so I'll just pass false there and then try setType. What I'm trying to do is add pragmas that control the default calling convention. If there is a way to do this all within the Lexer rather than changing it afterwards I'm all ears. Todd -----Original Message----- From: Eli Friedman [mailto:eli.friedman at gmail.com] Sent: Tuesday, July 26, 2011 4:50 PM To: Anderson, Todd A Cc: cfe-dev at cs.uiuc.edu Subject: Re: [cfe-dev] How to change calling convention. On Tue, Jul 26, 2011 at 4:36 PM, Anderson, Todd A wrote: > From within HandleTopLevelDecl, I'm trying to modify a function's > calling convention if it is not explicitly given.? getType() returns a > const though.? Any suggestions how to modify the underlying type? Types are immutable, but FunctionDecl's do have a setType method. > Also, what would be the best way to call a method on the Lexer from > BackendConsumer::HandleTopLevelDecl? What are you trying to do? -Eli From eli.friedman at gmail.com Wed Jul 27 11:47:19 2011 From: eli.friedman at gmail.com (Eli Friedman) Date: Wed, 27 Jul 2011 09:47:19 -0700 Subject: [cfe-dev] How to change calling convention. In-Reply-To: <1DB50624F8348F48840F2E2CF6040A9D0190695972@orsmsx508.amr.corp.intel.com> References: <1DB50624F8348F48840F2E2CF6040A9D0190695801@orsmsx508.amr.corp.intel.com> <1DB50624F8348F48840F2E2CF6040A9D0190695972@orsmsx508.amr.corp.intel.com> Message-ID: On Wed, Jul 27, 2011 at 9:09 AM, Anderson, Todd A wrote: > I tried creating a copy of the type using the copy constructor of FunctionType but that just gave me a bunch of compile errors about the Type constructor being private. There are methods to build new types on ASTContext. > Then I wanted to change the calling convention of that copied type and call setType. ?I'm currently trying to construct a new FunctionType using get methods on the previous type to fill in the parts that remain constant. ?The problem at the moment is that isVariadic() seems to be private but I presume that function types cannot be Variadic so I'll just pass false there and then try setType. There are two kinds of FunctionType: FunctionProtoType and FunctionNoProtoType. They need to be handled slightly differently. > What I'm trying to do is add pragmas that control the default calling convention. ?If there is a way to do this all within the Lexer rather than changing it afterwards I'm all ears. There are some existing pragmas that are a bit similar; look in lib/Parse/ParsePragma.cpp. -Eli From jfreeman at cse.tamu.edu Wed Jul 27 11:55:05 2011 From: jfreeman at cse.tamu.edu (John Freeman) Date: Wed, 27 Jul 2011 11:55:05 -0500 Subject: [cfe-dev] Error in Clang Doxygen? Message-ID: <4E3042E9.8040108@cse.tamu.edu> There are some entities documented in the source that are not included in the doxygen. For example, CXXRecordDecl has a page, but none of its members appear: http://clang.llvm.org/doxygen/classCXXRecordDecl.html For another example, neither CXXMethodDecl nor CXXCtorInitializer have pages at all, even though they appear in the same file (AST/DeclCXX.h), in the same scope, immediately following CXXRecordDecl. Is there an error in the documentation for CXXRecordDecl that prevents doxygen from finishing the file? I generated the docs with warnings, and I got no warnings for the file AST/DeclCXX.h. - John From vasil.georgiev.vasilev at cern.ch Wed Jul 27 12:22:55 2011 From: vasil.georgiev.vasilev at cern.ch (Vassil Vassilev) Date: Wed, 27 Jul 2011 19:22:55 +0200 Subject: [cfe-dev] dyn_cast and DiagnosticClient In-Reply-To: References: <4E01F122.2030002@cern.ch> Message-ID: <4E30496F.4060708@cern.ch> Hi, Sorry for the delayed answer I didn't follow the tread quite a while. Actually for cling prompt we needed to ignore certain error that doesn't make sense (of course within the prompt) like unused expression and etc. I had implemented a custom DiagnosticClient that ignored those warnings. However for the testsuite we needed the VerifyDiagnosticsClient and I wanted to check which is the currently attached diagnostic client. Soon I found out that clang has very nice interface for doing that. I could simply map the warning to ignored... Sorry for the noise. Vassil On 06/24/2011 06:50 PM, Eli Friedman wrote: > On Wed, Jun 22, 2011 at 6:41 AM, Vassil Vassilev > wrote: >> Hi, >> I was wondering is there any chance of having dyn_cast for clang's >> diagnostic clients? > We haven't had any use for that construct so far... why would it be useful? > > -Eli From vasil.georgiev.vasilev at cern.ch Wed Jul 27 12:31:38 2011 From: vasil.georgiev.vasilev at cern.ch (Vassil Vassilev) Date: Wed, 27 Jul 2011 19:31:38 +0200 Subject: [cfe-dev] Error in Clang Doxygen? In-Reply-To: <4E3042E9.8040108@cse.tamu.edu> References: <4E3042E9.8040108@cse.tamu.edu> Message-ID: <4E304B7A.4080207@cern.ch> Hi, Yes from time to time somebody asks about that (I did before) but didn't get answer. Perhaps it is not that important, but it is annoying. I could generate documentation as well, but I prefer to use the online docs because they are always up-to-date. Can anyone tell what needs to be fixed in order to see doxygen for DeclCXX in the online documentation? Vassil On 07/27/2011 06:55 PM, John Freeman wrote: > There are some entities documented in the source that are not included > in the doxygen. For example, CXXRecordDecl has a page, but none of its > members appear: > http://clang.llvm.org/doxygen/classCXXRecordDecl.html > > For another example, neither CXXMethodDecl nor CXXCtorInitializer have > pages at all, even th