[Bug target/44392] [4.5/4.6 Regression] libgcc compile with --enable-target-optspace (-Os) causes recursion in __bswapsi2
--- Comment #11 from ramana at gcc dot gnu dot org 2010-09-08 21:36 --- Subject: Bug 44392 Author: ramana Date: Wed Sep 8 21:35:48 2010 New Revision: 164029 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164029 Log: 2010-09-08 Ramana Radhakrishnan ramana.radhakrish...@arm.com PR target/44392 * config/arm/arm.md (bswapsi2): Handle condition correctly for armv6 and optimize_size. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44392
[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3
--- Comment #4 from ramana at gcc dot gnu dot org 2010-09-07 16:42 --- Confirmed based on comment #2 -- 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 |2010-09-07 16:42:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45445
[Bug tree-optimization/45533] New: Incorrect MEM_REF operand causes ICE.
/home/ramana/cross-build/arm-none-linux-gnueabi/obj/gcc2/gcc/cc1 -O2 ~/testcase.i Arch. specific configuration of GCC :--with-cpu=cortex-a9 --with-fpu=neon --with-float=softfp ./testcase.i: In function elf_machine_load_address: ./testcase.i:5254:38: warning: taking address of expression of type void [enabled by default] ./testcase.i: In function _dl_relocate_object: ./testcase.i:5432:1: error: Invalid first operand of MEM_REF. prephitmp.252_36 ./testcase.i:5432:1: note: in statement D.14709_176 = MEM[(const struct Elf32_Rel *)prephitmp.252_36 + 8B]; ./testcase.i:5432:1: error: Invalid first operand of MEM_REF. prephitmp.252_36 ./testcase.i:5432:1: note: in statement D.14712_1273 = MEM[(const struct Elf32_Rel *)prephitmp.252_36 + 8B]; ./testcase.i:5432:1: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. From a gdb session the pass that seems to have this problem with verification is ivopts. r163801 - works fine r163802 - starts ICE'ing. -- Summary: Incorrect MEM_REF operand causes ICE. Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ramana at gcc dot gnu dot org GCC host triplet: x86_64-linux GCC target triplet: arm-none-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45533
[Bug tree-optimization/45533] Incorrect MEM_REF operand causes ICE.
--- Comment #1 from ramana at gcc dot gnu dot org 2010-09-04 07:53 --- Created an attachment (id=21692) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21692action=view) Reduced testcase for ICE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45533
[Bug bootstrap/45514] [4.6 Regression] Bootstrap broken on arm-linux in locate_neon_builtin_icode
--- Comment #1 from ramana at gcc dot gnu dot org 2010-09-03 07:19 --- *** This bug has been marked as a duplicate of 45444 *** -- 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=45514
[Bug bootstrap/45444] [4.6 regression] ARM bootstrap failure: uninitialized const member in 'neon_builtin_datum' is invalid in C++ [-Werror=c++-compat]
--- Comment #6 from ramana at gcc dot gnu dot org 2010-09-03 07:19 --- *** Bug 45514 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=45444
[Bug target/45511] ICE in neon_valid_immediate, at config/arm/arm.c:8294
--- Comment #2 from ramana at gcc dot gnu dot org 2010-09-03 10:43 --- I don't see this with an arm-linux-gnu toolchain for r163798. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45511
[Bug target/44670] arm port fails to build with --enable-build-with-cxx
--- Comment #1 from ramana at gcc dot gnu dot org 2010-09-01 08:49 --- This is partially subsumed by the other bug at PR45444 *** This bug has been marked as a duplicate of 45444 *** -- 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=44670
[Bug bootstrap/45444] [4.6 regression] ARM bootstrap failure: uninitialized const member in 'neon_builtin_datum' is invalid in C++ [-Werror=c++-compat]
--- Comment #3 from ramana at gcc dot gnu dot org 2010-09-01 08:49 --- *** Bug 44670 has been marked as a duplicate of this bug. *** -- ramana at gcc dot gnu dot org changed: What|Removed |Added CC||amylaar at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45444
[Bug tree-optimization/42172] inefficient bit fields assignments
--- Comment #6 from ramana at gcc dot gnu dot org 2010-09-01 09:07 --- Leaving this open as per comment #4 -- 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 |2010-09-01 09:07:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42172
[Bug tree-optimization/42172] inefficient bit fields assignments
-- ramana at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42172
[Bug target/43588] ICE in copy_to_mode_reg, at explow.c:635
--- Comment #1 from ramana at gcc dot gnu dot org 2010-09-01 10:31 --- I'm not sure how well supported the old Linux target is with respect to the Neon builtins. It never received much testing and probably needs work since this target is in maintenance mode only. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P3 |P4 Last reconfirmed|-00-00 00:00:00 |2010-09-01 10:31:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43588
[Bug rtl-optimization/44025] Multiple load 0 to register
--- Comment #2 from ramana at gcc dot gnu dot org 2010-09-01 10:34 --- I'm not sure where this will be handled but I can see this with trunk today. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2010-09-01 10:34:47 date|| Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44025
[Bug bootstrap/45321] [4.6 regression] ARM bootstrap failure due to stdarg_p change
--- Comment #2 from ramana at gcc dot gnu dot org 2010-09-01 11:53 --- Subject: Bug 45321 Author: ramana Date: Wed Sep 1 11:52:55 2010 New Revision: 163726 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163726 Log: 2010-09-01 Mikael Pettersson mi...@it.uu.se PR bootstrap/45321 * tree.c (stdarg_p): Make fntype parameter const. * tree.h (stdarg_p): Likewise. (function_args_iterator): Remove unused fntype field. (function_args_iter_init): Do not initialize fntype field. Make fntype parameter const. Modified: trunk/gcc/ChangeLog trunk/gcc/tree.c trunk/gcc/tree.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45321
[Bug bootstrap/45321] [4.6 regression] ARM bootstrap failure due to stdarg_p change
--- Comment #3 from ramana at gcc dot gnu dot org 2010-09-01 12:03 --- Fixed. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45321
[Bug target/37954] [4.3 only] odd sized packed structures passed by value, under ARM, cause lockup of application
--- Comment #14 from ramana at gcc dot gnu dot org 2010-09-01 12:41 --- Patches should be submitted to gcc-patc...@gcc.gnu.org. This is a 4.3 only issue. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Known to fail||4.3.1 4.3.5 Known to work||4.4.2 4.5.0 Last reconfirmed|-00-00 00:00:00 |2010-09-01 12:41:33 date|| Summary|odd sized packed structures |[4.3 only] odd sized packed |passed by value, under ARM, |structures passed by value, |cause lockup of application |under ARM, cause lockup of ||application Target Milestone|--- |4.3.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37954
[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3
--- Comment #1 from ramana at gcc dot gnu dot org 2010-09-01 14:54 --- With r163667 and fixes for PR45444 applied I don't see issues with a v7-a bootstrap. Can we see if a later version works for you ? Ramana -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45445
[Bug bootstrap/45444] [4.6 regression] ARM bootstrap failure: uninitialized const member in 'neon_builtin_datum' is invalid in C++ [-Werror=c++-compat]
--- Comment #2 from ramana at gcc dot gnu dot org 2010-08-31 08:15 --- confirmed. I was working on fixing this but you beat my patch to it. cheers Ramana -- 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 |2010-08-31 08:15:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45444
[Bug rtl-optimization/45416] Code size regression between 4.6(4.5) and 4.4 for ARM
-- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Known to fail||4.5.0 4.5.1 Known to work||4.4.5 Last reconfirmed|-00-00 00:00:00 |2010-08-27 07:41:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45416
[Bug target/45094] [arm] wrong instructions for dword move in some cases
--- Comment #7 from ramana at gcc dot gnu dot org 2010-08-27 12:14 --- can this be backported to the 4.5 branch please ? -- ramana at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45094
[Bug target/45335] Use ldrd to load two consecutive words
-- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2010-08-23 08:23:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45335
[Bug target/43461] unsigned int var; (var 0xFF) not translated to uxtb insn in Thumb mode
--- Comment #4 from ramana at gcc dot gnu dot org 2010-08-23 14:31 ---
Trunk of a recent vintage generates -
@ frame_needed = 0, uses_anonymous_args = 0
push{r4, lr}
bl a
movwr4, #:lower16:b
movtr4, #:upper16:b
uxtbr0, r0
str r0, [r4, #0]
bl a
uxtbr0, r0
str r0, [r4, #0]
bl a
uxthr0, r0
str r0, [r4, #0]
bl a
uxthr0, r0
str r0, [r4, #0]
pop {r4, pc}
.size main, .-main
.ident GCC: (GNU) 4.6.0 20100823 (experimental) [trunk revision
163469]
This was fixed by the fix to PR44999. Hence fixed.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||FIXED
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43461
[Bug target/45070] Miscompiled c++ class with packed attribute on ARM with -Os optimizations (Qt 4.6.2)
--- Comment #14 from ramana at gcc dot gnu dot org 2010-08-19 08:28 --- Subject: Bug 45070 Author: ramana Date: Thu Aug 19 08:27:59 2010 New Revision: 163367 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163367 Log: For Ian Bolton ian.bol...@arm.com 2010-08-19 Ian Bolton ian.bol...@arm.com PR target/45070 * gcc.c-torture/execute/pr45070.c: New. * config/arm/arm.c (arm_output_epilogue): Ensure that return value of size 1-3 is handled correctly. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr45070.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45070
[Bug bootstrap/45321] [4.6 regression] ARM bootstrap failure due to stdarg_p change
-- 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 |2010-08-19 10:40:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45321
[Bug bootstrap/45177] [4.6 regression] cc1 runs out of memory building libgcc in ARM cross-compiler
--- Comment #7 from ramana at gcc dot gnu dot org 2010-08-10 22:17 --- Is this now fixed ? -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45177
[Bug c/45207] The -Os flag generates wrong code for ARM966e-s
--- Comment #5 from ramana at gcc dot gnu dot org 2010-08-06 09:13 --- If you don't give us a testcase we can't verify / see what's going wrong here. Please report bugs as described here. http://gcc.gnu.org/bugs/ . Thanks, Ramana -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45207
[Bug bootstrap/45162] [4.6 regression] ARM bootstrap comparison failures after stage 3
--- Comment #3 from ramana at gcc dot gnu dot org 2010-08-03 14:14 ---
Created an attachment (id=21375)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21375action=view)
testcase.
The difference is in the case with and without debug info. With the attached
pre-processed file and with and without -g you can see differences in code
generated between -g and no -g . The command line options I've used to generate
this code are in a cross-compiler.
-O2
and
-O2 -g
The difference in code generated in the case of debug info is with cprop
deciding to constant propagate a value of 0 into one of the instructions in the
case of with debug info and not without debug info.
We can see the difference in the case of tree-vect-data-refs.i with a cross
compiler to arm-linux-gnueabi with and without the command line options as
mentioned above.
Sorry about the largish testcase but I've not been able to reduce the testcase
further . The difference in code generation happens in
vect_analyze_data_ref_accesses - the one on the left is without debug and the
one on the right is the case with debug info for the same basic block.
.L947: .L947:
add ip, sp, #32 add ip, sp, #32
ldmia ip, {fp-ip} ldmia ip, {fp-ip}
ldr r4, [sp, #40]ldr r4, [sp, #40]
orrsip, fp, ip orrsip, fp, ip
moveq r0, #0
ldreq lr, [sp, #80]ldreq lr, [sp, #80]
streq r0, [sp, #36]
ldr r0, [r4, #4] ldr r0, [r4, #4]
streq lr, [sp, #32]streq lr, [sp, #32]
bl vinfo_for_stmt.isra.11 bl vinfo_for_stmt.isra.11
ldr r7, [sp, #32]ldr r7, [sp, #32]
str r7, [r0, #76] str r7, [r0, #76]
mov r0, #9 mov r0, #9
bl vect_print_dump_info bl vect_print_dump_info
cmp r0, #0 cmp r0, #0
bne .L1025 bne .L1025
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Attachment #21370|0 |1
is obsolete||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45162
[Bug tree-optimization/45144] SRA optimization issue of bit-field
-- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2010-08-02 07:54:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45144
[Bug middle-end/45098] Missed induction variable optimization
-- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2010-08-02 07:55:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45098
[Bug bootstrap/45162] [4.6 regression] ARM bootstrap comparison failures after stage 3
--- Comment #1 from ramana at gcc dot gnu dot org 2010-08-02 14:55 --- Confirmed. My bootstrap with thumb2 and armv7-a failed as well. Here's the configuration line . I only see a comparison failure with tree-vect-data-refs.o in this configuration. Configured with: /home/ramrad01/sources//trunk/configure --prefix=/home/ramrad01/install-nightlies/install-trunk-162814 --enable-languages=c,c++,fortran --enable-__cxa_atexit --disable-nls --enable-threads=posix --disable-multilib --with-arch=armv7-a --with-mode=thumb --with-float=softfp --with-fpu=vfpv3-d16 -- 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 |2010-08-02 14:55:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45162
[Bug bootstrap/45162] [4.6 regression] ARM bootstrap comparison failures after stage 3
--- Comment #2 from ramana at gcc dot gnu dot org 2010-08-02 14:58 --- Created an attachment (id=21370) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21370action=view) Disassembly and object files that are different with the thumb2 bootstrap Disassembly and object files in this case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45162
[Bug bootstrap/45138] [4.6 Regression] Bootstrap ICE on arm-linux: expected gimple_assign(error_mark), have gimple_nop() in gimple_assign_lhs, at gimple.h:1724
--- Comment #1 from ramana at gcc dot gnu dot org 2010-07-30 09:37 --- *** This bug has been marked as a duplicate of 45067 *** -- 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=45138
[Bug bootstrap/45067] [4.6 regression] ARM bootstrap failure: internal compiler error: in expand_widen_pattern_expr, at optabs.c:522
--- Comment #7 from ramana at gcc dot gnu dot org 2010-07-30 09:37 --- *** Bug 45138 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=45067
[Bug target/43698] [4.5/4.6 Regression] Wrong use of ARMv6 REV instruction for endian bytewapping with -Os or -O2 optimizations
--- Comment #17 from ramana at gcc dot gnu dot org 2010-07-30 22:36 ---
Subject: Bug 43698
Author: ramana
Date: Fri Jul 30 22:35:40 2010
New Revision: 162725
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162725
Log:
Backport fix for PR target/43698.
2010-07-30 Ramana Radhakrishnan ramana.radhakrish...@arm.com
Backport from mainline.
2010-07-22 Ramana Radhakrishnan ramana.radhakrish...@arm.com
PR target/43698
* config/arm/arm.md: Split arm_rev into *arm_rev and *thumb1_rev.
Set *arm_rev to be predicable.
2010-07-30 Ramana Radhakrishnan ramana.radhakrish...@arm.com
Backport from mainline
2010-07-22 Ramana Radhakrishnan ramana.radhakrish...@arm.com
PR target/43698
* gcc.target/arm/pr43698.c: New test.
Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.target/arm/pr43698.c
- copied unchanged from r162404,
trunk/gcc/testsuite/gcc.target/arm/pr43698.c
Modified:
branches/gcc-4_5-branch/ (props changed)
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/config/arm/arm.md
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
Propchange: branches/gcc-4_5-branch/
('svn:mergeinfo' added)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43698
[Bug target/43698] [4.5/4.6 Regression] Wrong use of ARMv6 REV instruction for endian bytewapping with -Os or -O2 optimizations
--- Comment #18 from ramana at gcc dot gnu dot org 2010-07-30 22:38 --- And hence fixed. Thanks for allowing the backport. Ramana -- 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=43698
[Bug c/45102] mm/page-writeback.c:820: internal compiler error: Segmentation fault
-- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45102
[Bug middle-end/45097] ICE: gimple check: expected gimple_assign(error_mark), have gimple_phi() in gimple_assign_lhs, at gimple.h:1724
--- Comment #2 from ramana at gcc dot gnu dot org 2010-07-28 08:03 --- I've been looking at this with respect to trunk bootstrapping on armv7a-linux platforms. http://gcc.gnu.org/ml/gcc-patches/2010-07/msg02102.html See if the patches in that trail fix your bug. -- 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 |2010-07-28 08:03:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45097
[Bug target/45070] Miscompiled c++ class with packed attribute on ARM with -Os optimizations (Qt 4.6.2)
--- Comment #7 from ramana at gcc dot gnu dot org 2010-07-28 09:01 --- Thanks for the analysis, yes that appears to be the nub of the problem with the result being removed . I see the same problem on trunk - Patches should however be submitted to gcc-patc...@gcc.gnu.org after appropriate regression testing. cheers Ramana -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail|4.5.0 |4.4.4 4.5.0 Last reconfirmed|-00-00 00:00:00 |2010-07-28 09:01:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45070
[Bug target/45070] Miscompiled c++ class with packed attribute on ARM with -Os optimizations (Qt 4.6.2)
--- Comment #8 from ramana at gcc dot gnu dot org 2010-07-28 09:22 --- (In reply to comment #7) Thanks for the analysis, yes that appears to be the nub of the problem with the result being removed . I see the same problem on trunk - I just realized that this is a packed structure and probably need to look up the semantics of this in the AAPCS. IIRC the AAPCS states that it doesn't support packed structures or bitfields at exported interfaces. Adding Richard for some ABI commentary. cheers Ramana -- ramana at gcc dot gnu dot org changed: What|Removed |Added CC||rearnsha at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45070
[Bug bootstrap/45067] [4.6 regression] ARM bootstrap failure: internal compiler error: in expand_widen_pattern_expr, at optabs.c:522
--- Comment #5 from ramana at gcc dot gnu dot org 2010-07-27 12:32 --- Patch posted here in response to the original thread. : http://gcc.gnu.org/ml/gcc-patches/2010-07/msg02076.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45067
[Bug target/45094] [arm] wrong instructions for dword move in some cases
--- Comment #1 from ramana at gcc dot gnu dot org 2010-07-27 12:47 --- Patches should be submitted to gcc-patc...@gcc.gnu.org after having been regression tested. Please also submit a testcase and appropriate Changelog entries as documented here - http://gcc.gnu.org/contribute.html#patches Having said that however, this patch looks alright to me from the naked eye and code inspection. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2010-07-27 12:47:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45094
[Bug bootstrap/44768] arm-linux bootstrap broken on expmed.c:157:3: warning ICE
--- Comment #8 from ramana at gcc dot gnu dot org 2010-07-27 13:37 --- Fixed. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44768
[Bug target/44290] [4.5 only] __naked attribute is broken
--- Comment #24 from ramana at gcc dot gnu dot org 2010-07-26 08:05 --- If this is fixed, the target milestone should be 4.6.0 and not 4.5.1 . I thought this was a regression on the 4.5 branch and given that the branch is now locked down for 4.5.1 the target milestone ought to be 4.5.2 and this patch should also be backported to the 4.5 branch. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | Summary|[4.5 Regression] __naked|[4.5 only] __naked attribute |attribute is broken |is broken http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44290
[Bug bootstrap/45067] [4.6 regression] ARM bootstrap failure: internal compiler error: in expand_widen_pattern_expr, at optabs.c:522
--- Comment #4 from ramana at gcc dot gnu dot org 2010-07-26 08:55 --- I see the same issue in my nightly armv7-a bootstrap. -- 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 |2010-07-26 08:55:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45067
[Bug target/43698] [4.5/4.6 Regression] Wrong use of ARMv6 REV instruction for endian bytewapping with -Os or -O2 optimizations
--- Comment #15 from ramana at gcc dot gnu dot org 2010-07-23 12:21 --- Patch can be backported and tested. But since 4.5 is frozen right now, needs RM permission. Adding RM to CC. cheers Ramana -- ramana at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43698
[Bug target/43698] [4.5/4.6 Regression] Wrong use of ARMv6 REV instruction for endian bytewapping with -Os or -O2 optimizations
--- Comment #13 from ramana at gcc dot gnu dot org 2010-07-22 08:31 --- Subject: Bug 43698 Author: ramana Date: Thu Jul 22 08:30:36 2010 New Revision: 162404 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162404 Log: Fix PR target/43698 2010-07-22 Ramana Radhakrishnan ramana.radhakrish...@arm.com PR target/43698 * config/arm/arm.md: Split arm_rev into *arm_rev and *thumb1_rev. Set *arm_rev to be predicable. 2010-07-22 Ramana Radhakrishnan ramana.radhakrish...@arm.com PR target/43698 * gcc.target/arm/pr43698.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/pr43698.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43698
[Bug target/45029] Buffer overflow in *push_multi pattern
--- Comment #2 from ramana at gcc dot gnu dot org 2010-07-22 14:37 --- Hi, Patches should be sent to gcc-patc...@gcc.gnu.org rather than put in bugzilla entries. Even though the number of registers is theoretically 16 you are never going to have num_saves = 16 . It's at the maximum going to be 14 (assuming the case that the base register is the lowest register in the list even though such use is deprecated, because you aren't going to be saving pc and sp in your prologue from the compiler ). BTW stmfd allows theoretically sp and PC in ARM state in the list of registers but such uses are deprecated and I don't think the compiler can even generate such code. In Thumb state this is just not allowed. Thus the total number of bytes should be 95 bytes (plugging in num_saves = 14) which gives us a 5 byte cushion. Ramana -- 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=45029
[Bug middle-end/44928] volatile globals illegally ignored on optimization levels 0
--- Comment #2 from ramana at gcc dot gnu dot org 2010-07-14 07:39 --- Please submit a fully pre-processed source for someone to look at this as per comment #2. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44928
[Bug target/44888] Stack pointer corruption within interrupt routine when compiled with -Os
--- Comment #1 from ramana at gcc dot gnu dot org 2010-07-12 09:35 --- Confirmed - I think it should be fixed by this patch here. http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00495.html Jie : do you think you could backport this to the 4.5 branch ? cheers Ramana -- ramana at gcc dot gnu dot org changed: What|Removed |Added CC||jiez at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.5.0 Known to work||4.4.4 4.6.0 Last reconfirmed|-00-00 00:00:00 |2010-07-12 09:35:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44888
[Bug target/44860] Thumb ICE due to spill failure
--- Comment #2 from ramana at gcc dot gnu dot org 2010-07-12 09:43 ---
Confirmed with Thumb1.
Just to be clear - command line options that cause the crash are :
./xgcc -B`pwd` -S -Os -mthumb -fno-omit-frame-pointer /tmp/t2ice.c
-march=armv5te
/tmp/t2ice.c: In function '__libc_recvfrom':
/tmp/t2ice.c:5:7: error: unable to find a register to spill in class 'LO_REGS'
/tmp/t2ice.c:5:7: error: this is the insn:
(insn 73 19 74 2 /tmp/t2ice.c:5 (set (reg:SI 12 ip [150])
(const_int 146 [0x92])) 167 {*thumb1_movsi_insn} (expr_list:REG_EQUAL
(const_int 146 [0x92])
(nil)))
/tmp/t2ice.c:5: confused by earlier errors, bailing out
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known to fail||4.5.0
Last reconfirmed|-00-00 00:00:00 |2010-07-12 09:43:13
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44860
[Bug tree-optimization/44886] New: Extra regressions in the vect testsuite with Neon.
: Likewise. * gcc.dg/vect/vect-reduc-dot-u16b.c: Likewise. * gcc.dg/vect/vect-strided-a-u32-mult.c: Likewise. * gcc.dg/vect/vect-strided-u32-mult.c: Likewise. * gcc.dg/vect/vect-widen-mult-s16.c: Likewise. * gcc.dg/vect/vect-widen-mult-s8.c: Likewise. * gcc.dg/vect/vect-widen-mult-sum.c: Likewise. * gcc.dg/vect/vect-widen-mult-u16.c: Likewise. 2010-07-06 Richard Guenther rguent...@suse.de PR middle-end/44828 * convert.c (convert_to_integer): Watch out for overflowing MULT_EXPR as well. * gcc.c-torture/execute/pr44828.c: New testcase. -- Summary: Extra regressions in the vect testsuite with Neon. Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ramana at gcc dot gnu dot org GCC build triplet: x86_64-linux GCC target triplet: arm-eabi, arm-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44886
[Bug bootstrap/44768] arm-linux bootstrap broken on expmed.c:157:3: warning ICE
--- Comment #7 from ramana at gcc dot gnu dot org 2010-07-09 16:19 --- Should be fixed by this commit. http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg00301.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44768
[Bug c/44853] can't find a register in class 'GENERAL_REGS' while reloading 'asm'
--- Comment #1 from ramana at gcc dot gnu dot org 2010-07-07 08:43 --- Can you reproduce this with GCC built using sources from http://gcc.gnu.org ? If not please report such issues to the vendors of your toolchain. If you can reproduce this with GCC built from FSF sources please let us know. Also give a better testcase which is consistent, complete and small, this is code with undefined behaviour, at the very best this is the Compiler ICE'ing on invalid code. All your local variables are uninitialized and they've been marked as input constraints to your asm. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44853
[Bug bootstrap/44768] arm-linux bootstrap broken on expmed.c:157:3: warning ICE
--- Comment #5 from ramana at gcc dot gnu dot org 2010-07-06 22:29 ---
The problem essentially is a miscompilation of diagnostic_action_after_output
in this case .
Attached is a testcase that demonstrates this problem with a cross compiler.
Configure just the compiler with arm-linux-gnueabi and you can see the
problem.
diagnostic_action_after_output.isra.1:
@ Volatile: function does not return. --- There we go ! Treating this
function as a NORETURN function when it clearly is *not* .
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
sub r1, r1, #2
stmfd sp!, {r3, lr} -- Not saved in the set of callee saved
registers ...
mov r4, r0 -- r4 is clobbered and is a callee saved register.
cmp r1, #7
ldrls pc, [pc, r1, asl #2]
b .L69
.L74:
.word .L70
.word .L71
.word .L72
.word .L72
.word .L68
.word .L68
.word .L68
.word .L68
.L72:
ldrbr3, [r0, #65] @ zero_extendqisi2
cmp r3, #0
From a session in gdb. As you can see the call to arm_compute_func_type is the
one that causes the problems here. arm_compute_func_type decides whether a
function is volatile or not depending on the value of TREE_THIS_VOLATILE for
current_function_decl. This allows the compiler to do optimizations that remove
the save of callee save registers in such volatile functions.
#0 arm_compute_func_type () at
/work/fsfwork/svn/trunk/gcc/config/arm/arm.c:1949
#1 0x0094a764 in arm_current_func_type () at
/work/fsfwork/svn/trunk/gcc/config/arm/arm.c:1993
#2 0x0094a787 in arm_allocate_stack_slots_for_args () at
/work/fsfwork/svn/trunk/gcc/config/arm/arm.c:2002
#3 0x0060da5e in use_register_for_decl (decl=0x2b5ae7029960) at
/work/fsfwork/svn/trunk/gcc/function.c:2015
#4 0x004e5251 in expand_one_var (var=0x2b5ae7029960, toplevel=1
'\001', really_expand=0 '\0') at /work/fsfwork/svn/trunk/gcc/cfgexpand.c:983
#5 0x004e5fcb in estimated_stack_frame_size () at
/work/fsfwork/svn/trunk/gcc/cfgexpand.c:1276
#6 0x0098d855 in compute_inline_parameters (node=0x2b5ae6f2cc18) at
/work/fsfwork/svn/trunk/gcc/ipa-inline.c:2022
#7 0x0080b631 in convert_callers (node=0x2b5ae6d89158,
old_decl=0x2b5ae6f1ff00, adjustments=0x4384680) at
/work/fsfwork/svn/trunk/gcc/tree-sra.c:4212
#8 0x0080b96c in modify_function (node=0x2b5ae6f2c560,
adjustments=0x4384680) at /work/fsfwork/svn/trunk/gcc/tree-sra.c:4276
#9 0x0080be6f in ipa_early_sra () at
/work/fsfwork/svn/trunk/gcc/tree-sra.c:4395
#10 0x006ca396 in execute_one_pass (pass=0x1118480) at
/work/fsfwork/svn/trunk/gcc/passes.c:1565
#11 0x006ca4ec in execute_pass_list (pass=0x1118480) at
/work/fsfwork/svn/trunk/gcc/passes.c:1620
#12 0x006ca505 in execute_pass_list (pass=0x11181e0) at
/work/fsfwork/svn/trunk/gcc/passes.c:1621
#13 0x006c998b in do_per_function_toporder (callback=0x6ca4d0
execute_pass_list, data=0x11180c0) at
/work/fsfwork/svn/trunk/gcc/passes.c:1158
#14 0x006cad17 in execute_ipa_pass_list (pass=0x1118240) at
/work/fsfwork/svn/trunk/gcc/passes.c:1920
#15 0x00982269 in cgraph_optimize () at
/work/fsfwork/svn/trunk/gcc/cgraphunit.c:1851
#16 0x009824ea in cgraph_finalize_compilation_unit () at
/work/fsfwork/svn/trunk/gcc/cgraphunit.c:1171
#17 0x00418b34 in c_write_global_declarations () at
/work/fsfwork/svn/trunk/gcc/c-decl.c:9698
#18 0x0076ee64 in toplev_main (argc=4, argv=0x7fffc3eda328) at
/work/fsfwork/svn/trunk/gcc/toplev.c:997
(gdb) p current_function_name ()
$3 = 0x2b5ae7024bb8 diagnostic_action_after_output.isra.1
(gdb) p current_function_decl
$4 = (tree) 0x2b5ae6f1fe00
(gdb) pct
error_recursion
(gdb) p cfun-decl
$5 = (tree) 0x2b5ae703c500
(gdb) pct
diagnostic_action_after_output.isra.1
Notice that cfun-decl and current_function_decl are different here because the
context hasn't been set up correctly in tree-sra.c . The following patch
appears to fix it by correctly not setting the function to be non-volatile.
Index: tree-sra.c
===
--- tree-sra.c (revision 161870)
+++ tree-sra.c (working copy)
@@ -4209,8 +4209,11 @@ convert_callers (struct cgraph_node *nod
for (cs = node-callers; cs; cs = cs-next_caller)
if (!bitmap_bit_p (recomputed_callers, cs-caller-uid))
{
+ current_function_decl = cs-caller-decl;
+ push_cfun (DECL_STRUCT_FUNCTION (cs-caller-decl));
compute_inline_parameters (cs-caller);
bitmap_set_bit (recomputed_callers, cs-caller-uid);
+ pop_cfun ();
}
BITMAP_FREE (recomputed_callers);
After the patch was applied on a cross-compiler
diagnostic_action_after_output.isra.1:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
[Bug bootstrap/44768] arm-linux bootstrap broken on expmed.c:157:3: warning ICE
--- Comment #6 from ramana at gcc dot gnu dot org 2010-07-06 22:39 --- Created an attachment (id=21116) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21116action=view) Actual testcase . Attached testcase. Configure cross compiler with --target=arm-eabi or --target=arm-linux-gnueabi and --enable-languages=c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44768
[Bug target/43703] Unexpected floating point precision loss due to ARM NEON autovectorization
--- Comment #8 from ramana at gcc dot gnu dot org 2010-07-05 12:22 --- Are you planning to backport this to all release branches since this affects all of them ? cheers Ramana -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43703
[Bug tree-optimization/44328] switch/case optimization produces an invalid lookup table index
--- Comment #22 from ramana at gcc dot gnu dot org 2010-07-05 13:43 ---
With trunk as of a couple of days back - the testcase when compiled with
-mcpu=cortex-a9 -mfpu=neon -mfloat-abi=softfp for EABI generates the following
code for C++ but not for C.
Notice the removal of the check of the condition for being out of range
Z9open_filePKc8OpenMode:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
stmfd sp!, {r3, lr}
ldr r3, .L2
ldr r1, [r3, r1, asl #2]
bl open
ldmfd sp!, {r3, lr}
bx lr
.L3:
.align 2
.L2:
.word .LANCHOR0
.size _Z9open_filePKc8OpenMode, .-_Z9open_filePKc8OpenMode
.section.rodata
.align 2
.set.LANCHOR0,. + 0
.type CSWTCH.1, %object
.size CSWTCH.1, 16
CSWTCH.1:
.word 1
.word 74
.word 3
.word 75
.ident GCC: (GNU) 4.6.0 20100702 (experimental)
Same file compiled in C.
open_file:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
cmp r1, #3
stmfd sp!, {r3, lr}
ldrls r3, .L4
movhi r1, #0
ldrls r1, [r3, r1, asl #2]
bl open
ldmfd sp!, {r3, lr}
bx lr
.L5:
.align 2
.L4:
.word .LANCHOR0
.size open_file, .-open_file
.section.rodata
.align 2
.set.LANCHOR0,. + 0
.type CSWTCH.1, %object
.size CSWTCH.1, 16
CSWTCH.1:
.word 1
.word 74
.word 3
.word 75
.ident GCC: (GNU) 4.6.0 20100702 (experimental)
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|c++ |tree-optimization
Ever Confirmed|0 |1
Known to fail||4.6.0
Last reconfirmed|-00-00 00:00:00 |2010-07-05 13:43:01
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328
[Bug bootstrap/44768] arm-linux bootstrap broken on expmed.c:157:3: warning ICE
--- Comment #4 from ramana at gcc dot gnu dot org 2010-07-02 16:15 --- I'm getting this failure in stage3 thus just attaching the expmed.i pre-processed file isn't enough to reproduce this with a cross. Doing a bisect I find that rev: 160827 - builds expmed.o in stage3 . rev: 160833 - Segfaults while building expmed.o rev:160832 was this commit . Author: jamborm jamb...@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Wed Jun 16 12:21:56 2010 + 2010-06-16 Martin Jambor mjam...@suse.cz PR tree-optimization/43905 * tree-sra.c: Include tree-inline.h. (create_abstract_origin): Removed. (modify_function): Version the call graph node instead of creating abstract origins and dealing with same_body aliases. * tree-sra.c (ipa_sra_preliminary_function_checks): Check whether the function is versionable. * Makefile.in (tree-sra.o): Add TREE_INLINE_H to dependencies. * testsuite/g++.dg/torture/pr43905.C: New test. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/tr...@160832 while 160833 touches only libstdc++ I think there is a case of memory corruption or miscompilation somewhere because of which global_dc-printer changes value between 2 calls to diagnostic_report_diagnostic. Still digging to find out what's gone wrong here - might well be a latent bug exposed from elsewhere. Cheers Ramana -- ramana at gcc dot gnu dot org changed: What|Removed |Added CC||jamborm at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44768
[Bug rtl-optimization/44787] [regression]internal compiler error: in reload_cse_simplify_operands, at postreload.c:395
--- Comment #2 from ramana at gcc dot gnu dot org 2010-07-03 00:01 --- I haven't verified the actual revision failing but I do see this failing as of trunk today with an eabi compiler and all the options specified. -- ramana at gcc dot gnu dot org changed: What|Removed |Added CC||bernds at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail||4.6.0 Last reconfirmed|-00-00 00:00:00 |2010-07-03 00:01:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44787
[Bug target/44626] [4.4 regression] ICE in output_operand: invalid expression as operand
--- Comment #4 from ramana at gcc dot gnu dot org 2010-07-03 00:03 --- Can this patch be submitted to gcc-patc...@gcc.gnu.org after due testing ? -- 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 |2010-07-03 00:03:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44626
[Bug target/44278] Use ubfx to extract unsigned bit fields at the low end
-- ramana at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2010-07-03 00:07:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44278
[Bug lto/44378] lto1: internal compiler error: in cgraph_mark_functions_to_output, at cgraphunit.c:1168
--- Comment #2 from ramana at gcc dot gnu dot org 2010-07-03 00:10 --- Waiting for feedback as per comments in Comment #1 -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44378
[Bug target/43961] [ARM thumb] branch out of range with thumb1_output_casesi
--- Comment #7 from ramana at gcc dot gnu dot org 2010-07-03 00:21 --- *** Bug 44603 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43961
[Bug target/44603] out of range branch generated in thumb code.
--- Comment #5 from ramana at gcc dot gnu dot org 2010-07-03 00:21 --- *** This bug has been marked as a duplicate of 43961 *** -- 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=44603
[Bug rtl-optimization/44675] Inefficient code to return a large struct
-- 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 |2010-07-03 00:23:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44675
[Bug target/44392] [4.5/4.6 Regression] libgcc compile with --enable-target-optspace (-Os) causes recursion in __bswapsi2
-- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2010-06-22 00:46:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44392
[Bug target/44392] [4.5/4.6 Regression] libgcc compile with --enable-target-optspace (-Os) causes recursion in __bswapsi2
--- Comment #5 from ramana at gcc dot gnu dot org 2010-06-22 00:51 ---
Khem,
Can you check if this fixes your problem ? Feel free to submit this to
gcc-patches@ if you get around to testing this before me.
Ramana
diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index 628bd62..9dcceea 100644
--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -11296,7 +11296,7 @@
(define_expand bswapsi2
[(set (match_operand:SI 0 s_register_operand =r)
(bswap:SI (match_operand:SI 1 s_register_operand r)))]
-TARGET_EITHER
+TARGET_EITHER (arm_arch6 || ( !arm_arch6 !optimize_size))
if (!arm_arch6)
{
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44392
[Bug target/44227] Invalid instruction generation in Thumb2 for tst instruction.
--- Comment #3 from ramana at gcc dot gnu dot org 2010-05-26 08:50 --- Yes - confirmed fixed with the reduced testcase. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44227
[Bug target/44227] New: Invalid instruction generation in Thumb2 for tst instruction.
CSiBe builds broke because of this change here to fix PR42879. http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00263.html Attached is a reduced testcase that shows the problem. The problem appears to be due to incorrect generation of the tst instruction as a result of the pattern added where the tst instruction appears to be generating a tst with 32767 which is an invalid immediate for the tst instruction in Thumb2 state. Carrot, can you look at this further ? Ramana -- Summary: Invalid instruction generation in Thumb2 for tst instruction. Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ramana at gcc dot gnu dot org GCC host triplet: X86_64-linux-gnu GCC target triplet: arm-eabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44227
[Bug target/44227] Invalid instruction generation in Thumb2 for tst instruction.
--- Comment #1 from ramana at gcc dot gnu dot org 2010-05-21 10:38 --- Created an attachment (id=20718) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20718action=view) testcase Testcase - Compile and assemble with -mcpu=cortex-a8 -mthumb -O3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44227
[Bug target/43988] unnecessary memory store
--- Comment #1 from ramana at gcc dot gnu dot org 2010-05-13 10:08 --- Confirmed . I think this is a result of DSE not being able to remove this because the prologue rtx pattern doesn't show the writes of the actual registers. Ramana -- ramana at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-13 10:08:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43988
[Bug target/44072] Use 'add r0, 1' to replace 'cmp r0, -1' in thumb2
-- ramana at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2010-05-11 07:31:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44072
[Bug target/43725] Poor instructions selection, scheduling and registers allocation for ARM NEON intrinsics
-- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2010-05-11 07:35:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43725
[Bug target/43927] genautomata: undeclared unit or reservation `cortex_a9_}ult'
--- Comment #1 from ramana at gcc dot gnu dot org 2010-05-11 07:37 --- Is this still an issue ? My armv5te box was bootstrapping without the issue you mention in cortex-a9.md and there is a test result from an armv5te-linux-eabi variant here. http://gcc.gnu.org/ml/gcc-testresults/2010-05/msg00953.html cheers Ramana -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43927
[Bug c/43999] Gcc (lib1funcs.asm) doesn't build on ARM/Thumb2
--- Comment #2 from ramana at gcc dot gnu dot org 2010-05-11 09:28 --- How did you configure your tools in ? Have you considered using the --with-cpu and --with-mode options while building your tools i.e. --with-cpu=cortex-m3 --with-mode=thumb. Ramana -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43999
[Bug debug/38479] Incorrect dwarf generated for function with parameters greater 4 words in length
-- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet|arm-unknown-elf |arm-unknown-elf, arm-eabi Last reconfirmed|-00-00 00:00:00 |2010-05-12 01:31:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38479
[Bug target/43961] [ARM thumb] branch out of range with thumb1_output_casesi
--- Comment #4 from ramana at gcc dot gnu dot org 2010-05-10 16:03 --- Confirmed - marking as a target bug . -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c |target Ever Confirmed|0 |1 GCC target triplet|arm-elf |arm-elf,arm-eabi Known to fail||4.6.0 Last reconfirmed|-00-00 00:00:00 |2010-05-10 16:03:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43961
[Bug other/43944] libgcc2 fails to build in gcc 4.5.0
--- Comment #1 from ramana at gcc dot gnu dot org 2010-04-30 00:31 --- (In reply to comment #0) Here is the concerning part of the log. In all-stageprofile-target-libgcc: building _moddi3.o ... ../../../gcc-4.5.0/libgcc/../gcc/libgcc2.c: In function '__moddi3': ../../../gcc-4.5.0/libgcc/../gcc/libgcc2.c:1103:1: error: total size of local objects too large The same kind of configuration built properly with gcc 4.4.3 Err, so what is the configuration and what are you trying to do ? It sounds like you are trying to do a profiled bootstrap. Is that the case ? Please file a bug with the information as in http://gcc.gnu.org/bugs/#report Ramana -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43944
[Bug target/43920] Choosing conditional execution over conditional branches for code size in some cases.
--- Comment #3 from ramana at gcc dot gnu dot org 2010-04-28 09:55 --- Confirmed though it isn't as simple as an expand time problem alone. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Known to fail||4.5.0 Last reconfirmed|-00-00 00:00:00 |2010-04-28 09:55:09 date|| Summary|A lot of instructions for |Choosing conditional |condition (start == -1 || |execution over conditional |end == -1) |branches for code size in ||some cases. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43920
[Bug target/43862] GCC doesn't use 16-bit armv5te multiplies when possible
--- Comment #2 from ramana at gcc dot gnu dot org 2010-04-28 10:06 --- * I don't see why smulbb, smultb, smulbt, smultt shouldn't be generated for their respective cases. So, yes that's correct. * smulwy is not supported in the backend, so that's a feature enhancement * smlawy is again not supported in the backend and anyone implementing this should note that overflow in the accumulate step is a part of the saturated Q bit. Also it isn't correct to be generating smlawy in the cases mentioned there. * smlaxy is something that could be generated in a few of the occasions but the PCS defeats us in these circumstances because we assume that the values passed in are appropriately zero /sign extended. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Known to fail||4.5.0 Last reconfirmed|-00-00 00:00:00 |2010-04-28 10:06:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43862
[Bug rtl-optimization/43908] [4.5 only] Unnecessary conditionals
--- Comment #1 from ramana at gcc dot gnu dot org 2010-04-28 10:10 --- On trunk I don't see the movne / moveq problem but the extra mov r3, #1 could be removed. (I think one of Bernd's recent fixes to ifcvt.c fixed these issues). tst r1, #1 mov r3, #1 streq r3, [r0, #4] strne r3, [r0, #0] tst r1, #2 mov r3, #1 streq r3, [r0, #4] strne r3, [r0, #0] tst r1, #4 mov r3, #1 streq r3, [r0, #4] strne r3, [r0, #0] tst r1, #8 mov r3, #1 streq r3, [r0, #4] strne r3, [r0, #0] tst r1, #16 mov r3, #1 streq r3, [r0, #4] strne r3, [r0, #0] tst r1, #32 mov r3, #1 streq r3, [r0, #4] strne r3, [r0, #0] tst r1, #64 mov r3, #1 streq r3, [r0, #4] strne r3, [r0, #0] tst r1, #128 mov r3, #1 strne r3, [r0, #0] streq r3, [r0, #4] bx lr -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Known to fail||4.5.0 Last reconfirmed|-00-00 00:00:00 |2010-04-28 10:10:19 date|| Summary|Very poor code generation |[4.5 only] Unnecessary |(unnecessary conditionals |conditionals |and reloads) for ARM| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43908
[Bug libgomp/39098] FAIL: libgomp.fortran/reduction3.f90
--- Comment #4 from ramana at gcc dot gnu dot org 2010-04-28 10:38 --- (In reply to comment #3) Subject: Re: FAIL: libgomp.fortran/reduction3.f90 Does it work without -fopenmp? Yes. Dave Does this still fail ? Recent testresults don't show this failure in libgomp. Ramana -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39098
[Bug target/43216] Use high registers to reduce code size and improve performance when targeting thumb2
--- Comment #6 from ramana at gcc dot gnu dot org 2010-04-26 08:47 --- Fixed now. -- 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=43216
[Bug target/43814] gcc failed to inline memcpy
-- ramana at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Known to fail||4.4.3 4.5.0 Last reconfirmed|-00-00 00:00:00 |2010-04-20 13:06:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43814
[Bug tree-optimization/43572] [4.5 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers
--- Comment #24 from ramana at gcc dot gnu dot org 2010-04-19 09:06 --- (In reply to comment #23) Fixed for 4.6, if you confirm the patch for the branch tested ok I'll apply that there. The patch works fine on the 4.5 branch with arm-linux-gnueabi. A bootstrap with --with-cpu=cortex-a9 --with-fpu=vfpv3-d16 --with-float=softfp succeeds and the number of fortran testfailures drops down nicely from 721 to just 1. No regressions in libstdc++ or g++. There are some extra guality failures but there have been quite a few for a while on this board and I need to check with a newer gdb on that board to see what's going on. Hence I'd say this is good to go. cheers Ramana -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572
[Bug target/43216] Use high registers to reduce code size and improve performance when targeting thumb2
--- Comment #4 from ramana at gcc dot gnu dot org 2010-04-17 15:32 --- I think this should now be fixed by http://gcc.gnu.org/viewcvs?root=gccview=revrev=158378 Carrot , can you confirm you are happy with the code generated on trunk now ? cheers Ramana -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43216
[Bug tree-optimization/43572] [4.5/4.6 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers
--- Comment #18 from ramana at gcc dot gnu dot org 2010-04-16 07:46 --- Looking at more dumps this morning with the testcase and you can see that in the not working case all the tmp variables aren't marked as being call-clobbered. Alias information for set_integer Aliased symbols tmp, UID D.1276, GFC_INTEGER_8, is addressable tmp, UID D.1279, GFC_INTEGER_4, is addressable .MEM, UID D.2024, void, is global, call clobbered, default def: .MEM_11(D) tmp, UID D.1281, GFC_INTEGER_2, is addressable tmp, UID D.1283, GFC_INTEGER_1, is addressable whereas in the case that it was working - Alias information for set_integer Aliased symbols tmp, UID D.1276, GFC_INTEGER_8, is addressable, call clobbered tmp, UID D.1279, GFC_INTEGER_4, is addressable, call clobbered .MEM, UID D.2024, void, is global, call clobbered, default def: .MEM_11(D) tmp, UID D.1281, GFC_INTEGER_2, is addressable, call clobbered tmp, UID D.1283, GFC_INTEGER_1, is addressable, call clobbered -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572
[Bug target/43723] Some ARMs support unaligned
--- Comment #1 from ramana at gcc dot gnu dot org 2010-04-15 09:13 --- It should be safe for GCC to generate unaligned accesses for newer cores that support this. cheers Ramana -- ramana at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Known to fail||4.4.3 4.5.0 Last reconfirmed|-00-00 00:00:00 |2010-04-15 09:13:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43723
[Bug target/43724] GCC produces suboptimal ARM NEON code for zero vector assignment
--- Comment #2 from ramana at gcc dot gnu dot org 2010-04-15 09:17 --- Confirmed. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-15 09:17:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43724
[Bug target/43722] [4.4 only] ICE when passing NEON registers using const refrences
--- Comment #8 from ramana at gcc dot gnu dot org 2010-04-15 09:39 --- Could you submit the patch to gcc-patches@ ? If you need some help in testing this patch let me know and I can do it for you. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail||4.4.3 Last reconfirmed|-00-00 00:00:00 |2010-04-15 09:39:24 date|| Summary|ICE when passing NEON |[4.4 only] ICE when passing |registers using const |NEON registers using const |refrences |refrences Target Milestone|--- |4.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43722
[Bug libfortran/43572] [4.5/4.6 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers
--- Comment #17 from ramana at gcc dot gnu dot org 2010-04-15 18:39 ---
Created an attachment (id=20389)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20389action=view)
Testcase for the problem.
Can this bug be reprioritized ?
Deep inside _gfortrani_set_integer, there's an incorrect sibling call to memcpy
where it shouldn't be doing so.
64: e28d1010add r1, sp, #16
68: e3a02004mov r2, #4
6c: e521c008str ip, [r1, #-8]!
70: e28dd014add sp, sp, #20
74: e49de004pop {lr}; (ldr lr, [sp], #4)
78: eafeb 0 memcpy
78: R_ARM_PLT32 memcpy
There's no reason why this should be being marked as a valid tail call here.
From the tailcall dumps.
set_integer (void * dest, GFC_INTEGER_8 value, int length)
{
GFC_INTEGER_1 tmp;
GFC_INTEGER_2 tmp;
GFC_INTEGER_4 tmp;
GFC_INTEGER_8 tmp;
GFC_INTEGER_1 tmp.30;
GFC_INTEGER_2 tmp.29;
GFC_INTEGER_4 tmp.28;
size_t length.27;
bb 2:
switch (length_1(D)) default: L4, case 1: L3, case 2: L2, case 4:
L1, case 8: L0
L0:
tmp = value_2(D);
memcpy (dest_4(D), tmp, 8); [tail call]
goto bb 8;
L1:
tmp.28_5 = (GFC_INTEGER_4) value_2(D);
tmp = tmp.28_5;
memcpy (dest_4(D), tmp, 4); [tail call]
goto bb 8;
L2:
tmp.29_7 = (GFC_INTEGER_2) value_2(D);
tmp = tmp.29_7;
memcpy (dest_4(D), tmp, 2); [tail call]
goto bb 8;
L3:
tmp.30_9 = (GFC_INTEGER_1) value_2(D);
tmp = tmp.30_9;
memcpy (dest_4(D), tmp, 1); [tail call]
goto bb 8;
L4:
internal_error (0B, Bad integer kind[0]);
bb 8:
return;
}
Attached is a testcase for this . Reproducible by building a cross-compiler to
arm-eabi .
../trunk/configure --with-cpu=cortex-a8 --target=arm-none-eabi
--enable-languages=c
And command line options for the testcase are just -O2.
You can reproduce this problem with r149170 and the fix up patch applied as
well.
cheers
Ramana
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572
[Bug target/43698] [4.5/4.6 Regression] Invalid code when building gentoo pax-utils-0.1.19 with -Os optimizations
--- Comment #7 from ramana at gcc dot gnu dot org 2010-04-12 08:38 --- Patch submitted here. http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00401.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43698
[Bug target/43703] Unexpected floating point precision loss due to ARM NEON autovectorization
--- Comment #3 from ramana at gcc dot gnu dot org 2010-04-12 09:17 --- Could you post a cleaned-up testcase ? I tried a cleaned up testcase with the values appropriately zero-initialized and gcc ends up generating the vectorized value in this case. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Known to fail||4.4.3 4.5.0 Last reconfirmed|-00-00 00:00:00 |2010-04-12 09:17:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43703
[Bug libfortran/43572] [4.5/4.6 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers
--- Comment #12 from ramana at gcc dot gnu dot org 2010-04-12 15:50 --- A git bisect between the ranges suggested by Dave in Comment #6, gave me r149470 this as the first broken commit using a cross-compiler to arm-linux-gnueabi with qemu as the simulator . 2009-07-02 Richard Guenther rguent...@suse.de * tree-ssa-live.c (remove_unused_locals): Do not remove heap variables. * tree-ssa-structalias.c (handle_lhs_call): Delay setting of DECL_EXTERNAL for HEAP variables. (compute_points_to_sets): Set DECL_EXTERNAL for escaped HEAP variables. Do not adjust RESTRICT vars. (find_what_var_points_to): Nobody cares if something points to READONLY. My tools were configured as /home/ramrad01/cross-build/src/gcc-trunk/configure --target=arm-none-linux-gnueabi --enable-languages=c,c++,fortran --with-cpu=cortex-a8 --with-fpu=vfp3 --with-float=softfp In the middle of debugging further now to get to a reduced testcase given that the failure is a miscompile somewhere deep inside libgfortran. -- ramana at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572
[Bug libfortran/43572] [4.5/4.6 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers
--- Comment #15 from ramana at gcc dot gnu dot org 2010-04-12 17:21 --- (In reply to comment #12) A git bisect between the ranges suggested by Dave in Comment #6, gave me r149470 this as the first broken commit using a cross-compiler to arm-linux-gnueabi with qemu as the simulator . Sigh, that should read 149170. I don't think this is it. r149263 is bad and r149105 is ok. http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg00659.html http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg00989.html Will try and debug some more given what Richi said earlier. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572
[Bug libfortran/43572] [4.5/4.6 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers
--- Comment #11 from ramana at gcc dot gnu dot org 2010-04-10 08:45 --- I can pretty much see this on a v7 arm-linux-gnueabi target with 157994 (i.e. using a libgfortran from my 4.5 tree, causes this test to fail and using the system libgfortran things just work). On this target peeking at the values using gdb . I see that as soon as gfortran_transfer_array is completed the value in i is this random number. Don't know enough yet about libgfortran to figure out where the miscompile is happening. Digging. GNU gdb (GDB) 7.0.90.20100309-ubuntu Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as arm-linux-gnueabi. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /tmp/a.out...done. (gdb) b _gfortran_transfer_array Breakpoint 1 at 0x8508 (gdb) r Starting program: /tmp/a.out Breakpoint 1, *_gfortran_transfer_array (dtp=0xbef2ae60, desc=0xbef2afd8, kind=4, charlen=0) at /home/ramrad01/trunk/libgfortran/io/transfer.c:1863 1863 if ((dtp-common.flags IOPARM_LIBRETURN_MASK) != IOPARM_LIBRETURN_OK) (gdb) finish Run till exit from #0 *_gfortran_transfer_array (dtp=0xbef2ae60, desc=0xbef2afd8, kind=4, charlen=0) at /home/ramrad01/trunk/libgfortran/io/transfer.c:1863 0x8878 in MAIN__ () at /home/ramrad01/trunk/gcc/testsuite/gfortran.dg/PR19872.f:13 13read(1,*)i (gdb) p i $1 = (2147483647, 2147483647, 2147483647, 2147483647) -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P4 |P3 Last reconfirmed|-00-00 00:00:00 |2010-04-10 08:45:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572
[Bug target/43698] Invalid code when building gentoo pax-utils-0.1.19 with -Os optimizations
--- Comment #3 from ramana at gcc dot gnu dot org 2010-04-09 07:02 --- I can see the same failure on 4.5 branch with the testcase. The flags I used on the command line were -mcpu=cortex-a8 -Os . cheers Ramana -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet|armv7l-unknown-linux-gnueabi|armv7l-unknown-linux- ||gnueabi, Known to fail||4.5.0 Last reconfirmed|-00-00 00:00:00 |2010-04-09 07:02:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43698
[Bug target/43698] Invalid code when building gentoo pax-utils-0.1.19 with -Os optimizations
--- Comment #4 from ramana at gcc dot gnu dot org 2010-04-09 07:38 ---
It appears as though there's a latent bug in arm_ccfsm_state_machine. If you
mark this correctly as being predicable which the rev insn is - the bug goes
away.
If arm_final_prescan_insn sees something of the following form, it goes ahead
and assumes it can convert the rev in this pattern into a condexec and removes
the branch.
(jump_insn:TI 12 15 19 /tmp/bitswap.c:23 (set (pc)
(if_then_else (eq (reg:CC 24 cc)
(const_int 0 [0x0]))
(label_ref:SI 23)
(pc))) 228 {*arm_cond_branch} (expr_list:REG_DEAD (reg:CC 24 cc)
(expr_list:REG_BR_PROB (const_int 3900 [0xf3c])
(nil)))
- 23)
(note 19 12 21 [bb 3] NOTE_INSN_BASIC_BLOCK)
(insn:TI 21 19 22 /tmp/bitswap.c:23 (set (reg:SI 2 r2 [orig:141 D.4313 ] [141])
(bswap:SI (reg:SI 2 r2 [152]))) 347 {arm_rev} (nil))
(insn:TI 22 21 23 /tmp/bitswap.c:23 (set (reg/v:DI 2 r2 [orig:133 __res ]
[133])
(zero_extend:DI (reg:SI 2 r2 [orig:141 D.4313 ] [141]))) 138
{*arm_zero_extendsidi2} (expr_list:REG_UNUSED (reg:SI 3 r3)
(nil)))
The patch below which I'm testing, fixes the immediate problem with rev as
below. Longer term we ought to remove the ccfsm_state_machine once we fix the
problem with conditional calls.
Index: arm.md
===
--- arm.md (revision 158138)
+++ arm.md (working copy)
@@ -11201,8 +11201,9 @@
[(set (match_operand:SI 0 s_register_operand =r)
(bswap:SI (match_operand:SI 1 s_register_operand r)))]
TARGET_EITHER arm_arch6
- rev\t%0, %1
- [(set (attr length)
+ rev%?\t%0, %1
+ [(set_attr predicable yes)
+ (set (attr length)
(if_then_else (eq_attr is_thumb yes)
(const_int 2)
(const_int 4)))]
Ramana
--
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|2010-04-09 07:02:26 |2010-04-09 07:38:25
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43698
[Bug target/43698] Invalid code when building gentoo pax-utils-0.1.19 with -Os optimizations
--- Comment #5 from ramana at gcc dot gnu dot org 2010-04-09 07:48 --- Actually strike out the last patch - that's just wrong for Thumb1. This is what I am testing currently. Index: arm.md === --- arm.md (revision 158138) +++ arm.md (working copy) @@ -11200,12 +11200,18 @@ (define_insn arm_rev [(set (match_operand:SI 0 s_register_operand =r) (bswap:SI (match_operand:SI 1 s_register_operand r)))] - TARGET_EITHER arm_arch6 + TARGET_32BIT arm_arch6 + rev%?\t%0, %1 + [(set_attr predicable yes) + (set_attr length 4)] +) + +(define_insn thumb1_rev + [(set (match_operand:SI 0 s_register_operand =l) + (bswap:SI (match_operand:SI 1 s_register_operand l)))] + TARGET_THUMB1 arm_arch6 rev\t%0, %1 - [(set (attr length) -(if_then_else (eq_attr is_thumb yes) - (const_int 2) - (const_int 4)))] + [(set_attr length 2)] ) (define_expand arm_legacy_rev -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43698
[Bug target/43590] ICE in spill_failure, at reload1.c:2158
--- Comment #1 from ramana at gcc dot gnu dot org 2010-04-08 22:13 --- Hmm - so why is it that we add an initialization for reg:XI 136 with a const_int 0 in .175r.init_regs adding initialization in test of reg 136 at in block 3 for insn 12. (insn 91 11 12 3 /tmp/n.c:13 (set (reg:XI 136 [ D.3722 ]) (const_int 0 [0x0])) -1 (nil)) There's something fundamentally funny going on here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43590
