This is the mail archive of the gcc@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]

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


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>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]