Reverting your patch from 2004-06-24

Reverting your patch from 2004-06-24

[Mark Mitchell]

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

Bug 16115, C++ invisible references (was: Reverting your patch from 2004-06-24)

[Jason Merrill]

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

Re: Bug 16115, C++ invisible references

[Mark Mitchell]

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

Re: Bug 16115, C++ invisible references

[Phil Edwards]

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.

Re: Bug 16115, C++ invisible references

[Mark Mitchell]

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

Re: Bug 16115, C++ invisible references

[Steven Bosscher]

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

Re: Bug 16115, C++ invisible references

[Mark Mitchell]

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

Re: Bug 16115, C++ invisible references

[Jason Merrill]

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

Re: Bug 16115, C++ invisible references

[Mark Mitchell]

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

Re: Bug 16115, C++ invisible references

[Richard Henderson]

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~

Re: Bug 16115, C++ invisible references

[Mark Mitchell]

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

Re: Bug 16115, C++ invisible references

[Richard Henderson]

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~

Re: Bug 16115, C++ invisible references

[Mark Mitchell]

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

Re: Bug 16115, C++ invisible references

[Richard Henderson]

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~

Re: Bug 16115, C++ invisible references

[Mark Mitchell]

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

Re: Bug 16115, C++ invisible references

[Gabriel Dos Reis]

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

Re: Bug 16115, C++ invisible references

[Jason Merrill]

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

Re: Bug 16115, C++ invisible references

[Mark Mitchell]

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