[Bug driver/27237] gcc driver should pass -mthumb option to arm assembler
--- Comment #1 from rearnsha at gcc dot gnu dot org 2006-04-21 08:27 --- There's no need to pass -mthumb to the assembler. If the compiler has emitted thumb code it will have inserted a suitable directive into the assembly file that will cause the assembler to act accordingly. -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27237
[Bug target/27263] armv5te-linux-gnueabi-gcc-4.1 fails to compile libquicktime-0.9.7-0.4/plugins/opendivx/encore50/text_code_mb.c
--- Comment #1 from rearnsha at gcc dot gnu dot org 2006-04-24 12:49 --- The testcase doesn't compile. Please attach a full, *compilable*, example of the program that shows the bug. -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27263
[Bug target/27263] armv5te-linux-gnueabi-gcc-4.1 fails to compile libquicktime-0.9.7-0.4/plugins/opendivx/encore50/text_code_mb.c
--- Comment #6 from rearnsha at gcc dot gnu dot org 2006-04-24 14:26
---
Confirmed. Also appears on trunk on an arm-elf cross with the flags:
-O3 -funroll-all-loops -fomit-frame-pointer -mno-apcs-frame -finline-functions
-mfpu=vfp -mfloat-abi=softfp -mcpu=arm926ej-s
We are generating an invalid input reload for
(insn:HI 320 4403 4405 391 (set (mem/s:HI (plus:SI (reg:SI 318 [ ivtmp.1515 ])
(reg/f:SI 1731)) [2 tmp S2 A16])
(subreg:HI (reg:SI 523) 0)) 152 {*movhi_insn_arch4}
(insn_list:REG_DEP_TRUE 319 (nil))
(expr_list:REG_DEAD (reg:SI 523)
(nil)))
Specifically, reload 2 contains:
Reload 2: reload_in (HI) = (mem:HI (plus:SI (mult:SI (reg:SI 11 fp [orig:318
ivtmp.1515 ] [318])
(const_int 2
[0x2]))
(reg/v/f:SI 10 sl
[orig:437 rcoeff_ind ] [437])) [4 S4 A32])
GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 1), can't combine
reload_in_reg: (subreg:HI (reg:SI 523) 0)
reload_reg_rtx: (reg:HI 6 r6)
but that's an invalid memory address for HImode.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
CC| |rearnsha at gcc dot gnu dot
| |org
Status|WAITING |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-04-24 14:26:03
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27263
[Bug bootstrap/27644] New: [4.1 regression] Bootstrap failure on native ARM targets
This patch:
2006-05-16 H.J. Lu <[EMAIL PROTECTED]>
* Makefile.in (GCC_OBJS): Replace options.o with gcc-options.o.
(gcc-options.o): New rule.
* optc-gen.awk: Protect variables for gcc-options.o with
#ifdef GCC_DRIVER/#endif.
is causing bootstrap failures:
gcc -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-format-attribute-DHAVE_CONFIG_H -o cc1-dummy c-lang.o
stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o
c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o
c-incpath.o cppdefault.o c-ppoutput.o c-cppbuiltin.o prefix.o c-objc-common.o
c-dump.o c-pch.o c-parser.o c-gimplify.o tree-mudflap.o c-pretty-print.o
dummy-checksum.o \
main.o libbackend.a ../libcpp/libcpp.a ../libcpp/libcpp.a
./../intl/libintl.a
../libiberty/libiberty.a
libbackend.a(options.o)(.rodata+0xb700): undefined reference to
`target_fpe_name'
libbackend.a(options.o)(.rodata+0xb740): undefined reference to
`target_fpe_name'
libbackend.a(arm.o)(.text+0x1274): In function `arm_override_options':
/home/rearnsha/gnusrc/gcc/gcc-4.1/gcc/config/arm/arm.c:1254: undefined
reference to `target_fpe_name'
--
Summary: [4.1 regression] Bootstrap failure on native ARM targets
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Keywords: build
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rearnsha at gcc dot gnu dot org
GCC build triplet: arm-netbsdelf3.0
GCC host triplet: arm-netbsdelf3.0
GCC target triplet: arm-netbsdelf3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27644
[Bug target/27829] ICE/abort in shift_op, at config/arm/arm.c:7917 with asm from testsuite/gcc.dg/pr21255-2-mb.c
--- Comment #4 from rearnsha at gcc dot gnu dot org 2006-05-31 10:12 --- Confirmed on trunk. -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added CC||rearnsha at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-31 10:12:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27829
[Bug target/27829] ICE/abort in shift_op, at config/arm/arm.c:7917 with asm from testsuite/gcc.dg/pr21255-2-mb.c
--- Comment #5 from rearnsha at gcc dot gnu dot org 2006-05-31 10:13 --- Created an attachment (id=11549) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11549&action=view) patch in testing -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rearnsha at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27829
[Bug target/27829] ICE/abort in shift_op, at config/arm/arm.c:7917 with asm from testsuite/gcc.dg/pr21255-2-mb.c
--- Comment #6 from rearnsha at gcc dot gnu dot org 2006-05-31 13:41 --- Subject: Bug 27829 Author: rearnsha Date: Wed May 31 13:41:08 2006 New Revision: 114265 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114265 Log: PR target/27829 * arm.c (arm_print_operand case 'S'): Validate that the operand is a shift operand before calling shift_op. Avoid redundant call of shift_op. Modified: trunk/gcc/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27829
[Bug target/27829] ICE/abort in shift_op, at config/arm/arm.c:7917 with asm from testsuite/gcc.dg/pr21255-2-mb.c
--- Comment #7 from rearnsha at gcc dot gnu dot org 2006-05-31 13:50 --- patch installed -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Keywords||ice-on-invalid-code Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27829
[Bug target/27829] ICE/abort in shift_op, at config/arm/arm.c:7917 with asm from testsuite/gcc.dg/pr21255-2-mb.c
-- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27829
[Bug c++/28215] New: [4.2 regression] Bootstrap failure on arm-eabi
The arm-none-eabi compiler gets a segmentation fault while building libstdc++. A back-trace shows that the fault is in determine_visibility() where we are dereferencing a null pointer. #0 determine_visibility (decl=0xbca2e280) at /home/rearnsha/gnusrc/gcc-cross/trunk/gcc/cp/decl2.c:1753 #1 0x08070697 in start_preparsed_function (decl1=0xbca2e280, attrs=0x0, flags=1) at /home/rearnsha/gnusrc/gcc-cross/trunk/gcc/cp/decl.c:10610 #2 0x080fd708 in use_thunk (thunk_fndecl=0xbca2e280, emit_p=1 '\001') at /home/rearnsha/gnusrc/gcc-cross/trunk/gcc/cp/method.c:460 #3 0x0810a4e3 in emit_associated_thunks (fn=0xbca2e180) at /home/rearnsha/gnusrc/gcc-cross/trunk/gcc/cp/semantics.c:3025 #4 0x0810a5e7 in expand_body (fn=0xbca2e180) at /home/rearnsha/gnusrc/gcc-cross/trunk/gcc/cp/semantics.c:3065 #5 0x084441cc in cgraph_expand_function (node=0xbcadd770) at /home/rearnsha/gnusrc/gcc-cross/trunk/gcc/cgraphunit.c:1112 #6 0x08444355 in cgraph_expand_all_functions () at /home/rearnsha/gnusrc/gcc-cross/trunk/gcc/cgraphunit.c:1177 #7 0x08444ac6 in cgraph_optimize () at /home/rearnsha/gnusrc/gcc-cross/trunk/gcc/cgraphunit.c:1449 #8 0x080ba20f in cp_finish_file () at /home/rearnsha/gnusrc/gcc-cross/trunk/gcc/cp/decl2.c:3310 #9 0x0815aa31 in c_common_parse_file (set_yydebug=0) ... The decl argument is: (gdb) call debug_tree (decl) sizes-gimplified asm_written public unsigned type_6 SI size unit size align 32 symtab -1118697984 alias set 5 pointer_to_this reference_to_this > SI size unit size align 32 symtab 0 alias set -1 method basetype >> arg-types chain >>> addressable used public static weak in_system_header no-static-chain decl_5 SI file /work/rearnsha/gnu/gcc-eabi/trunk/arm-eabi/libstdc++-v3/include/iosfwd line 92 context >> initial arguments >> readonly public unsigned SI size unit size align 32 symtab -1131518128 alias set -1> readonly used unsigned SI file /work/rearnsha/gnu/gcc-eabi/trunk/arm-eabi/libstdc++-v3/include/fstream line 585 size unit size align 32 context initial abstract_origin arg-type > result unsigned ignored SI file /home/rearnsha/gnusrc/gcc-cross/trunk/libstdc++-v3/src/fstream-inst.cc line 50 size unit size align 32> saved-insns 0xbd8b8bfc> -- Summary: [4.2 regression] Bootstrap failure on arm-eabi Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, build, visibility Severity: blocker Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rearnsha at gcc dot gnu dot org GCC target triplet: arm-none-eabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28215
[Bug c++/28215] [4.2 regression] Bootstrap failure on arm-eabi
--- Comment #1 from rearnsha at gcc dot gnu dot org 2006-07-01 18:04 --- Created an attachment (id=11787) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11787&action=view) gziped attachment of failing source file (pre-processed) cc1plus fstream-inst.ii -quiet -dumpbase fstream-inst.cc -auxbase-strip fstream-inst.o -g -O2 -Wall -Wextra -Wwrite-strings -Wcast-qual -version -fno-implicit-templates -fdiagnostics-show-location=once -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28215
[Bug target/37668] Obvious bug in arm.c: arm_size_rtx_costs() case NEG:
-- rearnsha at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rearnsha at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-09-28 11:57:07 |2008-12-10 14:29:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37668
[Bug target/37668] Obvious bug in arm.c: arm_size_rtx_costs() case NEG:
--- Comment #3 from rearnsha at gcc dot gnu dot org 2008-12-10 14:58 --- Subject: Bug 37668 Author: rearnsha Date: Wed Dec 10 14:57:18 2008 New Revision: 142647 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142647 Log: Martin Guy <[EMAIL PROTECTED]> PR target/37668 * arm.c (arm_size_rtx_costs, case NEG): Don't fall through if the result will be in an FPU register. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37668
[Bug target/37668] Obvious bug in arm.c: arm_size_rtx_costs() case NEG:
--- Comment #4 from rearnsha at gcc dot gnu dot org 2008-12-10 15:00 --- Fixed in 4.4.0 -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37668
[Bug target/37436] arm-cross-g++. internal compiler error: in extract_insn, at recog.c:1990
--- Comment #3 from rearnsha at gcc dot gnu dot org 2008-12-10 15:10 --- Confirmed. Still present on trunk. -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.4.0 Last reconfirmed|-00-00 00:00:00 |2008-12-10 15:10:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37436
[Bug target/37436] arm-cross-g++. internal compiler error: in extract_insn, at recog.c:1990
--- Comment #4 from rearnsha at gcc dot gnu dot org 2008-12-10 15:38 --- Some notes on the failure path: combine generates the pattern (insn 1466 1464 1467 192 regeximp.h:320 (set (reg:SI 1002) (sign_extend:SI (mem/s/j:QI (plus:SI (reg:SI 1000) (mult:SI (reg/v:SI 246 [ opValue.1977 ]) (const_int 32 [0x20]))) [note the address in the mem is not in canonical form] Register allocation realises that a scaled register is not permitted for a sign_extend(mem()) operation and splits the entire sub-expression into a separate insn. However, because that insn is not in canonical form, it then fails to recognize the result. -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added CC||rearnsha at gcc dot gnu dot ||org Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37436
[Bug target/37436] arm-cross-g++. internal compiler error: in extract_insn, at recog.c:1990
-- rearnsha at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rearnsha at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-12-10 15:10:56 |2008-12-10 16:54:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37436
[Bug target/37436] arm-cross-g++. internal compiler error: in extract_insn, at recog.c:1990
-- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37436
[Bug target/37436] arm-cross-g++. internal compiler error: in extract_insn, at recog.c:1990
-- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37436
[Bug target/37436] arm-cross-g++. internal compiler error: in extract_insn, at recog.c:1990
--- Comment #6 from rearnsha at gcc dot gnu dot org 2008-12-16 12:12 --- Fixed on trunk -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37436
[Bug target/36804] For-loop never exits in gcc for ARM.
--- Comment #1 from rearnsha at gcc dot gnu dot org 2008-12-16 16:45 --- I'm unable to reproduce this with any of svn-trunk, gcc-4.1.3 (debian), gcc-4.3.3 (SVN) or gcc-4.3.2 (debian). The loop essentially reads as mov r7, #1 mov r6, #0 L5: ... add r6, r6, #1 cmp r7, r6 bhi L5 This will iterate only while r7 is larger than r6 -- that is, exactly once, when r6 is 0. -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36804
[Bug target/37436] arm-cross-g++. internal compiler error: in extract_insn, at recog.c:1990
--- Comment #5 from rearnsha at gcc dot gnu dot org 2008-12-16 12:04 --- Subject: Bug 37436 Author: rearnsha Date: Tue Dec 16 12:03:41 2008 New Revision: 142778 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142778 Log: PR target/37436 * arm.c (arm_legitimate_index): Only accept addresses that are in canonical form. * predicates.md (arm_reg_or_extendqisi_mem_op): New predicate. * arm.md (extendqihi2): Use arm_reg_or_extendqisi_mem_op predicate for operand1. (extendqisi2): Likewise. (arm_extendqisi, arm_extendqisi_v6): Use arm_extendqisi_mem_op predicate for operand1. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/config/arm/arm.md trunk/gcc/config/arm/predicates.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37436
[Bug target/36209] arm-*-linux-gnueabi-gcc (4.3.0) segment fault during build of procps-3.2.7
--- Comment #2 from rearnsha at gcc dot gnu dot org 2008-12-16 17:12
---
Confirmed. This appears to be a bug in the register-renaming pass, where the
insn
(insn:HI 84 79 82 8 proc/sysinfo.c:890 (parallel [
(set (reg:CC_NOOV 24 cc)
(compare:CC_NOOV (minus:SI (ashiftrt:SI (reg:SI 2 r2 [170])
(const_int 2 [0x2]))
(reg:SI 3 r3 [173]))
(const_int 0 [0x0])))
(set (reg/v:SI 0 r0 [orig:133 rc.187 ] [133])
(minus:SI (ashiftrt:SI (reg:SI 2 r2 [170])
(const_int 2 [0x2]))
(reg:SI 3 r3 [173])))
]) 265 {*arith_shiftsi_compare0} (nil))
is transformed to
(insn:HI 84 79 82 8 proc/sysinfo.c:890 (parallel [
(set (reg:CC_NOOV 24 cc)
(compare:CC_NOOV (minus:SI (ashiftrt:SI (reg:SI 2 r2 [170])
(const_int 2 [0x2]))
(reg:SI 14 lr [173]))
(const_int 0 [0x0])))
(set (reg/v:SI 0 r0 [orig:133 rc.187 ] [133])
(minus:SI (cc0)
(cc0)))
]) 265 {*arith_shiftsi_compare0} (expr_list:REG_DEAD (reg:SI 3 r3
[173])
(expr_list:REG_DEAD (reg:SI 2 r2 [170])
(nil
The use of cc0 in the second version indicates a failure to correctly transform
the insn.
The bug goes away if -frename-registers is removed from the command line.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
CC||rearnsha at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known to fail||4.3.3
Known to work||4.4.0
Last reconfirmed|-00-00 00:00:00 |2008-12-16 17:12:19
date||
Target Milestone|--- |4.3.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36209
[Bug target/35624] ARM embeded assembly result error
--- Comment #4 from rearnsha at gcc dot gnu dot org 2008-12-16 17:39
---
Not a bug. You need to write your macro like this:
#define burst_copy(dst,src,len) {\
unsigned t1, t2, t3; \
__asm__ __volatile__ ( \
"1: \n\t" \
"ldmia %1!,{r3-r6} \n\t" \
"stmia %0!,{r3-r6} \n\t" \
"subs %2, %2, #1 \n\t" \
"bne 1b \n\t" \
:"=r"(t1),"=r"(t2),"=r"(t3) \
:"0"(dst),"1"(src),"2"(len) \
:"r3","r4","r5","r6", "memory"); \
}
Note that the results are never used, but this informs the compiler that the
input values have been destroyed by the operation. Also note the clobber of
"memory" to indicate that values in memory have been updated by the operation.
It might be better to use an inline function for this rather than a macro, then
you can use the input operands as your output operands and don't need to
declare the temporaries. It would also give better error checking in some
circumstances.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35624
[Bug bootstrap/38578] fatal warning during bootstrap on arm.c for output_move_double and arm_expand_prologue
--- Comment #1 from rearnsha at gcc dot gnu dot org 2008-12-19 10:22 --- I'm already testing fixes for this, but my native arm board is very sl -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rearnsha at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-12-19 10:22:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38578
[Bug bootstrap/38578] fatal warning during bootstrap on arm.c for output_move_double and arm_expand_prologue
--- Comment #3 from rearnsha at gcc dot gnu dot org 2008-12-19 17:24 --- Subject: Bug 38578 Author: rearnsha Date: Fri Dec 19 17:22:58 2008 New Revision: 142837 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142837 Log: PR bootstrap/38578 * arm.c (load_multiple_sequence): Initialize ORDER array. (store_multiple_sequence): Likewise. (output_move_double): Make reg0 unsigned. (arm_output_epilogue): Make amount unsigned. (arm_expand_prologue): Move declaration of dwarf before block statements. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38578
[Bug bootstrap/38578] fatal warning during bootstrap on arm.c for output_move_double and arm_expand_prologue
--- Comment #4 from rearnsha at gcc dot gnu dot org 2008-12-19 17:25 --- Fixed -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38578
[Bug target/38548] [4.4 Regression] bootstrap broken on arm-linux-gnu (not gnueabi)
-- rearnsha at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rearnsha at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-12-19 17:28:02 date|| Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38548
[Bug target/38548] [4.4 Regression] bootstrap broken on arm-linux-gnu (not gnueabi)
--- Comment #1 from rearnsha at gcc dot gnu dot org 2008-12-19 17:32 --- Subject: Bug 38548 Author: rearnsha Date: Fri Dec 19 17:31:12 2008 New Revision: 142838 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142838 Log: PR target/38548 * arm/t-linux (LIB1ASMFUNCS): Add _arm_addsubdf3 and _arm_addsubsf3. * arm/lib1funcs.asm (clzsi2): Use RET macro for return instruction. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/lib1funcs.asm trunk/gcc/config/arm/t-linux -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38548
[Bug target/38548] [4.4 Regression] bootstrap broken on arm-linux-gnu (not gnueabi)
--- Comment #2 from rearnsha at gcc dot gnu dot org 2008-12-19 17:33 --- Fixed -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added CC||rearnsha at gcc dot gnu dot ||org Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38548
[Bug target/14202] [arm] Thumb __builtin_setjmp not interworking safe
--- Comment #9 from rearnsha at gcc dot gnu dot org 2009-01-05 17:52 --- (In reply to comment #8) > Seems to work on 4.3.2-1 Debian gnueabi > You didn't compile your testcase with -mthumb. Also, that system should be using unwinding tables for exceptions, rather than builtin_setjmp and friends, so it's probably not relevant. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14202
[Bug target/38570] [arm] -mthumb generates sub-optimal prolog/epilog
--- Comment #7 from rearnsha at gcc dot gnu dot org 2009-05-04 09:41 --- (In reply to comment #6) > We can compute the maximum possible function length first. If the length is > not > large enough far jump is not necessary, and we can do this optimization > safely. > No, it's not that easy, since reload can add instructions. Realistically, there is a finite limit beyond which even reload couldn't generate sufficiently large numbers of instructions to cause failure, but it's hard to *prove* what that lower bound is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38570
[Bug target/38570] [arm] -mthumb generates sub-optimal prolog/epilog
--- Comment #9 from rearnsha at gcc dot gnu dot org 2009-05-05 10:06
---
(In reply to comment #8)
> Sorry for my ignorance to gcc. What types of instructions reload will add?
> Spilling and loading registers? and more?
>
That's pretty much it, but...
> By reading the the implementation of thumb_far_jump_used_p() I can get the
> conclusion that if reload thinks there is a far jump, later pass won't change
> this decision. But if reload thinks there is no far jump, later pass still
> need
> to re-check the far jump existence and may change this decision. So if reload
> occasionally makes a wrong decision later pass should correct it, is it right?
>
Once reload has completed we can't change the decision as to whether or not LR
gets saved onto the stack or not. Unfortunately, that doesn't play well with
constant pools. We sometimes need to inline these, and that might cause
branches to be pushed out of range. Since we don't inline the pools until
after reload has completed, that's a major stumbling block. The current code
just isn't aware of these issues.
--
rearnsha 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=38570
[Bug target/40153] Long long comparison optimized away incorrectly in Thumb code.
--- Comment #4 from rearnsha at gcc dot gnu dot org 2009-05-16 12:53 --- Subject: Bug 40153 Author: rearnsha Date: Sat May 16 12:53:22 2009 New Revision: 147613 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147613 Log: PR target/40153 * arm.md (cstoresi_nltu_thumb1): Use a neg of ltu as the pattern name implies. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40153
[Bug target/40153] Long long comparison optimized away incorrectly in Thumb code.
--- Comment #5 from rearnsha at gcc dot gnu dot org 2009-05-16 13:28 --- Subject: Bug 40153 Author: rearnsha Date: Sat May 16 13:28:27 2009 New Revision: 147614 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147614 Log: PR target/40153 * arm.md (cstoresi_nltu_thumb1): Use a neg of ltu as the pattern name implies. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config/arm/arm.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40153
[Bug target/40153] Long long comparison optimized away incorrectly in Thumb code.
-- rearnsha at gcc dot gnu dot org changed: What|Removed |Added CC||rearnsha at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |rearnsha at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Keywords||wrong-code Last reconfirmed|2009-05-15 08:26:09 |2009-05-16 13:49:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40153
[Bug target/39501] -O -ffinite-math-only gets min(x,y) optimization wrong for soft-float on arm-*-gnueabi
--- Comment #15 from rearnsha at gcc dot gnu dot org 2009-05-16 22:25 --- Subject: Bug 39501 Author: rearnsha Date: Sat May 16 22:24:59 2009 New Revision: 147623 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147623 Log: PR target/39501 * arm.md (movsfcc): Disable if not TARGET_HARD_FLOAT. * testsuite/gcc.c-torture/execute/pr39501.c: New file. * testsuite/gcc.c-torture/execute/pr39501.x: New file. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/execute/pr39501.c branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/execute/pr39501.x Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/config/arm/arm.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39501
[Bug target/40153] Long long comparison optimized away incorrectly in Thumb code.
--- Comment #7 from rearnsha at gcc dot gnu dot org 2009-05-16 23:04 --- Subject: Bug 40153 Author: rearnsha Date: Sat May 16 23:04:06 2009 New Revision: 147626 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147626 Log: PR target/40153 * arm.md (cstoresi_nltu_thumb1): Use a neg of ltu as the pattern name implies. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/config/arm/arm.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40153
[Bug target/40153] Long long comparison optimized away incorrectly in Thumb code.
--- Comment #8 from rearnsha at gcc dot gnu dot org 2009-05-16 23:06 --- (In reply to comment #6) > Thanks for fixing this. I also submitted a patch yesterday with the same fix > and a test case also. The bug is fixed but I think we still want the test > case, right? Sorry, didn't see your patch. I don't think another test is really necessary, this fixes so many failures on trunk that I don't see the need for an additional test. -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40153
[Bug target/39715] [4.5 Regression][cond-optab] extra sign extensions on Thumb
--- Comment #1 from rearnsha at gcc dot gnu dot org 2009-05-21 10:49
---
Another case, compile with -mcpu=arm1136jf-s -mthumb -O2
void f(unsigned a, unsigned b, unsigned c, unsigned d)
{
if (a <= b || c > d)
foo();
else
bar();
}
f:
push{r4, lr}
cmp r3, r2
sbc r2, r2, r2 @ r2 = 0 or -1
neg r2, r2 @ r2 = 0 or 1
cmp r2, #0
beq .L7
.L5:
bl foo
.L1:
@ sp needed for prologue
pop {r4, pc}
.L7:
cmp r1, r0 @ r2 = 0 (by flow control)
adc r2, r2, r2 @ r2 = 0 / 1
uxtbr2, r2 @ so this is redundant
cmp r2, #0
bne .L5
bl bar
b .L1
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-05-21 10:49:12
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39715
[Bug target/33111] Bad code generation with -O2 (ARM 7 architecture)
--- Comment #10 from rearnsha at gcc dot gnu dot org 2009-05-22 14:51 --- The ARM7 does not support unaligned accesses in the way that C programmers normally expect (even if it doesn't fault them in the MMU then it still won't fetch what you might expect -- see the CPU manuals for details). As of ARM11 the rules were changed, but that's a different story... -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33111
[Bug target/10242] [ARM] subsequent use of plus and minus operators could be improved
--- Comment #8 from rearnsha at gcc dot gnu dot org 2009-06-03 23:31 --- Subject: Bug 10242 Author: rearnsha Date: Wed Jun 3 23:31:12 2009 New Revision: 148156 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148156 Log: PR target/10242 * arm.md (arm_addsi3): Don't try to split an add with an eliminable register until after reload has completed. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10242
[Bug target/10242] [ARM] subsequent use of plus and minus operators could be improved
--- Comment #9 from rearnsha at gcc dot gnu dot org 2009-06-03 23:34 --- fixed -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10242
[Bug target/40327] Use less instructions to add some constants to register
--- Comment #3 from rearnsha at gcc dot gnu dot org 2009-06-09 22:06 --- Working on a patch -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rearnsha at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-06-03 10:36:14 |2009-06-09 22:06:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40327
[Bug target/40327] Use less instructions to add some constants to register
--- Comment #4 from rearnsha at gcc dot gnu dot org 2009-06-13 12:49 --- Subject: Bug 40327 Author: rearnsha Date: Sat Jun 13 12:49:25 2009 New Revision: 148452 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148452 Log: PR target/40327 * arm/constraints.md (Pa, Pb): New constraints. * arm/arm.md (thumb1_addsi3): Support more complex additions. Add a split pattern to deal with them. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.md trunk/gcc/config/arm/constraints.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40327
[Bug target/40327] Use less instructions to add some constants to register
--- Comment #5 from rearnsha at gcc dot gnu dot org 2009-06-13 13:04 --- fixed -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40327
[Bug tree-optimization/40436] New: [4.5 regression] 0.5% code size regression caused by r147852
Rev 147852, which claims (according to http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00812.html) to improve code size, really makes things worse by ~0.5% for ARM, thumb and thumb2 code when building CSiBE. -- Summary: [4.5 regression] 0.5% code size regression caused by r147852 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rearnsha at gcc dot gnu dot org GCC target triplet: arm-eabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
[Bug tree-optimization/40437] New: [4.5 regression] 0.5% code size regression caused by r147852
Rev 147852, which claims (according to http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00812.html) to improve code size, really makes things worse by ~0.5% for ARM, thumb and thumb2 code when building CSiBE. -- Summary: [4.5 regression] 0.5% code size regression caused by r147852 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rearnsha at gcc dot gnu dot org GCC target triplet: arm-eabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40437
[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852
--- Comment #3 from rearnsha at gcc dot gnu dot org 2009-06-13 23:10 --- For ARM -Os 114 files in CSiBE increase in size (total increase 21449 bytes) 20 files decrease in size (total decreases 1039 bytes); over all increase 20410 bytes) Worst single increase is from bzip2/compress (increase from 12495 to 19463 bytes). -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |major Keywords|missed-optimization | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852
-- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Keywords||missed-optimization Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
[Bug target/40457] use stm and ldm to access consecutive memory words
--- Comment #4 from rearnsha at gcc dot gnu dot org 2009-06-16 15:50 --- You haven't specified what compilation options you were using. -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added CC||rearnsha at gcc dot gnu dot | |org Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40457
[Bug target/40499] [missed optimization] branch to return not threaded on thumb
--- Comment #6 from rearnsha at gcc dot gnu dot org 2009-06-22 12:37 --- Support for single-instruction return insns has been around a lot longer than rtl-based epilogues, so there's no need to convert the thumb target to RTL epilogues as a pre-requisite for fixing this. Someone simply needs to sit down and work out what the code needs to do in order to support this feature; and then implement it... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40499
[Bug target/40487] Extra zero extensions produced for ARM.
--- Comment #4 from rearnsha at gcc dot gnu dot org 2009-06-22 17:00 --- (In reply to comment #3) > Is this related to bug 39715? > Maybe. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40487
[Bug target/40523] GCC generates invalid instructions when building for Thumb-2 on armel
-- rearnsha at gcc dot gnu dot org changed: What|Removed |Added CC||rearnsha at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |rearnsha at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-06-22 23:30:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40523
[Bug target/40487] Extra zero extensions produced for ARM.
--- Comment #11 from rearnsha at gcc dot gnu dot org 2009-07-14 14:53 --- The following define_split works for this specific case, but it needs to be made more generic (handling IOR and HImode variants). It also needs reworking for big-endian -- that needs (subreg...3). (define_split [(set (match_operand:SI 0 "s_register_operand" "") (xor:SI (and:SI (ashift:SI (match_operand:SI 1 "s_register_operand" "") (match_operand:SI 2 "const_int_operand" "")) (match_operand:SI 3 "const_int_operand" "")) (zero_extend:SI (subreg:QI (match_dup 1) 0] "TARGET_32BIT && INTVAL (operands[3]) == (255 & (255 << (INTVAL (operands[2]" [(set (match_dup 0) (xor:SI (ashift:SI (match_dup 1) (match_dup 2)) (match_dup 1))) (set (match_dup 0) (and:SI (match_dup 0) (const_int 255)))] "") -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40487
[Bug target/40487] Extra zero extensions produced for ARM.
--- Comment #12 from rearnsha at gcc dot gnu dot org 2009-07-15 10:31 --- Fixed with: http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00848.html -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added CC||rearnsha at gcc dot gnu dot ||org Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40487
[Bug target/40603] unnecessary conversion from unsigned byte load to signed byte load
--- Comment #4 from rearnsha at gcc dot gnu dot org 2009-07-22 21:22 --- The transformation to signed char is done very early on (maybe even during parsing). The 003t.original dump already contains: if ((signed char) *(p + 8) >= 0) -- rearnsha 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=40603
[Bug target/40835] redundant comparison instruction
--- Comment #7 from rearnsha at gcc dot gnu dot org 2009-07-24 14:08 --- (In reply to comment #6) > In fact even the compare isn't a separate insn: There's a reason for that. If you separate compares from uses of the flags then reload may end up inserting add or mov instructions in between the comparison and its use. Since thumb1 does not have non-flag setting versions of those instructions (at least for the lo-regs case) we thus cannot separate the two. To mitigate this, there are already a number of patterns in the thumb description that try to exploit flag-setting instructions more efficiently, but there are bound to be more cases that are not yet handled. Beware, however, of generating sequences that are impossible to reload. -- rearnsha 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=40835
[Bug tree-optimization/40914] New: ipa_analyze_call_uses fails to handle ptrmemfunc_vbit_in_delta
The code in ipa_analyze_call_uses tries to wade through the gimple to identify
uses of pointers to member functions that are invariant after inlining (due to
parameter passing). However, the code only looks for the vbit test on the
pointer part of the pmf not on the delta. On targets such as ARM all bits in
the pointer are meaningful and the vbit is stored in the delta and the code
scrubbing fails to match.
Testcase is g++.dg/ipa/iinline-1.C
On arm the relevant gimple looks like:
f$__pfn_4 = f.__pfn;
f$__delta_24 = f.__delta;
__comp_ctor (&S, &"muhehehe"[0]);
D.1787_3 = f$__delta_24 & 1;
if (D.1787_3 != 0)
goto ;
else
goto ;
:
D.1789_6 = f$__delta_24 >> 1;
D.1790_7 = (unsigned int) D.1789_6;
D.1791_8 = &S + D.1790_7;
D.1792_9 = (int (*__vtbl_ptr_type) (void) * *) D.1791_8;
D.1793_10 = *D.1792_9;
D.1795_12 = (unsigned int) f$__pfn_4;
D.1796_13 = D.1793_10 + D.1795_12;
D.1797_14 = *D.1796_13;
iftmp.0_15 = (String:: *) D.1797_14;
:
# iftmp.0_1 = PHI
D.1789_18 = f$__delta_24 >> 1;
D.1790_19 = (unsigned int) D.1789_18;
D.1798_20 = &S + D.1790_19;
D.1784_21 = iftmp.0_1 (D.1798_20, 4);
--
Summary: ipa_analyze_call_uses fails to handle
ptrmemfunc_vbit_in_delta
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rearnsha at gcc dot gnu dot org
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40914
[Bug tree-optimization/40914] ipa_analyze_call_uses fails to handle ptrmemfunc_vbit_in_delta
--- Comment #2 from rearnsha at gcc dot gnu dot org 2009-07-31 10:52 --- Patch proposed here: http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01816.html -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Severity|enhancement |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40914
[Bug tree-optimization/40914] ipa_analyze_call_uses fails to handle ptrmemfunc_vbit_in_delta
--- Comment #3 from rearnsha at gcc dot gnu dot org 2009-07-31 21:56 --- Subject: Bug 40914 Author: rearnsha Date: Fri Jul 31 21:56:28 2009 New Revision: 150319 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150319 Log: PR tree-optimization/40914 * ipa-prop.c (ipa_get_ptr_load_param): New argument use_delta, if set, then check the delta field of the PMF record. (ipa_get_stmt_member_ptr_load_param): Propagate new param use_delta. (ipa_analyze_call_uses): Handle machines where the vbit for a PMF call is stored in the delta. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-prop.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40914
[Bug tree-optimization/40914] ipa_analyze_call_uses fails to handle ptrmemfunc_vbit_in_delta
--- Comment #4 from rearnsha at gcc dot gnu dot org 2009-07-31 21:57 --- Fixed on trunk -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40914
[Bug other/41027] New: Missing warning from -Wc++-compat
trying to build gcc for arm-eabi with --enable-build-with-cxx fails with
'structure 'key' with uninitialized const members'. However, a normal C-based
bootstrap does not report this as a warning when -Wc++-compat is used.
struct f
{
const int a;
};
void g(struct f*);
void h ()
{
struct f h;
g(&h);
}
--
Summary: Missing warning from -Wc++-compat
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rearnsha at gcc dot gnu dot org
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41027
[Bug target/24861] internal compiler error when building gcc with --with-cpu=ep9312 --with-fpu=maverick
--- Comment #3 from rearnsha at gcc dot gnu dot org 2005-11-16 22:14 --- Subject: Bug 24861 Author: rearnsha Date: Wed Nov 16 22:14:38 2005 New Revision: 107104 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107104 Log: PR target/24861 * arm.md (split for movsf with immediate): Restrict split to insns that set a general register. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24861
[Bug target/24861] internal compiler error when building gcc with --with-cpu=ep9312 --with-fpu=maverick
--- Comment #4 from rearnsha at gcc dot gnu dot org 2005-11-16 22:31 --- Subject: Bug 24861 Author: rearnsha Date: Wed Nov 16 22:31:14 2005 New Revision: 107105 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107105 Log: PR target/24861 * arm.md (split for movsf with immediate): Restrict split to insns that set a general register. Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/config/arm/arm.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24861
[Bug target/24861] internal compiler error when building gcc with --with-cpu=ep9312 --with-fpu=maverick
--- Comment #5 from rearnsha at gcc dot gnu dot org 2005-11-16 22:34 --- There was a split pattern that was converting a set of a floating point value into a set of an integer value. This doesn't match anything if the register being set is a Maverick Co-pro register, and in general we only want to do this if setting an ARM core register. Having restricted the pattern in this way, the extra constraint that disabled the pattern for the FPA is no-longer relevant. -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added CC||rearnsha at gcc dot gnu dot | |org Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24861
[Bug target/24914] gcc fails when built with --with-cpu=ep9312 --with-fpu=maverick
--- Comment #2 from rearnsha at gcc dot gnu dot org 2005-11-17 20:55 --- The compiler is trying to reload the Maverick register into a VFP register. But there are no VFP registers on the ep9312! Testing a fix. -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added CC||rearnsha at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-17 20:55:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24914
[Bug target/24914] gcc fails when built with --with-cpu=ep9312 --with-fpu=maverick
--- Comment #3 from rearnsha at gcc dot gnu dot org 2005-11-18 17:59 --- Subject: Bug 24914 Author: rearnsha Date: Fri Nov 18 17:59:37 2005 New Revision: 107187 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107187 Log: PR target/24914 * arm.c (arm_hard_regno_mode_ok): Co-processor registers aren't ok when not generating code to use that co-processor. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24914
[Bug target/24914] gcc fails when built with --with-cpu=ep9312 --with-fpu=maverick
--- Comment #4 from rearnsha at gcc dot gnu dot org 2005-11-18 19:54 --- Subject: Bug 24914 Author: rearnsha Date: Fri Nov 18 19:54:41 2005 New Revision: 107189 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107189 Log: PR target/24914 * arm.c (arm_hard_regno_mode_ok): Co-processor registers aren't ok when not generating code to use that co-processor. Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/config/arm/arm.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24914
[Bug target/24914] gcc fails when built with --with-cpu=ep9312 --with-fpu=maverick
--- Comment #5 from rearnsha at gcc dot gnu dot org 2005-11-18 20:05 --- Sometimes when the reload needs to reload an expression that is a subreg of a wider register, X, into a different class than X it will call find_valid_class. This routine simply checks whether the class has any registers that *could* hold the value in X, it does not check that there *are* any such registers available. This was causing a problem on ARM in some circumstances because HARD_REGNO_MODE_OK was returning true for a class that would be suitable *if* such registers were available on the machine, but because of compilation options in force the set was currently empty. -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24914
[Bug middle-end/24947] -Os should maximize inlining --param values.
--- Comment #4 from rearnsha at gcc dot gnu dot org 2005-11-21 15:19 --- It seems to me that the problem here is that a 'warning' is too strong here, particularly with -Werror. We really need a diagnostic that is non-fatal to the compilation, since there's nothing really wrong with the user's code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24947
[Bug middle-end/24947] -Os should maximize inlining --param values.
--- Comment #6 from rearnsha at gcc dot gnu dot org 2005-11-21 15:49 --- Subject: Re: -Os should maximize inlining --param values. I didn't say the compiler shouldn't say anything, I said it shouldn't be fatal. Regardless of whether or not you think the limits are too low, others may disagree and not want to change them. That doesn't mean that the compiler should reject their code because the limit has been exceeded. This is not something that should cause -Werror to refuse compilation.. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24947
[Bug bootstrap/24998] Build failure on sparc-sun-solaris2.9/arm: undefined symbol __floatunsitf
--- Comment #2 from rearnsha at gcc dot gnu dot org 2005-11-23 12:12 --- Similar failures on arm: libbackend.a(timevar.o)(.text+0x1e4): In function `get_time': /work/rearnsha/gnusrc/gcc/trunk/gcc/timevar.c:203: undefined reference to `__floatunsidf' libbackend.a(timevar.o)(.text+0x200):/work/rearnsha/gnusrc/gcc/trunk/gcc/timevar.c:204: undefined reference to `__floatunsidf' libbackend.a(timevar.o)(.text+0x220):/work/rearnsha/gnusrc/gcc/trunk/gcc/timevar.c:205: undefined reference to `__floatunsidf' -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet|sparc-sun-solaris2.*|sparc-sun-solaris2.* arm-* Summary|Build failure on sparc-sun- |Build failure on sparc-sun- |solaris2.9: undefined symbol|solaris2.9/arm: undefined |__floatunsitf |symbol __floatunsitf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24998
[Bug middle-end/24998] [4.2 Regression] Build failure on sparc-sun-solaris2.9/arm: undefined symbol __floatunsitf
--- Comment #5 from rearnsha at gcc dot gnu dot org 2005-11-23 14:22 --- Subject: Re: [4.2 Regression] Build failure on sparc-sun-solaris2.9/arm: undefined symbol __floatunsitf On Wed, 2005-11-23 at 14:09, joseph at codesourcery dot com wrote: > On Wed, 23 Nov 2005, rearnsha at gcc dot gnu dot org wrote: > > > /work/rearnsha/gnusrc/gcc/trunk/gcc/timevar.c:203: undefined reference to > > `__floatunsidf' > > ARM should be getting __floatunsidf from ieee754-df.S. Why isn't it? > Did the code previously use __floatsidf, and if so where did it get > __floatsidf from? Because this is NetBSD, which doesn't use ieee754-df.S. And the C library only provides __floatsidf. Sorry, I hadn't realized this was restricted only to arm-netbsdelf -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24998
[Bug middle-end/24998] [4.2 Regression] Build failure on sparc-sun-solaris2.9/arm: undefined symbol __floatunsitf
--- Comment #7 from rearnsha at gcc dot gnu dot org 2005-11-23 14:44 --- Subject: Re: [4.2 Regression] Build failure on sparc-sun-solaris2.9/arm: undefined symbol __floatunsitf On Wed, 2005-11-23 at 14:28, joseph at codesourcery dot com wrote: > In that case the obvious solution is for the NetBSD configuration to start > using that one function from ieee754-df.S. (I checked that the > implementations in GCC of __float* already had corresponding > implementations of __floatun* as required - missing rs6000/ppc64-fp.c in > the process - but couldn't check for any case where these functions came > from libc.) Not that simple, because the implementation of __floatunsidf is tightly integrated with the implementation of __adddf3. And we don't want to override that because the ieee754-df.S implementation does not support raising signals. R. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24998
[Bug middle-end/24998] [4.2 Regression] Build failure on sparc-sun-solaris2.9/arm: undefined symbol __floatunsitf
--- Comment #12 from rearnsha at gcc dot gnu dot org 2005-11-25 10:09 --- Subject: Re: [4.2 Regression] Build failure on sparc-sun-solaris2.9/arm: undefined symbol __floatunsitf On Fri, 2005-11-25 at 02:51, joseph at codesourcery dot com wrote: > It > does not address the arm-netbsdelf problem (__floatsidf in libc), > which really needs to be addressed by someone who can test that > platform No, it needs to be addressed by someone who understands and can write ieee floating point support code. I can help testing, but I cannot just write code of that subtlety. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24998
[Bug target/25044] problems caused by unresolved symbols in libgcc
--- Comment #2 from rearnsha at gcc dot gnu dot org 2005-11-26 22:44 --- *** This bug has been marked as a duplicate of 16314 *** -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25044
[Bug target/16314] EP9312 gcc: undefined reference to __divdf3
--- Comment #12 from rearnsha at gcc dot gnu dot org 2005-11-26 22:44 --- *** Bug 25044 has been marked as a duplicate of this bug. *** -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added CC||nekkar at libero dot it http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16314
[Bug rtl-optimization/25133] [3.4 regression] wrong code for conditionals on arm
--- Comment #1 from rearnsha at gcc dot gnu dot org 2005-11-28 16:03 --- Confirmed. This appears to be a bug in noce_try_abs, which is substituting an abs() expansion into the RTL, but the substitution clobbers a hard register that is live (the condition code register). -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added CC||rearnsha at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Component|target |rtl-optimization Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-28 16:03:50 date|| Summary|gcc-3.4 wrong code for |[3.4 regression] wrong code |conditionals on arm |for conditionals on arm http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25133
[Bug middle-end/24998] [4.2 Regression] Build failure on sparc-sun-solaris2.9/arm: undefined symbol __floatunsitf
--- Comment #21 from rearnsha at gcc dot gnu dot org 2006-01-05 15:06 --- Subject: Bug 24998 Author: rearnsha Date: Thu Jan 5 15:06:09 2006 New Revision: 109380 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109380 Log: PR middle-end/24998 * arm/t-netbsd (LIB2FUNCS_EXTRA): Define. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/t-netbsd -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24998
[Bug middle-end/11135] It ought to be possible to make PIC_OFFSET_TABLE_REGNUM a pseudo
--- Comment #3 from rearnsha at gcc dot gnu dot org 2006-01-17 20:22 --- Subject: Bug 11135 Author: rearnsha Date: Tue Jan 17 20:22:19 2006 New Revision: 109839 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109839 Log: PR target/592 PR middle-end/11135 * arm.h (struct machine_function): Add pic_reg. * arm.c (arm_pic_register): Make unsigned. (arm_override_options): Only set arm_pic_register if TARGET_SINGLE_PIC_BASE. (use_return_insn): Only test for a pic register if it is fixed. (arm_compute_save_reg0_reg12_mask): Likewise. (thumb_compute_save_reg_mask): Likewise. (legitimate_pic_operand): Factor out some known invariants. (legitimize_pic_address): If we don't have a fixed pic register, then set up a pseudo in the function entry sequence. Handle the pic base being in a pseudo. (arm_load_pic_register): Handle the pic register being in a pseudo. (arm_expand_prologue): Only set up the pic register if it is fixed. (thumb_expand_prologue): Likewise. * arm.md (pic_load_addr_based): Handle the pic base being a pseudo. (pic_load_addr_based_insn): Likewise. (builtin_setjmp_receiver): Don't restore the pic base if it isn't fixed. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/config/arm/arm.h trunk/gcc/config/arm/arm.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11135
[Bug target/592] [ARM/Thumb] Poor choice of PIC register
--- Comment #7 from rearnsha at gcc dot gnu dot org 2006-01-17 20:22 --- Subject: Bug 592 Author: rearnsha Date: Tue Jan 17 20:22:19 2006 New Revision: 109839 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109839 Log: PR target/592 PR middle-end/11135 * arm.h (struct machine_function): Add pic_reg. * arm.c (arm_pic_register): Make unsigned. (arm_override_options): Only set arm_pic_register if TARGET_SINGLE_PIC_BASE. (use_return_insn): Only test for a pic register if it is fixed. (arm_compute_save_reg0_reg12_mask): Likewise. (thumb_compute_save_reg_mask): Likewise. (legitimate_pic_operand): Factor out some known invariants. (legitimize_pic_address): If we don't have a fixed pic register, then set up a pseudo in the function entry sequence. Handle the pic base being in a pseudo. (arm_load_pic_register): Handle the pic register being in a pseudo. (arm_expand_prologue): Only set up the pic register if it is fixed. (thumb_expand_prologue): Likewise. * arm.md (pic_load_addr_based): Handle the pic base being a pseudo. (pic_load_addr_based_insn): Likewise. (builtin_setjmp_receiver): Don't restore the pic base if it isn't fixed. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/config/arm/arm.h trunk/gcc/config/arm/arm.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=592
[Bug middle-end/11135] It ought to be possible to make PIC_OFFSET_TABLE_REGNUM a pseudo
--- Comment #4 from rearnsha at gcc dot gnu dot org 2006-01-17 20:32 --- Closing as WORKSFORME. I didn't have to change anything in the middle-end in order to fix the ARM back-end. Maybe the documentation should be updated to reflect this status. -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11135
[Bug target/592] [ARM/Thumb] Poor choice of PIC register
--- Comment #8 from rearnsha at gcc dot gnu dot org 2006-01-17 20:32 --- Fixed -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Status|SUSPENDED |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=592
[Bug libgomp/25865] New: libgomp incorrectly detects support for TLS
acinclude.m4 has a home-brewed rule to detect whether a target can support TLS. This rule incorrectly decides that NetBSD can support this. The result is that libgomp will not load, and faults with the error: Unsupported relocation type 14 in non-PLT relocations Rather than rolling its own rule, it should be using the rule in $(topsrcdir)/config/tls.m4 -- namely GCC_CHECK_TLS. -- Summary: libgomp incorrectly detects support for TLS Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rearnsha at gcc dot gnu dot org GCC target triplet: *-*-netbsd http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25865
[Bug target/27363] ARM gcc 4.1 optimization bug
-- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27363
[Bug target/27363] ARM gcc 4.1 optimization bug
-- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.1.3 |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27363
[Bug c/28568] compiler generates incorrect ARM instructions when using long bitfields
--- Comment #1 from rearnsha at gcc dot gnu dot org 2006-08-02 10:38 --- Please provide a fully compilable testcase that demonstrates the bug. -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28568
[Bug c/28568] compiler generates incorrect ARM instructions when using long bitfields
--- Comment #4 from rearnsha at gcc dot gnu dot org 2006-08-02 12:35 --- > What is the status of PR23624. I see there was a checkin, what do I have to > do to make use of the change? You have to convert your code/system to use the EABI version of GCC; or you have to modify your source so that it doesn't use volatile bitfields. The EABI for ARM mandates the behaviour of volatile bitfields, but the arm-elf configuration does not use that ABI and has different semantics in this area. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28568
[Bug target/28872] ARM inline assembly can be mispredicated.
--- Comment #1 from rearnsha at gcc dot gnu dot org 2006-08-29 14:41 --- The only reason for keeping the old predication-based code is that it can handle an important case that the generic code cannot. Specifically, it can conditionally skip a call to a function: this is not normally predicable since it clobbers the instruction codes. However, the arm-specific code knows that it is safe to do this iff the call instruction is the last instruction in the predicated sequence. If the MI code could be made to handle cases where the predicate register was clobbered by the last predicable instruction, then the need to keep the existing MD code could disappear in a puff of smoke. -- rearnsha 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=28872
[Bug target/29004] Wrong Code for ARM IRQ routine
--- Comment #1 from rearnsha at gcc dot gnu dot org 2006-09-11 10:41 --- *** This bug has been marked as a duplicate of 16634 *** -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29004
[Bug target/16634] arm-elf-gcc problems when generating code for __attribute__ ((interrupt ("IRQ")))
--- Comment #3 from rearnsha at gcc dot gnu dot org 2006-09-11 10:41 --- *** Bug 29004 has been marked as a duplicate of this bug. *** -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added CC||hans dot buchmann at fhso ||dot ch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16634
[Bug target/28568] compiler generates incorrect ARM instructions when using long bitfields
--- Comment #11 from rearnsha at gcc dot gnu dot org 2006-10-03 16:25 --- (In reply to comment #7) > Subject: RE: compiler generates incorrect ARM instructions when using long > bitfields > > Why not? What are the criteria? Because it isn't a regression. A regression is when all of the following are satisfied: a) It's a bug b) A previous release of the compiler supported the compiler configuration c) That previous release produced correct code d) This release produces the wrong code In this case b) does not hold and hence c) can't either. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28568
[Bug c/30581] Deeply inlined static functions break stack creation
--- Comment #5 from rearnsha at gcc dot gnu dot org 2007-01-25 17:25 --- --> volatile char buf[512] /*__attribute__ ((aligned (4)))*/; WHat makes you think this buffer will be word-aligned? One of your sub-routines creates a variable with 33 bytes, and when inlining happens there's nothing to stop the compiler from packing these structures onto the stack and starting buf at something like stack-base+33. -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30581
[Bug c/30581] Deeply inlined static functions break stack creation
--- Comment #7 from rearnsha at gcc dot gnu dot org 2007-01-25 17:35 --- (In reply to comment #6) > The problem is that the compiler is not either > 1) automatically aligning the > buffer so that the program actually works or It doesn't have to, because the user hasn't asked it to (align the data). > 2) warning the user that their > code is retarded and needs to be modified so that all the stacks fit to > multiples of 32-bits. It can't, because the various casts are asserting that everything is ok. The compiler isn't psychic and it isn't Lint (though I don't know if Lint would find these specific cases either). I would strongly suggest that if you want this sort of analysis then you take a look at some specialist code analysis tools. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30581
[Bug c++/8715] '~' operator for unsigned char and conversion to bool
--- Comment #7 from rearnsha at gcc dot gnu dot org 2007-01-26 16:46 --- (In reply to comment #6) > OK. I see now. This seems hard to fix, since it is exposing the current > implementation of a conversion to bool. > No, it's not the 'current implementation', its the way the C and C++ standards say this has to happen. When arithmetic operators are applied to sub-int sized operands they are first converted to int (or unsigned int if they can't be represented in int -- which is only the case when you have a machine where sizeof(unsigned short) == sizeof(unsigned int), or something similar). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8715
[Bug c++/8715] '~' operator for unsigned char and conversion to bool
--- Comment #9 from rearnsha at gcc dot gnu dot org 2007-01-26 17:03 --- (In reply to comment #8) > I meant that the warning is appropriate but > the message is confusing because it is exposing that when doing > > bool x = ~b; > > we actually do > > bool x = (~b != 0); > Or, more precisely, bool x = (~(int) b) != 0; > So an appropriate message would say something like: > > test.cpp:5: warning: '(bool) ~b' is always true > Don't you agree? > Yes, that would be nice, but hard to implement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8715
[Bug c/32973] New: [4.3 regression] bootstrap failure with indented structure declaration in macro
Since revision r126615:
2007-07-12 Andreas Schwab <[EMAIL PROTECTED]>
* gengtype-lex.l: Allow declarations to be indented.
Bootstrap of gcc on arm-netbsdelf has failed because
build/gengtype /work/rearnsha/gnusrc/gcc/trunk/gcc gtyp-input.list
/work/rearnsha/gnusrc/gcc/trunk/gcc/config/arm/netbsd-elf.h:144: unexpected
character `\'
This occurs when the scanned file contains something like
#define CLEAR_INSN_CACHE(BEG, END) \
do \
{ \
extern int sysarch(int number, void *args); \
struct \
{ \
unsigned int addr; \
int len; \
} s; \
s.addr = (unsigned int)(BEG); \
s.len = (END) - (BEG); \
(void) sysarch (0, &s); \
} \
while (0)
ie. we have a structure definition inside a macro
--
Summary: [4.3 regression] bootstrap failure with indented
structure declaration in macro
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: build
Severity: blocker
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rearnsha at gcc dot gnu dot org
GCC target triplet: arm-netbsdelf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32973
[Bug c/32978] New: [4.3 regression] bootstrap failure with indented structure declaration in macro
Since revision r126615:
2007-07-12 Andreas Schwab <[EMAIL PROTECTED]>
* gengtype-lex.l: Allow declarations to be indented.
Bootstrap of gcc on arm-netbsdelf has failed because
build/gengtype /work/rearnsha/gnusrc/gcc/trunk/gcc gtyp-input.list
/work/rearnsha/gnusrc/gcc/trunk/gcc/config/arm/netbsd-elf.h:144: unexpected
character `\'
This occurs when the scanned file contains something like
#define CLEAR_INSN_CACHE(BEG, END) \
do \
{ \
extern int sysarch(int number, void *args); \
struct \
{ \
unsigned int addr; \
int len; \
} s; \
s.addr = (unsigned int)(BEG); \
s.len = (END) - (BEG); \
(void) sysarch (0, &s); \
} \
while (0)
ie. we have a structure definition inside a macro
--
Summary: [4.3 regression] bootstrap failure with indented
structure declaration in macro
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: build
Severity: blocker
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rearnsha at gcc dot gnu dot org
GCC target triplet: arm-netbsdelf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32978
[Bug bootstrap/32973] [4.3 regression] bootstrap failure with indented structure declaration in macro
--- Comment #4 from rearnsha at gcc dot gnu dot org 2007-08-03 22:35 --- That looks like it solves the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32973
