* [Bug middle-end/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3
[not found] <bug-41082-4@http.gcc.gnu.org/bugzilla/>
@ 2010-11-22 10:06 ` dominiq at lps dot ens.fr
2010-11-26 15:39 ` jakub at gcc dot gnu.org
` (20 subsequent siblings)
21 siblings, 0 replies; 22+ messages in thread
From: dominiq at lps dot ens.fr @ 2010-11-22 10:06 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug middle-end/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3
[not found] <bug-41082-4@http.gcc.gnu.org/bugzilla/>
2010-11-22 10:06 ` [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
@ 2010-11-26 15:39 ` jakub at gcc dot gnu.org
2010-11-26 16:01 ` dominiq at lps dot ens.fr
` (19 subsequent siblings)
21 siblings, 0 replies; 22+ messages in thread
From: jakub at gcc dot gnu.org @ 2010-11-26 15:39 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug middle-end/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3
[not found] <bug-41082-4@http.gcc.gnu.org/bugzilla/>
2010-11-22 10:06 ` [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
2010-11-26 15:39 ` jakub at gcc dot gnu.org
@ 2010-11-26 16:01 ` dominiq at lps dot ens.fr
2010-11-26 16:54 ` jakub at gcc dot gnu.org
` (18 subsequent siblings)
21 siblings, 0 replies; 22+ messages in thread
From: dominiq at lps dot ens.fr @ 2010-11-26 16:01 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug middle-end/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3
[not found] <bug-41082-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2010-11-26 16:01 ` dominiq at lps dot ens.fr
@ 2010-11-26 16:54 ` jakub at gcc dot gnu.org
2010-11-26 17:18 ` dominiq at lps dot ens.fr
` (17 subsequent siblings)
21 siblings, 0 replies; 22+ messages in thread
From: jakub at gcc dot gnu.org @ 2010-11-26 16:54 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug middle-end/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3
[not found] <bug-41082-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2010-11-26 16:54 ` jakub at gcc dot gnu.org
@ 2010-11-26 17:18 ` dominiq at lps dot ens.fr
2010-11-26 17:42 ` jakub at gcc dot gnu.org
` (16 subsequent siblings)
21 siblings, 0 replies; 22+ messages in thread
From: dominiq at lps dot ens.fr @ 2010-11-26 17:18 UTC (permalink / raw)
To: gcc-bugs
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)))
...
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug middle-end/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3
[not found] <bug-41082-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2010-11-26 17:18 ` dominiq at lps dot ens.fr
@ 2010-11-26 17:42 ` jakub at gcc dot gnu.org
2010-11-27 18:15 ` jakub at gcc dot gnu.org
` (15 subsequent siblings)
21 siblings, 0 replies; 22+ messages in thread
From: jakub at gcc dot gnu.org @ 2010-11-26 17:42 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug middle-end/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3
[not found] <bug-41082-4@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2010-11-26 17:42 ` jakub at gcc dot gnu.org
@ 2010-11-27 18:15 ` jakub at gcc dot gnu.org
2010-11-27 22:12 ` dominiq at lps dot ens.fr
` (14 subsequent siblings)
21 siblings, 0 replies; 22+ messages in thread
From: jakub at gcc dot gnu.org @ 2010-11-27 18:15 UTC (permalink / raw)
To: gcc-bugs
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 ?
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug middle-end/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3
[not found] <bug-41082-4@http.gcc.gnu.org/bugzilla/>
` (6 preceding siblings ...)
2010-11-27 18:15 ` jakub at gcc dot gnu.org
@ 2010-11-27 22:12 ` dominiq at lps dot ens.fr
2010-12-07 22:08 ` jakub at gcc dot gnu.org
` (13 subsequent siblings)
21 siblings, 0 replies; 22+ messages in thread
From: dominiq at lps dot ens.fr @ 2010-11-27 22:12 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug middle-end/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3
[not found] <bug-41082-4@http.gcc.gnu.org/bugzilla/>
` (7 preceding siblings ...)
2010-11-27 22:12 ` dominiq at lps dot ens.fr
@ 2010-12-07 22:08 ` jakub at gcc dot gnu.org
2010-12-07 23:18 ` [Bug target/41082] " jakub at gcc dot gnu.org
` (12 subsequent siblings)
21 siblings, 0 replies; 22+ messages in thread
From: jakub at gcc dot gnu.org @ 2010-12-07 22:08 UTC (permalink / raw)
To: gcc-bugs
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...
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3
[not found] <bug-41082-4@http.gcc.gnu.org/bugzilla/>
` (8 preceding siblings ...)
2010-12-07 22:08 ` jakub at gcc dot gnu.org
@ 2010-12-07 23:18 ` jakub at gcc dot gnu.org
2010-12-08 0:13 ` jakub at gcc dot gnu.org
` (11 subsequent siblings)
21 siblings, 0 replies; 22+ messages in thread
From: jakub at gcc dot gnu.org @ 2010-12-07 23:18 UTC (permalink / raw)
To: gcc-bugs
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)).
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3
[not found] <bug-41082-4@http.gcc.gnu.org/bugzilla/>
` (9 preceding siblings ...)
2010-12-07 23:18 ` [Bug target/41082] " jakub at gcc dot gnu.org
@ 2010-12-08 0:13 ` jakub at gcc dot gnu.org
2010-12-08 0:16 ` pinskia at gcc dot gnu.org
` (10 subsequent siblings)
21 siblings, 0 replies; 22+ messages in thread
From: jakub at gcc dot gnu.org @ 2010-12-08 0:13 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3
[not found] <bug-41082-4@http.gcc.gnu.org/bugzilla/>
` (10 preceding siblings ...)
2010-12-08 0:13 ` jakub at gcc dot gnu.org
@ 2010-12-08 0:16 ` pinskia at gcc dot gnu.org
2010-12-08 0:33 ` jakub at gcc dot gnu.org
` (9 subsequent siblings)
21 siblings, 0 replies; 22+ messages in thread
From: pinskia at gcc dot gnu.org @ 2010-12-08 0:16 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3
[not found] <bug-41082-4@http.gcc.gnu.org/bugzilla/>
` (11 preceding siblings ...)
2010-12-08 0:16 ` pinskia at gcc dot gnu.org
@ 2010-12-08 0:33 ` jakub at gcc dot gnu.org
2010-12-08 7:36 ` jakub at gcc dot gnu.org
` (8 subsequent siblings)
21 siblings, 0 replies; 22+ messages in thread
From: jakub at gcc dot gnu.org @ 2010-12-08 0:33 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3
[not found] <bug-41082-4@http.gcc.gnu.org/bugzilla/>
` (12 preceding siblings ...)
2010-12-08 0:33 ` jakub at gcc dot gnu.org
@ 2010-12-08 7:36 ` jakub at gcc dot gnu.org
2010-12-08 8:29 ` jakub at gcc dot gnu.org
` (7 subsequent siblings)
21 siblings, 0 replies; 22+ messages in thread
From: jakub at gcc dot gnu.org @ 2010-12-08 7:36 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3
[not found] <bug-41082-4@http.gcc.gnu.org/bugzilla/>
` (13 preceding siblings ...)
2010-12-08 7:36 ` jakub at gcc dot gnu.org
@ 2010-12-08 8:29 ` jakub at gcc dot gnu.org
2010-12-08 20:30 ` meissner at gcc dot gnu.org
` (6 subsequent siblings)
21 siblings, 0 replies; 22+ messages in thread
From: jakub at gcc dot gnu.org @ 2010-12-08 8:29 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3
[not found] <bug-41082-4@http.gcc.gnu.org/bugzilla/>
` (14 preceding siblings ...)
2010-12-08 8:29 ` jakub at gcc dot gnu.org
@ 2010-12-08 20:30 ` meissner at gcc dot gnu.org
2010-12-09 6:15 ` dominiq at lps dot ens.fr
` (5 subsequent siblings)
21 siblings, 0 replies; 22+ messages in thread
From: meissner at gcc dot gnu.org @ 2010-12-08 20:30 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3
[not found] <bug-41082-4@http.gcc.gnu.org/bugzilla/>
` (15 preceding siblings ...)
2010-12-08 20:30 ` meissner at gcc dot gnu.org
@ 2010-12-09 6:15 ` dominiq at lps dot ens.fr
2010-12-09 8:34 ` jakub at gcc dot gnu.org
` (4 subsequent siblings)
21 siblings, 0 replies; 22+ messages in thread
From: dominiq at lps dot ens.fr @ 2010-12-09 6:15 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3
[not found] <bug-41082-4@http.gcc.gnu.org/bugzilla/>
` (16 preceding siblings ...)
2010-12-09 6:15 ` dominiq at lps dot ens.fr
@ 2010-12-09 8:34 ` jakub at gcc dot gnu.org
2010-12-09 8:36 ` [Bug target/41082] [4.5 " jakub at gcc dot gnu.org
` (3 subsequent siblings)
21 siblings, 0 replies; 22+ messages in thread
From: jakub at gcc dot gnu.org @ 2010-12-09 8:34 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3
[not found] <bug-41082-4@http.gcc.gnu.org/bugzilla/>
` (17 preceding siblings ...)
2010-12-09 8:34 ` jakub at gcc dot gnu.org
@ 2010-12-09 8:36 ` jakub at gcc dot gnu.org
2010-12-16 13:13 ` rguenth at gcc dot gnu.org
` (2 subsequent siblings)
21 siblings, 0 replies; 22+ messages in thread
From: jakub at gcc dot gnu.org @ 2010-12-09 8:36 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3
[not found] <bug-41082-4@http.gcc.gnu.org/bugzilla/>
` (18 preceding siblings ...)
2010-12-09 8:36 ` [Bug target/41082] [4.5 " jakub at gcc dot gnu.org
@ 2010-12-16 13:13 ` rguenth at gcc dot gnu.org
2011-01-16 20:13 ` jakub at gcc dot gnu.org
2011-01-17 9:14 ` jakub at gcc dot gnu.org
21 siblings, 0 replies; 22+ messages in thread
From: rguenth at gcc dot gnu.org @ 2010-12-16 13:13 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3
[not found] <bug-41082-4@http.gcc.gnu.org/bugzilla/>
` (19 preceding siblings ...)
2010-12-16 13:13 ` rguenth at gcc dot gnu.org
@ 2011-01-16 20:13 ` jakub at gcc dot gnu.org
2011-01-17 9:14 ` jakub at gcc dot gnu.org
21 siblings, 0 replies; 22+ messages in thread
From: jakub at gcc dot gnu.org @ 2011-01-16 20:13 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3
[not found] <bug-41082-4@http.gcc.gnu.org/bugzilla/>
` (20 preceding siblings ...)
2011-01-16 20:13 ` jakub at gcc dot gnu.org
@ 2011-01-17 9:14 ` jakub at gcc dot gnu.org
21 siblings, 0 replies; 22+ messages in thread
From: jakub at gcc dot gnu.org @ 2011-01-17 9:14 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 22+ messages in thread