[Bug target/52060] Incorrect mask/and (ARM bic) instruction generated for shifted expression parameter, triggered by -O2 -finline-functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52060 Ian Bolton ibolton at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-03 CC||ibolton at gcc dot gnu.org Ever Confirmed|0 |1 Known to fail||4.7.0 --- Comment #3 from Ian Bolton ibolton at gcc dot gnu.org 2012-02-03 16:49:55 UTC --- Confirmed on trunk (r183840).
[Bug middle-end/51794] ICE (segfault) with -O -fmodulo-sched
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51794 Ian Bolton ibolton at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-02-03 CC||ibolton at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Ian Bolton ibolton at gcc dot gnu.org 2012-02-03 18:44:16 UTC --- I could not reproduce with trunk (4.7.0) r183218 or r183840. Please can you provide details of your cc1. This is mine: /work/ian/cross-build/trunk-r183218-thumb/arm-none-linux-gnueabi/tools/libexec/gcc/arm-none-linux-gnueabi/4.7.0/cc1 -quiet -v /home/ian/bugzilla/pr51794.c -quiet -dumpbase pr51794.c -mcpu=cortex-a9 -mfloat-abi=softfp -mfpu=vfpv3-d16 -marm -mtls-dialect=gnu -auxbase-strip test.o -O -version -fmodulo-sched -o /tmp/cc76gYW3.s
[Bug target/49180] pr45070.c fails for -Os -mthumb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49180 Ian Bolton ibolton at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.06.01 13:32:49 CC||ibolton at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from Ian Bolton ibolton at gcc dot gnu.org 2011-06-01 13:32:49 UTC --- I have managed to reproduce this with latest trunk. Hopefully, the copyright assignment will come through soon and Mikael can post his patch.
[Bug target/49030] ICE in get_arm_condition_code, at config/arm/arm.c:17180
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49030 Ian Bolton ibolton at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.05.20 09:50:09 CC||ibolton at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Ian Bolton ibolton at gcc dot gnu.org 2011-05-20 09:50:09 UTC --- I haven't been able to reproduce this. Please can you include the args that are being sent to cc1.
[Bug target/49069] ICE in gen_cstoredi4, at config/arm/arm.md:7554
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49069 Ian Bolton ibolton at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.05.20 10:05:11 CC||ibolton at gcc dot gnu.org Ever Confirmed|0 |1 Known to fail||4.7.0 --- Comment #1 from Ian Bolton ibolton at gcc dot gnu.org 2011-05-20 10:05:11 UTC --- Confirmed. Fails for ARM and Thumb. Here's my compiler command-line: cc1 -fpreprocessed 49069.i -quiet -dumpbase 49069.i -marm -mcpu=cortex-a9 -mfloat-abi=softfp -mfpu=vfpv3-d16 -auxbase 49069 -Os -version -o 49069.s This has actually been broken since at least r164700 (I had some old toolchains available to try), so I expect 4.6.0 is broken too, but I don't have time to confirm at the moment.
[Bug target/49049] ICE in copyprop_hardreg_forward_1, at regcprop.c:767
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49049 Ian Bolton ibolton at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.05.20 09:53:22 CC||ibolton at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Ian Bolton ibolton at gcc dot gnu.org 2011-05-20 09:53:22 UTC --- Confirmed. Note that it does not happen for -marm. Full compilation command-line: cc1 -fpreprocessed 49049.i -quiet -dumpbase 49049.i -mthumb -mcpu=cortex-a9 -mfloat-abi=softfp -mfpu=vfpv3-d16 -auxbase 49049 -O3 -version -o 49049.s
[Bug target/49030] ICE in get_arm_condition_code, at config/arm/arm.c:17180
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49030 Ian Bolton ibolton at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW Known to fail||4.7.0 --- Comment #3 from Ian Bolton ibolton at gcc dot gnu.org 2011-05-20 13:46:00 UTC --- I was hoping the compiler command would tell me what -mcpu it was defaulting to. Anyway, I have managed to reproduce it now, by compiling as follows: cc1 -fpreprocessed 49030.i -quiet -O1 -o 49030.s -mcpu=arm7tdmi -marm Note that it all works with -mthumb and/or -mcpu=cortex-a9. I have tried this with my old toolchain and it is broken as far back as r164700.
[Bug target/49049] ICE in copyprop_hardreg_forward_1, at regcprop.c:767
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49049 --- Comment #3 from Ian Bolton ibolton at gcc dot gnu.org 2011-05-20 13:50:56 UTC --- Thanks for confirming that. If I try -marm -mcpu=arm7tdmi I can get the ICE, but not with -marm -mcpu=cortex-a9.
[Bug driver/44273] Using -save-temps and @file should also save the intermediate @file used by the driver.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44273 Ian Bolton ibolton at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ibolton at gcc dot gnu.org Resolution||WONTFIX --- Comment #1 from Ian Bolton ibolton at gcc dot gnu.org 2011-05-10 09:38:15 UTC --- This can be achieved by specifying -Wl,-debug, so the behaviour of --save-temps does not need to change.
[Bug target/48808] ICE in spill_failure, at reload1.c:2113
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48808 Ian Bolton ibolton at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2011.05.03 10:54:06 CC||ibolton at gcc dot gnu.org Ever Confirmed|0 |1 Known to fail||4.7.0 --- Comment #1 from Ian Bolton ibolton at gcc dot gnu.org 2011-05-03 10:54:06 UTC --- Confirmed on r173122 of trunk, using the command-line args provided by the reporter. I have managed to traced it back to happening somewhere between r172185 (works) and r172316 (ICEs) of trunk. Looking through the Changelogs for reload, the most likely candidates are: r172297 | cltang | 2011-04-12 05:42:55 +0100 (Tue, 12 Apr 2011) | 10 lines 2011-04-11 Chung-Lin Tang clt...@codesourcery.com Richard Earnshaw rearn...@arm.com PR target/48250 * config/arm/arm.c (arm_legitimize_reload_address): Update cases to use sign-magnitude offsets. Reject unsupported unaligned cases. Add detailed description in comments. * config/arm/arm.md (reload_outdf): Disable for ARM mode; change condition from TARGET_32BIT to TARGET_ARM. r172231 | aesok | 2011-04-09 20:10:45 +0100 (Sat, 09 Apr 2011) | 8 lines * expr.c (expand_expr_real_1): Use add_to_hard_reg_set function instead of loop. * sel-sched.c (mark_unavailable_hard_regs): Likewise. * function.c (record_hard_reg_sets): Likewise. * ira.c (compute_regs_asm_clobbered): Likewise. * sched-deps.c (sched_analyze_1): Likewise. * reload1.c (mark_reload_reg_in_use, choose_reload_regs): Likewise. r172197 | danglin | 2011-04-08 17:21:39 +0100 (Fri, 08 Apr 2011) | 12 lines PR target/48366 * config/pa/pa.c (hppa_register_move_cost): Increase to 18 cost of move from floating point to shift amount register . (emit_move_sequence): Remove secondary reload support for floating point to shift amount amount register copies. (pa_secondary_reload): Return GENERAL_REGS for floating point/shift amount register copies. * config/pa/pa32-regs.h (HARD_REGNO_MODE_OK): For shift amount register, return false if mode isn't a scalar integer mode. * config/pa/pa64-regs.h (HARD_REGNO_MODE_OK): Likewise. I don't have more time to devote to investigating this today, but hopefully someone else will be able to work out which change it was.
[Bug target/48792] ICE in failed_reload, at reload1.c:6000
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48792 Ian Bolton ibolton at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2011.05.03 12:54:27 CC||ibolton at gcc dot gnu.org Known to work||4.7.0 See Also||http://gcc.gnu.org/bugzilla ||/show_bug.cgi?id=48808 Ever Confirmed|0 |1 --- Comment #1 from Ian Bolton ibolton at gcc dot gnu.org 2011-05-03 12:54:27 UTC --- Confirmed. r170870 works. r172057 is broken. I think this is related to PR48808, but that one works for r172057, so I think that there is more likely some root cause that gets exposed in these two PRs.
[Bug rtl-optimization/48434] [4.7 Regression] Large SpecCPUFP Performance Regression for Thumb-2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48434 Ian Bolton ibolton at gcc dot gnu.org changed: What|Removed |Added Keywords||patch Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Ian Bolton ibolton at gcc dot gnu.org 2011-04-12 09:02:25 UTC --- This regression went away between r172185 and r172255. Performance is back to normal for SpecFP for Thumb-2 VFP. It was most likely fixed as a result of the PR48435 fix. The patch for that is here: http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00573.html.
[Bug other/48434] Large SpecCPUFP Performance Regression for Thumb-2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48434 Ian Bolton ibolton at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.04.05 09:07:14 Ever Confirmed|0 |1 --- Comment #2 from Ian Bolton ibolton at gcc dot gnu.org 2011-04-05 09:07:14 UTC --- (In reply to comment #1) Re-commit of IRA improvements? Are the results visible somewhere, similar to gcc.opensuse.org? r171648 (just before the first IRA change) does not show the regression. r171649 did not build for me - probably because it was the first of a few IRA patches. r171713 did build, and does show the regression. I think it is an IRA thing, as there aren't many non-IRA changes between the good and bad revisions.
[Bug other/48434] New: Large SpecCPUFP Performance Regression for Thumb-2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48434 Summary: Large SpecCPUFP Performance Regression for Thumb-2 Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: ibol...@gcc.gnu.org Host: arm-linux-gnueabi Target: arm-linux-gnueabi Build: arm-linux-gnueabi At least once a week, we measure SpecCPU2000 performance for Thumb-2 on a Cortex-A9. On Monday, all was well, but on Wednesday, there was a large performance regression across the board on SpecFP (except for Mesa and Facerec). Overall FP score has dropped by 25%. Known good revision: r171422 Know bad revision: r171723 I am currently bisecting to find the problem commit.
[Bug target/48308] crosscompiling to arm fails with assembler: can't resolve '.LC4' {.rodata.str1.1 section} - '.LPIC4' {*UND* section}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48308
Ian Bolton ibolton at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.03.29 15:23:12
CC||ibolton at gcc dot gnu.org
Known to work||4.4.5, 4.5.2
Ever Confirmed|0 |1
Known to fail||4.6.0, 4.7.0
--- Comment #6 from Ian Bolton ibolton at gcc dot gnu.org 2011-03-29 15:23:12
UTC ---
Using trunk, r171422, I have compiled the reduced test case as follows:
arm-none-linux-gnueabi-gcc -fPIC -Os -c pr48308.c -mcpu=arm9tdmi -marm
pr48308.s: Assembler messages:
pr48308.s:97: Error: can't resolve `.LC4' {.rodata.str1.1 section} - `.LPIC4'
{*UND* section}
With --save-temps, you can see the missing .LPIC4 in the .s.
This is therefore confirmed in trunk as well.
FYI: the problem doesn't happen with -mthumb.
[Bug target/48325] ICE in reload_cse_simplify_operands, at postreload.c:403 with neon optimized code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48325
Ian Bolton ibolton at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.03.29 16:23:26
CC||ibolton at gcc dot gnu.org
Ever Confirmed|0 |1
Known to fail||4.5.3, 4.7.0
--- Comment #2 from Ian Bolton ibolton at gcc dot gnu.org 2011-03-29 16:23:26
UTC ---
I get the same thing when I use r171282 of FSF 4.5 branch.
arm-none-linux-gnueabi-gcc pr48325.c -mfloat-abi=softfp -mfpu=neon -O1
pr48325.c: In function 'test':
pr48325.c:19:1: error: insn does not satisfy its constraints:
(insn 40 38 26 2
/work/ianbol01/cross-build/gcc45-r171282-thumb/arm-none-linux-gnueabi/tools/lib/gcc/arm-none-linux-gnueabi/4.5.3/include/arm_neon.h:10277
(set (reg:OI 95 d16 [orig:152 __b ] [152])
(mem/s/c:OI (pre_dec:SI (reg/f:SI 3 r3 [151])) [0 __b+0 S32 A64])) 731
{*neon_movoi} (expr_list:REG_INC (reg/f:SI 3 r3 [151])
(nil)))
pr48325.c:19:1: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:396
Here is the command-line just for cc1:
cc1 -quiet pr48325.c -mfloat-abi=softfp -mfpu=neon -marm -mcpu=cortex-a9 -O1
Doesn't work for thumb either.
It also fails on trunk.
There are two other bugs in flight that manifest in
reload_cse_simplify_operands: PR48250 (broke on trunk for EABI, works on 4.5
for EABI) and PR42949 (works on EABI for trunk and gcc4.5, broke for OABI).
I do not know if they are duplicates of each other, or if there are two or more
separate bugs causing this.
[Bug target/42949] ICE: reload_cse_simplify_operands, at postreload.c:396
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42949 Ian Bolton ibolton at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING CC||ibolton at gcc dot gnu.org --- Comment #3 from Ian Bolton ibolton at gcc dot gnu.org 2011-03-24 14:24:23 UTC --- For gcc 4.5 r171282, arm-none-linux-gnueabi, I can run this command without error: arm-none-linux-gnueabi-g++ ~/investigate/pr42949.i -B. -c -O1 -mfpu=vfp It also works for trunk (r171212). I therefore think this is fixed or has ceased to be, but it would be good to get confirmation someone else.
[Bug target/48250] ICE in reload_cse_simplify_operands, at postreload.c:403
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48250 Ian Bolton ibolton at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||4.5.3 Version|4.6.0 |4.7.0 Keywords||ice-on-valid-code Last reconfirmed||2011.03.24 14:34:13 CC||ibolton at gcc dot gnu.org Ever Confirmed|0 |1 Known to fail||4.7.0 --- Comment #1 from Ian Bolton ibolton at gcc dot gnu.org 2011-03-24 14:34:13 UTC --- Confirmed on trunk, r171212. Works on latest 4.5 (r171282). I don't think this is the same bug as PR42949 because that one has now ceased to occur - for me at least.
[Bug target/47920] strange code generated for expression (a+7)/8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47920 Ian Bolton ibolton at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.03.03 10:49:54 CC||ibolton at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #4 from Ian Bolton ibolton at gcc dot gnu.org 2011-03-03 10:49:54 UTC --- I don't think strange code applies any more, thanks to input from Mikael and Jakub. I am wondering whether to reject this bug. Any further comments?
[Bug target/47831] avoid if-convertion if the conditional instructions and following conditional branch has the same condition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47831 Ian Bolton ibolton at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.22 14:50:03 CC||ibolton at gcc dot gnu.org Ever Confirmed|0 |1 Known to fail||4.6.0 --- Comment #1 from Ian Bolton ibolton at gcc dot gnu.org 2011-02-22 14:50:03 UTC --- Confirmed on r170278 of trunk. The better sequence that Carrot mentions comes from having if-conversion disabled (-fno-if-conversion2). I expect Basic Block Reordering might be able to help out in the case where if-conversion is enabled, but I think it is still disabled for -Os, as it can sometimes lead to larger code. That is a separate issue though. To tackle this properly, the if-conversion heuristic would need to be enhanced to detect cases where the codesize will likely increase and pessimise against those cases when using -Os.
[Bug target/47764] The constant load instruction should be hoisted out of loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47764 Ian Bolton ibolton at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.18 11:36:27 CC||ibolton at gcc dot gnu.org Ever Confirmed|0 |1 Known to fail||4.6.0 --- Comment #1 from Ian Bolton ibolton at gcc dot gnu.org 2011-02-18 11:36:27 UTC --- I have confirmed this for r170052 of trunk. Any ideas of how this improvement could be implemented, Carrot?
[Bug c++/47749] Wrong function return value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47749 Ian Bolton ibolton at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.02.15 10:25:35 CC||ibolton at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #3 from Ian Bolton ibolton at gcc dot gnu.org 2011-02-15 10:25:35 UTC --- What compile flags are you using? Have you tried gcc 4.5?
[Bug rtl-optimization/47166] [4.5 Regression] SpecCpu2000 Ammp segfaults for ARM with -O3 -mthumb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47166 --- Comment #30 from Ian Bolton ibolton at gcc dot gnu.org 2011-02-15 15:47:24 UTC --- (In reply to comment #29) I've had some problems with timeouts in my test setup, but I now have runs that differ only in that pthread1.cc times out for one multilib and no longer times out for another. I took that as good enough to commit the patch. Just wanted to confirm that it is working for me with 4.5 now as well. Thanks for all your efforts, Bernd.
[Bug bootstrap/46456] cppbuiltin.o fails to build for arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46456 Ian Bolton ibolton at gcc dot gnu.org changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment #3 from Ian Bolton ibolton at gcc dot gnu.org 2011-02-09 09:38:57 UTC --- *** Bug 46276 has been marked as a duplicate of this bug. ***
[Bug target/46276] cppbuiltin.c:154:7: error: 'or' of unmatched not-equal tests is always 1 [-Werror]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46276 Ian Bolton ibolton at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ibolton at gcc dot gnu.org Resolution||DUPLICATE --- Comment #5 from Ian Bolton ibolton at gcc dot gnu.org 2011-02-09 09:38:57 UTC --- This is a duplicate of a fixed bug (PR46456), so marking RESOLVED DUPLICATE. *** This bug has been marked as a duplicate of bug 46456 ***
[Bug fortran/36158] Transformational function BESSEL_YN(n1,n2,x) and BESSEL_JN missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36158
Ian Bolton ibolton at gcc dot gnu.org changed:
What|Removed |Added
CC||ibolton at gcc dot gnu.org
--- Comment #15 from Ian Bolton ibolton at gcc dot gnu.org 2011-02-07
13:47:35 UTC ---
(In reply to comment #10)
Subject: Bug 36158
Author: burnus
Date: Sat Aug 21 10:12:53 2010
New Revision: 163440
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163440
Log:
2010-08-21 Tobias Burnus bur...@net-b.de
PR fortran/36158
PR fortran/33197
* intrinsic.c (add_sym): Init value attribute.
(set_attr_value): New function.
(add_functions) Use it and add JN/YN resolvers.
* symbol.c (gfc_copy_formal_args_intr): Copy value attr.
* intrinsic.h (gfc_resolve_bessel_n2): New prototype.
* gfortran.h (gfc_intrinsic_arg): Add value attribute.
* iresolve.c (gfc_resolve_bessel_n2): New function.
* trans-intrinsic.c (gfc_get_symbol_for_expr): Create
formal arg list.
(gfc_conv_intrinsic_function,gfc_is_intrinsic_libcall):
Add GFC_ISYM_JN2/GFC_ISYM_YN2 as case value.
* simplify.c (): For YN set to -INF if previous values
was -INF.
* trans-expr.c (gfc_conv_procedure_call): Don't crash
if sym-as is NULL.
* iresolve.c (gfc_resolve_extends_type_of): Set the
type of the dummy argument to the one of the actual.
2010-08-21 Tobias Burnus bur...@net-b.de
PR fortran/36158
PR fortran/33197
* m4/bessel.m4: Implement bessel_jn and bessel_yn.
* gfortran.map: Add the generated bessel_jn_r{4,8,10,16}
and bessel_yn_r{4,8,10,16}.
* Makefile.am: Add bessel.m4.
* Makefile.in: Regenerated.
* generated/bessel_r4.c: Generated.
* generated/bessel_r16.c: Generated.
* generated/bessel_r8.c: Generated.
* generated/bessel_r10.c: Generated.
2010-08-21 Tobias Burnus bur...@net-b.de
PR fortran/36158
PR fortran/33197
* gfortran.dg/bessel_6.f90: New.
* gfortran.dg/bessel_7.f90: New.
Is this going to be backported to 4.5? It is required to make CSHIFT function
correctly.
[Bug fortran/36158] Transformational function BESSEL_YN(n1,n2,x) and BESSEL_JN missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36158 --- Comment #17 from Ian Bolton ibolton at gcc dot gnu.org 2011-02-07 15:41:14 UTC --- (In reply to comment #16) (In reply to comment #15) Is this going to be backported to 4.5? It is required to make CSHIFT function correctly. It may be prudent to actually describe the problem with cshift and give a short example. The above is of little value. Sorry about that. You are right - I should have given more information. Here goes: Currently, the code for the gfc_get_symbol_for_expr() function on the 4.5 branch has a comment that says: /* TODO: proper argument lists for external intrinsics. */ CSHIFT is one such fortran intrinsic, which will have an incorrect formal argument list due to this TODO not being done. Specifically, we can end up with a _gfortran_cshift0_4 call with no formal arguments. Here is a reduced testcase (adapted from an existing testcase) that shows such an issue with _gfortran_cshift0_4: ! Program to test the cshift intrinsic program intrinsic_cshift integer, dimension(3, 2) :: a ! Scalar shift a = reshape ((/1, 2, 3, 4, 5, 6/), (/3, 2/)) a = cshift (a, 1, 1) if (any (a .ne. reshape ((/2, 3, 1, 5, 6, 4/), (/3, 2/ call abort end program There is no information within the existing tree dumps to show things have gone wrong, but debugging with gdb and inserting a breakpoint within the gfc_get_symbol_for_expr function will show that expr-value.function.isym.formal has three items in it, whereas the new sym that we create is empty. The patch that fixed PR36158 correctly copies the formal arguments from isym to sym and we then get the correct behaviour. I hope that information is sufficient.
[Bug target/47543] [4.6 Regression] ICE: in extract_insn, at recog.c:2109 when building zlib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47543 --- Comment #9 from Ian Bolton ibolton at gcc dot gnu.org 2011-02-02 09:50:23 UTC --- (In reply to comment #8) The potential fix seems to work fine on x86 as well. I'm going to build a arm-elf toolchain and see if anything else pops up during a cross build. If someone with real arm hardware could do a bootstrap with the potential fix applied, it'd be greatly appreciated. Thanks for nailing this one so quickly, Jeff. I will set off a native bootstrap and report back when done.
[Bug target/47543] [4.6 Regression] ICE: in extract_insn, at recog.c:2109 when building zlib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47543 --- Comment #10 from Ian Bolton ibolton at gcc dot gnu.org 2011-02-02 14:49:02 UTC --- (In reply to comment #8) The potential fix seems to work fine on x86 as well. I'm going to build a arm-elf toolchain and see if anything else pops up during a cross build. If someone with real arm hardware could do a bootstrap with the potential fix applied, it'd be greatly appreciated. The native bootstrap was successful. I configured with: --with-cpu=cortex-a9 --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb --enable-languages=c,c++,fortran
[Bug target/47543] [4.6 Regression] ICE: in extract_insn, at recog.c:2109 when building zlib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47543 --- Comment #12 from Ian Bolton ibolton at gcc dot gnu.org 2011-02-02 15:06:07 UTC --- The native bootstrap was successful. I configured with: --with-cpu=cortex-a9 --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb --enable-languages=c,c++,fortran Thanks. After sleeping on it, I made one tweak to the patch to avoid potential problems with creating invalid reg+reg addresses. I'll post the final version of the fix shortly. I forgot to mention that I also used the bootstrapped compiler to confirm that the reduced test case now works. I will re-confirm when your final patch is posted. Thanks again.
[Bug target/47543] ICE: in extract_insn, at recog.c:2109 when building zlib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47543 Ian Bolton ibolton at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.31 10:53:30 CC||ibolton at gcc dot gnu.org Ever Confirmed|0 |1 Known to fail||4.6.0
[Bug rtl-optimization/47454] registers are not allocated according to its preferred order
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47454 Ian Bolton ibolton at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.01.28 09:57:13 CC||ibolton at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Ian Bolton ibolton at gcc dot gnu.org 2011-01-28 09:57:13 UTC --- (In reply to comment #0) Created attachment 23115 [details] testcase Note that register r8 is used many times, but register r2 is never used. In thumb2 r8 is high register, its usage will cause 32bit instructions. If we replace r8 with r2, a lot of code size will be reduced in this case. In arm.h REG_ALLOC_ORDER is defined as 3, 2, 1, 0, 12, 14, 4, 5, 6, 7, 8, 10, 9, 11, 13, 15 ... We can see that r2 should be used before r8, but the result is not. I have thought about doing work in IRA to address this, so that we impose a higher cost for the higher registers if we have not yet ventured into them. In this particular case, the issue will be with IRA's calculated register costs. The REG_ALLOC_ORDER is only used when costs are equal, which is why the allocated order is normally roughly inline with it. R2 must be given a high cost for some reason, which causes assign_hard_reg to prefer later registers with lower costs. The IRA dump will show you the costs. If you attach it to this, we could investigate further.
[Bug middle-end/44554] Stack space after sigsetjmp is reused
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44554 Ian Bolton ibolton at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.01.28 10:03:46 Ever Confirmed|0 |1 --- Comment #17 from Ian Bolton ibolton at gcc dot gnu.org 2011-01-28 10:03:46 UTC --- (In reply to comment #15) (In reply to comment #14) Created attachment 21901 [details] A patch that should fix it Please verify whether this fixes it. Hasn't it already been fixed in comment #11? My plan was to wait until release of gcc-4.4.5 and test then. Are additional changes required to fix this bug? gcc 4.4.5 was released in October. Please can you confirm if this is now fixed.
[Bug c++/46317] Incorrect construction vtable on ARM in case of diamond shaped virtual inheritance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46317 Ian Bolton ibolton at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.01.28 10:19:03 CC||ibolton at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #3 from Ian Bolton ibolton at gcc dot gnu.org 2011-01-28 10:19:03 UTC --- (In reply to comment #2) (In reply to comment #1) Does -fno-tree-sink fixes the issue? No it doesn't. The only flags that works are: -O0 or -fno-inline or -fno-unit-at-a-time or -fno-toplevel-reorder I can also make it work more or less by deactivating a certain number of optimisation flag, but the output code does not really work... (I have tried something like 58 different flags...) Out of interest, did you try any newer releases of gcc?
[Bug target/46762] gcc crosscompiled for arm optimises away volatile struct member access when -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46762 Ian Bolton ibolton at gcc dot gnu.org changed: What|Removed |Added CC||ibolton at gcc dot gnu.org Known to work||4.5.3, 4.6.0 Target Milestone|--- |4.5.3 --- Comment #1 from Ian Bolton ibolton at gcc dot gnu.org 2011-01-28 10:36:23 UTC --- I have not yet confirmed that this occurs in gcc 4.5.1 (as opposed to the codesourcery release), but it is working correctly in gcc 4.5.3 (gcc 4.5 branch) and 4.6.0 (trunk).
[Bug middle-end/44554] Stack space after sigsetjmp is reused
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44554 --- Comment #19 from Ian Bolton ibolton at gcc dot gnu.org 2011-01-28 11:30:50 UTC --- (In reply to comment #18) (In reply to comment #17) gcc 4.4.5 was released in October. Please can you confirm if this is now fixed. I think THIS bug is fixed in 4.4.5. Unfortunately I've still problems with wrong computations as already mentioned in comment #8. But this would either be related to PR40386 or it's another bug. I think it's best to raise a new bug, and CC Vladimir Makarov and Jeff Law. It will help to hear about the specific issues you are still seeing within that bug report.
[Bug target/47246] [4.6 Regression] Invalid immediate offset for Thumb VFP store regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47246 --- Comment #7 from Ian Bolton ibolton at gcc dot gnu.org 2011-01-27 16:51:41 UTC --- (In reply to comment #6) Assuming this is fixed now. Yes, I can use trunk to run the whole of Spec2K for -O3 -mthumb without errors.
[Bug rtl-optimization/47166] [4.5/4.6 Regression] SpecCpu2000 Ammp segfaults for ARM with -O3 -mthumb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47166 --- Comment #23 from Ian Bolton ibolton at gcc dot gnu.org 2011-01-25 13:45:59 UTC --- (In reply to comment #21) So is this now fixed on the trunk? Can anyone run SPEC2k? Spec2K's Ammp now runs correctly for trunk, with -mthumb -O3. The rest of Spec2K is OK too (apart from mesa, which is the subject of another bug).
[Bug rtl-optimization/47166] [4.5/4.6 Regression] SpecCpu2000 Ammp segfaults for ARM with -O3 -mthumb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47166 --- Comment #22 from Ian Bolton ibolton at gcc dot gnu.org 2011-01-24 14:54:51 UTC --- (In reply to comment #21) So is this now fixed on the trunk? Can anyone run SPEC2k? I can run it. I will report back when done.
[Bug rtl-optimization/47166] [4.5/4.6 Regression] SpecCpu2000 Ammp segfaults for ARM with -O3 -mthumb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47166 Ian Bolton ibolton at gcc dot gnu.org changed: What|Removed |Added Keywords||patch --- Comment #11 from Ian Bolton ibolton at gcc dot gnu.org 2011-01-12 10:36:39 UTC --- I have now confirmed Richard's patch (http://gcc.gnu.org/ml/gcc-patches/2011-01/msg00548.html) is doing the right thing on 4.5 branch and trunk, for the tests that were previously failing. Thanks very much for debugging this, Bernd. Many thanks for your patch, Richard.
[Bug rtl-optimization/47166] [4.5/4.6 Regression] SpecCpu2000 Ammp segfaults for ARM with -O3 -mthumb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47166 --- Comment #12 from Ian Bolton ibolton at gcc dot gnu.org 2011-01-12 10:44:11 UTC --- (In reply to comment #9) Created attachment 22945 [details] Test patch Could you try the following? It's a variant of a patch Richard Sandiford recently posted. Just noticed you said this is a variant of Richard's patch. Hopefully the two patches can be reconciled?
[Bug rtl-optimization/47166] [4.5/4.6 Regression] SpecCpu2000 Ammp segfaults for ARM with -O3 -mthumb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47166 --- Comment #10 from Ian Bolton ibolton at gcc dot gnu.org 2011-01-11 17:42:52 UTC --- (In reply to comment #9) Created attachment 22945 [details] Test patch Could you try the following? It's a variant of a patch Richard Sandiford recently posted. Thanks for looking into this. The patch has worked on gcc 4.5 for Ammp, but I still need to test Applu (which is failing for current version of gcc 4.5 branch) and then Ammp on trunk. I'll get back to you. It's looking promising though.
[Bug rtl-optimization/47246] New: [4.6 Regression] Invalid immediate offset for Thumb VFP store
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47246 Summary: [4.6 Regression] Invalid immediate offset for Thumb VFP store Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: ibol...@gcc.gnu.org Host: arm-linux-gnueabi Target: arm-linux-gnueabi Build: arm-linux-gnueabi Created attachment 22939 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22939 This is the preprocessed source that shows the issue The following patch, which went into trunk as revision 168045, has made it possible for gcc to generate invalid offsets for some VFP stores: http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01349.html The range -1024 to +1024 is ok for 's' co-processor registers, but not for generic 'r' registers. The attached preprocessed source can be made to show the issue by compiling as follows: gcc -O3 -mthumb mcpu=cortex-a9 -mfloat-abi=softfp -mfpu=vfpv3-d16 besttry.i --save-temps The error caused is this: /tmp/ccxviNhV.s: Assembler messages: /tmp/ccxviNhV.s:37: Error: offset out of range I have attached the produced besttry.s. In the short-term, I suggest that we limit the negative offset, to be able to cover the case where VFP store ends up using general registers. I do not know how we could allow a larger negative offset for the 's' registers, when it is not known until later what type of register will get allocated.
[Bug rtl-optimization/47246] [4.6 Regression] Invalid immediate offset for Thumb VFP store
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47246 --- Comment #1 from Ian Bolton ibolton at gcc dot gnu.org 2011-01-10 16:17:37 UTC --- Created attachment 22940 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22940 Demonstrates the problem instruction, on line 37
[Bug target/45814] ICE in extract_insn, at recog.c:2127
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45814 Ian Bolton ibolton at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.01.07 11:44:57 CC||ibolton at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Ian Bolton ibolton at gcc dot gnu.org 2011-01-07 11:44:57 UTC --- I was able to replicate this with r165124 of trunk, but latest trunk is not showing this problem. Please can you confirm it is now working for you, Ryan.
[Bug pch/45979] precompiled headers breakage on 2.6.36-rc Linux/ARM kernels
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45979 Ian Bolton ibolton at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.01.07 11:49:35 CC||ibolton at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #8 from Ian Bolton ibolton at gcc dot gnu.org 2011-01-07 11:49:35 UTC --- Please can you confirm that this is now fixed in trunk, Mikael. And has it been backported?
[Bug target/47133] code size opportunity for boolean expression evaluation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47133 Ian Bolton ibolton at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.07 14:29:29 CC||ibolton at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Ian Bolton ibolton at gcc dot gnu.org 2011-01-07 14:29:29 UTC --- I have confirmed this on r168563 of trunk.
[Bug rtl-optimization/47166] [4.5 4.6 Regression] SpecCpu2000 Ammp segfaults for ARM with -O3 -mthumb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47166 --- Comment #6 from Ian Bolton ibolton at gcc dot gnu.org 2011-01-05 14:38:42 UTC --- I mean, the But r1 is an input as well as an output , i.e. referred to, so insn 3163 should have matched without your patch. I'm missing analysis on why that didn't happen part. OK, I will do more analysis to try to determine what's going on.
[Bug rtl-optimization/47166] [4.5 4.6 Regression] SpecCpu2000 Ammp segfaults for ARM with -O3 -mthumb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47166 Ian Bolton ibolton at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.05 16:45:57 Ever Confirmed|0 |1 --- Comment #7 from Ian Bolton ibolton at gcc dot gnu.org 2011-01-05 16:45:57 UTC --- I have altered the source, so that I call both refers_to_regno_p and reg_mentioned_p and print out when the two disagree. For the attached rectmm.i input file, there are only 5 disagreements: mismatch for regno=2343: refersto=F,mentions=T reg = (reg/f:SI 2343) i1 = (insn 3162 1730 3165 99 rectmm.c:1041 (set (reg/f:SI 2343) (reg:SI 1 r1)) -1 (nil)) mismatch for regno=2355: refersto=F,mentions=T reg = (reg/f:SI 2355) i1 = (insn 3166 1745 3169 99 rectmm.c:1043 (set (reg/f:SI 2355) (reg:SI 9 r9)) -1 (nil)) mismatch for regno=2377: refersto=F,mentions=T reg = (reg/f:SI 2377) i1 = (insn 3170 1770 1731 99 rectmm.c:1045 (set (reg/f:SI 2377) (reg:SI 12 ip)) -1 (nil)) mismatch for regno=2349: refersto=F,mentions=T reg = (reg/f:SI 2349) i1 = (insn 3174 1737 3177 99 rectmm.c:1042 (set (reg/f:SI 2349) (reg:SI 0 r0)) -1 (nil)) mismatch for regno=2361: refersto=F,mentions=T - reg and i1 follow ... reg = (reg/f:SI 2361) il = (insn 3178 1752 1772 99 rectmm.c:1044 (set (reg/f:SI 2361) (reg:SI 3 r3)) -1 (nil)) This occurs because reg_mentioned_p looks at output regs, but refers_to_regno_p does not. The knock-on effect of this difference must lead to those increments being lost, but I don't know why yet.
[Bug rtl-optimization/47166] New: [4.5 4.6 Regression] SpecCpu2000 Ammp segfaults for ARM with -O3 -mthumb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47166
Summary: [4.5 4.6 Regression] SpecCpu2000 Ammp segfaults for
ARM with -O3 -mthumb
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ibol...@gcc.gnu.org
Depends on: 45051
Host: arm-linux-gnueabi
Target: arm-linux-gnueabi
Build: arm-linux-gnueabi
As of r162558 on trunk, and r164498 on 4.5 branch, SpecCPU2000 Ammp has failed
for ARM -O3 thumb. The same patch was committed for both of these revisions,
intending to fix pr45051:
Index: gcc/reload1.c
===
--- gcc/reload1.c (revision 164495)
+++ gcc/reload1.c (revision 164498)
@@ -8325,6 +8325,8 @@ delete_output_reload (rtx insn, int j, i
int n_inherited = 0;
rtx i1;
rtx substed;
+ unsigned regno;
+ int nregs;
/* It is possible that this reload has been only used to set another reload
we eliminated earlier and thus deleted this instruction too. */
@@ -8376,6 +8378,12 @@ delete_output_reload (rtx insn, int j, i
if (n_occurrences n_inherited)
return;
+ regno = REGNO (reg);
+ if (regno = FIRST_PSEUDO_REGISTER)
+nregs = 1;
+ else
+nregs = hard_regno_nregs[regno][GET_MODE (reg)];
+
/* If the pseudo-reg we are reloading is no longer referenced
anywhere between the store into it and here,
and we're within the same basic block, then the value can only
@@ -8387,7 +8395,7 @@ delete_output_reload (rtx insn, int j, i
if (NOTE_INSN_BASIC_BLOCK_P (i1))
return;
if ((NONJUMP_INSN_P (i1) || CALL_P (i1))
- reg_mentioned_p (reg, PATTERN (i1)))
+ refers_to_regno_p (regno, regno + nregs, PATTERN (i1), NULL))
{
/* If this is USE in front of INSN, we only have to check that
there are no more references than accounted for by inheritance.
*/
I assume the patch was meant to prevent deletions that shouldn't occur. This
might be what happens for the original symptomatic test, but I am now seeing
extra deletions that shouldn't happen for Ammp.
For example, without this patch, you get these insns somewhere in the ira dump
for mm_fv_update_nonbon() from rectmm.c:
(insn 3163 3161 3164 107 rectmm.c:1041 (set (reg:SI 1 r1)
(plus:SI (reg:SI 1 r1)
(const_int 280 [0x118]))) 4 {*arm_addsi3} (nil))
(insn 3164 3163 1730 107 rectmm.c:1041 (set (reg:SI 3 r3)
(reg:SI 1 r1)) 586 {*thumb2_movsi_vfp} (nil))
With the patch, you lose the add and just get this:
(insn 3164 3161 1730 107 rectmm.c:1041 (set (reg:SI 3 r3)
(reg:SI 1 r1)) 586 {*thumb2_movsi_vfp} (nil))
The incrementing of r1 is perfectly legitimate and useful and removing it is a
bug. Other increments of r9, ip, r0 and r3 are also lost.
I think the issue might be that reg_mentioned_p() considers output registers to
have been mentioned, whereas the refers_to_regno_p() does not consider an
output register to have been referred to. I can see the problem with only
using reg_mentioned_p() because it doesn't handle subregs, but there is also a
problem with only using refers_to_regno_p(), as we can see with this segfault
in Ammp.
I therefore wonder if the fix might be this:
Index: gcc/reload1.c
===
--- gcc/reload1.c (revision 168082)
+++ gcc/reload1.c (working copy)
@@ -8395,7 +8395,8 @@ delete_output_reload (rtx insn, int j, i
if (NOTE_INSN_BASIC_BLOCK_P (i1))
return;
if ((NONJUMP_INSN_P (i1) || CALL_P (i1))
- refers_to_regno_p (regno, regno + nregs, PATTERN (i1), NULL))
+ (refers_to_regno_p (regno, regno + nregs, PATTERN (i1), NULL)
+ || reg_mentioned_p (reg, PATTERN (i1
{
/* If this is USE in front of INSN, we only have to check that
there are no more references than accounted for by inheritance.
*/
It would be helpful to have some input from someone who understands reload
better than I do, so we can come up with a fix that we have confidence in.
[Bug rtl-optimization/47166] [4.5 4.6 Regression] SpecCpu2000 Ammp segfaults for ARM with -O3 -mthumb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47166 --- Comment #2 from Ian Bolton ibolton at gcc dot gnu.org 2011-01-04 12:30:23 UTC --- Created attachment 22896 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22896 Preprocessed source, before/after .s file, before/after IRA dump Contains the following: pr47166/rectmm.i - the preprocessed source pr47166/CMD - how to compile it pr47166/rectmm.r164495.i.188r.ira - working IRA dump pr47166/rectmm.r164495.s - working assembly pr47166/rectmm.r164498.i.188r.ira - broken IRA dump pr47166/rectmm.r164498.s - broken assembly Note that the revision numbers represent working/broken revisions of gcc 4.5 branch.
[Bug rtl-optimization/47166] [4.5 4.6 Regression] SpecCpu2000 Ammp segfaults for ARM with -O3 -mthumb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47166 --- Comment #3 from Ian Bolton ibolton at gcc dot gnu.org 2011-01-04 12:32:50 UTC --- pr47166/CMD - how to compile it Sorry, I forgot to give cc1 commands: cc1 -fpreprocessed rectmm.i -quiet -dumpbase rectmm.i -mthumb -mcpu=cortex-a9 -mfloat-abi=softfp -mfpu=vfpv3-d16 -auxbase rectmm -O3 -version -fno-tree-vectorize -fdump-rtl-ira-details -o rectmm.s
[Bug rtl-optimization/45051] [4.6 Regression]: gcc.c-torture/execute/builtins/abs-2.c and abs-3.c due to track subwords of DImode allocnos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45051
Ian Bolton ibolton at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC||ibolton at gcc dot gnu.org
Resolution|FIXED |
--- Comment #7 from Ian Bolton ibolton at gcc dot gnu.org 2010-12-22 16:23:21
UTC ---
(In reply to comment #5)
Assuming fixed and closing. Please reopen if you still have a problem.
This patch has caused SpecCPU2000 Ammp to fail for ARM -O3 thumb.
I assume the patch was meant to prevent deletions that shouldn't occur. This
might be what happens for the original symptomatic test, but I am now seeing
extra deletions that shouldn't happen for Ammp.
For example, without this patch, you get these insns somewhere in the ira dump
for mm_fv_update_nonbon() from rectmm.c:
(insn 3163 3161 3164 107 rectmm.c:1041 (set (reg:SI 1 r1)
(plus:SI (reg:SI 1 r1)
(const_int 280 [0x118]))) 4 {*arm_addsi3} (nil))
(insn 3164 3163 1730 107 rectmm.c:1041 (set (reg:SI 3 r3)
(reg:SI 1 r1)) 586 {*thumb2_movsi_vfp} (nil))
With the patch, you lose the add and just get this:
(insn 3164 3161 1730 107 rectmm.c:1041 (set (reg:SI 3 r3)
(reg:SI 1 r1)) 586 {*thumb2_movsi_vfp} (nil))
The incrementing of r1 is perfectly legitimate and useful and removing it is a
bug. Other increments of r9, ip, r0 and r3 are also lost.
I think the issue might be that reg_mentioned_p() considers output registers to
have been mentioned, whereas the refers_to_regno_p() does not consider an
output register to have been referred to. I can see the problem with only
using reg_mentioned_p() because it doesn't handle subregs, but there is also a
problem with only using refers_to_regno_p(), as we can see with this segfault
in Ammp.
I therefore wonder if the fix might be this:
Index: gcc/reload1.c
===
--- gcc/reload1.c (revision 168082)
+++ gcc/reload1.c (working copy)
@@ -8395,7 +8395,8 @@ delete_output_reload (rtx insn, int j, i
if (NOTE_INSN_BASIC_BLOCK_P (i1))
return;
if ((NONJUMP_INSN_P (i1) || CALL_P (i1))
- refers_to_regno_p (regno, regno + nregs, PATTERN (i1), NULL))
+ (refers_to_regno_p (regno, regno + nregs, PATTERN (i1), NULL)
+ || reg_mentioned_p (reg, PATTERN (i1
{
/* If this is USE in front of INSN, we only have to check that
there are no more references than accounted for by inheritance.
*/
I am heading off for Christmas vacation shortly, so cannot look into this any
further, but I wanted to record my findings so far publicly. Apologies if
there is missing information. I return to work Jan 4th.
[Bug target/46191] Non-absolute names in libgcc_s.so
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46191 Ian Bolton ibolton at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.10.27 11:06:55 CC||ibolton at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #3 from Ian Bolton ibolton at gcc dot gnu.org 2010-10-27 11:06:55 UTC --- Setting status to NEW. How do other linker scripts do it?
[Bug target/46191] Non-absolute names in libgcc_s.so
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46191 Ian Bolton ibolton at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING --- Comment #4 from Ian Bolton ibolton at gcc dot gnu.org 2010-10-27 11:09:30 UTC --- On second thought, I have set this to WAITING, because the Known to work and Known to fail have not been complete. The Version is set to 4.5.0 - does trunk have a sensible solution?
[Bug target/46128] There is no mechanism for detecting VFP revisions in ARM GCC.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46128 Ian Bolton ibolton at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2010.10.27 12:59:21 CC||ibolton at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #3 from Ian Bolton ibolton at gcc dot gnu.org 2010-10-27 12:59:21 UTC --- Please complete the Known to work, Known to fail, Version and Target Milestone and any other useful details you can add. I can then move this onto the NEW status.
