[Bug debug/89681] Incorrect source positions on O1 for simple code case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89681 --- Comment #2 from alahay01 at gcc dot gnu.org --- Created attachment 45951 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45951=edit O0 expand pass
[Bug debug/89681] Incorrect source positions on O1 for simple code case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89681 --- Comment #1 from alahay01 at gcc dot gnu.org --- Created attachment 45950 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45950=edit O1 expand pass
[Bug debug/89681] New: Incorrect source positions on O1 for simple code case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89681
Bug ID: 89681
Summary: Incorrect source positions on O1 for simple code case
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: alahay01 at gcc dot gnu.org
Target Milestone: ---
Created attachment 45949
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45949=edit
source code
Compiling a simple test case with O1 gives incorrect line numbers for two of
the lines of assembly.
Tested this on HEAD, 6.4.0, 7.2.0, using both X86-64 and AArch64. Debug results
are the same for all.
$ gcc --version
gcc (Ubuntu 7.2.0-1ubuntu1~16.04) 7.2.0
$ cat -n consume.c
1 extern void consume(int);
2 void testfunc(int **p) {
3int *a = *p;
4int b = *a;
5consume(b);
6 }
$ gcc -O1 -g consume.c -c -fdump-rtl-all
$ objdump -S -l -d consume.o
consume.o: file format elf64-x86-64
Disassembly of section .text:
:
testfunc():
/home/alahay01/consume.c:2
extern void consume(int);
void testfunc(int **p) {
0: 48 83 ec 08 sub$0x8,%rsp
/home/alahay01/consume.c:4
int *a = *p;
int b = *a;
4: 48 8b 07mov(%rdi),%rax
/home/alahay01/consume.c:5
consume(b);
7: 8b 38 mov(%rax),%edi
9: e8 00 00 00 00 callq e
/home/alahay01/consume.c:6
}
e: 48 83 c4 08 add$0x8,%rsp
12: c3 retq
>The two MOV instructions are on the wrong line. They are given lines 4 and 5.
>They should have lines 3 and 4.
$ cat consume.c.229r.expand
;; Function testfunc (testfunc, funcdef_no=0, decl_uid=1795, cgraph_uid=0,
symbol_order=0)
;; Generating RTL for gimple basic block 2
try_optimize_cfg iteration 1
Merging block 3 into block 2...
Merged blocks 2 and 3.
Merged 2 and 3 without moving.
Merging block 4 into block 2...
Merged blocks 2 and 4.
Merged 2 and 4 without moving.
try_optimize_cfg iteration 2
;;
;; Full RTL generated for this function:
;;
(note 1 0 4 NOTE_INSN_DELETED)
(note 4 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(insn 2 4 3 2 (set (reg/v/f:DI 89 [ p ])
(reg:DI 5 di [ p ])) "consume.c":2 -1
(nil))
(note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)
(debug_insn 6 3 7 2 (var_location:DI a (mem/f:DI (reg/v/f:DI 89 [ p ]) [1
*p_2(D)+0 S8 A64])) "consume.c":3 -1
(nil))
(debug_insn 7 6 8 2 (var_location:SI b (mem:SI (mem/f:DI (reg/v/f:DI 89 [ p ])
[1 *p_2(D)+0 S8 A64]) [2 *a_3+0 S4 A32])) "consume.c":4 -1
(nil))
(insn 8 7 9 2 (set (reg/f:DI 90)
(mem/f:DI (reg/v/f:DI 89 [ p ]) [1 *p_2(D)+0 S8 A64])) "consume.c":4 -1
(nil))
(insn 9 8 10 2 (set (reg:SI 5 di)
(mem:SI (reg/f:DI 90) [2 *a_3+0 S4 A32])) "consume.c":5 -1
(nil))
(call_insn 10 9 0 2 (call (mem:QI (symbol_ref:DI ("consume") [flags 0x41]
) [0 consume S1 A8])
(const_int 0 [0])) "consume.c":5 -1
(nil)
(expr_list:SI (use (reg:SI 5 di))
(nil)))
>Looks to me like it goes wrong in the expand phase. There are two debug_insn's
>for lines 3 and 4. But, then there are two insn's for line 4 and 5. I think
>these are incorrect, and should be lines 3 and 4.
>With O0 the results are correct:
$ gcc -O0 -g consume.c -c -fdump-rtl-all
$ objdump -S -l -d consume.o
consume.o: file format elf64-x86-64
Disassembly of section .text:
:
testfunc():
/home/alahay01/consume.c:2
extern void consume(int);
void testfunc(int **p) {
0: 55 push %rbp
1: 48 89 e5mov%rsp,%rbp
4: 48 83 ec 20 sub$0x20,%rsp
8: 48 89 7d e8 mov%rdi,-0x18(%rbp)
/home/alahay01/consume.c:3
int *a = *p;
c: 48 8b 45 e8 mov-0x18(%rbp),%rax
10: 48 8b 00mov(%rax),%rax
13: 48 89 45 f8 mov%rax,-0x8(%rbp)
/home/alahay01/consume.c:4
int b = *a;
17: 48 8b 45 f8 mov-0x8(%rbp),%rax
1b: 8b 00 mov(%rax),%eax
1d: 89 45 f4mov%eax,-0xc(%rbp)
/home/alahay01/consume.c:5
consume(b);
20: 8b 45 f4mov-0xc(%rbp),%eax
23: 89 c7 mov%eax,%edi
25: e8 00 00 00 00 callq 2a
/home/alahay01/consume.c:6
}
2a: 90 nop
2b: c9 leaveq
2c: c3 retq
$ cat consume.c.229r.expand
;; Function testfunc (testfunc, funcdef_no=0, decl_uid=1795, cgraph_uid=0,
symbol_order=0)
Partition 0: size 8 align 8
a_3
Partition 1: size 4 align 4
b_4
;; Generating RTL for gimple basic block 2
try_optimize_cfg iteration 1
Merging block 3 into block 2...
Merged blocks 2 and 3.
Merged 2 and 3 without m
[Bug debug/88432] Dwarf line numbering inadequate when using -fstack-protector-strong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88432
--- Comment #3 from alahay01 at gcc dot gnu.org ---
I considered a number of solutions, but they all had issues:
1) Place the RTL for the stack guard inside the prologue, giving:
*function prologue rtl
*stack guard code (__stack_chk_guard)
*NOTE_INSN_PROLOGUE_END
*NOTE_INSN_FUNCTION_BEG
*rest of the function rtl
Then this would then automatically stop the line number being dumped for the
stack guard. The rest of the assembly would be the same.
Downside here is that in the future new optimisations could be added that have
exactly the same issue.
2) Add line numbers to NOTE_INSN_FUNCTION_BEG and remove line numbers from
stack guard code (which currently has the line number for the { line)
3) Ensure the stack guard code has the line number of the first line of the
function main body.
I'm not sure if 2 and 3 will break instruction reordering.
[Bug debug/88432] Dwarf line numbering inadequate when using -fstack-protector-strong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88432 --- Comment #2 from alahay01 at gcc dot gnu.org --- Created attachment 45200 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45200=edit Final assembly dump for the .cc file with dwarf
[Bug debug/88432] Dwarf line numbering inadequate when using -fstack-protector-strong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88432 --- Comment #1 from alahay01 at gcc dot gnu.org --- Created attachment 45199 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45199=edit rtl final dump for the .cc file
[Bug debug/88432] New: Dwarf line numbering inadequate when using -fstack-protector-strong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88432
Bug ID: 88432
Summary: Dwarf line numbering inadequate when using
-fstack-protector-strong
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: alahay01 at gcc dot gnu.org
Target Milestone: ---
Created attachment 45198
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45198=edit
Example breaking program
Using -fstack-protector-strong will cause GDB to break on the wrong line when
placing a breakpoint on a function.
[ Note that the GCC provided with Ubuntu will default to
-fstack-protector-strong, causing all function breakpoints to break on the
wrong line. This breaks roughly 50 GDB tests when run on x86 and AArch64 Ubuntu
]
The issue in GDB
=
Consider the following program:
47: int main ()
48: {
49: char arg2 = 2;
50: signed char arg3 = 3;
(full program attached. Ignore everything in it except for main. Testcase taken
from the GDB testsuite.)
When compiled with -fstack-protector-strong, then running it in GDB,
“breakpoint main” will stop at line 48, the "{". This is wrong, it should
instead stop on line 49 – the first line of the function body.
GDB figures this out by looking at the dwarf line numbers. It finds the entry
for the start of the function (from other dwarf entries), and assumes that it
the entry for the function prologue. It then jumps forward one entry.
With stack proctector turned off we get the following. Note that the dwarf
label for main points at index 2.
INDEXLINE ADDRESS
0 45 0x00400680
1 45 0x00400680
2 48 0x00400688 - main: prologue pt1
3 49 0x004006ac - main: first line of function
4 50 0x004006b4 - main: second line of function
...etc
With stack protector on (like Ubuntu):
INDEXLINE ADDRESS
0 45 0x00400680
1 45 0x00400680
2 48 0x00400688 - main: prologue pt1
3 48 0x00400698 - main: stack protector code
4 49 0x004006ac - main: first line of function
5 50 0x004006b4 - main: second line of function
...etc
Ok, we could jump forward two entries. But then breaks with the following (with
either stack protector on or off):
47: int main ()
48: { char arg2 = 2;
49: signed char arg3 = 3;
It will result in the same line table, with just two entries at line 48:
INDEXLINE ADDRESS
0 45 0x00400680
1 45 0x00400680
2 48 0x00400688 - main: prologue pt1
3 48 0x00400698 - main: stack protector code
4 49 0x004006ac - main: second line of function
...etc
There is no way to tell if a repeated line is the first line of code or the
stack protector.
The underlying issue in GCC
===
See the attached rtl final dump from GCC (note: aarch64 code, but that doesn't
matter).
With the stack protector on, GCC produces RTL for the stack protector at the
beginning of the function, after the prologue.
You roughly get:
*function prologue rtl
*NOTE_INSN_PROLOGUE_END
*NOTE_INSN_FUNCTION_BEG
*stack guard code (__stack_chk_guard)
*rest of the function rtl
The stack guard rtl is given the line number of the "{" line.
When dumping line locations, notice_source_line() decides which RTL expressions
should cause a dump. It will force a dump of the first expression following
the end of the prologue - expecting this to be the first line of the function.
This gives us:
.LFB1:
.loc 1 48 0. – function prologue.
.cfi_startproc
sub sp, sp, #176
.cfi_def_cfa_offset 176
stp x29, x30, [sp, 32]
.cfi_offset 29, -144
.cfi_offset 30, -136
add x29, sp, 32
.cfi_def_cfa 29, 144
str x19, [sp, 48]
.cfi_offset 19, -128
.loc 1 48 0-- Start of stack guard code
adrp x0, __stack_chk_guard
add x0, x0, :lo12:__stack_chk_guard
ldr x1, [x0]
str x1, [x29, 136]
mov x1,0
.loc 1 49 0. – first line of function
mov w0, 2
strbw0, [x29, 45]
.loc 1 50 0
mov w0, 3
strbw0, [x29, 46]
[Bug tree-optimization/71752] [7 Regression] ICE in compute_live_loop_exits, at tree-ssa-loop-manip.c:229 w/ -O1 -ftree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71752 alahay01 at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from alahay01 at gcc dot gnu.org --- Use the correct operands when SLP vectorising.
[Bug tree-optimization/71752] [7 Regression] ICE in compute_live_loop_exits, at tree-ssa-loop-manip.c:229 w/ -O1 -ftree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71752 --- Comment #4 from alahay01 at gcc dot gnu.org --- Author: alahay01 Date: Wed Aug 17 15:31:44 2016 New Revision: 239542 URL: https://gcc.gnu.org/viewcvs?rev=239542=gcc=rev Log: 2015-08-17 Alan Hayward <alan.hayw...@arm.com> PR tree-optimization/71752 * tree-vect-loop.c (vectorizable_reduction): Keep SLP operand ordering. * tree-vect-slp.c (vect_get_slp_defs): Handle null operands. PR tree-optimization/71752 * gcc.dg/vect/pr71752.c: New Added: trunk/gcc/testsuite/gcc.dg/vect/pr71752.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop.c trunk/gcc/tree-vect-slp.c
[Bug tree-optimization/71818] [7 Regression] ICE in as_a, at is-a.h:192 w/ -O2 -ftree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71818 alahay01 at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from alahay01 at gcc dot gnu.org --- Fixed. Allowing a non-invariant step to be incremented using vect_can_advance_ivs_p was causing: 1) Incorrect vectorisation of the IV and 2) Loop closed SSA to be broken (the step was being used outside the loop directly instead of via a PHI). The ICE was caused because vectorisable_live_operation was expecting the loop to be in loop closed SSA.
[Bug tree-optimization/71818] [7 Regression] ICE in as_a, at is-a.h:192 w/ -O2 -ftree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71818 --- Comment #1 from alahay01 at gcc dot gnu.org --- Author: alahay01 Date: Mon Aug 1 14:33:23 2016 New Revision: 238955 URL: https://gcc.gnu.org/viewcvs?rev=238955=gcc=rev Log: 2016-08-01 Alan Hayward <alan.hayw...@arm.com> gcc/ PR tree-optimization/71818 * tree-vect-loop-manip.c (vect_can_advance_ivs_p): Don't advance IVs with non invariant evolutions testsuite/ PR tree-optimization/71818 * gcc.dg/vect/pr71818.c: New Added: trunk/gcc/testsuite/gcc.dg/vect/pr71818.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop-manip.c
[Bug tree-optimization/71752] [7 Regression] ICE in compute_live_loop_exits, at tree-ssa-loop-manip.c:229 w/ -O1 -ftree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71752 alahay01 at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |alahay01 at gcc dot gnu.org --- Comment #3 from alahay01 at gcc dot gnu.org --- Looks like vector q4_lsm.5_8 is used before it is defined.
[Bug debug/71667] [7 Regression] ICE in as_a, at is-a.h:192 w/ -g -O2 -ftree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71667 alahay01 at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from alahay01 at gcc dot gnu.org --- Fixed. Additional issue found by Qirun has been raised as PR 71818
[Bug tree-optimization/71818] New: [7 Regression] ICE in as_a, at is-a.h:192 w/ -O2 -ftree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71818 Bug ID: 71818 Summary: [7 Regression] ICE in as_a, at is-a.h:192 w/ -O2 -ftree-vectorize Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: alahay01 at gcc dot gnu.org Target Milestone: --- This bug is for the regression found by Qirun Zhang here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71667#c4 Splitting out from PR 71667 because it is a different issue. The bug is caused because one for the uses of the live statement is neither a phi nor a debug statement.
[Bug debug/71667] [7 Regression] ICE in as_a, at is-a.h:192 w/ -g -O2 -ftree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71667 --- Comment #6 from alahay01 at gcc dot gnu.org --- Author: alahay01 Date: Fri Jul 8 08:50:24 2016 New Revision: 238160 URL: https://gcc.gnu.org/viewcvs?rev=238160=gcc=rev Log: 2016-07-08 Alan Hayward <alan.hayw...@arm.com> gcc/ PR tree-optimization/71667 * tree-vect-loop.c (vectorizable_live_operation): ignore DEBUG stmts testsuite/ PR tree-optimization/71667 * gcc.dg/vect/pr71667.c: New Added: trunk/gcc/testsuite/gcc.dg/vect/pr71667.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop.c
[Bug debug/71667] [7 Regression] ICE in as_a, at is-a.h:192 w/ -g -O2 -ftree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71667 --- Comment #5 from alahay01 at gcc dot gnu.org --- Qirun: That looks like a separate issue. My fix for 71667 (under review) is specific to debug statements. Could you please raise your test case as a new bug and assign it to me. Thanks!
[Bug debug/71667] [7 Regression] ICE in as_a, at is-a.h:192 w/ -g -O2 -ftree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71667 alahay01 at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug debug/71667] [7 Regression] ICE in as_a, at is-a.h:192 w/ -g -O2 -ftree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71667 alahay01 at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |alahay01 at gcc dot gnu.org --- Comment #3 from alahay01 at gcc dot gnu.org --- "-g" is the important thing here. A statement has been marked live, and a use of it outside the loop is a DEBUG stmt. vectorizable_live_operation fails trying to treat the DEBUG stmt as a phi.
[Bug tree-optimization/71438] [7 Regression] wrong code at -O3 on x86_64-linux-gnu (by tree vectorizer)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71438 alahay01 at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||alahay01 at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #2 from alahay01 at gcc dot gnu.org --- Same issue as PR71439, which is now fixed. *** This bug has been marked as a duplicate of bug 71439 ***
[Bug tree-optimization/71439] [7 Regression] wrong code at -O3 in 32-bit and 64-bit mode on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71439 alahay01 at gcc dot gnu.org changed: What|Removed |Added CC||su at cs dot ucdavis.edu --- Comment #5 from alahay01 at gcc dot gnu.org --- *** Bug 71438 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/71483] [7 Regression] g++ ICE at -O3 on valid code on x86_64-linux-gnu with “Floating point exception”
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71483 alahay01 at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from alahay01 at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/71483] [7 Regression] g++ ICE at -O3 on valid code on x86_64-linux-gnu with “Floating point exception”
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71483 --- Comment #3 from alahay01 at gcc dot gnu.org --- Author: alahay01 Date: Wed Jun 15 15:45:47 2016 New Revision: 237483 URL: https://gcc.gnu.org/viewcvs?rev=237483=gcc=rev Log: 2016-06-15 Alan Hayward <alan.hayw...@arm.com> gcc/ PR tree-optimization/71483 * tree-vect-loop.c (vectorizable_live_operation): Pick correct index for slp testsuite/ PR tree-optimization/71483 * g++.dg/vect/pr71483.c: New Added: trunk/gcc/testsuite/g++.dg/vect/pr71483.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop.c
[Bug tree-optimization/71439] [7 Regression] wrong code at -O3 in 32-bit and 64-bit mode on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71439 alahay01 at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from alahay01 at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/71439] [7 Regression] wrong code at -O3 in 32-bit and 64-bit mode on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71439 --- Comment #3 from alahay01 at gcc dot gnu.org --- Author: alahay01 Date: Wed Jun 15 10:53:01 2016 New Revision: 237476 URL: https://gcc.gnu.org/viewcvs?rev=237476=gcc=rev Log: 2016-06-15 Alan Hayward <alan.hayw...@arm.com> gcc/ PR tree-optimization/71439 * tree-vect-loop.c (vect_analyze_loop_operations): Additional check for live PHIs. testsuite/ PR tree-optimization/71439 * gcc.dg/vect/pr71439.c: New Added: trunk/gcc/testsuite/gcc.dg/vect/pr71439.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop.c
[Bug tree-optimization/71483] [7 Regression] g++ ICE at -O3 on valid code on x86_64-linux-gnu with “Floating point exception”
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71483 alahay01 at gcc dot gnu.org changed: What|Removed |Added CC||alahay01 at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |alahay01 at gcc dot gnu.org --- Comment #2 from alahay01 at gcc dot gnu.org --- Due to error when vectorizing a live SLP operation.
[Bug tree-optimization/71416] [7 Regression] ICE at -O3 in 32-bit and 64-bit modes on x86_64-linux-gnu (vectorizable_live_operation)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71416 alahay01 at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #10 from alahay01 at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/71416] [7 Regression] ICE at -O3 in 32-bit and 64-bit modes on x86_64-linux-gnu (vectorizable_live_operation)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71416 --- Comment #9 from alahay01 at gcc dot gnu.org --- Author: alahay01 Date: Mon Jun 13 11:07:35 2016 New Revision: 237375 URL: https://gcc.gnu.org/viewcvs?rev=237375=gcc=rev Log: 2016-06-13 Alan Hayward <alan.hayw...@arm.com> gcc/ PR tree-optimization/71416 * tree-vect-loop.c (vectorizable_live_operation): Let worklist have multiple entries Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-loop.c
[Bug tree-optimization/71416] [7 Regression] ICE at -O3 in 32-bit and 64-bit modes on x86_64-linux-gnu (vectorizable_live_operation)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71416 --- Comment #8 from alahay01 at gcc dot gnu.org --- In my current checkout, there is no ICE on x86 or aarch64. I've updated to latest head, and can now reproduce the ICE on x86 (but not on aarch64). Looks like there ends up being two stmts in the worklist. Investigating
[Bug tree-optimization/71439] [7 Regression] wrong code at -O3 in 32-bit and 64-bit mode on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71439 alahay01 at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #2 from alahay01 at gcc dot gnu.org --- This is due to a loop having a live PHI which we allow in the vectorisation. We then fail to replace the PHI with a vectorised version. The bug is only triggered because the vectorised loop runs exactly once.
[Bug tree-optimization/71407] [7 Regression] ICE at -O3 in 32-bit and 64-bit modes on x86_64-linux-gnu (verify_gimple: integral result type precision does not match field size of BIT_FIELD_REF)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71407 alahay01 at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from alahay01 at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/71416] [7 Regression] ICE at -O3 in 32-bit and 64-bit modes on x86_64-linux-gnu (vectorizable_live_operation)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71416 --- Comment #5 from alahay01 at gcc dot gnu.org --- Author: alahay01 Date: Fri Jun 10 08:46:55 2016 New Revision: 237288 URL: https://gcc.gnu.org/viewcvs?rev=237288=gcc=rev Log: 2016-06-10 Alan Hayward <alan.hayw...@arm.com> gcc/ PR tree-optimization/71407 PR tree-optimization/71416 * tree-vect-loop.c (vectorizable_live_operation): Use vectype for BIT_FIELD_REF type. testsuite/ PR tree-optimization/71407 PR tree-optimization/71416 * gcc.dg/vect/pr71407.c: New * gcc.dg/vect/pr71416-1.c: New * gcc.dg/vect/pr71416-2.c: New Added: trunk/gcc/testsuite/gcc.dg/vect/pr71407.c trunk/gcc/testsuite/gcc.dg/vect/pr71416-1.c trunk/gcc/testsuite/gcc.dg/vect/pr71416-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop.c
[Bug tree-optimization/71407] [7 Regression] ICE at -O3 in 32-bit and 64-bit modes on x86_64-linux-gnu (verify_gimple: integral result type precision does not match field size of BIT_FIELD_REF)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71407 --- Comment #8 from alahay01 at gcc dot gnu.org --- Author: alahay01 Date: Fri Jun 10 08:46:55 2016 New Revision: 237288 URL: https://gcc.gnu.org/viewcvs?rev=237288=gcc=rev Log: 2016-06-10 Alan Hayward <alan.hayw...@arm.com> gcc/ PR tree-optimization/71407 PR tree-optimization/71416 * tree-vect-loop.c (vectorizable_live_operation): Use vectype for BIT_FIELD_REF type. testsuite/ PR tree-optimization/71407 PR tree-optimization/71416 * gcc.dg/vect/pr71407.c: New * gcc.dg/vect/pr71416-1.c: New * gcc.dg/vect/pr71416-2.c: New Added: trunk/gcc/testsuite/gcc.dg/vect/pr71407.c trunk/gcc/testsuite/gcc.dg/vect/pr71416-1.c trunk/gcc/testsuite/gcc.dg/vect/pr71416-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop.c
[Bug tree-optimization/71407] [7 Regression] ICE at -O3 in 32-bit and 64-bit modes on x86_64-linux-gnu (verify_gimple: integral result type precision does not match field size of BIT_FIELD_REF)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71407 --- Comment #5 from alahay01 at gcc dot gnu.org --- Qirun Zhang : That's a different issue (original test fails due to data type mismatch, this test fails because the loop boundary is unset). Please could you raise your test as a new bug and assign it to me (I think I have a fix for it).
[Bug tree-optimization/71416] [7 Regression] ICE at -O3 in 32-bit and 64-bit modes on x86_64-linux-gnu (vectorizable_live_operation)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71416 alahay01 at gcc dot gnu.org changed: What|Removed |Added CC||alahay01 at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |alahay01 at gcc dot gnu.org --- Comment #3 from alahay01 at gcc dot gnu.org --- Looking at the ICE, this looks like a duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71407 Tested in my current work-in-progress for 71407 and the ICE looks fixed. Will roll this testcase into the fix for 71407.
[Bug tree-optimization/71407] [7 Regression] ICE at -O3 in 32-bit and 64-bit modes on x86_64-linux-gnu (verify_gimple: integral result type precision does not match field size of BIT_FIELD_REF)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71407 alahay01 at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |alahay01 at gcc dot gnu.org --- Comment #3 from alahay01 at gcc dot gnu.org --- I've reproduced this on x86. Issue is not present on aarch64.
[Bug tree-optimization/71271] SLP loop vectorized twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71271 --- Comment #1 from alahay01 at gcc dot gnu.org --- Created attachment 38560 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38560=edit slp1 pass output
[Bug tree-optimization/71271] SLP loop vectorized twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71271 --- Comment #2 from alahay01 at gcc dot gnu.org --- Created attachment 38561 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38561=edit Final optimized tree output
[Bug tree-optimization/71271] New: SLP loop vectorized twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71271
Bug ID: 71271
Summary: SLP loop vectorized twice
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: alahay01 at gcc dot gnu.org
Target Milestone: ---
Created attachment 38559
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38559=edit
Vectorizer pass output
Consider the following code, compiled with -O3 -fno-common:
__attribute__ ((noinline)) int
liveloop (int start, int n, int *x, int *y)
{
int i = start;
int n0, n1, n2, n3;
int j;
for (j = 0; j < n; ++j)
{
i += 1;
n0 = x[(j*4)];
n1 = x[(j*4)+1];
n2 = x[(j*4)+2];
n3 = x[(j*4)+3];
y[(j*4)] = n0 +1;
y[(j*4)+1] = n1 +2;
y[(j*4)+2] = n2 +7;
y[(j*4)+3] = n3 +9;
}
return 0;
}
The vectorizer pass will split the loop using versioning (due to alias
dependencies). One version will be vectorized using SLP, the second will be
kept in scalar form.
However, the slp1 pass will then SLP vectorize the second scalar loop.
This results in the final assembler output containing two versions of the loop,
both of which are vectorized and are almost identical.
Whilst (i think) the code is correct, the code is not ideal.
Tested on x86 and aarch64.
[Bug tree-optimization/69848] poor vectorization of a loop from SPEC2006 464.h264ref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69848 --- Comment #3 from alahay01 at gcc dot gnu.org --- The standard way of dealing with condition reductions like this is to ignore the contents of the "if" statement and produce a lot of code to deal with the general case (it creates two vectors - one full of indexes and one full of results). In the code, this is where STMT_VINFO_VEC_REDUCTION_TYPE is set to COND_REDUCTION in tree-vect-loop.c. We have an optimisation of this for when the code is "if (a[b]) c=b" which bypasses most of the code produced by the general case. In the code, this is where STMT_VINFO_VEC_REDUCTION_TYPE is set to INTEGER_INDUC_COND_REDUCTION tree-vect-loop.c. I haven't figured out what the generated asm should look like for this issue, but I think we'll need a further vect_reduction_type case (CONST_COND_REDUCTION ??) which is checked for at the same point as INTEGER_INDUC_COND_REDUCTION (just after the "If we have a condition reduction, see if we can simplify it further." comment).
[Bug target/69053] [6 Regression] ICE in build_vector_from_val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69053 --- Comment #4 from alahay01 at gcc dot gnu.org --- (In reply to alalaw01 from comment #3) > Well, this fixes it, but I'm not sure it fixes it in the right place... > > diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c > index ee32166..bd66aa5 100644 > --- a/gcc/tree-vect-loop.c > +++ b/gcc/tree-vect-loop.c > @@ -4178,7 +4178,9 @@ get_initial_def_for_reduction (gimple *stmt, tree > init_val > break; > } > } > - init_def = build_vector_from_val (vectype, init_value); > + init_def = build_vector_from_val (vectype, > + fold_convert (TREE_TYPE (vectype), > + init_value)); > break; > >default: I don’t think we can move the conversion any earlier, it needs to be somewhere in get_initial_def_for_reduction. Possibly you could move the fold_convert on init_val earlier in the function just before the switch statement, but that has the potential to break more things. So I’d probably leave it where it is. Also, the fold_convert should just vanish if there is nothing to do, so that shouldn't be an issue for existing vectorisations.
[Bug tree-optimization/68413] [6 Regression] internal compiler error: in vect_transform_stmt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68413 --- Comment #9 from alahay01 at gcc dot gnu.org --- Author: alahay01 Date: Fri Nov 20 14:20:24 2015 New Revision: 230658 URL: https://gcc.gnu.org/viewcvs?rev=230658=gcc=rev Log: 2015-11-20 Alan Hayward <alan.hayw...@arm.com> PR tree-optimization/68413 * tree-vect-loop.c (vect_analyze_scalar_cycles_1): Cache evolution base (vectorizable_reduction): Use cached base Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-loop.c trunk/gcc/tree-vectorizer.h
[Bug tree-optimization/68413] [6 Regression] internal compiler error: in vect_transform_stmt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68413 alahay01 at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from alahay01 at gcc dot gnu.org --- Instead of only only checking on the analysis stage, we now cache the base value (like we already did with the step).
[Bug tree-optimization/68413] [6 Regression] internal compiler error: in vect_transform_stmt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68413 alahay01 at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-11-19 Ever confirmed|0 |1
[Bug tree-optimization/68413] [6 Regression] internal compiler error: in vect_transform_stmt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68413 --- Comment #5 from alahay01 at gcc dot gnu.org --- Yes, your right, I meant to say vectorizable_reduction - it's a reduction of a condition.
[Bug tree-optimization/68413] [6 Regression] internal compiler error: in vect_transform_stmt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68413 alahay01 at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |ASSIGNED Assignee|unassigned at gcc dot gnu.org |alahay01 at gcc dot gnu.org --- Comment #8 from alahay01 at gcc dot gnu.org --- >Probably compute reduction type at analysis phase only? I had come to the same conclusion myself :) Initially I was going to ignore base in is_nonwrapping_integer_induction (), but that is not a good idea. I'm writing a patch now. There's a few places more places than I expected to add checks for the analysis phase.
[Bug tree-optimization/66558] Missed vectorization of loop with control flow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66558 --- Comment #3 from alahay01 at gcc dot gnu.org --- Author: alahay01 Date: Fri Nov 13 10:51:34 2015 New Revision: 230297 URL: https://gcc.gnu.org/viewcvs?rev=230297=gcc=rev Log: Optimize condition reductions where the result is an integer induction variable 2015-11-13 Alan Hayward <alan.hayw...@arm.com> gcc/ PR tree-optimization/66558 * tree-vect-loop.c (is_integer_induction):Add. (vectorizable_reduction): Add integer induction checks. gcc/testsuite/ PR tree-optimization/66558 * gcc.dg/vect/pr65947-1.c: Add checks. * gcc.dg/vect/pr65947-2.c: Add checks. * gcc.dg/vect/pr65947-3.c: Add checks. * gcc.dg/vect/pr65947-4.c: Add checks. * gcc.dg/vect/pr65947-5.c: Add checks. * gcc.dg/vect/pr65947-6.c: Add checks. * gcc.dg/vect/pr65947-10.c: Add checks. * gcc.dg/vect/pr65947-12.c: New test. * gcc.dg/vect/pr65947-13.c: New test. Added: trunk/gcc/testsuite/gcc.dg/vect/pr65947-12.c trunk/gcc/testsuite/gcc.dg/vect/pr65947-13.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/pr65947-1.c trunk/gcc/testsuite/gcc.dg/vect/pr65947-10.c trunk/gcc/testsuite/gcc.dg/vect/pr65947-2.c trunk/gcc/testsuite/gcc.dg/vect/pr65947-3.c trunk/gcc/testsuite/gcc.dg/vect/pr65947-4.c trunk/gcc/testsuite/gcc.dg/vect/pr65947-5.c trunk/gcc/testsuite/gcc.dg/vect/pr65947-6.c trunk/gcc/tree-vect-loop.c trunk/gcc/tree-vectorizer.h
[Bug middle-end/65947] Vectorizer misses conditional assignment of constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65947 --- Comment #5 from alahay01 at gcc dot gnu.org --- Author: alahay01 Date: Fri Oct 23 12:40:33 2015 New Revision: 229245 URL: https://gcc.gnu.org/viewcvs?rev=229245=gcc=rev Log: Support for vectorizing conditional expressions 2015-10-23 Alan Hayward <alan.hayw...@arm.com> gcc/ PR tree-optimization/65947 * tree-vect-loop.c (vect_is_simple_reduction_1): Find condition reductions. (vect_model_reduction_cost): Add condition reduction costs. (get_initial_def_for_reduction): Add condition reduction initial var. (vect_create_epilog_for_reduction): Add condition reduction epilog. (vectorizable_reduction): Condition reduction support. * tree-vect-stmts.c (vectorizable_condition): Add vect reduction arg * doc/sourcebuild.texi (Vector-specific attributes): Document vect_max_reduc gcc/testsuite PR tree-optimization/65947 * lib/target-supports.exp (check_effective_target_vect_max_reduc): Add. * gcc.dg/vect/pr65947-1.c: New test. * gcc.dg/vect/pr65947-2.c: New test. * gcc.dg/vect/pr65947-3.c: New test. * gcc.dg/vect/pr65947-4.c: New test. * gcc.dg/vect/pr65947-5.c: New test. * gcc.dg/vect/pr65947-6.c: New test. * gcc.dg/vect/pr65947-7.c: New test. * gcc.dg/vect/pr65947-8.c: New test. * gcc.dg/vect/pr65947-9.c: New test. * gcc.dg/vect/pr65947-10.c: New test. * gcc.dg/vect/pr65947-11.c: New test. Added: trunk/gcc/testsuite/gcc.dg/vect/pr65947-1.c trunk/gcc/testsuite/gcc.dg/vect/pr65947-10.c trunk/gcc/testsuite/gcc.dg/vect/pr65947-11.c trunk/gcc/testsuite/gcc.dg/vect/pr65947-2.c trunk/gcc/testsuite/gcc.dg/vect/pr65947-3.c trunk/gcc/testsuite/gcc.dg/vect/pr65947-4.c trunk/gcc/testsuite/gcc.dg/vect/pr65947-5.c trunk/gcc/testsuite/gcc.dg/vect/pr65947-6.c trunk/gcc/testsuite/gcc.dg/vect/pr65947-7.c trunk/gcc/testsuite/gcc.dg/vect/pr65947-8.c trunk/gcc/testsuite/gcc.dg/vect/pr65947-9.c Modified: trunk/gcc/ChangeLog trunk/gcc/doc/sourcebuild.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/target-supports.exp trunk/gcc/tree-vect-loop.c trunk/gcc/tree-vect-stmts.c trunk/gcc/tree-vectorizer.h
