From jediknil at belkadan.com Thu Apr 1 01:51:15 2010 From: jediknil at belkadan.com (Jordy Rose) Date: Wed, 31 Mar 2010 23:51:15 -0700 Subject: [cfe-dev] Newcomer! (with patch for XFAIL no-outofbounds.c) Message-ID: <5f7ee204d9be59f0e6a9dc8d63270101@localhost> Hello, all! I'm a Mac OS X programmer, a UC Berkeley CS undergrad, and a newcomer to Clang, though much indebted to its faster and lower-memory compilations and easy static analysis. I'm very interested in programming languages and by extension compilers and analysis tools, but haven't yet gotten the chance to work on any real projects in that area. I come bearing a small patch for the XFAIL test no-outofbounds.c (allow treating single variables as arrays); the idea is to just use the size of the atomic type to figure out the length of the "array". Not too hard. All tests pass. I'm interested in doing Google Summer of Code this summer, and I'd love to do a project for Clang. The catch is I don't yet have a solid project idea in mind; one of my ideas was a customization scheme similar to what Sam Harrington described a week ago. (http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-March/008482.html) Hoping to pin down a full proposal by the weekend; yes, I know I'm running behind! Anyway, I'm glad to be here and glad to be making a (small) contribution to the project. Jordy Rose -------------- next part -------------- Index: test/Analysis/no-outofbounds.c =================================================================== --- test/Analysis/no-outofbounds.c (revision 100088) +++ test/Analysis/no-outofbounds.c (working copy) @@ -1,6 +1,5 @@ // RUN: %clang_cc1 -analyzer-check-objc-mem -analyze -analyzer-experimental-internal-checks -analyzer-store=basic -verify %s // RUN: %clang_cc1 -analyzer-check-objc-mem -analyze -analyzer-experimental-internal-checks -analyzer-store=region -verify %s -// XFAIL: * //===----------------------------------------------------------------------===// // This file tests cases where we should not flag out-of-bounds warnings. @@ -10,4 +9,6 @@ long x = 0; char *y = (char*) &x; char c = y[0] + y[1] + y[2]; // no-warning + short *z = (short*) &x; + short s = z[0] + z[1]; // no-warning } Index: test/Analysis/outofbound.c =================================================================== --- test/Analysis/outofbound.c (revision 100088) +++ test/Analysis/outofbound.c (working copy) @@ -13,3 +13,26 @@ int *p = malloc(12); p[3] = 4; // expected-warning{{Access out-of-bound array element (buffer overflow)}} } + +struct three_words { + int c[3]; +}; + +struct seven_words { + int c[7]; +}; + +void f3() { + struct three_words a, *p; + p = &a; + p[0] = a; // no-warning + p[1] = a; // expected-warning{{Access out-of-bound array element (buffer overflow)}} +} + +void f4() { + struct seven_words c; + struct three_words a, *p = (struct three_words *)&c; + p[0] = a; // no-warning + p[1] = a; // no-warning + p[2] = a; // expected-warning{{Access out-of-bound array element (buffer overflow)}} +} Index: lib/Checker/RegionStore.cpp =================================================================== --- lib/Checker/RegionStore.cpp (revision 100088) +++ lib/Checker/RegionStore.cpp (working copy) @@ -787,9 +787,12 @@ return ValMgr.makeIntVal(CAT->getSize(), false); } - // Clients can use ordinary variables as if they were arrays. These - // essentially are arrays of size 1. - return ValMgr.makeIntVal(1, false); + // Clients can reinterpret ordinary variables as arrays, possibly of + // another type. The width is rounded down to ensure that an access is + // entirely within bounds. + CharUnits VarSize = getContext().getTypeSizeInChars(T); + CharUnits EleSize = getContext().getTypeSizeInChars(EleTy); + return ValMgr.makeIntVal(VarSize / EleSize, false); } } From ioripolo at gmail.com Thu Apr 1 03:14:17 2010 From: ioripolo at gmail.com (=?GB2312?B?1cLA2g==?=) Date: Thu, 1 Apr 2010 16:14:17 +0800 Subject: [cfe-dev] View graph while debugging code on windows Message-ID: Hi all, I've been study clang for a while, and i found it's great to view some graph (while debugging code). Usually i use gdb under emacs and call GRExprEngine::ViewGraph(false) when i need to see where the analysis goes. But i found it's faster for me to debug clang in VS, because i can see "locals" much quickly and clearly. Here comes the problems: First, can i make the "-analyzer-viz-egraph-graphviz" or something like this happen on windows? If so, how? Second, is there anything like "gdb call" in VS Debugging? Further, can i make GRExprEngine::ViewGraph(false) happen while debugging clang in VS? I'll also appreciate it if there are any advice about debugging with gdb. Thanks. -- Best regards! Lei Zhang -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100401/645c0b00/attachment.html From xuzhongxing at gmail.com Thu Apr 1 03:22:41 2010 From: xuzhongxing at gmail.com (Zhongxing Xu) Date: Thu, 1 Apr 2010 16:22:41 +0800 Subject: [cfe-dev] Newcomer! (with patch for XFAIL no-outofbounds.c) In-Reply-To: <5f7ee204d9be59f0e6a9dc8d63270101@localhost> References: <5f7ee204d9be59f0e6a9dc8d63270101@localhost> Message-ID: The patch looks good to me. Applied in r100099. Thanks Jordy. 2010/4/1 Jordy Rose > Hello, all! I'm a Mac OS X programmer, a UC Berkeley CS undergrad, and a > newcomer to Clang, though much indebted to its faster and lower-memory > compilations and easy static analysis. I'm very interested in programming > languages and by extension compilers and analysis tools, but haven't yet > gotten the chance to work on any real projects in that area. > > I come bearing a small patch for the XFAIL test no-outofbounds.c (allow > treating single variables as arrays); the idea is to just use the size of > the atomic type to figure out the length of the "array". Not too hard. All > tests pass. > > I'm interested in doing Google Summer of Code this summer, and I'd love to > do a project for Clang. The catch is I don't yet have a solid project idea > in mind; one of my ideas was a customization scheme similar to what Sam > Harrington described a week ago. > (http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-March/008482.html) > > Hoping to pin down a full proposal by the weekend; yes, I know I'm running > behind! Anyway, I'm glad to be here and glad to be making a (small) > contribution to the project. > > Jordy Rose > _______________________________________________ > 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/20100401/9fc315a9/attachment-0001.html From xuzhongxing at gmail.com Thu Apr 1 03:39:53 2010 From: xuzhongxing at gmail.com (Zhongxing Xu) Date: Thu, 1 Apr 2010 16:39:53 +0800 Subject: [cfe-dev] Clang analyzer Google Summer of Code ideas/proposals In-Reply-To: <58d9b0e61003250918u336d4601w46c8347c6b563c24@mail.gmail.com> References: <58d9b0e61003250918u336d4601w46c8347c6b563c24@mail.gmail.com> Message-ID: Hi Samuel, I haven't thought through about what the bug database or extension script would be like. So I couldn't comment on your proposals. But I personally prefer some improvements over the current core analysis engine. For example, improve the inter-procedural analysis, add an integer overflow detector, add a more powerful constraint manager, or add C++ support, etc. 2010/3/26 Samuel Harrington > Hello, > > I am interested in doing a project with Clang in the upcoming Google > Summer of Code. I am currently a sophomore at the South Dakota School > of Mines and Technology, and I have some C++, Perl, and Javascript > programming experience. I have been interested in Clang and LLVM for a > while, and I've looked through some of the code before. I am most > interested in the analyzer component though. > > > I have two possible project ideas I am interested in: > > > A) Bug database > > Create a tool to store bugs and track changes over time. > > This tool would use the XML analyzer output and the CIndex library to > correlate bugs over multiple runs. The tool would provide, at a > minimum, a diff-like output given a pair of runs. Ideally, this would > create and update a database with all the runs, and statuses for all > the bugs (uninspected, false positive, verified, fixed). The tool > would provide reports with chosen subsets of the bugs and annotations > such as first run present and current status. The reports could be > html output, reusing the existing infrastructure, or be viewable in a > gui application. > > The database could be XML, SQLite, or some plain-text format. I am > unsure whether this tool should be integrated into the clang binary, > be a separate executable, or even use a scripting language like > Python. However it is implemented, it would be integrated into > scan-build/scan-view. > > I am interested in this project because it would make using the > analyzer easier for larger projects. The diff output could be used as > a regression finder or fix checker. The database would allow users to > keep track of bugs better, and to provide statistics of bugs over > time. > > > B) User-made checkers > > This would provide some sort of easy extension mechanism to the > analyzer to allow simple domain-specific checks. I have a couple of > ideas of how this would look. > > > 1) The first would be to read and use mygcc [1] rules to detect bugs. > I believe this would would only provide simple flow-sensitive > analysis, but it looks useful nonetheless. This would require making a > pattern matcher to match ast nodes based on a parsed text expression. > > > 2) Second, would be an interface to the analysis engines from a > scripting language, perhaps python. This would be more complicated to > use than mygcc, but likely more useful. For example, a check to make > sure open has a third parameter if the CREATE flag is present is very > simple given a scripting language, but impossible using mygcc rules > [2]. > > If I was to do this project, I would likely try to do the second idea > first, and if time permits, write a mygcc matcher in the scripting > language. Implementing mygcc rules in the scripting language would > provide a good test of the interface completeness. > > I am interested in this because the clang analyzer could be easily > extended with domain specific checks. For example, specialized locking > rules could be checked using mygcc rules. A trickier example [3] would > be to make sure a llvm::StringRef is not assigned a std::string that > goes out of scope before it. This would be possible using a scripting > language binding, and easier than modifying the Clang source. These > types of checks are already being implemented in Clang, but it is > infeasible for specialized checks for arbitrary given projects to be > embedded. This project would be a way around the problem. > > > 3) The closest tool I have seen to #2 is Dehydra [4], which also has a > goal of allowing user-defined bug finding scripts. A complicating > factor is that the scripting language is Javascript, and it may be > infeasible to provide a compatible interface. Nevertheless, I am > including replicating the interface here as a third possibility. > > > Sorry for the incredibly long email. :) > > Are either of these proposals interesting? Any criticisms, ideas? All > comments and questions would be appreciated. > > Thanks, > - Sam > > > [1] http://mygcc.free.fr/ > Note: I forget how I found this, I believe it was through an email on > this list, but I can't find it. > > [2] example taken from Clang source > lib/Checker/UnixAPIChecker.cpp > > [3] example again from an existing Clang check > lib/Checker/LLVMConventionsChecker.cpp line 133 > > [4] https://developer.mozilla.org/en/Dehydra > _______________________________________________ > 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/20100401/a3405a9c/attachment.html From etherzhhb at gmail.com Thu Apr 1 04:40:49 2010 From: etherzhhb at gmail.com (ether zhhb) Date: Thu, 1 Apr 2010 17:40:49 +0800 Subject: [cfe-dev] View graph while debugging code on windows In-Reply-To: References: Message-ID: hi, It seems that this is because llvm delete the graph file before graphviz program start. you can just comment the statements that delete this file, that work for me :P best regards --ether On Thu, Apr 1, 2010 at 4:14 PM, ?? wrote: > Hi all, > > I've been study clang for a while, and i found it's great to view some > graph (while debugging code). > Usually i use gdb under emacs and call GRExprEngine::ViewGraph(false) when > i need to see where the analysis goes. > > But i found it's faster for me to debug clang in VS, because i can see > "locals" much quickly and clearly. > > > > Here comes the problems: > > First, can i make the "-analyzer-viz-egraph-graphviz" or something like > this happen on windows? If so, how? > > Second, is there anything like "gdb call" in VS Debugging? Further, can i > make GRExprEngine::ViewGraph(false) happen while debugging clang in VS? > > I'll also appreciate it if there are any advice about debugging with gdb. > > Thanks. > > -- > Best regards! > > Lei Zhang > > _______________________________________________ > 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/20100401/47a6d45b/attachment.html From ponnala.kalyan at gmail.com Thu Apr 1 16:43:34 2010 From: ponnala.kalyan at gmail.com (kalyan ponnala) Date: Thu, 1 Apr 2010 17:43:34 -0400 Subject: [cfe-dev] How to run Regressions on windows? Message-ID: Hi, I have been trying to run the regression test on windows. I have the visual studio 2008 solution file for Clang/LLVM. Can someone who uses windows tell me how to do this. I have tried several ways which were not so fruitful. Thanks. -- Kalyan Ponnala phone: 8163772059 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100401/fdc5f1ff/attachment.html From kremenek at apple.com Thu Apr 1 17:18:39 2010 From: kremenek at apple.com (Ted Kremenek) Date: Thu, 1 Apr 2010 15:18:39 -0700 Subject: [cfe-dev] Clang analyzer Google Summer of Code ideas/proposals In-Reply-To: <58d9b0e61003250918u336d4601w46c8347c6b563c24@mail.gmail.com> References: <58d9b0e61003250918u336d4601w46c8347c6b563c24@mail.gmail.com> Message-ID: Hi Sam, I think these are all great ideas. Comments inline. On Mar 25, 2010, at 9:18 AM, Samuel Harrington wrote: > Hello, > > I am interested in doing a project with Clang in the upcoming Google > Summer of Code. I am currently a sophomore at the South Dakota School > of Mines and Technology, and I have some C++, Perl, and Javascript > programming experience. I have been interested in Clang and LLVM for a > while, and I've looked through some of the code before. I am most > interested in the analyzer component though. > > > I have two possible project ideas I am interested in: > > > A) Bug database > > Create a tool to store bugs and track changes over time. > > This tool would use the XML analyzer output and the CIndex library to > correlate bugs over multiple runs. The tool would provide, at a > minimum, a diff-like output given a pair of runs. Ideally, this would > create and update a database with all the runs, and statuses for all > the bugs (uninspected, false positive, verified, fixed). The tool > would provide reports with chosen subsets of the bugs and annotations > such as first run present and current status. The reports could be > html output, reusing the existing infrastructure, or be viewable in a > gui application. > > The database could be XML, SQLite, or some plain-text format. I am > unsure whether this tool should be integrated into the clang binary, > be a separate executable, or even use a scripting language like > Python. However it is implemented, it would be integrated into > scan-build/scan-view. > > I am interested in this project because it would make using the > analyzer easier for larger projects. The diff output could be used as > a regression finder or fix checker. The database would allow users to > keep track of bugs better, and to provide statistics of bugs over > time. I think a bug database would be extremely useful, and the ability to correlate analysis results across runs would be really powerful. Ideally the infrastructure for a bug database would be split into "backend" and "frontend" pieces, where the backend would be the core logic for processing results across runs and the frontend integration into something like scan-view. This decoupling allows the database to be potentially be reused in other contexts, e.g. a Trac plugin. One tricky aspect is dealing with correlating analysis results across an evolving codebase. The code surrounding a bug may change but the bug would be the same. This is an arbitrarily complicated problem, but correlating across runs should at least need to be not overly sensitive to line number changes, etc. > B) User-made checkers > > This would provide some sort of easy extension mechanism to the > analyzer to allow simple domain-specific checks. I have a couple of > ideas of how this would look. I think having more ways to specify domain-specific checkers would be fantastic. > > > 1) The first would be to read and use mygcc [1] rules to detect bugs. > I believe this would would only provide simple flow-sensitive > analysis, but it looks useful nonetheless. This would require making a > pattern matcher to match ast nodes based on a parsed text expression. This would be extremely useful, and this has been requested a couple times. It is also a well-scoped project, and I think it would make a great GSoC project. Part of the work would also involve relaying useful diagnostics to user as well as having acceptable performance. > 2) Second, would be an interface to the analysis engines from a > scripting language, perhaps python. This would be more complicated to > use than mygcc, but likely more useful. For example, a check to make > sure open has a third parameter if the CREATE flag is present is very > simple given a scripting language, but impossible using mygcc rules > [2]. > > If I was to do this project, I would likely try to do the second idea > first, and if time permits, write a mygcc matcher in the scripting > language. Implementing mygcc rules in the scripting language would > provide a good test of the interface completeness. > > I am interested in this because the clang analyzer could be easily > extended with domain specific checks. For example, specialized locking > rules could be checked using mygcc rules. A trickier example [3] would > be to make sure a llvm::StringRef is not assigned a std::string that > goes out of scope before it. This would be possible using a scripting > language binding, and easier than modifying the Clang source. These > types of checks are already being implemented in Clang, but it is > infeasible for specialized checks for arbitrary given projects to be > embedded. This project would be a way around the problem. This is a far more ambitious project than the mygcc support. As you say this has the potential to have a lot of impact, but there are a couple concerns that come to mind that might make this much bigger than a GSoC project: 1) The internal interface between the analyzer and the external plugin support would need to be well-defined. 2) What do you expose at the higher level? There is both syntactic information (the ASTs) and semantic information (analysis state) that can be exposed to a checker. Both sets of information are currently available to C++ checks that derive from the Checker class, and to build great checks both would need to be exposed at a higher level. There is a lot of information to expose just for the llvm::StringRef check. 3) Performance. The analyzer is very compute-intensive; will path-sensitive checks written in an external scripting language be too slow in practice when analyzing moderate to large codebases? (this isn't a conclusion, just an open question) 4) Lots of infrastructure details including data management, etc., between the analysis core and the external checker. My feeling is that this is a big project. I think the work on the mygcc support would be a great starting point, as the bulk of the logic would be on the Clang-side, and then as you get experience working with the analysis engine you can gradually "move out" of Clang's interior and have plugins that interface with the analysis core. The nice thing about tackling the smaller piece first is that (a) you would make steady progress instead of waiting for the "big feature" to get completed and (b) you will likely finish the GSoC project with a set of very usable pieces that can be used by users (even though a few big pieces that might not be finished). > 3) The closest tool I have seen to #2 is Dehydra [4], which also has a > goal of allowing user-defined bug finding scripts. A complicating > factor is that the scripting language is Javascript, and it may be > infeasible to provide a compatible interface. Nevertheless, I am > including replicating the interface here as a third possibility. Replicating DeHydra's interface might be very useful for leveraging some of its checks. One big caveat I see is that this as has the challenges of (2) but also the additional burden that you are taking both a language *and* and a checker API that someone else has already defined and then try to match it to Clang's way of doing things. I think this would be more feasible if the base infrastructure for (2) was already in place, but without it you are more at risk of not having time to finish the project. For work done on the analyzer, I'd prefer GSoC projects that brings a new feature reasonably close to being usable by others. If your project contains a set of milestones that deliver pieces of great functionality (e.g., mygcc support) on the way towards implementing some bigger feature then the project work is always a net win. I'd be happy mentoring GSoC work on any of these project ideas as long as it had this kind of trajectory. From ioripolo at gmail.com Thu Apr 1 20:05:34 2010 From: ioripolo at gmail.com (=?GB2312?B?1cLA2g==?=) Date: Fri, 2 Apr 2010 09:05:34 +0800 Subject: [cfe-dev] View graph while debugging code on windows In-Reply-To: References: Message-ID: thanks, ether. I will try that. 2010/4/1 ether zhhb > hi, > > It seems that this is because llvm delete the graph file before graphviz > program start. you can just comment the statements that delete this file, > that work for me :P > > best regards > --ether > > On Thu, Apr 1, 2010 at 4:14 PM, ???? wrote: > >> Hi all, >> >> I've been study clang for a while, and i found it's great to view some >> graph (while debugging code). >> Usually i use gdb under emacs and call GRExprEngine::ViewGraph(false) when >> i need to see where the analysis goes. >> >> But i found it's faster for me to debug clang in VS, because i can see >> "locals" much quickly and clearly. >> >> >> >> Here comes the problems: >> >> First, can i make the "-analyzer-viz-egraph-graphviz" or something like >> this happen on windows? If so, how? >> >> Second, is there anything like "gdb call" in VS Debugging? Further, can i >> make GRExprEngine::ViewGraph(false) happen while debugging clang in VS? >> >> I'll also appreciate it if there are any advice about debugging with gdb. >> >> Thanks. >> >> -- >> Best regards! >> >> Lei Zhang >> >> _______________________________________________ >> cfe-dev mailing list >> cfe-dev at cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev >> >> > -- Best regards! Lei Zhang -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100402/22eb36e0/attachment.html From daniel at zuster.org Thu Apr 1 20:43:51 2010 From: daniel at zuster.org (Daniel Dunbar) Date: Thu, 1 Apr 2010 18:43:51 -0700 Subject: [cfe-dev] How to run Regressions on windows? In-Reply-To: References: Message-ID: Just build the clang-test project? - Daniel On Thursday, April 1, 2010, kalyan ponnala wrote: > Hi, > I have been trying to run the regression test on windows. I have the visual studio 2008 solution file for Clang/LLVM. > Can someone who uses windows tell me how to do this. I have tried several ways which were not so fruitful. > > Thanks. > -- > Kalyan Ponnala > phone: 8163772059 > > From naoya.maruyama at gmail.com Thu Apr 1 21:05:40 2010 From: naoya.maruyama at gmail.com (Naoya Maruyama) Date: Fri, 2 Apr 2010 11:05:40 +0900 Subject: [cfe-dev] clang plugin Message-ID: Hi, I'm developing a c-program tool with clang, and trying the PrintFunctionNames plugin. However, running a command loading plugin libraries doesn't seem to find plugins: $ clang -cc1 -load path/to/libPrintFunctionNames.so -plugin help clang -cc1 plugins: Actually, on my different machine, the same thing does work and I can see a list of function names with the plugin. But on another machine clang seems to silently fails to load the plugin library. Could anybody please tell me how to diagnose the problem? Thanks, Naoya From ponnala.kalyan at gmail.com Thu Apr 1 21:17:00 2010 From: ponnala.kalyan at gmail.com (kalyan ponnala) Date: Thu, 1 Apr 2010 22:17:00 -0400 Subject: [cfe-dev] How to run Regressions on windows? In-Reply-To: References: Message-ID: Thanks for the reply Daniel. I tried that and I got the following errors: C:\Users...\llvm-2.7\tools\clang\test\Index\complete-at-exprstmt.m:13:15: error: expected string not found in input and similar errors in the following files: 1>Failing Tests (13): 1> Clang :: Index/code-complete-errors.c 1> Clang :: Index/code-completion.cpp 1> Clang :: Index/complete-at-directives.m 1> Clang :: Index/complete-at-exprstmt.m 1> Clang :: Index/complete-categories.m 1> Clang :: Index/complete-interfaces.m 1> Clang :: Index/complete-member-access.m 1> Clang :: Index/complete-objc-message.m 1> Clang :: Index/complete-properties.m 1> Clang :: Index/complete-property-flags.m 1> Clang :: Index/complete-property-getset.m 1> Clang :: Index/complete-protocols.m 1> Clang :: Index/complete-tabs.c 1> Expected Passes : 2073 1> Expected Failures : 17 1> Unexpected Failures: 13 1>lit.py: lit.cfg:136: note: using clang: 'C:/Users/KalyanPonnala/Documents/llvm-2.7/build/bin/Debug\\clang.EXE' 1>Project : error PRJ0019: A tool returned an error code from "Running Clang regression tests" 1>Build log was saved at "file://c:\Users\KalyanPonnala\Documents\llvm-2.7\build\tools\clang\test\clang-test.dir\Debug\BuildLog.htm" 1>clang-test - 28 error(s), 0 warning(s) ========== Build: 0 succeeded, 1 failed, 54 up-to-date, 0 skipped ========== Do you know what am I doing incorrectly. I built the llvm/clang solution file using cmake-gui. And I could build the solution file "ALL BUILD" correctly without any errors. But when I tried to build the "clang-test" target it gave the errors above. Thanks for the reply. On Thu, Apr 1, 2010 at 9:43 PM, Daniel Dunbar wrote: > Just build the clang-test project? > > - Daniel > > On Thursday, April 1, 2010, kalyan ponnala > wrote: > > Hi, > > I have been trying to run the regression test on windows. I have the > visual studio 2008 solution file for Clang/LLVM. > > Can someone who uses windows tell me how to do this. I have tried several > ways which were not so fruitful. > > > > Thanks. > > -- > > Kalyan Ponnala > > phone: 8163772059 > > > > > -- Kalyan Ponnala phone: 8163772059 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100401/f20f7985/attachment-0001.html From ihusar at fit.vutbr.cz Fri Apr 2 08:24:31 2010 From: ihusar at fit.vutbr.cz (ihusar) Date: Fri, 02 Apr 2010 15:24:31 +0200 Subject: [cfe-dev] Memory consumption measurement results, for revision 100183 In-Reply-To: <20B42DEF-081B-4218-9E05-0B2C2ECA0984@apple.com> References: <850C09A2-6029-4562-9DF1-A20FBF2732C9@apple.com> <20B42DEF-081B-4218-9E05-0B2C2ECA0984@apple.com> Message-ID: On Wed, 31 Mar 2010 18:33:08 +0200, Chris Lattner wrote: > On Mar 31, 2010, at 4:33 AM, ihusar wrote: >> so I did some memory consumption measurement and the results are as >> follows: >> >> source file size: 12MB >> resulting .bc file with debug info has 250MB >> >> clang: max. 4.8 GB >> clang -fsyntax-only: max. ~120 MB >> llvm-gcc: max. 4.1 GB >> gcc 4.4.1: max 1.4 GB >> opt -O3: max. 3.6 GB >> >> >> source file size: 24MB >> >> clang: max. 7.5 GB, stopped after 1 hour >> gcc: after 11 seconds: gcc: Internal error: Segmentation fault (program >> cc1), max. 1.4 GB > > This is interesting. I infer that these memory usage numbers are for > "clang -O0 -g"? If so, you might want to try a new build, last night > several memory and compile time improvements went in for debug info, and > more are coming. > > -Chris Hello, I made some tests for the latest revision 100183 and the memory consumption has gotten even higher compared to revision 99809. For the same 12MB file: clang (no args): 5GB clang -O0 -g0: 5GB clang -O0 -g: 6.3GB, stopped after 33 minutes opt --disable-output: 3.7 GB opt -O3 --disable-output: 3.9 GB Details can be found here: http://lissom.aps-brno.cz/tmp/clang_rev100183.xls and http://lissom.aps-brno.cz/tmp/clang_rev99809.xls I will probably solve this problem by splitting this large file into smaller ones and by buying more memory, but I think it would be at least interesting to see, what is the main reason that the memory consumption is so much higher than in gcc. Best regards Adam From daniel at zuster.org Fri Apr 2 11:57:06 2010 From: daniel at zuster.org (Daniel Dunbar) Date: Fri, 2 Apr 2010 09:57:06 -0700 Subject: [cfe-dev] How to run Regressions on windows? In-Reply-To: References: Message-ID: Ah, you are on 2.7, I'm guessing? I believe these failures are spurious, and have been fixed on top-of-trunk, but Doug might remember more. - Daniel On Thu, Apr 1, 2010 at 7:17 PM, kalyan ponnala wrote: > Thanks for the reply Daniel. I tried that and I got the following errors: > > C:\Users...\llvm-2.7\tools\clang\test\Index\complete-at-exprstmt.m:13:15: > error: expected string not found in input > and similar errors in the following files: > 1>Failing Tests (13): > 1>??? Clang :: Index/code-complete-errors.c > 1>??? Clang :: Index/code-completion.cpp > 1>??? Clang :: Index/complete-at-directives.m > 1>??? Clang :: Index/complete-at-exprstmt.m > 1>??? Clang :: Index/complete-categories.m > 1>??? Clang :: Index/complete-interfaces.m > 1>??? Clang :: Index/complete-member-access.m > 1>??? Clang :: Index/complete-objc-message.m > 1>??? Clang :: Index/complete-properties.m > 1>??? Clang :: Index/complete-property-flags.m > 1>??? Clang :: Index/complete-property-getset.m > 1>??? Clang :: Index/complete-protocols.m > 1>??? Clang :: Index/complete-tabs.c > 1>? Expected Passes??? : 2073 > 1>? Expected Failures? : 17 > 1>? Unexpected Failures: 13 > 1>lit.py: lit.cfg:136: note: using clang: > 'C:/Users/KalyanPonnala/Documents/llvm-2.7/build/bin/Debug\\clang.EXE' > 1>Project : error PRJ0019: A tool returned an error code from "Running Clang > regression tests" > 1>Build log was saved at > "file://c:\Users\KalyanPonnala\Documents\llvm-2.7\build\tools\clang\test\clang-test.dir\Debug\BuildLog.htm" > 1>clang-test - 28 error(s), 0 warning(s) > ========== Build: 0 succeeded, 1 failed, 54 up-to-date, 0 skipped ========== > > > Do you know what am I doing incorrectly. I built the llvm/clang solution > file using cmake-gui. And I could build the solution file "ALL BUILD" > correctly without any errors. But when I tried to build the "clang-test" > target it gave the errors above. > > Thanks for the reply. > > On Thu, Apr 1, 2010 at 9:43 PM, Daniel Dunbar wrote: >> >> Just build the clang-test project? >> >> ?- Daniel >> >> On Thursday, April 1, 2010, kalyan ponnala >> wrote: >> > Hi, >> > I have been trying to run the regression test on windows. I have the >> > visual studio 2008 solution file for Clang/LLVM. >> > Can someone who uses windows tell me how to do this. I have tried >> > several ways which were not so fruitful. >> > >> > Thanks. >> > -- >> > Kalyan Ponnala >> > phone: 8163772059 >> > >> > > > > > -- > Kalyan Ponnala > phone: 8163772059 > From clattner at apple.com Sat Apr 3 00:05:23 2010 From: clattner at apple.com (Chris Lattner) Date: Fri, 2 Apr 2010 22:05:23 -0700 Subject: [cfe-dev] Memory consumption measurement results, for revision 100183 In-Reply-To: References: <850C09A2-6029-4562-9DF1-A20FBF2732C9@apple.com> <20B42DEF-081B-4218-9E05-0B2C2ECA0984@apple.com> Message-ID: <624488E1-4000-4208-B003-8618EFAD6679@apple.com> On Apr 2, 2010, at 6:24 AM, ihusar wrote: > Hello, > I made some tests for the latest revision 100183 > and the memory consumption has gotten even higher compared to revision > 99809. > > For the same 12MB file: > > clang (no args): 5GB > clang -O0 -g0: 5GB > clang -O0 -g: 6.3GB, stopped after 33 minutes > opt --disable-output: 3.7 GB > opt -O3 --disable-output: 3.9 GB > > Details can be found here: > http://lissom.aps-brno.cz/tmp/clang_rev100183.xls > and http://lissom.aps-brno.cz/tmp/clang_rev99809.xls Please try again post r100261, it should substantially improve the 1.3G of bloat going from -g0 -> -g. -Chris From cmeerw at cmeerw.org Sat Apr 3 07:54:48 2010 From: cmeerw at cmeerw.org (Christof Meerwald) Date: Sat, 3 Apr 2010 14:54:48 +0200 Subject: [cfe-dev] clang plugin In-Reply-To: References: Message-ID: <20100403125448.GA2815@edge.cmeerw.net> On Fri, 2 Apr 2010 11:05:40 +0900, Naoya Maruyama wrote: > I'm developing a c-program tool with clang, and trying the > PrintFunctionNames plugin. However, running a command loading plugin > libraries doesn't seem to find plugins: > > $ clang -cc1 -load path/to/libPrintFunctionNames.so -plugin help > clang -cc1 plugins: I have come across the same problem recently. I think it's caused by the plugin shared library using its own instance of the plugin registry instead of the one from the clang binary. The way I fixed (or worked around) it on my system was by changing autoconf/ExportMap.map (and rebuilding clang) as follows: { global: main; __progname; environ; _ZN4llvm8RegistryIN5clang14FrontendActionENS_14RegistryTraitsIS2_EEE4HeadE; local: *; }; Christof -- http://cmeerw.org sip:cmeerw at cmeerw.org mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org From csdavec at swan.ac.uk Sat Apr 3 12:54:15 2010 From: csdavec at swan.ac.uk (David Chisnall) Date: Sat, 3 Apr 2010 18:54:15 +0100 Subject: [cfe-dev] Fast enumeration extension proposal Message-ID: Hi, I'd like to propose an extension to the fast enumeration behaviour for Objective-C 2. This allows you to efficiently iterate over objects in a collection, but it would also be convenient in a great many cases to use the same mechanism to iterate over things that contain collections of primitive types, such as strings. Indeed, the iteration method is conceptually very similar to the -getBytes:range: and getCharacters:range: methods on NSData and NSString, respectively. I've attached a diff (please do not commit as is!) which give a proof of concept implementation of a generalisation of fast enumeration to permit this. This generalises the method use for fast enumeration to this: - (NSUInteger)countByEnumeratingWithState: (NSFastEnumerationState*)state buffer: (void*)stackbuf type: (const char*)type count: (NSUInteger)len This replaces the the object:(id*) parameter with two arguments; one a pointer to the buffer, the other an Objective-C type encoding of a single element in the array. If you call it with something like this: for (unichar a in @"Foobar!") The first parameter will be an array of len unichars, the third element will be "S" (the type encoding of unichar, which is a typedef for unsigned short). I could add this as a GNU extension, but it would be more useful if it were supported by Apple as well. Note that this should have no impact on existing code: currently both clang and GCC raise an error with non-object element types, and my diff generates the old method for object return types. I'm also tempted to suggest generalising it still slightly further by permitting a range for enumeration to be specified (this would, of course, only be relevant for ordered collections), as this currently requires falling back to very slow enumeration. I'm not sure what the best syntax for this would be though, maybe something like: for (id a in array[1..30]) for (id a in array range 1,30) Something else? Comments, (constructive) criticisms, and suggestions welcome, David -------------- next part -------------- A non-text attachment was scrubbed... Name: fenum.m Type: application/octet-stream Size: 1931 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100403/20626cc5/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: clang.diff Type: application/octet-stream Size: 3770 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100403/20626cc5/attachment-0001.obj -------------- next part -------------- -- Sent from my Difference Engine From bruce.cran at gmail.com Sat Apr 3 13:17:24 2010 From: bruce.cran at gmail.com (Bruce Cran) Date: Sat, 3 Apr 2010 19:17:24 +0100 Subject: [cfe-dev] Fwd: Precompiled headers error with clang++ 2.7-r96348 In-Reply-To: References: <9b136f541003060207j3ba0aa2dj4666dbb7a3136466@mail.gmail.com> <717CBB8E-793E-4CFE-8A50-7293EC3A3D31@apple.com> Message-ID: Forwarding to the list... ---------- Forwarded message ---------- From: Bruce Cran Date: 3 April 2010 19:14 Subject: Re: [cfe-dev] Precompiled headers error with clang++ 2.7-r96348 To: Douglas Gregor I think I've figured out what's causing the problem. The Makefile Qt generates outputs the precompiled header to obj/helloworldpch.gch/c++ and then passes obj/helloworldpch to clang++. It seems clang++ tries to open obj/helloworldpch.gch as a file and fails. -- Bruce On 29 March 2010 16:33, Douglas Gregor wrote: > > On Mar 6, 2010, at 2:07 AM, Bruce Cran wrote: > >> Hi, >> >> I'm trying to use precompiled headers when building a C++ application >> on amd64 FreeBSD using llvm 2.7 r96348, >> but even with a simple "hello world" application I'm getting the error: >> >> error: invalid or corrupt PTH file 'obj/helloworldpch.gch' >> Assertion failed: (P && "No PTHManager."), function >> AddImplicitIncludePTH, file InitPreprocessor.cpp, line 85. >> >> I've put the test application at >> http://www.cran.org.uk/~brucec/freebsd/helloworldpch.tar.gz - I'm >> trying to >> build it using "gmake CXX=clang++". > > Unfortunately, I am not able to use this tarball to reproduce the problem you're seeing, since I don't have a FreeBSD system with Qt on it. I did a quick test with "precompiled headers" for C++ here: > > blackthorn:clang dgregor$ cat std.h > #include > #include > #include > > blackthorn:clang dgregor$ clang++ -x c++-header std.h > blackthorn:clang dgregor$ ls -l std.h* > -rw-r--r-- ?1 dgregor ?staff ? ? ? 53 Mar 29 08:25 std.h > -rw-r--r-- ?1 dgregor ?staff ?1550000 Mar 29 08:29 std.h.gch > blackthorn:clang dgregor$ cat main.cpp > #include "std.h" > > int main() { > ?std::vector v; > } > > blackthorn:clang dgregor$ clang++ -include std.h main.cpp > blackthorn:clang dgregor$ > > and it works fine for me. That means we either fixed something since you sent your note, or that your makefile is using precompiled headers in some way that is broken/unsupported/different from what we've seen. Could you try again, and if it's still broken, get down to a simpler test case I can reproduce? > >> Do precompiled headers work with clang++ yet? > > > Yes and no. Precompiled headers themselves are not implemented for C++ yet, so the precompiled header syntax for C++ (with -include, -x c++-header, etc.) actually maps down to Clang's pretokenized headers, which are language-agnostic. Pretokenized headers don't give quite the same performance improvements that precompiled headers do, but they work now. > > ? ? ? ?- Doug From blaine at apple.com Sat Apr 3 19:32:16 2010 From: blaine at apple.com (Blaine Garst) Date: Sat, 3 Apr 2010 17:32:16 -0700 Subject: [cfe-dev] Fast enumeration extension proposal In-Reply-To: References: Message-ID: <9C2ED4E2-4A21-41A8-9F1E-D8FB03439C07@apple.com> Just some quick feedback. The Fast Enumeration protocol was directly driven by the need to simplify and improve access to the dominant-by-choice "collection" in Cocoa: the NSArray. We built it to be blindingly fast. And yet we also built in knowledge of particular protocols, which have Cocoa expression instead of ObjC, so its slightly sullied from a language viewpoint in that the ObjC protocol isn't widely used, but a Cocoa equivalent is. The issue with extending the existing protocol, as you propose, is that there are an arbitrary number of extensions possible, and each would require adoption by appropriate classes. Protocols are much heavier than method with blocks, and so we like the lighter weight on principle. Blocks are very efficient, but they do require a function call cost per item which, well, can be a lot depending on the application. Ripping through unichars would seem like possibly something done so often, and with somewhat tricky API, to warrant special treatment, as you suggest. However, unichars aren't what you think they are, in that several unichars are needed to represent some concepts, there are sex-change markers, etc. and hence the very studied complexity of the NSString implementation. So I honestly think your proposal would run into conceptual difficulties if presented within Apple's Cocoa engineering team, as an Apple Developer sonar request. This forum is not suitable for those discussions. Other suggestions for extensions to NSFastEnumeration have been to rip through language arrays, for example. This is wonderful if array size information is available to the compiler, which on occasion it is, then formal language treatment offers a significantly better programmer experience since it reduces or eliminates bounds errors. Supplying bounds by hand offers no language benefit other than a fancy syntax to distinguish a special use case - not really interesting. However, more on the for ( int a in intarray) line of thinking without the need for new protocols is interesting. That might, in fact, meet your criteria. Since this is a quick reply there is of course the possibility I haven't thought deeply enough about your suggestion, so please feel free to sign up as a developer and continue to argue your case some more when it involves Cocoa. Blaine On Apr 3, 2010, at 10:54 AM, David Chisnall wrote: > Hi, > > I'd like to propose an extension to the fast enumeration behaviour for Objective-C 2. This allows you to efficiently iterate over objects in a collection, but it would also be convenient in a great many cases to use the same mechanism to iterate over things that contain collections of primitive types, such as strings. Indeed, the iteration method is conceptually very similar to the -getBytes:range: and getCharacters:range: methods on NSData and NSString, respectively. > > I've attached a diff (please do not commit as is!) which give a proof of concept implementation of a generalisation of fast enumeration to permit this. This generalises the method use for fast enumeration to this: > > - (NSUInteger)countByEnumeratingWithState: (NSFastEnumerationState*)state > buffer: (void*)stackbuf > type: (const char*)type > count: (NSUInteger)len > > This replaces the the object:(id*) parameter with two arguments; one a pointer to the buffer, the other an Objective-C type encoding of a single element in the array. If you call it with something like this: > > for (unichar a in @"Foobar!") > > The first parameter will be an array of len unichars, the third element will be "S" (the type encoding of unichar, which is a typedef for unsigned short). > > I could add this as a GNU extension, but it would be more useful if it were supported by Apple as well. Note that this should have no impact on existing code: currently both clang and GCC raise an error with non-object element types, and my diff generates the old method for object return types. > > I'm also tempted to suggest generalising it still slightly further by permitting a range for enumeration to be specified (this would, of course, only be relevant for ordered collections), as this currently requires falling back to very slow enumeration. I'm not sure what the best syntax for this would be though, maybe something like: > > for (id a in array[1..30]) > > for (id a in array range 1,30) > > Something else? > > Comments, (constructive) criticisms, and suggestions welcome, > > David > > > > -- Sent from my Difference Engine > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From harrrrpo at gmail.com Sun Apr 4 07:08:17 2010 From: harrrrpo at gmail.com (Mohamed Yousef) Date: Sun, 4 Apr 2010 14:08:17 +0200 Subject: [cfe-dev] Source to Source Transformation guide lines Message-ID: Hello, I'm working in a project involving source to source transformation of some arbitrary c code , i'm looking forward to using Clang my main problem is where to start , i can find approx. no documentation on topic 1) how complete is the CIndex interface , what limitations can it impose ? 2) any existing source to source applications based on clang that can be of help as a starting point ? 3) can the LLVM Kaleidoscope lessons be of help in understanding how to use clang libraries ? Thanks, Mohamed Yousef -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100404/4dd5f2f3/attachment.html From wlynch at wlynch.cx Sun Apr 4 22:29:38 2010 From: wlynch at wlynch.cx (William Lynch) Date: Sun, 4 Apr 2010 22:29:38 -0500 Subject: [cfe-dev] clang plugin In-Reply-To: <20100403125448.GA2815@edge.cmeerw.net> References: <20100403125448.GA2815@edge.cmeerw.net> Message-ID: On Sat, Apr 3, 2010 at 7:54 AM, Christof Meerwald wrote: > On Fri, 2 Apr 2010 11:05:40 +0900, Naoya Maruyama wrote: >> I'm developing a c-program tool with clang, and trying the >> PrintFunctionNames plugin. However, running a command loading plugin >> libraries doesn't seem to find plugins: >> >> ?$ clang -cc1 -load path/to/libPrintFunctionNames.so -plugin help >> clang -cc1 plugins: > > I have come across the same problem recently. I think it's caused by the > plugin shared library using its own instance of the plugin registry instead > of the one from the clang binary. The way I fixed (or worked around) it on > my system was by changing autoconf/ExportMap.map (and rebuilding clang) as > follows: Just to verify though, shouldn't the following command print out the builtin plugins? Curently, on trunk, I'm seeing no plugins listed. $ clang -cc1 -plugin help Thanks. From daniel at zuster.org Sun Apr 4 22:47:51 2010 From: daniel at zuster.org (Daniel Dunbar) Date: Sun, 4 Apr 2010 20:47:51 -0700 Subject: [cfe-dev] clang plugin In-Reply-To: References: <20100403125448.GA2815@edge.cmeerw.net> Message-ID: On Sun, Apr 4, 2010 at 8:29 PM, William Lynch wrote: > On Sat, Apr 3, 2010 at 7:54 AM, Christof Meerwald wrote: >> On Fri, 2 Apr 2010 11:05:40 +0900, Naoya Maruyama wrote: >>> I'm developing a c-program tool with clang, and trying the >>> PrintFunctionNames plugin. However, running a command loading plugin >>> libraries doesn't seem to find plugins: >>> >>> ?$ clang -cc1 -load path/to/libPrintFunctionNames.so -plugin help >>> clang -cc1 plugins: >> >> I have come across the same problem recently. I think it's caused by the >> plugin shared library using its own instance of the plugin registry instead >> of the one from the clang binary. The way I fixed (or worked around) it on >> my system was by changing autoconf/ExportMap.map (and rebuilding clang) as >> follows: > > Just to verify though, shouldn't the following command print out the > builtin plugins? Curently, on trunk, I'm seeing no plugins listed. > > $ clang -cc1 -plugin help That only prints the loaded plugins. There is no automatic plugin loading, so unless you specify -load, nothing will be loaded. - Daniel > > Thanks. > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > From daniel at zuster.org Sun Apr 4 22:49:28 2010 From: daniel at zuster.org (Daniel Dunbar) Date: Sun, 4 Apr 2010 20:49:28 -0700 Subject: [cfe-dev] clang plugin In-Reply-To: <20100403125448.GA2815@edge.cmeerw.net> References: <20100403125448.GA2815@edge.cmeerw.net> Message-ID: On Sat, Apr 3, 2010 at 5:54 AM, Christof Meerwald wrote: > On Fri, 2 Apr 2010 11:05:40 +0900, Naoya Maruyama wrote: >> I'm developing a c-program tool with clang, and trying the >> PrintFunctionNames plugin. However, running a command loading plugin >> libraries doesn't seem to find plugins: >> >> ?$ clang -cc1 -load path/to/libPrintFunctionNames.so -plugin help >> clang -cc1 plugins: > > I have come across the same problem recently. I think it's caused by the > plugin shared library using its own instance of the plugin registry instead > of the one from the clang binary. The way I fixed (or worked around) it on > my system was by changing autoconf/ExportMap.map (and rebuilding clang) as > follows: > > { > ? ? ? ?global: main; > ? ? ? ? ? ? ? ?__progname; > ? ? ? ? ? ? ? ?environ; > ? ? ? ? ? ? ? ?_ZN4llvm8RegistryIN5clang14FrontendActionENS_14RegistryTraitsIS2_EEE4HeadE; > > ? ? ? ?local: *; > }; > Yes, unfortunately the plugin mechanism is currently limited & confusing because of how we handle symbol exports. I'm tempted to just remove the current example and recommend people follow the clang-interpreter example instead, until someone takes the plugin mechanism and really makes it robust & usable. Any objections? - Daniel > Christof > > -- > > http://cmeerw.org ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?sip:cmeerw at cmeerw.org > mailto:cmeerw at cmeerw.org ? ? ? ? ? ? ? ? ? xmpp:cmeerw at cmeerw.org > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > From jyasskin at google.com Mon Apr 5 03:19:03 2010 From: jyasskin at google.com (Jeffrey Yasskin) Date: Mon, 5 Apr 2010 01:19:03 -0700 Subject: [cfe-dev] Patch to make CXXScopeSpecs invalid when they refer to incomplete classes Message-ID: I have a patch at http://codereview.appspot.com/890041 which has Sema::RequireCompleteDeclContext(CXXScopeSpec &SS) mark SS as invalid when it refers to an incomplete type. It's pretty ugly because it makes lots of parameters non-const, and it breaks one test in way I'm not sure how to fix, but it also removes several redundant errors. Is this the right approach to avoid diagnosing "invalid_type::foo" multiple times? If so, I'll track down the temp.explicit/p3.cpp failure and mail the working patch. Otherwise, what's the better way to fix it? Thanks, Jeffrey From mtzrgb at gmail.com Mon Apr 5 03:48:12 2010 From: mtzrgb at gmail.com (moataz ragab) Date: Mon, 5 Apr 2010 10:48:12 +0200 Subject: [cfe-dev] Source to Source Transformation guide lines In-Reply-To: References: Message-ID: Hi, I haven't used CIndex so I can't help you on that, but others of course can help. To get started, take a look at clang/lib/Frontend/RewriteObjC.cpp. This code rewrites objc to C. There are two approaches for tsource-to-source transformation (Rewriting, AST re-build). Im the Rewriting approach the AST is traversed and the transformed code is generated as you traverse the AST, this is what is used in RewriteObjC. The other approach is to build the transformed AST from the original AST and then use the prettyprinter to generate the code. This approach is flexible and allows you to apply a chain of transformations on the AST. You can copy the Clang main file and start your tool under clang/tools. Try to trace the main file to know how the ObjC rewritter is invoked. Hope this helps, Moataz On Sun, Apr 4, 2010 at 2:08 PM, Mohamed Yousef wrote: > Hello, > > I'm working in a project involving source to source transformation of some > arbitrary c code , i'm looking forward to using Clang > my main problem is where to start , i can find approx. no documentation on > topic > > 1) how complete is the CIndex interface , what limitations can it impose ? > > 2) any existing source to source applications based on clang that can be of > help as a starting point ? > > 3) can the LLVM Kaleidoscope lessons be of help in understanding how to use > clang libraries ? > > Thanks, > Mohamed Yousef > > _______________________________________________ > 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/20100405/cb9e9860/attachment.html From anton at korobeynikov.info Mon Apr 5 07:19:07 2010 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Mon, 5 Apr 2010 16:19:07 +0400 Subject: [cfe-dev] **Important**: GSoC 2010 Message-ID: Dear prospective GSoC students! Please submit your proposals to GSoC webapp system **now**. The deadline won't be extended this year as it was last few years. Even if your application is not completed yet and you're still collecting comments in llvm-dev, please do it! Just indicate, that your application is still in progress. You will be able to refine it later answering to review comments, etc. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From dgregor at apple.com Mon Apr 5 09:09:50 2010 From: dgregor at apple.com (Douglas Gregor) Date: Mon, 5 Apr 2010 07:09:50 -0700 Subject: [cfe-dev] Patch to make CXXScopeSpecs invalid when they refer to incomplete classes In-Reply-To: References: Message-ID: <691E277E-AE21-4386-8F66-CA0A1B1463CB@apple.com> Hi Jeffrey, On Apr 5, 2010, at 1:19 AM, Jeffrey Yasskin wrote: > I have a patch at http://codereview.appspot.com/890041 which has > Sema::RequireCompleteDeclContext(CXXScopeSpec &SS) mark SS as invalid > when it refers to an incomplete type. It's pretty ugly because it > makes lots of parameters non-const, and it breaks one test in way I'm > not sure how to fix, but it also removes several redundant errors. > > Is this the right approach to avoid diagnosing "invalid_type::foo" > multiple times? If so, I'll track down the temp.explicit/p3.cpp > failure and mail the working patch. Otherwise, what's the better way > to fix it? Yes, this is the right approach to avoid multiply diagnostics when the nested-name-specifier has an incomplete type. Thanks for working on this! - Doug From dgregor at apple.com Mon Apr 5 10:13:56 2010 From: dgregor at apple.com (Douglas Gregor) Date: Mon, 5 Apr 2010 08:13:56 -0700 Subject: [cfe-dev] Source to Source Transformation guide lines In-Reply-To: References: Message-ID: <4DF415BC-3FBB-4ECE-A5E6-154D52B1108D@apple.com> On Apr 4, 2010, at 5:08 AM, Mohamed Yousef wrote: > Hello, > > I'm working in a project involving source to source transformation of some arbitrary c code , i'm looking forward to using Clang > my main problem is where to start , i can find approx. no documentation on topic > > 1) how complete is the CIndex interface , what limitations can it impose ? It's relatively complete for cross-referencing C code, but it does not have enough coverage of Clang's APIs for real source-to-source transformation. We'd like CIndex to move in that direction, but we're not there yet. - Doug From clattner at apple.com Mon Apr 5 10:37:02 2010 From: clattner at apple.com (Chris Lattner) Date: Mon, 05 Apr 2010 08:37:02 -0700 Subject: [cfe-dev] Fwd: RFC: c++ diagnostics References: <20100405082033.7a9bcf81@redhat.com> Message-ID: FYI, a very useful resource. -Chris Begin forwarded message: > From: Benjamin Kosnik > Date: April 5, 2010 8:20:33 AM PDT > To: libstdc++ at gcc.gnu.org, gcc at gcc.gnu.org > Subject: RFC: c++ diagnostics > > > Hello all! > > I've put up a short diagnostics comparison between gcc, icc, and > clang. It is my plan to update this with major revisions to individual > compilers. > > Included are most of the outstanding bugzilla requests with the > "diagnostic" keyword. However, I am looking for help! Please send me > code samples that frustrate, obfuscate, and annoy. > > In particular, I am looking for template instantiation issues such as > c++/41884, but hopefully something in a deliciously small snippet. No > doubt other C++ hackers have particular annoyances. > > I'm also looking for guidance on how to rank the priority of these > issues. Is there some way to tell what the biggest annoyance is? > > http://people.redhat.com/bkoz/diagnostics/diagnostics.html > > best, > benjamin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100405/d8ba4fa1/attachment-0001.html From dgregor at apple.com Mon Apr 5 10:57:50 2010 From: dgregor at apple.com (Douglas Gregor) Date: Mon, 5 Apr 2010 08:57:50 -0700 Subject: [cfe-dev] Fwd: RFC: c++ diagnostics In-Reply-To: References: <20100405082033.7a9bcf81@redhat.com> Message-ID: On Apr 5, 2010, at 8:37 AM, Chris Lattner wrote: > FYI, a very useful resource. This one, in particular, could use some help: http://people.redhat.com/bkoz/diagnostics/diagnostics.html#9335 Anyone want to contribute a patch to suppress some template instantiation contexts when there are too many? - Doug > -Chris > > Begin forwarded message: > >> From: Benjamin Kosnik >> Date: April 5, 2010 8:20:33 AM PDT >> To: libstdc++ at gcc.gnu.org, gcc at gcc.gnu.org >> Subject: RFC: c++ diagnostics >> >> >> Hello all! >> >> I've put up a short diagnostics comparison between gcc, icc, and >> clang. It is my plan to update this with major revisions to individual >> compilers. >> >> Included are most of the outstanding bugzilla requests with the >> "diagnostic" keyword. However, I am looking for help! Please send me >> code samples that frustrate, obfuscate, and annoy. >> >> In particular, I am looking for template instantiation issues such as >> c++/41884, but hopefully something in a deliciously small snippet. No >> doubt other C++ hackers have particular annoyances. >> >> I'm also looking for guidance on how to rank the priority of these >> issues. Is there some way to tell what the biggest annoyance is? >> >> http://people.redhat.com/bkoz/diagnostics/diagnostics.html >> >> best, >> benjamin > _______________________________________________ > 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/20100405/812d95b6/attachment.html From clattner at apple.com Mon Apr 5 11:37:58 2010 From: clattner at apple.com (Chris Lattner) Date: Mon, 5 Apr 2010 09:37:58 -0700 Subject: [cfe-dev] Fwd: RFC: c++ diagnostics In-Reply-To: References: <20100405082033.7a9bcf81@redhat.com> Message-ID: On Apr 5, 2010, at 8:57 AM, Douglas Gregor wrote: > > On Apr 5, 2010, at 8:37 AM, Chris Lattner wrote: > >> FYI, a very useful resource. > > This one, in particular, could use some help: > > http://people.redhat.com/bkoz/diagnostics/diagnostics.html#9335 > > Anyone want to contribute a patch to suppress some template instantiation contexts when there are too many? Yeah, that one is particularly bad, I filed it as PR6781. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100405/59715546/attachment.html From lattner at apple.com Mon Apr 5 11:56:23 2010 From: lattner at apple.com (Tanya Lattner) Date: Mon, 5 Apr 2010 09:56:23 -0700 Subject: [cfe-dev] 2.7 still has regressions Message-ID: <7EC86F62-6B58-4247-BF56-94D7EEAD365E@apple.com> All, We need to get all regressions fixed before 2.7 can continue onto pre-release2. Please take a look at all release blockers: http://llvm.org/bugs/show_bug.cgi?id=6586 At this point, the release is delayed until further notice. If no bugs get fixed this week, then I see no other solution but to cancel the release or only qualify it for darwin (the only platform that is regression free). Linux developers, please help us out. We need more people fixing bugs! -Tanya -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100405/ff7aa291/attachment.html From herrold at owlriver.com Mon Apr 5 13:22:14 2010 From: herrold at owlriver.com (R P Herrold) Date: Mon, 5 Apr 2010 14:22:14 -0400 (EDT) Subject: [cfe-dev] 2.7 still has regressions In-Reply-To: <7EC86F62-6B58-4247-BF56-94D7EEAD365E@apple.com> References: <7EC86F62-6B58-4247-BF56-94D7EEAD365E@apple.com> Message-ID: On Mon, 5 Apr 2010, Tanya Lattner wrote: > All, > > We need to get all regressions fixed before 2.7 can continue onto pre-release2. > > Please take a look at all release blockers: > http://llvm.org/bugs/show_bug.cgi?id=6586 > > At this point, the release is delayed until further notice. If no bugs get fixed this week, then I see no other solution but to cancel the release or only qualify it for darwin (the only platform that is regression free). > > Linux developers, please help us out. We need more people fixing bugs! Umm -- The remaining blocker bugs in that ticket are: 6616 - warnings -- not a bar to release as I understood the release criteria 6654 - a mish-mash of issues in a single bug, some seemingly related to deficiencies in the test suite code assignments 6696 - as I read it, a grey area as to proper behaviour, and not really a Linux issue so much as a correctness as to alignment issue under x86-64 6725 - a possible optional test, either proposed as blocking or non-blocking 6778 - a Darwin issue as to Fortran test coverage I don't see that segmenting the release's scope to Darwin only is either accurate, nor that Darwin buildout is without regressions -- Russ herrold From lattner at apple.com Mon Apr 5 13:31:19 2010 From: lattner at apple.com (Tanya Lattner) Date: Mon, 5 Apr 2010 11:31:19 -0700 Subject: [cfe-dev] 2.7 still has regressions In-Reply-To: References: <7EC86F62-6B58-4247-BF56-94D7EEAD365E@apple.com> Message-ID: <8C190B10-3370-4BCF-B08C-4AAC2B694D05@apple.com> On Apr 5, 2010, at 11:22 AM, R P Herrold wrote: > On Mon, 5 Apr 2010, Tanya Lattner wrote: > >> All, >> >> We need to get all regressions fixed before 2.7 can continue onto pre-release2. >> >> Please take a look at all release blockers: >> http://llvm.org/bugs/show_bug.cgi?id=6586 >> >> At this point, the release is delayed until further notice. If no bugs get fixed this week, then I see no other solution but to cancel the release or only qualify it for darwin (the only platform that is regression free). >> >> Linux developers, please help us out. We need more people fixing bugs! > > Umm -- The remaining blocker bugs in that ticket are: > 6616 - warnings -- not a bar to release as I understood the release criteria They are. We release without warnings. > 6654 - a mish-mash of issues in a single bug, some seemingly related to deficiencies in the test suite code assignments These are all valid regressions. Sure, its in a single bug (which I asked it to be separated out), but still they are regressions. > 6696 - as I read it, a grey area as to proper behaviour, and not really a Linux issue so much as a correctness as to alignment issue under x86-64 Its still a regression. The problem itself may not be Linux specific, but it was only found on Linux on that test case. > 6725 - a possible optional test, either proposed as blocking or non-blocking It was declared a release blocker. > 6778 - a Darwin issue as to Fortran test coverage > > I don't see that segmenting the release's scope to Darwin only is either accurate, nor that Darwin buildout is without regressions > Darwin is currently compiling without warnings or errors. It also has no regressions in the test-suite or dejagnu test suite for both clang and llvm-gcc. So by our release criteria, it is currently the only platform that is regression free. I'd like Linux to be ready to release too, but if no one is helping fix bugs, then there isnt much I can do about it. Please help fix what you can. Thanks, Tanya -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100405/11fcb5bf/attachment.html From martin at martincmartin.com Mon Apr 5 15:06:14 2010 From: martin at martincmartin.com (Martin C.Martin) Date: Mon, 05 Apr 2010 16:06:14 -0400 Subject: [cfe-dev] Once I have an AST, how do I compile it? Message-ID: <4BBA42B6.3010803@martincmartin.com> I've managed to create a test program, included below for the curious, which creates a super simple AST corresponding to "void foo() { }". What do I call to generate code from it? Any pointers on what classes/files to look at? Best, Martin #include "clang/Frontend/CompilerInstance.h" #include "clang/Frontend/TextDiagnosticBuffer.h" #include "clang/Basic/TargetInfo.h" #include "clang/AST/ASTContext.h" #include "clang/Parse/Scope.h" #include "clang/Lex/Preprocessor.h" #include "llvm/LLVMContext.h" #include "llvm/Target/TargetSelect.h" using namespace clang; using namespace std; int main(int argc, char **argv) { CompilerInstance MyCI; MyCI.setLLVMContext(new llvm::LLVMContext); llvm::InitializeAllTargets(); llvm::InitializeAllAsmPrinters(); TextDiagnosticBuffer DiagsBuffer; Diagnostic Diags(&DiagsBuffer); CompilerInvocation::CreateFromArgs(MyCI.getInvocation(), NULL, NULL, Diags); // Create the actual diagnostics engine. MyCI.createDiagnostics(0, NULL); if (!MyCI.hasDiagnostics()) return 1; MyCI.createSourceManager(); MyCI.createFileManager(); // Create the target instance. MyCI.setTarget(TargetInfo::CreateTargetInfo(MyCI.getDiagnostics(), MyCI.getTargetOpts())); MyCI.createPreprocessor(); MyCI.getPreprocessor(); MyCI.createASTContext(); // ************ Initialization finished. Now time for the fun. ASTContext &context = MyCI.getASTContext(); DeclContext *DC = context.getTranslationUnitDecl(); IdentifierInfo &info = MyCI.getPreprocessor().getIdentifierTable().get("foo"); DeclarationName myname(&info); FunctionDecl *fd = FunctionDecl::Create(context, DC, SourceLocation(), myname, context.DoubleTy, NULL, FunctionDecl::None, /* isInline = */ false, /* hasPrototype = */ false); } From eli.friedman at gmail.com Mon Apr 5 15:58:53 2010 From: eli.friedman at gmail.com (Eli Friedman) Date: Mon, 5 Apr 2010 13:58:53 -0700 Subject: [cfe-dev] Once I have an AST, how do I compile it? In-Reply-To: <4BBA42B6.3010803@martincmartin.com> References: <4BBA42B6.3010803@martincmartin.com> Message-ID: On Mon, Apr 5, 2010 at 1:06 PM, Martin C.Martin wrote: > I've managed to create a test program, included below for the curious, > which creates a super simple AST corresponding to "void foo() { }". > What do I call to generate code from it? ?Any pointers on what > classes/files to look at? Call CreateLLVMCodeGen in include/clang/CodeGen/ModuleBuilder.h to get an ASTConsumer, then call the appropriate APIs (see include/clang/AST/ASTConsumer.h) to make it generate code. -Eli From naoya.maruyama at gmail.com Mon Apr 5 16:55:37 2010 From: naoya.maruyama at gmail.com (Naoya Maruyama) Date: Tue, 6 Apr 2010 06:55:37 +0900 Subject: [cfe-dev] clang plugin In-Reply-To: References: <20100403125448.GA2815@edge.cmeerw.net> Message-ID: Thanks Christof. Changing ExportMap.map as you told does solve my problem. I personally like the plugin mechanism. It's much simpler for AST analysis and also seems much faster to compile a plugin library than to compile and link clang executables like clang-interpreter. Thanks, Naoya On Mon, Apr 5, 2010 at 12:49 PM, Daniel Dunbar wrote: > On Sat, Apr 3, 2010 at 5:54 AM, Christof Meerwald wrote: >> On Fri, 2 Apr 2010 11:05:40 +0900, Naoya Maruyama wrote: >>> I'm developing a c-program tool with clang, and trying the >>> PrintFunctionNames plugin. However, running a command loading plugin >>> libraries doesn't seem to find plugins: >>> >>> ?$ clang -cc1 -load path/to/libPrintFunctionNames.so -plugin help >>> clang -cc1 plugins: >> >> I have come across the same problem recently. I think it's caused by the >> plugin shared library using its own instance of the plugin registry instead >> of the one from the clang binary. The way I fixed (or worked around) it on >> my system was by changing autoconf/ExportMap.map (and rebuilding clang) as >> follows: >> >> { >> ? ? ? ?global: main; >> ? ? ? ? ? ? ? ?__progname; >> ? ? ? ? ? ? ? ?environ; >> ? ? ? ? ? ? ? ?_ZN4llvm8RegistryIN5clang14FrontendActionENS_14RegistryTraitsIS2_EEE4HeadE; >> >> ? ? ? ?local: *; >> }; >> > > Yes, unfortunately the plugin mechanism is currently limited & > confusing because of how we handle symbol exports. I'm tempted to just > remove the current example and recommend people follow the > clang-interpreter example instead, until someone takes the plugin > mechanism and really makes it robust & usable. Any objections? > > ?- Daniel > >> Christof >> >> -- >> >> http://cmeerw.org ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?sip:cmeerw at cmeerw.org >> mailto:cmeerw at cmeerw.org ? ? ? ? ? ? ? ? ? xmpp:cmeerw at cmeerw.org >> _______________________________________________ >> 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 jediknil at belkadan.com Mon Apr 5 20:02:24 2010 From: jediknil at belkadan.com (Jordy Rose) Date: Mon, 05 Apr 2010 18:02:24 -0700 Subject: [cfe-dev] GSoC Proposal: Buffer Message-ID: <8c5358680b4a3b8ddde5f34244ee20cd@localhost> Hi, all. I am a third-year CS undergrad at UC Berkeley, and I'm interested in doing a Google Summer of Code project for Clang. My primary programming experience is in Mac OS X programming, but I've also done work in several other languages. During the last two summers I interned at Apple, first in the AppKit frameworks group and then in the Xcode group. As part of the first internship, I worked on modifying the Regex component of the ICU libraries to use the ICU abstract type UText, rather than requiring the use of UTF-16 arrays. (The final version of this is planned for ICU 4.6.) In my "spare time", I write little utilities for OS X, which are available at http://belkadan.com. Clang and its static analyzer have been great to have for OS X programming, but it wasn't until last week that I actually got involved. I submitted a patch to fix one XFAILing test (Analysis/no-outofbounds.c), then spent the weekend working out an understanding of another (PCH/source-manager-stack.c), unfortunately without coming up with a good answer. Even so, my main focus of interest is on programming languages and on /how/ people program, which makes Clang a very promising project! My project proposal is to make buffer handling much smarter, particularly for char* strings. Currently a snippet like this won't even warn under checker analysis (unless I missed some flags): char buf[5], shortBuf[2]; memcpy(buf, shortBuf, 2); // copy of uninitialized values strcpy(buf, "12345"); // overflow gets(buf); // overflow (?) / Bad Idea strncpy(buf, "12345", 6); // overflow strcpy("12345", buf); // copy into a const buffer The fix is twofold. First, to add attributes requiring buffer contents to be defined, specifying that a given procedure will (or won't) modify a buffer (similar to C++ const). This is relatively simple and similar to other sorts of analysis warnings currently provided by the analyzer. The second part of the fix is to add bounds-tracking to buffers. That is, it should be possible to catch cases like this: char *buf = malloc(i); buf[i] = '\0'; Adding this to string handling procedures (such as strncpy()) could catch plenty of errors. If this functionality is exposed as a source-level annotation, this could catch all sorts of potential buffer overflows. The project would proceed in three stages: 1. Add initialization state checking for functions like memcpy, strcpy, fgets, etc. which either initialize the buffer or require an initialized buffer. 2. Allow buffer sizes (and possibly any integer expressions) to be bounded above and below, instead of just fixed, not-equal, or unknown. This would even include related parameters (e.g. the length of argv is argc+1). 3. Time permitting, allow bounds to be path-based. "Time" here refers both to "time during the summer" and "analysis time for a potentially exponential operation". This seems like a useful feature both for new programmers and for hardening existing codebases. What makes it interesting, though, is the possibility of source-level annotations, e.g. declaring that a function requires a buffer to be initialized. Any comments, suggestions, etc? If no one finds this interesting, I am also interested in the documentation project listed on the "Open Projects" page. (I wrote a toy documentation generator several years ago.) While I'm not as intrigued by this project, it would be useful to have documentation be able to take advantage of scoping rules. Of course, it would also be a great help to not have the documentation tool lagging behind the compiler concerning language changes. Apologies for the very long e-mail, and thanks! Jordy Rose From ponnala.kalyan at gmail.com Mon Apr 5 20:39:23 2010 From: ponnala.kalyan at gmail.com (kalyan ponnala) Date: Mon, 5 Apr 2010 21:39:23 -0400 Subject: [cfe-dev] for loop unrolling Message-ID: Hi, I was trying to step through the code for the following FOR loop. When I printed out the IR for some program with this FOR loop, it actually unrolled the loop. I could not see this when I tried to step through the code. Can someone tell me where to put the breakpoints to see how this loop is unrolled. And is there any way to tell it not to unroll the code? for (i=0; i< 10; i++) { a[i] = i ; } Thanks. -- Kalyan Ponnala phone: 8163772059 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100405/61ea00ea/attachment-0001.html From anton.yartsev at gmail.com Mon Apr 5 22:13:16 2010 From: anton.yartsev at gmail.com (Anton Yartsev) Date: Tue, 06 Apr 2010 07:13:16 +0400 Subject: [cfe-dev] AltiVec support with remarks considered Message-ID: <4BBAA6CC.3020708@Gmail.com> Hi all, Attached are the header and the patch giving support for all the predicates and a portion of another AltiVec functions. The test is also attached. 'altivec.h' is now included implicitly when '-faltivec' option is set. Only vital builtins are handled by clang, others are supported via header. Please review. -- Anton -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: altivec.h Url: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100406/852ff464/attachment-0001.h -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: altivec.patch Url: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100406/852ff464/attachment-0001.pl -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: builtins-pcc-altivec.c Url: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100406/852ff464/attachment-0001.c From clattner at apple.com Tue Apr 6 01:36:03 2010 From: clattner at apple.com (Chris Lattner) Date: Mon, 5 Apr 2010 23:36:03 -0700 Subject: [cfe-dev] blog post about clang diagnostics Message-ID: <04D5D109-E348-47D4-A3F9-702B83ABAAC6@apple.com> FYI, it's been too long since we've had a blog post, so I wrote this up tonight: http://blog.llvm.org/2010/04/amazing-feats-of-clang-error-recovery.html Thoughts and comments welcome! -Chris From magnus.reftel at gmail.com Tue Apr 6 04:23:53 2010 From: magnus.reftel at gmail.com (Magnus Reftel) Date: Tue, 6 Apr 2010 11:23:53 +0200 Subject: [cfe-dev] Source to Source Transformation guide lines In-Reply-To: References: Message-ID: Hi, On 5 April 2010 10:48, moataz ragab wrote: > There are two approaches for tsource-to-source > transformation (Rewriting, AST re-build). Im the Rewriting approach the AST > is traversed and the transformed code is generated as you traverse the AST, > this is what is used in RewriteObjC. The other approach is to build the > transformed AST from the original AST and then use the prettyprinter to > generate the code. This approach is flexible and allows you to apply a chain > of transformations on the AST. There is a third option as well: traverse the AST and make notes of changes that need to be made and where, and then search-and-replace in the source text (e.g. by alternating between coying from the source and from a modification to a new file). I used that with good results for a tool that did some fancy search-and-replace on hand-written code that will stay maintained by humans. The only problem I've run into is that getting the actual source position for something can be tricky (but possible) when it's a macro. Best Regards Magnus Reftel From martin at martincmartin.com Tue Apr 6 11:02:17 2010 From: martin at martincmartin.com (Martin C.Martin) Date: Tue, 06 Apr 2010 12:02:17 -0400 Subject: [cfe-dev] Once I have an AST, how do I compile it? In-Reply-To: References: <4BBA42B6.3010803@martincmartin.com> Message-ID: <4BBB5B09.4070109@martincmartin.com> On 4/5/2010 4:58 PM, Eli Friedman wrote: > On Mon, Apr 5, 2010 at 1:06 PM, Martin C.Martin > wrote: >> I've managed to create a test program, included below for the curious, >> which creates a super simple AST corresponding to "void foo() { }". >> What do I call to generate code from it? Any pointers on what >> classes/files to look at? > > Call CreateLLVMCodeGen in include/clang/CodeGen/ModuleBuilder.h to get > an ASTConsumer, then call the appropriate APIs (see > include/clang/AST/ASTConsumer.h) to make it generate code. > > -Eli Thanks Eli. What's the memory contract? Should I call delete on CreateLLVMCodeGen()'s value when I'm done with it? Best, Martin From eli.friedman at gmail.com Tue Apr 6 14:32:13 2010 From: eli.friedman at gmail.com (Eli Friedman) Date: Tue, 6 Apr 2010 12:32:13 -0700 Subject: [cfe-dev] Once I have an AST, how do I compile it? In-Reply-To: <4BBB5B09.4070109@martincmartin.com> References: <4BBA42B6.3010803@martincmartin.com> <4BBB5B09.4070109@martincmartin.com> Message-ID: On Tue, Apr 6, 2010 at 9:02 AM, Martin C.Martin wrote: > On 4/5/2010 4:58 PM, Eli Friedman wrote: >> >> On Mon, Apr 5, 2010 at 1:06 PM, Martin C.Martin >> ?wrote: >>> >>> I've managed to create a test program, included below for the curious, >>> which creates a super simple AST corresponding to "void foo() { }". >>> What do I call to generate code from it? ?Any pointers on what >>> classes/files to look at? >> >> Call CreateLLVMCodeGen in include/clang/CodeGen/ModuleBuilder.h to get >> an ASTConsumer, then call the appropriate APIs (see >> include/clang/AST/ASTConsumer.h) to make it generate code. >> >> -Eli > > Thanks Eli. ?What's the memory contract? ?Should I call delete on > CreateLLVMCodeGen()'s value when I'm done with it? Yes, delete to clean up (or use an llvm::OwningPtr). -Eli From Tim_Agnew at playstation.sony.com Tue Apr 6 17:57:37 2010 From: Tim_Agnew at playstation.sony.com (Tim_Agnew at playstation.sony.com) Date: Tue, 6 Apr 2010 15:57:37 -0700 Subject: [cfe-dev] Fw: Welcome to the "cfe-dev" mailing list Message-ID: Please post the following paid internship information to the cfe-dev mailing list Software Engineering Intern: Systems Technology Group The Worldwide Studios System Technology Group is offering a paid Engineering Internship! Job Description: Be a part of the most exciting and innovative computer entertainment in North America. Sony Computer Entertainment America (SCEA) markets the PlayStation? family of products and develops, publishes, markets, and distributes software for the PlayStation?3, and the PlayStation Portable (PSP?) computer entertainment systems. Based in Foster City, California, SCEA serves as headquarters for all North American operations and is a wholly owned subsidiary of Sony Computer Entertainment Inc. Job Responsibilities: The STG Intern will work on a variety of projects for internal and external developers working with the PlayStation platforms. Work on these projects may be directed, solo engineering efforts, or as part of a project team. Example projects include: Contributing code to existing test harnesses. Contributing code to PC based tools for PlayStation platforms. Contributing code to the open source GNU binutils assembler and gold linker. Contributing code to the open source LLVM compiler framework and Clang. Skills Required: C, C++ proficiency Excellent communication skills Bachelor in Computer Science (or in progress) Debugging techniques of concurrently programmed applications Proficiency in one or more of the following areas a strong plus: Assembly programming Multithreaded programming Multi-core programming Compiler optimizations Compiler parsing and semantic analysis Daily tasks can include: Research and follow changes in assigned software tools and technologies; Explore opportunities for use with SCEA technology. Partner with project teams to provide feedback and promote relationships. This position is located in Foster City CA, and is open to both graduate and undergraduate students. Do you think you might be just the person we are looking for? If so, apply now! Get your career in the gaming industry off to a great start with Sony Computer Entertainment America. (SCEA) It is the policy of Sony Computer Entertainment America, Inc. (SCEA) to provide equal employment opportunity for all applicants and employees. SCEA does not unlawfully discriminate on the basis of race, color, religion, sex, national origin, age, handicap, veteran status, marital status, or any other category protected by applicable federal and state law. SCEA also makes reasonable accommodations for handicapped and disabled employees. ----- Forwarded by Tim Agnew/HR/SCEA on 04/06/2010 03:56 PM ----- cfe-dev-request at cs.uiuc.edu Sent by: cfe-dev-bounces at cs.uiuc.edu 04/06/2010 03:49 PM To Tim Agnew/HR/SCEA at PLAYSTATION cc Subject Welcome to the "cfe-dev" mailing list Welcome to the cfe-dev at cs.uiuc.edu mailing list! To post to this list, send your email to: cfe-dev at cs.uiuc.edu General information about the mailing list is at: http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev If you ever want to unsubscribe or change your options (eg, switch to or from digest mode, change your password, etc.), visit your subscription page at: http://lists.cs.uiuc.edu/mailman/options/cfe-dev/tim_agnew%40playstation.sony.com You can also make such adjustments via email by sending a message to: cfe-dev-request at cs.uiuc.edu with the word `help' in the subject or body (don't include the quotes), and you will get back a message with instructions. You must know your password to change your options (including changing the password, itself) or to unsubscribe. It is: iswaigab Normally, Mailman will remind you of your cs.uiuc.edu mailing list passwords once every month, although you can disable this if you prefer. This reminder will also include instructions on how to unsubscribe or change your account options. There is also a button on your options page that will email your current password to you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100406/3f1a49b5/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 12688 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100406/3f1a49b5/attachment-0001.gif From xuzhongxing at gmail.com Tue Apr 6 21:16:06 2010 From: xuzhongxing at gmail.com (Zhongxing Xu) Date: Wed, 7 Apr 2010 10:16:06 +0800 Subject: [cfe-dev] wrong comment? Message-ID: Index: include/clang/AST/Expr.h =================================================================== --- include/clang/AST/Expr.h (?? 100519) +++ include/clang/AST/Expr.h (????) @@ -2362,7 +2362,7 @@ virtual child_iterator child_end(); }; -/// VAArgExpr, used for the builtin function __builtin_va_start. +/// VAArgExpr, used for the builtin function __builtin_va_arg. class VAArgExpr : public Expr { Stmt *Val; SourceLocation BuiltinLoc, RParenLoc; @@ -2373,7 +2373,7 @@ BuiltinLoc(BLoc), RParenLoc(RPLoc) { } - /// \brief Create an empty __builtin_va_start expression. + /// \brief Create an empty __builtin_va_arg expression. explicit VAArgExpr(EmptyShell Empty) : Expr(VAArgExprClass, Empty) { } const Expr *getSubExpr() const { return cast(Val); } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100407/9ad27ae8/attachment.html From clattner at apple.com Tue Apr 6 22:34:00 2010 From: clattner at apple.com (Chris Lattner) Date: Tue, 6 Apr 2010 20:34:00 -0700 Subject: [cfe-dev] wrong comment? In-Reply-To: References: Message-ID: <503C57BD-DF0A-4038-A183-6633C812E771@apple.com> Yep, please commit! On Apr 6, 2010, at 7:16 PM, Zhongxing Xu wrote: > Index: include/clang/AST/Expr.h > =================================================================== > --- include/clang/AST/Expr.h (?? 100519) > +++ include/clang/AST/Expr.h (????) > @@ -2362,7 +2362,7 @@ > virtual child_iterator child_end(); > }; > > -/// VAArgExpr, used for the builtin function __builtin_va_start. > +/// VAArgExpr, used for the builtin function __builtin_va_arg. > class VAArgExpr : public Expr { > Stmt *Val; > SourceLocation BuiltinLoc, RParenLoc; > @@ -2373,7 +2373,7 @@ > BuiltinLoc(BLoc), > RParenLoc(RPLoc) { } > > - /// \brief Create an empty __builtin_va_start expression. > + /// \brief Create an empty __builtin_va_arg expression. > explicit VAArgExpr(EmptyShell Empty) : Expr(VAArgExprClass, Empty) { } > > const Expr *getSubExpr() const { return cast(Val); } > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From cdavis at mymail.mines.edu Wed Apr 7 00:46:09 2010 From: cdavis at mymail.mines.edu (Charles Davis) Date: Tue, 06 Apr 2010 23:46:09 -0600 Subject: [cfe-dev] Fwd: SoC 2010 Proposal Message-ID: <4BBC1C21.7030506@mymail.mines.edu> Oops, wrong mailing list... -------- Original Message -------- Subject: SoC 2010 Proposal Date: Tue, 06 Apr 2010 23:45:39 -0600 From: Charles Davis To: LLVM Developers Mailing List Here's my SoC 2010 proposal. I submitted it a long time ago (last week, to be precise), but didn't post it to the list. You can review it here: http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/cdavis/t127000394358 Chip From cdavis at mymail.mines.edu Wed Apr 7 11:47:31 2010 From: cdavis at mymail.mines.edu (Charles Davis) Date: Wed, 07 Apr 2010 10:47:31 -0600 Subject: [cfe-dev] Fwd: SoC 2010 Proposal In-Reply-To: References: <4BBC1C21.7030506@mymail.mines.edu> Message-ID: <4BBCB723.9070400@mymail.mines.edu> On 4/7/10 10:36 AM, John Regehr wrote: > It doesn't appear to be readable. That is because I didn't make it public. In hindsight, I probably should have, but I can't now because I already submitted it. Maybe I could copy the proposal to a text file and send it to the list... Chip From cdavis at mymail.mines.edu Wed Apr 7 11:51:55 2010 From: cdavis at mymail.mines.edu (Charles Davis) Date: Wed, 07 Apr 2010 10:51:55 -0600 Subject: [cfe-dev] SoC 2010 Proposal (that you can read, this time) Message-ID: <4BBCB82B.7030609@mymail.mines.edu> Here's my SoC 2010 proposal. You can read it this time, because I've attached it to this message. Chip -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SoC2010Proposal.txt Url: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100407/8bf01bb9/attachment.txt From st at invia.fr Wed Apr 7 14:45:06 2010 From: st at invia.fr (Sylvere Teissier) Date: Wed, 07 Apr 2010 21:45:06 +0200 Subject: [cfe-dev] [PATCH] options -ffunction-sections and -fdata-sections Message-ID: <4BBCE0C2.4090809@invia.fr> Hi, This is a patch that implements "-ffunction-sections" and "-fdata-sections" options. These options place each functions and data into its own section in the output file. Currently it works only for elf format backend, for other object formats these options are ignored. This patch is separated for clang tree and llvm tree. -------------- next part -------------- A non-text attachment was scrubbed... Name: function-data-sections.patch Type: text/x-patch Size: 6008 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100407/74767b10/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: function-data-sections-clang.patch Type: text/x-patch Size: 3959 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100407/74767b10/attachment-0001.bin From anton at korobeynikov.info Wed Apr 7 15:07:46 2010 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Thu, 8 Apr 2010 00:07:46 +0400 Subject: [cfe-dev] [PATCH] options -ffunction-sections and -fdata-sections In-Reply-To: <4BBCE0C2.4090809@invia.fr> References: <4BBCE0C2.4090809@invia.fr> Message-ID: Hello, Sylvere > Currently it works only for elf format backend, for other object formats > these options are ignored. First of all, please honor the LLVM coding style (or, at least, the code style of the source files you're modifying). Second, I belive the approach used is wrong - there is already way to emit objects into separate sections, which is used for linkonce objects, you just need to hook in there. No need to reinvent the wheel :) -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From lattner at apple.com Wed Apr 7 16:29:19 2010 From: lattner at apple.com (Tanya Lattner) Date: Wed, 7 Apr 2010 14:29:19 -0700 Subject: [cfe-dev] 2.7 Release Status Message-ID: All, Thanks for those who have been helping fix regressions and warnings. Your hard work is appreciated and you have made great progress! Thank you again. The release is getting close. As a reminder, this is the master bug: http://llvm.org/bugs/show_bug.cgi?id=6586 In particular, we have one bug that needs attention: http://llvm.org/bugs/show_bug.cgi?id=6660 These are regressions in the testsuite using clang. This is x86 32bit Linux. If anyone can lend a hand for this bug, please do so! Hopefully, once this bug is resolved we can move onto pre-release2. Thanks, Tanya P.S. There is also a gfortran bug on Darwin, but it may not be a release blocker. But if we can get it fixed before pre-release2 goes out, that would be very very nice. Take a look if you can help: http://llvm.org/bugs/show_bug.cgi?id=6778 From st at invia.fr Wed Apr 7 17:25:40 2010 From: st at invia.fr (Sylvere Teissier) Date: Thu, 08 Apr 2010 00:25:40 +0200 Subject: [cfe-dev] [PATCH] options -ffunction-sections and -fdata-sections In-Reply-To: References: <4BBCE0C2.4090809@invia.fr> Message-ID: <4BBD0664.6030102@invia.fr> Anton Korobeynikov wrote: > Hello, Sylvere > > >> Currently it works only for elf format backend, for other object formats >> these options are ignored. >> > First of all, please honor the LLVM coding style (or, at least, the > code style of the source files you're modifying). > Ok, I have checked this point, I hope it's ok now > Second, I belive the approach used is wrong - there is already way to > emit objects into separate sections, which > is used for linkonce objects, you just need to hook in there. No need > to reinvent the wheel :) > Thanks for the tip, I've changed my patch using the existing code. But I use different section names than gnu.linkonce when It's not "WeakForLinker" because gnu.linkonce.* are special sections. (I try to follow GCC section naming for -ffunction-sections/-fdata-sections) -------------- next part -------------- A non-text attachment was scrubbed... Name: function-data-sections-clang.patch Type: text/x-patch Size: 4000 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100408/76cae99e/attachment-0002.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: function-data-sections-llvm.patch Type: text/x-patch Size: 4772 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100408/76cae99e/attachment-0003.bin From clattner at apple.com Wed Apr 7 17:32:15 2010 From: clattner at apple.com (Chris Lattner) Date: Wed, 7 Apr 2010 15:32:15 -0700 Subject: [cfe-dev] [PATCH] options -ffunction-sections and -fdata-sections In-Reply-To: <4BBD0664.6030102@invia.fr> References: <4BBCE0C2.4090809@invia.fr> <4BBD0664.6030102@invia.fr> Message-ID: On Apr 7, 2010, at 3:25 PM, Sylvere Teissier wrote: > Anton Korobeynikov wrote: >> Hello, Sylvere >> >> >>> Currently it works only for elf format backend, for other object formats >>> these options are ignored. >>> >> First of all, please honor the LLVM coding style (or, at least, the >> code style of the source files you're modifying). >> > Ok, I have checked this point, I hope it's ok now >> Second, I belive the approach used is wrong - there is already way to >> emit objects into separate sections, which >> is used for linkonce objects, you just need to hook in there. No need >> to reinvent the wheel :) >> > Thanks for the tip, I've changed my patch using the existing code. But I use different section names than gnu.linkonce when It's not "WeakForLinker" > because gnu.linkonce.* are special sections. (I try to follow GCC section naming for -ffunction-sections/-fdata-sections) Hi Sylvere, I agree that they can't be happen with linkonce linkage... but this should be handled in the backend, not in the frontend. TargetLoweringObjectFileELF::SelectSectionForGlobal is in charge of picking the section to use of a global, can you put this logic there? -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100407/9bf8a7f7/attachment.html From samuel.harrington at mines.sdsmt.edu Wed Apr 7 17:40:05 2010 From: samuel.harrington at mines.sdsmt.edu (Samuel Harrington) Date: Wed, 7 Apr 2010 16:40:05 -0600 Subject: [cfe-dev] Clang analyzer Google Summer of Code ideas/proposals In-Reply-To: References: <58d9b0e61003250918u336d4601w46c8347c6b563c24@mail.gmail.com> Message-ID: On Thu, Apr 1, 2010 at 4:18 PM, Ted Kremenek wrote: > Hi Sam, > > I think these are all great ideas. ?Comments inline. > > On Mar 25, 2010, at 9:18 AM, Samuel Harrington wrote: >> ... >> B) User-made checkers >> >> This would provide some sort of easy extension mechanism to the >> analyzer to allow simple domain-specific checks. I have a couple of >> ideas of how this would look. > > I think having more ways to specify domain-specific checkers would be fantastic. > >> >> >> 1) The first would be to read and use mygcc [1] rules to detect bugs. >> I believe this would would only provide simple flow-sensitive >> analysis, but it looks useful nonetheless. This would require making a >> pattern matcher to match ast nodes based on a parsed text expression. > > This would be extremely useful, and this has been requested a couple times. ?It is also a well-scoped project, and I think it would make a great GSoC project. ?Part of the work would also involve relaying useful diagnostics to user as well as having acceptable performance. ... > For work done on the analyzer, I'd prefer GSoC projects that brings a new feature reasonably close to being usable by others. ?If your project contains a set of milestones that deliver pieces of great functionality (e.g., mygcc support) on the way towards implementing some bigger feature then the project work is always a net win. ?I'd be happy mentoring GSoC work on any of these project ideas as long as it had this kind of trajectory. Thanks for your comments! I've submitted a formal proposal to implement mygcc rules, visible at: http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/samlh/t127053978725 I have also attached it in text form. Any further comments or questions would be appreciated. My primary concern is whether the proposed matching method is acceptable. I hope this proposal is clear, complete, and interesting! Thanks, Samuel Harrington -------------- next part -------------- Samuel Harrington MyGCC rules for the Clang Analyzer ================================== Me -- I am currently a sophomore at the South Dakota School of Mines and Technology studying Mechanical Engineering and Computer Science. I have some C/C++, Perl, Javascript, and Prolog programming experience. I have been interested in Clang and LLVM since I read an LWN article comment mentioning LLVM, and I've submitted a minor patch to Clang. I have read the Clang mailing list since 2008, and more recently subscibed to the commits list as well. I am most interested in the analyzer component. Project Summary --------------- This project would provide an easy extension mechanism to the Clang Analyzer to allow simple domain-specific checks. The analyzer would gain the ability to read and use mygcc [1] rules. Mygcc rules are "constrained reachability queries" of the form "from A to B avoid C". Mygcc rules were first implemented as a patch to gcc. The matching rules are in the form of code with %A style wildcards. These rules can be checked in linear time, and provide sufficient flexibility to create useful checks. Details ------- Mygcc implements its matching by unparsing the Abstract Syntax Tree of a statement, and matching it textually against the matching rules. The pros of this approach is that you do not need to parse the pattern in order to match against it. This is very useful because the addition of wildcards adds additional ambiguities to an already ambiguous language. The cons are that it depends on the exact pretty-printing of the AST, and requires the user to know what the pretty-printing is. In addition, it does not allow isomorphisms to be detected. An alternative is to parse the pattern as C/C++ code (with wildcards) and create a bytecode/tree representation to match against. The pros of this approach are that the patterns can be independent of the ast format, and it is easier to implement isomorphisms in this form. The con is primarily that parsing C/C++ with the addition of wildcards is significantly harder than without, and Clang has already devoted significant time to the simpler approach. Given the alternatives, I have decided it would be best to implement the approach mygcc uses. Rules originally implemented for mygcc may not be exactly interoperable due to differences in ASTs between GCC and Clang, but I believe this approach is the most pragmatic and likely to be effective. The checker must: * find all the "from" matches * find all paths from the "from" matches to "to" matches, avoiding matching the "avoid" matches * if an avoid rule is an assertion, ensure that the assertion does not match any conditionals along the path The required components are the Matcher and the Finder. The Matcher will be a class that, given a statement, rules to check, and current wildcard values, finds all the matches. For each match, it also stores what values the wildcards must take on. When matching a rule with already bound wildcards, the Matcher must ensure that if the wildcard references a variable, it has not changed since the last time it was matched. The Matcher uses a technique called 'unparsed patterns' [2] for the user patterns. Unparsed patterns work by incrementally unparsing the AST. This technique is known to have linear match time, but needs parenthesis in rare situations. Despite this limitation, it is substantially easier than other approaches, both to use (no need to limit syntax to a subset), and to implement (no need to parse the pattern). The Finder uses the Matcher and the following algorithm to find the bugs: 1. Find all "from" matches 2. For each "from" match, find all paths that end by matching the "to" rule, without matching the "avoid" rules. The Matcher will use the already existing pretty-printer. Further details on the matching algorithm can be found in [2]. The Finder will use the existing flow-sensitive analysis infrastructure. Further details on its algorithm can be found at [3]. Milestones ---------- Dates TBD 1. Be able to match expressions with no wildcards 2. Be able to match rules with only "from" parts and no wildcards 3. Be able to match rules with only "from" parts with anonymous wildcards or named wildcards only appearing once 4. Be able to match rules with only "from" parts with named wildcards appearing multiple times 5. Be able to match rules with only "from", "to", and "avoid" parts with named wildcards appearing multiple times, but not including positive or negative assertions 6. Be able to match rules with only "from", "to", and "avoid" parts with named wildcards appearing multiple times, with assertions in the "avoid" parts MyGCC Rule example ------------------ condate double_lock { from "lock(%L)" to "lock(%L)" avoid "unlock(%L)" } warning("Lock L is locked twice"); References ---------- [1] http://mygcc.free.fr/ [2] http://mypatterns.free.fr/unparsed/unparsed-pepm08-extended.pdf [3] http://mygcc.free.fr/condate-asej07.pdf From st at invia.fr Thu Apr 8 03:43:09 2010 From: st at invia.fr (Sylvere Teissier) Date: Thu, 08 Apr 2010 10:43:09 +0200 Subject: [cfe-dev] [PATCH] options -ffunction-sections and -fdata-sections In-Reply-To: References: <4BBCE0C2.4090809@invia.fr> <4BBD0664.6030102@invia.fr> Message-ID: <4BBD971D.8020806@invia.fr> Chris Lattner a ?crit : > > On Apr 7, 2010, at 3:25 PM, Sylvere Teissier wrote: > > Hi Sylvere, > > I agree that they can't be happen with linkonce linkage... but this > should be handled in the backend, not in the frontend. > TargetLoweringObjectFileELF::SelectSectionForGlobal is in charge of > picking the section to use of a global, can you put this logic there? > > -Chris Hi Chris, Perhaps I don't understand correctly your remark but that's what this patch does: The function TargetLoweringObjectFileELF::SelectSectionForGlobal is modified. There are 2 patchs: 1 for llvm tree and 1 for clang tree. From dmp at rice.edu Thu Apr 8 10:34:09 2010 From: dmp at rice.edu (David Peixotto) Date: Thu, 8 Apr 2010 10:34:09 -0500 Subject: [cfe-dev] Clang macro expansion differs from GCC Message-ID: <4F1B53BA-DEA5-46DB-BAC5-F1921D832B63@rice.edu> I have found a discrepancy in behavior between the clang preprocessor and gcc. $ cat t.c #define X 0 .. 1 0 .. 1 // Ok X // Bad: space between .. $ gcc -E t.c 0 .. 1 0 .. 1 $ clang -E t.c 0 .. 1 0 . . 1 The problem is that when ".." is in the macro and the macro gets expanded, it adds a space between the dots. As you can see, the space is not added when the ".." is entered directly in the text. GCC does not insert a space in either case. I'm not sure this qualifies as a bug, but the reason I need this to work is that I am trying to compile GHC (a Haskell compiler) with clang. It uses GCC to preprocess c-- files (http://www.cminusminus.org) before parsing them and ".." is a valid operator in c--. Adding the extra space messes up the subsequent parsing phase. I'd be happy to take a look at fixing this myself if someone could point me in the right direction. Thanks! -Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100408/0ea310a0/attachment.html From clattner at apple.com Thu Apr 8 11:48:47 2010 From: clattner at apple.com (Chris Lattner) Date: Thu, 8 Apr 2010 09:48:47 -0700 Subject: [cfe-dev] Clang macro expansion differs from GCC In-Reply-To: <4F1B53BA-DEA5-46DB-BAC5-F1921D832B63@rice.edu> References: <4F1B53BA-DEA5-46DB-BAC5-F1921D832B63@rice.edu> Message-ID: <079BB2A4-126C-4C92-90C0-DF99CA1AEBEE@apple.com> On Apr 8, 2010, at 8:34 AM, David Peixotto wrote: > I have found a discrepancy in behavior between the clang preprocessor and gcc. > > $ cat t.c > #define X 0 .. 1 > > 0 .. 1 // Ok > X // Bad: space between .. > > $ gcc -E t.c > > > 0 .. 1 > 0 .. 1 > > $ clang -E t.c > > > 0 .. 1 > 0 . . 1 > > The problem is that when ".." is in the macro and the macro gets expanded, it adds a space between the dots. As you can see, the space is not added when the ".." is entered directly in the text. GCC does not insert a space in either case. > > I'm not sure this qualifies as a bug, but the reason I need this to work is that I am trying to compile GHC (a Haskell compiler) with clang. It uses GCC to preprocess c-- files (http://www.cminusminus.org) before parsing them and ".." is a valid operator in c--. Adding the extra space messes up the subsequent parsing phase. Hi David, I'm not particularly interested in fixing this: people abusing the C preprocessor to preprocess things that aren't C don't get much sympathy from me. However, if you are able to produce a patch that works, doesn't break anything else, and doesn't affect performance, I'd be happy to apply it. > > I'd be happy to take a look at fixing this myself if someone could point me in the right direction. lib/Frontend/PrintPreprocessedOutput.cpp is the code that outputs a .i file, the "AvoidConcat" stuff is what you want. It is what decides to add spaces to prevent three . tokens from looking like a ... for example. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100408/be33662a/attachment-0001.html From dmp at rice.edu Thu Apr 8 12:41:39 2010 From: dmp at rice.edu (David Peixotto) Date: Thu, 8 Apr 2010 12:41:39 -0500 Subject: [cfe-dev] Clang macro expansion differs from GCC In-Reply-To: <079BB2A4-126C-4C92-90C0-DF99CA1AEBEE@apple.com> References: <4F1B53BA-DEA5-46DB-BAC5-F1921D832B63@rice.edu> <079BB2A4-126C-4C92-90C0-DF99CA1AEBEE@apple.com> Message-ID: Hi Chris, Thanks for the quick response. On Apr 8, 2010, at 11:48 AM, Chris Lattner wrote: > On Apr 8, 2010, at 8:34 AM, David Peixotto wrote: > >> I have found a discrepancy in behavior between the clang preprocessor and gcc. >> > > Hi David, > > I'm not particularly interested in fixing this: people abusing the C preprocessor to preprocess things that aren't C don't get much sympathy from me. However, if you are able to produce a patch that works, doesn't break anything else, and doesn't affect performance, I'd be happy to apply it. I can fully understand your position on this point. I thought I'd report it since the behavior was different than GCC and did prevent clang from being used as a drop-in replacement. > >> >> I'd be happy to take a look at fixing this myself if someone could point me in the right direction. > > > lib/Frontend/PrintPreprocessedOutput.cpp is the code that outputs a .i file, the "AvoidConcat" stuff is what you want. It is what decides to add spaces to prevent three . tokens from looking like a ... for example. Great, thanks for the pointer. I'll take a look and if I can come up with something reasonable, I will send a patch. -Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100408/516f045a/attachment.html From mtzrgb at gmail.com Thu Apr 8 21:58:55 2010 From: mtzrgb at gmail.com (moataz ragab) Date: Fri, 9 Apr 2010 04:58:55 +0200 Subject: [cfe-dev] Chaining multiple AST consumers Message-ID: Hi, I would like to pre-process the AST before I do actual analysis on it. For example I would like to normalize loops first. I have three solutions in mind 1) I know that I can write the AST to a file after processing and read it again. But that will make the process complicated and slower 2) I can add the code as separate functions in the ASTConsumer that I will use but that will limit the reusability of the loop normalization. 3) I can make loop normalization code in a StmtVisitor and call it when I reach function body. but that will make a separate traversal of the AST tree. 4) Make a separate ASTConsumer. but in this case I need to enable ParseAST to handle multiple consumers (maybe by passing a vector of the ASTConsumers) and having ParseAST call them one after the other but that will require modifying the Clang builtin function ParseAST plus I am not sure if there might be other issues involved (Do I have to worry about the context? I am not changing the types) Is option 4 a viable option? Do you have another option? Thanks, Moataz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100409/d832b94b/attachment.html From mtzrgb at gmail.com Thu Apr 8 22:13:33 2010 From: mtzrgb at gmail.com (moataz ragab) Date: Fri, 9 Apr 2010 05:13:33 +0200 Subject: [cfe-dev] Chaining multiple AST consumers In-Reply-To: References: Message-ID: Kindly ignore option 4. After rethinking it doesn't make sense. On Fri, Apr 9, 2010 at 4:58 AM, moataz ragab wrote: > Hi, > > I would like to pre-process the AST before I do actual analysis on it. For > example I would like to normalize loops first. I have three solutions in > mind > > 1) I know that I can write the AST to a file after processing and read it > again. But that will make the process complicated and slower > 2) I can add the code as separate functions in the ASTConsumer that I will > use but that will limit the reusability of the loop normalization. > 3) I can make loop normalization code in a StmtVisitor and call it when I > reach function body. but that will make a separate traversal of the AST > tree. > 4) Make a separate ASTConsumer. but in this case I need to enable ParseAST > to handle multiple consumers (maybe by passing a vector of the ASTConsumers) > and having ParseAST call them one after the other but that will require > modifying the Clang builtin function ParseAST plus I am not sure if there > might be other issues involved (Do I have to worry about the context? I am > not changing the types) > > Is option 4 a viable option? Do you have another option? > > Thanks, > Moataz > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100409/413b8ea1/attachment.html From simonhf at gmail.com Thu Apr 8 14:22:42 2010 From: simonhf at gmail.com (Simon) Date: Thu, 8 Apr 2010 12:22:42 -0700 Subject: [cfe-dev] newbie wants to do round-trip, source to source C parsing Message-ID: Hello! I discovered clang from this thread: http://stackoverflow.com/questions/239722/ast-from-c-code The example link in the thread describing how to perform 'source to source' parsing and re-writing using clang doesn't work anymore :-( Can anybody give links and/or hints and tips on how to do this and where to start? Thanks, Simon From wan at google.com Thu Apr 8 23:18:57 2010 From: wan at google.com (=?UTF-8?B?WmhhbnlvbmcgV2FuICjOu3gueCB4KQ==?=) Date: Thu, 8 Apr 2010 21:18:57 -0700 Subject: [cfe-dev] failed to build llvm using cmake Message-ID: Hi, I'm at Clang/LLVM r100846. According to http://google1.osuosl.org:8011/console, it's a good revision for Linux. However I'm having trouble building it using cmake. Here's what did: cd my_llvm_checkout_root mkdir mybuild cd mybuild cmake .. make I got: ... Linking CXX executable ../../bin/llvm-mc CMakeFiles/llvm-mc.dir/Disassembler.cpp.o: In function `verboseEvaluator(unsigned long*, unsigned int, void*)': Disassembler.cpp:(.text+0x14b): undefined reference to `EDGetRegisterName' Disassembler.cpp:(.text+0x1af): undefined reference to `EDRegisterIsStackPointer' Disassembler.cpp:(.text+0x1db): undefined reference to `EDRegisterIsProgramCounter' CMakeFiles/llvm-mc.dir/Disassembler.cpp.o: In function `llvm::Disassembler::disassembleEnhanced(std::basic_string, std::allocator > const&, llvm::MemoryBuffer&)': Disassembler.cpp:(.text+0x824): undefined reference to `EDGetDisassembler' Disassembler.cpp:(.text+0x8aa): undefined reference to `EDCreateInsts' Disassembler.cpp:(.text+0x8e0): undefined reference to `EDNumTokens' Disassembler.cpp:(.text+0x928): undefined reference to `EDGetToken' Disassembler.cpp:(.text+0x961): undefined reference to `EDGetTokenString' Disassembler.cpp:(.text+0x9aa): undefined reference to `EDOperandIndexForToken' Disassembler.cpp:(.text+0x9db): undefined reference to `EDTokenIsWhitespace' Disassembler.cpp:(.text+0xa06): undefined reference to `EDTokenIsPunctuation' Disassembler.cpp:(.text+0xa31): undefined reference to `EDTokenIsOpcode' Disassembler.cpp:(.text+0xa59): undefined reference to `EDTokenIsLiteral' Disassembler.cpp:(.text+0xa81): undefined reference to `EDTokenIsRegister' Disassembler.cpp:(.text+0xaeb): undefined reference to `EDTokenIsLiteral' Disassembler.cpp:(.text+0xb15): undefined reference to `EDTokenIsNegativeLiteral' Disassembler.cpp:(.text+0xb3f): undefined reference to `EDLiteralTokenAbsoluteValue' Disassembler.cpp:(.text+0xb98): undefined reference to `EDTokenIsRegister' Disassembler.cpp:(.text+0xbc2): undefined reference to `EDRegisterTokenValue' Disassembler.cpp:(.text+0xc5a): undefined reference to `EDNumOperands' Disassembler.cpp:(.text+0xcc1): undefined reference to `EDGetOperand' Disassembler.cpp:(.text+0xd02): undefined reference to `EDEvaluateOperand' collect2: ld returned 1 exit status make[2]: *** [bin/llvm-mc] Error 1 make[1]: *** [tools/llvm-mc/CMakeFiles/llvm-mc.dir/all] Error 2 make: *** [all] Error 2 Am I missing something? Or is the cmake script broken? My cmake version is 2.6.4. I'm using Linux. Thanks, -- Zhanyong From wingusr at gmail.com Fri Apr 9 03:44:20 2010 From: wingusr at gmail.com (TP) Date: Fri, 9 Apr 2010 01:44:20 -0700 Subject: [cfe-dev] Trying to use CLang / CLang Static Analyzer under Windows XP SP3 32-bit Message-ID: I'm trying to get CLang to run so that I can try out the CLang Static Analyzer. I followed the instructions given in the "Using Visual Studio" section of http://clang.llvm.org/get_started.html. The ALL_BUILD Project built fine in Visual Studio 2008. But when I try the first example I get: >clang t.c clang: error: unable to execute command: program not executable clang: error: assembler command failed due to signal 1 (use -v to see invocation) >clang -v t.c clang version 1.5 (trunk 100852) Target: i686-pc-win32 Thread model: posix "C:/llvm/bin/Debug/clang.exe" -cc1 -triple i686-pc-win32 -S -disable-free -main-file-name t.c -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -v -resource-dir C:/llvm/bin/lib/clang/1.5 -ferror-limit 19 -fmessage-length 80 -fms-extensions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o C:/Temp/cc-000000.s -x c t.c clang -cc1 version 1.5 based upon llvm 2.7svn hosted on i686-pc-win32 ignoring nonexistent directory "/usr/local/include" ignoring nonexistent directory "/usr/include" #include "..." search starts here: #include <...> search starts here: C:/llvm/bin/lib/clang/1.5/include C:\Program Files\Microsoft Visual Studio 9.0\VC\include C:\Program Files\Microsoft SDKs\Windows\v6.0A End of search list. "gcc" -v -c -o C:/Temp/cc-000001.o -x assembler C:/Temp/cc-000000.s clang: error: unable to execute command: program not executable clang: error: assembler command failed due to signal 1 (use -v to see invocation) I don't really want to use gcc (I happen to have cygwin installed, but gcc is called gcc-3.exe or gcc-4.exe in cygwin\bin.) I notice that the examples use the -cc1 option so I tried that: >clang -cc1 t.c In file included from t.c:1: In file included from C:\Program Files\Microsoft Visual Studio 9.0\VC\include/stdio.h:22: C:\Program Files\Microsoft Visual Studio 9.0\VC\include/crtdefs.h:574:9: error: unknown type name '__int64' typedef __int64 __time64_t; /* 64-bit time value */ ^ In file included from t.c:1: C:\Program Files\Microsoft Visual Studio 9.0\VC\include/stdio.h:268:77: error: unknown type name '__int64' _Check_return_opt_ _CRTIMP int __cdecl _fseeki64(_Inout_ FILE * _File, _In_ __int64 _Offset, _In_ int _Origin); ^ C:\Program Files\Microsoft Visual Studio 9.0\VC\include/stdio.h:269:24: error: unknown type name '__int64' _Check_return_ _CRTIMP __int64 __cdecl _ftelli64(_Inout_ FILE * _File); ^ C:\Program Files\Microsoft Visual Studio 9.0\VC\include/stdio.h:683:84: error: unknown type name '__int64' _Check_return_opt_ _CRTIMP int __cdecl _fseeki64_nolock(_Inout_ FILE * _File, _In_ __int64 _Offset, _In_ int _Origin); ^ C:\Program Files\Microsoft Visual Studio 9.0\VC\include/stdio.h:684:24: error: unknown type name '__int64' _Check_return_ _CRTIMP __int64 __cdecl _ftelli64_nolock(_Inout_ FILE * _File); ^ 5 errors generated. __int64 is a builtin VC++ keyword so it's not surprising that CLang doesn't understand it. but: >clang -cc1 -D__int64=int t.c doesn't produce any output? >clang -cc1 -D__int64=int -v t.c clang -cc1 version 1.5 based upon llvm 2.7svn hosted on i686-pc-win32 ignoring nonexistent directory "/usr/local/include" ignoring nonexistent directory "/usr/include" #include "..." search starts here: #include <...> search starts here: C:/llvm/bin/lib/clang/1.5/include C:\Program Files\Microsoft Visual Studio 9.0\VC\include C:\Program Files\Microsoft SDKs\Windows\v6.0A End of search list. No .exe is produced? Taking a look at C:\llvm\tools\clang\tools\scan-build\scan-build I gather that it's a perl script. Any chance this is going to work with cygwin perl (or better yet ActiveState Perl), assuming I figure out the clang issues? From anton at korobeynikov.info Fri Apr 9 04:28:16 2010 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Fri, 9 Apr 2010 13:28:16 +0400 Subject: [cfe-dev] Trying to use CLang / CLang Static Analyzer under Windows XP SP3 32-bit In-Reply-To: References: Message-ID: Hello > I don't really want to use gcc You should. clang calls gcc for assembling & linking. > I notice that the examples use the -cc1 option so I tried that: -cc1 is an internal interface, you should not use it > Taking a look at C:\llvm\tools\clang\tools\scan-build\scan-build > > I gather that it's a perl script. Any chance this is going to work > with cygwin perl (or better yet ActiveState Perl), assuming I figure > out the clang issues? No, there are some changes wrt process spawning & stuff to make it work at least with msys perl (and, I assume, for cygwin as well). No idea for activestate perl, but it's safe to assume that more invasive changes will be needed. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From eli.friedman at gmail.com Fri Apr 9 04:33:33 2010 From: eli.friedman at gmail.com (Eli Friedman) Date: Fri, 9 Apr 2010 02:33:33 -0700 Subject: [cfe-dev] Trying to use CLang / CLang Static Analyzer under Windows XP SP3 32-bit In-Reply-To: References: Message-ID: On Fri, Apr 9, 2010 at 1:44 AM, TP wrote: > I'm trying to get CLang to run so that I can try out the CLang Static Analyzer. > > I followed the instructions given in the "Using Visual Studio" section > of http://clang.llvm.org/get_started.html. > > The ALL_BUILD Project built fine in Visual Studio 2008. > > But when I try the first example I get: > >>clang t.c > clang: error: unable to execute command: program not executable > clang: error: assembler command failed due to signal 1 (use -v to see > invocation) > >>clang -v t.c > clang version 1.5 (trunk 100852) > Target: i686-pc-win32 > Thread model: posix > ?"C:/llvm/bin/Debug/clang.exe" -cc1 -triple i686-pc-win32 > -S -disable-free -main-file-name t.c -mrelocation-model static > -mdisable-fp-elim -mconstructor-aliases -v -resource-dir > C:/llvm/bin/lib/clang/1.5 -ferror-limit 19 -fmessage-length 80 > -fms-extensions -fgnu-runtime -fdiagnostics-show-option > -fcolor-diagnostics -o C:/Temp/cc-000000.s -x c t.c > clang -cc1 version 1.5 based upon llvm 2.7svn hosted on i686-pc-win32 > ignoring nonexistent directory "/usr/local/include" > ignoring nonexistent directory "/usr/include" > #include "..." search starts here: > #include <...> search starts here: > ?C:/llvm/bin/lib/clang/1.5/include > ?C:\Program Files\Microsoft Visual Studio 9.0\VC\include > ?C:\Program Files\Microsoft SDKs\Windows\v6.0A > End of search list. > ?"gcc" -v -c -o C:/Temp/cc-000001.o -x assembler C:/Temp/cc-000000.s > clang: error: unable to execute command: program not executable > clang: error: assembler command failed due to signal 1 (use -v to see > invocation) > > I don't really want to use gcc (I happen to have cygwin installed, but > gcc is called gcc-3.exe or gcc-4.exe in cygwin\bin.) That's the only way clang knows to assemble and link programs on Windows at the moment. If you want to use some alternate way of assembling/linking the output, pass -S to clang. Or you can use something like -ccc-gcc-name gcc-4 as the first command-line option. Or you can patch clang to support cygwin and/or mingw as and ld directly. I'm not sure what "I don't really want to use gcc" means. > I notice that the examples use the -cc1 option so I tried that: -cc1 is an internal interface; if you don't pass a very similar set of options to what you see from clang -v, you're likely to run into issues for general compilation. (On Windows in particular, I think you need to pass -fms-extensions if clang is using MSVC headers.) > Taking a look at C:\llvm\tools\clang\tools\scan-build\scan-build > > I gather that it's a perl script. Any chance this is going to work > with cygwin perl (or better yet ActiveState Perl), assuming I figure > out the clang issues? I'm not familiar with the details, but there's no fundamental reason why it shouldn't work. -Eli From devlists at shadowlab.org Fri Apr 9 05:20:25 2010 From: devlists at shadowlab.org (Jean-Daniel Dupas) Date: Fri, 9 Apr 2010 12:20:25 +0200 Subject: [cfe-dev] spurious unused function warning on static constructor/destructor Message-ID: I don't think clang should emit an "unused function" warning when the function is declared as a constructor or a destructor (using Constructor/Destructor Attr). Here is a patch that prevent warning and (used add two cases in the warn-unused-function.c test). -------------- next part -------------- A non-text attachment was scrubbed... Name: unused.patch Type: application/octet-stream Size: 1128 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100409/b2db18f3/attachment.obj -------------- next part -------------- -- Jean-Daniel From clattner at apple.com Fri Apr 9 12:26:08 2010 From: clattner at apple.com (Chris Lattner) Date: Fri, 9 Apr 2010 10:26:08 -0700 Subject: [cfe-dev] spurious unused function warning on static constructor/destructor In-Reply-To: References: Message-ID: On Apr 9, 2010, at 3:20 AM, Jean-Daniel Dupas wrote: > I don't think clang should emit an "unused function" warning when the function is declared as a constructor or a destructor (using Constructor/Destructor Attr). > > Here is a patch that prevent warning and (used add two cases in the warn-unused-function.c test). Makes sense, patch looks great, applied as r100870, thanks! From lattner at apple.com Fri Apr 9 14:22:32 2010 From: lattner at apple.com (Tanya Lattner) Date: Fri, 9 Apr 2010 12:22:32 -0700 Subject: [cfe-dev] (still need help) Re: 2.7 Release Status In-Reply-To: References: Message-ID: <8499C08A-0DDB-4F02-8C0B-AAEB63A3353B@apple.com> One bug left. Its clang specific. If anyone can help, please do! > http://llvm.org/bugs/show_bug.cgi?id=6660 Thanks, Tanya On Apr 7, 2010, at 2:29 PM, Tanya Lattner wrote: > All, > > Thanks for those who have been helping fix regressions and warnings. Your hard work is appreciated and you have made great progress! Thank you again. > > The release is getting close. As a reminder, this is the master bug: > http://llvm.org/bugs/show_bug.cgi?id=6586 > > In particular, we have one bug that needs attention: > http://llvm.org/bugs/show_bug.cgi?id=6660 > > These are regressions in the testsuite using clang. This is x86 32bit Linux. > > If anyone can lend a hand for this bug, please do so! Hopefully, once this bug is resolved we can move onto pre-release2. > > Thanks, > Tanya > > P.S. There is also a gfortran bug on Darwin, but it may not be a release blocker. But if we can get it fixed before pre-release2 goes out, that would be very very nice. Take a look if you can help: > http://llvm.org/bugs/show_bug.cgi?id=6778 > > > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From Tim_Agnew at playstation.sony.com Fri Apr 9 15:37:06 2010 From: Tim_Agnew at playstation.sony.com (Tim_Agnew at playstation.sony.com) Date: Fri, 9 Apr 2010 13:37:06 -0700 Subject: [cfe-dev] Paid Internship at Sony Playstation! Message-ID: Software Engineering Intern: Systems Technology Group The Worldwide Studios System Technology Group is offering a paid Engineering Internship! Job Description: Be a part of the most exciting and innovative computer entertainment in North America. Sony Computer Entertainment America (SCEA) markets the PlayStation? family of products and develops, publishes, markets, and distributes software for the PlayStation?3, and the PlayStation Portable (PSP?) computer entertainment systems. Based in Foster City, California, SCEA serves as headquarters for all North American operations and is a wholly owned subsidiary of Sony Computer Entertainment Inc. Job Responsibilities: The STG Intern will work on a variety of projects for internal and external developers working with the PlayStation platforms. Work on these projects may be directed, solo engineering efforts, or as part of a project team. Example projects include: Contributing code to existing test harnesses. Contributing code to PC based tools for PlayStation platforms. Contributing code to the open source GNU binutils assembler and gold linker. Contributing code to the open source LLVM compiler framework and Clang. Skills Required: C, C++ proficiency Excellent communication skills Bachelor in Computer Science (or in progress) Debugging techniques of concurrently programmed applications Proficiency in one or more of the following areas a strong plus: Assembly programming Multithreaded programming Multi-core programming Compiler optimizations Compiler parsing and semantic analysis Daily tasks can include: Research and follow changes in assigned software tools and technologies; Explore opportunities for use with SCEA technology. Partner with project teams to provide feedback and promote relationships. This position is located in Foster City CA, and is open to both graduate and undergraduate students. Do you think you might be just the person we are looking for? If so, apply now! Get your career in the gaming industry off to a great start with Sony Computer Entertainment America. (SCEA) It is the policy of Sony Computer Entertainment America, Inc. (SCEA) to provide equal employment opportunity for all applicants and employees. SCEA does not unlawfully discriminate on the basis of race, color, religion, sex, national origin, age, handicap, veteran status, marital status, or any other category protected by applicable federal and state law. SCEA also makes reasonable accommodations for handicapped and disabled employees. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100409/50f2f02a/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 12688 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100409/50f2f02a/attachment-0001.gif From anton at korobeynikov.info Sat Apr 10 10:43:18 2010 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Sat, 10 Apr 2010 19:43:18 +0400 Subject: [cfe-dev] *Important*: Google Summer of Code 2010 Message-ID: Dear prospective GSoC Students! Please note, that you won't receive any reviews of your proposals from SoC webapp automatically. You **need to explicitly** subscribe for them. Please do it now and respond to requests / comments already made in some of applications. Thanks! -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From clattner at apple.com Sat Apr 10 14:39:24 2010 From: clattner at apple.com (Chris Lattner) Date: Sat, 10 Apr 2010 12:39:24 -0700 Subject: [cfe-dev] [cfe-commits] r100942 - /cfe/trunk/lib/CodeGen/CGObjC.cpp In-Reply-To: References: <20100410190639.264392A6C12C@llvm.org> Message-ID: <96423BB7-5E9F-41EA-84F6-805B4D9F96E9@apple.com> taking this to cfe-dev. On Apr 10, 2010, at 12:23 PM, David Chisnall wrote: > Hi Chris, > > As I said on the PR, I disagree with your assessment of the correct fix - I think your proposal would introduce a lot of difficulties. Given that this is a trivial change and does fix the problem, I'd rather leave it in for now and, if you think rewriting a large chunk of AST code to treat a single special case is the correct solution then revert it when this has been done. If you disagree, then please revert it. > > I do not know how you think that setting a flag on ObjCMessageExpr will make things simpler though. There doesn't seem to be a bitfield on ObjCMessageExpr already, so we'd need to add a new field just to hold this one flag, which would increase the size of every ObjCMessageExpr for one special case. Alternatively we could add a new subclass, but I'm not really sure that this would be more convenient. > > It would also make it impossible if we wanted to support GCC's treatment of super in contexts other than as the receiver for messages. To me, this is a very similar cousin to "cast of super" which we explicitly disallow. The big issue here is that from a language perspective, "super" is not an expression at all. It is a magic token that is only valid in a message send. Things like super->ivar *should* be disallowed, as should "id x = super" and many other things that we probably accidentally allow. I think that the big AST change to model this correctly is really important, because it will fix a number of other problems and cases where Sema probably accidentally accepts invalid code (what about foo(super), passing it as an argument)? This is not about a single special case, this is about the design always being broken and wanting to fix the root problem. Just "leaving it in" will make clang accept illegal code - weaning the invalid code off their constructs is going to be more difficult in the future than it is now. Since clang has never accepted this, we just continue rejecting it. -Chris From csdavec at swan.ac.uk Sat Apr 10 15:03:10 2010 From: csdavec at swan.ac.uk (David Chisnall) Date: Sat, 10 Apr 2010 21:03:10 +0100 Subject: [cfe-dev] [cfe-commits] r100942 - /cfe/trunk/lib/CodeGen/CGObjC.cpp In-Reply-To: <96423BB7-5E9F-41EA-84F6-805B4D9F96E9@apple.com> References: <20100410190639.264392A6C12C@llvm.org> <96423BB7-5E9F-41EA-84F6-805B4D9F96E9@apple.com> Message-ID: On 10 Apr 2010, at 20:39, Chris Lattner wrote: > To me, this is a very similar cousin to "cast of super" which we explicitly disallow. > > The big issue here is that from a language perspective, "super" is not an expression at all. It is a magic token that is only valid in a message send. Things like super->ivar *should* be disallowed, as should "id x = super" and many other things that we probably accidentally allow. Currently, super->ivar is disallowed, so is id x = super. These are accepted by GCC, although that's probably not sensible. > I think that the big AST change to model this correctly is really important, because it will fix a number of other problems and cases where Sema probably accidentally accepts invalid code (what about foo(super), passing it as an argument)? This is not about a single special case, this is about the design always being broken and wanting to fix the root problem. Sema allows foo(super), but it stops in CodeGen. This is probably worth fixing, but I'm not entirely convinced by your proposed solution. This is accepted by GCC, although it generates a spurious warning about incompatible pointer types. > Just "leaving it in" will make clang accept illegal code - weaning the invalid code off their constructs is going to be more difficult in the future than it is now. Since clang has never accepted this, we just continue rejecting it. The change doesn't make it accept illegal code, it will make it accept legal code. The following absolutely should be legal: [(super) foo]; While you would never write this directly, it is relatively common as a result of macro expansion, when a macro is used to optionally remove message sends. Consider a macro like this: #ifndef DISABLE_LOGS #define LOG(x) [(x) log] #else #define LOG(x) #endif The brackets are in the macro, but when you call it like this, gcc accepts it and clang rejects it: FOO(super); If you make a message send to super a flag in the AST, then how would you represent [(super) foo] or [((super)) foo] in the AST? Would they be the same as [super foo]? How would this effect AST consumers other than CodeGen? David -- Sent from my PDP-11 From clattner at apple.com Sat Apr 10 15:09:30 2010 From: clattner at apple.com (Chris Lattner) Date: Sat, 10 Apr 2010 13:09:30 -0700 Subject: [cfe-dev] [cfe-commits] r100942 - /cfe/trunk/lib/CodeGen/CGObjC.cpp In-Reply-To: References: <20100410190639.264392A6C12C@llvm.org> <96423BB7-5E9F-41EA-84F6-805B4D9F96E9@apple.com> Message-ID: <8FB9165D-566B-43BD-8162-A9A01AFD8310@apple.com> On Apr 10, 2010, at 1:03 PM, David Chisnall wrote: >> >> The big issue here is that from a language perspective, "super" is not an expression at all. It is a magic token that is only valid in a message send. Things like super->ivar *should* be disallowed, as should "id x = super" and many other things that we probably accidentally allow. > > Currently, super->ivar is disallowed, so is id x = super. Good. > These are accepted by GCC, although that's probably not sensible. No, they aren't. > >> I think that the big AST change to model this correctly is really important, because it will fix a number of other problems and cases where Sema probably accidentally accepts invalid code (what about foo(super), passing it as an argument)? This is not about a single special case, this is about the design always being broken and wanting to fix the root problem. > > Sema allows foo(super), but it stops in CodeGen. Right, that is bad, my solution would fix that. >> Just "leaving it in" will make clang accept illegal code - weaning the invalid code off their constructs is going to be more difficult in the future than it is now. Since clang has never accepted this, we just continue rejecting it. > > The change doesn't make it accept illegal code, it will make it accept legal code. The following absolutely should be legal: > > [(super) foo]; No, that should not be legal. Super is not an expression. It is not valid to use it in expression contexts: paren exprs require that the subexpression be an expression. > While you would never write this directly, it is relatively common as a result of macro expansion, when a macro is used to optionally remove message sends. Consider a macro like this: > > #ifndef DISABLE_LOGS > #define LOG(x) [(x) log] > #else > #define LOG(x) > #endif Just because something is convenient doesn't mean it should be legal. > > If you make a message send to super a flag in the AST, then how would you represent [(super) foo] or [((super)) foo] in the AST? You wouldn't, we should reject this code, that's the whole point. -Chris From csdavec at swan.ac.uk Sat Apr 10 15:24:14 2010 From: csdavec at swan.ac.uk (David Chisnall) Date: Sat, 10 Apr 2010 21:24:14 +0100 Subject: [cfe-dev] [cfe-commits] r100942 - /cfe/trunk/lib/CodeGen/CGObjC.cpp In-Reply-To: <8FB9165D-566B-43BD-8162-A9A01AFD8310@apple.com> References: <20100410190639.264392A6C12C@llvm.org> <96423BB7-5E9F-41EA-84F6-805B4D9F96E9@apple.com> <8FB9165D-566B-43BD-8162-A9A01AFD8310@apple.com> Message-ID: On 10 Apr 2010, at 21:09, Chris Lattner wrote: > On Apr 10, 2010, at 1:03 PM, David Chisnall wrote: >>> >>> The big issue here is that from a language perspective, "super" is not an expression at all. It is a magic token that is only valid in a message send. Things like super->ivar *should* be disallowed, as should "id x = super" and many other things that we probably accidentally allow. >> >> Currently, super->ivar is disallowed, so is id x = super. > > Good. > >> These are accepted by GCC, although that's probably not sensible. > > No, they aren't. They seem to be on my copy of GCC. I just tested all of these and they worked. >> [(super) foo]; > > No, that should not be legal. Super is not an expression. It is not valid to use it in expression contexts: paren exprs require that the subexpression be an expression. > >> While you would never write this directly, it is relatively common as a result of macro expansion, when a macro is used to optionally remove message sends. Consider a macro like this: >> >> #ifndef DISABLE_LOGS >> #define LOG(x) [(x) log] >> #else >> #define LOG(x) >> #endif > > Just because something is convenient doesn't mean it should be legal. The fact that something is convenient, supported by GCC, and used in existing code seems like a good reason for accepting it... >> If you make a message send to super a flag in the AST, then how would you represent [(super) foo] or [((super)) foo] in the AST? > > You wouldn't, we should reject this code, that's the whole point. I don't really see a convincing argument for rejecting it. Even if super is not an expression, being able to put it in brackets seems logical because you use it in the same place as expressions. If you can put some message receivers in brackets and not others, this makes the language inconsistent and makes macros even more irritating to work with than the C spec normally does. And, if something can be used in the same place as an expression, but isn't an expression, what is it? David -- Sent from my brain From clattner at apple.com Sat Apr 10 16:41:32 2010 From: clattner at apple.com (Chris Lattner) Date: Sat, 10 Apr 2010 14:41:32 -0700 Subject: [cfe-dev] [cfe-commits] r100942 - /cfe/trunk/lib/CodeGen/CGObjC.cpp In-Reply-To: References: <20100410190639.264392A6C12C@llvm.org> <96423BB7-5E9F-41EA-84F6-805B4D9F96E9@apple.com> <8FB9165D-566B-43BD-8162-A9A01AFD8310@apple.com> Message-ID: <5876A18D-08D4-4BDC-B2C0-D533B2906857@apple.com> By your logic, we would accept cast of super... But we don't and it is intentional. This is the same issue. -Chris On Apr 10, 2010, at 1:24 PM, David Chisnall wrote: > On 10 Apr 2010, at 21:09, Chris Lattner wrote: > >> On Apr 10, 2010, at 1:03 PM, David Chisnall wrote: >>>> >>>> The big issue here is that from a language perspective, "super" >>>> is not an expression at all. It is a magic token that is only >>>> valid in a message send. Things like super->ivar *should* be >>>> disallowed, as should "id x = super" and many other things that >>>> we probably accidentally allow. >>> >>> Currently, super->ivar is disallowed, so is id x = super. >> >> Good. >> >>> These are accepted by GCC, although that's probably not sensible. >> >> No, they aren't. > > They seem to be on my copy of GCC. I just tested all of these and > they worked. > >>> [(super) foo]; >> >> No, that should not be legal. Super is not an expression. It is >> not valid to use it in expression contexts: paren exprs require >> that the subexpression be an expression. >> >>> While you would never write this directly, it is relatively common >>> as a result of macro expansion, when a macro is used to optionally >>> remove message sends. Consider a macro like this: >>> >>> #ifndef DISABLE_LOGS >>> #define LOG(x) [(x) log] >>> #else >>> #define LOG(x) >>> #endif >> >> Just because something is convenient doesn't mean it should be legal. > > The fact that something is convenient, supported by GCC, and used in > existing code seems like a good reason for accepting it... > >>> If you make a message send to super a flag in the AST, then how >>> would you represent [(super) foo] or [((super)) foo] in the AST? >> >> You wouldn't, we should reject this code, that's the whole point. > > I don't really see a convincing argument for rejecting it. Even if > super is not an expression, being able to put it in brackets seems > logical because you use it in the same place as expressions. If you > can put some message receivers in brackets and not others, this > makes the language inconsistent and makes macros even more > irritating to work with than the C spec normally does. > > And, if something can be used in the same place as an expression, > but isn't an expression, what is it? > > David > > -- Sent from my brain > From csdavec at swan.ac.uk Sat Apr 10 17:00:32 2010 From: csdavec at swan.ac.uk (David Chisnall) Date: Sat, 10 Apr 2010 23:00:32 +0100 Subject: [cfe-dev] [cfe-commits] r100942 - /cfe/trunk/lib/CodeGen/CGObjC.cpp In-Reply-To: <5876A18D-08D4-4BDC-B2C0-D533B2906857@apple.com> References: <20100410190639.264392A6C12C@llvm.org> <96423BB7-5E9F-41EA-84F6-805B4D9F96E9@apple.com> <8FB9165D-566B-43BD-8162-A9A01AFD8310@apple.com> <5876A18D-08D4-4BDC-B2C0-D533B2906857@apple.com> Message-ID: <9C6EAC9C-6097-4191-BF80-5C47AAF7FD1D@swan.ac.uk> On 10 Apr 2010, at 22:41, Chris Lattner wrote: > By your logic, we would accept cast of super... But we don't and it is intentional. This is the same issue. No, because cast of super is never a sensible thing to do. The class of super is fixed at compile time, so casting it is always wrong. If code does this, then it should be fixed. In contrast, putting parentheses around super does not change its semantics. If you wish for clang not to support this, what do you propose as the alternative for the (currently in use in existing code) use case that I described in my last mail? Cast of super is a work around for calling private methods in the superclass. You can work around its lack trivially with a private category on the superclass. You have not proposed a way of replacing macros that conditionally call a method (a widely-used idiom) when they are passed super as an argument. If the macro takes an expression, it must be parenthetical. If the macro takes super, it must not be parenthetical. Note that the fact that Smalltalk does not support this construct is not an issue because Smalltalk does not use the C preprocessor, it uses a much more sane model for AST transforms. The same is true of Java. Only the fact that Objective-C is used with the C preprocessor makes this an issue. David From clattner at apple.com Sat Apr 10 18:35:03 2010 From: clattner at apple.com (Chris Lattner) Date: Sat, 10 Apr 2010 16:35:03 -0700 Subject: [cfe-dev] [cfe-commits] r100942 - /cfe/trunk/lib/CodeGen/CGObjC.cpp In-Reply-To: <9C6EAC9C-6097-4191-BF80-5C47AAF7FD1D@swan.ac.uk> References: <20100410190639.264392A6C12C@llvm.org> <96423BB7-5E9F-41EA-84F6-805B4D9F96E9@apple.com> <8FB9165D-566B-43BD-8162-A9A01AFD8310@apple.com> <5876A18D-08D4-4BDC-B2C0-D533B2906857@apple.com> <9C6EAC9C-6097-4191-BF80-5C47AAF7FD1D@swan.ac.uk> Message-ID: On Apr 10, 2010, at 3:00 PM, David Chisnall wrote: > On 10 Apr 2010, at 22:41, Chris Lattner wrote: > >> By your logic, we would accept cast of super... But we don't and it is intentional. This is the same issue. > > > No, because cast of super is never a sensible thing to do. The class of super is fixed at compile time, so casting it is always wrong. If code does this, then it should be fixed. The point is, super is not an expression, it is a magic keyword that affects messages sends. It cannot be used in any other places that expressions are allowed, so it should not be part of the expression grammar. -Chris From csdavec at swan.ac.uk Sat Apr 10 18:43:21 2010 From: csdavec at swan.ac.uk (David Chisnall) Date: Sun, 11 Apr 2010 00:43:21 +0100 Subject: [cfe-dev] [cfe-commits] r100942 - /cfe/trunk/lib/CodeGen/CGObjC.cpp In-Reply-To: References: <20100410190639.264392A6C12C@llvm.org> <96423BB7-5E9F-41EA-84F6-805B4D9F96E9@apple.com> <8FB9165D-566B-43BD-8162-A9A01AFD8310@apple.com> <5876A18D-08D4-4BDC-B2C0-D533B2906857@apple.com> <9C6EAC9C-6097-4191-BF80-5C47AAF7FD1D@swan.ac.uk> Message-ID: On 11 Apr 2010, at 00:35, Chris Lattner wrote: > The point is, super is not an expression, it is a magic keyword that affects messages sends. It cannot be used in any other places that expressions are allowed, so it should not be part of the expression grammar. Which is a side issue. There are three questions here. First, should we support super in parentheses in message send expressions? I say we should because: - It is supported by GCC. - It is used in existing code. - It is required for macros that send messages to their arguments. - You have not proposed any way for people to work around this You say no because is counter to your private sense of aesthetics. Question two. Should we do so with the existing infrastructure and the one-line change that I just made? I say yes because: - It is a trivial change. - It works now. - It allows existing code to be compiled with Clang that was previously requiring GCC. You say no because is counter to your private sense of aesthetics. Question three. Should we work to remove ObjCSuperExpr. You say yes because: - It is not really an expression. - It complicates semantic analysis. - It doesn't truly reflect the language semantics. I say I don't really care, but it's probably a nicer design longer term and if someone wants to put some effort into it then it will probably make things cleaner and easier. David -- Sent from my PDP-11 From clattner at apple.com Sat Apr 10 18:52:28 2010 From: clattner at apple.com (Chris Lattner) Date: Sat, 10 Apr 2010 16:52:28 -0700 Subject: [cfe-dev] [cfe-commits] r100942 - /cfe/trunk/lib/CodeGen/CGObjC.cpp In-Reply-To: References: <20100410190639.264392A6C12C@llvm.org> <96423BB7-5E9F-41EA-84F6-805B4D9F96E9@apple.com> <8FB9165D-566B-43BD-8162-A9A01AFD8310@apple.com> <5876A18D-08D4-4BDC-B2C0-D533B2906857@apple.com> <9C6EAC9C-6097-4191-BF80-5C47AAF7FD1D@swan.ac.uk> Message-ID: <12DEE4F0-9BC1-409A-ABF4-C40D29B4117F@apple.com> On Apr 10, 2010, at 4:43 PM, David Chisnall wrote: > On 11 Apr 2010, at 00:35, Chris Lattner wrote: > >> The point is, super is not an expression, it is a magic keyword that affects messages sends. It cannot be used in any other places that expressions are allowed, so it should not be part of the expression grammar. > > > Which is a side issue. There are three questions here. First, should we support super in parentheses in message send expressions? I say we should because: > > - It is supported by GCC. > - It is used in existing code. > - It is required for macros that send messages to their arguments. > - You have not proposed any way for people to work around this > > You say no because is counter to your private sense of aesthetics. I say no because it doesn't fit with the rest of the compiler, our current implementation of super is a ecological disaster and needs to be fixed, and it is obviously not been used enough to be reported yet. I would argue that cast of super is much more widely used than parenthesized super. > Question two. Should we do so with the existing infrastructure and the one-line change that I just made? I say yes because: > > - It is a trivial change. > - It works now. > - It allows existing code to be compiled with Clang that was previously requiring GCC. > > You say no because is counter to your private sense of aesthetics. This encourages broken code. Continuing to reject it forces people to fix their broken code. This is exactly what we did with cast of super, and the world is better place because of it. Whether ObjCSuperExpr is removed or not seems completely unrelated to the user visible issue of whether the code is accepted or rejected. -Chris From csdavec at swan.ac.uk Sat Apr 10 19:00:36 2010 From: csdavec at swan.ac.uk (David Chisnall) Date: Sun, 11 Apr 2010 01:00:36 +0100 Subject: [cfe-dev] [cfe-commits] r100942 - /cfe/trunk/lib/CodeGen/CGObjC.cpp In-Reply-To: <12DEE4F0-9BC1-409A-ABF4-C40D29B4117F@apple.com> References: <20100410190639.264392A6C12C@llvm.org> <96423BB7-5E9F-41EA-84F6-805B4D9F96E9@apple.com> <8FB9165D-566B-43BD-8162-A9A01AFD8310@apple.com> <5876A18D-08D4-4BDC-B2C0-D533B2906857@apple.com> <9C6EAC9C-6097-4191-BF80-5C47AAF7FD1D@swan.ac.uk> <12DEE4F0-9BC1-409A-ABF4-C40D29B4117F@apple.com> Message-ID: <7BAC61E8-412E-44A0-B092-C98719D48BDD@swan.ac.uk> On 11 Apr 2010, at 00:52, Chris Lattner wrote: > I say no because it doesn't fit with the rest of the compiler, our current implementation of super is a ecological disaster and needs to be fixed, and it is obviously not been used enough to be reported yet. I would argue that cast of super is much more widely used than parenthesized super. I suspect that it hasn't been reported because clang is only very recently able to compile most Objective-C code without random things breaking. Now that most things are working we're getting into tidying up the last bits. >> Question two. Should we do so with the existing infrastructure and the one-line change that I just made? I say yes because: >> >> - It is a trivial change. >> - It works now. >> - It allows existing code to be compiled with Clang that was previously requiring GCC. >> >> You say no because is counter to your private sense of aesthetics. > > This encourages broken code. Continuing to reject it forces people to fix their broken code. This is exactly what we did with cast of super, and the world is better place because of it. Please can we define 'broken' here? I gave a use case for it. You have still, after three replies, not propose a way in which code that uses this idiom could be rewritten to work with clang. Cast of super can, as I have already said be, worked around by declaring the private method in a category. How do you work around macros that need to be able to take any valid receiver as an argument? Give me a solution to this problem, and I'll shut up and write about your proposed work around in my new Objective-C book. Simply declaring code as broken when it has always worked in GCC and solves a specific problem is not a constructive approach. The world is not a better place when you take code that works, is easy to read and understand, and declare unilaterally that it is broken and needs to be fixed, but don't propose a way of fixing it. > Whether ObjCSuperExpr is removed or not seems completely unrelated to the user visible issue of whether the code is accepted or rejected. But this is the argument that you seem to be using to motivate the user-visible change. David From rideau3 at gmail.com Sat Apr 10 19:30:09 2010 From: rideau3 at gmail.com (Sean Hunt) Date: Sat, 10 Apr 2010 18:30:09 -0600 Subject: [cfe-dev] [cfe-commits] r100942 - /cfe/trunk/lib/CodeGen/CGObjC.cpp In-Reply-To: References: <20100410190639.264392A6C12C@llvm.org> <96423BB7-5E9F-41EA-84F6-805B4D9F96E9@apple.com> <8FB9165D-566B-43BD-8162-A9A01AFD8310@apple.com> <5876A18D-08D4-4BDC-B2C0-D533B2906857@apple.com> <9C6EAC9C-6097-4191-BF80-5C47AAF7FD1D@swan.ac.uk> Message-ID: <4BC11811.10603@gmail.com> On 04/10/2010 05:43 PM, David Chisnall wrote: > You say no because is counter to your private sense of aesthetics. > > You say no because is counter to your private sense of aesthetics. > > Question three. Should we work to remove ObjCSuperExpr. You say yes because: > > - It is not really an expression. > - It complicates semantic analysis. > - It doesn't truly reflect the language semantics. > > David I'm going to weigh in here. I checked the spec, and it's clear that super is not allowed except as the receiver in a message send. Whether this should be supported as an extension is another question (and not one that I can answer satisfactorily, seeing as I don't use Objective-C), but even if we do support it as an extension, it should at least give a warning in all cases. Sean From csdavec at swan.ac.uk Sat Apr 10 19:48:13 2010 From: csdavec at swan.ac.uk (David Chisnall) Date: Sun, 11 Apr 2010 01:48:13 +0100 Subject: [cfe-dev] [cfe-commits] r100942 - /cfe/trunk/lib/CodeGen/CGObjC.cpp In-Reply-To: <4BC11811.10603@gmail.com> References: <20100410190639.264392A6C12C@llvm.org> <96423BB7-5E9F-41EA-84F6-805B4D9F96E9@apple.com> <8FB9165D-566B-43BD-8162-A9A01AFD8310@apple.com> <5876A18D-08D4-4BDC-B2C0-D533B2906857@apple.com> <9C6EAC9C-6097-4191-BF80-5C47AAF7FD1D@swan.ac.uk> <4BC11811.10603@gmail.com> Message-ID: <0709A6D9-15BD-4D5A-9650-807F80386EC5@swan.ac.uk> On 11 Apr 2010, at 01:30, Sean Hunt wrote: > I'm going to weigh in here. I checked the spec, and it's clear that > super is not allowed except as the receiver in a message send. Whether > this should be supported as an extension is another question (and not > one that I can answer satisfactorily, seeing as I don't use > Objective-C), but even if we do support it as an extension, it should at > least give a warning in all cases. I don't think anyone is arguing that we should support the general case of treating super as an expression equivalent to self. GCC does, but it leads to code that doesn't do what it looks like it ought to do and is an artefact of how Objective-C is implemented in GCC rather than a design decision for the language. The only question is whether, in the one context where we do want to allow super, we allow it to be in parentheses, as it may be as a result of macro expansion. David From clattner at apple.com Sat Apr 10 21:33:15 2010 From: clattner at apple.com (Chris Lattner) Date: Sat, 10 Apr 2010 19:33:15 -0700 Subject: [cfe-dev] [cfe-commits] r100942 - /cfe/trunk/lib/CodeGen/CGObjC.cpp In-Reply-To: <7BAC61E8-412E-44A0-B092-C98719D48BDD@swan.ac.uk> References: <20100410190639.264392A6C12C@llvm.org> <96423BB7-5E9F-41EA-84F6-805B4D9F96E9@apple.com> <8FB9165D-566B-43BD-8162-A9A01AFD8310@apple.com> <5876A18D-08D4-4BDC-B2C0-D533B2906857@apple.com> <9C6EAC9C-6097-4191-BF80-5C47AAF7FD1D@swan.ac.uk> <12DEE4F0-9BC1-409A-ABF4-C40D29B4117F@apple.com> <7BAC61E8-412E-44A0-B092-C98719D48BDD@swan.ac.uk> Message-ID: On Apr 10, 2010, at 5:00 PM, David Chisnall wrote: > On 11 Apr 2010, at 00:52, Chris Lattner wrote: > >> I say no because it doesn't fit with the rest of the compiler, our current implementation of super is a ecological disaster and needs to be fixed, and it is obviously not been used enough to be reported yet. I would argue that cast of super is much more widely used than parenthesized super. > > I suspect that it hasn't been reported because clang is only very recently able to compile most Objective-C code without random things breaking. Now that most things are working we're getting into tidying up the last bits. Uh, we've compiled a *lot* of objective-c code, and Apple has been shipping clang as a production quality c/objc compiler since last summer. >> >> This encourages broken code. Continuing to reject it forces people to fix their broken code. This is exactly what we did with cast of super, and the world is better place because of it. > > Please can we define 'broken' here? I gave a use case for it. You have still, after three replies, not propose a way in which code that uses this idiom could be rewritten to work with clang. There are lots of ways, remove the parens from the macro or don't use a macro at all. Amazing. > Simply declaring code as broken when it has always worked in GCC and solves a specific problem is not a constructive approach. David, I respect you a lot, but I feel like I've given you several explanations of why this is wrong. I can't help that you don't want to hear it :) Have you looked at all the places and weird ad-hoc things that clang is doing w.r.t. super? It is a real mess right now, it isn't a keyword, it is special cased in a few bizarre places. I want to make it so the parser *just* handles this in the message dispatch parser as a context sensitive keyword. This is the semantic behavior of it, it should not be parsed as a general expression because it doesn't make sense. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100410/ae8faade/attachment.html From csdavec at swan.ac.uk Sun Apr 11 07:25:45 2010 From: csdavec at swan.ac.uk (David Chisnall) Date: Sun, 11 Apr 2010 13:25:45 +0100 Subject: [cfe-dev] [cfe-commits] r100942 - /cfe/trunk/lib/CodeGen/CGObjC.cpp In-Reply-To: References: <20100410190639.264392A6C12C@llvm.org> <96423BB7-5E9F-41EA-84F6-805B4D9F96E9@apple.com> <8FB9165D-566B-43BD-8162-A9A01AFD8310@apple.com> <5876A18D-08D4-4BDC-B2C0-D533B2906857@apple.com> <9C6EAC9C-6097-4191-BF80-5C47AAF7FD1D@swan.ac.uk> <12DEE4F0-9BC1-409A-ABF4-C40D29B4117F@apple.com> <7BAC61E8-412E-44A0-B092-C98719D48BDD@swan.ac.uk> Message-ID: <3549D5F1-187B-46CF-A7D5-AF312E70F1B5@swan.ac.uk> On 11 Apr 2010, at 03:33, Chris Lattner wrote: > Uh, we've compiled a *lot* of objective-c code, and Apple has been shipping clang as a production quality c/objc compiler since last summer. Perhaps this is not an idiom used inside Apple. XCode does not default to clang, and most projects that I have tried compiling only worked without issues in the last few months. ABI support has been a big issue for non-Darwin users, with various random seeming crashes that have only been addressed (and reported - no implied criticism here) recently. > There are lots of ways, remove the parens from the macro or don't use a macro at all. Amazing. Neither of these are solutions. Removing the parentheses from the macro is not an option, because they are required when something that is an expression is used. Don't use the macro at all is not really a solution either - macros of this form are already in use and suggesting that someone goes through their existing code and manually expands every instance of the macro (including wrapping it in #ifdefs) is more of a problem than a solution. Macros of this form are included with the standard GNUstep headers, and have been for the past 15 years. Our next release will be the first one to officially support clang as a compiler, although the fact that you broke the address of label extension just before 1.1 means that we have to require clang from svn to build our Foundation implementation. This is the first time that we are encouraging downstream developers to use clang, and you are intentionally breaking the compilation of their code, if they are using these macros. >> Simply declaring code as broken when it has always worked in GCC and solves a specific problem is not a constructive approach. > > David, I respect you a lot, but I feel like I've given you several explanations of why this is wrong. I can't help that you don't want to hear it :) I agree that treating super as an expression is wrong in the general case, but I disagree that it is wrong for super to be allowed to be in brackets. Putting something in brackets does not change its semantics, is an idiom used in the wild, and does not require it to be treated as an expression. > Have you looked at all the places and weird ad-hoc things that clang is doing w.r.t. super? It is a real mess right now, it isn't a keyword, it is special cased in a few bizarre places. I want to make it so the parser *just* handles this in the message dispatch parser as a context sensitive keyword. This is the semantic behavior of it, it should not be parsed as a general expression because it doesn't make sense. With regard to your latest change, I really dislike this warning: 'super' not valid when not in a method This is misleading, because 'super' is valid when not used in a method, as long as it is declared as a variable. I often use super as a variable name referring to a superclass in Objective-C code outside of methods, especially in free-standing methods that will be attached to a class at run time. And please don't tell me that this is a bug - Objective-C is a pure superset of C and, by design, does not declare any keywords that are valid C identifiers. You also seem to have broken some valid code: $ cat sup.m && clang -c sup.m #import int main(void) { id super = nil; [(Object*)super new]; int *s1 = (int*)super; return 0; } sup.m:6:12: error: cannot cast 'super' (it isn't an expression) [(Object*)super new]; ~~~~~~~~~^ sup.m:7:18: error: cannot cast 'super' (it isn't an expression) int *s1 = (int*)super; ~~~~~~^ 2 errors generated. super is an expression here. It is a local variable. This is entirely valid, especially in the second case where there is no Objective-C at all. Pure C code should always compile correctly in Objective-C mode. David -- Sent from my brain From arplynn at gmail.com Sun Apr 11 07:29:21 2010 From: arplynn at gmail.com (Alistair Lynn) Date: Sun, 11 Apr 2010 13:29:21 +0100 Subject: [cfe-dev] [cfe-commits] r100942 - /cfe/trunk/lib/CodeGen/CGObjC.cpp In-Reply-To: References: <20100410190639.264392A6C12C@llvm.org> <96423BB7-5E9F-41EA-84F6-805B4D9F96E9@apple.com> <8FB9165D-566B-43BD-8162-A9A01AFD8310@apple.com> <5876A18D-08D4-4BDC-B2C0-D533B2906857@apple.com> <9C6EAC9C-6097-4191-BF80-5C47AAF7FD1D@swan.ac.uk> <12DEE4F0-9BC1-409A-ABF4-C40D29B4117F@apple.com> <7BAC61E8-412E-44A0-B092-C98719D48BDD@swan.ac.uk> Message-ID: <5EAA558A-C4AC-481C-BAA2-27C67C6E893A@gmail.com> Hello- Forgive me, but if (super) is really necessary for David, could it not be implemented as a preprocessor hack which just eats the parens, with associated warning, thus avoiding any codegen/parser/sema complications? Alistair On 11 Apr 2010, at 03:33, Chris Lattner wrote: > > On Apr 10, 2010, at 5:00 PM, David Chisnall wrote: > >> On 11 Apr 2010, at 00:52, Chris Lattner wrote: >> >>> I say no because it doesn't fit with the rest of the compiler, our current implementation of super is a ecological disaster and needs to be fixed, and it is obviously not been used enough to be reported yet. I would argue that cast of super is much more widely used than parenthesized super. >> >> I suspect that it hasn't been reported because clang is only very recently able to compile most Objective-C code without random things breaking. Now that most things are working we're getting into tidying up the last bits. > > Uh, we've compiled a *lot* of objective-c code, and Apple has been shipping clang as a production quality c/objc compiler since last summer. > >>> >>> This encourages broken code. Continuing to reject it forces people to fix their broken code. This is exactly what we did with cast of super, and the world is better place because of it. >> >> Please can we define 'broken' here? I gave a use case for it. You have still, after three replies, not propose a way in which code that uses this idiom could be rewritten to work with clang. > > There are lots of ways, remove the parens from the macro or don't use a macro at all. Amazing. > >> Simply declaring code as broken when it has always worked in GCC and solves a specific problem is not a constructive approach. > > David, I respect you a lot, but I feel like I've given you several explanations of why this is wrong. I can't help that you don't want to hear it :) > > Have you looked at all the places and weird ad-hoc things that clang is doing w.r.t. super? It is a real mess right now, it isn't a keyword, it is special cased in a few bizarre places. I want to make it so the parser *just* handles this in the message dispatch parser as a context sensitive keyword. This is the semantic behavior of it, it should not be parsed as a general expression because it doesn't make sense. > > -Chris > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100411/a2d5c00f/attachment.html From csdavec at swan.ac.uk Sun Apr 11 07:54:32 2010 From: csdavec at swan.ac.uk (David Chisnall) Date: Sun, 11 Apr 2010 13:54:32 +0100 Subject: [cfe-dev] [cfe-commits] r100942 - /cfe/trunk/lib/CodeGen/CGObjC.cpp In-Reply-To: <5EAA558A-C4AC-481C-BAA2-27C67C6E893A@gmail.com> References: <20100410190639.264392A6C12C@llvm.org> <96423BB7-5E9F-41EA-84F6-805B4D9F96E9@apple.com> <8FB9165D-566B-43BD-8162-A9A01AFD8310@apple.com> <5876A18D-08D4-4BDC-B2C0-D533B2906857@apple.com> <9C6EAC9C-6097-4191-BF80-5C47AAF7FD1D@swan.ac.uk> <12DEE4F0-9BC1-409A-ABF4-C40D29B4117F@apple.com> <7BAC61E8-412E-44A0-B092-C98719D48BDD@swan.ac.uk> <5EAA558A-C4AC-481C-BAA2-27C67C6E893A@gmail.com> Message-ID: On 11 Apr 2010, at 13:29, Alistair Lynn wrote: > Forgive me, but if (super) is really necessary for David, could it not be implemented as a preprocessor hack which just eats the parens, with associated warning, thus avoiding any codegen/parser/sema complications? That would work for me - I don't mind if (super) is only valid as the result of a macro expansion. It's a ugly solution, but it's significantly less ugly than the existing code. David From dmp at rice.edu Sun Apr 11 13:43:52 2010 From: dmp at rice.edu (David Peixotto) Date: Sun, 11 Apr 2010 13:43:52 -0500 Subject: [cfe-dev] Clang macro expansion differs from GCC In-Reply-To: <079BB2A4-126C-4C92-90C0-DF99CA1AEBEE@apple.com> References: <4F1B53BA-DEA5-46DB-BAC5-F1921D832B63@rice.edu> <079BB2A4-126C-4C92-90C0-DF99CA1AEBEE@apple.com> Message-ID: Hi Chris, I took a look at modifying the preprocessor output and it was pretty straightforward. I have attached a patch that makes the preprocessed output less conservative in adding spaces between periods. It will now add a space to avoid turning ".. ." into "...", but does not always add a space between two consecutive dots. The change was done by keeping track of the last two tokens that were output and testing against those two tokens to avoid creating "...". Previously only the last output token was tracked and tested against, which caused any two consecutive . tokens to have a space between them. The patch passes all the tests in the tests subdirectory. I modified one test to reflect the output changing from ". . ." to ".. .". This output happens to match the expected output in the test comment. I also added a test for the original case that was causing me problems. Please let me know if there are more tests I should run or anything else that needs to happen for the patch to be accepted. Thanks! -David On Apr 8, 2010, at 11:48 AM, Chris Lattner wrote: > > On Apr 8, 2010, at 8:34 AM, David Peixotto wrote: > >> I have found a discrepancy in behavior between the clang preprocessor and gcc. >> >> $ cat t.c >> #define X 0 .. 1 >> >> 0 .. 1 // Ok >> X // Bad: space between .. >> >> $ gcc -E t.c >> >> >> 0 .. 1 >> 0 .. 1 >> >> $ clang -E t.c >> >> >> 0 .. 1 >> 0 . . 1 >> >> The problem is that when ".." is in the macro and the macro gets expanded, it adds a space between the dots. As you can see, the space is not added when the ".." is entered directly in the text. GCC does not insert a space in either case. >> >> I'm not sure this qualifies as a bug, but the reason I need this to work is that I am trying to compile GHC (a Haskell compiler) with clang. It uses GCC to preprocess c-- files (http://www.cminusminus.org) before parsing them and ".." is a valid operator in c--. Adding the extra space messes up the subsequent parsing phase. > > Hi David, > > I'm not particularly interested in fixing this: people abusing the C preprocessor to preprocess things that aren't C don't get much sympathy from me. However, if you are able to produce a patch that works, doesn't break anything else, and doesn't affect performance, I'd be happy to apply it. > >> >> I'd be happy to take a look at fixing this myself if someone could point me in the right direction. > > > lib/Frontend/PrintPreprocessedOutput.cpp is the code that outputs a .i file, the "AvoidConcat" stuff is what you want. It is what decides to add spaces to prevent three . tokens from looking like a ... for example. > > -Chris > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100411/0e7ad646/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: PPdots.patch Type: application/octet-stream Size: 4869 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100411/0e7ad646/attachment.obj -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100411/0e7ad646/attachment-0001.html From clattner at apple.com Sun Apr 11 13:49:14 2010 From: clattner at apple.com (Chris Lattner) Date: Sun, 11 Apr 2010 11:49:14 -0700 Subject: [cfe-dev] [cfe-commits] r100942 - /cfe/trunk/lib/CodeGen/CGObjC.cpp In-Reply-To: <3549D5F1-187B-46CF-A7D5-AF312E70F1B5@swan.ac.uk> References: <20100410190639.264392A6C12C@llvm.org> <96423BB7-5E9F-41EA-84F6-805B4D9F96E9@apple.com> <8FB9165D-566B-43BD-8162-A9A01AFD8310@apple.com> <5876A18D-08D4-4BDC-B2C0-D533B2906857@apple.com> <9C6EAC9C-6097-4191-BF80-5C47AAF7FD1D@swan.ac.uk> <12DEE4F0-9BC1-409A-ABF4-C40D29B4117F@apple.com> <7BAC61E8-412E-44A0-B092-C98719D48BDD@swan.ac.uk> <3549D5F1-187B-46CF-A7D5-AF312E70F1B5@swan.ac.uk> Message-ID: On Apr 11, 2010, at 5:25 AM, David Chisnall wrote: > On 11 Apr 2010, at 03:33, Chris Lattner wrote: > >> Uh, we've compiled a *lot* of objective-c code, and Apple has been shipping clang as a production quality c/objc compiler since last summer. > > Perhaps this is not an idiom used inside Apple. XCode does not default to clang, and most projects that I have tried compiling only worked without issues in the last few months. Arguing about whether people are using clang or not is a moot point. If they aren't already, they will at some point. We intentionally have decided to reject some constructs that GCC supports (for a number of reasons, forcing people to clean up their code is one). Doing this when transitioning from GCC -> Clang is a much easier thing for developers to understand than to find out they upgraded a minor version of their compiler and suddenly their code doesn't build. > ABI support has been a big issue for non-Darwin users, with various random seeming crashes that have only been addressed (and reported - no implied criticism here) recently. I'm not sure what you mean. >> There are lots of ways, remove the parens from the macro or don't use a macro at all. Amazing. > > Neither of these are solutions. Removing the parentheses from the macro is not an option, because they are required when something that is an expression is used. Don't use the macro at all is not really a solution either - macros of this form are already in use and suggesting that someone goes through their existing code and manually expands every instance of the macro (including wrapping it in #ifdefs) is more of a problem than a solution. > > Macros of this form are included with the standard GNUstep headers, and have been for the past 15 years. Our next release will be the first one to officially support clang as a compiler, although the fact that you broke the address of label extension just before 1.1 means that we have to require clang from svn to build our Foundation implementation. > > This is the first time that we are encouraging downstream developers to use clang, and you are intentionally breaking the compilation of their code, if they are using these macros. Why not include a second version of the macro that works with super? Alternatively, why not just drop the parens from the macro definition? I'm not sure how address of label is broken, PR#? >>> Simply declaring code as broken when it has always worked in GCC and solves a specific problem is not a constructive approach. >> >> David, I respect you a lot, but I feel like I've given you several explanations of why this is wrong. I can't help that you don't want to hear it :) > > I agree that treating super as an expression is wrong in the general case, but I disagree that it is wrong for super to be allowed to be in brackets. Putting something in brackets does not change its semantics, is an idiom used in the wild, and does not require it to be treated as an expression. I agree that putting an expression in parentheses does not change it semantics, but super isn't an expression. You can't do: x (+) y for example. You also can't do: for (id x (in) ... etc. Why should you be able to parenthesize super? It doesn't make any sense, and arguing about language semantics from a convenience standpoint doesn't fly well, there are lots of things that don't make sense that would be convenient. >> Have you looked at all the places and weird ad-hoc things that clang is doing w.r.t. super? It is a real mess right now, it isn't a keyword, it is special cased in a few bizarre places. I want to make it so the parser *just* handles this in the message dispatch parser as a context sensitive keyword. This is the semantic behavior of it, it should not be parsed as a general expression because it doesn't make sense. > > With regard to your latest change, I really dislike this warning: > > 'super' not valid when not in a method > > This is misleading, because 'super' is valid when not used in a method, as long as it is declared as a variable. Sure, this is the typical problem with diagnostics: you have to guess what the user meant and/or what the most useful message is to help people fix their code. I inferred that a likely reason to get this message is refactoring code from a method out to a C function. ObjC programers consider super to be a magic incantation, not something they're likely to name variables (despite it not actually being a keyword). I don't think it would be particularly useful to emit "'super' not valid when not in a method, but you could name a variable 'super' if you really wanted to". > I often use super as a variable name referring to a superclass in Objective-C code outside of methods, especially in free-standing methods that will be attached to a class at run time. And please don't tell me that this is a bug - Objective-C is a pure superset of C and, by design, does not declare any keywords that are valid C identifiers. I agree, that is not a bug. > You also seem to have broken some valid code: > > $ cat sup.m && clang -c sup.m > #import > > int main(void) > { > id super = nil; > [(Object*)super new]; > int *s1 = (int*)super; > return 0; > } > sup.m:6:12: error: cannot cast 'super' (it isn't an expression) > [(Object*)super new]; > ~~~~~~~~~^ > sup.m:7:18: error: cannot cast 'super' (it isn't an expression) > int *s1 = (int*)super; > ~~~~~~^ > 2 errors generated. > > super is an expression here. It is a local variable. This is entirely valid, especially in the second case where there is no Objective-C at all. Pure C code should always compile correctly in Objective-C mode. I'll take a look thanks! -Chris From devlists at shadowlab.org Mon Apr 12 03:59:48 2010 From: devlists at shadowlab.org (Jean-Daniel Dupas) Date: Mon, 12 Apr 2010 10:59:48 +0200 Subject: [cfe-dev] =?windows-1252?q?Obj-C_Super_badly_broken=85?= Message-ID: <84D1AD51-B0F7-42EE-9D54-B4E0F5569E21@shadowlab.org> Hi, Look like recent change in super handling in Obj-C broke it in a nasty way. In short, when using [super classMethod] in a class derived class, 'self' does not point on the derived class in the super's method invocation, but it contains the super class instead. See Bug 6819 for details. -- Jean-Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100412/0111cfc5/attachment.html From devlists at shadowlab.org Mon Apr 12 04:21:24 2010 From: devlists at shadowlab.org (Jean-Daniel Dupas) Date: Mon, 12 Apr 2010 11:21:24 +0200 Subject: [cfe-dev] =?windows-1252?q?Obj-C_Super_badly_broken=85?= In-Reply-To: <84D1AD51-B0F7-42EE-9D54-B4E0F5569E21@shadowlab.org> References: <84D1AD51-B0F7-42EE-9D54-B4E0F5569E21@shadowlab.org> Message-ID: <7A1B289B-2258-4999-9638-54FEE73F9F8F@shadowlab.org> Le 12 avr. 2010 ? 10:59, Jean-Daniel Dupas a ?crit : > Hi, > > Look like recent change in super handling in Obj-C broke it in a nasty way. > > In short, when using [super classMethod] in a class derived class, 'self' does not point on the derived class in the super's method invocation, but it contains the super class instead. > > See Bug 6819 for details. A short investigation shows that clang generate an objc_msgSend call instead of a objc_msgSendSuper call. -- Jean-Daniel From Olaf.Krzikalla at tu-dresden.de Mon Apr 12 07:16:32 2010 From: Olaf.Krzikalla at tu-dresden.de (Olaf Krzikalla) Date: Mon, 12 Apr 2010 14:16:32 +0200 Subject: [cfe-dev] C++0x attributes Message-ID: <4BC30F20.2050900@tu-dresden.de> Hi @all, maybe the question is a little bit early given that current C++ support is still incomplete, but anyway here we go: are there any ongoing or planned efforts to implement attributes (syntax: [[attribute]], ?7.6 in current draft) in clang? An implementation targetting the parser and AST components as a first step would be already sufficient for me. Thus I could and would dig into it (I just need something like parfor to overcome these openmp-like pragma hell). Then someone (else) could work on the trickier codegen part and implement the semantics of the predefined attributes. Best regards Olaf Krzikalla From rideau3 at gmail.com Mon Apr 12 08:17:43 2010 From: rideau3 at gmail.com (Sean Hunt) Date: Mon, 12 Apr 2010 07:17:43 -0600 Subject: [cfe-dev] C++0x attributes In-Reply-To: <4BC30F20.2050900@tu-dresden.de> References: <4BC30F20.2050900@tu-dresden.de> Message-ID: <4BC31D77.5010003@gmail.com> On 04/12/2010 06:16 AM, Olaf Krzikalla wrote: > Hi @all, > > maybe the question is a little bit early given that current C++ support > is still incomplete, but anyway here we go: > are there any ongoing or planned efforts to implement attributes > (syntax: [[attribute]], ?7.6 in current draft) in clang? > An implementation targetting the parser and AST components as a first > step would be already sufficient for me. > Thus I could and would dig into it (I just need something like parfor > to overcome these openmp-like pragma hell). > Then someone (else) could work on the trickier codegen part and > implement the semantics of the predefined attributes. > > Best regards > Olaf Krzikalla clang already has a parser of C++0x attributes. It's a bit dated though, as it does not reflect many changes made in the FCD. My SOC proposal focuses on cleaning up attributes a lot. If I am not accepted, I will do the same work but at a slower pace. The standard [[final]], [[noreturn]], and [[aligned]] attributes are supported. [[base_check]], [[override]], [[hiding]], and [[carries_dependency]] are currently parsed and ignored, although the name-checking attributes are checked to make sure they appear on the correct sort of declaration. Sean From Olaf.Krzikalla at tu-dresden.de Mon Apr 12 09:03:04 2010 From: Olaf.Krzikalla at tu-dresden.de (Olaf Krzikalla) Date: Mon, 12 Apr 2010 16:03:04 +0200 Subject: [cfe-dev] C++0x attributes In-Reply-To: <4BC31D77.5010003@gmail.com> References: <4BC30F20.2050900@tu-dresden.de> <4BC31D77.5010003@gmail.com> Message-ID: <4BC32818.5010601@tu-dresden.de> Sean Hunt schrieb: > On 04/12/2010 06:16 AM, Olaf Krzikalla wrote: > >> Hi @all, >> >> maybe the question is a little bit early given that current C++ support >> is still incomplete, but anyway here we go: >> are there any ongoing or planned efforts to implement attributes >> (syntax: [[attribute]], ?7.6 in current draft) in clang? >> An implementation targetting the parser and AST components as a first >> step would be already sufficient for me. >> Thus I could and would dig into it (I just need something like parfor >> to overcome these openmp-like pragma hell). >> Then someone (else) could work on the trickier codegen part and >> implement the semantics of the predefined attributes. >> >> Best regards >> Olaf Krzikalla >> > > clang already has a parser of C++0x attributes. It's a bit dated though, > as it does not reflect many changes made in the FCD. My SOC proposal > focuses on cleaning up attributes a lot. If I am not accepted, I will do > the same work but at a slower pace. > OK, sounds good for me anyway. Of course it would be better as a SOC project. Where can I sign as a proponent? :-) I found the "old" attribute support in the clang code, however I wasn't aware of the fact that the parser already handles the [[]] syntax. Though one important thing is the possibility to attach attributes to statements. If I didn't overlooked something, for the moment you can attach them to declarations only. Another thing is the ability to add implementation-defined attributes by external code (e.g. I'm working on a source-to-source transformator based on clang and I know of other people doing the same). Best regards Olaf Krzikalla From dgregor at apple.com Mon Apr 12 11:26:20 2010 From: dgregor at apple.com (Douglas Gregor) Date: Mon, 12 Apr 2010 09:26:20 -0700 Subject: [cfe-dev] newbie wants to do round-trip, source to source C parsing In-Reply-To: References: Message-ID: <0120EED8-4A63-46CF-828B-3754534FCC9D@apple.com> On Apr 8, 2010, at 12:22 PM, Simon wrote: > Hello! I discovered clang from this thread: > http://stackoverflow.com/questions/239722/ast-from-c-code > > The example link in the thread describing how to perform 'source to > source' parsing and re-writing using clang doesn't work anymore :-( > Can anybody give links and/or hints and tips on how to do this and > where to start? Check out the Rewriter class, which helps with rewriting specific parts of the source without disturbing the rest of the source. Also, look at the Objective-C rewriter in lib/Frontend/RewriteObjc.cpp. - Doug From clattner at apple.com Mon Apr 12 12:28:13 2010 From: clattner at apple.com (Chris Lattner) Date: Mon, 12 Apr 2010 10:28:13 -0700 Subject: [cfe-dev] =?windows-1252?q?Obj-C_Super_badly_broken=85?= In-Reply-To: <84D1AD51-B0F7-42EE-9D54-B4E0F5569E21@shadowlab.org> References: <84D1AD51-B0F7-42EE-9D54-B4E0F5569E21@shadowlab.org> Message-ID: <8E32A0D4-39F9-44B7-9FDC-7108B542C948@apple.com> On Apr 12, 2010, at 1:59 AM, Jean-Daniel Dupas wrote: > Hi, > > Look like recent change in super handling in Obj-C broke it in a nasty way. > > In short, when using [super classMethod] in a class derived class, 'self' does not point on the derived class in the super's method invocation, but it contains the super class instead. > > See Bug 6819 for details. > Fixed, thanks a lot for the great testcase! No good deed goes unpunished :) -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100412/9a2da8b8/attachment.html From clattner at apple.com Mon Apr 12 19:12:41 2010 From: clattner at apple.com (Chris Lattner) Date: Mon, 12 Apr 2010 17:12:41 -0700 Subject: [cfe-dev] Clang macro expansion differs from GCC In-Reply-To: References: <4F1B53BA-DEA5-46DB-BAC5-F1921D832B63@rice.edu> <079BB2A4-126C-4C92-90C0-DF99CA1AEBEE@apple.com> Message-ID: On Apr 11, 2010, at 11:43 AM, David Peixotto wrote: > Hi Chris, > > I took a look at modifying the preprocessor output and it was pretty > straightforward. I have attached a patch that makes the preprocessed output > less conservative in adding spaces between periods. It will now add a space to > avoid turning ".. ." into "...", but does not always add a space between two > consecutive dots. > > The change was done by keeping track of the last two tokens that were output > and testing against those two tokens to avoid creating "...". Previously only > the last output token was tracked and tested against, which caused any two > consecutive . tokens to have a space between them. > > The patch passes all the tests in the tests subdirectory. I modified one test > to reflect the output changing from ". . ." to ".. .". This output happens to > match the expected output in the test comment. I also added a test for the > original case that was causing me problems. > > Please let me know if there are more tests I should run or anything else that > needs to happen for the patch to be accepted. Thanks! This patch looks great, except that it happens to conflict on mainline. :( Please send and updated patch and I'll be happy to apply it for you. One minor thing is to watch & placement in "const Token& PrevPrevTok, " Thanks for working on this! -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100412/d927beda/attachment.html From clattner at apple.com Mon Apr 12 19:39:54 2010 From: clattner at apple.com (Chris Lattner) Date: Mon, 12 Apr 2010 17:39:54 -0700 Subject: [cfe-dev] [PATCH] options -ffunction-sections and -fdata-sections In-Reply-To: <4BBD971D.8020806@invia.fr> References: <4BBCE0C2.4090809@invia.fr> <4BBD0664.6030102@invia.fr> <4BBD971D.8020806@invia.fr> Message-ID: On Apr 8, 2010, at 1:43 AM, Sylvere Teissier wrote: > Chris Lattner a ?crit : >> >> On Apr 7, 2010, at 3:25 PM, Sylvere Teissier wrote: >> >> Hi Sylvere, >> >> I agree that they can't be happen with linkonce linkage... but this >> should be handled in the backend, not in the frontend. >> TargetLoweringObjectFileELF::SelectSectionForGlobal is in charge of >> picking the section to use of a global, can you put this logic there? >> >> -Chris > > Hi Chris, > > Perhaps I don't understand correctly your remark but that's what this > patch does: The function > TargetLoweringObjectFileELF::SelectSectionForGlobal is modified. > > There are 2 patchs: 1 for llvm tree and 1 for clang tree. Aha, I either wildly misread your patch or read an earlier one, sorry about that! I applied your llvm patch here (with a few changes + testcase): http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100412/099668.html and your clang patch here: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20100412/029278.html Can you write a testcase for the clang part? Thanks! -Chris From clattner at apple.com Mon Apr 12 20:12:40 2010 From: clattner at apple.com (Chris Lattner) Date: Mon, 12 Apr 2010 18:12:40 -0700 Subject: [cfe-dev] AltiVec support with remarks considered In-Reply-To: <4BBAA6CC.3020708@Gmail.com> References: <4BBAA6CC.3020708@Gmail.com> Message-ID: <9C97E4A6-42DD-41BD-8E9B-2707047E40F0@apple.com> On Apr 5, 2010, at 8:13 PM, Anton Yartsev wrote: > Hi all, > > Attached are the header and the patch giving support for all the predicates and a portion of another AltiVec functions. The test is also attached. > 'altivec.h' is now included implicitly when '-faltivec' option is set. Only vital builtins are handled by clang, others are supported via header. > Please review. Hi Anton, I have no opinion or background to decide if this implements the feature properly, but the patch itself looks great to me. One minor change though: please remove __builtin_altivec_abs_v4sf. Instead of having the builtin, you can just implement vec_abs with the corresponding expanded code in the header. Feel free to apply the patch (or resend and I'll apply) with that change. Thanks! -Chris From dmp at rice.edu Mon Apr 12 23:44:26 2010 From: dmp at rice.edu (David Peixotto) Date: Mon, 12 Apr 2010 23:44:26 -0500 Subject: [cfe-dev] Clang macro expansion differs from GCC In-Reply-To: References: <4F1B53BA-DEA5-46DB-BAC5-F1921D832B63@rice.edu> <079BB2A4-126C-4C92-90C0-DF99CA1AEBEE@apple.com> Message-ID: <01912E59-2862-4C93-B094-C4F608FFB1D3@rice.edu> Hi Chris, Here is an updated patch that applied cleanly to the trunk. I can see that it is quite a moving target so hopefully it is still valid by the time you get it :) I also fixed the formatting of the & token to be consistent with the rest of the code. Please let me know if you see any more issues. Thanks! -Dave On Apr 12, 2010, at 7:12 PM, Chris Lattner wrote: > > On Apr 11, 2010, at 11:43 AM, David Peixotto wrote: > >> Hi Chris, >> >> I took a look at modifying the preprocessor output and it was pretty >> straightforward. I have attached a patch that makes the preprocessed output >> less conservative in adding spaces between periods. It will now add a space to >> avoid turning ".. ." into "...", but does not always add a space between two >> consecutive dots. >> >> The change was done by keeping track of the last two tokens that were output >> and testing against those two tokens to avoid creating "...". Previously only >> the last output token was tracked and tested against, which caused any two >> consecutive . tokens to have a space between them. >> >> The patch passes all the tests in the tests subdirectory. I modified one test >> to reflect the output changing from ". . ." to ".. .". This output happens to >> match the expected output in the test comment. I also added a test for the >> original case that was causing me problems. >> >> Please let me know if there are more tests I should run or anything else that >> needs to happen for the patch to be accepted. Thanks! > > This patch looks great, except that it happens to conflict on mainline. :( Please send and updated patch and I'll be happy to apply it for you. One minor thing is to watch & placement in "const Token& PrevPrevTok, " > > Thanks for working on this! > > -Chris > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100412/ce35f959/attachment-0002.html -------------- next part -------------- A non-text attachment was scrubbed... Name: PPdots2.patch Type: application/octet-stream Size: 4829 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100412/ce35f959/attachment-0001.obj -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100412/ce35f959/attachment-0003.html From ihusar at fit.vutbr.cz Tue Apr 13 06:49:28 2010 From: ihusar at fit.vutbr.cz (ihusar) Date: Tue, 13 Apr 2010 13:49:28 +0200 Subject: [cfe-dev] Memory consumption measurement results, for revision 100620 In-Reply-To: <624488E1-4000-4208-B003-8618EFAD6679@apple.com> References: <850C09A2-6029-4562-9DF1-A20FBF2732C9@apple.com> <20B42DEF-081B-4218-9E05-0B2C2ECA0984@apple.com> <624488E1-4000-4208-B003-8618EFAD6679@apple.com> Message-ID: > > On Apr 2, 2010, at 6:24 AM, ihusar wrote: >> Hello, >> I made some tests for the latest revision 100183 >> and the memory consumption has gotten even higher compared to revision >> 99809. >> >> For the same 12MB file: >> >> clang (no args): 5GB >> clang -O0 -g0: 5GB >> clang -O0 -g: 6.3GB, stopped after 33 minutes >> opt --disable-output: 3.7 GB >> opt -O3 --disable-output: 3.9 GB >> >> Details can be found here: >> http://lissom.aps-brno.cz/tmp/clang_rev100183.xls >> and http://lissom.aps-brno.cz/tmp/clang_rev99809.xls > > Please try again post r100261, it should substantially improve the 1.3G > of bloat going from -g0 -> -g. > > -Chris Hello, so I bought some memory, so my computer has 8 GB now and results for a quite recent revision 100620 are as follows: clang -g0 -O0: 5 GB clang -g1 -O0: 7.6 GB (for previous results for revision 100183, the test was stopped before it ended) clang -g3 -O0: 7.6 GB opt --disable-output: 3.8 GB (for file generated with clang -g3) gcc -g0 -O0: 1.4 GB (object file for x86 was also generated) gcc -g1 -O0: 1.4 GB gcc -g3 -O0: 2.0 GB The memory consumption for large files is much higher than in gcc. The only serious problem for standard usage I can imagine right now, is when "make" tool runs multiple instances of clang in parallel. Also, for large generated files would be the compilation on standard computer unbearably slow because of swapping, or on a 32-bit machine impossible because of insufficient address space. Again, details are here: http://lissom.aps-brno.cz/tmp/clang_rev100620.xls, http://lissom.aps-brno.cz/tmp/clang_rev100183.xls and http://lissom.aps-brno.cz/tmp/clang_rev99809.xls. Best regards, Adam From widman at gimpel.com Tue Apr 13 10:31:28 2010 From: widman at gimpel.com (James Widman) Date: Tue, 13 Apr 2010 11:31:28 -0400 Subject: [cfe-dev] blog post about clang diagnostics In-Reply-To: <04D5D109-E348-47D4-A3F9-702B83ABAAC6@apple.com> References: <04D5D109-E348-47D4-A3F9-702B83ABAAC6@apple.com> Message-ID: On Apr 6, 2010, at 2:36 AM, Chris Lattner wrote: > FYI, it's been too long since we've had a blog post, so I wrote this up tonight: > http://blog.llvm.org/2010/04/amazing-feats-of-clang-error-recovery.html > > Thoughts and comments welcome! Apologies in advance, because I know I'm being pedantic, *but*... You wrote: > [...] if you comment out the two > using directives in the example above [...] Many seasoned C++ programmers get this terminology wrong. The aforementioned things in the example: using B1::f; using B2::f; ... are using-declarations, not using-directives. This might help to keep it straight: A using-declaration is a *declaration* in the sense that it *declares* (introduces) a name in the scope where it appears. A using-directive is not a declaration *at all*, and it doesn't introduce any names in the scope where it appears. It is a *directive* in the sense that it sort of *tells name lookup to behave differently* (whereas a declaration tends to alter just the input to name lookup but not the behavior). And a using-directive always names a *namespace*. namespace N{} using namespace N; // ok namespace Q{ void f(); } using namespace Q::f(); // error (expected a namespace name) ... whereas a using-declaration can name just about anything that can be named with a qualified-id (with the exception of a template-id (grammar term)). James Widman -- Gimpel Software http://gimpel.com From clattner at apple.com Tue Apr 13 11:49:52 2010 From: clattner at apple.com (Chris Lattner) Date: Tue, 13 Apr 2010 09:49:52 -0700 Subject: [cfe-dev] blog post about clang diagnostics In-Reply-To: References: <04D5D109-E348-47D4-A3F9-702B83ABAAC6@apple.com> Message-ID: <4437F2A0-2B2D-45B7-BAA3-210FB7399448@apple.com> fixed thanks. On Apr 13, 2010, at 8:31 AM, James Widman wrote: > > On Apr 6, 2010, at 2:36 AM, Chris Lattner wrote: > >> FYI, it's been too long since we've had a blog post, so I wrote this up tonight: >> http://blog.llvm.org/2010/04/amazing-feats-of-clang-error-recovery.html >> >> Thoughts and comments welcome! > > Apologies in advance, because I know I'm being pedantic, *but*... > > You wrote: >> [...] if you comment out the two >> using directives in the example above [...] > > Many seasoned C++ programmers get this terminology wrong. > > The aforementioned things in the example: > > using B1::f; using B2::f; > > ... are using-declarations, not using-directives. This might help to keep it straight: > > A using-declaration is a *declaration* in the sense that it *declares* (introduces) a name in the scope where it appears. > > A using-directive is not a declaration *at all*, and it doesn't introduce any names in the scope where it appears. It is a *directive* in the sense that it sort of *tells name lookup to behave differently* (whereas a declaration tends to alter just the input to name lookup but not the behavior). > > And a using-directive always names a *namespace*. > > namespace N{} > using namespace N; // ok > > namespace Q{ void f(); } > using namespace Q::f(); // error (expected a namespace name) > > ... whereas a using-declaration can name just about anything that can be named with a qualified-id (with the exception of a template-id (grammar term)). > > James Widman > -- > Gimpel Software > http://gimpel.com > > > From anton.yartsev at gmail.com Tue Apr 13 18:22:13 2010 From: anton.yartsev at gmail.com (Anton Yartsev) Date: Wed, 14 Apr 2010 03:22:13 +0400 Subject: [cfe-dev] AltiVec support with remarks considered In-Reply-To: <9C97E4A6-42DD-41BD-8E9B-2707047E40F0@apple.com> References: <4BBAA6CC.3020708@Gmail.com> <9C97E4A6-42DD-41BD-8E9B-2707047E40F0@apple.com> Message-ID: <4BC4FCA5.1060304@Gmail.com> On 13.04.2010 5:12, Chris Lattner wrote: > On Apr 5, 2010, at 8:13 PM, Anton Yartsev wrote: > > >> Hi all, >> >> Attached are the header and the patch giving support for all the predicates and a portion of another AltiVec functions. The test is also attached. >> 'altivec.h' is now included implicitly when '-faltivec' option is set. Only vital builtins are handled by clang, others are supported via header. >> Please review. >> > Hi Anton, > > I have no opinion or background to decide if this implements the feature properly, but the patch itself looks great to me. > > One minor change though: please remove __builtin_altivec_abs_v4sf. Instead of having the builtin, you can just implement vec_abs with the corresponding expanded code in the header. Feel free to apply the patch (or resend and I'll apply) with that change. > > Thanks! > > -Chris Hi Chris, here are updated files -- Anton -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: altivec.h Url: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100414/4e1f61ae/attachment-0001.h -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: altivec.patch Url: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100414/4e1f61ae/attachment-0001.pl -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: builtins-pcc-altivec.c Url: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100414/4e1f61ae/attachment-0001.c From clattner at apple.com Tue Apr 13 22:56:24 2010 From: clattner at apple.com (Chris Lattner) Date: Tue, 13 Apr 2010 20:56:24 -0700 Subject: [cfe-dev] AltiVec support with remarks considered In-Reply-To: <4BC4FCA5.1060304@Gmail.com> References: <4BBAA6CC.3020708@Gmail.com> <9C97E4A6-42DD-41BD-8E9B-2707047E40F0@apple.com> <4BC4FCA5.1060304@Gmail.com> Message-ID: <068E1CD7-32BB-4E0B-B751-9D9594DCE354@apple.com> On Apr 13, 2010, at 4:22 PM, Anton Yartsev wrote: >> >> One minor change though: please remove __builtin_altivec_abs_v4sf. Instead of having the builtin, you can just implement vec_abs with the corresponding expanded code in the header. Feel free to apply the patch (or resend and I'll apply) with that change. >> >> Thanks! >> >> -Chris > Hi Chris, > > here are updated files Applied in r101215! Note that I had to xfail test/Parser/cxx-altivec.cpp since it is now dying with this patch, please investigate. -Chris From clattner at apple.com Tue Apr 13 22:58:39 2010 From: clattner at apple.com (Chris Lattner) Date: Tue, 13 Apr 2010 20:58:39 -0700 Subject: [cfe-dev] Clang macro expansion differs from GCC In-Reply-To: <01912E59-2862-4C93-B094-C4F608FFB1D3@rice.edu> References: <4F1B53BA-DEA5-46DB-BAC5-F1921D832B63@rice.edu> <079BB2A4-126C-4C92-90C0-DF99CA1AEBEE@apple.com> <01912E59-2862-4C93-B094-C4F608FFB1D3@rice.edu> Message-ID: Applied here, thanks! http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20100412/029325.html If there is a PR tracking this, please close it. -Chris On Apr 12, 2010, at 9:44 PM, David Peixotto wrote: > Hi Chris, > > Here is an updated patch that applied cleanly to the trunk. I can see that it is quite a moving target so hopefully it is still valid by the time you get it :) I also fixed the formatting of the & token to be consistent with the rest of the code. Please let me know if you see any more issues. Thanks! > > -Dave > > > > > On Apr 12, 2010, at 7:12 PM, Chris Lattner wrote: > >> >> On Apr 11, 2010, at 11:43 AM, David Peixotto wrote: >> >>> Hi Chris, >>> >>> I took a look at modifying the preprocessor output and it was pretty >>> straightforward. I have attached a patch that makes the preprocessed output >>> less conservative in adding spaces between periods. It will now add a space to >>> avoid turning ".. ." into "...", but does not always add a space between two >>> consecutive dots. >>> >>> The change was done by keeping track of the last two tokens that were output >>> and testing against those two tokens to avoid creating "...". Previously only >>> the last output token was tracked and tested against, which caused any two >>> consecutive . tokens to have a space between them. >>> >>> The patch passes all the tests in the tests subdirectory. I modified one test >>> to reflect the output changing from ". . ." to ".. .". This output happens to >>> match the expected output in the test comment. I also added a test for the >>> original case that was causing me problems. >>> >>> Please let me know if there are more tests I should run or anything else that >>> needs to happen for the patch to be accepted. Thanks! >> >> This patch looks great, except that it happens to conflict on mainline. :( Please send and updated patch and I'll be happy to apply it for you. One minor thing is to watch & placement in "const Token& PrevPrevTok, " >> >> Thanks for working on this! >> >> -Chris >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100413/8b3eb958/attachment.html From kyenchik at yahoo.com Wed Apr 14 01:52:19 2010 From: kyenchik at yahoo.com (Kevin Yenchik) Date: Tue, 13 Apr 2010 23:52:19 -0700 (PDT) Subject: [cfe-dev] Principal Compiler Engineer Opportunity - Sony Playstation Message-ID: <192513.44271.qm@web59208.mail.re1.yahoo.com> The Principal Software Engineer will help drive forward next generation technology through the use of compiler techniques.? We are looking for proven, world class technical expertise in compiler optimization. ? * Be a key contributor on SCEA 1st party's next generation PlayStation Tools and Technology team * Provide technical leadership in a truly collaborative effort that brings out the best in SCEA * Work with your team and other technical leaders to ensure the software is elegant, efficient, utterly??? ? reliable, and done on time * Provide vision and direction in your area of technical specialization * Research, analyze, and write up technical designs and project plans and review plans of others * Communicate clearly in the form of written correspondence and design documentation * Work with technical writers as necessary * Create efficient, flexible, and sustainable architectures * Create automated tests to ensure reliability * Even your dreams should be in SSA form ? If interested, please apply via the link below: ? http://playstation.taleo.net/careersection/sceaexternal1/jobdetail.ftl?lang=en&job=01740 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100413/2edac39e/attachment.html From anton.yartsev at gmail.com Wed Apr 14 08:56:07 2010 From: anton.yartsev at gmail.com (Anton Yartsev) Date: Wed, 14 Apr 2010 17:56:07 +0400 Subject: [cfe-dev] AltiVec support with remarks considered In-Reply-To: <068E1CD7-32BB-4E0B-B751-9D9594DCE354@apple.com> References: <4BBAA6CC.3020708@Gmail.com> <9C97E4A6-42DD-41BD-8E9B-2707047E40F0@apple.com> <4BC4FCA5.1060304@Gmail.com> <068E1CD7-32BB-4E0B-B751-9D9594DCE354@apple.com> Message-ID: <4BC5C977.6040902@Gmail.com> On 14.04.2010 7:56, Chris Lattner wrote: > On Apr 13, 2010, at 4:22 PM, Anton Yartsev wrote: > > >>> One minor change though: please remove __builtin_altivec_abs_v4sf. Instead of having the builtin, you can just implement vec_abs with the corresponding expanded code in the header. Feel free to apply the patch (or resend and I'll apply) with that change. >>> >>> Thanks! >>> >>> -Chris >>> >> Hi Chris, >> >> here are updated files >> > Applied in r101215! Note that I had to xfail test/Parser/cxx-altivec.cpp since it is now dying with this patch, please investigate. > > -Chris Added explicit type casting for cpp Additionally removed all unneeded functions with plain char argument(s) -- Anton -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: altivec.patch Url: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100414/aca151e2/attachment-0001.pl -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: builtins-pcc-altivec.c Url: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100414/aca151e2/attachment-0001.c From clattner at apple.com Wed Apr 14 15:36:41 2010 From: clattner at apple.com (Chris Lattner) Date: Wed, 14 Apr 2010 13:36:41 -0700 Subject: [cfe-dev] AltiVec support with remarks considered In-Reply-To: <4BC5C977.6040902@Gmail.com> References: <4BBAA6CC.3020708@Gmail.com> <9C97E4A6-42DD-41BD-8E9B-2707047E40F0@apple.com> <4BC4FCA5.1060304@Gmail.com> <068E1CD7-32BB-4E0B-B751-9D9594DCE354@apple.com> <4BC5C977.6040902@Gmail.com> Message-ID: <3F96169A-719D-4859-BD34-B419EC68B59C@apple.com> On Apr 14, 2010, at 6:56 AM, Anton Yartsev wrote: >>> >>> >> Applied in r101215! Note that I had to xfail test/Parser/cxx-altivec.cpp since it is now dying with this patch, please investigate. >> >> -Chris > Added explicit type casting for cpp > Additionally removed all unneeded functions with plain char argument(s) Applied in r101281, thanks! From dgregor at apple.com Wed Apr 14 15:51:51 2010 From: dgregor at apple.com (Douglas Gregor) Date: Wed, 14 Apr 2010 13:51:51 -0700 Subject: [cfe-dev] Living on Clang Message-ID: <4229484F-BA99-41CD-B4DD-A6A31AB522DA@apple.com> Hello fellow LLVMers and Clangstas, We want to make Clang great, and we need your help! Helping is easy: just build Clang on your platform and start using it as your main compiler for LLVM and Clang development. Much of the Clang team has been living on Clang for at least several weeks already, and we've found it to be quite stable for development. If you run into problems---poor diagnostics, poor debugging experience, compiler crashes, rejecting valid code, whatever---please file Bugzillas so we can get them fixed. Steps to living on Clang: - Make sure you're getting a good revision of Clang/LLVM from Subversion by checking the Buildbots (http://google1.osuosl.org:8011/console). The clang-*-selfhost builds have passed self-host + testing and are good candidates. - Build Clang as part of LLVM (http://clang.llvm.org/get_started.html). I suggest a Release build, since Debug builds tend to be very slow. - Install Clang + LLVM somewhere that isn't where you do your normal LLVM/Clang development. - Configure with the environment variables CC=/path/to/clang CXX=/path/to/clang++, which works with either autoconf configure or CMake cmake/ccmake. - Build LLVM and Clang as normal. - Report your experiences to help us improve Clang! - Doug From sanxiyn at gmail.com Wed Apr 14 21:23:55 2010 From: sanxiyn at gmail.com (Seo Sanghyeon) Date: Thu, 15 Apr 2010 11:23:55 +0900 Subject: [cfe-dev] Living on Clang In-Reply-To: <4229484F-BA99-41CD-B4DD-A6A31AB522DA@apple.com> References: <4229484F-BA99-41CD-B4DD-A6A31AB522DA@apple.com> Message-ID: 2010/4/15 Douglas Gregor : > ?- Report your experiences to help us improve Clang! I switched to Clang, and I got 49 new unexpected failures on Linux. Is this normal? (New, as in, there were no unexpected failures when compiled the same source with GCC.) -- Seo Sanghyeon From rene at exactcode.de Thu Apr 15 02:17:29 2010 From: rene at exactcode.de (Rene Rebe) Date: Thu, 15 Apr 2010 09:17:29 +0200 Subject: [cfe-dev] Living on Clang In-Reply-To: <4229484F-BA99-41CD-B4DD-A6A31AB522DA@apple.com> References: <4229484F-BA99-41CD-B4DD-A6A31AB522DA@apple.com> Message-ID: <9E1253F6-0202-4E58-B5E0-FCB61307B455@exactcode.de> Hi, On Apr 14, 2010, at 10:51 PM, Douglas Gregor wrote: > Hello fellow LLVMers and Clangstas, > > We want to make Clang great, and we need your help! > > Helping is easy: just build Clang on your platform and start using it as your main compiler for LLVM and Clang development. Much of the Clang team has been living on Clang for at least several weeks already, and we've found it to be quite stable for development. If you run into problems---poor diagnostics, poor debugging experience, compiler crashes, rejecting valid code, whatever---please file Bugzillas so we can get them fixed. Been there, done that: http://rene.rebe.de/2010-02-16/llvm-clang-support-in-t2-sde-linux/ And reported C++ issues spotted while at it. I plan to further extend the testing and potentially default to Clang (without GCC) in a future T2 Linux revision. > Steps to living on Clang: > > - Make sure you're getting a good revision of Clang/LLVM from Subversion by checking the Buildbots (http://google1.osuosl.org:8011/console). The clang-*-selfhost builds have passed self-host + testing and are good candidates. > > - Build Clang as part of LLVM (http://clang.llvm.org/get_started.html). I suggest a Release build, since Debug builds tend to be very slow. > > - Install Clang + LLVM somewhere that isn't where you do your normal LLVM/Clang development. > > - Configure with the environment variables CC=/path/to/clang CXX=/path/to/clang++, which works with either autoconf configure or CMake cmake/ccmake. > > - Build LLVM and Clang as normal. > > - Report your experiences to help us improve Clang! > > - Doug -- Ren? Rebe, ExactCODE GmbH, Jaegerstr. 67, DE-10117 Berlin http://exactcode.com | http://t2-project.org | http://rene.rebe.de From abramo.bagnara at gmail.com Thu Apr 15 06:55:14 2010 From: abramo.bagnara at gmail.com (Abramo Bagnara) Date: Thu, 15 Apr 2010 13:55:14 +0200 Subject: [cfe-dev] Diagnostics are unconditionally suppressed after fatal error Message-ID: <4BC6FEA2.5000102@gmail.com> Currently it's not possible for a clang library client to obtain the diagnostics generated after the first fatal error. The attached (trivial) patch add a flag to control this behaviour. Please commit. -------------- next part -------------- A non-text attachment was scrubbed... Name: Diagnostic.patch Type: text/x-patch Size: 2158 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100415/ba7c1065/attachment.bin From dgregor at apple.com Thu Apr 15 09:10:14 2010 From: dgregor at apple.com (Douglas Gregor) Date: Thu, 15 Apr 2010 07:10:14 -0700 Subject: [cfe-dev] Living on Clang In-Reply-To: References: <4229484F-BA99-41CD-B4DD-A6A31AB522DA@apple.com> Message-ID: <96C9E3C4-56D2-4C27-BB83-1BECC896EF5D@apple.com> On Apr 14, 2010, at 7:23 PM, Seo Sanghyeon wrote: > 2010/4/15 Douglas Gregor : >> - Report your experiences to help us improve Clang! > > I switched to Clang, and I got 49 new unexpected failures on Linux. Is > this normal? (New, as in, there were no unexpected failures when > compiled the same source with GCC.) This is not normal. It may be a symptom of http://llvm.org/bugs/show_bug.cgi?id=6795 It looks like we still need some help tracking down problems on Linux; we're not seeing any of these failures on Mac OS X. - Doug From wingusr at gmail.com Thu Apr 15 09:29:01 2010 From: wingusr at gmail.com (TP) Date: Thu, 15 Apr 2010 07:29:01 -0700 Subject: [cfe-dev] Trying to use CLang / CLang Static Analyzer under Windows XP SP3 32-bit In-Reply-To: References: Message-ID: I've managed to get scan-build working on Windows XP Pro SP3 using a Visual Studio 2008 built version of clang.exe. This post describes what I had to do. As others mentioned to my initial post, you have to use gcc (I was under the mistaken impression that clang was a *replacement* for gcc). First some things to note about trying to run the scan-build perl script on Windows XP Pro SP3. 1). ActiveState perl doesn't work with scan-build. The getpwuid function is unimplemented. Easy to get around by just faking it. List form of pipe open not implemented, so it can't handle: # Query clang for analysis options. open(PIPE, "-|", $Clang, "-cc1", "-help") or DieDiag("Cannot execute '$Clang'\n"); Once I saw that error I gave up on trying to use ActiveState perl. 2). You can't run cygwin perl using the normal Windows XP command prompt window (or JP Software's enhanced shell 4NT for that matter). Things like `uname` or "system 'mkdir','-p',$NewDir;" don't work. You have to use the cygwin bash shell. 3). In order to debug the perl fork() command (used inside ccc-analyzer), you need to run perl -d inside an xterm window. This means that you not only need xterm, but also X11. See http://x.cygwin.com/ for installation instructions. Use the created Start -> Cygwin-X -> XWin Server shortcut to start a resizable XTerm window. Then you can do the following: perl /cygdrive/c/llvm/tools/clang/tools/scan-build/scan-build gcc t.c or: perl /cygdrive/c/llvm/tools/clang/tools/scan-build/scan-build gcc -v -v -v t.c to get a bit more info on what's going on. Once you get all that sorted out, you then will hit some bugs in scan-build and ccc-analyzer. First of all, it turns out that the following is *normal* for clean .c files: ANALYZE: t.c main scan-build: Removing directory '/tmp/scan-build-2010-04-15-3' because it contains no reports. So if there are no warnings or errors you see *nothing*. Therefore, when first testing scan-build, make sure your small test file actually has an error or two. Then you should see something like this: ANALYZE: t.c main t.c(7) : warning: Value stored to 'c' is never read c = a + b; ^ ~~~~~ t.c(7) : warning: The left operand of '+' is a garbage value c = a + b; ~ ^ 2 warnings generated. scan-build: 2 bugs found. scan-build: Run 'scan-view /tmp/scan-build-2010-04-15-1' to examine bug reports. (where /tmp is actually c:\cygwin\tmp). I don't bother with scan-view, I just open the index.html directly. There are a number of problems in scan-build since it doesn't seem to be in the place where it used to be (or maybe there's a symbolic link that doesn't show up on Windows XP)? Change: my $ClangSB = Cwd::realpath("$RealBin/bin/clang"); to: my $ClangSB = Cwd::realpath("$RealBin/../../../../bin/Debug/clang.exe"); (assuming you built a Debug version of clang with Visual Studio 2008) Change: my $AbsRealBin = Cwd::realpath($RealBin); my $Cmd = "$AbsRealBin/libexec/ccc-analyzer"; my $CmdCXX = "$AbsRealBin/libexec/c++-analyzer"; To: my $AbsRealBin = Cwd::realpath($RealBin); my $Cmd = "$AbsRealBin/ccc-analyzer"; my $CmdCXX = "$AbsRealBin/c++-analyzer"; Change: my $ScanView = Cwd::realpath("$RealBin/scan-view"); To: my $ScanView = Cwd::realpath("$RealBin/../scan-view/scan-view"); in ccc-analyzer: in sub GetCCArgs() chomp $line; $line =~ s/^\s+//; my @items = quotewords('\s+', 0, $line); should be changed to: chomp $line; $line =~ s/^\s+//; $line =~ s/\cM//; #%%%% remove trailing carriage return my @items = quotewords('\s+', 0, $line); Otherwise you get the following error: Use of uninitialized value $CmdArgs[25] in exec at /cygdrive/c/llvm/tools/clang/tools/scan-build/ccc-analyzer line 238. The remaining problem is caused by sending cygwin style filenames to a clang.exe built with Visual Studio 2008 (which doesn't understand such things): if ($RunAnalyzer) { if (defined $ResultFile) { push @CmdArgs,'-o'; push @CmdArgs, $ResultFile; } elsif (defined $HtmlDir) { push @CmdArgs,'-o'; push @CmdArgs, $HtmlDir; } } should be changed to: if ($RunAnalyzer) { if (defined $ResultFile) { push @CmdArgs,'-o'; if ($ResultFile =~ m!^/cygdrive!) { $ResultFile =~ s!/cygdrive/(.)!$1:!i; } else { $ResultFile = "c:/cygwin$ResultFile"; } push @CmdArgs, $ResultFile; } elsif (defined $HtmlDir) { push @CmdArgs,'-o'; if ($HtmlDir =~ m!^/cygdrive!) { $HtmlDir =~ s!/cygdrive/(.)!$1:!i; } else { $HtmlDir = "c:/cygwin$HtmlDir"; } push @CmdArgs, $HtmlDir; } } Finally. I found that in order to debug ccc-analyzer, in scan-build's RunBuildCommand(), I had to change: shift @$Args; unshift @$Args, $CCAnalyzer; to: shift @$Args; unshift @$Args, $CCAnalyzer; unshift @$Args, "-d"; unshift @$Args, "perl"; Then: $DB::single = 1; will break wherever I want in ccc-analyzer. Without the above change, perl -d scan-build will debug scan-build, but *doesn't* stop at $DB::single=1; statements inside ccc-analyzer. This is presumably because ccc-analyzer is started via: return (system(@$Args) >> 8); so the debugger doesn't know to also debug it unless explicitly told to? From kennethuil at gmail.com Thu Apr 15 09:32:54 2010 From: kennethuil at gmail.com (Kenneth Uildriks) Date: Thu, 15 Apr 2010 09:32:54 -0500 Subject: [cfe-dev] [LLVMdev] Living on Clang In-Reply-To: <9E1253F6-0202-4E58-B5E0-FCB61307B455@exactcode.de> References: <4229484F-BA99-41CD-B4DD-A6A31AB522DA@apple.com> <9E1253F6-0202-4E58-B5E0-FCB61307B455@exactcode.de> Message-ID: I can't switch to clang on my project until it can handle boost headers. On Thu, Apr 15, 2010 at 2:17 AM, Rene Rebe wrote: > Hi, > > On Apr 14, 2010, at 10:51 PM, Douglas Gregor wrote: > >> Hello fellow LLVMers and Clangstas, >> >> We want to make Clang great, and we need your help! >> >> Helping is easy: just build Clang on your platform and start using it as your main compiler for LLVM and Clang development. Much of the Clang team has been living on Clang for at least several weeks already, and we've found it to be quite stable for development. If you run into problems---poor diagnostics, poor debugging experience, compiler crashes, rejecting valid code, whatever---please file Bugzillas so we can get them fixed. > > Been there, done that: http://rene.rebe.de/2010-02-16/llvm-clang-support-in-t2-sde-linux/ > > And reported C++ issues spotted while at it. I plan to further extend the testing and potentially default to Clang (without GCC) in a future T2 Linux revision. > >> Steps to living on Clang: >> >> ?- Make sure you're getting a good revision of Clang/LLVM from Subversion by checking the Buildbots (http://google1.osuosl.org:8011/console). The clang-*-selfhost builds have passed self-host + testing and are good candidates. >> >> ?- Build Clang as part of LLVM (http://clang.llvm.org/get_started.html). I suggest a Release build, since Debug builds tend to be very slow. >> >> ?- Install Clang + LLVM somewhere that isn't where you do your normal LLVM/Clang development. >> >> ?- Configure with the environment variables CC=/path/to/clang CXX=/path/to/clang++, which works with either autoconf configure or CMake cmake/ccmake. >> >> ?- Build LLVM and Clang as normal. >> >> ?- Report your experiences to help us improve Clang! >> >> ? ? ? - Doug > > -- > ?Ren? Rebe, ExactCODE GmbH, Jaegerstr. 67, DE-10117 Berlin > ?http://exactcode.com | http://t2-project.org | http://rene.rebe.de > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From dgregor at apple.com Thu Apr 15 09:38:59 2010 From: dgregor at apple.com (Douglas Gregor) Date: Thu, 15 Apr 2010 07:38:59 -0700 Subject: [cfe-dev] [LLVMdev] Living on Clang In-Reply-To: References: <4229484F-BA99-41CD-B4DD-A6A31AB522DA@apple.com> <9E1253F6-0202-4E58-B5E0-FCB61307B455@exactcode.de> Message-ID: On Apr 15, 2010, at 7:32 AM, Kenneth Uildriks wrote: > I can't switch to clang on my project until it can handle boost headers. The intent of using Clang for LLVM & Clang development is that we can improve compiler quality (diagnostics, debugging, etc.) on a code base where Clang works reasonably well already. For other code bases, we're likely to have more basic problems---rejecting valid code, complaining about ill-formed code that GCC accepts, horrid miscompilations, etc.---so we get a different kind of feedback. For Boost specifically, we have a tracking bug (http://llvm.org/bugs/show_bug.cgi?id=6023) and are interested in reduced problems that show up in Boost libraries [*]. - Doug [*] Actually, we're *particularly* interested in Boost since there will be a Clang talk at BoostCon this year. Check it out at http://www.boostcon.com/home . > On Thu, Apr 15, 2010 at 2:17 AM, Rene Rebe wrote: >> Hi, >> >> On Apr 14, 2010, at 10:51 PM, Douglas Gregor wrote: >> >>> Hello fellow LLVMers and Clangstas, >>> >>> We want to make Clang great, and we need your help! >>> >>> Helping is easy: just build Clang on your platform and start using it as your main compiler for LLVM and Clang development. Much of the Clang team has been living on Clang for at least several weeks already, and we've found it to be quite stable for development. If you run into problems---poor diagnostics, poor debugging experience, compiler crashes, rejecting valid code, whatever---please file Bugzillas so we can get them fixed. >> >> Been there, done that: http://rene.rebe.de/2010-02-16/llvm-clang-support-in-t2-sde-linux/ >> >> And reported C++ issues spotted while at it. I plan to further extend the testing and potentially default to Clang (without GCC) in a future T2 Linux revision. >> >>> Steps to living on Clang: >>> >>> - Make sure you're getting a good revision of Clang/LLVM from Subversion by checking the Buildbots (http://google1.osuosl.org:8011/console). The clang-*-selfhost builds have passed self-host + testing and are good candidates. >>> >>> - Build Clang as part of LLVM (http://clang.llvm.org/get_started.html). I suggest a Release build, since Debug builds tend to be very slow. >>> >>> - Install Clang + LLVM somewhere that isn't where you do your normal LLVM/Clang development. >>> >>> - Configure with the environment variables CC=/path/to/clang CXX=/path/to/clang++, which works with either autoconf configure or CMake cmake/ccmake. >>> >>> - Build LLVM and Clang as normal. >>> >>> - Report your experiences to help us improve Clang! >>> >>> - Doug >> >> -- >> Ren? Rebe, ExactCODE GmbH, Jaegerstr. 67, DE-10117 Berlin >> http://exactcode.com | http://t2-project.org | http://rene.rebe.de >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> From csdavec at swan.ac.uk Thu Apr 15 10:04:57 2010 From: csdavec at swan.ac.uk (David Chisnall) Date: Thu, 15 Apr 2010 16:04:57 +0100 Subject: [cfe-dev] Living on Clang In-Reply-To: <4229484F-BA99-41CD-B4DD-A6A31AB522DA@apple.com> References: <4229484F-BA99-41CD-B4DD-A6A31AB522DA@apple.com> Message-ID: <1527EC3E-78B7-487D-9872-4E71CF5EE969@swan.ac.uk> On 14 Apr 2010, at 21:51, Douglas Gregor wrote: > Helping is easy: just build Clang on your platform and start using it as your main compiler for LLVM and Clang development I never bother installing clang - I just add the build location to my path, which saves some time and disk space. Unfortunately, this makes it impossible to build clang with clang, because it's replacing the libraries and executable while building. Would it be possible for the LLVM / Clang makefiles to build these files with a temporary name and then move them over the originals when the build process is finished? This would make it much easier to live on clang. I also had problems last time I tried building LLVM with clang - apparently the makefiles were not respecting the CXX environment variable, so you need a complete reconfigure, which is incredibly irritating. With other projects I test with GCC and clang just by doing: $ gmake CC=clang $ gmake clean $ gmake CC=gcc David -- Sent from my STANTEC-ZEBRA From dgregor at apple.com Thu Apr 15 10:18:01 2010 From: dgregor at apple.com (Douglas Gregor) Date: Thu, 15 Apr 2010 08:18:01 -0700 Subject: [cfe-dev] Living on Clang In-Reply-To: <1527EC3E-78B7-487D-9872-4E71CF5EE969@swan.ac.uk> References: <4229484F-BA99-41CD-B4DD-A6A31AB522DA@apple.com> <1527EC3E-78B7-487D-9872-4E71CF5EE969@swan.ac.uk> Message-ID: On Apr 15, 2010, at 8:04 AM, David Chisnall wrote: > On 14 Apr 2010, at 21:51, Douglas Gregor wrote: > >> Helping is easy: just build Clang on your platform and start using it as your main compiler for LLVM and Clang development > > > I never bother installing clang - I just add the build location to my path, which saves some time and disk space. Unfortunately, this makes it impossible to build clang with clang, because it's replacing the libraries and executable while building. I suggest keeping a separate Clang-built-Clang that you live on, and update periodically to known-good revisions. Otherwise, you're likely to end up with a broken host compiler when something goes wrong on the trunk, which is a complete waste of time. Personally, I update my host Clang each morning to a version that has passed self-host + test. > Would it be possible for the LLVM / Clang makefiles to build these files with a temporary name and then move them over the originals when the build process is finished? This would make it much easier to live on clang. A top level "bootstrap" target would address this issue better. I'd be opposed to having the normal build create temporary compilers that get moved over the originals, because that's more build-system ugliness to confuse IDEs and users alike. > I also had problems last time I tried building LLVM with clang - apparently the makefiles were not respecting the CXX environment variable, so you need a complete reconfigure, which is incredibly irritating. With other projects I test with GCC and clang just by doing: > > $ gmake CC=clang > $ gmake clean > $ gmake CC=gcc gmake CXX=clang++ CC=clang should work fine with the normal makefiles. - Doug From magnus.reftel at gmail.com Thu Apr 15 11:16:09 2010 From: magnus.reftel at gmail.com (Magnus Reftel) Date: Thu, 15 Apr 2010 18:16:09 +0200 Subject: [cfe-dev] Getting the SourceLocation of the qualifier of a parameter Message-ID: Hi all, I'm trying to find the start of a parameter declaration, but only have limited success. The function I'm looking at is defined similar to void foo(const int* p) { } and I'm using ASTConsumer::HandleTranslationUnit to trawl though the AST looking for function definitions. When I find one I'm interested in, I do FunctionDecl* function=static_cast(decl); VarDecl* parm=function->getParamDecl(0); SourceLocation pos; pos=parm->getSourceRange().getBegin(); // Nope, didn't work cout << "Parameter declaration starts at column " << source_manager->getSpellingColumnNumber(pos) << endl; pos=parm->getTypeSpecStartLoc(); // Nope, didn't work wither cout << "Parameter declaration starts at column " << source_manager->getSpellingColumnNumber(pos) << endl; pos=parm->getTypeSourceInfo()->getTypeLoc().getFullSourceRange().getBegin(); // What about this one? cout << "Parameter declaration starts at column " << source_manager->getSpellingColumnNumber(pos) << endl; In all cases I've tried, I get the position of the "int", not the position of the "const". Is there a way of doing it that I have missed, or is this an omission? A simple test case showing this problem is attached. Best Regards Magnus Reftel -------------- next part -------------- A non-text attachment was scrubbed... Name: const_pos-1.zip Type: application/zip Size: 1812 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100415/bac03afd/attachment.zip From clattner at apple.com Thu Apr 15 11:23:23 2010 From: clattner at apple.com (Chris Lattner) Date: Thu, 15 Apr 2010 09:23:23 -0700 Subject: [cfe-dev] Diagnostics are unconditionally suppressed after fatal error In-Reply-To: <4BC6FEA2.5000102@gmail.com> References: <4BC6FEA2.5000102@gmail.com> Message-ID: <95DE930F-E209-4F2F-9410-D427D6E8AAF9@apple.com> On Apr 15, 2010, at 4:55 AM, Abramo Bagnara wrote: > > Currently it's not possible for a clang library client to obtain the > diagnostics generated after the first fatal error. > > The attached (trivial) patch add a flag to control this behaviour. I'm not sure I understand. The idea of a fatal error is that it is the last one emitted. If your library client doesn't want diagnostics to be discarded, it should map things that default to fatal to Error instead. -Chris From dgregor at apple.com Thu Apr 15 11:55:02 2010 From: dgregor at apple.com (Douglas Gregor) Date: Thu, 15 Apr 2010 09:55:02 -0700 Subject: [cfe-dev] Getting the SourceLocation of the qualifier of a parameter In-Reply-To: References: Message-ID: <666724D1-25E3-4A18-88A5-9A5D46B72B10@apple.com> On Apr 15, 2010, at 9:16 AM, Magnus Reftel wrote: > Hi all, > > I'm trying to find the start of a parameter declaration, but only have > limited success. The function I'm looking at is defined similar to > > void foo(const int* p) > { > } > > and I'm using ASTConsumer::HandleTranslationUnit to trawl though the > AST looking for function definitions. When I find one I'm interested > in, I do > > FunctionDecl* function=static_cast(decl); > VarDecl* parm=function->getParamDecl(0); > SourceLocation pos; > pos=parm->getSourceRange().getBegin(); // Nope, didn't work > cout << "Parameter declaration starts at column " << > source_manager->getSpellingColumnNumber(pos) << endl; > pos=parm->getTypeSpecStartLoc(); // Nope, didn't work wither > cout << "Parameter declaration starts at column " << > source_manager->getSpellingColumnNumber(pos) << endl; > pos=parm->getTypeSourceInfo()->getTypeLoc().getFullSourceRange().getBegin(); > // What about this one? > cout << "Parameter declaration starts at column " << > source_manager->getSpellingColumnNumber(pos) << endl; > > In all cases I've tried, I get the position of the "int", not the > position of the "const". Is there a way of doing it that I have > missed, or is this an omission? It's a Clang bug. getTypeSpecStartLoc() should return the location of the "const". Want to take a shot at fixing it? - Doug From zaffanella at cs.unipr.it Thu Apr 15 12:46:35 2010 From: zaffanella at cs.unipr.it (Enea Zaffanella) Date: Thu, 15 Apr 2010 19:46:35 +0200 Subject: [cfe-dev] Diagnostics are unconditionally suppressed after fatal error In-Reply-To: <95DE930F-E209-4F2F-9410-D427D6E8AAF9@apple.com> References: <4BC6FEA2.5000102@gmail.com> <95DE930F-E209-4F2F-9410-D427D6E8AAF9@apple.com> Message-ID: <4BC750FB.4000400@cs.unipr.it> Chris Lattner wrote: > On Apr 15, 2010, at 4:55 AM, Abramo Bagnara wrote: > >> Currently it's not possible for a clang library client to obtain the >> diagnostics generated after the first fatal error. >> >> The attached (trivial) patch add a flag to control this behaviour. > > I'm not sure I understand. The idea of a fatal error is that it is > the last one emitted. If your library client doesn't want diagnostics > to be discarded, it should map things that default to fatal to Error instead. > > -Chris We thought that it was not possible to map a fatal diagnostic to error. Actually, we tried and we got the following assertion failure: [Thread 1] /llvm/tools/clang/include/clang/Basic/Diagnostic.h:333: void clang::Diagnostic::setDiagnosticMapping(clang::diag::kind, clang::diag::Mapping): Assertion failed: (isBuiltinWarningOrExtension(Diag) || Map == diag::MAP_FATAL) && "Cannot map errors!" Aborted Are there other ways to map a fatal to error? Cheers, Enea Zaffanella. From jim.crafton at gmail.com Thu Apr 15 14:54:20 2010 From: jim.crafton at gmail.com (Jim Crafton) Date: Thu, 15 Apr 2010 15:54:20 -0400 Subject: [cfe-dev] Getting preprocessor statements Message-ID: I have a couple of pre-processor questions: How to collect any #includes in a translation unit? How to collect any macros that are defined? Cheers Jim From notfed at gmail.com Thu Apr 15 15:25:34 2010 From: notfed at gmail.com (Jay Sullivan) Date: Thu, 15 Apr 2010 16:25:34 -0400 Subject: [cfe-dev] Clang build (with profiling enabled) fails on FreeBSD Message-ID: I attempted to build clang with profiling enabled, and it won't compile. I was able to compile the Debug and Release versions without problems, but problems arise whenever I try to add profiling. Here's what I attempted to do: $ svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm $ cd llvm/tools $ svn co http://llvm.org/svn/llvm-project/cfe/trunk clang $ cd .. $ ./configure --enable-optimized --enable-profiling $ gmake It was building for a while, but eventually saw the following output: llvm[2]: Linking Release+Profile executable not llvm[2]: ======= Finished Linking Release+Profile Executable not gmake[2]: Leaving directory `/usr/home/jay/progs/llvm/utils/not' gmake[2]: Entering directory `/usr/home/jay/progs/llvm/utils/unittest' gmake[3]: Entering directory `/usr/home/jay/progs/llvm/utils/unittest/googletest' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/usr/home/jay/progs/llvm/utils/unittest/googletest' gmake[3]: Entering directory `/usr/home/jay/progs/llvm/utils/unittest/UnitTestMain' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/usr/home/jay/progs/llvm/utils/unittest/UnitTestMain' gmake[2]: Leaving directory `/usr/home/jay/progs/llvm/utils/unittest' gmake[1]: Leaving directory `/usr/home/jay/progs/llvm/utils' gmake[1]: Entering directory `/usr/home/jay/progs/llvm/lib/VMCore' llvm[1]: Building Intrinsics.gen.tmp from Intrinsics.td gmake[1]: *** [/usr/home/jay/progs/llvm/lib/VMCore/Release+Profile/Intrinsics.gen.tmp] Segmentation fault: 11 (core dumped) gmake[1]: Leaving directory `/usr/home/jay/progs/llvm/lib/VMCore' gmake: *** [all] Error 1 I'm running FreeBSD 7.0 on a PC with 128 Mb of RAM. More details: $ uname -a FreeBSD dell.petio.org 7.0-RELEASE FreeBSD 7.0-RELEASE #2: Tue Dec 23 01:38:59 EST 2008 root at dell.petio.org:/usr/obj/usr/src/sys/DELL i386 $ cc -v Using built-in specs. Target: i386-undermydesk-freebsd Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 4.2.1 20070719 [FreeBSD] -- Jay Sullivan From notfed at gmail.com Thu Apr 15 16:11:06 2010 From: notfed at gmail.com (Jay Sullivan) Date: Thu, 15 Apr 2010 17:11:06 -0400 Subject: [cfe-dev] Clang build (with profiling enabled) fails on FreeBSD In-Reply-To: <20100415202749.GA10200@freebsd.org> References: <20100415202749.GA10200@freebsd.org> Message-ID: Sorry, I had to redo it a few times to get the correct output again. I've uploaded the full output of gmake to: http://petio.org/temp/clangoutput On Thu, Apr 15, 2010 at 4:27 PM, Roman Divacky wrote: > > what happens with "gmake VERBOSE=1" ? I believe our buggy/old gcc > is to be blamed :( > > On Thu, Apr 15, 2010 at 04:25:34PM -0400, Jay Sullivan wrote: >> I attempted to build clang with profiling enabled, and it won't >> compile. ?I was able to compile the Debug and Release versions without >> problems, but problems arise whenever I try to add profiling. >> >> Here's what I attempted to do: >> >> ? ? $ svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm >> ? ? $ cd llvm/tools >> ? ? $ svn co http://llvm.org/svn/llvm-project/cfe/trunk clang >> ? ? $ cd .. >> ? ? $ ./configure --enable-optimized --enable-profiling >> ? ? $ gmake >> >> It was building for a while, but eventually saw the following output: >> >> ? ? llvm[2]: Linking Release+Profile executable not >> ? ? llvm[2]: ======= Finished Linking Release+Profile Executable not >> ? ? gmake[2]: Leaving directory `/usr/home/jay/progs/llvm/utils/not' >> ? ? gmake[2]: Entering directory `/usr/home/jay/progs/llvm/utils/unittest' >> ? ? gmake[3]: Entering directory >> `/usr/home/jay/progs/llvm/utils/unittest/googletest' >> ? ? gmake[3]: Nothing to be done for `all'. >> ? ? gmake[3]: Leaving directory >> `/usr/home/jay/progs/llvm/utils/unittest/googletest' >> ? ? gmake[3]: Entering directory >> `/usr/home/jay/progs/llvm/utils/unittest/UnitTestMain' >> ? ? gmake[3]: Nothing to be done for `all'. >> ? ? gmake[3]: Leaving directory >> `/usr/home/jay/progs/llvm/utils/unittest/UnitTestMain' >> ? ? gmake[2]: Leaving directory `/usr/home/jay/progs/llvm/utils/unittest' >> ? ? gmake[1]: Leaving directory `/usr/home/jay/progs/llvm/utils' >> ? ? gmake[1]: Entering directory `/usr/home/jay/progs/llvm/lib/VMCore' >> ? ? llvm[1]: Building Intrinsics.gen.tmp from Intrinsics.td >> ? ? gmake[1]: *** >> [/usr/home/jay/progs/llvm/lib/VMCore/Release+Profile/Intrinsics.gen.tmp] >> Segmentation fault: 11 (core dumped) >> ? ? gmake[1]: Leaving directory `/usr/home/jay/progs/llvm/lib/VMCore' >> ? ? gmake: *** [all] Error 1 >> >> I'm running FreeBSD 7.0 on a PC with 128 Mb of RAM. More details: >> >> ? ? $ uname -a >> ? ? FreeBSD dell.petio.org 7.0-RELEASE FreeBSD 7.0-RELEASE #2: Tue Dec >> 23 01:38:59 EST 2008 ? ? root at dell.petio.org:/usr/obj/usr/src/sys/DELL >> ?i386 >> >> ? ? $ cc -v >> ? ? Using built-in specs. >> ? ? Target: i386-undermydesk-freebsd >> ? ? Configured with: FreeBSD/i386 system compiler >> ? ? Thread model: posix >> ? ? gcc version 4.2.1 20070719 ?[FreeBSD] >> >> >> -- >> Jay Sullivan >> _______________________________________________ >> cfe-dev mailing list >> cfe-dev at cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > -- Jay Sullivan From notfed at gmail.com Thu Apr 15 16:23:15 2010 From: notfed at gmail.com (Jay Sullivan) Date: Thu, 15 Apr 2010 17:23:15 -0400 Subject: [cfe-dev] Clang build (with profiling enabled) fails on FreeBSD In-Reply-To: References: <20100415202749.GA10200@freebsd.org> Message-ID: So, looks like it's failing on the tblgen command: /usr/home/jay/progs/llvm/Release+Profile/bin/tblgen -I /usr/home/jay/progs/llvm/lib/VMCore -I /usr/home/jay/progs/llvm/include -I /usr/home/jay/progs/llvm/include -I /usr/home/jay/progs/llvm/lib/Target /usr/home/jay/progs/llvm/include/llvm/Intrinsics.td -o /usr/home/jay/progs/llvm/lib/VMCore/Release+Profile/Intrinsics.gen.tmp -gen-intrinsic Here's a trussed output for this command: http://petio.org/temp/tblgen_bad Interestingly, if I try to use a different tblgen (one compiled without profiling enabled), it doesn't crash: http://petio.org/temp/tblgen_good Any thoughts? On Thu, Apr 15, 2010 at 5:11 PM, Jay Sullivan wrote: > Sorry, I had to redo it a few times to get the correct output again. > I've uploaded the full output of gmake to: > http://petio.org/temp/clangoutput > > > On Thu, Apr 15, 2010 at 4:27 PM, Roman Divacky wrote: >> >> what happens with "gmake VERBOSE=1" ? I believe our buggy/old gcc >> is to be blamed :( >> >> On Thu, Apr 15, 2010 at 04:25:34PM -0400, Jay Sullivan wrote: >>> I attempted to build clang with profiling enabled, and it won't >>> compile. ?I was able to compile the Debug and Release versions without >>> problems, but problems arise whenever I try to add profiling. >>> >>> Here's what I attempted to do: >>> >>> ? ? $ svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm >>> ? ? $ cd llvm/tools >>> ? ? $ svn co http://llvm.org/svn/llvm-project/cfe/trunk clang >>> ? ? $ cd .. >>> ? ? $ ./configure --enable-optimized --enable-profiling >>> ? ? $ gmake >>> >>> It was building for a while, but eventually saw the following output: >>> >>> ? ? llvm[2]: Linking Release+Profile executable not >>> ? ? llvm[2]: ======= Finished Linking Release+Profile Executable not >>> ? ? gmake[2]: Leaving directory `/usr/home/jay/progs/llvm/utils/not' >>> ? ? gmake[2]: Entering directory `/usr/home/jay/progs/llvm/utils/unittest' >>> ? ? gmake[3]: Entering directory >>> `/usr/home/jay/progs/llvm/utils/unittest/googletest' >>> ? ? gmake[3]: Nothing to be done for `all'. >>> ? ? gmake[3]: Leaving directory >>> `/usr/home/jay/progs/llvm/utils/unittest/googletest' >>> ? ? gmake[3]: Entering directory >>> `/usr/home/jay/progs/llvm/utils/unittest/UnitTestMain' >>> ? ? gmake[3]: Nothing to be done for `all'. >>> ? ? gmake[3]: Leaving directory >>> `/usr/home/jay/progs/llvm/utils/unittest/UnitTestMain' >>> ? ? gmake[2]: Leaving directory `/usr/home/jay/progs/llvm/utils/unittest' >>> ? ? gmake[1]: Leaving directory `/usr/home/jay/progs/llvm/utils' >>> ? ? gmake[1]: Entering directory `/usr/home/jay/progs/llvm/lib/VMCore' >>> ? ? llvm[1]: Building Intrinsics.gen.tmp from Intrinsics.td >>> ? ? gmake[1]: *** >>> [/usr/home/jay/progs/llvm/lib/VMCore/Release+Profile/Intrinsics.gen.tmp] >>> Segmentation fault: 11 (core dumped) >>> ? ? gmake[1]: Leaving directory `/usr/home/jay/progs/llvm/lib/VMCore' >>> ? ? gmake: *** [all] Error 1 >>> >>> I'm running FreeBSD 7.0 on a PC with 128 Mb of RAM. More details: >>> >>> ? ? $ uname -a >>> ? ? FreeBSD dell.petio.org 7.0-RELEASE FreeBSD 7.0-RELEASE #2: Tue Dec >>> 23 01:38:59 EST 2008 ? ? root at dell.petio.org:/usr/obj/usr/src/sys/DELL >>> ?i386 >>> >>> ? ? $ cc -v >>> ? ? Using built-in specs. >>> ? ? Target: i386-undermydesk-freebsd >>> ? ? Configured with: FreeBSD/i386 system compiler >>> ? ? Thread model: posix >>> ? ? gcc version 4.2.1 20070719 ?[FreeBSD] >>> >>> >>> -- >>> Jay Sullivan >>> _______________________________________________ >>> cfe-dev mailing list >>> cfe-dev at cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev >> > > > > -- > Jay Sullivan > -- Jay Sullivan From dgregor at apple.com Thu Apr 15 16:31:05 2010 From: dgregor at apple.com (Douglas Gregor) Date: Thu, 15 Apr 2010 14:31:05 -0700 Subject: [cfe-dev] [LLVMdev] Living on Clang In-Reply-To: <0D4616E6925F9541919B60692F61509E5A3A3047@orsmsx502.amr.corp.intel.com> References: <4229484F-BA99-41CD-B4DD-A6A31AB522DA@apple.com> <0D4616E6925F9541919B60692F61509E5A3A3047@orsmsx502.amr.corp.intel.com> Message-ID: <153A43E9-A3FE-43BB-B367-75F6203B4108@apple.com> On Apr 15, 2010, at 2:27 PM, Lacey, Mark wrote: >> We want to make Clang great, and we need your help! > > Doug, > > I don't see any type of selfbuild target in the LLVM top level makefile. > This would be a useful way to automate the self build process. > > I've used similar mechanisms before on other compilers, where you can > trivially invoke a three phase build (first you do a full build with your > system compiler, then you use your built compiler to do another full build, > and then take that most recent build compiler to build yet again...). The > build options of the last two phases are identical, and the object files > from those last two passes are compared to ensure that they are identical. Yes, we would love to have this, but nobody has taken the time to write the Makefile/CMake magic to make it happen. - Doug From anton at korobeynikov.info Thu Apr 15 16:54:21 2010 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Fri, 16 Apr 2010 01:54:21 +0400 Subject: [cfe-dev] Clang build (with profiling enabled) fails on FreeBSD In-Reply-To: References: <20100415202749.GA10200@freebsd.org> Message-ID: > Any thoughts? Looks like your gcc is broken. Consider upgrading / downgrading -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From theraven at sucs.org Thu Apr 15 17:03:57 2010 From: theraven at sucs.org (David Chisnall) Date: Thu, 15 Apr 2010 23:03:57 +0100 Subject: [cfe-dev] Clang build (with profiling enabled) fails on FreeBSD In-Reply-To: References: <20100415202749.GA10200@freebsd.org> Message-ID: On 15 Apr 2010, at 22:54, Anton Korobeynikov wrote: >> Any thoughts? > Looks like your gcc is broken. Consider upgrading / downgrading It looks like exactly the same GCC that I've been using on FreeBSD 7.x / 8.0 to build clang, and it works for me, although I've not tried a profiling build. Jay, does it work without profiling for you? David From dgregor at apple.com Thu Apr 15 17:11:10 2010 From: dgregor at apple.com (Douglas Gregor) Date: Thu, 15 Apr 2010 15:11:10 -0700 Subject: [cfe-dev] Getting preprocessor statements In-Reply-To: References: Message-ID: <6DEB7099-A89B-4D51-8346-D5CD450F1BB3@apple.com> On Apr 15, 2010, at 12:54 PM, Jim Crafton wrote: > I have a couple of pre-processor questions: > How to collect any #includes in a translation unit? > How to collect any macros that are defined? You can write a subclass of PPCallbacks and attach an object of that subclass to the preprocessor. Then, you'll see whenever we #include a file, #define a macro, etc. Alternatively, you could extend the (optionally-built) PreprocessingRecord to specifically track #includes (it already tracks macro definitions) and use that information. - Doug From neil at daikokuya.co.uk Thu Apr 15 17:37:18 2010 From: neil at daikokuya.co.uk (Neil Booth) Date: Fri, 16 Apr 2010 07:37:18 +0900 Subject: [cfe-dev] Clang build (with profiling enabled) fails on FreeBSD In-Reply-To: References: Message-ID: <20100415223718.GC267@daikokuya.co.uk> Jay Sullivan wrote:- > I'm running FreeBSD 7.0 on a PC with 128 Mb of RAM. More details: I think you're optimistic. Clang in release-asserts mode only just builds on a 512MB machine of mine; the whole machine is in swap when linking, and it takes 30mins to 1hr just to link the various binaries. Neil. From r.amadini at virgilio.it Fri Apr 16 05:35:02 2010 From: r.amadini at virgilio.it (Roberto Amadini) Date: Fri, 16 Apr 2010 12:35:02 +0200 Subject: [cfe-dev] Patch proposal for __builtin_offsetof construct. Message-ID: <4BC83D56.4050106@virgilio.it> Hi, I'm the student who is trying to fix the problem mentioned in http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-February/007833.html . I followed the guidelines described in the previous messages, creating a dedicated class OffsetOfExpr which doesn't contain any sub-expression. The offsetof base type is encoded in a TypeSourceInfo field, while the sub-components are stored in a SmallVector of OffsetOfExpr::OffsetOfNode (a public struct similar to Action::OffsetOfComponent). Note that the goal of this patch is solely to avoid the unsuitable use of UnaryOperator for OffsetOf expressions: namely, it is not meant to provide a solution to other FIXME's (e.g., type-dependent OffsetOfExpr are still not handled). This patch passes all clang tests (it refers to revision 100962), but since I'm only a beginner in clang development I am note sure about the code I wrote, so any comments and/or suggestions are really welcome. Regards, Roberto. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: OffsetOfExpr.patch Url: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100416/c6817c38/attachment-0001.pl From notfed at gmail.com Fri Apr 16 09:35:39 2010 From: notfed at gmail.com (Jay Sullivan) Date: Fri, 16 Apr 2010 10:35:39 -0400 Subject: [cfe-dev] Clang build (with profiling enabled) fails on FreeBSD In-Reply-To: <20100415223718.GC267@daikokuya.co.uk> References: <20100415223718.GC267@daikokuya.co.uk> Message-ID: On Thu, Apr 15, 2010 at 6:37 PM, Neil Booth wrote: > Jay Sullivan wrote:- > >> I'm running FreeBSD 7.0 on a PC with 128 Mb of RAM. More details: > > I think you're optimistic. ?Clang in release-asserts mode only just > builds on a 512MB machine of mine; the whole machine is in swap > when linking, and it takes 30mins to 1hr just to link the various > binaries. > > Neil. > Hey, now, there's got to be some value in testing the build in a low RAM environment. It is swapping a little bit, but not thrashing! And yes, 30mins to 1hr is accurate. You mean it's not supposed to take that long?? :) -- Jay Sullivan From dgregor at apple.com Fri Apr 16 10:36:11 2010 From: dgregor at apple.com (Douglas Gregor) Date: Fri, 16 Apr 2010 08:36:11 -0700 Subject: [cfe-dev] Patch proposal for __builtin_offsetof construct. In-Reply-To: <4BC83D56.4050106@virgilio.it> References: <4BC83D56.4050106@virgilio.it> Message-ID: <41C8B229-2FAD-4F34-B024-E481F07C7B50@apple.com> On Apr 16, 2010, at 3:35 AM, Roberto Amadini wrote: > Hi, > > I'm the student who is trying to fix the problem mentioned in > http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-February/007833.html . > > I followed the guidelines described in the previous messages, creating a > dedicated class OffsetOfExpr which doesn't contain any sub-expression. > The offsetof base type is encoded in a TypeSourceInfo field, while > the sub-components are stored in a SmallVector of > OffsetOfExpr::OffsetOfNode (a public struct similar to Action::OffsetOfComponent). > > Note that the goal of this patch is solely to avoid the unsuitable use of > UnaryOperator for OffsetOf expressions: namely, it is not meant to provide a > solution to other FIXME's (e.g., type-dependent OffsetOfExpr are still not handled). > This patch passes all clang tests (it refers to revision 100962), but since > I'm only a beginner in clang development I am note sure about the code I wrote, > so any comments and/or suggestions are really welcome. Thanks for tackling this! Even if you're not handling type-dependent __builtin_offsetof expressions, having a proper AST for __builtin_offsetof improves Clang and will make it easier to add support for type-dependent __builtin_offsetof in the future. Some comments inline. For reference, your attachment shows up inline, which makes it hard to apply/test. Please follow the instructions http://llvm.org/docs/DeveloperPolicy.html#patches to configure Thunderbird to send patches in a more Apple-Mail-friendly way. > Index: include/clang/AST/Expr.h > =================================================================== > --- include/clang/AST/Expr.h (revisione 100962) > +++ include/clang/AST/Expr.h (copia locale) > @@ -991,6 +985,78 @@ > virtual child_iterator child_end(); > }; > > +/// OffsetOfExpr > +class OffsetOfExpr : public Expr { > + Please provide some documentation for this AST node, including what it represents and an example of code that will be represented as an OffsetOfExpr. > +public: > + // __builtin_offsetof(type, identifier(.identifier|[expr])*) > + // FIXME: Type-dependent case ignored. > + struct OffsetOfNode { > + SourceLocation LocStart, LocEnd; > + bool isBrackets; // true if [expr], false if .ident > + union { > + FieldDecl *MemberDecl; > + Expr *IndexExpr; > + } U; > + }; You could save a word of storage per OffsetOfNode by mangling the "isBrackets" bit into the lowest bit of the FieldDecl or Expr pointer. llvm::PointerUnion will do this for you. But, see below for more comments on this representation. > +private: > + typedef llvm::SmallVector Components; > + // Base type; > + TypeSourceInfo *TSInfo; > + SourceLocation Loc; > + // Keep track of the various subcomponents (e.g. instance of OffsetOfNode). > + Components Comps; We're trying to eliminate all SmallVectors (and other malloc-allocated memory) from the AST representation. Please put a count of the number of components into this structure, then allocate storage for the OffsetOfNode structures after the OffsetOfExpr node (you'll want to make the OffsetOfExpr constructor private, then add a Create memory to do allocation + construction). > +public: > + > + OffsetOfExpr(QualType type, SourceLocation l, > + TypeSourceInfo *tsi, const Components &comps) > + : Expr(OffsetOfExprClass, type, false, false), > + TSInfo(tsi), Loc(l), Comps(comps) {} > + > + /// \brief Build an empty offsetof. > + explicit OffsetOfExpr(EmptyShell Empty) > + : Expr(OffsetOfExprClass, Empty), TSInfo(0), Comps(0) {} > + > + /// getOperatorLoc - Return the location of the operator. > + SourceLocation getOperatorLoc() const { return Loc; } > + void setOperatorLoc(SourceLocation L) { Loc = L; } > + > + TypeSourceInfo *getTypeSourceInfo() const { > + return TSInfo; > + } > + void setTypeSourceInfo(TypeSourceInfo *tsi) { > + TSInfo = tsi; > + } > + > + const OffsetOfNode* getComponents() const { > + return &Comps[0]; > + } > + void setComponents(Components comps) { > + Comps = comps; > + } > + > + size_t getNumComponents() const { > + return Comps.size(); > + } > + > + virtual SourceRange getSourceRange() const { > + return SourceRange(Loc, Comps.back().LocEnd); > + } > + virtual SourceLocation getExprLoc() const { return Loc; } > + > + static bool classof(const Stmt *T) { > + return T->getStmtClass() == OffsetOfExprClass; > + } > + > + static bool classof(const OffsetOfExpr *) { return true; } > + > + // Iterators > + virtual child_iterator child_begin(); > + virtual child_iterator child_end(); > +}; > + > /// SizeOfAlignOfExpr - [C99 6.5.3.4] - This is for sizeof/alignof, both of > /// types and expressions. > class SizeOfAlignOfExpr : public Expr { > Index: include/clang/AST/StmtNodes.def > =================================================================== > --- include/clang/AST/StmtNodes.def (revisione 100962) > +++ include/clang/AST/StmtNodes.def (copia locale) > @@ -78,6 +78,7 @@ > EXPR(CharacterLiteral , Expr) > EXPR(ParenExpr , Expr) > EXPR(UnaryOperator , Expr) > +EXPR(OffsetOfExpr , Expr) > EXPR(SizeOfAlignOfExpr , Expr) > EXPR(ArraySubscriptExpr , Expr) > EXPR(CallExpr , Expr) > Index: tools/CIndex/CXCursor.cpp > =================================================================== > --- tools/CIndex/CXCursor.cpp (revisione 100962) > +++ tools/CIndex/CXCursor.cpp (copia locale) > @@ -139,7 +139,8 @@ > case Stmt::StringLiteralClass: > case Stmt::CharacterLiteralClass: > case Stmt::ParenExprClass: > - case Stmt::UnaryOperatorClass: > + case Stmt::UnaryOperatorClass: > + case Stmt::OffsetOfExprClass: > case Stmt::SizeOfAlignOfExprClass: > case Stmt::ArraySubscriptExprClass: > case Stmt::BinaryOperatorClass: > Index: lib/Frontend/StmtXML.cpp > =================================================================== > --- lib/Frontend/StmtXML.cpp (revisione 100962) > +++ lib/Frontend/StmtXML.cpp (copia locale) > @@ -125,6 +125,7 @@ > void VisitFloatingLiteral(FloatingLiteral *Node); > void VisitStringLiteral(StringLiteral *Str); > void VisitUnaryOperator(UnaryOperator *Node); > + void VisitOffsetOfExpr(OffsetOfExpr *Node); > void VisitSizeOfAlignOfExpr(SizeOfAlignOfExpr *Node); > void VisitMemberExpr(MemberExpr *Node); > void VisitExtVectorElementExpr(ExtVectorElementExpr *Node); > @@ -260,7 +261,6 @@ > case UnaryOperator::Real: return "__real"; > case UnaryOperator::Imag: return "__imag"; > case UnaryOperator::Extension: return "__extension__"; > - case UnaryOperator::OffsetOf: return "__builtin_offsetof"; > } > } > > @@ -308,6 +308,10 @@ > Doc.addAttribute("op_code", getOpcodeStr(Node->getOpcode())); > } > > +void StmtXML::OffsetOfExpr(OffsetOfExpr *Node) { > + DumpExpr(Node); > +} > + > void StmtXML::VisitSizeOfAlignOfExpr(SizeOfAlignOfExpr *Node) { > DumpExpr(Node); > Doc.addAttribute("is_sizeof", Node->isSizeOf() ? "sizeof" : "alignof"); > Index: lib/Sema/TreeTransform.h > =================================================================== > --- lib/Sema/TreeTransform.h (revisione 100962) > +++ lib/Sema/TreeTransform.h (copia locale) > @@ -3828,6 +3828,12 @@ > > template > Sema::OwningExprResult > +TreeTransform::TransformOffsetOfExpr(OffsetOfExpr *E) { > + return SemaRef.Owned(new (SemaRef.Context) OffsetOfExpr(*E)); > +} Please add a FIXME here so that we don't forget to add the template-instantiation logic later. > > Index: lib/Sema/SemaExpr.cpp > =================================================================== > --- lib/Sema/SemaExpr.cpp (revisione 100962) > +++ lib/Sema/SemaExpr.cpp (copia locale) > @@ -18,6 +18,7 @@ > #include "clang/AST/ASTContext.h" > #include "clang/AST/DeclObjC.h" > #include "clang/AST/DeclTemplate.h" > +#include "clang/AST/Expr.h" > #include "clang/AST/ExprCXX.h" > #include "clang/AST/ExprObjC.h" > #include "clang/Basic/PartialDiagnostic.h" > @@ -6401,9 +6402,6 @@ > Expr *Input = (Expr *)InputArg.get(); > QualType resultType; > switch (Opc) { > - case UnaryOperator::OffsetOf: > - assert(false && "Invalid unary operator"); > - break; > > case UnaryOperator::PreInc: > case UnaryOperator::PreDec: > @@ -6571,8 +6569,8 @@ > SourceLocation RPLoc) { > // FIXME: This function leaks all expressions in the offset components on > // error. > - // FIXME: Preserve type source info. > - QualType ArgTy = GetTypeFromParser(argty); > + TypeSourceInfo *ArgTInfo; > + QualType ArgTy = GetTypeFromParser(argty, &ArgTInfo); > assert(!ArgTy.isNull() && "Missing type argument!"); When ArgTy.isNull(), we should just return with an error. > bool Dependent = ArgTy->isDependentType(); > @@ -6592,6 +6590,7 @@ > Expr* Res = new (Context) ImplicitValueInitExpr(ArgTyPtr); > Res = new (Context) UnaryOperator(Res, UnaryOperator::Deref, > ArgTy, SourceLocation()); > + llvm::SmallVector Comps(NumComponents); > > // offsetof with non-identifier designators (e.g. "offsetof(x, a.b[c])") are a > // GCC extension, diagnose them. > @@ -6608,83 +6607,63 @@ > diag::err_offsetof_incomplete_type)) > return ExprError(); > > - // FIXME: Dependent case loses a lot of information here. And probably > - // leaks like a sieve. > + QualType CurrentType = ArgTy; > for (unsigned i = 0; i != NumComponents; ++i) { > const OffsetOfComponent &OC = CompPtr[i]; > if (OC.isBrackets) { > - // Offset of an array sub-field. TODO: Should we allow vector elements? > - const ArrayType *AT = Context.getAsArrayType(Res->getType()); > - if (!AT) { > - Res->Destroy(Context); > + const ArrayType *AT = Context.getAsArrayType(CurrentType); > + if(!AT) > return ExprError(Diag(OC.LocEnd, diag::err_offsetof_array_type) > - << Res->getType()); > - } > + << CurrentType); > > // FIXME: C++: Verify that operator[] isn't overloaded. > > - // Promote the array so it looks more like a normal array subscript > - // expression. > - DefaultFunctionArrayLvalueConversion(Res); > - > // C99 6.5.2.1p1 > Expr *Idx = static_cast(OC.U.E); > - // FIXME: Leaks Res > if (!Idx->isTypeDependent() && !Idx->getType()->isIntegerType()) > return ExprError(Diag(Idx->getLocStart(), > diag::err_typecheck_subscript_not_integer) > - << Idx->getSourceRange()); > - > - Res = new (Context) ArraySubscriptExpr(Res, Idx, AT->getElementType(), > - OC.LocEnd); > - continue; > + << Idx->getSourceRange()); > + CurrentType = AT->getElementType(); > + Comps[i].U.IndexExpr = Idx; > } > - > - const RecordType *RC = Res->getType()->getAs(); > - if (!RC) { > - Res->Destroy(Context); > - return ExprError(Diag(OC.LocEnd, diag::err_offsetof_record_type) > - << Res->getType()); > - } > - > - // Get the decl corresponding to this. > - RecordDecl *RD = RC->getDecl(); > - if (CXXRecordDecl *CRD = dyn_cast(RD)) { > - if (!CRD->isPOD() && !DidWarnAboutNonPOD && > + else { > + const RecordType *RC = CurrentType->getAs(); > + if (!RC) > + return ExprError(Diag(OC.LocEnd, diag::err_offsetof_array_type) > + << CurrentType); This should be diag::err_offsetof_record_type? > + RecordDecl *RD = RC->getDecl(); > + if (CXXRecordDecl *CRD = dyn_cast(RD)) { > + if (!CRD->isPOD() && !DidWarnAboutNonPOD && > DiagRuntimeBehavior(BuiltinLoc, > PDiag(diag::warn_offsetof_non_pod_type) > << SourceRange(CompPtr[0].LocStart, OC.LocEnd) > - << Res->getType())) > + << CurrentType)) > DidWarnAboutNonPOD = true; > - } > + } > + LookupResult R(*this, OC.U.IdentInfo, OC.LocStart, LookupMemberName); > + LookupQualifiedName(R, RD); > + FieldDecl *MemberDecl = R.getAsSingle(); > + if (!MemberDecl) > + return ExprError(Diag(BuiltinLoc, diag::err_no_member) > + << OC.U.IdentInfo << RD << SourceRange(OC.LocStart, OC.LocEnd)); > > - LookupResult R(*this, OC.U.IdentInfo, OC.LocStart, LookupMemberName); > - LookupQualifiedName(R, RD); > - > - FieldDecl *MemberDecl = R.getAsSingle(); > - // FIXME: Leaks Res > - if (!MemberDecl) > - return ExprError(Diag(BuiltinLoc, diag::err_no_member) > - << OC.U.IdentInfo << RD << SourceRange(OC.LocStart, OC.LocEnd)); > - > - // FIXME: C++: Verify that MemberDecl isn't a static field. > - // FIXME: Verify that MemberDecl isn't a bitfield. > - if (cast(MemberDecl->getDeclContext())->isAnonymousStructOrUnion()) { > - Res = BuildAnonymousStructUnionMemberReference( > - OC.LocEnd, MemberDecl, Res, OC.LocEnd).takeAs(); > - } else { > - PerformObjectMemberConversion(Res, /*Qualifier=*/0, > - *R.begin(), MemberDecl); > - // MemberDecl->getType() doesn't get the right qualifiers, but it > - // doesn't matter here. > - Res = new (Context) MemberExpr(Res, false, MemberDecl, OC.LocEnd, > - MemberDecl->getType().getNonReferenceType()); > + // FIXME: C++: Verify that MemberDecl isn't a static field. > + // FIXME: Verify that MemberDecl isn't a bitfield. > + if (cast(MemberDecl->getDeclContext())->isAnonymousStructOrUnion()) > + CurrentType = MemberDecl->getType(); This isn't going to work. When we find a member of an anonymous struct or union, we need to introduce OffsetOfNodes for the FieldDecls that represent the anonymous unions. Imagine, e.g., struct A { struct { union { int i; float f; }; bool isInt; }; }; If I ask for the offset of "i" in A, we should (semantically!) get an OffsetOfNode referring to the anonymous struct, another OffsetOfNode for the anonymous union, and then, finally, the OffsetOfNode for "i". So you can have more OffsetOfNodes in the AST than there were components parsed by the parser, since we're adding implicit ones. > + else > + CurrentType = MemberDecl->getType().getNonReferenceType(); > + Comps[i].U.MemberDecl = MemberDecl; > } > + Comps[i].LocStart = OC.LocStart; > + Comps[i].LocEnd = OC.LocEnd; > } > + > } > > - return Owned(new (Context) UnaryOperator(Res, UnaryOperator::OffsetOf, > - Context.getSizeType(), BuiltinLoc)); > + return Owned(new (Context) OffsetOfExpr(Context.getSizeType(), BuiltinLoc, > + ArgTInfo, Comps)); > } Aside from the anonymous struct/union issue, this is a big improvement. > Index: lib/AST/ExprConstant.cpp > =================================================================== > --- lib/AST/ExprConstant.cpp (revisione 100962) > +++ lib/AST/ExprConstant.cpp (copia locale) > @@ -16,7 +16,9 @@ > #include "clang/AST/CharUnits.h" > #include "clang/AST/RecordLayout.h" > #include "clang/AST/StmtVisitor.h" > +#include "clang/AST/TypeLoc.h" > #include "clang/AST/ASTDiagnostic.h" > +#include "clang/AST/Expr.h" > #include "clang/Basic/Builtins.h" > #include "clang/Basic/TargetInfo.h" > #include "llvm/ADT/SmallString.h" > @@ -221,7 +223,7 @@ > APValue VisitStmt(Stmt *S) { > return APValue(); > } > - > + > APValue VisitParenExpr(ParenExpr *E) { return Visit(E->getSubExpr()); } > APValue VisitDeclRefExpr(DeclRefExpr *E); > APValue VisitPredefinedExpr(PredefinedExpr *E) { return APValue(E); } > @@ -821,6 +823,7 @@ > > bool VisitCallExpr(CallExpr *E); > bool VisitBinaryOperator(const BinaryOperator *E); > + bool VisitOffsetOfExpr(const OffsetOfExpr *E); > bool VisitUnaryOperator(const UnaryOperator *E); > bool VisitConditionalOperator(const ConditionalOperator *E); > > @@ -1365,20 +1368,56 @@ > return Success(Info.Ctx.getTypeSizeInChars(SrcTy).getQuantity(), E); > } > > +bool IntExprEvaluator::VisitOffsetOfExpr(const OffsetOfExpr *E) { > + CharUnits Result; > + const OffsetOfExpr::OffsetOfNode *Comps = E->getComponents(); > + unsigned n = E->getNumComponents(); > + if (n == 0) > + return false; > + QualType CurrentType = E->getTypeSourceInfo()->getType(); > + for (unsigned i = 0; i != n; ++i) { > + const OffsetOfExpr::OffsetOfNode& ON = Comps[i]; > + if (ON.isBrackets) { > + Expr *Idx = static_cast(ON.U.IndexExpr); > + APSInt IdxResult; > + if (!EvaluateInteger(Idx, IdxResult, Info)) > + return false; > + const ArrayType *AT = Info.Ctx.getAsArrayType(CurrentType); > + if (!AT) > + return false; > + CurrentType = AT->getElementType(); > + CharUnits ElementSize = Info.Ctx.getTypeSizeInChars(CurrentType); > + Result += IdxResult.getSExtValue() * ElementSize; > + } > + else { > + FieldDecl *MemberDecl = ON.U.MemberDecl; > + const RecordType *RT = CurrentType->getAs(); > + if (!RT) > + return false; > + RecordDecl *RD = RT->getDecl(); > + const ASTRecordLayout &RL = Info.Ctx.getASTRecordLayout(RD); > + unsigned i = 0; > + for (RecordDecl::field_iterator Field = RD->field_begin(), > + FieldEnd = RD->field_end(); > + Field != FieldEnd; (void)++Field, ++i) { > + if (*Field == MemberDecl) > + break; > + } > + if (i < RL.getFieldCount()) > + Result += CharUnits::fromQuantity(RL.getFieldOffset(i) / 8); Use ASTContext::getCharWidth() rather than 8. > + if (cast(MemberDecl->getDeclContext())->isAnonymousStructOrUnion()) > + CurrentType = MemberDecl->getType(); If you follow my advice about expanded references into anonymous structs/unions, you won't need to do anything special here. > Index: lib/AST/StmtProfile.cpp > =================================================================== > --- lib/AST/StmtProfile.cpp (revisione 100962) > +++ lib/AST/StmtProfile.cpp (copia locale) > @@ -261,6 +261,10 @@ > ID.AddInteger(S->getOpcode()); > } > > +void StmtProfiler::VisitOffsetOfExpr(OffsetOfExpr *S) { > + VisitExpr(S); > +} > + To profile an OffsetOfExpr, we'll need to visit the type and all of the OffsetOfNodes as well. That way, we can distinguish between different OffsetOfExprs on the same base type. > Index: lib/AST/Expr.cpp > =================================================================== > --- lib/AST/Expr.cpp (revisione 100962) > +++ lib/AST/Expr.cpp (copia locale) > @@ -334,7 +334,6 @@ > case Real: return "__real"; > case Imag: return "__imag"; > case Extension: return "__extension__"; > - case OffsetOf: return "__builtin_offsetof"; > } > } > > @@ -1835,7 +1834,9 @@ > case UnaryOperator::Real: > case UnaryOperator::Imag: > return CheckICE(Exp->getSubExpr(), Ctx); > - case UnaryOperator::OffsetOf: > + } > + } > + case Expr::OffsetOfExprClass: { > // Note that per C99, offsetof must be an ICE. And AFAIK, using > // Evaluate matches the proposed gcc behavior for cases like > // "offsetof(struct s{int x[4];}, x[!.0])". This doesn't affect > @@ -1843,7 +1844,6 @@ > // array subscripts that aren't ICEs, and if the array subscripts > // are ICEs, the value of the offsetof must be an integer constant. > return CheckEvalInICE(E, Ctx); > - } > } > case Expr::SizeOfAlignOfExprClass: { > const SizeOfAlignOfExpr *Exp = cast(E); > @@ -2582,6 +2582,15 @@ > Stmt::child_iterator UnaryOperator::child_begin() { return &Val; } > Stmt::child_iterator UnaryOperator::child_end() { return &Val+1; } > > +// OffsetOfExpr > +Stmt::child_iterator OffsetOfExpr::child_begin() { > + return child_iterator(); > +} > + > +Stmt::child_iterator OffsetOfExpr::child_end() { > + return child_iterator(); > +} This is a tricky area. child_begin()/child_end() are supposed to provide iterators that cover all of the Expr*'s (actually, Stmt*'s) that are subexpressions of the expression node. With OffsetOfExpr, those Expr*'s aren't currently in contiguous memory. In DesignatedInitExpr, which is very similar to OffsetOfExpr, we actually did a little dance where we have an array of Expr* nodes that are all of the subexpressions. Then, each node was either non-Expr* data (e.g., a FieldDecl*) or it was an index into the array of Expr* nodes. child_begin()/child_end() just pointed to the beginning/end of that Expr* array. It's a bit clumsy to implement, but that's what we're stuck with at the moment. Overall, this is a great start on __builtin_offsetof, thanks! I look forward to seeing a revised patch. - Doug From notfed at gmail.com Fri Apr 16 10:36:24 2010 From: notfed at gmail.com (Jay Sullivan) Date: Fri, 16 Apr 2010 11:36:24 -0400 Subject: [cfe-dev] Can't build CLang with CLang on FreeBSD Message-ID: When I try to build clang with clang, I get an error when building Alarm.cpp. When I compile with profiling, I'm seeing the error "clang: warning: the clang compiler does not support '-pg' ". The build then fails in the same place (Alarm.cpp) whether I use Debug and/or Release, with or without profiling. My operating system is FreeBSD 7.0-RELEASE. The clang I'm using was built with gcc4.2.1 (admittedly I'm not sure if that matters). ---- Here's some info about my PC ---- $ uname -a FreeBSD dell.petio.org 7.0-RELEASE FreeBSD 7.0-RELEASE #2: Tue Dec 23 01:38:59 EST 2008 root at dell.petio.org:/usr/obj/usr/src/sys/DELL i386 $ dmesg | head -n 20 Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-RELEASE #2: Tue Dec 23 01:38:59 EST 2008 root at dell.petio.org:/usr/obj/usr/src/sys/DELL Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 2.66GHz (2657.83-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebfbff Features2=0x4400 real memory = 259473408 (247 MB) avail memory = 244158464 (232 MB) ----Here's the version info for the compilers:---- $ gcc -v Using built-in specs. Target: i386-undermydesk-freebsd Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 4.2.1 20070719 [FreeBSD] $ g++ -v Using built-in specs. Target: i386-undermydesk-freebsd Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 4.2.1 20070719 [FreeBSD] $ clang -v clang version 1.5 (trunk 101372) Target: i386-unknown-freebsd7.0 Thread model: posix $ clang++ -v clang version 1.5 (trunk 101372) Target: i386-unknown-freebsd7.0 Thread model: posix ----Here's the outputs for the builds:---- Debug (build fails) $ env CC=clang CXX=clang++ ./configure --enable-profiling Output: http://petio.org/2010/04/16/clang_debug_configure $ gmake VERBOSE=1 Output: http://petio.org/2010/04/16/clang_debug_make Debug+Profile (build fails) $ env CC=clang CXX=clang++ ./configure --enable-profiling Output: http://petio.org/2010/04/16/clang_debug_profile_configure $ gmake VERBOSE=1 Output: http://petio.org/2010/04/16/clang_debug_profile_make Release (build fails) $ env CC=clang CXX=clang++ ./configure --enable-optimized --enable-profiling Output: http://petio.org/2010/04/16/clang_release_configure $ gmake VERBOSE=1 Output: http://petio.org/2010/04/16/clang_release_make Release+Profile (build fails) $ env CC=clang CXX=clang++ ./configure --enable-optimized --enable-profiling Output: http://petio.org/2010/04/16/clang_release_profile_configure $ gmake VERBOSE=1 Output: http://petio.org/2010/04/16/clang_release_profile_make -- Jay Sullivan From notfed at gmail.com Fri Apr 16 10:41:58 2010 From: notfed at gmail.com (Jay Sullivan) Date: Fri, 16 Apr 2010 11:41:58 -0400 Subject: [cfe-dev] Can't build CLang with CLang on FreeBSD In-Reply-To: References: Message-ID: > ----Here's the outputs for the builds:---- > > Debug (build fails) > ? ?$ env CC=clang CXX=clang++ ./configure --enable-profiling > ? ? ? ?Output: http://petio.org/2010/04/16/clang_debug_configure > ? ?$ gmake VERBOSE=1 > ? ? ? ?Output: http://petio.org/2010/04/16/clang_debug_make > > Debug+Profile (build fails) > ? ?$ env CC=clang CXX=clang++ ./configure --enable-profiling > ? ? ? ?Output: http://petio.org/2010/04/16/clang_debug_profile_configure > ? ?$ gmake VERBOSE=1 > ? ? ? ?Output: http://petio.org/2010/04/16/clang_debug_profile_make > > Release (build fails) > ? ?$ env CC=clang CXX=clang++ ./configure --enable-optimized --enable-profiling > ? ? ? ?Output: http://petio.org/2010/04/16/clang_release_configure > ? ?$ gmake VERBOSE=1 > ? ? ? ?Output: http://petio.org/2010/04/16/clang_release_make > > Release+Profile (build fails) > ? ?$ env CC=clang CXX=clang++ ./configure --enable-optimized --enable-profiling > ? ? ? ?Output: http://petio.org/2010/04/16/clang_release_profile_configure > ? ?$ gmake VERBOSE=1 > ? ? ? ?Output: http://petio.org/2010/04/16/clang_release_profile_make > > -- > Jay Sullivan > Oops, I got the options wrong. I meant to say : Debug (build fails) $ env CC=clang CXX=clang++ ./configure Debug+Profile (build fails) $ env CC=clang CXX=clang++ ./configure --enable-profiling Release (build fails) $ env CC=clang CXX=clang++ ./configure --enable-optimized Release+Profile (build fails) $ env CC=clang CXX=clang++ ./configure --enable-optimized --enable-profiling The output logs are still correct; I just made a typo in the email. -- Jay Sullivan From clattner at apple.com Fri Apr 16 13:40:50 2010 From: clattner at apple.com (Chris Lattner) Date: Fri, 16 Apr 2010 11:40:50 -0700 Subject: [cfe-dev] Diagnostics are unconditionally suppressed after fatal error In-Reply-To: <4BC750FB.4000400@cs.unipr.it> References: <4BC6FEA2.5000102@gmail.com> <95DE930F-E209-4F2F-9410-D427D6E8AAF9@apple.com> <4BC750FB.4000400@cs.unipr.it> Message-ID: On Apr 15, 2010, at 10:46 AM, Enea Zaffanella wrote: > > We thought that it was not possible to map a fatal diagnostic to error. > Actually, we tried and we got the following assertion failure: > > [Thread 1] > /llvm/tools/clang/include/clang/Basic/Diagnostic.h:333: void clang::Diagnostic::setDiagnosticMapping(clang::diag::kind, clang::diag::Mapping): Assertion failed: (isBuiltinWarningOrExtension(Diag) || Map == diag::MAP_FATAL) && "Cannot map errors!" > Aborted > > Are there other ways to map a fatal to error? This was an over-cautious assert, fixed in r101516. Thanks! -Chris From wan at google.com Fri Apr 16 13:48:58 2010 From: wan at google.com (=?UTF-8?B?WmhhbnlvbmcgV2FuICjOu3gueCB4KQ==?=) Date: Fri, 16 Apr 2010 11:48:58 -0700 Subject: [cfe-dev] adding FileSkipped() to PPCallbacks Message-ID: Hi Doug, Per our IRC chat yesterday, I'm extending PPCallbacks with a new method FileSkipped() to notify a listener when a #include is skipped due to header guard optimization. Please see the attached patch and let me know if this is the right direction. (I verified that it works for my use case.) Also, how should I add a test for this? Thanks, -- Zhanyong -------------- next part -------------- A non-text attachment was scrubbed... Name: file_skipped.patch Type: text/x-patch Size: 2362 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100416/64f8e6ed/attachment.bin From dgregor at apple.com Fri Apr 16 14:21:47 2010 From: dgregor at apple.com (Douglas Gregor) Date: Fri, 16 Apr 2010 12:21:47 -0700 Subject: [cfe-dev] adding FileSkipped() to PPCallbacks In-Reply-To: References: Message-ID: <42D536ED-FE89-4371-B869-A7A4E2E6229F@apple.com> On Apr 16, 2010, at 11:48 AM, Zhanyong Wan (?x.x x) wrote: > Per our IRC chat yesterday, I'm extending PPCallbacks with a new > method FileSkipped() to notify a listener when a #include is skipped > due to header guard optimization. Please see the attached patch and > let me know if this is the right direction. (I verified that it works > for my use case.) Also, how should I add a test for this? Looks good. I have no idea how to test this, since we don't have any way for preprocessor callbacks to show up in any of Clang's output. It's okay to commit something this small without a test. - Doug From zaffanella at cs.unipr.it Fri Apr 16 14:27:12 2010 From: zaffanella at cs.unipr.it (Enea Zaffanella) Date: Fri, 16 Apr 2010 21:27:12 +0200 Subject: [cfe-dev] Storage class as written in the source. Message-ID: <4BC8BA10.7080907@cs.unipr.it> Hello. Some time ago, Paolo Bolzoni sent to the mailing list a patch meant to enhance VarDecl and FunctionDecl nodes so that they can record the storage class "as written" in the source code (in contrast with the semantic storage class, which could be inherited). This was the message: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-February/007982.html The patch was not applied and now is out-of-date. I have just refreshed it to be a patch against a recent version (r101446, see attached file). It passes all of the clang tests. It would be nice if someone could have a look on and possibly commit it. Regards, Enea Zaffanella. -------------- next part -------------- A non-text attachment was scrubbed... Name: StorageClassAsWritten.patch Type: text/x-patch Size: 57893 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100416/7def8611/attachment-0001.bin From wan at google.com Fri Apr 16 14:44:29 2010 From: wan at google.com (=?UTF-8?B?WmhhbnlvbmcgV2FuICjOu3gueCB4KQ==?=) Date: Fri, 16 Apr 2010 12:44:29 -0700 Subject: [cfe-dev] adding FileSkipped() to PPCallbacks In-Reply-To: <42D536ED-FE89-4371-B869-A7A4E2E6229F@apple.com> References: <42D536ED-FE89-4371-B869-A7A4E2E6229F@apple.com> Message-ID: On Fri, Apr 16, 2010 at 12:21 PM, Douglas Gregor wrote: > On Apr 16, 2010, at 11:48 AM, Zhanyong Wan (?x.x x) wrote: >> Per our IRC chat yesterday, I'm extending PPCallbacks with a new >> method FileSkipped() to notify a listener when a #include is skipped >> due to header guard optimization. ?Please see the attached patch and >> let me know if this is the right direction. ?(I verified that it works >> for my use case.) ?Also, how should I add a test for this? > > Looks good. I have no idea how to test this, since we don't have any way for preprocessor callbacks to show up in any of Clang's output. It's okay to commit something this small without a test. Thanks, Doug. I don't have the right to commit. Would you commit the patch for me? Thanks, -- Zhanyong From agl at imperialviolet.org Fri Apr 16 15:31:54 2010 From: agl at imperialviolet.org (Adam Langley) Date: Fri, 16 Apr 2010 16:31:54 -0400 Subject: [cfe-dev] clang generating aliases to aliases and breaking llvm-link Message-ID: (LLVM and Clang built from r101478) Background: I want to run ots[1], which parses and sanitises TrueType files, under KLEE. My first step was to build it with clang: $ for x in $(ls *.cc) ; do clang++ -c -g -emit-llvm -I../include $x; done And then try to link it: $ llvm-link -o out *.o llvm-link: LinkModules.cpp:767: bool LinkAlias(llvm::Module*, const llvm::Module*, std::map, std::allocator > >&, std::string*): Assertion `VMI != ValueMap.end() && "Aliasee not linked"' failed. 0 llvm-link 0x000000000054a49f 1 llvm-link 0x000000000054c38a 2 libpthread.so.0 0x000000364b00f0f0 3 libc.so.6 0x000000364a8326d5 gsignal + 53 4 libc.so.6 0x000000364a833eb5 abort + 373 5 libc.so.6 0x000000364a82b7c5 __assert_fail + 245 6 llvm-link 0x000000000044546e 7 llvm-link 0x0000000000446e62 8 llvm-link 0x0000000000405d27 main + 327 9 libc.so.6 0x000000364a81eb1d __libc_start_main + 253 10 llvm-link 0x0000000000405009 Stack dump: 0. Program arguments: llvm-link -o out cff.o cmap.o cvt.o fpgm.o gasp.o glyf.o hdmx.o head.o head-test.o hhea.o hmtx.o kern.o loca.o ltsh.o maxp.o name.o os2.o ots.o post.o prep.o vdmx.o vorg.o Aborted (core dumped) By adding debugging to LinkModules.cpp, we find that the symbol that is causing it to explode is _ZNSt12_Vector_baseIN12_GLOBAL__N_118CMAPSubtableHeaderESaIS1_EE12_Vector_implD1Ev. >From running llvm-nm on some of the .o files, there are a couple of files with symbols that are marked as '?'. It's these symbols which kill llvm-link. Adding more debugging to llvm-nm (see patch below), it turns out that these symbols are aliases to aliases of functions, and aliases to aliases to aliases of functions: T _ZNSt6vectorIN12_GLOBAL__N_118CMAPSubtableHeaderESaIS1_EED1Ev { _ZNSt12_Vector_baseIN12_GLOBAL__N_118CMAPSubtableHeaderESaIS1_EE12_Vector_implD1Ev ( _ZNSt12_Vector_baseIN12_GLOBAL__N_118CMAPSubtableHeaderESaIS1_EE12_Vector_implD2Ev T _ZNSaIN12_GLOBAL__N_118CMAPSubtableHeaderEED2Ev Here my knowledge gives out. I'm not sure if clang is generating bad output, or if llvm-link should be able to handle it. Any ideas? Cheers AGL Index: tools/llvm-nm/llvm-nm.cpp =================================================================== --- tools/llvm-nm/llvm-nm.cpp (revision 101478) +++ tools/llvm-nm/llvm-nm.cpp (working copy) @@ -82,6 +82,16 @@ const GlobalValue *AliasedGV = GA->getAliasedGlobal(); if (isa(AliasedGV)) return 'T'; if (isa(AliasedGV)) return 'D'; + if (const GlobalAlias *GA = dyn_cast(AliasedGV)) { + const GlobalValue *AliasedGV = GA->getAliasedGlobal(); + if (isa(AliasedGV)) return '('; + if (isa(AliasedGV)) return ')'; + if (const GlobalAlias *GA = dyn_cast(AliasedGV)) { + const GlobalValue *AliasedGV = GA->getAliasedGlobal(); + if (isa(AliasedGV)) return '{'; + if (isa(AliasedGV)) return '}'; + } + } } return '?'; } [1] http://code.google.com/p/ots/ -- Adam Langley agl at imperialviolet.org http://www.imperialviolet.org From clattner at apple.com Fri Apr 16 15:34:46 2010 From: clattner at apple.com (Chris Lattner) Date: Fri, 16 Apr 2010 13:34:46 -0700 Subject: [cfe-dev] adding FileSkipped() to PPCallbacks In-Reply-To: References: Message-ID: <15C03547-2968-4A83-9452-AE5DED44F25C@apple.com> On Apr 16, 2010, at 11:48 AM, Zhanyong Wan (?x.x x) wrote: > Hi Doug, > > Per our IRC chat yesterday, I'm extending PPCallbacks with a new > method FileSkipped() to notify a listener when a #include is skipped > due to header guard optimization. Please see the attached patch and > let me know if this is the right direction. (I verified that it works > for my use case.) Also, how should I add a test for this? The .h file change look fine to me, but it isn't good to sink the check below SourceMgr.createFileID. Skipping headers is a fairly hot path, so we don't want it to do additional work when ppcallbacks aren't being used. Please change the callback to take the FileEntry or some other information that doesn't require sinking the check below the potentially expensive work. -Chris From abramo.bagnara at gmail.com Fri Apr 16 15:40:30 2010 From: abramo.bagnara at gmail.com (Abramo Bagnara) Date: Fri, 16 Apr 2010 22:40:30 +0200 Subject: [cfe-dev] adding FileSkipped() to PPCallbacks In-Reply-To: References: Message-ID: <4BC8CB3E.5030803@gmail.com> Il 16/04/2010 20:48, Zhanyong Wan (?x.x x) ha scritto: > Hi Doug, > > Per our IRC chat yesterday, I'm extending PPCallbacks with a new > method FileSkipped() to notify a listener when a #include is skipped > due to header guard optimization. Please see the attached patch and > let me know if this is the right direction. (I verified that it works > for my use case.) Also, how should I add a test for this? We have encountered a similar problem concerning the lack of PPCallbacks for skipped excluded conditional blocks. Do you see some problems in adding such a callback? From clattner at apple.com Fri Apr 16 15:50:07 2010 From: clattner at apple.com (Chris Lattner) Date: Fri, 16 Apr 2010 13:50:07 -0700 Subject: [cfe-dev] adding FileSkipped() to PPCallbacks In-Reply-To: <4BC8CB3E.5030803@gmail.com> References: <4BC8CB3E.5030803@gmail.com> Message-ID: <3185DC4A-5CFB-4F8E-AFAB-C51FE901BC0B@apple.com> On Apr 16, 2010, at 1:40 PM, Abramo Bagnara wrote: > Il 16/04/2010 20:48, Zhanyong Wan (?x.x x) ha scritto: >> Hi Doug, >> >> Per our IRC chat yesterday, I'm extending PPCallbacks with a new >> method FileSkipped() to notify a listener when a #include is skipped >> due to header guard optimization. Please see the attached patch and >> let me know if this is the right direction. (I verified that it works >> for my use case.) Also, how should I add a test for this? > > We have encountered a similar problem concerning the lack of PPCallbacks > for skipped excluded conditional blocks. > > Do you see some problems in adding such a callback? Adding a callback for skipped #if blocks would be fine. From wan at google.com Fri Apr 16 16:09:56 2010 From: wan at google.com (=?UTF-8?B?WmhhbnlvbmcgV2FuICjOu3gueCB4KQ==?=) Date: Fri, 16 Apr 2010 14:09:56 -0700 Subject: [cfe-dev] adding FileSkipped() to PPCallbacks In-Reply-To: <15C03547-2968-4A83-9452-AE5DED44F25C@apple.com> References: <15C03547-2968-4A83-9452-AE5DED44F25C@apple.com> Message-ID: Thanks for the review, Chris. Please see the new patch. I kept the signature of FileSkipped() unchanged to be consistent with FileChanged(). On Fri, Apr 16, 2010 at 1:34 PM, Chris Lattner wrote: > > On Apr 16, 2010, at 11:48 AM, Zhanyong Wan (?x.x x) wrote: > >> Hi Doug, >> >> Per our IRC chat yesterday, I'm extending PPCallbacks with a new >> method FileSkipped() to notify a listener when a #include is skipped >> due to header guard optimization. ?Please see the attached patch and >> let me know if this is the right direction. ?(I verified that it works >> for my use case.) ?Also, how should I add a test for this? > > The .h file change look fine to me, but it isn't good to sink the check below SourceMgr.createFileID. ?Skipping headers is a fairly hot path, so we don't want it to do additional work when ppcallbacks aren't being used. > > Please change the callback to take the FileEntry or some other information that doesn't require sinking the check below the potentially expensive work. > > -Chris -- Zhanyong -------------- next part -------------- A non-text attachment was scrubbed... Name: file_skipped2.patch Type: text/x-patch Size: 2245 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100416/e105f65f/attachment.bin From clattner at apple.com Fri Apr 16 16:14:05 2010 From: clattner at apple.com (Chris Lattner) Date: Fri, 16 Apr 2010 14:14:05 -0700 Subject: [cfe-dev] adding FileSkipped() to PPCallbacks In-Reply-To: References: <15C03547-2968-4A83-9452-AE5DED44F25C@apple.com> Message-ID: <9AE21B23-06E4-48B2-B4D0-DFB5D76908C7@apple.com> On Apr 16, 2010, at 2:09 PM, Zhanyong Wan (?x.x x) wrote: > Thanks for the review, Chris. Please see the new patch. I kept the > signature of FileSkipped() unchanged to be consistent with > FileChanged(). Keeping the interfaces consistent is nice, but is it really worth it? This will punish other PPCallbacks that don't care about this, like -MM mode and friends. SourceMgr.createFileID isn't hyper-expensive, but it is good to avoid work that no other client at all needs. Sinking this work into the implementation that cares makes sense to me. -Chris > > On Fri, Apr 16, 2010 at 1:34 PM, Chris Lattner wrote: >> >> On Apr 16, 2010, at 11:48 AM, Zhanyong Wan (?x.x x) wrote: >> >>> Hi Doug, >>> >>> Per our IRC chat yesterday, I'm extending PPCallbacks with a new >>> method FileSkipped() to notify a listener when a #include is skipped >>> due to header guard optimization. Please see the attached patch and >>> let me know if this is the right direction. (I verified that it works >>> for my use case.) Also, how should I add a test for this? >> >> The .h file change look fine to me, but it isn't good to sink the check below SourceMgr.createFileID. Skipping headers is a fairly hot path, so we don't want it to do additional work when ppcallbacks aren't being used. >> >> Please change the callback to take the FileEntry or some other information that doesn't require sinking the check below the potentially expensive work. >> >> -Chris > > > > -- > Zhanyong > From wan at google.com Fri Apr 16 16:38:08 2010 From: wan at google.com (=?UTF-8?B?WmhhbnlvbmcgV2FuICjOu3gueCB4KQ==?=) Date: Fri, 16 Apr 2010 14:38:08 -0700 Subject: [cfe-dev] adding FileSkipped() to PPCallbacks In-Reply-To: <9AE21B23-06E4-48B2-B4D0-DFB5D76908C7@apple.com> References: <15C03547-2968-4A83-9452-AE5DED44F25C@apple.com> <9AE21B23-06E4-48B2-B4D0-DFB5D76908C7@apple.com> Message-ID: On Fri, Apr 16, 2010 at 2:14 PM, Chris Lattner wrote: > > On Apr 16, 2010, at 2:09 PM, Zhanyong Wan (?x.x x) wrote: > >> Thanks for the review, Chris. ?Please see the new patch. ?I kept the >> signature of FileSkipped() unchanged to be consistent with >> FileChanged(). > > Keeping the interfaces consistent is nice, but is it really worth it? ?This will punish other PPCallbacks that don't care about this, like -MM mode and friends. ?SourceMgr.createFileID isn't hyper-expensive, but it is good to avoid work that no other client at all needs. ?Sinking this work into the implementation that cares makes sense to me. If createFileID() is called here, the file being skipped has already been processed earlier, which is a much more expensive operation. So do we really want to sacrifice the cleanness of the API for it? Thanks, > -Chris > >> >> On Fri, Apr 16, 2010 at 1:34 PM, Chris Lattner wrote: >>> >>> On Apr 16, 2010, at 11:48 AM, Zhanyong Wan (?x.x x) wrote: >>> >>>> Hi Doug, >>>> >>>> Per our IRC chat yesterday, I'm extending PPCallbacks with a new >>>> method FileSkipped() to notify a listener when a #include is skipped >>>> due to header guard optimization. ?Please see the attached patch and >>>> let me know if this is the right direction. ?(I verified that it works >>>> for my use case.) ?Also, how should I add a test for this? >>> >>> The .h file change look fine to me, but it isn't good to sink the check below SourceMgr.createFileID. ?Skipping headers is a fairly hot path, so we don't want it to do additional work when ppcallbacks aren't being used. >>> >>> Please change the callback to take the FileEntry or some other information that doesn't require sinking the check below the potentially expensive work. >>> >>> -Chris >> >> >> >> -- >> Zhanyong >> > > -- Zhanyong From john.thompson.jtsoftware at gmail.com Fri Apr 16 17:53:03 2010 From: john.thompson.jtsoftware at gmail.com (John Thompson) Date: Fri, 16 Apr 2010 15:53:03 -0700 Subject: [cfe-dev] Inline assembly Z constraint and more Message-ID: Using Clang to compile some PS3 headers, I ran into a problem with some inline assembly for some instrinsics macros with an unrecognized "Z" constraint. Looking at the gcc sources, I see there are several other constraints not currently supported. The enclosed macro lets them get through the parser, but at present I have no idea how to actually implement them, so before I look into it more, I thought I'd ask. Can someone help me out? This from the gcc sources: (define_memory_constraint "Z" "Memory operand that is an indexed or indirect from a register (it is usually better to use @samp{m} or @samp{es} in @code{asm} statements)" (match_operand 0 "indexed_or_indirect_operand")) Is it okay to check in the patch as an intermediate step? -John -- John Thompson John.Thompson.JTSoftware at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100416/515928dc/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: Z_constraint.patch Type: application/octet-stream Size: 1860 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100416/515928dc/attachment.obj From clattner at apple.com Fri Apr 16 18:38:46 2010 From: clattner at apple.com (Chris Lattner) Date: Fri, 16 Apr 2010 16:38:46 -0700 Subject: [cfe-dev] Inline assembly Z constraint and more In-Reply-To: References: Message-ID: <78ECA01C-708A-4B20-B76A-8699561F9F7F@apple.com> On Apr 16, 2010, at 3:53 PM, John Thompson wrote: > Using Clang to compile some PS3 headers, I ran into a problem with some inline assembly for some instrinsics macros with an unrecognized "Z" constraint. Looking at the gcc sources, I see there are several other constraints not currently supported. The enclosed macro lets them get through the parser, but at present I have no idea how to actually implement them, so before I look into it more, I thought I'd ask. Can someone help me out? > > This from the gcc sources: > > (define_memory_constraint "Z" > "Memory operand that is an indexed or indirect from a register (it is > usually better to use @samp{m} or @samp{es} in @code{asm} statements)" > (match_operand 0 "indexed_or_indirect_operand")) > Is it okay to check in the patch as an intermediate step? > it Z a target independent or target-specific constraint? You have some unrelated changes in your diff. -Chris From clattner at apple.com Fri Apr 16 18:41:20 2010 From: clattner at apple.com (Chris Lattner) Date: Fri, 16 Apr 2010 16:41:20 -0700 Subject: [cfe-dev] adding FileSkipped() to PPCallbacks In-Reply-To: References: <15C03547-2968-4A83-9452-AE5DED44F25C@apple.com> <9AE21B23-06E4-48B2-B4D0-DFB5D76908C7@apple.com> Message-ID: <237198E3-89C6-458D-B4B6-A7F0C6EB7A4C@apple.com> On Apr 16, 2010, at 2:38 PM, Zhanyong Wan (?x.x x) wrote: > On Fri, Apr 16, 2010 at 2:14 PM, Chris Lattner wrote: >> >> On Apr 16, 2010, at 2:09 PM, Zhanyong Wan (?x.x x) wrote: >> >>> Thanks for the review, Chris. Please see the new patch. I kept the >>> signature of FileSkipped() unchanged to be consistent with >>> FileChanged(). >> >> Keeping the interfaces consistent is nice, but is it really worth it? This will punish other PPCallbacks that don't care about this, like -MM mode and friends. SourceMgr.createFileID isn't hyper-expensive, but it is good to avoid work that no other client at all needs. Sinking this work into the implementation that cares makes sense to me. > > If createFileID() is called here, the file being skipped has already > been processed earlier, which is a much more expensive operation. So > do we really want to sacrifice the cleanness of the API for it? I'm pushing back because the preprocessor is a particularly performance sensitive part of the compiler, and this adds no value for any current clients. I think the cost should be sunk into your client, even if it makes its implementation a little less elegant. -Chris From dgregor at apple.com Fri Apr 16 18:49:28 2010 From: dgregor at apple.com (Douglas Gregor) Date: Fri, 16 Apr 2010 16:49:28 -0700 Subject: [cfe-dev] Storage class as written in the source. In-Reply-To: <4BC8BA10.7080907@cs.unipr.it> References: <4BC8BA10.7080907@cs.unipr.it> Message-ID: Hi Enea, On Apr 16, 2010, at 12:27 PM, Enea Zaffanella wrote: > Some time ago, Paolo Bolzoni sent to the mailing list a patch meant to enhance VarDecl and FunctionDecl nodes so that they can record the storage class "as written" in the source code (in contrast with the semantic storage class, which could be inherited). > > This was the message: > http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-February/007982.html > > The patch was not applied and now is out-of-date. > > I have just refreshed it to be a patch against a recent version (r101446, see attached file). It passes all of the clang tests. > > It would be nice if someone could have a look on and possibly commit it. Looks very good. I have a few comments that I'd like to see addressed before I commit. Index: include/clang/AST/DeclCXX.h =================================================================== --- include/clang/AST/DeclCXX.h (revision 101446) +++ include/clang/AST/DeclCXX.h (working copy) @@ -1186,8 +1187,9 @@ CXXConstructorDecl(CXXRecordDecl *RD, SourceLocation L, DeclarationName N, QualType T, TypeSourceInfo *TInfo, bool isExplicitSpecified, bool isInline, - bool isImplicitlyDeclared) - : CXXMethodDecl(CXXConstructor, RD, L, N, T, TInfo, false, isInline), + bool isImplicitlyDeclared, StorageClass SCAsWritten) + : CXXMethodDecl(CXXConstructor, RD, L, N, T, TInfo, false, SCAsWritten, + isInline), IsExplicitSpecified(isExplicitSpecified), ImplicitlyDefined(false), BaseOrMemberInitializers(0), NumBaseOrMemberInitializers(0) { setImplicit(isImplicitlyDeclared); @@ -1199,7 +1201,8 @@ SourceLocation L, DeclarationName N, QualType T, TypeSourceInfo *TInfo, bool isExplicit, - bool isInline, bool isImplicitlyDeclared); + bool isInline, bool isImplicitlyDeclared, + StorageClass SCAsWritten); /// isExplicitSpecified - Whether this constructor declaration has the /// 'explicit' keyword specified. @@ -1329,8 +1332,10 @@ CXXDestructorDecl(CXXRecordDecl *RD, SourceLocation L, DeclarationName N, QualType T, - bool isInline, bool isImplicitlyDeclared) - : CXXMethodDecl(CXXDestructor, RD, L, N, T, /*TInfo=*/0, false, isInline), + bool isInline, bool isImplicitlyDeclared, + StorageClass SCAsWritten) + : CXXMethodDecl(CXXDestructor, RD, L, N, T, /*TInfo=*/0, false, + SCAsWritten, isInline), ImplicitlyDefined(false), OperatorDelete(0) { setImplicit(isImplicitlyDeclared); } @@ -1339,7 +1344,8 @@ static CXXDestructorDecl *Create(ASTContext &C, CXXRecordDecl *RD, SourceLocation L, DeclarationName N, QualType T, bool isInline, - bool isImplicitlyDeclared); + bool isImplicitlyDeclared, + StorageClass SCAsWritten); /// isImplicitlyDefined - Whether this destructor was implicitly /// defined. If false, then this destructor was defined by the @@ -1385,15 +1391,18 @@ CXXConversionDecl(CXXRecordDecl *RD, SourceLocation L, DeclarationName N, QualType T, TypeSourceInfo *TInfo, - bool isInline, bool isExplicitSpecified) - : CXXMethodDecl(CXXConversion, RD, L, N, T, TInfo, false, isInline), + bool isInline, bool isExplicitSpecified, + StorageClass SCAsWritten) + : CXXMethodDecl(CXXConversion, RD, L, N, T, TInfo, false, SCAsWritten, + isInline), IsExplicitSpecified(isExplicitSpecified) { } public: static CXXConversionDecl *Create(ASTContext &C, CXXRecordDecl *RD, SourceLocation L, DeclarationName N, QualType T, TypeSourceInfo *TInfo, - bool isInline, bool isExplicit); + bool isInline, bool isExplicit, + StorageClass SCAsWritten); /// IsExplicitSpecified - Whether this conversion function declaration is /// marked "explicit", meaning that it can only be applied when the user Constructors, destructors, and conversions don't have storage classes in well-formed code, so we shouldn't make the storage-class specifier part of the constructors for the corresponding AST nodes. Just pass FunctionDecl::None down to the CXXMethodDecl constructor in the appropriate place. Index: lib/Sema/SemaDecl.cpp =================================================================== --- lib/Sema/SemaDecl.cpp (revision 101446) +++ lib/Sema/SemaDecl.cpp (working copy) @@ -1729,12 +1732,29 @@ SC = VarDecl::None; break; } + VarDecl::StorageClass SCAsWritten; + switch (DS.getStorageClassSpecAsWritten()) { + default: /* Uncorrect program: we mark the sintatic + storage class as none. */ + case DeclSpec::SCS_unspecified: + SCAsWritten = VarDecl::None; break; + case DeclSpec::SCS_extern: + SCAsWritten = VarDecl::Extern; break; + case DeclSpec::SCS_static: + SCAsWritten = VarDecl::Static; break; + case DeclSpec::SCS_auto: + SCAsWritten = VarDecl::Auto; break; + case DeclSpec::SCS_register: + SCAsWritten = VarDecl::Register; break; + case DeclSpec::SCS_private_extern: + SCAsWritten = VarDecl::PrivateExtern; break; + } We don't need the default case here. It's better to write out all of the cases. @@ -2350,6 +2370,23 @@ SC = VarDecl::None; break; } + VarDecl::StorageClass SCAsWritten; + switch (D.getDeclSpec().getStorageClassSpecAsWritten()) { + default: /* Uncorrect program: we mark the sintatic + storage class as none. */ + case DeclSpec::SCS_unspecified: + SCAsWritten = VarDecl::None; break; + case DeclSpec::SCS_extern: + SCAsWritten = VarDecl::Extern; break; + case DeclSpec::SCS_static: + SCAsWritten = VarDecl::Static; break; + case DeclSpec::SCS_auto: + SCAsWritten = VarDecl::Auto; break; + case DeclSpec::SCS_register: + SCAsWritten = VarDecl::Register; break; + case DeclSpec::SCS_private_extern: + SCAsWritten = VarDecl::PrivateExtern; break; + } Copy-paste from above? Please factor this into its own utility routine. @@ -2801,7 +2838,21 @@ bool isInline = D.getDeclSpec().isInlineSpecified(); bool isVirtual = D.getDeclSpec().isVirtualSpecified(); bool isExplicit = D.getDeclSpec().isExplicitSpecified(); + FunctionDecl::StorageClass SCAsWritten; + switch (D.getDeclSpec().getStorageClassSpecAsWritten()) { + default: /* Uncorrect program: we mark the sintatic + storage class as none. */ + case DeclSpec::SCS_unspecified: + SCAsWritten = FunctionDecl::None; break; + case DeclSpec::SCS_extern: + SCAsWritten = FunctionDecl::Extern; break; + case DeclSpec::SCS_static: + SCAsWritten = FunctionDecl::Static; break; + case DeclSpec::SCS_private_extern: + SCAsWritten = FunctionDecl::PrivateExtern; break; + } We don't want the default case here, either. - Doug From john.thompson.jtsoftware at gmail.com Fri Apr 16 21:20:38 2010 From: john.thompson.jtsoftware at gmail.com (John Thompson) Date: Fri, 16 Apr 2010 19:20:38 -0700 Subject: [cfe-dev] Inline assembly Z constraint and more In-Reply-To: <78ECA01C-708A-4B20-B76A-8699561F9F7F@apple.com> References: <78ECA01C-708A-4B20-B76A-8699561F9F7F@apple.com> Message-ID: Oh, sorry, I forgot to hit the save button in the editor. It's just one file: Index: lib/Basic/TargetInfo.cpp =================================================================== --- lib/Basic/TargetInfo.cpp (revision 101528) +++ lib/Basic/TargetInfo.cpp (working copy) @@ -280,6 +280,8 @@ Info.setAllowsRegister(); Info.setAllowsMemory(); break; + case 'Z': // wish I knew what Z was for... + break; } Name++; @@ -359,6 +361,14 @@ case 'N': case 'O': case 'P': + case 'Q': + case 'R': + case 'S': + case 'T': + case 'U': + case 'W': + case 'Y': + case 'Z': break; case 'r': // general register. Info.setAllowsRegister(); I don't know if it's target-specific or not. The gcc comment makes it seem generic (register indexed memory), but I couldn't find any docs that mentioned it. -John On Fri, Apr 16, 2010 at 4:38 PM, Chris Lattner wrote: > > On Apr 16, 2010, at 3:53 PM, John Thompson wrote: > > > Using Clang to compile some PS3 headers, I ran into a problem with some > inline assembly for some instrinsics macros with an unrecognized "Z" > constraint. Looking at the gcc sources, I see there are several other > constraints not currently supported. The enclosed macro lets them get > through the parser, but at present I have no idea how to actually implement > them, so before I look into it more, I thought I'd ask. Can someone help me > out? > > > > This from the gcc sources: > > > > (define_memory_constraint "Z" > > "Memory operand that is an indexed or indirect from a register (it is > > usually better to use @samp{m} or @samp{es} in @code{asm} statements)" > > (match_operand 0 "indexed_or_indirect_operand")) > > Is it okay to check in the patch as an intermediate step? > > > > it Z a target independent or target-specific constraint? You have some > unrelated changes in your diff. > > -Chris > > -- John Thompson John.Thompson.JTSoftware at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100416/e7f499ce/attachment-0001.html From zaffanella at cs.unipr.it Sat Apr 17 01:48:19 2010 From: zaffanella at cs.unipr.it (Enea Zaffanella) Date: Sat, 17 Apr 2010 08:48:19 +0200 Subject: [cfe-dev] Storage class as written in the source. In-Reply-To: References: <4BC8BA10.7080907@cs.unipr.it> Message-ID: <4BC959B3.80208@cs.unipr.it> Douglas Gregor wrote: > Hi Enea, > > On Apr 16, 2010, at 12:27 PM, Enea Zaffanella wrote: >> Some time ago, Paolo Bolzoni sent to the mailing list a patch meant to enhance VarDecl and FunctionDecl nodes so that they can record the storage class "as written" in the source code (in contrast with the semantic storage class, which could be inherited). >> >> This was the message: >> http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-February/007982.html >> >> The patch was not applied and now is out-of-date. >> >> I have just refreshed it to be a patch against a recent version (r101446, see attached file). It passes all of the clang tests. >> >> It would be nice if someone could have a look on and possibly commit it. > > Looks very good. I have a few comments that I'd like to see addressed before I commit. Thank you for the very quick reply. [...] > Constructors, destructors, and conversions don't have storage classes in well-formed code, so we shouldn't make the storage-class specifier part of the constructors for the corresponding AST nodes. Just pass FunctionDecl::None down to the CXXMethodDecl constructor in the appropriate place. Paolo in his message observed that out-of-line definitions of constructors, destructors and conversions can have "extern" as a storage class. The following compiles cleanly on g++: struct S { S(); ~S(); operator bool(); }; extern S::S() {} extern S::~S() {} extern S::operator bool() { return true; } Hence, will it be OK if we leave the extra argument in the constructors of the AST nodes above? (The other comments are finding their way in the revised patch.) Cheers, Enea. From zaffanella at cs.unipr.it Sat Apr 17 05:14:22 2010 From: zaffanella at cs.unipr.it (Enea Zaffanella) Date: Sat, 17 Apr 2010 12:14:22 +0200 Subject: [cfe-dev] Storage class as written in the source. In-Reply-To: <4BC959B3.80208@cs.unipr.it> References: <4BC8BA10.7080907@cs.unipr.it> <4BC959B3.80208@cs.unipr.it> Message-ID: <4BC989FE.9090005@cs.unipr.it> Enea Zaffanella wrote: [...] > Hence, will it be OK if we leave the extra argument in the constructors > of the AST nodes above? If the answer to the above question is positive, then here is revised patch. Cheers, Enea Zaffanella. -------------- next part -------------- A non-text attachment was scrubbed... Name: StorageClassAsWritten-2.patch Type: text/x-patch Size: 60602 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100417/ad8aa065/attachment-0001.bin From devlists at shadowlab.org Sat Apr 17 07:18:50 2010 From: devlists at shadowlab.org (Jean-Daniel Dupas) Date: Sat, 17 Apr 2010 14:18:50 +0200 Subject: [cfe-dev] clang and -integrated-as Message-ID: Hello, After the post about LLVM-MC, I tried to play with the "-integrated-as" flag. Unfortunately, it does not works for a simple case which is an obj-c file with a class and a category to extend this class (on i386). @interface Foo { void *isa; } @end @implementation Foo @end @implementation Foo (Bar) @end clang -arch i386 -integrated-as -c test.m :2:23: error: invalid assignment to '.objc_class_name_Foo' .objc_class_name_Foo=0 To be exact, it stopped on these lines: .lazy_reference .objc_class_name_Foo .objc_class_name_Foo=0 .globl .objc_class_name_Foo If the file does not contains a category, the .lazy_reference is not generated, and the code compile fine. As LLVM-MV is fairly young, this is maybe a know issue, else should I fill a bug report ? Thanks -- Jean-Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100417/60f6f08c/attachment.html From dgregor at apple.com Sat Apr 17 09:55:14 2010 From: dgregor at apple.com (Douglas Gregor) Date: Sat, 17 Apr 2010 07:55:14 -0700 Subject: [cfe-dev] Storage class as written in the source. In-Reply-To: <4BC959B3.80208@cs.unipr.it> References: <4BC8BA10.7080907@cs.unipr.it> <4BC959B3.80208@cs.unipr.it> Message-ID: <78717169-BBE7-4830-A82F-99906A0F843A@apple.com> On Apr 16, 2010, at 11:48 PM, Enea Zaffanella wrote: > Douglas Gregor wrote: >> Hi Enea, >> >> On Apr 16, 2010, at 12:27 PM, Enea Zaffanella wrote: >>> Some time ago, Paolo Bolzoni sent to the mailing list a patch meant to enhance VarDecl and FunctionDecl nodes so that they can record the storage class "as written" in the source code (in contrast with the semantic storage class, which could be inherited). >>> >>> This was the message: >>> http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-February/007982.html >>> >>> The patch was not applied and now is out-of-date. >>> >>> I have just refreshed it to be a patch against a recent version (r101446, see attached file). It passes all of the clang tests. >>> >>> It would be nice if someone could have a look on and possibly commit it. >> Looks very good. I have a few comments that I'd like to see addressed before I commit. > > Thank you for the very quick reply. > > [...] > >> Constructors, destructors, and conversions don't have storage classes in well-formed code, so we shouldn't make the storage-class specifier part of the constructors for the corresponding AST nodes. Just pass FunctionDecl::None down to the CXXMethodDecl constructor in the appropriate place. > > Paolo in his message observed that out-of-line definitions of constructors, destructors and conversions can have "extern" as a storage class. The following compiles cleanly on g++: > > struct S { > S(); > ~S(); > operator bool(); > }; > > extern S::S() {} > extern S::~S() {} > extern S::operator bool() { return true; } GCC allows it (but it doesn't have any effect on translation), while EDG rejects it. C++ [class.mem]p5 explicitly calls this ill-formed: A member shall not be declared with the extern or register storage-class-specifier. We should have an Extension/ExtWarn diagnostic about the storage-class-specifier being redundant and then just drop the storage-class-specifier. > Hence, will it be OK if we leave the extra argument in the constructors of the AST nodes above? I don't think we should model it in the AST because (1) it's not in the language and (2) it has no effect in GCC. Do you disagree? - Doug From zaffanella at cs.unipr.it Sat Apr 17 12:02:36 2010 From: zaffanella at cs.unipr.it (Enea Zaffanella) Date: Sat, 17 Apr 2010 19:02:36 +0200 Subject: [cfe-dev] Storage class as written in the source. In-Reply-To: <78717169-BBE7-4830-A82F-99906A0F843A@apple.com> References: <4BC8BA10.7080907@cs.unipr.it> <4BC959B3.80208@cs.unipr.it> <78717169-BBE7-4830-A82F-99906A0F843A@apple.com> Message-ID: <4BC9E9AC.7020604@cs.unipr.it> Douglas Gregor wrote: > On Apr 16, 2010, at 11:48 PM, Enea Zaffanella wrote: [...] >> struct S { >> S(); >> ~S(); >> operator bool(); >> }; >> >> extern S::S() {} >> extern S::~S() {} >> extern S::operator bool() { return true; } > > GCC allows it (but it doesn't have any effect on translation), while EDG rejects it. C++ [class.mem]p5 explicitly calls this ill-formed: > > A member shall not be declared with the extern or register storage-class-specifier. > > We should have an Extension/ExtWarn diagnostic about the storage-class-specifier being redundant and then just drop the storage-class-specifier. > >> Hence, will it be OK if we leave the extra argument in the constructors of the AST nodes above? > > I don't think we should model it in the AST because (1) it's not in the language and (2) it has no effect in GCC. Do you disagree? > > - Doug > Let me try and summarize the state of things, so that you can point out any flaw in my reasoning: a) any FunctionDecl node should provide the "storage class as written" info for the purposes of source-based applications such as pretty printers, code style checkers and so on; b) the clang AST hierarchy implies that all nodes encoding C++ methods are FunctionDecl nodes, so that they incur no additional memory cost; c) since GCC accepts the construct, you (wisely) suggest that clang should allow for the same extension and maybe issue corresponding diagnostic. The combination of a), b) means that the AST is already able to model this info, whereas c) means that you are willing to add the corresponding logic ... so I cannot see where is the problem. If the problem is that you do NOT like having an additional argument in the C++ constructor for classes derived from CXXMethodDecl, then we can workaround this while still having this info in the AST. For instance, we can: A) let this argument have default value FunctionDecl::None; or B) completely remove the argument from the CXXConstructorDecl, CXXDestructorDecl and CXXConversionDecl constructors and instead call method FunctionDecl::setStorageClassAsWritten if and when needed. As for my personal taste, I would go for option A. Are there other issues we are still missing? Regards, Enea. From dgregor at apple.com Sat Apr 17 12:16:49 2010 From: dgregor at apple.com (Douglas Gregor) Date: Sat, 17 Apr 2010 10:16:49 -0700 Subject: [cfe-dev] Storage class as written in the source. In-Reply-To: <4BC9E9AC.7020604@cs.unipr.it> References: <4BC8BA10.7080907@cs.unipr.it> <4BC959B3.80208@cs.unipr.it> <78717169-BBE7-4830-A82F-99906A0F843A@apple.com> <4BC9E9AC.7020604@cs.unipr.it> Message-ID: On Apr 17, 2010, at 10:02 AM, Enea Zaffanella wrote: > Douglas Gregor wrote: >> On Apr 16, 2010, at 11:48 PM, Enea Zaffanella wrote: > > [...] > >>> struct S { >>> S(); >>> ~S(); >>> operator bool(); >>> }; >>> >>> extern S::S() {} >>> extern S::~S() {} >>> extern S::operator bool() { return true; } >> GCC allows it (but it doesn't have any effect on translation), while EDG rejects it. C++ [class.mem]p5 explicitly calls this ill-formed: >> A member shall not be declared with the extern or register storage-class-specifier. >> We should have an Extension/ExtWarn diagnostic about the storage-class-specifier being redundant and then just drop the storage-class-specifier. >>> Hence, will it be OK if we leave the extra argument in the constructors of the AST nodes above? >> I don't think we should model it in the AST because (1) it's not in the language and (2) it has no effect in GCC. Do you disagree? >> - Doug > > Let me try and summarize the state of things, so that you can point out any flaw in my reasoning: > > a) any FunctionDecl node should provide the "storage class as written" info for the purposes of source-based applications such as pretty printers, code style checkers and so on; > > b) the clang AST hierarchy implies that all nodes encoding C++ methods are FunctionDecl nodes, so that they incur no additional memory cost; Well, it prevents us from re-using those bits for something else, now or in the future. > c) since GCC accepts the construct, you (wisely) suggest that clang should allow for the same extension and maybe issue corresponding diagnostic. I'm saying that we should diagnose this violation of the standard and we shouldn't model such ill-formed code in our AST. However, since it's a relatively benign problem (i.e., the presence of such an error would not compromise our AST), I'm okay if the diagnostic is given the ExtWarn/Extension class. Note that EDG treats this is a hard error, so code that is relying on this extension in GCC is not portable. > The combination of a), b) means that the AST is already able to model this info, whereas c) means that you are willing to add the corresponding logic ... so I cannot see where is the problem. > > If the problem is that you do NOT like having an additional argument in the C++ constructor for classes derived from CXXMethodDecl, then we can workaround this while still having this info in the AST. No, that's not the problem I have. The problem I have is that this appears to be a GCC extension by accident, since it is not documented and has no effect on the translation of the program. The GCC authors probably just forgot to check that part of the standard, like we did. What is the benefit of modeling a GCC accident that is rejected outright by other C++ compilers? Now, if this extension was *not* an accident and does have some effect on translation, then by all means we should support it and model it in the AST. I haven't seen any evidence that this extension was intentional or has any use. - Doug From clattner at apple.com Sat Apr 17 13:29:11 2010 From: clattner at apple.com (Chris Lattner) Date: Sat, 17 Apr 2010 11:29:11 -0700 Subject: [cfe-dev] clang and -integrated-as In-Reply-To: References: Message-ID: <4266BF60-378F-4732-A327-BCB7635A201F@apple.com> On Apr 17, 2010, at 5:18 AM, Jean-Daniel Dupas wrote: > Hello, > > After the post about LLVM-MC, I tried to play with the "-integrated-as" flag. > Unfortunately, it does not works for a simple case which is an obj-c file with a class and a category to extend this class (on i386). It was a known issue, we just didn't get around to addressing it. Fixed in r101660, thanks for nudging us! -Chris > > @interface Foo { void *isa; } @end > @implementation Foo > @end > @implementation Foo (Bar) > @end > > clang -arch i386 -integrated-as -c test.m > :2:23: error: invalid assignment to '.objc_class_name_Foo' > .objc_class_name_Foo=0 > > To be exact, it stopped on these lines: > > .lazy_reference .objc_class_name_Foo > .objc_class_name_Foo=0 > .globl .objc_class_name_Foo > > If the file does not contains a category, the .lazy_reference is not generated, and the code compile fine. > > As LLVM-MV is fairly young, this is maybe a know issue, else should I fill a bug report ? > > Thanks > > -- Jean-Daniel > > > > > _______________________________________________ > 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/20100417/9b5907d4/attachment.html From devlists at shadowlab.org Sat Apr 17 14:08:09 2010 From: devlists at shadowlab.org (Jean-Daniel Dupas) Date: Sat, 17 Apr 2010 21:08:09 +0200 Subject: [cfe-dev] clang and -integrated-as In-Reply-To: <4266BF60-378F-4732-A327-BCB7635A201F@apple.com> References: <4266BF60-378F-4732-A327-BCB7635A201F@apple.com> Message-ID: <4571CDCD-D091-4C4F-BE74-89D3344DBE09@shadowlab.org> Le 17 avr. 2010 ? 20:29, Chris Lattner a ?crit : > > On Apr 17, 2010, at 5:18 AM, Jean-Daniel Dupas wrote: > >> Hello, >> >> After the post about LLVM-MC, I tried to play with the "-integrated-as" flag. >> Unfortunately, it does not works for a simple case which is an obj-c file with a class and a category to extend this class (on i386). > > It was a known issue, we just didn't get around to addressing it. Fixed in r101660, thanks for nudging us! Thanks for the quick fix :-) -- Jean-Daniel From devlists at shadowlab.org Sat Apr 17 14:49:52 2010 From: devlists at shadowlab.org (Jean-Daniel Dupas) Date: Sat, 17 Apr 2010 21:49:52 +0200 Subject: [cfe-dev] clang and -integrated-as In-Reply-To: <4571CDCD-D091-4C4F-BE74-89D3344DBE09@shadowlab.org> References: <4266BF60-378F-4732-A327-BCB7635A201F@apple.com> <4571CDCD-D091-4C4F-BE74-89D3344DBE09@shadowlab.org> Message-ID: Le 17 avr. 2010 ? 21:08, Jean-Daniel Dupas a ?crit : > > Le 17 avr. 2010 ? 20:29, Chris Lattner a ?crit : > >> >> On Apr 17, 2010, at 5:18 AM, Jean-Daniel Dupas wrote: >> >>> Hello, >>> >>> After the post about LLVM-MC, I tried to play with the "-integrated-as" flag. >>> Unfortunately, it does not works for a simple case which is an obj-c file with a class and a category to extend this class (on i386). >> >> It was a known issue, we just didn't get around to addressing it. Fixed in r101660, thanks for nudging us! > > Thanks for the quick fix :-) Unfortunately, it does not works as expected. It uncovers an other blocking bug :-( The assembler generates an undefined symbol instead of generating an absolute symbol for classes, and so, in my test project, it now fails at linking time. ================= @interface Foo { void *isa; } @end @implementation Foo @end ================= % clang -arch i386 -c test.m % nm -m test.o 00000000 (absolute) external .objc_class_name_Foo % clang -arch i386 -c test.m -integrated-as % nm -m test.o (undefined) external .objc_class_name_Foo -- Jean-Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100417/dd6b37fc/attachment.html From devlists at shadowlab.org Sat Apr 17 18:08:14 2010 From: devlists at shadowlab.org (Jean-Daniel Dupas) Date: Sun, 18 Apr 2010 01:08:14 +0200 Subject: [cfe-dev] clang and -integrated-as In-Reply-To: References: <4266BF60-378F-4732-A327-BCB7635A201F@apple.com> <4571CDCD-D091-4C4F-BE74-89D3344DBE09@shadowlab.org> Message-ID: <5E7CD457-712D-4775-92C4-691522A7E3CB@shadowlab.org> Le 17 avr. 2010 ? 21:49, Jean-Daniel Dupas a ?crit : > > Le 17 avr. 2010 ? 21:08, Jean-Daniel Dupas a ?crit : > >> >> Le 17 avr. 2010 ? 20:29, Chris Lattner a ?crit : >> >>> >>> On Apr 17, 2010, at 5:18 AM, Jean-Daniel Dupas wrote: >>> >>>> Hello, >>>> >>>> After the post about LLVM-MC, I tried to play with the "-integrated-as" flag. >>>> Unfortunately, it does not works for a simple case which is an obj-c file with a class and a category to extend this class (on i386). >>> >>> It was a known issue, we just didn't get around to addressing it. Fixed in r101660, thanks for nudging us! >> >> Thanks for the quick fix :-) > > Unfortunately, it does not works as expected. It uncovers an other blocking bug :-( > The assembler generates an undefined symbol instead of generating an absolute symbol for classes, and so, in my test project, it now fails at linking time. > > ================= > @interface Foo { void *isa; } > @end > @implementation Foo > @end > ================= > > % clang -arch i386 -c test.m > % nm -m test.o > 00000000 (absolute) external .objc_class_name_Foo > > % clang -arch i386 -c test.m -integrated-as > % nm -m test.o > (undefined) external .objc_class_name_Foo Look like this is due to the FIXME at line 198 in MCMachOSteamer.cpp ( FIXME: Set associated section. ). This functions does not mark the symbol as absolute (by setting its section to absolute pseudo section), and so it is interpreted as undefined symbol by the MachOWriter. Unfortunately, I don't known assembly and object generation enough to fix this. -- Jean-Daniel From daniel at zuster.org Sun Apr 18 10:35:27 2010 From: daniel at zuster.org (Daniel Dunbar) Date: Sun, 18 Apr 2010 08:35:27 -0700 Subject: [cfe-dev] clang generating aliases to aliases and breaking llvm-link In-Reply-To: References: Message-ID: My opinion is that this is an llvm linker bug. Can you file a bugzilla for it with a test case (ideally, a small set of .bc files that cause it to fail)? On Fri, Apr 16, 2010 at 1:31 PM, Adam Langley wrote: > (LLVM and Clang built from r101478) > > Background: I want to run ots[1], which parses and sanitises TrueType > files, under KLEE. Cool, I'd love to hear if this works, eventually. - Daniel > My first step was to build it with clang: > > $ for x in $(ls *.cc) ; do clang++ -c -g -emit-llvm -I../include ?$x; done > > And then try to link it: > > $ llvm-link -o out *.o > llvm-link: LinkModules.cpp:767: bool LinkAlias(llvm::Module*, const > llvm::Module*, std::map std::less, std::allocator llvm::Value* const, llvm::Value*> > >&, std::string*): Assertion `VMI > != ValueMap.end() && "Aliasee not linked"' failed. > 0 ?llvm-link ? ? ? 0x000000000054a49f > 1 ?llvm-link ? ? ? 0x000000000054c38a > 2 ?libpthread.so.0 0x000000364b00f0f0 > 3 ?libc.so.6 ? ? ? 0x000000364a8326d5 gsignal + 53 > 4 ?libc.so.6 ? ? ? 0x000000364a833eb5 abort + 373 > 5 ?libc.so.6 ? ? ? 0x000000364a82b7c5 __assert_fail + 245 > 6 ?llvm-link ? ? ? 0x000000000044546e > 7 ?llvm-link ? ? ? 0x0000000000446e62 > 8 ?llvm-link ? ? ? 0x0000000000405d27 main + 327 > 9 ?libc.so.6 ? ? ? 0x000000364a81eb1d __libc_start_main + 253 > 10 llvm-link ? ? ? 0x0000000000405009 > Stack dump: > 0. ? ? ?Program arguments: llvm-link -o out cff.o cmap.o cvt.o fpgm.o > gasp.o glyf.o hdmx.o head.o head-test.o hhea.o hmtx.o kern.o loca.o > ltsh.o maxp.o name.o os2.o ots.o post.o prep.o vdmx.o vorg.o > Aborted (core dumped) > > By adding debugging to LinkModules.cpp, we find that the symbol that > is causing it to explode is > _ZNSt12_Vector_baseIN12_GLOBAL__N_118CMAPSubtableHeaderESaIS1_EE12_Vector_implD1Ev. > > >From running llvm-nm on some of the .o files, there are a couple of > files with symbols that are marked as '?'. It's these symbols which > kill llvm-link. > > Adding more debugging to llvm-nm (see patch below), it turns out that > these symbols are aliases to aliases of functions, and aliases to > aliases to aliases of functions: > > ? ? ? ? T _ZNSt6vectorIN12_GLOBAL__N_118CMAPSubtableHeaderESaIS1_EED1Ev > ? ? ? ? { _ZNSt12_Vector_baseIN12_GLOBAL__N_118CMAPSubtableHeaderESaIS1_EE12_Vector_implD1Ev > ? ? ? ? ( _ZNSt12_Vector_baseIN12_GLOBAL__N_118CMAPSubtableHeaderESaIS1_EE12_Vector_implD2Ev > ? ? ? ? T _ZNSaIN12_GLOBAL__N_118CMAPSubtableHeaderEED2Ev > > Here my knowledge gives out. I'm not sure if clang is generating bad > output, or if llvm-link should be able to handle it. > > Any ideas? > > > Cheers > > AGL > > > Index: tools/llvm-nm/llvm-nm.cpp > =================================================================== > --- tools/llvm-nm/llvm-nm.cpp ? (revision 101478) > +++ tools/llvm-nm/llvm-nm.cpp ? (working copy) > @@ -82,6 +82,16 @@ > ? ? const GlobalValue *AliasedGV = GA->getAliasedGlobal(); > ? ? if (isa(AliasedGV)) ? ? ? ? ? ? ? ? ? ? ? ? ?return 'T'; > ? ? if (isa(AliasedGV)) ? ? ? ? ? ? ? ? ? ?return 'D'; > + ? ?if (const GlobalAlias *GA = dyn_cast(AliasedGV)) { > + ? ? ?const GlobalValue *AliasedGV = GA->getAliasedGlobal(); > + ? ? ?if (isa(AliasedGV)) ? ? ? ? ? ? ? ? ? ? ? ?return '('; > + ? ? ?if (isa(AliasedGV)) ? ? ? ? ? ? ? ? ?return ')'; > + ? ? ?if (const GlobalAlias *GA = dyn_cast(AliasedGV)) { > + ? ? ? ?const GlobalValue *AliasedGV = GA->getAliasedGlobal(); > + ? ? ? ?if (isa(AliasedGV)) ? ? ? ? ? ? ? ? ? ? ?return '{'; > + ? ? ? ?if (isa(AliasedGV)) ? ? ? ? ? ? ? ?return '}'; > + ? ? ?} > + ? ?} > ? } > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?return '?'; > ?} > > > > [1] http://code.google.com/p/ots/ > > -- > Adam Langley agl at imperialviolet.org http://www.imperialviolet.org > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > From zaffanella at cs.unipr.it Sun Apr 18 13:54:05 2010 From: zaffanella at cs.unipr.it (Enea Zaffanella) Date: Sun, 18 Apr 2010 20:54:05 +0200 Subject: [cfe-dev] Storage class as written in the source. In-Reply-To: References: <4BC8BA10.7080907@cs.unipr.it> <4BC959B3.80208@cs.unipr.it> <78717169-BBE7-4830-A82F-99906A0F843A@apple.com> <4BC9E9AC.7020604@cs.unipr.it> Message-ID: <4BCB554D.6020701@cs.unipr.it> Douglas Gregor wrote: [...] > The problem I have is that this > appears to be a GCC extension by accident, since it is not documented > and has no effect on the translation of the program. The GCC authors > probably just forgot to check that part of the standard, like we did. > What is the benefit of modeling a GCC accident that is rejected > outright by other C++ compilers? OK, you convinced me. Here is the revised patch, modified along your suggestions. Cheers, Enea. -------------- next part -------------- A non-text attachment was scrubbed... Name: StorageClassAsWritten-3.patch Type: text/x-patch Size: 53003 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100418/b12133ca/attachment-0001.bin From zaffanella at cs.unipr.it Sun Apr 18 16:51:18 2010 From: zaffanella at cs.unipr.it (Enea Zaffanella) Date: Sun, 18 Apr 2010 23:51:18 +0200 Subject: [cfe-dev] __builtin_index not recognized. Message-ID: <4BCB7ED6.4030108@cs.unipr.it> Hello. The following program fragment, which compiles cleanly using GCC, produces the following error with clang++: $ cat bug.cc char* idx(char *s, int c) { return __builtin_index(s, c); } $ clang++ -fsyntax-only bug.cc bug.cc:2:10: error: use of undeclared identifier '__builtin_index' return __builtin_index(s, c); ^ 1 error generated. Looking into include/clang/Builtins.def, we find LIBBUILTIN(index, "c*cC*i", "f", "strings.h") LIBBUILTIN(rindex, "c*cC*i", "f", "strings.h") but there are no corresponding lines for __builtin_index and __builtin_rindex. Regards, Enea Zaffanella. From diegoiast at gmail.com Mon Apr 19 04:52:37 2010 From: diegoiast at gmail.com (Diego Iastrubni) Date: Mon, 19 Apr 2010 12:52:37 +0300 Subject: [cfe-dev] [LLVMdev] Living on Clang In-Reply-To: <0D4616E6925F9541919B60692F61509E5A3A3047@orsmsx502.amr.corp.intel.com> References: <4229484F-BA99-41CD-B4DD-A6A31AB522DA@apple.com> <0D4616E6925F9541919B60692F61509E5A3A3047@orsmsx502.amr.corp.intel.com> Message-ID: How about building this in the CMake or auto* level we build a separate build script for it? I attache a simple version here. It does seem to work here. It's a shell script, which uses cmake for the building but it seems the second stage file works. I am not really sure why a third stage is needed, but it can be added quite easily. A windows version should be trivial to write (next week). A few rants about clang: This is the first time I was able to bootstrap the whole compiler. Which is great, don't get me wrong. But it was painfully slow, and the CPU of my machine became *really* hot unlike with gcc. The whole building process took more then 4 hours on this old cual core machine, while stage one took an hour more or less (I need to do a test again, without ccache). [elcuco at pinky ~/src/llvm] ls bootstrap-stage-2/bin/ -ltr total 262708 -rwxrwxr-x. 1 elcuco elcuco 5641794 2010-04-19 03:12 tblgen -rwxrwxr-x. 1 elcuco elcuco 985416 2010-04-19 04:41 FileCheck -rwxrwxr-x. 1 elcuco elcuco 6374 2010-04-19 04:41 count -rwxrwxr-x. 1 elcuco elcuco 122992 2010-04-19 04:41 not -rwxrwxr-x. 1 elcuco elcuco 24101 2010-04-19 05:34 llvm-config -rwxrwxr-x. 1 elcuco elcuco 18325933 2010-04-19 05:36 opt -rwxrwxr-x. 1 elcuco elcuco 7705301 2010-04-19 05:36 llvm-as -rwxrwxr-x. 1 elcuco elcuco 6671138 2010-04-19 05:36 llvm-dis -rwxrwxr-x. 1 elcuco elcuco 31626605 2010-04-19 05:37 llvm-mc -rwxrwxr-x. 1 elcuco elcuco 32630459 2010-04-19 05:38 llc -rwxrwxr-x. 1 elcuco elcuco 6814656 2010-04-19 05:38 llvm-ranlib -rwxrwxr-x. 1 elcuco elcuco 6875243 2010-04-19 05:38 llvm-ar -rwxrwxr-x. 1 elcuco elcuco 6827605 2010-04-19 05:38 llvm-nm -rwxrwxr-x. 1 elcuco elcuco 14608549 2010-04-19 05:39 llvm-ld -rwxrwxr-x. 1 elcuco elcuco 7506306 2010-04-19 05:39 llvm-prof -rwxrwxr-x. 1 elcuco elcuco 8310633 2010-04-19 05:39 llvm-link -rwxrwxr-x. 1 elcuco elcuco 25527057 2010-04-19 05:40 lli -rwxrwxr-x. 1 elcuco elcuco 8217315 2010-04-19 05:40 llvm-extract -rwxrwxr-x. 1 elcuco elcuco 18994379 2010-04-19 05:42 bugpoint -rwxrwxr-x. 1 elcuco elcuco 1011333 2010-04-19 05:43 llvm-bcanalyzer -rwxrwxr-x. 1 elcuco elcuco 6468 2010-04-19 05:43 llvm-stub -rwxrwxr-x. 1 elcuco elcuco 42747 2010-04-19 07:28 c-index-test -rwxrwxr-x. 1 elcuco elcuco 60447800 2010-04-19 07:29 clang lrwxrwxrwx. 1 elcuco elcuco 51 2010-04-19 07:29 clang++ -> /home/elcuco/src/llvm/bootstrap-stage-2/bin/./clang On Fri, Apr 16, 2010 at 12:27 AM, Lacey, Mark wrote: > > We want to make Clang great, and we need your help! > > Doug, > > I don't see any type of selfbuild target in the LLVM top level makefile. > This would be a useful way to automate the self build process. > > I've used similar mechanisms before on other compilers, where you can > trivially invoke a three phase build (first you do a full build with your > system compiler, then you use your built compiler to do another full build, > and then take that most recent build compiler to build yet again...). The > build options of the last two phases are identical, and the object files > from those last two passes are compared to ensure that they are identical. > > Ideally you can control the build options of the initial build and last two > builds independently (e.g. build a compiler without optimizations and with > assertions, and then do the last two builds with assertions disabled, and > optimizations on) - I'm not sure how easy this is with the autoconfig based > system LLVM/clang use, if at all. > > Mark > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100419/45b20edf/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: bootstrap-clang.sh Type: application/x-sh Size: 371 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100419/45b20edf/attachment.sh From ofv at wanadoo.es Mon Apr 19 08:52:18 2010 From: ofv at wanadoo.es (=?utf-8?Q?=C3=93scar_Fuentes?=) Date: Mon, 19 Apr 2010 15:52:18 +0200 Subject: [cfe-dev] [LLVMdev] Living on Clang References: <4229484F-BA99-41CD-B4DD-A6A31AB522DA@apple.com> <0D4616E6925F9541919B60692F61509E5A3A3047@orsmsx502.amr.corp.intel.com> Message-ID: <87zl0z5z3h.fsf@telefonica.net> Diego Iastrubni writes: > How about building this in the CMake or auto* level we build a separate > build script for it? I was thinking along the same lines, although a cmake script will do too, the only tricky point being the special syntax required for executing it. > I attache a simple version here. It does seem to work > here. It's a shell script, which uses cmake for the building but it seems > the second stage file works. I am not really sure why a third stage is > needed, but it can be added quite easily. The third stage is for comparing the output of clang (as compiled by gcc) against clang (as compiled by clang). The whole process is: Stage 1: build clang with gcc Stage 2: build clang with the clang created by gcc Stage 3: build clang with the clang created by clang. Final test: compare the object files geneated on Stage 2 with the object files generated on Stage 3. The last step is useful for detecting bugs on clang (and on gcc). > A windows version should be trivial to write (next week). Comparing the object files on Windows may be tricky, because IIRC they contain timestamps. > A few rants about clang: > This is the first time I was able to bootstrap the whole compiler. Which is > great, don't get me wrong. But it was painfully slow, and the CPU of my > machine became *really* hot unlike with gcc. The whole building process took > more then 4 hours on this old cual core machine, while stage one took an > hour more or less (I need to do a test again, without ccache). Building llvm+clang requires less than 10 minutes here with an Intel Q6600, Linux x86_64. From mark.lacey at intel.com Mon Apr 19 11:40:07 2010 From: mark.lacey at intel.com (Lacey, Mark) Date: Mon, 19 Apr 2010 09:40:07 -0700 Subject: [cfe-dev] [LLVMdev] Living on Clang In-Reply-To: <87zl0z5z3h.fsf@telefonica.net> References: <4229484F-BA99-41CD-B4DD-A6A31AB522DA@apple.com> <0D4616E6925F9541919B60692F61509E5A3A3047@orsmsx502.amr.corp.intel.com> <87zl0z5z3h.fsf@telefonica.net> Message-ID: <0D4616E6925F9541919B60692F61509E5A3A3EEB@orsmsx502.amr.corp.intel.com> > > A windows version should be trivial to write (next week). > > Comparing the object files on Windows may be tricky, because IIRC they > contain timestamps. This could be worked around by adding a hack (enabled by command-line options of various tools) to zero out the time/date stamp in the MS COFF header. Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 8614 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100419/a8502624/attachment-0001.bin From john.thompson.jtsoftware at gmail.com Mon Apr 19 13:45:27 2010 From: john.thompson.jtsoftware at gmail.com (John Thompson) Date: Mon, 19 Apr 2010 11:45:27 -0700 Subject: [cfe-dev] Casting scalars to vectors Message-ID: According to the AltiVec standard (section 2.4.6 in http://www.freescale.com/files/32bit/doc/ref_manual/ALTIVECPIM.pdf), casting a scalar to a vector is illegal, yet gcc seems to support it, as seen in many of those little files in the PS3 SDK in target\ppu\include\bits, which have statements like: vec_uint4 mask = (vec_uint4)(vec_int4)(-1); where vec_uint4 and vec_int4 are typedefs for vector types, i.e.: typedef vector int vec_int4; What does this actually do? I'm guessing it's supposed to fill the vector components with -1. How should this be handled in Clang? I filed a Bugzilla bug 6846 on this. If Clang should support it, I might be able to take a crack at it, with a little guidance. -- John Thompson John.Thompson.JTSoftware at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100419/4beeaed6/attachment.html From notfed at gmail.com Mon Apr 19 14:38:35 2010 From: notfed at gmail.com (Jay Sullivan) Date: Mon, 19 Apr 2010 15:38:35 -0400 Subject: [cfe-dev] Can't build CLang with CLang on FreeBSD In-Reply-To: References: Message-ID: > When I try to build clang with clang, I get an error when building > Alarm.cpp. When I compile with profiling, I'm seeing the error "clang: > warning: the clang compiler does not support '-pg' ". The build then > fails in the same place (Alarm.cpp) whether I use Debug and/or > Release, with or without profiling. My operating system is FreeBSD > 7.0-RELEASE. The clang I'm using was built with gcc4.2.1. Okay! Get this: it took about a day and a half to complete, but I was able to compile Clang [Release] using Clang [Debug]. Thus, I've had to use GCC to build Clang [Debug], and then use Clang [Debug] to build Clang [Release]. (When I try to build Clang [Release] with GCC, it creates a b0rken executable.) Trying to build Clang [Release] with Clang [Release], however, left me with: [jay at dell ~/progs/llvm]$ gmake gmake[1]: Entering directory `/usr/home/jay/progs/llvm/lib/System' llvm[1]: Compiling Alarm.cpp for Release build Stack dump: 0. Program arguments: /usr/home/jay/progs/clang/Release_clang/bin/clang -cc1 -triple i386-unknown-freebsd7.0 -S -disable-free -main-file-name Alarm.cpp -pic-level 2 -mdisable-fp-elim -mconstructor-aliases -target-cpu pentium4 -resource-dir /usr/home/jay/progs/clang/Release_clang/lib/clang/1.5 -dependency-file /usr/home/jay/progs/llvm/lib/System/Release/Alarm.d.tmp -MP -MT /usr/home/jay/progs/llvm/lib/System/Release/Alarm.o -MT /usr/home/jay/progs/llvm/lib/System/Release/Alarm.d -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -I/usr/home/jay/progs/llvm/include -I/usr/home/jay/progs/llvm/lib/System -O3 -Woverloaded-virtual -Wcast-qual -Wall -W -Wno-unused-parameter -Wwrite-strings -ferror-limit 19 -fmessage-length 80 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-HxV9zW.s -x c++ Alarm.cpp 1. parser at end of file 2. Per-module optimization passes 3. Running pass 'CallGraph Pass Manager' on module 'Alarm.cpp'. 4. Running pass 'Dead Store Elimination' on function '@_ZN4llvm3sys10SetupAlarmEj' clang: error: compiler command failed due to signal 11 (use -v to see invocation) gmake[1]: *** [/usr/home/jay/progs/llvm/lib/System/Release/Alarm.o] Error 1 gmake[1]: Leaving directory `/usr/home/jay/progs/llvm/lib/System' gmake: *** [all] Error 1 -- Jay Sullivan From wan at google.com Mon Apr 19 14:38:51 2010 From: wan at google.com (=?UTF-8?B?WmhhbnlvbmcgV2FuICjOu3gueCB4KQ==?=) Date: Mon, 19 Apr 2010 12:38:51 -0700 Subject: [cfe-dev] adding FileSkipped() to PPCallbacks In-Reply-To: <237198E3-89C6-458D-B4B6-A7F0C6EB7A4C@apple.com> References: <15C03547-2968-4A83-9452-AE5DED44F25C@apple.com> <9AE21B23-06E4-48B2-B4D0-DFB5D76908C7@apple.com> <237198E3-89C6-458D-B4B6-A7F0C6EB7A4C@apple.com> Message-ID: Please take a look at the new patch, which doesn't call createFileID() for a skipped file. Thanks! On Fri, Apr 16, 2010 at 4:41 PM, Chris Lattner wrote: > > On Apr 16, 2010, at 2:38 PM, Zhanyong Wan (?x.x x) wrote: > >> On Fri, Apr 16, 2010 at 2:14 PM, Chris Lattner wrote: >>> >>> On Apr 16, 2010, at 2:09 PM, Zhanyong Wan (?x.x x) wrote: >>> >>>> Thanks for the review, Chris. ?Please see the new patch. ?I kept the >>>> signature of FileSkipped() unchanged to be consistent with >>>> FileChanged(). >>> >>> Keeping the interfaces consistent is nice, but is it really worth it? ?This will punish other PPCallbacks that don't care about this, like -MM mode and friends. ?SourceMgr.createFileID isn't hyper-expensive, but it is good to avoid work that no other client at all needs. ?Sinking this work into the implementation that cares makes sense to me. >> >> If createFileID() is called here, the file being skipped has already >> been processed earlier, which is a much more expensive operation. ?So >> do we really want to sacrifice the cleanness of the API for it? > > I'm pushing back because the preprocessor is a particularly performance sensitive part of the compiler, and this adds no value for any current clients. ?I think the cost should be sunk into your client, even if it makes its implementation a little less elegant. > > -Chris -- Zhanyong -------------- next part -------------- A non-text attachment was scrubbed... Name: file_skipped3.patch Type: text/x-patch Size: 2753 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100419/6df37bac/attachment.bin From anthony.hw.kong at gmail.com Mon Apr 19 15:08:39 2010 From: anthony.hw.kong at gmail.com (Anthony Kong) Date: Tue, 20 Apr 2010 06:08:39 +1000 Subject: [cfe-dev] Problem with building CLang on OSX (Snow Leopard) Message-ID: Hi, all, I tried to build clang Here is the list of commands I used svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm cd tools svn co http://llvm.org/svn/llvm-project/cfe/trunk clang cd .. ./configure make Then I encountered a number of error messages similar to this /var/folders/gM/gM3LrYvlHsiF1mG55FgL+k+++TI/-Tmp-/camlasm67bd71.s:697:suffix or operands invalid for `call' /var/folders/gM/gM3LrYvlHsiF1mG55FgL+k+++TI/-Tmp-/camlasm67bd71.s:701:suffix or operands invalid for `push' /var/folders/gM/gM3LrYvlHsiF1mG55FgL+k+++TI/-Tmp-/camlasm67bd71.s:702:32-bit absolute addressing is not supported for x86-64 Just wonder if anyone has encountered similar issue Cheers -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100420/03a3848e/attachment.html From clattner at apple.com Mon Apr 19 15:45:43 2010 From: clattner at apple.com (Chris Lattner) Date: Mon, 19 Apr 2010 13:45:43 -0700 Subject: [cfe-dev] adding FileSkipped() to PPCallbacks In-Reply-To: References: <15C03547-2968-4A83-9452-AE5DED44F25C@apple.com> <9AE21B23-06E4-48B2-B4D0-DFB5D76908C7@apple.com> <237198E3-89C6-458D-B4B6-A7F0C6EB7A4C@apple.com> Message-ID: On Apr 19, 2010, at 12:38 PM, Zhanyong Wan (?x.x x) wrote: > Please take a look at the new patch, which doesn't call createFileID() > for a skipped file. Thanks! Looks good, committed in r101813, thanks! -Chris > > On Fri, Apr 16, 2010 at 4:41 PM, Chris Lattner wrote: >> >> On Apr 16, 2010, at 2:38 PM, Zhanyong Wan (?x.x x) wrote: >> >>> On Fri, Apr 16, 2010 at 2:14 PM, Chris Lattner wrote: >>>> >>>> On Apr 16, 2010, at 2:09 PM, Zhanyong Wan (?x.x x) wrote: >>>> >>>>> Thanks for the review, Chris. Please see the new patch. I kept the >>>>> signature of FileSkipped() unchanged to be consistent with >>>>> FileChanged(). >>>> >>>> Keeping the interfaces consistent is nice, but is it really worth it? This will punish other PPCallbacks that don't care about this, like -MM mode and friends. SourceMgr.createFileID isn't hyper-expensive, but it is good to avoid work that no other client at all needs. Sinking this work into the implementation that cares makes sense to me. >>> >>> If createFileID() is called here, the file being skipped has already >>> been processed earlier, which is a much more expensive operation. So >>> do we really want to sacrifice the cleanness of the API for it? >> >> I'm pushing back because the preprocessor is a particularly performance sensitive part of the compiler, and this adds no value for any current clients. I think the cost should be sunk into your client, even if it makes its implementation a little less elegant. >> >> -Chris > > > > -- > Zhanyong > From john.thompson.jtsoftware at gmail.com Mon Apr 19 17:00:43 2010 From: john.thompson.jtsoftware at gmail.com (John Thompson) Date: Mon, 19 Apr 2010 15:00:43 -0700 Subject: [cfe-dev] Casting scalars to vectors In-Reply-To: References: Message-ID: My colleague pointed out that it's not a cast, but a literal, which Clang should support. -John On Mon, Apr 19, 2010 at 11:45 AM, John Thompson < john.thompson.jtsoftware at gmail.com> wrote: > According to the AltiVec standard (section 2.4.6 in > http://www.freescale.com/files/32bit/doc/ref_manual/ALTIVECPIM.pdf), > casting a scalar to a vector is illegal, yet gcc seems to support it, as > seen in many of those little files in the PS3 SDK in > target\ppu\include\bits, which have statements like: > > vec_uint4 mask = (vec_uint4)(vec_int4)(-1); > where vec_uint4 and vec_int4 are typedefs for vector types, i.e.: > > typedef vector int vec_int4; > > What does this actually do? I'm guessing it's supposed to fill the vector > components with -1. > > How should this be handled in Clang? > I filed a Bugzilla bug 6846 on this. > > If Clang should support it > , I might be able to take a crack at it, with a little guidance. > > -- > John Thompson > John.Thompson.JTSoftware at gmail.com > > -- John Thompson John.Thompson.JTSoftware at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100419/2bb0a411/attachment-0001.html From dgregor at apple.com Mon Apr 19 17:42:53 2010 From: dgregor at apple.com (Douglas Gregor) Date: Mon, 19 Apr 2010 15:42:53 -0700 Subject: [cfe-dev] [LLVMdev] Living on Clang In-Reply-To: References: <4229484F-BA99-41CD-B4DD-A6A31AB522DA@apple.com> <0D4616E6925F9541919B60692F61509E5A3A3047@orsmsx502.amr.corp.intel.com> Message-ID: <697AF43F-9E72-4190-AC2C-E53BC9293273@apple.com> On Apr 19, 2010, at 2:52 AM, Diego Iastrubni wrote: > How about building this in the CMake or auto* level we build a separate build script for it? I attache a simple version here. It does seem to work here. It's a shell script, which uses cmake for the building but it seems the second stage file works. I am not really sure why a third stage is needed, but it can be added quite easily. A windows version should be trivial to write (next week). We can do this with a script, although it would be more convenient if it were a part of the build system itself. Regarding the script itself... mkdir -p bootstrap-stage-1 cd bootstrap-stage-1 cmake -DVARIABLE:CMAKE_BUILD_TYPE=release ../ make VERBOSE=1 cd .. Your CMake command-line syntax is wrong. To set CMAKE_BUILD_TYPE to Release, use cmake -DCMAKE_BUILD_TYPE:STRING=Release ../ > A few rants about clang: > This is the first time I was able to bootstrap the whole compiler. Which is great, don't get me wrong. But it was painfully slow, and the CPU of my machine became *really* hot unlike with gcc. The whole building process took more then 4 hours on this old cual core machine, while stage one took an hour more or less (I need to do a test again, without ccache). That's what happens when you use an unoptimized Clang to build Clang :) Your mis-typed setting of CMAKE_BUILD_TYPE meant that the first stage built a debug Clang. I'm sure things will go better when you turn optimization on. - Doug From dgregor at apple.com Mon Apr 19 17:55:44 2010 From: dgregor at apple.com (Douglas Gregor) Date: Mon, 19 Apr 2010 15:55:44 -0700 Subject: [cfe-dev] Storage class as written in the source. In-Reply-To: <4BCB554D.6020701@cs.unipr.it> References: <4BC8BA10.7080907@cs.unipr.it> <4BC959B3.80208@cs.unipr.it> <78717169-BBE7-4830-A82F-99906A0F843A@apple.com> <4BC9E9AC.7020604@cs.unipr.it> <4BCB554D.6020701@cs.unipr.it> Message-ID: <693E9E56-A5F7-4DDD-A7E0-C487BEFB30B5@apple.com> On Apr 18, 2010, at 11:54 AM, Enea Zaffanella wrote: > Douglas Gregor wrote: > [...] >> The problem I have is that this >> appears to be a GCC extension by accident, since it is not documented >> and has no effect on the translation of the program. The GCC authors >> probably just forgot to check that part of the standard, like we did. >> What is the benefit of modeling a GCC accident that is rejected >> outright by other C++ compilers? > > OK, you convinced me. > Here is the revised patch, modified along your suggestions. Thanks! Committed in r101826. - Doug From eli.friedman at gmail.com Mon Apr 19 18:07:13 2010 From: eli.friedman at gmail.com (Eli Friedman) Date: Mon, 19 Apr 2010 16:07:13 -0700 Subject: [cfe-dev] Casting scalars to vectors In-Reply-To: References: Message-ID: On Mon, Apr 19, 2010 at 3:00 PM, John Thompson wrote: > My colleague pointed out that it's not a cast, but a literal, which Clang > should support. I'm pretty sure that's already implemented... are you passing -faltivec to clang? -Eli > -John > > On Mon, Apr 19, 2010 at 11:45 AM, John Thompson > wrote: >> >> According to the AltiVec standard (section 2.4.6 in >> http://www.freescale.com/files/32bit/doc/ref_manual/ALTIVECPIM.pdf), casting >> a scalar to a vector is illegal, yet gcc seems to support it, as seen in >> many of those little files in the PS3 SDK in target\ppu\include\bits, which >> have statements like: >> >> vec_uint4 mask = (vec_uint4)(vec_int4)(-1); >> >> where vec_uint4 and vec_int4 are typedefs for vector types, i.e.: >> >> typedef vector int vec_int4; >> >> What does this actually do? I'm guessing it's supposed to fill the vector >> components with -1. >> >> How should this be handled in Clang? >> >> I filed a Bugzilla bug 6846 on this. >> >> If Clang should support it >> , I might be able to take a crack at it, with a little guidance. >> >> -- >> John Thompson >> John.Thompson.JTSoftware at gmail.com >> > > > > -- > John Thompson > John.Thompson.JTSoftware at gmail.com > > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > > From john.thompson.jtsoftware at gmail.com Mon Apr 19 20:02:09 2010 From: john.thompson.jtsoftware at gmail.com (John Thompson) Date: Mon, 19 Apr 2010 18:02:09 -0700 Subject: [cfe-dev] Casting scalars to vectors In-Reply-To: References: Message-ID: >I'm pretty sure that's already implemented... are you passing >-faltivec to clang? Yes. This stops the error, but is it enough?: Index: lib/Sema/SemaInit.cpp =================================================================== --- lib/Sema/SemaInit.cpp (revision 101528) +++ lib/Sema/SemaInit.cpp (working copy) @@ -886,7 +886,7 @@ // OpenCL & AltiVec require all elements to be initialized. if (numEltsInit != maxElements) - if (SemaRef.getLangOptions().OpenCL || SemaRef.getLangOptions().AltiVec) + if (SemaRef.getLangOptions().OpenCL) SemaRef.Diag(IList->getSourceRange().getBegin(), diag::err_vector_incorrect_num_initializers) << (numEltsInit < maxElements) << maxElements << numEltsInit; On Mon, Apr 19, 2010 at 4:07 PM, Eli Friedman wrote: > On Mon, Apr 19, 2010 at 3:00 PM, John Thompson > wrote: > > My colleague pointed out that it's not a cast, but a literal, which Clang > > should support. > > I'm pretty sure that's already implemented... are you passing > -faltivec to clang? > > -Eli > > > -John > > > > On Mon, Apr 19, 2010 at 11:45 AM, John Thompson > > wrote: > >> > >> According to the AltiVec standard (section 2.4.6 in > >> http://www.freescale.com/files/32bit/doc/ref_manual/ALTIVECPIM.pdf), > casting > >> a scalar to a vector is illegal, yet gcc seems to support it, as seen in > >> many of those little files in the PS3 SDK in target\ppu\include\bits, > which > >> have statements like: > >> > >> vec_uint4 mask = (vec_uint4)(vec_int4)(-1); > >> > >> where vec_uint4 and vec_int4 are typedefs for vector types, i.e.: > >> > >> typedef vector int vec_int4; > >> > >> What does this actually do? I'm guessing it's supposed to fill the > vector > >> components with -1. > >> > >> How should this be handled in Clang? > >> > >> I filed a Bugzilla bug 6846 on this. > >> > >> If Clang should support it > >> , I might be able to take a crack at it, with a little guidance. > >> > >> -- > >> John Thompson > >> John.Thompson.JTSoftware at gmail.com > >> > > > > > > > > -- > > John Thompson > > John.Thompson.JTSoftware at gmail.com > > > > > > _______________________________________________ > > cfe-dev mailing list > > cfe-dev at cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > > > > > -- John Thompson John.Thompson.JTSoftware at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100419/8eafd446/attachment.html From clattner at apple.com Mon Apr 19 20:04:51 2010 From: clattner at apple.com (Chris Lattner) Date: Mon, 19 Apr 2010 18:04:51 -0700 Subject: [cfe-dev] Casting scalars to vectors In-Reply-To: References: Message-ID: On Apr 19, 2010, at 6:02 PM, John Thompson wrote: > >I'm pretty sure that's already implemented... are you passing > >-faltivec to clang? > Yes. > > This stops the error, but is it enough?: That should be enough, if you like that patch go ahead and commit it (with a testcase). -Chris > > Index: lib/Sema/SemaInit.cpp > =================================================================== > --- lib/Sema/SemaInit.cpp (revision 101528) > +++ lib/Sema/SemaInit.cpp (working copy) > @@ -886,7 +886,7 @@ > > // OpenCL & AltiVec require all elements to be initialized. > if (numEltsInit != maxElements) > - if (SemaRef.getLangOptions().OpenCL || SemaRef.getLangOptions().AltiVec) > + if (SemaRef.getLangOptions().OpenCL) > SemaRef.Diag(IList->getSourceRange().getBegin(), > diag::err_vector_incorrect_num_initializers) > << (numEltsInit < maxElements) << maxElements << numEltsInit; > > On Mon, Apr 19, 2010 at 4:07 PM, Eli Friedman wrote: > On Mon, Apr 19, 2010 at 3:00 PM, John Thompson > wrote: > > My colleague pointed out that it's not a cast, but a literal, which Clang > > should support. > > I'm pretty sure that's already implemented... are you passing > -faltivec to clang? > > -Eli > > > -John > > > > On Mon, Apr 19, 2010 at 11:45 AM, John Thompson > > wrote: > >> > >> According to the AltiVec standard (section 2.4.6 in > >> http://www.freescale.com/files/32bit/doc/ref_manual/ALTIVECPIM.pdf), casting > >> a scalar to a vector is illegal, yet gcc seems to support it, as seen in > >> many of those little files in the PS3 SDK in target\ppu\include\bits, which > >> have statements like: > >> > >> vec_uint4 mask = (vec_uint4)(vec_int4)(-1); > >> > >> where vec_uint4 and vec_int4 are typedefs for vector types, i.e.: > >> > >> typedef vector int vec_int4; > >> > >> What does this actually do? I'm guessing it's supposed to fill the vector > >> components with -1. > >> > >> How should this be handled in Clang? > >> > >> I filed a Bugzilla bug 6846 on this. > >> > >> If Clang should support it > >> , I might be able to take a crack at it, with a little guidance. > >> > >> -- > >> John Thompson > >> John.Thompson.JTSoftware at gmail.com > >> > > > > > > > > -- > > John Thompson > > John.Thompson.JTSoftware at gmail.com > > > > > > _______________________________________________ > > cfe-dev mailing list > > cfe-dev at cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > > > > > > > > -- > John Thompson > John.Thompson.JTSoftware at gmail.com > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100419/61acff7d/attachment-0001.html From clattner at apple.com Mon Apr 19 20:32:18 2010 From: clattner at apple.com (Chris Lattner) Date: Mon, 19 Apr 2010 18:32:18 -0700 Subject: [cfe-dev] __builtin_index not recognized. In-Reply-To: <4BCB7ED6.4030108@cs.unipr.it> References: <4BCB7ED6.4030108@cs.unipr.it> Message-ID: <4CB3C55E-E74A-4AB4-92AA-1BB12885D00F@apple.com> added in r101858. On Apr 18, 2010, at 2:51 PM, Enea Zaffanella wrote: > Hello. > > The following program fragment, which compiles cleanly using GCC, > produces the following error with clang++: > > $ cat bug.cc > char* idx(char *s, int c) { > return __builtin_index(s, c); > } > > > $ clang++ -fsyntax-only bug.cc > bug.cc:2:10: error: use of undeclared identifier '__builtin_index' > return __builtin_index(s, c); > ^ > 1 error generated. > > > Looking into include/clang/Builtins.def, we find > > LIBBUILTIN(index, "c*cC*i", "f", "strings.h") > LIBBUILTIN(rindex, "c*cC*i", "f", "strings.h") > > but there are no corresponding lines for __builtin_index and > __builtin_rindex. > > Regards, > Enea Zaffanella. > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From yan_lin_aung at yahoo.com Mon Apr 19 21:07:55 2010 From: yan_lin_aung at yahoo.com (Yan Lin Aung) Date: Mon, 19 Apr 2010 19:07:55 -0700 (PDT) Subject: [cfe-dev] Makefile with Clang Message-ID: <337138.87442.qm@web30005.mail.mud.yahoo.com> Hi I would like to compile applications which consists of multiple source files (for example, file1.c file2.c, main.c) with Clang using Makefile to get the LLVM bitcode file. Anyone knows how to do that? Thanks. With regards Yan Lin From eli.friedman at gmail.com Mon Apr 19 23:05:31 2010 From: eli.friedman at gmail.com (Eli Friedman) Date: Mon, 19 Apr 2010 21:05:31 -0700 Subject: [cfe-dev] Makefile with Clang In-Reply-To: <337138.87442.qm@web30005.mail.mud.yahoo.com> References: <337138.87442.qm@web30005.mail.mud.yahoo.com> Message-ID: On Mon, Apr 19, 2010 at 7:07 PM, Yan Lin Aung wrote: > Hi > > I would like to compile applications which consists of multiple source files (for example, file1.c file2.c, main.c) with Clang using Makefile to get the LLVM bitcode file. Anyone knows how to do that? Thanks. Try the following: make CC="clang -emit-llvm" -Eli From zhunansjtu at gmail.com Tue Apr 20 00:32:41 2010 From: zhunansjtu at gmail.com (Nan Zhu) Date: Tue, 20 Apr 2010 13:32:41 +0800 Subject: [cfe-dev] Makefile with Clang In-Reply-To: <337138.87442.qm@web30005.mail.mud.yahoo.com> References: <337138.87442.qm@web30005.mail.mud.yahoo.com> Message-ID: You mean you want one bitcode file for each C source file or you would like to have a whole program bitcode file? 2010/4/20 Yan Lin Aung > Hi > > I would like to compile applications which consists of multiple source > files (for example, file1.c file2.c, main.c) with Clang using Makefile to > get the LLVM bitcode file. Anyone knows how to do that? Thanks. > > With regards > Yan Lin > > > > _______________________________________________ > 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/20100420/b0dad7ef/attachment.html From erik at cederstrand.dk Tue Apr 20 01:56:40 2010 From: erik at cederstrand.dk (Erik Cederstrand) Date: Tue, 20 Apr 2010 08:56:40 +0200 Subject: [cfe-dev] Can't build CLang with CLang on FreeBSD In-Reply-To: References: Message-ID: <15479C91-52AE-45D6-9B12-4CB5AE40AABB@cederstrand.dk> Den 19/04/2010 kl. 21.38 skrev Jay Sullivan: > > clang: error: compiler command failed due to signal 11 (use -v to see > invocation) At least earlier, a signal 11 from GCC on FreeBSD was a strong indicator of faulty hardware, e.g. a bad RAM module. It may be the case for Clang, too. Thanks, Erik -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1928 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100420/6edc522e/attachment.bin From spellegrini at dps.uibk.ac.at Tue Apr 20 02:03:47 2010 From: spellegrini at dps.uibk.ac.at (Simone Pellegrini) Date: Tue, 20 Apr 2010 09:03:47 +0200 Subject: [cfe-dev] Clang 2.7 and C++ support Message-ID: <4BCD51D3.20105@dps.uibk.ac.at> Hi all, I was wondering if C++ support will be enabled by default in this release or we would have to wait the next release (2.8). and if not, is there any way to enable it? cheers, Simone From xuzhongxing at gmail.com Tue Apr 20 02:24:41 2010 From: xuzhongxing at gmail.com (Zhongxing Xu) Date: Tue, 20 Apr 2010 15:24:41 +0800 Subject: [cfe-dev] Clang 2.7 and C++ support In-Reply-To: <4BCD51D3.20105@dps.uibk.ac.at> References: <4BCD51D3.20105@dps.uibk.ac.at> Message-ID: Hi Simone, You can use clang++ just like g++. On Tue, Apr 20, 2010 at 3:03 PM, Simone Pellegrini < spellegrini at dps.uibk.ac.at> wrote: > Hi all, > I was wondering if C++ support will be enabled by default in this > release or we would have to wait the next release (2.8). > > and if not, is there any way to enable it? > > cheers, Simone > _______________________________________________ > 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/20100420/dd033e8a/attachment.html From dgregor at apple.com Tue Apr 20 02:25:42 2010 From: dgregor at apple.com (Douglas Gregor) Date: Tue, 20 Apr 2010 00:25:42 -0700 Subject: [cfe-dev] Clang 2.7 and C++ support In-Reply-To: <4BCD51D3.20105@dps.uibk.ac.at> References: <4BCD51D3.20105@dps.uibk.ac.at> Message-ID: On Apr 20, 2010, at 12:03 AM, Simone Pellegrini wrote: > Hi all, > I was wondering if C++ support will be enabled by default in this > release or we would have to wait the next release (2.8). > > and if not, is there any way to enable it? C++ support is enabled by default in 2.7. - Doug From spellegrini at dps.uibk.ac.at Tue Apr 20 03:02:22 2010 From: spellegrini at dps.uibk.ac.at (Simone Pellegrini) Date: Tue, 20 Apr 2010 10:02:22 +0200 Subject: [cfe-dev] Clang 2.7 and C++ support In-Reply-To: References: <4BCD51D3.20105@dps.uibk.ac.at> Message-ID: <4BCD5F8E.608@dps.uibk.ac.at> On 04/20/2010 09:25 AM, Douglas Gregor wrote: > On Apr 20, 2010, at 12:03 AM, Simone Pellegrini wrote: > > >> Hi all, >> I was wondering if C++ support will be enabled by default in this >> release or we would have to wait the next release (2.8). >> >> and if not, is there any way to enable it? >> > C++ support is enabled by default in 2.7. > What I am doing is using clang as a library so I cannot use the clang driver directly. I manually instantiate a CompilerInstance and feed C++ code and get the following error: error: unknown type name 'class' I also tried to feed the "-ccc-clang-cxx" flag as suggested in: http://clang.llvm.org/docs/UsersManual.html#cxx but it didn't help. The actual code I use to instantiate a compiler is the following: CompilerInstance Clang; Clang.setLLVMContext(new llvm::LLVMContext); Clang.createDiagnostics(argc, argv); Clang.setFileManager(&FileMgr); Clang.createSourceManager(); Clang.InitializeSourceManager(File->getName()); // Add the default clang system headers Clang.getHeaderSearchOpts().AddPath( "/software/llvm-2.7/lib/clang/1.1/include/", clang::frontend::System, true, false ); // add user headers for (size_t i = 0; i < Flags::I_dirs.size(); ++i) Clang.getHeaderSearchOpts().AddPath( Flags::I_dirs[i], clang::frontend::Angled, true, false); TargetOptions TO; TO.Triple = llvm::Triple("x86_64", "PC", "Linux").getTriple(); Clang.setTarget( TargetInfo::CreateTargetInfo (Clang.getDiagnostics(), TO) ); // A compiler invocation object has to be created in order for the diagnostics to work CompilerInvocation* CI = new CompilerInvocation; // CompilerInvocation will be deleted by CompilerInstance const char* arg = "ccc-clang-cxx"; CompilerInvocation::CreateFromArgs(*CI, &arg, &arg+1, Clang.getDiagnostics()); Clang.setInvocation(CI); Clang.createPreprocessor(); Clang.createASTContext(); ... what am I doing wrong? The code works perfectly for C programs!! Where I can find the code > - Doug > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100420/c677b039/attachment-0001.html From Anton.Lokhmotov at arm.com Tue Apr 20 04:34:53 2010 From: Anton.Lokhmotov at arm.com (Anton Lokhmotov) Date: Tue, 20 Apr 2010 10:34:53 +0100 Subject: [cfe-dev] Casting scalars to vectors In-Reply-To: References: Message-ID: <000101cae06c$bb6245b0$3226d110$@Lokhmotov@arm.com> > This stops the error, but is it enough? Sorry, I couldn't understand from the thread what was the error? > - if (SemaRef.getLangOptions().OpenCL || SemaRef.getLangOptions().AltiVec) > + if (SemaRef.getLangOptions().OpenCL) In other words, it's something that's not required for AltiVec but is required for OpenCL? Cheers, Anton. From aaronngray.lists at googlemail.com Tue Apr 20 08:26:32 2010 From: aaronngray.lists at googlemail.com (Aaron Gray) Date: Tue, 20 Apr 2010 14:26:32 +0100 Subject: [cfe-dev] Clang on Clang on Cygwin - configure failure Message-ID: On doing a configure :- /usr/build/llvm-2/configure --prefix=/usr/llvm-2 CC=/usr/llvm/bin/clang CXX=/usr/llvm/bin/clang++ I am getting the following warnings and an error at the end :- checking dlfcn.h presence... yes configure: WARNING: dlfcn.h: present but cannot be compiled configure: WARNING: dlfcn.h: check for missing prerequisite headers? configure: WARNING: dlfcn.h: see the Autoconf documentation configure: WARNING: dlfcn.h: section "Present But Cannot Be Compiled" configure: WARNING: dlfcn.h: proceeding with the preprocessor's result configure: WARNING: dlfcn.h: in the future, the compiler will take precedence configure: WARNING: ## ----------------------------------- ## configure: WARNING: ## Report this to llvmbugs at cs.uiuc.edu ## configure: WARNING: ## ----------------------------------- ## checking for dlfcn.h... yes checking dynamic linker characteristics... Win32 ld.exe checking which extension is used for loadable modules... .dll checking which variable specifies run-time library path... PATH checking for the default library search path... /lib /usr/lib checking for objdir... .libs checking command to parse /usr/bin/nm -B output from object... ok checking whether libtool supports -dlopen/-dlpreopen... yes checking for shl_load... no checking for shl_load in -ldld... no checking for dlopen in -ldl... yes checking for dlerror... yes checking for _ prefix in compiled symbols... yes checking whether we have to add an underscore for dlsym... unknown checking whether deplibs are loaded by dlopen... unknown checking argz.h usability... no checking argz.h presence... yes configure: WARNING: argz.h: present but cannot be compiled configure: WARNING: argz.h: check for missing prerequisite headers? configure: WARNING: argz.h: see the Autoconf documentation configure: WARNING: argz.h: section "Present But Cannot Be Compiled" configure: WARNING: argz.h: proceeding with the preprocessor's result configure: WARNING: argz.h: in the future, the compiler will take precedence configure: WARNING: ## ----------------------------------- ## configure: WARNING: ## Report this to llvmbugs at cs.uiuc.edu ## configure: WARNING: ## ----------------------------------- ## checking for argz.h... yes checking assert.h usability... no checking assert.h presence... yes configure: WARNING: assert.h: present but cannot be compiled configure: WARNING: assert.h: check for missing prerequisite headers? configure: WARNING: assert.h: see the Autoconf documentation configure: WARNING: assert.h: section "Present But Cannot Be Compiled" configure: WARNING: assert.h: proceeding with the preprocessor's result configure: WARNING: assert.h: in the future, the compiler will take precedence configure: WARNING: ## ----------------------------------- ## configure: WARNING: ## Report this to llvmbugs at cs.uiuc.edu ## configure: WARNING: ## ----------------------------------- ## checking for assert.h... yes checking ctype.h usability... no checking ctype.h presence... yes configure: WARNING: ctype.h: present but cannot be compiled configure: WARNING: ctype.h: check for missing prerequisite headers? configure: WARNING: ctype.h: see the Autoconf documentation configure: WARNING: ctype.h: section "Present But Cannot Be Compiled" configure: WARNING: ctype.h: proceeding with the preprocessor's result configure: WARNING: ctype.h: in the future, the compiler will take precedence configure: WARNING: ## ----------------------------------- ## configure: WARNING: ## Report this to llvmbugs at cs.uiuc.edu ## configure: WARNING: ## ----------------------------------- ## checking for ctype.h... yes checking errno.h usability... no checking errno.h presence... yes configure: WARNING: errno.h: present but cannot be compiled configure: WARNING: errno.h: check for missing prerequisite headers? configure: WARNING: errno.h: see the Autoconf documentation configure: WARNING: errno.h: section "Present But Cannot Be Compiled" configure: WARNING: errno.h: proceeding with the preprocessor's result configure: WARNING: errno.h: in the future, the compiler will take precedence configure: WARNING: ## ----------------------------------- ## configure: WARNING: ## Report this to llvmbugs at cs.uiuc.edu ## configure: WARNING: ## ----------------------------------- ## checking for errno.h... yes checking malloc.h usability... no checking malloc.h presence... yes configure: WARNING: malloc.h: present but cannot be compiled configure: WARNING: malloc.h: check for missing prerequisite headers? configure: WARNING: malloc.h: see the Autoconf documentation configure: WARNING: malloc.h: section "Present But Cannot Be Compiled" configure: WARNING: malloc.h: proceeding with the preprocessor's result configure: WARNING: malloc.h: in the future, the compiler will take precedence configure: WARNING: ## ----------------------------------- ## configure: WARNING: ## Report this to llvmbugs at cs.uiuc.edu ## configure: WARNING: ## ----------------------------------- ## checking for malloc.h... yes checking for memory.h... (cached) no checking for stdlib.h... (cached) no checking stdio.h usability... no checking stdio.h presence... yes configure: WARNING: stdio.h: present but cannot be compiled configure: WARNING: stdio.h: check for missing prerequisite headers? configure: WARNING: stdio.h: see the Autoconf documentation configure: WARNING: stdio.h: section "Present But Cannot Be Compiled" configure: WARNING: stdio.h: proceeding with the preprocessor's result configure: WARNING: stdio.h: in the future, the compiler will take precedence configure: WARNING: ## ----------------------------------- ## configure: WARNING: ## Report this to llvmbugs at cs.uiuc.edu ## configure: WARNING: ## ----------------------------------- ## checking errno.h usability... no checking errno.h presence... yes configure: WARNING: errno.h: present but cannot be compiled configure: WARNING: errno.h: check for missing prerequisite headers? configure: WARNING: errno.h: see the Autoconf documentation configure: WARNING: errno.h: section "Present But Cannot Be Compiled" configure: WARNING: errno.h: proceeding with the preprocessor's result configure: WARNING: errno.h: in the future, the compiler will take precedence configure: WARNING: ## ----------------------------------- ## configure: WARNING: ## Report this to llvmbugs at cs.uiuc.edu ## configure: WARNING: ## ----------------------------------- ## checking for errno.h... yes checking malloc.h usability... no checking malloc.h presence... yes configure: WARNING: malloc.h: present but cannot be compiled configure: WARNING: malloc.h: check for missing prerequisite headers? configure: WARNING: malloc.h: see the Autoconf documentation configure: WARNING: malloc.h: section "Present But Cannot Be Compiled" configure: WARNING: malloc.h: proceeding with the preprocessor's result configure: WARNING: malloc.h: in the future, the compiler will take precedence configure: WARNING: ## ----------------------------------- ## configure: WARNING: ## Report this to llvmbugs at cs.uiuc.edu ## configure: WARNING: ## ----------------------------------- ## checking for malloc.h... yes checking for memory.h... (cached) no checking for stdlib.h... (cached) no checking stdio.h usability... no checking stdio.h presence... yes configure: WARNING: stdio.h: present but cannot be compiled configure: WARNING: stdio.h: check for missing prerequisite headers? configure: WARNING: stdio.h: see the Autoconf documentation configure: WARNING: stdio.h: section "Present But Cannot Be Compiled" configure: WARNING: stdio.h: proceeding with the preprocessor's result configure: WARNING: stdio.h: in the future, the compiler will take precedence configure: WARNING: ## ----------------------------------- ## configure: WARNING: ## Report this to llvmbugs at cs.uiuc.edu ## configure: WARNING: ## ----------------------------------- ## checking for stdio.h... yes checking for unistd.h... (cached) no checking dl.h usability... no checking dl.h presence... no checking for dl.h... no checking sys/dl.h usability... no checking sys/dl.h presence... no checking for sys/dl.h... no checking dld.h usability... no checking dld.h presence... no checking for dld.h... no checking mach-o/dyld.h usability... no checking mach-o/dyld.h presence... no checking for mach-o/dyld.h... no checking for string.h... (cached) no checking for strings.h... (cached) no checking for strchr... yes checking for strrchr... yes checking for memcpy... yes checking for memmove... yes checking for strcmp... yes checking for closedir... yes checking for opendir... yes checking for readdir... yes checking for llvm-gcc.exe... no checking for llvm-g++.exe... no checking LLVM capable compiler... clang checking tool compatibility... ok checking optional compiler flags... -Wno-variadic-macros -Wno-missing-field-init ializers checking for sin in -lm... yes checking for library containing dlopen... none required checking for library containing mallinfo... none required checking for pthread_mutex_init in -lpthread... yes checking for library containing pthread_mutex_lock... none required checking for library containing pthread_rwlock_init... none required checking for library containing pthread_getspecific... none required checking for dirent.h that defines DIR... (cached) no checking for sys/ndir.h that defines DIR... (cached) no checking for sys/dir.h that defines DIR... (cached) no checking for ndir.h that defines DIR... (cached) no checking for library containing opendir... (cached) none required checking for MAP_ANONYMOUS vs. MAP_ANON... no checking whether stat file-mode macros are broken... no checking for ANSI C header files... (cached) no checking for sys/wait.h that is POSIX.1 compatible... no checking whether time.h and sys/time.h may both be included... no checking for dlfcn.h... (cached) yes checking execinfo.h usability... no checking execinfo.h presence... no checking for execinfo.h... no checking fcntl.h usability... no checking fcntl.h presence... yes configure: WARNING: fcntl.h: present but cannot be compiled configure: WARNING: fcntl.h: check for missing prerequisite headers? configure: WARNING: fcntl.h: see the Autoconf documentation configure: WARNING: fcntl.h: section "Present But Cannot Be Compiled" configure: WARNING: fcntl.h: proceeding with the preprocessor's result configure: WARNING: fcntl.h: in the future, the compiler will take precedence configure: WARNING: ## ----------------------------------- ## configure: WARNING: ## Report this to llvmbugs at cs.uiuc.edu ## configure: WARNING: ## ----------------------------------- ## checking for fcntl.h... yes checking for inttypes.h... (cached) no checking limits.h usability... no checking limits.h presence... yes configure: WARNING: limits.h: present but cannot be compiled configure: WARNING: limits.h: check for missing prerequisite headers? configure: WARNING: limits.h: see the Autoconf documentation configure: WARNING: limits.h: section "Present But Cannot Be Compiled" configure: WARNING: limits.h: proceeding with the preprocessor's result configure: WARNING: limits.h: in the future, the compiler will take precedence configure: WARNING: ## ----------------------------------- ## configure: WARNING: ## Report this to llvmbugs at cs.uiuc.edu ## configure: WARNING: ## ----------------------------------- ## checking for limits.h... yes checking link.h usability... no checking link.h presence... no checking for link.h... no checking for malloc.h... (cached) yes checking setjmp.h usability... no checking setjmp.h presence... yes configure: WARNING: setjmp.h: present but cannot be compiled configure: WARNING: setjmp.h: check for missing prerequisite headers? configure: WARNING: setjmp.h: see the Autoconf documentation configure: WARNING: setjmp.h: section "Present But Cannot Be Compiled" configure: WARNING: setjmp.h: proceeding with the preprocessor's result configure: WARNING: setjmp.h: in the future, the compiler will take precedence configure: WARNING: ## ----------------------------------- ## configure: WARNING: ## Report this to llvmbugs at cs.uiuc.edu ## configure: WARNING: ## ----------------------------------- ## checking for setjmp.h... yes checking signal.h usability... no checking signal.h presence... yes configure: WARNING: signal.h: present but cannot be compiled configure: WARNING: signal.h: check for missing prerequisite headers? configure: WARNING: signal.h: see the Autoconf documentation configure: WARNING: signal.h: section "Present But Cannot Be Compiled" configure: WARNING: signal.h: proceeding with the preprocessor's result configure: WARNING: signal.h: in the future, the compiler will take precedence configure: WARNING: ## ----------------------------------- ## configure: WARNING: ## Report this to llvmbugs at cs.uiuc.edu ## configure: WARNING: ## ----------------------------------- ## checking for signal.h... yes checking for stdint.h... (cached) no checking termios.h usability... no checking termios.h presence... yes configure: WARNING: termios.h: present but cannot be compiled configure: WARNING: termios.h: check for missing prerequisite headers? configure: WARNING: termios.h: see the Autoconf documentation configure: WARNING: termios.h: section "Present But Cannot Be Compiled" configure: WARNING: termios.h: proceeding with the preprocessor's result configure: WARNING: termios.h: in the future, the compiler will take precedence configure: WARNING: ## ----------------------------------- ## configure: WARNING: ## Report this to llvmbugs at cs.uiuc.edu ## configure: WARNING: ## ----------------------------------- ## checking for termios.h... yes checking for unistd.h... (cached) no checking utime.h usability... no checking utime.h presence... yes configure: WARNING: utime.h: present but cannot be compiled configure: WARNING: utime.h: check for missing prerequisite headers? configure: WARNING: utime.h: see the Autoconf documentation configure: WARNING: utime.h: section "Present But Cannot Be Compiled" configure: WARNING: utime.h: proceeding with the preprocessor's result configure: WARNING: utime.h: in the future, the compiler will take precedence configure: WARNING: ## ----------------------------------- ## configure: WARNING: ## Report this to llvmbugs at cs.uiuc.edu ## configure: WARNING: ## ----------------------------------- ## checking for utime.h... yes checking windows.h usability... no checking windows.h presence... no checking for windows.h... no checking sys/mman.h usability... no checking sys/mman.h presence... yes configure: WARNING: sys/mman.h: present but cannot be compiled configure: WARNING: sys/mman.h: check for missing prerequisite headers? configure: WARNING: sys/mman.h: see the Autoconf documentation configure: WARNING: sys/mman.h: section "Present But Cannot Be Compiled" configure: WARNING: sys/mman.h: proceeding with the preprocessor's result configure: WARNING: sys/mman.h: in the future, the compiler will take precedence configure: WARNING: ## ----------------------------------- ## configure: WARNING: ## Report this to llvmbugs at cs.uiuc.edu ## configure: WARNING: ## ----------------------------------- ## checking for sys/mman.h... yes checking sys/param.h usability... no checking sys/param.h presence... yes configure: WARNING: sys/param.h: present but cannot be compiled configure: WARNING: sys/param.h: check for missing prerequisite headers? configure: WARNING: sys/param.h: see the Autoconf documentation configure: WARNING: sys/param.h: section "Present But Cannot Be Compiled" configure: WARNING: sys/param.h: proceeding with the preprocessor's result configure: WARNING: sys/param.h: in the future, the compiler will take precedence configure: WARNING: ## ----------------------------------- ## configure: WARNING: ## Report this to llvmbugs at cs.uiuc.edu ## configure: WARNING: ## ----------------------------------- ## checking for sys/param.h... yes checking sys/resource.h usability... no checking sys/resource.h presence... yes configure: WARNING: sys/resource.h: present but cannot be compiled configure: WARNING: sys/resource.h: check for missing prerequisite headers? configure: WARNING: sys/resource.h: see the Autoconf documentation configure: WARNING: sys/resource.h: section "Present But Cannot Be Compiled" configure: WARNING: sys/resource.h: proceeding with the preprocessor's result configure: WARNING: sys/resource.h: in the future, the compiler will take precedence configure: WARNING: ## ----------------------------------- ## configure: WARNING: ## Report this to llvmbugs at cs.uiuc.edu ## configure: WARNING: ## ----------------------------------- ## checking for sys/resource.h... yes checking sys/time.h usability... no checking sys/time.h presence... yes configure: WARNING: sys/time.h: present but cannot be compiled configure: WARNING: sys/time.h: check for missing prerequisite headers? configure: WARNING: sys/time.h: see the Autoconf documentation configure: WARNING: sys/time.h: section "Present But Cannot Be Compiled" configure: WARNING: sys/time.h: proceeding with the preprocessor's result configure: WARNING: sys/time.h: in the future, the compiler will take precedence configure: WARNING: ## ----------------------------------- ## configure: WARNING: ## Report this to llvmbugs at cs.uiuc.edu ## configure: WARNING: ## ----------------------------------- ## checking for sys/time.h... yes checking for sys/types.h... (cached) no checking sys/ioctl.h usability... no checking sys/ioctl.h presence... yes configure: WARNING: sys/ioctl.h: present but cannot be compiled configure: WARNING: sys/ioctl.h: check for missing prerequisite headers? configure: WARNING: sys/ioctl.h: see the Autoconf documentation configure: WARNING: sys/ioctl.h: section "Present But Cannot Be Compiled" configure: WARNING: sys/ioctl.h: proceeding with the preprocessor's result configure: WARNING: sys/ioctl.h: in the future, the compiler will take precedence configure: WARNING: ## ----------------------------------- ## configure: WARNING: ## Report this to llvmbugs at cs.uiuc.edu ## configure: WARNING: ## ----------------------------------- ## checking for sys/ioctl.h... yes checking malloc/malloc.h usability... no checking malloc/malloc.h presence... no checking for malloc/malloc.h... no checking mach/mach.h usability... no checking mach/mach.h presence... no checking for mach/mach.h... no checking valgrind/valgrind.h usability... no checking valgrind/valgrind.h presence... no checking for valgrind/valgrind.h... no checking pthread.h usability... no checking pthread.h presence... yes configure: WARNING: pthread.h: present but cannot be compiled configure: WARNING: pthread.h: check for missing prerequisite headers? configure: WARNING: pthread.h: see the Autoconf documentation configure: WARNING: pthread.h: section "Present But Cannot Be Compiled" configure: WARNING: pthread.h: proceeding with the preprocessor's result configure: WARNING: pthread.h: in the future, the compiler will take precedence configure: WARNING: ## ----------------------------------- ## configure: WARNING: ## Report this to llvmbugs at cs.uiuc.edu ## configure: WARNING: ## ----------------------------------- ## checking for pthread.h... yes The error :- checking for int64_t... no configure: error: Type int64_t required but not found -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100420/84ad5b2e/attachment-0001.html From lattner at apple.com Tue Apr 20 13:12:02 2010 From: lattner at apple.com (Tanya Lattner) Date: Tue, 20 Apr 2010 11:12:02 -0700 Subject: [cfe-dev] 2.7 Pre-Release2 Available! Message-ID: <533CF441-0FA5-4961-80E4-9299F97B562B@apple.com> The 2.7 pre-release2 is available for testing: http://llvm.org/pre-releases/2.7/pre-release2/ Please complete all testing by April 23rd EOD. We are shortening this testing period a bit to get the release out soon since its been delayed so far. The release team has done our qualifications and we think its of high quality and ready to go. As this is the last pre-release, we only accept fixes for absolutely critical bugs as defined by our release criteria: http://llvm.org/docs/HowToReleaseLLVM.html#release-qualify If you are able to test this pre-release, we ask that you try the following: To test llvm-gcc: 1) Compile llvm from source and untar the llvm-test in the projects directory (name it llvm-test or test-suite). Choose to use a pre-compiled llvm-gcc or re-compile it yourself. 2) Run make check, report any failures (FAIL or unexpected pass). Note that you need to reconfigure llvm with llvm-gcc in your path or with --with-llvmgccdir 3) Run "make TEST=nightly report" and compare your results with 2.6 if possible. To test clang: 1) Compile llvm and clang from source. 2) Run make check for llvm. 3) Run make -C tools/clang-2.6 test VERBOSE=1 (report any failures or unexpected passes) 4) Reconfigure llvm-test/llvm to use clang to run the test-suite (make TEST=nightly report) and compare the results with 2.6 if possible. If you think you have found a release blocker, please file a bug and have it block this bug: http://llvm.org/bugs/show_bug.cgi?id=6586 We also ask that you try clang or llvm-gcc on various applications. Please note that any bugs found will be fixed in TOT, but not in the release. Thanks! -Tanya -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100420/28cd17ff/attachment.html From herrold at owlriver.com Tue Apr 20 13:14:15 2010 From: herrold at owlriver.com (R P Herrold) Date: Tue, 20 Apr 2010 14:14:15 -0400 (EDT) Subject: [cfe-dev] self-hosting build problem with a build from yesterday's CO and todays revision 101919 Message-ID: Trying to rebuild clang (revision 101919) with a clang from a CO on 20100419, I get: ... === configuring in projects/sample (/home/herrold/rpmbuild/BUILD/clang-20100420/projects/sample) configure: running /bin/sh ./configure --prefix=/usr '--libexecdir=/usr/bin' '--libdir=/usr/lib64' '--enable-targets=host,x86,x86_64,cpp' '--without-ocaml' '--enable-optimized' '--enable-debug-runtime' '--enable-doxygen' '--disable-static' '--with-gnu-ld' '--enable-bindings=none' 'CC=/usr/bin/clang' 'CFLAGS=-g0 -O2 -pipe ' 'CPPFLAGS=-I/usr/include/c++/4.1.1/x86_64-redhat-linux/ ' 'CXX=/usr/bin/clang++' --cache-file=/dev/null --srcdir=. configure: creating ./config.status config.status: creating Makefile.common config.status: executing setup commands config.status: executing Makefile commands config.status: executing lib/Makefile commands config.status: executing lib/sample/Makefile commands config.status: executing tools/Makefile commands config.status: executing tools/sample/Makefile commands + make DESTDIR=/var/tmp/clang-0.0.20100420.cvs.root prefix=/usr libdir=/usr/lib64 make[1]: Entering directory `/home/herrold/rpmbuild/BUILD/clang-20100420/lib/System' llvm[1]: Compiling Alarm.cpp for Release build llvm[1]: Compiling Atomic.cpp for Release build In file included from Atomic.cpp:14: In file included from /home/herrold/rpmbuild/BUILD/clang-20100420/include/llvm/System/Atomic.h:17: In file included from /home/herrold/rpmbuild/BUILD/clang-20100420/include/llvm/System/DataTypes.h:35: /usr/include/c++/4.1.2/cmath:49:10: fatal error: 'bits/c++config.h' file not found #include ^ 1 error generated. make[1]: *** [/home/herrold/rpmbuild/BUILD/clang-20100420/lib/System/Release/Atomic.o] Error 1 make[1]: Leaving directory `/home/herrold/rpmbuild/BUILD/clang-20100420/lib/System' make: *** [all] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.88449 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.88449 (%build) real 3m9.395s user 0m4.940s sys 0m6.476s =============================================================== CO level: Checked out revision 101919. clang version: clang-0.0.20100419.cvs-1orc arch: x86_64 Linux centos-5.first.lan 2.6.18-164.11.1.el5xen #1 SMP Wed Jan 20 08:06:04 EST 2010 x86_64 x86_64 x86_64 GNU/Linux [herrold at centos-5 clang]$ ------------------------------------- The addition to the include path points to the only path I can see on my box with a 'bits/c++config.h' The fault is reproduceable, and I can file a bug, if helpful. -- Russ herrold From john.thompson.jtsoftware at gmail.com Tue Apr 20 14:45:35 2010 From: john.thompson.jtsoftware at gmail.com (John Thompson) Date: Tue, 20 Apr 2010 12:45:35 -0700 Subject: [cfe-dev] Casting scalars to vectors In-Reply-To: <-4709689112681150107@unknownmsgid> References: <-4709689112681150107@unknownmsgid> Message-ID: Anton, Clang was generating an error on vector initializers, when all the vector slots are not provided, i.e.: vector unsigned int v = (vector unsigned int)(vector int)(-1); Instead of: vector unsigned int v = (vector unsigned int)(vector int)(-1, -1, -1, -1); I'm seeing these kinds of statements in some headers in the PS3 sdk, which gcc allows. I've checked in a fix and revised the altivec tests. (Sorry I missed a test last night, and broke the build.) I have a question, though (for Anton or anyone). What will the initializers be for the unspecified slots? Will they be 0? What does gcc do? -John On Tue, Apr 20, 2010 at 2:34 AM, Anton Lokhmotov wrote: > > This stops the error, but is it enough? > > Sorry, I couldn't understand from the thread what was the error? > > > - if (SemaRef.getLangOptions().OpenCL || > SemaRef.getLangOptions().AltiVec) > > + if (SemaRef.getLangOptions().OpenCL) > > In other words, it's something that's not required for AltiVec but is > required for OpenCL? > > Cheers, > Anton. > > > -- John Thompson John.Thompson.JTSoftware at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100420/49b38ed6/attachment.html From clattner at apple.com Tue Apr 20 16:39:24 2010 From: clattner at apple.com (Chris Lattner) Date: Tue, 20 Apr 2010 14:39:24 -0700 Subject: [cfe-dev] clang and -integrated-as In-Reply-To: References: <4266BF60-378F-4732-A327-BCB7635A201F@apple.com> <4571CDCD-D091-4C4F-BE74-89D3344DBE09@shadowlab.org> Message-ID: On Apr 17, 2010, at 12:49 PM, Jean-Daniel Dupas wrote: >>> It was a known issue, we just didn't get around to addressing it. Fixed in r101660, thanks for nudging us! >> >> Thanks for the quick fix :-) > > Unfortunately, it does not works as expected. It uncovers an other blocking bug :-( > The assembler generates an undefined symbol instead of generating an absolute symbol for classes, and so, in my test project, it now fails at linking time. > > ================= > @interface Foo { void *isa; } > @end > @implementation Foo > @end > ================= > > % clang -arch i386 -c test.m > % nm -m test.o > 00000000 (absolute) external .objc_class_name_Foo > > % clang -arch i386 -c test.m -integrated-as > % nm -m test.o > (undefined) external .objc_class_name_Foo This is definitely a bug. I filed it internally to track it, Daniel will take a look when he has a chance. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100420/bfc581d8/attachment.html From john.thompson.jtsoftware at gmail.com Tue Apr 20 18:30:15 2010 From: john.thompson.jtsoftware at gmail.com (John Thompson) Date: Tue, 20 Apr 2010 16:30:15 -0700 Subject: [cfe-dev] Casting scalars to vectors In-Reply-To: References: <-4709689112681150107@unknownmsgid> Message-ID: I've run into a problem with vector literal/casting confusion: vector float v = (vector float)((vector unsigned int)(0x49800000)); vecinit1.cpp:1:33: error: cannot initialize a vector element of type 'float' with an lvalue of type '__vector unsigned int' vector float v = (vector float)((vector unsigned int)(0x49800000)); It appears to be treating the outer paren expression as a vector literal instead of a cast. I'm looking into to it, but if someone knows a quick fix already... -John On Tue, Apr 20, 2010 at 12:45 PM, John Thompson < john.thompson.jtsoftware at gmail.com> wrote: > Anton, > > Clang was generating an error on vector initializers, when all the vector > slots are not provided, i.e.: > > vector unsigned int v = (vector unsigned int)(vector int)(-1); > > Instead of: > > vector unsigned int v = (vector unsigned int)(vector int)(-1, -1, -1, -1); > > I'm seeing these kinds of statements in some headers in the PS3 sdk, which > gcc allows. > > I've checked in a fix and revised the altivec tests. (Sorry I missed a > test last night, and broke the build.) > > I have a question, though (for Anton or anyone). What will the > initializers be for the unspecified slots? Will they be 0? What does gcc > do? > > -John > On Tue, Apr 20, 2010 at 2:34 AM, Anton Lokhmotov < > Anton.Lokhmotov at arm.com> wrote: > >> > This stops the error, but is it enough? >> >> Sorry, I couldn't understand from the thread what was the error? >> >> > - if (SemaRef.getLangOptions().OpenCL || >> SemaRef.getLangOptions().AltiVec) >> > + if (SemaRef.getLangOptions().OpenCL) >> >> In other words, it's something that's not required for AltiVec but is >> required for OpenCL? >> >> Cheers, >> Anton. >> >> >> > > > -- > John Thompson > John.Thompson.JTSoftware at gmail.com > > -- John Thompson John.Thompson.JTSoftware at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100420/9d47e30e/attachment-0001.html From dgregor at apple.com Wed Apr 21 00:47:52 2010 From: dgregor at apple.com (Douglas Gregor) Date: Tue, 20 Apr 2010 22:47:52 -0700 Subject: [cfe-dev] Clang 2.7 and C++ support In-Reply-To: <4BCD5F8E.608@dps.uibk.ac.at> References: <4BCD51D3.20105@dps.uibk.ac.at> <4BCD5F8E.608@dps.uibk.ac.at> Message-ID: <89DAFE22-D079-4F4D-B98E-A4D02F617AC0@apple.com> On Apr 20, 2010, at 1:02 AM, Simone Pellegrini wrote: > On 04/20/2010 09:25 AM, Douglas Gregor wrote: >> >> On Apr 20, 2010, at 12:03 AM, Simone Pellegrini wrote: >> >> >>> Hi all, >>> I was wondering if C++ support will be enabled by default in this >>> release or we would have to wait the next release (2.8). >>> >>> and if not, is there any way to enable it? >>> >> C++ support is enabled by default in 2.7. >> > What I am doing is using clang as a library so I cannot use the clang driver directly. > > I manually instantiate a CompilerInstance and feed C++ code and get the following error: > > error: unknown type name 'class' > > I also tried to feed the "-ccc-clang-cxx" flag as suggested in: http://clang.llvm.org/docs/UsersManual.html#cxx > but it didn't help. > > The actual code I use to instantiate a compiler is the following: > > CompilerInstance Clang; > Clang.setLLVMContext(new llvm::LLVMContext); > Clang.createDiagnostics(argc, argv); > > Clang.setFileManager(&FileMgr); > Clang.createSourceManager(); > > Clang.InitializeSourceManager(File->getName()); > > // Add the default clang system headers > Clang.getHeaderSearchOpts().AddPath( "/software/llvm-2.7/lib/clang/1.1/include/", clang::frontend::System, true, false ); > // add user headers > for (size_t i = 0; i < Flags::I_dirs.size(); ++i) > Clang.getHeaderSearchOpts().AddPath( Flags::I_dirs[i], clang::frontend::Angled, true, false); > > TargetOptions TO; > TO.Triple = llvm::Triple("x86_64", "PC", "Linux").getTriple(); > Clang.setTarget( TargetInfo::CreateTargetInfo (Clang.getDiagnostics(), TO) ); > > // A compiler invocation object has to be created in order for the diagnostics to work > CompilerInvocation* CI = new CompilerInvocation; // CompilerInvocation will be deleted by CompilerInstance > > const char* arg = "ccc-clang-cxx"; > CompilerInvocation::CreateFromArgs(*CI, &arg, &arg+1, Clang.getDiagnostics()); > Clang.setInvocation(CI); > > Clang.createPreprocessor(); > Clang.createASTContext(); > > ... > > what am I doing wrong? The code works perfectly for C programs!! I don't see where you're setting the LangOption bit that tells it to compile C++ code. - Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100420/5c9c3574/attachment.html From zaffanella at cs.unipr.it Wed Apr 21 14:20:05 2010 From: zaffanella at cs.unipr.it (Enea Zaffanella) Date: Wed, 21 Apr 2010 21:20:05 +0200 Subject: [cfe-dev] Template parameters for out-of-line definitions of class template methods. Message-ID: <4BCF4FE5.8010805@cs.unipr.it> Hello. We have a somewhat naive question regarding the AST generated for the following program fragment: ====================================== template struct S { void foo(); }; template void S::foo() {} ====================================== We would like to retrieve the template parameter list for the out-of-line definition of method foo(), that is template but we cannot see if and how this could be achieved. Apparently, clang++ produces a plain CXXMethodDecl, with no explicit indication that this is actually a "member function template" (C++98 14.5.1.1). Are we missing some existing clang methods that allow to retrieve this info or is it really missing? In the latter case, is there any plan to add this info to the generated AST? The same question can be asked for the case of an out-of-line definition of a static data member (which generates a VarDecl node) and of a member class (generating a plain CXXRecordDecl). Cheers, Enea Zaffanella. From john.thompson.jtsoftware at gmail.com Wed Apr 21 17:35:36 2010 From: john.thompson.jtsoftware at gmail.com (John Thompson) Date: Wed, 21 Apr 2010 15:35:36 -0700 Subject: [cfe-dev] asserts Message-ID: I'm getting a couple of asserts, one from the assert in Sema::ActOnNumericConstant at line 1897, the other in a separate case in the APInt::trunc call because the argument is bigger than the width. These two changes seem to avoid the asserts, I'm not sure it's the right fix: Index: lib/Sema/SemaExpr.cpp =================================================================== --- lib/Sema/SemaExpr.cpp (revision 102026) +++ lib/Sema/SemaExpr.cpp (working copy) @@ -1885,7 +1885,10 @@ Diag(Tok.getLocation(), diag::ext_longlong); // Get the value in the widest-possible width. - llvm::APInt ResultVal(Context.Target.getIntMaxTWidth(), 0); + llvm::APInt ResultVal( + Literal.isLongLong ? + Context.Target.getLongLongWidth() : + Context.Target.getIntMaxTWidth(), 0); if (Literal.GetIntegerValue(ResultVal)) { // If this value didn't fit into uintmax_t, warn and force to ull. @@ -1956,8 +1959,12 @@ Width = Context.Target.getLongLongWidth(); } - if (ResultVal.getBitWidth() != Width) - ResultVal.trunc(Width); + if (ResultVal.getBitWidth() != Width) { + if (Literal.isUnsigned) + ResultVal.zextOrTrunc(Width); + else + ResultVal.sextOrTrunc(Width); + } } Res = new (Context) IntegerLiteral(ResultVal, Ty, Tok.getLocation()); } -- John Thompson John.Thompson.JTSoftware at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100421/72d006eb/attachment.html From michael.g.miller at gmail.com Wed Apr 21 19:48:02 2010 From: michael.g.miller at gmail.com (Mike Miller) Date: Wed, 21 Apr 2010 19:48:02 -0500 Subject: [cfe-dev] Maintaining a consistant path across two clang instances Message-ID: Hi cfe-dev, I'm working on a distributed compiler project using clang(see herefor more information). One issue I am coming across is that the "master" must have the same working directory as the client it is preprocessing for, so that relative paths resolve correctly. My first intuition was to send the output of getcwd on the slave to the master, and use chdir on the master to set the appropriate working directory, before invoking the preprocessor. However, this brings to mind two concerns: 1. The cache in the FileManager might get confused(e.g. it might cache /u/mike/dir1/test/test.c while /u/mike/dir1 is the cwd, and attempt to access /u/mike/dir2/test/test.c while the cwd is /u/mike/dir2). 2. Since setting the cwd would affect the whole process, it would not be possible to preprocess multiple files simultaneously with different threads. Are these two concerns valid? If so, how would you recommend resolving them? Additionally, I have two more questions: 1. Is the preprocessor threadsafe? Specifically, I want to know if I can invoke multiple, completely disjoint preprocessors on different threads, without negative consequence. 2. Is the FileManager threadsafe? Specifically, I want to know if I can invoke multiple preprocessors using the same FileManager without negative consequence. If not, would you imagine it to be better to have a single preprocessor with a very large cache, or multiple preprocessors running in parallel with separate, disjoint, but smaller caches? Thanks! Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100421/e51b34d3/attachment.html From zaffanella at cs.unipr.it Thu Apr 22 03:34:48 2010 From: zaffanella at cs.unipr.it (Enea Zaffanella) Date: Thu, 22 Apr 2010 10:34:48 +0200 Subject: [cfe-dev] Missing NNS qualification in ElaboratedType. Message-ID: <4BD00A28.8070704@cs.unipr.it> Hello. In the generated AST for the following program fragment: /*==========================*/ namespace N { struct S {}; } N::S s1; struct N::S s2; /*==========================*/ the global variable 's1' has QualifiedNameType (as expected). In contrast, the global variable 's2' has ElaboratedType (good, so far) that contains a plain CXXRecordType (bad, the NNS qualification is missing). The attached simple patch fixes this problem by making sure that the ElaboratedType will contain a QualifiedNameType. The patch also changes the expected output of a single test, since the generated diagnostic now contains a NNS qualification. Cheers, Enea Zaffanella. -------------- next part -------------- A non-text attachment was scrubbed... Name: Elaborated_Qualified.patch Type: text/x-patch Size: 1110 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100422/9a96984d/attachment.bin From ponnala.kalyan at gmail.com Thu Apr 22 04:29:55 2010 From: ponnala.kalyan at gmail.com (kalyan ponnala) Date: Thu, 22 Apr 2010 05:29:55 -0400 Subject: [cfe-dev] Attaching Metadata to BasicBlocks Message-ID: Hello, I was researching how Metadata in LLVM 2.7 is represented and used and I found that Metadata can be attached and manipulated at both the module level and instruction levels. Upon inspecting the Metadata classes, I also saw that there is an enum that contains a bit for "FunctionLocalBit" on the MDNode. Unfortunately, I did not see any methods to attach or manipulate Metadata at the BasicBlock level or Function levels in the LLVM IR classes. Can someone please tell me why there is no support for attaching and manipulating Metadata to BasicBlocks and Functions? Thanks a lot. -- Kalyan Ponnala phone: 8163772059 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100422/33c3e1df/attachment.html From dgregor at apple.com Thu Apr 22 09:11:01 2010 From: dgregor at apple.com (Douglas Gregor) Date: Thu, 22 Apr 2010 07:11:01 -0700 Subject: [cfe-dev] Template parameters for out-of-line definitions of class template methods. In-Reply-To: <4BCF4FE5.8010805@cs.unipr.it> References: <4BCF4FE5.8010805@cs.unipr.it> Message-ID: <910088CD-9C49-4E46-937C-C919861FA5E7@apple.com> On Apr 21, 2010, at 12:20 PM, Enea Zaffanella wrote: > Hello. > > We have a somewhat naive question regarding the AST generated for the > following program fragment: > ====================================== > template > struct S { > void foo(); > }; > > template > void S::foo() {} > ====================================== > > We would like to retrieve the template parameter list for the > out-of-line definition of method foo(), that is > template > but we cannot see if and how this could be achieved. Clang's AST doesn't actually store the template parameter list that was used in the out-of-line definition. It should. > Apparently, clang++ produces a plain CXXMethodDecl, with no explicit > indication that this is actually a "member function template" (C++98 > 14.5.1.1). Technically, it's a member function of a class template. > Are we missing some existing clang methods that allow to retrieve this > info or is it really missing? In the latter case, is there any plan to > add this info to the generated AST? It is missing, and we will add this info to the generated AST at some point. > The same question can be asked for the case of an out-of-line definition > of a static data member (which generates a VarDecl node) and of a member > class (generating a plain CXXRecordDecl). Right, this is the same kind of issue. We're missing this information for out-of-line definitions of everything. - Doug From dgregor at apple.com Thu Apr 22 09:18:03 2010 From: dgregor at apple.com (Douglas Gregor) Date: Thu, 22 Apr 2010 07:18:03 -0700 Subject: [cfe-dev] Maintaining a consistant path across two clang instances In-Reply-To: References: Message-ID: <28D524A8-5201-4E95-97DC-93771B6A4046@apple.com> On Apr 21, 2010, at 5:48 PM, Mike Miller wrote: > Hi cfe-dev, > > I'm working on a distributed compiler project using clang(see here for more information). One issue I am coming across is that the "master" must have the same working directory as the client it is preprocessing for, so that relative paths resolve correctly. My first intuition was to send the output of getcwd on the slave to the master, and use chdir on the master to set the appropriate working directory, before invoking the preprocessor. However, this brings to mind two concerns: > > 1. The cache in the FileManager might get confused(e.g. it might cache /u/mike/dir1/test/test.c while /u/mike/dir1 is the cwd, and attempt to access /u/mike/dir2/test/test.c while the cwd is /u/mike/dir2). > > 2. Since setting the cwd would affect the whole process, it would not be possible to preprocess multiple files simultaneously with different threads. > > Are these two concerns valid? If so, how would you recommend resolving them? The preprocessor should not depend on the actually current working directory; the working directory should be queried once (in the driver) and provided to clang -cc1 via a command-line parameter, which the header search will used as its working directory for searches. > Additionally, I have two more questions: > > 1. Is the preprocessor threadsafe? No. > Specifically, I want to know if I can invoke multiple, completely disjoint preprocessors on different threads, without negative consequence. You can use completely disjoint preprocessors concurrently. > 2. Is the FileManager threadsafe? No. > Specifically, I want to know if I can invoke multiple preprocessors using the same FileManager without negative consequence. No, FileManager isn't prepared for this. > If not, would you imagine it to be better to have a single preprocessor with a very large cache, or multiple preprocessors running in parallel with separate, disjoint, but smaller caches? I would *guess* that having only a single preprocessor would be best, but since the point of this project is to improve performance, you'll have to measure it. - Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100422/000f997e/attachment-0001.html From dgregor at apple.com Thu Apr 22 09:25:37 2010 From: dgregor at apple.com (Douglas Gregor) Date: Thu, 22 Apr 2010 07:25:37 -0700 Subject: [cfe-dev] Missing NNS qualification in ElaboratedType. In-Reply-To: <4BD00A28.8070704@cs.unipr.it> References: <4BD00A28.8070704@cs.unipr.it> Message-ID: <1155633F-58BA-405F-B45D-7FC1D0506DA5@apple.com> On Apr 22, 2010, at 1:34 AM, Enea Zaffanella wrote: > Hello. > > In the generated AST for the following program fragment: > /*==========================*/ > namespace N { > struct S {}; > } > > N::S s1; > struct N::S s2; > /*==========================*/ > > the global variable 's1' has QualifiedNameType (as expected). > In contrast, the global variable 's2' has ElaboratedType (good, so far) that contains a plain CXXRecordType (bad, the NNS qualification is missing). > > The attached simple patch fixes this problem by making sure that the ElaboratedType will contain a QualifiedNameType. The patch also changes the expected output of a single test, since the generated diagnostic now contains a NNS qualification. Good catch, thanks! Committed as r102065. - Doug From devlists at shadowlab.org Thu Apr 22 11:08:06 2010 From: devlists at shadowlab.org (Jean-Daniel Dupas) Date: Thu, 22 Apr 2010 18:08:06 +0200 Subject: [cfe-dev] [Obj-C]method lookup for invalid receiver Message-ID: <57948E04-937F-4682-AFA1-AD1ADA967C4A@shadowlab.org> Hello, I see that when trying to send a message to a non object receiver (not type id but compatible type like void *), clang interprets the receiver as an 'id', but it does not lookup the selector in the global selector pool like it does for 'id' receiver. It makes clang unable to compile code that GCC accepts: ---------------------------------------------------------------------- @interface NSNumber {} - (long)integerValue; @end float test(void *receiver) { return [receiver integerValue]; } ---------------------------------------------------------------------- Of course, I agree that code relying on this must be fixed, but this is true for a bunch of other warnings ;-) So, if this is not a design choice, I attach a patch that change the behavior to lookup selector when the receiver is not an object (and fixes tests that rely on the old behavior). -------------- next part -------------- A non-text attachment was scrubbed... Name: lookup.patch Type: application/octet-stream Size: 3852 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100422/170c8ef4/attachment.obj -------------- next part -------------- Regards -- Jean-Daniel From csdavec at swan.ac.uk Thu Apr 22 11:32:22 2010 From: csdavec at swan.ac.uk (David Chisnall) Date: Thu, 22 Apr 2010 17:32:22 +0100 Subject: [cfe-dev] [Obj-C]method lookup for invalid receiver In-Reply-To: <57948E04-937F-4682-AFA1-AD1ADA967C4A@shadowlab.org> References: <57948E04-937F-4682-AFA1-AD1ADA967C4A@shadowlab.org> Message-ID: <6A53E69A-40A2-4787-87E1-2DE559B556F2@swan.ac.uk> On 22 Apr 2010, at 17:08, Jean-Daniel Dupas wrote: > Hello, > > I see that when trying to send a message to a non object receiver (not type id but compatible type like void *), clang interprets the receiver as an 'id', but it does not lookup the selector in the global selector pool like it does for 'id' receiver. This sounds like exactly the opposite of what it should be doing. I don't think we should be allowing non-object types to be message receivers, even if GCC does (a few issues with struct objc_object* and struct objc_class* aside). If people need to do this, they should use an explicit cast. > Of course, I agree that code relying on this must be fixed, but this is true for a bunch of other warnings ;-) > > So, if this is not a design choice, I attach a patch that change the behavior to lookup selector when the receiver is not an object (and fixes tests that rely on the old behavior). The second part here is something that should be fixed. GCC says 'this object doesn't advertise understanding this message, so I will assume that this is an oversight' while clang says 'this object doesn't advertise understanding this message, so I will generate a stack frame with a random layout - have fun debugging!' For example, this snippet: @interface A - (void)foo: (float)a; @end @interface B @end @implementation B - (void)bar { [self foo: 0]; } - (void)foo: (float)a {} @end The message send in this example has i32 0 as its last argument. The receiver, in contrast, expects a float, so the stack layout will be wrong. You should get a warning that B might not respond to -foo:, but you should then get the correct stack layout because there is only one -foo: method defined. A very common case for this warning is when someone forgets to include NSObject in a protocol list, for example specifying something as id when they mean either NSObject*, id, or for Foo to conform to the NSObject protocol. Sending -retain or -release messages to an id will tell you that the -retain and -release messages don't exist - which is clearly wrong. (Aside: this would be a really useful thing for the fixit magic to do; suggest that you add the NSObject protocol if you send messages from this protocol to a qualified id that does not conform to it) It would also be worth warning when you define two methods with the same name and different type signatures, because any message send to an id will pick one of these and you may get some fun stack corruption (this is more of an issue on Darwin; the GNU runtime, at least in theory, can recover from this gracefully, the Mac runtimes can't). David -- Sent from my IBM 1620 -- Send from my Jacquard Loom From clattner at apple.com Thu Apr 22 11:44:54 2010 From: clattner at apple.com (Chris Lattner) Date: Thu, 22 Apr 2010 09:44:54 -0700 Subject: [cfe-dev] Attaching Metadata to BasicBlocks In-Reply-To: References: Message-ID: <16D0960D-A60F-4CE4-A765-A6BC145966F1@apple.com> On Apr 22, 2010, at 2:29 AM, kalyan ponnala wrote: > > Hello, > > I was researching how Metadata in LLVM 2.7 is represented and used and I found that Metadata can be attached and manipulated at both the module level and instruction levels. Upon inspecting the Metadata classes, I also saw that there is an enum that contains a bit for "FunctionLocalBit" on the MDNode. > > Unfortunately, I did not see any methods to attach or manipulate Metadata at the BasicBlock level or Function levels in the LLVM IR classes. > > Can someone please tell me why there is no support for attaching and manipulating Metadata to BasicBlocks and Functions? Just because no one has needed it yet. I'm not opposed to it being added it if you have a compelling client for it. -Chris From r.amadini at virgilio.it Thu Apr 22 14:30:18 2010 From: r.amadini at virgilio.it (Roberto Amadini) Date: Thu, 22 Apr 2010 21:30:18 +0200 Subject: [cfe-dev] Patch proposal for __builtin_offsetof construct. In-Reply-To: <41C8B229-2FAD-4F34-B024-E481F07C7B50@apple.com> References: <4BC83D56.4050106@virgilio.it> <41C8B229-2FAD-4F34-B024-E481F07C7B50@apple.com> Message-ID: <4BD0A3CA.2050904@virgilio.it> Douglas Gregor ha scritto: > On Apr 16, 2010, at 3:35 AM, Roberto Amadini wrote: > > >> Hi, >> >> I'm the student who is trying to fix the problem mentioned in >> http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-February/007833.html . >> [...] >> Index: include/clang/AST/Expr.h >> =================================================================== >> --- include/clang/AST/Expr.h (revisione 100962) >> +++ include/clang/AST/Expr.h (copia locale) >> @@ -991,6 +985,78 @@ >> [...] >> +public: >> + // __builtin_offsetof(type, identifier(.identifier|[expr])*) >> + // FIXME: Type-dependent case ignored. >> + struct OffsetOfNode { >> + SourceLocation LocStart, LocEnd; >> + bool isBrackets; // true if [expr], false if .ident >> + union { >> + FieldDecl *MemberDecl; >> + Expr *IndexExpr; >> + } U; >> + }; >> > > You could save a word of storage per OffsetOfNode by mangling the "isBrackets" bit into the lowest bit of the FieldDecl or Expr pointer. llvm::PointerUnion will do this for you. > > But, see below for more comments on this representation. > In Order to have Expr*'s in contiguous memory, I replaced *IndexExpr field with an unsigned integer ExprIndex, which represents the index of the corresponding Expr* in the array of subscript expressions: in this way, I can't use a PointerUnion, or not? >> Index: lib/AST/StmtProfile.cpp >> =================================================================== >> --- lib/AST/StmtProfile.cpp (revisione 100962) >> +++ lib/AST/StmtProfile.cpp (copia locale) >> @@ -261,6 +261,10 @@ >> ID.AddInteger(S->getOpcode()); >> } >> >> +void StmtProfiler::VisitOffsetOfExpr(OffsetOfExpr *S) { >> + VisitExpr(S); >> +} >> + >> > > To profile an OffsetOfExpr, we'll need to visit the type and all of the OffsetOfNodes as well. That way, we can distinguish between different OffsetOfExprs on the same base type. > > Ok, but I have a doubt: VisitExpr(S) visits recursively all the sub-expressions, thus I think that I haven't to explicitly visit such expressions while I'm iterating on OffsetOfNodes array for declarations visit... Or not? > Overall, this is a great start on __builtin_offsetof, thanks! I look forward to seeing a revised patch. > > - Doug > Thanks for your comments! I tried to follow your advices... I attached a new patch which refers to revision no. 102050. Regards, Roberto. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: OffsetOfExpr0422.patch Url: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100422/92105b9a/attachment-0001.pl From ponnala.kalyan at gmail.com Fri Apr 23 02:13:39 2010 From: ponnala.kalyan at gmail.com (kalyan ponnala) Date: Fri, 23 Apr 2010 03:13:39 -0400 Subject: [cfe-dev] Attaching Metadata to BasicBlocks In-Reply-To: <16D0960D-A60F-4CE4-A765-A6BC145966F1@apple.com> References: <16D0960D-A60F-4CE4-A765-A6BC145966F1@apple.com> Message-ID: Thanks for the reply Chris, I would like to add Metadata to a loop. To do this, can I simply add the Metadata Manipulation methods & Metadata private data from Instruction.h & their method bodies from Metadata.cpp into the BasicBlock.h & BasicBlock.cpp files.? Or Am I missing an important dependency. Thanks, Kalyan the great (even greater than Chris Latner) On Thu, Apr 22, 2010 at 12:44 PM, Chris Lattner wrote: > > On Apr 22, 2010, at 2:29 AM, kalyan ponnala wrote: > > > > > Hello, > > > > I was researching how Metadata in LLVM 2.7 is represented and used and I > found that Metadata can be attached and manipulated at both the module level > and instruction levels. Upon inspecting the Metadata classes, I also saw > that there is an enum that contains a bit for "FunctionLocalBit" on the > MDNode. > > > > Unfortunately, I did not see any methods to attach or manipulate Metadata > at the BasicBlock level or Function levels in the LLVM IR classes. > > > > Can someone please tell me why there is no support for attaching and > manipulating Metadata to BasicBlocks and Functions? > > Just because no one has needed it yet. I'm not opposed to it being added > it if you have a compelling client for it. > > -Chris > -- Kalyan Ponnala phone: 8163772059 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100423/458b5a8e/attachment.html From mark.lacey at intel.com Thu Apr 15 16:27:28 2010 From: mark.lacey at intel.com (Lacey, Mark) Date: Thu, 15 Apr 2010 14:27:28 -0700 Subject: [cfe-dev] [LLVMdev] Living on Clang In-Reply-To: <4229484F-BA99-41CD-B4DD-A6A31AB522DA@apple.com> References: <4229484F-BA99-41CD-B4DD-A6A31AB522DA@apple.com> Message-ID: <0D4616E6925F9541919B60692F61509E5A3A3047@orsmsx502.amr.corp.intel.com> > We want to make Clang great, and we need your help! Doug, I don't see any type of selfbuild target in the LLVM top level makefile. This would be a useful way to automate the self build process. I've used similar mechanisms before on other compilers, where you can trivially invoke a three phase build (first you do a full build with your system compiler, then you use your built compiler to do another full build, and then take that most recent build compiler to build yet again...). The build options of the last two phases are identical, and the object files from those last two passes are compared to ensure that they are identical. Ideally you can control the build options of the initial build and last two builds independently (e.g. build a compiler without optimizations and with assertions, and then do the last two builds with assertions disabled, and optimizations on) - I'm not sure how easy this is with the autoconfig based system LLVM/clang use, if at all. Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 8614 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100415/9ef6e874/attachment.bin From clattner at apple.com Fri Apr 23 10:30:08 2010 From: clattner at apple.com (Chris Lattner) Date: Fri, 23 Apr 2010 08:30:08 -0700 Subject: [cfe-dev] Attaching Metadata to BasicBlocks In-Reply-To: References: <16D0960D-A60F-4CE4-A765-A6BC145966F1@apple.com> Message-ID: <672F91CC-6C13-46D5-914B-C83E8688F8BE@apple.com> On Apr 23, 2010, at 12:13 AM, kalyan ponnala wrote: > Thanks for the reply Chris, > > I would like to add Metadata to a loop. > > To do this, can I simply add the Metadata Manipulation methods & Metadata private data from Instruction.h & their method bodies from Metadata.cpp into the BasicBlock.h & BasicBlock.cpp files.? It's non-trivial: you need to add support to the .ll file parser/printer, the .bc file reader/writer, the IR stuff, etc. It's probably best discussed on llvmdev, instead of cfe-dev. -Chris From clattner at apple.com Fri Apr 23 11:56:34 2010 From: clattner at apple.com (Chris Lattner) Date: Fri, 23 Apr 2010 09:56:34 -0700 Subject: [cfe-dev] Inline assembly Z constraint and more In-Reply-To: References: <78ECA01C-708A-4B20-B76A-8699561F9F7F@apple.com> Message-ID: On Apr 16, 2010, at 7:20 PM, John Thompson wrote: > Oh, sorry, I forgot to hit the save button in the editor. It's just one file: This isn't the right patch. These constraints are all target specific, so it'll have to be sunk into a (probably new) hook in the PowerPC TargetInfo impl. There is documentation of this stuff here: http://gcc.gnu.org/onlinedocs/gcc/Simple-Constraints.html#Simple-Constraints http://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html#Machine-Constraints FWIW, Z is apparently "Memory operand that is an indexed or indirect from a register (it is usually better to use `m' or `es' in asm statements) " -Chris > > Index: lib/Basic/TargetInfo.cpp > =================================================================== > --- lib/Basic/TargetInfo.cpp (revision 101528) > +++ lib/Basic/TargetInfo.cpp (working copy) > @@ -280,6 +280,8 @@ > Info.setAllowsRegister(); > Info.setAllowsMemory(); > break; > + case 'Z': // wish I knew what Z was for... > + break; > } > > Name++; > @@ -359,6 +361,14 @@ > case 'N': > case 'O': > case 'P': > + case 'Q': > + case 'R': > + case 'S': > + case 'T': > + case 'U': > + case 'W': > + case 'Y': > + case 'Z': > break; > case 'r': // general register. > Info.setAllowsRegister(); > I don't know if it's target-specific or not. The gcc comment makes it seem generic (register indexed memory), but I couldn't find any docs that mentioned it. > > -John > > On Fri, Apr 16, 2010 at 4:38 PM, Chris Lattner wrote: > > On Apr 16, 2010, at 3:53 PM, John Thompson wrote: > > > Using Clang to compile some PS3 headers, I ran into a problem with some inline assembly for some instrinsics macros with an unrecognized "Z" constraint. Looking at the gcc sources, I see there are several other constraints not currently supported. The enclosed macro lets them get through the parser, but at present I have no idea how to actually implement them, so before I look into it more, I thought I'd ask. Can someone help me out? > > > > This from the gcc sources: > > > > (define_memory_constraint "Z" > > "Memory operand that is an indexed or indirect from a register (it is > > usually better to use @samp{m} or @samp{es} in @code{asm} statements)" > > (match_operand 0 "indexed_or_indirect_operand")) > > Is it okay to check in the patch as an intermediate step? > > > > it Z a target independent or target-specific constraint? You have some unrelated changes in your diff. > > -Chris > > > > > -- > John Thompson > John.Thompson.JTSoftware at gmail.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100423/eabeea1b/attachment-0001.html From ponnala.kalyan at gmail.com Fri Apr 23 16:29:47 2010 From: ponnala.kalyan at gmail.com (kalyan ponnala) Date: Fri, 23 Apr 2010 17:29:47 -0400 Subject: [cfe-dev] Attaching Metadata to BasicBlocks In-Reply-To: <672F91CC-6C13-46D5-914B-C83E8688F8BE@apple.com> References: <16D0960D-A60F-4CE4-A765-A6BC145966F1@apple.com> <672F91CC-6C13-46D5-914B-C83E8688F8BE@apple.com> Message-ID: Thanks again Chris, I'll post the follow up post on the LLVM side. PS: Please forgive the silly humor at the end of the post, my friend and I were up till 3:30 AM trying to figure out how to use Metadata in a non-trivial way. We were trying to frame the question properly and he wrote the last line as a joke to me. Neither of us intended it to go on the entire news group let alone to you specifically. You are truely the great, not the Kalyan! On Fri, Apr 23, 2010 at 11:30 AM, Chris Lattner wrote: > > On Apr 23, 2010, at 12:13 AM, kalyan ponnala wrote: > > > Thanks for the reply Chris, > > > > I would like to add Metadata to a loop. > > > > To do this, can I simply add the Metadata Manipulation methods & Metadata > private data from Instruction.h & their method bodies from Metadata.cpp into > the BasicBlock.h & BasicBlock.cpp files.? > > It's non-trivial: you need to add support to the .ll file parser/printer, > the .bc file reader/writer, the IR stuff, etc. It's probably best discussed > on llvmdev, instead of cfe-dev. > > -Chris > -- Kalyan Ponnala phone: 8163772059 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100423/b03eb40c/attachment.html From Trevor.W.Harmon at nasa.gov Fri Apr 23 17:59:08 2010 From: Trevor.W.Harmon at nasa.gov (Trevor Harmon) Date: Fri, 23 Apr 2010 15:59:08 -0700 Subject: [cfe-dev] Attributes on statements and expressions Message-ID: <6F4C1B12-8A16-4FDD-B3E0-44F7A56AADF9@nasa.gov> Hello Clangers, Some time ago, there was talk of extending Clang to allow attributes on statements and expressions [1]. By relaxing the restrictions on where attributes can be placed, users would be able to attach arbitrary info to the AST, which would then be transferred to the LLVM IR (presumably as LLVM 2.7 metadata [2]). Clients of the AST or the LLVM IR could then use this information to do whatever they want. The clients would typically be static analysis tools such as: * Design-by-contract checkers (to declare pre-, post-, and loop invariants) * Defect finders like Clang's own Static Analyzer (to eliminate false positives) * WCET analyzers (to define loop bounds) I would like to begin work on a patch that implements this feature in Clang. The first order of business is to decide how the attributes would look in the user source code. One approach is to retain the existing GCC __attribute__ syntax and simply allow the __attribute__ token to appear on statements and expressions. (Currently it is only allowed on variable, type, and function declarations.) For example: void myFunc(...) { __attribute__((loopbound(50)) while (...) { ... } } Any comments or questions on this? I'd also appreciate any tips on how to get started, as well as admonitions of obstacles I might encounter. Thanks, Trevor [1] http://lists.cs.uiuc.edu/pipermail/cfe-dev/2007-November/000473.html [2] http://blog.llvm.org/2010/04/extensible-metadata-in-llvm-ir.html From rideau3 at gmail.com Sat Apr 24 00:17:27 2010 From: rideau3 at gmail.com (Sean Hunt) Date: Fri, 23 Apr 2010 23:17:27 -0600 Subject: [cfe-dev] Attributes on statements and expressions In-Reply-To: <6F4C1B12-8A16-4FDD-B3E0-44F7A56AADF9@nasa.gov> References: <6F4C1B12-8A16-4FDD-B3E0-44F7A56AADF9@nasa.gov> Message-ID: <4BD27EE7.9040708@gmail.com> On 04/23/2010 04:59 PM, Trevor Harmon wrote: > Hello Clangers, > > Some time ago, there was talk of extending Clang to allow attributes > on statements and expressions [1]. By relaxing the restrictions on > where attributes can be placed, users would be able to attach > arbitrary info to the AST, which would then be transferred to the LLVM > IR (presumably as LLVM 2.7 metadata [2]). Clients of the AST or the > LLVM IR could then use this information to do whatever they want. > > The clients would typically be static analysis tools such as: > > * Design-by-contract checkers (to declare pre-, post-, and loop > invariants) > * Defect finders like Clang's own Static Analyzer (to eliminate false > positives) > * WCET analyzers (to define loop bounds) > > I would like to begin work on a patch that implements this feature in > Clang. The first order of business is to decide how the attributes > would look in the user source code. One approach is to retain the > existing GCC __attribute__ syntax and simply allow the __attribute__ > token to appear on statements and expressions. (Currently it is only > allowed on variable, type, and function declarations.) For example: > > void myFunc(...) { > __attribute__((loopbound(50)) > while (...) { > ... > } > } > > Any comments or questions on this? I'd also appreciate any tips on how > to get started, as well as admonitions of obstacles I might encounter. > Thanks, > > Trevor > > [1] http://lists.cs.uiuc.edu/pipermail/cfe-dev/2007-November/000473.html > [2] http://blog.llvm.org/2010/04/extensible-metadata-in-llvm-ir.html My Summer of Code project is to overhaul the way attributes are handled in clang. Adding attributes to statements is one of the parts of this project, in order to add support for the forthcoming C++0x standard. Once attributes are placed onto the Stmt nodes, it would then be the responsibility of the CodeGen module to encode attribute information into the LLVM IR. Ideally, getting them there would require only a small amount of effort - ideally only a few lines added to a definition file. From there, you would have to add the CG code to forward it into LLVM (and, of course, code to actually do something with the metadata). Sean From zaffanella at cs.unipr.it Sat Apr 24 02:55:49 2010 From: zaffanella at cs.unipr.it (Enea Zaffanella) Date: Sat, 24 Apr 2010 09:55:49 +0200 Subject: [cfe-dev] A patch for Sema::CheckTypenameType. Message-ID: <4BD2A405.3010000@cs.unipr.it> Hello. Please find attached a patch for Sema::CheckTypenameType() that should solve a couple of FIXMEs related to the construction of DependentNameType nodes. In code such as the following =============== template class S; template struct Derived : public S::base_type {}; =============== clang was generating a DependentNameType node for the base class of Derived where the presence of the keyword "typename" was (wrongly) assumed. Hence we were obtaining: $ llvm/Debug/bin/clang -cc1 -ast-print c.cc template class S; template class Derived : public typename S::base_type { }; With the attached patch, we get instead: template class S; template struct Derived : public S::base_type { }; The patch passes all tests (r102070). Regards, Enea Zaffanella. -------------- next part -------------- A non-text attachment was scrubbed... Name: CheckTypenameType.patch Type: text/x-patch Size: 5015 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100424/8252a340/attachment.bin From zaffanella at cs.unipr.it Sat Apr 24 05:30:45 2010 From: zaffanella at cs.unipr.it (Enea Zaffanella) Date: Sat, 24 Apr 2010 12:30:45 +0200 Subject: [cfe-dev] Doubts regarding CXXPseudoDestructorExpr. Message-ID: <4BD2C855.5090308@cs.unipr.it> Hello. When compiling the following program with clang: ============================= template struct S { typedef U my_type; }; template struct T { void foo(typename S::my_type* x) { typedef typename S::my_type Type; x->Type::~Type(); // OK x->~Type(); // OK x->S::my_type::~my_type(); // Error (why?) x->S::~my_type(); // Error (why?) x->Type::~my_type(); // Crash. } }; int main() { T t; t.foo(0); return 0; } ============================= we obtain the two errors and then a crash: ============================= $ llvm/Debug/bin/clang++ -fsyntax-only pseudo.cc pseudo.cc:12:10: error: 'U' does not refer to a value x->S::my_type::~my_type(); // Error (why?) ^ pseudo.cc:6:20: note: declared at template ^ pseudo.cc:13:10: error: 'U' does not refer to a value x->S::~my_type(); // Error (why?) ^ pseudo.cc:6:20: note: declared at template ^ [...snip...] 1. parser at end of file 2. pseudo.cc:8:8: instantiating function definition 'T::foo' clang: error: compiler command failed due to signal 11 (use -v to see invocation) ============================= Apart from the crash, we would like to know whether or not the two errors are meant to be there (we tried other compilers ... but each one seems to have its own view of the matter). As a side note, when looking into the definition of AST node CXXPseudoDestructorExpr, we were surprised to see so many data members (Qualifier, ScopeType and DestroyedType) and were wondering whether or not all of this could be replaced by a single TypeSourceInfo, possibly containing a QualifiedNameType or a DependentNameType encoding the optional (dependent) name qualifier. Cheers, Enea Zaffanella. From zaffanella at cs.unipr.it Sat Apr 24 06:43:21 2010 From: zaffanella at cs.unipr.it (Enea Zaffanella) Date: Sat, 24 Apr 2010 13:43:21 +0200 Subject: [cfe-dev] On the NNS representation for name qualifiers. Message-ID: <4BD2D959.6040101@cs.unipr.it> Hello. We have a question regarding the intended design of AST nodes representing name qualifiers (i.e., those containing a NestedNameSpecifier pointer). Consider the following program fragment: ================ namespace N { struct S { struct T {}; }; } N::S::T t; ================ where we have the name qualifier N::S:: for the type T. In principle, this qualifier can be represented in two ways: a) as a namespace specifier N:: followed by an (unqualified) type specifier S:: or b) as a single (qualified) type specifier N::S::, i.e., a single pointer to a QualifiedNameType (which of course contains another NNS*). Are both possibilities above actually possible in clang, or is it the case that clang will systematically choose once and for all between option a) and option b) ? Thanks in advance for any clarification you can provide us. Cheers, Enea Zaffanella From dgregor at apple.com Sat Apr 24 10:37:22 2010 From: dgregor at apple.com (Douglas Gregor) Date: Sat, 24 Apr 2010 08:37:22 -0700 Subject: [cfe-dev] A patch for Sema::CheckTypenameType. In-Reply-To: <4BD2A405.3010000@cs.unipr.it> References: <4BD2A405.3010000@cs.unipr.it> Message-ID: <6AD4564C-47A0-42D1-9CB9-A6E6D391F105@apple.com> On Apr 24, 2010, at 12:55 AM, Enea Zaffanella wrote: > Hello. > > Please find attached a patch for Sema::CheckTypenameType() that should solve a couple of FIXMEs related to the construction of DependentNameType nodes. In code such as the following > =============== > template class S; > > template > struct Derived : public S::base_type {}; > =============== > clang was generating a DependentNameType node for the base class of Derived where the presence of the keyword "typename" was (wrongly) assumed. Hence we were obtaining: > > $ llvm/Debug/bin/clang -cc1 -ast-print c.cc > template class S; > template class Derived : public typename S::base_type { > }; > > > With the attached patch, we get instead: > > template class S; > template struct Derived : public S::base_type { > }; > > The patch passes all tests (r102070). Perfect, thanks! Committed as r102243. - Doug From listrp at gmail.com Sat Apr 24 22:18:04 2010 From: listrp at gmail.com (Robert Purves) Date: Sun, 25 Apr 2010 15:18:04 +1200 Subject: [cfe-dev] Fatal error from -include if pwd has Unicode characters Message-ID: <11BF85EF-58ED-4FBB-9384-B3CCAFE023FC@gmail.com> OS X 10.6.3 $ pwd /Users/rdp/Desktop/Fran?ais $ cat test.c int main( void ) { return 0; } $ cat test.h // test.h $ /Developer/usr/bin/clang -c test.c $ /Developer/usr/bin/clang -c test.c -include test.h In file included from :110: :1:10: fatal error: '/Users/rdp/Desktop/Fran?ais' file not found #include "/Users/rdp/Desktop/Fran?ais" ^ 1 diagnostic generated. $ /Developer/usr/bin/clang --version clang version 1.0.2 (http://llvm.org/svn/llvm-project/cfe/tags/Apple/clang-32 exported) Target: x86_64-apple-darwin10 Reassuringly, r102295 does not show the problem, but I am not sure if that is a guarantee for future Apple branches. Robert P. From clattner at apple.com Sat Apr 24 22:46:53 2010 From: clattner at apple.com (Chris Lattner) Date: Sat, 24 Apr 2010 20:46:53 -0700 Subject: [cfe-dev] Fatal error from -include if pwd has Unicode characters In-Reply-To: <11BF85EF-58ED-4FBB-9384-B3CCAFE023FC@gmail.com> References: <11BF85EF-58ED-4FBB-9384-B3CCAFE023FC@gmail.com> Message-ID: <172BDFCD-4CD2-473E-BF95-6A3EDAA3DC52@apple.com> On Apr 24, 2010, at 8:18 PM, Robert Purves wrote: > $ /Developer/usr/bin/clang -c test.c > $ /Developer/usr/bin/clang -c test.c -include test.h > In file included from :110: > :1:10: fatal error: '/Users/rdp/Desktop/Fran?ais' file not found > #include "/Users/rdp/Desktop/Fran?ais" > ^ > 1 diagnostic generated. > > $ /Developer/usr/bin/clang --version > clang version 1.0.2 (http://llvm.org/svn/llvm-project/cfe/tags/Apple/clang-32 exported) > Target: x86_64-apple-darwin10 > > > Reassuringly, r102295 does not show the problem, but I am not sure if that is a guarantee for future Apple branches. clang "1.0.2" is pretty ancient by now :). Thanks for confirming that it is fixed on mainline though, -Chris From listrp at gmail.com Sun Apr 25 00:01:36 2010 From: listrp at gmail.com (Robert Purves) Date: Sun, 25 Apr 2010 17:01:36 +1200 Subject: [cfe-dev] Fatal error from -include if pwd has Unicode characters In-Reply-To: <172BDFCD-4CD2-473E-BF95-6A3EDAA3DC52@apple.com> References: <11BF85EF-58ED-4FBB-9384-B3CCAFE023FC@gmail.com> <172BDFCD-4CD2-473E-BF95-6A3EDAA3DC52@apple.com> Message-ID: <1150EED4-034B-422F-9A79-D8955521413B@gmail.com> Chris Lattner wrote: >> Reassuringly, r102295 does not show the problem, but I am not sure if that is a guarantee for future Apple branches. > > clang "1.0.2" is pretty ancient by now :). Thanks for confirming that it is fixed on mainline though, Pretty ancient? clang 1.0.2 is a component of Xcode 3.2.2, and Software Update advised me of this release less than 48 hours ago. Of course you're right; the executable is three months old. That's a lot of commits. On the other hand, three months is a spectacularly better turnaround time than for Apple gcc releases. Surely an occasion for congratulations, bonuses and cigars all round? Robert P. From mikem.llvm at gmail.com Sun Apr 25 00:57:13 2010 From: mikem.llvm at gmail.com (mike) Date: Sun, 25 Apr 2010 01:57:13 -0400 Subject: [cfe-dev] [PATCH] add regex/globbing to -verify diagnostics Message-ID: The other day someone on IRC asked if -verify supported regex; attached is a patch for regex and glob-style matching. They're selected by using one of '-', '~' or '*' for string, regex and glob matching. Maybe '?' would be better for glob? Here's a few pertinent lines from the header docs: /// Alternative matching modes may be specified via the first character which /// follows 'expected'. The following modes are supported: /// /// - standard string matching, case-sensitive /// ~ regular-expression matching /// * glob-style matching /// /// Examples: match error "variable has incomplete type 'struct s'" /// /// // expected-error {{variable has incomplete type 'struct s'}} /// // expected-error {{variable has incomplete type}} /// /// // expected~error {{variable has has type 'struct .'}} /// // expected~error {{variable has has type 'struct .*'}} /// // expected~error {{variable has has type 'struct (.*)'}} /// /// // expected*error {{variable has incomplete type 'struct ?'}} /// // expected*error {{variable has incomplete type 'struct [stuv]'}} /// // expected*error {{variable has incomplete type 'struct [!abcd]'}} /// // expected*error {{variable has incomplete type 'struct *'}} --mike -------------- next part -------------- A non-text attachment was scrubbed... Name: verify.regex0.patch Type: application/octet-stream Size: 21669 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100425/a169e08a/attachment-0001.obj From zhunansjtu at gmail.com Sun Apr 25 05:06:40 2010 From: zhunansjtu at gmail.com (Nan Zhu) Date: Sun, 25 Apr 2010 18:06:40 +0800 Subject: [cfe-dev] Fwd: Makefile with Clang In-Reply-To: References: <956798.91121.qm@web30008.mail.mud.yahoo.com> Message-ID: Actually, we have been working on this way, the key to acquire the bitcode file is to write a "dummy_gcc" which can call cc ??llvm-ld to finish the compiling procedure, since the llvm-gcc cannot invoke llvm-ld to generate LLVM bitcode files for you automatically 2010/4/20 Yan Lin Aung > I would like to have a whole program bitcode file. Any idea? > > --- On *Tue, 4/20/10, Nan Zhu * wrote: > > > From: Nan Zhu > Subject: Re: [cfe-dev] Makefile with Clang > To: "Yan Lin Aung" > Cc: cfe-dev at cs.uiuc.edu > Date: Tuesday, April 20, 2010, 1:32 PM > > > You mean you want one bitcode file for each C source file or you would like > to have a whole program bitcode file? > > 2010/4/20 Yan Lin Aung > > > >> Hi >> >> I would like to compile applications which consists of multiple source >> files (for example, file1.c file2.c, main.c) with Clang using Makefile to >> get the LLVM bitcode file. Anyone knows how to do that? Thanks. >> >> With regards >> Yan Lin >> >> >> >> _______________________________________________ >> 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/20100425/b934b0c8/attachment.html From mail at justinbogner.com Sun Apr 25 12:11:16 2010 From: mail at justinbogner.com (Justin Bogner) Date: Sun, 25 Apr 2010 11:11:16 -0600 Subject: [cfe-dev] [PATCH] add regex/globbing to -verify diagnostics References: Message-ID: <87mxwrzccr.fsf@justinbogner.com> mike writes: > The other day someone on IRC asked if -verify supported regex; > attached is a patch for regex and glob-style matching. They're > selected by using one of '-', '~' or '*' for string, regex and glob > matching. Maybe '?' would be better for glob? Here's a few pertinent > lines from the header docs: The expected-error, expected~error, and expected*error are so similar as to be confusing. Why not simply have expected-error, expected-error-re, and expected-error-glob? It's only a few extra characters, and much more noticeable. From lattner at apple.com Sun Apr 25 14:05:12 2010 From: lattner at apple.com (Tanya Lattner) Date: Sun, 25 Apr 2010 12:05:12 -0700 Subject: [cfe-dev] 2.7 Release Status Message-ID: All, I hope to have 2.7 released tomorrow. We have a 2 last minute fixes that we are debating on putting in, but otherwise the release looks great. Thanks, Tanya From abramo.bagnara at gmail.com Sun Apr 25 15:57:58 2010 From: abramo.bagnara at gmail.com (Abramo Bagnara) Date: Sun, 25 Apr 2010 22:57:58 +0200 Subject: [cfe-dev] Wrong extern inside no braces linkage specification declaration Message-ID: <4BD4ACD6.4020600@gmail.com> Currently clang marks these two declarations extern "C" int a; extern "C" void foo(); as extern in StorageClassAsWritten, but the inner declarations does not have any storage class specified (and C++ standard does not allow any). The attached patch wrt r102259 fixes the problem (and do not introduce any regressions). -------------- next part -------------- A non-text attachment was scrubbed... Name: linkage-extern.patch Type: text/x-patch Size: 4952 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100425/89784c3d/attachment.bin From mikem.llvm at gmail.com Mon Apr 26 00:36:24 2010 From: mikem.llvm at gmail.com (mike-m) Date: Mon, 26 Apr 2010 01:36:24 -0400 Subject: [cfe-dev] [PATCH] add regex/globbing to -verify diagnostics In-Reply-To: <87mxwrzccr.fsf@justinbogner.com> References: <87mxwrzccr.fsf@justinbogner.com> Message-ID: <931E5657-3E1B-4236-8E59-BF1E10E90B19@gmail.com> Patch update uses suggested '-re' and '-glob' syntax, patch attached. - lit tests pass with clang-debug, clang-release and selfclang-debug builds - no measurable performance impact on lit tests ***Changes from last patch: - updated syntax to use suffixes { -re | -glob } for regex and globbing, respectively - added glob sequence support: first element ']' treated as literal - reworked verify-string parser to be more resilient to errors - added lit test/Misc/verify.c ***Examples matching error: "variable has incomplete type 'struct s'" // expected-error {{variable has incomplete type 'struct s'}} // expected-error {{variable has incomplete type}} // expected-error-re {{variable has has type 'struct .'}} // expected-error-re {{variable has has type 'struct .*'}} // expected-error-re {{variable has has type 'struct (.*)'}} // expected-error-re {{variable has has type 'struct[[:space:]](.*)'}} // expected-error-glob {{variable has incomplete type 'struct ?'}} // expected-error-glob {{variable has incomplete type 'struct [stuv]'}} // expected-error-glob {{variable has incomplete type 'struct [!abcd]'}} // expected-error-glob {{variable has incomplete type 'struct *'}} --mike-m On 2010-04-25, at 1:11 PM, Justin Bogner wrote: > > The expected-error, expected~error, and expected*error are so similar as > to be confusing. Why not simply have expected-error, expected-error-re, > and expected-error-glob? It's only a few extra characters, and much more > noticeable. -------------- next part -------------- A non-text attachment was scrubbed... Name: verify.regex1.patch Type: application/octet-stream Size: 24100 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100426/c7d0a773/attachment-0001.obj From Olaf.Krzikalla at tu-dresden.de Mon Apr 26 02:40:13 2010 From: Olaf.Krzikalla at tu-dresden.de (Olaf Krzikalla) Date: Mon, 26 Apr 2010 09:40:13 +0200 Subject: [cfe-dev] Attributes on statements and expressions In-Reply-To: <6F4C1B12-8A16-4FDD-B3E0-44F7A56AADF9@nasa.gov> References: <6F4C1B12-8A16-4FDD-B3E0-44F7A56AADF9@nasa.gov> Message-ID: <4BD5435D.3000706@tu-dresden.de> Trevor, Sean and me talked about the topic two weeks ago on the list. It is a good idea to have attributes as defined in the upcoming C++ standard in mind while implementing that feature in clang. > The clients would typically be static analysis tools such as: > IMHO one thing that will be solved using attributes in the future is a "parfor" construct. > > I would like to begin work on a patch that implements this feature in > Clang. The first order of business is to decide how the attributes > would look in the user source code. One approach is to retain the > existing GCC __attribute__ syntax and simply allow the __attribute__ > token to appear on statements and expressions. To be honest I don't like the GCC syntax and - given an proposal already accepted for standardization - I wouldn't bother implementing it but go straight for the new [[attribute]] syntax. Best regards Olaf Krzikalla From sebastian.redl at getdesigned.at Mon Apr 26 03:39:01 2010 From: sebastian.redl at getdesigned.at (Sebastian Redl) Date: Mon, 26 Apr 2010 10:39:01 +0200 Subject: [cfe-dev] Wrong extern inside no braces linkage specification declaration In-Reply-To: <4BD4ACD6.4020600@gmail.com> References: <4BD4ACD6.4020600@gmail.com> Message-ID: On Sun, 25 Apr 2010 22:57:58 +0200, Abramo Bagnara wrote: > Currently clang marks these two declarations > > extern "C" int a; > extern "C" void foo(); > > as extern in StorageClassAsWritten, but the inner declarations does not > have any storage class specified (and C++ standard does not allow any). > > The attached patch wrt r102259 fixes the problem (and do not introduce > any regressions). As I explained in Bug 6276, Clang's behavior is correct. 7.5p7 states that a linkage specifier without braces acts like an extern storage class specifier. http://llvm.org/bugs/show_bug.cgi?id=6276 From abramo.bagnara at gmail.com Mon Apr 26 03:59:33 2010 From: abramo.bagnara at gmail.com (Abramo Bagnara) Date: Mon, 26 Apr 2010 10:59:33 +0200 Subject: [cfe-dev] Wrong extern inside no braces linkage specification declaration In-Reply-To: References: <4BD4ACD6.4020600@gmail.com> Message-ID: <4BD555F5.1080108@gmail.com> Il 26/04/2010 10:39, Sebastian Redl ha scritto: > > On Sun, 25 Apr 2010 22:57:58 +0200, Abramo Bagnara > wrote: >> Currently clang marks these two declarations >> >> extern "C" int a; >> extern "C" void foo(); >> >> as extern in StorageClassAsWritten, but the inner declarations does not >> have any storage class specified (and C++ standard does not allow any). >> >> The attached patch wrt r102259 fixes the problem (and do not introduce >> any regressions). > > As I explained in Bug 6276, Clang's behavior is correct. 7.5p7 states that > a linkage specifier without braces acts like an extern storage class > specifier. > > http://llvm.org/bugs/show_bug.cgi?id=6276 This patch is not about whether or not the inner Decl should be interpreted as declaration or a definition, neither it has to do with whether or not the linkage of the declaration should be interpreted as extern (in both cases clang's behavior is correct). Rather, the patch is only addressing whether or not the "extern" keyword was syntactically written in the source code as a storage specifier. This is not the case in the given examples, as the keyword is syntactically written as a linkage specification. Note that if you query those Decl by method getStorageClass() you will still obtain Extern. On the other hand, if you call getStorageClassAsWritten(), you will obtain None. From sebastian.redl at getdesigned.at Mon Apr 26 04:10:51 2010 From: sebastian.redl at getdesigned.at (Sebastian Redl) Date: Mon, 26 Apr 2010 11:10:51 +0200 Subject: [cfe-dev] Wrong extern inside no braces linkage specification declaration In-Reply-To: <4BD555F5.1080108@gmail.com> References: <4BD4ACD6.4020600@gmail.com> <4BD555F5.1080108@gmail.com> Message-ID: <4915311ab90d2daffb8ff4dbc662880d@localhost> On Mon, 26 Apr 2010 10:59:33 +0200, Abramo Bagnara wrote: > This patch is not about whether or not the inner Decl should be > interpreted as declaration or a definition, neither it has to do with > whether or not the linkage of the declaration should be interpreted as > extern (in both cases clang's behavior is correct). > > Rather, the patch is only addressing whether or not the "extern" keyword > was syntactically written in the source code as a storage specifier. > This is not the case in the given examples, as the keyword is > syntactically written as a linkage specification. > > Note that if you query those Decl by method getStorageClass() you will > still obtain Extern. On the other hand, if you call > getStorageClassAsWritten(), you will obtain None. You're right, of course. Sorry for that. Sebastian From j.wilhelmy at arcor.de Mon Apr 26 13:04:43 2010 From: j.wilhelmy at arcor.de (Jochen Wilhelmy) Date: Mon, 26 Apr 2010 20:04:43 +0200 Subject: [cfe-dev] how to mapping from struct index to name Message-ID: <4BD5D5BB.4020408@arcor.de> Hi! How can I find out the mapping between structure element names and index used in getelementptr? If I have the following program: struct Foo { int i; float j; }; Foo foo; void main() { foo.j = 1.0f } I get an instruction containing getelementptr (%Foo* @foo, i32 0, i32 1) Member i is at index 0 and member j is at index 1. This is what I want to find out. Perhaps it can be done using debug info? -Jochen From Trevor.W.Harmon at nasa.gov Mon Apr 26 16:34:06 2010 From: Trevor.W.Harmon at nasa.gov (Trevor Harmon) Date: Mon, 26 Apr 2010 14:34:06 -0700 Subject: [cfe-dev] Attributes on statements and expressions In-Reply-To: <4BD5435D.3000706@tu-dresden.de> References: <6F4C1B12-8A16-4FDD-B3E0-44F7A56AADF9@nasa.gov> <4BD5435D.3000706@tu-dresden.de> Message-ID: On Apr 26, 2010, at 12:40 AM, Olaf Krzikalla wrote: > To be honest I don't like the GCC syntax and - given an proposal > already > accepted for standardization - I wouldn't bother implementing it but > go > straight for the new [[attribute]] syntax. Actually I wasn't even aware of the new [[attribute]] syntax. (I've not been following the C++0x effort.) I only mentioned __attribute__ because that seemed to the planned approach in the original discussion I referenced. The new [[attribute]] stuff looks cool; it's exactly what I need. In particular it allows attributes on loops, such as: for [[ attr1 ]] (int i=0; i References: <87mxwrzccr.fsf@justinbogner.com> <931E5657-3E1B-4236-8E59-BF1E10E90B19@gmail.com> Message-ID: On Apr 25, 2010, at 10:36 PM, mike-m wrote: > Patch update uses suggested '-re' and '-glob' syntax, patch attached. > > - lit tests pass with clang-debug, clang-release and selfclang-debug builds > - no measurable performance impact on lit tests I also prefer the "-re" suffix, thanks for doing that. This is really cool, but I think it's a bit overkill. I'd rather not support glob at all, it adds a bunch of complexity for no added advantage. You converted some loops like this: - std::string Msg(CommentStart, ExpectedEnd); - std::string::size_type FindPos; - while ((FindPos = Msg.find("\\n")) != std::string::npos) - Msg.replace(FindPos, 2, "\n"); - // Add is possibly multiple times. - for (int i = 0; i < Times; ++i) - ExpectedDiags.push_back(std::make_pair(Pos, Msg)); to explicit for loops with switches in them. If you're going to change them, please convert them to using the StringRef API and its algorithms. It looks like using an invalid regex in an directive line will cause an assertion, pleasem ake it be an error from -verify mode. Thanks for working on this! -Chris > > ***Changes from last patch: > > - updated syntax to use suffixes { -re | -glob } for regex and globbing, respectively > - added glob sequence support: first element ']' treated as literal > - reworked verify-string parser to be more resilient to errors > - added lit test/Misc/verify.c > > ***Examples matching error: "variable has incomplete type 'struct s'" > > // expected-error {{variable has incomplete type 'struct s'}} > // expected-error {{variable has incomplete type}} > > // expected-error-re {{variable has has type 'struct .'}} > // expected-error-re {{variable has has type 'struct .*'}} > // expected-error-re {{variable has has type 'struct (.*)'}} > // expected-error-re {{variable has has type 'struct[[:space:]](.*)'}} > > // expected-error-glob {{variable has incomplete type 'struct ?'}} > // expected-error-glob {{variable has incomplete type 'struct [stuv]'}} > // expected-error-glob {{variable has incomplete type 'struct [!abcd]'}} > // expected-error-glob {{variable has incomplete type 'struct *'}} > > --mike-m > > On 2010-04-25, at 1:11 PM, Justin Bogner wrote: >> >> The expected-error, expected~error, and expected*error are so similar as >> to be confusing. Why not simply have expected-error, expected-error-re, >> and expected-error-glob? It's only a few extra characters, and much more >> noticeable. > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From Trevor.W.Harmon at nasa.gov Mon Apr 26 16:43:44 2010 From: Trevor.W.Harmon at nasa.gov (Trevor Harmon) Date: Mon, 26 Apr 2010 14:43:44 -0700 Subject: [cfe-dev] Attributes on statements and expressions In-Reply-To: <4BD27EE7.9040708@gmail.com> References: <6F4C1B12-8A16-4FDD-B3E0-44F7A56AADF9@nasa.gov> <4BD27EE7.9040708@gmail.com> Message-ID: On Apr 23, 2010, at 10:17 PM, Sean Hunt wrote: > My Summer of Code project is to overhaul the way attributes are > handled > in clang. Adding attributes to statements is one of the parts of this > project, in order to add support for the forthcoming C++0x standard. Is your proposal available online somewhere? > Once attributes are placed onto the Stmt nodes, it would then be the > responsibility of the CodeGen module to encode attribute information > into the LLVM IR. Would the attribute information be encoded as LLVM metadata (MDNode)? Let me know if there's any way I can help in this effort. Trevor From micky686 at gmail.com Mon Apr 26 20:43:06 2010 From: micky686 at gmail.com (Micky J) Date: Tue, 27 Apr 2010 03:43:06 +0200 Subject: [cfe-dev] Bug: clang-cc -cfg-view Message-ID: Hi, After checking out and building llvm , running clang-cc on the program file.c simply does not produce any results. file.c: int main (int argc, char* argv[]) { return 0; } Here is the run session: $ clang-cc -cfg-dump -v file.c clang-cc version 1.1 based upon llvm 2.7svn hosted on i386-pc-linux-gnu ignoring nonexistent directory "/System/Library/Frameworks" ignoring nonexistent directory "/Library/Frameworks" #include "..." search starts here: #include <...> search starts here: /home/milj/downloads/src/llvm/llvm/Debug/lib/clang/1.1/include /usr/local/include /usr/include End of search list. ---------------------------------- The -ast-dump and -ast-view options work perfectly, but the -cfg-dump and -cfg-view options do not. Does someone have any recommendations on how to get -cfg-dump and -cfg-view to work with clang-cc or for some other visualization alternatives of llvm code CFGs? Regards! Micky -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100427/1666df3a/attachment.html From eli.friedman at gmail.com Mon Apr 26 23:19:19 2010 From: eli.friedman at gmail.com (Eli Friedman) Date: Mon, 26 Apr 2010 21:19:19 -0700 Subject: [cfe-dev] Bug: clang-cc -cfg-view In-Reply-To: References: Message-ID: On Mon, Apr 26, 2010 at 6:43 PM, Micky J wrote: > Hi, > After checking out and building llvm , > running clang-cc on the program file.c > simply does not produce any results. > > file.c: > int main (int argc, char* argv[]) { > > > ? return 0; > } > > > Here is the run session: > > $ clang-cc -cfg-dump -v file.c > clang-cc version 1.1 based upon llvm 2.7svn hosted on i386-pc-linux-gnu > ignoring nonexistent directory "/System/Library/Frameworks" > ignoring nonexistent directory "/Library/Frameworks" > #include "..." search starts here: > #include <...> search starts here: > ?/home/milj/downloads/src/llvm/llvm/Debug/lib/clang/1.1/include > ?/usr/local/include > ?/usr/include > End of search list. > ---------------------------------- > > The -ast-dump and -ast-view options work perfectly, but the -cfg-dump and > -cfg-view options do not. > Does someone have any recommendations on how to get -cfg-dump and -cfg-view > to work with clang-cc or > for some other visualization alternatives of llvm code CFGs? AFAIK, -cfg-dump only works in -analyze mode. -Eli From mikem.llvm at gmail.com Mon Apr 26 23:49:30 2010 From: mikem.llvm at gmail.com (mike-m) Date: Tue, 27 Apr 2010 00:49:30 -0400 Subject: [cfe-dev] [PATCH] add regex/globbing to -verify diagnostics In-Reply-To: References: <87mxwrzccr.fsf@justinbogner.com> <931E5657-3E1B-4236-8E59-BF1E10E90B19@gmail.com> Message-ID: Hi Chris, thanks for taking a look at this patch. Patch is updated to your specs and attached. Summary of changes since last iteration: - removed globbing support - invalid regex now reports proper diagnostic instead of using assert mechanism - reworked "\\n" -> '\n' substitution with StringRef - parameterized various verify diagnostic error definitions for { string | regex } differentiation Existing lit tests show no measurable performance impact. --mike-m -------------- next part -------------- A non-text attachment was scrubbed... Name: verify.regex2.patch Type: application/octet-stream Size: 22466 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100427/4d469548/attachment-0001.obj -------------- next part -------------- On 2010-04-26, at 5:41 PM, Chris Lattner wrote: > On Apr 25, 2010, at 10:36 PM, mike-m wrote: >> Patch update uses suggested '-re' and '-glob' syntax, patch attached. >> >> - lit tests pass with clang-debug, clang-release and selfclang-debug builds >> - no measurable performance impact on lit tests > > I also prefer the "-re" suffix, thanks for doing that. > > This is really cool, but I think it's a bit overkill. I'd rather not support glob at all, it adds a bunch of complexity for no added advantage. > > You converted some loops like this: > > - std::string Msg(CommentStart, ExpectedEnd); > - std::string::size_type FindPos; > - while ((FindPos = Msg.find("\\n")) != std::string::npos) > - Msg.replace(FindPos, 2, "\n"); > - // Add is possibly multiple times. > - for (int i = 0; i < Times; ++i) > - ExpectedDiags.push_back(std::make_pair(Pos, Msg)); > > to explicit for loops with switches in them. If you're going to change them, please convert them to using the StringRef API and its algorithms. > > It looks like using an invalid regex in an directive line will cause an assertion, pleasem ake it be an error from -verify mode. > > Thanks for working on this! > > -Chris From rideau3 at gmail.com Tue Apr 27 01:14:19 2010 From: rideau3 at gmail.com (Sean Hunt) Date: Tue, 27 Apr 2010 00:14:19 -0600 Subject: [cfe-dev] Attributes on statements and expressions In-Reply-To: References: <6F4C1B12-8A16-4FDD-B3E0-44F7A56AADF9@nasa.gov> <4BD27EE7.9040708@gmail.com> Message-ID: <4BD680BB.3010801@gmail.com> On 04/26/2010 03:43 PM, Trevor Harmon wrote: > Is your proposal available online somewhere? http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/llvm/t127230760878 > Would the attribute information be encoded as LLVM metadata (MDNode)? > > Let me know if there's any way I can help in this effort. > > Trevor > Encoding it as a metadata node seems like a good idea, but that's something I'll probably leave to someone else. I don't know enough about LLVM's metadata to know if you'd want to just have an [[llvm::metadata()]] attribute, or individual attributes for different kinds of metadata. Sean From charlesneedspace at yahoo.com.ar Mon Apr 26 10:59:56 2010 From: charlesneedspace at yahoo.com.ar (Charllls Alquarra) Date: Mon, 26 Apr 2010 08:59:56 -0700 (PDT) Subject: [cfe-dev] prototyping c++ language extensions Message-ID: <777745.30150.qm@web63508.mail.re1.yahoo.com> Hi, I'm trying to find a set of open source tools to quickly prototype language extensions for c++. Basically i'm just wondering if it is possible to implement compile-time reflection in a way that is similar to what open-c++ did http://opencxx.sourceforge.net/ using clang That project is largely dead but i feel that a tool like this would have great potential for code reusability and expressivity From sebastian.redl at getdesigned.at Tue Apr 27 02:37:12 2010 From: sebastian.redl at getdesigned.at (Sebastian Redl) Date: Tue, 27 Apr 2010 09:37:12 +0200 Subject: [cfe-dev] prototyping c++ language extensions In-Reply-To: <777745.30150.qm@web63508.mail.re1.yahoo.com> References: <777745.30150.qm@web63508.mail.re1.yahoo.com> Message-ID: <935ac595cb09d6640a2839e0e8e708fe@localhost> On Mon, 26 Apr 2010 08:59:56 -0700 (PDT), Charllls Alquarra wrote: > I'm trying to find a set of open source tools to quickly prototype > language extensions for c++. Basically i'm just wondering if it is possible > to implement compile-time reflection in a way that is similar to what > open-c++ did http://opencxx.sourceforge.net/ using clang > That project is largely dead but i feel that a tool like this would have > great potential for code reusability and expressivity Hi, Clang is probably the best environment available to try such a thing. Of course, with Clang, you would create a direct compiler instead of a source-to-source translator. (My own plans for compile-time reflection will also be prototyped in Clang.) Note, though, that experiments probably won't be accepted back into mainline unless they prove themselves. Sebastian From rengolin at systemcall.org Tue Apr 27 03:37:53 2010 From: rengolin at systemcall.org (Renato Golin) Date: Tue, 27 Apr 2010 09:37:53 +0100 Subject: [cfe-dev] [LLVMdev] Phoronix: Benchmarking LLVM & Clang Against GCC 4.5 In-Reply-To: References: Message-ID: On 27 April 2010 08:18, Stefano Delli Ponti wrote: > FYI > http://www.phoronix.com/scan.php?page=article&item=gcc_llvm_clang&num=1 For Apache and Dhrystone, the performance boost is good (but only the former is really important), but for the rest, especially those with image/sound processing, and HMMR, it's still far behind. Is this only because there is no auto vectorization in LLVM? Would be good to know why some programs were not compiled with Clang. -- cheers, --renato http://systemcall.org/ Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm From Olaf.Krzikalla at tu-dresden.de Tue Apr 27 03:37:51 2010 From: Olaf.Krzikalla at tu-dresden.de (Olaf Krzikalla) Date: Tue, 27 Apr 2010 10:37:51 +0200 Subject: [cfe-dev] Attributes on statements and expressions In-Reply-To: References: <6F4C1B12-8A16-4FDD-B3E0-44F7A56AADF9@nasa.gov> <4BD5435D.3000706@tu-dresden.de> Message-ID: <4BD6A25F.4060709@tu-dresden.de> Trevor Harmon schrieb: > For those interested in reading about it, the best material I've been > able to find so far is this: > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2418.pdf > > It's a little old but provides a good overview. Another source of interest is http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3092.pdf esp. section 7.6. This is the FCD, so we can expect this getting standardized with some minor changes only. > There's one thing I'm confused about, though. I assume it's possible > to define my own attributes, e.g. [[mycoolattr(42)]]. But how exactly > do I do that? Is there some sample code somewhere? I don't know of examples. The FCD states that the behavior of attributes other than the predefined ones are implementation defined. That is you can define your own attributes at will in the compiler implementation. (hmm - that would prevent the standardization of other attributes in the future. I'm going to raise that issue in csc++...) Best regards Olaf Krzikalla From j.wilhelmy at arcor.de Tue Apr 27 03:42:09 2010 From: j.wilhelmy at arcor.de (Jochen Wilhelmy) Date: Tue, 27 Apr 2010 10:42:09 +0200 Subject: [cfe-dev] little bug: comments swapped Message-ID: <4BD6A361.2010005@arcor.de> Hi! in CGRecordLayout.h the comments for unsigned getLLVMFieldNo (const FieldDecl *FD) const and const CGBitFieldInfo &getBitFieldInfo (const FieldDecl *FD) const are swapped. It seemsCGRecordLayout contains the info I need, is there a way to access it after compilation to LLVM IR? -Jochen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100427/2b98b74b/attachment.html From indeyets at gmail.com Tue Apr 27 05:20:44 2010 From: indeyets at gmail.com (Alexey Zakhlestin) Date: Tue, 27 Apr 2010 14:20:44 +0400 Subject: [cfe-dev] [LLVMdev] Phoronix: Benchmarking LLVM & Clang Against GCC 4.5 In-Reply-To: References: Message-ID: <3963B042-27FD-4EAB-B00C-0773871F0AB4@gmail.com> On 27.04.2010, at 12:37, Renato Golin wrote: > On 27 April 2010 08:18, Stefano Delli Ponti > wrote: >> FYI >> http://www.phoronix.com/scan.php?page=article&item=gcc_llvm_clang&num=1 > > For Apache and Dhrystone, the performance boost is good (but only the > former is really important), but for the rest, especially those with > image/sound processing, and HMMR, it's still far behind. Is this only > because there is no auto vectorization in LLVM? > > Would be good to know why some programs were not compiled with Clang. yup. it's a bit strange, that they couldn't compile php. I compile php with clang for several months (at least) and it just works -- Alexey Zakhlestin http://www.milkfarmsoft.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2673 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100427/73c12918/attachment.bin From rengolin at systemcall.org Tue Apr 27 05:28:05 2010 From: rengolin at systemcall.org (Renato Golin) Date: Tue, 27 Apr 2010 11:28:05 +0100 Subject: [cfe-dev] [LLVMdev] Phoronix: Benchmarking LLVM & Clang Against GCC 4.5 In-Reply-To: <3963B042-27FD-4EAB-B00C-0773871F0AB4@gmail.com> References: <3963B042-27FD-4EAB-B00C-0773871F0AB4@gmail.com> Message-ID: On 27 April 2010 11:20, Alexey Zakhlestin wrote: > yup. > it's a bit strange, that they couldn't compile php. > > I compile php with clang for several months (at least) and it just works Could be a temporary broken svn version. They could've waited until 2.7 was officially out, couldn't they? ;) cheers, --renato http://systemcall.org/ Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm From computerhenu at gmail.com Tue Apr 27 07:19:23 2010 From: computerhenu at gmail.com (=?UTF-8?B?546L5bu65Lic?=) Date: Tue, 27 Apr 2010 20:19:23 +0800 Subject: [cfe-dev] help: clang&LLVM Message-ID: Hi, I am new to LLVM&Clang.Now I'm confused by the unhelpful documentation online. What I'm expecting is to build my own bug checker using LLVM&Clang, but I haven't got through how to start it, even what an programming environment I need. Any help? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100427/a41c320d/attachment.html From landir at gmail.com Tue Apr 27 08:08:39 2010 From: landir at gmail.com (Lucas Silva) Date: Tue, 27 Apr 2010 09:08:39 -0400 Subject: [cfe-dev] broken link Message-ID: Hi for those who maintain the website: The link to download Clang source code is broken in http://llvm.org/releases/download.html#2.7 It opens http://llvm.org/releases/2.7/clang-2.7.tar.gz with a 404 not found page -- Lucas da Costa Silva @landir -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100427/a5a29675/attachment.html From daniel at zuster.org Tue Apr 27 09:42:29 2010 From: daniel at zuster.org (Daniel Dunbar) Date: Tue, 27 Apr 2010 07:42:29 -0700 Subject: [cfe-dev] [LLVMdev] Phoronix: Benchmarking LLVM & Clang Against GCC 4.5 In-Reply-To: <20100427133431.GA6170@bromo.med.uc.edu> References: <20100427133431.GA6170@bromo.med.uc.edu> Message-ID: We haven't spent much time on Clang code quality. The results are "interesting", but hardly surprising. This is something I hope to spend some time on in the upcoming months, FWIW. - Daniel On Tue, Apr 27, 2010 at 6:34 AM, Jack Howarth wrote: > On Tue, Apr 27, 2010 at 09:37:53AM +0100, Renato Golin wrote: >> On 27 April 2010 08:18, Stefano Delli Ponti >> wrote: >> > FYI >> > http://www.phoronix.com/scan.php?page=article&item=gcc_llvm_clang&num=1 >> >> For Apache and Dhrystone, the performance boost is good (but only the >> former is really important), but for the rest, especially those with >> image/sound processing, and HMMR, it's still far behind. Is this only >> because there is no auto vectorization in LLVM? > > Doesn't llvm-gcc still lack autovectorization support as well? It's > numbers are closer to the stock gcc releases suggesting the problem > isn't from the absence of vectorization, no? > ? ? ? ? ? Jack >> >> Would be good to know why some programs were not compiled with Clang. >> >> -- >> cheers, >> --renato >> >> http://systemcall.org/ >> >> Reclaim your digital rights, eliminate DRM, learn more at >> http://www.defectivebydesign.org/what_is_drm >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From daniel at zuster.org Tue Apr 27 09:53:13 2010 From: daniel at zuster.org (Daniel Dunbar) Date: Tue, 27 Apr 2010 07:53:13 -0700 Subject: [cfe-dev] little bug: comments swapped In-Reply-To: <4BD6A361.2010005@arcor.de> References: <4BD6A361.2010005@arcor.de> Message-ID: On Tue, Apr 27, 2010 at 1:42 AM, Jochen Wilhelmy wrote: > Hi! > > in CGRecordLayout.h > the comments for > > unsigned getLLVMFieldNo(const FieldDecl *FD) const > and > const CGBitFieldInfo &getBitFieldInfo(const FieldDecl *FD) const > > are swapped. Fixed. > It seems CGRecordLayout contains the info I need, > is there a way to access it after compilation to LLVM IR? I don't have enough context. If you have access to a CodeGenTypes instance, you can ask it for the record layouts. You haven't said what you are trying to do. :) - Daniel > -Jochen > > > > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > > From daniel at zuster.org Tue Apr 27 10:04:13 2010 From: daniel at zuster.org (Daniel Dunbar) Date: Tue, 27 Apr 2010 08:04:13 -0700 Subject: [cfe-dev] how to mapping from struct index to name In-Reply-To: <4BD5D5BB.4020408@arcor.de> References: <4BD5D5BB.4020408@arcor.de> Message-ID: Ah, this explains later message. Why do you want to do this? Are you prepared to handle bit-fields? - Daniel On Mon, Apr 26, 2010 at 11:04 AM, Jochen Wilhelmy wrote: > Hi! > > How can I find out the mapping between structure element names and index > used > in getelementptr? > If I have the following program: > > struct Foo > { > ? ? int i; > ? ? float j; > }; > > Foo foo; > > void main() > { > ? ? foo.j = 1.0f > } > > I get an instruction containing getelementptr (%Foo* @foo, i32 0, i32 1) > Member i is at index 0 and member j is at index 1. > This is what I want to find out. > Perhaps it can be done using debug info? > > -Jochen > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > From abramo.bagnara at gmail.com Tue Apr 27 10:40:48 2010 From: abramo.bagnara at gmail.com (Abramo Bagnara) Date: Tue, 27 Apr 2010 17:40:48 +0200 Subject: [cfe-dev] Attributes on statements and expressions In-Reply-To: <4BD680BB.3010801@gmail.com> References: <6F4C1B12-8A16-4FDD-B3E0-44F7A56AADF9@nasa.gov> <4BD27EE7.9040708@gmail.com> <4BD680BB.3010801@gmail.com> Message-ID: <4BD70580.7080506@gmail.com> Il 27/04/2010 08:14, Sean Hunt ha scritto: > On 04/26/2010 03:43 PM, Trevor Harmon wrote: >> Is your proposal available online somewhere? > > http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/llvm/t127230760878 > Have you considered the opportunity to store in the AST attribute also the attribute arguments expressions? This, together with the insertion of a generic attribute would permit to add arbitrary annotations to source code to be used by analysis client and other clients. The reason to have a regular expression AST for argument has two benefits: 1) the possibility to know the original syntactic form 2) the resolution of identifiers in the exact scope where they appeared From charlesneedspace at yahoo.com.ar Tue Apr 27 10:52:06 2010 From: charlesneedspace at yahoo.com.ar (Charllls Alquarra) Date: Tue, 27 Apr 2010 08:52:06 -0700 (PDT) Subject: [cfe-dev] prototyping c++ language extensions Message-ID: <777823.50604.qm@web63506.mail.re1.yahoo.com> >Clang is probably the best environment available to try such a thing. Of >course, with Clang, you would create a direct compiler instead of a >source-to-source translator. (My own plans for compile-time reflection will >also be prototyped in Clang.) wouldn't it possible to have a default/identity/trivial code generator that produces readable c++ code? The reason i think this is important is than in languages like java annotations change the code at compile time but doesn't necessarily makes that code available for important stuff like debugging for instance. A source-to-source translator would allow an user to check the result of its compile-time metaprograms as c++ code instead of some target that is hard to debug/understand, i've seen some comments on this mailing list that mention source-to-source translators but i'm not sure if they are for extending clang or rather their own projects >Note, though, that experiments probably won't be accepted back into >mainline unless they prove themselves. makes sense From dgregor at apple.com Tue Apr 27 11:09:30 2010 From: dgregor at apple.com (Douglas Gregor) Date: Tue, 27 Apr 2010 09:09:30 -0700 Subject: [cfe-dev] prototyping c++ language extensions In-Reply-To: <777823.50604.qm@web63506.mail.re1.yahoo.com> References: <777823.50604.qm@web63506.mail.re1.yahoo.com> Message-ID: <7817C143-B834-41F0-94CE-E7E70F25BD69@apple.com> On Apr 27, 2010, at 8:52 AM, Charllls Alquarra wrote: >> Clang is probably the best environment available to try such a thing. Of >> course, with Clang, you would create a direct compiler instead of a >> source-to-source translator. (My own plans for compile-time reflection will >> also be prototyped in Clang.) > > wouldn't it possible to have a default/identity/trivial code generator that produces readable c++ code? Translating a complete AST into parseable, readable C++ code is actually quite complicated. Clang may eventually get there (I hope it does!), but there is a lot of work to make that happen. > The reason i think this is important is than in languages like java annotations change the code at compile time but doesn't necessarily makes that code available for important stuff like debugging for instance. A source-to-source translator would allow an user to check the result of its compile-time metaprograms as c++ code instead of some target that is hard to debug/understand, Source-to-source translation is a double-edged sword. Yes, you can see the transformed code to figure out what it does, and that is helpful to understand or debug the transformation. That might be helpful to some people to understand/debug their extensions, although I personally have found it to be a hindrance. On the other hand, you *always* see the transformed code, even when you don't care about it. If your extensions end up becoming popular, your users will not want to see the transformed code, and the source-to-source translation step is going to get in their way. So, I don't recommend going the source-to-source translation route. That said... > i've seen some comments on this mailing list that mention source-to-source translators but i'm not sure if they are for extending clang or rather their own projects Clang has a Rewriter library that simplifies the task of rewriting parts of the source code without changing any of the surrounding code. For source-to-source translation that involves localized changes (e.g., replace some new language construct with some boilerplate code, add some attributes, etc.), the Rewriter is the best way to go. Check out the Objective-C rewriter to see how to use it. - Doug From zaffanella at cs.unipr.it Tue Apr 27 11:30:32 2010 From: zaffanella at cs.unipr.it (Enea Zaffanella) Date: Tue, 27 Apr 2010 18:30:32 +0200 Subject: [cfe-dev] Storing the NoReturn attribute in Decl nodes. Message-ID: <4BD71128.5050308@cs.unipr.it> Hello. As we are using clang as a base for a source-code based tool, one of our goals is to be able to obtain an AST faithfully representing the original source code. Among other things, we would like to have a precise description of the set of attributes adorning declarations, as well as the specific syntax (gnu, cxx0x, microsoft, ...) used to specify them. One simple option to encode this syntax-kind info would be to add a bitfield to the Attr base class: this will require no additional memory, since Attr already has a bitfield of length 1 (Inherited). However, we just discovered that, e.g., attribute NoReturn is not stored as usual in the list of attributes of the corresponding declaration, but it will rather end up in the FunctionType node, encoded as a single bit. This would prevent our tool from distinguishing, e.g., between void p [[ noreturn ]] (); and void p() __attribute__ ((__noreturn__)); Similarly, having it in the FunctionType probably means that there will be no Inherited bitfield to query, so that we would not be able to know if the attribute was written in this very declaration or in a previous declaration of the same function. Would it be acceptable if clang (also) adds this attribute to the list of attributes of the corresponding declaration, so that it could be queried like all other attributes? Note the we are NOT suggesting modification to FunctionType nodes, which will still encode the noreturn bit for any semantic reasoning; we are just asking to add some additional syntactic info where it belongs (the attributes of the Decl node). As an alternative, if you do not want to place it in the Decl node, it might be possible to store the NoReturnAttr node in the TypeSourceInfo. However, this seems to be an unnecessary complication. Regards, Enea Zaffanella. From howarth at bromo.med.uc.edu Tue Apr 27 08:34:31 2010 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Tue, 27 Apr 2010 09:34:31 -0400 Subject: [cfe-dev] [LLVMdev] Phoronix: Benchmarking LLVM & Clang Against GCC 4.5 In-Reply-To: References: Message-ID: <20100427133431.GA6170@bromo.med.uc.edu> On Tue, Apr 27, 2010 at 09:37:53AM +0100, Renato Golin wrote: > On 27 April 2010 08:18, Stefano Delli Ponti > wrote: > > FYI > > http://www.phoronix.com/scan.php?page=article&item=gcc_llvm_clang&num=1 > > For Apache and Dhrystone, the performance boost is good (but only the > former is really important), but for the rest, especially those with > image/sound processing, and HMMR, it's still far behind. Is this only > because there is no auto vectorization in LLVM? Doesn't llvm-gcc still lack autovectorization support as well? It's numbers are closer to the stock gcc releases suggesting the problem isn't from the absence of vectorization, no? Jack > > Would be good to know why some programs were not compiled with Clang. > > -- > cheers, > --renato > > http://systemcall.org/ > > Reclaim your digital rights, eliminate DRM, learn more at > http://www.defectivebydesign.org/what_is_drm > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From lattner at apple.com Tue Apr 27 11:41:39 2010 From: lattner at apple.com (Tanya Lattner) Date: Tue, 27 Apr 2010 09:41:39 -0700 Subject: [cfe-dev] [LLVMdev] broken link In-Reply-To: References: Message-ID: <46402EB6-01C9-4F7F-8318-0E1CFC3173AE@apple.com> Fixed. -Tanya On Apr 27, 2010, at 6:08 AM, Lucas Silva wrote: > Hi for those who maintain the website: > The link to download Clang source code is broken in http://llvm.org/releases/download.html#2.7 > It opens http://llvm.org/releases/2.7/clang-2.7.tar.gz with a 404 not found page > > -- > Lucas da Costa Silva > @landir > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100427/6d34076e/attachment.html From sorokin at rain.ifmo.ru Tue Apr 27 14:24:29 2010 From: sorokin at rain.ifmo.ru (Ivan Sorokin) Date: Tue, 27 Apr 2010 23:24:29 +0400 Subject: [cfe-dev] C++0x in clang Message-ID: <4BD739ED.6020602@rain.ifmo.ru> Just interesting. It is planned to implement C++0x features in clang? (As I understand, yes) When we will see first working C++0x features? In which order they will be implemented? Any thoughts about that? From dgregor at apple.com Tue Apr 27 14:43:48 2010 From: dgregor at apple.com (Douglas Gregor) Date: Tue, 27 Apr 2010 12:43:48 -0700 Subject: [cfe-dev] C++0x in clang In-Reply-To: <4BD739ED.6020602@rain.ifmo.ru> References: <4BD739ED.6020602@rain.ifmo.ru> Message-ID: <7153B4C9-F594-418D-9037-6C4CA3E2DB05@apple.com> On Apr 27, 2010, at 12:24 PM, Ivan Sorokin wrote: > Just interesting. > > It is planned to implement C++0x features in clang? (As I understand, yes) Yes, absolutely. > When we will see first working C++0x features? After the vast majority of C++98/03 code compiles well with Clang and we feel that we have a solid compiler, developers will probably turn their attention toward C++0x. > In which order they will > be implemented? Any thoughts about that? Rvalue references and variadic templates would be my top 2. - Doug From Trevor.W.Harmon at nasa.gov Tue Apr 27 16:35:59 2010 From: Trevor.W.Harmon at nasa.gov (Trevor Harmon) Date: Tue, 27 Apr 2010 14:35:59 -0700 Subject: [cfe-dev] Attributes on statements and expressions In-Reply-To: <4BD6A25F.4060709@tu-dresden.de> References: <6F4C1B12-8A16-4FDD-B3E0-44F7A56AADF9@nasa.gov> <4BD5435D.3000706@tu-dresden.de> <4BD6A25F.4060709@tu-dresden.de> Message-ID: <24B8B7FC-0227-49A9-851E-65F7B2A75BB8@nasa.gov> On Apr 27, 2010, at 1:37 AM, Olaf Krzikalla wrote: >> There's one thing I'm confused about, though. I assume it's possible >> to define my own attributes, e.g. [[mycoolattr(42)]]. But how exactly >> do I do that? Is there some sample code somewhere? > I don't know of examples. The FCD states that the behavior of > attributes > other than the predefined ones are implementation defined. That is you > can define your own attributes at will in the compiler implementation. I'm only familiar with the Java mechanism, which works like this: // Definition of custom attribute public @interface RequestForEnhancement { String synopsis(); String engineer() default "[unassigned]"; String date() default "[unimplemented]"; } // Use of custom attribute @RequestForEnhancement( synopsis = "Enable time-travel", engineer = "Mr. Peabody", date = "4/1/3007" ) public static void travelThroughTime(Date destination) { ... } The nice thing about this is that the annotation data is (optionally) embedded into the Java class file's metadata, and it can then be extracted by tools by means of a well-defined spec. Is there a way to do something similar to the above in C++0x? Trevor From anton.yartsev at gmail.com Tue Apr 27 13:22:21 2010 From: anton.yartsev at gmail.com (Anton Yartsev) Date: Tue, 27 Apr 2010 22:22:21 +0400 Subject: [cfe-dev] AltiVec support Message-ID: <4BD72B5D.3060404@Gmail.com> Hi all, This patch enables support of all the AltiVec functions from the PIM. Tests are also attached. -- Anton -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: altivec.patch Url: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100427/1a35c760/attachment-0002.pl -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: builtins-pcc-altivec.c Url: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100427/1a35c760/attachment-0001.c -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: builtins-pcc-altivec.cpp Url: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100427/1a35c760/attachment-0003.pl From thomas.gill at csr.com Wed Apr 28 02:09:44 2010 From: thomas.gill at csr.com (Ned Gill) Date: Wed, 28 Apr 2010 09:09:44 +0200 Subject: [cfe-dev] Re-targeting clang to a new architecture Message-ID: Hi all. I'm contemplating re-targeting clang to a new architecture. Initially I'd like to just port the front end as a static analysis tool to use alongside our existing GCC based toolchain, but ultimately I'd like to write a code generator too. Unfortunately my architecture has a couple of wrinkles that sometimes make life hard for compilers: CHAR_BIT is 16 (i.e. the minimum addressable unit of memory is 16 bits) It's a Harvard architecture with 16 bit data pointers and 24 bit function pointers. Does anyone have any thoughts on how difficult it would be to target clang to this sort of architecture - just as a front end (for now)? Thanks, Ned. p.s. I'm reading the group through gmane.org, in case that makes a difference to anyone -- Apologies for any crummy corporate signature appended here: From csdavec at swan.ac.uk Wed Apr 28 06:45:10 2010 From: csdavec at swan.ac.uk (David Chisnall) Date: Wed, 28 Apr 2010 12:45:10 +0100 Subject: [cfe-dev] Running passes from the clang driver Message-ID: Hi, Is there any support yet in the clang driver for running optimisation passes that are in a shared library, or do I still need to do the clang -c -emit-llvm, opt -load, llc, clang dance? On a related note, are there any plans to make the clang driver understand what to do when presented with bitcode files? It would be nice if we could do link-time optimisations without needing linker support just by adding -emit-llvm in CFLAGS and setting LD=clang. David -- Sent from my Difference Engine From dgregor at apple.com Wed Apr 28 09:50:16 2010 From: dgregor at apple.com (Douglas Gregor) Date: Wed, 28 Apr 2010 07:50:16 -0700 Subject: [cfe-dev] Re-targeting clang to a new architecture In-Reply-To: References: Message-ID: <1BCD32FE-9DF0-4750-9D3F-115178D46DC5@apple.com> On Apr 28, 2010, at 12:09 AM, Ned Gill wrote: > > Hi all. > > I'm contemplating re-targeting clang to a new architecture. Initially I'd > like to just port the front end as a static analysis tool to use alongside > our existing GCC based toolchain, but ultimately I'd like to write a code > generator too. Unfortunately my architecture has a couple of wrinkles > that sometimes make life hard for compilers: > > CHAR_BIT is 16 (i.e. the minimum addressable unit of memory is 16 bits) > It's a Harvard architecture with 16 bit data pointers and 24 bit function > pointers. > > Does anyone have any thoughts on how difficult it would be to target clang > to this sort of architecture - just as a front end (for now)? This came up on the list about 6 months ago, and the consensus was that it would be fairly tricky to do, since the "8 bits per char/byte" assumption pervades Clang and LLVM: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2009-September/006349.html Since then, there has been some work to make Clang depend on the target's character width rather than assuming it is 8 bits, so the situation has improved. I still expect it to be fairly tricky, but you aren't the only one interested in working on this particular issue in Clang. - Doug From thomas.gill at csr.com Wed Apr 28 10:03:32 2010 From: thomas.gill at csr.com (Ned Gill) Date: Wed, 28 Apr 2010 16:03:32 +0100 Subject: [cfe-dev] Re-targeting clang to a new architecture In-Reply-To: <1BCD32FE-9DF0-4750-9D3F-115178D46DC5@apple.com> References: <1BCD32FE-9DF0-4750-9D3F-115178D46DC5@apple.com> Message-ID: On Wed, 28 Apr 2010 15:50:16 +0100, Douglas Gregor wrote: >> CHAR_BIT is 16 (i.e. the minimum addressable unit of memory is 16 bits) >> It's a Harvard architecture with 16 bit data pointers and 24 bit >> function pointers. > > This came up on the list about 6 months ago, and the consensus was that > it would be fairly tricky to do, since the "8 bits per char/byte" > assumption pervades Clang and LLVM: > > http://lists.cs.uiuc.edu/pipermail/cfe-dev/2009-September/006349.html > > Since then, there has been some work to make Clang depend on the > target's character width rather than assuming it is 8 bits, so the > situation has improved. Thanks Doug. I guess my next step is to try it and see how far I get. Any thoughts on the different sizes of pointers? Ned. -- Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom From dgregor at apple.com Wed Apr 28 10:05:57 2010 From: dgregor at apple.com (Douglas Gregor) Date: Wed, 28 Apr 2010 08:05:57 -0700 Subject: [cfe-dev] Re-targeting clang to a new architecture In-Reply-To: References: <1BCD32FE-9DF0-4750-9D3F-115178D46DC5@apple.com> Message-ID: On Apr 28, 2010, at 8:03 AM, Ned Gill wrote: > On Wed, 28 Apr 2010 15:50:16 +0100, Douglas Gregor wrote: > >>> CHAR_BIT is 16 (i.e. the minimum addressable unit of memory is 16 bits) >>> It's a Harvard architecture with 16 bit data pointers and 24 bit function pointers. >> >> This came up on the list about 6 months ago, and the consensus was that it would be fairly tricky to do, since the "8 bits per char/byte" assumption pervades Clang and LLVM: >> >> http://lists.cs.uiuc.edu/pipermail/cfe-dev/2009-September/006349.html >> >> Since then, there has been some work to make Clang depend on the target's character width rather than assuming it is 8 bits, so the situation has improved. > > Thanks Doug. I guess my next step is to try it and see how far I get. > > Any thoughts on the different sizes of pointers? Those won't be a problem; Clang already handles different pointer sizes. - Doug From thomas.gill at csr.com Wed Apr 28 10:10:20 2010 From: thomas.gill at csr.com (Ned Gill) Date: Wed, 28 Apr 2010 16:10:20 +0100 Subject: [cfe-dev] Re-targeting clang to a new architecture In-Reply-To: References: <1BCD32FE-9DF0-4750-9D3F-115178D46DC5@apple.com> Message-ID: On Wed, 28 Apr 2010 16:05:57 +0100, Douglas Gregor wrote: >> Any thoughts on the different sizes of pointers? > > Those won't be a problem; Clang already handles different pointer sizes. Thanks Doug. Time for me to get hacking :) Ned. -- Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom From pocmatos at gmail.com Wed Apr 28 13:18:59 2010 From: pocmatos at gmail.com (Paulo J. Matos) Date: Wed, 28 Apr 2010 19:18:59 +0100 Subject: [cfe-dev] Re-targeting clang to a new architecture In-Reply-To: (Douglas Gregor's message of "Wed, 28 Apr 2010 08:05:57 -0700") References: <1BCD32FE-9DF0-4750-9D3F-115178D46DC5@apple.com> Message-ID: <841vdzzbho.fsf@gmail.com> Douglas Gregor writes: >>> >>> Since then, there has been some work to make Clang depend on the target's character width rather than assuming it is 8 bits, so the situation has improved. >> >> Any thoughts on the different sizes of pointers? > > > Those won't be a problem; Clang already handles different pointer sizes. All in all, this seems to be positive news for Ned. Any news on how far Ray Fix is with the changes to LLVM regarding the 16bit char? Another more general question for the LLVM maintainers, would they be interested in these changes? Would they integrate possible changes regarding this upstream? (assume they would actually make LLVM independent of the char size instead of just changing the dependency from 8bit to 16bit)? If yes, are there any licensing gotchas regarding integrating patches upstream? Cheers, -- PMatos From clattner at apple.com Wed Apr 28 15:03:43 2010 From: clattner at apple.com (Chris Lattner) Date: Wed, 28 Apr 2010 13:03:43 -0700 Subject: [cfe-dev] [PATCH] add regex/globbing to -verify diagnostics In-Reply-To: References: <87mxwrzccr.fsf@justinbogner.com> <931E5657-3E1B-4236-8E59-BF1E10E90B19@gmail.com> Message-ID: <26D36CA4-C93F-42EA-B7CF-C47656256E40@apple.com> looks great to me, applied in r102516, thanks! On Apr 26, 2010, at 9:49 PM, mike-m wrote: > Hi Chris, thanks for taking a look at this patch. > > Patch is updated to your specs and attached. Summary of changes since last iteration: > > - removed globbing support > - invalid regex now reports proper diagnostic instead of using assert mechanism > - reworked "\\n" -> '\n' substitution with StringRef > - parameterized various verify diagnostic error definitions for { string | regex } differentiation > > Existing lit tests show no measurable performance impact. > > --mike-m > > > On 2010-04-26, at 5:41 PM, Chris Lattner wrote: > >> On Apr 25, 2010, at 10:36 PM, mike-m wrote: >>> Patch update uses suggested '-re' and '-glob' syntax, patch attached. >>> >>> - lit tests pass with clang-debug, clang-release and selfclang-debug builds >>> - no measurable performance impact on lit tests >> >> I also prefer the "-re" suffix, thanks for doing that. >> >> This is really cool, but I think it's a bit overkill. I'd rather not support glob at all, it adds a bunch of complexity for no added advantage. >> >> You converted some loops like this: >> >> - std::string Msg(CommentStart, ExpectedEnd); >> - std::string::size_type FindPos; >> - while ((FindPos = Msg.find("\\n")) != std::string::npos) >> - Msg.replace(FindPos, 2, "\n"); >> - // Add is possibly multiple times. >> - for (int i = 0; i < Times; ++i) >> - ExpectedDiags.push_back(std::make_pair(Pos, Msg)); >> >> to explicit for loops with switches in them. If you're going to change them, please convert them to using the StringRef API and its algorithms. >> >> It looks like using an invalid regex in an directive line will cause an assertion, pleasem ake it be an error from -verify mode. >> >> Thanks for working on this! >> >> -Chris > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From clattner at apple.com Wed Apr 28 15:20:55 2010 From: clattner at apple.com (Chris Lattner) Date: Wed, 28 Apr 2010 13:20:55 -0700 Subject: [cfe-dev] asserts In-Reply-To: References: Message-ID: <80ABD658-1934-4F96-8B4D-B5BD438B252C@apple.com> On Apr 21, 2010, at 3:35 PM, John Thompson wrote: > I'm getting a couple of asserts, one from the assert in Sema::ActOnNumericConstant at line 1897, the other in a separate case in the APInt::trunc call because the argument is bigger than the width. Hi John, I don't understand why this is a bug, can you give a testcase? > > These two changes seem to avoid the asserts, I'm not sure it's the right fix: > > Index: lib/Sema/SemaExpr.cpp > =================================================================== > --- lib/Sema/SemaExpr.cpp (revision 102026) > +++ lib/Sema/SemaExpr.cpp (working copy) > @@ -1885,7 +1885,10 @@ > Diag(Tok.getLocation(), diag::ext_longlong); > > // Get the value in the widest-possible width. > - llvm::APInt ResultVal(Context.Target.getIntMaxTWidth(), 0); > + llvm::APInt ResultVal( > + Literal.isLongLong ? > + Context.Target.getLongLongWidth() : > + Context.Target.getIntMaxTWidth(), 0); > > if (Literal.GetIntegerValue(ResultVal)) { > // If this value didn't fit into uintmax_t, warn and force to ull. > @@ -1956,8 +1959,12 @@ > Width = Context.Target.getLongLongWidth(); > } > > - if (ResultVal.getBitWidth() != Width) > - ResultVal.trunc(Width); > + if (ResultVal.getBitWidth() != Width) { > + if (Literal.isUnsigned) > + ResultVal.zextOrTrunc(Width); > + else > + ResultVal.sextOrTrunc(Width); > + } > } > Res = new (Context) IntegerLiteral(ResultVal, Ty, Tok.getLocation()); > } > > > -- > John Thompson > John.Thompson.JTSoftware at gmail.com > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100428/6ec5a99b/attachment.html From dgregor at apple.com Wed Apr 28 17:19:44 2010 From: dgregor at apple.com (Douglas Gregor) Date: Wed, 28 Apr 2010 15:19:44 -0700 Subject: [cfe-dev] Patch proposal for __builtin_offsetof construct. In-Reply-To: <4BD0A3CA.2050904@virgilio.it> References: <4BC83D56.4050106@virgilio.it> <41C8B229-2FAD-4F34-B024-E481F07C7B50@apple.com> <4BD0A3CA.2050904@virgilio.it> Message-ID: <47C3E661-8109-4C41-8628-0E7F611F0144@apple.com> On Apr 22, 2010, at 12:30 PM, Roberto Amadini wrote: > Douglas Gregor ha scritto: >> On Apr 16, 2010, at 3:35 AM, Roberto Amadini wrote: >> >> >>> Hi, >>> >>> I'm the student who is trying to fix the problem mentioned in >>> http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-February/007833.html . >>> > [...] >>> Index: include/clang/AST/Expr.h >>> =================================================================== >>> --- include/clang/AST/Expr.h (revisione 100962) >>> +++ include/clang/AST/Expr.h (copia locale) >>> @@ -991,6 +985,78 @@ >>> > [...] >>> +public: >>> + // __builtin_offsetof(type, identifier(.identifier|[expr])*) >>> + // FIXME: Type-dependent case ignored. >>> + struct OffsetOfNode { >>> + SourceLocation LocStart, LocEnd; >>> + bool isBrackets; // true if [expr], false if .ident >>> + union { >>> + FieldDecl *MemberDecl; >>> + Expr *IndexExpr; >>> + } U; >>> + }; >>> >> >> You could save a word of storage per OffsetOfNode by mangling the "isBrackets" bit into the lowest bit of the FieldDecl or Expr pointer. llvm::PointerUnion will do this for you. >> >> But, see below for more comments on this representation. >> > In Order to have Expr*'s in contiguous memory, I replaced *IndexExpr > field with an unsigned integer ExprIndex, which represents the index of the > corresponding Expr* in the array of subscript expressions: in this way, I can't > use a PointerUnion, or not? Correct. PointerUnion won't help here. Instead, I played more fun tricks by using the lower two bits of a pointer-sized integer as a descriminator. For a FieldDecl*, we mask off those bits and cast the type; for an expression index, we shift away those bits. >>> Index: lib/AST/StmtProfile.cpp >>> =================================================================== >>> --- lib/AST/StmtProfile.cpp (revisione 100962) >>> +++ lib/AST/StmtProfile.cpp (copia locale) >>> @@ -261,6 +261,10 @@ >>> ID.AddInteger(S->getOpcode()); >>> } >>> >>> +void StmtProfiler::VisitOffsetOfExpr(OffsetOfExpr *S) { >>> + VisitExpr(S); >>> +} >>> + >>> >> >> To profile an OffsetOfExpr, we'll need to visit the type and all of the OffsetOfNodes as well. That way, we can distinguish between different OffsetOfExprs on the same base type. >> >> > Ok, but I have a doubt: VisitExpr(S) visits recursively all the sub-expressions, > thus I think that I haven't to explicitly visit such expressions while I'm iterating on > OffsetOfNodes array for declarations visit... Or not? Right. VisitStmt(S) will get the subexpressions, but it won't get the field declarations. >> Overall, this is a great start on __builtin_offsetof, thanks! I look forward to seeing a revised patch. >> >> - Doug >> > Thanks for your comments! I tried to follow your advices... > I attached a new patch which refers to revision no. 102050. This is great. I've committed a modified version of your patch, where I compressed the storage of OffsetOfNode a bit and added support for template instantiation and precompiled headers. Since we already had __builtin_offsetof that somewhat worked, everything had to go in at once. Here's what I ended up doing: - Implemented the bit-mangled encoding I described above, to shrink the size of OffsetOfNode. Added accessors/constructors to OffsetOfNode, so that the representation is hidden. - Simplified the pointer arithmetic inside OffsetOfExpr. - Added support for templates: - OffsetOfNode now has an "Identifier", for the case where the offsetof designates a field but we can't look up the field yet (since the record type is dependent). - Reorganized semantic checking so that it copes with dependent types. - Added template instantiation logic - Added support for reading/writer OffsetOfExpr to precompiled headers The commit is here: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20100426/029847.html Thanks for working on this! - Doug From ponnala.kalyan at gmail.com Wed Apr 28 17:36:15 2010 From: ponnala.kalyan at gmail.com (kalyan ponnala) Date: Wed, 28 Apr 2010 18:36:15 -0400 Subject: [cfe-dev] Adding new data type Message-ID: Hello Group, I am trying to add a new data type to clang. Can someone tell me the important files and classes to look into and how to start in order to lex and parse and generate an AST node to this new data type. Thanks -- Kalyan Ponnala phone: 8163772059 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100428/3eb0c0b5/attachment.html From john.thompson.jtsoftware at gmail.com Wed Apr 28 20:01:40 2010 From: john.thompson.jtsoftware at gmail.com (John Thompson) Date: Wed, 28 Apr 2010 18:01:40 -0700 Subject: [cfe-dev] asserts In-Reply-To: <80ABD658-1934-4F96-8B4D-B5BD438B252C@apple.com> References: <80ABD658-1934-4F96-8B4D-B5BD438B252C@apple.com> Message-ID: It looks like it might be a targets problem, as I only see it with -targets ppu-unknown-lv2: File: long long value = 0LL; Command line: clang -cc1 -targets ppu-unknown-lv2 file.cpp Any idea? -John On Wed, Apr 28, 2010 at 1:20 PM, Chris Lattner wrote: > > On Apr 21, 2010, at 3:35 PM, John Thompson wrote: > > I'm getting a couple of asserts, one from the assert in > Sema::ActOnNumericConstant at line 1897, the other in a separate case in the > APInt::trunc call because the argument is bigger than the width. > > > Hi John, > > I don't understand why this is a bug, can you give a testcase? > > > These two changes seem to avoid the asserts, I'm not sure it's the right > fix: > > Index: lib/Sema/SemaExpr.cpp > =================================================================== > --- lib/Sema/SemaExpr.cpp (revision 102026) > +++ lib/Sema/SemaExpr.cpp (working copy) > @@ -1885,7 +1885,10 @@ > Diag(Tok.getLocation(), diag::ext_longlong); > > // Get the value in the widest-possible width. > - llvm::APInt ResultVal(Context.Target.getIntMaxTWidth(), 0); > + llvm::APInt ResultVal( > + Literal.isLongLong ? > + Context.Target.getLongLongWidth() : > + Context.Target.getIntMaxTWidth(), 0); > > if (Literal.GetIntegerValue(ResultVal)) { > // If this value didn't fit into uintmax_t, warn and force to ull. > @@ -1956,8 +1959,12 @@ > Width = Context.Target.getLongLongWidth(); > } > > - if (ResultVal.getBitWidth() != Width) > - ResultVal.trunc(Width); > + if (ResultVal.getBitWidth() != Width) { > + if (Literal.isUnsigned) > + ResultVal.zextOrTrunc(Width); > + else > + ResultVal.sextOrTrunc(Width); > + } > } > Res = new (Context) IntegerLiteral(ResultVal, Ty, Tok.getLocation()); > } > > > -- > John Thompson > John.Thompson.JTSoftware at gmail.com > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > > > -- John Thompson John.Thompson.JTSoftware at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100428/7929a05e/attachment-0001.html From sanxiyn at gmail.com Thu Apr 29 01:50:04 2010 From: sanxiyn at gmail.com (Seo Sanghyeon) Date: Thu, 29 Apr 2010 15:50:04 +0900 Subject: [cfe-dev] help: clang&LLVM In-Reply-To: References: Message-ID: 2010/4/27 ??? : > Hi, I am new to LLVM&Clang.Now I'm confused by the unhelpful documentation > online. What I'm expecting is to build my own bug checker using LLVM&Clang, > but I haven't got through how to start it, even what an programming > environment I need. > Any help? Thanks. Have you looked at this? http://clang-analyzer.llvm.org/ -- Seo Sanghyeon From computerhenu at gmail.com Thu Apr 29 01:55:56 2010 From: computerhenu at gmail.com (Jiandong Wang) Date: Thu, 29 Apr 2010 14:55:56 +0800 Subject: [cfe-dev] help: clang&LLVM In-Reply-To: References: Message-ID: thanks. I'll have a look. > > Have you looked at this? > http://clang-analyzer.llvm.org/ > > -- > Seo Sanghyeon > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100429/3851d36d/attachment.html From rengolin at systemcall.org Thu Apr 29 03:06:25 2010 From: rengolin at systemcall.org (Renato Golin) Date: Thu, 29 Apr 2010 09:06:25 +0100 Subject: [cfe-dev] Adding new data type In-Reply-To: References: Message-ID: On 28 April 2010 23:36, kalyan ponnala wrote: > Hello Group, > > I am trying to add a new data type to clang. Can someone tell me the > important files and classes to look into and how to start in order to lex > and parse and generate an AST node to this new data type. First you have to add the new type to the Type hierarchy. See include/llvm/Type.h and its derived classes, find a suitable spot and implement it. Then you have to change the type handlers in clang to, based on the source's type, add your custom type to the AST. I'm not sure that LLVM's subsequent passes will recognize all properties of your new type, but I guess if you build it well enough, it might go on unnoticed. Out of curiosity, what is this new type you need? cheers, --renato http://systemcall.org/ Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm From zaffanella at cs.unipr.it Thu Apr 29 04:02:43 2010 From: zaffanella at cs.unipr.it (Enea Zaffanella) Date: Thu, 29 Apr 2010 11:02:43 +0200 Subject: [cfe-dev] QualifiedNameType generated for a dependent type name. Message-ID: <4BD94B33.4000708@cs.unipr.it> Hello. It seems that clang (r102496) sometimes generates a QualifiedNameType (which is meant to be a non-dependent type) when a DependentNameType should be expected. Consider the following program fragment: ================= template struct S { class Inner {}; Inner a_method(); }; template typename S::Inner a_function(); template typename S::Inner S::a_method() {} ================= Both return types for a_function() and a_method() are type dependent, hence they should be encoded by a DependentNameType. However, it seems that a QualifiedNameType is generated for a_method(). I don't know how to obtain a detailed description of the AST produced by clang ... since AST type nodes seems to be just printed rather than dumped. Anyway, even with the -ast-print option, it can be seen that the out-of-line definition of a_method() is missing the "typename" keyword. $ llvm/Debug/bin/clang++ -cc1 -ast-print bug.cc [...] template typename S::Inner a_function(); S::Inner a_method() { } Regards, Enea Zaffanella. From joe at alacatialabs.com Thu Apr 29 07:08:23 2010 From: joe at alacatialabs.com (Joe Ranieri) Date: Thu, 29 Apr 2010 08:08:23 -0400 Subject: [cfe-dev] Silencing an analyzer warning Message-ID: <4BD976B7.6080309@alacatialabs.com> CURL *handle = curl_easy_init(); RequestInfo *result = [[[RequestInfo alloc] init] autorelease]; // Keep a pointer to this object around so that curl can give it back to us in callbacks curl_easy_setopt(handle, CURLOPT_PRIVATE, CFRetain(result))); The static analyzer tells us that result is leaked (which, without it knowing about curl, it does look like). However, it's not actually being leaked and gets cleaned up later when we clean up the CURL handle. Is there any way to silence this analyzer warning? We'd like to get our project analyzer-warning free and require no warnings before committing things. -- Joe Ranieri From j.wilhelmy at arcor.de Thu Apr 29 08:04:34 2010 From: j.wilhelmy at arcor.de (Jochen Wilhelmy) Date: Thu, 29 Apr 2010 15:04:34 +0200 Subject: [cfe-dev] how to mapping from struct index to name In-Reply-To: References: <4BD5D5BB.4020408@arcor.de> Message-ID: <4BD983E2.1020809@arcor.de> Hi! > Why do you want to do this? Are you prepared to handle bit-fields? > bit-fields will not appear in my input code. If llvm ir accesses a field (only bool, int or float) i want to find out the field name. But seems i can copy the implementation of CodeGeneratorImpl in ModuleBuilder.cpp and then access the CodeGenTypes. -Jochen From Ken.Dyck at onsemi.com Thu Apr 29 09:26:02 2010 From: Ken.Dyck at onsemi.com (Ken Dyck) Date: Thu, 29 Apr 2010 07:26:02 -0700 Subject: [cfe-dev] Re-targeting clang to a new architecture In-Reply-To: <841vdzzbho.fsf@gmail.com> References: <1BCD32FE-9DF0-4750-9D3F-115178D46DC5@apple.com> <841vdzzbho.fsf@gmail.com> Message-ID: <8F2E4A8BCDA0B84DA6C9088EB5B27747017ECCA2@NAMAIL.ad.onsemi.com> On Wednesday, April 28, 2010 2:19 PM, Paulo J. Matos wrote: >>> On Wednesday, April 28, 2010 10:50 AM, Douglas Gregor wrote: >>>> Since then, there has been some work to >>>> make Clang depend on the target's character >>>> width rather than assuming it is 8 bits, so >>>> the situation has improved. There is still a significant amount of work left to do here. I plan to get back to work on this in the next couple of months. > All in all, this seems to be positive news > for Ned. Any news on how > far Ray Fix is with the changes to LLVM > regarding the 16bit char? When I last talked to Ray he told me that the project on which he was working switched from LLVM to another technology, so I wouldn't expect anything to come from him anytime soon. I have been working on a back end for a machine with 24-bit word-addressable memory and have made numerous changes to a private branch of LLVM to support word-addressable memory (and non-power-of-2-sized native integer types, fwiw). I intend to contribute these changes back to the mainline eventually. In the meantime, I could make a patch available here or the llvm-dev list if anybody is interested in seeing this work in progress (but probably not until next week when I update to the 2.7 release). -Ken From j.wilhelmy at arcor.de Thu Apr 29 09:51:53 2010 From: j.wilhelmy at arcor.de (Jochen Wilhelmy) Date: Thu, 29 Apr 2010 16:51:53 +0200 Subject: [cfe-dev] how to mapping from struct index to name In-Reply-To: References: <4BD5D5BB.4020408@arcor.de> Message-ID: <4BD99D09.30604@arcor.de> Hi! For me it would be convenient if CodeGeneratorImpl is visible in a header file instead of being hidden in an anonymous namespace. -Jochen From pocmatos at gmail.com Thu Apr 29 09:50:57 2010 From: pocmatos at gmail.com (Paulo J. Matos) Date: Thu, 29 Apr 2010 15:50:57 +0100 Subject: [cfe-dev] Re-targeting clang to a new architecture In-Reply-To: <8F2E4A8BCDA0B84DA6C9088EB5B27747017ECCA2@NAMAIL.ad.onsemi.com> (Ken Dyck's message of "Thu, 29 Apr 2010 07:26:02 -0700") References: <1BCD32FE-9DF0-4750-9D3F-115178D46DC5@apple.com> <841vdzzbho.fsf@gmail.com> <8F2E4A8BCDA0B84DA6C9088EB5B27747017ECCA2@NAMAIL.ad.onsemi.com> Message-ID: "Ken Dyck" writes: > In the meantime, I could > make a patch available here or the llvm-dev list if anybody is > interested in seeing this work in progress (but probably not until next > week when I update to the 2.7 release). > Yes, it would be great it you could do that. Thanks, -- PMatos From dgregor at apple.com Thu Apr 29 11:16:02 2010 From: dgregor at apple.com (Douglas Gregor) Date: Thu, 29 Apr 2010 09:16:02 -0700 Subject: [cfe-dev] QualifiedNameType generated for a dependent type name. In-Reply-To: <4BD94B33.4000708@cs.unipr.it> References: <4BD94B33.4000708@cs.unipr.it> Message-ID: <48ABEFAA-68FD-490C-9B94-C24E62C8C073@apple.com> On Apr 29, 2010, at 2:02 AM, Enea Zaffanella wrote: > Hello. > > It seems that clang (r102496) sometimes generates a QualifiedNameType > (which is meant to be a non-dependent type) when a DependentNameType > should be expected. > > Consider the following program fragment: > ================= > template > struct S { > class Inner {}; > Inner a_method(); > }; > > template > typename S::Inner a_function(); > > template > typename S::Inner > S::a_method() {} > ================= > > Both return types for a_function() and a_method() are type dependent, > hence they should be encoded by a DependentNameType. However, it seems > that a QualifiedNameType is generated for a_method(). The name DependentNameType is slightly misleading. It represents dependent types that refer to a member of an unknown specialization, meaning that we can't resolve them to an actual type until we instantiate. With the example you've given, we know that Inner is a member of the current instantiation, so it is correct to use QualifiedNameType. > I don't know how to obtain a detailed description of the AST produced by > clang ... since AST type nodes seems to be just printed rather than > dumped. Anyway, even with the -ast-print option, it can be seen that the > out-of-line definition of a_method() is missing the "typename" keyword. Right. We don't keep track of whether typename was written in the QualifiedNameType, but we should. > $ llvm/Debug/bin/clang++ -cc1 -ast-print bug.cc > [...] > template typename S::Inner a_function(); > S::Inner a_method() { > } > > > Regards, > Enea Zaffanella. > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From dgregor at apple.com Thu Apr 29 11:21:02 2010 From: dgregor at apple.com (Douglas Gregor) Date: Thu, 29 Apr 2010 09:21:02 -0700 Subject: [cfe-dev] Storing the NoReturn attribute in Decl nodes. In-Reply-To: <4BD71128.5050308@cs.unipr.it> References: <4BD71128.5050308@cs.unipr.it> Message-ID: Sent from my iPhone On Apr 27, 2010, at 9:30 AM, Enea Zaffanella wrote: > Hello. > > As we are using clang as a base for a source-code based tool, one of our > goals is to be able to obtain an AST faithfully representing the > original source code. > > Among other things, we would like to have a precise description of the > set of attributes adorning declarations, as well as the specific syntax > (gnu, cxx0x, microsoft, ...) used to specify them. One simple option to > encode this syntax-kind info would be to add a bitfield to the Attr base > class: this will require no additional memory, since Attr already has a > bitfield of length 1 (Inherited). > > However, we just discovered that, e.g., attribute NoReturn is not stored > as usual in the list of attributes of the corresponding declaration, but > it will rather end up in the FunctionType node, encoded as a single > bit. This would prevent our tool from distinguishing, e.g., between > void p [[ noreturn ]] (); > and > void p() __attribute__ ((__noreturn__)); > > Similarly, having it in the FunctionType probably means that there will > be no Inherited bitfield to query, so that we would not be able to know > if the attribute was written in this very declaration or in a previous > declaration of the same function. > > Would it be acceptable if clang (also) adds this attribute to the list > of attributes of the corresponding declaration, so that it could be > queried like all other attributes? Yes, this would be good. Patch pre-approved :) > Note the we are NOT suggesting modification to FunctionType nodes, which > will still encode the noreturn bit for any semantic reasoning; we are > just asking to add some additional syntactic info where it belongs (the > attributes of the Decl node). > > As an alternative, if you do not want to place it in the Decl node, it > might be possible to store the NoReturnAttr node in the TypeSourceInfo. > However, this seems to be an unnecessary complication. This is too complicated. It belongs on the Decl. > Regards, > Enea Zaffanella. > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From kremenek at apple.com Thu Apr 29 11:21:32 2010 From: kremenek at apple.com (Ted Kremenek) Date: Thu, 29 Apr 2010 09:21:32 -0700 Subject: [cfe-dev] Silencing an analyzer warning In-Reply-To: <4BD976B7.6080309@alacatialabs.com> References: <4BD976B7.6080309@alacatialabs.com> Message-ID: <1EE94938-F93A-46C9-9FAE-CC62AF92CF51@apple.com> There is currently no good way to silence warnings using attributes or pragmas, but you should be able to get around the issue with a wrapper function: static inline CFTypeRef CFRetainForCurl(CFTypeRef obj) { CFRetain(obj); return obj; } ... curl_easy_setopt(handle, CURLOPT_PRIVATE, CFRetainForCurl(result)); This isn't a permanent solution; it's essentially relying on a deficiency in the analyzer when it comes to wrapper functions (and so eventually a leak will be reported for this case as well). However, the plan is to eventually add pragma support (or something like that) to silence specific analyzer warnings. On Apr 29, 2010, at 5:08 AM, Joe Ranieri wrote: > CURL *handle = curl_easy_init(); > RequestInfo *result = [[[RequestInfo alloc] init] autorelease]; > > // Keep a pointer to this object around so that curl can give it back to > us in callbacks > curl_easy_setopt(handle, CURLOPT_PRIVATE, CFRetain(result))); > > > The static analyzer tells us that result is leaked (which, without it > knowing about curl, it does look like). However, it's not actually being > leaked and gets cleaned up later when we clean up the CURL handle. Is > there any way to silence this analyzer warning? We'd like to get our > project analyzer-warning free and require no warnings before committing > things. > > -- Joe Ranieri > _______________________________________________ > 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 Apr 29 11:45:42 2010 From: rjmccall at apple.com (John McCall) Date: Thu, 29 Apr 2010 09:45:42 -0700 Subject: [cfe-dev] Adding new data type In-Reply-To: References: Message-ID: On Apr 29, 2010, at 1:06 AM, Renato Golin wrote: > On 28 April 2010 23:36, kalyan ponnala wrote: >> Hello Group, >> >> I am trying to add a new data type to clang. Can someone tell me the >> important files and classes to look into and how to start in order to lex >> and parse and generate an AST node to this new data type. > > First you have to add the new type to the Type hierarchy. See > include/llvm/Type.h and its derived classes, find a suitable spot and > implement it. I think you mean include/clang/AST/Type.h. But changes to the type system can be very subtle; Kalyan, if you can be more specific about what type you're thinking of adding, we can give better advice. There isn't much internal documentation on adding a type. John. From jyasskin at google.com Thu Apr 29 12:02:34 2010 From: jyasskin at google.com (Jeffrey Yasskin) Date: Thu, 29 Apr 2010 10:02:34 -0700 Subject: [cfe-dev] Silencing an analyzer warning In-Reply-To: <1EE94938-F93A-46C9-9FAE-CC62AF92CF51@apple.com> References: <4BD976B7.6080309@alacatialabs.com> <1EE94938-F93A-46C9-9FAE-CC62AF92CF51@apple.com> Message-ID: Wouldn't it make more sense to add annotations to the analyzer so that users can annotate that curl_easy_setopt steals a reference from its third argument or that the caller promises to release that argument at the same time as they release 'handle'? Then the analyzer would have enough information to complain when a caller _forgot_ to CFRetain that argument, instead of just hiding both kinds of mistakes. Obviously an escape hatch is useful too, for cases that don't have analyzer support yet, but it shouldn't be the long-term fix. Jeffrey On Thu, Apr 29, 2010 at 9:21 AM, Ted Kremenek wrote: > There is currently no good way to silence warnings using attributes or pragmas, but you should be able to get around the issue with a wrapper function: > > ?static inline CFTypeRef CFRetainForCurl(CFTypeRef obj) { CFRetain(obj); ?return obj; } > ?... > ?curl_easy_setopt(handle, CURLOPT_PRIVATE, CFRetainForCurl(result)); > > This isn't a permanent solution; it's essentially relying on a deficiency in the analyzer when it comes to wrapper functions (and so eventually a leak will be reported for this case as well). ?However, the plan is to eventually add pragma support (or something like that) to silence specific analyzer warnings. > > On Apr 29, 2010, at 5:08 AM, Joe Ranieri wrote: > >> CURL *handle = curl_easy_init(); >> RequestInfo *result = [[[RequestInfo alloc] init] autorelease]; >> >> // Keep a pointer to this object around so that curl can give it back to >> us in callbacks >> curl_easy_setopt(handle, CURLOPT_PRIVATE, CFRetain(result))); >> >> >> The static analyzer tells us that result is leaked (which, without it >> knowing about curl, it does look like). However, it's not actually being >> leaked and gets cleaned up later when we clean up the CURL handle. Is >> there any way to silence this analyzer warning? We'd like to get our >> project analyzer-warning free and require no warnings before committing >> things. >> >> -- Joe Ranieri >> _______________________________________________ >> cfe-dev mailing list >> cfe-dev at cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > From kremenek at apple.com Thu Apr 29 12:13:32 2010 From: kremenek at apple.com (Ted Kremenek) Date: Thu, 29 Apr 2010 10:13:32 -0700 Subject: [cfe-dev] Silencing an analyzer warning In-Reply-To: References: <4BD976B7.6080309@alacatialabs.com> <1EE94938-F93A-46C9-9FAE-CC62AF92CF51@apple.com> Message-ID: <50B1F866-3651-4E24-8125-20A6E57DF39A@apple.com> Yes, an annotation would make more sense in this case. This particular checker employs has the cf_retains_retained and ns_returns_retained attributes to make it smarter about return values. This case is a little trickier, however, as it isn't a blanket property of curl_easy_setopt, but in how it is used in this particular instance. On Apr 29, 2010, at 10:02 AM, Jeffrey Yasskin wrote: > Wouldn't it make more sense to add annotations to the analyzer so that > users can annotate that curl_easy_setopt steals a reference from its > third argument or that the caller promises to release that argument at > the same time as they release 'handle'? Then the analyzer would have > enough information to complain when a caller _forgot_ to CFRetain that > argument, instead of just hiding both kinds of mistakes. > > Obviously an escape hatch is useful too, for cases that don't have > analyzer support yet, but it shouldn't be the long-term fix. > > Jeffrey > > On Thu, Apr 29, 2010 at 9:21 AM, Ted Kremenek wrote: >> There is currently no good way to silence warnings using attributes or pragmas, but you should be able to get around the issue with a wrapper function: >> >> static inline CFTypeRef CFRetainForCurl(CFTypeRef obj) { CFRetain(obj); return obj; } >> ... >> curl_easy_setopt(handle, CURLOPT_PRIVATE, CFRetainForCurl(result)); >> >> This isn't a permanent solution; it's essentially relying on a deficiency in the analyzer when it comes to wrapper functions (and so eventually a leak will be reported for this case as well). However, the plan is to eventually add pragma support (or something like that) to silence specific analyzer warnings. >> >> On Apr 29, 2010, at 5:08 AM, Joe Ranieri wrote: >> >>> CURL *handle = curl_easy_init(); >>> RequestInfo *result = [[[RequestInfo alloc] init] autorelease]; >>> >>> // Keep a pointer to this object around so that curl can give it back to >>> us in callbacks >>> curl_easy_setopt(handle, CURLOPT_PRIVATE, CFRetain(result))); >>> >>> >>> The static analyzer tells us that result is leaked (which, without it >>> knowing about curl, it does look like). However, it's not actually being >>> leaked and gets cleaned up later when we clean up the CURL handle. Is >>> there any way to silence this analyzer warning? We'd like to get our >>> project analyzer-warning free and require no warnings before committing >>> things. >>> >>> -- Joe Ranieri >>> _______________________________________________ >>> 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 ponnala.kalyan at gmail.com Thu Apr 29 15:35:56 2010 From: ponnala.kalyan at gmail.com (kalyan ponnala) Date: Thu, 29 Apr 2010 16:35:56 -0400 Subject: [cfe-dev] Adding new data type In-Reply-To: References: Message-ID: Hi guys, Thanks for the replies. I am trying to add support to a new architecture called Line Associative Registers. It has vector registers in it. I would like to add a vector data type such as int[4] which could access a register with a width of 4 integers in it (max). Since it has to be mentioned in the source as int[4] = {1, 2, 3, 4} I am not sure about how to proceed. This form looks like an array with 4 elements but I want it to be a datatype. I was looking into targetinfo.h and initpreprocessor.cpp. it looks like I can add a new type here or change the existing one. And about the type.h in ClangAST target, will it work if I added this type here. Any advices about how to proceed would be really appreciated. Thanks again. On Thu, Apr 29, 2010 at 12:45 PM, John McCall wrote: > > On Apr 29, 2010, at 1:06 AM, Renato Golin wrote: > > > On 28 April 2010 23:36, kalyan ponnala wrote: > >> Hello Group, > >> > >> I am trying to add a new data type to clang. Can someone tell me the > >> important files and classes to look into and how to start in order to > lex > >> and parse and generate an AST node to this new data type. > > > > First you have to add the new type to the Type hierarchy. See > > include/llvm/Type.h and its derived classes, find a suitable spot and > > implement it. > > I think you mean include/clang/AST/Type.h. But changes to the type system > can be very subtle; Kalyan, if you can be more specific about what type > you're thinking of adding, we can give better advice. There isn't much > internal documentation on adding a type. > > John. -- Kalyan Ponnala phone: 8163772059 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100429/385d59b2/attachment.html From dgregor at apple.com Thu Apr 29 15:59:55 2010 From: dgregor at apple.com (Douglas Gregor) Date: Thu, 29 Apr 2010 13:59:55 -0700 Subject: [cfe-dev] Adding new data type In-Reply-To: References: Message-ID: On Apr 29, 2010, at 1:35 PM, kalyan ponnala wrote: > Hi guys, > > Thanks for the replies. I am trying to add support to a new architecture called Line Associative Registers. It has vector registers in it. I would like to add a vector data type such as int[4] which could access a register with a width of 4 integers in it (max). Since it has to be mentioned in the source as > > int[4] = {1, 2, 3, 4} > > I am not sure about how to proceed. This form looks like an array with 4 elements but I want it to be a datatype. > I was looking into targetinfo.h and initpreprocessor.cpp. it looks like I can add a new type here or change the existing one. And about the type.h in ClangAST target, will it work if I added this type here. > > Any advices about how to proceed would be really appreciated. Clang already has vector types (VectorType) and "extended" vector types (ExtVectorType). They're created using attributes, e.g., typedef int v4si __attribute__ ((vector_size (16))); You could probably just re-use these vector types, possibly tweaking their semantics a bit, for your architecture. - Doug From rjmccall at apple.com Thu Apr 29 16:00:48 2010 From: rjmccall at apple.com (John McCall) Date: Thu, 29 Apr 2010 14:00:48 -0700 Subject: [cfe-dev] Adding new data type In-Reply-To: References: Message-ID: On Apr 29, 2010, at 1:35 PM, kalyan ponnala wrote: > Thanks for the replies. I am trying to add support to a new architecture called Line Associative Registers. It has vector registers in it. I would like to add a vector data type such as int[4] which could access a register with a width of 4 integers in it (max). Clang already has support for vector types based off the gcc vector_size and ext_vector attributes, as well as some support for altivec-style vectors; before you start hacking in a new type with associated syntax, I would suggesting investigating whether any of those would be sufficient or at least provide a better baseline to begin with. > Since it has to be mentioned in the source as > > int[4] = {1, 2, 3, 4} > > I am not sure about how to proceed. This form looks like an array with 4 elements but I want it to be a datatype. Do you mean something like this? int myVector[4] = { 1, 2, 3, 4 }; Making that a vector will break existing C code. Unless you *really* need new syntax, I would strongly suggest sticking with one of the existing vector types. John. From jfreeman at cse.tamu.edu Thu Apr 29 14:10:54 2010 From: jfreeman at cse.tamu.edu (John Freeman) Date: Thu, 29 Apr 2010 14:10:54 -0500 Subject: [cfe-dev] Living on Clang In-Reply-To: <4229484F-BA99-41CD-B4DD-A6A31AB522DA@apple.com> References: <4229484F-BA99-41CD-B4DD-A6A31AB522DA@apple.com> Message-ID: <4BD9D9BE.4020307@cse.tamu.edu> On 4/14/2010 3:51 PM, Douglas Gregor wrote: > Helping is easy: just build Clang on your platform and start using it as your main compiler for LLVM and Clang development. I took your suggestion, and it's worked out pretty well so far. I did not quite understand how to add my own system header paths to the hard-coded paths in clang/lib/Frontend/InitHeaderSearch.cpp (my attempt failed to solve the problem), so I ended up having to create a link from /usr/include/stdarg.h to /usr/lib/gcc/i686-apple-darwin9/4.0.1/include/stdarg.h so that would compile. In my latest small project (51 headers, 14 sources so far), Clang was able to compile every source, some of which included templates, except for the ones that instantiated boost::uuids::string_generator::operator() (Boost.Uuid is a new library in version 1.42). However, GCC was able to compile those sources and successfully link the resulting objects with the Clang-built objects. Knowing where Clang has come from, I am impressed with the progress! I'm looking forward to the day I can completely switch over. :) - John From dgregor at apple.com Fri Apr 30 00:38:03 2010 From: dgregor at apple.com (Douglas Gregor) Date: Thu, 29 Apr 2010 22:38:03 -0700 Subject: [cfe-dev] Living on Clang In-Reply-To: <4BD9D9BE.4020307@cse.tamu.edu> References: <4229484F-BA99-41CD-B4DD-A6A31AB522DA@apple.com> <4BD9D9BE.4020307@cse.tamu.edu> Message-ID: <9D044C58-0979-4E58-AAFA-9C3A47274342@apple.com> On Apr 29, 2010, at 12:10 PM, John Freeman wrote: > On 4/14/2010 3:51 PM, Douglas Gregor wrote: >> Helping is easy: just build Clang on your platform and start using it as your main compiler for LLVM and Clang development. > > I took your suggestion, and it's worked out pretty well so far. > > I did not quite understand how to add my own system header paths to the > hard-coded paths in clang/lib/Frontend/InitHeaderSearch.cpp (my attempt > failed to solve the problem), so I ended up having to create a link from > /usr/include/stdarg.h to > /usr/lib/gcc/i686-apple-darwin9/4.0.1/include/stdarg.h so that > would compile. > > In my latest small project (51 headers, 14 sources so far), Clang was > able to compile every source, some of which included templates, except > for the ones that instantiated > boost::uuids::string_generator::operator() (Boost.Uuid is a new library > in version 1.42). Hrm. The Boost.UUID tests are passing using Boost from trunk (and yesterday's Clang from trunk). Did you file a bug about the failure you're seeing? - Doug From ponnala.kalyan at gmail.com Fri Apr 30 01:08:22 2010 From: ponnala.kalyan at gmail.com (kalyan ponnala) Date: Fri, 30 Apr 2010 02:08:22 -0400 Subject: [cfe-dev] Adding new data type In-Reply-To: <4D805ED7-2796-4CFE-BD7A-066E3060A0AD@apple.com> References: <4D805ED7-2796-4CFE-BD7A-066E3060A0AD@apple.com> Message-ID: hi, Thanks for the replies. @john : I am looking into "typedef int int_4 __attribute__((ext_vector_type(4)));" way of adding the vector data type. I do not want to change the array type to vector type. Right now I am trying to add this as a header file into the clang architecture so that it won't look bad and at the same time it would make the new data type "int_4" look like its a built in data type in clang when we write code at source level. I am still trying to figure it out. It looks like headers added to clang/lib/Headers are not recognized as I thought they would be. I am using visual studio 2008 on windows 7. Thanks. On Thu, Apr 29, 2010 at 7:29 PM, Douglas Gregor wrote: > > On Apr 29, 2010, at 4:28 PM, kalyan ponnala wrote: > > Thanks for letting me know about the vector types Douglas. I think I can > use this to implement the new vector datatype. Can you tell me a better way > to add this as a header file to Clang. I dont want this typedef way to be > visible on the source side. (I dont want to add this as a header file on the > source side.). If I wanted the header file to contain something like > typedef int int_4 __attribute__((ext_vector_type(4))); > > Where can I add this header file inside clang so that it can understand > something like int_4 on the source code, i mean to which target should I add > it? > > > Look in clang/libs/Headers for other Clang-supplied headers. > > - Doug > > Thanks again. > > On Thu, Apr 29, 2010 at 4:59 PM, Douglas Gregor wrote: > >> >> On Apr 29, 2010, at 1:35 PM, kalyan ponnala wrote: >> >> > Hi guys, >> > >> > Thanks for the replies. I am trying to add support to a new architecture >> called Line Associative Registers. It has vector registers in it. I would >> like to add a vector data type such as int[4] which could access a register >> with a width of 4 integers in it (max). Since it has to be mentioned in the >> source as >> > >> > int[4] = {1, 2, 3, 4} >> > >> > I am not sure about how to proceed. This form looks like an array with 4 >> elements but I want it to be a datatype. >> > I was looking into targetinfo.h and initpreprocessor.cpp. it looks like >> I can add a new type here or change the existing one. And about the type.h >> in ClangAST target, will it work if I added this type here. >> > >> > Any advices about how to proceed would be really appreciated. >> >> Clang already has vector types (VectorType) and "extended" vector types >> (ExtVectorType). They're created using attributes, e.g., >> >> typedef int v4si __attribute__ ((vector_size (16))); >> >> You could probably just re-use these vector types, possibly tweaking their >> semantics a bit, for your architecture. >> >> - Doug > > > > > -- > Kalyan Ponnala > phone: 8163772059 > > > -- Kalyan Ponnala phone: 8163772059 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100430/42bdf3bc/attachment.html From Olaf.Krzikalla at tu-dresden.de Fri Apr 30 02:48:38 2010 From: Olaf.Krzikalla at tu-dresden.de (Olaf Krzikalla) Date: Fri, 30 Apr 2010 09:48:38 +0200 Subject: [cfe-dev] Adding new data type In-Reply-To: References: Message-ID: <4BDA8B56.60102@tu-dresden.de> Hi, kalyan ponnala schrieb: > Thanks for the replies. I am trying to add support to a new > architecture called Line Associative Registers. It has vector > registers in it. I would like to add a vector data type such as int[4] > which could access a register with a width of 4 integers in it (max). > Since it has to be mentioned in the source as > > int[4] = {1, 2, 3, 4} > > I am not sure about how to proceed. This form looks like an array with > 4 elements but I want it to be a datatype. I had a similiar problem when I wanted to add SSE data types. First I tried adding a new type to the type system too, but this was clearly the wrong way. I recommend adding just a typedef, which then can act like a built-in type. See my source code below (vecType should be int, float, double or the like). QualType StmtCollector::getSimdType(const QualType& vecType, unsigned NumElts) { // Ctx is a ASTContext BuiltinType *baseType = dyn_cast(Ctx.getCanonicalType(vecType).getTypePtr()); assert(baseType != 0 && "getVectorType(): Expecting a built-in type"); TypedefDecl*& simdTypedef = m_SimdTypedefDecl[tSimdTypedefDeclKey(baseType, NumElts)]; if (simdTypedef == 0) { const char* pTypeName; if (baseType == Ctx.FloatTy.getTypePtr() && NumElts == 4) { pTypeName = "__m128"; } else if (baseType == Ctx.DoubleTy.getTypePtr() && NumElts == 2) { pTypeName = "__m128d"; } else { assert(0 && "simd type unsupported"); } simdTypedef = TypedefDecl::Create(Ctx, Ctx.getTranslationUnitDecl(), SourceLocation(), &Ctx.Idents.get(pTypeName), Ctx.CreateTypeSourceInfo(Ctx.getVectorType(vecType, NumElts, false, false))); } return Ctx.getTypedefType(simdTypedef); } Hth Olaf Krzikalla From abramo.bagnara at gmail.com Fri Apr 30 04:23:07 2010 From: abramo.bagnara at gmail.com (Abramo Bagnara) Date: Fri, 30 Apr 2010 11:23:07 +0200 Subject: [cfe-dev] Storing the NoReturn attribute in Decl nodes. In-Reply-To: References: <4BD71128.5050308@cs.unipr.it> Message-ID: <4BDAA17B.7090407@gmail.com> Il 29/04/2010 18:21, Douglas Gregor ha scritto: > >> Would it be acceptable if clang (also) adds this attribute to the list >> of attributes of the corresponding declaration, so that it could be >> queried like all other attributes? > > Yes, this would be good. Patch pre-approved :) Commited in r102705. Another commit concerning attributes related to calling conventions will follow. From Anton.Lokhmotov at arm.com Fri Apr 30 07:09:52 2010 From: Anton.Lokhmotov at arm.com (Anton Lokhmotov) Date: Fri, 30 Apr 2010 13:09:52 +0100 Subject: [cfe-dev] Giving consistent semantics to extended vectors Message-ID: <002401cae85e$0a57b350$1f0719f0$@Lokhmotov@arm.com> Hello, I've been investigating how Clang interprets operations on extended vectors [those declared with __attribute__((ext_vector_type(n))], in particular with respect to the OpenCL semantics, since http://clang.llvm.org/docs/LanguageExtensions.html#vectors implies that extended vectors have some support for OpenCL constructs. My conclusion is that Clang's behaviour with respect to OpenCL considerably varies from producing wrong diagnostics to accepting invalid statements and rejecting valid statements to silently producing wrong LLVM code. Couple of examples (all vector types have obvious definitions): uchar4 vu = (uchar4) true; // results in: (0x01, 0x01, 0x01, 0x01) // must be: (0xff, 0xff, 0xff, 0xff) int4 vu = (uint4) vi; // disallowed in OpenCL, accepted by Clang uchar2 vuca; char2 vsca; char2 vscc = vsca < vuca; // disallowed in OpenCL, rejected by Clang: // error: can't convert between vector values of different size ('uchar2' and 'char2') int4 via, vib, vic; vic = (via == vib ? via : vib); // allowed in OpenCL, rejected by Clang: // error: used type 'int4' where arithmetic or pointer type is required short2 vs, vr; int i; vr = vs < i; // down-conversion and vector widening: disallowed by OpenCL, rejected by Clang: // error: can't convert between vector values of different size ('short2' and 'int') // (clearly, the error message could be more helpful) My question is whether it anyone has objections to making statements involving extended vectors to have by default semantics consistent with OpenCL or only have the OpenCL semantics when the LangOpts flag is enabled? Anton L. From natebegeman at me.com Fri Apr 30 12:13:33 2010 From: natebegeman at me.com (Nate Begeman) Date: Fri, 30 Apr 2010 10:13:33 -0700 Subject: [cfe-dev] Giving consistent semantics to extended vectors In-Reply-To: <002401cae85e$0a57b350$1f0719f0$%Lokhmotov@arm.com> References: <002401cae85e$0a57b350$1f0719f0$%Lokhmotov@arm.com> Message-ID: <6D5D2B02-55AC-4433-8F85-99A8A2B1F5A0@me.com> On Apr 30, 2010, at 5:09 AM, Anton Lokhmotov wrote: > Hello, > > I've been investigating how Clang interprets operations on extended vectors > [those declared with __attribute__((ext_vector_type(n))], in particular with > respect to the OpenCL semantics, since > http://clang.llvm.org/docs/LanguageExtensions.html#vectors implies that > extended vectors have some support for OpenCL constructs. > > My conclusion is that Clang's behaviour with respect to OpenCL considerably > varies from producing wrong diagnostics to accepting invalid statements and > rejecting valid statements to silently producing wrong LLVM code. Couple of > examples (all vector types have obvious definitions): > > uchar4 vu = (uchar4) true; > // results in: (0x01, 0x01, 0x01, 0x01) > // must be: (0xff, 0xff, 0xff, 0xff) > > int4 vu = (uint4) vi; // disallowed in OpenCL, accepted by Clang This is intentional. > > int4 via, vib, vic; > vic = (via == vib ? via : vib); // allowed in OpenCL, rejected by Clang: > // error: used type 'int4' where arithmetic or pointer type is > required The patch for this has not been submitted back to TOT clang yet. > > short2 vs, vr; int i; > vr = vs < i; > // down-conversion and vector widening: disallowed by OpenCL, > rejected by Clang: > // error: can't convert between vector values of different size > ('short2' and 'int') > // (clearly, the error message could be more helpful) Patches welcome. > > My question is whether it anyone has objections to making statements > involving extended vectors to have by default semantics consistent with > OpenCL or only have the OpenCL semantics when the LangOpts flag is enabled? Extended Vectors are meant to support OpenCL-ish operations, but not enforce OpenCL error semantics all the time. Nate -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100430/899e0262/attachment.html From john.thompson.jtsoftware at gmail.com Fri Apr 30 18:55:09 2010 From: john.thompson.jtsoftware at gmail.com (John Thompson) Date: Fri, 30 Apr 2010 16:55:09 -0700 Subject: [cfe-dev] Question regarding error Message-ID: This doesn't compile. Should it?: class test { public: test( float x ); test(__attribute__((vector_size(16))) float v ); }; int vi = 0; void func() { test object = test(vi); } C:\Sony\Clang\exp>clang -cc1 scalar.cpp scalar.cpp:13:16: error: functional-style cast from 'int' to 'test' is not allowed test object = test(vi); ^~~~ -- John Thompson John.Thompson.JTSoftware at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100430/fb70b981/attachment.html From dgregor at apple.com Fri Apr 30 19:11:13 2010 From: dgregor at apple.com (Douglas Gregor) Date: Fri, 30 Apr 2010 17:11:13 -0700 Subject: [cfe-dev] Question regarding error In-Reply-To: References: Message-ID: On Apr 30, 2010, at 4:55 PM, John Thompson wrote: > This doesn't compile. Should it?: > > class test > { > public: > test( float x ); > test(__attribute__((vector_size(16))) float v ); > }; > int vi = 0; > void func() > { > test object = test(vi); > } > C:\Sony\Clang\exp>clang -cc1 scalar.cpp > scalar.cpp:13:16: error: functional-style cast from 'int' to 'test' is not allowed > test object = test(vi); > ^~~~ The logic for computing implicit conversion sequences in C++ does not know anything about vectors. What you're seeing here is a poor diagnostic due to the cast. Change it to a direct initialization and you'll see the ambiguity: t2.cpp:10:7: error: call to constructor of 'test' is ambiguous test object(vi); ^ ~~ t2.cpp:4:2: note: candidate constructor test( float x ); ^ t2.cpp:5:2: note: candidate constructor test(__attribute__((vector_size(16))) float v ); ^ t2.cpp:1:7: note: candidate is the implicit copy constructor class test ^ Clang can't figure out which constructor is the better match. - Doug From ponnala.kalyan at gmail.com Fri Apr 30 19:38:21 2010 From: ponnala.kalyan at gmail.com (kalyan ponnala) Date: Fri, 30 Apr 2010 20:38:21 -0400 Subject: [cfe-dev] Adding new data type In-Reply-To: References: <4D805ED7-2796-4CFE-BD7A-066E3060A0AD@apple.com> Message-ID: Hi guys, I was trying to add this header file named "NEW_DATATYPES.h" with the following information into clang. typedef int int_2 __attribute__((ext_vector_type(2))); I added it to clang\lib\Headers. And in the source program when I try to do: >>code-1: int main() { int_2 abc = { 1, 2 }; int_2 bbc = { 3, 4} ; abc.x = bbc.y; return 0; } clang gives me an error. saying that it does not identify int_2. When I add the header file's name "NEW_DATATYPES.h" to the source like below, clang compiles the code fine. >>code2: #include "NEW_DATATYPES.h" int main() { int_2 abc = { 1, 2 }; int_2 bbc = { 3, 4} ; abc.x = bbc.y; return 0; } But what I want is that the clang should be able to compile the code-1 fine where I dont have to add the header file explicitly. Can someone please tell me how to do this without actually making any changes to the existing clang architecture. I am trying not to disturb the code. Thanks a ton. Kalyan On Fri, Apr 30, 2010 at 2:08 AM, kalyan ponnala wrote: > > hi, > > Thanks for the replies. @john : I am looking into "typedef int int_4 > __attribute__((ext_vector_type(4)));" way of adding the vector data type. I > do not want to change the array type to vector type. Right now I am trying > to add this as a header file into the clang architecture so that it won't > look bad and at the same time it would make the new data type "int_4" look > like its a built in data type in clang when we write code at source level. I > am still trying to figure it out. It looks like headers added to > clang/lib/Headers are not recognized as I thought they would be. I am using > visual studio 2008 on windows 7. > > Thanks. > > > > On Thu, Apr 29, 2010 at 7:29 PM, Douglas Gregor wrote: > >> >> On Apr 29, 2010, at 4:28 PM, kalyan ponnala wrote: >> >> Thanks for letting me know about the vector types Douglas. I think I can >> use this to implement the new vector datatype. Can you tell me a better way >> to add this as a header file to Clang. I dont want this typedef way to be >> visible on the source side. (I dont want to add this as a header file on the >> source side.). If I wanted the header file to contain something like >> typedef int int_4 __attribute__((ext_vector_type(4))); >> >> Where can I add this header file inside clang so that it can understand >> something like int_4 on the source code, i mean to which target should I add >> it? >> >> >> Look in clang/libs/Headers for other Clang-supplied headers. >> >> - Doug >> >> Thanks again. >> >> On Thu, Apr 29, 2010 at 4:59 PM, Douglas Gregor wrote: >> >>> >>> On Apr 29, 2010, at 1:35 PM, kalyan ponnala wrote: >>> >>> > Hi guys, >>> > >>> > Thanks for the replies. I am trying to add support to a new >>> architecture called Line Associative Registers. It has vector registers in >>> it. I would like to add a vector data type such as int[4] which could access >>> a register with a width of 4 integers in it (max). Since it has to be >>> mentioned in the source as >>> > >>> > int[4] = {1, 2, 3, 4} >>> > >>> > I am not sure about how to proceed. This form looks like an array with >>> 4 elements but I want it to be a datatype. >>> > I was looking into targetinfo.h and initpreprocessor.cpp. it looks like >>> I can add a new type here or change the existing one. And about the type.h >>> in ClangAST target, will it work if I added this type here. >>> > >>> > Any advices about how to proceed would be really appreciated. >>> >>> Clang already has vector types (VectorType) and "extended" vector types >>> (ExtVectorType). They're created using attributes, e.g., >>> >>> typedef int v4si __attribute__ ((vector_size (16))); >>> >>> You could probably just re-use these vector types, possibly tweaking >>> their semantics a bit, for your architecture. >>> >>> - Doug >> >> >> >> >> -- >> Kalyan Ponnala >> phone: 8163772059 >> >> >> > > > -- > Kalyan Ponnala > phone: 8163772059 > -- Kalyan Ponnala phone: 8163772059 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100430/0588dbe8/attachment.html From eli.friedman at gmail.com Fri Apr 30 19:44:34 2010 From: eli.friedman at gmail.com (Eli Friedman) Date: Fri, 30 Apr 2010 17:44:34 -0700 Subject: [cfe-dev] Question regarding error In-Reply-To: References: Message-ID: On Fri, Apr 30, 2010 at 5:11 PM, Douglas Gregor wrote: > > On Apr 30, 2010, at 4:55 PM, John Thompson wrote: > >> This doesn't compile. ?Should it?: >> >> class test >> { >> public: >> ?test( float x ); >> ?test(__attribute__((vector_size(16))) float v ); >> }; >> int vi = 0; >> void func() >> { >> ?test object = test(vi); >> } >> C:\Sony\Clang\exp>clang -cc1 scalar.cpp >> scalar.cpp:13:16: error: functional-style cast from 'int' to 'test' is not allowed >> ? ? ? ? test object = test(vi); >> ? ? ? ? ? ? ? ? ? ? ? ^~~~ > > The logic for computing implicit conversion sequences in C++ does not know anything about vectors. What you're seeing here is a poor diagnostic due to the cast. Change it to a direct initialization and you'll see the ambiguity: > > t2.cpp:10:7: error: call to constructor of 'test' is ambiguous > ?test object(vi); > ? ? ?^ ? ? ?~~ > t2.cpp:4:2: note: candidate constructor > ?test( float x ); > ?^ > t2.cpp:5:2: note: candidate constructor > ?test(__attribute__((vector_size(16))) float v ); > ?^ > t2.cpp:1:7: note: candidate is the implicit copy constructor > class test > ? ? ?^ > > Clang can't figure out which constructor is the better match. Right, it's treating it like a class which has constructors for, for example, float and double. It does this because our routines for identifying types do strange things for queries like isRealFloatingType(). See also http://llvm.org/bugs/show_bug.cgi?id=4208 . -Eli From eli.friedman at gmail.com Fri Apr 30 19:52:17 2010 From: eli.friedman at gmail.com (Eli Friedman) Date: Fri, 30 Apr 2010 17:52:17 -0700 Subject: [cfe-dev] Adding new data type In-Reply-To: References: <4D805ED7-2796-4CFE-BD7A-066E3060A0AD@apple.com> Message-ID: On Fri, Apr 30, 2010 at 5:38 PM, kalyan ponnala wrote: > Hi guys, > > I was trying to add this header file named "NEW_DATATYPES.h"? with the > following information into clang. > > typedef int int_2 __attribute__((ext_vector_type(2))); > > I added it to clang\lib\Headers. And in the source program when I try to do: >>>code-1: > > int main() > { > ??? int_2 abc = { 1, 2 }; > ??? int_2 bbc = { 3, 4} ; > ??? abc.x = bbc.y; > return 0; > } > > clang gives me an error. saying that it does not identify int_2. > When I add the header file's name "NEW_DATATYPES.h" to the source like > below, clang compiles the code fine. >>>code2: > > #include "NEW_DATATYPES.h" > int main() > { > ??? int_2 abc = { 1, 2 }; > ??? int_2 bbc = { 3, 4} ; > ??? abc.x = bbc.y; > return 0; > } > > But what I want is that the clang should be able to compile the code-1 fine > where I dont have to add the header file explicitly. Can someone please tell > me how to do this without actually making any changes to the existing clang > architecture. I am trying not to disturb the code. Pass "-include NEW_DATATYPES.h" on the command-line, or do the equivalent in the code that calls clang::InitializePreprocessor, or modify lib/Frontend/InitializePreprocessor.cpp to either add the include or add the typedef directly. -Eli > Thanks a ton. > > Kalyan > > On Fri, Apr 30, 2010 at 2:08 AM, kalyan ponnala > wrote: >> >> hi, >> >> Thanks for the replies. @john :? I am looking into "typedef int int_4 >> __attribute__((ext_vector_type(4)));" way of adding the vector data type. I >> do not want to change the array type to vector type. Right now I am trying >> to add this as a header file into the clang architecture so that it won't >> look bad and at the same time it would make the new data type "int_4" look >> like its a built in data type in clang when we write code at source level. I >> am still trying to figure it out. It looks like headers added to >> clang/lib/Headers are not recognized as I thought they would be. I am using >> visual studio 2008 on windows 7. >> >> Thanks. >> >> >> On Thu, Apr 29, 2010 at 7:29 PM, Douglas Gregor wrote: >>> >>> On Apr 29, 2010, at 4:28 PM, kalyan ponnala wrote: >>> >>> Thanks for letting me know about the vector types Douglas. I think I can >>> use this to implement the new vector datatype. Can you tell me a better way >>> to add this as a header file to Clang. I dont want this typedef way to be >>> visible on the source side. (I dont want to add this as a header file on the >>> source side.). If I wanted the header file to contain something like >>> typedef int int_4 __attribute__((ext_vector_type(4))); >>> >>> Where can I add this header file inside clang so that it can understand >>> something like int_4 on the source code, i mean to which target should I add >>> it? >>> >>> Look in clang/libs/Headers for other Clang-supplied headers. >>> - Doug >>> >>> Thanks again. >>> >>> On Thu, Apr 29, 2010 at 4:59 PM, Douglas Gregor >>> wrote: >>>> >>>> On Apr 29, 2010, at 1:35 PM, kalyan ponnala wrote: >>>> >>>> > Hi guys, >>>> > >>>> > Thanks for the replies. I am trying to add support to a new >>>> > architecture called Line Associative Registers. It has vector registers in >>>> > it. I would like to add a vector data type such as int[4] which could access >>>> > a register with a width of 4 integers in it (max). Since it has to be >>>> > mentioned in the source as >>>> > >>>> > int[4] = {1, 2, 3, 4} >>>> > >>>> > I am not sure about how to proceed. This form looks like an array with >>>> > 4 elements but I want it to be a datatype. >>>> > I was looking into targetinfo.h and initpreprocessor.cpp. it looks >>>> > like I can add a new type here or change the existing one. And about the >>>> > type.h in ClangAST target, will it work if I added this type here. >>>> > >>>> > Any advices about how to proceed would be really appreciated. >>>> >>>> Clang already has vector types (VectorType) and "extended" vector types >>>> (ExtVectorType). They're created using attributes, e.g., >>>> >>>> ? ? ? ?typedef int v4si __attribute__ ((vector_size (16))); >>>> >>>> You could probably just re-use these vector types, possibly tweaking >>>> their semantics a bit, for your architecture. >>>> >>>> ? ? ? ?- Doug >>> >>> >>> -- >>> Kalyan Ponnala >>> phone: 8163772059 >>> >> >> >> >> -- >> Kalyan Ponnala >> phone: 8163772059 > > > > -- > Kalyan Ponnala > phone: 8163772059 > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > > From john.thompson.jtsoftware at gmail.com Fri Apr 30 20:49:46 2010 From: john.thompson.jtsoftware at gmail.com (John Thompson) Date: Fri, 30 Apr 2010 18:49:46 -0700 Subject: [cfe-dev] Accessing private members through typedefs Message-ID: I have the following: template class test; typedef test testClass; typedef testClass& refTestClass; template class test { public: test(refTestClass other); private: int member; }; template inline test::test(refTestClass other) { member = other.member; } C:\Sony\Clang\exp>clang -cc1 priv.cpp priv.cpp:15:17: error: 'member' is a private member of 'test' member = other.member; ^ priv.cpp:10:6: note: declared private here int member; Is this a bug or legitimate behavior? Sorry to bug you with these. Basically I'm running Clang over a very large program written by someone else and compiled with gcc. Is this the appropriate place for this, or should I just file bugs and let someone else respond as needed? -John -- John Thompson John.Thompson.JTSoftware at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20100430/bdb057ae/attachment.html From rjmccall at apple.com Fri Apr 30 21:17:27 2010 From: rjmccall at apple.com (John McCall) Date: Fri, 30 Apr 2010 19:17:27 -0700 Subject: [cfe-dev] Accessing private members through typedefs In-Reply-To: References: Message-ID: <8F744F17-087D-471A-8549-AAAEE27CF5B8@apple.com> On Apr 30, 2010, at 6:49 PM, John Thompson wrote: > I have the following: > > template class test; > typedef test testClass; > typedef testClass& refTestClass; > template class test > { > public: > test(refTestClass other); > private: > int member; > }; > template > inline test::test(refTestClass other) { > member = other.member; > } > C:\Sony\Clang\exp>clang -cc1 priv.cpp > priv.cpp:15:17: error: 'member' is a private member of 'test' > member = other.member; > ^ > priv.cpp:10:6: note: declared private here > int member; > > Is this a bug or legitimate behavior? It's a bug. There is one valid instantiation of this template, at TYPE=int, so we can't diagnose. The bug has nothing to do with typedefs. Reduction: template class A { int foo; int getFoo(A &a) { return a.foo; } }; > Sorry to bug you with these. Basically I'm running Clang over a very large program written by someone else and compiled with gcc. Is this the appropriate place for this, or should I just file bugs and let someone else respond as needed? Bugs are probably more appropriate. Please file this one. John. From joerg.zeiner at gmx.de Fri Apr 30 15:07:07 2010 From: joerg.zeiner at gmx.de (=?ISO-8859-15?Q?J=F6rg_Zeiner?=) Date: Fri, 30 Apr 2010 22:07:07 +0200 Subject: [cfe-dev] Broken link in "http://clang.llvm.org/docs/InternalsManual.html" Message-ID: <4BDB386B.4050903@gmx.de> Hi, I'm not sure if this is the right place to post it, but the weg page "http://clang.llvm.org/docs/InternalsManual.html" contains a broken link to "http://llvm.org/svn/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticKinds.def" J?rg