This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
| Other format: | [Raw text] | |
This patch fixes PR debug/5271.
The bulk of this patch just replaces each call to "build (CALL_EXPR, ..)"
with a "build_call_expr (..)" (and same for build_nt and build_min_nt).
The new build_call_expr() then builds the call expression by calling
build() again but also adds the current location (the call site) to the
call expression. [ This is achieved in the same way as that 'WFL' works:
'complexity' is used for the linenumber (this is possible because the
'complexity' was 0 throughout the lifetime of a call expression) and
an operands[] element is added to CALL_EXPR for the filename. ]
The rest of the patch causes the call-site location to be outputted as
debugging information in expand_call(), fixing the cases where the call
is part of an inlined statement like the initialization of the parameters
of an inlined function call, for example in code like
"inlined_function (our_call_expr());".
ChangeLog
---------
PR debug/5271, debug/4431
* tree.c (build_call_expr(tree, tree, tree)): Added.
(build_call_expr_nt(tree, tree)): Added.
* cp/tree.c (build_call_expr_min_nt(tree, tree)): Added.
* tree.h (EXPR_CALL_FILENODE(NODE)): Added.
(EXPR_CALL_FILENAME(NODE)): Added.
(EXPR_CALL_LINECOL(NODE)): Added.
(EXPR_CALL_LINENO(NODE)): Added.
(EXPR_CALL_COLNO(NODE)): Added.
(EXPR_CALL_SET_LINECOL(NODE, LINE, COL)): Added.
(build_call_expr): extern declaration.
(build_call_expr_nt): Same.
* cp/cp-tree.h (build_call_expr_min_nt): Same.
* tree.def: Increased number of operands of call_expr with one.
* calls.c (expand_call): Emit line note for call site, using
the EXPR_CALL_* macro's.
* c-common.h (C_EXP_ORIGINAL_CODE): Still return ERROR_MARK
for call expressions now that complexitity is used for the
call site line number.
* builtins.c (build_function_call_expr): Replace call to
build (CALL_EXPR, ...) with build_call_expr (...).
* c-typeck.c (build_function_call): Same.
* expr.c (emit_block_move_via_libcall): Same.
(clear_storage_via_libcall): Same.
* trans.c (tree_transform): Same.
(emit_discriminant_check): Same.
* ada/utils.c (max_size): Same.
* ada/utils2.c (build_call_1_expr): Same.
(build_call_2_expr): Same.
(build_call_0_expr): Same.
(build_call_alloc_dealloc): Same.
* cp/call.c (build_call): Same.
(build_java_interface_fn_ref): Same.
* cp/decl2.c (build_offset_ref_call_from_tree): Same.
* java/builtins.c (java_build_function_call_expr): Same.
* java/decl.c (complete_start_java_method): Same.
* java/expr.c (build_java_athrow): Same.
(encode_newarray_type): Same.
(build_java_array_length_access): Same.
(java_check_reference): Same.
(build_java_arraystore_check): Same.
(build_newarray): Same.
(build_anewarray): Same.
(expand_java_multianewarray): Same.
(expand_java_arrayload): Same.
(expand_java_array_length): Same.
(expand_java_NEW): Same.
(build_instanceof): Same.
(expand_java_CHECKCAST): Same.
(build_java_soft_divmod): Same.
(build_java_binop): Same.
(build_class_init): Same.
(build_class_init): Same.
(build_invokeinterface): Same.
(expand_invoke): Same.
(build_jni_stub): Same.
* java/java-tree.h (BUILD_MONITOR_ENTER): Same.
(BUILD_MONITOR_EXIT): Same.
java/parse.h (BUILD_THROW): Same.
* java/parse.y (java_expand_method_bodies): Same.
(patch_invoke): Same.
(build_this_super_qualified_invocation): Same.
(patch_cast): Same.
(patch_newarray): Same.
(build_assertion): Same.
* treelang/treetree.c (tree_code_get_expression): Same.
* c-objc-common.c (start_cdtor): Replace call to
build_nt (CALL_EXPR, ...) with build_call_expr_nt (...).
* objc/objc-act.c (build_module_descriptor): Same.
(really_start_method): Same.
* c-parse.in: Same.
* cp/lex.c (make_call_declarator): Same.
* cp/semantics.c (finish_call_expr): Same.
(finish_object_call_expr): Same.
(simplify_aggr_init_expr): Same for build/build_call_expr.
* cp/parser.c (cp_parser_postfix_expression): Replace call to
build_min_nt (CALL_EXPR, ...) with build_call_expr_min_nt (...).
Problem Reports
---------------
With this patch, the output of the test case of PR 5271,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5271
is
main:
.LFB3:
.file 1 "libcwd.tst/leak.cc"
.loc 1 21 0
pushl %ebp
.LCFI0:
movl %esp, %ebp
.LCFI1:
subl $8, %esp
.LCFI2:
andl $-16, %esp
.LBB2:
.LBB3:
.LBB4:
.loc 1 22 0
subl $12, %esp
pushl $4
.LCFI3:
call _Znwj
addl $16, %esp
movl (%eax), %eax
.LBB5:
.file 2 "../include/libcw/macro_AllocTag.h"
.loc 2 210 0
addl $1234, %eax
.LBE5:
Giving the correct line (22) for the call to _Znwj now,
and as such fixes this PR.
This is also a follow up on
http://gcc.gnu.org/ml/gcc/2003-09/msg00942.html
The test case given there gives the following result
using this patch:
_Z1fv:
.LFB4:
.file 1 "troep.cc"
.loc 1 20 0
pushl %ebp
.LCFI0:
movl %esp, %ebp
.LCFI1:
subl $56, %esp
.LCFI2:
.LBB2:
.LBB3:
.loc 1 21 0
call _Z1hv
movl %eax, -12(%ebp)
.loc 1 12 0
call _Z1hv
movl %eax, -16(%ebp)
.LBB4:
.loc 1 6 0
movl $12345, -24(%ebp)
.loc 1 13 0
call _Z1hv
movl %eax, -28(%ebp)
.LBB5:
.loc 1 7 0
movl -28(%ebp), %eax
addl -24(%ebp), %eax
addl %eax, a
.LBE5:
.LBE4:
.loc 1 6 0
movl -32(%ebp), %eax
movl %eax, -20(%ebp)
.LBB6:
.LBB7:
.loc 1 15 0
movl $2, -56(%ebp)
movl $3, -52(%ebp)
movl $5, -48(%ebp)
movl $7, -44(%ebp)
.loc 1 16 0
movl -16(%ebp), %eax
addl -12(%ebp), %eax
movl %eax, %edx
addl -20(%ebp), %edx
leal -56(%ebp), %eax
leal (%edx,%eax), %eax
addl %eax, a
.LBE7:
.LBE6:
.LBE3:
.LBE2:
.loc 1 22 0
leave
ret
which is exactly the proposed result with the exception
of the location of the prologue of i() (proposed was line 8,
result gives line 6 - just like it did before this patch).
Memory usage
------------
Using a large and complex C++ compilation unit,
the output with and without this patch of -fmem-report is:
Without:
Size Allocated Used Overhead
8 256k 86k 5888
16 564k 334k 8460
32 1144k 696k 12k
64 2044k 1624k 17k
128 4096 1792 32
256 2388k 2295k 16k
512 1640k 1565k 11k
1024 3128k 3048k 21k
2048 20k 12k 140
4096 4096 4096 28
8192 40k 40k 140
16384 16k 16k 28
32768 416k 416k 364
65536 128k 128k 56
524288 512k 512k 28
108 9236k 8462k 72k
20 6052k 3372k 76k
24 1188k 599k 13k
12 1076k 319k 17k
40 2364k 1793k 23k
Total 31M 24M 297k
32220k
With:
Size Allocated Used Overhead
8 256k 86k 5888
16 564k 334k 8460
32 1356k 860k 14k
64 2048k 1630k 18k
128 4096 1792 32
256 2388k 2295k 16k
512 1640k 1565k 11k
1024 3128k 3048k 21k
2048 20k 12k 140
4096 4096 4096 28
8192 40k 40k 140
16384 16k 16k 28
32768 416k 416k 364
65536 128k 128k 56
524288 512k 512k 28
108 9236k 8462k 72k
20 6052k 3372k 76k
24 1028k 478k 12k
12 1076k 319k 17k
40 2364k 1793k 23k
Total 31M 24M 298k
32276k
Showing an increase of less than 0.2% (56k on 30M).
[A test was performed with adding a location_t
to struct tree_exp, that lead to an increase of 7%].
Rationale
---------
While this treats a CALL_EXPR more or less as
special - and a more general solution is possible -
it was intentionally done so: The more general case
has been implemented in the tree-ssa branch and
doing this work more generally by adding a location_t
to every expression and not only the CALL_EXPR would
increase the memory usage needless because the only
intend is to fix this particular case for the 3.4
release for CALL expressions.
Already this patch adds the location of a CALL_EXPR to
3.4 because calls turn up in the backtrace of debuggers
and are therefore especially important to get right.
Why not use EXPR_WITH_FILE_LOCATION?
------------------------------------
Extensive tests have been performed with using
EXPR_WITH_FILE_LOCATION in order to add a location
to CALL_EXPR. The problem with that approach is
that all of gcc assumes that when two expressions
have different tree codes (TREE_CODE()) then they
are essential different; every expression type
needing specialized handling (for example in order
to do optimization) is explicitely tested on its type.
Nowhere it is taken into account that a WFL that wraps
an expression of type FOO_EXPR should be handled the
same way as if it was an unwrapped FOO_EXPR.
As a result, at the few dozen places in the code where
a CALL_EXPR is handled differently from the arbitrary
expressions, extra code would need to be added to also
test for the EXPR_WITH_FILE_LOCATION in order to handle
the CALL_EXPR within it. It is hard to make sure
all these code instances are found, and it is often
not obvious how to handle it - because just-like-that
unwrapping the CALL_EXPR would only lead to losing the
location infomation prematurely.
Contrary to what one would assume, the
EXPR_WITH_FILE_LOCATION expression is not handled
automatically: at many places operands of expressions
are read and processed immedeately without first passing
it through expand_expr(), the only function that
actually does unwrapping of EXPR_WITH_FILE_LOCATION.
The conclusion is that WFL is not suitable for adding
location info to expressions - as was also the conclusion
of the tree-ssa team when they first tried to use it that
way, according to Daniel Berlin.
Corresponding opinions of others can be found here
http://gcc.gnu.org/ml/gcc/2003-10/msg00409.html
http://gcc.gnu.org/ml/gcc/2003-10/msg00411.html
http://gcc.gnu.org/ml/gcc/2003-10/msg00163.html
Final testing
-------------
The patch was tested to bootstrap (all languages) on i686-gnu-linux.
It did not introduce new failures in the testsuites or in the gdb
testsuite.
Would it be OK to commit this to mainline?
--
Carlo Wood <carlo@alinoe.com>
Attachment:
PR5271.diff
Description: Text document
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |