[Bug bootstrap/35373] New: [4.4 Regression] bootstraping on powerpc-apple-darwin9 fails with revision 132578

[Bug bootstrap/35373] New: [4.4 Regression] bootstraping on powerpc-apple-darwin9 fails with revision 132578

[dominiq at lps dot ens dot fr]

As reported in http://gcc.gnu.org/ml/gcc-patches/2008-02/msg01134.html,
bootstraping on powerpc-apple-darwin9 fails with revision 132578:

...
libtool: compile:  /opt/gcc/darwin_buildw/./gcc/xgcc
-B/opt/gcc/darwin_buildw/./gcc/ -B/opt/gcc/gcc4.4w/powerpc-apple-darwin9/bin/
-B/opt/gcc/gcc4.4w/powerpc-apple-darwin9/lib/ -isystem
/opt/gcc/gcc4.4w/powerpc-apple-darwin9/include -isystem
/opt/gcc/gcc4.4w/powerpc-apple-darwin9/sys-include -DHAVE_CONFIG_H -I.
-I../../../gcc-4.4-work/libgfortran -I.
-iquote../../../gcc-4.4-work/libgfortran/io
-I../../../gcc-4.4-work/libgfortran/../gcc
-I../../../gcc-4.4-work/libgfortran/../gcc/config -I../.././gcc -D_GNU_SOURCE
-std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wextra -Wwrite-strings -g -O2 -MT maxloc1_4_r16.lo -MD
-MP -MF .deps/maxloc1_4_r16.Tpo -c
../../../gcc-4.4-work/libgfortran/generated/maxloc1_4_r16.c  -fno-common -DPIC
-o .libs/maxloc1_4_r16.o
../../../gcc-4.4-work/libgfortran/generated/maxloc1_4_r16.c: In function
'mmaxloc1_4_r16':
../../../gcc-4.4-work/libgfortran/generated/maxloc1_4_r16.c:220: internal
compiler error: in memory_address, at explow.c:492
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[3]: *** [maxloc1_4_r16.lo] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-target-libgfortran] Error 2
make: *** [all] Error 2

The build completes if I remove the line 492 in explow.c.


-- 
           Summary: [4.4 Regression] bootstraping on powerpc-apple-darwin9
                    fails with revision 132578
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: bootstrap
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: dominiq at lps dot ens dot fr
 GCC build triplet: powerpc-apple-darwin9
  GCC host triplet: powerpc-apple-darwin9
GCC target triplet: powerpc-apple-darwin9


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

[Bug target/35373] [4.4 Regression] bootstraping on powerpc-apple-darwin9 fails with revision 132578

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|bootstrap                   |target
           Keywords|                            |build
   Target Milestone|---                         |4.4.0


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

[Bug target/35373] [4.4 Regression] bootstraping on powerpc-apple-darwin9 fails with revision 132578

[eres at il dot ibm dot com]

------- Comment #1 from eres at il dot ibm dot com  2008-02-27 10:03 -------
Same error was received on powerpc64-linux, trunk r132684

configured with:
--with-cpu=default32  --enable-checking --enable-bootstrap


-- 


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

[Bug target/35373] [4.4 Regression] bootstraping on powerpc-apple-darwin9 fails with revision 132578

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |blocker
  GCC build triplet|powerpc-apple-darwin9       |
   GCC host triplet|powerpc-apple-darwin9       |
 GCC target triplet|powerpc-apple-darwin9       |powerpc*-*-*


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

[Bug target/35373] [4.4 Regression] bootstraping on powerpc-apple-darwin9 fails with revision 132578

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2008-02-29 07:26 -------
Because I am lazy and I don't have access right now to my ppc box, could
someone attach the preprocessed source?


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org


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

[Bug target/35373] [4.4 Regression] bootstraping on powerpc-apple-darwin9 fails with revision 132578

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2008-03-01 01:55 -------
*** Bug 35414 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jvdelisle at gcc dot gnu dot
                   |                            |org


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

[Bug target/35373] [4.4 Regression] bootstraping on powerpc-apple-darwin9 fails with revision 132578

[fxcoudert at gcc dot gnu dot org]

------- Comment #4 from fxcoudert at gcc dot gnu dot org  2008-03-02 18:05 -------
Here's the preprocessed source, reduced on ppc-darwin:

void maxloc1_4_r16 ()
{
  int n, result, *dest;
  long double *src, maxval;

  for (n = 0; n < 10; n++, src++)
    if (*src > maxval)
      result++;

  *dest = result;
}

It compiles at -O0 but fails at -O1. The backtrace is:

#0  fancy_abort (file=0x755644
"/var/tmp/gfortran-20080302/ibin/../gcc/gcc/explow.c", line=492,
function=0x856e04 "memory_address") at
/var/tmp/gfortran-20080302/ibin/../gcc/gcc/diagnostic.c:664
#1  0x0025f428 in memory_address (mode=TFmode, x=0x40db2370) at
/var/tmp/gfortran-20080302/ibin/../gcc/gcc/explow.c:492
#2  0x0055410c in get_computation_cost_at (data=<value temporarily unavailable,
due to optimizations>, use=<value temporarily unavailable, due to
optimizations>, cand=<value temporarily unavailable, due to optimizations>,
address_p=<value temporarily unavailable, due to optimizations>,
depends_on=<value temporarily unavailable, due to optimizations>, at=<value
temporarily unavailable, due to optimizations>) at
/var/tmp/gfortran-20080302/ibin/../gcc/gcc/tree-ssa-loop-ivopts.c:3066
#3  0x00554850 in determine_use_iv_cost (data=0xbffff558, use=0x40c10070,
cand=0x40c100d0) at
/var/tmp/gfortran-20080302/ibin/../gcc/gcc/tree-ssa-loop-ivopts.c:3616
#4  0x00554e30 in determine_use_iv_costs (data=0xbffff558) at
/var/tmp/gfortran-20080302/ibin/../gcc/gcc/tree-ssa-loop-ivopts.c:3888
#5  0x00558dac in tree_ssa_iv_optimize_loop (data=0xbffff558, loop=<value
temporarily unavailable, due to optimizations>) at
/var/tmp/gfortran-20080302/ibin/../gcc/gcc/tree-ssa-loop-ivopts.c:5453
#6  0x00559aa4 in tree_ssa_iv_optimize () at
/var/tmp/gfortran-20080302/ibin/../gcc/gcc/tree-ssa-loop-ivopts.c:5501
#7  0x0056a9e8 in tree_ssa_loop_ivopts () at
/var/tmp/gfortran-20080302/ibin/../gcc/gcc/tree-ssa-loop.c:550

and the lines around the failed assert:

(gdb) l 490
485              the register is a valid address.  */
486           else
487             x = force_reg (Pmode, x);
488         }
489
490      done:
491
492       gcc_assert (memory_address_p (mode, x));
493       /* If we didn't change the address, we are done.  Otherwise, mark
494          a reg as a pointer if we have REG or REG + CONST_INT.  */
(gdb) p mode
$4 = TFmode
(gdb) p debug_rtx(x)
(plus:SI (reg:SI 119)
    (reg/f:SI 119))
$5 = void
(gdb) p memory_address_p (mode, x) 
$6 = 0


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fxcoudert at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2008-03-02 18:05:04
               date|                            |


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

[Bug target/35373] [4.4 Regression] bootstraping on powerpc-apple-darwin9 fails with revision 132578

[joseph at codesourcery dot com]

------- Comment #5 from joseph at codesourcery dot com  2008-03-02 19:01 -------
Subject: Re:  [4.4 Regression] bootstraping on
 powerpc-apple-darwin9 fails with revision 132578

On Sun, 2 Mar 2008, fxcoudert at gcc dot gnu dot org wrote:

> (gdb) p mode
> $4 = TFmode
> (gdb) p debug_rtx(x)
> (plus:SI (reg:SI 119)
>     (reg/f:SI 119))

reg+reg isn't valid for TFmode (because reg+reg+offset isn't valid for the 
second half).  My guess would be that in rs6000_legitimize_address

  else if (GET_CODE (x) == PLUS
           && GET_CODE (XEXP (x, 0)) == REG
           && GET_CODE (XEXP (x, 1)) != CONST_INT
           && GET_MODE_NUNITS (mode) == 1
           && ((TARGET_HARD_FLOAT && TARGET_FPRS)
               || TARGET_POWERPC64
               || (((mode != DImode && mode != DFmode && mode != DDmode)
                    || TARGET_E500_DOUBLE)
                   && mode != TFmode && mode != TDmode))
           && (TARGET_POWERPC64 || mode != DImode)
           && mode != TImode)

should disallow TFmode like it disallows TImode.


-- 


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

[Bug target/35373] [4.4 Regression] bootstraping on powerpc-apple-darwin9 fails with revision 132578

[fxcoudert at gcc dot gnu dot org]

------- Comment #6 from fxcoudert at gcc dot gnu dot org  2008-03-02 19:11 -------
(In reply to comment #5)
> My guess would be that in rs6000_legitimize_address

So maybe a likely culprit would be:

2008-02-22  Nathan Froyd  <froydnj@codesourcery.com>

        * config/rs6000/rs6000.c (rs6000_legitimize_address): Check to
        ensure that we can address an entire entity > 8 bytes.  Don't
        generate reg+reg addressing for such data.

Another rs6000 patch in this span of time is:

2008-02-23  David Edelsohn  <edelsohn@gnu.org>

        * config/rs6000/rs6000.h (CONSTANT_ALIGNMENT): Use STRICT_ALIGNMENT
        instead of TARGET_STRICT_ALIGN.

(plus the patches adding support for new models, but they shouldn't make a
difference). 


-- 


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

[Bug target/35373] [4.4 Regression] bootstraping on powerpc-apple-darwin9 fails with revision 132578

[joseph at codesourcery dot com]

------- Comment #7 from joseph at codesourcery dot com  2008-03-02 19:52 -------
Subject: Re:  [4.4 Regression] bootstraping on
 powerpc-apple-darwin9 fails with revision 132578

On Sun, 2 Mar 2008, fxcoudert at gcc dot gnu dot org wrote:

> So maybe a likely culprit would be:
> 
> 2008-02-22  Nathan Froyd  <froydnj@codesourcery.com>
> 
>         * config/rs6000/rs6000.c (rs6000_legitimize_address): Check to
>         ensure that we can address an entire entity > 8 bytes.  Don't
>         generate reg+reg addressing for such data.

That patch is fixing a problem for SPE similar to the problem this bug 
reports for classic hard-float.


-- 


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

[Bug target/35373] [4.4 Regression] bootstraping on powerpc-apple-darwin9 fails with revision 132578

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1


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

[Bug target/35373] [4.4 Regression] bootstraping on powerpc-apple-darwin9 fails with revision 132578

[bergner at gcc dot gnu dot org]

------- Comment #8 from bergner at gcc dot gnu dot org  2008-03-04 05:25 -------
Created an attachment (id=15256)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15256&action=view)
Disallow TFmode and TDmode from reg+reg addressing

This ICE is similar to the one Nathan fixed which is caused by the new 
gcc_assert Joseph added here:

  http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01959.html

I agree with Joseph's suggestion from Comment #5 that we need to disallow
TFmode (and TDmode) similar to Nathan's patch.  This patch fixes the ICE
on the test case.  I'm running a full bootstrap with it now on powerpc64-linux.

        * config/rs6000/rs6000.c (rs6000_legitimize_address): Don't generate
        reg+reg addressing for TFmode or TDmode quantities.


-- 

bergner at gcc dot gnu dot org changed:

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


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

[Bug target/35373] [4.4 Regression] bootstraping on powerpc with 128bit long double fails with revision 132578

[pinskia at gcc dot gnu dot org]

------- Comment #9 from pinskia at gcc dot gnu dot org  2008-03-05 16:01 -------
*** Bug 35473 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dir at lanl dot gov


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

[Bug target/35373] [4.4 Regression] bootstraping on powerpc with 128bit long double fails with revision 132578

[bergner at gcc dot gnu dot org]

------- Comment #10 from bergner at gcc dot gnu dot org  2008-03-07 04:15 -------
Created an attachment (id=15276)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15276&action=view)
Updated patch to disallow TFmode and TDmode from reg+reg addressing      

Here is an updated patch that not only fixes the bootstrap issue, but also
fixes a regression of the vect-64.c test case, both of which were being caught
by the new gcc_assert added by Joseph.


-- 

bergner at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #15256|0                           |1
        is obsolete|                            |


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

[Bug target/35373] [4.4 Regression] bootstraping on powerpc with 128bit long double fails with revision 132578

[ubizjak at gmail dot com]

------- Comment #11 from ubizjak at gmail dot com  2008-03-07 07:06 -------
(In reply to comment #10)
> Created an attachment (id=15276)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15276&action=view) [edit]
> Updated patch to disallow TFmode and TDmode from reg+reg addressing      
> 
> Here is an updated patch that not only fixes the bootstrap issue, but also
> fixes a regression of the vect-64.c test case, both of which were being caught
> by the new gcc_assert added by Joseph.

Is there a reason why you don't use GET_MODE_SIZE (mode) != N in the
expression?


-- 


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

[Bug target/35373] [4.4 Regression] bootstraping on powerpc with 128bit long double fails with revision 132578

[bergner at gcc dot gnu dot org]

------- Comment #12 from bergner at gcc dot gnu dot org  2008-03-07 15:21 -------
Subject: Bug 35373

Author: bergner
Date: Fri Mar  7 15:20:31 2008
New Revision: 133008

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133008
Log:
        PR target/35373
        * config/rs6000/rs6000.c (rs6000_legitimize_address): Don't generate
        reg+const addressing for Altivec modes.  Don't generate reg+reg
        addressing for TFmode or TDmode quantities.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/rs6000/rs6000.c


-- 


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

[Bug target/35373] [4.4 Regression] bootstraping on powerpc with 128bit long double fails with revision 132578

[bergner at gcc dot gnu dot org]

------- Comment #13 from bergner at gcc dot gnu dot org  2008-03-07 15:44 -------
(In reply to comment #11)
> Is there a reason why you don't use GET_MODE_SIZE (mode) != N in the
> expression?

Well, the T[IFD]mode don't allow reg+reg addressing, but other 8 byte modes
do (eg, V4SImode).


-- 

bergner at gcc dot gnu dot org changed:

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


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

[Bug target/35373] [4.4 Regression] bootstraping on powerpc with 128bit long double fails with revision 132578

[pinskia at gcc dot gnu dot org]

------- Comment #14 from pinskia at gcc dot gnu dot org  2008-03-08 15:51 -------
*** Bug 35510 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schwab at suse dot de


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

[Bug target/35373] [4.4 Regression] bootstraping on powerpc with 128bit long double fails with revision 132578

[pinskia at gcc dot gnu dot org]

------- Comment #15 from pinskia at gcc dot gnu dot org  2008-09-28 23:17 -------
I came up with the same patch for the Altivec modes when doing the merge of the
PS3 compiler to a 4.3 based compiler.

-- Pinski


-- 


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