[Bug libgcj/40867] New: [4.5 Regression] FAIL: StackTrace2 output - source compiled test

Executing on host:
/home/dave/gnu/gcc/objdir/hppa-linux/libjava/testsuite/../libtool --silent
--tag=GCJ --mode=link /home/dave/gnu/gcc/objdir/./gcc/gcj
-B/home/dave/gnu/gcc/objdir/hppa-linux/libjava/
-B/home/dave/gnu/gcc/objdir/./gcc/ -B/ho
me/dave/opt/gnu/gcc/gcc-4.5.0/hppa-linux/bin/
-B/home/dave/opt/gnu/gcc/gcc-4.5.0/hppa-linux/lib/ -isystem
/home/dave/opt/gnu/gcc/gcc-4.5.0/hppa-linux/include -isystem
/home/dave/opt/gnu/gcc/gcc-4.5.0/hppa-linux/sys-include    --encoding=UTF-8
-B/home/dave/gnu/gcc/objdir/hppa-linux/libjava/testsuite/../
/home/dave/gnu/gcc/gcc/libjava/testsuite/libjava.lang/StackTrace2.jar  -w
-specs=libgcj-test.spec -no-install --main=StackTrace2 -g
-L/home/dave/gnu/gcc/objdir/hppa-linux/./libjava/.libs -lm   -o
/home/dave/gnu/gcc/objdir/hppa-linux/libjava/testsuite/StackTrace2.exe  
(timeout = 300)PASS: StackTrace2 compilation from
sourceset_ld_library_path_env_vars:
ld_library_path=.:/home/dave/gnu/gcc/objdir/hppa-linux/./libjava/.libs:/home/dave/gnu/gcc/objdir/gcc
invoke: /home/dave/gnu/gcc/objdir/hppa-linux/libjava/testsuite/StackTrace2.exe  
Setting LD_LIBRARY_PATH to
.:/home/dave/gnu/gcc/objdir/hppa-linux/./libjava/.libs:/home/dave/gnu/gcc/objdir/gcc:.:/home/dave/gnu/gcc/objdir/hppa-linux/./libjava
/.libs:/home/dave/gnu/gcc/objdir/gcc:/home/dave/gnu/gcc/objdir/hppa-linux/libstd
c++-v3/.libs:/home/dave/gnu/gcc/objdir/hppa-linux/libmudflap/.libs:/home/dave/gnu/gcc/objdir/hppa-linux/libssp/.libs:/home/dave/gnu/gcc/objdir/hppa-linux/libgomp/.libs:/home/dave/gnu/gcc/objdir/./gcc:/home/dave/gnu/gcc/objdir/./prev-gccTrace
length = 4StackTrace2$Inner.doCrash:FAIL - expected 33, got: 34, in file
StackTrace2.javaStackTrace2$Inner.foo:OK
StackTrace2.a:OK
StackTrace2.main:OK
PASS: StackTrace2 execution - source compiled test
FAIL: StackTrace2 output - source compiled test

Also, the following fail in the same way:

FAIL: StackTrace2 -findirect-dispatch output - source compiled test
FAIL: StackTrace2 -O3 output - source compiled test
FAIL: StackTrace2 -O3 -findirect-dispatch output - source compiled test


--
           Summary: [4.5 Regression] FAIL: StackTrace2 output - source
                    compiled test
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libgcj
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa*-*-* (32 bit)
  GCC host triplet: hppa*-*-* (32 bit)
GCC target triplet: hppa*-*-* (32 bit)


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40867

------- Comment #1 from hjl dot tools at gmail dot com  2009-07-27 19:07 -------
I also see it on Linux/x86. It is an known issue:

http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00266.html


--

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hjl dot tools at gmail dot
                   |                            |com, rguenth at gcc dot gnu
                   |                            |dot org, aph at redhat dot
                   |                            |com
  GCC build triplet|hppa*-*-* (32 bit)          |
   GCC host triplet|hppa*-*-* (32 bit)          |
 GCC target triplet|hppa*-*-* (32 bit)          |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40867

------- Comment #2 from aph at gcc dot gnu dot org  2009-07-28 08:02 -------
This is actually a regression in debuginfo: the line number info is being
corrupted, somewhere after the front end.  I don't know if this was caused by
the gimplify unit-at-a-time patch.


--

aph at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
          Component|libgcj                      |middle-end
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2009-07-28 08:02:23
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40867

--

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4
   Target Milestone|---                         |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40867

------- Comment #3 from aph at gcc dot gnu dot org  2009-07-30 07:37 -------
This regression in debuginfo seems to have been downgraded to P4, with no
explanation or discussion of which I'm aware.


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40867

------- Comment #4 from joseph at codesourcery dot com  2009-07-30 11:24 -------
Subject: Re:  [4.5 Regression] FAIL: StackTrace2 output
 - source compiled test

On Thu, 30 Jul 2009, aph at gcc dot gnu dot org wrote:

> This regression in debuginfo seems to have been downgraded to P4, with no
> explanation or discussion of which I'm aware.

Java issues are not release-critical.  Restore to P3 if you have a C or
C++ test showing the problem.


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40867

------- Comment #5 from aph at gcc dot gnu dot org  2009-07-30 11:36 -------
Hmm, this seems to me as a rather perverse interpretation of the rule that
"Java issues are not release-critical": this bug may be manifested in Java
programs, but there is no evidence of which I'm aware that this specifically is
a Java issue.

It seems to be coincident with the gimplify unit-at-a-time patch.

I'll try to figure out what is going wrong.


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40867

------- Comment #6 from aph at gcc dot gnu dot org  2009-07-30 17:24 -------
This seems to be happening very early, because the very first tree dump shows:

StackTrace2$Inner.doCrash(java.lang.Object) (struct StackTrace2$Inner * this,
struct java.lang.Object * o)
[StackTrace2.java : 0:0] {
  struct java.lang.Object * #ref#2#2.146;
  struct
{
  struct java.lang.Class * class;
  void * methods[2];
} * D.1837;
  void * * D.1838;
  void * D.1839;
  struct java.lang.String * java.lang.Object::<Tb5> (struct java.lang.Object *)
* D.1840;

  [StackTrace2.java : 34:0] {
    void * #ref#1#0;
    struct java.lang.Object * D.252;
    void * #ref#2#2;

    [StackTrace2.java : 33:0] D.252 = o;
    [StackTrace2.java : 34:0] #ref#2#2 = D.252;
    [StackTrace2.java : 34:0] #ref#2#2.146 = (struct java.lang.Object *)
#ref#2#2;
    [StackTrace2.java : 34:0] D.1837 = #ref#2#2.146->vtable;
    [StackTrace2.java : 34:0] D.1838 = &D.1837->methods[4];
    ...

All this code should be marked as Line 33, not line 34.  I don't know
why this has changed recently.


--

aph at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |aph at gcc dot gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40867

------- Comment #7 from rguenther at suse dot de  2009-07-31 09:19 -------
Subject: Re:  [4.5 Regression] FAIL: StackTrace2 output
 - source compiled test

On Thu, 30 Jul 2009, aph at gcc dot gnu dot org wrote:

> ------- Comment #6 from aph at gcc dot gnu dot org  2009-07-30 17:24 -------
> This seems to be happening very early, because the very first tree dump shows:
>
> StackTrace2$Inner.doCrash(java.lang.Object) (struct StackTrace2$Inner * this,
> struct java.lang.Object * o)
> [StackTrace2.java : 0:0] {
>   struct java.lang.Object * #ref#2#2.146;
>   struct
> {
>   struct java.lang.Class * class;
>   void * methods[2];
> } * D.1837;
>   void * * D.1838;
>   void * D.1839;
>   struct java.lang.String * java.lang.Object::<Tb5> (struct java.lang.Object *)
> * D.1840;
>
>   [StackTrace2.java : 34:0] {
>     void * #ref#1#0;
>     struct java.lang.Object * D.252;
>     void * #ref#2#2;
>
>     [StackTrace2.java : 33:0] D.252 = o;
>     [StackTrace2.java : 34:0] #ref#2#2 = D.252;
>     [StackTrace2.java : 34:0] #ref#2#2.146 = (struct java.lang.Object *)
> #ref#2#2;
>     [StackTrace2.java : 34:0] D.1837 = #ref#2#2.146->vtable;
>     [StackTrace2.java : 34:0] D.1838 = &D.1837->methods[4];
>     ...
>
> All this code should be marked as Line 33, not line 34.  I don't know
> why this has changed recently.

Could it be now that all the java_replace_references is done at
a different time we fail to properly update / copy locations in
that function?  I don't see that it changed really, and nothing
uses locators there before or after the patch, but ... certainly
the MODIFY_EXPR doesn't get its location copied from the original
one.

So, maybe the following would make a difference?  (untested)

Index: decl.c
===================================================================
--- decl.c      (revision 150221)
+++ decl.c      (working copy)
@@ -361,9 +361,10 @@ java_replace_references (tree *tp, int *
          tree new_lhs = java_replace_reference (lhs, /* want_lvalue */
true);
          tree new_rhs = build1 (NOP_EXPR, TREE_TYPE (new_lhs),
                                 TREE_OPERAND (*tp, 1));
-         *tp = build2 (MODIFY_EXPR, TREE_TYPE (new_lhs),
-                       new_lhs, new_rhs);
-         *tp = build1 (NOP_EXPR, TREE_TYPE (lhs), *tp);
+         tree tem = build2 (MODIFY_EXPR, TREE_TYPE (new_lhs),
+                            new_lhs, new_rhs);
+         SET_EXPR_LOCATION (tem, EXPR_LOCATION (*tp));
+         *tp = build1 (NOP_EXPR, TREE_TYPE (lhs), tem);
        }
     }
   if (TREE_CODE (*tp) == VAR_DECL)


Richard.


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40867

------- Comment #8 from aph at gcc dot gnu dot org  2009-08-03 17:55 -------
Subject: Bug 40867

Author: aph
Date: Mon Aug  3 17:55:11 2009
New Revision: 150376

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150376
Log:
2009-07-31  Andrew Haley  <aph@...>

        PR java/40867
        * decl.c (java_replace_references): Set EXPR_LOCATION on all
        generated expressions.
        (binding_level.loc): new field.
        (clear_binding_level): Initialize loc.
        (set_input_location): New function.
        (pushlevel): Set new binding_level.loc.
        (poplevel): Set EXPR_LOCATION on the new BIND_EXPR_BODY.
        (start_java_method): Set DECL_SOURCE_LOCATION of this new method.
        (java_add_stmt): Set the EXPR_LOCATION on all subtrees of new_stmt.


Modified:
    trunk/gcc/java/ChangeLog
    trunk/gcc/java/decl.c


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40867

------- Comment #9 from hjl dot tools at gmail dot com  2009-08-24 15:48 -------
Fixed:

http://gcc.gnu.org/ml/gcc-testresults/2009-08/msg02467.html


--

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40867