[PATCH] Set correct source location for deallocator calls

Richard Henderson rth@redhat.com
Thu Aug 30 14:28:00 GMT 2012


On 08/17/2012 03:02 PM, Dehao Chen wrote:
> I spend a whole day working on this, but find it very difficult to add
> such a java test because:
> 
> * First, libjava testsuits are all runtime tests, i.e., it compiles
> the byte code to native code, execute it, and compares the output to
> expected output. There is no way to scan the assembly.
> * Though there is a way to derive the line number at runtime in java
> (using Exception().getStackTrace()), this method only works on VM, and
> the gcj generated native code does not get the lineno.
> 
> Any suggestions on this?

Hmm, not from me, unfortunately.  Cc'ing the java list for clues.
I won't hang up the main patch for this though.

>> BTW, for the future, please fix your mailer to not wrap lines.
> 
> Okay, I'll try. The problem is that we have to send mail in plain txt.
> And in "plain text mode" gmail wraps each line to 80 characters and
> wouldn't allow you change that...

In that case use a text/plain attachment (which, not having tried it myself,
may require you use a .txt suffix on the patch file).  Most mail readers will
show those inline.  It's certainly better than having actually corrupt data
sent to the list.

> +// { dg-options "-O2 -fno-exceptions -g -dA" }
...
> +// { dg-final { scan-assembler "1 28 0" } }

You're still scanning for the .loc line, not the "test.c:28"
comment added by -dA.

To understand the problem, go back to your build tree, edit
auto-host.h and undefine HAVE_AS_DWARF2_DEBUG_LINE.  Then
rerun the testsuite with RUNTESTFLAGS=dwarf2.exp.

> +	    /* Calls to destructors are generated automatically in FINALL/CATCH
> +	       block. They should have location as UNKNOWN_LOCATION. However,
> +	       gimplify_call_expr will reset these call stmts to input_location
> +	       if it finds stmt's location is unknown. To prevent resetting for
> +	       destructors, we set the input_location to unknown.
> +	       Note that this only affects the destructor calls in FINALL/CATCH
> +	       block, and will automatically reset to its original value by the
> +	       end of gimplify_expr.  */

s/FINALL/FINALLY/g


r~



More information about the Java mailing list