RFC: debug line info & inlining; patch proposal and request for comments.

RFC: debug line info & inlining; patch proposal and request for comments.

[Carlo Wood]

Problem description
-------------------

The debug source-file/line-number information (location) in relation
with inlined functions is not perfect.

The main problem in fixing this, hence this RFC, is that I am not
sure what test case would cover all possibilities.  The test case
that I have in mind is given below.  If something is missing then
I really need to know that or else the patch might fix one thing
but break another!

Consider the following test case (a C++ program):

~>grep -n ^ troep.cc
1:extern int a;
2:extern int h();
3:
4:inline int
5:i(int v, int w)
6:{
7:  a += v + w;
8:}
9:
10:inline void
11:g(int x,
12:  int y = h(),
13:  int z = i(12345, h()))
14:{
15:  int q[4] = { 2, 3, 5, 7 };
16:  a += x + y + z + (int)&q;
17:}
18:
19:void f()
20:{
21:  g(h());
22:}

This generates (current CVS + patch of PR 12319) the following assembly code
for function f(), compiled as:
# g++-cvs-3.4 -c troep.cc -g -finline -save-temps -v

                                        // My comments here:
_Z1fv:
.LFB4:
        .file 1 "troep.c"
        .loc 1 20 0			// Prologue of f() at line 20
        pushl   %ebp
.LCFI0:
        movl    %esp, %ebp
.LCFI1:
        subl    $56, %esp
.LCFI2:
.LBB2:
.LBB3:
        .loc 1 14 0			// Line 14 for inlined g()
        call    _Z1hv			// Call that is actually done at line 21
        movl    %eax, -12(%ebp)		// Assignment to x.
        call    _Z1hv			// Call that is actually done at line 12
        movl    %eax, -16(%ebp)		// Assignment to y.
.LBB4:
        .loc 1 6 0			// Line 6 for inlined i()
        movl    $12345, -24(%ebp)	// Assignment to v.
        call    _Z1hv			// Call that is actually done at line 13
        movl    %eax, -28(%ebp)		// Assignment to w.
.LBB5:
        .loc 1 7 0			// Actually inlined code of i(), at line 7.
        movl    -28(%ebp), %eax		// >
        addl    -24(%ebp), %eax		// > a += v + w
        addl    %eax, a			// >
.LBE5:
.LBE4:
        .loc 1 6 0			// Back to line 6 - prologue of i() actually at line 8.
        movl    -32(%ebp), %eax		// Undefined return value of i()
        movl    %eax, -20(%ebp)		// Assignment to z, actually at line 13
.LBB6:
.LBB7:
        .loc 1 15 0			// Wow, a correctc linenumber for a change.
        movl    $2, -56(%ebp)		// int q[4] = { 2, 3, 4, 5 };
        movl    $3, -52(%ebp)
        movl    $5, -48(%ebp)
        movl    $7, -44(%ebp)
        .loc 1 16 0			// Line 16: a += x + y + z + (int)&q;
        movl    -16(%ebp), %eax		// y
        addl    -12(%ebp), %eax		// x
        movl    %eax, %edx		// x + y
        addl    -20(%ebp), %edx		// + z
        leal    -56(%ebp), %eax		// (int)&q
        leal    (%edx,%eax), %eax	// a +=
        addl    %eax, a
.LBE7:
.LBE6:
.LBE3:
.LBE2:
        .loc 1 22 0			// Prologue of f() at line 22.
        leave
        ret


As you can see, all line numbers are wrong that refer to initialization
of inlined function parameters.

I think I can hardly screw this up MORE then already is the case,
but maybe I am overlooking a construction that WOULD be screwed up
changing this.

For the given test case, the most important thing to get right
imho are the call's (to h()).  These calls leave their return address
on the stack and are therefore a direct target for debuggers to
be resolved to a source location; this needs to be fixed.
The actual assignment to the function parameters is less
important I think: in order to get that right you'd need to
"swap" between line numbers too often, only increasing the the
ammount of debug info rather unnecessarily imho.

All of this (the part that I intend to fix the debug line number
information for) is emitted by a single call to expand_expr() in
expr.c, for an expression of type 'expr_with_file_location'
that recursively contains all the initialization (calls) of
the function parameters of an inlined function.

The problem arises from this recursion: the expr_with_file_location
is only a container of everything of the inlined function, including
the initialization and any calls that are done as part of the
parameter initialization.  But, the implementation of this
expr_"with_file_location" is that it emits that location at the
start.  As a result all of the initialization, including any calls
needed, are assigned the line number of the prologue of the inlined
functions definition - totally incorrect.


Proposal for new behaviour
--------------------------

My proposal for a new behaviour is that the above assembly code
would contain the following line numbers:

_Z1fv:
.LFB4:
        .file 1 "troep.c"
        .loc 1 20 0			// Prologue of f() at line 20
        pushl   %ebp
.LCFI0:
        movl    %esp, %ebp
.LCFI1:
        subl    $56, %esp
.LCFI2:
.LBB2:
.LBB3:
        .loc 1 21 0			// Line 21
        call    _Z1hv			// Call that is actually done at line 21
        movl    %eax, -12(%ebp)		// Assignment to x.
	.loc 1 12 0			// Line 12
        call    _Z1hv			// Call that is actually done at line 12
        movl    %eax, -16(%ebp)		// Assignment to y.
.LBB4:
        .loc 1 6 0			// Line 6 for inlined i()
        movl    $12345, -24(%ebp)	// Assignment to v.
	.loc 1 13			// Line 13
        call    _Z1hv			// Call that is actually done at line 13
        movl    %eax, -28(%ebp)		// Assignment to w.
.LBB5:
        .loc 1 7 0			// Actually inlined code of i(), at line 7.
        movl    -28(%ebp), %eax		// >
        addl    -24(%ebp), %eax		// > a += v + w
        addl    %eax, a			// >
.LBE5:
.LBE4:
        .loc 1 8 0			// Prologue of i() actually at line 8.
        movl    -32(%ebp), %eax		// Undefined return value of i()
        movl    %eax, -20(%ebp)		// Assignment to z, actually at line 13
.LBB6:
.LBB7:
        .loc 1 15 0			// Line 15
        movl    $2, -56(%ebp)		// int q[4] = { 2, 3, 4, 5 };
        movl    $3, -52(%ebp)
        movl    $5, -48(%ebp)
        movl    $7, -44(%ebp)
        .loc 1 16 0			// Line 16: a += x + y + z + (int)&q;
        movl    -16(%ebp), %eax		// y
        addl    -12(%ebp), %eax		// x
        movl    %eax, %edx		// x + y
        addl    -20(%ebp), %edx		// + z
        leal    -56(%ebp), %eax		// (int)&q
        leal    (%edx,%eax), %eax	// a +=
        addl    %eax, a
.LBE7:
.LBE6:
.LBE3:
.LBE2:
        .loc 1 22 0			// Prologue of f() at line 22.
        leave
        ret

In other words: all of the call's correct, and the assignments
to function parameters rather fuzzy.

Comments please?

-- 
Carlo Wood <carlo@alinoe.com>

Re: RFC: debug line info & inlining; patch proposal and request for comments.

[Jim Wilson]

Carlo Wood wrote:
> The debug source-file/line-number information (location) in relation
> with inlined functions is not perfect.

The primary place for tests of this kind is in the gdb testsuite.  If 
you make changes to debug info, you have to make sure that the gdb 
testsuite doesn't break.  This may mean patches for the gdb testsuite if 
you want to change behaviour visible to it, or add tests to it.  This 
may need to be discussed with the gdb team.

You are apparently using stabs.  DWARF2 is preferred.  If DWARF2 gives 
the right answer, then maybe the solution is to use DWARF2 instead of 
stabs.  If you are changing code outside dbxout.c, then make sure you 
don't accidentally break the DWARF2 output, since people will be unhappy 
if stabs gets better at the expense of DWARF2.

This does look like a reasonable change to the debug info.  I'm not 
enough of a C++ expert to comment on the right testcase for the change.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only.

[Carlo Wood]

I worked out several ways to achieve said goal of fixing the
debug info of calls and inlining,
(see http://gcc.gnu.org/ml/gcc/2003-09/msg00942.html)
but in all cases there needs to be a location_t assigned to
every CALL_EXPR.

The most robust and simplist solution is to add a
location_t to tree_exp.  When I mentioned on IRC that
I had solved it this way, there was objection about
memory usage.  But tree-ssa (3.5) even adds a
location_t to tree_common!  Then why not do the same
for 3.4 already so I can solve the problem at hand?

A suggestion was to use expr wfl, but that is impractical:
there are too many places where an expressions type is directly
compared with CALL_EXPR (if (TREE_CODE (call) != CALL_EXPR)) -
all of those places would have to be changed to also check for
a EXPR_WITH_FILE_LOCATION that wraps a CALL_EXPR and then
unwrap the call expr in order to subsequentially be able to
process it.  I heared that this is the way that tree-ssa has
attempted to add locations at first (using a macro STRIP_WFL),
but also then was decided that it was undoable.

Imho, the conclusion is, looking at how this will be done
more generally in 3.5, that we should simply solve this for
3.4 in the same way (memory consumption wise) and
- adding an addition pointer or integer to tree_exp, until the
merge with tree-ssa 3.5.  This should be acceptable.

If people think that that uses too much memory nevertheless,
then please explain how else it is possible to add a location_t
to a CALL_EXPR.  Or just tell me what WILL be approved in terms
of memory usage. 
- Add a complete tree_common + location_t to every
CALL_EXPR?  Then I could add another operand to call expressions.
- Or only a single location_t per CALL_EXPR (the very minimum of
memory usage).  That is possible but then I will have to make
some changes to how the ggc_* works now (I'd dynamically add a
location_t *behind* the operand[]).

On Mon, Sep 22, 2003 at 02:17:10AM +0200, Carlo Wood wrote:
> Proposal for new behaviour
> --------------------------
> 
> My proposal for a new behaviour is that the above assembly code
> would contain the following line numbers:
> 
> _Z1fv:
> .LFB4:
>         .file 1 "troep.c"
>         .loc 1 20 0			// Prologue of f() at line 20
>         pushl   %ebp
> .LCFI0:
>         movl    %esp, %ebp
> .LCFI1:
>         subl    $56, %esp
> .LCFI2:
> .LBB2:
> .LBB3:
>         .loc 1 21 0			// Line 21
>         call    _Z1hv			// Call that is actually done at line 21
>         movl    %eax, -12(%ebp)
> 	.loc 1 12 0			// Line 12
>         call    _Z1hv			// Call that is actually done at line 12
>         movl    %eax, -16(%ebp)
> .LBB4:
>         .loc 1 6 0			// Line 6 for inlined i()
>         movl    $12345, -24(%ebp)	// Assignment to v.
> 	.loc 1 13			// Line 13
>         call    _Z1hv			// Call that is actually done at line 13
[...]

-- 
Carlo Wood <carlo@alinoe.com>

Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only.

[Hans-Peter Nilsson]

(It's properly "RFC" for this kind of message.  C is for Comments,
while A is for Approval, as in "patch-included-ok-to-check-in?".
Dan Berlin wants to make you say "[PATCH]" -- don't listen to him! ;-)

On Sat, 27 Sep 2003, Carlo Wood wrote:
> I worked out several ways to achieve said goal of fixing the
> debug info of calls and inlining,
> (see http://gcc.gnu.org/ml/gcc/2003-09/msg00942.html)
> but in all cases there needs to be a location_t assigned to
> every CALL_EXPR.

Being on the receiving end of faulty inline debug info, I'd say
that fixing such problems would be quite worthwhile!

Unfortunately, I know too little of this area to even answer
your question.

To get a patch in in *this* phase, I suggest sending patches
ASAP.  (If you did, I guess I missed it.)  I suggest being very
careful to follow the contribution guidelines to avoid
unnecessary patch iterations and reviewer badwill.

brgds, H-P

Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only.

[Richard Henderson]

On Sat, Sep 27, 2003 at 02:49:20PM +0200, Carlo Wood wrote:
> But tree-ssa (3.5) even adds a location_t to tree_common!

Not anymore.

> A suggestion was to use expr wfl, but that is impractical:
> there are too many places where an expressions type is directly
> compared with CALL_EXPR (if (TREE_CODE (call) != CALL_EXPR)) -
> all of those places would have to be changed to also check for
> a EXPR_WITH_FILE_LOCATION that wraps a CALL_EXPR and then
> unwrap the call expr in order to subsequentially be able to
> process it.

What leads you to believe that this is true?  Why would not the
WFL expr just go through expand_expr, and thence to expand_call?


r~

Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only.

[Daniel Jacobowitz]

On Mon, Oct 06, 2003 at 10:40:54AM -0700, Richard Henderson wrote:
> On Sat, Sep 27, 2003 at 02:49:20PM +0200, Carlo Wood wrote:
> > But tree-ssa (3.5) even adds a location_t to tree_common!
> 
> Not anymore.
> 
> > A suggestion was to use expr wfl, but that is impractical:
> > there are too many places where an expressions type is directly
> > compared with CALL_EXPR (if (TREE_CODE (call) != CALL_EXPR)) -
> > all of those places would have to be changed to also check for
> > a EXPR_WITH_FILE_LOCATION that wraps a CALL_EXPR and then
> > unwrap the call expr in order to subsequentially be able to
> > process it.
> 
> What leads you to believe that this is true?  Why would not the
> WFL expr just go through expand_expr, and thence to expand_call?

Well, wouldn't e.g. operand_equal_p need to handle
EXPR_WITH_FILE_LOCATION?  I see lots of other places in the optimizers
with the same issue.  Right now EXPR_WITH_FILE_LOCATION is only used to
wrap inline calls, as far as I can see.  Even there I suspect it hurts
optimization because of this issue.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only.

[Daniel Berlin]

On Oct 6, 2003, at 1:51 PM, Daniel Jacobowitz wrote:

> On Mon, Oct 06, 2003 at 10:40:54AM -0700, Richard Henderson wrote:
>> On Sat, Sep 27, 2003 at 02:49:20PM +0200, Carlo Wood wrote:
>>> But tree-ssa (3.5) even adds a location_t to tree_common!
>>
>> Not anymore.

Instead it adds it to tree_exp and tree_decl.
Adding it to tree_exp on the mainline would also help solve Carlo's 
problem.


>>
>>> A suggestion was to use expr wfl, but that is impractical:
>>> there are too many places where an expressions type is directly
>>> compared with CALL_EXPR (if (TREE_CODE (call) != CALL_EXPR)) -
>>> all of those places would have to be changed to also check for
>>> a EXPR_WITH_FILE_LOCATION that wraps a CALL_EXPR and then
>>> unwrap the call expr in order to subsequentially be able to
>>> process it.
>>
>> What leads you to believe that this is true?  Why would not the
>> WFL expr just go through expand_expr, and thence to expand_call?
>
> Well, wouldn't e.g. operand_equal_p need to handle
> EXPR_WITH_FILE_LOCATION?  I see lots of other places in the optimizers
> with the same issue.  Right now EXPR_WITH_FILE_LOCATION is only used to
> wrap inline calls, as far as I can see.  Even there I suspect it hurts
> optimization because of this issue.

God i hated STRIP_WFL.
It was evil.
>

Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only.

[Carlo Wood]

On Mon, Oct 06, 2003 at 10:40:54AM -0700, Richard Henderson wrote:
> What leads you to believe that this is true?  Why would not the
> WFL expr just go through expand_expr, and thence to expand_call?

Most code is simply assuming that if an expression is not
a CALL_EXP it is not a call - while a CALL_EXP wrapped in
a WFL *would* be a call.  There is no automatic unwrapping
done due to how expressions are handled at all places;
I ran into a few cases where actually was tested for CALL_EXP
while at that moment it was my WFL containing the CALL_EXP
and then, when talking to Daniel Berlin on IRC he told me
that the same approach has been tried on tree-ssa, giving
rise to the need for a macro STRIP_WFL at all those places.
Because of this past experience with tree-ssa on the same
subject, it seemed not necessary to investigate this further.

-- 
Carlo Wood <carlo@alinoe.com>

Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only.

[Carlo Wood]

On Mon, Oct 06, 2003 at 02:03:21PM -0400, Daniel Berlin wrote:
> 
> On Oct 6, 2003, at 1:51 PM, Daniel Jacobowitz wrote:
> 
> >On Mon, Oct 06, 2003 at 10:40:54AM -0700, Richard Henderson wrote:
> >>On Sat, Sep 27, 2003 at 02:49:20PM +0200, Carlo Wood wrote:
> >>>But tree-ssa (3.5) even adds a location_t to tree_common!
> >>
> >>Not anymore.
> 
> Instead it adds it to tree_exp and tree_decl.
> Adding it to tree_exp on the mainline would also help solve Carlo's 
> problem.

Then would it be ok for me to add the location_t to tree_exp
already please?  The following patch is an example (although
fully functional):

When using the compiler with and without this patch on very large
C++ compialtion unit, the result of -fmem-report gave:

without:

Size   Allocated        Used    Overhead
Total         30M         24M        291k

with:

Size   Allocated        Used    Overhead
Total         32M         25M        301k

I have no problem with reducing the memory usage, but that will
be a considerably more complex (looking) patch :).
I still don't believe that the WFL is the correct approach,
but I could make the location_t *optional* to tree_exp structs
so that they will only be allocated when it is a CALL_EXP.
In order to not confuse the existing code for non-CALL_EXP tree_exp
objects, this extension would need to be added *after* the
operand[] array.  You you rather see me submit a patch for that
for review?  That will make the extra memory usage go away at
the cost of ... well, at the cost of nothing actually, except
that the patch is more complex to understand :*).  When I proposed
this on IRC, drow said 'it would almost certainly be disapproved'.
But I wouldn't know why.  This approach would be normal 'inheritance'
approach from the object oriented world:

                     __
struct tree_exp --> /
                    |
		    |  Normal tree_exp
		    |
		    \__
		    |
		    |  Extension
		    \__

It would as if

struct call_expr : public tree_exp {
  location_t locus;
};

if you get the idea.


Index: gcc/expr.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/expr.c,v
retrieving revision 1.589
diff -u -d -p -r1.589 expr.c
--- gcc/expr.c	28 Sep 2003 04:56:33 -0000	1.589
+++ gcc/expr.c	6 Oct 2003 18:37:40 -0000
@@ -7909,6 +7909,7 @@ expand_expr (tree exp, rtx target, enum 
 	    return expand_builtin (exp, target, subtarget, tmode, ignore);
 	}
 
+      emit_line_note (EXPR_SOURCE_LOCATION (exp));
       return expand_call (exp, target, ignore);
 
     case NON_LVALUE_EXPR:
Index: gcc/tree.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/tree.c,v
retrieving revision 1.330
diff -u -d -p -r1.330 tree.c
--- gcc/tree.c	22 Sep 2003 05:09:12 -0000	1.330
+++ gcc/tree.c	6 Oct 2003 18:37:45 -0000
@@ -2389,6 +2389,9 @@ build (enum tree_code code, tree tt, ...
 	TREE_SIDE_EFFECTS (t) = 1;
     }
 
+  if (code == CALL_EXPR)
+    EXPR_SOURCE_LOCATION (t) = input_location;
+
   return t;
 }
 
Index: gcc/tree.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/tree.h,v
retrieving revision 1.447
diff -u -d -p -r1.447 tree.h
--- gcc/tree.h	28 Sep 2003 19:09:49 -0000	1.447
+++ gcc/tree.h	6 Oct 2003 18:37:49 -0000
@@ -837,9 +837,21 @@ struct tree_vec GTY(())
 #define TARGET_EXPR_INITIAL(NODE) TREE_OPERAND_CHECK_CODE (NODE, TARGET_EXPR, 1)
 #define TARGET_EXPR_CLEANUP(NODE) TREE_OPERAND_CHECK_CODE (NODE, TARGET_EXPR, 2)
 
+/* These two fields describe where in the source code the call was
+   done in the case of a call expression.
+   This is particular useful when the call_expr is buried inside a
+   decl_expr of the function parameters of an inlined function; at
+   that moment the input_location points to the definition of the
+   inlined function, while this call is likely to be done at the
+   same line as the call to the inlined function.  */
+#define EXPR_SOURCE_LOCATION(NODE) (EXPR_CHECK (NODE)->exp.locus)
+#define EXPR_SOURCE_FILE(NODE) (EXPR_SOURCE_LOCATION (NODE).file)
+#define EXPR_SOURCE_LINE(NODE) (EXPR_SOURCE_LOCATION (NODE).line)
+
 struct tree_exp GTY(())
 {
   struct tree_common common;
+  location_t locus;		/* Used for call expressions only. */
   int complexity;
   tree GTY ((special ("tree_exp"),
 	     desc ("TREE_CODE ((tree) &%0)")))

Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only.

[Richard Henderson]

On Mon, Oct 06, 2003 at 09:08:17PM +0200, Carlo Wood wrote:
> Most code is simply assuming that if an expression is not
> a CALL_EXP it is not a call - while a CALL_EXP wrapped in
> a WFL *would* be a call.

That is a specious argument.  How does this differ from a
PLUS_EXPR that contains a call?


r~

Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only.

[Daniel Jacobowitz]

On Mon, Oct 06, 2003 at 01:11:02PM -0700, Richard Henderson wrote:
> On Mon, Oct 06, 2003 at 09:08:17PM +0200, Carlo Wood wrote:
> > Most code is simply assuming that if an expression is not
> > a CALL_EXP it is not a call - while a CALL_EXP wrapped in
> > a WFL *would* be a call.
> 
> That is a specious argument.  How does this differ from a
> PLUS_EXPR that contains a call?

A number of places continue to recurse on the arguments of a PLUS_EXPR
but do not handle EXPR_WITH_FILE_LOCATION, for one thing.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only.

[Richard Henderson]

On Mon, Oct 06, 2003 at 04:14:23PM -0400, Daniel Jacobowitz wrote:
> A number of places continue to recurse on the arguments of a PLUS_EXPR
> but do not handle EXPR_WITH_FILE_LOCATION, for one thing.

Please name such a place.  I'm asking for specifics here and
getting nothing from yall.

Have yall *tried* WFL and have experimental evidence for how much
of a performance hit you get?  Given that we do extraordinarily
little reasoning with trees on mainline, I have a hard time imagining
that it has much affect at all.


r~

Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only.

[Daniel Jacobowitz]

On Mon, Oct 06, 2003 at 01:20:57PM -0700, Richard Henderson wrote:
> On Mon, Oct 06, 2003 at 04:14:23PM -0400, Daniel Jacobowitz wrote:
> > A number of places continue to recurse on the arguments of a PLUS_EXPR
> > but do not handle EXPR_WITH_FILE_LOCATION, for one thing.
> 
> Please name such a place.  I'm asking for specifics here and
> getting nothing from yall.

I gave one a couple messages back, or meant to: operand_equal_p.

> Have yall *tried* WFL and have experimental evidence for how much
> of a performance hit you get?  Given that we do extraordinarily
> little reasoning with trees on mainline, I have a hard time imagining
> that it has much affect at all.

I'd be surprised if it was a major hit, too, but Carlo did claim he'd
found more occurances than just the one I quoted.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only.

[Carlo Wood]

On Mon, Oct 06, 2003 at 01:20:57PM -0700, Richard Henderson wrote:
> Please name such a place.  I'm asking for specifics here and
> getting nothing from yall.

get_callee_fndecl is one.

It says:

   if (TREE_CODE (call) != CALL_EXPR)
        abort ();

... it did abort.

> Have yall *tried* WFL

yes

> and have experimental evidence for how much
> of a performance hit you get?

I never said it would be a performance hit, the whole WFL is
just a ugly "solution" that isn't used much yet; when using
it more it will cause exceptions all over the code.

I'll write the patch nevertheless, then you can see what I mean.

-- 
Carlo Wood <carlo@alinoe.com>

Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only.

[Richard Henderson]

On Mon, Oct 06, 2003 at 04:24:00PM -0400, Daniel Jacobowitz wrote:
> I'd be surprised if it was a major hit, too, but Carlo did claim he'd
> found more occurances than just the one I quoted.

One or two ocurrences does not make a good argument for
adding a location_t to tree_expr.  Dozens, maybe.



r~

Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only.

[Richard Henderson]

On Mon, Oct 06, 2003 at 11:53:15PM +0200, Carlo Wood wrote:
> get_callee_fndecl is one.
> 
> It says:
> 
>    if (TREE_CODE (call) != CALL_EXPR)
>         abort ();
> 
> ... it did abort.

And why exactly would you be calling get_callee_fndecl on a WFL
in the first place?


r~

Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only.

[Carlo Wood]

On Mon, Oct 06, 2003 at 02:55:36PM -0700, Richard Henderson wrote:
> On Mon, Oct 06, 2003 at 11:53:15PM +0200, Carlo Wood wrote:
> > get_callee_fndecl is one.
> > 
> > It says:
> > 
> >    if (TREE_CODE (call) != CALL_EXPR)
> >         abort ();
> > 
> > ... it did abort.
> 
> And why exactly would you be calling get_callee_fndecl on a WFL
> in the first place?

Normally, get_callee_fndecl is called with a CALL_EXPR
as might be clear from the abort test :).

Now I don't understand your remark because when I add a location
to every CALL_EXPR by means of wrapping every CALL_EXPR in a WFL,
then get_callee_fndecl is thus called with a WFL that wraps the
CALL_EXPR.  That was the whole point no?  To *replace* *every*
CALL_EXPR with a EXPR_WITH_FILE_LOCATION, so I did :/

Now tell me I need to make an exception for get_callee_fndecl
because that would be the first of many exceptions that would
make this totally unmaintainable - or I am missing something.

/usr/src/GNU/gcc/gcc-mainline/gcc>grep get_callee_fndecl *.c
builtins.c:  tree fndecl = get_callee_fndecl (exp);
builtins.c:  tree fndecl = get_callee_fndecl (exp);
builtins.c:  tree fndecl = get_callee_fndecl (exp);
builtins.c:  fndecl = get_callee_fndecl (t);
builtins.c:  tree fndecl = get_callee_fndecl (exp);
builtins.c:  tree fndecl = get_callee_fndecl (exp);
builtins.c:      tree fndecl = get_callee_fndecl (exp);
builtins.c:      tree fndecl = get_callee_fndecl (exp);
builtins.c:  tree fndecl = get_callee_fndecl (exp);
calls.c:  fndecl = get_callee_fndecl (exp);
cgraphunit.c:   tree decl = get_callee_fndecl (*tp);
dojump.c:       tree fndecl = get_callee_fndecl (exp);
fold-const.c:     fndecl = get_callee_fndecl (arg0);
fold-const.c:         fndecl = get_callee_fndecl (arg0);
fold-const.c:     tree fndecl = get_callee_fndecl (arg0);
fold-const.c:   tree fndecl = get_callee_fndecl (t);
function.c:     fntype = get_callee_fndecl (fntype);
tree.c: tree fn = get_callee_fndecl (t);
tree.c:get_callee_fndecl (tree call)
tree-inline.c:      t = get_callee_fndecl (node);
tree-inline.c:  fn = get_callee_fndecl (t);

-- 
Carlo Wood <carlo@alinoe.com>

Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only.

[Richard Henderson]

On Tue, Oct 07, 2003 at 12:30:34AM +0200, Carlo Wood wrote:
> Now I don't understand your remark because when I add a location
> to every CALL_EXPR by means of wrapping every CALL_EXPR in a WFL,
> then get_callee_fndecl is thus called with a WFL that wraps the
> CALL_EXPR.  That was the whole point no?  To *replace* *every*
> CALL_EXPR with a EXPR_WITH_FILE_LOCATION, so I did :/

Sure.  But previously the code must have been looking for CALL_EXPR
by virtue of a switch/test/whatever.  This is obvious because we 
were not aborting in get_callee_fndecl.  I expect this to change 
not at all.

I would expect wrapping with WFL would not change this at all.  I
would expect that we'd simply call expand_expr one extra time, and
the subsequent recursion on the contained call_expr to do exactly
what we would have done before your change.

So your comment re get_callee_fndecl continues to make no sense.


r~


PS: Your response should include a *detailed* explanation for how
we would get into the situation that you describe.

Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only.

[Carlo Wood]

On Mon, Oct 06, 2003 at 04:17:06PM -0700, Richard Henderson wrote:
> Sure.  But previously the code must have been looking for CALL_EXPR
> by virtue of a switch/test/whatever.  This is obvious because we 
> were not aborting in get_callee_fndecl.  I expect this to change 
> not at all.
> 
> I would expect wrapping with WFL would not change this at all.  I
> would expect that we'd simply call expand_expr one extra time, and
> the subsequent recursion on the contained call_expr to do exactly
> what we would have done before your change.
> 
> So your comment re get_callee_fndecl continues to make no sense.

~>/usr/src/GNU/builds-gcc/mainline-native/gcc/xgcc -B/usr/src/GNU/builds-gcc/mainline-native/gcc/ -B/usr/src/GNU/install/i686-pc-linux-gnu/bin/ -B/usr/src/GNU/install/i686-pc-linux-gnu/lib/ -isystem /usr/src/GNU/install/i686-pc-linux-gnu/include -isystem /usr/src/GNU/install/i686-pc-linux-gnu/sys-include -g3 -finline -c troep.cc -S ; egrep -n '(call|\.loc)' troep.s | grep -B1 call
troep.cc:12: internal compiler error: in get_callee_fndecl, at tree.c:4440
Please submit a full bug report,

Thats the abort() that I ran into.  It made me feel unsecure about
how safe it would be to just-like-that wrap every CALL_EXPR in a WFL.

> r~
> 
> 
> PS: Your response should include a *detailed* explanation for how
> we would get into the situation that you describe.

Breakpoint 1, get_callee_fndecl (call=0x40266360)
    at ../../../gcc/gcc-mainline/gcc/tree.c:4440
4440        abort ();
(gdb) bt
#0  get_callee_fndecl (call=0x40266360) at ../../../gcc/gcc-mainline/gcc/tree.c:4440
#1  0x08058d10 in build_cxx_call (fn=0x40266360, args=0x0, converted_args=0x0)
    at ../../../gcc/gcc-mainline/gcc/cp/call.c:4626
#2  0x08058a61 in build_over_call (cand=0x402cff28, flags=3)
    at ../../../gcc/gcc-mainline/gcc/cp/call.c:4597
#3  0x08052139 in build_new_function_call (fn=0x402f4510, args=0x0)
    at ../../../gcc/gcc-mainline/gcc/cp/call.c:2751
#4  0x0817482e in finish_call_expr (fn=0x402f4510, args=0x0, disallow_virtual=false,
    koenig_p=false) at ../../../gcc/gcc-mainline/gcc/cp/semantics.c:1693
#5  0x08120ee6 in cp_parser_postfix_expression (parser=0x402f9140, address_p=false)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:3588
[...]

Frame #1, cp/call.c:

  fn = build_call (fn, converted_args);

  /* If this call might throw an exception, note that fact.  */
  fndecl = get_callee_fndecl (fn);


build_call now returns a WFL.
If we replacing the get_callee_fndecl call here with:

  fndecl = get_callee_fndecl (EXPR_WFL_NODE (fn));

it seems to work fine.

I guess more investigation IS warranted ;).
But I was already working on that, I'll get back with a full
report on the need to unwrap WFL-ed CALL_EXPR later...

Thanks for your patience so far,

-- 
Carlo Wood <carlo@alinoe.com>

Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only.

[Richard Henderson]

On Tue, Oct 07, 2003 at 01:49:40AM +0200, Carlo Wood wrote:
> Frame #1, cp/call.c:
> 
>   fn = build_call (fn, converted_args);
> 
>   /* If this call might throw an exception, note that fact.  */
>   fndecl = get_callee_fndecl (fn);
> 
> build_call now returns a WFL.

I think most definitely you're making your change at the wrong place.


r~

Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only.

[Carlo Wood]

On Mon, Oct 06, 2003 at 05:07:03PM -0700, Richard Henderson wrote:
> > build_call now returns a WFL.
> 
> I think most definitely you're making your change at the wrong place.

Oh.  Then where would be a better place?

-- 
Carlo Wood <carlo@alinoe.com>

Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only.

[Richard Henderson]

On Tue, Oct 07, 2003 at 02:43:05AM +0200, Carlo Wood wrote:
> Oh.  Then where would be a better place?

build_cxx_call, for one.  *After* propagating nothrow info.


r~

Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only.

[Carlo Wood]

Ok, I moved the wrapping to build_cxx_call.
That didn't help much though: the WFL is still passed
to functions that expect (or *might* expect) a CALL_EXPR.

The diff below reflects the state of my current test.

It contains a *functional* WFL wrapping (assembly output is
ok with my test case); however - I also added some test
code that does the following:

I changed the macro TREE_CODE(NODE) to core dump every
time that it is being called for the WFL that wraps
a CALL_EXPR and when the global 'nocheck' variable is not
set.

I set the 'nocheck' to 1 when it is normal that TREE_CODE()
would be called for the WFL; but still, it turns out that
the WFL ends up being passed unwrapped to certain functions
for which it is not logical that it isn't unwrapped in
advance and which potentially could cause a problem.

With my test case, and with the diff below, the core is
triggered here:

0x08192696 in arg_assoc (k=0xbfffea60, n=0x40266380)
    at ../../../gcc/gcc-mainline/gcc/cp/decl2.c:3699
3699      if (TYPE_P (n))

Where 'n' is a expr_with_file_location wrapping a call_expr:

(gdb) call debug_tree(n)
 <expr_with_file_location 0x40266380
    type <integer_type 0x4026a57c int SI
        size <integer_cst 0x40268258 constant 32>
        unit size <integer_cst 0x402682e4 constant 4>
        align 32 symtab 0 alias set -1 precision 32 min <integer_cst 0x402682bc -2147483648> max <integer_cst 0x402682d0 2147483647>
        pointer_to_this <pointer_type 0x4027506c>>
    side-effects public
    arg 0 <call_expr 0x4026f390 type <integer_type 0x4026a57c int>
        side-effects
        arg 0 <addr_expr 0x402edb90 type <pointer_type 0x402f4c3c>
            constant arg 0 <function_decl 0x402f45e8 h13>>>
    arg 1 <identifier_node 0x402f9580 troep.ccbindings <(nil)>local bindings <(nil)>>
    troep.cc:13:0>

While this particuar place might not be a problem because
it doesn't test explicitly for CALL_EXPR, so that that
now CALL_EXPR is 'replaced' with 'EXPR_WITH_FILE_LOCATION',
nothing changes, it still makes clear things COULD have
gone wrong.

arg_assoc contains a lot of direct tests of TREE_CODE:

static bool
arg_assoc (struct arg_lookup *k, tree n)
{
  if (n == error_mark_node)
    return false;

  if (TYPE_P (n))
    return arg_assoc_type (k, n);

  if (! type_unknown_p (n))
    return arg_assoc_type (k, TREE_TYPE (n));

  if (TREE_CODE (n) == ADDR_EXPR)
    n = TREE_OPERAND (n, 0);
  if (TREE_CODE (n) == COMPONENT_REF)
    n = TREE_OPERAND (n, 1);
  if (TREE_CODE (n) == OFFSET_REF)
    n = TREE_OPERAND (n, 1);
  while (TREE_CODE (n) == TREE_LIST)
    n = TREE_VALUE (n);
  if (TREE_CODE (n) == BASELINK)
[...etc...]


(gdb) bt
#0  0x08192696 in arg_assoc (k=0xbfffea60, n=0x40266380)
    at ../../../gcc/gcc-mainline/gcc/cp/decl2.c:3699
#1  0x08192628 in arg_assoc_args (k=0xbfffea60, args=0x402edba4)
    at ../../../gcc/gcc-mainline/gcc/cp/decl2.c:3686
#2  0x081937b0 in lookup_arg_dependent (name=0x402f9340, fns=0x402f4870, args=0x402edb7c)
    at ../../../gcc/gcc-mainline/gcc/cp/decl2.c:3790
#3  0x0823fd19 in perform_koenig_lookup (fn=0x402f4870, args=0x402edb7c)
    at ../../../gcc/gcc-mainline/gcc/cp/semantics.c:1567
#4  0x081b572b in cp_parser_postfix_expression (parser=0x402f9140, address_p=false)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:3543
#5  0x081b685a in cp_parser_unary_expression (parser=0x402f9140, address_p=false)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:4122
#6  0x081b6fa4 in cp_parser_cast_expression (parser=0x402f9140, address_p=false)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:4546
#7  0x081c71df in cp_parser_simple_cast_expression (parser=0x402f9140)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:13791
#8  0x081c6259 in cp_parser_binary_expression (parser=0x402f9140,
    token_tree_map=0x873a280, fn=0x81c71cc <cp_parser_simple_cast_expression>)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:13290
#9  0x081b6fca in cp_parser_pm_expression (parser=0x402f9140)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:4567
#10 0x081c6259 in cp_parser_binary_expression (parser=0x402f9140,
    token_tree_map=0x873a28c, fn=0x81b6faf <cp_parser_pm_expression>)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:13290
#11 0x081b6fea in cp_parser_multiplicative_expression (parser=0x402f9140)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:4591
#12 0x081c6259 in cp_parser_binary_expression (parser=0x402f9140,
    token_tree_map=0x873a29c, fn=0x81b6fcf <cp_parser_multiplicative_expression>)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:13290
#13 0x081b700a in cp_parser_additive_expression (parser=0x402f9140)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:4614
#14 0x081c6259 in cp_parser_binary_expression (parser=0x402f9140,
    token_tree_map=0x873a2a8, fn=0x81b6fef <cp_parser_additive_expression>)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:13290
#15 0x081b702a in cp_parser_shift_expression (parser=0x402f9140)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:4637
#16 0x081c6259 in cp_parser_binary_expression (parser=0x402f9140,
    token_tree_map=0x873a2b4, fn=0x81b700f <cp_parser_shift_expression>)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:13290
#17 0x081b704a in cp_parser_relational_expression (parser=0x402f9140)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:4672
#18 0x081c6259 in cp_parser_binary_expression (parser=0x402f9140,
    token_tree_map=0x873a2d0, fn=0x81b702f <cp_parser_relational_expression>)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:13290
#19 0x081b706a in cp_parser_equality_expression (parser=0x402f9140)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:4695
#20 0x081c6259 in cp_parser_binary_expression (parser=0x402f9140,
    token_tree_map=0x873a2dc, fn=0x81b704f <cp_parser_equality_expression>)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:13290
#21 0x081b708a in cp_parser_and_expression (parser=0x402f9140)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:4716
#22 0x081c6259 in cp_parser_binary_expression (parser=0x402f9140,
    token_tree_map=0x873a2e4, fn=0x81b706f <cp_parser_and_expression>)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:13290
#23 0x081b70aa in cp_parser_exclusive_or_expression (parser=0x402f9140)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:4737
#24 0x081c6259 in cp_parser_binary_expression (parser=0x402f9140,
    token_tree_map=0x873a2ec, fn=0x81b708f <cp_parser_exclusive_or_expression>)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:13290
#25 0x081b70ca in cp_parser_inclusive_or_expression (parser=0x402f9140)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:4759
#26 0x081c6259 in cp_parser_binary_expression (parser=0x402f9140,
    token_tree_map=0x873a2f4, fn=0x81b70af <cp_parser_inclusive_or_expression>)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:13290
#27 0x081b70ea in cp_parser_logical_and_expression (parser=0x402f9140)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:4780
#28 0x081c6259 in cp_parser_binary_expression (parser=0x402f9140,
    token_tree_map=0x873a2fc, fn=0x81b70cf <cp_parser_logical_and_expression>)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:13290
#29 0x081b710a in cp_parser_logical_or_expression (parser=0x402f9140)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:4801
#30 0x081b71e0 in cp_parser_assignment_expression (parser=0x402f9140)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:4869
#31 0x081bfa60 in cp_parser_parameter_declaration (parser=0x402f9140,
    template_parm_p=false) at ../../../gcc/gcc-mainline/gcc/cp/parser.c:10632
#32 0x081bf5d6 in cp_parser_parameter_declaration_list (parser=0x402f9140)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:10386
#33 0x081bf517 in cp_parser_parameter_declaration_clause (parser=0x402f9140)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:10332
#34 0x081bd3f4 in cp_parser_direct_declarator (parser=0x402f9140,
    dcl_kind=CP_PARSER_DECLARATOR_NAMED, ctor_dtor_or_conv_p=0xbffff0e0)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:9750
#35 0x081bd318 in cp_parser_declarator (parser=0x402f9140,
    dcl_kind=CP_PARSER_DECLARATOR_NAMED, ctor_dtor_or_conv_p=0xbffff0e0)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:9625
#36 0x081bcced in cp_parser_init_declarator (parser=0x402f9140,
    decl_specifiers=0x402edaa0, prefix_attributes=0x0,
    function_definition_allowed_p=true, member_p=false, declares_class_or_enum=0,
    function_definition_p=0xbffff13f) at ../../../gcc/gcc-mainline/gcc/cp/parser.c:9299
#37 0x081b8652 in cp_parser_simple_declaration (parser=0x402f9140,
    function_definition_allowed_p=true) at ../../../gcc/gcc-mainline/gcc/cp/parser.c:6156
#38 0x081b858c in cp_parser_block_declaration (parser=0x402f9140, statement_p=false)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:6072
#39 0x081b8448 in cp_parser_declaration (parser=0x402f9140)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:5992
#40 0x081b827e in cp_parser_declaration_seq_opt (parser=0x402f9140)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:5901
#41 0x081b34a5 in cp_parser_translation_unit (parser=0x402f9140)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:2163
#42 0x081c8cdb in c_parse_file () at ../../../gcc/gcc-mainline/gcc/cp/parser.c:14523
#43 0x082d79c8 in c_common_parse_file (set_yydebug=0)
    at ../../../gcc/gcc-mainline/gcc/c-opts.c:1226
#44 0x0860c923 in compile_file () at ../../../gcc/gcc-mainline/gcc/toplev.c:1792
#45 0x08611d36 in do_compile () at ../../../gcc/gcc-mainline/gcc/toplev.c:4482
#46 0x08611dcb in toplev_main (argc=29, argv=0xbffff2f4)
    at ../../../gcc/gcc-mainline/gcc/toplev.c:4522
#47 0x082db882 in main (argc=29, argv=0xbffff2f4)
    at ../../../gcc/gcc-mainline/gcc/main.c:35
#48 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
(gdb)

I go to bed now - tomorrow I'll find more places where this happens.


Index: rtl.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/rtl.c,v
retrieving revision 1.126
diff -u -d -p -r1.126 rtl.c
--- rtl.c	30 Jul 2003 19:23:31 -0000	1.126
+++ rtl.c	7 Oct 2003 02:22:14 -0000
@@ -28,6 +28,7 @@ Software Foundation, 59 Temple Place - S
 #include "ggc.h"
 #include "errors.h"
 
+int nocheck = 0;	/* just temporal test var */
 \f
 /* Indexed by rtx code, gives number of operands for an rtx with that code.
    Does NOT include rtx header data (code and links).  */
Index: tree.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/tree.h,v
retrieving revision 1.447
diff -u -d -p -r1.447 tree.h
--- tree.h	28 Sep 2003 19:09:49 -0000	1.447
+++ tree.h	7 Oct 2003 02:22:19 -0000
@@ -267,7 +267,20 @@ struct tree_common GTY(())
 
 /* The tree-code says what kind of node it is.
    Codes are defined in tree.def.  */
+extern int nocheck;
+#if 0
 #define TREE_CODE(NODE) ((enum tree_code) (NODE)->common.code)
+#else
+/* TEST CODE - REMOVE */
+#define TREE_CODE(NODE) __extension__					\
+({  enum tree_code code = ((enum tree_code) (NODE)->common.code);	\
+    if (!nocheck && code == EXPR_WITH_FILE_LOCATION &&			\
+        (TREE_CODE_NOCHECK(((NODE)->exp.operands[0])) == CALL_EXPR))	\
+      *(int*)0=1;							\
+    code; })
+#define TREE_CODE_NOCHECK(NODE) ((enum tree_code) (NODE)->common.code)
+#endif
+
 #define TREE_SET_CODE(NODE, VALUE) \
 ((NODE)->common.code = (ENUM_BITFIELD (tree_code)) (VALUE))
 
Index: cp/call.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cp/call.c,v
retrieving revision 1.437
diff -u -d -p -r1.437 call.c
--- cp/call.c	27 Sep 2003 16:44:04 -0000	1.437
+++ cp/call.c	7 Oct 2003 02:22:22 -0000
@@ -4642,7 +4642,18 @@ build_cxx_call(tree fn, tree args, tree 
 
   if (IS_AGGR_TYPE (TREE_TYPE (fn)))
     fn = build_cplus_new (TREE_TYPE (fn), fn);
-  return convert_from_reference (fn);
+
+  fn = convert_from_reference (fn);
+
+  /* Wrap every call in a wfl in order to garantee that the correct
+     locus debug information is emitted.  This exception is made for
+     calls because they turn up in debugger back traces.  */
+  nocheck=1;
+  fn = build_expr_wfl (fn, input_location.file, input_location.line, 0);
+  EXPR_WFL_EMIT_LINE_NOTE (fn) = 1;
+  nocheck=0;
+
+  return fn;
 }
 
 static GTY(()) tree java_iface_lookup_fn;

-- 
Carlo Wood <carlo@alinoe.com>

Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only.

[Carlo Wood]

On Mon, Oct 06, 2003 at 05:46:47PM -0700, Richard Henderson wrote:
> build_cxx_call, for one.  *After* propagating nothrow info.

As in the patch in my previous post, for testing purposes,
I did replace TREE_CODE() with a code that warns me whenever
it is used for a EXPR_WITH_FILE_LOCATION (wrapping the newly
wrapped CALL_EXPR).  I used TREE_CODE_NOCHECK to do what the
old TREE_CODE did.

Next, I manually investigated every place where this happened
and either turned off the warning (using TREE_CODE_NOCHECK or
with ++nocheck ... --nocheck wraps) and/or added code to handle
the EXPR_WITH_FILE_LOCATION.

Obvious places where no fix is needed is code like:

  if (TREE_CODE(t) == FOOBAR)

because FOOBAR != CALL_EXPR, and thus a wrapping with a
EXPR_WITH_FILE_LOCATION where TREE_CODE() suddenly returns
EXPR_WITH_FILE_LOCATION instead of CALL_EXPR, has no effect.

At other places it was less obvious and at several places
a fix was indeed needed to handle the EXPR_WITH_FILE_LOCATION:
automatic unwrapping had NOT taken place already and it
DID matter that the 'tree' at that point represents a CALL_EXPR,
although being wrapped up in a wfl now.  Examples of this are
where we test for TREE_CODE(t) == CALL_EXPR or a switch that
handles CALL_EXPR but does not handle EXPR_WITH_FILE_LOCATION.


For the little test case that I am using, I managed to fix
every place in gcc : either by using TREE_CODE_NOCHECK or
by handling the EXPR_WITH_FILE_LOCATION.  This resulted in
the following diff.  Please don't judge this diff on usefulness
or style - it is only intended to demonstrate the impact of using
WFL for CALL_EXPR-essions in build_cxx_call.

At *every* place where the diff changes something, we DID arrive
with a EXPR_WITH_FILE_LOCATION containing the CALL_EXPR *instead*
of getting there with the CALL_EXPR itself.

The changes to tree.h are not relevant for this demonstration
and are therefore not included.

Index: c-common.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/c-common.c,v
retrieving revision 1.461
diff -u -d -p -r1.461 c-common.c
--- c-common.c	25 Sep 2003 01:25:43 -0000	1.461
+++ c-common.c	7 Oct 2003 18:10:54 -0000
@@ -5733,10 +5733,10 @@ c_estimate_num_insns_1 (tree *tp, int *w
   /* Assume that constants and references counts nothing.  These should
      be majorized by amount of operations among them we count later
      and are common target of CSE and similar optimizations.  */
-  if (TREE_CODE_CLASS (TREE_CODE (x)) == 'c'
-      || TREE_CODE_CLASS (TREE_CODE (x)) == 'r')
+  if (TREE_CODE_CLASS (TREE_CODE_NOCHECK (x)) == 'c'
+      || TREE_CODE_CLASS (TREE_CODE_NOCHECK (x)) == 'r')
     return NULL;
-  switch (TREE_CODE (x))
+  switch (TREE_CODE_NOCHECK (x))
     { 
     /* Reconginze assignments of large structures and constructors of
        big arrays.  */
Index: cgraphunit.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cgraphunit.c,v
retrieving revision 1.33
diff -u -d -p -r1.33 cgraphunit.c
--- cgraphunit.c	26 Sep 2003 00:14:28 -0000	1.33
+++ cgraphunit.c	7 Oct 2003 18:10:54 -0000
@@ -227,7 +227,34 @@ record_call_1 (tree *tp, int *walk_subtr
 {
   tree t = *tp;
 
-  switch (TREE_CODE (t))
+  /* Another serious problem: we get here with our WFL for 't',
+     but the switch does not handle EXPR_WITH_FILE_LOCATION.
+     Getting here from:
+#0  0x0855e48d in record_call_1 (tp=0x402fe254, walk_subtrees=0xbfffed7c,
+    data=0x402fd3cc) at ../../../gcc/gcc-mainline/gcc/cgraphunit.c:230
+#1  0x0855abae in walk_tree (tp=0x402fe254, func=0x855e457 <record_call_1>,
+    data=0x402fd3cc, htab_=0x8767da0) at ../../../gcc/gcc-mainline/gcc/tree-inline.c:1720
+#2  0x0855b891 in walk_tree (tp=0x4026f584, func=0x855e457 <record_call_1>,
+    data=0x402fd3cc, htab_=0x8767da0) at ../../../gcc/gcc-mainline/gcc/tree-inline.c:1846
+#3  0x0855e782 in record_call_1 (tp=0x402fe330, walk_subtrees=0xbfffee7c,
+    data=0x402fd3cc) at ../../../gcc/gcc-mainline/gcc/cgraphunit.c:267
+#4  0x0855abae in walk_tree (tp=0x402fe330, func=0x855e457 <record_call_1>,
+    data=0x402fd3cc, htab_=0x8767da0) at ../../../gcc/gcc-mainline/gcc/tree-inline.c:1720
+#5  0x0855b01a in walk_tree (tp=0x402fe1b8, func=0x855e457 <record_call_1>,
+    data=0x402fd3cc, htab_=0x8767da0) at ../../../gcc/gcc-mainline/gcc/tree-inline.c:1771
+#6  0x0855b01a in walk_tree (tp=0x402fe17c, func=0x855e457 <record_call_1>,
+    data=0x402fd3cc, htab_=0x8767da0) at ../../../gcc/gcc-mainline/gcc/tree-inline.c:1771
+#7  0x0855b01a in walk_tree (tp=0xbfffefd4, func=0x855e457 <record_call_1>,
+    data=0x402fd3cc, htab_=0x8767da0) at ../../../gcc/gcc-mainline/gcc/tree-inline.c:1771
+#8  0x0855e891 in cgraph_create_edges (decl=0x402fd3cc, body=0x402fe168)
+    at ../../../gcc/gcc-mainline/gcc/cgraphunit.c:300
+#9  0x0855e904 in cgraph_analyze_function (node=0x402fd654)
+    at ../../../gcc/gcc-mainline/gcc/cgraphunit.c:314
+#10 0x0855e3fe in cgraph_finalize_function (decl=0x402fd3cc, nested=false)
+    at ../../../gcc/gcc-mainline/gcc/cgraphunit.c:209
+  */
+  tree t2 = t;
+  switch (TREE_CODE_NOCHECK (t))
     {
     case VAR_DECL:
       /* ??? Really, we should mark this decl as *potentially* referenced
@@ -248,9 +275,14 @@ record_call_1 (tree *tp, int *walk_subtr
 	}
       break;
 
+    case EXPR_WITH_FILE_LOCATION:
+      ++nocheck;
+      t2 = EXPR_WFL_NODE (t);
+      --nocheck;
     case CALL_EXPR:
+      if (TREE_CODE (t2) == CALL_EXPR)
       {
-	tree decl = get_callee_fndecl (*tp);
+	tree decl = get_callee_fndecl (t2);
 	if (decl && TREE_CODE (decl) == FUNCTION_DECL)
 	  {
 	    if (DECL_BUILT_IN (decl))
@@ -264,7 +296,7 @@ record_call_1 (tree *tp, int *walk_subtr
 	       taken by something that is not a function call.  So only
 	       walk the function parameter list, skip the other subtrees.  */
 
-	    walk_tree (&TREE_OPERAND (*tp, 1), record_call_1, data,
+	    walk_tree (&TREE_OPERAND (t2, 1), record_call_1, data,
 		       visited_nodes);
 	    *walk_subtrees = 0;
 	  }
Index: expr.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/expr.c,v
retrieving revision 1.589
diff -u -d -p -r1.589 expr.c
--- expr.c	28 Sep 2003 04:56:33 -0000	1.589
+++ expr.c	7 Oct 2003 18:10:56 -0000
@@ -4150,6 +4150,7 @@ expand_assignment (tree to, tree from, i
 {
   rtx to_rtx = 0;
   rtx result;
+  tree unwrapped_from = from;
 
   /* Don't crash if the lhs of the assignment was erroneous.  */
 
@@ -4287,8 +4288,38 @@ expand_assignment (tree to, tree from, i
      since it might be a promoted variable where the zero- or sign- extension
      needs to be done.  Handling this in the normal way is safe because no
      computation is done before the call.  */
-  if (TREE_CODE (from) == CALL_EXPR && ! aggregate_value_p (from, from)
-      && TREE_CODE (TYPE_SIZE (TREE_TYPE (from))) == INTEGER_CST
+  if (TREE_CODE_NOCHECK (from) == EXPR_WITH_FILE_LOCATION)
+  {
+/* We get here from
+#0  expand_assignment (to=0x402fd804, from=0x40266440, want_value=0)
+    at ../../../gcc/gcc-mainline/gcc/expr.c:4293
+#1  0x084fde22 in expand_decl_init (decl=0x402fd804)
+    at ../../../gcc/gcc-mainline/gcc/stmt.c:3985
+#2  0x0822d642 in emit_local_var (decl=0x402fd804)
+    at ../../../gcc/gcc-mainline/gcc/c-semantics.c:287
+#3  0x0822d9fb in genrtl_decl_stmt (t=0x402fe3fc)
+    at ../../../gcc/gcc-mainline/gcc/c-semantics.c:382
+#4  0x08230396 in expand_stmt (t=0x402fe3fc)
+    at ../../../gcc/gcc-mainline/gcc/c-semantics.c:809
+#5  0x0822fc73 in genrtl_compound_stmt (t=0x402fe3d4)
+    at ../../../gcc/gcc-mainline/gcc/c-semantics.c:723
+#6  0x082303f5 in expand_stmt (t=0x402fe3d4)
+    at ../../../gcc/gcc-mainline/gcc/c-semantics.c:829
+#7  0x0821f568 in c_expand_expr (exp=0x402fe3e8, target=0x40264210, tmode=VOIDmode,
+    modifier=0) at ../../../gcc/gcc-mainline/gcc/c-common.c:4098
+#8  0x080b4cc7 in cxx_expand_expr (exp=0x402fe3e8, target=0x40264210, tmode=VOIDmode,
+    modifier=0) at ../../../gcc/gcc-mainline/gcc/cp/expr.c:122
+#9  0x0830bc65 in expand_expr (exp=0x402fe3e8, target=0x0, tmode=VOIDmode,
+    modifier=EXPAND_NORMAL) at ../../../gcc/gcc-mainline/gcc/expr.c:9493
+#10 0x082efdea in expand_expr (exp=0x402664e0, target=0x0, tmode=VOIDmode,
+    modifier=EXPAND_NORMAL) at ../../../gcc/gcc-mainline/gcc/expr.c:6991
+*/
+    ++nocheck;
+    unwrapped_from = EXPR_WFL_NODE(from);
+    --nocheck;
+  }
+  if (TREE_CODE_NOCHECK (unwrapped_from) == CALL_EXPR && ! aggregate_value_p (unwrapped_from, unwrapped_from)
+      && TREE_CODE (TYPE_SIZE (TREE_TYPE (unwrapped_from))) == INTEGER_CST
       && ! ((TREE_CODE (to) == VAR_DECL || TREE_CODE (to) == PARM_DECL)
 	    && GET_CODE (DECL_RTL (to)) == REG))
     {
@@ -4433,7 +4464,7 @@ store_expr (tree exp, rtx target, int wa
       expand_expr (exp, const0_rtx, VOIDmode, 0);
       return NULL_RTX;
     }
-  if (TREE_CODE (exp) == COMPOUND_EXPR)
+  if (TREE_CODE_NOCHECK (exp) == COMPOUND_EXPR)
     {
       /* Perform first part of compound expression, then assign from second
 	 part.  */
@@ -4442,7 +4473,7 @@ store_expr (tree exp, rtx target, int wa
       emit_queue ();
       return store_expr (TREE_OPERAND (exp, 1), target, want_value);
     }
-  else if (TREE_CODE (exp) == COND_EXPR && GET_MODE (target) == BLKmode)
+  else if (TREE_CODE_NOCHECK (exp) == COND_EXPR && GET_MODE (target) == BLKmode)
     {
       /* For conditional expression, get safe form of the target.  Then
 	 test the condition, doing the appropriate assignment on either
@@ -6613,14 +6644,17 @@ expand_expr (tree exp, rtx target, enum 
   tree type = TREE_TYPE (exp);
   int unsignedp = TREE_UNSIGNED (type);
   enum machine_mode mode;
-  enum tree_code code = TREE_CODE (exp);
+  enum tree_code code = TREE_CODE_NOCHECK (exp);	/* That it is ok here to set code to
+                                                           EXPR_WITH_FILE_LOCATION when that
+							   wraps a CALL_EXPR was the most
+							   difficult decision. */
   optab this_optab;
   rtx subtarget, original_target;
   int ignore;
   tree context;
 
   /* Handle ERROR_MARK before anybody tries to access its type.  */
-  if (TREE_CODE (exp) == ERROR_MARK || TREE_CODE (type) == ERROR_MARK)
+  if (TREE_CODE_NOCHECK (exp) == ERROR_MARK || TREE_CODE_NOCHECK (type) == ERROR_MARK)
     {
       op0 = CONST0_RTX (tmode);
       if (op0 != 0)
Index: rtl.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/rtl.c,v
retrieving revision 1.126
diff -u -d -p -r1.126 rtl.c
--- rtl.c	30 Jul 2003 19:23:31 -0000	1.126
+++ rtl.c	7 Oct 2003 18:10:57 -0000
@@ -28,6 +28,7 @@ Software Foundation, 59 Temple Place - S
 #include "ggc.h"
 #include "errors.h"
 
+int nocheck = 0;
 \f
 /* Indexed by rtx code, gives number of operands for an rtx with that code.
    Does NOT include rtx header data (code and links).  */
Index: stmt.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/stmt.c,v
retrieving revision 1.333
diff -u -d -p -r1.333 stmt.c
--- stmt.c	28 Sep 2003 19:09:49 -0000	1.333
+++ stmt.c	7 Oct 2003 18:11:02 -0000
@@ -3979,7 +3979,7 @@ expand_decl_init (tree decl)
 			   0);
       emit_queue ();
     }
-  else if (DECL_INITIAL (decl) && TREE_CODE (DECL_INITIAL (decl)) != TREE_LIST)
+  else if (DECL_INITIAL (decl) && TREE_CODE_NOCHECK (DECL_INITIAL (decl)) != TREE_LIST)
     {
       emit_line_note (DECL_SOURCE_LOCATION (decl));
       expand_assignment (decl, DECL_INITIAL (decl), 0);
Index: tree-inline.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/tree-inline.c,v
retrieving revision 1.81
diff -u -d -p -r1.81 tree-inline.c
--- tree-inline.c	23 Sep 2003 20:02:48 -0000	1.81
+++ tree-inline.c	7 Oct 2003 18:11:04 -0000
@@ -40,7 +40,6 @@ Boston, MA 02111-1307, USA.  */
 #include "cgraph.h"
 #include "intl.h"
 
-
 /* This should be eventually be generalized to other languages, but
    this would require a shared function-as-trees infrastructure.  */
 #ifndef INLINER_FOR_JAVA
@@ -1227,7 +1226,7 @@ expand_call_inline (tree *tp, int *walk_
 
   /* Recurse, but letting recursive invocations know that we are
      inside the body of a TARGET_EXPR.  */
-  if (TREE_CODE (*tp) == TARGET_EXPR)
+  if (TREE_CODE_NOCHECK (*tp) == TARGET_EXPR)
     {
 #ifndef INLINER_FOR_JAVA
       int i, len = first_rtl_op (TARGET_EXPR);
@@ -1253,7 +1252,7 @@ expand_call_inline (tree *tp, int *walk_
       abort ();
 #endif /* INLINER_FOR_JAVA */
     }
-  else if (TREE_CODE (t) == EXPR_WITH_FILE_LOCATION)
+  else if (TREE_CODE_NOCHECK (t) == EXPR_WITH_FILE_LOCATION)
     {
       /* We're walking the subtree directly.  */
       *walk_subtrees = 0;
@@ -1724,7 +1723,10 @@ walk_tree (tree *tp, walk_tree_fn func, 
   if (result)
     return result;
 
-  code = TREE_CODE (*tp);
+  code = TREE_CODE_NOCHECK (*tp);
+  /* The _NOCHECK is only ok if: */
+  my_friendly_assert ( STATEMENT_CODE_P (CALL_EXPR) == STATEMENT_CODE_P (EXPR_WITH_FILE_LOCATION), whatisthis );
+  my_friendly_assert ( IS_EXPR_CODE_CLASS (TREE_CODE_CLASS (CALL_EXPR)) == IS_EXPR_CODE_CLASS (TREE_CODE_CLASS (EXPR_WITH_FILE_LOCATION)), foobar );
 
 #ifndef INLINER_FOR_JAVA
   /* Even if we didn't, FUNC may have decided that there was nothing
@@ -1933,7 +1935,10 @@ walk_tree_without_duplicates (tree *tp, 
 tree
 copy_tree_r (tree *tp, int *walk_subtrees, void *data ATTRIBUTE_UNUSED)
 {
-  enum tree_code code = TREE_CODE (*tp);
+  enum tree_code code = TREE_CODE_NOCHECK (*tp);
+  /* The _NOCHECK is ok when: */
+  my_friendly_assert( IS_EXPR_CODE_CLASS (TREE_CODE_CLASS (CALL_EXPR)) ==
+                      IS_EXPR_CODE_CLASS (TREE_CODE_CLASS (EXPR_WITH_FILE_LOCATION)), 0);
 
   /* We make copies of most nodes.  */
   if (IS_EXPR_CODE_CLASS (TREE_CODE_CLASS (code))
@@ -1959,7 +1964,7 @@ copy_tree_r (tree *tp, int *walk_subtree
 
       /* For now, we don't update BLOCKs when we make copies.  So, we
 	 have to nullify all scope-statements.  */
-      if (TREE_CODE (*tp) == SCOPE_STMT)
+      if (TREE_CODE_NOCHECK (*tp) == SCOPE_STMT)
 	SCOPE_STMT_BLOCK (*tp) = NULL_TREE;
 #else /* INLINER_FOR_JAVA */
 	  || (*lang_hooks.tree_inlining.tree_chain_matters_p) (*tp))
Index: tree.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/tree.c,v
retrieving revision 1.330
diff -u -d -p -r1.330 tree.c
--- tree.c	22 Sep 2003 05:09:12 -0000	1.330
+++ tree.c	7 Oct 2003 18:11:05 -0000
@@ -139,7 +139,7 @@ decl_assembler_name (tree decl)
 size_t
 tree_size (tree node)
 {
-  enum tree_code code = TREE_CODE (node);
+  enum tree_code code = TREE_CODE_NOCHECK (node);
 
   switch (TREE_CODE_CLASS (code))
     {
@@ -344,7 +344,7 @@ tree
 copy_node (tree node)
 {
   tree t;
-  enum tree_code code = TREE_CODE (node);
+  enum tree_code code = TREE_CODE_NOCHECK (node);
   size_t length;
 
   length = tree_size (node);
Index: tree.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/tree.h,v
retrieving revision 1.447
diff -u -d -p -r1.447 tree.h
--- tree.h	28 Sep 2003 19:09:49 -0000	1.447
+++ tree.h	7 Oct 2003 18:11:08 -0000
@@ -267,7 +267,20 @@ struct tree_common GTY(())
 
 /* The tree-code says what kind of node it is.
    Codes are defined in tree.def.  */
+extern int nocheck;
+#if 0
 #define TREE_CODE(NODE) ((enum tree_code) (NODE)->common.code)
+#else
+/* TEST CODE - REMOVE */
+#define TREE_CODE(NODE) __extension__					\
+({  enum tree_code code = ((enum tree_code) (NODE)->common.code);	\
+    if (!nocheck && code == EXPR_WITH_FILE_LOCATION &&			\
+        (TREE_CODE_NOCHECK(((NODE)->exp.operands[0])) == CALL_EXPR))	\
+      printf("TREE_CODE: %s:%d\n", __FILE__, __LINE__);			\
+    code; })
+#define TREE_CODE_NOCHECK(NODE) ((enum tree_code) (NODE)->common.code)
+#endif
+
 #define TREE_SET_CODE(NODE, VALUE) \
 ((NODE)->common.code = (ENUM_BITFIELD (tree_code)) (VALUE))
 
[...deleted...]
Index: cp/call.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cp/call.c,v
retrieving revision 1.437
diff -u -d -p -r1.437 call.c
--- cp/call.c	27 Sep 2003 16:44:04 -0000	1.437
+++ cp/call.c	7 Oct 2003 18:11:11 -0000
@@ -4293,7 +4293,7 @@ convert_default_arg (tree type, tree arg
 {
   /* If the ARG is an unparsed default argument expression, the
      conversion cannot be performed.  */
-  if (TREE_CODE (arg) == DEFAULT_ARG)
+  if (TREE_CODE_NOCHECK (arg) == DEFAULT_ARG)
     {
       error ("the default argument for parameter %d of `%D' has "
 	     "not yet been parsed",
@@ -4306,7 +4306,7 @@ convert_default_arg (tree type, tree arg
 
   arg = break_out_target_exprs (arg);
 
-  if (TREE_CODE (arg) == CONSTRUCTOR)
+  if (TREE_CODE_NOCHECK (arg) == CONSTRUCTOR)
     {
       arg = digest_init (type, arg, 0);
       arg = convert_for_initialization (0, type, arg, LOOKUP_NORMAL,
@@ -4642,7 +4642,18 @@ build_cxx_call(tree fn, tree args, tree 
 
   if (IS_AGGR_TYPE (TREE_TYPE (fn)))
     fn = build_cplus_new (TREE_TYPE (fn), fn);
-  return convert_from_reference (fn);
+
+  fn = convert_from_reference (fn);
+
+  /* Wrap every call in a wfl in order to garantee that the correct
+     locus debug information is emitted.  This exception is made for
+     calls because they turn up in debugger back traces.  */
+  ++nocheck;
+  fn = build_expr_wfl (fn, input_location.file, input_location.line, 0);
+  EXPR_WFL_EMIT_LINE_NOTE (fn) = 1;
+  --nocheck;
+
+  return fn;
 }
 
 static GTY(()) tree java_iface_lookup_fn;
Index: cp/decl.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cp/decl.c,v
retrieving revision 1.1138
diff -u -d -p -r1.1138 decl.c
--- cp/decl.c	30 Sep 2003 22:58:39 -0000	1.1138
+++ cp/decl.c	7 Oct 2003 18:11:19 -0000
@@ -8764,7 +8764,7 @@ grokfndecl (tree ctype, 
 
   for (t = TYPE_ARG_TYPES (TREE_TYPE (decl)); t; t = TREE_CHAIN (t))
     if (TREE_PURPOSE (t)
-	&& TREE_CODE (TREE_PURPOSE (t)) == DEFAULT_ARG)
+	&& TREE_CODE_NOCHECK (TREE_PURPOSE (t)) == DEFAULT_ARG)
       {
 	has_default_arg = 1;
 	break;
@@ -11633,13 +11633,13 @@ require_complete_types_for_parms (tree p
 int
 local_variable_p (tree t)
 {
-  if ((TREE_CODE (t) == VAR_DECL
+  if ((TREE_CODE_NOCHECK (t) == VAR_DECL
        /* A VAR_DECL with a context that is a _TYPE is a static data
 	  member.  */
        && !TYPE_P (CP_DECL_CONTEXT (t))
        /* Any other non-local variable must be at namespace scope.  */
        && !DECL_NAMESPACE_SCOPE_P (t))
-      || (TREE_CODE (t) == PARM_DECL))
+      || (TREE_CODE_NOCHECK (t) == PARM_DECL))
     return 1;
 
   return 0;
@@ -11680,11 +11680,13 @@ check_default_argument (tree decl, tree 
   tree var;
   tree decl_type;
 
-  if (TREE_CODE (arg) == DEFAULT_ARG)
+  if (TREE_CODE_NOCHECK (arg) == DEFAULT_ARG)
+  {
     /* We get a DEFAULT_ARG when looking at an in-class declaration
        with a default argument.  Ignore the argument for now; we'll
        deal with it after the class is complete.  */
     return arg;
+  }
 
   if (processing_template_decl || uses_template_parms (arg))
     /* We don't do anything checking until instantiation-time.  Note
Index: cp/init.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cp/init.c,v
retrieving revision 1.344
diff -u -d -p -r1.344 init.c
--- cp/init.c	28 Sep 2003 04:37:40 -0000	1.344
+++ cp/init.c	7 Oct 2003 18:11:23 -0000
@@ -1591,7 +1591,7 @@ decl_constant_value (tree decl)
      as an lvalue or as an rvalue.  If it is an lvalue, it's not safe
      to replace the second and third operands with their
      initializers.  So, we do that here.  */
-  if (TREE_CODE (decl) == COND_EXPR)
+  if (TREE_CODE_NOCHECK (decl) == COND_EXPR)
     {
       tree d1;
       tree d2;
Index: cp/optimize.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cp/optimize.c,v
retrieving revision 1.101
diff -u -d -p -r1.101 optimize.c
--- cp/optimize.c	22 Sep 2003 05:09:23 -0000	1.101
+++ cp/optimize.c	7 Oct 2003 18:11:23 -0000
@@ -70,7 +70,7 @@ calls_setjmp_r (tree *tp, int *walk_subt
                 void *data ATTRIBUTE_UNUSED)
 {
   /* We're only interested in FUNCTION_DECLS.  */
-  if (TREE_CODE (*tp) != FUNCTION_DECL)
+  if (TREE_CODE_NOCHECK (*tp) != FUNCTION_DECL)
     return NULL_TREE;
 
   return setjmp_call_p (*tp) ? *tp : NULL_TREE;
Index: cp/pt.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cp/pt.c,v
retrieving revision 1.784
diff -u -d -p -r1.784 pt.c
--- cp/pt.c	23 Sep 2003 15:42:21 -0000	1.784
+++ cp/pt.c	7 Oct 2003 18:11:30 -0000
@@ -4602,7 +4602,12 @@ for_each_template_parm (tree t, tree_fn_
 int
 uses_template_parms (tree t)
 {
-  return for_each_template_parm (t, 0, 0, NULL);
+  ++nocheck;	/* Because uses_template_parms should only be called with types, never with a call_expr */
+  		/* Now it IS called with a call_expr, but in that case this function threats 't' the
+		   same as when it is a wfl anyway: as a not-type */
+  int result = for_each_template_parm (t, 0, 0, NULL);
+  --nocheck;
+  return result;
 }
 
 static int tinst_depth;
Index: cp/semantics.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cp/semantics.c,v
retrieving revision 1.368
diff -u -d -p -r1.368 semantics.c
--- cp/semantics.c	23 Sep 2003 15:42:21 -0000	1.368
+++ cp/semantics.c	7 Oct 2003 18:11:32 -0000
@@ -2716,7 +2716,7 @@ simplify_aggr_init_exprs_r (tree* tp, 
       return NULL_TREE;
     }
   /* Only AGGR_INIT_EXPRs are interesting.  */
-  else if (TREE_CODE (*tp) != AGGR_INIT_EXPR)
+  else if (TREE_CODE_NOCHECK (*tp) != AGGR_INIT_EXPR)
     return NULL_TREE;
 
   simplify_aggr_init_expr (tp);
Index: cp/tree.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cp/tree.c,v
retrieving revision 1.348
diff -u -d -p -r1.348 tree.c
--- cp/tree.c	22 Sep 2003 05:09:23 -0000	1.348
+++ cp/tree.c	7 Oct 2003 18:11:32 -0000
@@ -71,7 +71,37 @@ lvalue_p_1 (tree ref, 
   if (ref == current_class_ptr)
     return clk_none;
 
-  switch (TREE_CODE (ref))
+/* This is a definite problem case: we get here with the new WFL,
+   containing the CALL_EXPR - but the switch does not take WFL's
+   into account!  We get here from:
+#0  0x082477b8 in lvalue_p_1 (ref=0x40266380, treat_class_rvalues_as_lvalues=1)
+    at ../../../gcc/gcc-mainline/gcc/cp/tree.c:74
+#1  0x082489c0 in lvalue_p (ref=0x40266380)
+    at ../../../gcc/gcc-mainline/gcc/cp/tree.c:209
+#2  0x0804ce18 in standard_conversion (to=0x4026a57c, from=0x4026a57c, expr=0x40266380)
+    at ../../../gcc/gcc-mainline/gcc/cp/call.c:619
+#3  0x08050cdf in implicit_conversion (to=0x4026a57c, from=0x4026a57c, expr=0x40266380,
+    flags=3) at ../../../gcc/gcc-mainline/gcc/cp/call.c:1220
+#4  0x080516c6 in add_function_candidate (candidates=0xbfffea54, fn=0x402f4870,
+    ctype=0x0, arglist=0x402edb7c, access_path=0x0, conversion_path=0x0, flags=3)
+    at ../../../gcc/gcc-mainline/gcc/cp/call.c:1373
+#5  0x0805e210 in add_candidates (fns=0x402f4870, args=0x402edb7c, explicit_targs=0x0,
+    template_only=false, conversion_path=0x0, access_path=0x0, flags=3,
+    candidates=0xbfffea54) at ../../../gcc/gcc-mainline/gcc/cp/call.c:3461
+#6  0x08059990 in perform_overload_resolution (fn=0x402f4870, args=0x402edb7c,
+    candidates=0xbfffea54, any_viable_p=0xbfffea4f)
+    at ../../../gcc/gcc-mainline/gcc/cp/call.c:2705
+#7  0x08059a2c in build_new_function_call (fn=0x402f4870, args=0x402edb7c)
+    at ../../../gcc/gcc-mainline/gcc/cp/call.c:2732
+#8  0x082407be in finish_call_expr (fn=0x402f4870, args=0x402edb7c,
+    disallow_virtual=false, koenig_p=true)
+    at ../../../gcc/gcc-mainline/gcc/cp/semantics.c:1693
+#9  0x081b5c7f in cp_parser_postfix_expression (parser=0x402f9140, address_p=false)
+    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:3588
+#10 0x081b6896 in cp_parser_unary_expression (parser=0x402f9140, address_p=false)
+    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:4122
+*/
+  switch (TREE_CODE_NOCHECK (ref))
     {
       /* preincrements and predecrements are valid lvals, provided
 	 what they refer to are valid lvals.  */
@@ -151,6 +181,14 @@ lvalue_p_1 (tree ref, 
     case TARGET_EXPR:
       return treat_class_rvalues_as_lvalues ? clk_class : clk_none;
 
+    case EXPR_WITH_FILE_LOCATION:
+      ++nocheck;
+      if (TREE_CODE (EXPR_WFL_NODE (ref)) != CALL_EXPR)
+      {
+	--nocheck;
+        break;
+      }
+      --nocheck;
     case CALL_EXPR:
     case VA_ARG_EXPR:
       /* Any class-valued call would be wrapped in a TARGET_EXPR.  */
@@ -1180,7 +1218,7 @@ bot_manip (tree* tp, int* walk_subtrees,
       *walk_subtrees = 0;
       return NULL_TREE;
     }
-  if (TREE_CODE (t) == TARGET_EXPR)
+  if (TREE_CODE_NOCHECK (t) == TARGET_EXPR)
     {
       tree u;
 
@@ -1209,8 +1247,44 @@ bot_manip (tree* tp, int* walk_subtrees,
       *walk_subtrees = 0;
       return NULL_TREE;
     }
-  else if (TREE_CODE (t) == CALL_EXPR)
+/* Another definite problem case: we get here with a EXPR_WITH_FILE_LOCATION
+   that wraps a CALL_EXPR, but do not test for EXPR_WITH_FILE_LOCATION.
+#0  0x081ca56a in bot_manip (tp=0xbfffe970, walk_subtrees=0xbfffe93c, data=0x8775ce0)
+    at ../../../gcc/gcc-mainline/gcc/cp/tree.c:1246
+#1  0x0856936a in walk_tree (tp=0xbfffe970, func=0x81c9e1d <bot_manip>, data=0x8775ce0,
+    htab_=0x0) at ../../../gcc/gcc-mainline/gcc/tree-inline.c:1721
+#2  0x081ca7bb in break_out_target_exprs (t=0x40266360)
+    at ../../../gcc/gcc-mainline/gcc/cp/tree.c:1290
+#3  0x0805dff2 in convert_default_arg (type=0x4026a57c, arg=0x40266360, fn=0x402f4ec4,
+    parmnum=1) at ../../../gcc/gcc-mainline/gcc/cp/call.c:4307
+#4  0x0805f120 in build_over_call (cand=0x402ff0a0, flags=3)
+    at ../../../gcc/gcc-mainline/gcc/cp/call.c:4477
+#5  0x08056ccd in build_new_function_call (fn=0x402f4ec4, args=0x402fe1f4)
+    at ../../../gcc/gcc-mainline/gcc/cp/call.c:2751
+#6  0x081beefc in finish_call_expr (fn=0x402f4ec4, args=0x402fe1f4,
+    disallow_virtual=false, koenig_p=true)
+    at ../../../gcc/gcc-mainline/gcc/cp/semantics.c:1693
+#7  0x08154531 in cp_parser_postfix_expression (parser=0x402f9140, address_p=false)
+    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:3588
+#8  0x081550e8 in cp_parser_unary_expression (parser=0x402f9140, address_p=false)
+    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:4122
+#9  0x08155832 in cp_parser_cast_expression (parser=0x402f9140, address_p=false)
+    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:4546
+#10 0x08163686 in cp_parser_simple_cast_expression (parser=0x402f9140)
+    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:13791
+*/
+  else if (TREE_CODE_NOCHECK (t) == CALL_EXPR)
     mark_used (TREE_OPERAND (TREE_OPERAND (t, 0), 0));
+  else if (TREE_CODE_NOCHECK (t) == EXPR_WITH_FILE_LOCATION)
+  {
+    /* This is just a hack to get past this point; unwrap the WFL. */
+    tree exp;
+    ++nocheck;
+    exp = EXPR_WFL_NODE(t);
+    --nocheck;
+    if (TREE_CODE_NOCHECK (exp) == CALL_EXPR)
+      mark_used (TREE_OPERAND (TREE_OPERAND (exp, 0), 0));
+  }
 
   /* Make a copy of this node.  */
   return copy_tree_r (tp, walk_subtrees, NULL);
@@ -1227,7 +1301,7 @@ bot_replace (tree* t, 
 {
   splay_tree target_remap = ((splay_tree) data);
 
-  if (TREE_CODE (*t) == VAR_DECL)
+  if (TREE_CODE_NOCHECK (*t) == VAR_DECL)
     {
       splay_tree_node n = splay_tree_lookup (target_remap,
 					     (splay_tree_key) *t);
@@ -1632,7 +1706,7 @@ tree
 lvalue_type (tree arg)
 {
   tree type = TREE_TYPE (arg);
-  if (TREE_CODE (arg) == OVERLOAD)
+  if (TREE_CODE_NOCHECK (arg) == OVERLOAD)
     type = unknown_type_node;
   return type;
 }
@@ -2086,7 +2160,7 @@ cp_add_pending_fn_decls (void* fns_p, tr
 int
 cp_is_overload_p (tree t)
 {
-  return TREE_CODE (t) == OVERLOAD;
+  return TREE_CODE_NOCHECK (t) == OVERLOAD;
 }
 
 /* Determine whether VAR is a declaration of an automatic variable in
Index: cp/typeck.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cp/typeck.c,v
retrieving revision 1.505
diff -u -d -p -r1.505 typeck.c
--- cp/typeck.c	28 Sep 2003 19:09:53 -0000	1.505
+++ cp/typeck.c	7 Oct 2003 18:11:37 -0000
@@ -163,8 +163,8 @@ complete_type_or_diagnostic (tree type, 
 int
 type_unknown_p (tree exp)
 {
-  return (TREE_CODE (exp) == OVERLOAD
-          || TREE_CODE (exp) == TREE_LIST
+  return (TREE_CODE_NOCHECK (exp) == OVERLOAD
+          || TREE_CODE_NOCHECK (exp) == TREE_LIST
 	  || TREE_TYPE (exp) == unknown_type_node);
 }
 
@@ -5573,7 +5573,7 @@ convert_for_assignment (tree type, tree 
   register enum tree_code coder;
 
   /* Strip NON_LVALUE_EXPRs since we aren't using as an lvalue.  */
-  if (TREE_CODE (rhs) == NON_LVALUE_EXPR)
+  if (TREE_CODE_NOCHECK (rhs) == NON_LVALUE_EXPR)
     rhs = TREE_OPERAND (rhs, 0);
 
   rhstype = TREE_TYPE (rhs);
@@ -5586,7 +5586,7 @@ convert_for_assignment (tree type, tree 
 
   if (rhs == error_mark_node || rhstype == error_mark_node)
     return error_mark_node;
-  if (TREE_CODE (rhs) == TREE_LIST && TREE_VALUE (rhs) == error_mark_node)
+  if (TREE_CODE_NOCHECK (rhs) == TREE_LIST && TREE_VALUE (rhs) == error_mark_node)
     return error_mark_node;
 
   rhs = dubious_conversion_warnings (type, rhs, errtype, fndecl, parmnum);
@@ -5599,7 +5599,7 @@ convert_for_assignment (tree type, tree 
     }
 
   /* Simplify the RHS if possible.  */
-  if (TREE_CODE (rhs) == CONST_DECL)
+  if (TREE_CODE_NOCHECK (rhs) == CONST_DECL)
     rhs = DECL_INITIAL (rhs);
   
   /* We do not use decl_constant_value here because of this case:
@@ -5674,13 +5674,13 @@ convert_for_initialization (tree exp, tr
 
   /* build_c_cast puts on a NOP_EXPR to make the result not an lvalue.
      Strip such NOP_EXPRs, since RHS is used in non-lvalue context.  */
-  if (TREE_CODE (rhs) == NOP_EXPR
+  if (TREE_CODE_NOCHECK (rhs) == NOP_EXPR
       && TREE_TYPE (rhs) == TREE_TYPE (TREE_OPERAND (rhs, 0))
       && codel != REFERENCE_TYPE)
     rhs = TREE_OPERAND (rhs, 0);
 
   if (rhs == error_mark_node
-      || (TREE_CODE (rhs) == TREE_LIST && TREE_VALUE (rhs) == error_mark_node))
+      || (TREE_CODE_NOCHECK (rhs) == TREE_LIST && TREE_VALUE (rhs) == error_mark_node))
     return error_mark_node;
 
   if (TREE_CODE (TREE_TYPE (rhs)) == REFERENCE_TYPE)



While the above patch is enough to garantee correct compilation
(despite the wrapping of CALL_EXPR inside a WFL) for the simple
test case, it is NOT enough in general.  When using this compiler
to compile a big C++ source file, the following additional
locations were printed that need manual checking before we can
be sure that the wrapping doesn't do any harm (see patch above
for tree.h so see where TREE_CODE: is printed):

TREE_CODE: ../../../gcc/gcc-mainline/gcc/builtins.c:5331
TREE_CODE: ../../../gcc/gcc-mainline/gcc/c-common.c:1234
TREE_CODE: ../../../gcc/gcc-mainline/gcc/c-common.c:1235
TREE_CODE: ../../../gcc/gcc-mainline/gcc/c-common.c:1243
TREE_CODE: ../../../gcc/gcc-mainline/gcc/c-common.c:1244
TREE_CODE: ../../../gcc/gcc-mainline/gcc/c-common.c:1252
TREE_CODE: ../../../gcc/gcc-mainline/gcc/c-common.c:2254
TREE_CODE: ../../../gcc/gcc-mainline/gcc/c-common.c:2602
TREE_CODE: ../../../gcc/gcc-mainline/gcc/c-common.c:2627
TREE_CODE: ../../../gcc/gcc-mainline/gcc/convert.c:102
TREE_CODE: ../../../gcc/gcc-mainline/gcc/convert.c:204
TREE_CODE: ../../../gcc/gcc-mainline/gcc/convert.c:287
TREE_CODE: ../../../gcc/gcc-mainline/gcc/convert.c:85
TREE_CODE: ../../../gcc/gcc-mainline/gcc/cp/cvt.c:702
TREE_CODE: ../../../gcc/gcc-mainline/gcc/cp/cvt.c:704
TREE_CODE: ../../../gcc/gcc-mainline/gcc/cp/cvt.c:808
TREE_CODE: ../../../gcc/gcc-mainline/gcc/cp/cvt.c:890
TREE_CODE: ../../../gcc/gcc-mainline/gcc/cp/decl.c:14367
TREE_CODE: ../../../gcc/gcc-mainline/gcc/cp/decl.c:7548
TREE_CODE: ../../../gcc/gcc-mainline/gcc/cp/decl.c:7573
TREE_CODE: ../../../gcc/gcc-mainline/gcc/cp/decl.c:7613
TREE_CODE: ../../../gcc/gcc-mainline/gcc/cp/decl.c:7875
TREE_CODE: ../../../gcc/gcc-mainline/gcc/cp/semantics.c:1195
TREE_CODE: ../../../gcc/gcc-mainline/gcc/cp/semantics.c:1199
TREE_CODE: ../../../gcc/gcc-mainline/gcc/cp/tree.c:349
TREE_CODE: ../../../gcc/gcc-mainline/gcc/cp/tree.c:882
TREE_CODE: ../../../gcc/gcc-mainline/gcc/cp/tree.c:884
TREE_CODE: ../../../gcc/gcc-mainline/gcc/cp/tree.c:886
TREE_CODE: ../../../gcc/gcc-mainline/gcc/cp/tree.c:887
TREE_CODE: ../../../gcc/gcc-mainline/gcc/cp/tree.c:888
TREE_CODE: ../../../gcc/gcc-mainline/gcc/cp/tree.c:889
TREE_CODE: ../../../gcc/gcc-mainline/gcc/cp/tree.c:896
TREE_CODE: ../../../gcc/gcc-mainline/gcc/cp/tree.c:898
TREE_CODE: ../../../gcc/gcc-mainline/gcc/cp/tree.c:901
TREE_CODE: ../../../gcc/gcc-mainline/gcc/cp/tree.c:902
TREE_CODE: ../../../gcc/gcc-mainline/gcc/cp/tree.c:903
TREE_CODE: ../../../gcc/gcc-mainline/gcc/cp/typeck2.c:329
TREE_CODE: ../../../gcc/gcc-mainline/gcc/cp/typeck2.c:353
TREE_CODE: ../../../gcc/gcc-mainline/gcc/cp/typeck2.c:400
TREE_CODE: ../../../gcc/gcc-mainline/gcc/cp/typeck2.c:404
TREE_CODE: ../../../gcc/gcc-mainline/gcc/cp/typeck2.c:416
TREE_CODE: ../../../gcc/gcc-mainline/gcc/cp/typeck2.c:419
TREE_CODE: ../../../gcc/gcc-mainline/gcc/cp/typeck2.c:504
TREE_CODE: ../../../gcc/gcc-mainline/gcc/cp/typeck.c:1290
TREE_CODE: ../../../gcc/gcc-mainline/gcc/cp/typeck.c:1426
TREE_CODE: ../../../gcc/gcc-mainline/gcc/cp/typeck.c:2828
TREE_CODE: ../../../gcc/gcc-mainline/gcc/cp/typeck.c:3152
TREE_CODE: ../../../gcc/gcc-mainline/gcc/cp/typeck.c:3294
TREE_CODE: ../../../gcc/gcc-mainline/gcc/cp/typeck.c:3295
TREE_CODE: ../../../gcc/gcc-mainline/gcc/cp/typeck.c:4406
TREE_CODE: ../../../gcc/gcc-mainline/gcc/cp/typeck.c:4758
TREE_CODE: ../../../gcc/gcc-mainline/gcc/cp/typeck.c:4866
TREE_CODE: ../../../gcc/gcc-mainline/gcc/cp/typeck.c:5182
TREE_CODE: ../../../gcc/gcc-mainline/gcc/cp/typeck.c:5190
TREE_CODE: ../../../gcc/gcc-mainline/gcc/cp/typeck.c:5543
TREE_CODE: ../../../gcc/gcc-mainline/gcc/cp/typeck.c:5810
TREE_CODE: ../../../gcc/gcc-mainline/gcc/cp/typeck.c:5812
TREE_CODE: ../../../gcc/gcc-mainline/gcc/cp/typeck.c:5813
TREE_CODE: ../../../gcc/gcc-mainline/gcc/cp/typeck.c:5814
TREE_CODE: ../../../gcc/gcc-mainline/gcc/cp/typeck.c:5820
TREE_CODE: ../../../gcc/gcc-mainline/gcc/cp/typeck.c:5987
TREE_CODE: ../../../gcc/gcc-mainline/gcc/cp/typeck.c:6028
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:1862
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:1941
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:2005
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:2131
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:2336
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:3000
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:3229
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:4152
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:4904
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:4990
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:4992
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:4995
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:4997
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:5000
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:5002
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:5066
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:5071
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:5072
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:5100
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:5105
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:5106
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:5147
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:5151
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:5169
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:5172
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:5214
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:5220
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:5224
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:5230
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:5236
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:5237
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:5247
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:5250
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:5251
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:5286
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:5287
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:5364
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:5387
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:5621
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:5632
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:5647
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:5679
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:5815
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:6065
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:6069
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:6770
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:6794
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:6910
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:6921
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:7007
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:7077
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:7143
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:7144
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:7167
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:7287
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:7288
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:7289
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:7299
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:7309
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:7317
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:7327
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:7328
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:7329
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:7355
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:7389
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:7390
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:7391
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:7392
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:7406
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:7413
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:7428
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:7445
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:7529
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:7618
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:7620
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:7666
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:7713
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:7737
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:7774
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:7785
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:7948
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:976
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:978
TREE_CODE: ../../../gcc/gcc-mainline/gcc/fold-const.c:984
TREE_CODE: ../../../gcc/gcc-mainline/gcc/tree.c:1474
TREE_CODE: ../../../gcc/gcc-mainline/gcc/tree.c:1886
TREE_CODE: ../../../gcc/gcc-mainline/gcc/tree.c:1913
TREE_CODE: ../../../gcc/gcc-mainline/gcc/tree.c:1916
TREE_CODE: ../../../gcc/gcc-mainline/gcc/tree.c:1920
TREE_CODE: ../../../gcc/gcc-mainline/gcc/tree.c:4129
TREE_CODE: ../../../gcc/gcc-mainline/gcc/tree.c:4169
TREE_CODE: ../../../gcc/gcc-mainline/gcc/tree.c:588
TREE_CODE: ../../../gcc/gcc-mainline/gcc/tree.c:592
TREE_CODE: ../../../gcc/gcc-mainline/gcc/tree.c:605
TREE_CODE: ../../../gcc/gcc-mainline/gcc/tree.c:609
TREE_CODE: ../../../gcc/gcc-mainline/gcc/tree.c:812
TREE_CODE: ../../../gcc/gcc-mainline/gcc/tree.c:815
TREE_CODE: ../../../gcc/gcc-mainline/gcc/tree.c:827
TREE_CODE: ../../../gcc/gcc-mainline/gcc/tree.c:830
TREE_CODE: ../../../gcc/gcc-mainline/gcc/tree.c:857
TREE_CODE: ../../../gcc/gcc-mainline/gcc/tree.c:860
TREE_CODE: ../../../gcc/gcc-mainline/gcc/tree-inline.c:428
TREE_CODE: ../../../gcc/gcc-mainline/gcc/tree-inline.c:492
TREE_CODE: ../../../gcc/gcc-mainline/gcc/tree-inline.c:495
TREE_CODE: ../../../gcc/gcc-mainline/gcc/tree-inline.c:501
TREE_CODE: ../../../gcc/gcc-mainline/gcc/tree-inline.c:531
TREE_CODE: ../../../gcc/gcc-mainline/gcc/tree-inline.c:554
TREE_CODE: ../../../gcc/gcc-mainline/gcc/tree-inline.c:580
TREE_CODE: ../../../gcc/gcc-mainline/gcc/tree-inline.c:890
TREE_CODE: gtype-cp.h:218
TREE_CODE: gtype-cp.h:241

So, at least one hunk would/should be added to the diff
above for each line printed here.

... that, and the convincing fact that despite all the care
that I took the compiler DID crash (just to prove how dangerous
this is?), make be ask you to reconsider and let me solve adding
a location_t to CALL_EXPR-essions differently.  Not by means of WFL.

What is your opinion?  Shall we go for adding the location_t
to tree_exp, shall I add it after the normal tree_exp struct
for CALL_EXPR only (less memory usage and still totally safe),
or do you have other ideas?

-- 
Carlo Wood <carlo@alinoe.com>

Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only.

[Carlo Wood]

On Tue, Oct 07, 2003 at 08:32:31PM +0200, Carlo Wood wrote:
> While the above patch is enough to garantee correct compilation
> (despite the wrapping of CALL_EXPR inside a WFL) for the simple
> test case, it is NOT enough in general.  When using this compiler
> to compile a big C++ source file, the following additional
> locations were printed that need manual checking before we can
> be sure that the wrapping doesn't do any harm (see patch above
> for tree.h so see where TREE_CODE: is printed):
> 
> TREE_CODE: ../../../gcc/gcc-mainline/gcc/builtins.c:5331
> TREE_CODE: ../../../gcc/gcc-mainline/gcc/c-common.c:1234
[..snip..]

Because those file names do not say much - except that
there are still a lot to check - here is a list of the
actual source lines plus a little context.

It proves that expressions with file locations get all
over the code and will need special handling at many
places, although not at all places listed here of course.


gtype-cp.h:217                 gt_ggc_m_9tree_node ((*x).generic.exp.common.type);
gtype-cp.h:218:===>              switch (TREE_CODE ((tree) &(*x)))
gtype-cp.h:219                   {
--
gtype-cp.h:240                       size_t i1;
gtype-cp.h:241:===>                    for (i1 = 0; i1 < (size_t)(TREE_CODE_LENGTH (TREE_CODE ((tree) &(*x)))); i1++) {
gtype-cp.h:242                         gt_ggc_m_9tree_node ((*x).generic.exp.operands[i1]);
--
builtins.c:5330:
builtins.c:5331:===>  if (TREE_CODE (t) != CALL_EXPR
builtins.c:5332         || TREE_CODE (TREE_OPERAND (t, 0)) != ADDR_EXPR)
--
c-common.c:1233
c-common.c:1234:===>  if ((TREE_CODE (value) == INTEGER_CST
c-common.c:1235:===>       || (TREE_CODE (value) == COMPLEX_CST
c-common.c:1236       && TREE_CODE (TREE_REALPART (value)) == INTEGER_CST))
--
c-common.c:1242       }
c-common.c:1243:===>  else if ((TREE_CODE (value) == REAL_CST
c-common.c:1244:===>        || (TREE_CODE (value) == COMPLEX_CST
c-common.c:1245         && TREE_CODE (TREE_REALPART (value)) == REAL_CST))
--
c-common.c:1251       }
c-common.c:1252:===>  else if (TREE_CODE (value) == VECTOR_CST && TREE_OVERFLOW (value))
c-common.c:1253       {
--
c-common.c:2253     if (!real1 && !real2
c-common.c:2254:===>      && TREE_CODE (primop1) == INTEGER_CST
c-common.c:2255         && TYPE_PRECISION (TREE_TYPE (primop0)) < TYPE_PRECISION (*restype_ptr))
--
c-common.c:2601
c-common.c:2602:===>  if (TREE_CODE (expr) == ERROR_MARK)
c-common.c:2603       return expr;
--
c-common.c:2626:
c-common.c:2627:===>  switch (TREE_CODE (expr))
c-common.c:2628       {
--
convert.c:84         but 2.0 is double constant.  */
convert.c:85:===>  if (TREE_CODE (exp) == REAL_CST)
convert.c:86       {
--
convert.c:101:
convert.c:102:===>  if (TREE_CODE (exp) != NOP_EXPR)
convert.c:103       return exp;
--
convert.c:203     if (itype != type && FLOAT_TYPE_P (type))
convert.c:204:===>    switch (TREE_CODE (expr))
convert.c:205         {
--
convert.c:286
convert.c:287:===>  enum tree_code ex_form = TREE_CODE (expr);
convert.c:288     tree intype = TREE_TYPE (expr);
--
cp/cvt.c:701                about this since it is so bad.  */
cp/cvt.c:702:===>         if (TREE_CODE (expr) == FUNCTION_DECL)
cp/cvt.c:703        fn = expr;
cp/cvt.c:704:===>         else if (TREE_CODE (expr) == ADDR_EXPR
cp/cvt.c:705               && TREE_CODE (TREE_OPERAND (expr, 0)) == FUNCTION_DECL)
--
cp/cvt.c:807       return expr;
cp/cvt.c:808:===>  switch (TREE_CODE (expr))
cp/cvt.c:809       {
--
cp/cvt.c:889
cp/cvt.c:890:===>    if (TREE_CODE (probe) == ADDR_EXPR)
cp/cvt.c:891         probe = TREE_OPERAND (expr, 0);
--
cp/decl.c:7547       {
cp/decl.c:7548:===>      if (TREE_CODE (init) == CONSTRUCTOR && TREE_HAS_CONSTRUCTOR (init))
cp/decl.c:7549    {
--
cp/decl.c:7572         type = TREE_TYPE (decl);
cp/decl.c:7573:===>      if (TREE_CODE (init) == CONSTRUCTOR && TREE_HAS_CONSTRUCTOR (init))
cp/decl.c:7574    TREE_TYPE (init) = type;
--
cp/decl.c:7612    dont_use_constructor:
cp/decl.c:7613:===>       if (TREE_CODE (init) != TREE_VEC)
cp/decl.c:7614        init = store_init_value (decl, init);
--
cp/decl.c:7874:
cp/decl.c:7875:===>  if (init && TREE_CODE (init) == NAMESPACE_DECL)
cp/decl.c:7876       {
--
cp/decl.c:14366
cp/decl.c:14367:===>  switch (TREE_CODE (&t->generic))
cp/decl.c:14368       {
--
cp/semantics.c:1194
cp/semantics.c:1195:===>  if (IS_EXPR_CODE_CLASS (TREE_CODE_CLASS (TREE_CODE (expr))))
cp/semantics.c:1196       /* This inhibits warnings in c_common_truthvalue_conversion.  */
--
cp/semantics.c:1198:
cp/semantics.c:1199:===>  if (TREE_CODE (expr) == OFFSET_REF)
cp/semantics.c:1200       /* [expr.unary.op]/3 The qualified id of a pointer-to-member must not be
--
cp/tree.c:348:
cp/tree.c:349:===>  if (TREE_CODE (init) == TARGET_EXPR)
cp/tree.c:350       return init;
--
cp/tree.c:881     /* A baselink is also considered an overloaded function.  */
cp/tree.c:882:===>  if (TREE_CODE (x) == OFFSET_REF)
cp/tree.c:883       x = TREE_OPERAND (x, 1);
cp/tree.c:884:===>  if (BASELINK_P (x))
cp/tree.c:885       x = BASELINK_FUNCTIONS (x);
cp/tree.c:886:===>  return (TREE_CODE (x) == FUNCTION_DECL
cp/tree.c:887:===>        || TREE_CODE (x) == TEMPLATE_ID_EXPR
cp/tree.c:888:===>        || DECL_FUNCTION_TEMPLATE_P (x)
cp/tree.c:889:===>        || TREE_CODE (x) == OVERLOAD);
cp/tree.c:890
--
cp/tree.c:895     /* A baselink is also considered an overloaded function.  */
cp/tree.c:896:===>  if (TREE_CODE (x) == OFFSET_REF)
cp/tree.c:897       x = TREE_OPERAND (x, 1);
cp/tree.c:898:===>  if (BASELINK_P (x))
cp/tree.c:899       x = BASELINK_FUNCTIONS (x);
cp/tree.c:900
cp/tree.c:901:===>  return ((TREE_CODE (x) == OVERLOAD && OVL_CHAIN (x))
cp/tree.c:902:===>        || DECL_FUNCTION_TEMPLATE_P (OVL_CURRENT (x))
cp/tree.c:903:===>        || TREE_CODE (x) == TEMPLATE_ID_EXPR);
cp/tree.c:904
--
cp/typeck2.c:328       }
cp/typeck2.c:329:===>  else if (TREE_CODE (init) == TREE_LIST
cp/typeck2.c:330       && TREE_TYPE (init) != unknown_type_node)
--
cp/typeck2.c:352:
cp/typeck2.c:353:===>  if (TREE_CODE (value) == ERROR_MARK)
cp/typeck2.c:354       ;
--
cp/typeck2.c:399:
cp/typeck2.c:400:===>  if (init == error_mark_node || (TREE_CODE (init) == TREE_LIST
cp/typeck2.c:401                          && TREE_VALUE (init) == error_mark_node))
--
cp/typeck2.c:403:
cp/typeck2.c:404:===>  if (TREE_CODE (init) == ERROR_MARK)
cp/typeck2.c:405       /* __PRETTY_FUNCTION__'s initializer is a bogus expression inside
--
cp/typeck2.c:415     /* Strip NON_LVALUE_EXPRs since we aren't using as an lvalue.  */
cp/typeck2.c:416:===>  if (TREE_CODE (init) == NON_LVALUE_EXPR)
cp/typeck2.c:417       init = TREE_OPERAND (init, 0);
cp/typeck2.c:418:
cp/typeck2.c:419:===>  raw_constructor = (TREE_CODE (init) == CONSTRUCTOR
cp/typeck2.c:420             && TREE_HAS_CONSTRUCTOR (init));
--
cp/typeck2.c:503    }
cp/typeck2.c:504:===>      while (TREE_CODE (init) == CONSTRUCTOR && TREE_HAS_CONSTRUCTOR (init))
cp/typeck2.c:505    {
--
cp/typeck.c:1289     /* Constants can be used directly unless they're not loadable.  */
cp/typeck.c:1290:===>  if (TREE_CODE (exp) == CONST_DECL)
cp/typeck.c:1291       exp = DECL_INITIAL (exp);
--
cp/typeck.c:1425:
cp/typeck.c:1426:===>  if (TREE_CODE (exp) == STRING_CST)
cp/typeck.c:1427       {
--
cp/typeck.c:2827           it was unsigned.  */
cp/typeck.c:2828:===>       shorten = ((TREE_CODE (op0) == NOP_EXPR
cp/typeck.c:2829                && TREE_UNSIGNED (TREE_TYPE (TREE_OPERAND (op0, 0))))
--
cp/typeck.c:3151          (unsigned0, common_type (TREE_TYPE (arg0), TREE_TYPE (arg1)));
cp/typeck.c:3152:===>     else if (TREE_CODE (arg0) == INTEGER_CST
cp/typeck.c:3153           && (unsigned1 || !uns)
--
cp/typeck.c:3293:
cp/typeck.c:3294:===>     if ((TREE_CODE (primop0) == BIT_NOT_EXPR)
cp/typeck.c:3295:===>         ^ (TREE_CODE (primop1) == BIT_NOT_EXPR))
cp/typeck.c:3296        {
--
cp/typeck.c:4405     if (TREE_CODE (type) != REFERENCE_TYPE
cp/typeck.c:4406:===>      && TREE_CODE (expr) == NOP_EXPR
cp/typeck.c:4407         && TREE_TYPE (expr) == TREE_TYPE (TREE_OPERAND (expr, 0)))
--
cp/typeck.c:4757     if (TREE_CODE (type) != REFERENCE_TYPE
cp/typeck.c:4758:===>      && TREE_CODE (value) == NOP_EXPR
cp/typeck.c:4759         && TREE_TYPE (value) == TREE_TYPE (TREE_OPERAND (value, 0)))
--
cp/typeck.c:4865         /* Ignore any integer overflow caused by the cast.  */
cp/typeck.c:4866:===>      if (TREE_CODE (value) == INTEGER_CST)
cp/typeck.c:4867    {
--
cp/typeck.c:5181                                 NULL_TREE, 0);
cp/typeck.c:5182:===>      if (TREE_CODE (newrhs) == CALL_EXPR
cp/typeck.c:5183      && TYPE_NEEDS_CONSTRUCTING (lhstype))
--
cp/typeck.c:5189     expanded without a target.  */
cp/typeck.c:5190:===>      if (TREE_CODE (newrhs) == TARGET_EXPR)
cp/typeck.c:5191    newrhs = build (COMPOUND_EXPR, TREE_TYPE (newrhs), newrhs,
--
cp/typeck.c:5542       {
cp/typeck.c:5543:===>      if (TREE_CODE (expr) == INTEGER_CST
cp/typeck.c:5544      && TREE_NEGATED_INT (expr))
--
cp/typeck.c:5809       {
cp/typeck.c:5810:===>      if (TREE_CODE (whats_returned) == COMPOUND_EXPR)
cp/typeck.c:5811    whats_returned = TREE_OPERAND (whats_returned, 1);
cp/typeck.c:5812:===>      else if (TREE_CODE (whats_returned) == CONVERT_EXPR
cp/typeck.c:5813:===>          || TREE_CODE (whats_returned) == NON_LVALUE_EXPR
cp/typeck.c:5814:===>          || TREE_CODE (whats_returned) == NOP_EXPR)
cp/typeck.c:5815    whats_returned = TREE_OPERAND (whats_returned, 0);
--
cp/typeck.c:5819:
cp/typeck.c:5820:===>  if (TREE_CODE (whats_returned) != ADDR_EXPR)
cp/typeck.c:5821       return;
--
cp/typeck.c:5986          || current_function_return_value == retval)
cp/typeck.c:5987:===>     && TREE_CODE (retval) == VAR_DECL
cp/typeck.c:5988      && DECL_CONTEXT (retval) == current_function_decl
--
cp/typeck.c:6027         else if (! current_function_returns_struct
cp/typeck.c:6028:===>          && TREE_CODE (retval) == TARGET_EXPR
cp/typeck.c:6029           && TREE_CODE (TREE_OPERAND (retval, 1)) == AGGR_INIT_EXPR)
--
fold-const.c:975:
fold-const.c:976:===>  if (TREE_CODE (in) == INTEGER_CST || TREE_CODE (in) == REAL_CST)
fold-const.c:977       *litp = in;
fold-const.c:978:===>  else if (TREE_CODE (in) == code
fold-const.c:979       || (! FLOAT_TYPE_P (TREE_TYPE (in))
--
fold-const.c:983          affected, so we can't.  */
fold-const.c:984:===>          && ((code == PLUS_EXPR && TREE_CODE (in) == MINUS_EXPR)
fold-const.c:985           || (code == MINUS_EXPR && TREE_CODE (in) == PLUS_EXPR))))
--
fold-const.c:1861:
fold-const.c:1862:===>  if (TREE_CODE (arg0) != TREE_CODE (arg1)
fold-const.c:1863         /* This is needed for conversions and for COMPONENT_REF.
--
fold-const.c:1940:
fold-const.c:1941:===>  switch (TREE_CODE_CLASS (TREE_CODE (arg0)))
fold-const.c:1942       {
--
fold-const.c:2004       case 'e':
fold-const.c:2005:===>      switch (TREE_CODE (arg0))
fold-const.c:2006    {
--
fold-const.c:2130
fold-const.c:2131:===>  enum tree_code code = TREE_CODE (arg);
fold-const.c:2132     char class = TREE_CODE_CLASS (code);
--
fold-const.c:2335     tree type = TREE_TYPE (arg);
fold-const.c:2336:===>  enum tree_code code = TREE_CODE (arg);
fold-const.c:2337:
--
fold-const.c:2999       {
fold-const.c:3000:===>      code = TREE_CODE (exp);
fold-const.c:3001:
--
fold-const.c:3228     /* If EXP is a constant, we can evaluate whether this is true or false.  */
fold-const.c:3229:===>  if (TREE_CODE (exp) == INTEGER_CST)
fold-const.c:3230       {
--
fold-const.c:4151     tree type = TREE_TYPE (t);
fold-const.c:4152:===>  enum tree_code tcode = TREE_CODE (t);
fold-const.c:4153     tree ctype = (wide_type != 0 && (GET_MODE_SIZE (TYPE_MODE (wide_type))
--
fold-const.c:4903     if ((code == NE_EXPR || code == EQ_EXPR)
fold-const.c:4904:===>      && TREE_CODE (arg0) == BIT_AND_EXPR && integer_zerop (arg1)
fold-const.c:4905         && integer_pow2p (TREE_OPERAND (arg0, 1)))
--
fold-const.c:4989:
fold-const.c:4990:===>  if (TREE_CODE (arg1) == INTEGER_CST)
fold-const.c:4991       return 0;
fold-const.c:4992:===>  if (TREE_CODE (arg0) == INTEGER_CST)
fold-const.c:4993       return 1;
fold-const.c:4994:
fold-const.c:4995:===>  if (TREE_CODE (arg1) == REAL_CST)
fold-const.c:4996       return 0;
fold-const.c:4997:===>  if (TREE_CODE (arg0) == REAL_CST)
fold-const.c:4998       return 1;
fold-const.c:4999:
fold-const.c:5000:===>  if (TREE_CODE (arg1) == COMPLEX_CST)
fold-const.c:5001       return 0;
fold-const.c:5002:===>  if (TREE_CODE (arg0) == COMPLEX_CST)
fold-const.c:5003       return 1;
--
fold-const.c:5065:
fold-const.c:5066:===>      if (arg0 != 0 && TREE_CODE (arg0) == COMPLEX_CST)
fold-const.c:5067    subop = TREE_REALPART (arg0);
--
fold-const.c:5070:
fold-const.c:5071:===>      if (subop != 0 && TREE_CODE (subop) != INTEGER_CST
fold-const.c:5072:===>    && TREE_CODE (subop) != REAL_CST)
fold-const.c:5073    /* Note that TREE_CONSTANT isn't enough:
--
fold-const.c:5099:
fold-const.c:5100:===>    if (TREE_CODE (op) == COMPLEX_CST)
fold-const.c:5101        subop = TREE_REALPART (op);
--
fold-const.c:5104:
fold-const.c:5105:===>    if (TREE_CODE (subop) != INTEGER_CST
fold-const.c:5106:===>        && TREE_CODE (subop) != REAL_CST)
fold-const.c:5107        /* Note that TREE_CONSTANT isn't enough:
--
fold-const.c:5146          || code == EQ_EXPR || code == NE_EXPR)
fold-const.c:5147:===>      && ((truth_value_p (TREE_CODE (arg0))
fold-const.c:5148       && (truth_value_p (TREE_CODE (arg1))
--
fold-const.c:5150          && integer_onep (TREE_OPERAND (arg1, 1)))))
fold-const.c:5151:===>    || (truth_value_p (TREE_CODE (arg1))
fold-const.c:5152          && (truth_value_p (TREE_CODE (arg0))
--
fold-const.c:5168       {
fold-const.c:5169:===>      if (TREE_CODE (arg0) == COMPOUND_EXPR)
fold-const.c:5170    return build (COMPOUND_EXPR, type, TREE_OPERAND (arg0, 0),
fold-const.c:5171             fold (build1 (code, type, TREE_OPERAND (arg0, 1))));
fold-const.c:5172:===>      else if (TREE_CODE (arg0) == COND_EXPR)
fold-const.c:5173    {
--
fold-const.c:5213    }
fold-const.c:5214:===>      else if (TREE_CODE_CLASS (TREE_CODE (arg0)) == '<')
fold-const.c:5215    return fold (build (COND_EXPR, type, arg0,
--
fold-const.c:5219     else if (TREE_CODE_CLASS (code) == '<'
fold-const.c:5220:===>     && TREE_CODE (arg0) == COMPOUND_EXPR)
fold-const.c:5221       return build (COMPOUND_EXPR, type, TREE_OPERAND (arg0, 0),
--
fold-const.c:5223     else if (TREE_CODE_CLASS (code) == '<'
fold-const.c:5224:===>     && TREE_CODE (arg1) == COMPOUND_EXPR)
fold-const.c:5225       return build (COMPOUND_EXPR, type, TREE_OPERAND (arg1, 0),
--
fold-const.c:5229       {
fold-const.c:5230:===>      if (TREE_CODE (arg1) == COMPOUND_EXPR
fold-const.c:5231      && ! TREE_SIDE_EFFECTS (TREE_OPERAND (arg1, 0))
--
fold-const.c:5235                          arg0, TREE_OPERAND (arg1, 1))));
fold-const.c:5236:===>      else if ((TREE_CODE (arg1) == COND_EXPR
fold-const.c:5237:===>          || (TREE_CODE_CLASS (TREE_CODE (arg1)) == '<'
fold-const.c:5238           && TREE_CODE_CLASS (code) != '<'))
--
fold-const.c:5246                                      /*cond_first_p=*/0);
fold-const.c:5247:===>      else if (TREE_CODE (arg0) == COMPOUND_EXPR)
fold-const.c:5248    return build (COMPOUND_EXPR, type, TREE_OPERAND (arg0, 0),
fold-const.c:5249             fold (build (code, type, TREE_OPERAND (arg0, 1), arg1)));
fold-const.c:5250:===>      else if ((TREE_CODE (arg0) == COND_EXPR
fold-const.c:5251:===>          || (TREE_CODE_CLASS (TREE_CODE (arg0)) == '<'
fold-const.c:5252           && TREE_CODE_CLASS (code) != '<'))
--
fold-const.c:5285         /* Handle cases of two conversions in a row.  */
fold-const.c:5286:===>      if (TREE_CODE (TREE_OPERAND (t, 0)) == NOP_EXPR
fold-const.c:5287:===>    || TREE_CODE (TREE_OPERAND (t, 0)) == CONVERT_EXPR)
fold-const.c:5288    {
--
fold-const.c:5363:
fold-const.c:5364:===>      if (TREE_CODE (TREE_OPERAND (t, 0)) == MODIFY_EXPR
fold-const.c:5365      && TREE_CONSTANT (TREE_OPERAND (TREE_OPERAND (t, 0), 1))
--
fold-const.c:5386      && TREE_CODE (TREE_TYPE (t)) != BOOLEAN_TYPE
fold-const.c:5387:===>    && TREE_CODE (TREE_OPERAND (t, 0)) == BIT_AND_EXPR
fold-const.c:5388      && TREE_CODE (TREE_OPERAND (TREE_OPERAND (t, 0), 1)) == INTEGER_CST)
--
fold-const.c:5620         /* (-A) + B -> B - A */
fold-const.c:5621:===>      if (TREE_CODE (arg0) == NEGATE_EXPR)
fold-const.c:5622    return fold (build (MINUS_EXPR, type, arg1, TREE_OPERAND (arg0, 0)));
--
fold-const.c:5631         simplifications.  */
fold-const.c:5632:===>    if (TREE_CODE (arg0) == BIT_AND_EXPR
fold-const.c:5633          && TREE_CODE (arg1) == BIT_AND_EXPR
--
fold-const.c:5646         take advantage of the factoring cases below.  */
fold-const.c:5647:===>    if ((TREE_CODE (arg0) == PLUS_EXPR
fold-const.c:5648           && TREE_CODE (arg1) == MULT_EXPR)
--
fold-const.c:5678:
fold-const.c:5679:===>    if (TREE_CODE (arg0) == MULT_EXPR && TREE_CODE (arg1) == MULT_EXPR)
fold-const.c:5680        {
--
fold-const.c:5814    enum tree_code code0, code1;
fold-const.c:5815:===>  code0 = TREE_CODE (arg0);
fold-const.c:5816    code1 = TREE_CODE (arg1);
--
fold-const.c:6064         /* (-A) * (-B) -> A * B  */
fold-const.c:6065:===>      if (TREE_CODE (arg0) == NEGATE_EXPR && negate_expr_p (arg1))
fold-const.c:6066    return fold (build (MULT_EXPR, type,
--
fold-const.c:6068                   negate_expr (arg1)));
fold-const.c:6069:===>      if (TREE_CODE (arg1) == NEGATE_EXPR && negate_expr_p (arg0))
fold-const.c:6070    return fold (build (MULT_EXPR, type,
--
fold-const.c:6769    return non_lvalue (convert (type, arg1));
fold-const.c:6770:===>      if (TREE_CODE (arg1) == INTEGER_CST && ! integer_zerop (arg1)
fold-const.c:6771      /* Preserve sequence points.  */
--
fold-const.c:6793     might change the truth-value of A.  */
fold-const.c:6794:===>      if (TREE_CODE (arg0) == TREE_CODE (arg1)
fold-const.c:6795      && (TREE_CODE (arg0) == TRUTH_ANDIF_EXPR
--
fold-const.c:6909      /* (-a) CMP (-b) -> b CMP a  */
fold-const.c:6910:===>    if (TREE_CODE (arg0) == NEGATE_EXPR
fold-const.c:6911          && TREE_CODE (arg1) == NEGATE_EXPR)
--
fold-const.c:6920        /* (-a) CMP CST -> a swap(CMP) (-CST)  */
fold-const.c:6921:===>      if (TREE_CODE (arg0) == NEGATE_EXPR)
fold-const.c:6922          return
--
fold-const.c:7006:
fold-const.c:7007:===>  if (constop && TREE_CODE (varop) == POSTINCREMENT_EXPR)
fold-const.c:7008      {
--
fold-const.c:7076      }
fold-const.c:7077:===>  else if (constop && TREE_CODE (varop) == POSTDECREMENT_EXPR)
fold-const.c:7078      {
--
fold-const.c:7142     optimizations involving comparisons with non-negative constants.  */
fold-const.c:7143:===>      if (TREE_CODE (arg1) == INTEGER_CST
fold-const.c:7144:===>    && TREE_CODE (arg0) != INTEGER_CST
fold-const.c:7145      && tree_int_cst_sgn (arg1) > 0)
--
fold-const.c:7166:
fold-const.c:7167:===>  if (TREE_CODE (arg1) == INTEGER_CST
fold-const.c:7168        && ! TREE_CONSTANT_OVERFLOW (arg1)
--
fold-const.c:7286         if ((code == EQ_EXPR || code == NE_EXPR)
fold-const.c:7287:===>    && TREE_CODE (arg1) == INTEGER_CST
fold-const.c:7288:===>    && (TREE_CODE (arg0) == PLUS_EXPR
fold-const.c:7289:===>        || TREE_CODE (arg0) == MINUS_EXPR)
fold-const.c:7290      && TREE_CODE (TREE_OPERAND (arg0, 1)) == INTEGER_CST
--
fold-const.c:7298         else if ((code == EQ_EXPR || code == NE_EXPR)
fold-const.c:7299:===>         && TREE_CODE (arg0) == NEGATE_EXPR
fold-const.c:7300           && TREE_CODE (arg1) == INTEGER_CST
--
fold-const.c:7308         else if ((code == NE_EXPR || code == EQ_EXPR)
fold-const.c:7309:===>         && integer_zerop (arg1) && TREE_CODE (arg0) == MINUS_EXPR)
fold-const.c:7310    return fold (build (code, type,
--
fold-const.c:7316         else if (TREE_CODE (TREE_TYPE (arg0)) == INTEGER_TYPE
fold-const.c:7317:===>         && TREE_CODE (arg0) == NOP_EXPR
fold-const.c:7318           && (tem = get_unwidened (arg0, NULL_TREE)) != arg0
--
fold-const.c:7326     constant, we can simplify it.  */
fold-const.c:7327:===>      else if (TREE_CODE (arg1) == INTEGER_CST
fold-const.c:7328:===>         && (TREE_CODE (arg0) == MIN_EXPR
fold-const.c:7329:===>             || TREE_CODE (arg0) == MAX_EXPR)
fold-const.c:7330           && TREE_CODE (TREE_OPERAND (arg0, 1)) == INTEGER_CST)
--
fold-const.c:7354         if (integer_zerop (arg1) && (code == EQ_EXPR || code == NE_EXPR)
fold-const.c:7355:===>    && TREE_CODE (arg0) == BIT_AND_EXPR)
fold-const.c:7356    {
--
fold-const.c:7388      && ! TREE_UNSIGNED (TREE_TYPE (arg0))
fold-const.c:7389:===>    && (TREE_CODE (arg0) == TRUNC_MOD_EXPR
fold-const.c:7390:===>        || TREE_CODE (arg0) == CEIL_MOD_EXPR
fold-const.c:7391:===>        || TREE_CODE (arg0) == FLOOR_MOD_EXPR
fold-const.c:7392:===>        || TREE_CODE (arg0) == ROUND_MOD_EXPR)
fold-const.c:7393      && integer_pow2p (TREE_OPERAND (arg0, 1)))
--
fold-const.c:7405         if (code == NE_EXPR && integer_zerop (arg1)
fold-const.c:7406:===>    && TREE_CODE (arg0) == BIT_AND_EXPR
fold-const.c:7407      && integer_onep (TREE_OPERAND (arg0, 1)))
--
fold-const.c:7412         if ((code == EQ_EXPR || code == NE_EXPR)
fold-const.c:7413:===>    && TREE_CODE (arg0) == BIT_AND_EXPR
fold-const.c:7414      && integer_pow2p (TREE_OPERAND (arg0, 1))
--
fold-const.c:7427         if ((code == EQ_EXPR || code == NE_EXPR)
fold-const.c:7428:===>    && TREE_CODE (arg0) == BIT_AND_EXPR
fold-const.c:7429      && TREE_CODE (arg1) == INTEGER_CST
--
fold-const.c:7444         if ((code == EQ_EXPR || code == NE_EXPR)
fold-const.c:7445:===>    && TREE_CODE (arg0) == BIT_IOR_EXPR
fold-const.c:7446      && TREE_CODE (arg1) == INTEGER_CST
--
fold-const.c:7528:
fold-const.c:7529:===>      if (TREE_CODE (arg1) == INTEGER_CST && TREE_CODE (arg0) != INTEGER_CST)
fold-const.c:7530    {
--
fold-const.c:7617         /* If this is a comparison of a field, we may be able to simplify it.  */
fold-const.c:7618:===>      if (((TREE_CODE (arg0) == COMPONENT_REF
fold-const.c:7619        && (*lang_hooks.can_use_bit_fields_p) ())
fold-const.c:7620:===>     || TREE_CODE (arg0) == BIT_FIELD_REF)
fold-const.c:7621      && (code == EQ_EXPR || code == NE_EXPR)
--
fold-const.c:7665      && integer_zerop (arg1)
fold-const.c:7666:===>    && TREE_CODE (arg0) == CALL_EXPR)
fold-const.c:7667    {
--
fold-const.c:7712     otherwise return T.  */
fold-const.c:7713:===>      if (TREE_CODE (arg0) == INTEGER_CST && TREE_CODE (arg1) == INTEGER_CST)
fold-const.c:7714    {
--
fold-const.c:7736         /* Two real constants can be compared explicitly.  */
fold-const.c:7737:===>      else if (TREE_CODE (arg0) == REAL_CST && TREE_CODE (arg1) == REAL_CST)
fold-const.c:7738    {
--
fold-const.c:7773     so all simple results must be passed through pedantic_non_lvalue.  */
fold-const.c:7774:===>      if (TREE_CODE (arg0) == INTEGER_CST)
fold-const.c:7775    return pedantic_non_lvalue
--
fold-const.c:7784:
fold-const.c:7785:===>      if (TREE_CODE_CLASS (TREE_CODE (arg0)) == '<'
fold-const.c:7786      && operand_equal_for_comparison_p (TREE_OPERAND (arg0, 0),
--
fold-const.c:7947      if (INTEGRAL_TYPE_P (type)
fold-const.c:7948:===>        && TREE_CODE (TREE_OPERAND (arg0, 1)) == INTEGER_CST
fold-const.c:7949          && TREE_CODE (arg2) == INTEGER_CST)
--
tree.c:587:
tree.c:588:===>  return ((TREE_CODE (expr) == INTEGER_CST
tree.c:589       && ! TREE_CONSTANT_OVERFLOW (expr)
--
tree.c:591       && TREE_INT_CST_HIGH (expr) == 0)
tree.c:592:===>   || (TREE_CODE (expr) == COMPLEX_CST
tree.c:593          && integer_zerop (TREE_REALPART (expr))
--
tree.c:604:
tree.c:605:===>  return ((TREE_CODE (expr) == INTEGER_CST
tree.c:606       && ! TREE_CONSTANT_OVERFLOW (expr)
--
tree.c:608       && TREE_INT_CST_HIGH (expr) == 0)
tree.c:609:===>   || (TREE_CODE (expr) == COMPLEX_CST
tree.c:610          && integer_onep (TREE_REALPART (expr))
--
tree.c:811:
tree.c:812:===>  return ((TREE_CODE (expr) == REAL_CST
tree.c:813       && ! TREE_CONSTANT_OVERFLOW (expr)
tree.c:814       && REAL_VALUES_EQUAL (TREE_REAL_CST (expr), dconst0))
tree.c:815:===>   || (TREE_CODE (expr) == COMPLEX_CST
tree.c:816          && real_zerop (TREE_REALPART (expr))
--
tree.c:826:
tree.c:827:===>  return ((TREE_CODE (expr) == REAL_CST
tree.c:828       && ! TREE_CONSTANT_OVERFLOW (expr)
tree.c:829       && REAL_VALUES_EQUAL (TREE_REAL_CST (expr), dconst1))
tree.c:830:===>   || (TREE_CODE (expr) == COMPLEX_CST
tree.c:831          && real_onep (TREE_REALPART (expr))
--
tree.c:856:
tree.c:857:===>  return ((TREE_CODE (expr) == REAL_CST
tree.c:858       && ! TREE_CONSTANT_OVERFLOW (expr)
tree.c:859       && REAL_VALUES_EQUAL (TREE_REAL_CST (expr), dconstm1))
tree.c:860:===>   || (TREE_CODE (expr) == COMPLEX_CST
tree.c:861          && real_minus_onep (TREE_REALPART (expr))
--
tree.c:1473
tree.c:1474:===>  enum tree_code code = TREE_CODE (t);
tree.c:1475:
--
tree.c:1885:
tree.c:1886:===>  switch (TREE_CODE (exp))
tree.c:1887       {
--
tree.c:1912        the situation.  */
tree.c:1913:===>  if ((int) TREE_CODE (exp) >= (int) LAST_AND_UNUSED_TREE_CODE)
tree.c:1914       return -1;
tree.c:1915:
tree.c:1916:===>  nops = first_rtl_op (TREE_CODE (exp));
tree.c:1917     for (i = 0; i < nops; i++)
--
tree.c:1919         {
tree.c:1920:===>        int type = TREE_CODE_CLASS (TREE_CODE (TREE_OPERAND (exp, i)));
tree.c:1921    if (type == 'e' || type == '<' || type == '1' || type == '2'
--
tree.c:4128:
tree.c:4129:===>  while (TREE_CODE (op) == NOP_EXPR)
tree.c:4130       {
--
tree.c:4168:
tree.c:4169:===>  if (TREE_CODE (op) == COMPONENT_REF
tree.c:4170         /* Since type_for_size always gives an integer type.  */
--
tree-inline.c:427    ifndef INLINER_FOR_JAVA
tree-inline.c:428:===>  if (TREE_CODE (*tp) == RETURN_STMT && id->ret_label)
tree-inline.c:429    else /* INLINER_FOR_JAVA */
--
tree-inline.c:491    endif
tree-inline.c:492:===>  else if (TREE_CODE (*tp) == SAVE_EXPR)
tree-inline.c:493       remap_save_expr (tp, id->decl_map, VARRAY_TREE (id->fns, 0),
tree-inline.c:494            walk_subtrees);
tree-inline.c:495:===>  else if (TREE_CODE (*tp) == UNSAVE_EXPR)
tree-inline.c:496       /* UNSAVE_EXPRs should not be generated until expansion time.  */
--
tree-inline.c:500        can write out debugging information for the inlined variables.  */
tree-inline.c:501:===>  else if (TREE_CODE (*tp) == SCOPE_STMT && !id->in_target_cleanup_p)
tree-inline.c:502       copy_scope_stmt (tp, walk_subtrees, id);
--
tree-inline.c:530       {
tree-inline.c:531:===>      if (TREE_CODE (*tp) == MODIFY_EXPR
tree-inline.c:532      && TREE_OPERAND (*tp, 0) == TREE_OPERAND (*tp, 1)
--
tree-inline.c:553    }
tree-inline.c:554:===>      else if (TREE_CODE (*tp) == ADDR_EXPR
tree-inline.c:555           && ((*lang_hooks.tree_inlining.auto_var_in_fn_p)
--
tree-inline.c:579     original node was expanded already.  */
tree-inline.c:580:===>      if (TREE_CODE (*tp) == TARGET_EXPR && TREE_OPERAND (*tp, 3))
tree-inline.c:581    {
--
tree-inline.c:889:
tree-inline.c:890:===>  switch (TREE_CODE (node))
tree-inline.c:891       {

-- 
Carlo Wood <carlo@alinoe.com>

Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only.

[Carlo Wood]

On Mon, Oct 06, 2003 at 02:55:36PM -0700, Richard Henderson wrote:
> And why exactly would you be calling get_callee_fndecl on a WFL
> in the first place?

Here is another way where get_callee_fndecl is called on
the WFL, still only having build_cxx_call return the WFL.

Breakpoint 1, get_callee_fndecl (call=0x41396d80)
    at ../../../gcc/gcc-mainline/gcc/tree.c:4428
4428        abort ();
(gdb) bt
#0  get_callee_fndecl (call=0x41396d80) at ../../../gcc/gcc-mainline/gcc/tree.c:4428
#1  0x081b1694 in build_new_1 (exp=0x41396d60)
    at ../../../gcc/gcc-mainline/gcc/cp/init.c:2069
#2  0x081b0038 in build_new (placement=0x0, decl=0x413aa6f4, init=0x0, use_global_new=0)
    at ../../../gcc/gcc-mainline/gcc/cp/init.c:1816
#3  0x0815f4de in cp_parser_new_expression (parser=0x402f95c0)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:4210
#4  0x0815f096 in cp_parser_unary_expression (parser=0x402f95c0, address_p=false)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:3996
#5  0x0815faac in cp_parser_cast_expression (parser=0x402f95c0, address_p=false)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:4546
#6  0x0816e02e in cp_parser_simple_cast_expression (parser=0x402f95c0)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:13791
#7  0x0816d18f in cp_parser_binary_expression (parser=0x402f95c0,
    token_tree_map=0x861c580, fn=0x816e01b <cp_parser_simple_cast_expression>)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:13290
#8  0x0815fad2 in cp_parser_pm_expression (parser=0x402f95c0)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:4567
#9  0x0816d18f in cp_parser_binary_expression (parser=0x402f95c0,
    token_tree_map=0x861c58c, fn=0x815fab7 <cp_parser_pm_expression>)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:13290
#10 0x0815faf2 in cp_parser_multiplicative_expression (parser=0x402f95c0)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:4591
#11 0x0816d18f in cp_parser_binary_expression (parser=0x402f95c0,
    token_tree_map=0x861c59c, fn=0x815fad7 <cp_parser_multiplicative_expression>)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:13290
---Type <return> to continue, or q <return> to quit---
#12 0x0815fb12 in cp_parser_additive_expression (parser=0x402f95c0)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:4614
#13 0x0816d18f in cp_parser_binary_expression (parser=0x402f95c0,
    token_tree_map=0x861c5a8, fn=0x815faf7 <cp_parser_additive_expression>)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:13290
#14 0x0815fb32 in cp_parser_shift_expression (parser=0x402f95c0)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:4637
#15 0x0816d18f in cp_parser_binary_expression (parser=0x402f95c0,
    token_tree_map=0x861c5b4, fn=0x815fb17 <cp_parser_shift_expression>)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:13290
#16 0x0815fb52 in cp_parser_relational_expression (parser=0x402f95c0)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:4672
#17 0x0816d18f in cp_parser_binary_expression (parser=0x402f95c0,
    token_tree_map=0x861c5d0, fn=0x815fb37 <cp_parser_relational_expression>)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:13290
#18 0x0815fb72 in cp_parser_equality_expression (parser=0x402f95c0)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:4695
#19 0x0816d18f in cp_parser_binary_expression (parser=0x402f95c0,
    token_tree_map=0x861c5dc, fn=0x815fb57 <cp_parser_equality_expression>)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:13290
#20 0x0815fb92 in cp_parser_and_expression (parser=0x402f95c0)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:4716
#21 0x0816d18f in cp_parser_binary_expression (parser=0x402f95c0,
    token_tree_map=0x861c5e4, fn=0x815fb77 <cp_parser_and_expression>)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:13290
#22 0x0815fbb2 in cp_parser_exclusive_or_expression (parser=0x402f95c0)
---Type <return> to continue, or q <return> to quit---
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:4737
#23 0x0816d18f in cp_parser_binary_expression (parser=0x402f95c0,
    token_tree_map=0x861c5ec, fn=0x815fb97 <cp_parser_exclusive_or_expression>)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:13290
#24 0x0815fbd2 in cp_parser_inclusive_or_expression (parser=0x402f95c0)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:4759
#25 0x0816d18f in cp_parser_binary_expression (parser=0x402f95c0,
    token_tree_map=0x861c5f4, fn=0x815fbb7 <cp_parser_inclusive_or_expression>)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:13290
#26 0x0815fbf2 in cp_parser_logical_and_expression (parser=0x402f95c0)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:4780
#27 0x0816d18f in cp_parser_binary_expression (parser=0x402f95c0,
    token_tree_map=0x861c5fc, fn=0x815fbd7 <cp_parser_logical_and_expression>)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:13290
#28 0x0815fc12 in cp_parser_logical_or_expression (parser=0x402f95c0)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:4801
#29 0x0815fce8 in cp_parser_assignment_expression (parser=0x402f95c0)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:4869
#30 0x0815fd3c in cp_parser_assignment_expression (parser=0x402f95c0)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:4887
#31 0x0815fe79 in cp_parser_expression (parser=0x402f95c0)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:5017
#32 0x08160310 in cp_parser_expression_statement (parser=0x402f95c0,
    in_statement_expr_p=false) at ../../../gcc/gcc-mainline/gcc/cp/parser.c:5299
#33 0x08160104 in cp_parser_statement (parser=0x402f95c0, in_statement_expr_p=false)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:5209
---Type <return> to continue, or q <return> to quit---
#34 0x0816043e in cp_parser_statement_seq_opt (parser=0x402f95c0,
    in_statement_expr_p=false) at ../../../gcc/gcc-mainline/gcc/cp/parser.c:5364
#35 0x081603c5 in cp_parser_compound_statement (parser=0x402f95c0,
    in_statement_expr_p=false) at ../../../gcc/gcc-mainline/gcc/cp/parser.c:5337
#36 0x08167d13 in cp_parser_function_body (parser=0x402f95c0)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:10849
#37 0x08167d42 in cp_parser_ctor_initializer_opt_and_function_body (parser=0x402f95c0)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:10866
#38 0x0816d710 in cp_parser_function_definition_after_declarator (parser=0x402f95c0,
    inline_p=false) at ../../../gcc/gcc-mainline/gcc/cp/parser.c:13600
#39 0x0816d630 in cp_parser_function_definition_from_specifiers_and_declarator (
    parser=0x402f95c0, decl_specifiers=0x413aa2d0, attributes=0x0, declarator=0x41098ee8)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:13546
#40 0x0816548c in cp_parser_init_declarator (parser=0x402f95c0,
    decl_specifiers=0x413aa2d0, prefix_attributes=0x0,
    function_definition_allowed_p=true, member_p=false, declares_class_or_enum=0,
    function_definition_p=0xbfffef2f) at ../../../gcc/gcc-mainline/gcc/cp/parser.c:9359
#41 0x08161138 in cp_parser_simple_declaration (parser=0x402f95c0,
    function_definition_allowed_p=true) at ../../../gcc/gcc-mainline/gcc/cp/parser.c:6156
#42 0x08161072 in cp_parser_block_declaration (parser=0x402f95c0, statement_p=false)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:6072
#43 0x08160f2e in cp_parser_declaration (parser=0x402f95c0)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:5992
#44 0x08160d64 in cp_parser_declaration_seq_opt (parser=0x402f95c0)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:5901
#45 0x08164c36 in cp_parser_namespace_body (parser=0x402f95c0)
---Type <return> to continue, or q <return> to quit---
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:8915
#46 0x08164c06 in cp_parser_namespace_definition (parser=0x402f95c0)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:8900
#47 0x08160f1c in cp_parser_declaration (parser=0x402f95c0)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:5987
#48 0x08160d64 in cp_parser_declaration_seq_opt (parser=0x402f95c0)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:5901
#49 0x08164c36 in cp_parser_namespace_body (parser=0x402f95c0)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:8915
#50 0x08164c06 in cp_parser_namespace_definition (parser=0x402f95c0)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:8900
#51 0x08160f1c in cp_parser_declaration (parser=0x402f95c0)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:5987
#52 0x08160d64 in cp_parser_declaration_seq_opt (parser=0x402f95c0)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:5901
#53 0x08164c36 in cp_parser_namespace_body (parser=0x402f95c0)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:8915
#54 0x08164c06 in cp_parser_namespace_definition (parser=0x402f95c0)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:8900
#55 0x08160f1c in cp_parser_declaration (parser=0x402f95c0)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:5987
#56 0x08160d64 in cp_parser_declaration_seq_opt (parser=0x402f95c0)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:5901
#57 0x0815c41b in cp_parser_translation_unit (parser=0x402f95c0)
    at ../../../gcc/gcc-mainline/gcc/cp/parser.c:2163
#58 0x0816f60c in c_parse_file () at ../../../gcc/gcc-mainline/gcc/cp/parser.c:14523
---Type <return> to continue, or q <return> to quit---
#59 0x08240e14 in c_common_parse_file (set_yydebug=0)
    at ../../../gcc/gcc-mainline/gcc/c-opts.c:1226
#60 0x08510333 in compile_file () at ../../../gcc/gcc-mainline/gcc/toplev.c:1792
#61 0x08514fac in do_compile () at ../../../gcc/gcc-mainline/gcc/toplev.c:4482
#62 0x08515041 in toplev_main (argc=29, argv=0xbffff2f4)
    at ../../../gcc/gcc-mainline/gcc/toplev.c:4522
#63 0x08244aa6 in main (argc=29, argv=0xbffff2f4)
    at ../../../gcc/gcc-mainline/gcc/main.c:35
#64 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6

-- 
Carlo Wood <carlo@alinoe.com>

Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only.

[Richard Henderson]

On Tue, Oct 07, 2003 at 08:32:31PM +0200, Carlo Wood wrote:
> Next, I manually investigated every place where this happened
> and either turned off the warning (using TREE_CODE_NOCHECK or
> with ++nocheck ... --nocheck wraps) and/or added code to handle
> the EXPR_WITH_FILE_LOCATION.

I think you're completely off-track with this.  You'll get
near 100% false hits with this scheme.


r~

Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only.

[Carlo Wood]

On Tue, Oct 07, 2003 at 12:46:04PM -0700, Richard Henderson wrote:
> On Tue, Oct 07, 2003 at 08:32:31PM +0200, Carlo Wood wrote:
> > Next, I manually investigated every place where this happened
> > and either turned off the warning (using TREE_CODE_NOCHECK or
> > with ++nocheck ... --nocheck wraps) and/or added code to handle
> > the EXPR_WITH_FILE_LOCATION.
> 
> I think you're completely off-track with this.  You'll get
> near 100% false hits with this scheme.

More like 80 - 90%.  But its the only sheme that garantees that
you won't miss a hit.

Did you look at the patch?  Then you'd see that there are many
places where there *is* a need to add special case handling.
Yes, most hits are for TREE_CODE(t) == SOMETHINGELSE, but you
have to look at those lines before you can see that it says
'SOMETHINGELSE' and not 'CALL_EXPR'.
The huge amount of places where the WFL happily shows up
proves that it is not handled as automatically as you seem
to believe.

Can we now please forget about using WFL?  Trust me, the result
would be unmaintainable.

-- 
Carlo Wood <carlo@alinoe.com>

Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only.

[Carlo Wood]

I finished the patch that adds the location_t after
the expressions' structure (like in OO inheritance).

This patch is simple, robust, maintainable and increases
the memory usage only with 0.2% instead of the 7% when
adding the location_t to tree_exp as a fixed member.

The patch certainly is a lot smaller and simpler than a
WFL based patch would be - and garanteed bug free, something
that I'd not be able to garantee with a patch that uses WFL :/.
Also, it uses less memory than when implementing this with WFL
(a WFL adds a whole tree struct, which is considerably larger
than a location_t).

As soon as I did the mandatory bootstrap and gdb testsuite
tests, I will post the patch to gcc-patches@ with a CC to you
for review.

Thanks,

-- 
Carlo Wood <carlo@alinoe.com>

Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only.

[law]

In message <20031006202057.GB5019@redhat.com>, Richard Henderson writes:
 >On Mon, Oct 06, 2003 at 04:14:23PM -0400, Daniel Jacobowitz wrote:
 >> A number of places continue to recurse on the arguments of a PLUS_EXPR
 >> but do not handle EXPR_WITH_FILE_LOCATION, for one thing.
 >
 >Please name such a place.  I'm asking for specifics here and
 >getting nothing from yall.
 >
 >Have yall *tried* WFL and have experimental evidence for how much
 >of a performance hit you get?  Given that we do extraordinarily
 >little reasoning with trees on mainline, I have a hard time imagining
 >that it has much affect at all.
Ugh.  WFL nodes have certain properties that are very undesirable.  Their
worst property is that you have to make sure you strip them away in all
the locations that expect to see the underlying expression -- which is very
prone to mistakes.

IMHO locus information belongs in the tree nodes themselves, not in a
wrapper node such as a WFL.

jeff

Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only.

[Daniel Berlin]

On Sat, 11 Oct 2003 law@redhat.com wrote:

> In message <20031006202057.GB5019@redhat.com>, Richard Henderson writes:
>  >On Mon, Oct 06, 2003 at 04:14:23PM -0400, Daniel Jacobowitz wrote:
>  >> A number of places continue to recurse on the arguments of a PLUS_EXPR
>  >> but do not handle EXPR_WITH_FILE_LOCATION, for one thing.
>  >
>  >Please name such a place.  I'm asking for specifics here and
>  >getting nothing from yall.
>  >
>  >Have yall *tried* WFL and have experimental evidence for how much
>  >of a performance hit you get?  Given that we do extraordinarily
>  >little reasoning with trees on mainline, I have a hard time imagining
>  >that it has much affect at all.
> Ugh.  WFL nodes have certain properties that are very undesirable.  Their
> worst property is that you have to make sure you strip them away in all
> the locations that expect to see the underlying expression -- which is very
> prone to mistakes.

The second worst has to be that you have to "unstrip" them in order to
maintain
line info if you duplicate code through an optimization.

IE you strip them to process the underlying expression, then you need to
copy the WFL if you end up copying the underyling expression, or you lose
line info.

Since most, if not everything, doesn't WANT to see a WFL, only the
underlying expression, this usually means passing the WFL around too.