[Bug target/78222] target-tilegx: Incorrect bundle: let addli in y pipe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78222
--- Comment #1 from Chen Gang ---
The root cause is: in tilegx_gen_bundle, gcc will lose prev insn when it
deletes useless insns.
The related insns before tilegx_gen_bbundle (it is correct).
249 (insn:TI 71 68 75 4 (set (mem:DI (reg/f:DI 10 r10 [112]) [3 *rp_19(D)+8 S8
A64])
250 (reg:DI 32 r32 [orig:115 r+8 ] [115])) "test.c":25 4 {*movdi_insn}
251 (expr_list:REG_DEAD (reg:DI 32 r32 [orig:115 r+8 ] [115])
252 (expr_list:REG_DEAD (reg/f:DI 10 r10 [112])
253 (nil
254 (insn 75 71 78 4 (unspec_volatile [
255 (const_int 0 [0])
256 ] 201) "test.c":27 162 {blockage}
257 (nil))
258 (insn 78 71 160 4 (unspec_volatile [
259 (const_int 0 [0])
260 ] 201) "test.c":27 162 {blockage}
261 (nil))
262
263
264 (insn:TI 144 160 142 4 (set (reg:DI 28 r28)
265 (plus:DI (reg/f:DI 54 sp)
266 (const_int 120 [0x78]))) "test.c":27 38 {adddi3}
267 (nil))
268 (insn 142 144 79 4 (set (reg:DI 29 r29)
269 (plus:DI (reg/f:DI 54 sp)
270 (const_int 128 [0x80]))) "test.c":27 38 {adddi3}
271 (nil))
The insns after tilegx_gen_bundle (remove 2 useless insns, but forgot to
correct the prev insn)
249 (insn:SI # 0 0 4 (set (mem:DI (reg/f:DI 10 r10 [112]) [ *rp_19(D)+8 S8
A64])
250 (reg:DI 32 r32 [orig:115 r+8 ] [115])) "test.c":25# {*movdi_insn}
251 (expr_list:REG_DEAD (reg:DI 32 r32 [orig:115 r+8 ] [115])
252 (expr_list:REG_DEAD (reg/f:DI 10 r10 [112])
253 (nil
254 (insn:SI # 0 0 4 (set (reg:DI 28 r28)
255 (plus:DI (reg/f:DI 54 sp)
256 (const_int 120 [0x78]))) "test.c":27# {adddi3}
257 (nil))
258 (insn:QI # 0 0 4 (set (reg:DI 29 r29)
259 (plus:DI (reg/f:DI 54 sp)
260 (const_int 128 [0x80]))) "test.c":27# {adddi3}
261 (nil))
The correct insns after tilegx_gen_bundle should be:
220 (insn:QI # 0 0 4 (set (mem:DI (reg/f:DI 10 r10 [112]) [ *rp_19(D)+8 S8
A64])
221 (reg:DI 32 r32 [orig:115 r+8 ] [115])) "test.c":25# {*movdi_insn}
222 (expr_list:REG_DEAD (reg:DI 32 r32 [orig:115 r+8 ] [115])
223 (expr_list:REG_DEAD (reg/f:DI 10 r10 [112])
224 (nil
225 (note # 0 0 NOTE_INSN_EPILOGUE_BEG)
226 (insn:SI # 0 0 4 (set (reg:DI 28 r28)
227 (plus:DI (reg/f:DI 54 sp)
228 (const_int 120 [0x78]))) "test.c":27# {adddi3}
229 (nil))
230 (insn:QI # 0 0 4 (set (reg:DI 29 r29)
231 (plus:DI (reg/f:DI 54 sp)
232 (const_int 128 [0x80]))) "test.c":27# {adddi3}
233 (nil))
234 (insn # 0 0 4 (use (reg/i:TI 0 r0)) "test.c":27#
235 (nil))
I shall make patch for it next.
[Bug target/78222] New: target-tilegx: Incorrect bundle: let addli in y pipe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78222
Bug ID: 78222
Summary: target-tilegx: Incorrect bundle: let addli in y pipe
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gang.chen.5i5j at gmail dot com
Target Milestone: ---
Host: chroot ubuntu 15.10 under Android 5.1 x86_64
Target: tilegx
Build: Just building, use the latest version
1. Version:
COLLECT_GCC=/upstream/build-gcc/./gcc/xgcc
COLLECT_LTO_WRAPPER=/upstream/build-gcc/./gcc/lto-wrapper
Target: tilegx-gchen-linux
Configured with: ../gcc/configure --target=tilegx-gchen-linux --disable-nls
--enable-languages=c --disable-threads --disable-shared --disable-libssp
--disable-libquadmath --disable-libgomp --disable-libatomic
--prefix=/upstream/release-tile --disable-multilib
--with-headers=/upstream/release-tile/include
Thread model: single
gcc version 7.0.0 20161105 (experimental) (GCC)
2. Contents of test.c:
typedef int DItype __attribute__ ((mode (DI)));
typedef unsigned int UTItype __attribute__ ((mode (TI)));
UTItype test (UTItype *rp)
{
union
{
DItype low;
UTItype ll;
} uu, nn, dd, rr;
UTItype w, r;
DItype c1, c2, d0 = dd.low, n1 = nn.low;
if (uu.low < 0)
c1 = ~c1, c2 = ~c2, uu.ll = -uu.ll;
rr.low = n1 % d0;
w = rr.ll;
if (c1)
r = -r;
if (c2)
r = -r;
*rp = r;
return w;
}
3. Compiling issue:
/upstream/build-gcc/./gcc/xgcc -B/upstream/build-gcc/./gcc/
-B/upstream/release-tile/tilegx-gchen-linux/bin/
-B/upstream/release-tile/tilegx-gchen-linux/lib/ -O2 -c test.c
-fnon-call-exceptions -save-temps
test.s: Assembler messages:
test.s:84: Error: Invalid combination of instructions for bundle.
4. Contents of output (test.s):
1 .file "test.c"
2 .global __moddi3
3 .text
4 .align 8
5 .global test
6 .type test, @function
7 test:
8 .LFB0:
9 .cfi_startproc
10 {
11 st sp, lr
12 .cfi_offset 55, 0
13 mover29, sp
14 addir28, sp, -120
15 }
16 addisp, sp, -128
17 .cfi_def_cfa_offset 128
18 {
19 st r28, r29
20 addir27, sp, 120
21 addir26, sp, 112
22 }
23 {
24 st r27, r34
25 .cfi_offset 34, -8
26 addir25, sp, 104
27 addir10, sp, 16
28 }
29 {
30 st r26, r33
31 .cfi_offset 33, -16
32 addir24, sp, 96
33 addir11, sp, 48
34 }
35 {
36 st r25, r32
37 .cfi_offset 32, -24
38 addir27, r27, -32
39 }
40 ld r10, r10
41 st r24, r31
42 .cfi_offset 31, -32
43 {
44 ld r1, r11
45 addir11, sp, 32
46 cmpltsi r12, r10, 0
47 }
48 {
49 st r27, r30
50 .cfi_offset 30, -40
51 mover30, r0
52 }
53 {
54 ld r0, r11
55 movei r11, -1
56 }
57 cmovnez r33, r12, r11
58 {
59 cmovnez r34, r12, r11
60 jal __moddi3
61 }
62 {
63 addir10, sp, 72
64 mz r31, r33, r31
65 }
66 {
67 ld r1, r10
68 mz r32, r33, r32
69 }
70 beqzr34, .L4
71 {
72 sub r31, zero, r31
73 sub r32, zero, r32
74 }
75 cmpne r10, r31, zero
76 sub r32, r32, r10
77 .L4:
78 mover10, r30
79 st_add r10, r31, 8
80 {
81 st r10, r32
82 addir28, sp, 120
83 addli r29, sp, 128
84 }
85 {
86 ld r34, r28
87 addir27, sp, 112
88 addir26, sp, 104
89 }
90 {
91 addir25, sp, 96
92 addir28, r28, -32
93 ld lr, r29
94 }
95 ld r33, r27
96 ld r32, r26
97 ld r31, r25
98 ld r30, r28
99 {
100 addli sp, sp, 128
101 .cfi_restore 54
102 .cfi_restore 30
103 .cfi_restore 31
104 .cfi_restore 32
105 .cfi_restore 33
106 .cfi_restore 34
107 .cfi_restore 55
108 .cfi_def_cfa_offset 0
109 jrp lr
110 }
111 .cfi_endproc
112 .LFE0:
113 .size test, .-test
114 .ident "GCC: (GNU) 7.0.0 20161105 (experimental)"
115 .section.note.GNU-stack,"",@progbits
[Bug target/71331] target-tilegx: nested-function-4.c: r10 is conflict which is both in function frame and in parameter.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71331
--- Comment #1 from Chen Gang ---
Oh, lucky enough! The diff below should be OK for this issue.
diff --git a/gcc/config/tilegx/tilegx.c b/gcc/config/tilegx/tilegx.c
index 06c832c..bc41105 100644
--- a/gcc/config/tilegx/tilegx.c
+++ b/gcc/config/tilegx/tilegx.c
@@ -5510,18 +5510,28 @@ tilegx_function_profiler (FILE *file, int labelno
ATTRIBUTE_UNUSED)
if (flag_pic)
{
fprintf (file,
+ "\tst\tsp, r10\n"
+ "\taddi\tsp, sp, -8\n"
"\t{\n"
"\tmove\tr10, lr\n"
"\tjal\tplt(%s)\n"
- "\t}\n", MCOUNT_NAME);
+ "\t}\n"
+ "\taddi\tsp, sp, 8\n"
+ "\tld\tr10, sp\n",
+ MCOUNT_NAME);
}
else
{
fprintf (file,
+ "\tst\tsp, r10\n"
+ "\taddi\tsp, sp, -8\n"
"\t{\n"
"\tmove\tr10, lr\n"
"\tjal\t%s\n"
- "\t}\n", MCOUNT_NAME);
+ "\t}\n"
+ "\taddi\tsp, sp, 8\n"
+ "\tld\tr10, sp\n",
+ MCOUNT_NAME);
}
tilegx_in_bundle = false;
[Bug target/71331] New: target-tilegx: nested-function-4.c: r10 is conflict which is both in function frame and in parameter.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71331
Bug ID: 71331
Summary: target-tilegx: nested-function-4.c: r10 is conflict
which is both in function frame and in parameter.
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gang.chen.5i5j at gmail dot com
Target Milestone: ---
Created attachment 38591
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38591=edit
The related insns for nested-function-4.c
The nest function:
extern void abort(void);
void foo(int i)
{
void bar(void)
{
if (i != 2)
abort ();
}
bar();
}
int main(void)
{
foo (2);
return 0;
}
The command:
/upstream/build-gcc-tile/gcc/xgcc -B/upstream/build-gcc-tile/gcc/
./nested-func-4.c -fno-diagnostics-show-caret -fdiagnostics-color=never -pg
-I/upstream/release-tile/usr/include -fno-asynchronous-unwind-tables -m64
-mcpu=tilegx -mcmodel=large -mlittle-endian -L /upstream/release-tile/lib -lm
-o ./nested-func-4.exe -save-temps -fdump-final-insns=./insns.s
The asm output:
1 .file "nested-func-4.c"
2 .text
3 .align 8
4 .type bar.1690, @function
5 bar.1690:
6 {
7 mover10, lr
8 jal __mcount
9 }
10 st sp, lr
11 mover29, r52
12 mover52, sp
13 addir28, sp, -40
14 addisp, sp, -48
15 st r28, r52
16 addir27, r52, -8
17 st r27, r29
18
19 mover12, r10
20 addir11, r52, -24
21 st r11, r10
22 ld4sr10, r12
23 xorir10, r10, 2; bfextu r10, r10, 0, 31; cmpeqi r10, r10, 0
24 bnezr10, .L3
25 moveli r10, hw2_last(abort)
26 shl16insli r10, r10, hw1(abort)
27 shl16insli r10, r10, hw0(abort)
28 jalrr10
29 .L3:
30 nop
31 ld lr, r52
32 addir28, r52, -8
33 ld r29, r28
34
35 movesp, r52
36 mover52, r29
37 jrp lr
38 .size bar.1690, .-bar.1690
39 .align 8
40 .global foo
41 .type foo, @function
42 foo:
43 {
44 mover10, lr
45 jal __mcount
46 }
47 st sp, lr
48 mover29, r52
49 mover52, sp
50 addir28, sp, -56
51 addisp, sp, -64
52 st r28, r52
53 addir27, r52, -8
54 st r27, r29
55
56 mover10, r0
57 addxi r11, r10, 0
58 addir10, r52, -36
59 st4 r10, r11
60 mover11, r52
61 addir10, r52, -32
62 addir10, r10, 8
63 st r10, r11
64 addir10, r52, -32
65 addir11, r52, -36
66 ld4sr11, r11
67 st4 r10, r11
68 addir10, r52, -32
69 moveli r11, hw2_last(bar.1690)
70 shl16insli r11, r11, hw1(bar.1690)
71 shl16insli r11, r11, hw0(bar.1690)
72 jalrr11
73 nop
74 ld lr, r52
75 addir28, r52, -8
76 ld r29, r28
77
78 movesp, r52
79 mover52, r29
80 jrp lr
81 .size foo, .-foo
82 .align 8
83 .global main
84 .type main, @function
85 main:
86 {
87 mover10, lr
88 jal __mcount
89 }
90 st sp, lr
91 mover29, r52
92 mover52, sp
93 addir28, sp, -24
94 addisp, sp, -32
95 st r28, r52
96 addir27, r52, -8
97 st r27, r29
98
99 movei r0, 2
100 moveli r10, hw2_last(foo)
101 shl16insli r10, r10, hw1(foo)
102 shl16insli r10, r10, hw0(foo)
103 jalrr10
104 movei r10, 0
105 mover0, r10
106 ld lr, r52
107 addir28, r52, -8
108 ld r29, r28
109
110 movesp, r52
111 mover52, r29
112 jrp lr
113 .size main, .-main
114 .ident "GCC: (GNU) 7.0.0 20160529 (experimental)"
115 .section.note.GNU-stack,"",@progbits
[Bug testsuite/69573] FAIL: gcc.dg/pr61053.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69573
--- Comment #18 from Chen Gang ---
(In reply to Martin Sebor from comment #17)
> Patch committed in r233564.
Sorry for replying late (I am in holiday during these days, and no any x86
environments). Your patch is OK to me. But I guess, providing more details will
be helpful for other members:
For ia32, gcc includes intel common environments (e.g. linux) and mac
environments. Size of long double can be get by "echo | gcc -m32 -dM -E - |
grep LONG_DOUBLE", linux is 12, mac is 16.
For long double alignment can be get by building the c code: "int
alignof_long_double = _Alignof (long double); long double ld = 1;", linux is 4,
mac is 16.
For most archs, size of long double should be 16, so checking the special case
should be OK (check intel common ia32, and remove "{ target { ! { ia32 } } }").
If any other archs report failure, we can add another switch macros just like
this patch has done.
Thanks.
[Bug testsuite/69573] FAIL: gcc.dg/pr61053.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69573 --- Comment #14 from Chen Gang --- (In reply to Martin Sebor from comment #2) > Patch posted for review: > https://gcc.gnu.org/ml/gcc-patches/2016-01/msg02372.html For your original patch, my test result is below (only compare 5 result files, because of "make check" fails), I am not quite sure whether it is OK, please check, thanks. ShengShiZhuChengdeMacBook-Pro:gcc sszc$ sudo ./contrib/compare_tests ../build-gcc ../build-gcc-new Password: # Comparing directories ## Dir1=../build-gcc:5 sum files ## Dir2=../build-gcc-new:5 sum files # Comparing5 common sum files ## /bin/sh ./contrib/compare_tests /tmp/gxx-sum1.388 /tmp/gxx-sum2.388 Tests that now fail, but worked before: c-c++-common/asan/halt_on_error-1.c -O0 execution test c-c++-common/asan/halt_on_error-1.c -O1 execution test c-c++-common/asan/halt_on_error-1.c -O2 execution test c-c++-common/asan/halt_on_error-1.c -O3 -g execution test c-c++-common/asan/halt_on_error-1.c -Os execution test c-c++-common/asan/strncpy-overflow-1.c -O0 execution test gcc.dg/pch/save-temps-1.c -O0 -g -I. -Dwith_PCH (test for excess errors) Tests that now work, but didn't before: c-c++-common/asan/halt_on_error-1.c -O0 execution test c-c++-common/asan/halt_on_error-1.c -O1 execution test c-c++-common/asan/halt_on_error-1.c -O2 execution test c-c++-common/asan/halt_on_error-1.c -O3 -g execution test c-c++-common/asan/halt_on_error-1.c -Os execution test c-c++-common/asan/strncpy-overflow-1.c -O0 execution test New tests that FAIL: gcc.dg/pch/save-temps-1.c -O0 -g assembly comparison New tests that PASS: gcc.dg/pr61053.c (test for errors, line 80) gcc.dg/pr61053.c (test for errors, line 81) gcc.dg/pr61053.c (test for errors, line 82) gcc.dg/pr61053.c (test for errors, line 83) gcc.dg/pr61053.c (test for errors, line 84) Old tests that passed, that have disappeared: (Eeek!) gcc.dg/pch/save-temps-1.c -O0 -g -I. -Dwithout_PCH (test for excess errors) gcc.dg/pch/save-temps-1.c -O0 -g assembly comparison gcc.dg/pr61053.c (test for errors, line 70) gcc.dg/pr61053.c (test for errors, line 71) gcc.dg/pr61053.c (test for errors, line 72) gcc.dg/pr61053.c (test for errors, line 73) gcc.dg/pr61053.c (test for errors, line 74) ## Differences found: # 1 differences in5 common sum files found 5 result files are (which should be enough for us, I guess): ShengShiZhuChengdeMacBook-Pro:build-gcc sszc$ sudo find ./ | grep "\.sum$" .//gcc/testsuite/g++/g++.sum .//gcc/testsuite/gcc/gcc.sum .//gcc/testsuite/gfortran/gfortran.sum .//gcc/testsuite/objc/objc.sum .//x86_64-apple-darwin14.4.0/libstdc++-v3/testsuite/libstdc++.sum "make check" fails information (I guess, it should be easy to be fixed): /Applications/Xcode-2.app/Contents/Developer/usr/bin/make all-am true DO=all multi-do # /Applications/Xcode-2.app/Contents/Developer/usr/bin/make /Applications/Xcode-2.app/Contents/Developer/usr/bin/make btest stest /Users/sszc/Desktop/build-gcc/./gcc/xgcc -B/Users/sszc/Desktop/build-gcc/./gcc/ -B/usr/local/x86_64-apple-darwin14.4.0/bin/ -B/usr/local/x86_64-apple-darwin14.4.0/lib/ -isystem /usr/local/x86_64-apple-darwin14.4.0/include -isystem /usr/local/x86_64-apple-darwin14.4.0/sys-include-DHAVE_CONFIG_H -I. -I../../../gcc/libbacktrace -I ../../../gcc/libbacktrace/../include -I ../../../gcc/libbacktrace/../libgcc -I ../libgcc -funwind-tables -frandom-seed=btest-btest.o -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -Wcast-qual -Werror -g -O -g -O2 -c -o btest-btest.o `test -f 'btest.c' || echo '../../../gcc/libbacktrace/'`btest.c ../../../gcc/libbacktrace/btest.c:624:1: error: ‘test5’ defined but not used [-Werror=unused-function] test5 (void) ^ cc1: all warnings being treated as errors make[3]: *** [btest-btest.o] Error 1 make[2]: *** [check-am] Error 2 make[1]: *** [check-target-libbacktrace] Error 2 make: *** [do-check] Error 2
[Bug testsuite/69573] FAIL: gcc.dg/pr61053.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69573 --- Comment #15 from Chen Gang --- (In reply to Martin Sebor from comment #9) > I built the x86_64-apple-darwin15.3.0 cross-compiler to better understand > what the problem is but I don't see it. The cross compiler says the size > and alignment of long double is 16 in both ILP32 (with -m32) and LP64. So > the patched test should pass without any further changes. > > Can you let me know the target triple of your GCC and the result of > _Alignof(long double)? Below is what I get: > I get the same result just like you have done. And my gcc information is: ShengShiZhuChengdeMacBook-Pro:ana sszc$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin14.4.0/6.0.0/lto-wrapper Target: x86_64-apple-darwin14.4.0 Configured with: ../gcc/configure Thread model: posix gcc version 6.0.0 20160205 (experimental) (GCC) Thanks.
[Bug testsuite/69573] FAIL: gcc.dg/pr61053.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69573 --- Comment #4 from Chen Gang --- (In reply to Chen Gang from comment #3) > Created attachment 37625 [details] > Under my Darwin mac book OS X Yosemite 10.10.4, it looks short wide alignas > for long wide type will cause issue. Oh, sorry, it is my misunderstanding. I shall try the "make check" for this patch under Darwin with gcc 6.0.0. Thanks.
[Bug testsuite/69573] FAIL: gcc.dg/pr61053.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69573 --- Comment #5 from Chen Gang --- (In reply to Martin Sebor from comment #2) > Patch posted for review: > https://gcc.gnu.org/ml/gcc-patches/2016-01/msg02372.html I do not known why let __SIZEOF_LONG_DOUBLE__ == 12 ? I guess we need use __SIZEOF_LONG_DOUBLE__ != 4 instead of. Thanks.
[Bug testsuite/69573] FAIL: gcc.dg/pr61053.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69573 --- Comment #6 from Chen Gang --- (In reply to Chen Gang from comment #5) > > I guess we need use __SIZEOF_LONG_DOUBLE__ != 4 instead of. > Oh, sorry again, the above is incorrect. Under my x86_64 Darwin, for m32, __SIZEOF_LONG_DOUBLE__ is 16. It looks that only use __SIZEOF_LONG_DOUBLE__ is not enough.
[Bug c/61053] [4.9/5/6 Regression] _Alignas(long long) reduces alignment of long long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61053 --- Comment #11 from Chen Gang --- (In reply to Martin Sebor from comment #10) > On second thought, since the test isn't failing because _Alignas isn't > working but rather because the DejaGnu directive in it is wrong, it this bug > can be resolved as fixed and a new one for the test raised. I've taken the > liberty to do both. Bug 69573 tracks the failing test. Excuse me, I am not quite familiar with _Alignas. If we need improve the testsuite pr61053.c, I guess we need to check __APPLE_CC__ for the related long double cases in pr61053.c, since at present, this issue is only related with Darwin.
[Bug testsuite/69573] FAIL: gcc.dg/pr61053.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69573 --- Comment #7 from Chen Gang --- Can we check __APPLE_CC__ instead of __SIZEOF_LONG_DOUBLE__ ?
[Bug testsuite/69573] FAIL: gcc.dg/pr61053.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69573 --- Comment #3 from Chen Gang --- Created attachment 37625 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37625=edit Under my Darwin mac book OS X Yosemite 10.10.4, it looks short wide alignas for long wide type will cause issue. Under my Darwin mac book OS X Yosemite 10.10.4, it looks short wide alignas for long wide type will cause issue. Please check, thanks. And I shall continue, too.
[Bug c/28901] -Wunused-variable ignores unused const initialised variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901 --- Comment #22 from Chen Gang --- (In reply to Mark Wielaard from comment #21) [...] > Although in C a static const is not really like a #define I suspect that > there are cases where they are used as such in header files. If that is the > major reason for why there are people opposed to the warning then what we > could do is hide such (non-)usage of static const variables from header > files behind -Wextra and only explicitly warn for static const variable > defined (and then not used) in the main file. > For me, what you said above sounds reasonable. :-)
[Bug c/28901] -Wunused-variable ignores unused const initialised variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901 --- Comment #19 from Chen Gang --- I build linux kernel with allyesconfig under x86_64 for linux-next tree 20160122. I can find some related cases for BUG28901 (but they are not quite much), one case is below: CC drivers/acpi/sbshc.o In file included from drivers/acpi/sbshc.c:17:0: drivers/acpi/sbshc.h:17:17: warning: ‘SMBUS_PEC’ defined but not used [-Wunused-const-variable] static const u8 SMBUS_PEC = 0x80; ^ For me, I dislike -Wno-unused-const-variable option, the reason is "when C programmers use static const int variable, in most cases, they want to use them instead of #define". So for me, -Wunused-variable need skip static const int variable warning. If anyone wants to warn about it, they can add additional option (e.g. -Wunused-const-int-variable) to let C compiler report warning for it. Thanks.
[Bug c/28901] -Wunused-variable ignores unused const initialised variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901 --- Comment #20 from Chen Gang --- (In reply to Chen Gang from comment #19) > I build linux kernel with allyesconfig under x86_64 for linux-next tree > 20160122. I can find some related cases for BUG28901 (but they are not quite > much), one case is below: > > CC drivers/acpi/sbshc.o > In file included from drivers/acpi/sbshc.c:17:0: > drivers/acpi/sbshc.h:17:17: warning: ‘SMBUS_PEC’ defined but not used > [-Wunused-const-variable] > static const u8 SMBUS_PEC = 0x80; > ^ Oh, sorry, this case is not suitable, it is -Wunused-const-variable. But my opinion still like what I said in comment #19. Thanks.
[Bug testsuite/68917] test suite failure for builtin-bitops-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68917 --- Comment #5 from Chen Gang --- (In reply to Bernd Edlinger from comment #1) > does something like this help? > OK, it has effect, :-) And pass gcc testsuite. The related result is below: [root@localhost contrib]# ./compare_tests ../../build-gcc-cur ../../build-gcc-cur-new # Comparing directories ## Dir1=../../build-gcc-cur: 2 sum files ## Dir2=../../build-gcc-cur-new: 2 sum files # Comparing 2 common sum files ## /bin/sh ./compare_tests /tmp/gxx-sum1.1535 /tmp/gxx-sum2.1535 Tests that now work, but didn't before: tile: gcc.c-torture/execute/builtin-bitops-1.c -O0 (test for excess errors) tile: gcc.c-torture/execute/builtin-bitops-1.c -O1 (test for excess errors) tile: gcc.c-torture/execute/builtin-bitops-1.c -O2 (test for excess errors) tile: gcc.c-torture/execute/builtin-bitops-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for excess errors) tile: gcc.c-torture/execute/builtin-bitops-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for excess errors) tile: gcc.c-torture/execute/builtin-bitops-1.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) tile: gcc.c-torture/execute/builtin-bitops-1.c -O3 -g (test for excess errors) tile: gcc.c-torture/execute/builtin-bitops-1.c -Os (test for excess errors) tile: gcc.dg/builtin-protos-1.c (test for excess errors) tile: gcc.dg/tree-ssa/vrp89.c (test for excess errors) New tests that PASS: tile: gcc.c-torture/execute/builtin-bitops-1.c -O0 execution test tile: gcc.c-torture/execute/builtin-bitops-1.c -O1 execution test tile: gcc.c-torture/execute/builtin-bitops-1.c -O2 execution test tile: gcc.c-torture/execute/builtin-bitops-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test tile: gcc.c-torture/execute/builtin-bitops-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test tile: gcc.c-torture/execute/builtin-bitops-1.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test tile: gcc.c-torture/execute/builtin-bitops-1.c -O3 -g execution test tile: gcc.c-torture/execute/builtin-bitops-1.c -Os execution test Old tests that failed, that have disappeared: (Eeek!) tile: gcc.c-torture/execute/builtin-bitops-1.c -O0 (internal compiler error) tile: gcc.c-torture/execute/builtin-bitops-1.c -O1 (internal compiler error) tile: gcc.c-torture/execute/builtin-bitops-1.c -O2 (internal compiler error) tile: gcc.c-torture/execute/builtin-bitops-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error) tile: gcc.c-torture/execute/builtin-bitops-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (internal compiler error) tile: gcc.c-torture/execute/builtin-bitops-1.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (internal compiler error) tile: gcc.c-torture/execute/builtin-bitops-1.c -O3 -g (internal compiler error) tile: gcc.c-torture/execute/builtin-bitops-1.c -Os (internal compiler error) tile: gcc.dg/builtin-protos-1.c (internal compiler error) tile: gcc.dg/tree-ssa/vrp89.c (internal compiler error) # No differences found in 2 common sum files [root@localhost contrib]#
[Bug testsuite/68917] test suite failure for builtin-bitops-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68917 --- Comment #4 from Chen Gang --- (In reply to Bernd Edlinger from comment #3) > by the way, did you have also trouble to build the > libgcc multilib configuration or did you --disable-multilib? > this seems completely broken too... Yes, I did. ../gcc/configure --target=tilegx-gchen-linux --disable-nls --enable-threads --enable-shared --enable-libssp --prefix=/upstream/release-tile --with-headers=/upstream/release-tile/include --with-sysroot=/upstream/release-tile --disable-multilib --disable-libquadmath --disable-libgomp --disable-libatomic target_alias=tilegx-gchen-linux --enable-languages=c,c++,lto Thanks.
[Bug testsuite/68917] test suite failure for builtin-bitops-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68917
--- Comment #2 from Chen Gang ---
(In reply to Bernd Edlinger from comment #1)
> does something like this help?
>
Oh, sorry for replying late.
I shall try to give a test within this month.
Thanks. :-)
> Index: tilegx.md
> ===
> --- tilegx.md (Revision 231696)
> +++ tilegx.md (Arbeitskopie)
> @@ -1799,13 +1799,16 @@
>
> (define_expand "clzsi2"
>[(set (match_dup 2)
> -(ashift:DI (match_operand:SI 1 "reg_or_0_operand" "")
> + (zero_extend:DI (match_operand:SI 1 "reg_or_0_operand" "")))
> + (set (match_dup 2)
> + (ashift:DI (match_dup 2)
> (const_int 32)))
> - (set (subreg:DI (match_operand:SI 0 "register_operand" "") 0)
> - (clz:DI (match_dup 2)))]
> + (set (match_dup 2)
> + (clz:DI (match_dup 2)))
> + (set (match_operand:SI 0 "register_operand" "")
> + (subreg:SI (match_dup 2) 0))]
> ""
> {
> - operands[1] = simplify_gen_subreg (DImode, operands[1], SImode, 0);
> operands[2] = gen_reg_rtx (DImode);
> })
[Bug c/68917] New: test suite failure for builtin-bitops-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68917 Bug ID: 68917 Summary: test suite failure for builtin-bitops-1.c Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: gang.chen.5i5j at gmail dot com Target Milestone: --- The latest gcc version introduce a new issue which has no issue before (e.g. for gcc_5_3_0_release branch, it has no this issue). The related file is gcc/testsuite/gcc.c-torture/execute/builtin-bitops-1.c [root@localhost try]# /upstream/build-gcc-tile/gcc/xgcc -B/upstream/build-gcc-tile/gcc/ builtin-bitops-1.c -fno-diagnostics-show-caret -fdiagnostics-color=never -O0 -w -I/upstream/release-tile/usr/include -fno-asynchronous-unwind-tables -m64 -mcpu=tilegx -mcmodel=large -mlittle-endian -L /upstream/release-tile/lib -lm -o ./builtin-bitops-1.exe builtin-bitops-1.c: In function 'main': builtin-bitops-1.c:281:1: error: unrecognizable insn: (insn 77 76 78 9 (set (subreg:DI (subreg/s/u:SI (reg:DI 82 [ _24 ]) 0) 0) (clz:DI (reg:DI 355))) builtin-bitops-1.c:184 -1 (nil)) builtin-bitops-1.c:281:1: internal compiler error: in extract_insn, at recog.c:2286 0x9ff4d3 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) ../../gcc/gcc/rtl-error.c:108 0x9ff509 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) ../../gcc/gcc/rtl-error.c:116 0x9d3741 extract_insn(rtx_insn*) ../../gcc/gcc/recog.c:2286 0x7e4073 instantiate_virtual_regs_in_insn ../../gcc/gcc/function.c:1578 0x7e4073 instantiate_virtual_regs ../../gcc/gcc/function.c:1946 0x7e4073 execute ../../gcc/gcc/function.c:1995 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions.
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 --- Comment #22 from Chen Gang --- (In reply to Jakub Jelinek from comment #21) > Author: jakub > Date: Fri Nov 27 08:59:55 2015 > New Revision: 230999 > > URL: https://gcc.gnu.org/viewcvs?rev=230999=gcc=rev This way looks OK to me. But for C++, it has no pr63326 issue, do we still need to modify gcc/cp/parser.c? pr42979 is related with this issue, more or less. May this patch also fix pr42979 by the way? If this patch really fix pr42979, we will still need gcc/cp/parser.c (both C and C++ have pr42979 issue). Thanks.
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 --- Comment #19 from Chen Gang --- (In reply to Andrew Pinski from comment #18) > (In reply to Chen Gang from comment #17) > > I guess the diff below should be OK, I shall give a make check test. > > I would rather have the C front-end behavior for C++ rather than the > opposite way around. Because _Pragma are considered statements. For me, this bug is related with the demands (language definition), and C need not be part of C++. - For me, what cc1plus has done is OK: C++ looks that it always 'likes' more new features, and want to let the users (C++ programmer) use the language freely and in common sense. - But for C, if one feature is in discussing, it should not be treated as a common features (C standard is more stricter than C++). So we need not care about this 'bug' quite much (In real world, C programmers need not use #pragma in this way). In our case (this cc1 'bug'), Instead of returning the 'anbisous' result (it may cause misunderstanding for C/C++ programmers more or less), cc1 need report error during compiling.
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 --- Comment #20 from Chen Gang --- (In reply to Andrew Pinski from comment #18) > (In reply to Chen Gang from comment #17) > > I guess the diff below should be OK, I shall give a make check test. > > I would rather have the C front-end behavior for C++ rather than the > opposite way around. Because _Pragma are considered statements. For me, this bug is related with the demands (language definition), and C need not be part of C++. - For me, what cc1plus has done is OK: C++ looks that it always 'likes' more new features, and want to let the users (C++ programmer) use the language freely and in common sense. - But for C, if one feature is in discussing, it should not be treated as a common features (C standard is more stricter than C++). So we need not care about this 'bug' quite much (In real world, C programmers need not use #pragma in this way). In our case (this cc1 'bug'), Instead of returning the 'anbisous' result (it may cause misunderstanding for C/C++ programmers more or less), cc1 need report error during compiling.
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 --- Comment #17 from Chen Gang --- I guess the diff below should be OK, I shall give a make check test. diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c index 7b10764..257 100644 --- a/gcc/c/c-parser.c +++ b/gcc/c/c-parser.c @@ -5170,7 +5170,9 @@ c_parser_statement_after_labels (c_parser *parser, vec *chain) c_parser_consume_token (parser); break; case CPP_PRAGMA: - c_parser_pragma (parser, pragma_stmt); + c_parser_error (parser, + "don't allow if, while, do, swith, or label" +); break; default: expr_stmt:
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 --- Comment #15 from Chen Gang --- For me, comment #9 is the reasonable fixing way. In real world, C/C++ programmers will/should not use #pragma in this way (use #pragma in place of the statement following an if, while, do, switch, or label). Another compilers maybe support #pragma in this way and check every #pragma details to determine to be as a statement or not, but in real world, this feature is useless (never need be used) for C/C++ programmers. It is worthless for gcc to support it. Could any members tell me the related usage cases in real world? Thanks.
[Bug c/42979] OpenMP #pragma omp taskwait after a label is not permitted - should fail at compile time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42979
--- Comment #3 from Chen Gang ---
For "The taskwait directive may not be used in place of the statement following
an if, while, do, switch, or label."
if "if, while, do, switch, or label" is just flowed with a code block which let
"#pragma omp taskwait" as its first statement. Should compiler also report
error? (I guess not), e.g.
#include
int main(void)
{
#pragma omp parallel
{
goto mylabel;
mylabel:
{
#pragma omp taskwait
}
;
}
fprintf(stderr, "%s:%i: FAIL - negative test case should not compile\n",
__FILE__, __LINE__);
return 1;
}
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 --- Comment #16 from Chen Gang --- Our C++ has no this issue. For precisely saying: cc1 has the issue, but cc1plus has no the issue (if use g++ build c programs, it has no issue; if use gcc build c++ programs, it has no issue, either). But still, for me, it is worthless for gcc and g++ to support this feature.
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 --- Comment #14 from Chen Gang --- For gcc version 6.0.0 20151121 (experimental) (GCC), this issue is still existant. I shall try to fix it within this month (2015-11-30). Hope I can succeed.
[Bug middle-end/63510] Wrong line number in Wstrict-overflow message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63510 --- Comment #13 from Chen Gang --- gcc version 6.0.0 20151023 (experimental) (GCC) has no this issue (I guess, the reason is that it calls gimple_simplify instead of fold_binary). For me, this issue can be closed. Thanks.
[Bug target/65804] blackfin: Not support global frame pointer with -fno-omit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65804 --- Comment #2 from Chen Gang --- It is about git commit "e52beba PR debug/54694". I am just consulting about it in gcc-help mailing list.
[Bug debug/54694] [4.7/4.8 Regression] internal compiler error: in dwarf2out_frame_debug_expr, at dwarf2out.c:2387
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54694 Chen Gang changed: What|Removed |Added CC||gang.chen.5i5j at gmail dot com --- Comment #25 from Chen Gang --- (In reply to Richard Henderson from comment #20) > Author: rth > Date: Thu Jan 16 16:33:30 2014 > New Revision: 206667 > > URL: http://gcc.gnu.org/viewcvs?rev=206667=gcc=rev > Log: > PR debug/54694 > > Diagnose frame_pointer_required vs fixed hfp > > Added: > branches/gcc-4_7-branch/gcc/testsuite/gcc.target/i386/pr54694.c > Modified: > branches/gcc-4_7-branch/gcc/ChangeLog > branches/gcc-4_7-branch/gcc/ira.c > branches/gcc-4_7-branch/gcc/reginfo.c > branches/gcc-4_7-branch/gcc/rtl.h After this git commit, the current blackfin kernel code can not pass building when enable FUNCTION_TRACER. The related bug number is Bug65804 I want to consult: Is it the original gcc and current kernel issue? or our related git commit "e52beba PR debug/54694" need be improved? Thanks.
[Bug middle-end/63510] Wrong line number in Wstrict-overflow message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63510 --- Comment #12 from Chen Gang --- The patch passes "make check". I guess, it should be OK.
[Bug target/66620] bfin: bfin.c: (hwloop_optimize): gcc_assert (JUMP_P (insn)) fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66620 Chen Gang changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #14 from Chen Gang --- It is already fixed. Just change the status.
[Bug target/65804] blackfin: Not support global frame pointer with -fno-omit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65804 Chen Gang changed: What|Removed |Added CC||gang.chen.5i5j at gmail dot com --- Comment #1 from Chen Gang --- I shall try to fix this issue. Hope I can finish within this month (although I am really not quite sure).
[Bug middle-end/63510] Wrong line number in Wstrict-overflow message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63510 --- Comment #11 from Chen Gang gang.chen.5i5j at gmail dot com --- Created attachment 36267 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36267action=edit The related fix patch for it. The related fix patch for it: current input_location isn't precise for reporting warning. The correct location is gimple location of current statement.
[Bug middle-end/63510] Wrong line number in Wstrict-overflow message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63510 --- Comment #10 from Chen Gang gang.chen.5i5j at gmail dot com --- Need use gimple_location(stmt) for it. The stmt is the variable in gcc/tree-ssa-sccvn.c before call fold_binary(). But unlucky, it is not passed into fold_binary(), we can not get it directly. After try a temporary fix, the related output is: [root@localhost build-gcc-x86_64]# gcc -O2 -Wall -Wextra -c /tmp/i387-tdep.c when assuming that (X + c) = X is always true /tmp/i387-tdep.c: In function ‘i387_supply_fsave’: /tmp/i387-tdep.c:6:3: warning: assuming signed overflow does not occur when assuming that (X + c) = X is always true [-Wstrict-overflow] for (i = st0_regnum; i st0_regnum + 16;) ^ I shall try to give a normal fix for it, next.
[Bug middle-end/63510] Wrong line number in Wstrict-overflow message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63510 --- Comment #9 from Chen Gang gang.chen.5i5j at gmail dot com --- We need call warning_at() instead of warnings() in fold_overflow_warning() in gcc/fold-const.c. The related location parameter of warning_at() should be calculated, just like another gcc files has done: e.g. gcc/c-family/*.c which use warning_at(). I shall continue to analyze how to calculate the location in gcc/fold-const.c, reference from the other files. Thanks.
[Bug middle-end/63510] Wrong line number in Wstrict-overflow message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63510 --- Comment #8 from Chen Gang gang.chen.5i5j at gmail dot com --- For the latest gcc, it still has this issue, I shall try to fix it during these days (hope can fix it within this month). Thanks.
[Bug target/66620] bfin: bfin.c: (hwloop_optimize): gcc_assert (JUMP_P (insn)) fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66620 --- Comment #8 from Chen Gang gang.chen.5i5j at gmail dot com --- Created attachment 35866 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35866action=edit Full insns for without -fno-reorder-blocks.
[Bug target/66620] bfin: bfin.c: (hwloop_optimize): gcc_assert (JUMP_P (insn)) fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66620
--- Comment #9 from Chen Gang gang.chen.5i5j at gmail dot com ---
After check the assembly result for the without -fno-reorder-block, it is OK.
It is for lsetup optimization.
And for having -fno-reorder-block, the insns are also correct, and after skip
the related assert(), it can also pass compiling and generate the correct
assembly code.
The related diff is below, and the related assembly code is in the next
attachment.
diff --git a/gcc/config/bfin/bfin.c b/gcc/config/bfin/bfin.c
index 3b4b54e..91866dd 100644
--- a/gcc/config/bfin/bfin.c
+++ b/gcc/config/bfin/bfin.c
@@ -3520,7 +3520,13 @@ hwloop_optimize (hwloop_info loop)
if (vec_safe_length (loop-incoming) 1
|| !(loop-incoming-last ()-flags EDGE_FALLTHRU))
{
- gcc_assert (JUMP_P (insn));
+ if (!JUMP_P (insn))
+ {
+ if (dump_file)
+ fprintf (dump_file, ;; loop %d lsetup may already inserted\n,
+loop-loop_no);
+ return false;
+ }
insn = PREV_INSN (insn);
}
[Bug target/66620] bfin: bfin.c: (hwloop_optimize): gcc_assert (JUMP_P (insn)) fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66620 --- Comment #12 from Chen Gang gang.chen.5i5j at gmail dot com --- Created attachment 35869 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35869action=edit The result before lsetup optimization The lsetup information is below: lsetup (loop_begin, loop_end) count. R0 will add 1 for each times, in our case, it is initialized to 0 before lsetup(). After the loop_end, in our case, it needs R0 += 1 to increase the last count.
[Bug target/66620] bfin: bfin.c: (hwloop_optimize): gcc_assert (JUMP_P (insn)) fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66620 --- Comment #10 from Chen Gang gang.chen.5i5j at gmail dot com --- Created attachment 35867 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35867action=edit The result after skip the assert() for having -fno-reorder-block
[Bug target/66620] bfin: bfin.c: (hwloop_optimize): gcc_assert (JUMP_P (insn)) fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66620 --- Comment #11 from Chen Gang gang.chen.5i5j at gmail dot com --- Created attachment 35868 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35868action=edit The result when without -fno-reorder-block
[Bug target/66620] bfin: bfin.c: (hwloop_optimize): gcc_assert (JUMP_P (insn)) fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66620 --- Comment #7 from Chen Gang gang.chen.5i5j at gmail dot com --- (In reply to Chen Gang from comment #2) (In reply to Mikhail Maltsev from comment #1) Started with r208165. OK, thanks. Really it is, it is valuable to me (it can generate the correct insns for comparing). And also if remove -fno-reorder-blocks, it can generate correct insns too (after comparing with the original correct insns, this optimized insns are correct). Oh, sorry, after check again, I missed the left output (which is final output) when remove -fno-reorder-blocks. For removing -fno-reorder-blocks, it is passed compiling, but we should check the assembly output too: hwloop_optimize() generates almost the same insns just like having -fno-reorder-blocks, but it is passed compiling. The related full insns for removing -fno-reorder-blocks are in the next attachment.
[Bug target/66620] bfin: bfin.c: (hwloop_optimize): gcc_assert (JUMP_P (insn)) fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66620 --- Comment #6 from Chen Gang gang.chen.5i5j at gmail dot com --- 1st call in hwloop_optimize() in gcc/config/bfin/bfin.c, the input insns are correct (just the same as insns-should_be.log), but the output insns are incorrect (just the same as insns-issue.log). Then 2nd call in hwloop_optimize() in gcc/config/bfin/bfin.c finds this issue, then cause assert().
[Bug target/66620] bfin: bfin.c: (hwloop_optimize): gcc_assert (JUMP_P (insn)) fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66620
--- Comment #2 from Chen Gang gang.chen.5i5j at gmail dot com ---
(In reply to Mikhail Maltsev from comment #1)
Started with r208165.
OK, thanks. Really it is, it is valuable to me (it can generate the correct
insns for comparing). And also if remove -fno-reorder-blocks, it can generate
correct insns too (after comparing with the original correct insns, this
optimized insns are correct).
In our case, the issue insn is:
(insn 132 59 74 6 (parallel [
(set (reg:SI 45 LT1)
(label_ref 74))
(set (reg:SI 49 LB1)
(label_ref 133))
(set (reg:SI 47 LC1)
(reg:SI 8 P0 [112]))
]) lpt_commit.i:11 -1
(nil))
it is in an incorrect area, which want to optimize the insns below in another
area:
(note 68 67 69 9 [bb 9] NOTE_INSN_BASIC_BLOCK)
(insn:TI 69 68 109 9 (set (reg/v:SI 0 R0 [orig:94 iip ] [94])
(plus:SI (reg/v:SI 0 R0 [orig:94 iip ] [94])
(const_int 1 [0x1]))) lpt_commit.i:19 50 {addsi3}
(nil))
(jump_insn:TI 109 69 73 9 (parallel [
(set (pc)
(if_then_else (ne (reg:SI 8 P0 [112])
(const_int 1 [0x1]))
(label_ref:SI 70)
(pc)))
(set (reg:SI 8 P0 [112])
(plus:SI (reg:SI 8 P0 [112])
(const_int -1 [0x])))
(unspec [
(const_int 0 [0])
] 10)
(clobber (scratch:SI))
]) lpt_commit.i:19 96 {loop_end}
(int_list:REG_BR_PROB 7384 (nil))
- 70)
The incorrect insn wants to merge the too for (iip = 0; iip 4; iip++) {...}
in one.
Next, I shall continue analyzing it, and the all related insns are in
attachments. And welcome any ideas, suggestions and completions, Thanks.
[Bug target/66620] bfin: bfin.c: (hwloop_optimize): gcc_assert (JUMP_P (insn)) fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66620 --- Comment #4 from Chen Gang gang.chen.5i5j at gmail dot com --- Created attachment 35863 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35863action=edit The correct insns without -fno-reorder-blocks
[Bug target/66620] bfin: bfin.c: (hwloop_optimize): gcc_assert (JUMP_P (insn)) fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66620 --- Comment #3 from Chen Gang gang.chen.5i5j at gmail dot com --- Created attachment 35862 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35862action=edit The insns for our issue.
[Bug target/66620] bfin: bfin.c: (hwloop_optimize): gcc_assert (JUMP_P (insn)) fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66620 --- Comment #5 from Chen Gang gang.chen.5i5j at gmail dot com --- Created attachment 35864 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35864action=edit The correct insns should be with -fno-reorder-blocks
[Bug target/66620] New: bfin: bfin.c: (hwloop_optimize): gcc_assert (JUMP_P (insn)) fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66620
Bug ID: 66620
Summary: bfin: bfin.c: (hwloop_optimize): gcc_assert (JUMP_P
(insn)) fails.
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gang.chen.5i5j at gmail dot com
Target Milestone: ---
[root@localhost gcc]# cat lpt_commit.i
struct ubifs_nnode {
int iip;
int level;
int nbranch[4];
};
struct ubifs_nnode *next_pnode_to_dirty(struct ubifs_nnode *nnode)
{
int iip;
while (nnode-level 1) {
for (iip = 0; iip 4; iip++) {
if (nnode-nbranch[iip])
break;
}
nnode = nnode + iip;
}
for (iip = 0; iip 4; iip++)
if (nnode-nbranch[iip])
break;
return nnode + iip;
}
[root@localhost gcc]# /upstream/build-gcc-blackfin/gcc/cc1 -Os
-fno-reorder-blocks lpt_commit.i
next_pnode_to_dirty
Analyzing compilation unit
Performing interprocedural optimizations
*free_lang_data visibility build_ssa_passes opt_local_passes
free-inline-summary emutls whole-program profile_estimate icf
devirt cp inline pure-const static-var single-use
comdatsAssembling functions:
next_pnode_to_dirty
lpt_commit.i: In function 'next_pnode_to_dirty':
lpt_commit.i:24:1: internal compiler error: in hwloop_optimize, at
config/bfin/bfin.c:3523
}
^
0xd9c8eb hwloop_optimize
../../gcc/gcc/config/bfin/bfin.c:3523
0xe3b0cb optimize_loop
../../gcc/gcc/hw-doloop.c:610
0xe3cb1e reorg_loops(bool, hw_doloop_hooks*)
../../gcc/gcc/hw-doloop.c:674
0xda055f bfin_reorg_loops
../../gcc/gcc/config/bfin/bfin.c:3908
0xda055f bfin_reorg
../../gcc/gcc/config/bfin/bfin.c:4650
0xa3a169 execute
../../gcc/gcc/reorg.c:4030
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[root@localhost gcc]# /upstream/build-gcc-blackfin/gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=/upstream/build-gcc-blackfin/gcc/xgcc
Target: bfin-gchen-elf
Configured with: ../gcc/configure --target=bfin-gchen-elf --disable-nls
--disable-threads --disable-shared --disable-libssp --disable-libquadmath
--disable-libgomp --disable-libatomic --prefix=/upstream/release-blackfin
--without-headers --enable-languages=c,lto
Thread model: single
gcc version 6.0.0 20150620 (experimental) (GCC)
[Bug target/65803] blackfin: internal compiler error: segment fault linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65803
--- Comment #4 from Chen Gang gang.chen.5i5j at gmail dot com ---
Reference to gccint.pdf Page 268 for jump_isn, we know that JUMP_LABLE() must
be defined after optimization completed. In our case, we are just doing
optimization, and is almost finished, so we need set JUMP_LABLE() after emit
jump_insn.
The related diff is bellow:
diff --git a/gcc/config/bfin/bfin.c b/gcc/config/bfin/bfin.c
index dc24ed5..0297b59 100644
--- a/gcc/config/bfin/bfin.c
+++ b/gcc/config/bfin/bfin.c
@@ -3777,7 +3777,10 @@ hwloop_optimize (hwloop_info loop)
}
else
{
- emit_jump_insn (gen_jump (label));
+ rtx_insn * ret = emit_jump_insn (gen_jump (label));
+
+ JUMP_LABEL(ret) = label;
+ LABEL_NUSES (label)++;
seq_end = emit_barrier ();
}
}
[Bug target/65803] blackfin: internal compiler error: segment fault linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65803
--- Comment #3 from Chen Gang gang.chen.5i5j at gmail dot com ---
It is about JUMP_LABEL, gcc should set the JUMP_LABEL before use it. If we set
the label as soon as it is generated, it can build the issue code successfully.
diff --git a/gcc/config/bfin/bfin.c b/gcc/config/bfin/bfin.c
index dc24ed5..b8c9567 100644
--- a/gcc/config/bfin/bfin.c
+++ b/gcc/config/bfin/bfin.c
@@ -3777,7 +3777,8 @@ hwloop_optimize (hwloop_info loop)
}
else
{
- emit_jump_insn (gen_jump (label));
+ rtx_insn * ret = emit_jump_insn (gen_jump (label));
+ JUMP_LABEL(ret) = label;
seq_end = emit_barrier ();
}
}
So we can say, it must be the direct cause (but may be not the root cause). I
shall continue analyzing: why gcc did not set JUMP_LABEL before using it.
Welcome any others' ideas, suggestions and completions.
Thanks.
[Bug target/65803] New: blackfin: internal compiler error: segment fault linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65803
Bug ID: 65803
Summary: blackfin: internal compiler error: segment fault linux
kernel
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gang.chen.5i5j at gmail dot com
The code:
[root@localhost gcc]# cat lbalance.i
struct a {
short count;
};
struct reiserfs_de_head {
unsigned short deh_location;
} __attribute__ ((__packed__));
void leaf_cut_from_buffer(struct a *ih, int from)
{
struct reiserfs_de_head *deh = (struct reiserfs_de_head *)ih;
int i;
for (i = ih-count - 1; i from; i--)
deh[i].deh_location--;
for (i = 0; i from; i++)
deh[i].deh_location--;
}
The error:
[root@localhost gcc]# /upstream/build-gcc-blackfin/gcc/cc1 lbalance.i -Os
-fno-strict-overflow
lbalance.i: In function 'leaf_cut_from_buffer':
lbalance.i:19:1: internal compiler error: Segmentation fault
}
^
0xa54a9f crash_signal
../../gcc-blackfin/gcc/toplev.c:383
0x77af8b INSN_UID
../../gcc-blackfin/gcc/rtl.h:1329
0x77af8b insn_current_reference_address(rtx_insn*)
../../gcc-blackfin/gcc/final.c:686 0xd39604
insn_current_length(rtx_insn*)
/upstream/build-gcc-blackfin/gcc/insn-attrtab.c:84
0x77c12e shorten_branches(rtx_insn*)
../../gcc-blackfin/gcc/final.c:1478
0x77c51f rest_of_handle_shorten_branches
../../gcc-blackfin/gcc/final.c:4580
0x77c51f execute
../../gcc-blackfin/gcc/final.c:4609
Please submit a full bug report,
The version:
[root@localhost gcc]# /upstream/release-blackfin/bin/bfin-gchen-elf-gcc -v
Using built-in specs.
COLLECT_GCC=/upstream/release-blackfin/bin/bfin-gchen-elf-gcc
COLLECT_LTO_WRAPPER=/upstream/release-blackfin/libexec/gcc/bfin-gchen-elf/5.0.0/lto-wrapper
Target: bfin-gchen-elf
Configured with: ../gcc-blackfin/configure --target=bfin-gchen-elf
--disable-nls --disable-threads --disable-shared --disable-libssp
--disable-libquadmath --disable-libgomp --disable-libatomic
--prefix=/upstream/release-blackfin --without-headers
target_alias=bfin-gchen-elf --enable-languages=c,lto
Thread model: single
gcc version 5.0.0 20150401 (experimental) (GCC)
[Bug target/65804] New: blackfin: Not support global frame pointer with -fno-omit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65804
Bug ID: 65804
Summary: blackfin: Not support global frame pointer with
-fno-omit-frame-pointer
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gang.chen.5i5j at gmail dot com
The code:
[root@localhost gcc]# cat stacktrace.i
register unsigned long current_frame_pointer asm(FP);
void save_stack_trace(void)
{
unsigned long fp;
fp = current_frame_pointer;
}
For gcc5 from upstream (cause issue):
[root@localhost gcc]# /upstream/release-blackfin/bin/bfin-gchen-elf-gcc
-mcpu=bf533-0.3 -fno-omit-frame-pointer -pg -c stacktrace.i
stacktrace.i: In function 'save_stack_trace':
stacktrace.i:3:6: error: frame pointer required, but reserved
void save_stack_trace(void)
^
stacktrace.i:1:24: note: for 'current_frame_pointer'
register unsigned long current_frame_pointer asm(FP);
^
[root@localhost linux-next]#
/upstream/release-blackfin/bin/bfin-gchen-elf-gcc -v
Using built-in specs.
COLLECT_GCC=/upstream/release-blackfin/bin/bfin-gchen-elf-gcc
COLLECT_LTO_WRAPPER=/upstream/release-blackfin/libexec/gcc/bfin-gchen-elf/5.0.0/lto-wrapper
Target: bfin-gchen-elf
Configured with: ../gcc-blackfin/configure --target=bfin-gchen-elf
--disable-nls --disable-threads --disable-shared --disable-libquadmath
--disable-libgomp --disable-libatomic --prefix=/upstream/release-blackfin
--without-headers target_alias=bfin-gchen-elf --enable-languages=c
Thread model: single
gcc version 5.0.0 20150401 (experimental) (GCC)
For blackfin gcc4.5.4 from soureforge (no issue):
root@gchen:/upstream/linux-next# /3p/release-blackfin/bin/bfin-gchen-elf-gcc
-mcpu=bf533-0.3 -fno-omit-frame-pointer -pg -c stacktrace.i
root@gchen:/upstream/linux-next# /3p/release-blackfin/bin/bfin-gchen-elf-gcc
-v
Using built-in specs.
COLLECT_GCC=/3p/release-blackfin/bin/bfin-gchen-elf-gcc
COLLECT_LTO_WRAPPER=/3p/release-blackfin/libexec/gcc/bfin-gchen-elf/4.5.4/lto-wrapper
Target: bfin-gchen-elf
Configured with: ../gcc/configure --target=bfin-gchen-elf --disable-nls
--disable-threads --disable-shared --disable-libssp --disable-libquadmath
--disable-libgomp --disable-libatomic --prefix=/upstream/release-blackfin
--without-headers --enable-languages=c : (reconfigured) ../gcc/configure
--target=bfin-gchen-elf --disable-nls --disable-threads --disable-shared
--disable-libssp --disable-libquadmath --disable-libgomp --disable-libatomic
--prefix=/3p/release-blackfin --without-headers --enable-languages=c
Thread model: single
gcc version 4.5.4 (GCC)
[Bug target/65510] target-tic6x: unrecognizable insn with -O(1,2,3,s).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65510 --- Comment #5 from Chen Gang gang.chen.5i5j at gmail dot com --- After remove clobber (match_scratch ...), it will generate the correct assembly code (I guess it is): .file test.i .c6xabi_attribute Tag_ABI_array_object_alignment, 0 .c6xabi_attribute Tag_ABI_array_object_align_expected, 0 .c6xabi_attribute Tag_ABI_stack_align_needed, 0 .c6xabi_attribute Tag_ABI_stack_align_preserved, 0 .c6xabi_attribute Tag_ABI_conformance, 1.0 .text; .align 2 .global oxu_driver_init .type oxu_driver_init, @function oxu_driver_init: mvk .d1 11, A4 ldnw.d1t1 *A4, A3 nop 4 stnw.d1t1 A3, *A4 ret .s2 B3 nop 5 .size oxu_driver_init, .-oxu_driver_init .ident GCC: (GNU) 5.0.0 20150321 (experimental) And also can cross building Linux kernel with allmodconfig successfully. I shall send patch for it, next.
[Bug target/65510] target-tic6x: unrecognizable insn with -O(1,2,3,s).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65510 --- Comment #4 from Chen Gang gang.chen.5i5j at gmail dot com --- In gcc/config/c6x/c6x.md, if we remove (clober ...) for movmisalignmode_store, it will be OK (just symmetric with movmisalignmode_load which is OK). (define_insn_and_split movmisalignmode_store [(set (match_operand:SIDIVM 0 memory_operand =W,Q,T,Q,T) (unspec:SIDIVM [(match_operand:SIDIVM 1 register_operand r,a,b,b,a)] UNSPEC_MISALIGNED_ACCESS)) (clobber (match_scratch:SI 2 =r,X,X,X,X))] I shall try to analyze why clobber match_scratch will cause issue.
[Bug target/65510] target-tic6x: unrecognizable insn with -O(1,2,3,s).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65510
--- Comment #3 from Chen Gang gang.chen.5i5j at gmail dot com ---
(In reply to Chen Gang from comment #2)
For test.i:
int oxu_driver_init(void)
{
*(volatile unsigned int *)(-1) = *(unsigned int *)(-1);
}
If test.i use a valid number (= 0x10) or normal variable instead of -1,
it will be OK (the insns are almost the same between using valid numbers and
using variable).
If test.i use 0 (NULL) instead of -1, it will be OK, too, but it will
generate an abort() insn for it (unlike valid numbers' and variable's insn).
If test.i se invalid number (e.g. -2, -1, 0x1, 0x2 ... 0xf), it will
generate a different insn which can not be recognized by MD file.
So for me, we need process the left invalid numbers just as processing 0
(NULL) -- generate an abort() insn for them.
Oh, sorry, the contents above is incorrect, it is about memory alignment issue.
If the alignment is less than 32, it will cause issue. e.g. 0, 4, 8, 16, 20,
pointer parameter ... are all OK, but the other will cause issue.
[Bug target/65510] target-tic6x: unrecognizable insn with -O(1,2,3,s).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65510
--- Comment #2 from Chen Gang gang.chen.5i5j at gmail dot com ---
For test.i:
int oxu_driver_init(void)
{
*(volatile unsigned int *)(-1) = *(unsigned int *)(-1);
}
If test.i use a valid number (= 0x10) or normal variable instead of -1, it
will be OK (the insns are almost the same between using valid numbers and using
variable).
If test.i use 0 (NULL) instead of -1, it will be OK, too, but it will
generate an abort() insn for it (unlike valid numbers' and variable's insn).
If test.i se invalid number (e.g. -2, -1, 0x1, 0x2 ... 0xf), it will generate a
different insn which can not be recognized by MD file.
So for me, we need process the left invalid numbers just as processing 0 (NULL)
-- generate an abort() insn for them.
[Bug target/65510] target-tic6x: unrecognizable insn with -O(1,2,3,s).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65510 Chen Gang gang.chen.5i5j at gmail dot com changed: What|Removed |Added CC||gang.chen.5i5j at gmail dot com --- Comment #1 from Chen Gang gang.chen.5i5j at gmail dot com --- I shall try to fix it within this month (2015-03-31).
[Bug target/65510] New: target-tic6x: unrecognizable insn with -O(1,2,3,s).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65510
Bug ID: 65510
Summary: target-tic6x: unrecognizable insn with -O(1,2,3,s).
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gang.chen.5i5j at gmail dot com
[root@localhost c6x]# cat test.i
int oxu_driver_init(void)
{
*(volatile unsigned int *)(-1) = *(unsigned int *)(-1);
}
[root@localhost c6x]#
/upstream/release-c6x/libexec/gcc/tic6x-gchen-elf/5.0.0/cc1 -Os test.i
oxu_driver_init
test.i: In function 'oxu_driver_init':
test.i:4:1: error: unrecognizable insn:
}
^
(insn 9 8 12 2 (set (mem/v:SI (reg/f:SI 77) [1 MEM[(volatile unsigned int
*)4294967295B]+0 S4 A8])
(unspec:SI [
(reg:SI 73 [ D.1542 ])
] UNSPEC_MISALIGNED_ACCESS)) test.i:3 -1
(nil))
test.i:4:1: internal compiler error: in extract_insn, at recog.c:2343
0x9f8645 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc-c6x/gcc/rtl-error.c:110
0x9f8679 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc-c6x/gcc/rtl-error.c:118
0x9ce127 extract_insn(rtx_insn*)
../../gcc-c6x/gcc/recog.c:2343
0x7c759b instantiate_virtual_regs_in_insn
../../gcc-c6x/gcc/function.c:1598
0x7c759b instantiate_virtual_regs
../../gcc-c6x/gcc/function.c:1966
0x7c759b execute
../../gcc-c6x/gcc/function.c:2015
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[root@localhost c6x]#
[root@localhost c6x]# /upstream/release-c6x/bin/tic6x-gchen-elf-gcc -v
Using built-in specs.
COLLECT_GCC=/upstream/release-c6x/bin/tic6x-gchen-elf-gcc
COLLECT_LTO_WRAPPER=/upstream/release-c6x/libexec/gcc/tic6x-gchen-elf/5.0.0/lto-wrapper
Target: tic6x-gchen-elf
Configured with: ../gcc-c6x/configure --target=tic6x-gchen-elf --disable-nls
--enable-languages=c --disable-threads --disable-shared --disable-libssp
--disable-libquadmath --disable-libgomp --disable-libatomic
--prefix=/upstream/release-c6x --without-headers
Thread model: single
gcc version 5.0.0 20150321 (experimental) (GCC)
[Bug c/65117] xtensa: With -Os, invalid parameter c1 for reg_class_subset_p() to cause segment fault.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65117 --- Comment #1 from Chen Gang gang.chen.5i5j at gmail dot com --- The root cause is in function 'find_reload' (at least it should be a real cause): - 'this_alternative_match_win' is not initialized before use it -- for the first looping 0, it initializes 'this_alternative_match_win[0]', but 'did_match' may use 'this_alternative_match_win[2]'. - 'this_alternative' is not initialized before use it -- it initializes this_alternative[i], but may use this_alternative[m] (m i). After initialize the 2 arrays with 0, this issue can be fixed (r100.i can pass compiling).
[Bug target/65117] xtensa: With -Os, invalid parameter c1 for reg_class_subset_p() to cause segment fault.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65117 --- Comment #2 from Chen Gang gang.chen.5i5j at gmail dot com --- Oh, sorry, one typo issue: 'this_alternative_match_win' is incorrect, it should be 'this_alternative_win'.
[Bug c/65117] New: xtensa: With -Os, invalid parameter c1 for reg_class_subset_p() to cause segment fault.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65117
Bug ID: 65117
Summary: xtensa: With -Os, invalid parameter c1 for
reg_class_subset_p() to cause segment fault.
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gang.chen.5i5j at gmail dot com
The related source file:
# cat r100.i
#pragma pack()
struct r100_cs_cube_info {
char a[17];
unsigned int width;
unsigned int height;
};
struct r100_cs_track_texture {
char a[96];
struct r100_cs_cube_info cube_info[5];
unsigned int tex_coord_type;
unsigned int txdepth;
char roundup_h;
};
struct r100_cs_track {
char a[89];
unsigned int num_cb;
unsigned int num_texture;
struct r100_cs_track_texture textures[2];
};
struct radeon_device;
void r100_cs_track_clear(int x, struct r100_cs_track *y)
{
int i, j;
for (i = 0; i y-num_texture; i++) {
if (x = 8)
y-textures[i].txdepth = 0;
else {
y-textures[i].txdepth = 9;
y-textures[i].tex_coord_type = 1;
}
y-textures[i].roundup_h = 0;
if (y-num_cb)
for (j= 0; j 5; j++) {
y-textures[i].cube_info[j].width = 2;
y-textures[i].cube_info[j].height = 2;
}
}
}
The related issue:
# /upstream/release-xtensa/libexec/gcc/xtensa-gchen-elf32/5.0.0/cc1 -Os r100.i
r100.i: In function 'r100_cs_track_clear':
r100.i:43:1: internal compiler error: Segmentation fault
}
^
0xa4427f crash_signal
../../gcc-xtensa/gcc/toplev.c:383
0x9c79c0 reg_class_subset_p(int, int)
../../gcc-xtensa/gcc/reginfo.c:1221
0x9d7a0c find_reloads(rtx_insn*, int, int, int, short*)
../../gcc-xtensa/gcc/reload.c:3678
0x9e2cbb reload_as_needed
../../gcc-xtensa/gcc/reload1.c:4688
0x9e8460 reload(rtx_insn*, int)
../../gcc-xtensa/gcc/reload1.c:1092
0x8cdb2d do_reload
../../gcc-xtensa/gcc/ira.c:5430
0x8cdb2d execute
../../gcc-xtensa/gcc/ira.c:5589
The related version:
# /upstream/release-xtensa/bin/xtensa-gchen-elf32-gcc -v
Using built-in specs.
COLLECT_GCC=/upstream/release-xtensa/bin/xtensa-gchen-elf32-gcc
COLLECT_LTO_WRAPPER=/upstream/release-xtensa/libexec/gcc/xtensa-gchen-elf32/5.0.0/lto-wrapper
Target: xtensa-gchen-elf32
Configured with: ../gcc-xtensa/configure --target=xtensa-gchen-elf32
--prefix=/upstream/release-xtensa --disable-nls --enable-languages=c
--disable-threads --disable-shared --enable-libssp --disable-libquadmath
--disable-libgomp --disable-libatomic
Thread model: single
gcc version 5.0.0 20150219 (experimental) (GCC)
# /upstream/release-xtensa/bin/xtensa-gchen-elf32-ld -v
GNU ld (GNU Binutils) 2.25.51.20150219
I shall try to fix it within this month, at present, the direct cause is: for
reg_class_subset_p(), the upper caller passes an incorrect parameter c1 which
value is -926186479, and this issue has only effect with -Os (no effect with
-O0, or -O2 ...).
[Bug target/58400] gcc for h8300 internal compiler error: insn does not satisfy its constraints at fs/ext4/mballoc.c: In function 'mb_free_blocks':
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58400 --- Comment #16 from Chen Gang gang.chen.5i5j at gmail dot com --- (In reply to Jeffrey A. Law from comment #15) The patch needs to be reviewed. It's been a long time since I thought about the _STRICT variants of the REG_OK_ macros and how all that's supposed to work. I'll have to read up on their semantics before I can review this patch. Can I do anything helpful for this issue, next? If I can, please let me know, and I shall try.
[Bug target/58400] gcc for h8300 internal compiler error: insn does not satisfy its constraints at fs/ext4/mballoc.c: In function 'mb_free_blocks':
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58400 --- Comment #13 from Chen Gang gang.chen.5i5j at gmail dot com --- (In reply to Jeffrey A. Law from comment #12) Please leave the bug open until a fix is committed to the trunk. OK, thanks. Could any members help to commit the related patch to the trunk? I guess, I am not the suitable member to do it: - I only reported and monitored this issue, but did not analyze it in details, this issue is fixed by another related members. - Either, at present, I have no write right for main branch (I have posted my assignment paper to FSF in 2015-01-31, I guess, it will reach FSF within 2015-02-28). Thanks.
[Bug target/58400] gcc for h8300 internal compiler error: insn does not satisfy its constraints at fs/ext4/mballoc.c: In function 'mb_free_blocks':
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58400 Chen Gang gang.chen.5i5j at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Chen Gang gang.chen.5i5j at gmail dot com --- (In reply to Yoshinori Sato from comment #10) I verified fix problem in this patch. (4.9.2 and 5.0) Thank you for your response. Then I should mark it is as fixed, at present. If any members find this issue will repeat again in the future, please reopen it.
[Bug target/58400] gcc for h8300 internal compiler error: insn does not satisfy its constraints at fs/ext4/mballoc.c: In function 'mb_free_blocks':
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58400 --- Comment #9 from Chen Gang gang.chen.5i5j at gmail dot com --- (In reply to Jorn Wolfgang Rennecke from comment #8) Created attachment 32285 [details] patch made as an example how to debug gcc here is a patch - not regtested. you might also consider to put the three non-constriant uses of [satisfies_constraint_]U in predicates.md into a different constraint /vpredicate. And delete the unused fix_bit_operand, Is this issue fixed? If need continue to test and analyze, please let me know (If really need continue, I shall try to finish it within next month)
[Bug target/58256] gcc for h8300 internal compiler error: in maybe_record_trace_start
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58256 --- Comment #13 from Chen Gang gang.chen.5i5j at gmail dot com --- For gcc version 5.0.0 20150109 (experimental) (GCC), can not find this issue again. So at present, we can close it.
[Bug target/58256] gcc for h8300 internal compiler error: in maybe_record_trace_start
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58256 Chen Gang gang.chen.5i5j at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #14 from Chen Gang gang.chen.5i5j at gmail dot com --- For gcc version 5.0.0 20150109 (experimental) (GCC), can not find this issue again. So at present, we can mark it as FIXED
[Bug middle-end/63510] Wrong line number in Wstrict-overflow message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63510 --- Comment #4 from Chen Gang gang.chen.5i5j at gmail dot com --- For gcc version 5.0.0 20150109 (experimental) (GCC), can not find this warnings again. So at present, for me, this bug can be closed.
[Bug middle-end/63510] Wrong line number in Wstrict-overflow message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63510 --- Comment #3 from Chen Gang gang.chen.5i5j at gmail dot com --- It still exists in gcc version 5.0.0 20141109 (experimental) (GCC), I shall try to solve it. Hope I can finish within 2 months.
