[Bug middle-end/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3

[Bug middle-end/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |meissner at gcc dot gnu.org

--- Comment #53 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2010-11-22 10:01:21 UTC ---
This PR has been fixed by revision 166947

Revision 166947

Jump to revision:         
Author:    meissner
Date:    Fri Nov 19 17:27:18 2010 UTC (2 days, 16 hours ago)
Changed paths:    25
Log Message:    
Add PowerPC target attribute/pragma support
Changed paths:

Path    Details
trunk/gcc/ChangeLog    modified , text changed
trunk/gcc/Makefile.in    modified , text changed
trunk/gcc/config/rs6000/aix.opt    modified , text changed
trunk/gcc/config/rs6000/aix64.opt    modified , text changed
trunk/gcc/config/rs6000/linux64.h    modified , text changed
trunk/gcc/config/rs6000/linux64.opt    modified , text changed
trunk/gcc/config/rs6000/rs6000-opts.h    added
trunk/gcc/config/rs6000/rs6000-protos.h    modified , text changed
trunk/gcc/config/rs6000/rs6000.c    modified , text changed
trunk/gcc/config/rs6000/rs6000.h    modified , text changed
trunk/gcc/config/rs6000/rs6000.opt    modified , text changed
trunk/gcc/config/rs6000/sysv4.h    modified , text changed
trunk/gcc/config/rs6000/sysv4.opt    modified , text changed
trunk/gcc/configure    modified , text changed
trunk/gcc/configure.ac    modified , text changed
trunk/gcc/doc/extend.texi    modified , text changed
trunk/gcc/doc/invoke.texi    modified , text changed
trunk/gcc/doc/options.texi    modified , text changed
trunk/gcc/opt-include.awk    added
trunk/gcc/optc-gen.awk    modified , text changed
trunk/gcc/opth-gen.awk    modified , text changed
trunk/gcc/testsuite/ChangeLog    modified , text changed
trunk/gcc/testsuite/gcc.target/powerpc/ppc-target-1.c    added
trunk/gcc/testsuite/gcc.target/powerpc/ppc-target-2.c    added
trunk/gcc/testsuite/gcc.target/powerpc/ppc-target-3.c    added

Before I close the PR as fixed, is anyone interested to understand why this
revision fixed it?

[Bug middle-end/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #54 from Jakub Jelinek <jakub at gcc dot gnu.org> 2010-11-26 15:20:37 UTC ---
Perhaps try to build with r166946 and r166947 the testcase with -fdump-tree-all
-fdump-rtl-all, see where the dumps start diverging and what is the difference
between assembly outputs?

[Bug middle-end/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3

[dominiq at lps dot ens.fr]

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

--- Comment #55 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2010-11-26 15:48:44 UTC ---
> Perhaps try to build with r166946 and r166947 the testcase with -fdump-tree-all
> -fdump-rtl-all, see where the dumps start diverging and what is the difference
> between assembly outputs?

First difference is the following!-(

diff 166946/0/where_2.f90.003t.original 166947/0/where_2.f90.003t.original
183c183
<       integer(kind=4) D.1181;
---
>       integer(kind=4) D.1179;
199c199
<       D.1181 = val.27;
---
>       D.1179 = val.27;
209c209
<                 temp[S.29 + -1] = temp[S.29 + -1] + D.1181;
---
>                 temp[S.29 + -1] = temp[S.29 + -1] + D.1179;

How am I supposed to go further?

[Bug middle-end/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3

[jakub at gcc dot gnu.org]

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

--- Comment #56 from Jakub Jelinek <jakub at gcc dot gnu.org> 2010-11-26 16:20:18 UTC ---
That is an unimportant difference.  It is fine if a different uid is used, as
long as it used consistently through the whole source.
You can -fdump-tree-all-nouid and -fdump-rtl-all-nouid alternatively and look
for differences in that case.

[Bug middle-end/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3

[dominiq at lps dot ens.fr]

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

--- Comment #57 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2010-11-26 16:54:08 UTC ---
> That is an unimportant difference.  It is fine if a different uid is used, as
> long as it used consistently through the whole source.

I understand, but it make the diff of ~200 files impractical.

> You can -fdump-tree-all-nouid and -fdump-rtl-all-nouid alternatively and look
> for differences in that case.

Then I can go a little further to

diff 166946/where_2.f90.025t.ealias 166947/where_2.f90.025t.ealias
23,24c23,24
< D.1218_25 = S.0_1
< D.1218_25 = &NONLOCAL
---
> D.1216_25 = S.0_1
> D.1216_25 = &NONLOCAL
...

diff 166946/where_2.f90.191r.sched1 166947/where_2.f90.191r.sched1
16c16
< ;;      0-->    19 r440=0                           
:ppc750_du,iu1_7xx|iu2_7xx
---
> ;;      0-->    19 r440=0                            :iu1_6xx|iu2_6xx
20c20
< ;;      1-->    47 [sfp+0x54]=r440#3                 :ppc750_du,lsu_7xx
---
> ;;      1-->    47 [sfp+0x54]=r440#3                 :lsu_6xx
24c24
< ;;      2-->     9 r435=0xa                         
:ppc750_du,iu1_7xx|iu2_7xx
---
> ;;      2-->     9 r435=0xa                          :iu1_6xx|iu2_6xx
28c28
< ;;      3-->    99 r885=[sfp+0x54]                   :ppc750_du,lsu_7xx
---
> ;;      3-->    13 r437=0xffffffffffffffff           :iu1_6xx|iu2_6xx
32c32
< ;;      4-->    13 r437=0xffffffffffffffff          
:ppc750_du,iu1_7xx|iu2_7xx
---
> ;;      4-->    99 r885=[sfp+0x54]                   :lsu_6xx
36c36
< ;;      5-->   101 {r485=cmp(zxn(r885),0);clobber
scr:ppc750_du,iu1_7xx|iu2_7xx
---
> ;;      5-->    68 r470=0x64                         :iu1_6xx|iu2_6xx
40c40
< ;;      6-->    68 r470=0x64                        
:ppc750_du,iu1_7xx|iu2_7xx
---
> ;;      6-->   101 {r485=cmp(zxn(r885),0);clobber scr:iu1_6xx|iu2_6xx
...

2697c2697
< (insn 9 47 99 2 (set (reg:SI 435)
---
> (insn 9 47 13 2 (set (reg:SI 435)
2701c2701,2705
< (insn 99 9 13 2 (set (reg:QI 885 [ temp.5+4 ])
---
> (insn 13 9 99 2 (set (reg:SI 437)
>         (const_int -1 [0xffffffffffffffff])) ../where_2.f90:6 353 {*movsi_internal1}
>      (nil))
> 
> (insn 99 13 68 2 (set (reg:QI 885 [ temp.5+4 ])
2706,2707c2710,2711
< (insn 13 99 101 2 (set (reg:SI 437)
<         (const_int -1 [0xffffffffffffffff])) ../where_2.f90:6 353
{*movsi_internal1}
---
> (insn 68 99 101 2 (set (reg:SI 470)
>         (const_int 100 [0x64])) ../where_2.f90:11 353 {*movsi_internal1}
2710c2714
< (insn 101 13 68 2 (parallel [
---
> (insn 101 68 5 2 (parallel [
2718,2722c2722
< (insn 68 101 5 2 (set (reg:SI 470)
<         (const_int 100 [0x64])) ../where_2.f90:11 353 {*movsi_internal1}
<      (nil))
< 
< (insn 5 68 25 2 (set (reg:V4SI 433)
---
> (insn 5 101 25 2 (set (reg:V4SI 433)
3189c3189
< (insn 160 879 181 14 (set (reg:SI 243 [ mask.16+-3 ])
---
> (insn 160 879 161 14 (set (reg:SI 243 [ mask.16+-3 ])
3195c3195,3203
< (insn 181 160 195 14 (set (reg:SI 893 [ reduce+8 ])
---
> (insn 161 160 181 14 (parallel [
>             (set (reg:SI 513)
>                 (and:SI (reg:SI 241 [ cond.15+-3 ])
>                     (reg:SI 243 [ mask.16+-3 ])))
>             (clobber (scratch:CC))
>         ]) ../where_2.f90:11 161 {andsi3_mc}
>      (nil))
> 
> (insn 181 161 195 14 (set (reg:SI 893 [ reduce+8 ])
3230c3238
< (insn 279 265 161 14 (set (reg:SI 871 [ reduce+36 ])
---
> (insn 279 265 295 14 (set (reg:SI 871 [ reduce+36 ])
3235,3241c3243,3247
< (insn 161 279 880 14 (parallel [
<             (set (reg:SI 513)
<                 (and:SI (reg:SI 241 [ cond.15+-3 ])
<                     (reg:SI 243 [ mask.16+-3 ])))
<             (clobber (scratch:CC))
<         ]) ../where_2.f90:11 161 {andsi3_mc}
<      (nil))
---
> (insn 295 279 880 14 (set (reg:CC 609)
>         (compare:CC (reg:SI 513)
>             (const_int 0 [0]))) ../where_2.f90:11 451 {*cmpsi_internal1}
>      (expr_list:REG_DEAD (reg:SI 513)
>         (nil)))
...

[Bug middle-end/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3

[jakub at gcc dot gnu.org]

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

--- Comment #58 from Jakub Jelinek <jakub at gcc dot gnu.org> 2010-11-26 17:34:23 UTC ---
At least in my cross it seems the r166947 commit just changed default tuning
for -m64, from -mtune=power4 to -mtune=rs64.  Not sure if it was intentional or
not.  Anyway, with explicit -mtune=power4 the result is exactly the same as
before without any tuning options (and with -mtune=rs64 before is the same as
now without any tuning options).

[Bug middle-end/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3

[jakub at gcc dot gnu.org]

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

--- Comment #59 from Jakub Jelinek <jakub at gcc dot gnu.org> 2010-11-27 17:51:38 UTC ---
Can you please try latest trunk, if the test works with -O3 -m64 -mtune=rs64
and fails with -O3 -m64 -mtune=power4 ?

[Bug middle-end/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3

[dominiq at lps dot ens.fr]

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

--- Comment #60 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2010-11-27 21:49:28 UTC ---
> Can you please try latest trunk, if the test works with -O3 -m64 -mtune=rs64
> and fails with -O3 -m64 -mtune=power4 ?

Confirmed, but I have no idea of what is the default on darwin.

[Bug middle-end/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3

[jakub at gcc dot gnu.org]

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

--- Comment #61 from Jakub Jelinek <jakub at gcc dot gnu.org> 2010-12-07 22:07:59 UTC ---
I've managed to massage both -O3 -m64 -mtune={rs64,power4} darwin assembly into
ppc64-linux assembly.
Before DSE2 we have:
(insn 460 483 925 33 (set (reg:CC 75 cr7)
        (compare:CC (reg:SI 11 r11 [orig:866 reduce+32 ] [866])
            (const_int 6 [0x6]))) where_2.f90:11 451 {*cmpsi_internal1}
     (nil))

(insn 925 460 926 33 (set (reg:CC 0 r0)
        (reg:CC 75 cr7)) where_2.f90:11 358 {*movcc_internal1}
     (nil))

(insn 926 925 467 33 (set (mem/c:CC (plus:DI (reg/f:DI 1 r1)
                (const_int 272 [0x110])) [5 %sfp+272 S4 A32])
        (reg:CC 0 r0)) where_2.f90:11 358 {*movcc_internal1}
     (nil))

... # %sfp+272 not used anywhere here

(insn 931 415 932 33 (set (reg:CC 19 r19)
        (mem/c:CC (plus:DI (reg/f:DI 1 r1)
                (const_int 272 [0x110])) [5 %sfp+272 S4 A32])) where_2.f90:11
358 {*movcc_internal1}
     (nil))

(insn 932 931 461 33 (set (reg:CC 74 cr6)
        (reg:CC 19 r19)) where_2.f90:11 358 {*movcc_internal1}
     (nil))

(insn 461 932 422 33 (set (reg:SI 27 r27 [712])
        (gt:SI (reg:CC 74 cr6)
            (const_int 0 [0]))) where_2.f90:11 462 {*rs6000.md:13486}
     (nil))

and DSE2 somehow decides to nuke the insn 926 store.  The error could be also
that RA decides to share %sfp+272 not just for the CCmode stuff, but also
before that for a SImode value.

Looking into it...

[Bug target/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|middle-end                  |target

--- Comment #62 from Jakub Jelinek <jakub at gcc dot gnu.org> 2010-12-07 23:18:05 UTC ---
On a closer look, the reason why DSE deletes it is because there is a stvewx
insn in between, and the pattern of the insn is just plain wrong.
rs6000_expand_vector_extract has called assign_stack_temp, which gave for a
V4SImode something that is at r1+256, 16 bytes.
But rs6000_expand_vector_extract adjusts the address by elt * 4 bytes, here for
elt 3, so it is r1+268.  The pattern wrongly says that a V4SImode register is
stored into (mem:V4SI (r1 + 268)), which is not true (the insn stores just
4 bytes, i.e. SImode, into r1 + 268.  The r1+272 address which was given for
one of the spilled CCmode pseudos is then considered to be clobbered by DSE,
because
(mem:V4SI (r1 + 268)) overlaps it, thus the removed (mem:CC (r1 + 272)) store
by DSE.

I think the stve* insns need to be represented as what it really does, i.e.
(set (mem:SI ...) (either vec_select or perhaps unspec with the V4SImode reg
inside of it)).

[Bug target/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3

[jakub at gcc dot gnu.org]

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

--- Comment #63 from Jakub Jelinek <jakub at gcc dot gnu.org> 2010-12-08 00:12:52 UTC ---
Created attachment 22678
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22678
gcc46-pr41082.patch

Totally untested proof of concept patch.
The disadvantage is that as the MEM mode is not altivec-ish, it isn't forced
into reg+reg addressing early.

On the other side, when rs6000_expand_vector_extract always creates a new stack
local (shouldn't it try to share just one such slot for each mode in each
function btw?), is there any reason why a normal stvx insn can't be used
instead of these stve*x insns?  Is it a performance issue?  The difference
between stvx and stve*x I understand is just that stve*x doesn't clobber in the
memory
other bytes, while stvx stores everything in the 16 byte slot.  But we don't
care about those other bytes anyway, so if it is not a performance issue, IMHO
we should just get rid of UNSPEC_STVE stuff and store the whole vector, then
just read the bytes we want.

[Bug target/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3

[pinskia at gcc dot gnu.org]

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

--- Comment #64 from Andrew Pinski <pinskia at gcc dot gnu.org> 2010-12-08 00:15:44 UTC ---
> IMHO we should just get rid of UNSPEC_STVE stuff and store the whole vector, 

No you cannot because there are builtins which create the UNSPEC_STVE.

[Bug target/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3

[jakub at gcc dot gnu.org]

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

--- Comment #65 from Jakub Jelinek <jakub at gcc dot gnu.org> 2010-12-08 00:32:47 UTC ---
Created attachment 22679
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22679
gcc46-pr41082.patch

Found that now too.  Anyway, I believe (if there is no performance issue) I can
just tweak rs6000_expand_vector_extract this way, and the stve*x patterns would
need to be fixed anyway, though, because it hardly can have the extra argument,
it couldn't be VEC_SELECT, but I guess a scalar store with =Z or some similar
constraint that forces reg or reg+reg, with source being jus tthe unspec
UNSPEC_STVE with the vector as argument thereof.

[Bug target/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #22678|0                           |1
        is obsolete|                            |
  Attachment #22679|0                           |1
        is obsolete|                            |

--- Comment #66 from Jakub Jelinek <jakub at gcc dot gnu.org> 2010-12-08 07:35:43 UTC ---
Created attachment 22680
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22680
gcc46-pr41082.patch

Another untested fix, which this time should fix both
rs6000_expand_vector_extract patterns and __builtin_altivec_stve*x.
For altivec-4.c it generates identical code before/after the patch for both -O0
and -O2.

[Bug target/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3

[jakub at gcc dot gnu.org]

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

--- Comment #67 from Jakub Jelinek <jakub at gcc dot gnu.org> 2010-12-08 08:28:42 UTC ---
Perhaps it would be also good to add new peephole2 to catch:
(insn 931 415 932 33 (set (reg:CC 19 r19)
        (mem/c:CC (plus:DI (reg/f:DI 1 r1)
                (const_int 272 [0x110])) [5 %sfp+272 S4 A32])) where_2.f90:11
358 {*movcc_internal1}
     (nil))

(insn 932 931 461 33 (set (reg:CC 74 cr6)
        (reg:CC 19 r19)) where_2.f90:11 358 {*movcc_internal1}
     (expr_list:REG_DEAD (reg:CC 19 r19)
        (nil)))

(insn 461 932 422 33 (set (reg:SI 27 r27 [712])
        (gt:SI (reg:CC 74 cr6)
            (const_int 0 [0]))) where_2.f90:11 462 {*rs6000.md:13486}
     (expr_list:REG_DEAD (reg:CC 74 cr6)
        (nil)))

which is expanded to (if -fno-schedule-insns2, but peephole2 is run before
second scheduling):
        lwz r19,272(r1)
        rlwinm r19,r19,8,0xffffffff
        mtcrf 2,r19
        rlwinm r19,r19,24,0xffffffff
        mfcr r27
        rlwinm r27,r27,26,1
while only one lwz and one rlwinm are actually needed (BTW, also it would be
nice to avoid the second rlwinm in movcc_internal1 pattern if the source
integer register is dead at the insn).

I guess this can happen quite often, any time the register pressure is too high
and reload spills CC mode registers and then they are used just once for cr*
cond 0 ? 1 : 0 assignments.

[Bug target/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3

[meissner at gcc dot gnu.org]

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

--- Comment #68 from Michael Meissner <meissner at gcc dot gnu.org> 2010-12-08 20:29:45 UTC ---
gcc46-pr41082.patch looks correct to me.  I did a build on a linux power7
system, and saw no regressions in the make check output.

[Bug target/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3

[dominiq at lps dot ens.fr]

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

--- Comment #69 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2010-12-09 06:15:02 UTC ---
With gcc46-pr41082.patch, the test passes on darwin with both -mtune=rs64 and
-mtune=power4.

Thanks.

[Bug target/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3

[jakub at gcc dot gnu.org]

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

--- Comment #70 from Jakub Jelinek <jakub at gcc dot gnu.org> 2010-12-09 08:33:49 UTC ---
Author: jakub
Date: Thu Dec  9 08:33:45 2010
New Revision: 167629

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167629
Log:
    PR target/41082
    * config/rs6000/rs6000.c (rs6000_expand_vector_extract): Use stvx
    instead of stve*x.
    (altivec_expand_stv_builtin): For op0 use mode of operand 1 instead
    of operand 0.
    * config/rs6000/altivec.md (VI_scalar): New mode attr.
    (altivec_stve<VI_char>x, *altivec_stvesfx): Use scalar instead of
    vector mode for operand 0, put operand 1 into UNSPEC.

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

[Bug target/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2010.12.09 08:35:33
         AssignedTo|unassigned at gcc dot       |jakub at gcc dot gnu.org
                   |gnu.org                     |
            Summary|[4.5/4.6 Regression] FAIL:  |[4.5 Regression] FAIL:
                   |gfortran.fortran-torture/ex |gfortran.fortran-torture/ex
                   |ecute/where_2.f90           |ecute/where_2.f90
                   |execution,  -O3             |execution,  -O3
     Ever Confirmed|0                           |1

--- Comment #71 from Jakub Jelinek <jakub at gcc dot gnu.org> 2010-12-09 08:35:33 UTC ---
Fixed on the trunk, 4.5 backport waiting until it is unfrozen after 4.5.2
release.

[Bug target/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.5.2                       |4.5.3

--- Comment #72 from Richard Guenther <rguenth at gcc dot gnu.org> 2010-12-16 13:03:12 UTC ---
GCC 4.5.2 is being released, adjusting target milestone.

[Bug target/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3

[jakub at gcc dot gnu.org]

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

--- Comment #73 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-01-16 20:11:21 UTC ---
Author: jakub
Date: Sun Jan 16 20:11:16 2011
New Revision: 168860

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168860
Log:
    Backport from mainline
    2010-12-09  Jakub Jelinek  <jakub@redhat.com>

    PR target/41082
    * config/rs6000/rs6000.c (rs6000_expand_vector_extract): Use stvx
    instead of stve*x.
    (altivec_expand_stv_builtin): For op0 use mode of operand 1 instead
    of operand 0.
    * config/rs6000/altivec.md (VI_scalar): New mode attr.
    (altivec_stve<VI_char>x, *altivec_stvesfx): Use scalar instead of
    vector mode for operand 0, put operand 1 into UNSPEC.

Modified:
    branches/gcc-4_5-branch/gcc/ChangeLog
    branches/gcc-4_5-branch/gcc/config/rs6000/altivec.md
    branches/gcc-4_5-branch/gcc/config/rs6000/rs6000.c

[Bug target/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #74 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-01-17 08:26:29 UTC ---
Fixed.

[Bug middle-end/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3

[dominiq at lps dot ens dot fr]

------- Comment #52 from dominiq at lps dot ens dot fr  2010-08-06 07:33 -------
The miscompilation with -m64 is back at revision 162879.


-- 


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

[Bug middle-end/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3

[rguenth at gcc dot gnu dot org]

------- Comment #51 from rguenth at gcc dot gnu dot org  2010-07-31 09:29 -------
GCC 4.5.1 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.5.1                       |4.5.2


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

[Bug middle-end/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3

[dominiq at lps dot ens dot fr]

------- Comment #50 from dominiq at lps dot ens dot fr  2010-07-25 10:20 -------
Between revisions 162269 and 162477 this pr has been fixed for -m64 (but not
for -m32).


-- 


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

[Bug middle-end/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3

[dominiq at lps dot ens dot fr]

------- Comment #49 from dominiq at lps dot ens dot fr  2010-05-14 09:28 -------
> Any news on this?

Still there at revision 159329. Ira Rosen has devoted a fair amount of time to
trace the problem, but nobody cared to pursue.

Presently this PR has nothing to do with -g nor -ma64, so I updated the
summary.

Note that bootstrapping gcc on powerpc-apple-darwin9 is broken since revision
159339!-(each time a fix is posted an other breakage follows).


-- 

dominiq at lps dot ens dot fr changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.5/4.6 Regression] FAIL:  |[4.5/4.6 Regression] FAIL:
                   |gfortran.fortran-           |gfortran.fortran-
                   |torture/execute/where_2.f90 |torture/execute/where_2.f90
                   |execution,  -O3 -g with -m64|execution,  -O3


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