[Bug bootstrap/53249] New: [4.8 Regression] Bootstrap failure

[Bug bootstrap/53249] New: [4.8 Regression] Bootstrap failure

[hjl.tools at gmail dot com]

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

             Bug #: 53249
           Summary: [4.8 Regression] Bootstrap failure
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: bootstrap
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: hjl.tools@gmail.com
                CC: rsandifo@gcc.gnu.org


On Linux/x86-64 with x32 enabled, revision 187199:

http://gcc.gnu.org/ml/gcc-cvs/2012-05/msg00195.html

caused:

../../../../src-trunk/libgomp/barrier.c: In function 'GOMP_barrier':
../../../../src-trunk/libgomp/barrier.c:34:21: internal compiler error: in
plus_constant, at explow.c:88
   struct gomp_team *team = thr->ts.team;
                     ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[12]: *** [barrier.lo] Error 1

[Bug bootstrap/53249] [4.8 Regression] Bootstrap failure

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu <hjl.tools at gmail dot com> 2012-05-05 22:22:27 UTC ---
Created attachment 27322
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27322
A testcase

On Linux/x86-64:

[hjl@gnu-35 gcc]$ ./xgcc -B./ -O2 -mx32 -fPIC -S -ftls-model=initial-exec
/tmp/barrier.i -o /tmp/x.s
../../../../src-trunk/libgomp/barrier.c: In function \u2018GOMP_barrier\u2019:
../../../../src-trunk/libgomp/barrier.c:34:21: internal compiler error: in
plus_constant, at explow.c:88
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
[hjl@gnu-35 gcc]$

[Bug bootstrap/53249] [4.8 Regression] Bootstrap failure

[rsandifo at gcc dot gnu.org]

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

--- Comment #2 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> 2012-05-06 10:55:48 UTC ---
Gah.  Sorry for the breakage.

This is caused by the x86_64 TLS code generating a DImode
MEM address when Pmode == SImode.  As you say here:

  http://gcc.gnu.org/ml/gcc-patches/2012-03/msg01205.html

that's wrong from a pure rtl semantics perspective:
MEM addresses must have the mode given by
targetm.addr_space.address_mode.  Even if having a different
mode happens to work most of the time, I think that's only
by accident.  Your original suggestion avoided this, of course.

I don't understand the constraints you're working under
well enough to suggest anything constructive here, sorry.
I don't know whether it would be possible to model this
as an address space or not.

[Bug bootstrap/53249] [4.8 Regression] Bootstrap failure

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ubizjak at gmail dot com
   Target Milestone|---                         |4.8.0

--- Comment #3 from H.J. Lu <hjl.tools at gmail dot com> 2012-05-06 14:06:20 UTC ---
On x32, Pmode can be either DImode or SImode.
It is incorrect to say "happens to work most of
the time" for x32.  Can you add a target hook to
restore the old behavior?

[Bug bootstrap/53249] [4.8 Regression] Bootstrap failure

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu <hjl.tools at gmail dot com> 2012-05-06 14:28:55 UTC ---
A small testcase:

[hjl@gnu-6 pr53249]$ cat x.i
struct gomp_task
{
  struct gomp_task *parent;
};

struct gomp_thread
{
  int foo1;
  struct gomp_task *task;
};

extern __thread struct gomp_thread gomp_tls_data;

void
__attribute__ ((noinline))
gomp_end_task (void)
{
  struct gomp_thread *thr = &gomp_tls_data;
  struct gomp_task *task = thr->task;

  thr->task = task->parent;
}
[hjl@gnu-6 pr53249]$

[Bug bootstrap/53249] [4.8 Regression] Bootstrap failure

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu <hjl.tools at gmail dot com> 2012-05-06 14:35:26 UTC ---
X32 is a 32bit environment for x86-64:

https://sites.google.com/site/x32abi/

Since there is no x32 mode in hardware, x32 binaries
run in pure 64-bit mode.

[Bug bootstrap/53249] [4.8 Regression] Bootstrap failure

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu <hjl.tools at gmail dot com> 2012-05-06 14:54:10 UTC ---
Can you just use GET_MODE (mem) instead of
targetm.addr_space.address_mode (MEM_ADDR_SPACE (mem))
when you change plus_constant (mem, offset)?
At least, you should allow a backend to do

plus_constant (GET_MODE (mem), mem, offset)

instead of

mode = targetm.addr_space.address_mode (MEM_ADDR_SPACE (mem))

plus_constant (mode, mem, offset)

[Bug bootstrap/53249] [4.8 Regression] Bootstrap failure

[rsandifo at gcc dot gnu.org]

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

rsandifo@gcc.gnu.org <rsandifo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2012-05-06
         AssignedTo|unassigned at gcc dot       |rsandifo at gcc dot gnu.org
                   |gnu.org                     |
     Ever Confirmed|0                           |1

--- Comment #7 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> 2012-05-06 15:06:34 UTC ---
Testing a patch.

[Bug bootstrap/53249] [4.8 Regression] Bootstrap failure

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |UNCONFIRMED
     Ever Confirmed|1                           |0

--- Comment #8 from H.J. Lu <hjl.tools at gmail dot com> 2012-05-06 15:42:09 UTC ---
get_address_mode in dwarf2out.c works for this testcase.

[Bug bootstrap/53249] [4.8 Regression] Bootstrap failure

[rdsandiford at googlemail dot com]

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

--- Comment #9 from rdsandiford at googlemail dot com <rdsandiford at googlemail dot com> 2012-05-06 15:56:09 UTC ---
"hjl.tools at gmail dot com" <gcc-bugzilla@gcc.gnu.org> writes:
> get_address_mode in dwarf2out.c works for this testcase.

Yeah, that's what I was testing FWIW.  If x32 wants to do this,
then pretty much every instance of:

    targetm.addr_space.address_mode (MEM_ADDR_SPACE (mem))

needs to use get_address_mode instead.  So I'm trying to convert all of them.

(There's a duplicate copy in var-tracking.c, so the patch consolidates
them into a general rtl.h function.)

[Bug bootstrap/53249] [4.8 Regression] Bootstrap failure

[hjl.tools at gmail dot com]

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

--- Comment #10 from H.J. Lu <hjl.tools at gmail dot com> 2012-05-06 16:00:35 UTC ---
(In reply to comment #9)
> "hjl.tools at gmail dot com" <gcc-bugzilla@gcc.gnu.org> writes:
> > get_address_mode in dwarf2out.c works for this testcase.
> 
> Yeah, that's what I was testing FWIW.  If x32 wants to do this,
> then pretty much every instance of:
> 
>     targetm.addr_space.address_mode (MEM_ADDR_SPACE (mem))
> 
> needs to use get_address_mode instead.  So I'm trying to convert all of them.

This is the minimum one:

diff --git a/gcc/dse.c b/gcc/dse.c
index 0523757..964804c 100644
--- a/gcc/dse.c
+++ b/gcc/dse.c
@@ -1455,7 +1455,7 @@ record_store (rtx body, bb_info_t bb_info)
       return 0;
     }

-  address_mode = targetm.addr_space.address_mode (MEM_ADDR_SPACE (mem));
+  address_mode = get_address_mode (mem);

   if (GET_MODE (mem) == BLKmode)
     width = MEM_SIZE (mem);
@@ -2181,11 +2181,8 @@ check_mem_read_rtx (rtx *loc, void *data)
       mem_addr = group->canon_base_addr;
     }
       if (offset)
-    {
-      enum machine_mode address_mode
-        = targetm.addr_space.address_mode (MEM_ADDR_SPACE (mem));
-      mem_addr = plus_constant (address_mode, mem_addr, offset);
-    }
+    mem_addr = plus_constant (get_address_mode (mem),
+                  mem_addr, offset);
     }

   /* We ignore the clobbers in store_info.  The is mildly aggressive,
diff --git a/gcc/emit-rtl.c b/gcc/emit-rtl.c
index 25c8ded..9d10bac 100644
--- a/gcc/emit-rtl.c
+++ b/gcc/emit-rtl.c
@@ -2113,7 +2113,7 @@ adjust_address_1 (rtx memref, enum machine_mode mode,
HOST_WIDE_INT offset,
                    plus_constant (address_mode,
                           XEXP (addr, 1), offset));
       else
-    addr = plus_constant (address_mode, addr, offset);
+    addr = plus_constant (get_address_mode (memref), addr, offset);
     }

   new_rtx = change_address_1 (memref, mode, addr, validate);

to build x32 run-time libraries for c,c++,fortran,objc,go.

[Bug bootstrap/53249] [4.8 Regression] Bootstrap failure

[rsandifo at gcc dot gnu.org]

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

--- Comment #11 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> 2012-05-09 09:23:03 UTC ---
Author: rsandifo
Date: Wed May  9 09:22:57 2012
New Revision: 187320

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187320
Log:
gcc/
    PR middle-end/53249
    * dwarf2out.h (get_address_mode): Move declaration to...
    * rtl.h: ...here.
    * dwarf2out.c (get_address_mode): Move definition to...
    * rtlanal.c: ...here.
    * var-tracking.c (get_address_mode): Delete.
    * combine.c (find_split_point): Use get_address_mode instead of
    targetm.addr_space.address_mode.
    * cselib.c (cselib_record_sets): Likewise.
    * dse.c (canon_address, record_store): Likewise.
    * emit-rtl.c (adjust_address_1, offset_address): Likewise.
    * expr.c (move_by_pieces, emit_block_move_via_loop, store_by_pieces)
    (store_by_pieces_1, expand_assignment, store_expr, store_constructor)
    (expand_expr_real_1): Likewise.
    * ifcvt.c (noce_try_cmove_arith): Likewise.
    * optabs.c (maybe_legitimize_operand_same_code): Likewise.
    * reload.c (find_reloads): Likewise.
    * sched-deps.c (sched_analyze_1, sched_analyze_2): Likewise.
    * sel-sched-dump.c (debug_mem_addr_value): Likewise.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/combine.c
    trunk/gcc/cselib.c
    trunk/gcc/dse.c
    trunk/gcc/dwarf2out.c
    trunk/gcc/dwarf2out.h
    trunk/gcc/emit-rtl.c
    trunk/gcc/expr.c
    trunk/gcc/ifcvt.c
    trunk/gcc/optabs.c
    trunk/gcc/reload.c
    trunk/gcc/rtl.h
    trunk/gcc/rtlanal.c
    trunk/gcc/sched-deps.c
    trunk/gcc/sel-sched-dump.c
    trunk/gcc/var-tracking.c

[Bug bootstrap/53249] [4.8 Regression] Bootstrap failure

[rsandifo at gcc dot gnu.org]

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

rsandifo@gcc.gnu.org <rsandifo at gcc dot gnu.org> changed:

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

--- Comment #12 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> 2012-05-09 09:24:16 UTC ---
Patch applied.

[Bug bootstrap/53249] [4.8 Regression] Bootstrap failure

[hjl at gcc dot gnu.org]

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

--- Comment #13 from hjl at gcc dot gnu.org <hjl at gcc dot gnu.org> 2012-05-09 13:32:22 UTC ---
Author: hjl
Date: Wed May  9 13:32:13 2012
New Revision: 187331

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187331
Log:
Add a test for PR middle-end/53249

    PR middle-end/53249
    * gcc.target/i386/pr53249.c: New.

Added:
    trunk/gcc/testsuite/gcc.target/i386/pr53249.c
Modified:
    trunk/gcc/testsuite/ChangeLog