[Bug target/40031] [4.5 Regression] ARM broken with addresses in PHIs with -fPIC
--- Comment #2 from ramana at gcc dot gnu dot org 2009-05-06 08:46 ---
Can't replicate this with a stage2 or stage3 compiler with O2, O3, Os -fPIC
{-mthumb} with r147121.
However while bootstrapping the above mentioned revision, I get a segfault as
in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39929#c12 but with .
ram...@gcc55:~/build-20090505/armv5tel-unknown-linux-gnueabi/libstdc++-v3/libsupc++\[01;32mram...@gcc55[01;34m
~/build-20090505/armv5tel-unknown-linux-gnueabi/libstdc++-v3/libsupc++ $[00m
[Kgdb --args /home/ramana/build-20090505/./gcc/cc1 -quiet -v -I..
-I/home/ramana/trunk/libstdc++-v3/../libiberty
-I/home/ramana/trunk/libstdc++-v3/../include
-I/home/ramana/build-20090505/armv5tel-unknown-linux-gnueabi/libstdc++-v3/include/armv5tel-unknown-linux-gnueabi
-I/home/ramana/build-20090505/armv5tel-unknown-linux-gnuea
bi/libstdc++-v3/include -I/home/ramana/trunk/libstdc++-v3/libsupc++ -iprefix
/home/ramana/build-20090505/gcc/../lib/gcc/armv5tel-unknown-linux-gnueabi/4.5.0/
-isystem /home/ramana/build-20090505/./gcc/include -isystem
/home/ramana/build-20090505/./gcc/include-fixed -DHAVE_CONFIG_H -DIN_GLIBCPP_V3
-DPIC -isystem /usr/local/armv5tel-unknown-linux-gnueabi/include -isystem
/usr/local/armv5tel-unknown-linux-gnueabi/sys-include cp-demangle.c -quiet
-dumpbase cp-demangle.c -auxbase-strip cp-demangle.o -g -O2 -Wno-error -version
-fPIC -o /tmp/ccIO2OGk.s
(gdb) r
Starting program: /home/ramana/build-20090505/gcc/cc1 -quiet -v -I..
-I/home/ramana/trunk/libstdc++-v3/../libiberty
-I/home/ramana/trunk/libstdc++-v3/../include
-I/home/ramana/build-20090505/armv5tel-unknown-linux-gnueabi/libstdc++-v3/include/armv5tel-unknown-linux-gnueabi
-I/home/ramana/build-20090505/armv5tel-unknown-linux-gnueabi/libstdc++-v3/include
-I/home/ramana/trunk/libstdc++-v3/libsupc++ -iprefix
/home/ramana/build-20090505/gcc/../lib/gcc/armv5tel-unknown-linux-gnueabi/4.5.0/
-isystem /home/ramana/build-20090505/./gcc/include -isystem
/home/ramana/build-20090505/./gcc/include-fixed -DHAVE_CONFIG_H -DIN_GLIBCPP_V3
-DPIC -isystem /usr/local/armv5tel-unknown-linux-gnueabi/include -isystem
/usr/local/armv5tel-unknown-linux-gnueabi/sys-include cp-demangle.c -quiet
-dumpbase cp-demangle.c -auxbase-strip cp-demangle.o -g -O2 -Wno-error -version
-fPIC -o /tmp/ccIO2OGk.s
GNU C (GCC) version 4.5.0 20090505 (experimental) [trunk revision 147121]
(armv5tel-unknown-linux-gnueabi)
compiled by GNU C version 4.5.0 20090505 (experimental) [trunk revision
147121], GMP version 4.2.4, MPFR version 2.3.2.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Program received signal SIGSEGV, Segmentation fault.
emit_insn_after_1 (first=0x403790f0, after=0x40588f50, bb=0xa5a5a5a5) at
../../trunk/gcc/emit-rtl.c:4129
4129 if (BB_END (bb) == after)
(gdb) bt
#0 emit_insn_after_1 (first=0x403790f0, after=0x40588f50, bb=0xa5a5a5a5) at
../../trunk/gcc/emit-rtl.c:4129
#1 0x0053cc60 in legitimize_pic_address (orig=0x40595b80, mode=, reg=0x0) at ../../trunk/gcc/config/arm/arm.c:3600
#2 0x00602060 in gen_movsi (operand0=0x0, operand1=) at
../../trunk/gcc/config/arm/arm.md:4966
#3 0x001e72c0 in emit_move_insn_1 (x=0x40706d38, y=0x40595b80) at
../../trunk/gcc/expr.c:3337
#4 0x001e756c in emit_move_insn (x=0x40706d38, y=0x40595b80) at
../../trunk/gcc/expr.c:3425
#5 0x001c3a60 in force_reg (mode=SImode, x=0x40595b80) at
../../trunk/gcc/explow.c:663
#6 0x001c4a90 in use_anchored_address (x=0x403d8350) at
../../trunk/gcc/explow.c:583
#7 0x001dd558 in expand_expr_real_1 (exp=0x404a8b40, target=, tmode=, modifier=, alt_rtl=0x0)
at ../../trunk/gcc/expr.c:7329
#8 0x001e6110 in expand_expr_real (exp=0x404a8b40, target=0x40588f50,
tmode=VOIDmode, modifier=EXPAND_WRITE, alt_rtl=0x0) at
../../trunk/gcc/expr.c:7114
#9 0x001ea070 in expand_expr_addr_expr_1 (exp=0x404a8b40, target=0x0,
tmode=SImode, modifier=EXPAND_NORMAL) at ../../trunk/gcc/expr.h:539
#10 0x001e9e14 in expand_expr_addr_expr_1 (exp=0x405fb690, target=0x40706630,
tmode=SImode, modifier=EXPAND_NORMAL) at ../../trunk/gcc/expr.c:6838
#11 0x001db5d4 in expand_expr_real_1 (exp=0x405c1fc0, target=0x40706630,
tmode=, modifier=, alt_rtl=0x0) at
../../trunk/gcc/expr.c:6897
#12 0x001e6110 in expand_expr_real (exp=0x405c1fc0, target=0x40588f50,
tmode=VOIDmode, modifier=EXPAND_WRITE, alt_rtl=0x0) at
../../trunk/gcc/expr.c:7114
#13 0x0072be90 in eliminate_phi (e=0x405fb900, g=0xa39f08) at
../../trunk/gcc/expr.h:539
#14 0x0072cb6c in expand_phi_nodes (sa=) at
../../trunk/gcc/tree-outof-ssa.c:777
#15 0x006b4800 in gimple_expand_cfg () at ../../trunk/gcc/cfgexpand.c:2506
#16 0x002fcdf0 in execute_one_pass (pass=0x95dcfc) at
../../trunk/gcc/passes.c:1291
#17 0x002fd07c in execute_pass_list (pass=0x95dcfc) at
../../trunk/gcc/passes.c:1340
#18 0x003fa1e0 in tree_rest_of_compilation (fndecl=0x403cc580) at
../../trunk/gcc/tree-optimize.c:394
#19 0x0054e584 in cgraph_expand_function (node=0x4047cf00) at
../../trunk/gcc/cgraphunit.c:1051
#20 0x005505
[Bug target/39975] Support big endian ARM by default.
--- Comment #2 from ramana at gcc dot gnu dot org 2009-05-06 10:52 --- *** This bug has been marked as a duplicate of 16350 *** -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39975
[Bug target/16350] gcc only understands little endian ARM systems
--- Comment #23 from ramana at gcc dot gnu dot org 2009-05-06 10:52 --- *** Bug 39975 has been marked as a duplicate of this bug. *** -- ramana at gcc dot gnu dot org changed: What|Removed |Added CC||ramana at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16350
[Bug target/40031] [4.5 Regression] ARM broken with addresses in PHIs with -fPIC
--- Comment #3 from ramana at gcc dot gnu dot org 2009-05-06 10:59 --- (In reply to comment #1) > What's the ICE? > With a cross arm-linux-gnueabi version r147153, I get a segfault with the following backtrace for this particular testcase. #0 0x082112b1 in emit_insn_after_1 (first=0xb7c352d0, after=0xb7c324b0, bb=0xb7c324d4) at /home/ramrad01/sourcearea/trunk/gcc/emit-rtl.c:4129 #1 0x0821214c in emit_insn_after (pattern=0x0, after=0xb7c324b0) at /home/ramrad01/sourcearea/trunk/gcc/emit-rtl.c:4335 #2 0x085eb5b7 in legitimize_pic_address (orig=0xb7c41c08, mode=SImode, reg=0x0) at /home/ramrad01/sourcearea/trunk/gcc/config/arm/arm.c:3599 #3 0x086b2ead in gen_movsi (operand0=0x0, operand1=0xb7c41c08) at /home/ramrad01/sourcearea/trunk/gcc/config/arm/arm.md:4966 #4 0x0824ad24 in emit_move_insn_1 (x=0xb7c39ce0, y=0xb7c41c08) at /home/ramrad01/sourcearea/trunk/gcc/expr.c:3337 #5 0x0824b012 in emit_move_insn (x=0xb7c39ce0, y=0xb7c41c08) at /home/ramrad01/sourcearea/trunk/gcc/expr.c:3425 #6 0x087d1923 in expand_phi_nodes (sa=0x8acb174) at /home/ramrad01/sourcearea/trunk/gcc/tree-outof-ssa.c:211 #7 0x08754d77 in gimple_expand_cfg () at /home/ramrad01/sourcearea/trunk/gcc/cfgexpand.c:2506 #8 0x08381d8d in execute_one_pass (pass=0x8a2f720) at /home/ramrad01/sourcearea/trunk/gcc/passes.c:1291 #9 0x0838200c in execute_pass_list (pass=0x8a2f720) at /home/ramrad01/sourcearea/trunk/gcc/passes.c:1340 #10 0x0848a6c0 in tree_rest_of_compilation (fndecl=0xb7c34680) at /home/ramrad01/sourcearea/trunk/gcc/tree-optimize.c:394 #11 0x085fd902 in cgraph_expand_function (node=0xb7bb8a00) at /home/ramrad01/sourcearea/trunk/gcc/cgraphunit.c:1051 #12 0x085ff7cf in cgraph_optimize () at /home/ramrad01/sourcearea/trunk/gcc/cgraphunit.c:1110 #13 0x080cec7b in c_write_global_declarations () at /home/ramrad01/sourcearea/trunk/gcc/c-decl.c:8364 #14 0x084334a6 in toplev_main (argc=20, argv=0xbf806e84) at /home/ramrad01/sourcearea/trunk/gcc/toplev.c:990 #15 0x08152f82 in main (argc=Cannot access memory at address 0x0 ) at /home/ramrad01/sourcearea/trunk/gcc/main.c:35 -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-06 10:59:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40031
[Bug bootstrap/40053] cp-demangle.c: In function 'd_substitution': segfault on arm-linux-gnueabi
--- Comment #1 from ramana at gcc dot gnu dot org 2009-05-07 08:10 --- *** This bug has been marked as a duplicate of 40031 *** -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40053
[Bug target/40031] [4.5 Regression] ARM broken with addresses in PHIs with -fPIC
--- Comment #4 from ramana at gcc dot gnu dot org 2009-05-07 08:10 --- *** Bug 40053 has been marked as a duplicate of this bug. *** -- ramana at gcc dot gnu dot org changed: What|Removed |Added CC||laurent at guerby dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40031
[Bug debug/31004] arm ABI bug in transfer structure on the 4th parameter
--- Comment #1 from ramana at gcc dot gnu dot org 2009-05-07 11:37 --- Can you try with a later compiler which is in the release train now and get back ? -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31004
[Bug libgomp/33770] gcc4.2.1 :libgomp fails to configure on ARM
--- Comment #1 from ramana at gcc dot gnu dot org 2009-05-07 11:39 --- Can you try with a later compiler ? 4.2.x no longer exists. As long as your headers were fine I don't see why this shouldn't have built. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33770
[Bug target/27308] Compiler generates incorrect code when calling a function with the result of an inline function as parameter
--- Comment #7 from ramana at gcc dot gnu dot org 2009-05-12 09:36 --- Confirmed with r147377 -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-12 09:36:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27308
[Bug target/35296] init_expr_once suboptimal for Thumb
--- Comment #1 from ramana at gcc dot gnu dot org 2009-05-12 10:05 --- init_expr_once is now renamed to init_expr_target, though I see that the comments / code you refer to in the bug report still exist . Can you give any examples of optimizations that might be enabled if we went ahead and tried to get this going ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35296
[Bug c/40128] [ARM] Incorrect optimized code >= -O2
--- Comment #1 from ramana at gcc dot gnu dot org 2009-05-13 09:52 --- Can you try a newer version of the compiler ? 4.1.x is unsupported today. I can see this is fixed on trunk and 4.3 as of revisions 147467 147441. An older version of 4.4 does not show this problem. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40128
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
--- Comment #2 from ramana at gcc dot gnu dot org 2009-05-13 10:08 --- I can see this with trunk at r147467 -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-13 10:08:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246
[Bug tree-optimization/39251] FAIL: g++.dg/tree-ssa/new1.C scan-tree-dump-not forwprop1 "= .* \+ -"
--- Comment #3 from ramana at gcc dot gnu dot org 2009-05-13 10:10 --- Appears on trunk as of r147467. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-13 10:10:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39251
[Bug target/37987] iwmmxt: insn does not satisfy its constraints on (int64_t)
--- Comment #2 from ramana at gcc dot gnu dot org 2009-05-13 10:14 --- Can you check this with a later compiler. 4.2.x is closed. Works for me with current trunk. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37987
[Bug target/34341] GCC generates incorrect code on ARM in certain case, resulting in stack corruption
--- Comment #1 from ramana at gcc dot gnu dot org 2009-05-13 10:52 ---
I see a problem with your testcase here. r is assigned to h which has not been
initialized if I uncomment the line //r=h as per your comment above.
int test_func(void *p) {
dummy_func();
register int r;
register void *h;
if (p == 0) {
return 0;
}
//r = (int)h;
return r;
}
I'm not sure what the bug is here because the testcase doesn't seem reasonable.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34341
[Bug target/37386] Interrupt service routine for arm target corrupts program counter
--- Comment #2 from ramana at gcc dot gnu dot org 2009-05-13 12:31 ---
This appears to be fixed with trunk as of r147467. Can you reproduce this with
4.3 or 4.4 ? If not we can close this one out.
_Z18serial_IRQ_Routinev:
@ Interrupt Service Routine.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
stmfd sp!, {r0, r1, r2, r3, r4, ip}
mov r2, #0
ldr r3, .L9
ldr r0, .L9+4
mov r1, r2
.L6:
ldr r4, [r3, #36]
ldr ip, [r3, #40]
cmp r4, ip
bne .L2
ldr ip, [r3, #32]
cmp ip, #0
beq .L1
.L2:
ldr ip, [r3, #32]
sub ip, ip, #1
str ip, [r3, #32]
ldr ip, [r3, #40]
ldr r4, [r3, #40]
add r4, r4, #1
str r4, [r3, #40]
ldr r4, [r3, #40]
ldrbip, [r3, ip]@ zero_extendqisi2
cmp r4, #32
add r2, r2, #1
streq r1, [r3, #40]
cmp r2, #16
strbip, [r0, #0]
bne .L6
.L1:
ldmfd sp!, {r0, r1, r2, r3, r4, ip}
subspc, lr, #4
.L10:
.align 2
.L9:
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37386
[Bug target/36966] arm iwmmxt builtin problem
--- Comment #2 from ramana at gcc dot gnu dot org 2009-05-13 12:34 --- Appears with today's trunk (r147467) with the following options. /home/ramrad01/fsfbugzilla/pr36966.c: In function 'foo': /home/ramrad01/fsfbugzilla/pr36966.c:5: internal compiler error: in arm_expand_binop_builtin, at config/arm/arm.c:16182 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-13 12:34:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36966
[Bug target/36798] internal compiler error: in arm_expand_binop_builtin, at config/arm/arm.c:12548
--- Comment #7 from ramana at gcc dot gnu dot org 2009-05-13 12:45 --- I get an ICE with trunk as of r146467 using -flax-vector-conversions otherwise the test doesn't compile. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-13 12:45:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36798
[Bug tree-optimization/33404] Predictive commoning + ivopts possibly introducing extra sign extensions.
--- Comment #5 from ramana at gcc dot gnu dot org 2009-05-13 14:33 --- (In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > > Also IV-opts is messing up anyways, it should have done out+1 as the base > > > instead of out, blah. > > > > Filed as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36905 . > > Can we close this bug, then, or is there some other problem reported in this > testcase? As far as I can tell, predictive commoning does not introduce any > new sign extensions (it does not eliminate any, either, but that is not its > job). > I am closing this because the problem is not in predictive commoning which is doing the right thing and the problem is as per PR36905. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33404
[Bug target/39244] Various cleanup tests fail
--- Comment #2 from ramana at gcc dot gnu dot org 2009-05-13 14:39 --- I don't see these failing with trunk as of 147209 or on an arm-none-linux-gnueabi 4.4.x on the testresults mailing list. Do these still fail for your tester? -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39244
[Bug target/38703] testsuite __gnu_mcount_nc link error when profiling on arm
--- Comment #5 from ramana at gcc dot gnu dot org 2009-05-13 14:51 --- (In reply to comment #1) > That's what dg-require-profiling does. > > IMHO this is a deficiency in your glibc. It's very hard to distinguish between > "something is subtly busted" and "my glibc sucks", so I'm not sure fixing this > is appropriate for fsf gcc. > Given this bit here, can this now be closed as WONTFIX ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38703
[Bug target/39244] Various cleanup tests fail
-- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-13 15:19:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39244
[Bug target/35623] RTL check failure in arm_const_double_rtx
--- Comment #3 from ramana at gcc dot gnu dot org 2009-05-13 16:34 --- Can you try a later compiler ? -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35623
[Bug rtl-optimization/39836] [4.4/4.5 regression] unoptimal code generated
-- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-13 16:47:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39836
[Bug target/38703] testsuite __gnu_mcount_nc link error when profiling on arm
--- Comment #7 from ramana at gcc dot gnu dot org 2009-05-13 23:56 --- Marking as WONTFIX as per comment#1 above. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38703
[Bug target/38643] Doesn't hide (visibility-wise) vtables and VTTs on ARM EABI
--- Comment #4 from ramana at gcc dot gnu dot org 2009-05-15 06:28 --- Doesn't work on 4.3 branch rev. 147478 .Works fine on trunk. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-15 06:28:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38643
[Bug target/40153] Long long comparison optimized away incorrectly in Thumb code.
--- Comment #2 from ramana at gcc dot gnu dot org 2009-05-15 08:26 --- (In reply to comment #1) > This is caused by a typo in arm.md. > > (define_insn "cstoresi_nltu_thumb1" > [(set (match_operand:SI 0 "s_register_operand" "=l,l") > (neg:SI (gtu:SI (match_operand:SI 1 "s_register_operand" "l,*h") > (match_operand:SI 2 "thumb1_cmp_operand" > "lI*h,*r"] > "TARGET_THUMB1" > "cmp\\t%1, %2\;sbc\\t%0, %0, %0" > [(set_attr "length" "4")] > ) > > The instruction cstoresi_nltu_thumb1 is used to compute the expression -(x < > y) > where x and y are unsigned SI-type values. The operand of the NEG RTX should > be a LTU RTX instead of a GTU RTX. The incorrected RTX code caused a later > CSE > pass to substitute this pattern: > > (set x > (neg (gtu a b))) <=== cstoresi_nltu_thumb1 > (set y (neg x)) > > with > > (set y (gtu a b)) > > I tried fixing the RTX code and the test case passed. > This looks correct. Please submit a patch to gcc-patc...@. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-15 08:26:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40153
[Bug target/25249] inconsistent code for template function calls
--- Comment #2 from ramana at gcc dot gnu dot org 2009-05-18 14:10 --- I can't see this with 4.3, 4.4 or trunk today. Can you provide a more recent reference to this problem ? -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25249
[Bug rtl-optimization/36712] Inefficient loop unrolling
--- Comment #1 from ramana at gcc dot gnu dot org 2009-05-20 13:19 --- Can be reproduced with trunk today. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-20 13:19:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36712
[Bug rtl-optimization/36712] Inefficient loop unrolling
--- Comment #3 from ramana at gcc dot gnu dot org 2009-05-20 14:14 --- There was a discussion thread here. http://gcc.gnu.org/ml/gcc/2008-07/msg00037.html and one of the solutions that Bingfeng was investigating was loop unrolling before ivopts in certain cases being useful . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36712
[Bug rtl-optimization/39837] [4.3/4.4/4.5 regression] unoptimal code generated
-- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-20 14:17:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39837
[Bug tree-optimization/39839] [4.3/4.4/4.5 regression] loop invariant motion causes stack spill
-- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-20 14:17:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39839
[Bug rtl-optimization/39871] [4.3/4.4/4.5 regression] Code size increase on ARM due to inferior CSE
-- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-20 14:17:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39871
[Bug libstdc++/40133] exception propagation support not enabled in libstdc++ 4.4 on {armeabi,hppa}-linux
-- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-22 13:36:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40133
[Bug target/40134] symbols not resolved when building shared libraries (link with -lgcc_s -lgcc?)
-- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-22 13:37:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40134
[Bug libffi/40242] unsupported asm instructions in libffi/src/arm/sysv.S
--- Comment #1 from ramana at gcc dot gnu dot org 2009-05-27 09:50 --- (In reply to comment #0) > Hello, > > during cross compilation of gcc, the libffi build for the target breaks with > this error message: > > libtool: compile: /home/frogger/pengutronix/toolchain/libffi/build/./gcc/xgcc > -B/home/frogger/pengutronix/toolchain/libffi/build/./gcc/ > -B/usr/local/arm-1136jfs-linux-gnueabi/bin/ > -B/usr/local/arm-1136jfs-linux-gnueabi/lib/ -isystem > /usr/local/arm-1136jfs-linux-gnueabi/include -isystem > /usr/local/arm-1136jfs-linux-gnueabi/sys-include -I. > -I../../../gcc-4.4.0/libffi/include -Iinclude -I../../../gcc-4.4.0/libffi/src > -g -O2 -c ../../../gcc-4.4.0/libffi/src/arm/sysv.S -fPIC -DPIC -o > src/arm/.libs/sysv.o > ../../../gcc-4.4.0/libffi/src/arm/sysv.S: Assembler messages: > ../../../gcc-4.4.0/libffi/src/arm/sysv.S:202: Error: selected processor does > not support `stfeqs f0,[r2]' > ../../../gcc-4.4.0/libffi/src/arm/sysv.S:207: Error: selected processor does > not support `stfeqd f0,[r2]' > ../../../gcc-4.4.0/libffi/src/arm/sysv.S:282: Error: selected processor does > not support `ldfs f0,[sp]' > ../../../gcc-4.4.0/libffi/src/arm/sysv.S:285: Error: selected processor does > not support `ldfd f0,[sp]' > ../../../gcc-4.4.0/libffi/src/arm/sysv.S:288: Error: selected processor does > not support `ldfd f0,[sp]' > > the offending code is: > > #ifndef __SOFTFP__ > beq LSYM(Lepilogue) > > @ return FLOAT > cmp r3, #FFI_TYPE_FLOAT > stfeqs f0, [r2] > beq LSYM(Lepilogue) > > @ return DOUBLE or LONGDOUBLE > cmp r3, #FFI_TYPE_DOUBLE > stfeqd f0, [r2] > #endif > > > gcc is configured this way: > > ../gcc-4.4.0/configure --enable-languages=c,c++,java > --target=arm-1136jfs-linux-gnueabi > --with-mpfr=/home/frogger/pengutronix/toolchain/OSELAS.Toolchain-trunk/platform-arm-v4t-linux-gnueabi-gcc-4.4.0-glibc-2.9-binutils-2.19.1-kernel-2.6.29-sanitized/sysroot-host > --with-gmp=/home/frogger/pengutronix/toolchain/OSELAS.Toolchain-trunk/platform-arm-v4t-linux-gnueabi-gcc-4.4.0-glibc-2.9-binutils-2.19.1-kernel-2.6.29-sanitized/sysroot-host > --with-float=softfp --with-fpu=vfp --with-cpu=arm1136jf-s > --with-sysroot=/opt/OSELAS.Toolchain-1.99.3/arm-1136jfs-linux-gnueabi/gcc-4.3.2-glibc-2.8-binutils-2.19-kernel-2.6.27-sanitized/sysroot-arm-1136jfs-linux-gnueabi > > I.e. as an arm-eabi target, --with-fpu=vfp and --with-float=softfp. Which > means > floats are passed in integer registers, but in function the compiler generates > floating point instructions, the preprocessor doesn't define a "__SOFTFP__" > symbol. > > If configuring the compiler with "--with-float=soft" it will pass floats in > integer registers and it will generate softfloat emulation code. In this case > the preprocessor defines "__SOFTFP__". > > In both variants the function calling convention is the same, but in one case > we have the __SOFTFP__ symbol in the other not. > > libffi changes it's behaviour depending on this symbol, which is IMHO not > correct. > > I've tested some combinations, this is the summary of > (echo | arm-v4t-linux-gnueabi-cpp -dM -mfloat-abi=XXX -mfpu=YYY| egrep -i > 'vfp|fp|soft|hard|float'): > > -mfloat-abi=soft -mfpu=vfp__SOFTFP__ __VFP_FP__ > -mfloat-abi=softfp -mfpu=vfp __VFP_FP__ > -mfloat-abi=hard -mfpu=vfp __VFP_FP__ (sorry, unimplemented) > > -mfloat-abi=soft -mfpu=fpa__SOFTFP__ > -mfloat-abi=softfp -mfpu=fpa > -mfloat-abi=hard -mfpu=fpa > > I'm not sure which of these combinations makes sense, or are actually used, > the > 3rd one seems not to be implemented, though. We at pengutronix use usually 1. > and 2. In some weird projects 4. and 6. but not with the current gcc. Using mfpu=fpa in eabi configurations is wrong. Trunk is now patched to no longer allow this. > > This table shows that it's not possible to distinguish between the "hard" and > "softfp" case, a diff off the preprocessor's output shows no difference in the > symbols tough. On the upside the vfp-hard case seems not to be implemented. The difference between vfp-hard and softfp is whether we use the VFP registers for passing parameters or not. Currently softfp is the only one implemented in trunk and all release branches though an implementation is under way in an architecture specific branch viz. ARM/hardvfp_4_4_branch. > > So the question is which is the correct symbol for libffi? If there is code in here that tries to return values
[Bug target/35079] [arm] ICE (segfault) with gfortran -O3 -funroll-loops
--- Comment #3 from ramana at gcc dot gnu dot org 2009-05-27 13:01 --- I just tried this with gfortran 4.3.3 that I have on my ubuntu box. I don't get a failure with arm-linux-gnueabi. Can you verify that this still exists with arm-linux configurations ? Thanks. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35079
[Bug target/40277] New: Spill failures for VFP_REGS with scalar-return_5.c in the testsuite.
A number of tests in today's trunk fail with -mcpu=cortex-a8 -mfloat-abi=softfp
-mfpu=neon with spill failures for the following form of instructions.
/home/ramana/cos/combined-git-master-cloned/gcc/testsuite/gcc.c-torture/compile/2804-1.c:20:
error: this is the insn:
(insn 53 29 30 2
/home/ramana/cos/combined-git-master-cloned/gcc/testsuite/gcc.c-torture/compile/2804-1.c:16
(set (subreg:TI (reg:CDI 2 r2 [151]) 0)
(subreg:TI (reg:CDI 2 r2 [154]) 0)) 715 {*neon_movti}
(expr_list:REG_DEAD (reg:CDI 2 r2 [154])
(nil)))
/home/ramana/cos/combined-git-master-cloned/gcc/testsuite/gcc.dg/compat//scalar-return-3_x.c:
In function 'checkcll':
/home/ramana/cos/combined-git-master-cloned/gcc/testsuite/gcc.dg/compat//scalar-return-3_x.c:90:
error: unable to find a register to spill in class 'VFP_REGS'
/home/ramana/cos/combined-git-master-cloned/gcc/testsuite/gcc.dg/compat//scalar-return-3_x.c:90:
error: this is the insn:
(insn 4 3 5 2
/home/ramana/cos/combined-git-master-cloned/gcc/testsuite/gcc.dg/compat//scalar-return-3_x.c:90
(set (mem/s/c:TI (reg/f:SI 12 ip [141]) [0 x+0 S16 A64])
(subreg:TI (reg:CDI 0 r0 [ x ]) 0)) 718 {*neon_movti}
(expr_list:REG_DEAD (reg/f:SI 12 ip [141])
(nil)))
This occurs today on arm-none-eabi cross with r147930 and a related fix might
be http://gcc.gnu.org/ml/gcc-patches/2008-07/msg00703.html for one of the test
failures (2804-1.c) .
I am testing the following patch based on Paul Brook's comments later in that
thread which might fix the problem
(http://gcc.gnu.org/ml/gcc-patches/2008-07/msg01618.html)
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -14746,7 +14746,7 @@ arm_hard_regno_mode_ok (unsigned int regno, enum
machine_mode mode)
they would use too many. */
if (regno <= LAST_ARM_REGNUM)
return !(TARGET_LDRD && GET_MODE_SIZE (mode) > 4 && (regno & 1) != 0)
- && !VALID_NEON_STRUCT_MODE (mode);
+ && (ARM_NUM_REGS (mode) <= 4);
if (regno == FRAME_POINTER_REGNUM
|| regno == ARG_POINTER_REGNUM)
--
Summary: Spill failures for VFP_REGS with scalar-return_5.c in
the testsuite.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ramana at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40277
[Bug target/40277] Spill failures for VFP_REGS with scalar-return_5.c in the testsuite.
-- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-27 23:19:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40277
[Bug middle-end/31241] Post Increment opportunity missed
--- Comment #5 from ramana at gcc dot gnu dot org 2009-05-30 09:18 --- This is improved by http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01622.html. With the patch we get the following code generated. .cpu cortex-a8 .eabi_attribute 27, 3 .fpu neon .eabi_attribute 20, 1 .eabi_attribute 21, 1 .eabi_attribute 23, 3 .eabi_attribute 24, 1 .eabi_attribute 25, 1 .eabi_attribute 26, 1 .eabi_attribute 30, 2 .eabi_attribute 18, 4 .file "31241.c" .text .align 2 .global foo .type foo, %function foo: @ args = 0, pretend = 0, frame = 0 @ frame_needed = 0, uses_anonymous_args = 0 @ link register save eliminated. add r2, r0, #40 .L2: ldr r3, [r0, #0] orr r3, r1, r3 str r3, [r0], #4 cmp r0, r2 bne .L2 bx lr .size foo, .-foo .ident "GCC: (GNU) 4.5.0 20090527 (experimental)" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31241
[Bug debug/40012] [4.5 Regression] Revision 146817 generated bad debug info for local variables
--- Comment #8 from ramana at gcc dot gnu dot org 2009-06-03 13:17 --- Also broken on arm-eabi cross. Using gdb and the exact steps as in Comment #0 shows me problem as 0x100. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40012
[Bug target/19599] function pointer prevents tail-call optimization on arm
--- Comment #3 from ramana at gcc dot gnu dot org 2009-06-04 12:39 --- Patch submitted here. http://gcc.gnu.org/ml/gcc-patches/2009-06/msg00373.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19599
[Bug rtl-optimization/34849] Missed autoincrement opportunities due to a different basic block structure.
--- Comment #12 from ramana at gcc dot gnu dot org 2009-06-05 23:16 ---
(In reply to comment #10)
> Ramana, can you please add the exact command line you are using (so that I can
> see what flags you use and what cpu you target) and the exact output you are
> expecting? I have hacked things such that the store is cross-jumped but I
> still don't get an autoincrement insn. I get this for arm7-r with r147999,
> -Os, and my hack:
Sorry about the late response, I sort of dropped the ball on this one. The
target was essentially default arm which is armv4t and I suspect the command
line was -O2, -O3 and -Os.
Yes the case where you show is where I would have expected an auto-increment .
I presume this is after the new cross jumping work you've done -
>
> .file "t.c"
> .text
> .align 2
> .global foo
> .type foo, %function
> foo:
> @ args = 0, pretend = 0, frame = 0
> @ frame_needed = 0, uses_anonymous_args = 0
> ldr r3, #0
> stmfd sp!, {r4, r5, lr}
> mov ip, r3
> b .L2
> .L4:
> ldr r4, [r1, r3]
> movwr5, #39030
> cmp r4, #0
> movwr4, #4660
> moveq r4, r5
> str r4, [r2, r3]
> add r3, r3, #4 @ I suppose you expect an autoinc
> here?
> .L2:
> cmp ip, r0
> add ip, ip, #1
> blt .L5
> ldmfd sp!, {r4, r5, pc}
> .size foo, .-foo
> .ident "GCC: (GNU) 4.5.0 20090530 (experimental) [trunk revision
> 147999]"
>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34849
[Bug target/40375] redundant register move with -mthumb
--- Comment #7 from ramana at gcc dot gnu dot org 2009-06-09 14:32 --- (In reply to comment #6) > (In reply to comment #5) > > Hmm, I was under the impression that postreload-cse could move instructions > > too, but that was just wishful thinking. > > > I will look into postreload-cse. > I've looked at this superficially and something that I noticed was that in the ARM case (i.e !-mthumb) there aren't any redundant moves - It works fine in the Register allocator but the only difference that I can see / think of is that we support sibling calls for ARM mode. We don't have sibling calls supported for Thumb. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40375
[Bug driver/40251] Using the -V option makes the compiler to exit with 0 exit code on error
-- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-06-11 14:06:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40251
[Bug target/40419] New: __attribute__((mips16)) is broken on trunk.
While implementing something like mips16 as a __attribute__((thumb)) for the
ARM port I discovered that the following testcase stripped down from a testcase
in the gcc testsuite causes a segmentation fault in the compiler for the MIPS
port as well.
static double __attribute__((mips16)) time_giop_encode (unsigned long);
int
main(int ac, char *av[])
{
time_giop_encode (0);
}
static
double __attribute__ ((mips16))
time_giop_encode (unsigned long l)
{
giop_encode_ulong (l);
}
A run through a valgrind showed that there was a write to an invalid address -
==7998== Invalid write of size 4
==7998==at 0x8234A0E: gen_reg_rtx (emit-rtl.c:912)
==7998==by 0x830CD7B: expand_function_start (function.c:4416)
==7998==by 0x88BBF81: gimple_expand_cfg (cfgexpand.c:2512)
==7998==by 0x83D220C: execute_one_pass (passes.c:1289)
==7998==by 0x83D248B: execute_pass_list (passes.c:1338)
==7998==by 0x854C81F: tree_rest_of_compilation (tree-optimize.c:394)
==7998==by 0x86C524B: cgraph_expand_function (cgraphunit.c:1097)
==7998==by 0x86C7A4C: cgraph_optimize (cgraphunit.c:1156)
==7998==by 0x80BE9BA: c_write_global_declarations (c-decl.c:8593)
==7998==by 0x84F4255: toplev_main (toplev.c:1044)
==7998==by 0x8144A21: main (main.c:35)
==7998== Address 0x46811f0 is not stack'd, malloc'd or (recently) free'd
==7998==
==7998== Invalid write of size 4
==7998==at 0x8234A0E: gen_reg_rtx (emit-rtl.c:912)
==7998==by 0x8304E0B: assign_parm_setup_reg (function.c:2780)
==7998==by 0x830AB61: assign_parms (function.c:3172)
==7998==by 0x830C938: expand_function_start (function.c:4432)
==7998==by 0x88BBF81: gimple_expand_cfg (cfgexpand.c:2512)
==7998==by 0x83D220C: execute_one_pass (passes.c:1289)
==7998==by 0x83D248B: execute_pass_list (passes.c:1338)
==7998==by 0x854C81F: tree_rest_of_compilation (tree-optimize.c:394)
==7998==by 0x86C524B: cgraph_expand_function (cgraphunit.c:1097)
==7998==by 0x86C7A4C: cgraph_optimize (cgraphunit.c:1156)
==7998==by 0x80BE9BA: c_write_global_declarations (c-decl.c:8593)
==7998==by 0x84F4255: toplev_main (toplev.c:1044)
==7998== Address 0x46811f4 is not stack'd, malloc'd or (recently) free'd
==7998==
==7998== Invalid write of size 1
==7998==at 0x82351A2: mark_reg_pointer (emit-rtl.c:1120)
==7998==by 0x830522D: assign_parm_setup_reg (function.c:2945)
==7998==by 0x830AB61: assign_parms (function.c:3172)
==7998==by 0x830C938: expand_function_start (function.c:4432)
==7998==by 0x88BBF81: gimple_expand_cfg (cfgexpand.c:2512)
==7998==by 0x83D220C: execute_one_pass (passes.c:1289)
==7998==by 0x83D248B: execute_pass_list (passes.c:1338)
==7998==by 0x854C81F: tree_rest_of_compilation (tree-optimize.c:394)
==7998==by 0x86C524B: cgraph_expand_function (cgraphunit.c:1097)
==7998==by 0x86C7A4C: cgraph_optimize (cgraphunit.c:1156)
==7998==by 0x80BE9BA: c_write_global_declarations (c-decl.c:8593)
==7998==by 0x84F4255: toplev_main (toplev.c:1044)
==7998== Address 0x479423a is 1 bytes after a block of size 1 alloc'd
==7998==at 0x4026FDE: malloc (vg_replace_malloc.c:207)
==7998==by 0x89D8DC7: xrealloc (xmalloc.c:177)
==7998==by 0x8234A5E: gen_reg_rtx (emit-rtl.c:900)
==7998==by 0x830CD7B: expand_function_start (function.c:4416)
==7998==by 0x88BBF81: gimple_expand_cfg (cfgexpand.c:2512)
==7998==by 0x83D220C: execute_one_pass (passes.c:1289)
==7998==by 0x83D248B: execute_pass_list (passes.c:1338)
==7998==by 0x854C81F: tree_rest_of_compilation (tree-optimize.c:394)
==7998==by 0x86C524B: cgraph_expand_function (cgraphunit.c:1097)
==7998==by 0x86C7A4C: cgraph_optimize (cgraphunit.c:1156)
The segfault is because reg_rtx_no is 0 and rtx_reg_no are uninitialized. It
looks like the infrastructure of target_reinit is broken because these are not
reinitialized correctly after inlining does its bit with setting and resetting
this . init_function_start from tree_rest_of_compilation initializes these but
the inlining bits call set_cfun and do a target_reinit which sets all these
values to zero. expand_function_start gets called later and by this time since
regno_reg_rtx is set to 0 you have gen_reg_rtx returning a hard register.
--
Summary: __attribute__((mips16)) is broken on trunk.
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ramana at gcc dot gnu dot org
GCC build triplet: i686-linux-gnu
GCC host triplet: i686-linux-gnu
GCC target triplet: mips-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40419
[Bug target/40419] __attribute__((mips16)) is broken on trunk.
--- Comment #1 from ramana at gcc dot gnu dot org 2009-06-11 21:29 --- Adding Richard and Sandra to the CC list. -- ramana at gcc dot gnu dot org changed: What|Removed |Added CC||sandra at gcc dot gnu dot ||org, rsandifo at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40419
[Bug target/40424] --verbose-asm option not list all enbaled command line option flags
--- Comment #1 from ramana at gcc dot gnu dot org 2009-06-12 10:00 --- That might be because you have differences in your override_options from the "native" compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40424
[Bug target/40416] unnecessary register spill
--- Comment #2 from ramana at gcc dot gnu dot org 2009-06-12 12:54 ---
(In reply to comment #1)
> Created an attachment (id=17983)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17983&action=view) [edit]
> test case
>
Your attachment didn't have #include - Please try and supply
pre-processed input which is self contained . Adding a -I from a build
directory can be rather painful . Thanks -
> The spilling is occurred around the first loop:
>
> push{r4, r5, r6, r7, lr}
> sub sp, sp, #12
> .loc 1 5 0
> str r2, [sp, #4] // A
> .loc 1 6 0
> add r6, r1, r2
> mov r4, r0
> .loc 1 8 0
> b .L2
> .L5:
> .loc 1 10 0
> mov r7, #0
> ldrsh r5, [r4, r7]
> .loc 1 12 0
> cmp r2, r5
> bge .L3
> .loc 1 14 0
> ldrbr7, [r1]
> strbr7, [r1, r2]
> .loc 1 15 0
> strhr2, [r4]
> .loc 1 16 0
> lsl r1, r2, #1
> sub r2, r5, r2
> strhr2, [r1, r4]
> .L6:
> .loc 1 5 0
> ldr r5, [sp, #4] // B
> lsl r4, r5, #1
> add r0, r0, r4
> b .L4
> .L3:
> .loc 1 19 0
> lsl r7, r5, #1
> mov ip, r7
> add r4, r4, ip
> .loc 1 20 0
> add r1, r1, r5
> .loc 1 21 0
> sub r2, r2, r5
> .L2:
> .loc 1 8 0
> cmp r2, #0
> bgt .L5
> b .L6
> .L4:
> .loc 1 30 0
> mov r1, #0
>
>
> The spilling is occurred at instruction A and reload at instruction B.
>
> The spilled value is x. The source code computes next_runs and next_alpha
> before while loop and preserve them through the loop body. But the generated
> code preserve next_alpha, original runs and original x through the loop body
> and compute next_runs after the loop. This caused an extra usage of register
> and results in a register spilling.
>
Could you say what you'd like the code to be because I don't see an option but
to spill one of the values here. ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40416
[Bug libffi/40242] unsupported asm instructions in libffi/src/arm/sysv.S
--- Comment #4 from ramana at gcc dot gnu dot org 2009-06-12 13:13 --- There was a merge of some work from libffi recently and IIRC I saw some commits go into the same file. Can you check if that fixes your problem ? Ramana > > This means we cannot use "-mfloat-abi=soft" unconditionally, which boils down > (again) to the question: how can we distinguish between the > float-passed-in-int-regs and float-passed-in-float-regs case. Ideally this > should work if building libffi as part of gcc and if building libffi > standalone. > > cheers, Marc > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40242
[Bug target/40416] unnecessary register spill
-- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-06-15 09:14:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40416
[Bug target/9831] [ARM] Peephole for multiple load/store could be more effective.
--- Comment #7 from ramana at gcc dot gnu dot org 2009-06-16 10:01 ---
(In reply to comment #5)
> See the attached pqp.c file.
>
> With gcc 4.3.3, on such simplistic examples, peephole ldm and stm works:
>
> sum:
> ldr r2, .L3
> ldmia r2, {r1, r3}@ phole ldm
> add r3, r0, r3
> add r0, r0, r1
> stmia r2, {r0, r3}@ phole stm
> bx lr
>
>
> With gcc 4.4.0 branch, built on 20090413, it fails:
>
> sum:
> @ args = 0, pretend = 0, frame = 0
> @ frame_needed = 0, uses_anonymous_args = 0
> @ link register save eliminated.
> ldr r3, .L3
> ldr r2, [r3, #0]
> ldr r1, [r3, #4]
> add r2, r0, r2
> add r1, r0, r1
> str r1, [r3, #4]
> str r2, [r3, #0]
> bx lr
>
We can't use stm or ldm on the second case because ldm's and stm's depend on
the lowest numbered register going to the lowest memory address. It's a relic
of the register allocator choosing a different order for the registers for such
cases.
ldm's and stm's are not easily describable in the RTL backend and are
semi-bolted on on top of the existing infrastructure using peepholes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9831
[Bug target/40457] use stm and ldm to access consecutive memory words
--- Comment #2 from ramana at gcc dot gnu dot org 2009-06-16 10:03 --- Could you check to see why store_multiple_sequence doesn't find this in the peephole in the ARM backend ? GCC does generate stm and ldm's in a number of other places using the old peephole and store_multiple_sequence option. It might be worth digging into this further. -- ramana at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ramana at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-06-16 10:03:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40457
[Bug target/40463] linux-eabi.h:79:36: error: identifier "not" is a special operator name in C++
--- Comment #1 from ramana at gcc dot gnu dot org 2009-06-17 08:29 --- Could you specify which version of the source tree this was ? -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40463
[Bug target/40457] use stm and ldm to access consecutive memory words
--- Comment #8 from ramana at gcc dot gnu dot org 2009-06-17 09:49 --- (In reply to comment #7) > My command line option is -O2 -Os -mthumb > > The compiler didn't run into load_multiple_sequence and > store_multiple_sequence. The peephole rules specified it applies to TARGET_ARM > only. Is there any special reason we didn't enable it in thumb mode? ldms and stms in thumb mode overwrite the base register that is used for addresses and that's why this is not enabled for thumb mode. One could write a peephole2 pattern that checked for liveness of the base register - if the base register were dead after the instruction, then there could be an ldm or stm peepholed. > > For the ascending register number, do we have any code to rename a set of > registers to make them ascending? In the generated code for the second > function, the register numbers have different order compared with memory > offsets. > > ldr r2, [r0, #4] > ldr r3, [r0] > Not that I am aware of , it's as good as renaming but to allow combinations to happen . It might be useful with PR9831 as well but is a separate problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40457
[Bug target/40482] shift a small constant to get larger one
--- Comment #2 from ramana at gcc dot gnu dot org 2009-06-18 09:18 --- I can confirm this for Thumb1 which is what I presume you are interested in. Also, please note that -O2 -Os is the same as -Os. We have a splitter that should ideally take care of this case. Digging. -- ramana at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ramana at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-06-18 09:18:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40482
[Bug target/40482] shift a small constant to get larger one
--- Comment #3 from ramana at gcc dot gnu dot org 2009-06-18 09:50 --- Testing a patch now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40482
[Bug target/40487] New: Extra zero extensions produced for ARM.
A colleague at ARM found this a couple of days back.
With trunk as of a few days back configured for arm-none-eabi for cortex-a8
typedef unsigned short ushort;
typedef unsigned char uchar;
ushort foo(uchar data, uchar data1, uchar data2)
{
uchar x = (uchar)(data);
x ^= (x + 5);
x ^= (x << 2);
x ^= (x << 1);
return x;
}
foo:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
add r3, r0, #5
eor r0, r3, r0
uxtbr0, r0 //redundant
eor r0, r0, r0, lsl #2
uxtbr0, r0 // redundant
eor r0, r0, r0, lsl #1
uxtbr0, r0
bx lr
--
Summary: Extra zero extensions produced for ARM.
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ramana at gcc dot gnu dot org
GCC build triplet: x86_64-linux
GCC host triplet: x86_64-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40487
[Bug target/40487] Extra zero extensions produced for ARM.
--- Comment #1 from ramana at gcc dot gnu dot org 2009-06-18 12:58 --- I'm not sure about the best way of fixing this without looking at bigger trees at expand time or for combine to be able to do something smart about this one. Essentially you fold the previous zero extension with the current operation because the current operation doesn't care about the higher order bits and there is a zero extension afterwards that puts it into the right shape. x = zextb (y) z = x ^ (x << #n) w = zextb (z) into x = y ^ (y << #n) w = zextb (x) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40487
[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852
--- Comment #4 from ramana at gcc dot gnu dot org 2009-06-19 00:00 --- Confirmed that the problem exists. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-06-19 00:00:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
[Bug target/40457] use stm and ldm to access consecutive memory words
-- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |ASSIGNED Last reconfirmed|2009-06-16 10:03:48 |2009-06-19 10:18:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40457
[Bug target/40482] shift a small constant to get larger one
--- Comment #4 from ramana at gcc dot gnu dot org 2009-06-19 21:22 --- Subject: Bug 40482 Author: ramana Date: Fri Jun 19 21:22:44 2009 New Revision: 148728 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148728 Log: Fix PR 40482 2009-06-19 Ramana Radhakrishnan PR target/40482 * config/arm/arm.c (thumb_shiftable_const): Truncate val to 32 bits. * config/arm/arm.md: Likewise. 2009-06-19 Ramana Radhakrishnan PR target/40482 * gcc.target/arm/pr40482.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/pr40482.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/config/arm/arm.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40482
[Bug target/40482] shift a small constant to get larger one
--- Comment #5 from ramana at gcc dot gnu dot org 2009-06-19 22:20 --- Hence fixed. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40482
[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852
--- Comment #5 from ramana at gcc dot gnu dot org 2009-06-19 23:14 --- The difference essentially is because all functions getting inlined into BZ2_Compress_Block with the newer heuristics. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
[Bug libffi/40242] unsupported asm instructions in libffi/src/arm/sysv.S
-- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40242
[Bug target/40424] --verbose-asm option not list all enbaled command line option flags
--- Comment #7 from ramana at gcc dot gnu dot org 2009-06-22 10:30 --- I'm not allowed to authorize or approve the change. You'd be better off requesting for a review and someone to commit this for you on gcc-patches @ rather than in comments in bugzilla. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40424
[Bug target/40463] linux-eabi.h:79:36: error: identifier "not" is a special operator name in C++
--- Comment #4 from ramana at gcc dot gnu dot org 2009-06-22 12:43 --- Subject: Bug 40463 Author: ramana Date: Mon Jun 22 12:43:23 2009 New Revision: 148791 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148791 Log: Fix target/40463 2009-06-22 Ramana Radhakrishnan PR target/40463 * config/arm/linux-eabi.h (CLEAR_INSN_CACHE): Fix definition. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/linux-eabi.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40463
[Bug target/40463] linux-eabi.h:79:36: error: identifier "not" is a special operator name in C++
--- Comment #5 from ramana at gcc dot gnu dot org 2009-06-22 13:05 --- hence fixed. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40463
[Bug target/40487] Extra zero extensions produced for ARM.
--- Comment #8 from ramana at gcc dot gnu dot org 2009-06-22 22:57 --- (In reply to comment #5) > Compiling with gcc 4.4.1 with options "-Os -mtune=cortex-a8" I get this: Try with -mcpu=cortex-a8 . -mtune=cortex-a8 doesn't choose the cpu for that , insn selection for the arm port happens with mcpu and tuning and costs are controlled by mtune. And no it isn't a whole load better :) I had configured the toolchain with --with-cpu=cortex-a8. Thanks, Ramana -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40487
[Bug target/35296] init_expr_once suboptimal for Thumb
-- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35296
[Bug libgcj/35552] GCJ ARM compiled programs give segmentation fault
--- Comment #1 from ramana at gcc dot gnu dot org 2009-06-22 23:25 --- What happens with a more recent version of the toolchain ? 4.2.x is now obsolete. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35552
[Bug target/40525] missed optimization in conditional expression
--- Comment #1 from ramana at gcc dot gnu dot org 2009-06-23 09:05 --- Can you specify options , example, target under consideration and version of the source tree considered ? -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40525
[Bug target/40487] Extra zero extensions produced for ARM.
--- Comment #9 from ramana at gcc dot gnu dot org 2009-06-23 09:16 --- (In reply to comment #4) > (In reply to comment #3) > > Is this related to bug 39715? > > > > Maybe. > 39715 appears to be strictly a 4.5 missed optimization, but from comment #5 it appears as though this is different and I can verify that the same problem exists for 4.3 and trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40487
[Bug target/40487] Extra zero extensions produced for ARM.
-- ramana at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ramana at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-06-22 16:47:08 |2009-06-23 12:38:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40487
[Bug c/40586] CROSS COMPILE Badness
--- Comment #2 from ramana at gcc dot gnu dot org 2009-06-29 16:14 --- Try with a newer version of the compiler. The cross compiler shouldn't be inserting a -I/usr/include/xorg . It must be a function of your environment. Also we no longer support 4.1.2. Try using a more recent version of the compiler. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40586
[Bug target/37987] iwmmxt: insn does not satisfy its constraints on (int64_t)
--- Comment #4 from ramana at gcc dot gnu dot org 2009-07-01 08:39 ---
(In reply to comment #3)
> (In reply to comment #2)
> > Can you check this with a later compiler. 4.2.x is closed. Works for me with
> > current trunk.
> >
> Just encountered similar problem while cross compiling gcc 4.4.0 with glibc
> 2.9.
> (Using crosstool-NG).>
> The error messages:
>
> [ALL ]arm-iwmmxt-linux-gnueabi-gcc
> ../sysdeps/unix/sysv/linux/libc_fatal.c -c -std=gnu99 -fgnu89-inline -O -Wall
> -Winline -Wwrite-strings -finline-limit=1 -fmerge-all-constants
> -mabi=aapcs-linux -march=iwmmxt -mlittle-endian -msoft-float
> -Wstrict-prototypes -I../include
> -I/home/jsji/arm-iwmmxt-linux-4.4-ctng/targets/arm-iwmmxt-linux-gnueabi/build/build-libc/libio
> -I/home/jsji/arm-iwmmxt-linux-4.4-ctng/targets/arm-iwmmxt-linux-gnueabi/build/build-libc
> -I../ports/sysdeps/arm/elf -I../ports/sysdeps/unix/sysv/linux/arm/eabi/nptl
> -I../ports/sysdeps/unix/sysv/linux/arm/eabi
> -I../ports/sysdeps/unix/sysv/linux/arm/nptl
> -I../ports/sysdeps/unix/sysv/linux/arm -I../nptl/sysdeps/unix/sysv/linux
> -I../nptl/sysdeps/pthread -I../sysdeps/pthread
> -I../ports/sysdeps/unix/sysv/linux -I../sysdeps/unix/sysv/linux
> -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman
> -I../sysdeps/unix/inet -I../nptl/sysdeps/unix/sysv
> -I../ports/sysdeps/unix/sysv
> -I../sysdeps/unix/sysv -I../ports/sysdeps/unix/arm -I../nptl/sysdeps/unix
> -I../ports/sysdeps/unix -I../sysdeps/unix -I../sysdeps/posix
> -I../ports/sysdeps/arm/eabi -I../ports/sysdeps/arm/nptl -I../ports/sysdeps/arm
> -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/flt-32
> -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754 -I../sysdeps/generic/elf
> -I../sysdeps/generic -I../nptl -I../ports -I.. -I../libio -I. -nostdinc
> -isystem
> /home/jsji/arm-iwmmxt-linux-4.4-ctng/targets/arm-iwmmxt-linux-gnueabi/build/gcc-core-shared/lib/gcc/arm-iwmmxt-linux-gnueabi/4.4.0/include
> -isystem
> /home/jsji/arm-iwmmxt-linux-4.4-ctng/targets/arm-iwmmxt-linux-gnueabi/build/gcc-core-shared/lib/gcc/arm-iwmmxt-linux-gnueabi/4.4.0/include-fixed
> -isystem
> /home/jsji/x-tools/arm-iwmmxt-linux-gnueabi/arm-iwmmxt-linux-gnueabi//sys-root/usr/include
> -D_LIBC_REENTRANT -include ../include/libc-symbols.h-D_IO_MTSAFE_IO -o
> /home/jsji/arm-iwmmxt-linux-4.4-ctng/targets/arm-iwmmxt-linux-gnueabi/build/build-libc/libio/libc_fatal.o
> -MD -MP -MF
> /home/jsji/arm-iwmmxt-linux-4.4-ctng/targets/arm-iwmmxt-linux-gnueabi/build/build-libc/libio/libc_fatal.o.dt
> -MT
> /home/jsji/arm-iwmmxt-linux-4.4-ctng/targets/arm-iwmmxt-linux-gnueabi/build/build-libc/libio/libc_fatal.o
>
> [ALL ]../sysdeps/unix/sysv/linux/libc_fatal.c: In function
> '__libc_message':
> [ERROR]../sysdeps/unix/sysv/linux/libc_fatal.c:172: error: insn does not
> satisfy its constraints:
> [ALL ](insn 459 154 155 19 ../sysdeps/unix/sysv/linux/libc_fatal.c:106
> (set (reg:SI 43 wcgr0)
> [ALL ](mem/c:SI (plus:SI (reg/f:SI 11 fp)
> [ALL ](const_int -1324 [0xfad4])) [0
> %sfp+-1292 S4 A32])) 441 {*iwmmxt_movsi_insn} (nil))
> [ERROR]../sysdeps/unix/sysv/linux/libc_fatal.c:172: internal compiler
> error: in reload_cse_simplify_operands, at postreload.c:396
> [ALL ]Please submit a full bug report,
> [ALL ]with preprocessed source if appropriate.
> [ALL ]See <http://gcc.gnu.org/bugs.html> for instructions.
> [ERROR]make[3]: ***
> [/home/jsji/arm-iwmmxt-linux-4.4-ctng/targets/arm-iwmmxt-linux-gnueabi/build/build-libc/libio/libc_fatal.o]
> Error 1
> [ALL ]make[3]: Leaving directory
> `/home/jsji/arm-iwmmxt-linux-4.4-ctng/targets/src/glibc-cvs-2.9/libio'
> [ERROR]make[2]: *** [libio/subdir_lib] Error 2
> [ALL ]make[2]: Leaving directory
> `/home/jsji/arm-iwmmxt-linux-4.4-ctng/targets/src/glibc-cvs-2.9'
> [ERROR]make[1]: *** [all] Error 2
> [ALL ]make[1]: Leaving directory
> `/home/jsji/arm-iwmmxt-linux-4.4-ctng/targets/arm-iwmmxt-linux-gnueabi/build/build-libc'
>
Can you give a pre-processed file for further investigations ? Your report is
incomplete without it and hence I'll have to retain the waiting status on this
one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37987
[Bug target/40615] unnecessary CSE
--- Comment #2 from ramana at gcc dot gnu dot org 2009-07-02 08:53 --- This looks like one of those rematerialization problems albeit with the stack pointer this time. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-07-02 08:53:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40615
[Bug target/40615] unnecessary CSE
--- Comment #4 from ramana at gcc dot gnu dot org 2009-07-02 09:39 ---
(In reply to comment #3)
> Is there a C test case? Can you add objdump of the gcc-generated asm and the
> fixed asm to show the impact on code size? (/me is surprised that 3*"add
> r0,sp,4" is smaller than 1**"add r0,sp,4"+3*"mov r0,r4"... Thumb is amazing
> :-)
The length of add r0,sp,4 and mov r0,r4 is the same for Thumb1 (16 bits).
I suppose the ideal code generated would be something like this modulo errors
with stack alignments in the prologue and the epilogue.
We also don't need r4 in that case :) . So we can save a load, a store as well
as 1 instruction over all. Smaller and faster by 1 instruction and reduced
register usage.
push{lr}
sub sp, sp, #12 (8 byte stack alignment )
add r0, sp, 4// add r0, sp, 4
bl _ZN1XC1Ev
add r0, sp, #4// add r0, sp, 4
bl _Z3barP1X
add r0, sp, #4 // add r0, sp, 4
bl _ZN1XD1Ev
add sp, sp, #12(8 byte stack alignment )
@ sp needed for prologue
pop {pc}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40615
[Bug target/40657] allocate local variables with fewer instructions
--- Comment #3 from ramana at gcc dot gnu dot org 2009-07-06 09:54 --- (In reply to comment #2) > IIRC push-multiple and pop-multiple are not supported yet. Richard E.? > I am not sure what you mean here. push and pop multiple are supported to the best of the cases that GCC can detect them. since load and store multiple are not first class citizens, the ARM backend attempts to detect them in the form of peephole2's and peephole's. However this case isn't to do with push or pop multiple but to do with saving space in the thumb prologue and epilogue by emitting push and pop multiple instructions instead of explicit instructions to manipulate the stack. Notice that r2 and r3 are not used in the code that Carrot is proposing in comment #1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40657
[Bug target/40672] constant address loads moved into loop unnecessarily
--- Comment #2 from ramana at gcc dot gnu dot org 2009-07-07 16:07 --- confirmed with trunk revision 149279. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-07-07 16:07:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40672
[Bug rtl-optimization/40679] Optimizer handles loops with volatiles and post-incr. wrong
--- Comment #3 from ramana at gcc dot gnu dot org 2009-07-08 08:49 --- On trunk with -fno-tree-vrp I see the correct code being generated. bs: @ Function supports interworking. @ args = 0, pretend = 0, frame = 0 @ frame_needed = 0, uses_anonymous_args = 0 @ link register save eliminated. mvn r3, #255 mov r2, #10 .L2: str r2, [r3], #4 cmp r3, #0 bne .L2 bx lr -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40679
[Bug tree-optimization/40679] Optimizer handles loops with volatiles and post-incr. wrong
--- Comment #5 from ramana at gcc dot gnu dot org 2009-07-08 09:12 --- Richi, Can you comment on this one ? Ramana -- ramana at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Component|rtl-optimization|tree-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40679
[Bug target/40680] extra register move
--- Comment #2 from ramana at gcc dot gnu dot org 2009-07-08 10:00 ---
However Confirmed with trunk for Thumb1. The extra move doesn't appear for ARM
or Thumb2 .
The code below is what is generated for Thumb2 or ARM .
.type _ZN3CCC5funcAEv, %function
_ZN3CCC5funcAEv:
.fnstart
.LFB2:
.cfi_startproc
.cfi_personality 0x0,__gxx_personality_v0
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
push{r3, r4, r5, lr}@
.save {r3, r4, r5, lr}
.cfi_def_cfa_offset 16
mov r5, r0 @ this, this
.cfi_offset 14, -4
.cfi_offset 5, -8
.cfi_offset 4, -12
.cfi_offset 3, -16
ldr r0, [r0, #0]@ float @, .fRadius
bl _Z3foof @
ldr r1, [r5, #4]@, .flag
mov r4, r0 @ radius,
bl _Z3barfi@
mov r0, r4 @, data$fSignBitInt
bl _Z3fffi @
mov r5, r0 @ D.1797,
mov r0, r4 @, data$fSignBitInt
bl _Z3fffi @
mov r1, r0 @ D.1803,
mov r0, r5 @, D.1797
bl _Z3setii@
pop {r3, r4, r5, pc}
.cfi_endproc
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-07-08 10:00:06
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40680
[Bug bootstrap/40651] bootstrap error on arm-linux-gnueabi: segfault in next_const_call_expr_arg
--- Comment #1 from ramana at gcc dot gnu dot org 2009-07-08 10:01 --- Can you attach a pre-processed file for someone to look at this ? This bug report seems incomplete. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40651
[Bug target/40603] unnecessary conversion from unsigned byte load to signed byte load
-- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-07-08 10:49:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40603
[Bug target/40697] inefficient code to extract least bits from an integer value
--- Comment #3 from ramana at gcc dot gnu dot org 2009-07-09 10:32 --- (In reply to comment #2) > Maybe we can fix this in expand instead: if we see (x & CONST) and CONST is a > masking constant that isn't a legitimate constant for the the target, then see > if the sum of the rtx_cost of expressing the mask as shifts is less than the > rtx_cost of a load and an AND. > > I think (but I'm not sure...) that if you do this with a peephole, you're too > late to avoid the constant pool. A peephole2 will do the trick . Constant pools in the ARM port are generated and placed as a part of the reorg pass. > > Is this also a size issue? Indeed - instead of 6 bytes (2 bytes for the ldr and 4 bytes for the .word which ends up in the .text section anyway.) instructions and you save a memory access. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40697
[Bug target/38642] [4.3/4.4/4.5 Regression] Code with -fPIC results in segfault on ARM (old ABI)
--- Comment #4 from ramana at gcc dot gnu dot org 2009-07-10 09:45 --- Does this still occur on trunk ? -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38642
[Bug target/39429] compiler create bad asm codes.
--- Comment #5 from ramana at gcc dot gnu dot org 2009-07-12 20:51 --- (In reply to comment #4) > Created an attachment (id=18179) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18179&action=view) [edit] > reduced test case in plain C > What options did you use ? Did you use -O2 , -O3 or -Os with the testcase you've added here ? I don't see the problem with 4.5.0 trunk 149479 with either -mcpu=arm740t or with arm7tdmi. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39429
[Bug target/40670] Load floating point constant 0 directly
--- Comment #3 from ramana at gcc dot gnu dot org 2009-07-13 15:15 --- (In reply to comment #2) > I'll go farther than that and say that all single-precision fp numbers > destined for integer registers should be passed through the normal > constant splitting routines. > > For instance, all positive powers of two satisfy the (0xff << lowbit) test. > Note that we already pass the constants through a splitter for ARM mode. It's essentially redoing this for thumb and splitting the constants appropriately. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40670
[Bug rtl-optimization/39836] [4.4/4.5 regression] unoptimal code generated
--- Comment #7 from ramana at gcc dot gnu dot org 2009-07-13 16:05 --- Since there are no objections to comment #6 - I am closing this to WONTFIX -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39836
[Bug rtl-optimization/34849] Missed autoincrement opportunities due to a different basic block structure.
-- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Last reconfirmed|2009-04-30 13:18:25 |2009-07-14 10:47:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34849
[Bug target/40783] inefficient code to accumulate function return values
--- Comment #2 from ramana at gcc dot gnu dot org 2009-07-27 15:05 ---
This seems to be related to the other reassoc + register pressure bugs reported
in the database. I am not sure if this is a dup of either PR28481 or PR27855
but they appear to be related.
With -fno-tree-reassoc I get the same code for both loops.
time_math:
push{r4, r5, r6, lr}
bl dumm
mov r4, #0
mov r6, #99
add r5, r0, #0
.L2:
add r0, r5, #0
bl __aeabi_f2iz
add r5, r5, #1
add r4, r4, r0
add r0, r5, #0
bl __aeabi_f2iz
add r5, r5, #1
add r4, r4, r0
add r0, r5, #0
bl __aeabi_f2iz
add r5, r5, #1
add r4, r4, r0
add r0, r5, #0
bl __aeabi_f2iz
add r5, r5, #1
add r4, r4, r0
sub r6, r6, #1
bcs .L2
bl dumm
mov r6, #99
add r5, r0, #0
.L3:
add r0, r5, #0
bl MyConvert
add r5, r5, #1
add r4, r4, r0
add r0, r5, #0
bl MyConvert
add r5, r5, #1
add r4, r4, r0
add r0, r5, #0
bl MyConvert
add r5, r5, #1
add r4, r4, r0
add r0, r5, #0
bl MyConvert
add r5, r5, #1
add r4, r4, r0
sub r6, r6, #1
bcs .L3
mov r0, r4
@ sp needed for prologue
pop {r4, r5, r6, pc}
.size time_math, .-time_math
.ident "GCC: (GNU) 4.5.0 20090727 (experimental)"
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
CC||dberlin at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-07-27 15:05:21
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40783
[Bug middle-end/40887] GCC generates suboptimal code for indirect function calls on ARM
--- Comment #2 from ramana at gcc dot gnu dot org 2009-07-28 08:29 ---
(In reply to comment #0)
> Consider the following code:
>
> int (*indirect_func)();
>
> int indirect_call()
> {
> return indirect_func();
> }
>
> gcc 4.4.0 generates the following with -O2 -mcpu=cortex-a8 -S:
>
> indirect_call:
> @ args = 0, pretend = 0, frame = 0
> @ frame_needed = 0, uses_anonymous_args = 0
> movwr3, #:lower16:indirect_func
> stmfd sp!, {r4, lr}
> movtr3, #:upper16:indirect_func
> mov lr, pc
> ldr pc, [r3, #0]
> ldmfd sp!, {r4, pc}
>
> The problem is that the instruction "ldr pc, [r3, #0]" is not considered a
> function call by the Cortex-A8's branch predictor, as noted in DDI0344J
> section
> 5.2.1, Return stack predictions. Thus, the return from the called function is
> mispredicted resulting in a penalty of 13 cycles compared to a direct call
>
> Rather than doing
> mov lr, pc
> ldr pc, [r3]
> it should instead use the blx instruction as so:
> ldr lr, [r3]
> blx lr
> which is considered a function call by the branch predictor, and has an
> overhead of only one cycle compared to a direct call.
The point made is correct but there is something you've missed in your patch !
loading lr with the address of the function you want to call, destroys the
return address ,- so your code is never going to return !
Instead you want -
ldr r3,[r3]
blx r3
Or better still bx r3 but that is PR19599 :)
>
> gcc -v:
> Using built-in specs.
> Target: arm-none-linux-gnueabi
> Configured with: ../gcc-4.4.0/configure --target=arm-none-linux-gnueabi
> --prefix=/usr/local/arm --enable-threads
> --with-sysroot=/usr/local/arm/arm-none-linux-gnueabi/libc
> Thread model: posix
> gcc version 4.4.0 (GCC)
>
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-07-28 08:29:41
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40887
[Bug middle-end/40887] GCC generates suboptimal code for indirect function calls on ARM
--- Comment #4 from ramana at gcc dot gnu dot org 2009-07-28 12:09 --- (In reply to comment #3) > (In reply to comment #2) > > The point made is correct but there is something you've missed in your > > patch ! > > loading lr with the address of the function you want to call, destroys the > > return address ,- so your code is never going to return ! > > > > Instead you want - > > > > ldr r3,[r3] > > blx r3 > > > > Or better still bx r3 but that is PR19599 :) > > blx sets the link register to the correct return address as a part of the > instruction, and the return address of the calling function has to already > have > been saved before this point or the mov lr, pc would destroy it already. Oops yes, you are right - I must have been asleep ! . I would rather split the load out as a separate insn and allow it to be scheduled separately. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40887
[Bug target/40900] redundant sign extend of short function returned value
--- Comment #2 from ramana at gcc dot gnu dot org 2009-07-29 09:33 --- You don't see it on ARM for this case because of tail-calling. But for Thumb or without sibcall optimizations you do see this problem. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-07-29 09:33:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40900
[Bug rtl-optimization/40900] redundant sign extend of short function returned value
--- Comment #3 from ramana at gcc dot gnu dot org 2009-07-29 10:33 --- I don't think this is a backend specific problem but more an rtl-optimization problem where combine with its sign extension detection machinery should be extended to detect such cases. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Component|target |rtl-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40900
[Bug libffi/40242] unsupported asm instructions in libffi/src/arm/sysv.S
--- Comment #5 from ramana at gcc dot gnu dot org 2009-08-03 08:31 --- Confirmed with Trunk as of 150308 -- ramana at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|-00-00 00:00:00 |2009-08-03 08:31:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40242
[Bug libffi/40242] unsupported asm instructions in libffi/src/arm/sysv.S
--- Comment #6 from ramana at gcc dot gnu dot org 2009-08-03 08:33 --- (In reply to comment #5) > Confirmed with Trunk as of 150308 > With the following options. /home/ramrad01/sources/trunk/configure --with-cpu=cortex-a8 --with-float=softfp --with-fpu=neon -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|2009-08-03 08:31:56 |2009-08-03 08:33:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40242
[Bug target/36466] internal compiler error: in choose_reload_regs, at reload1.c:6190
--- Comment #7 from ramana at gcc dot gnu dot org 2009-08-05 16:42 --- Invalid testcase as per comment #6. (In reply to comment #4) > I see the same problem when I try to compile transmission release 1.73. The > error happens with file libtransmission/fdlimit.c. Works till -O1 but fails > with -O2 or -O3. Seeing this error with gcc 4.21. > Please file a separate bug report about this as per http://gcc.gnu.org/bugs.html if you can reproduce this for trunk or any of the current release branches. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36466
[Bug target/29274] 4.1, 4.2 (possibly 4.0?) not using mulsidi3
--- Comment #3 from ramana at gcc dot gnu dot org 2009-03-27 17:12 --- I can see this with trunk as well as 4.3 branch today. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-03-27 17:12:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29274
