From kremenek at apple.com Tue Sep 4 11:44:58 2007 From: kremenek at apple.com (Ted Kremenek) Date: Tue, 4 Sep 2007 09:44:58 -0700 Subject: [cfe-dev] clang fails to build with latest LLVM revision Message-ID: This morning I did an update of both my LLVM and clang trees. Now clang doesn't compile: llvm[1]: Compiling CGExprComplex.cpp for Debug build /Volumes/Data/Users/kremenek/dev/src/llvm/include/llvm/Instructions.h: In member function ?void llvm::GetElementPtrInst::init(llvm::Value*, InputIterator, InputIterator, const std::string&, std::random_access_iterator_tag) [with InputIterator = llvm::Constant*]?: /Volumes/Data/Users/kremenek/dev/src/llvm/include/llvm/Instructions.h: 459: instantiated from ?llvm::GetElementPtrInst::GetElementPtrInst(llvm::Value*, InputIterator, InputIterator, const std::string&, llvm::Instruction*) [with InputIterator = llvm::Constant*]? /Volumes/Data/Users/kremenek/dev/src/llvm/include/llvm/Support/ LLVMBuilder.h:223: instantiated from ?llvm::GetElementPtrInst* llvm::LLVMBuilder::CreateGEP(llvm::Value*, InputIterator, InputIterator, const char*) [with InputIterator = llvm::Constant*]? CGExprComplex.cpp:194: instantiated from here /Volumes/Data/Users/kremenek/dev/src/llvm/include/llvm/Instructions.h: 404: error: no matching function for call to ?llvm::GetElementPtrInst::init(llvm::Value*&, llvm::Constant*, ptrdiff_t&)? /Volumes/Data/Users/kremenek/dev/src/llvm/include/llvm/Instructions.h: 390: note: candidates are: void llvm::GetElementPtrInst::init(llvm::Value*, llvm::Value* const*, unsigned int) /Volumes/Data/Users/kremenek/dev/src/llvm/include/llvm/Instructions.h: 391: note: void llvm::GetElementPtrInst::init(llvm::Value*, llvm::Value*) make[1]: *** [/Volumes/Data/Users/kremenek/dev/src/llvm/tools/clang/ CodeGen/Debug/CGExprComplex.o] Error 1 make: *** [all] Error 1 The revision numbers for the trees are as follows: (kremenek at grue:llvm)$ svn update At revision 41699. (kremenek at grue:clang)$ svn update At revision 41699. It appears that the signature for GetElementPtrInst::init has changed. I can look into fixing this, but I'm not super savvy on the latest changes to the LLVM tree and how those changes effect the CodeGen component of clang. From clattner at apple.com Tue Sep 4 11:56:02 2007 From: clattner at apple.com (Chris Lattner) Date: Tue, 4 Sep 2007 09:56:02 -0700 Subject: [cfe-dev] clang fails to build with latest LLVM revision In-Reply-To: References: Message-ID: <80B69433-1325-4B04-9C9A-51CA071C9146@apple.com> It looks like the mainline interfaces were changed. Before it used to have several versions, including one that took a an array of operands as a base pointer + count, now it only takes two iterators as input. Please change stuff like this: llvm::Value *ImagPtr = Builder.CreateGEP(SrcPtr, Zero, One, Name.c_str()); to: Value *Ops[] = {Zero, One}; llvm::Value *ImagPtr = Builder.CreateGEP(SrcPtr, Ops, Ops+2, Name.c_str()); and it should work. -Chris On Sep 4, 2007, at 9:44 AM, Ted Kremenek wrote: > This morning I did an update of both my LLVM and clang trees. Now > clang doesn't compile: > > llvm[1]: Compiling CGExprComplex.cpp for Debug build > /Volumes/Data/Users/kremenek/dev/src/llvm/include/llvm/Instructions.h: > In member function ?void llvm::GetElementPtrInst::init(llvm::Value*, > InputIterator, InputIterator, const std::string&, > std::random_access_iterator_tag) [with InputIterator = > llvm::Constant*]?: > /Volumes/Data/Users/kremenek/dev/src/llvm/include/llvm/Instructions.h: > 459: instantiated from > ?llvm::GetElementPtrInst::GetElementPtrInst(llvm::Value*, > InputIterator, InputIterator, const std::string&, llvm::Instruction*) > [with InputIterator = llvm::Constant*]? > /Volumes/Data/Users/kremenek/dev/src/llvm/include/llvm/Support/ > LLVMBuilder.h:223: instantiated from ?llvm::GetElementPtrInst* > llvm::LLVMBuilder::CreateGEP(llvm::Value*, InputIterator, > InputIterator, const char*) [with InputIterator = llvm::Constant*]? > CGExprComplex.cpp:194: instantiated from here > /Volumes/Data/Users/kremenek/dev/src/llvm/include/llvm/Instructions.h: > 404: error: no matching function for call to > ?llvm::GetElementPtrInst::init(llvm::Value*&, llvm::Constant*, > ptrdiff_t&)? > /Volumes/Data/Users/kremenek/dev/src/llvm/include/llvm/Instructions.h: > 390: note: candidates are: void > llvm::GetElementPtrInst::init(llvm::Value*, llvm::Value* const*, > unsigned int) > /Volumes/Data/Users/kremenek/dev/src/llvm/include/llvm/Instructions.h: > 391: note: void > llvm::GetElementPtrInst::init(llvm::Value*, llvm::Value*) > make[1]: *** [/Volumes/Data/Users/kremenek/dev/src/llvm/tools/clang/ > CodeGen/Debug/CGExprComplex.o] Error 1 > make: *** [all] Error 1 > > The revision numbers for the trees are as follows: > > (kremenek at grue:llvm)$ svn update > At revision 41699. > > (kremenek at grue:clang)$ svn update > At revision 41699. > > It appears that the signature for GetElementPtrInst::init has > changed. I can look into fixing this, but I'm not super savvy on the > latest changes to the LLVM tree and how those changes effect the > CodeGen component of clang. > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From kremenek at apple.com Tue Sep 4 12:20:36 2007 From: kremenek at apple.com (Ted Kremenek) Date: Tue, 4 Sep 2007 10:20:36 -0700 Subject: [cfe-dev] clang fails to build with latest LLVM revision In-Reply-To: <80B69433-1325-4B04-9C9A-51CA071C9146@apple.com> References: <80B69433-1325-4B04-9C9A-51CA071C9146@apple.com> Message-ID: OK. I've patched the calls to CreateGEP in the CodeGen directory. The code now compiles. Haven't tested it though. On Sep 4, 2007, at 9:56 AM, Chris Lattner wrote: > It looks like the mainline interfaces were changed. Before it used > to have several versions, including one that took a an array of > operands as a base pointer + count, now it only takes two iterators > as input. > > Please change stuff like this: > llvm::Value *ImagPtr = Builder.CreateGEP(SrcPtr, Zero, One, > Name.c_str()); > > to: > > Value *Ops[] = {Zero, One}; > llvm::Value *ImagPtr = Builder.CreateGEP(SrcPtr, Ops, Ops+2, > Name.c_str()); > > and it should work. > > -Chris > > On Sep 4, 2007, at 9:44 AM, Ted Kremenek wrote: > >> This morning I did an update of both my LLVM and clang trees. Now >> clang doesn't compile: >> >> llvm[1]: Compiling CGExprComplex.cpp for Debug build >> /Volumes/Data/Users/kremenek/dev/src/llvm/include/llvm/ >> Instructions.h: >> In member function ?void llvm::GetElementPtrInst::init(llvm::Value*, >> InputIterator, InputIterator, const std::string&, >> std::random_access_iterator_tag) [with InputIterator = >> llvm::Constant*]?: >> /Volumes/Data/Users/kremenek/dev/src/llvm/include/llvm/ >> Instructions.h: >> 459: instantiated from >> ?llvm::GetElementPtrInst::GetElementPtrInst(llvm::Value*, >> InputIterator, InputIterator, const std::string&, llvm::Instruction*) >> [with InputIterator = llvm::Constant*]? >> /Volumes/Data/Users/kremenek/dev/src/llvm/include/llvm/Support/ >> LLVMBuilder.h:223: instantiated from ?llvm::GetElementPtrInst* >> llvm::LLVMBuilder::CreateGEP(llvm::Value*, InputIterator, >> InputIterator, const char*) [with InputIterator = llvm::Constant*]? >> CGExprComplex.cpp:194: instantiated from here >> /Volumes/Data/Users/kremenek/dev/src/llvm/include/llvm/ >> Instructions.h: >> 404: error: no matching function for call to >> ?llvm::GetElementPtrInst::init(llvm::Value*&, llvm::Constant*, >> ptrdiff_t&)? >> /Volumes/Data/Users/kremenek/dev/src/llvm/include/llvm/ >> Instructions.h: >> 390: note: candidates are: void >> llvm::GetElementPtrInst::init(llvm::Value*, llvm::Value* const*, >> unsigned int) >> /Volumes/Data/Users/kremenek/dev/src/llvm/include/llvm/ >> Instructions.h: >> 391: note: void >> llvm::GetElementPtrInst::init(llvm::Value*, llvm::Value*) >> make[1]: *** [/Volumes/Data/Users/kremenek/dev/src/llvm/tools/clang/ >> CodeGen/Debug/CGExprComplex.o] Error 1 >> make: *** [all] Error 1 >> >> The revision numbers for the trees are as follows: >> >> (kremenek at grue:llvm)$ svn update >> At revision 41699. >> >> (kremenek at grue:clang)$ svn update >> At revision 41699. >> >> It appears that the signature for GetElementPtrInst::init has >> changed. I can look into fixing this, but I'm not super savvy on the >> latest changes to the LLVM tree and how those changes effect the >> CodeGen component of clang. >> _______________________________________________ >> cfe-dev mailing list >> cfe-dev at cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > From kremenek at apple.com Tue Sep 4 12:45:32 2007 From: kremenek at apple.com (Ted Kremenek) Date: Tue, 4 Sep 2007 10:45:32 -0700 Subject: [cfe-dev] clang fails to build with latest LLVM revision In-Reply-To: References: <80B69433-1325-4B04-9C9A-51CA071C9146@apple.com> Message-ID: <05CC1A96-625E-4F8A-B4C7-9B0BDE6FE6D6@apple.com> On Sep 4, 2007, at 10:20 AM, Ted Kremenek wrote: > OK. I've patched the calls to CreateGEP in the CodeGen directory. > The code now compiles. Haven't tested it though. Correction: make test works fine. From neil at daikokuya.co.uk Wed Sep 5 06:47:04 2007 From: neil at daikokuya.co.uk (Neil Booth) Date: Wed, 5 Sep 2007 20:47:04 +0900 Subject: [cfe-dev] EXTENSION for some diags In-Reply-To: <20070826051531.GT4363@daikokuya.co.uk> References: <20070826044931.GS4363@daikokuya.co.uk> <431896BD-4F6A-4259-ACC0-14AE075C876B@apple.com> <20070826051531.GT4363@daikokuya.co.uk> Message-ID: <20070905114704.GL11470@daikokuya.co.uk> Neil Booth wrote:- > I implemented something like the following myself; I'm quite fond > of this approach and it's flexible: [snip] Any thoughts? Neil. From clattner at apple.com Wed Sep 5 20:43:22 2007 From: clattner at apple.com (Chris Lattner) Date: Wed, 5 Sep 2007 18:43:22 -0700 Subject: [cfe-dev] EXTENSION for some diags In-Reply-To: <20070826051531.GT4363@daikokuya.co.uk> References: <20070826044931.GS4363@daikokuya.co.uk> <431896BD-4F6A-4259-ACC0-14AE075C876B@apple.com> <20070826051531.GT4363@daikokuya.co.uk> Message-ID: <8FD50E5A-C71E-4846-8321-09D8A1F67AEB@apple.com> >> You're right, we do. What do you suggest? GCC has a class of >> extension warnings that are emitted by default. Is this what you >> mean? That would give us: >> >> 1. Error. >> 2. Warning always (eventually enabled or disabled by other -W >> options) >> 3. Extension, defaults to a warning >> 4. Extension, defaults to silent >> >> -pedantic would then map #4 to a warning. -pedantic-errors would >> make #3/#4 to error. >> >> Sound reasonable? > > I implemented something like the following myself; I'm quite fond > of this approach and it's flexible: Sorry for dropping the ball on this, it got buried in some other mail when I was playing with filtering rules. :( > a) Each diagnostic tag has a default severity suitable for normal > compiles. Severities are, in order, suppress, remark, warning, > soft error, hard error, fatal and maybe ice. > b) User can change the severity of any diagnostic with default > severity <= soft error to any severity <= soft error, either > via #pragma or on the command line. > c) In C90 and C99 pedantic mode, a table of tags that must > be diagnosed according to the standard is scanned and the > severity of said tag "upgraded" to warning (-pedantic or > equivalent) or error (-pedantic-errors or equivalent) if it > isn't already. > d) Some severities need to be different depending on compile- > time context anyway (e.g. integer division by zero is a > run-time error, compile-time warning except in constant > expressions where it is compile-time error). So when > raising a diagnostic it should be possible for the front > end to specify a severity override anyway. > You probably feel something slightly different is appropriate > for LLVM, but there may be ideas worth using here. It avoids > the need for duplicate tags too, which is good from a user- > interface point of view if they are exposed to the user (they > probably should be for the fine-grained control of b)). I think this makes sense. You basically have a table mapping diagnostics to severity, which can be manipulated based on a variety of things. clang currently has two distinct notions: we distinguish between what class a particular diagnostic falls into from how it is reported. These two categorizations are used by different pieces of the diagnostic handling machinery. The first part of the diagnostics machinery is the piece that is generating the diagnostics: the parser, lexer, sema, checking system, etc. Each diagnostic itself is tagged (in DiagnosticKinds.def) with a class, which is a member of the set {NOTE,WARNING,EXTENSION,ERROR}. The important part of the classification at this level is that it is completely independent of how the diagnostic is reported and they have obvious meanings: 1. NOTEs (which aren't used and may be removed in the future) are informational messages. For example, perhaps the optimizer could emit information about which loops are vectorized etc. 2. WARNINGs are emitted for legal code that is questionable somehow. 3. EXTENSIONs are emitted for illegal code that is accepted anyway as an extension to the language. 4. ERRORs flag a malformed program where error recovery techniques must be used to continue parsing. I believe that each of these categories is well described and simple. It is easy to determine which class any particular diagnostic falls into. > a) Each diagnostic tag has a default severity suitable for normal > compiles. Severities are, in order, suppress, remark, warning, > soft error, hard error, fatal and maybe ice. In contrast to your system, we don't specify a "default mapping": that is completely client-specific. Because the library generating the diagnostic doesn't know/care about how these diagnostics are emitted, we don't need to talk about suppressed diagnostics. I'm not sure the distinction between soft/hard error in your scheme. Fatal/ ICE are also interesting: we don't emit a diagnostic for these cases: these are presumably internal consistency failures, where we prefer to have the library assert/abort and die. When diagnostics are reported by the parser (etc), they get routed through the Diagnostic class. This class is designed to do various types of mapping, which turns the class above into a concrete diagnostic level. The level is completely different from the class, but they have similar names (and are thus somewhat confusing). The Diagnostic class maps each diagnostic onto the level set, which is { Ignored, Note, Warning, Error, Fatal }. These levels are what we expect the tool to report to the user. As you might expect, the {note,warning,extension} classes can be mapped onto any of these levels, and the {error} class can only be mapped onto {error,fatal}. Most of these are self-explanatory, but here are some interesting pieces: 1. The warning class can be mapped onto the note level if desired (or completely ignored) at the discretion of the client. 2. Fatal errors aren't property of the diagnostic, they are a level that can be mapped onto: we expect all errors to be recovered from when the diagnostic generator produces them. The Fatal level is useful for clients that want the parser to stop as soon as possible after some set of diagnostics are emitted (for example an error). I believe that this system is fully general: any interesting policy the client wants can be implemented with this scheme (Diagnostic::setDiagnosticMapping can be used to specify a level on a per-diagnostic basis), and higher level policies (e.g. -Werror, - pedantic, -pedantic-errors etc) can be easily handled by mapping entire classes to levels. > Something I've not implemented yet is diagnostic groups, so > you could give groups of tags a name and manipulate them > en-masse, e.g. portability warnings, unused warnings, etc. This is also something that clang is missing. In particular, the client would like to be able to manipulate groups at a coarse grain to implement controls such as the GCC options -Wextra, -Wall, -W, etc. These are basically controls that modify a whole set of diagnostics. However, it is important to note that the groupings are client specific, so this should be implemented in the driver, not in the libraries. The original topic of discussion was what "extensions" should be warned about even when -pedantic is not specified. In contrast to my original proposal, I now don't think this should be another class of warning, I think this should be controlled with the (currently missing) diagnostic grouping mechanism in the driver. Is this design reasonable? -Chris From uniheliodem at gmail.com Wed Sep 5 22:08:11 2007 From: uniheliodem at gmail.com (Justin Handville) Date: Wed, 5 Sep 2007 23:08:11 -0400 Subject: [cfe-dev] clang C++ volunteer Message-ID: <992b09980709052008i7de5ca8ey6b65d49aad1104a5@mail.gmail.com> I understand that you are currently looking for developers to assist with clang, specifically for the C++ front-end and for code generation tasks. I am willing to toss my hat in. I have some experience with compiler development, mainly in the area of source-to-source compilers. What are the current low-hanging fruit? There wouldn't by chance be a developer FAQ yet? While it is still very early for a definitive answer to this question, what is planned for the STL implementation for clang? This would be a rich source of test cases for the C++ front end. Thanks, Justin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20070905/854f44d2/attachment.html From jwiegley at gmail.com Wed Sep 5 23:32:19 2007 From: jwiegley at gmail.com (John Wiegley) Date: Thu, 06 Sep 2007 00:32:19 -0400 Subject: [cfe-dev] clang C++ volunteer In-Reply-To: <992b09980709052008i7de5ca8ey6b65d49aad1104a5@mail.gmail.com> (Justin Handville's message of "Wed\, 5 Sep 2007 23\:08\:11 -0400") References: <992b09980709052008i7de5ca8ey6b65d49aad1104a5@mail.gmail.com> Message-ID: "Justin Handville" writes: > I understand that you are currently looking for developers to assist with > clang, specifically for the C++ front-end and for code generation tasks. > > I am willing to toss my hat in. I have some experience with compiler > development, mainly in the area of source-to-source compilers. What are the > current low-hanging fruit? There wouldn't by chance be a developer FAQ yet? Yes, is there an open list of items it would be easier for new people to jump into? John From isanbard at gmail.com Thu Sep 6 03:41:40 2007 From: isanbard at gmail.com (Bill Wendling) Date: Thu, 6 Sep 2007 01:41:40 -0700 Subject: [cfe-dev] clang C++ volunteer In-Reply-To: References: <992b09980709052008i7de5ca8ey6b65d49aad1104a5@mail.gmail.com> Message-ID: <26846B8E-03ED-42B6-BF2C-920CE4A09E2B@gmail.com> On Sep 5, 2007, at 9:32 PM, John Wiegley wrote: > "Justin Handville" writes: > >> I understand that you are currently looking for developers to >> assist with >> clang, specifically for the C++ front-end and for code generation >> tasks. >> >> I am willing to toss my hat in. I have some experience with compiler >> development, mainly in the area of source-to-source compilers. >> What are the >> current low-hanging fruit? There wouldn't by chance be a >> developer FAQ yet? > > Yes, is there an open list of items it would be easier for new > people to jump > into? > The C++ support is in an *extremely* early phase right now. There's only named operators, bool, parsing for C++ casts, and references in there right now. Some of the things to be done with the C++ casts and references are: - Do semantic analysis for reference initialization. - Do semantic analysis for casts. There's obviously a lot more to do. I would suggest taking small steps; learning the code base and its architecture by adding smaller features of the language. As far as a specific list of items, there isn't any official one. Though I'd start with the two I mentioned above (I have some code for the second of those, if you'd like to see it) and proceed from there. -bw From uniheliodem at gmail.com Thu Sep 6 06:57:59 2007 From: uniheliodem at gmail.com (Justin Handville) Date: Thu, 6 Sep 2007 07:57:59 -0400 Subject: [cfe-dev] clang C++ volunteer In-Reply-To: <26846B8E-03ED-42B6-BF2C-920CE4A09E2B@gmail.com> References: <992b09980709052008i7de5ca8ey6b65d49aad1104a5@mail.gmail.com> <26846B8E-03ED-42B6-BF2C-920CE4A09E2B@gmail.com> Message-ID: <992b09980709060457h47bb9b62jfa32d26a29d199f9@mail.gmail.com> > The C++ support is in an *extremely* early phase right now. There's > only named operators, bool, parsing for C++ casts, and references in > there right now. Some of the things to be done with the C++ casts and > references are: > > - Do semantic analysis for reference initialization. > - Do semantic analysis for casts. > > There's obviously a lot more to do. I would suggest taking small > steps; learning the code base and its architecture by adding smaller > features of the language. As far as a specific list of items, there > isn't any official one. Though I'd start with the two I mentioned > above (I have some code for the second of those, if you'd like to see > it) and proceed from there. Yes, I would be interested in seeing what you have so far to implement semantic analysis for casts. I'll start digging into the code base tonight to see how the AST is implemented. From neil at daikokuya.co.uk Thu Sep 6 07:46:53 2007 From: neil at daikokuya.co.uk (Neil Booth) Date: Thu, 6 Sep 2007 21:46:53 +0900 Subject: [cfe-dev] EXTENSION for some diags In-Reply-To: <8FD50E5A-C71E-4846-8321-09D8A1F67AEB@apple.com> References: <20070826044931.GS4363@daikokuya.co.uk> <431896BD-4F6A-4259-ACC0-14AE075C876B@apple.com> <20070826051531.GT4363@daikokuya.co.uk> <8FD50E5A-C71E-4846-8321-09D8A1F67AEB@apple.com> Message-ID: <20070906124652.GM11470@daikokuya.co.uk> Chris Lattner wrote:- > clang currently has two distinct notions: we distinguish between what > class a particular diagnostic falls into from how it is reported. > These two categorizations are used by different pieces of the > diagnostic handling machinery. > > The first part of the diagnostics machinery is the piece that is > generating the diagnostics: the parser, lexer, sema, checking system, > etc. Each diagnostic itself is tagged (in DiagnosticKinds.def) with > a class, which is a member of the set > {NOTE,WARNING,EXTENSION,ERROR}. The important part of the > classification at this level is that it is completely independent of > how the diagnostic is reported and they have obvious meanings: > > 1. NOTEs (which aren't used and may be removed in the future) are > informational messages. For example, perhaps the optimizer could > emit information about which loops are vectorized etc. > > 2. WARNINGs are emitted for legal code that is questionable somehow. > > 3. EXTENSIONs are emitted for illegal code that is accepted anyway as > an extension to the language. > > 4. ERRORs flag a malformed program where error recovery techniques > must be used to continue parsing. > > I believe that each of these categories is well described and > simple. It is easy to determine which class any particular > diagnostic falls into. So client is just gets one of these severities and it's up to them how they handle it? > >a) Each diagnostic tag has a default severity suitable for normal > > compiles. Severities are, in order, suppress, remark, warning, > > soft error, hard error, fatal and maybe ice. > > In contrast to your system, we don't specify a "default mapping": > that is completely client-specific. Because the library generating > the diagnostic doesn't know/care about how these diagnostics are > emitted, we don't need to talk about suppressed diagnostics. I'm not > sure the distinction between soft/hard error in your scheme. To the client they're both errors. Only soft errors can have their severities changed by the user; hard errors are always hard errors. This was buried in my mail and probably not clear. > Fatal/ ICE are also interesting: we don't emit a diagnostic for these cases: > these are presumably internal consistency failures, where we prefer > to have the library assert/abort and die. Yeah, ICE should probably become fatal. #error is a good example of a fatal error - the std specifies translation should halt (something GCC gets wrong but it's hard to fix in GCC because of its architecture). > When diagnostics are reported by the parser (etc), they get routed > through the Diagnostic class. This class is designed to do various > types of mapping, which turns the class above into a concrete > diagnostic level. The level is completely different from the class, > but they have similar names (and are thus somewhat confusing). The > Diagnostic class maps each diagnostic onto the level set, which is > { Ignored, Note, Warning, Error, Fatal }. > > These levels are what we expect the tool to report to the user. As > you might expect, the {note,warning,extension} classes can be mapped > onto any of these levels, and the {error} class can only be mapped > onto {error,fatal}. OK. But is this mapping per-tag, or blanket for all tags? If the former, it seems unduly inflexible, and if the latter then why bother having a mapping (i.e. a severity at the raising side) at all? Why not just provide a diagnostic tag and leave it to the client what they want to do with it? I'm struggling to understand the rationale for the two-level nature of it. > I believe that this system is fully general: any interesting policy > the client wants can be implemented with this scheme > (Diagnostic::setDiagnosticMapping can be used to specify a level on a > per-diagnostic basis), and higher level policies (e.g. -Werror, - > pedantic, -pedantic-errors etc) can be easily handled by mapping > entire classes to levels. This kind of answers my question above I think, but my confusion remains. What about diagnostics, such as for line comments, that is an extension in one dialect but not another? Either you're duplicating the diagnostic tag, which means presenting the user with two tags for the same diagnostic, or you're requiring clients to know what is and isn't an extension in various dialects. What about integer division by zero? It should be a hard error in some contexts and not others, even for a single dialect. How does the client deal with that? It seems the only solution is two tags. I can imagine situations where essentially the same diagnostic needs to become three or four tags with multiple dialect support. > >Something I've not implemented yet is diagnostic groups, so > >you could give groups of tags a name and manipulate them > >en-masse, e.g. portability warnings, unused warnings, etc. > > This is also something that clang is missing. In particular, the > client would like to be able to manipulate groups at a coarse grain > to implement controls such as the GCC options -Wextra, -Wall, -W, > etc. These are basically controls that modify a whole set of > diagnostics. However, it is important to note that the groupings are > client specific, so this should be implemented in the driver, not in > the libraries. > > The original topic of discussion was what "extensions" should be > warned about even when -pedantic is not specified. In contrast to my > original proposal, I now don't think this should be another class of > warning, I think this should be controlled with the (currently > missing) diagnostic grouping mechanism in the driver. > > Is this design reasonable? I can see the reasoning behind it, but I'm not convinced it's the best approach for the reasons above. I may be misunderstanding how it works. One other thing - raising a diagnostic only for it to be suppressed at the client side can be expensive when various other information has to be calculated just to raise it. For example, a diagnostic indicating that one decl hides another. Depending on your symbol table, even determining that something hides something else, or what kind of entity it's hiding (nice to have that in the diagnostic) can take time. Another example is coming up with the English reprentation of types for diagnostics. You don't want to do all that work only to find the diagnostic is suppressed anyway. How do you intend to handle such things? Neil. From fjoe at samodelkin.net Thu Sep 6 10:59:34 2007 From: fjoe at samodelkin.net (Max Khon) Date: Thu, 6 Sep 2007 22:59:34 +0700 Subject: [cfe-dev] clang C++ volunteer In-Reply-To: <992b09980709052008i7de5ca8ey6b65d49aad1104a5@mail.gmail.com> References: <992b09980709052008i7de5ca8ey6b65d49aad1104a5@mail.gmail.com> Message-ID: <20070906155934.GA48959@samodelkin.net> Hi! On Wed, Sep 05, 2007 at 11:08:11PM -0400, Justin Handville wrote: > I understand that you are currently looking for developers to assist with > clang, specifically for the C++ front-end and for code generation tasks. > > I am willing to toss my hat in. I have some experience with compiler > development, mainly in the area of source-to-source compilers. What are the > current low-hanging fruit? There wouldn't by chance be a developer FAQ yet? > > While it is still very early for a definitive answer to this question, what > is planned for the STL implementation for clang? This would be a rich > source of test cases for the C++ front end. Are there alternatives to STLport? /fjoe From kremenek at apple.com Thu Sep 6 11:42:45 2007 From: kremenek at apple.com (Ted Kremenek) Date: Thu, 6 Sep 2007 09:42:45 -0700 Subject: [cfe-dev] GotoStmt::getSourceRange, bug? Message-ID: <174F62A4-C719-47B9-B7D7-914BF0B4127D@apple.com> I think there is a bug in the current implementation of getSourceRange for GotoStmt: class GotoStmt : public Stmt { LabelStmt *Label; SourceLocation GotoLoc; public: ... virtual SourceRange getSourceRange() const { return SourceRange(GotoLoc, Label->getLocEnd()); } ... }; I believe that getting the end SourceLocation using Label->getLocEnd() is incorrect. While the target LabelStmt is referenced by GotoStmt, it isn't a substatement in the tree. Consider the following snippet of code: l1: goto l1; Here, the GotoStmt is a substatement of the LabelStmt for "l1". The implementation of getSourceRange() in LabelStmt is as follows (notice the call to SubStmt->getLocEnd): class LabelStmt : public Stmt { IdentifierInfo *Label; Stmt *SubStmt; SourceLocation IdentLoc; public: ... virtual SourceRange getSourceRange() const { return SourceRange(IdentLoc, SubStmt->getLocEnd()); } .... }; There is an unbounded recursion here. While LabelStmt is correctly calling getLocEnd for its substatement, GotoStmt is incorrectly calling getLocEnd for the target LabelStmt. The question is that do we have enough extent information recorded in GotoStmt to accurately recreate the full source range for a goto statement? From snaroff at apple.com Thu Sep 6 11:58:16 2007 From: snaroff at apple.com (Steve Naroff) Date: Thu, 6 Sep 2007 09:58:16 -0700 Subject: [cfe-dev] GotoStmt::getSourceRange, bug? In-Reply-To: <174F62A4-C719-47B9-B7D7-914BF0B4127D@apple.com> References: <174F62A4-C719-47B9-B7D7-914BF0B4127D@apple.com> Message-ID: On Sep 6, 2007, at 9:42 AM, Ted Kremenek wrote: > The question is that do we have enough extent information recorded in > GotoStmt to accurately recreate the full source range for a goto > statement? Not currently. It looks like we need to add a "LabelLoc" to the AST (this is already passed into the actions, so it's trivial to do). Make sense? Thanks for finding this, snaroff > I think there is a bug in the current implementation of getSourceRange > for GotoStmt: > > > class GotoStmt : public Stmt { > LabelStmt *Label; > SourceLocation GotoLoc; > public: > ... > virtual SourceRange getSourceRange() const { > return SourceRange(GotoLoc, Label->getLocEnd()); > } > ... > }; > > > I believe that getting the end SourceLocation using Label->getLocEnd() > is incorrect. While the target LabelStmt is referenced by GotoStmt, > it isn't a substatement in the tree. Consider the following snippet > of code: > > l1: goto l1; > > Here, the GotoStmt is a substatement of the LabelStmt for "l1". The > implementation of getSourceRange() in LabelStmt is as follows (notice > the call to SubStmt->getLocEnd): > > > class LabelStmt : public Stmt { > IdentifierInfo *Label; > Stmt *SubStmt; > SourceLocation IdentLoc; > public: > ... > virtual SourceRange getSourceRange() const { > return SourceRange(IdentLoc, SubStmt->getLocEnd()); > } > .... > }; > > > There is an unbounded recursion here. While LabelStmt is correctly > calling getLocEnd for its substatement, GotoStmt is incorrectly > calling getLocEnd for the target LabelStmt. > > The question is that do we have enough extent information recorded in > GotoStmt to accurately recreate the full source range for a goto > statement? > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From uniheliodem at gmail.com Thu Sep 6 12:11:06 2007 From: uniheliodem at gmail.com (Justin Handville) Date: Thu, 6 Sep 2007 13:11:06 -0400 Subject: [cfe-dev] clang C++ volunteer In-Reply-To: <20070906155934.GA48959@samodelkin.net> References: <992b09980709052008i7de5ca8ey6b65d49aad1104a5@mail.gmail.com> <20070906155934.GA48959@samodelkin.net> Message-ID: <992b09980709061011x91d41dcj4ac15f0694798fba@mail.gmail.com> STLPort would be a quick solution to adding STL functionality to clang. Obviously, this is a long way off. Advantages: * (mostly) complete implementation of ISO/IEC 14882 2003. * thoroughly tested. Disadvantages: * lots of macro cruft for working with non-standard compilers and other implementations of STL. * May need to be updated to properly detect clang. As far as I know, STLPort would be the best library to use in this case, unless we wanted to go through the long process of rolling our own. On 9/6/07, Max Khon wrote: > Hi! > > On Wed, Sep 05, 2007 at 11:08:11PM -0400, Justin Handville wrote: > > > I understand that you are currently looking for developers to assist with > > clang, specifically for the C++ front-end and for code generation tasks. > > > > I am willing to toss my hat in. I have some experience with compiler > > development, mainly in the area of source-to-source compilers. What are the > > current low-hanging fruit? There wouldn't by chance be a developer FAQ yet? > > > > While it is still very early for a definitive answer to this question, what > > is planned for the STL implementation for clang? This would be a rich > > source of test cases for the C++ front end. > > Are there alternatives to STLport? > > /fjoe > From kremenek at apple.com Thu Sep 6 12:13:52 2007 From: kremenek at apple.com (Ted Kremenek) Date: Thu, 6 Sep 2007 10:13:52 -0700 Subject: [cfe-dev] GotoStmt::getSourceRange, bug? In-Reply-To: References: <174F62A4-C719-47B9-B7D7-914BF0B4127D@apple.com> Message-ID: <7DB74134-95B2-49F0-93E0-20582E709B08@apple.com> On Sep 6, 2007, at 9:58 AM, Steve Naroff wrote: > Not currently. It looks like we need to add a "LabelLoc" to the AST > (this is already passed into the actions, so it's trivial to do). > Make sense? > > Thanks for finding this, Cool. I've committed a patch. I'm terribly familiar with the mechanics of SourceLocations, so if someone could audit the patch that would be great. In particular, I'm not so certain about the following line in GotoStmt:getSourceRange: return SourceRange(GotoLoc, LabelLoc); This extent will only include from the start of the goto statement to the start of the label token (and not the end of the label token). Is this what we want? From snaroff at apple.com Thu Sep 6 12:34:56 2007 From: snaroff at apple.com (Steve Naroff) Date: Thu, 6 Sep 2007 10:34:56 -0700 Subject: [cfe-dev] GotoStmt::getSourceRange, bug? In-Reply-To: <7DB74134-95B2-49F0-93E0-20582E709B08@apple.com> References: <174F62A4-C719-47B9-B7D7-914BF0B4127D@apple.com> <7DB74134-95B2-49F0-93E0-20582E709B08@apple.com> Message-ID: <39D70E79-E3C0-4655-94E2-D7F185C20D6C@apple.com> On Sep 6, 2007, at 10:13 AM, Ted Kremenek wrote: > > On Sep 6, 2007, at 9:58 AM, Steve Naroff wrote: > >> Not currently. It looks like we need to add a "LabelLoc" to the >> AST (this is already passed into the actions, so it's trivial to >> do). Make sense? >> >> Thanks for finding this, > > Cool. I've committed a patch. I'm terribly familiar with the > mechanics of SourceLocations, so if someone could audit the patch > that would be great. > > In particular, I'm not so certain about the following line in > GotoStmt:getSourceRange: > > return SourceRange(GotoLoc, LabelLoc); > > This extent will only include from the start of the goto statement > to the start of the label token (and not the end of the label > token). Is this what we want? It is. It will derive the end of the label token through the magic of the routine below. This enables us to compute the range of identifiers (which are quite common) without caching pairs. Since the range protocol is typically used for error/diagnostics, performance isn't a problem... snaroff /// GetTokenLength - Given the source location of a token, determine its length. /// This is a fully general function that uses a lexer to relex the token. unsigned TextDiagnosticPrinter::GetTokenLength(SourceLocation Loc) { // If this comes from a macro expansion, we really do want the macro name, not // the token this macro expanded to. Loc = SourceMgr.getLogicalLoc(Loc); const char *StrData = SourceMgr.getCharacterData(Loc); // TODO: this could be special cased for common tokens like identifiers, ')', // etc to make this faster, if it mattered. This could use // Lexer::isObviouslySimpleCharacter for example. // Create a lexer starting at the beginning of this token. Lexer TheLexer(Loc, *ThePreprocessor, StrData); Token TheTok; TheLexer.LexRawToken(TheTok); return TheTok.getLength(); } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20070906/c0eb57e9/attachment.html From clattner at apple.com Thu Sep 6 12:48:47 2007 From: clattner at apple.com (Chris Lattner) Date: Thu, 6 Sep 2007 10:48:47 -0700 Subject: [cfe-dev] clang C++ volunteer In-Reply-To: <26846B8E-03ED-42B6-BF2C-920CE4A09E2B@gmail.com> References: <992b09980709052008i7de5ca8ey6b65d49aad1104a5@mail.gmail.com> <26846B8E-03ED-42B6-BF2C-920CE4A09E2B@gmail.com> Message-ID: > The C++ support is in an *extremely* early phase right now. There's > only named operators, bool, parsing for C++ casts, and references in > there right now. Some of the things to be done with the C++ casts and > references are: > > - Do semantic analysis for reference initialization. > - Do semantic analysis for casts. > > There's obviously a lot more to do. I would suggest taking small > steps; learning the code base and its architecture by adding smaller > features of the language. As far as a specific list of items, there > isn't any official one. Though I'd start with the two I mentioned > above (I have some code for the second of those, if you'd like to see > it) and proceed from there. I also added preliminary support for parsing namespace declarations as well. Right now there is no semantic analysis or AST building happening for them (they are just parsed and ignored) but implementing this would be a great way to get familiar with sema and AST interfaces. Once we can represent namespaces decls in the AST (and decls inside of them are properly nested) the next step would be to resolve x::y::z to the appropriate decl, then add support for using. The nice thing about C++ is that it's such a huge language that there are a large variety of parallel tasks that can be tackled at the same time :) -Chris From clattner at apple.com Thu Sep 6 12:51:36 2007 From: clattner at apple.com (Chris Lattner) Date: Thu, 6 Sep 2007 10:51:36 -0700 Subject: [cfe-dev] clang C++ volunteer In-Reply-To: <992b09980709061011x91d41dcj4ac15f0694798fba@mail.gmail.com> References: <992b09980709052008i7de5ca8ey6b65d49aad1104a5@mail.gmail.com> <20070906155934.GA48959@samodelkin.net> <992b09980709061011x91d41dcj4ac15f0694798fba@mail.gmail.com> Message-ID: <2A12FF36-C5E6-4A17-BD9A-9043D51784CF@apple.com> On Sep 6, 2007, at 10:11 AM, Justin Handville wrote: > STLPort would be a quick solution to adding STL functionality to > clang. Obviously, this is a long way off. > > Advantages: > * (mostly) complete implementation of ISO/IEC 14882 2003. > * thoroughly tested. > > Disadvantages: > * lots of macro cruft for working with non-standard compilers and > other implementations of STL. > * May need to be updated to properly detect clang. > > As far as I know, STLPort would be the best library to use in this > case, unless we wanted to go through the long process of rolling our > own. Working with STLport makes sense. We also plan to be compatible with GNU libstdc++ for ABI compatibility reasons. We're signing up to support GNU extensions, so we #define the "GNUC" macro, which means STLport shouldn't need an extra port for us (at least in GCC compat mode). -Chris From clattner at apple.com Thu Sep 6 13:27:12 2007 From: clattner at apple.com (Chris Lattner) Date: Thu, 6 Sep 2007 11:27:12 -0700 Subject: [cfe-dev] EXTENSION for some diags In-Reply-To: <20070906124652.GM11470@daikokuya.co.uk> References: <20070826044931.GS4363@daikokuya.co.uk> <431896BD-4F6A-4259-ACC0-14AE075C876B@apple.com> <20070826051531.GT4363@daikokuya.co.uk> <8FD50E5A-C71E-4846-8321-09D8A1F67AEB@apple.com> <20070906124652.GM11470@daikokuya.co.uk> Message-ID: <717B37B8-139C-4C4F-924C-2030E7387779@apple.com> >> Each diagnostic itself is tagged (in DiagnosticKinds.def) with >> a class, which is a member of the set >> {NOTE,WARNING,EXTENSION,ERROR}. The important part of the >> classification at this level is that it is completely independent of >> how the diagnostic is reported and they have obvious meanings: > > So client is just gets one of these severities and it's up to > them how they handle it? These are classifications, not severities. The Diagnostic class maps this onto a "level" which is basically a severity. The client implements the DiagnosticClient interface which is passed a level. >>> a) Each diagnostic tag has a default severity suitable for normal >>> compiles. Severities are, in order, suppress, remark, warning, >>> soft error, hard error, fatal and maybe ice. >> >> In contrast to your system, we don't specify a "default mapping": >> that is completely client-specific. Because the library generating >> the diagnostic doesn't know/care about how these diagnostics are >> emitted, we don't need to talk about suppressed diagnostics. I'm not >> sure the distinction between soft/hard error in your scheme. > > To the client they're both errors. Only soft errors can have their > severities changed by the user; hard errors are always hard errors. > This was buried in my mail and probably not clear. Ok, so soft errors don't require recovery I assume. >> Fatal/ ICE are also interesting: we don't emit a diagnostic for >> these cases: >> these are presumably internal consistency failures, where we prefer >> to have the library assert/abort and die. > > Yeah, ICE should probably become fatal. #error is a good example > of a fatal error - the std specifies translation should halt > (something > GCC gets wrong but it's hard to fix in GCC because of its > architecture). Interesting, good point. In clang, the client can choose to map it either to error or fatal. >> When diagnostics are reported by the parser (etc), they get routed >> through the Diagnostic class. This class is designed to do various >> types of mapping, which turns the class above into a concrete >> diagnostic level. The level is completely different from the class, >> but they have similar names (and are thus somewhat confusing). The >> Diagnostic class maps each diagnostic onto the level set, which is >> { Ignored, Note, Warning, Error, Fatal }. >> >> These levels are what we expect the tool to report to the user. As >> you might expect, the {note,warning,extension} classes can be mapped >> onto any of these levels, and the {error} class can only be mapped >> onto {error,fatal}. > > OK. But is this mapping per-tag, or blanket for all tags? The mapping is per-diagnostic. > If the > former, it seems unduly inflexible, and if the latter then why > bother having a mapping (i.e. a severity at the raising side) at > all? Why not just provide a diagnostic tag and leave it to the > client what they want to do with it? I'm struggling to understand > the rationale for the two-level nature of it. There are three separate stages here: producing diagnostics, mapping them, and reporting them somehow. In general, the parser just unconditionally emits diagnostics in some cases without care for how it will be reported. In other cases, computing whether the diagnostic should be emitted is expensive. For example "diag::pp_macro_not_used" requires looping over all macro definitions to determine whether any of them are unused. This warning is usually not enabled, so doing this computation is wasted work. To handle this, the parser makes a query the mapping code to see what level it will be mapped onto. If it is mapped onto ignore, the macro table isn't walked (the code is at Preprocessor.cpp:1112). Separating the mapping from reporting thus provides two features: 1) the parser can see how diagnostics will get mapped. 2) the mapping logic is shared among all the clients. >> I believe that this system is fully general: any interesting > policy >> the client wants can be implemented with this scheme >> (Diagnostic::setDiagnosticMapping can be used to specify a level on a >> per-diagnostic basis), and higher level policies (e.g. -Werror, - >> pedantic, -pedantic-errors etc) can be easily handled by mapping >> entire classes to levels. > > This kind of answers my question above I think, but my confusion > remains. > > What about diagnostics, such as for line comments, that is an > extension in one dialect but not another? I assume you mean "//" comments? In this case, we have logic like this (Lexer.cpp): if (!Features.BCPLComment) { Diag(BufferPtr, diag::ext_bcpl_comment); // Mark them enabled so we only emit one warning for this translation // unit. Features.BCPLComment = true; } If // comments aren't an extension in this dialect, then the warning is never produced, so it doesn't matter how it is mapped. > Either you're duplicating > the diagnostic tag, which means presenting the user with two tags > for the same diagnostic, or you're requiring clients to know what > is and isn't an extension in various dialects. We do sometimes have to duplicate the tag, for example if it's an extension in one dialect but a warning in another. This is actually ok though IMO, because you want the message to be different for the different cases. > What about integer division by zero? It should be a hard error in > some contexts and not others, even for a single dialect. How does > the client deal with that? It seems the only solution is two tags. > I can imagine situations where essentially the same diagnostic > needs to become three or four tags with multiple dialect support. We'd use two tags: this makes sense because the message should be different. In general, I'd like to have many fine-grained diagnostics with extremely helpful messages than trying to squish down the number we have. >> Is this design reasonable? > > I can see the reasoning behind it, but I'm not convinced it's the > best approach for the reasons above. I may be misunderstanding > how it works. Please let me know if the above helps :) > One other thing - raising a diagnostic only for it to be suppressed > at the client side can be expensive when various other information > has to be calculated just to raise it. For example, a diagnostic > indicating that one decl hides another. Depending on your symbol > table, even determining that something hides something else, or > what kind of entity it's hiding (nice to have that in the diagnostic) > can take time. Another example is coming up with the English > reprentation of types for diagnostics. You don't want to do all > that work only to find the diagnostic is suppressed anyway. How > do you intend to handle such things? I covered this above. -Chris From neil at daikokuya.co.uk Thu Sep 6 16:56:23 2007 From: neil at daikokuya.co.uk (Neil Booth) Date: Fri, 7 Sep 2007 06:56:23 +0900 Subject: [cfe-dev] EXTENSION for some diags In-Reply-To: <717B37B8-139C-4C4F-924C-2030E7387779@apple.com> References: <20070826044931.GS4363@daikokuya.co.uk> <431896BD-4F6A-4259-ACC0-14AE075C876B@apple.com> <20070826051531.GT4363@daikokuya.co.uk> <8FD50E5A-C71E-4846-8321-09D8A1F67AEB@apple.com> <20070906124652.GM11470@daikokuya.co.uk> <717B37B8-139C-4C4F-924C-2030E7387779@apple.com> Message-ID: <20070906215623.GQ11470@daikokuya.co.uk> Chris Lattner wrote:- > Please let me know if the above helps :) I think so. The need for classification seems weakened though, but lets see how it goes. It'll probably be clear once more stuff is in-place. Neil. From isanbard at gmail.com Thu Sep 6 23:01:51 2007 From: isanbard at gmail.com (Bill Wendling) Date: Thu, 6 Sep 2007 21:01:51 -0700 Subject: [cfe-dev] clang C++ volunteer In-Reply-To: <992b09980709060457h47bb9b62jfa32d26a29d199f9@mail.gmail.com> References: <992b09980709052008i7de5ca8ey6b65d49aad1104a5@mail.gmail.com> <26846B8E-03ED-42B6-BF2C-920CE4A09E2B@gmail.com> <992b09980709060457h47bb9b62jfa32d26a29d199f9@mail.gmail.com> Message-ID: On Sep 6, 2007, at 4:57 AM, Justin Handville wrote: >> The C++ support is in an *extremely* early phase right now. There's >> only named operators, bool, parsing for C++ casts, and references in >> there right now. Some of the things to be done with the C++ casts and >> references are: >> >> - Do semantic analysis for reference initialization. >> - Do semantic analysis for casts. >> >> There's obviously a lot more to do. I would suggest taking small >> steps; learning the code base and its architecture by adding smaller >> features of the language. As far as a specific list of items, there >> isn't any official one. Though I'd start with the two I mentioned >> above (I have some code for the second of those, if you'd like to see >> it) and proceed from there. > > Yes, I would be interested in seeing what you have so far to implement > semantic analysis for casts. I'll start digging into the code base > tonight to see how the AST is implemented. Hi Justin, Here's what I have so far for the C++ cast checking. Notice that the concept of "casting away constness" is not equivalent to checking that the const_cast operator is validly applied. It's a concept that's explain in the same section of the standard as the const_cast operator, though. The reinterpret_cast should be complete. The const_cast has a few more checks that need to be added to it. The static and dynamic casts are still undone (though dynamic_cast will have to wait until inheritance is supported). Let me know if you have questions about the code! -bw -------------- next part -------------- A non-text attachment was scrubbed... Name: cxx-cast.patch Type: application/octet-stream Size: 21819 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20070906/29f2643e/attachment-0001.obj -------------- next part -------------- From clattner at apple.com Fri Sep 7 01:30:22 2007 From: clattner at apple.com (Chris Lattner) Date: Thu, 6 Sep 2007 23:30:22 -0700 Subject: [cfe-dev] Newby questions In-Reply-To: <014601c7ec38$238486c0$0401a8c0@slartibartfast> References: <014401c7ec23$be4cc060$0401a8c0@slartibartfast> <20070901010233.GH11470@daikokuya.co.uk> <014601c7ec38$238486c0$0401a8c0@slartibartfast> Message-ID: <8EF979D6-18F0-49A3-82CD-ED0A4EDE8382@apple.com> On Aug 31, 2007, at 6:33 PM, Hartmut Kaiser wrote: > Neil Booth wrote: > >>> 1. I couldn't find any build instructions/project files to >> build clang >>> using MSVC8, so I decided to create these. I tried to use similar >>> build settings as have been used in the corresponding MSVC project >>> files for LLVM. Almost everything compiled fine, except for >> a bigger >>> issue and some really minor platform specific issues, which I have >>> been able to address. The bigger issue is that the clang::FileEntry >>> class retrieves the size of the file using stat, but because of the >>> EOL translation done on Windows the file usually is smaller >> in memory >>> than it is on disk. I introduced a hack in the >>> ReadFileFast() function to circumvent an infinite loop >> there, but this >>> has other effects I'm not able to resolve ad hoc. How is >> this solved in LLVM? >> >> I think we should be reading the files in binary mode. > > Ok, this did the trick. If you tell me, how I detect compilation on a > windows platform in LLVM/clang style (i.e. which pp constant to > use) I'll > submit a patch. I'm behind and not following closely, did the patch to open files in binary mode make it into the tree? > The errors I've seen were because of the problem above. Now > everything I > checked (especially wrt macro expansion order and macro parameter > evaluation) looks ok. Good job! There aren't too much preprocessors > around > being able to get all the Wave test cases right (so far, actually > besides > Wave itself there was only 'gcc -E' doing it correctly). Nice! We have a bunch of nasty testcases of our own in clang/test/ Preprocessor if you're interested. -Chris From hartmut.kaiser at gmail.com Fri Sep 7 08:17:00 2007 From: hartmut.kaiser at gmail.com (Hartmut Kaiser) Date: Fri, 7 Sep 2007 08:17:00 -0500 Subject: [cfe-dev] Newby questions In-Reply-To: <8EF979D6-18F0-49A3-82CD-ED0A4EDE8382@apple.com> References: <014401c7ec23$be4cc060$0401a8c0@slartibartfast> <20070901010233.GH11470@daikokuya.co.uk> <014601c7ec38$238486c0$0401a8c0@slartibartfast> <8EF979D6-18F0-49A3-82CD-ED0A4EDE8382@apple.com> Message-ID: <002b01c7f151$6095e630$0401a8c0@slartibartfast> Chris, > >> I think we should be reading the files in binary mode. > > > > Ok, this did the trick. If you tell me, how I detect > compilation on a > > windows platform in LLVM/clang style (i.e. which pp constant to > > use) I'll > > submit a patch. > > I'm behind and not following closely, did the patch to open > files in binary mode make it into the tree? It's in the SVN. The only thing I'm not sure with is the condition it is guarded by. Currently it's: #if defined(_WIN32) || defined(_WIN64) Windows specifics here #else ... #endif I just don't know, what's pp constant is usually used in Clang for this kind of stuff. Please advise. > > The errors I've seen were because of the problem above. Now > everything > > I checked (especially wrt macro expansion order and macro parameter > > evaluation) looks ok. Good job! There aren't too much preprocessors > > around being able to get all the Wave test cases right (so far, > > actually besides Wave itself there was only 'gcc -E' doing it > > correctly). > > Nice! We have a bunch of nasty testcases of our own in > clang/test/ Preprocessor if you're interested. Ohh! Cool. Found a bug in wave using these :-P! May I include the corresponding test to the Wave test suite in Boost? Regards Hartmut From asl at math.spbu.ru Fri Sep 7 09:26:27 2007 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Fri, 07 Sep 2007 18:26:27 +0400 Subject: [cfe-dev] Newby questions In-Reply-To: <002b01c7f151$6095e630$0401a8c0.SS1416SS@slartibartfast> References: <014401c7ec23$be4cc060$0401a8c0@slartibartfast> <20070901010233.GH11470@daikokuya.co.uk> <014601c7ec38$238486c0$0401a8c0@slartibartfast> <8EF979D6-18F0-49A3-82CD-ED0A4EDE8382@apple.com> <002b01c7f151$6095e630$0401a8c0.SS1416SS@slartibartfast> Message-ID: <1189175187.11114.48.camel@asl.dorms.spbu.ru> Hello, Harmut. > #if defined(_WIN32) || defined(_WIN64) > Windows specifics here > #else > .. > #endif Please don't forget about mingw32 :) It's also running on windows. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University. From hartmut.kaiser at gmail.com Fri Sep 7 09:37:23 2007 From: hartmut.kaiser at gmail.com (Hartmut Kaiser) Date: Fri, 7 Sep 2007 09:37:23 -0500 Subject: [cfe-dev] Newby questions In-Reply-To: <1189175187.11114.48.camel@asl.dorms.spbu.ru> References: <014401c7ec23$be4cc060$0401a8c0@slartibartfast> <20070901010233.GH11470@daikokuya.co.uk> <014601c7ec38$238486c0$0401a8c0@slartibartfast> <8EF979D6-18F0-49A3-82CD-ED0A4EDE8382@apple.com> <002b01c7f151$6095e630$0401a8c0.SS1416SS@slartibartfast> <1189175187.11114.48.camel@asl.dorms.spbu.ru> Message-ID: <003501c7f15c$9b9b4d00$0401a8c0@slartibartfast> > > #if defined(_WIN32) || defined(_WIN64) Windows specifics > here #else .. > > #endif > Please don't forget about mingw32 :) It's also running on windows. So what's the general approach to this kind of pp magic? Is there some existing pp constant I could use? And BTW, is there some config file for Clang? Regards Hartmut From criswell at uiuc.edu Fri Sep 7 11:53:02 2007 From: criswell at uiuc.edu (John Criswell) Date: Fri, 07 Sep 2007 10:53:02 -0600 Subject: [cfe-dev] LLVM Service Interruption Message-ID: <46E181EE.9090602@uiuc.edu> Dear All, My apologies, but I forgot to write this list to warn of some scheduled downtime of the LLVM server (llvm.org). We needed to move the physical server to a new location. I took the machine down at 10 am CDT. The move is complete and services have been restored. If you find something isn't working, please email either the cfe-dev list or the llvmdev list. -- John T. From Ar18 at comcast.net Fri Sep 7 15:43:34 2007 From: Ar18 at comcast.net (Ar18 at comcast.net) Date: Fri, 07 Sep 2007 20:43:34 +0000 Subject: [cfe-dev] LLVM Service Interruption Message-ID: <090720072043.17409.46E1B7F60004E47D000044012200763704C8CE9DBE@comcast.net> Hey John, I'm not sure if this is your area or not, but I am having a problem with the mailing list that is not related to the move. It appears that the mailing list is posting my complete email address (only slightly obfuscated). I tried, but I couldn't get it to change that setting like everyone else here seems to have. :( I'd like to be able to get my email address deleted from the archive before other archivers and spambots get ahold of it... also, and maybe fix it so it will stop listing my email address on the archive as well. :) -------------- Original message ---------------------- From: John Criswell > Dear All, > > My apologies, but I forgot to write this list to warn of some scheduled > downtime of the LLVM server (llvm.org). We needed to move the physical > server to a new location. I took the machine down at 10 am CDT. > > The move is complete and services have been restored. If you find > something isn't working, please email either the cfe-dev list or the > llvmdev list. > > -- John T. > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From uniheliodem at gmail.com Fri Sep 7 19:40:56 2007 From: uniheliodem at gmail.com (Justin Handville) Date: Fri, 7 Sep 2007 20:40:56 -0400 Subject: [cfe-dev] Clang build issues FreeBSD + gcc 4.2 Message-ID: <992b09980709071740h7962181m3ecafbfbe989eac2@mail.gmail.com> Here's the error I'm getting during a build against trunk. The getTokenName function is defined in the tok namespace. The build results and the patch are below. After applying the patch, the code compiles. $ gmake gmake[1]: Entering directory `/llvm-trunk/tools/clang/Basic' gmake[1]: Nothing to be done for `all'. gmake[1]: Leaving directory `/llvm-trunk/tools/clang/Basic' gmake[1]: Entering directory `/llvm-trunk/tools/clang/Lex' llvm[1]: Compiling IdentifierTable.cpp for Debug build In file included from /llvm-trunk/tools/clang/Lex/../include/clang/Lex/MacroInfo.h:17, from IdentifierTable.cpp:16: /llvm-trunk/tools/clang/Lex/../include/clang/Lex/Token.h: In member function 'const char* clang::Token::getName() const': /llvm-trunk/tools/clang/Lex/../include/clang/Lex/Token.h:64: error: 'getTokenName' was not declared in this scope gmake[1]: *** [/llvm-trunk/tools/clang/Lex/Debug/IdentifierTable.o] Error 1 gmake[1]: Leaving directory `/llvm-trunk/tools/clang/Lex' gmake: *** [all] Error 1 $ gcc --version gcc (GCC) 4.2.2 20070822 (prerelease) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ uname -a FreeBSD 6.2-STABLE FreeBSD 6.2-STABLE amd64 Here's the patch: Index: include/clang/Lex/Token.h =================================================================== --- include/clang/Lex/Token.h (revision 41776) +++ include/clang/Lex/Token.h (working copy) @@ -61,7 +61,7 @@ void setLocation(SourceLocation L) { Loc = L; } void setLength(unsigned Len) { Length = Len; } - const char *getName() const { return getTokenName(Kind); } + const char *getName() const { return tok::getTokenName(Kind); } /// startToken - Reset all flags to cleared. /// From clattner at apple.com Fri Sep 7 20:29:17 2007 From: clattner at apple.com (Chris Lattner) Date: Fri, 7 Sep 2007 18:29:17 -0700 Subject: [cfe-dev] Clang build issues FreeBSD + gcc 4.2 In-Reply-To: <992b09980709071740h7962181m3ecafbfbe989eac2@mail.gmail.com> References: <992b09980709071740h7962181m3ecafbfbe989eac2@mail.gmail.com> Message-ID: On Sep 7, 2007, at 5:40 PM, Justin Handville wrote: > Here's the error I'm getting during a build against trunk. The > getTokenName function is defined in the tok namespace. The build > results and the patch are below. After applying the patch, the code > compiles. Hrm, it looks like GCC 4.2.2 broke argument dependent lookup based on a bitfield enum argument. You should probably file a gcc bugzilla about this. In any case, relying on ADL is badness, so I applied your patch, thanks! -Chris > $ gmake > gmake[1]: Entering directory `/llvm-trunk/tools/clang/Basic' > gmake[1]: Nothing to be done for `all'. > gmake[1]: Leaving directory `/llvm-trunk/tools/clang/Basic' > gmake[1]: Entering directory `/llvm-trunk/tools/clang/Lex' > llvm[1]: Compiling IdentifierTable.cpp for Debug build > In file included from > /llvm-trunk/tools/clang/Lex/../include/clang/Lex/MacroInfo.h:17, > from IdentifierTable.cpp:16: > /llvm-trunk/tools/clang/Lex/../include/clang/Lex/Token.h: In member > function 'const char* clang::Token::getName() const': > /llvm-trunk/tools/clang/Lex/../include/clang/Lex/Token.h:64: error: > 'getTokenName' was not declared in this scope > gmake[1]: *** [/llvm-trunk/tools/clang/Lex/Debug/IdentifierTable.o] > Error 1 > gmake[1]: Leaving directory `/llvm-trunk/tools/clang/Lex' > gmake: *** [all] Error 1 > > $ gcc --version > gcc (GCC) 4.2.2 20070822 (prerelease) > Copyright (C) 2007 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. > There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR > PURPOSE. > > $ uname -a > FreeBSD 6.2-STABLE FreeBSD 6.2-STABLE amd64 > > Here's the patch: > > Index: include/clang/Lex/Token.h > =================================================================== > --- include/clang/Lex/Token.h (revision 41776) > +++ include/clang/Lex/Token.h (working copy) > @@ -61,7 +61,7 @@ > void setLocation(SourceLocation L) { Loc = L; } > void setLength(unsigned Len) { Length = Len; } > > - const char *getName() const { return getTokenName(Kind); } > + const char *getName() const { return tok::getTokenName(Kind); } > > /// startToken - Reset all flags to cleared. > /// > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From uniheliodem at gmail.com Fri Sep 7 20:35:45 2007 From: uniheliodem at gmail.com (Justin Handville) Date: Fri, 7 Sep 2007 21:35:45 -0400 Subject: [cfe-dev] Clang build issues FreeBSD + gcc 4.2 In-Reply-To: References: <992b09980709071740h7962181m3ecafbfbe989eac2@mail.gmail.com> Message-ID: <992b09980709071835v7f7eaa3axc064e328153a752b@mail.gmail.com> > Hrm, it looks like GCC 4.2.2 broke argument dependent lookup based on > a bitfield enum argument. You should probably file a gcc bugzilla > about this. > > In any case, relying on ADL is badness, so I applied your patch, thanks! > > -Chris Yeah, that's highly likely. I'll reduce it to a test case and submit it to gcc. Thanks, Justin From isanbard at gmail.com Sat Sep 8 19:59:48 2007 From: isanbard at gmail.com (Bill Wendling) Date: Sat, 8 Sep 2007 17:59:48 -0700 Subject: [cfe-dev] Not Warning About Invalid C Code Message-ID: Hi all, This program: struct t { unsigned long l; }; void g(struct t *); void bork() { const unsigned long v = 'vcgt'; struct t A = { v }; g(&A); } Should warn for C89/C90, but doesn't even with -pedantic set. Here's what GCC produces: $ gcc t.c -pedantic -c t.c: In function 'bork': t.c:9: warning: initializer element is not computable at load time Without the -pedantic flag, gcc accepts this without warning. -bw From snaroff at apple.com Sat Sep 8 22:17:26 2007 From: snaroff at apple.com (Steve Naroff) Date: Sat, 8 Sep 2007 20:17:26 -0700 Subject: [cfe-dev] Not Warning About Invalid C Code In-Reply-To: References: Message-ID: <8E3CD5F8-C5B8-41C0-A039-5A609042A8D8@apple.com> On Sep 8, 2007, at 5:59 PM, Bill Wendling wrote: > Hi all, > > This program: > > struct t { > unsigned long l; > }; > > void g(struct t *); > > void bork() { > const unsigned long v = 'vcgt'; > struct t A = { v }; > > g(&A); > } > > Should warn for C89/C90, but doesn't even with -pedantic set. Here's > what GCC produces: > > $ gcc t.c -pedantic -c > t.c: In function 'bork': > t.c:9: warning: initializer element is not computable at load time > > Without the -pedantic flag, gcc accepts this without warning. > This is because Sema::CheckInitializer() doesn't type check structs yet (for any dialect). Finishing type checking for initializers is on the short list... snaroff > -bw > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From uniheliodem at gmail.com Sat Sep 8 23:39:13 2007 From: uniheliodem at gmail.com (Justin Handville) Date: Sun, 9 Sep 2007 00:39:13 -0400 Subject: [cfe-dev] Bug in clang parsing pointer to an array in function parameter list Message-ID: <992b09980709082139x4760c934t685156c7a45c701e@mail.gmail.com> The following code snippet generates an assert when compiled with clang -emit-llvm int main(int argc, char* argv[]) { return 0; } Assert: Assertion failed: (getOperand(0)->getType() == cast(getOperand(1)->getType())->getElementType() && "Ptr must be a pointer to Val type!"), function AssertOK, file Instructions.cpp, line 796. The problem here is at line 116 of CGDecl.cpp: if (LTy->isFirstClassType()) { // TODO: Alignment DeclPtr = new llvm::AllocaInst(LTy, 0, std::string(D.getName())+".addr", AllocaInsertPt); // Store the initial value into the alloca. Builder.CreateStore(Arg, DeclPtr); //attempting to store char*[] as char** The problem is that llvm treats char*[] and char** as two distinct types as far as I can tell. EmitParmDecl should convert the type to a char** before calling CreateStore, since this is how the argument would be passed in C ABI. I assume that a transform step should be added before the CreateStore that could normalize the argument to match the declptr. I assume a good approach would be to descend through both Arg and DeclPtr, transforming Arg to match DeclPtr where compatible, or raising an appropriate diagnostic error if such a transformation is not possible. If I can get some approval that this route would work in this case, then I will go ahead and submit the patch. Thanks, Justin From uniheliodem at gmail.com Sat Sep 8 23:43:37 2007 From: uniheliodem at gmail.com (Justin Handville) Date: Sun, 9 Sep 2007 00:43:37 -0400 Subject: [cfe-dev] Bug in clang parsing pointer to an array in function parameter list In-Reply-To: <992b09980709082139x4760c934t685156c7a45c701e@mail.gmail.com> References: <992b09980709082139x4760c934t685156c7a45c701e@mail.gmail.com> Message-ID: <992b09980709082143n6f25d045t2bde296a2f25d313@mail.gmail.com> Perhaps the better question to ask is where should this transform occur? On 9/9/07, Justin Handville wrote: > The following code snippet generates an assert when compiled with > clang -emit-llvm > > int main(int argc, char* argv[]) > { > return 0; > } > > Assert: > > Assertion failed: (getOperand(0)->getType() == > cast(getOperand(1)->getType())->getElementType() && "Ptr > must be a pointer to Val type!"), function AssertOK, file > Instructions.cpp, line 796. > > The problem here is at line 116 of CGDecl.cpp: > > if (LTy->isFirstClassType()) { > // TODO: Alignment > DeclPtr = new llvm::AllocaInst(LTy, 0, std::string(D.getName())+".addr", > AllocaInsertPt); > > // Store the initial value into the alloca. > Builder.CreateStore(Arg, DeclPtr); //attempting to store > char*[] as char** > > The problem is that llvm treats char*[] and char** as two distinct > types as far as I can tell. EmitParmDecl should convert the type to a > char** before calling CreateStore, since this is how the argument > would be passed in C ABI. > > I assume that a transform step should be added before the CreateStore > that could normalize the argument to match the declptr. I assume a > good approach would be to descend through both Arg and DeclPtr, > transforming Arg to match DeclPtr where compatible, or raising an > appropriate diagnostic error if such a transformation is not possible. > > If I can get some approval that this route would work in this case, > then I will go ahead and submit the patch. > > Thanks, > Justin > From asl at math.spbu.ru Sun Sep 9 14:56:04 2007 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Sun, 09 Sep 2007 23:56:04 +0400 Subject: [cfe-dev] Newby questions In-Reply-To: <003501c7f15c$9b9b4d00$0401a8c0.SS333SS@slartibartfast> References: <014401c7ec23$be4cc060$0401a8c0@slartibartfast> <20070901010233.GH11470@daikokuya.co.uk> <014601c7ec38$238486c0$0401a8c0@slartibartfast> <8EF979D6-18F0-49A3-82CD-ED0A4EDE8382@apple.com> <002b01c7f151$6095e630$0401a8c0.SS1416SS@slartibartfast> <1189175187.11114.48.camel@asl.dorms.spbu.ru> <003501c7f15c$9b9b4d00$0401a8c0.SS333SS@slartibartfast> Message-ID: <1189367764.11114.62.camel@asl.dorms.spbu.ru> Hello, Hartmut > So what's the general approach to this kind of pp magic? Is there some > existing pp constant I could use? I don't exactly know, how the things are going in clang. But I'd really prefer not to use any platform-dependent defines in the "common" sources. Maybe some indirection via configuration defines (like "CLANG_ON_WINDOWS" - same as "LLVM_ON_UNIX" / "LLVM_ON_WINDOWS" and libSystem / libSupport) should be introduced. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University. From uniheliodem at gmail.com Sun Sep 9 17:32:52 2007 From: uniheliodem at gmail.com (Justin Handville) Date: Sun, 9 Sep 2007 18:32:52 -0400 Subject: [cfe-dev] Bug in clang parsing pointer to an array in function parameter list In-Reply-To: <992b09980709082143n6f25d045t2bde296a2f25d313@mail.gmail.com> References: <992b09980709082139x4760c934t685156c7a45c701e@mail.gmail.com> <992b09980709082143n6f25d045t2bde296a2f25d313@mail.gmail.com> Message-ID: <992b09980709091532g4de521b0wfffcd8fd13dc2562@mail.gmail.com> With the following patch, I can now compile and execute this source file: int puts(char*); int main(int argc, char* argv[]) { char* foo = argv[0]; puts(foo); return 0; } Here's the patch. I'm curious to see if this will work in all cases. I am still adding test cases to the build, so it is a bit experimental: ndex: CodeGen/CodeGenFunction.h =================================================================== --- CodeGen/CodeGenFunction.h (revision 41790) +++ CodeGen/CodeGenFunction.h (working copy) @@ -237,6 +237,11 @@ }; llvm::SmallVector BreakContinueStack; + static bool + isCompatibleDeclPointerType( + const llvm::Type* Arg, + const llvm::Type* DeclPtr); + public: CodeGenFunction(CodeGenModule &cgm); Index: CodeGen/CGDecl.cpp =================================================================== --- CodeGen/CGDecl.cpp (revision 41790) +++ CodeGen/CGDecl.cpp (working copy) @@ -96,11 +96,69 @@ } } +bool +CodeGenFunction::isCompatibleDeclPointerType( + const llvm::Type* ArgType, + const llvm::Type* DeclType) +{ + if( + ArgType->getTypeID() != llvm::Type::PointerTyID + || DeclType->getTypeID() != llvm::Type::PointerTyID) + { + return false; + } + + while( + ArgType->getNumContainedTypes() == 1 + && DeclType->getNumContainedTypes() == 1) + { + const llvm::Type* ArgContainedType = ArgType->getContainedType(0); + const llvm::Type* DeclContainedType = DeclType->getContainedType(0); + + //if the two contained types point to the same + //location, then these pointer types are compatible + if( + ArgContainedType == DeclContainedType) + { + return true; + } + //is the pointer indirection level different? + else if( + ArgContainedType->getNumContainedTypes() != + DeclContainedType->getNumContainedTypes()) + { + break; + } + //are these compatible pointer / array types? + else if( + llvm::SequentialType::classof(ArgContainedType) + && llvm::SequentialType::classof(DeclContainedType)) + { + if( ArgContainedType->getNumContainedTypes() != 1 ) + { + //FIXME will this ever happen with arrays / pointers? + break; + } + + ArgType = ArgContainedType; + DeclType = DeclContainedType; + } + else + { + //one or more of these is something other than an array / pointer + break; + } + } + + return false; +} + /// Emit an alloca for the specified parameter and set up LocalDeclMap. void CodeGenFunction::EmitParmDecl(const ParmVarDecl &D, llvm::Value *Arg) { QualType Ty = D.getCanonicalType(); llvm::Value *DeclPtr; + if (!Ty->isConstantSizeType(getContext())) { // Variable sized values always are passed by-reference. DeclPtr = Arg; @@ -111,7 +169,19 @@ // TODO: Alignment DeclPtr = new llvm::AllocaInst(LTy, 0, std::string(D.getName())+".addr", AllocaInsertPt); - + + //do we need to perform an implicit conversion? + if( isCompatibleDeclPointerType(Arg->getType(), DeclPtr->getType()) ) + { + llvm::Value* CastPtr = + Builder.CreateBitCast( + Arg, + LTy, + (std::string(D.getName()) + ".implconv").c_str()); + + Arg = CastPtr; + } + // Store the initial value into the alloca. Builder.CreateStore(Arg, DeclPtr); } else { On 9/9/07, Justin Handville wrote: > Perhaps the better question to ask is where should this transform occur? > > On 9/9/07, Justin Handville wrote: > > The following code snippet generates an assert when compiled with > > clang -emit-llvm > > > > int main(int argc, char* argv[]) > > { > > return 0; > > } > > > > Assert: > > > > Assertion failed: (getOperand(0)->getType() == > > cast(getOperand(1)->getType())->getElementType() && "Ptr > > must be a pointer to Val type!"), function AssertOK, file > > Instructions.cpp, line 796. > > > > The problem here is at line 116 of CGDecl.cpp: > > > > if (LTy->isFirstClassType()) { > > // TODO: Alignment > > DeclPtr = new llvm::AllocaInst(LTy, 0, std::string(D.getName())+".addr", > > AllocaInsertPt); > > > > // Store the initial value into the alloca. > > Builder.CreateStore(Arg, DeclPtr); //attempting to store > > char*[] as char** > > > > The problem is that llvm treats char*[] and char** as two distinct > > types as far as I can tell. EmitParmDecl should convert the type to a > > char** before calling CreateStore, since this is how the argument > > would be passed in C ABI. > > > > I assume that a transform step should be added before the CreateStore > > that could normalize the argument to match the declptr. I assume a > > good approach would be to descend through both Arg and DeclPtr, > > transforming Arg to match DeclPtr where compatible, or raising an > > appropriate diagnostic error if such a transformation is not possible. > > > > If I can get some approval that this route would work in this case, > > then I will go ahead and submit the patch. > > > > Thanks, > > Justin > > > From snaroff at apple.com Sun Sep 9 17:52:41 2007 From: snaroff at apple.com (Steve Naroff) Date: Sun, 9 Sep 2007 15:52:41 -0700 Subject: [cfe-dev] Bug in clang parsing pointer to an array in function parameter list In-Reply-To: <992b09980709091532g4de521b0wfffcd8fd13dc2562@mail.gmail.com> References: <992b09980709082139x4760c934t685156c7a45c701e@mail.gmail.com> <992b09980709082143n6f25d045t2bde296a2f25d313@mail.gmail.com> <992b09980709091532g4de521b0wfffcd8fd13dc2562@mail.gmail.com> Message-ID: On Sep 9, 2007, at 3:32 PM, Justin Handville wrote: > With the following patch, I can now compile and execute this source > file: > > int puts(char*); > > int main(int argc, char* argv[]) > { > char* foo = argv[0]; > > puts(foo); > > return 0; > } > Justin, I'm a bit confused. The front-end (Sema::ParseParamDeclarator) already converts argv from "char *[]" to "char **". See the "DeclRefExpr" node below (on line 6). I don't know why the code generator would need to fiddle with this. Chris will need to advise... snaroff [dylan:~/llvm/tools/clang] admin% ../../Debug/bin/clang justin.c - parse-ast-dump int puts(char *); int main(int argc, char *argv[]) (CompoundStmt 0x3105ed0 (DeclStmt 0x3105bf0 <:0:0> 0x3105dd0 "char *foo = (ArraySubscriptExpr 0x3105db0 'char *' (DeclRefExpr 0x3105d70 'char **' Decl='argv' 0x3105d40) (IntegerLiteral 0x3105d90 'int' 0))") (CallExpr 0x3105e70 'int' (ImplicitCastExpr 0x3105e60 'int (*)(char *)' (DeclRefExpr 0x3105e00 'int (char *)' Decl='puts' 0x3105c20)) (DeclRefExpr 0x3105e20 'char *' Decl='foo' 0x3105dd0)) (ReturnStmt 0x3105ec0 (IntegerLiteral 0x3105ea0 'int' 0))) > Here's the patch. I'm curious to see if this will work in all cases. > I am still adding test cases to the build, so it is a bit > experimental: > > ndex: CodeGen/CodeGenFunction.h > =================================================================== > --- CodeGen/CodeGenFunction.h (revision 41790) > +++ CodeGen/CodeGenFunction.h (working copy) > @@ -237,6 +237,11 @@ > }; > llvm::SmallVector BreakContinueStack; > > + static bool > + isCompatibleDeclPointerType( > + const llvm::Type* Arg, > + const llvm::Type* DeclPtr); > + > public: > CodeGenFunction(CodeGenModule &cgm); > > Index: CodeGen/CGDecl.cpp > =================================================================== > --- CodeGen/CGDecl.cpp (revision 41790) > +++ CodeGen/CGDecl.cpp (working copy) > @@ -96,11 +96,69 @@ > } > } > > +bool > +CodeGenFunction::isCompatibleDeclPointerType( > + const llvm::Type* ArgType, > + const llvm::Type* DeclType) > +{ > + if( > + ArgType->getTypeID() != llvm::Type::PointerTyID > + || DeclType->getTypeID() != llvm::Type::PointerTyID) > + { > + return false; > + } > + > + while( > + ArgType->getNumContainedTypes() == 1 > + && DeclType->getNumContainedTypes() == 1) > + { > + const llvm::Type* ArgContainedType = ArgType->getContainedType > (0); > + const llvm::Type* DeclContainedType = DeclType- > >getContainedType(0); > + > + //if the two contained types point to the same > + //location, then these pointer types are compatible > + if( > + ArgContainedType == DeclContainedType) > + { > + return true; > + } > + //is the pointer indirection level different? > + else if( > + ArgContainedType->getNumContainedTypes() != > + DeclContainedType->getNumContainedTypes()) > + { > + break; > + } > + //are these compatible pointer / array types? > + else if( > + llvm::SequentialType::classof(ArgContainedType) > + && llvm::SequentialType::classof(DeclContainedType)) > + { > + if( ArgContainedType->getNumContainedTypes() != 1 ) > + { > + //FIXME will this ever happen with arrays / pointers? > + break; > + } > + > + ArgType = ArgContainedType; > + DeclType = DeclContainedType; > + } > + else > + { > + //one or more of these is something other than an array / > pointer > + break; > + } > + } > + > + return false; > +} > + > /// Emit an alloca for the specified parameter and set up > LocalDeclMap. > void CodeGenFunction::EmitParmDecl(const ParmVarDecl &D, > llvm::Value *Arg) { > QualType Ty = D.getCanonicalType(); > > llvm::Value *DeclPtr; > + > if (!Ty->isConstantSizeType(getContext())) { > // Variable sized values always are passed by-reference. > DeclPtr = Arg; > @@ -111,7 +169,19 @@ > // TODO: Alignment > DeclPtr = new llvm::AllocaInst(LTy, 0, std::string(D.getName > ())+".addr", > AllocaInsertPt); > - > + > + //do we need to perform an implicit conversion? > + if( isCompatibleDeclPointerType(Arg->getType(), DeclPtr- > >getType()) ) > + { > + llvm::Value* CastPtr = > + Builder.CreateBitCast( > + Arg, > + LTy, > + (std::string(D.getName()) + ".implconv").c_str()); > + > + Arg = CastPtr; > + } > + > // Store the initial value into the alloca. > Builder.CreateStore(Arg, DeclPtr); > } else { > > On 9/9/07, Justin Handville wrote: >> Perhaps the better question to ask is where should this transform >> occur? >> >> On 9/9/07, Justin Handville wrote: >>> The following code snippet generates an assert when compiled with >>> clang -emit-llvm >>> >>> int main(int argc, char* argv[]) >>> { >>> return 0; >>> } >>> >>> Assert: >>> >>> Assertion failed: (getOperand(0)->getType() == >>> cast(getOperand(1)->getType())->getElementType() && >>> "Ptr >>> must be a pointer to Val type!"), function AssertOK, file >>> Instructions.cpp, line 796. >>> >>> The problem here is at line 116 of CGDecl.cpp: >>> >>> if (LTy->isFirstClassType()) { >>> // TODO: Alignment >>> DeclPtr = new llvm::AllocaInst(LTy, 0, std::string(D.getName >>> ())+".addr", >>> AllocaInsertPt); >>> >>> // Store the initial value into the alloca. >>> Builder.CreateStore(Arg, DeclPtr); //attempting to store >>> char*[] as char** >>> >>> The problem is that llvm treats char*[] and char** as two distinct >>> types as far as I can tell. EmitParmDecl should convert the type >>> to a >>> char** before calling CreateStore, since this is how the argument >>> would be passed in C ABI. >>> >>> I assume that a transform step should be added before the >>> CreateStore >>> that could normalize the argument to match the declptr. I assume a >>> good approach would be to descend through both Arg and DeclPtr, >>> transforming Arg to match DeclPtr where compatible, or raising an >>> appropriate diagnostic error if such a transformation is not >>> possible. >>> >>> If I can get some approval that this route would work in this case, >>> then I will go ahead and submit the patch. >>> >>> Thanks, >>> Justin >>> >> > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From uniheliodem at gmail.com Sun Sep 9 17:59:06 2007 From: uniheliodem at gmail.com (Justin Handville) Date: Sun, 9 Sep 2007 18:59:06 -0400 Subject: [cfe-dev] Bug in clang parsing pointer to an array in function parameter list In-Reply-To: References: <992b09980709082139x4760c934t685156c7a45c701e@mail.gmail.com> <992b09980709082143n6f25d045t2bde296a2f25d313@mail.gmail.com> <992b09980709091532g4de521b0wfffcd8fd13dc2562@mail.gmail.com> Message-ID: <992b09980709091559v58be5268r110c64ec1cbe2670@mail.gmail.com> Ah. Then I'll check in the front end. I thought that the char*[] in the parameter list looked a little funny, but I thought maybe that might be intended. Without the patch, the code asserts, since it is trying to store a char*[] into a char** location. It wouldn't be difficult to add the check to the appropriate place in the front end to change the argument declaration to a char**, as llvm-gcc does. On 9/9/07, Steve Naroff wrote: > > On Sep 9, 2007, at 3:32 PM, Justin Handville wrote: > > > With the following patch, I can now compile and execute this source > > file: > > > > int puts(char*); > > > > int main(int argc, char* argv[]) > > { > > char* foo = argv[0]; > > > > puts(foo); > > > > return 0; > > } > > > > Justin, > > I'm a bit confused. The front-end (Sema::ParseParamDeclarator) > already converts argv from "char *[]" to "char **". > > See the "DeclRefExpr" node below (on line 6). > > I don't know why the code generator would need to fiddle with this. > > Chris will need to advise... > > snaroff > > [dylan:~/llvm/tools/clang] admin% ../../Debug/bin/clang justin.c - > parse-ast-dump > > int puts(char *); > > int main(int argc, char *argv[]) > (CompoundStmt 0x3105ed0 > (DeclStmt 0x3105bf0 <:0:0> > 0x3105dd0 "char *foo = > (ArraySubscriptExpr 0x3105db0 'char *' > (DeclRefExpr 0x3105d70 'char **' Decl='argv' > 0x3105d40) > (IntegerLiteral 0x3105d90 'int' 0))") > (CallExpr 0x3105e70 'int' > (ImplicitCastExpr 0x3105e60 'int (*)(char *)' > (DeclRefExpr 0x3105e00 'int (char *)' Decl='puts' > 0x3105c20)) > (DeclRefExpr 0x3105e20 'char *' Decl='foo' 0x3105dd0)) > (ReturnStmt 0x3105ec0 > (IntegerLiteral 0x3105ea0 'int' 0))) > > > > Here's the patch. I'm curious to see if this will work in all cases. > > I am still adding test cases to the build, so it is a bit > > experimental: > > > > ndex: CodeGen/CodeGenFunction.h > > =================================================================== > > --- CodeGen/CodeGenFunction.h (revision 41790) > > +++ CodeGen/CodeGenFunction.h (working copy) > > @@ -237,6 +237,11 @@ > > }; > > llvm::SmallVector BreakContinueStack; > > > > + static bool > > + isCompatibleDeclPointerType( > > + const llvm::Type* Arg, > > + const llvm::Type* DeclPtr); > > + > > public: > > CodeGenFunction(CodeGenModule &cgm); > > > > Index: CodeGen/CGDecl.cpp > > =================================================================== > > --- CodeGen/CGDecl.cpp (revision 41790) > > +++ CodeGen/CGDecl.cpp (working copy) > > @@ -96,11 +96,69 @@ > > } > > } > > > > +bool > > +CodeGenFunction::isCompatibleDeclPointerType( > > + const llvm::Type* ArgType, > > + const llvm::Type* DeclType) > > +{ > > + if( > > + ArgType->getTypeID() != llvm::Type::PointerTyID > > + || DeclType->getTypeID() != llvm::Type::PointerTyID) > > + { > > + return false; > > + } > > + > > + while( > > + ArgType->getNumContainedTypes() == 1 > > + && DeclType->getNumContainedTypes() == 1) > > + { > > + const llvm::Type* ArgContainedType = ArgType->getContainedType > > (0); > > + const llvm::Type* DeclContainedType = DeclType- > > >getContainedType(0); > > + > > + //if the two contained types point to the same > > + //location, then these pointer types are compatible > > + if( > > + ArgContainedType == DeclContainedType) > > + { > > + return true; > > + } > > + //is the pointer indirection level different? > > + else if( > > + ArgContainedType->getNumContainedTypes() != > > + DeclContainedType->getNumContainedTypes()) > > + { > > + break; > > + } > > + //are these compatible pointer / array types? > > + else if( > > + llvm::SequentialType::classof(ArgContainedType) > > + && llvm::SequentialType::classof(DeclContainedType)) > > + { > > + if( ArgContainedType->getNumContainedTypes() != 1 ) > > + { > > + //FIXME will this ever happen with arrays / pointers? > > + break; > > + } > > + > > + ArgType = ArgContainedType; > > + DeclType = DeclContainedType; > > + } > > + else > > + { > > + //one or more of these is something other than an array / > > pointer > > + break; > > + } > > + } > > + > > + return false; > > +} > > + > > /// Emit an alloca for the specified parameter and set up > > LocalDeclMap. > > void CodeGenFunction::EmitParmDecl(const ParmVarDecl &D, > > llvm::Value *Arg) { > > QualType Ty = D.getCanonicalType(); > > > > llvm::Value *DeclPtr; > > + > > if (!Ty->isConstantSizeType(getContext())) { > > // Variable sized values always are passed by-reference. > > DeclPtr = Arg; > > @@ -111,7 +169,19 @@ > > // TODO: Alignment > > DeclPtr = new llvm::AllocaInst(LTy, 0, std::string(D.getName > > ())+".addr", > > AllocaInsertPt); > > - > > + > > + //do we need to perform an implicit conversion? > > + if( isCompatibleDeclPointerType(Arg->getType(), DeclPtr- > > >getType()) ) > > + { > > + llvm::Value* CastPtr = > > + Builder.CreateBitCast( > > + Arg, > > + LTy, > > + (std::string(D.getName()) + ".implconv").c_str()); > > + > > + Arg = CastPtr; > > + } > > + > > // Store the initial value into the alloca. > > Builder.CreateStore(Arg, DeclPtr); > > } else { > > > > On 9/9/07, Justin Handville wrote: > >> Perhaps the better question to ask is where should this transform > >> occur? > >> > >> On 9/9/07, Justin Handville wrote: > >>> The following code snippet generates an assert when compiled with > >>> clang -emit-llvm > >>> > >>> int main(int argc, char* argv[]) > >>> { > >>> return 0; > >>> } > >>> > >>> Assert: > >>> > >>> Assertion failed: (getOperand(0)->getType() == > >>> cast(getOperand(1)->getType())->getElementType() && > >>> "Ptr > >>> must be a pointer to Val type!"), function AssertOK, file > >>> Instructions.cpp, line 796. > >>> > >>> The problem here is at line 116 of CGDecl.cpp: > >>> > >>> if (LTy->isFirstClassType()) { > >>> // TODO: Alignment > >>> DeclPtr = new llvm::AllocaInst(LTy, 0, std::string(D.getName > >>> ())+".addr", > >>> AllocaInsertPt); > >>> > >>> // Store the initial value into the alloca. > >>> Builder.CreateStore(Arg, DeclPtr); //attempting to store > >>> char*[] as char** > >>> > >>> The problem is that llvm treats char*[] and char** as two distinct > >>> types as far as I can tell. EmitParmDecl should convert the type > >>> to a > >>> char** before calling CreateStore, since this is how the argument > >>> would be passed in C ABI. > >>> > >>> I assume that a transform step should be added before the > >>> CreateStore > >>> that could normalize the argument to match the declptr. I assume a > >>> good approach would be to descend through both Arg and DeclPtr, > >>> transforming Arg to match DeclPtr where compatible, or raising an > >>> appropriate diagnostic error if such a transformation is not > >>> possible. > >>> > >>> If I can get some approval that this route would work in this case, > >>> then I will go ahead and submit the patch. > >>> > >>> Thanks, > >>> Justin > >>> > >> > > _______________________________________________ > > cfe-dev mailing list > > cfe-dev at cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > > From uniheliodem at gmail.com Sun Sep 9 18:09:35 2007 From: uniheliodem at gmail.com (Justin Handville) Date: Sun, 9 Sep 2007 19:09:35 -0400 Subject: [cfe-dev] Bug in clang parsing pointer to an array in function parameter list In-Reply-To: <992b09980709091559v58be5268r110c64ec1cbe2670@mail.gmail.com> References: <992b09980709082139x4760c934t685156c7a45c701e@mail.gmail.com> <992b09980709082143n6f25d045t2bde296a2f25d313@mail.gmail.com> <992b09980709091532g4de521b0wfffcd8fd13dc2562@mail.gmail.com> <992b09980709091559v58be5268r110c64ec1cbe2670@mail.gmail.com> Message-ID: <992b09980709091609r1ee173d5qb18566a71aaca80b@mail.gmail.com> Also, note that the issue is with the initial store of the argv argument generated by the code generator, which isn't shown in the parse-ast-dump call. I'm still not familiar with the code base, so I'll need a little guidance with where this change belongs, but the bug definitely exists. On 9/9/07, Justin Handville wrote: > Ah. Then I'll check in the front end. I thought that the char*[] in > the parameter list looked a little funny, but I thought maybe that > might be intended. > > Without the patch, the code asserts, since it is trying to store a > char*[] into a char** location. It wouldn't be difficult to add the > check to the appropriate place in the front end to change the argument > declaration to a char**, as llvm-gcc does. > > On 9/9/07, Steve Naroff wrote: > > > > On Sep 9, 2007, at 3:32 PM, Justin Handville wrote: > > > > > With the following patch, I can now compile and execute this source > > > file: > > > > > > int puts(char*); > > > > > > int main(int argc, char* argv[]) > > > { > > > char* foo = argv[0]; > > > > > > puts(foo); > > > > > > return 0; > > > } > > > > > > > Justin, > > > > I'm a bit confused. The front-end (Sema::ParseParamDeclarator) > > already converts argv from "char *[]" to "char **". > > > > See the "DeclRefExpr" node below (on line 6). > > > > I don't know why the code generator would need to fiddle with this. > > > > Chris will need to advise... > > > > snaroff > > > > [dylan:~/llvm/tools/clang] admin% ../../Debug/bin/clang justin.c - > > parse-ast-dump > > > > int puts(char *); > > > > int main(int argc, char *argv[]) > > (CompoundStmt 0x3105ed0 > > (DeclStmt 0x3105bf0 <:0:0> > > 0x3105dd0 "char *foo = > > (ArraySubscriptExpr 0x3105db0 'char *' > > (DeclRefExpr 0x3105d70 'char **' Decl='argv' > > 0x3105d40) > > (IntegerLiteral 0x3105d90 'int' 0))") > > (CallExpr 0x3105e70 'int' > > (ImplicitCastExpr 0x3105e60 'int (*)(char *)' > > (DeclRefExpr 0x3105e00 'int (char *)' Decl='puts' > > 0x3105c20)) > > (DeclRefExpr 0x3105e20 'char *' Decl='foo' 0x3105dd0)) > > (ReturnStmt 0x3105ec0 > > (IntegerLiteral 0x3105ea0 'int' 0))) > > > > > > > Here's the patch. I'm curious to see if this will work in all cases. > > > I am still adding test cases to the build, so it is a bit > > > experimental: > > > > > > ndex: CodeGen/CodeGenFunction.h > > > =================================================================== > > > --- CodeGen/CodeGenFunction.h (revision 41790) > > > +++ CodeGen/CodeGenFunction.h (working copy) > > > @@ -237,6 +237,11 @@ > > > }; > > > llvm::SmallVector BreakContinueStack; > > > > > > + static bool > > > + isCompatibleDeclPointerType( > > > + const llvm::Type* Arg, > > > + const llvm::Type* DeclPtr); > > > + > > > public: > > > CodeGenFunction(CodeGenModule &cgm); > > > > > > Index: CodeGen/CGDecl.cpp > > > =================================================================== > > > --- CodeGen/CGDecl.cpp (revision 41790) > > > +++ CodeGen/CGDecl.cpp (working copy) > > > @@ -96,11 +96,69 @@ > > > } > > > } > > > > > > +bool > > > +CodeGenFunction::isCompatibleDeclPointerType( > > > + const llvm::Type* ArgType, > > > + const llvm::Type* DeclType) > > > +{ > > > + if( > > > + ArgType->getTypeID() != llvm::Type::PointerTyID > > > + || DeclType->getTypeID() != llvm::Type::PointerTyID) > > > + { > > > + return false; > > > + } > > > + > > > + while( > > > + ArgType->getNumContainedTypes() == 1 > > > + && DeclType->getNumContainedTypes() == 1) > > > + { > > > + const llvm::Type* ArgContainedType = ArgType->getContainedType > > > (0); > > > + const llvm::Type* DeclContainedType = DeclType- > > > >getContainedType(0); > > > + > > > + //if the two contained types point to the same > > > + //location, then these pointer types are compatible > > > + if( > > > + ArgContainedType == DeclContainedType) > > > + { > > > + return true; > > > + } > > > + //is the pointer indirection level different? > > > + else if( > > > + ArgContainedType->getNumContainedTypes() != > > > + DeclContainedType->getNumContainedTypes()) > > > + { > > > + break; > > > + } > > > + //are these compatible pointer / array types? > > > + else if( > > > + llvm::SequentialType::classof(ArgContainedType) > > > + && llvm::SequentialType::classof(DeclContainedType)) > > > + { > > > + if( ArgContainedType->getNumContainedTypes() != 1 ) > > > + { > > > + //FIXME will this ever happen with arrays / pointers? > > > + break; > > > + } > > > + > > > + ArgType = ArgContainedType; > > > + DeclType = DeclContainedType; > > > + } > > > + else > > > + { > > > + //one or more of these is something other than an array / > > > pointer > > > + break; > > > + } > > > + } > > > + > > > + return false; > > > +} > > > + > > > /// Emit an alloca for the specified parameter and set up > > > LocalDeclMap. > > > void CodeGenFunction::EmitParmDecl(const ParmVarDecl &D, > > > llvm::Value *Arg) { > > > QualType Ty = D.getCanonicalType(); > > > > > > llvm::Value *DeclPtr; > > > + > > > if (!Ty->isConstantSizeType(getContext())) { > > > // Variable sized values always are passed by-reference. > > > DeclPtr = Arg; > > > @@ -111,7 +169,19 @@ > > > // TODO: Alignment > > > DeclPtr = new llvm::AllocaInst(LTy, 0, std::string(D.getName > > > ())+".addr", > > > AllocaInsertPt); > > > - > > > + > > > + //do we need to perform an implicit conversion? > > > + if( isCompatibleDeclPointerType(Arg->getType(), DeclPtr- > > > >getType()) ) > > > + { > > > + llvm::Value* CastPtr = > > > + Builder.CreateBitCast( > > > + Arg, > > > + LTy, > > > + (std::string(D.getName()) + ".implconv").c_str()); > > > + > > > + Arg = CastPtr; > > > + } > > > + > > > // Store the initial value into the alloca. > > > Builder.CreateStore(Arg, DeclPtr); > > > } else { > > > > > > On 9/9/07, Justin Handville wrote: > > >> Perhaps the better question to ask is where should this transform > > >> occur? > > >> > > >> On 9/9/07, Justin Handville wrote: > > >>> The following code snippet generates an assert when compiled with > > >>> clang -emit-llvm > > >>> > > >>> int main(int argc, char* argv[]) > > >>> { > > >>> return 0; > > >>> } > > >>> > > >>> Assert: > > >>> > > >>> Assertion failed: (getOperand(0)->getType() == > > >>> cast(getOperand(1)->getType())->getElementType() && > > >>> "Ptr > > >>> must be a pointer to Val type!"), function AssertOK, file > > >>> Instructions.cpp, line 796. > > >>> > > >>> The problem here is at line 116 of CGDecl.cpp: > > >>> > > >>> if (LTy->isFirstClassType()) { > > >>> // TODO: Alignment > > >>> DeclPtr = new llvm::AllocaInst(LTy, 0, std::string(D.getName > > >>> ())+".addr", > > >>> AllocaInsertPt); > > >>> > > >>> // Store the initial value into the alloca. > > >>> Builder.CreateStore(Arg, DeclPtr); //attempting to store > > >>> char*[] as char** > > >>> > > >>> The problem is that llvm treats char*[] and char** as two distinct > > >>> types as far as I can tell. EmitParmDecl should convert the type > > >>> to a > > >>> char** before calling CreateStore, since this is how the argument > > >>> would be passed in C ABI. > > >>> > > >>> I assume that a transform step should be added before the > > >>> CreateStore > > >>> that could normalize the argument to match the declptr. I assume a > > >>> good approach would be to descend through both Arg and DeclPtr, > > >>> transforming Arg to match DeclPtr where compatible, or raising an > > >>> appropriate diagnostic error if such a transformation is not > > >>> possible. > > >>> > > >>> If I can get some approval that this route would work in this case, > > >>> then I will go ahead and submit the patch. > > >>> > > >>> Thanks, > > >>> Justin > > >>> > > >> > > > _______________________________________________ > > > cfe-dev mailing list > > > cfe-dev at cs.uiuc.edu > > > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > > > > > From uniheliodem at gmail.com Sun Sep 9 18:32:47 2007 From: uniheliodem at gmail.com (Justin Handville) Date: Sun, 9 Sep 2007 19:32:47 -0400 Subject: [cfe-dev] Bug in clang parsing pointer to an array in function parameter list In-Reply-To: <992b09980709091609r1ee173d5qb18566a71aaca80b@mail.gmail.com> References: <992b09980709082139x4760c934t685156c7a45c701e@mail.gmail.com> <992b09980709082143n6f25d045t2bde296a2f25d313@mail.gmail.com> <992b09980709091532g4de521b0wfffcd8fd13dc2562@mail.gmail.com> <992b09980709091559v58be5268r110c64ec1cbe2670@mail.gmail.com> <992b09980709091609r1ee173d5qb18566a71aaca80b@mail.gmail.com> Message-ID: <992b09980709091632n220ae754l92042d523e831615@mail.gmail.com> Okay. I found the section in Sema::ParseParamDeclarator where the bug is occurring. Apparently, this is where the fix needs to go. I'll work on analyzing why this code is failing, put together some test cases, and submit the patch at the appropriate place. I apologize, I'm still learning the code. On 9/9/07, Justin Handville wrote: > Also, note that the issue is with the initial store of the argv > argument generated by the code generator, which isn't shown in the > parse-ast-dump call. > > I'm still not familiar with the code base, so I'll need a little > guidance with where this change belongs, but the bug definitely > exists. > > On 9/9/07, Justin Handville wrote: > > Ah. Then I'll check in the front end. I thought that the char*[] in > > the parameter list looked a little funny, but I thought maybe that > > might be intended. > > > > Without the patch, the code asserts, since it is trying to store a > > char*[] into a char** location. It wouldn't be difficult to add the > > check to the appropriate place in the front end to change the argument > > declaration to a char**, as llvm-gcc does. > > > > On 9/9/07, Steve Naroff wrote: > > > > > > On Sep 9, 2007, at 3:32 PM, Justin Handville wrote: > > > > > > > With the following patch, I can now compile and execute this source > > > > file: > > > > > > > > int puts(char*); > > > > > > > > int main(int argc, char* argv[]) > > > > { > > > > char* foo = argv[0]; > > > > > > > > puts(foo); > > > > > > > > return 0; > > > > } > > > > > > > > > > Justin, > > > > > > I'm a bit confused. The front-end (Sema::ParseParamDeclarator) > > > already converts argv from "char *[]" to "char **". > > > > > > See the "DeclRefExpr" node below (on line 6). > > > > > > I don't know why the code generator would need to fiddle with this. > > > > > > Chris will need to advise... > > > > > > snaroff > > > > > > [dylan:~/llvm/tools/clang] admin% ../../Debug/bin/clang justin.c - > > > parse-ast-dump > > > > > > int puts(char *); > > > > > > int main(int argc, char *argv[]) > > > (CompoundStmt 0x3105ed0 > > > (DeclStmt 0x3105bf0 <:0:0> > > > 0x3105dd0 "char *foo = > > > (ArraySubscriptExpr 0x3105db0 'char *' > > > (DeclRefExpr 0x3105d70 'char **' Decl='argv' > > > 0x3105d40) > > > (IntegerLiteral 0x3105d90 'int' 0))") > > > (CallExpr 0x3105e70 'int' > > > (ImplicitCastExpr 0x3105e60 'int (*)(char *)' > > > (DeclRefExpr 0x3105e00 'int (char *)' Decl='puts' > > > 0x3105c20)) > > > (DeclRefExpr 0x3105e20 'char *' Decl='foo' 0x3105dd0)) > > > (ReturnStmt 0x3105ec0 > > > (IntegerLiteral 0x3105ea0 'int' 0))) > > > > > > > > > > Here's the patch. I'm curious to see if this will work in all cases. > > > > I am still adding test cases to the build, so it is a bit > > > > experimental: > > > > > > > > ndex: CodeGen/CodeGenFunction.h > > > > =================================================================== > > > > --- CodeGen/CodeGenFunction.h (revision 41790) > > > > +++ CodeGen/CodeGenFunction.h (working copy) > > > > @@ -237,6 +237,11 @@ > > > > }; > > > > llvm::SmallVector BreakContinueStack; > > > > > > > > + static bool > > > > + isCompatibleDeclPointerType( > > > > + const llvm::Type* Arg, > > > > + const llvm::Type* DeclPtr); > > > > + > > > > public: > > > > CodeGenFunction(CodeGenModule &cgm); > > > > > > > > Index: CodeGen/CGDecl.cpp > > > > =================================================================== > > > > --- CodeGen/CGDecl.cpp (revision 41790) > > > > +++ CodeGen/CGDecl.cpp (working copy) > > > > @@ -96,11 +96,69 @@ > > > > } > > > > } > > > > > > > > +bool > > > > +CodeGenFunction::isCompatibleDeclPointerType( > > > > + const llvm::Type* ArgType, > > > > + const llvm::Type* DeclType) > > > > +{ > > > > + if( > > > > + ArgType->getTypeID() != llvm::Type::PointerTyID > > > > + || DeclType->getTypeID() != llvm::Type::PointerTyID) > > > > + { > > > > + return false; > > > > + } > > > > + > > > > + while( > > > > + ArgType->getNumContainedTypes() == 1 > > > > + && DeclType->getNumContainedTypes() == 1) > > > > + { > > > > + const llvm::Type* ArgContainedType = ArgType->getContainedType > > > > (0); > > > > + const llvm::Type* DeclContainedType = DeclType- > > > > >getContainedType(0); > > > > + > > > > + //if the two contained types point to the same > > > > + //location, then these pointer types are compatible > > > > + if( > > > > + ArgContainedType == DeclContainedType) > > > > + { > > > > + return true; > > > > + } > > > > + //is the pointer indirection level different? > > > > + else if( > > > > + ArgContainedType->getNumContainedTypes() != > > > > + DeclContainedType->getNumContainedTypes()) > > > > + { > > > > + break; > > > > + } > > > > + //are these compatible pointer / array types? > > > > + else if( > > > > + llvm::SequentialType::classof(ArgContainedType) > > > > + && llvm::SequentialType::classof(DeclContainedType)) > > > > + { > > > > + if( ArgContainedType->getNumContainedTypes() != 1 ) > > > > + { > > > > + //FIXME will this ever happen with arrays / pointers? > > > > + break; > > > > + } > > > > + > > > > + ArgType = ArgContainedType; > > > > + DeclType = DeclContainedType; > > > > + } > > > > + else > > > > + { > > > > + //one or more of these is something other than an array / > > > > pointer > > > > + break; > > > > + } > > > > + } > > > > + > > > > + return false; > > > > +} > > > > + > > > > /// Emit an alloca for the specified parameter and set up > > > > LocalDeclMap. > > > > void CodeGenFunction::EmitParmDecl(const ParmVarDecl &D, > > > > llvm::Value *Arg) { > > > > QualType Ty = D.getCanonicalType(); > > > > > > > > llvm::Value *DeclPtr; > > > > + > > > > if (!Ty->isConstantSizeType(getContext())) { > > > > // Variable sized values always are passed by-reference. > > > > DeclPtr = Arg; > > > > @@ -111,7 +169,19 @@ > > > > // TODO: Alignment > > > > DeclPtr = new llvm::AllocaInst(LTy, 0, std::string(D.getName > > > > ())+".addr", > > > > AllocaInsertPt); > > > > - > > > > + > > > > + //do we need to perform an implicit conversion? > > > > + if( isCompatibleDeclPointerType(Arg->getType(), DeclPtr- > > > > >getType()) ) > > > > + { > > > > + llvm::Value* CastPtr = > > > > + Builder.CreateBitCast( > > > > + Arg, > > > > + LTy, > > > > + (std::string(D.getName()) + ".implconv").c_str()); > > > > + > > > > + Arg = CastPtr; > > > > + } > > > > + > > > > // Store the initial value into the alloca. > > > > Builder.CreateStore(Arg, DeclPtr); > > > > } else { > > > > > > > > On 9/9/07, Justin Handville wrote: > > > >> Perhaps the better question to ask is where should this transform > > > >> occur? > > > >> > > > >> On 9/9/07, Justin Handville wrote: > > > >>> The following code snippet generates an assert when compiled with > > > >>> clang -emit-llvm > > > >>> > > > >>> int main(int argc, char* argv[]) > > > >>> { > > > >>> return 0; > > > >>> } > > > >>> > > > >>> Assert: > > > >>> > > > >>> Assertion failed: (getOperand(0)->getType() == > > > >>> cast(getOperand(1)->getType())->getElementType() && > > > >>> "Ptr > > > >>> must be a pointer to Val type!"), function AssertOK, file > > > >>> Instructions.cpp, line 796. > > > >>> > > > >>> The problem here is at line 116 of CGDecl.cpp: > > > >>> > > > >>> if (LTy->isFirstClassType()) { > > > >>> // TODO: Alignment > > > >>> DeclPtr = new llvm::AllocaInst(LTy, 0, std::string(D.getName > > > >>> ())+".addr", > > > >>> AllocaInsertPt); > > > >>> > > > >>> // Store the initial value into the alloca. > > > >>> Builder.CreateStore(Arg, DeclPtr); //attempting to store > > > >>> char*[] as char** > > > >>> > > > >>> The problem is that llvm treats char*[] and char** as two distinct > > > >>> types as far as I can tell. EmitParmDecl should convert the type > > > >>> to a > > > >>> char** before calling CreateStore, since this is how the argument > > > >>> would be passed in C ABI. > > > >>> > > > >>> I assume that a transform step should be added before the > > > >>> CreateStore > > > >>> that could normalize the argument to match the declptr. I assume a > > > >>> good approach would be to descend through both Arg and DeclPtr, > > > >>> transforming Arg to match DeclPtr where compatible, or raising an > > > >>> appropriate diagnostic error if such a transformation is not > > > >>> possible. > > > >>> > > > >>> If I can get some approval that this route would work in this case, > > > >>> then I will go ahead and submit the patch. > > > >>> > > > >>> Thanks, > > > >>> Justin > > > >>> > > > >> > > > > _______________________________________________ > > > > cfe-dev mailing list > > > > cfe-dev at cs.uiuc.edu > > > > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > > > > > > > > > From snaroff at apple.com Sun Sep 9 19:13:21 2007 From: snaroff at apple.com (Steve Naroff) Date: Sun, 9 Sep 2007 17:13:21 -0700 Subject: [cfe-dev] Bug in clang parsing pointer to an array in function parameter list In-Reply-To: <992b09980709091632n220ae754l92042d523e831615@mail.gmail.com> References: <992b09980709082139x4760c934t685156c7a45c701e@mail.gmail.com> <992b09980709082143n6f25d045t2bde296a2f25d313@mail.gmail.com> <992b09980709091532g4de521b0wfffcd8fd13dc2562@mail.gmail.com> <992b09980709091559v58be5268r110c64ec1cbe2670@mail.gmail.com> <992b09980709091609r1ee173d5qb18566a71aaca80b@mail.gmail.com> <992b09980709091632n220ae754l92042d523e831615@mail.gmail.com> Message-ID: On Sep 9, 2007, at 4:32 PM, Justin Handville wrote: > Okay. I found the section in Sema::ParseParamDeclarator where the bug > is occurring. Apparently, this is where the fix needs to go. I'll > work on analyzing why this code is failing, put together some test > cases, and submit the patch at the appropriate place. I apologize, > I'm still learning the code. > No need to apologize. Here is some more data that might help... From my perspective, it's not clear the fix can be isolated to Sema::ParseParamDeclarator(). First, let's be clear on the bug. The bug is the functions type is not in sync with it's ParmVarDecl AST node. The function type is computed *before* calling Sema::ParseParamDeclarator(), which does the ParmVarDecl conversion. As a result, we could either... (a) Move the argument conversion "up" to Sema::GetTypeForDeclarator (). If we did this, the conversion code could be removed from Sema::ParseParamDeclarator(). (b) Have Sema::ParseParamDeclarator() some how change the functions type when it does the conversion for ParmVarDecl (I don't like this, put want to mention it for completeness). (c) See if it is possible for the code generator to rely on the ParmVarDecls, *not* the function type. Chris and I thought long and hard about this particular ParmVarDecl conversion (hence the large comment in the code). That said, this may well be a code gen bug. If not, then we will need to consider a front-end fix. snaroff Breakpoint 1, clang::Sema::GetTypeForDeclarator (this=0x2605900, D=@0xbffff2a0, S=0x2605a50) at SemaType.cpp:248 248 if (!FTI.hasPrototype) { (gdb) c Continuing. int (foo)(int, char *[]) Breakpoint 2, clang::Sema::ParseParamDeclarator (this=0x2605900, FTI=@0xbffff2c0, ArgNo=0, FnScope=0x2605b20) at SemaDecl.cpp:688 688 QualType parmDeclType = QualType::getFromOpaquePtr (PI.TypeInfo); > On 9/9/07, Justin Handville wrote: >> Also, note that the issue is with the initial store of the argv >> argument generated by the code generator, which isn't shown in the >> parse-ast-dump call. >> >> I'm still not familiar with the code base, so I'll need a little >> guidance with where this change belongs, but the bug definitely >> exists. >> >> On 9/9/07, Justin Handville wrote: >>> Ah. Then I'll check in the front end. I thought that the char* >>> [] in >>> the parameter list looked a little funny, but I thought maybe that >>> might be intended. >>> >>> Without the patch, the code asserts, since it is trying to store a >>> char*[] into a char** location. It wouldn't be difficult to add the >>> check to the appropriate place in the front end to change the >>> argument >>> declaration to a char**, as llvm-gcc does. >>> >>> On 9/9/07, Steve Naroff wrote: >>>> >>>> On Sep 9, 2007, at 3:32 PM, Justin Handville wrote: >>>> >>>>> With the following patch, I can now compile and execute this >>>>> source >>>>> file: >>>>> >>>>> int puts(char*); >>>>> >>>>> int main(int argc, char* argv[]) >>>>> { >>>>> char* foo = argv[0]; >>>>> >>>>> puts(foo); >>>>> >>>>> return 0; >>>>> } >>>>> >>>> >>>> Justin, >>>> >>>> I'm a bit confused. The front-end (Sema::ParseParamDeclarator) >>>> already converts argv from "char *[]" to "char **". >>>> >>>> See the "DeclRefExpr" node below (on line 6). >>>> >>>> I don't know why the code generator would need to fiddle with this. >>>> >>>> Chris will need to advise... >>>> >>>> snaroff >>>> >>>> [dylan:~/llvm/tools/clang] admin% ../../Debug/bin/clang justin.c - >>>> parse-ast-dump >>>> >>>> int puts(char *); >>>> >>>> int main(int argc, char *argv[]) >>>> (CompoundStmt 0x3105ed0 >>>> (DeclStmt 0x3105bf0 <:0:0> >>>> 0x3105dd0 "char *foo = >>>> (ArraySubscriptExpr 0x3105db0 >>>> 'char *' >>>> (DeclRefExpr 0x3105d70 'char **' Decl='argv' >>>> 0x3105d40) >>>> (IntegerLiteral 0x3105d90 'int' 0))") >>>> (CallExpr 0x3105e70 'int' >>>> (ImplicitCastExpr 0x3105e60 'int (*)(char *)' >>>> (DeclRefExpr 0x3105e00 'int (char *)' Decl='puts' >>>> 0x3105c20)) >>>> (DeclRefExpr 0x3105e20 'char *' Decl='foo' 0x3105dd0)) >>>> (ReturnStmt 0x3105ec0 >>>> (IntegerLiteral 0x3105ea0 'int' 0))) >>>> >>>> >>>>> Here's the patch. I'm curious to see if this will work in all >>>>> cases. >>>>> I am still adding test cases to the build, so it is a bit >>>>> experimental: >>>>> >>>>> ndex: CodeGen/CodeGenFunction.h >>>>> ================================================================== >>>>> = >>>>> --- CodeGen/CodeGenFunction.h (revision 41790) >>>>> +++ CodeGen/CodeGenFunction.h (working copy) >>>>> @@ -237,6 +237,11 @@ >>>>> }; >>>>> llvm::SmallVector BreakContinueStack; >>>>> >>>>> + static bool >>>>> + isCompatibleDeclPointerType( >>>>> + const llvm::Type* Arg, >>>>> + const llvm::Type* DeclPtr); >>>>> + >>>>> public: >>>>> CodeGenFunction(CodeGenModule &cgm); >>>>> >>>>> Index: CodeGen/CGDecl.cpp >>>>> ================================================================== >>>>> = >>>>> --- CodeGen/CGDecl.cpp (revision 41790) >>>>> +++ CodeGen/CGDecl.cpp (working copy) >>>>> @@ -96,11 +96,69 @@ >>>>> } >>>>> } >>>>> >>>>> +bool >>>>> +CodeGenFunction::isCompatibleDeclPointerType( >>>>> + const llvm::Type* ArgType, >>>>> + const llvm::Type* DeclType) >>>>> +{ >>>>> + if( >>>>> + ArgType->getTypeID() != llvm::Type::PointerTyID >>>>> + || DeclType->getTypeID() != llvm::Type::PointerTyID) >>>>> + { >>>>> + return false; >>>>> + } >>>>> + >>>>> + while( >>>>> + ArgType->getNumContainedTypes() == 1 >>>>> + && DeclType->getNumContainedTypes() == 1) >>>>> + { >>>>> + const llvm::Type* ArgContainedType = ArgType- >>>>> >getContainedType >>>>> (0); >>>>> + const llvm::Type* DeclContainedType = DeclType- >>>>>> getContainedType(0); >>>>> + >>>>> + //if the two contained types point to the same >>>>> + //location, then these pointer types are compatible >>>>> + if( >>>>> + ArgContainedType == DeclContainedType) >>>>> + { >>>>> + return true; >>>>> + } >>>>> + //is the pointer indirection level different? >>>>> + else if( >>>>> + ArgContainedType->getNumContainedTypes() != >>>>> + DeclContainedType->getNumContainedTypes()) >>>>> + { >>>>> + break; >>>>> + } >>>>> + //are these compatible pointer / array types? >>>>> + else if( >>>>> + llvm::SequentialType::classof(ArgContainedType) >>>>> + && llvm::SequentialType::classof(DeclContainedType)) >>>>> + { >>>>> + if( ArgContainedType->getNumContainedTypes() != 1 ) >>>>> + { >>>>> + //FIXME will this ever happen with arrays / pointers? >>>>> + break; >>>>> + } >>>>> + >>>>> + ArgType = ArgContainedType; >>>>> + DeclType = DeclContainedType; >>>>> + } >>>>> + else >>>>> + { >>>>> + //one or more of these is something other than an array / >>>>> pointer >>>>> + break; >>>>> + } >>>>> + } >>>>> + >>>>> + return false; >>>>> +} >>>>> + >>>>> /// Emit an alloca for the specified parameter and set up >>>>> LocalDeclMap. >>>>> void CodeGenFunction::EmitParmDecl(const ParmVarDecl &D, >>>>> llvm::Value *Arg) { >>>>> QualType Ty = D.getCanonicalType(); >>>>> >>>>> llvm::Value *DeclPtr; >>>>> + >>>>> if (!Ty->isConstantSizeType(getContext())) { >>>>> // Variable sized values always are passed by-reference. >>>>> DeclPtr = Arg; >>>>> @@ -111,7 +169,19 @@ >>>>> // TODO: Alignment >>>>> DeclPtr = new llvm::AllocaInst(LTy, 0, std::string >>>>> (D.getName >>>>> ())+".addr", >>>>> AllocaInsertPt); >>>>> - >>>>> + >>>>> + //do we need to perform an implicit conversion? >>>>> + if( isCompatibleDeclPointerType(Arg->getType(), DeclPtr- >>>>>> getType()) ) >>>>> + { >>>>> + llvm::Value* CastPtr = >>>>> + Builder.CreateBitCast( >>>>> + Arg, >>>>> + LTy, >>>>> + (std::string(D.getName()) + ".implconv").c_str()); >>>>> + >>>>> + Arg = CastPtr; >>>>> + } >>>>> + >>>>> // Store the initial value into the alloca. >>>>> Builder.CreateStore(Arg, DeclPtr); >>>>> } else { >>>>> >>>>> On 9/9/07, Justin Handville wrote: >>>>>> Perhaps the better question to ask is where should this transform >>>>>> occur? >>>>>> >>>>>> On 9/9/07, Justin Handville wrote: >>>>>>> The following code snippet generates an assert when compiled >>>>>>> with >>>>>>> clang -emit-llvm >>>>>>> >>>>>>> int main(int argc, char* argv[]) >>>>>>> { >>>>>>> return 0; >>>>>>> } >>>>>>> >>>>>>> Assert: >>>>>>> >>>>>>> Assertion failed: (getOperand(0)->getType() == >>>>>>> cast(getOperand(1)->getType())->getElementType() && >>>>>>> "Ptr >>>>>>> must be a pointer to Val type!"), function AssertOK, file >>>>>>> Instructions.cpp, line 796. >>>>>>> >>>>>>> The problem here is at line 116 of CGDecl.cpp: >>>>>>> >>>>>>> if (LTy->isFirstClassType()) { >>>>>>> // TODO: Alignment >>>>>>> DeclPtr = new llvm::AllocaInst(LTy, 0, std::string >>>>>>> (D.getName >>>>>>> ())+".addr", >>>>>>> AllocaInsertPt); >>>>>>> >>>>>>> // Store the initial value into the alloca. >>>>>>> Builder.CreateStore(Arg, DeclPtr); //attempting to store >>>>>>> char*[] as char** >>>>>>> >>>>>>> The problem is that llvm treats char*[] and char** as two >>>>>>> distinct >>>>>>> types as far as I can tell. EmitParmDecl should convert the >>>>>>> type >>>>>>> to a >>>>>>> char** before calling CreateStore, since this is how the >>>>>>> argument >>>>>>> would be passed in C ABI. >>>>>>> >>>>>>> I assume that a transform step should be added before the >>>>>>> CreateStore >>>>>>> that could normalize the argument to match the declptr. I >>>>>>> assume a >>>>>>> good approach would be to descend through both Arg and DeclPtr, >>>>>>> transforming Arg to match DeclPtr where compatible, or >>>>>>> raising an >>>>>>> appropriate diagnostic error if such a transformation is not >>>>>>> possible. >>>>>>> >>>>>>> If I can get some approval that this route would work in this >>>>>>> case, >>>>>>> then I will go ahead and submit the patch. >>>>>>> >>>>>>> Thanks, >>>>>>> Justin >>>>>>> >>>>>> >>>>> _______________________________________________ >>>>> cfe-dev mailing list >>>>> cfe-dev at cs.uiuc.edu >>>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev >>>> >>>> >>> >> From clattner at apple.com Sun Sep 9 19:18:53 2007 From: clattner at apple.com (Chris Lattner) Date: Sun, 9 Sep 2007 17:18:53 -0700 Subject: [cfe-dev] Newby questions In-Reply-To: <1189367764.11114.62.camel@asl.dorms.spbu.ru> References: <014401c7ec23$be4cc060$0401a8c0@slartibartfast> <20070901010233.GH11470@daikokuya.co.uk> <014601c7ec38$238486c0$0401a8c0@slartibartfast> <8EF979D6-18F0-49A3-82CD-ED0A4EDE8382@apple.com> <002b01c7f151$6095e630$0401a8c0.SS1416SS@slartibartfast> <1189175187.11114.48.camel@asl.dorms.spbu.ru> <003501c7f15c$9b9b4d00$0401a8c0.SS333SS@slartibartfast> <1189367764.11114.62.camel@asl.dorms.spbu.ru> Message-ID: <81E1C2B6-CBEC-44F3-BA02-2A3297638633@apple.com> On Sep 9, 2007, at 12:56 PM, Anton Korobeynikov wrote: > Hello, Hartmut > >> So what's the general approach to this kind of pp magic? Is there >> some >> existing pp constant I could use? > I don't exactly know, how the things are going in clang. But I'd > really > prefer not to use any platform-dependent defines in the "common" > sources. Maybe some indirection via configuration defines (like > "CLANG_ON_WINDOWS" - same as "LLVM_ON_UNIX" / "LLVM_ON_WINDOWS" and > libSystem / libSupport) should be introduced. clang gets access to all the llvm headers, so you should be able to do: #include "llvm/Config/config.h" #ifdef LLVM_ON_WIN32 ... #endif Does that work? -Chris From uniheliodem at gmail.com Sun Sep 9 19:40:36 2007 From: uniheliodem at gmail.com (Justin Handville) Date: Sun, 9 Sep 2007 20:40:36 -0400 Subject: [cfe-dev] Bug in clang parsing pointer to an array in function parameter list In-Reply-To: References: <992b09980709082139x4760c934t685156c7a45c701e@mail.gmail.com> <992b09980709082143n6f25d045t2bde296a2f25d313@mail.gmail.com> <992b09980709091532g4de521b0wfffcd8fd13dc2562@mail.gmail.com> <992b09980709091559v58be5268r110c64ec1cbe2670@mail.gmail.com> <992b09980709091609r1ee173d5qb18566a71aaca80b@mail.gmail.com> <992b09980709091632n220ae754l92042d523e831615@mail.gmail.com> Message-ID: <992b09980709091740s13b542fan45b17e70b0be11e0@mail.gmail.com> Well, I'll defer to you and Chris on this. Let me know where to make the change, and I will be more than happy to make it. Would this also be a good time to address the FIXME at the bottom of the comment in Sema::ParseParamDeclarator corresponding to this? On 9/9/07, Steve Naroff wrote: > > On Sep 9, 2007, at 4:32 PM, Justin Handville wrote: > > > Okay. I found the section in Sema::ParseParamDeclarator where the bug > > is occurring. Apparently, this is where the fix needs to go. I'll > > work on analyzing why this code is failing, put together some test > > cases, and submit the patch at the appropriate place. I apologize, > > I'm still learning the code. > > > > No need to apologize. Here is some more data that might help... > > From my perspective, it's not clear the fix can be isolated to > Sema::ParseParamDeclarator(). > > First, let's be clear on the bug. The bug is the functions type is > not in sync with it's ParmVarDecl AST node. > > The function type is computed *before* calling > Sema::ParseParamDeclarator(), which does the ParmVarDecl conversion. > As a result, we could either... > > (a) Move the argument conversion "up" to Sema::GetTypeForDeclarator > (). If we did this, the conversion code could be removed from > Sema::ParseParamDeclarator(). > (b) Have Sema::ParseParamDeclarator() some how change the functions > type when it does the conversion for ParmVarDecl (I don't like this, > put want to mention it for completeness). > (c) See if it is possible for the code generator to rely on the > ParmVarDecls, *not* the function type. Chris and I thought long and > hard about this particular ParmVarDecl conversion (hence the large > comment in the code). That said, this may well be a code gen bug. If > not, then we will need to consider a front-end fix. > > snaroff > > Breakpoint 1, clang::Sema::GetTypeForDeclarator (this=0x2605900, > D=@0xbffff2a0, S=0x2605a50) at SemaType.cpp:248 > 248 if (!FTI.hasPrototype) { > (gdb) c > Continuing. > int (foo)(int, char *[]) > > Breakpoint 2, clang::Sema::ParseParamDeclarator (this=0x2605900, > FTI=@0xbffff2c0, ArgNo=0, FnScope=0x2605b20) at SemaDecl.cpp:688 > 688 QualType parmDeclType = QualType::getFromOpaquePtr > (PI.TypeInfo); > > > On 9/9/07, Justin Handville wrote: > >> Also, note that the issue is with the initial store of the argv > >> argument generated by the code generator, which isn't shown in the > >> parse-ast-dump call. > >> > >> I'm still not familiar with the code base, so I'll need a little > >> guidance with where this change belongs, but the bug definitely > >> exists. > >> > >> On 9/9/07, Justin Handville wrote: > >>> Ah. Then I'll check in the front end. I thought that the char* > >>> [] in > >>> the parameter list looked a little funny, but I thought maybe that > >>> might be intended. > >>> > >>> Without the patch, the code asserts, since it is trying to store a > >>> char*[] into a char** location. It wouldn't be difficult to add the > >>> check to the appropriate place in the front end to change the > >>> argument > >>> declaration to a char**, as llvm-gcc does. > >>> > >>> On 9/9/07, Steve Naroff wrote: > >>>> > >>>> On Sep 9, 2007, at 3:32 PM, Justin Handville wrote: > >>>> > >>>>> With the following patch, I can now compile and execute this > >>>>> source > >>>>> file: > >>>>> > >>>>> int puts(char*); > >>>>> > >>>>> int main(int argc, char* argv[]) > >>>>> { > >>>>> char* foo = argv[0]; > >>>>> > >>>>> puts(foo); > >>>>> > >>>>> return 0; > >>>>> } > >>>>> > >>>> > >>>> Justin, > >>>> > >>>> I'm a bit confused. The front-end (Sema::ParseParamDeclarator) > >>>> already converts argv from "char *[]" to "char **". > >>>> > >>>> See the "DeclRefExpr" node below (on line 6). > >>>> > >>>> I don't know why the code generator would need to fiddle with this. > >>>> > >>>> Chris will need to advise... > >>>> > >>>> snaroff > >>>> > >>>> [dylan:~/llvm/tools/clang] admin% ../../Debug/bin/clang justin.c - > >>>> parse-ast-dump > >>>> > >>>> int puts(char *); > >>>> > >>>> int main(int argc, char *argv[]) > >>>> (CompoundStmt 0x3105ed0 > >>>> (DeclStmt 0x3105bf0 <:0:0> > >>>> 0x3105dd0 "char *foo = > >>>> (ArraySubscriptExpr 0x3105db0 > >>>> 'char *' > >>>> (DeclRefExpr 0x3105d70 'char **' Decl='argv' > >>>> 0x3105d40) > >>>> (IntegerLiteral 0x3105d90 'int' 0))") > >>>> (CallExpr 0x3105e70 'int' > >>>> (ImplicitCastExpr 0x3105e60 'int (*)(char *)' > >>>> (DeclRefExpr 0x3105e00 'int (char *)' Decl='puts' > >>>> 0x3105c20)) > >>>> (DeclRefExpr 0x3105e20 'char *' Decl='foo' 0x3105dd0)) > >>>> (ReturnStmt 0x3105ec0 > >>>> (IntegerLiteral 0x3105ea0 'int' 0))) > >>>> > >>>> > >>>>> Here's the patch. I'm curious to see if this will work in all > >>>>> cases. > >>>>> I am still adding test cases to the build, so it is a bit > >>>>> experimental: > >>>>> > >>>>> ndex: CodeGen/CodeGenFunction.h > >>>>> ================================================================== > >>>>> = > >>>>> --- CodeGen/CodeGenFunction.h (revision 41790) > >>>>> +++ CodeGen/CodeGenFunction.h (working copy) > >>>>> @@ -237,6 +237,11 @@ > >>>>> }; > >>>>> llvm::SmallVector BreakContinueStack; > >>>>> > >>>>> + static bool > >>>>> + isCompatibleDeclPointerType( > >>>>> + const llvm::Type* Arg, > >>>>> + const llvm::Type* DeclPtr); > >>>>> + > >>>>> public: > >>>>> CodeGenFunction(CodeGenModule &cgm); > >>>>> > >>>>> Index: CodeGen/CGDecl.cpp > >>>>> ================================================================== > >>>>> = > >>>>> --- CodeGen/CGDecl.cpp (revision 41790) > >>>>> +++ CodeGen/CGDecl.cpp (working copy) > >>>>> @@ -96,11 +96,69 @@ > >>>>> } > >>>>> } > >>>>> > >>>>> +bool > >>>>> +CodeGenFunction::isCompatibleDeclPointerType( > >>>>> + const llvm::Type* ArgType, > >>>>> + const llvm::Type* DeclType) > >>>>> +{ > >>>>> + if( > >>>>> + ArgType->getTypeID() != llvm::Type::PointerTyID > >>>>> + || DeclType->getTypeID() != llvm::Type::PointerTyID) > >>>>> + { > >>>>> + return false; > >>>>> + } > >>>>> + > >>>>> + while( > >>>>> + ArgType->getNumContainedTypes() == 1 > >>>>> + && DeclType->getNumContainedTypes() == 1) > >>>>> + { > >>>>> + const llvm::Type* ArgContainedType = ArgType- > >>>>> >getContainedType > >>>>> (0); > >>>>> + const llvm::Type* DeclContainedType = DeclType- > >>>>>> getContainedType(0); > >>>>> + > >>>>> + //if the two contained types point to the same > >>>>> + //location, then these pointer types are compatible > >>>>> + if( > >>>>> + ArgContainedType == DeclContainedType) > >>>>> + { > >>>>> + return true; > >>>>> + } > >>>>> + //is the pointer indirection level different? > >>>>> + else if( > >>>>> + ArgContainedType->getNumContainedTypes() != > >>>>> + DeclContainedType->getNumContainedTypes()) > >>>>> + { > >>>>> + break; > >>>>> + } > >>>>> + //are these compatible pointer / array types? > >>>>> + else if( > >>>>> + llvm::SequentialType::classof(ArgContainedType) > >>>>> + && llvm::SequentialType::classof(DeclContainedType)) > >>>>> + { > >>>>> + if( ArgContainedType->getNumContainedTypes() != 1 ) > >>>>> + { > >>>>> + //FIXME will this ever happen with arrays / pointers? > >>>>> + break; > >>>>> + } > >>>>> + > >>>>> + ArgType = ArgContainedType; > >>>>> + DeclType = DeclContainedType; > >>>>> + } > >>>>> + else > >>>>> + { > >>>>> + //one or more of these is something other than an array / > >>>>> pointer > >>>>> + break; > >>>>> + } > >>>>> + } > >>>>> + > >>>>> + return false; > >>>>> +} > >>>>> + > >>>>> /// Emit an alloca for the specified parameter and set up > >>>>> LocalDeclMap. > >>>>> void CodeGenFunction::EmitParmDecl(const ParmVarDecl &D, > >>>>> llvm::Value *Arg) { > >>>>> QualType Ty = D.getCanonicalType(); > >>>>> > >>>>> llvm::Value *DeclPtr; > >>>>> + > >>>>> if (!Ty->isConstantSizeType(getContext())) { > >>>>> // Variable sized values always are passed by-reference. > >>>>> DeclPtr = Arg; > >>>>> @@ -111,7 +169,19 @@ > >>>>> // TODO: Alignment > >>>>> DeclPtr = new llvm::AllocaInst(LTy, 0, std::string > >>>>> (D.getName > >>>>> ())+".addr", > >>>>> AllocaInsertPt); > >>>>> - > >>>>> + > >>>>> + //do we need to perform an implicit conversion? > >>>>> + if( isCompatibleDeclPointerType(Arg->getType(), DeclPtr- > >>>>>> getType()) ) > >>>>> + { > >>>>> + llvm::Value* CastPtr = > >>>>> + Builder.CreateBitCast( > >>>>> + Arg, > >>>>> + LTy, > >>>>> + (std::string(D.getName()) + ".implconv").c_str()); > >>>>> + > >>>>> + Arg = CastPtr; > >>>>> + } > >>>>> + > >>>>> // Store the initial value into the alloca. > >>>>> Builder.CreateStore(Arg, DeclPtr); > >>>>> } else { > >>>>> > >>>>> On 9/9/07, Justin Handville wrote: > >>>>>> Perhaps the better question to ask is where should this transform > >>>>>> occur? > >>>>>> > >>>>>> On 9/9/07, Justin Handville wrote: > >>>>>>> The following code snippet generates an assert when compiled > >>>>>>> with > >>>>>>> clang -emit-llvm > >>>>>>> > >>>>>>> int main(int argc, char* argv[]) > >>>>>>> { > >>>>>>> return 0; > >>>>>>> } > >>>>>>> > >>>>>>> Assert: > >>>>>>> > >>>>>>> Assertion failed: (getOperand(0)->getType() == > >>>>>>> cast(getOperand(1)->getType())->getElementType() && > >>>>>>> "Ptr > >>>>>>> must be a pointer to Val type!"), function AssertOK, file > >>>>>>> Instructions.cpp, line 796. > >>>>>>> > >>>>>>> The problem here is at line 116 of CGDecl.cpp: > >>>>>>> > >>>>>>> if (LTy->isFirstClassType()) { > >>>>>>> // TODO: Alignment > >>>>>>> DeclPtr = new llvm::AllocaInst(LTy, 0, std::string > >>>>>>> (D.getName > >>>>>>> ())+".addr", > >>>>>>> AllocaInsertPt); > >>>>>>> > >>>>>>> // Store the initial value into the alloca. > >>>>>>> Builder.CreateStore(Arg, DeclPtr); //attempting to store > >>>>>>> char*[] as char** > >>>>>>> > >>>>>>> The problem is that llvm treats char*[] and char** as two > >>>>>>> distinct > >>>>>>> types as far as I can tell. EmitParmDecl should convert the > >>>>>>> type > >>>>>>> to a > >>>>>>> char** before calling CreateStore, since this is how the > >>>>>>> argument > >>>>>>> would be passed in C ABI. > >>>>>>> > >>>>>>> I assume that a transform step should be added before the > >>>>>>> CreateStore > >>>>>>> that could normalize the argument to match the declptr. I > >>>>>>> assume a > >>>>>>> good approach would be to descend through both Arg and DeclPtr, > >>>>>>> transforming Arg to match DeclPtr where compatible, or > >>>>>>> raising an > >>>>>>> appropriate diagnostic error if such a transformation is not > >>>>>>> possible. > >>>>>>> > >>>>>>> If I can get some approval that this route would work in this > >>>>>>> case, > >>>>>>> then I will go ahead and submit the patch. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Justin > >>>>>>> > >>>>>> > >>>>> _______________________________________________ > >>>>> cfe-dev mailing list > >>>>> cfe-dev at cs.uiuc.edu > >>>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > >>>> > >>>> > >>> > >> > > From kremenek at apple.com Tue Sep 11 13:28:49 2007 From: kremenek at apple.com (Ted Kremenek) Date: Tue, 11 Sep 2007 11:28:49 -0700 Subject: [cfe-dev] parsing of self-referring vardecls Message-ID: <4A60B5A7-A3E2-4F98-A999-41EF61C3C709@apple.com> I'm not certain if vardecls are being correctly parsed. Consider the following program (self-decl.c): #include int foo(int var) { { // note the extra scope L1: int var = var+1; return var; } } int main() { printf("%d\n",foo(10)); return 0; } The output of this program is not what you might expected: (kremenek at grue:tmp)$ gcc -o self-decl self-decl.c (kremenek at grue:tmp)$ ./self-decl 1 What happens is that the declaration of "var" at label "L1" refers to itself, and thus is undefined. This is because "var" comes into scope before its initialization. I wrote a checker to look for such cases, but it isn't flagging any warnings because the initialization is falsely referring to the decl in the enclosing scope. This can be seen from a dump of the AST: int foo(int var) (CompoundStmt 0x710fd0 (CompoundStmt 0x710f60 (DeclStmt 0x70f210 <:0:0> 0x710f00 "int var = (BinaryOperator 0x710ee0 'int' '+' (DeclRefExpr 0x70ec50 'int' ParmVariable='var' 0x710e90) (IntegerLiteral 0x710ec0 'int' 1))") (ReturnStmt 0x710f50 (DeclRefExpr 0x710f30 'int' BlockVariable='var' 0x710f00)))) Notice the "DeclRefExpr" refers to the ParmVariable, not a VarDecl (the choice of using a parameter in this case just easily disambiguates this case, but "var" could have been a variable declared in any enclosing scope). From clattner at apple.com Tue Sep 11 15:53:32 2007 From: clattner at apple.com (Chris Lattner) Date: Tue, 11 Sep 2007 13:53:32 -0700 Subject: [cfe-dev] parsing of self-referring vardecls In-Reply-To: <4A60B5A7-A3E2-4F98-A999-41EF61C3C709@apple.com> References: <4A60B5A7-A3E2-4F98-A999-41EF61C3C709@apple.com> Message-ID: <28241019-0505-4155-B568-20C8A03C810E@apple.com> On Sep 11, 2007, at 11:28 AM, Ted Kremenek wrote: > I'm not certain if vardecls are being correctly parsed. Consider the > following program (self-decl.c): You're right, this looks like a bug in the initializer parsing stuff. "var" should be added to the scope chain before the initializer for var is parsed. This will require some juggling of the actions hooks though, so it will be non-trivial. Steve, can you add this to your todo list? -Chris > #include > > int foo(int var) > { > { // note the extra scope > L1: > int var = var+1; > return var; > } > } > > int main() { > printf("%d\n",foo(10)); > return 0; > } > > The output of this program is not what you might expected: > > (kremenek at grue:tmp)$ gcc -o self-decl self-decl.c > (kremenek at grue:tmp)$ ./self-decl > 1 > > > What happens is that the declaration of "var" at label "L1" refers to > itself, and thus is undefined. This is because "var" comes into scope > before its initialization. I wrote a checker to look for such cases, > but it isn't flagging any warnings because the initialization is > falsely referring to the decl in the enclosing scope. This can be > seen from a dump of the AST: > > int foo(int var) > (CompoundStmt 0x710fd0 > (CompoundStmt 0x710f60 > (DeclStmt 0x70f210 <:0:0> > 0x710f00 "int var = > (BinaryOperator 0x710ee0 'int' '+' > (DeclRefExpr 0x70ec50 'int' ParmVariable='var' > 0x710e90) > (IntegerLiteral 0x710ec0 'int' 1))") > (ReturnStmt 0x710f50 > (DeclRefExpr 0x710f30 'int' BlockVariable='var' > 0x710f00)))) > > Notice the "DeclRefExpr" refers to the ParmVariable, not a VarDecl > (the choice of using a parameter in this case just easily > disambiguates this case, but "var" could have been a variable declared > in any enclosing scope). > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From snaroff at apple.com Tue Sep 11 16:14:43 2007 From: snaroff at apple.com (Steve Naroff) Date: Tue, 11 Sep 2007 14:14:43 -0700 Subject: [cfe-dev] parsing of self-referring vardecls In-Reply-To: <28241019-0505-4155-B568-20C8A03C810E@apple.com> References: <4A60B5A7-A3E2-4F98-A999-41EF61C3C709@apple.com> <28241019-0505-4155-B568-20C8A03C810E@apple.com> Message-ID: On Sep 11, 2007, at 1:53 PM, Chris Lattner wrote: > On Sep 11, 2007, at 11:28 AM, Ted Kremenek wrote: >> I'm not certain if vardecls are being correctly parsed. Consider the >> following program (self-decl.c): > > You're right, this looks like a bug in the initializer parsing > stuff. "var" should be added to the scope chain before the > initializer for var is parsed. This will require some juggling of > the actions hooks though, so it will be non-trivial. > > Steve, can you add this to your todo list? > Already added...Ted and I discussed this over lunch. As you say, the fix requires some redesign of the parser/action dance... snaroff > -Chris > >> #include >> >> int foo(int var) >> { >> { // note the extra scope >> L1: >> int var = var+1; >> return var; >> } >> } >> >> int main() { >> printf("%d\n",foo(10)); >> return 0; >> } >> >> The output of this program is not what you might expected: >> >> (kremenek at grue:tmp)$ gcc -o self-decl self-decl.c >> (kremenek at grue:tmp)$ ./self-decl >> 1 >> >> >> What happens is that the declaration of "var" at label "L1" refers to >> itself, and thus is undefined. This is because "var" comes into >> scope >> before its initialization. I wrote a checker to look for such cases, >> but it isn't flagging any warnings because the initialization is >> falsely referring to the decl in the enclosing scope. This can be >> seen from a dump of the AST: >> >> int foo(int var) >> (CompoundStmt 0x710fd0 >> (CompoundStmt 0x710f60 >> (DeclStmt 0x70f210 <:0:0> >> 0x710f00 "int var = >> (BinaryOperator 0x710ee0 'int' '+' >> (DeclRefExpr 0x70ec50 'int' ParmVariable='var' >> 0x710e90) >> (IntegerLiteral 0x710ec0 'int' 1))") >> (ReturnStmt 0x710f50 >> (DeclRefExpr 0x710f30 'int' BlockVariable='var' >> 0x710f00)))) >> >> Notice the "DeclRefExpr" refers to the ParmVariable, not a VarDecl >> (the choice of using a parameter in this case just easily >> disambiguates this case, but "var" could have been a variable >> declared >> in any enclosing scope). >> _______________________________________________ >> 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 clattner at apple.com Tue Sep 11 16:37:11 2007 From: clattner at apple.com (Chris Lattner) Date: Tue, 11 Sep 2007 14:37:11 -0700 Subject: [cfe-dev] parsing of self-referring vardecls In-Reply-To: References: <4A60B5A7-A3E2-4F98-A999-41EF61C3C709@apple.com> <28241019-0505-4155-B568-20C8A03C810E@apple.com> Message-ID: On Sep 11, 2007, at 2:14 PM, Steve Naroff wrote: > On Sep 11, 2007, at 1:53 PM, Chris Lattner wrote: > >> On Sep 11, 2007, at 11:28 AM, Ted Kremenek wrote: >>> I'm not certain if vardecls are being correctly parsed. Consider >>> the >>> following program (self-decl.c): >> >> You're right, this looks like a bug in the initializer parsing >> stuff. "var" should be added to the scope chain before the >> initializer for var is parsed. This will require some juggling of >> the actions hooks though, so it will be non-trivial. >> >> Steve, can you add this to your todo list? >> > > Already added...Ted and I discussed this over lunch. > > As you say, the fix requires some redesign of the parser/action > dance... Thanks Steve! -Chris From clattner at apple.com Wed Sep 12 01:54:09 2007 From: clattner at apple.com (Chris Lattner) Date: Tue, 11 Sep 2007 23:54:09 -0700 Subject: [cfe-dev] Newby questions In-Reply-To: <003501c7f15c$9b9b4d00$0401a8c0@slartibartfast> References: <014401c7ec23$be4cc060$0401a8c0@slartibartfast> <20070901010233.GH11470@daikokuya.co.uk> <014601c7ec38$238486c0$0401a8c0@slartibartfast> <8EF979D6-18F0-49A3-82CD-ED0A4EDE8382@apple.com> <002b01c7f151$6095e630$0401a8c0.SS1416SS@slartibartfast> <1189175187.11114.48.camel@asl.dorms.spbu.ru> <003501c7f15c$9b9b4d00$0401a8c0@slartibartfast> Message-ID: <03DE46B4-94D8-4386-9B2F-E71F67D7814C@apple.com> On Sep 7, 2007, at 7:37 AM, Hartmut Kaiser wrote: > >>> #if defined(_WIN32) || defined(_WIN64) Windows specifics >> here #else .. >>> #endif >> Please don't forget about mingw32 :) It's also running on windows. > > So what's the general approach to this kind of pp magic? Is there some > existing pp constant I could use? > And BTW, is there some config file for Clang? Hartmut, does #ifdef LLVM_ON_WIN32 work after #include "llvm/Config/config.h" ? -Chris From clattner at apple.com Wed Sep 12 01:54:28 2007 From: clattner at apple.com (Chris Lattner) Date: Tue, 11 Sep 2007 23:54:28 -0700 Subject: [cfe-dev] Newby questions In-Reply-To: <002b01c7f151$6095e630$0401a8c0@slartibartfast> References: <014401c7ec23$be4cc060$0401a8c0@slartibartfast> <20070901010233.GH11470@daikokuya.co.uk> <014601c7ec38$238486c0$0401a8c0@slartibartfast> <8EF979D6-18F0-49A3-82CD-ED0A4EDE8382@apple.com> <002b01c7f151$6095e630$0401a8c0@slartibartfast> Message-ID: <81814244-A5EE-479E-A445-B480B788289D@apple.com> On Sep 7, 2007, at 6:17 AM, Hartmut Kaiser wrote: >>> The errors I've seen were because of the problem above. Now >> everything >>> I checked (especially wrt macro expansion order and macro parameter >>> evaluation) looks ok. Good job! There aren't too much preprocessors >>> around being able to get all the Wave test cases right (so far, >>> actually besides Wave itself there was only 'gcc -E' doing it >>> correctly). >> >> Nice! We have a bunch of nasty testcases of our own in >> clang/test/ Preprocessor if you're interested. > > Ohh! Cool. Found a bug in wave using these :-P! May I include the > corresponding test to the Wave test suite in Boost? > Sure, go for it. -Chris From hartmut.kaiser at gmail.com Wed Sep 12 10:39:05 2007 From: hartmut.kaiser at gmail.com (Hartmut Kaiser) Date: Wed, 12 Sep 2007 10:39:05 -0500 Subject: [cfe-dev] Newby questions In-Reply-To: <03DE46B4-94D8-4386-9B2F-E71F67D7814C@apple.com> References: <014401c7ec23$be4cc060$0401a8c0@slartibartfast> <20070901010233.GH11470@daikokuya.co.uk> <014601c7ec38$238486c0$0401a8c0@slartibartfast> <8EF979D6-18F0-49A3-82CD-ED0A4EDE8382@apple.com> <002b01c7f151$6095e630$0401a8c0.SS1416SS@slartibartfast> <1189175187.11114.48.camel@asl.dorms.spbu.ru> <003501c7f15c$9b9b4d00$0401a8c0@slartibartfast> <03DE46B4-94D8-4386-9B2F-E71F67D7814C@apple.com> Message-ID: <027201c7f553$12cf1380$0401a8c0@slartibartfast> Chris, > >>> #if defined(_WIN32) || defined(_WIN64) Windows specifics > >> here #else .. > >>> #endif > >> Please don't forget about mingw32 :) It's also running on windows. > > > > So what's the general approach to this kind of pp magic? Is > there some > > existing pp constant I could use? > > And BTW, is there some config file for Clang? > > does #ifdef LLVM_ON_WIN32 work after #include "llvm/Config/config.h" ? Sure, this does work. Thanks. Regards Hartmut From clattner at apple.com Wed Sep 12 12:21:26 2007 From: clattner at apple.com (Chris Lattner) Date: Wed, 12 Sep 2007 10:21:26 -0700 Subject: [cfe-dev] Newby questions In-Reply-To: <027201c7f553$12cf1380$0401a8c0@slartibartfast> References: <014401c7ec23$be4cc060$0401a8c0@slartibartfast> <20070901010233.GH11470@daikokuya.co.uk> <014601c7ec38$238486c0$0401a8c0@slartibartfast> <8EF979D6-18F0-49A3-82CD-ED0A4EDE8382@apple.com> <002b01c7f151$6095e630$0401a8c0.SS1416SS@slartibartfast> <1189175187.11114.48.camel@asl.dorms.spbu.ru> <003501c7f15c$9b9b4d00$0401a8c0@slartibartfast> <03DE46B4-94D8-4386-9B2F-E71F67D7814C@apple.com> <027201c7f553$12cf1380$0401a8c0@slartibartfast> Message-ID: <295F5119-7B2A-48F2-B31C-E1214D9592DD@apple.com> On Sep 12, 2007, at 8:39 AM, Hartmut Kaiser wrote: > Chris, > >>>>> #if defined(_WIN32) || defined(_WIN64) Windows specifics >>>> here #else .. >>>>> #endif >>>> Please don't forget about mingw32 :) It's also running on windows. >>> >>> So what's the general approach to this kind of pp magic? Is >> there some >>> existing pp constant I could use? >>> And BTW, is there some config file for Clang? >> >> does #ifdef LLVM_ON_WIN32 work after #include "llvm/Config/ >> config.h" ? > > Sure, this does work. Thanks. Nice, thanks! -Chris From clattner at apple.com Wed Sep 12 13:46:40 2007 From: clattner at apple.com (Chris Lattner) Date: Wed, 12 Sep 2007 11:46:40 -0700 Subject: [cfe-dev] diff for clang environment variables/paths In-Reply-To: References: Message-ID: <09872C7D-78F3-4090-9A9E-7EC97080A0CD@apple.com> On Aug 22, 2007, at 10:44 AM, Kelly Wilson wrote: > Hello fellow clangers ;) > > I am just sending a quick diff for a couple clang.cpp "FIXME"'s. > Not sure if the use of the system()/getenv() calls are appropriate > but I just wanted this to work for my setup. Let me know if this is > not an acceptable patch. > > Not really tested on Mac OS X but the syscalls exist and 'gcc -v' > replies with the correct info, I think. Hi Kelly, Sorry for the delay, I'm catching up on old email. This is a very interesting approach, but it would have some serious startup-time implications :). I think that clang really needs a configure script, which could sniff these values when the compiler is being built, instead of doing it on each run. Alternatively, it could have some configuration file that specifies where to find stuff etc. Are you still interested in working on this? -Chris From kremenek at apple.com Wed Sep 12 15:16:40 2007 From: kremenek at apple.com (Ted Kremenek) Date: Wed, 12 Sep 2007 13:16:40 -0700 Subject: [cfe-dev] clang Contributors listing on Ohloh Message-ID: I came upon this last night: http://www.ohloh.net/projects/6827/contributors It has a graphical listing of commit activity per contributor. I'm not certain how are why they are compiling this, but I thought I would share the link. From asl at math.spbu.ru Wed Sep 12 15:37:50 2007 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Thu, 13 Sep 2007 00:37:50 +0400 Subject: [cfe-dev] clang Contributors listing on Ohloh In-Reply-To: References: Message-ID: <1189629470.13269.5.camel@asl.dorms.spbu.ru> Ted, > It has a graphical listing of commit activity per contributor. I'm > not certain how are why they are compiling this, but I thought I would > share the link. I updated LLVM & clang entries on ohloh some time ago. They just downloads the whole repository provided and collects informaation from there. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University. From kremenek at apple.com Wed Sep 12 15:54:39 2007 From: kremenek at apple.com (Ted Kremenek) Date: Wed, 12 Sep 2007 13:54:39 -0700 Subject: [cfe-dev] clang Contributors listing on Ohloh In-Reply-To: <1189629470.13269.5.camel@asl.dorms.spbu.ru> References: <1189629470.13269.5.camel@asl.dorms.spbu.ru> Message-ID: <4784CB86-CFB3-4B66-90AF-170A3FAF3543@apple.com> On Sep 12, 2007, at 1:37 PM, Anton Korobeynikov wrote: > Ted, > >> It has a graphical listing of commit activity per contributor. I'm >> not certain how are why they are compiling this, but I thought I >> would >> share the link. > I updated LLVM & clang entries on ohloh some time ago. They just > downloads the whole repository provided and collects informaation from > there. > > -- > With best regards, Anton Korobeynikov. Hi Anton, I suspected it was you since you were listed as the only contributor with an actual name as opposed to whatever handle was ripped from SVN. Thanks for doing this. BTW, do you know how often they update this information, or do we have to do it manually? Ted From asl at math.spbu.ru Wed Sep 12 15:57:27 2007 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Thu, 13 Sep 2007 00:57:27 +0400 Subject: [cfe-dev] clang Contributors listing on Ohloh In-Reply-To: <4784CB86-CFB3-4B66-90AF-170A3FAF3543.SS712SS@apple.com> References: <1189629470.13269.5.camel@asl.dorms.spbu.ru> <4784CB86-CFB3-4B66-90AF-170A3FAF3543.SS712SS@apple.com> Message-ID: <1189630647.13269.12.camel@asl.dorms.spbu.ru> Hello, Ted. > I suspected it was you since you were listed as the only contributor > with an actual name as opposed to whatever handle was ripped from > SVN. No, also Lauro (in LLVM) :) > Thanks for doing this. BTW, do you know how often they update > this information, or do we have to do it manually? They promised to update stats per each 2-3 weeks. But it seems, that their scripts are buggy somehow, so usually they need to ping'ed via forum :) -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University. From uniheliodem at gmail.com Sat Sep 15 17:34:06 2007 From: uniheliodem at gmail.com (Justin Handville) Date: Sat, 15 Sep 2007 18:34:06 -0400 Subject: [cfe-dev] Warnings patch for gcc 4.2.x Message-ID: <992b09980709151534k4caef0b8lec18ba06536480b5@mail.gmail.com> This patch fixes all of the warnings currently generated in trunk with -Wall -Werror. Mostly, this stubs out missing enums in switch statements. Also, note the fix for InvalidDecl below. Index: include/clang/AST/Decl.h =================================================================== --- include/clang/AST/Decl.h (revision 41989) +++ include/clang/AST/Decl.h (working copy) @@ -57,7 +57,7 @@ Kind DeclKind : 8; /// InvalidDecl - This indicates a semantic error occurred. - int InvalidDecl : 1; + unsigned int InvalidDecl : 1; protected: Decl(Kind DK) : DeclKind(DK), InvalidDecl(0) { Index: AST/Decl.cpp =================================================================== --- AST/Decl.cpp (revision 41989) +++ AST/Decl.cpp (working copy) @@ -105,6 +105,21 @@ case ObjcInterface: nInterfaceDecls++; break; + case ObjcClass: + //FIXME add functionality here. + break; + case ObjcMethod: + //FIXME add functionality here. + break; + case ObjcProtoMethod: + //FIXME add functionality here. + break; + case ObjcProtocol: + //FIXME add functionality here. + break; + case ObjcIvar: + //FIXME add functionality here. + break; } } Index: AST/ASTContext.cpp =================================================================== --- AST/ASTContext.cpp (revision 41989) +++ AST/ASTContext.cpp (working copy) @@ -730,6 +730,9 @@ } } assert(0 && "getFloatingTypeOfSizeWithinDomain(): illegal domain"); + //an invalid return value, but the assert + //will ensure that this code is never reached. + return VoidTy; } /// compareFloatingType - Handles 3 different combos: Index: CodeGen/CGExpr.cpp =================================================================== --- CodeGen/CGExpr.cpp (revision 41989) +++ CodeGen/CGExpr.cpp (working copy) @@ -134,6 +134,9 @@ return EmitLoadOfOCUElementLValue(LV, ExprType); assert(0 && "Bitfield ref not impl!"); + //an invalid RValue, but the assert will + //ensure that this point is never reached + return RValue(); } // If this is a reference to a subset of the elements of a vector, either @@ -270,6 +273,9 @@ return LValue::MakeAddr(CGM.GetAddrOfGlobalDecl(D)); } assert(0 && "Unimp declref"); + //an invalid LValue, but the assert will + //ensure that this point is never reached. + return LValue(); } LValue CodeGenFunction::EmitUnaryOpLValue(const UnaryOperator *E) { Index: CodeGen/CodeGenTypes.cpp =================================================================== --- CodeGen/CodeGenTypes.cpp (revision 41989) +++ CodeGen/CodeGenTypes.cpp (working copy) @@ -136,6 +136,11 @@ return llvm::FunctionType::get(ResultType, ArgTys, isVarArg, 0); } + + case Type::ObjcInterface: + //FIXME: add missing functionality here + break; + case Type::Tagged: const TagType &TT = cast(Ty); const TagDecl *TD = TT.getDecl(); From uniheliodem at gmail.com Sat Sep 15 19:15:12 2007 From: uniheliodem at gmail.com (Justin Handville) Date: Sat, 15 Sep 2007 20:15:12 -0400 Subject: [cfe-dev] Patch to fix negative test cases (expected-error / expected-warning) Message-ID: <992b09980709151715p3b8270f8wcad7bff8b7981683@mail.gmail.com> The ExpectedStr search was starting at the end of the comment string. This patch starts the search at the beginning of the comment string. After applying this patch, clang -parse-ast-check on negative test case source files worked as expected. Index: Driver/DiagChecker.cpp =================================================================== --- Driver/DiagChecker.cpp (revision 41992) +++ Driver/DiagChecker.cpp (working copy) @@ -51,7 +51,7 @@ const char * const ExpectedStr) { // Find all expected diagnostics typedef std::string::size_type size_type; - size_type ColNo = std::string::npos; + size_type ColNo = 0; for (;;) { ColNo = Comment.find(ExpectedStr, ColNo); From uniheliodem at gmail.com Sat Sep 15 23:02:01 2007 From: uniheliodem at gmail.com (Justin Handville) Date: Sun, 16 Sep 2007 00:02:01 -0400 Subject: [cfe-dev] Small patch for internals manual documentation Message-ID: <992b09980709152102iaefec3dpa252fd1afc302a02@mail.gmail.com> Escaping a '<' fixes the error I'm getting when reading it. Index: InternalsManual.html =================================================================== --- InternalsManual.html (revision 41997) +++ InternalsManual.html (working copy) @@ -233,7 +233,7 @@ support the -C preprocessor mode, which passes comments through, and is used by the diagnostic checker to identifier expect-error annotations.
  • The lexer can be in ParsingFilename mode, which happens when preprocessing - after reading a #include directive. This mode changes the parsing of '<' + after reading a #include directive. This mode changes the parsing of '<' to return an "angled string" instead of a bunch of tokens for each thing within the filename.
  • When parsing a preprocessor directive (after "#") the From clattner at apple.com Sun Sep 16 14:24:31 2007 From: clattner at apple.com (Chris Lattner) Date: Sun, 16 Sep 2007 12:24:31 -0700 Subject: [cfe-dev] Warnings patch for gcc 4.2.x In-Reply-To: <992b09980709151534k4caef0b8lec18ba06536480b5@mail.gmail.com> References: <992b09980709151534k4caef0b8lec18ba06536480b5@mail.gmail.com> Message-ID: <807221D0-A207-4DC4-8C25-D732AED9A502@apple.com> On Sep 15, 2007, at 3:34 PM, Justin Handville wrote: > This patch fixes all of the warnings currently generated in trunk with > -Wall -Werror. > > Mostly, this stubs out missing enums in switch statements. Also, note > the fix for InvalidDecl below. Applied, thanks! > --- AST/Decl.cpp (revision 41989) > +++ AST/Decl.cpp (working copy) > @@ -105,6 +105,21 @@ > case ObjcInterface: > nInterfaceDecls++; > break; > + case ObjcClass: > + //FIXME add functionality here. > + break; For chunks like this, please change these to assert on the unimplemented case so we can find them easily if executed. Thanks Justin, -Chris From clattner at apple.com Sun Sep 16 14:25:53 2007 From: clattner at apple.com (Chris Lattner) Date: Sun, 16 Sep 2007 12:25:53 -0700 Subject: [cfe-dev] Small patch for internals manual documentation In-Reply-To: <992b09980709152102iaefec3dpa252fd1afc302a02@mail.gmail.com> References: <992b09980709152102iaefec3dpa252fd1afc302a02@mail.gmail.com> Message-ID: <856E9174-4603-4601-817A-A5C51A0FEDF4@apple.com> On Sep 15, 2007, at 9:02 PM, Justin Handville wrote: > Escaping a '<' fixes the error I'm getting when reading it. Applied. FYI, the patch wrapped, which made it not apply. Please attach patches as attachments to the email instead of including them inline. This is obviously not a big deal with this small patch, but just mentioning it for the future. :) Thanks! -Chris > Index: InternalsManual.html > =================================================================== > --- InternalsManual.html (revision 41997) > +++ InternalsManual.html (working copy) > @@ -233,7 +233,7 @@ > support the -C preprocessor mode, which passes comments > through, and is > used by the diagnostic checker to identifier expect-error > annotations.
    • >
  • The lexer can be in ParsingFilename mode, which happens when > preprocessing > - after reading a #include directive. This mode changes the > parsing of '<' > + after reading a #include directive. This mode changes the > parsing of '<' > to return an "angled string" instead of a bunch of tokens for > each thing > within the filename.
    • >
  • When parsing a preprocessor directive (after "#") the > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From cedric.venet at student.ecp.fr Tue Sep 18 03:51:09 2007 From: cedric.venet at student.ecp.fr (=?iso-8859-1?b?Q+lkcmlj?= Venet) Date: Tue, 18 Sep 2007 10:51:09 +0200 Subject: [cfe-dev] Bug Patch for MSVC Message-ID: <20070918105109.4uzuus9w080g8og0@webmail.student.ecp.fr> Hi, There is a small bug in the actual clang code when compiling with visual studio 8.0 . For VS, the enum are signed so when an enum is used in a bit field just the right size, it get sign exteded when you read it and this cause problems (here it perturb isa<> so clang can't compile a function definition...) here is the patch (not a true patch since I don't have svn acces from where I am) file: /include/clang/AST/Type.h lines: 199 to 216 class Type { public: - enum TypeClass { + enum TypeClass : unsigned int { Builtin, Complex, Pointer, Reference, ConstantArray, VariableArray, Vector, OCUVector, FunctionNoProto, FunctionProto, TypeName, Tagged, ObjcInterface, TypeOfExp, TypeOfTyp // GNU typeof extension. }; private: QualType CanonicalType; /// TypeClass bitfield - Enum that specifies what subclass this belongs to. /// Note that this should stay at the end of the ivars for Type so that /// subclasses can pack their bitfields into the same word. TypeClass TC : 4; another alternative is to make the TC bit field 5 bits wide. This is the choice llvm made in one of is class. best regards, -- C?dric Venet From mmarcin at method-solutions.com Tue Sep 18 15:08:26 2007 From: mmarcin at method-solutions.com (Michael Marcin) Date: Tue, 18 Sep 2007 15:08:26 -0500 Subject: [cfe-dev] Newsreader access available through Gmane. Message-ID: The Clang development mailing list can now be accessed via Gmane. nntp://news.gmane.org/gmane.comp.compilers.clang.devel - Michael Marcin From clattner at apple.com Tue Sep 18 15:59:28 2007 From: clattner at apple.com (Chris Lattner) Date: Tue, 18 Sep 2007 13:59:28 -0700 Subject: [cfe-dev] Newsreader access available through Gmane. In-Reply-To: References: Message-ID: <90F115C0-D794-476C-8B30-DAC6710D9EAA@apple.com> On Sep 18, 2007, at 1:08 PM, Michael Marcin wrote: > The Clang development mailing list can now be accessed via Gmane. > > nntp://news.gmane.org/gmane.comp.compilers.clang.devel > > - Michael Marcin nice! -Chris From clattner at apple.com Wed Sep 19 12:16:40 2007 From: clattner at apple.com (Chris Lattner) Date: Wed, 19 Sep 2007 10:16:40 -0700 Subject: [cfe-dev] Bug Patch for MSVC In-Reply-To: <20070918105109.4uzuus9w080g8og0@webmail.student.ecp.fr> References: <20070918105109.4uzuus9w080g8og0@webmail.student.ecp.fr> Message-ID: <261F503B-1B79-4F2C-B752-4374B9AC34ED@apple.com> On Sep 18, 2007, at 1:51 AM, C?dric Venet wrote: > > Hi, > > There is a small bug in the actual clang code when compiling with > visual studio 8.0 . For VS, the enum are signed so when an enum is > used in a bit field just the right size, it get sign exteded when you > read it and this cause problems (here it perturb isa<> so clang can't > compile a function definition...) Ok. > here is the patch (not a true patch since I don't have svn acces from > where I am) > > file: /include/clang/AST/Type.h > lines: 199 to 216 > > class Type { > public: > - enum TypeClass { > + enum TypeClass : unsigned int { This isn't valid C++ Syntax. > QualType CanonicalType; > > /// TypeClass bitfield - Enum that specifies what subclass this > belongs to. > /// Note that this should stay at the end of the ivars for Type > so that > /// subclasses can pack their bitfields into the same word. > TypeClass TC : 4; > > another alternative is to make the TC bit field 5 bits wide. This is > the choice llvm made in one of is class. I'd suggest changing getTypeClass() to do the appropriate masking. -Chris From hartmut.kaiser at gmail.com Wed Sep 19 13:38:15 2007 From: hartmut.kaiser at gmail.com (Hartmut Kaiser) Date: Wed, 19 Sep 2007 13:38:15 -0500 Subject: [cfe-dev] Bug Patch for MSVC In-Reply-To: <261F503B-1B79-4F2C-B752-4374B9AC34ED@apple.com> References: <20070918105109.4uzuus9w080g8og0@webmail.student.ecp.fr> <261F503B-1B79-4F2C-B752-4374B9AC34ED@apple.com> Message-ID: <023401c7faec$3ddf51e0$0401a8c0@slartibartfast> Chris, > > QualType CanonicalType; > > > > /// TypeClass bitfield - Enum that specifies what subclass this > > belongs to. > > /// Note that this should stay at the end of the ivars > for Type so > > that > > /// subclasses can pack their bitfields into the same word. > > TypeClass TC : 4; > > > > another alternative is to make the TC bit field 5 bits > wide. This is > > the choice llvm made in one of is class. > > I'd suggest changing getTypeClass() to do the appropriate masking. FWIW, that's exactly what I did a couple of days ago. Are there other places in clang where bitmasks are used? Regards Hartmut From clattner at apple.com Wed Sep 19 13:49:19 2007 From: clattner at apple.com (Chris Lattner) Date: Wed, 19 Sep 2007 11:49:19 -0700 Subject: [cfe-dev] Bug Patch for MSVC In-Reply-To: <023401c7faec$3ddf51e0$0401a8c0@slartibartfast> References: <20070918105109.4uzuus9w080g8og0@webmail.student.ecp.fr> <261F503B-1B79-4F2C-B752-4374B9AC34ED@apple.com> <023401c7faec$3ddf51e0$0401a8c0@slartibartfast> Message-ID: <19E78A89-4AD8-43B4-B174-B1360B822B6B@apple.com> On Sep 19, 2007, at 11:38 AM, Hartmut Kaiser wrote: > Chris, > >>> QualType CanonicalType; >>> >>> /// TypeClass bitfield - Enum that specifies what subclass this >>> belongs to. >>> /// Note that this should stay at the end of the ivars >> for Type so >>> that >>> /// subclasses can pack their bitfields into the same word. >>> TypeClass TC : 4; >>> >>> another alternative is to make the TC bit field 5 bits >> wide. This is >>> the choice llvm made in one of is class. >> >> I'd suggest changing getTypeClass() to do the appropriate masking. > > FWIW, that's exactly what I did a couple of days ago. > Are there other places in clang where bitmasks are used? The specific sticking issue seems to be enum bitfields. The other solution would be to declare TC as: unsigned TC : 4; and then return (TypeClass)TC; in getTypeClass(). This is probably the cleanest solution. -Chris From kremenek at apple.com Wed Sep 19 16:32:10 2007 From: kremenek at apple.com (Ted Kremenek) Date: Wed, 19 Sep 2007 14:32:10 -0700 Subject: [cfe-dev] revision 42152 requires updated with llvm main tree Message-ID: My latest patch: http://llvm.org/viewvc/llvm-project?view=rev&revision=42152 requires an update with the main LLVM tree in order to compile clang. This is due to a patch I made to GraphWriter.h in order to support visualization of ASTs. Ted From clattner at apple.com Wed Sep 19 19:24:55 2007 From: clattner at apple.com (Chris Lattner) Date: Wed, 19 Sep 2007 17:24:55 -0700 Subject: [cfe-dev] -parse-ast-view Message-ID: FYI, with Ted's latest changes, we can now use -parse-ast-view to look at ASTs. If you have graphviz set up right, you should see something like this: -------------- next part -------------- A non-text attachment was scrubbed... Name: pastedGraphic.png Type: image/png Size: 55812 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20070919/ae79c520/attachment-0001.png -------------- next part -------------- for void foo(int *P, int N) { for (int i = 0; i != N; ++i) P[i] = N; } nifty! Over time, more info will be added to the nodes. -Chris From clattner at apple.com Wed Sep 19 19:39:12 2007 From: clattner at apple.com (Chris Lattner) Date: Wed, 19 Sep 2007 17:39:12 -0700 Subject: [cfe-dev] -parse-ast-view In-Reply-To: References: Message-ID: <1EF8943B-DE2A-4C58-A267-D1C5C4524BDC@apple.com> On Sep 19, 2007, at 5:24 PM, Chris Lattner wrote: > FYI, with Ted's latest changes, we can now use -parse-ast-view to > look at ASTs. If you have graphviz set up right, you should see > something like this: BTW, in order for this to work, you have to have dot or Graphviz installed correctly, instructions are here: http://llvm.org/docs/ProgrammersManual.html#ViewGraph One of the nice things about this is that you can just use things like "call S->viewAST()" in GDB and a window pops up with the subgraph for S. -Chris > > > > for > > void foo(int *P, int N) { > for (int i = 0; i != N; ++i) > P[i] = N; > } > > nifty! > > Over time, more info will be added to the nodes. > > -Chris From snaroff at apple.com Wed Sep 19 21:30:03 2007 From: snaroff at apple.com (Steve Naroff) Date: Wed, 19 Sep 2007 19:30:03 -0700 Subject: [cfe-dev] -parse-ast-view In-Reply-To: References: Message-ID: <76121197-513D-4FFC-B636-7C9B00CE8057@apple.com> Ted, This is very cool. Great work, snaroff On Sep 19, 2007, at 5:24 PM, Chris Lattner wrote: > FYI, with Ted's latest changes, we can now use -parse-ast-view to > look at ASTs. If you have graphviz set up right, you should see > something like this: > > > > > > for > > void foo(int *P, int N) { > for (int i = 0; i != N; ++i) > P[i] = N; > } > > nifty! > > Over time, more info will be added to the nodes. > > -Chris_______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From mmarcin at method-solutions.com Thu Sep 20 20:24:47 2007 From: mmarcin at method-solutions.com (Michael Marcin) Date: Thu, 20 Sep 2007 20:24:47 -0500 Subject: [cfe-dev] -parse-ast-view In-Reply-To: <1EF8943B-DE2A-4C58-A267-D1C5C4524BDC@apple.com> References: <1EF8943B-DE2A-4C58-A267-D1C5C4524BDC@apple.com> Message-ID: Chris Lattner wrote: > On Sep 19, 2007, at 5:24 PM, Chris Lattner wrote: > >> FYI, with Ted's latest changes, we can now use -parse-ast-view to >> look at ASTs. If you have graphviz set up right, you should see >> something like this: > > BTW, in order for this to work, you have to have dot or Graphviz > installed correctly, instructions are here: > http://llvm.org/docs/ProgrammersManual.html#ViewGraph > > One of the nice things about this is that you can just use things > like "call S->viewAST()" in GDB and a window pops up with the > subgraph for S. > > -Chris > >> >> >> for >> >> void foo(int *P, int N) { >> for (int i = 0; i != N; ++i) >> P[i] = N; >> } >> >> nifty! >> >> Over time, more info will be added to the nodes. >> Wow this is really cool. - Michael Marcin From uniheliodem at gmail.com Sun Sep 23 18:47:09 2007 From: uniheliodem at gmail.com (Justin Handville) Date: Sun, 23 Sep 2007 19:47:09 -0400 Subject: [cfe-dev] Non-portable cast in DataflowValues.h Message-ID: <992b09980709231647l235681dcp81ca74687b881097@mail.gmail.com> I am getting the following compile error when compiling for x86_64 FreeBSD. The getHashValue function assumes that unsigned int and a pointer are the same size, which is not true in the x86_64 ABI. In file included from /packages/llvm-trunk/tools/clang/Analysis/../include/clang/Analysis/UninitializedValues.h:19, from UninitializedValues.cpp:14: /packages/llvm-trunk/tools/clang/Analysis/../include/clang/Analysis/DataflowValues.h: In static member function 'static unsigned int llvm::DenseMapInfo::getHashValue(const clang::CFG::Edge&)': /packages/llvm-trunk/tools/clang/Analysis/../include/clang/Analysis/DataflowValues.h:40: error: cast from 'const clang::CFGBlock*' to 'unsigned int' loses precision /packages/llvm-trunk/tools/clang/Analysis/../include/clang/Analysis/DataflowValues.h:41: error: cast from 'const clang::CFGBlock*' to 'unsigned int' loses precision /packages/llvm-trunk/tools/clang/Analysis/../include/clang/Analysis/DataflowValues.h:42: error: cast from 'const clang::CFGBlock*' to 'unsigned int' loses precision /packages/llvm-trunk/tools/clang/Analysis/../include/clang/Analysis/DataflowValues.h:43: error: cast from 'const clang::CFGBlock*' to 'unsigned int' loses precision gmake[1]: *** [/packages/llvm-trunk/tools/clang/Analysis/Debug/UninitializedValues.o] Error 1 gmake[1]: Leaving directory `/packages/llvm-trunk/tools/clang/Analysis' gmake: *** [all] Error 1 From clattner at apple.com Sun Sep 23 18:53:13 2007 From: clattner at apple.com (Chris Lattner) Date: Sun, 23 Sep 2007 16:53:13 -0700 Subject: [cfe-dev] Non-portable cast in DataflowValues.h In-Reply-To: <992b09980709231647l235681dcp81ca74687b881097@mail.gmail.com> References: <992b09980709231647l235681dcp81ca74687b881097@mail.gmail.com> Message-ID: <92F5E33B-8097-4DC1-BB00-059C886F49B3@apple.com> On Sep 23, 2007, at 4:47 PM, Justin Handville wrote: > I am getting the following compile error when compiling for x86_64 > FreeBSD. The getHashValue function assumes that unsigned int and a > pointer are the same size, which is not true in the x86_64 ABI. Does this fix it? http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of- Mon-20070917/002072.html -Chris > In file included from > /packages/llvm-trunk/tools/clang/Analysis/../include/clang/Analysis/ > UninitializedValues.h:19, > from UninitializedValues.cpp:14: > /packages/llvm-trunk/tools/clang/Analysis/../include/clang/Analysis/ > DataflowValues.h: > In static member function 'static unsigned int > llvm::DenseMapInfo::getHashValue(const > clang::CFG::Edge&)': > /packages/llvm-trunk/tools/clang/Analysis/../include/clang/Analysis/ > DataflowValues.h:40: > error: cast from 'const clang::CFGBlock*' to 'unsigned int' loses > precision > /packages/llvm-trunk/tools/clang/Analysis/../include/clang/Analysis/ > DataflowValues.h:41: > error: cast from 'const clang::CFGBlock*' to 'unsigned int' loses > precision > /packages/llvm-trunk/tools/clang/Analysis/../include/clang/Analysis/ > DataflowValues.h:42: > error: cast from 'const clang::CFGBlock*' to 'unsigned int' loses > precision > /packages/llvm-trunk/tools/clang/Analysis/../include/clang/Analysis/ > DataflowValues.h:43: > error: cast from 'const clang::CFGBlock*' to 'unsigned int' loses > precision > gmake[1]: *** [/packages/llvm-trunk/tools/clang/Analysis/Debug/ > UninitializedValues.o] > Error 1 > gmake[1]: Leaving directory `/packages/llvm-trunk/tools/clang/ > Analysis' > gmake: *** [all] Error 1 > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev From uniheliodem at gmail.com Sun Sep 23 18:59:46 2007 From: uniheliodem at gmail.com (Justin Handville) Date: Sun, 23 Sep 2007 19:59:46 -0400 Subject: [cfe-dev] Non-portable cast in DataflowValues.h In-Reply-To: <92F5E33B-8097-4DC1-BB00-059C886F49B3@apple.com> References: <992b09980709231647l235681dcp81ca74687b881097@mail.gmail.com> <92F5E33B-8097-4DC1-BB00-059C886F49B3@apple.com> Message-ID: <992b09980709231659q2facf0f7p8ecdefdb8e138732@mail.gmail.com> Yes. That will do it. :-) On 9/23/07, Chris Lattner wrote: > > On Sep 23, 2007, at 4:47 PM, Justin Handville wrote: > > > I am getting the following compile error when compiling for x86_64 > > FreeBSD. The getHashValue function assumes that unsigned int and a > > pointer are the same size, which is not true in the x86_64 ABI. > > Does this fix it? > http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of- > Mon-20070917/002072.html > > -Chris > > > In file included from > > /packages/llvm-trunk/tools/clang/Analysis/../include/clang/Analysis/ > > UninitializedValues.h:19, > > from UninitializedValues.cpp:14: > > /packages/llvm-trunk/tools/clang/Analysis/../include/clang/Analysis/ > > DataflowValues.h: > > In static member function 'static unsigned int > > llvm::DenseMapInfo::getHashValue(const > > clang::CFG::Edge&)': > > /packages/llvm-trunk/tools/clang/Analysis/../include/clang/Analysis/ > > DataflowValues.h:40: > > error: cast from 'const clang::CFGBlock*' to 'unsigned int' loses > > precision > > /packages/llvm-trunk/tools/clang/Analysis/../include/clang/Analysis/ > > DataflowValues.h:41: > > error: cast from 'const clang::CFGBlock*' to 'unsigned int' loses > > precision > > /packages/llvm-trunk/tools/clang/Analysis/../include/clang/Analysis/ > > DataflowValues.h:42: > > error: cast from 'const clang::CFGBlock*' to 'unsigned int' loses > > precision > > /packages/llvm-trunk/tools/clang/Analysis/../include/clang/Analysis/ > > DataflowValues.h:43: > > error: cast from 'const clang::CFGBlock*' to 'unsigned int' loses > > precision > > gmake[1]: *** [/packages/llvm-trunk/tools/clang/Analysis/Debug/ > > UninitializedValues.o] > > Error 1 > > gmake[1]: Leaving directory `/packages/llvm-trunk/tools/clang/ > > Analysis' > > gmake: *** [all] Error 1 > > _______________________________________________ > > cfe-dev mailing list > > cfe-dev at cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > > From hartmut.kaiser at gmail.com Sun Sep 23 20:05:08 2007 From: hartmut.kaiser at gmail.com (Hartmut Kaiser) Date: Sun, 23 Sep 2007 20:05:08 -0500 Subject: [cfe-dev] Bug Patch for MSVC In-Reply-To: <19E78A89-4AD8-43B4-B174-B1360B822B6B@apple.com> References: <20070918105109.4uzuus9w080g8og0@webmail.student.ecp.fr> <261F503B-1B79-4F2C-B752-4374B9AC34ED@apple.com> <023401c7faec$3ddf51e0$0401a8c0@slartibartfast> <19E78A89-4AD8-43B4-B174-B1360B822B6B@apple.com> Message-ID: <00e001c7fe46$f3811f80$0901a8c0@slartibartfast> Done. Regards Hartmut > -----Original Message----- > From: Chris Lattner [mailto:clattner at apple.com] > Sent: Wednesday, September 19, 2007 1:49 PM > To: hartmut.kaiser at gmail.com > Cc: 'C?dric Venet'; cfe-dev at cs.uiuc.edu > Subject: Re: [cfe-dev] Bug Patch for MSVC > > > On Sep 19, 2007, at 11:38 AM, Hartmut Kaiser wrote: > > > Chris, > > > >>> QualType CanonicalType; > >>> > >>> /// TypeClass bitfield - Enum that specifies what > subclass this > >>> belongs to. > >>> /// Note that this should stay at the end of the ivars > >> for Type so > >>> that > >>> /// subclasses can pack their bitfields into the same word. > >>> TypeClass TC : 4; > >>> > >>> another alternative is to make the TC bit field 5 bits > >> wide. This is > >>> the choice llvm made in one of is class. > >> > >> I'd suggest changing getTypeClass() to do the appropriate masking. > > > > FWIW, that's exactly what I did a couple of days ago. > > Are there other places in clang where bitmasks are used? > > The specific sticking issue seems to be enum bitfields. The > other solution would be to declare TC as: > > unsigned TC : 4; > > and then return (TypeClass)TC; in getTypeClass(). This is > probably the cleanest solution. > > -Chris > From asmodai at in-nomine.org Sun Sep 30 05:19:36 2007 From: asmodai at in-nomine.org (Jeroen Ruigrok van der Werven) Date: Sun, 30 Sep 2007 12:19:36 +0200 Subject: [cfe-dev] extern supported yet? In-Reply-To: <2757AE95-77C5-44C7-BB5E-55499AF77144@apple.com> References: <20070724091348.GQ14220@nexus.in-nomine.org> <7CA85D5D-0533-48D6-942A-238ACE2641FF@apple.com> <20070724164551.GU14220@nexus.in-nomine.org> <7E95DA9A-2CC7-4CD2-A142-AB3610DBED5D@apple.com> <2757AE95-77C5-44C7-BB5E-55499AF77144@apple.com> Message-ID: <20070930101936.GH1025@nexus.in-nomine.org> -On [20070724 19:42], Steve Naroff (snaroff at apple.com) wrote: >On Jul 24, 2007, at 10:06 AM, Chris Lattner wrote: > This is a bug or missing feature in the declaration merging code. > Steve, can you take a look at this? Here's a self-contained example: > > int array[10]; > extern int array[]; > >This is a missing feature that has a clear FIXME... > >/// FIXME: Need to carefully consider tentative definition rules (C99 6.9.2p2). >/// For example, we incorrectly complain about i1, i4 from C99 6.9.2p4. >/// >VarDecl *Sema::MergeVarDecl(VarDecl *New, Decl *OldD) { > >MergeTypedefDecl and MergeFunctionDecl are also incomplete. They both have >TODO annotations... Any of you guys happen to have looked at it in the mean time? -- Jeroen Ruigrok van der Werven / asmodai ????? ?????? ??? ?? ?????? http://www.in-nomine.org/ | http://www.rangaku.org/ Those who cannot remember the past are condemned to repeat it...