* Reverting your patch from 2004-06-24 @ 2004-07-06 7:32 Mark Mitchell 2004-07-06 22:33 ` Bug 16115, C++ invisible references (was: Reverting your patch from 2004-06-24) Jason Merrill 0 siblings, 1 reply; 18+ messages in thread From: Mark Mitchell @ 2004-07-06 7:32 UTC (permalink / raw) To: gcc-patches, jason Jason -- I've reverted this patch: 2004-06-24 Jason Merrill <jason@redhat.com> PR c++/16115 * decl.c (grokparms): Give the PARM_DECL reference type if the parameter is passed by invisible reference. because (a) it's slightly buggy, and (b) I think it's the wrong approach. I recognize that I've exceeded my mandate here, in that I've just reverted the patch without the usual 48-hour deal, but I'm counting on the fact that you and I have always resolved differences effectively to allow me to avoid massive wrath from the direction of greater Boston. If you're not happy, well, revert my reversion, and we'll find another way to work it out. Here's what I put into bugzilla: == This patch is incorrect, on several levels. First, it changes the type of the PARM_DECL to be different from the type that C++ assigns that declaration. That is incorrect; the C++ front end's assignment of types should match the language. As we've discussed previously, for example, it's a bug that we have expressions with REFERENCE_TYPE; the standard says that no expressions have that type. (Declarations can, of course, have REFERENCE_TYPE -- but these parameters do not.) We should be trying to minimize the extent to which ABI details appear in the front end. Furthermore, this test case: template <typename T> struct S { ~S(); }; struct T { T(S<int>); S<int> s_; }; T::T(S<int> s) : s_(s) { } now ICEs the compiler on (at least) powerpc-apple-darwin7.4.0 due to some problem with cloned functions. Also, this change is potentially pessimizing code in that it will no longer be obvious to the optimizers that the static type of the parameter must in fact be the declared type. So, we may not be able to resolve virtual function invoked on the parameter. Finally, if we were going to make this change in the front end, the right place would be in grokdeclarator (where the PARM_DECL is created) rather than in grokparms, where we must then wastefully create a second PARM_DECL. If the optimizers needs these parameters to have reference type, then that change needs to happen after the front end processing is complete, in the course of generating code for this function. I'm not sure what the tradeoffs are vis a vis (re)teaching the optimizers about TREE_ADDRESSABLE on types. I've reverted this patch. I'll be happy to help with an alternate solution in whatever way I can. (Parenthetically, I'm not sure the call1.C test is checking anything useful, since it does not fail even after I reverted the patch.) == -- Mark Mitchell CodeSourcery, LLC mark@codesourcery.com ^ permalink raw reply [flat|nested] 18+ messages in thread
* Bug 16115, C++ invisible references (was: Reverting your patch from 2004-06-24) 2004-07-06 7:32 Reverting your patch from 2004-06-24 Mark Mitchell @ 2004-07-06 22:33 ` Jason Merrill 2004-07-06 22:42 ` Bug 16115, C++ invisible references Mark Mitchell 0 siblings, 1 reply; 18+ messages in thread From: Jason Merrill @ 2004-07-06 22:33 UTC (permalink / raw) To: mark; +Cc: gcc-patches, Richard Henderson On Tue, 6 Jul 2004 00:23:43 -0700, Mark Mitchell <mark@codesourcery.com> wrote: > Jason -- > > I've reverted this patch: > > 2004-06-24 Jason Merrill <jason@redhat.com> > PR c++/16115 > * decl.c (grokparms): Give the PARM_DECL reference type if the > parameter is passed by invisible reference. > > because (a) it's slightly buggy, and (b) I think it's the wrong > approach. > > I recognize that I've exceeded my mandate here, in that I've just > reverted the patch without the usual 48-hour deal, but I'm counting on > the fact that you and I have always resolved differences effectively > to allow me to avoid massive wrath from the direction of greater > Boston. If you're not happy, well, revert my reversion, and we'll > find another way to work it out. Reverting the patch before discussion strikes me as an odd overreaction, but I feel no wrath about it. :) I've been continuing to work in this area; I'll just wait and check in the improved version later. > This patch is incorrect, on several levels. > > First, it changes the type of the PARM_DECL to be different from the > type that C++ assigns that declaration. That is incorrect; the C++ > front end's assignment of types should match the language. As we've > discussed previously, for example, it's a bug that we have expressions > with REFERENCE_TYPE; the standard says that no expressions have that > type. (Declarations can, of course, have REFERENCE_TYPE -- but these > parameters do not.) We should be trying to minimize the extent to > which ABI details appear in the front end. I disagree with this. It seems to me that you're striving towards a goal of turning the IL into a mirror of the source, which is nice to keep as an ideal, but impractical in many cases. 'for' scoping comes to mind; the scope of a declaration in the for-init-statement is larger than its sub-tree, so to do anything sensible with it we need to move it outside the loop construct. Within the compiler, we need to represent things in an internally consistent way, which may not always match the convoluted C++ syntax. This last came up in the context of the patch to use STATEMENT_LISTs for C and C++, and I suppose it's an issue that needs to be resolved separately: How hard should we try to retain C++ syntactic structure during parsing? My own feeling is: as much as possible when parsing templates, as much as convenient otherwise. In this case, the parameter is in fact passed as a reference. The C++ language requires that the object live past the end of the function for the lifetime of temporaries rules to work properly. Representing it as a local object is lying to the compiler, and Bug 16115 is an example of it having its revenge. Representing parms and returns as references when they are passed as such also allows us to clean up a lot of special cases in the inliner. I don't think we have expressions with REFERENCE_TYPE; all occurrences of a reference immediately decay. I would prefer a design that didn't require us to scatter convert_from_reference calls everywhere, but I agree with the <INDIRECT_REF <decl/call>> tree structure that results. ABI details pervade the front end. I don't see how it could be otherwise. Besides, while passing these types by invisible reference happens to be described by the C++ ABI, I can't think of any other implementation that both conforms to the standard and allows elision of temporaries. > Furthermore, this test case: > > template <typename T> > struct S { > ~S(); > }; > struct T { > T(S<int>); > S<int> s_; > }; > T::T(S<int> s) : s_(s) { > } > > now ICEs the compiler on (at least) powerpc-apple-darwin7.4.0 due to > some problem with cloned functions. I'll take a look. > Also, this change is potentially pessimizing code in that it will no > longer be obvious to the optimizers that the static type of the > parameter must in fact be the declared type. So, we may not be able > to resolve virtual function invoked on the parameter. True. rth also pointed out that we should set __restrict on the reference, since nothing else can refer to these stack slots; the issue you mention calls for a GENERIC-level type assertion just like we want for new-expressions. > Finally, if we were going to make this change in the front end, the > right place would be in grokdeclarator (where the PARM_DECL is > created) rather than in grokparms, where we must then wastefully > create a second PARM_DECL. Yes, that was sloppy; my current code avoids creating a second PARM_DECL. > If the optimizers needs these parameters to have reference type, then > that change needs to happen after the front end processing is > complete, in the course of generating code for this function. I'm not > sure what the tradeoffs are vis a vis (re)teaching the optimizers > about TREE_ADDRESSABLE on types. You mean teaching the optimizers that a PARM_DECL of TREE_ADDRESSABLE type lives beyond the end of the function? That sounds like rather complex semantics to expect them to hold on to. I much prefer to make as much as possible explicit in the GENERIC. Your other suggestion gets back to the question above of conformity to the source. Is it worth the cost of building and throwing away all these extra nodes just to have the parse trees match the C++ syntax more closely? > (Parenthetically, I'm not sure the call1.C test is checking anything > useful, since it does not fail even after I reverted the patch.) Probably because I forgot to set dg-options to -O2. Corrected. Jason ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Bug 16115, C++ invisible references 2004-07-06 22:33 ` Bug 16115, C++ invisible references (was: Reverting your patch from 2004-06-24) Jason Merrill @ 2004-07-06 22:42 ` Mark Mitchell 2004-07-06 22:54 ` Phil Edwards ` (2 more replies) 0 siblings, 3 replies; 18+ messages in thread From: Mark Mitchell @ 2004-07-06 22:42 UTC (permalink / raw) To: Jason Merrill; +Cc: gcc-patches, Richard Henderson Jason Merrill wrote: >>I recognize that I've exceeded my mandate here, in that I've just >>reverted the patch without the usual 48-hour deal, but I'm counting on >>the fact that you and I have always resolved differences effectively >>to allow me to avoid massive wrath from the direction of greater >>Boston. If you're not happy, well, revert my reversion, and we'll >>find another way to work it out. >> >> > >Reverting the patch before discussion strikes me as an odd overreaction, >but I feel no wrath about it. :) > > Good. I don't mind being a little odd, but I don't want to be a jerk. >>This patch is incorrect, on several levels. >> >>First, it changes the type of the PARM_DECL to be different from the >>type that C++ assigns that declaration. That is incorrect; the C++ >>front end's assignment of types should match the language. As we've >>discussed previously, for example, it's a bug that we have expressions >>with REFERENCE_TYPE; the standard says that no expressions have that >>type. (Declarations can, of course, have REFERENCE_TYPE -- but these >>parameters do not.) We should be trying to minimize the extent to >>which ABI details appear in the front end. >> >> > >I disagree with this. It seems to me that you're striving towards a goal >of turning the IL into a mirror of the source, which is nice to keep as an >ideal, but impractical in many cases. > I think this is a major policy point. It may be something we should talk to the SC about, because it's a question of what we want GCC to be, as much as it is a technical question. If GCC to be purely a compiler, then my argument has no validity. If, on the other hand, we want G++ to be a separate front end that can be used for other purposes, then my argument has considerably more utility. EDG provides unlowered IL C++ that looks a lot like the source (but in a form that would be very easy for an interpreter to execute) and lowered IL (which looks like C, with magic for exceptions). This model has been very successful; compiler vendors generally use the lowered form, while other tools vendors use the unlowered form. I don't know that much about EDG's business, but they have substantial sets of customers in both camps; in various situations, I've used EDG's front end in both contexts. It's great for both purposes. I'd like to see G++ be used with non-compiler tools, and I've talked to many (10-ish?) groups that would also like to do that. They generally need good fidelity to the source; in fact, EDG provides a C++-to-C++ translator mode, which works because they can generate valid C++ from their unlowered IL. Not only is the code valid, but compiling the output of the translator will result in an object file with the same functions defined, etc. (In this particular case, the lowered form reprsents the parameter as "S*"; the unlowered form is "S".) >'for' scoping comes to mind; the >scope of a declaration in the for-init-statement is larger than its >sub-tree, so to do anything sensible with it we need to move it outside the >loop construct. > Are you referring to the pre-ARM scoping rules? Otherwise, I'm confused; a for-statement defines a scope, and there's nothing wrong with a representation that looks like: (for init-statement test-expr increment-expr body) By GIMPLE time, it makes perfect sense for that to be more like: { init-statement; while (test-expr) { body; increment-expr } } not that this is fully correct. I've no problem at all with making that transformation, as long as its postponed until we're generating code. >ABI details pervade the front end. I don't see how it could be otherwise. >Besides, while passing these types by invisible reference happens to be >described by the C++ ABI, I can't think of any other implementation that >both conforms to the standard and allows elision of temporaries. > > It's a question of degree. Some ABI details must be part of the front end; for example "sizeof(X)" must be something we can compute. But, which arguments go in a register is generally not something we need to know. So, I should have said "we should avoid ABI details as much as possible". >>If the optimizers needs these parameters to have reference type, then >>that change needs to happen after the front end processing is >>complete, in the course of generating code for this function. I'm not >>sure what the tradeoffs are vis a vis (re)teaching the optimizers >>about TREE_ADDRESSABLE on types. >> >> > >You mean teaching the optimizers that a PARM_DECL of TREE_ADDRESSABLE type >lives beyond the end of the function? That sounds like rather complex >semantics to expect them to hold on to. I much prefer to make as much as >possible explicit in the GENERIC. > > I'd be perfectly happy for this change to happen during either lowering or gimplification; I'm all for making things explicit for the optimizers. It's a question of when we do these things. >Your other suggestion gets back to the question above of conformity to the >source. Is it worth the cost of building and throwing away all these extra >nodes just to have the parse trees match the C++ syntax more closely? > > I think so, yes. I'm also not convinced it's that many nodes, or that we can't overwrite existing nodes rather than creating new ones. But, I agree that there's a non-zero cost in doing a lowering phase. I think Gaby, at least, agrees with me. Rather than having early-lowering code creep in, I think we should reach some kind of conclusion, and then act accordingly, whatever conclusion we reach. -- Mark Mitchell CodeSourcery, LLC (916) 791-8304 mark@codesourcery.com ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Bug 16115, C++ invisible references 2004-07-06 22:42 ` Bug 16115, C++ invisible references Mark Mitchell @ 2004-07-06 22:54 ` Phil Edwards 2004-07-06 23:05 ` Mark Mitchell 2004-07-06 23:15 ` Steven Bosscher 2004-07-07 17:53 ` Jason Merrill 2 siblings, 1 reply; 18+ messages in thread From: Phil Edwards @ 2004-07-06 22:54 UTC (permalink / raw) To: Mark Mitchell; +Cc: Jason Merrill, gcc-patches, Richard Henderson On Tue, Jul 06, 2004 at 03:33:05PM -0700, Mark Mitchell wrote: > in fact, EDG provides a C++-to-C++ translator mode, Shoot, I can provide that; there's a copy of /bin/cat laying around here somewhere. -- <The_Vulture> evilgeek: actually it's <: and :>, <% and %> <evilgeek> oh, right. digraphs are always happy. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Bug 16115, C++ invisible references 2004-07-06 22:54 ` Phil Edwards @ 2004-07-06 23:05 ` Mark Mitchell 0 siblings, 0 replies; 18+ messages in thread From: Mark Mitchell @ 2004-07-06 23:05 UTC (permalink / raw) To: Phil Edwards; +Cc: Jason Merrill, gcc-patches, Richard Henderson Phil Edwards wrote: >On Tue, Jul 06, 2004 at 03:33:05PM -0700, Mark Mitchell wrote: > > > >>in fact, EDG provides a C++-to-C++ translator mode, >> >> > >Shoot, I can provide that; there's a copy of /bin/cat laying around >here somewhere. > > Silly boy. :-) The point, of course, is that you can insert extra stuff in the code while it's inside EDG. -- Mark Mitchell CodeSourcery, LLC (916) 791-8304 mark@codesourcery.com ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Bug 16115, C++ invisible references 2004-07-06 22:42 ` Bug 16115, C++ invisible references Mark Mitchell 2004-07-06 22:54 ` Phil Edwards @ 2004-07-06 23:15 ` Steven Bosscher 2004-07-07 1:32 ` Mark Mitchell 2004-07-07 17:53 ` Jason Merrill 2 siblings, 1 reply; 18+ messages in thread From: Steven Bosscher @ 2004-07-06 23:15 UTC (permalink / raw) To: Mark Mitchell, Jason Merrill; +Cc: gcc-patches, Richard Henderson On Wednesday 07 July 2004 00:33, Mark Mitchell wrote: > I think this is a major policy point. It may be something we should > talk to the SC about, because it's a question of what we want GCC to be, > as much as it is a technical question. If GCC to be purely a compiler, > then my argument has no validity. If, on the other hand, we want G++ to > be a separate front end that can be used for other purposes, then my > argument has considerably more utility. All would be much easier if you could go EDG-like all the way, with a G++ specific (ie. non-tree) internal representation that is very close to the source code, which can be lowered at a later point (say, after parsing the whole file?) to the back-end representation (ie. trees, but I'm sure LLVM and perhaps other Free Software compilers). Much like what Neil is doing in his new C parser. I doubt any representation G++ produces now is useful for the kind of non-compiler applications you have in mind, because the trees and an occasional piece of RTL the front end produces are purely aimed at g++-as-a-compiler. Or at least, G++ could be made much easier to work with for non-compiler applications, with the bonus of no longer bloating the back end IR like G++ does now with all those language specific trees and interesting ways in which they're linked together. Regardless of whether GCC must be more than purely a compiler (IMO it should first try to be better at being just a compiler), I believe going to truely language specific representations and lighter weight trees would be a good idea. GNAT and EDG are the proof that it can be done ;-) <PITA If GCC should be more than purely a compiler, then surely dumping the IR to a file should also no longer be an issue? If we _want_ to make front ends usable by others, then that argument against exporting the whole IR can be dropped ;-) </PITA> Gr. Steven ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Bug 16115, C++ invisible references 2004-07-06 23:15 ` Steven Bosscher @ 2004-07-07 1:32 ` Mark Mitchell 0 siblings, 0 replies; 18+ messages in thread From: Mark Mitchell @ 2004-07-07 1:32 UTC (permalink / raw) To: Steven Bosscher; +Cc: Jason Merrill, gcc-patches, Richard Henderson Steven Bosscher wrote: >On Wednesday 07 July 2004 00:33, Mark Mitchell wrote: > > >>I think this is a major policy point. It may be something we should >>talk to the SC about, because it's a question of what we want GCC to be, >>as much as it is a technical question. If GCC to be purely a compiler, >>then my argument has no validity. If, on the other hand, we want G++ to >>be a separate front end that can be used for other purposes, then my >>argument has considerably more utility. >> >> > >All would be much easier if you could go EDG-like all the way, >with a G++ specific (ie. non-tree) internal representation that >is very close to the source code, which can be lowered at a >later point (say, after parsing the whole file?) to the back-end >representation (ie. trees, but I'm sure LLVM and perhaps other >Free Software compilers). > I don't necessarily disagree, but actually, I think trees would work OK. Since I've been gluing analysis tools to front ends for over a decade now, I feel like I've got a decent sense of what needs to be there and what doesn't. Trees are not necessarily ideal, but they would probably be sufficient, with relatively minor changes. -- Mark Mitchell CodeSourcery, LLC (916) 791-8304 mark@codesourcery.com ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Bug 16115, C++ invisible references 2004-07-06 22:42 ` Bug 16115, C++ invisible references Mark Mitchell 2004-07-06 22:54 ` Phil Edwards 2004-07-06 23:15 ` Steven Bosscher @ 2004-07-07 17:53 ` Jason Merrill 2004-07-07 18:22 ` Mark Mitchell 2 siblings, 1 reply; 18+ messages in thread From: Jason Merrill @ 2004-07-07 17:53 UTC (permalink / raw) To: Mark Mitchell; +Cc: gcc-patches, Richard Henderson On Tue, 06 Jul 2004 15:33:05 -0700, Mark Mitchell <mark@codesourcery.com> wrote: > EDG provides unlowered IL C++ that looks a lot like the source (but in a > form that would be very easy for an interpreter to execute) and lowered IL > (which looks like C, with magic for exceptions). This model has been very > successful; compiler vendors generally use the lowered form, while other > tools vendors use the unlowered form. Good to know. In that form are destructor calls explicit, or are they generated during lowering? >>'for' scoping comes to mind; the scope of a declaration in the >>for-init-statement is larger than its sub-tree, so to do anything >>sensible with it we need to move it outside the loop construct. >> > Are you referring to the pre-ARM scoping rules? Otherwise, I'm confused; > a for-statement defines a scope, and there's nothing wrong with a > representation that looks like: > > (for init-statement test-expr increment-expr body) The problem with that representation is that it requires something like SCOPE_STMT to express scopes that can't clearly nest with other tree nodes. This makes it hard to do anything that involves reasoning about scoping. If you're going to lower this form before you try to do anything with it, that isn't a big problem, but I would expect this to be a hassle for other tools as well. >>Your other suggestion gets back to the question above of conformity to the >>source. Is it worth the cost of building and throwing away all these extra >>nodes just to have the parse trees match the C++ syntax more closely? > I think so, yes. I'm also not convinced it's that many nodes, or that we > can't overwrite existing nodes rather than creating new ones. But, I agree > that there's a non-zero cost in doing a lowering phase. > > I think Gaby, at least, agrees with me. > > Rather than having early-lowering code creep in, I think we should reach > some kind of conclusion, and then act accordingly, whatever conclusion we > reach. I agree that we need to resolve this design issue now. Jason ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Bug 16115, C++ invisible references 2004-07-07 17:53 ` Jason Merrill @ 2004-07-07 18:22 ` Mark Mitchell 2004-07-07 19:40 ` Richard Henderson 0 siblings, 1 reply; 18+ messages in thread From: Mark Mitchell @ 2004-07-07 18:22 UTC (permalink / raw) To: Jason Merrill; +Cc: gcc-patches, Richard Henderson Jason Merrill wrote: >On Tue, 06 Jul 2004 15:33:05 -0700, Mark Mitchell <mark@codesourcery.com> wrote: > > > >>EDG provides unlowered IL C++ that looks a lot like the source (but in a >>form that would be very easy for an interpreter to execute) and lowered IL >>(which looks like C, with magic for exceptions). This model has been very >>successful; compiler vendors generally use the lowered form, while other >>tools vendors use the unlowered form. >> >> > >Good to know. In that form are destructor calls explicit, or are they >generated during lowering? > > I assume that you're talking about calls that are not explicitly indicated by the user; i.e., the destructor call in: struct S { ~S(); }; void f() { S s; } not the one in: void g(S* s) { s->~S(); } ? I'm not quite sure what aspects of EDG IL are proprietary, so I don't want to be too explicit. The basic idea is that they put a description of how to cleanup an object in the same place that they show how to initialize the object. For example, for "s" above, they have a node that says "here is how to initialize this object and here is how to destroy it when it goes out of scope". There is also information about what "out of scope" means -- does it mean end of the full-expression, end of the block, etc. If you were an interpreter, you would see the "s" declaration, construct it, and push a cleanup onto one of serveral stacks to run later. Then, later you would run the right stack of cleanups, when an appropriate triggering condition occurred. >>Are you referring to the pre-ARM scoping rules? Otherwise, I'm confused; >>a for-statement defines a scope, and there's nothing wrong with a >>representation that looks like: >> >> (for init-statement test-expr increment-expr body) >> >> > >The problem with that representation is that it requires something like >SCOPE_STMT to express scopes that can't clearly nest with other tree nodes. >This makes it hard to do anything that involves reasoning about scoping. >If you're going to lower this form before you try to do anything with it, >that isn't a big problem, but I would expect this to be a hassle for other >tools as well. > > I'm not sure I understand the issue you're trying to raise. The declaration in the init-statement is nested within the for-stmt; is your point that the representation above doesn't make it obvious that the declaration is visible in the test-expr, increment-expr, and body? That's not a problem if you have a scope tree (e.g. BLOCKs) which you really want for analysis purposes anyhow. (Show me all the variables in this scope.) >>Rather than having early-lowering code creep in, I think we should reach >>some kind of conclusion, and then act accordingly, whatever conclusion we >>reach. >> >> > >I agree that we need to resolve this design issue now. > > Good. What mechanism do you propose? Are there other people on the GCC list that have input? -- Mark Mitchell CodeSourcery, LLC (916) 791-8304 mark@codesourcery.com ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Bug 16115, C++ invisible references 2004-07-07 18:22 ` Mark Mitchell @ 2004-07-07 19:40 ` Richard Henderson 2004-07-07 20:29 ` Mark Mitchell 0 siblings, 1 reply; 18+ messages in thread From: Richard Henderson @ 2004-07-07 19:40 UTC (permalink / raw) To: Mark Mitchell; +Cc: Jason Merrill, gcc-patches On Wed, Jul 07, 2004 at 11:04:21AM -0700, Mark Mitchell wrote: > Good. What mechanism do you propose? Are there other people on the GCC > list that have input? I think the current mix of odd lowering of syntax and semantics is a mistake. If you want stuff that mirrors source syntax, then something akin to what we do right now for templates is probably not a bad starting point. But once we start trying to add semantics to the representation, in particular anything that needs strict logical nesting, then I think we should drop all requirement that we match up directly with the source. r~ ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Bug 16115, C++ invisible references 2004-07-07 19:40 ` Richard Henderson @ 2004-07-07 20:29 ` Mark Mitchell 2004-07-07 21:16 ` Richard Henderson 0 siblings, 1 reply; 18+ messages in thread From: Mark Mitchell @ 2004-07-07 20:29 UTC (permalink / raw) To: Richard Henderson; +Cc: Jason Merrill, gcc-patches Richard Henderson wrote: >But once we start trying to add semantics to the representation, >in particular anything that needs strict logical nesting, then >I think we should drop all requirement that we match up directly >with the source. > > What do you mean by "semantics"? Certainly, unlowered EDG IL is semantic, in the sense that it would be easy to execute. For example, a call to an overloaded function is resolved into a call to a particular function, and implicit conversions (say, using an overloaded "operator int" on a class) are represented explicitly as function calls. However, things are still at the level of C++; for example, calls to virtual functions are represented as such (without any reference to vtables). I believe the only dependency on the particular C/C++ ABI is in determining the sizes and alignment of objects. This representation is perfect for cross-reference tools and source-level analysis tools (like lint); you can compute call graphs, you can find all the places where a given variable is used, etc. -- Mark Mitchell CodeSourcery, LLC (916) 791-8304 mark@codesourcery.com ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Bug 16115, C++ invisible references 2004-07-07 20:29 ` Mark Mitchell @ 2004-07-07 21:16 ` Richard Henderson 2004-07-07 21:17 ` Mark Mitchell 0 siblings, 1 reply; 18+ messages in thread From: Richard Henderson @ 2004-07-07 21:16 UTC (permalink / raw) To: Mark Mitchell; +Cc: Jason Merrill, gcc-patches On Wed, Jul 07, 2004 at 12:47:14PM -0700, Mark Mitchell wrote: > What do you mean by "semantics"? I did mean the "what does it mean to execute this" type of semantics as opposed to the "is this a valid program" type of semantics. > Certainly, unlowered EDG IL is semantic, in the sense that it would be > easy to execute. Well then, they've certainly done something different with their scopes than we have. I'm guessing statement-like things that push/pop the scope? More or less what we had with SCOPE_STMT? That's all well and good, but GENERIC doesn't work that way. It wants strictly nested constructs. I think any attempt to mix a strictly-nested style with one that is not strictly nested (as with C++ {IF,WHILE,FOR,SWITCH}_STMT), will result in Ugly Warts. r~ ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Bug 16115, C++ invisible references 2004-07-07 21:16 ` Richard Henderson @ 2004-07-07 21:17 ` Mark Mitchell 2004-07-07 21:35 ` Richard Henderson 0 siblings, 1 reply; 18+ messages in thread From: Mark Mitchell @ 2004-07-07 21:17 UTC (permalink / raw) To: Richard Henderson; +Cc: Jason Merrill, gcc-patches Richard Henderson wrote: >>Certainly, unlowered EDG IL is semantic, in the sense that it would be >>easy to execute. >> >> > >Well then, they've certainly done something different with their >scopes than we have. I'm guessing statement-like things that >push/pop the scope? More or less what we had with SCOPE_STMT? > >That's all well and good, but GENERIC doesn't work that way. It >wants strictly nested constructs. I think any attempt to mix a >strictly-nested style with one that is not strictly nested >(as with C++ {IF,WHILE,FOR,SWITCH}_STMT), will result in Ugly Warts. > > Their stuff is more like the FOR_STMT sytle, but they don't have anything like SCOPE_STMT. They do have a scope tree, though. I don't think what they have is strictly nested, but it's close. I'm not keen on mixing, and I've got no beef with GENERIC; I just want to see that the transformation to GENERIC happen separately. For example, I'd expect that: for (int i = 0; i < 10; ++i) ... be transformed so that the declaration of "i" was pulled out into a new scope, ala: { int i = 0; for (; i < 10; ++i) ... } by the lowering phase. That's when I'd expect Jason's parameter-type manipulations to happen as well. -- Mark Mitchell CodeSourcery, LLC (916) 791-8304 mark@codesourcery.com ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Bug 16115, C++ invisible references 2004-07-07 21:17 ` Mark Mitchell @ 2004-07-07 21:35 ` Richard Henderson 2004-07-07 21:41 ` Mark Mitchell 0 siblings, 1 reply; 18+ messages in thread From: Richard Henderson @ 2004-07-07 21:35 UTC (permalink / raw) To: Mark Mitchell; +Cc: Jason Merrill, gcc-patches On Wed, Jul 07, 2004 at 02:03:20PM -0700, Mark Mitchell wrote: > I'm not keen on mixing, and I've got no beef with GENERIC; I just want > to see that the transformation to GENERIC happen separately. I have no problem with that. Indeed, if you can get the representation of normal functions closer to what you need for template functions, then things might well be cleaner all through the front end. r~ ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Bug 16115, C++ invisible references 2004-07-07 21:35 ` Richard Henderson @ 2004-07-07 21:41 ` Mark Mitchell 2004-07-07 21:58 ` Gabriel Dos Reis 2004-07-15 7:27 ` Jason Merrill 0 siblings, 2 replies; 18+ messages in thread From: Mark Mitchell @ 2004-07-07 21:41 UTC (permalink / raw) To: Richard Henderson; +Cc: Jason Merrill, gcc-patches Richard Henderson wrote: >On Wed, Jul 07, 2004 at 02:03:20PM -0700, Mark Mitchell wrote: > > >>I'm not keen on mixing, and I've got no beef with GENERIC; I just want >>to see that the transformation to GENERIC happen separately. >> >> > >I have no problem with that. > >Indeed, if you can get the representation of normal functions >closer to what you need for template functions, then things >might well be cleaner all through the front end. > > Indeed. My longer-term roadmap would be to gradually move the transformations that we already do into the high-level->GENERIC conversion phase. For example, I'd postpone vtable generation and lowering of virtual function calls until that phase. Another win of this approach is better diagnostics; right now, our expression-printers will sometimes print out gobbledygook about vtables when trying to show a virtual function call, for example. Jason? -- Mark Mitchell CodeSourcery, LLC (916) 791-8304 mark@codesourcery.com ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Bug 16115, C++ invisible references 2004-07-07 21:41 ` Mark Mitchell @ 2004-07-07 21:58 ` Gabriel Dos Reis 2004-07-15 7:27 ` Jason Merrill 1 sibling, 0 replies; 18+ messages in thread From: Gabriel Dos Reis @ 2004-07-07 21:58 UTC (permalink / raw) To: Mark Mitchell; +Cc: Richard Henderson, Jason Merrill, gcc-patches Mark Mitchell: > Richard Henderson wrote: >>Indeed, if you can get the representation of normal functions >>closer to what you need for template functions, then things >>might well be cleaner all through the front end. >> >> > Indeed. My longer-term roadmap would be to gradually move the > transformations that we already do into the high-level->GENERIC > conversion phase. For example, I'd postpone vtable generation and > lowering of virtual function calls until that phase. Another win of > this approach is better diagnostics; right now, our expression-printers > will sometimes print out gobbledygook about vtables when trying to show > a virtual function call, for example. I strongly second this move. -- Gaby ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Bug 16115, C++ invisible references 2004-07-07 21:41 ` Mark Mitchell 2004-07-07 21:58 ` Gabriel Dos Reis @ 2004-07-15 7:27 ` Jason Merrill 2004-07-15 7:28 ` Mark Mitchell 1 sibling, 1 reply; 18+ messages in thread From: Jason Merrill @ 2004-07-15 7:27 UTC (permalink / raw) To: Mark Mitchell; +Cc: Richard Henderson, gcc-patches On Wed, 07 Jul 2004 14:16:23 -0700, Mark Mitchell <mark@codesourcery.com> wrote: > Richard Henderson wrote: > >>On Wed, Jul 07, 2004 at 02:03:20PM -0700, Mark Mitchell wrote: >> >>> I'm not keen on mixing, and I've got no beef with GENERIC; I just want >>> to see that the transformation to GENERIC happen separately. >> >>I have no problem with that. >> >>Indeed, if you can get the representation of normal functions >>closer to what you need for template functions, then things >>might well be cleaner all through the front end. >> > Indeed. My longer-term roadmap would be to gradually move the > transformations that we already do into the high-level->GENERIC conversion > phase. For example, I'd postpone vtable generation and lowering of virtual > function calls until that phase. Another win of this approach is better > diagnostics; right now, our expression-printers will sometimes print out > gobbledygook about vtables when trying to show a virtual function call, for > example. > > Jason? OK. Jason ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Bug 16115, C++ invisible references 2004-07-15 7:27 ` Jason Merrill @ 2004-07-15 7:28 ` Mark Mitchell 0 siblings, 0 replies; 18+ messages in thread From: Mark Mitchell @ 2004-07-15 7:28 UTC (permalink / raw) To: Jason Merrill; +Cc: Richard Henderson, gcc-patches Jason Merrill wrote: >On Wed, 07 Jul 2004 14:16:23 -0700, Mark Mitchell <mark@codesourcery.com> wrote: > > > >>Richard Henderson wrote: >> >> >> >>>On Wed, Jul 07, 2004 at 02:03:20PM -0700, Mark Mitchell wrote: >>> >>> >>> >>>>I'm not keen on mixing, and I've got no beef with GENERIC; I just want >>>>to see that the transformation to GENERIC happen separately. >>>> >>>> >>>I have no problem with that. >>> >>>Indeed, if you can get the representation of normal functions >>>closer to what you need for template functions, then things >>>might well be cleaner all through the front end. >>> >>> >>> >>Indeed. My longer-term roadmap would be to gradually move the >>transformations that we already do into the high-level->GENERIC conversion >>phase. For example, I'd postpone vtable generation and lowering of virtual >>function calls until that phase. Another win of this approach is better >>diagnostics; right now, our expression-printers will sometimes print out >>gobbledygook about vtables when trying to show a virtual function call, for >>example. >> >>Jason? >> >> > >OK. > Yay, I like agreement. :-) Thanks, -- Mark Mitchell CodeSourcery, LLC (916) 791-8304 mark@codesourcery.com ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2004-07-14 22:46 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-07-06 7:32 Reverting your patch from 2004-06-24 Mark Mitchell 2004-07-06 22:33 ` Bug 16115, C++ invisible references (was: Reverting your patch from 2004-06-24) Jason Merrill 2004-07-06 22:42 ` Bug 16115, C++ invisible references Mark Mitchell 2004-07-06 22:54 ` Phil Edwards 2004-07-06 23:05 ` Mark Mitchell 2004-07-06 23:15 ` Steven Bosscher 2004-07-07 1:32 ` Mark Mitchell 2004-07-07 17:53 ` Jason Merrill 2004-07-07 18:22 ` Mark Mitchell 2004-07-07 19:40 ` Richard Henderson 2004-07-07 20:29 ` Mark Mitchell 2004-07-07 21:16 ` Richard Henderson 2004-07-07 21:17 ` Mark Mitchell 2004-07-07 21:35 ` Richard Henderson 2004-07-07 21:41 ` Mark Mitchell 2004-07-07 21:58 ` Gabriel Dos Reis 2004-07-15 7:27 ` Jason Merrill 2004-07-15 7:28 ` Mark Mitchell
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).