* RFC: debug line info & inlining; patch proposal and request for comments. @ 2003-09-22 2:31 Carlo Wood 2003-09-23 5:33 ` Jim Wilson 2003-09-27 16:38 ` RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only Carlo Wood 0 siblings, 2 replies; 31+ messages in thread From: Carlo Wood @ 2003-09-22 2:31 UTC (permalink / raw) To: gcc 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> ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: RFC: debug line info & inlining; patch proposal and request for comments. 2003-09-22 2:31 RFC: debug line info & inlining; patch proposal and request for comments Carlo Wood @ 2003-09-23 5:33 ` Jim Wilson 2003-09-27 16:38 ` RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only Carlo Wood 1 sibling, 0 replies; 31+ messages in thread From: Jim Wilson @ 2003-09-23 5:33 UTC (permalink / raw) To: Carlo Wood; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only. 2003-09-22 2:31 RFC: debug line info & inlining; patch proposal and request for comments Carlo Wood 2003-09-23 5:33 ` Jim Wilson @ 2003-09-27 16:38 ` Carlo Wood 2003-10-06 12:58 ` Hans-Peter Nilsson 2003-10-06 17:41 ` Richard Henderson 1 sibling, 2 replies; 31+ messages in thread From: Carlo Wood @ 2003-09-27 16:38 UTC (permalink / raw) To: gcc; +Cc: wilson, jason, rth 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> ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only. 2003-09-27 16:38 ` RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only Carlo Wood @ 2003-10-06 12:58 ` Hans-Peter Nilsson 2003-10-06 17:41 ` Richard Henderson 1 sibling, 0 replies; 31+ messages in thread From: Hans-Peter Nilsson @ 2003-10-06 12:58 UTC (permalink / raw) To: Carlo Wood; +Cc: gcc (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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only. 2003-09-27 16:38 ` RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only Carlo Wood 2003-10-06 12:58 ` Hans-Peter Nilsson @ 2003-10-06 17:41 ` Richard Henderson 2003-10-06 17:51 ` Daniel Jacobowitz 2003-10-06 19:08 ` Carlo Wood 1 sibling, 2 replies; 31+ messages in thread From: Richard Henderson @ 2003-10-06 17:41 UTC (permalink / raw) To: gcc, wilson, jason 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~ ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only. 2003-10-06 17:41 ` Richard Henderson @ 2003-10-06 17:51 ` Daniel Jacobowitz 2003-10-06 18:03 ` Daniel Berlin 2003-10-06 19:08 ` Carlo Wood 1 sibling, 1 reply; 31+ messages in thread From: Daniel Jacobowitz @ 2003-10-06 17:51 UTC (permalink / raw) To: gcc; +Cc: Richard Henderson 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only. 2003-10-06 17:51 ` Daniel Jacobowitz @ 2003-10-06 18:03 ` Daniel Berlin 2003-10-06 19:20 ` Carlo Wood 0 siblings, 1 reply; 31+ messages in thread From: Daniel Berlin @ 2003-10-06 18:03 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gcc, Richard Henderson 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. > ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only. 2003-10-06 18:03 ` Daniel Berlin @ 2003-10-06 19:20 ` Carlo Wood 0 siblings, 0 replies; 31+ messages in thread From: Carlo Wood @ 2003-10-06 19:20 UTC (permalink / raw) To: Daniel Berlin; +Cc: Daniel Jacobowitz, gcc, Richard Henderson 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)"))) ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only. 2003-10-06 17:41 ` Richard Henderson 2003-10-06 17:51 ` Daniel Jacobowitz @ 2003-10-06 19:08 ` Carlo Wood 2003-10-06 20:11 ` Richard Henderson 1 sibling, 1 reply; 31+ messages in thread From: Carlo Wood @ 2003-10-06 19:08 UTC (permalink / raw) To: gcc; +Cc: Richard Henderson, wilson, jason 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> ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only. 2003-10-06 19:08 ` Carlo Wood @ 2003-10-06 20:11 ` Richard Henderson 2003-10-06 20:14 ` Daniel Jacobowitz 0 siblings, 1 reply; 31+ messages in thread From: Richard Henderson @ 2003-10-06 20:11 UTC (permalink / raw) To: gcc, wilson, jason 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~ ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only. 2003-10-06 20:11 ` Richard Henderson @ 2003-10-06 20:14 ` Daniel Jacobowitz 2003-10-06 20:20 ` Richard Henderson 0 siblings, 1 reply; 31+ messages in thread From: Daniel Jacobowitz @ 2003-10-06 20:14 UTC (permalink / raw) To: gcc; +Cc: Richard Henderson, wilson, jason 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only. 2003-10-06 20:14 ` Daniel Jacobowitz @ 2003-10-06 20:20 ` Richard Henderson 2003-10-06 20:24 ` Daniel Jacobowitz ` (2 more replies) 0 siblings, 3 replies; 31+ messages in thread From: Richard Henderson @ 2003-10-06 20:20 UTC (permalink / raw) To: gcc, wilson, jason 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~ ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only. 2003-10-06 20:20 ` Richard Henderson @ 2003-10-06 20:24 ` Daniel Jacobowitz 2003-10-06 21:54 ` Richard Henderson 2003-10-06 21:53 ` Carlo Wood 2003-10-12 4:32 ` law 2 siblings, 1 reply; 31+ messages in thread From: Daniel Jacobowitz @ 2003-10-06 20:24 UTC (permalink / raw) To: gcc; +Cc: Richard Henderson, wilson, jason 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only. 2003-10-06 20:24 ` Daniel Jacobowitz @ 2003-10-06 21:54 ` Richard Henderson 0 siblings, 0 replies; 31+ messages in thread From: Richard Henderson @ 2003-10-06 21:54 UTC (permalink / raw) To: gcc, wilson, jason 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~ ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only. 2003-10-06 20:20 ` Richard Henderson 2003-10-06 20:24 ` Daniel Jacobowitz @ 2003-10-06 21:53 ` Carlo Wood 2003-10-06 21:55 ` Richard Henderson 2003-10-12 4:32 ` law 2 siblings, 1 reply; 31+ messages in thread From: Carlo Wood @ 2003-10-06 21:53 UTC (permalink / raw) To: Richard Henderson, gcc, wilson, jason 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> ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only. 2003-10-06 21:53 ` Carlo Wood @ 2003-10-06 21:55 ` Richard Henderson 2003-10-06 22:30 ` Carlo Wood 2003-10-07 19:41 ` Carlo Wood 0 siblings, 2 replies; 31+ messages in thread From: Richard Henderson @ 2003-10-06 21:55 UTC (permalink / raw) To: gcc, wilson, jason 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~ ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only. 2003-10-06 21:55 ` Richard Henderson @ 2003-10-06 22:30 ` Carlo Wood 2003-10-06 23:17 ` Richard Henderson 2003-10-07 19:41 ` Carlo Wood 1 sibling, 1 reply; 31+ messages in thread From: Carlo Wood @ 2003-10-06 22:30 UTC (permalink / raw) To: Richard Henderson, gcc, wilson, jason 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> ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only. 2003-10-06 22:30 ` Carlo Wood @ 2003-10-06 23:17 ` Richard Henderson 2003-10-06 23:49 ` Carlo Wood 0 siblings, 1 reply; 31+ messages in thread From: Richard Henderson @ 2003-10-06 23:17 UTC (permalink / raw) To: gcc, wilson, jason 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. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only. 2003-10-06 23:17 ` Richard Henderson @ 2003-10-06 23:49 ` Carlo Wood 2003-10-07 0:07 ` Richard Henderson 0 siblings, 1 reply; 31+ messages in thread From: Carlo Wood @ 2003-10-06 23:49 UTC (permalink / raw) To: Richard Henderson, gcc, wilson, jason 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> ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only. 2003-10-06 23:49 ` Carlo Wood @ 2003-10-07 0:07 ` Richard Henderson 2003-10-07 0:43 ` Carlo Wood 0 siblings, 1 reply; 31+ messages in thread From: Richard Henderson @ 2003-10-07 0:07 UTC (permalink / raw) To: gcc, wilson, jason 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~ ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only. 2003-10-07 0:07 ` Richard Henderson @ 2003-10-07 0:43 ` Carlo Wood 2003-10-07 0:46 ` Richard Henderson 0 siblings, 1 reply; 31+ messages in thread From: Carlo Wood @ 2003-10-07 0:43 UTC (permalink / raw) To: Richard Henderson, gcc, wilson, jason 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> ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only. 2003-10-07 0:43 ` Carlo Wood @ 2003-10-07 0:46 ` Richard Henderson 2003-10-07 2:40 ` Carlo Wood 2003-10-07 18:32 ` Carlo Wood 0 siblings, 2 replies; 31+ messages in thread From: Richard Henderson @ 2003-10-07 0:46 UTC (permalink / raw) To: gcc, wilson, jason 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~ ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only. 2003-10-07 0:46 ` Richard Henderson @ 2003-10-07 2:40 ` Carlo Wood 2003-10-07 18:32 ` Carlo Wood 1 sibling, 0 replies; 31+ messages in thread From: Carlo Wood @ 2003-10-07 2:40 UTC (permalink / raw) To: Richard Henderson, gcc, wilson, jason 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> ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only. 2003-10-07 0:46 ` Richard Henderson 2003-10-07 2:40 ` Carlo Wood @ 2003-10-07 18:32 ` Carlo Wood 2003-10-07 19:08 ` Carlo Wood 2003-10-07 19:46 ` Richard Henderson 1 sibling, 2 replies; 31+ messages in thread From: Carlo Wood @ 2003-10-07 18:32 UTC (permalink / raw) To: Richard Henderson, gcc, wilson, jason 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> ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only. 2003-10-07 18:32 ` Carlo Wood @ 2003-10-07 19:08 ` Carlo Wood 2003-10-07 19:46 ` Richard Henderson 1 sibling, 0 replies; 31+ messages in thread From: Carlo Wood @ 2003-10-07 19:08 UTC (permalink / raw) To: Richard Henderson, gcc, wilson, jason 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> ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only. 2003-10-07 18:32 ` Carlo Wood 2003-10-07 19:08 ` Carlo Wood @ 2003-10-07 19:46 ` Richard Henderson 2003-10-07 21:12 ` Carlo Wood 1 sibling, 1 reply; 31+ messages in thread From: Richard Henderson @ 2003-10-07 19:46 UTC (permalink / raw) To: gcc, wilson, jason 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~ ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only. 2003-10-07 19:46 ` Richard Henderson @ 2003-10-07 21:12 ` Carlo Wood 2003-10-07 23:43 ` Carlo Wood 0 siblings, 1 reply; 31+ messages in thread From: Carlo Wood @ 2003-10-07 21:12 UTC (permalink / raw) To: Richard Henderson, gcc, wilson, jason 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> ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only. 2003-10-07 21:12 ` Carlo Wood @ 2003-10-07 23:43 ` Carlo Wood 0 siblings, 0 replies; 31+ messages in thread From: Carlo Wood @ 2003-10-07 23:43 UTC (permalink / raw) To: Richard Henderson, gcc, wilson, jason 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> ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only. 2003-10-06 21:55 ` Richard Henderson 2003-10-06 22:30 ` Carlo Wood @ 2003-10-07 19:41 ` Carlo Wood 1 sibling, 0 replies; 31+ messages in thread From: Carlo Wood @ 2003-10-07 19:41 UTC (permalink / raw) To: Richard Henderson, gcc, wilson, jason 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> ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only. 2003-10-06 20:20 ` Richard Henderson 2003-10-06 20:24 ` Daniel Jacobowitz 2003-10-06 21:53 ` Carlo Wood @ 2003-10-12 4:32 ` law 2003-10-12 12:02 ` Daniel Berlin 2 siblings, 1 reply; 31+ messages in thread From: law @ 2003-10-12 4:32 UTC (permalink / raw) To: Richard Henderson; +Cc: gcc, wilson, jason 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only. 2003-10-12 4:32 ` law @ 2003-10-12 12:02 ` Daniel Berlin 0 siblings, 0 replies; 31+ messages in thread From: Daniel Berlin @ 2003-10-12 12:02 UTC (permalink / raw) To: law; +Cc: Richard Henderson, gcc, wilson, jason 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. ^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~2003-10-12 4:07 UTC | newest] Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-09-22 2:31 RFC: debug line info & inlining; patch proposal and request for comments Carlo Wood 2003-09-23 5:33 ` Jim Wilson 2003-09-27 16:38 ` RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only Carlo Wood 2003-10-06 12:58 ` Hans-Peter Nilsson 2003-10-06 17:41 ` Richard Henderson 2003-10-06 17:51 ` Daniel Jacobowitz 2003-10-06 18:03 ` Daniel Berlin 2003-10-06 19:20 ` Carlo Wood 2003-10-06 19:08 ` Carlo Wood 2003-10-06 20:11 ` Richard Henderson 2003-10-06 20:14 ` Daniel Jacobowitz 2003-10-06 20:20 ` Richard Henderson 2003-10-06 20:24 ` Daniel Jacobowitz 2003-10-06 21:54 ` Richard Henderson 2003-10-06 21:53 ` Carlo Wood 2003-10-06 21:55 ` Richard Henderson 2003-10-06 22:30 ` Carlo Wood 2003-10-06 23:17 ` Richard Henderson 2003-10-06 23:49 ` Carlo Wood 2003-10-07 0:07 ` Richard Henderson 2003-10-07 0:43 ` Carlo Wood 2003-10-07 0:46 ` Richard Henderson 2003-10-07 2:40 ` Carlo Wood 2003-10-07 18:32 ` Carlo Wood 2003-10-07 19:08 ` Carlo Wood 2003-10-07 19:46 ` Richard Henderson 2003-10-07 21:12 ` Carlo Wood 2003-10-07 23:43 ` Carlo Wood 2003-10-07 19:41 ` Carlo Wood 2003-10-12 4:32 ` law 2003-10-12 12:02 ` Daniel Berlin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).