[Bug target/44860] New: Thumb ICE due to spill failure
The attached program causes spill failure on latest 4.5 branch with -mthumb
it fails when no -On is used and works when -Os/-O2 is used but fails again
when -fno-omit-frame-pointer is passed in addition to -Os or -O2
arm-oe-linux-uclibceabi-gcc -mthumb -Os -fno-omit-frame-pointer recvfrom.i
recvfrom.i: In function '__libc_recvfrom':
recvfrom.i:5:9: error: unable to find a register to spill in class 'LO_REGS'
recvfrom.i:5:9: error: this is the insn:
(insn 73 19 74 2 recvfrom.i:5 (set (reg:SI 12 ip [150])
(const_int 146 [0x92])) 167 {*thumb1_movsi_insn} (expr_list:REG_EQUAL
(const_int 146 [0x92])
(nil)))
recvfrom.i:5: confused by earlier errors, bailing out
here is the test case
extern __thread int __libc_errno __attribute__ ((tls_model (initial-exec)));
int __libc_recvfrom(
int sockfd, void * buffer, int len, int flags, void * to, void * tolen) {
return (int)({
unsigned int _inline_sys_result = ({ unsigned int _internal_sys_result;
{ int _sys_buf[2]; register int _a1 __asm__ (a1); register int *_v3 __asm__
(v3) = _sys_buf; int _v2tmp = (int) (tolen); int _v1tmp = (int) (to); int
_a4tmp = (int) (flags); int _a3tmp = (int) (len); int _a2tmp = (int) (buffer);
int _a1tmp = (int) (sockfd); _a1 = _a1tmp; register int _a2 __asm__ (a2) =
_a2tmp; register int _a3 __asm__ (a3) = _a3tmp; register int _a4 __asm__
(a4) = _a4tmp; register int _v1 __asm__ (v1) = _v1tmp; register int _v2
__asm__ (v2) = _v2tmp; *_v3 = (int) (((0 +292))); __asm__ __volatile__ (str
r7, [v3, #4]\n \tldr r7, [v3]\n \tswi 0 @ syscall
SYS_ify(__libc_recvfrom) \n \tldr r7, [v3, #4] : =r (_a1) : r
(_v3) , r (_a1), r (_a2), r (_a3), r (_a4), r (_v1), r (_v2) :
memory); _internal_sys_result = _a1; } (int) _internal_sys_result; }); if
(__builtin_expect (((unsigned int) (_inline_sys_result) = 0xf001u), 0)) {
(__libc_errno = ((-(_inline_sys_result; _inline_sys_result = (unsigned int)
-1; } (int) _inline_sys_result; }); }
--
Summary: Thumb ICE due to spill failure
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: raj dot khem at gmail dot com
GCC build triplet: x86_64-linux
GCC host triplet: x86_64-linux
GCC target triplet: arm-oe-linux-uclibceabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44860
[Bug target/44860] Thumb ICE due to spill failure
--- Comment #1 from raj dot khem at gmail dot com 2010-07-07 19:35 --- Created an attachment (id=21128) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21128action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44860
[Bug target/44734] New: GCC compiled to run on mips platform ICE's in def_builtin_1 ()
There seems to be wrong code generated when cross-gcc (x86_64-mips) is used to compile gcc for mips target. Program received signal SIGSEGV, Segmentation fault. 0x004940ac in def_builtin_1 (fncode=BUILT_IN_HUGE_VAL, name=value optimized out, fnclass=BUILT_IN_NORMAL, fntype=value optimized out, libtype=0x0, both_p=0 '\000', fallback_p=0 '\000', nonansi_p=0 '\000', fnattrs=0x2adc42b8, implicit_p=1 '\001') at /scratch/oe/work/mips-oe-linux-uclibc/gcc-4.5-r4.1+svnr161450/gcc-4.5/gcc/c-common.c:5186 5186 built_in_decls[(int) fncode] = decl; When I debugged through it then I see that in this function def_builtin_1 its trying to access 'fncode' which comes in a0 into function it stores it into s2 and then later it moves it into s5 and it uses s5 later to generate the offset into the array built_in_decls[(int) fncode] but the this move into s5 doesnt happen in all execution paths and it gets a bogus high value into s5 which it thinks is an offset into array and then dies. The case where s5 is not populated correctly is when in following assert (!both_p fallback_p) is true then it does not have to compute the || and it follows a different execution path. gcc_assert ((!both_p fallback_p) || !strncmp (name, __builtin_, strlen (__builtin_))); I have attached the objdump output of c-common.o -- Summary: GCC compiled to run on mips platform ICE's in def_builtin_1 () Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: raj dot khem at gmail dot com GCC build triplet: x86_64-linux GCC host triplet: x86_64-linux GCC target triplet: mips-oe-linux-uclibc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44734
[Bug target/44734] GCC compiled to run on mips platform ICE's in def_builtin_1 ()
--- Comment #1 from raj dot khem at gmail dot com 2010-06-30 21:22 --- Created an attachment (id=21046) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21046action=view) objdump intermixed with source for the function -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44734
[Bug target/44734] GCC compiled to run on mips platform ICE's in def_builtin_1 ()
--- Comment #2 from raj dot khem at gmail dot com 2010-06-30 21:24 --- Created an attachment (id=21047) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21047action=view) preprocessed c-common.c to compile use mips-oe-linux-uclibc-gcc -march=mips32 -O c-common.i -S -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44734
[Bug target/44734] GCC compiled to run on mips platform ICE's in def_builtin_1 ()
--- Comment #3 from raj dot khem at gmail dot com 2010-06-30 21:31 --- gcc_assert ((!both_p !fallback_p) 4a7c: 1684bnezs4,4a90 def_builtin_1+0x84 4a80: 02002021move a0,s0 4a84: 12c00051beqzs6,4bcc def_builtin_1+0x1c0 = this jump is taken 4a88: 0080a821moves5,a0 . then it comes here libname = name + strlen (__builtin_); decl = add_builtin_function (name, fntype, fncode, fnclass, 4bcc: afa00010sw zero,16(sp) 4bd0: 8fc20070lw v0,112(s8) 4bd4: afa20014sw v0,20(sp) 4bd8: 00a02021movea0,a1 4bdc: 00e02821movea1,a3 4be0: 02403021movea2,s2 4be4: 02e03821movea3,s7 4be8: 8f99lw t9,0(gp) 4bec: 0320f809jalrt9 4bf0: nop 4bf4: 8fdc0018lw gp,24(s8) 4bf8: 080012e8j 4ba0 def_builtin_1+0x194 this jump takes it back to failing assignment 4bfc: 00408821moves1,v0 built_in_decls[(int) fncode] = decl; 4ba0: 00151080sll v0,s5,0x2 4ba4: 8f83lw v1,0(gp) 4ba8: 00621021adduv0,v1,v0 4bac: ac51sw s1,0(v0) dies here because this is invalid address in v0 now in cases where the first branch is not taken it goes into || !strncmp (name, __builtin_, strlen (__builtin_))); libname = name + strlen (__builtin_); decl = add_builtin_function (name, fntype, fncode, fnclass, 4ad4: 0240a821moves5,s2 4ad8: 1021movev0,zero 4adc: 0276100bmovnv0,s3,s6 4ae0: afa20010sw v0,16(sp) 4ae4: 8fc20070lw v0,112(s8) 4ae8: afa20014sw v0,20(sp) 4aec: 02002021movea0,s0 4af0: 02202821movea1,s1 4af4: 02403021movea2,s2 4af8: 02e03821movea3,s7 4afc: 8f99lw t9,0(gp) 4b00: 0320f809jalrt9 4b04: nop 4b08: 8fdc0018lw gp,24(s8) as you can see first instruction moves s2 into s5 and s2 holds the right value so it works ok. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44734
[Bug target/44734] GCC compiled to run on mips platform ICE's in def_builtin_1 ()
--- Comment #4 from raj dot khem at gmail dot com 2010-06-30 21:33 --- just in case here is how the compiler was configured Using built-in specs. COLLECT_GCC=mips-oe-linux-uclibc-gcc COLLECT_LTO_WRAPPER=/scratch/oe/cross/mips/libexec/gcc/mips-oe-linux-uclibc/4.5.1/lto-wrapper Target: mips-oe-linux-uclibc Configured with: /scratch/oe/work/mips-oe-linux-uclibc/gcc-cross-4.5-r1+svnr161450/gcc-4.5/configure --build=x86_64-linux --host=x86_64-linux --target=mips-oe-linux-uclibc --prefix=/scratch/oe/cross/mips --exec_prefix=/scratch/oe/cross/mips --bindir=/scratch/oe/cross/mips/bin --sbindir=/scratch/oe/cross/mips/bin --libexecdir=/scratch/oe/cross/mips/libexec --datadir=/scratch/oe/cross/mips/share --sysconfdir=/scratch/oe/cross/mips/etc --sharedstatedir=/scratch/oe/cross/mips/com --localstatedir=/scratch/oe/cross/mips/var --libdir=/scratch/oe/cross/mips/lib --includedir=/scratch/oe/cross/mips/include --oldincludedir=/scratch/oe/cross/mips/include --infodir=/scratch/oe/cross/mips/share/info --mandir=/scratch/oe/cross/mips/share/man --enable-clocale=generic --with-gnu-ld --enable-shared --enable-languages=c,c++ --enable-threads=posix --enable-multilib --enable-c99 --enable-long-long --enable-symvers=gnu --enable-libstdcxx-pch --program-prefix=mips-oe-linux-uclibc- --enable-target-optspace --enable-lto --enable-libssp --disable-bootstrap --disable-libgomp --disable-libmudflap --with-local-prefix=/scratch/oe/sysroots/mips-oe-linux-uclibc/usr --with-gxx-include-dir=/scratch/oe/sysroots/mips-oe-linux-uclibc//usr/include/c++ --with-sysroot=/scratch/oe/sysroots/mips-oe-linux-uclibc --with-build-sysroot=/scratch/oe/sysroots/mips-oe-linux-uclibc --disable-libunwind-exceptions --with-mpfr=/scratch/oe/sysroots/x86_64-linux/usr --with-system-zlib --disable-decimal-float --program-prefix=mips-oe-linux-uclibc- --disable-__cxa_atexit --disable-nls Thread model: posix gcc version 4.5.1 20100627 (prerelease) (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44734
[Bug target/44685] New: internal compiler error: in final_scan_insn, at final.c:2650 while compiling program with complex types
latest 4.5 branch is ICEing on the following code on mips. It works file with
-Os and -O2 and above but ICE's with -O1 or -O0, note that -fPIC is required to
reproduce it with -fPIC its ok.
Here is command to reproduce
mips-oe-linux-gcc -march=mips32 -mabi=32 b.c -c -fPIC
b.c: In function __casin:
b.c:19:1: error: could not split insn
(call_insn 20 55 21 b.c:13 (parallel [
(set (reg:DF 32 $f0)
(call (mem:SI (reg:SI 25 $25) [0 S4 A32])
(unspec [
(const_int 16 [0x10])
(symbol_ref:SI (__casinh) [flags 0x41]
function_decl 0xb7721e00 __casinh)
] 55)))
(set (reg:DF 34 $f2)
(call (mem:SI (reg:SI 25 $25) [0 S4 A32])
(const_int 16 [0x10])))
(clobber (reg:SI 31 $31))
]) 574 {call_value_multiple_internal} (nil)
(expr_list:REG_DEP_TRUE (use (reg:SI 79 $fakec))
(expr_list:REG_DEP_TRUE (use (reg:SI 28 $28))
(expr_list:REG_DEP_TRUE (use (reg:DC 4 $4))
(nil)
b.c:19:1: internal compiler error: in final_scan_insn, at final.c:2650
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
gcc is compiled with following options
Using built-in specs.
COLLECT_GCC=mips-oe-linux-gcc
COLLECT_LTO_WRAPPER=/scratch/oe/cross/mips/libexec/gcc/mips-oe-linux/4.5.1/lto-wrapper
Target: mips-oe-linux
Configured with:
/scratch/oe/work/mips-oe-linux/gcc-cross-intermediate-4.5-r1+svnr161450/gcc-4.5/configure
--build=i686-linux --host=i686-linux --target=mips-oe-linux
--prefix=/scratch/oe/cross/mips --exec_prefix=/scratch/oe/cross/mips
--bindir=/scratch/oe/cross/mips/bin --sbindir=/scratch/oe/cross/mips/bin
--libexecdir=/scratch/oe/cross/mips/libexec
--datadir=/scratch/oe/cross/mips/share --sysconfdir=/scratch/oe/cross/mips/etc
--sharedstatedir=/scratch/oe/cross/mips/com
--localstatedir=/scratch/oe/cross/mips/var --libdir=/scratch/oe/cross/mips/lib
--includedir=/scratch/oe/cross/mips/include
--oldincludedir=/scratch/oe/cross/mips/include
--infodir=/scratch/oe/cross/mips/share/info
--mandir=/scratch/oe/cross/mips/share/man
--with-local-prefix=/scratch/oe/sysroots/mips-oe-linux/usr --enable-shared
--disable-multilib --disable-threads --enable-languages=c
--program-prefix=mips-oe-linux-
--with-sysroot=/scratch/oe/sysroots/mips-oe-linux
--with-build-sysroot=/scratch/oe/sysroots/mips-oe-linux
--enable-target-optspace --disable-libmudflap --disable-libgomp
--disable-libssp --with-mips-plt --program-prefix=mips-oe-linux-
--enable-__cxa_atexit
Thread model: single
gcc version 4.5.1 20100627 (prerelease) (GCC)
--
Summary: internal compiler error: in final_scan_insn, at
final.c:2650 while compiling program with complex types
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: raj dot khem at gmail dot com
GCC build triplet: x86_64-linux
GCC host triplet: x86_64-linux
GCC target triplet: mips-oe-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44685
[Bug target/44685] internal compiler error: in final_scan_insn, at final.c:2650 while compiling program with complex types
--- Comment #1 from raj dot khem at gmail dot com 2010-06-27 07:11 --- Created an attachment (id=21013) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21013action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44685
[Bug target/44392] [4.5/4.6 Regression] libgcc compile with --enable-target-optspace (-Os) causes recursion in __bswapsi2
--- Comment #7 from raj dot khem at gmail dot com 2010-06-22 15:42 --- (In reply to comment #6) Why not just: TARGET_EITHER (arm_arch6 || !optimize_size) ? That !arm_arch6 is completely redundant there. Hi Ramana the patch along with Jakub's suggestions works for me. Thx -Khem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44392
[Bug target/44603] out of range branch generated in thumb code.
--- Comment #4 from raj dot khem at gmail dot com 2010-06-21 17:45 --- (In reply to comment #3) Dupe of PR43961? yes seems so. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44603
[Bug target/44603] New: out of range branch generated in thumb code.
attached example fails to compile when no -On is used. $ arm-oe-linux-uclibceabi-gcc -mthumb -fPIC a.i -c /tmp/cc1iMNtS.s: Assembler messages: /tmp/cc1iMNtS.s:4814: Error: branch out of range If -O1 or any other -O optlevel is used then it works fine. -- Summary: out of range branch generated in thumb code. Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: raj dot khem at gmail dot com GCC build triplet: x86_64-linux GCC host triplet: x86_64-linux GCC target triplet: arm-oe-linux-uclibceabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44603
[Bug target/44603] out of range branch generated in thumb code.
--- Comment #1 from raj dot khem at gmail dot com 2010-06-20 22:01 --- Created an attachment (id=20949) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20949action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44603
[Bug c/44586] New: gcc does not warn about casting non-variadic types to variadic types
the folowing testcase does a casting which results in undefined behaviour but
gcc does not warn about it.
ypedef int (*bar_t)(int x, int y, ...);
int foo(int x, int y) {
return x+y;
}
void f(int x, int y) {
bar_t bar;
/* Cast foo to variadic type... undefined behaviour */
bar = (bar_t) foo;
(*bar)(x,y);
}
--
Summary: gcc does not warn about casting non-variadic types to
variadic types
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: raj dot khem at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44586
[Bug target/44557] New: internal compiler error: in gen_thumb_movhi_clobber, at config/arm/arm.md:5811
X-Bugzilla-Reason: CC gcc built from recent gcc-4_5-branch ICE's compiling attached testcase for arm with following options -mthumb -O1 -fno-omit-frame-pointer $ arm-oe-linux-uclibceabi-gcc -v Using built-in specs. COLLECT_GCC=arm-oe-linux-uclibceabi-gcc COLLECT_LTO_WRAPPER=/home/kraj/work/oe/tmp/cross/armv5te/libexec/gcc/arm-oe-linux-uclibceabi/4.5.1/lto-wrapper Target: arm-oe-linux-uclibceabi Configured with: /home/kraj/work/oe/tmp/work/armv5te-oe-linux-uclibceabi/gcc-cross-4.5-r1+svnr160764/gcc-4.5/configure --build=x86_64-linux --host=x86_64-linux --target=arm-oe-linux-uclibceabi --prefix=/home/kraj/work/oe/tmp/cross/armv5te --exec_prefix=/home/kraj/work/oe/tmp/cross/armv5te --bindir=/home/kraj/work/oe/tmp/cross/armv5te/bin --sbindir=/home/kraj/work/oe/tmp/cross/armv5te/bin --libexecdir=/home/kraj/work/oe/tmp/cross/armv5te/libexec --datadir=/home/kraj/work/oe/tmp/cross/armv5te/share --sysconfdir=/home/kraj/work/oe/tmp/cross/armv5te/etc --sharedstatedir=/home/kraj/work/oe/tmp/cross/armv5te/com --localstatedir=/home/kraj/work/oe/tmp/cross/armv5te/var --libdir=/home/kraj/work/oe/tmp/cross/armv5te/lib --includedir=/home/kraj/work/oe/tmp/cross/armv5te/include --oldincludedir=/home/kraj/work/oe/tmp/cross/armv5te/include --infodir=/home/kraj/work/oe/tmp/cross/armv5te/share/info --mandir=/home/kraj/work/oe/tmp/cross/armv5te/share/man --enable-clocale=generic --with-gnu-ld --enable-shared --enable-languages=c,c++ --enable-threads=posix --enable-multilib --enable-c99 --enable-long-long --enable-symvers=gnu --enable-libstdcxx-pch --program-prefix=arm-oe-linux-uclibceabi- --enable-lto --enable-libssp --disable-bootstrap --disable-libgomp --disable-libmudflap --with-float=soft --with-local-prefix=/home/kraj/work/oe/tmp/sysroots/armv5te-oe-linux-uclibceabi/usr --with-gxx-include-dir=/home/kraj/work/oe/tmp/sysroots/armv5te-oe-linux-uclibceabi//usr/include/c++ --with-sysroot=/home/kraj/work/oe/tmp/sysroots/armv5te-oe-linux-uclibceabi --with-build-sysroot=/home/kraj/work/oe/tmp/sysroots/armv5te-oe-linux-uclibceabi --disable-libunwind-exceptions --with-mpfr=/home/kraj/work/oe/tmp/sysroots/x86_64-linux/usr --with-system-zlib --disable-decimal-float --program-prefix=arm-oe-linux-uclibceabi- --disable-__cxa_atexit --disable-nls Thread model: posix gcc version 4.5.1 20100614 (prerelease) (GCC) -- Summary: internal compiler error: in gen_thumb_movhi_clobber, at config/arm/arm.md:5811 Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: raj dot khem at gmail dot com GCC build triplet: x86_64-linux GCC host triplet: x86_64-linux GCC target triplet: arm-oe-linux-uclibceabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44557
[Bug target/44557] internal compiler error: in gen_thumb_movhi_clobber, at config/arm/arm.md:5811
X-Bugzilla-Reason: CC --- Comment #1 from raj dot khem at gmail dot com 2010-06-16 14:04 --- Created an attachment (id=20928) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20928action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44557
[Bug libstdc++/44461] __cxa_end_cleanup ends up in wrong section i.e. not in .text
--- Comment #7 from raj dot khem at gmail dot com 2010-06-09 15:48 --- thanks Paolo, we would need this patch on 4.5 branch as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44461
[Bug libstdc++/44461] New: __cxa_end_cleanup ends up in wrong section i.e. not in .text
__cxa_end_cleanup on arm is inline assembly in libsupc++/eh_arm.cc in one case when libstdc++ was compiled with -Os this inline assembly is emitted at the beginning and the section before that is a .debug section as a result this ends up in .debug section and the symbol goes missing in libstdc++ as seen below 000a7ff0 t cxa_end_cleanup_veneer 0009ce84 T __cxa_begin_cleanup 00382842 N __cxa_end_cleanup 0009f090 T __cxa_vec_cleanup -- Summary: __cxa_end_cleanup ends up in wrong section i.e. not in .text Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: raj dot khem at gmail dot com GCC build triplet: x86_64-linux GCC host triplet: x86_64-linux GCC target triplet: arm-oe-linux-uclibceabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44461
[Bug libstdc++/44461] __cxa_end_cleanup ends up in wrong section i.e. not in .text
--- Comment #1 from raj dot khem at gmail dot com 2010-06-08 03:20 --- Created an attachment (id=20863) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20863action=view) the fix 2010-06-07 Khem Raj raj.k...@gmail.com * libsupc++/eh_arm.cc (__cxa_end_cleanup): Switch to .text section before emitting inline assembly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44461
[Bug libstdc++/44461] __cxa_end_cleanup ends up in wrong section i.e. not in .text
--- Comment #3 from raj dot khem at gmail dot com 2010-06-08 04:53 --- (In reply to comment #2) Confirmed, it should do a .text and then a previous. I have closed a bug where an inline-asm was not doing this too (see PR 35895). another version I had was with pushsection and popsection but then I read that these directives are ELF specific I thought not to use them .previous is also stated ELF specific in GAS manual. if its ok I can redo it with pushsection/popsection -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44461
[Bug regression/44392] New: libgcc compile with --enable-target-optspace (-Os) causes recursion in __bswapsi2
When using --enable-target-optspace on gcc 4.5 function __bswapsi2 in libgcc
generates call to itself which causes infinite recursion. Here is disassembly.
$ arm-none-linux-uclibcgnueabi-objdump -d _bswapsi2_s.o
_bswapsi2_s.o: file format elf32-littlearm
Disassembly of section .text:
__bswapsi2:
0: e92d4008push{r3, lr}
4: ebfebl 0 __bswapsi2
8: e8bd8008pop {r3, pc}
This does not happen on -O1, O2 or O3 where is computes the swapping
and does not call the libgcc function. With gcc 4.4 it does not call
libgcc function even at -Os. I have only tested it on arm architecture.
Here is little program which demonstrates it
typedef signed int SItype;
SItype
__bswapsi2 (SItype u)
{
return u) 0xff00) 24)
| (((u) 0x00ff) 8)
| (((u) 0xff00) 8)
| (((u) 0x00ff) 24));
}
here is how the gcc was built
/scratch/oe/work/armv5te-oe-linux-gnueabi/gcc-cross-intermediate-4.5-r0+svnr160043/gcc-4.5/build.x86_64-linux.arm-oe-linux-gnueabi/gcc/xgcc
-v
Using built-in specs.
COLLECT_GCC=/scratch/oe/work/armv5te-oe-linux-gnueabi/gcc-cross-intermediate-4.5-r0+svnr160043/gcc-4.5/build.x86_64-linux.arm-oe-linux-gnueabi/gcc/xgcc
Target: arm-oe-linux-gnueabi
Configured with:
/scratch/oe/work/armv5te-oe-linux-gnueabi/gcc-cross-intermediate-4.5-r0+svnr160043/gcc-4.5/configure
--build=x86_64-linux --host=x86_64-linux --target=arm-oe-linux-gnueabi
--prefix=/scratch/oe/cross/armv5te --exec_prefix=/scratch/oe/cross/armv5te
--bindir=/scratch/oe/cross/armv5te/bin --sbindir=/scratch/oe/cross/armv5te/bin
--libexecdir=/scratch/oe/cross/armv5te/libexec
--datadir=/scratch/oe/cross/armv5te/share
--sysconfdir=/scratch/oe/cross/armv5te/etc
--sharedstatedir=/scratch/oe/cross/armv5te/com
--localstatedir=/scratch/oe/cross/armv5te/var
--libdir=/scratch/oe/cross/armv5te/lib
--includedir=/scratch/oe/cross/armv5te/include
--oldincludedir=/scratch/oe/cross/armv5te/include
--infodir=/scratch/oe/cross/armv5te/share/info
--mandir=/scratch/oe/cross/armv5te/share/man
--with-local-prefix=/scratch/oe/sysroots/armv5te-oe-linux-gnueabi/usr
--enable-shared --disable-multilib --disable-threads --enable-languages=c
--program-prefix=arm-oe-linux-gnueabi-
--with-sysroot=/scratch/oe/sysroots/armv5te-oe-linux-gnueabi
--with-build-sysroot=/scratch/oe/sysroots/armv5te-oe-linux-gnueabi
--enable-target-optspace --disable-libmudflap --disable-libgomp
--disable-libssp --with-float=soft --program-prefix=arm-oe-linux-gnueabi-
--enable-__cxa_atexit
Thread model: single
gcc version 4.5.1 20100530 (prerelease) (GCC)
--
Summary: libgcc compile with --enable-target-optspace (-Os)
causes recursion in __bswapsi2
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: raj dot khem at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: arm-oe-linux-gnueabi
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 #2 from raj dot khem at gmail dot com 2010-06-02 22:52 --- (In reply to comment #1) Heh. arm does have a bswapsi pattern though - why is that expanding to a call at -Os? IIUC this pattern only triggers for armv6+ architectures. The problem I see is on a armv5te -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44392
[Bug target/44290] [4.5 Regression] __naked attribute is broken
--- Comment #20 from raj dot khem at gmail dot com 2010-05-30 06:54 --- Created an attachment (id=20777) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20777action=view) includes fix for all arms I see the problem after reading Richard's comment #10, here is some more additions to kernel workaround patch which work for me too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44290
[Bug target/44290] [4.5 Regression] __naked attribute is broken
--- Comment #19 from raj dot khem at gmail dot com 2010-05-30 05:58 --- (In reply to comment #18) Created an attachment (id=20773) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20773action=view) [edit] linux kernel workaround for attribute naked breakage This patch makes the Linux kernel add noinline and noclone attributes to functions declared __naked. This allows gcc-4.5 to build a working 2.6.34 Linux kernel for my mach-iop32x/n2100 ARM box. Khem: can you check if this kernel-side workaround fixes your problem? I have tried using __noclone__ a couple of days ago to workaround the problem //static void __attribute__((__naked__, __noinline__, __noclone__, __no_instrument_function__)) static void __attribute__((__naked__, __no_instrument_function__)) v4wb_copy_user_page(void *kto, const void *kfrom) But my gcc seems to ignore it and its generating same code for both with Os and O2 for both above cases. Hence did not solve my issue. I am using snapshot of 4.5 branch from May 20 Eventually I'd like the kernel to not use __naked, but that is non-trivial. This fix should work now and be easily backportable to older kernels. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44290
[Bug tree-optimization/44290] New: arm linux kernel crahes when built with -fipa-sra
While trying to boot linux 2.6.34 built with gcc from latest gcc-4_5-branch the kernel would not boot. Same kernel would work fine with gcc 4.4.4 Reducing to individual optimization phases. So far I have seen that when compiled with -O2 the kernel crashes however when I change the flags to -O2 -fno-ipa-sra then it works well. I don't have a small test-case as of now. I am trying to reduce it but it might take some time. Meanwhile I wanted to open the bug so that if someone else has information on similar issue can chime in. -- Summary: arm linux kernel crahes when built with -fipa-sra Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: raj dot khem at gmail dot com GCC build triplet: x86_64-linux GCC host triplet: x86_64-linux GCC target triplet: arm-none-linux-uclibcgnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44290
[Bug tree-optimization/44290] arm linux kernel crahes when built with -fipa-sra
--- Comment #1 from raj dot khem at gmail dot com 2010-05-27 07:06 --- Created an attachment (id=20759) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20759action=view) preprocessed testcase OK so here is one file which whic is compiled with -O2 -fno-ipa-sra and rest of kernel with -O2 and it works ok. So something is going wrong in this file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44290
[Bug tree-optimization/44290] arm linux kernel crahes when built with -fipa-sra
--- Comment #2 from raj dot khem at gmail dot com 2010-05-27 07:12 ---
here is diff of two assembly outputs
$ diff copypage-v4wb.s copypage-v4wb.no-ipa-sra.S -u
--- copypage-v4wb.s 2010-05-27 00:11:03.130607878 -0700
+++ copypage-v4wb.no-ipa-sra.S 2010-05-27 00:10:54.790615578 -0700
@@ -120,19 +120,30 @@
v4wb_copy_user_highpage:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
- stmfd sp!, {r4, lr}
- mov r1, sp
- bic r4, r1, #8128
+ stmfd sp!, {r4, r5, r6, lr}
+ mov ip, sp
+ bic r4, ip, #8128
bic r4, r4, #63
- ldr r1, [r4, #4]
- add r1, r1, #1
- str r1, [r4, #4]
- ldr r1, [r4, #4]
- add r1, r1, #1
- str r1, [r4, #4]
- ldr r1, [r3, #0]
- ldr r1, [r1, #332]
- tst r1, #1
+ ldr ip, [r4, #4]
+ add ip, ip, #1
+ str ip, [r4, #4]
+ ldr ip, .L8
+ ldr lr, [r4, #4]
+ ldr r6, [ip, #0]
+ add lr, lr, #1
+ rsb r6, r6, r0
+ mov r6, r6, asr #5
+ mov r6, r6, asl #12
+ add r6, r6, #-1073741824
+ str lr, [r4, #4]
+ ldr r5, [ip, #0]
+ ldr r0, [r3, #0]
+ rsb r5, r5, r1
+ ldr r0, [r0, #332]
+ mov r5, r5, asr #5
+ mov r5, r5, asl #12
+ tst r0, #1
+ add r5, r5, #-1073741824
beq .L6
bic r2, r2, #4080
bic r0, r2, #15
@@ -140,6 +151,8 @@
ldr r2, [r3, #20]
bl arm926_flush_user_cache_range
.L6:
+ mov r0, r6
+ mov r1, r5
bl v4wb_copy_user_page
ldr r3, [r4, #4]
sub r3, r3, #1
@@ -147,7 +160,11 @@
ldr r3, [r4, #4]
sub r3, r3, #1
str r3, [r4, #4]
- ldmfd sp!, {r4, pc}
+ ldmfd sp!, {r4, r5, r6, pc}
+.L9:
+ .align 2
+.L8:
+ .word mem_map
.size v4wb_copy_user_highpage, .-v4wb_copy_user_highpage
.global v4wb_user_fns
.section.init.data,aw,%progbits
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44290
[Bug tree-optimization/44290] [4.5 Regression] arm linux kernel crahes when built with -fipa-sra
--- Comment #4 from raj dot khem at gmail dot com 2010-05-27 17:25 --- $ /home/kraj/work/cross/arm-none-linux-uclibcgnueabi/tools/bin/arm-none-linux-uclibcgnueabi-gcc -O2 -fno-ipa-sra -S -v copypage-v4wb.i Using built-in specs. COLLECT_GCC=/home/kraj/work/cross/arm-none-linux-uclibcgnueabi/tools/bin/arm-none-linux-uclibcgnueabi-gcc COLLECT_LTO_WRAPPER=/home/kraj/work/cross/arm-none-linux-uclibcgnueabi/tools/libexec/gcc/arm-none-linux-uclibcgnueabi/4.5.1/lto-wrapper Target: arm-none-linux-uclibcgnueabi Configured with: /home/kraj/work/cross/arm-none-linux-uclibcgnueabi/../../gcc-4.5-20100520/configure --target=arm-none-linux-uclibcgnueabi --prefix=/home/kraj/work/cross/arm-none-linux-uclibcgnueabi/tools --with-sysroot=/home/kraj/work/cross/arm-none-linux-uclibcgnueabi/sysroot --enable-__cxa_atexit --disable-libssp --disable-libgomp --disable-libmudflap --enable-languages=c,c++ Thread model: posix gcc version 4.5.1 20100520 (prerelease) (GCC) COLLECT_GCC_OPTIONS='-O2' '-fno-ipa-sra' '-S' '-v' /home/kraj/work/cross/arm-none-linux-uclibcgnueabi/tools/libexec/gcc/arm-none-linux-uclibcgnueabi/4.5.1/cc1 -fpreprocessed copypage-v4wb.i -quiet -dumpbase copypage-v4wb.i -auxbase copypage-v4wb -O2 -version -fno-ipa-sra -o copypage-v4wb.s GNU C (GCC) version 4.5.1 20100520 (prerelease) (arm-none-linux-uclibcgnueabi) compiled by GNU C version 4.4.3, GMP version 4.3.2, MPFR version 2.4.2-p1, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C (GCC) version 4.5.1 20100520 (prerelease) (arm-none-linux-uclibcgnueabi) compiled by GNU C version 4.4.3, GMP version 4.3.2, MPFR version 2.4.2-p1, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: acf86197000a593407366115824f5d00 COMPILER_PATH=/home/kraj/work/cross/arm-none-linux-uclibcgnueabi/tools/libexec/gcc/arm-none-linux-uclibcgnueabi/4.5.1/:/home/kraj/work/cross/arm-none-linux-uclibcgnueabi/tools/libexec/gcc/arm-none-linux-uclibcgnueabi/4.5.1/:/home/kraj/work/cross/arm-none-linux-uclibcgnueabi/tools/libexec/gcc/arm-none-linux-uclibcgnueabi/:/home/kraj/work/cross/arm-none-linux-uclibcgnueabi/tools/lib/gcc/arm-none-linux-uclibcgnueabi/4.5.1/:/home/kraj/work/cross/arm-none-linux-uclibcgnueabi/tools/lib/gcc/arm-none-linux-uclibcgnueabi/:/home/kraj/work/cross/arm-none-linux-uclibcgnueabi/tools/lib/gcc/arm-none-linux-uclibcgnueabi/4.5.1/../../../../arm-none-linux-uclibcgnueabi/bin/ LIBRARY_PATH=/home/kraj/work/cross/arm-none-linux-uclibcgnueabi/tools/lib/gcc/arm-none-linux-uclibcgnueabi/4.5.1/:/home/kraj/work/cross/arm-none-linux-uclibcgnueabi/tools/lib/gcc/arm-none-linux-uclibcgnueabi/4.5.1/../../../../arm-none-linux-uclibcgnueabi/lib/:/home/kraj/work/cross/arm-none-linux-uclibcgnueabi/sysroot/lib/:/home/kraj/work/cross/arm-none-linux-uclibcgnueabi/sysroot/usr/lib/ COLLECT_GCC_OPTIONS='-O2' '-fno-ipa-sra' '-S' '-v' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44290
[Bug tree-optimization/44290] [4.5 Regression] arm linux kernel crahes when built with -fipa-sra
--- Comment #5 from raj dot khem at gmail dot com 2010-05-27 17:27 --- oops that was for good case. But just remove -fno-ipa-sra to make it a failing case :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44290
[Bug target/43810] [4.5 Regression] linking results in undefined references to _savegpr_* _restgpr_*_x
--- Comment #11 from raj dot khem at gmail dot com 2010-05-19 16:25 --- (In reply to comment #10) See comment #4. I believe this is a pilot error. yeah on 4.5.0 libgcc.so is a linker script but 4.4 is still broken with this issues I guess http://gcc.gnu.org/ml/gcc-cvs/2009-09/msg00315.html needs backported to 4.4 branch as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43810
[Bug target/44067] New: internal compiler error: in rs6000_split_multireg_move, at config/rs6000/rs6000.c:16713
gcc 4.5.0 fails to build libgcc when configured as follows /scratch/oe/calamari/work/ppce500v2-oe-linux-gnuspe/gcc-cross-initial-4.5.0-r0/gcc-4.5.0/configure --build=x86_64-linux --host=x86_64-linux --target=powerpc-oe-linux-gnuspe --prefix=/scratch/oe/calamari/cross/ppce500v2 --exec_prefix=/scratch/oe/calamari/cross/ppce500v2 --bindir=/scratch/oe/calamari/cross/ppce500v2/bin --sbindir=/scratch/oe/calamari/cross/ppce500v2/bin --libexecdir=/scratch/oe/calamari/cross/ppce500v2/libexec --datadir=/scratch/oe/calamari/cross/ppce500v2/share --sysconfdir=/scratch/oe/calamari/cross/ppce500v2/etc --sharedstatedir=/scratch/oe/calamari/cross/ppce500v2/com --localstatedir=/scratch/oe/calamari/cross/ppce500v2/var --libdir=/scratch/oe/calamari/cross/ppce500v2/lib --includedir=/scratch/oe/calamari/cross/ppce500v2/include --oldincludedir=/scratch/oe/calamari/cross/ppce500v2/include --infodir=/scratch/oe/calamari/cross/ppce500v2/share/info --mandir=/scratch/oe/calamari/cross/ppce500v2/share/man --with-local-prefix=/scratch/oe/calamari/sysroots/ppce500v2-oe-linux-gnuspe/usr --with-newlib --without-headers --disable-shared --disable-threads --disable-multilib --disable-__cxa_atexit --enable-languages=c --program-prefix=powerpc-oe-linux-gnuspe- --with-sysroot=/scratch/oe/calamari/sysroots/ppce500v2-oe-linux-gnuspe --with-build-sysroot=/scratch/oe/calamari/sysroots/ppce500v2-oe-linux-gnuspe --disable-libmudflap --disable-libgomp --disable-libssp --enable-decimal-float=no --program-prefix=powerpc-oe-linux-gnuspe- It fails in libgcc /scratch/oe/calamari/work/ppce500v2-oe-linux-gnuspe/gcc-cross-initial-4.5.0-r0/gcc-4.5.0/build.x86_64-linux.powerpc-oe-linux-gnuspe/./gcc/xgcc -B/scratch/oe/calamari/work/ppce500v2-oe-linux-gnuspe/gcc-cross-initial-4.5.0-r0/gcc-4.5.0/build.x86_64-linux.powerpc-oe-linux-gnuspe/./gcc/ -mcpu=8548 -mspe=yes -mabi=spe -mfloat-gprs=double -isystem/scratch/oe/calamari/sysroots/ppce500v2-oe-linux-gnuspe/usr/include -B/scratch/oe/calamari/cross/ppce500v2/powerpc-oe-linux-gnuspe/bin/ -B/scratch/oe/calamari/cross/ppce500v2/powerpc-oe-linux-gnuspe/lib/ -isystem /scratch/oe/calamari/cross/ppce500v2/powerpc-oe-linux-gnuspe/include -isystem /scratch/oe/calamari/cross/ppce500v2/powerpc-oe-linux-gnuspe/sys-include --sysroot=/scratch/oe/calamari/sysroots/ppce500v2-oe-linux-gnuspe -isystem/scratch/oe/calamari/sysroots/x86_64-linux/usr/include -O2 -g -O2 -isystem/scratch/oe/calamari/sysroots/x86_64-linux/usr/include -O2 -g -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../.././gcc -I/scratch/oe/calamari/work/ppce500v2-oe-linux-gnuspe/gcc-cross-initial-4.5.0-r0/gcc-4.5.0/libgcc -I/scratch/oe/calamari/work/ppce500v2-oe-linux-gnuspe/gcc-cross-initial-4.5.0-r0/gcc-4.5.0/libgcc/. -I/scratch/oe/calamari/work/ppce500v2-oe-linux-gnuspe/gcc-cross-initial-4.5.0-r0/gcc-4.5.0/libgcc/../gcc -I/scratch/oe/calamari/work/ppce500v2-oe-linux-gnuspe/gcc-cross-initial-4.5.0-r0/gcc-4.5.0/libgcc/../include -DHAVE_CC_TLS -o _powidf2.o -MT _powidf2.o -MD -MP -MF _powidf2.dep -DL_powidf2 -c /scratch/oe/calamari/work/ppce500v2-oe-linux-gnuspe/gcc-cross-initial-4.5.0-r0/gcc-4.5.0/libgcc/../gcc/libgcc2.c /scratch/oe/calamari/work/ppce500v2-oe-linux-gnuspe/gcc-cross-initial-4.5.0-r0/gcc-4.5.0/libgcc/../gcc/libgcc2.c: In function __powidf2: /scratch/oe/calamari/work/ppce500v2-oe-linux-gnuspe/gcc-cross-initial-4.5.0-r0/gcc-4.5.0/libgcc/../gcc/libgcc2.c:1739:1: internal compiler error: in rs6000_split_multireg_move, at config/rs6000/rs6000.c:16713 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. If I remove -mfloat-gprs=double from the commandline then the ICE does not happen. -- Summary: internal compiler error: in rs6000_split_multireg_move, at config/rs6000/rs6000.c:16713 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: raj dot khem at gmail dot com GCC build triplet: x86_64-linux GCC host triplet: x86_64-linux GCC target triplet: powerpc-oe-linux-gnuspe http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44067
[Bug target/43810] [4.5 Regression] linking results in undefined references to _savegpr_* _restgpr_*_x
--- Comment #6 from raj dot khem at gmail dot com 2010-04-30 04:13 --- I have similar problem when building glibc for 603e. When I dump libgcc.a then it shows these symbols but they are hidden crtsavfpr.o: file format elf32-powerpc g F .text 004c .hidden _savefpr_14 0004 g F .text 0048 .hidden _savefpr_15 0008 g F .text 0044 .hidden _savefpr_16 000c g F .text 0040 .hidden _savefpr_17 0010 g F .text 003c .hidden _savefpr_18 0014 g F .text 0038 .hidden _savefpr_19 0018 g F .text 0034 .hidden _savefpr_20 001c g F .text 0030 .hidden _savefpr_21 0020 g F .text 002c .hidden _savefpr_22 0024 g F .text 0028 .hidden _savefpr_23 0028 g F .text 0024 .hidden _savefpr_24 002c g F .text 0020 .hidden _savefpr_25 0030 g F .text 001c .hidden _savefpr_26 0034 g F .text 0018 .hidden _savefpr_27 0038 g F .text 0014 .hidden _savefpr_28 003c g F .text 0010 .hidden _savefpr_29 0040 g F .text 000c .hidden _savefpr_30 0044 g F .text 0008 .hidden _savefpr_31 crtsavgpr.o: file format elf32-powerpc g F .text 004c .hidden _savegpr_14 0004 g F .text 0048 .hidden _savegpr_15 0008 g F .text 0044 .hidden _savegpr_16 000c g F .text 0040 .hidden _savegpr_17 0010 g F .text 003c .hidden _savegpr_18 0014 g F .text 0038 .hidden _savegpr_19 0018 g F .text 0034 .hidden _savegpr_20 001c g F .text 0030 .hidden _savegpr_21 0020 g F .text 002c .hidden _savegpr_22 0024 g F .text 0028 .hidden _savegpr_23 0028 g F .text 0024 .hidden _savegpr_24 002c g F .text 0020 .hidden _savegpr_25 0030 g F .text 001c .hidden _savegpr_26 0034 g F .text 0018 .hidden _savegpr_27 0038 g F .text 0014 .hidden _savegpr_28 003c g F .text 0010 .hidden _savegpr_29 0040 g F .text 000c .hidden _savegpr_30 0044 g F .text 0008 .hidden _savegpr_31 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43810
[Bug target/43810] [4.5 Regression] linking results in undefined references to _savegpr_* _restgpr_*_x
--- Comment #7 from raj dot khem at gmail dot com 2010-04-30 04:34 ---
calls to _savegpr_31 and _restgpr_31_x are only generated when compiling libgcc
with -Os same compiled with -O2 it does not emit the calls
here is a reduced testcase from crtstuff.c compile it will -Os and then with
-O2
typedef void (*func_ptr) (void);
static func_ptr __CTOR_END__[1]
__attribute__((section(.ctors), aligned(sizeof(func_ptr
= { (func_ptr) 0 };
static void __attribute__((used))
__do_global_ctors_aux (void)
{
func_ptr *p;
for (p = __CTOR_END__ - 1; *p != (func_ptr) -1; p--)
(*p) ();
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43810
[Bug target/43810] [4.5 Regression] linking results in undefined references to _savegpr_* _restgpr_*_x
--- Comment #8 from raj dot khem at gmail dot com 2010-04-30 04:55 --- below is the linker command that reports liking error. /scratch/oe/efika/cross/ppc603e/lib/gcc/powerpc-oe-linux/4.5.0/crtend.o: In function `__do_global_ctors_aux': crtstuff.c:(.text+0xc): undefined reference to `_savegpr_31' collect2: ld returned 1 exit status as we can see the failure is seen in crtend.o and in the linking order libgcc is specified before crtend.o therefore it does not pick the required object from libgcc.a if I add -lgcc after crtend.o then it links successfully. /scratch/oe/efika/cross/ppc603e/bin/powerpc-oe-linux-gcc -nostdlib -nostartfiles -o /scratch/oe/efika/work/ppc603e-oe-linux/eglibc-2.11-r10.4/build-powerpc-oe-linux/posix/getconf -Wl,-dynamic-linker=/lib/ld.so.1 -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both /scratch/oe/efika/work/ppc603e-oe-linux/eglibc-2.11-r10.4/build-powerpc-oe-linux/csu/crt1.o /scratch/oe/efika/work/ppc603e-oe-linux/eglibc-2.11-r10.4/build-powerpc-oe-linux/csu/crti.o `/scratch/oe/efika/cross/ppc603e/bin/powerpc-oe-linux-gcc -mcpu=603e -mhard-float --print-file-name=crtbegin.o` /scratch/oe/efika/work/ppc603e-oe-linux/eglibc-2.11-r10.4/build-powerpc-oe-linux/posix/getconf.o -Wl,-rpath-link=/scratch/oe/efika/work/ppc603e-oe-linux/eglibc-2.11-r10.4/build-powerpc-oe-linux:/scratch/oe/efika/work/ppc603e-oe-linux/eglibc-2.11-r10.4/build-powerpc-oe-linux/math:/scratch/oe/efika/work/ppc603e-oe-linux/eglibc-2.11-r10.4/build-powerpc-oe-linux/elf:/scratch/oe/efika/work/ppc603e-oe-linux/eglibc-2.11-r10.4/build-powerpc-oe-linux/dlfcn:/scratch/oe/efika/work/ppc603e-oe-linux/eglibc-2.11-r10.4/build-powerpc-oe-linux/nss:/scratch/oe/efika/work/ppc603e-oe-linux/eglibc-2.11-r10.4/build-powerpc-oe-linux/nis:/scratch/oe/efika/work/ppc603e-oe-linux/eglibc-2.11-r10.4/build-powerpc-oe-linux/rt:/scratch/oe/efika/work/ppc603e-oe-linux/eglibc-2.11-r10.4/build-powerpc-oe-linux/resolv:/scratch/oe/efika/work/ppc603e-oe-linux/eglibc-2.11-r10.4/build-powerpc-oe-linux/crypt:/scratch/oe/efika/work/ppc603e-oe-linux/eglibc-2.11-r10.4/build-powerpc-oe-linux/nptl /scratch/oe/efika/work/ppc603e-oe-linux/eglibc-2.11-r10.4/build-powerpc-oe-linux/libc.so.6 /scratch/oe/efika/work/ppc603e-oe-linux/eglibc-2.11-r10.4/build-powerpc-oe-linux/libc_nonshared.a -lgcc `/scratch/oe/efika/cross/ppc603e/bin/powerpc-oe-linux-gcc -mcpu=603e -mhard-float --print-file-name=crtend.o` /scratch/oe/efika/work/ppc603e-oe-linux/eglibc-2.11-r10.4/build-powerpc-oe-linux/csu/crtn.o -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43810
[Bug middle-end/36282] Spurious warning asm declaration ignored due to conflict with previous rename
--- Comment #2 from raj dot khem at gmail dot com 2010-02-17 06:18 --- this warning also triggers with current head/4.5.0 -- raj dot khem at gmail dot com changed: What|Removed |Added CC||raj dot khem at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36282
[Bug target/42894] [4.5 Regression] Invalid rtl sharing in Thumb1.
--- Comment #7 from raj dot khem at gmail dot com 2010-02-12 19:39 --- you could try standalone target ../sources/gcc-trunk/configure --target=arm-none-eabi --prefix=/scratch/oss/baremetal/arm-none-eabi/tools --enable-languages=c,c++ --with-newlib and make sure that you pass -O0 -mthumb -march=armv5te to gcc when compiling the testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42894
[Bug target/42964] gcc.c-torture/compile/20001226-1.c takes too long to compile
--- Comment #1 from raj dot khem at gmail dot com 2010-02-05 16:55 --- after rebooting the machine. I dont see this happening. Closing invalid. -- raj dot khem at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42964
[Bug target/42981] New: internal compiler error: in default_secondary_reload, at targhooks.c:660
gcc ICE's when compiling attached example arm-none-eabi-gcc lib_pad.i -c -O -fPIC -mthumb ../ncurses/./base/lib_pad.c: In function pnoutrefresh: ../ncurses/./base/lib_pad.c:218: internal compiler error: in default_secondary_reload, at targhooks.c:660 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Target: arm-none-eabi Configured with: ../sources/gcc-4_4-branch/configure --target=arm-none-eabi --prefix=/scratch/oss/baremetal/arm-none-eabi/tools --enable-languages=c,c++ --with-newlib Thread model: single gcc version 4.4.4 20100203 (prerelease) (GCC) -- Summary: internal compiler error: in default_secondary_reload, at targhooks.c:660 Product: gcc Version: 4.4.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: raj dot khem at gmail dot com GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: arm-none-eabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42981
[Bug target/42981] internal compiler error: in default_secondary_reload, at targhooks.c:660
--- Comment #1 from raj dot khem at gmail dot com 2010-02-06 00:06 --- Created an attachment (id=19811) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19811action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42981
[Bug target/42964] New: gcc.c-torture/compile/20001226-1.c takes too long to compile
This testcase takes too long to compile at -O3. It freezes my box. I really did not get it to completion but I will try. Same compiles fine when gcc is configured for native build. So it seems like mips specific issue. here is how gcc is configured Configured with: /sources/gcc-trunk/configure --target=mips64-none-elf --prefix=/scratch/baremetal/mips64-none-elf/tools --enable-multilib --disable-werror --enable-languages=c,c++ --with-newlib Thread model: single gcc version 4.5.0 20100204 (experimental) (GCC) I tried same test with gcc 4.1(mips64-elf) and it took about 48 seconds and about 11s for native compile. -- Summary: gcc.c-torture/compile/20001226-1.c takes too long to compile Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: raj dot khem at gmail dot com GCC build triplet: x86_64-linux GCC host triplet: x86_64-linux GCC target triplet: mips64-none-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42964
[Bug target/42947] New: multilib and startup files paths differ on sh4 with -m4 and without -m4 where -m4 is default multilib
Configuring with following options --build=x86_64-linux --host=x86_64-linux --target=sh4-oe-linux --prefix=/scratch/oe/qemush4/cross/sh4 --exec_prefix=/scratch/oe/qemush4/cross/sh4 --bindir=/scratch/oe/qemush4/cross/sh4/bin --sbindir=/scratch/oe/qemush4/cross/sh4/bin --libexecdir=/scratch/oe/qemush4/cross/sh4/libexec --datadir=/scratch/oe/qemush4/cross/sh4/share --sysconfdir=/scratch/oe/qemush4/cross/sh4/etc --sharedstatedir=/scratch/oe/qemush4/cross/sh4/com --localstatedir=/scratch/oe/qemush4/cross/sh4/var --libdir=/scratch/oe/qemush4/cross/sh4/lib --includedir=/scratch/oe/qemush4/cross/sh4/include --oldincludedir=/scratch/oe/qemush4/cross/sh4/include --infodir=/scratch/oe/qemush4/cross/sh4/share/info --mandir=/scratch/oe/qemush4/cross/sh4/share/man --with-local-prefix=/scratch/oe/qemush4/staging/sh4-oe-linux/usr --enable-shared --disable-multilib --disable-threads --enable-languages=c --enable-target-optspace --program-prefix=sh4-oe-linux- --with-sysroot=/scratch/oe/qemush4/staging/sh4-oe-linux --with-build-sysroot=/scratch/oe/qemush4/staging/sh4-oe-linux --disable-libmudflap --disable-libgomp --disable-libssp --enable-__cxa_atexit Thread model: single gcc version 4.5.0 20100127 (experimental) (GCC) The compilation fails during libgcc build because its not able to find crti.o Reducing the problem, when -m4 is explicitly mentioned on the commandline then gcc calls collect2 with different parameters. with -m4 /scratch/oe/qemush4/work/sh4-oe-linux/gcc-cross-intermediate-4.5+svnr156268-r0/gcc-4.5+svnr156268/build.x86_64-linux.sh4-oe-linux/gcc/collect2 --sysroot=/scratch/oe/qemush4/staging/sh4-oe-linux/m4 --eh-frame-hdr -m shlelf_linux -dynamic-linker /lib/ld-linux.so.2 crt1.o crti.o /scratch/oe/qemush4/work/sh4-oe-linux/gcc-cross-intermediate-4.5+svnr156268-r0/gcc-4.5+svnr156268/build.x86_64-linux.sh4-oe-linux/gcc/crtbegin.o -L/scratch/oe/qemush4/work/sh4-oe-linux/gcc-cross-intermediate-4.5+svnr156268-r0/gcc-4.5+svnr156268/build.x86_64-linux.sh4-oe-linux/gcc /tmp/ccwddCby.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /scratch/oe/qemush4/work/sh4-oe-linux/gcc-cross-intermediate-4.5+svnr156268-r0/gcc-4.5+svnr156268/build.x86_64-linux.sh4-oe-linux/gcc/crtend.o crtn.o /scratch/oe/qemush4/cross/sh4/sh4-oe-linux/bin/ld: crt1.o: No such file: No such file or directory without -m4 COLLECT_GCC_OPTIONS='-v' '-B/scratch/oe/qemush4/work/sh4-oe-linux/gcc-cross-intermediate-4.5+svnr156268-r0/gcc-4.5+svnr156268/build.x86_64-linux.sh4-oe-linux/gcc' /scratch/oe/qemush4/work/sh4-oe-linux/gcc-cross-intermediate-4.5+svnr156268-r0/gcc-4.5+svnr156268/build.x86_64-linux.sh4-oe-linux/gcc/collect2 --sysroot=/scratch/oe/qemush4/staging/sh4-oe-linux --eh-frame-hdr -m shlelf_linux -dynamic-linker /lib/ld-linux.so.2 /scratch/oe/qemush4/staging/sh4-oe-linux/usr/lib/crt1.o /scratch/oe/qemush4/staging/sh4-oe-linux/usr/lib/crti.o /scratch/oe/qemush4/work/sh4-oe-linux/gcc-cross-intermediate-4.5+svnr156268-r0/gcc-4.5+svnr156268/build.x86_64-linux.sh4-oe-linux/gcc/crtbegin.o -L/scratch/oe/qemush4/work/sh4-oe-linux/gcc-cross-intermediate-4.5+svnr156268-r0/gcc-4.5+svnr156268/build.x86_64-linux.sh4-oe-linux/gcc -L/scratch/oe/qemush4/staging/sh4-oe-linux/usr/lib /tmp/cch1T65V.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /scratch/oe/qemush4/work/sh4-oe-linux/gcc-cross-intermediate-4.5+svnr156268-r0/gcc-4.5+svnr156268/build.x86_64-linux.sh4-oe-linux/gcc/crtend.o /scratch/oe/qemush4/staging/sh4-oe-linux/usr/lib/crtn.o --sysroot is appended with 'm4' the default multilib is m4 so it should have looked under base sysroot like it did when no -m4 was used and crti.o and crtn.o are not used with absolute path if I use any other option other than -m4 say -m4-nofpu it works ok. It works ok on gcc 4.4 may be http://gcc.gnu.org/ml/gcc-patches/2009-04/msg00432.html is related to this. -- Summary: multilib and startup files paths differ on sh4 with -m4 and without -m4 where -m4 is default multilib Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: raj dot khem at gmail dot com GCC build triplet: x86_64-linux GCC host triplet: x86_64-linux GCC target triplet: sh4-oe-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42947
[Bug target/42894] New: ICE internal consistency failure
on arm compiling attached file gcc ICE's arm-oe-linux-uclibceabi-gcc -mthumb -O0 select.i work fine at higher O level and also in arm mode. libc/sysdeps/linux/common/select.c: In function '__syscall_select': libc/sysdeps/linux/common/select.c:75:73: error: invalid rtl sharing found in the insn (insn 81 80 82 (unspec_volatile [ (const:SI (unspec:SI [ (symbol_ref:SI (__libc_errno) [flags 0x60] var_decl 0x7fca82ba61e0 __libc_errno) (const_int 3 [0x3]) (const (unspec:SI [ (const_int 0 [0x0]) ] 21)) (const_int 4 [0x4]) ] 20)) ] 6) -1 (nil)) libc/sysdeps/linux/common/select.c:75:73: error: shared rtx (const:SI (unspec:SI [ (symbol_ref:SI (__libc_errno) [flags 0x60] var_decl 0x7fca82ba61e0 __libc_errno) (const_int 3 [0x3]) (const (unspec:SI [ (const_int 0 [0x0]) ] 21)) (const_int 4 [0x4]) ] 20)) libc/sysdeps/linux/common/select.c:75:73: internal compiler error: internal consistency failure -- Summary: ICE internal consistency failure Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: raj dot khem at gmail dot com GCC build triplet: x86_64-linux GCC host triplet: x86_64-linux GCC target triplet: arm-oe-linux-uclibceabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42894
[Bug target/42894] ICE internal consistency failure
--- Comment #1 from raj dot khem at gmail dot com 2010-01-28 07:49 --- Created an attachment (id=19737) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19737action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42894
[Bug debug/42638] New: stack trace shows wrong value for a formal parameter in call-chain
When a formal parameter 1 is not stored on stack the location list mark the
life of this parameter in DW_OP_reg0 however it does not consider the function
calls that would be made in the function in question and the fact that eax can
be destroyed down the call chain. Attached example demonstrates the problem.
gcc -m32 -O -g try.c
and here is .gdbinit file which would show the problem
file a.out
b 69
b 71
r
bt
c
bt
c
q
The sample looks like this
Breakpoint 1 at 0x80483b7: file try.c, line 69.
Breakpoint 2 at 0x80483bd: file try.c, line 71.
Breakpoint 1, __sfvwrite (fp=0xd810, uio=0x804a018) at try.c:69
69 {
#0 __sfvwrite (fp=0xd810, uio=0x804a018) at try.c:69
#1 0x080483e8 in __sprint (fp=0xd810, uio=0x804a018) at try.c:63
#2 0x0804840d in sprint (fp=0xd810, uio=0x804a018) at try.c:74
#3 0x08048436 in main () at try.c:81
Breakpoint 2, __sfvwrite (fp=0xd810, uio=0x804a018) at try.c:71
71 }
#0 __sfvwrite (fp=0xd810, uio=0x804a018) at try.c:71
#1 0x080483e8 in __sprint (fp=0x0, uio=0x804a018) at try.c:63 -- fp is
wrong
#2 0x0804840d in sprint (fp=0xd810, uio=0x804a018) at try.c:74
#3 0x08048436 in main () at try.c:81
Program exited normally.
observe the value of frame 1 formal parameter 'fp' in backtrace.
--
Summary: stack trace shows wrong value for a formal parameter in
call-chain
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: raj dot khem at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42638
[Bug debug/42638] stack trace shows wrong value for a formal parameter in call-chain
--- Comment #1 from raj dot khem at gmail dot com 2010-01-06 20:27 --- Created an attachment (id=19489) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19489action=view) C testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42638
[Bug debug/42638] stack trace shows wrong value for a formal parameter in call-chain
--- Comment #2 from raj dot khem at gmail dot com 2010-01-06 20:28 --- Created an attachment (id=19490) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19490action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42638
[Bug debug/42638] stack trace shows wrong value for a formal parameter in call-chain
--- Comment #3 from raj dot khem at gmail dot com 2010-01-06 22:34 --- http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01317.html could be the fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42638
[Bug regression/42632] New: unimplemented: inlining failed in call to �pskb_trim�: recursive inlining
Attached testcase fails with gcc trunk when compiled with -O2 it works ok with -O1. This works fine with gcc 4.4/-O2 -- Summary: unimplemented: inlining failed in call to pskb_trim: recursive inlining Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: raj dot khem at gmail dot com GCC build triplet: i686-linux GCC host triplet: i686-linux GCC target triplet: i686-oe-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42632
[Bug regression/42632] unimplemented: inlining failed in call to �pskb_trim�: recursive inlining
--- Comment #1 from raj dot khem at gmail dot com 2010-01-06 06:08 --- Created an attachment (id=19482) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19482action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42632
[Bug middle-end/42398] New: internal compiler error: in sra_modify_expr, at tree-sra.c:2175
Attached testcase from linux kernel fails to compile with latest trunk rev 155302 on mips architecture. options to pass -c -O1 $ mips-oe-linux-gcc y.c -c -O1 y.c: In function ptrace_setregs: y.c:12917:1: internal compiler error: in sra_modify_expr, at tree-sra.c:2175 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: internal compiler error: in sra_modify_expr, at tree- sra.c:2175 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: raj dot khem at gmail dot com GCC build triplet: x86_64-linux GCC host triplet: x86_64-linux GCC target triplet: mips-oe-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42398
[Bug middle-end/42398] internal compiler error: in sra_modify_expr, at tree-sra.c:2175
--- Comment #1 from raj dot khem at gmail dot com 2009-12-17 08:36 --- Created an attachment (id=19334) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19334action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42398
[Bug middle-end/42372] New: Error: undefined symbol `.LPIC7' in operation
attached testcase fails on trunk for arm target with the following optset -c -fgnu89-inline -Os -frename-registers it works ok with -O2 or -O3 /tmp/cc9PcQw8.s: Assembler messages: /tmp/cc9PcQw8.s:438: Error: undefined symbol `.LPIC7' in operation -- Summary: Error: undefined symbol `.LPIC7' in operation Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: raj dot khem at gmail dot com GCC build triplet: x86_64-linux GCC host triplet: x86_64-linux GCC target triplet: arm-oe-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42372
[Bug middle-end/42372] Error: undefined symbol `.LPIC7' in operation
--- Comment #1 from raj dot khem at gmail dot com 2009-12-14 22:51 --- Created an attachment (id=19300) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19300action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42372
[Bug c/41151] New: Gas fails to consume the assembly Error: offset too big
When compiling the test program arm-none-linux-gnueabi-gcc -march=armv7-a -O2 -c -o ltest.o ltest.i Assembler fails to assemble it and emits the error Error: offset too big If I do not use -march=armv7-a it works ok and also if I dont use O2 it compiles fine. -- Summary: Gas fails to consume the assembly Error: offset too big Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: raj dot khem at gmail dot com GCC build triplet: x86_64-linux GCC host triplet: x86_64-linux GCC target triplet: arm-none-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41151
[Bug c/41151] Gas fails to consume the assembly Error: offset too big
--- Comment #1 from raj dot khem at gmail dot com 2009-08-24 06:24 --- Created an attachment (id=18417) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18417action=view) preprocessed testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41151
[Bug tree-optimization/37433] [4.4 Regression] tree check: expected function_decl, have string_cst in ccp_fold, at tree-ssa-ccp.c:1050
--- Comment #10 from raj dot khem at gmail dot com 2008-11-08 04:56 --- on arm I get /home/kraj/work/cross/arm-none-linux-gnueabi/obj/gcc3/gcc/xgcc -B/home/kraj/work/cross/arm-none-linux-gnueabi/obj/gcc3/gcc/ -O1 -w -c -o pr37433.o /home/kraj/work/gcc-trunk/gcc/testsuite/gcc.c-torture/compile/pr37433.c (timeout = 300) pid is 7689 -7689 /home/kraj/work/gcc-trunk/gcc/testsuite/gcc.c-torture/compile/pr37433.c: In function 'regex_subst': /home/kraj/work/gcc-trunk/gcc/testsuite/gcc.c-torture/compile/pr37433.c:4: internal compiler error: tree check: expected tree that contains 'decl with visibility' structure, have 'string_cst' in arm_function_in_section_p, at config/arm/arm.c:3312 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. my gcc is Using built-in specs. Target: arm-none-linux-gnueabi Configured with: /home/kraj/work/cross/arm-none-linux-gnueabi/../../gcc-trunk/configure --target=arm-none-linux-gnueabi --prefix=/home/kraj/work/cross/arm-none-linux-gnueabi/tools --with-sysroot=/home/kraj/work/cross/arm-none-linux-gnueabi/sysroot --enable-__cxa_atexit --disable-libssp --disable-libgomp --disable-libmudflap --enable-languages=c,c++ Thread model: posix gcc version 4.4.0 20081106 (experimental) (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37433
[Bug middle-end/37026] New: GCC ICE in tree_to_gimple_tuple
I am seeing this error when compiling linux kernel 2.6.25 with gcc build from
latest 4_3 branch tip.
Here is test case
struct a {
long a1;
long a2;
};
struct b {
struct a b1;
struct a b2;
};
void bar (struct b *c)
{
c-b1 = c-b2 = ((struct a) { foo(), 0 });
}
arm-none-linux-gnueabi-gcc test.c
test.c: In function âbarâ:
test.c:12: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
--
Summary: GCC ICE in tree_to_gimple_tuple
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: raj dot khem at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: arm-none-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37026
[Bug middle-end/37026] GCC ICE in tree_to_gimple_tuple
--- Comment #1 from raj dot khem at gmail dot com 2008-08-05 07:07 --- It seems to be related to fix committed for http://gcc.gnu.org/PR36991 -- raj dot khem at gmail dot com changed: What|Removed |Added CC||jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37026
[Bug c/36350] New: GCC ICE with -frename-registers
Attached sample (reduced from glibc cvs) caused gcc built from latest
gcc-4_3-branch to ICE on arm. It worked ok with gcc 4.2.2. If I removed
-frename-registers then the ICE would not happen.
Steps to reproduce
Compile as follows
arm-none-linux-gnueabi-gcc -c -O2 sample.c -frename-registers
sample.c: In function foo:
sample.c:10: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
/* sample.c */
int foo () {
const unsigned char *inptr = 0;
unsigned char *outptr = 0;
unsigned int inval = (__extension__ ({ register unsigned int __bsx = (*(const
unsigned int *) inptr); __bsx) 0xff00u) 24) | (((__bsx)
0x00ffu) 8) | (((__bsx) 0xff00u) 8) | (((__bsx) 0x00ffu)
24)); }));
if (__builtin_expect (inval 0x7fff, 0))
{
*((unsigned int *) outptr) = inval;
}
return 0;
}
--
Summary: GCC ICE with -frename-registers
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: raj dot khem at gmail dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-none-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36350
[Bug bootstrap/34205] iwmmxt type/size error
--- Comment #10 from raj dot khem at gmail dot com 2007-11-28 16:40 --- (In reply to comment #9) If the requested bitfield is larger than the type that was previously tried for enum, then you have to widen the type to fulfill that constaint. is there a reference for this in the standards? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34205
[Bug bootstrap/34205] iwmmxt type/size error
--- Comment #8 from raj dot khem at gmail dot com 2007-11-28 00:11 --- (In reply to comment #7) s/int//. The enumerated type is implementation defined but shall be capable to represent the values of all members. Exactly and gcc for arm uses this definition to its advantage so that it can save some size. I'd read this as -fshort-enum violating that :16? GCC can smartly chose type based on enum values for size reasons and it will choose the smallest type that can represent the enum. In this testcase enum can be represented by a char. with __extension__ enum tree_code code:16 The testcase is asking for the bit-fields which are not defined for the enum type that gcc has chosen So I think error is ok here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34205
[Bug target/31490] New: Compile error section type conflict
The attached testcase does not compile for ppc64 using gcc confgured to generate ppc/ppc64 code. Attached is a reduced testcase from kernel. This error was not happening with gcc 4.2 snapshot from January. I think it is related to static inline and extern inline. compile the attached testcase gcc -m64 -c test.c test.c:51: error: __ksymtab_cpu_add_sysdev_attr_group causes a section type conflict -- Summary: Compile error section type conflict Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: raj dot khem at gmail dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: powerpc-*-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31490
[Bug target/31490] Compile error section type conflict
--- Comment #1 from raj dot khem at gmail dot com 2007-04-06 01:28 --- Created an attachment (id=1) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=1action=view) testcase testcase to reproduce the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31490
[Bug target/31165] New: Error: symbol `an_empty_string' is already defined
While compiling groff with latest snapshot from GCC 4.2 branch. I am getting this error with the attached preprocessed file with optimization turned on (O2, O1 ,Os are ones I tried). At -O0 it works ok The error from assembler /tmp/ccOeOEGl.s: Assembler messages: /tmp/ccOeOEGl.s:5826: Error: symbol `an_empty_string' is already defined /tmp/ccOeOEGl.s:5830: Error: symbol `an_empty_string' is already defined /tmp/ccOeOEGl.s:5834: Error: symbol `an_empty_string' is already defined /tmp/ccOeOEGl.s:5838: Error: symbol `an_empty_string' is already defined /tmp/ccOeOEGl.s:5842: Error: symbol `an_empty_string' is already defined -- Summary: Error: symbol `an_empty_string' is already defined Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: raj dot khem at gmail dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: powerpc-*-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31165
[Bug target/31165] Error: symbol `an_empty_string' is already defined
--- Comment #1 from raj dot khem at gmail dot com 2007-03-13 19:59 --- Created an attachment (id=13203) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13203action=view) testcase This is the preprocessed testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31165
[Bug target/29983] New: [Regression 4.2] Out of range offset for ldrd/strd intruction.
GCC 4.2 is generating wrong offset while compiling the attached example. This only happens when using -mcpu=iwmmxt option. It works ok on 3.4.6 /tmp/cc4oD6OO.s: Assembler messages: /tmp/cc4oD6OO.s:15151: Error: bad immediate value for half-word offset (328) /tmp/cc4oD6OO.s:15151: Error: bad immediate value for half-word offset (512) /tmp/cc4oD6OO.s:15151: Error: bad immediate value for half-word offset (328) /tmp/cc4oD6OO.s:15151: Error: bad immediate value for half-word offset (328) To reproduce this compile the testcase with gcc -O2 -c -mcpu=iwmmxt -- Summary: [Regression 4.2] Out of range offset for ldrd/strd intruction. Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: raj dot khem at gmail dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: armv5tel-*-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29983
[Bug target/29983] [Regression 4.2] Out of range offset for ldrd/strd intruction.
--- Comment #1 from raj dot khem at gmail dot com 2006-11-26 03:27 --- Created an attachment (id=12693) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12693action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29983
[Bug target/29984] New: [Regression 4.2]: ppc 8540 g++ segfaults on valid C++ code.
The following example is a reduced testcase from icewm. GCC when configured for
ppc-*-linux-gnuspe segfaults.
To reproduce the ICE compile like below
g++ -c -O2 testcase.C
this works fine on gcc configured with powerpc-*-linux
testcase.C
class YRect {
public:
YRect(int x, int y, int w, int h)
:xx(x), yy(y), ww(w), hh(h)
{ }
int x() const { return xx; }
int y() const { return yy; }
int width() const { return ww; }
int height() const { return hh; }
private:
int xx, yy, ww, hh;
};
void setGeometry(const YRect r);
void resize(int xiscreen) {
int dx, dy, dw, dh;
int aWidth =
(int) dw * 1/3;
int tWidth=0;
int w = aWidth;
int h;
if (h) {
if (w = 0)
w = 0;
int step;
int maxHeight;
if (h maxHeight)
h= maxHeight;
} else{
int iWidth;
if (iWidth aWidth)
aWidth = iWidth;
if (iWidth) {
if (aWidth w)
w = aWidth;
}
if (h/*quickSwitchAllIcons*/)
h += 1;
}
setGeometry(YRect(dx + ((dw - w) 1),
dy + ((dh - h) 1),
w, h));
}
--
Summary: [Regression 4.2]: ppc 8540 g++ segfaults on valid C++
code.
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: raj dot khem at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: powerpc-*-linux-gnuspe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29984
[Bug target/29983] Out of range offset for ldrd/strd intruction.
--- Comment #5 from raj dot khem at gmail dot com 2006-11-26 07:05 --- It is also reproducible using trunk and arm-none-eabi -- raj dot khem at gmail dot com changed: What|Removed |Added GCC target triplet|armv5tel-*-linux-gnueabi|arm-none-eabi Known to fail|4.2.0 |4.2.0 4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29983
[Bug target/29943] New: gcc generate incorrect alias symbols for PPC
The following example(reduced from glibc) compiles differently for ppc target
when using gcc 4.2 as compared to gcc 4.1
It generates the alias symbol as a real symbol instead of creating it as alias.
I get this correct using gcc 4.2 for arm so the problem seems to be affecting
only ppc. This also works ok with gcc 4.1
to reproduce compile the example with -O2
testcase.c
extern char **_dl_argv
__attribute__ ((section (.data.rel.ro)))
;
extern char **_dl_argv_internal __attribute__ ((visibility (hidden)))
__attribute__ ((section (.data.rel.ro)))
;
char **_dl_argv __attribute__ ((section (.data.rel.ro))) = ((void *)0);
extern __typeof (_dl_argv) _dl_argv_internal __attribute__ ((alias
(_dl_argv)));
char* foo (){
return _dl_argv_internal[0];
}
=
glibc segfaults in ld.so currently when compiled with gcc 4.2 for ppc due to
this issue.
--
Summary: gcc generate incorrect alias symbols for PPC
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: raj dot khem at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: powerpc-*-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29943
[Bug regression/29841] New: ICE: on function pointer call.
The following example (reduced from openssl) causes GCC 4.2 to ICE when -O2 is
used it works ok with -O1. It does not ICE with GCC 4.1 as well with 3.4.6
gcc -c -O2 xxx.c
xxx.c: In function 'foo':
xxx.c:8: warning: function called through a non-compatible type
xxx.c:8: note: if this code is reached, the program will abort
xxx.c:9: internal compiler error: Segmentation fault
xxx.c
typedef void (*fp)(void);
extern char* bar(void* a1, int a2);
extern char* mar(int n);
char* cptr;
void foo()
{
cptr = mar(6);
((char *(*)(void *,int (*)(void *,unsigned char **),char
**))((fp)bar))(0,0,(void*)(0));
}
--
Summary: ICE: on function pointer call.
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: raj dot khem at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i586-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29841
[Bug regression/29841] ICE: on function pointer call.
--- Comment #2 from raj dot khem at gmail dot com 2006-11-15 06:17 --- Yeah it worked fine when configured --target=i686-*-linux-gnu but not with --target=i586-*-linux-gnu --with-cpu=i586 -- raj dot khem at gmail dot com changed: What|Removed |Added Component|target |regression http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29841
[Bug libstdc++/29722] New: Linking with libsupc++.a creates link time undefined references
Compiling a small C++ test program with GCC and linking with libsupc++ is
causing the link to fail.
try.C
===
#include stdio.h
int main(){
printf(Hello);
return 0;
}
==
arm_v5t_le-gcc try.C -lsupc++
/mnt/disk2/opt/HEAD/arm_v5t_le/opt/montavista/foundation/devkit/arm/v5t_le/target/usr/lib/libsupc++.a(eh_alloc.o):
In function `__cxa_free_exception':
eh_alloc.cc:(.text.__cxa_free_exception+0xc8): undefined reference to
`std::__throw_runtime_error(char const*)'
eh_alloc.cc:(.text.__cxa_free_exception+0xd4): undefined reference to
`std::__throw_runtime_error(char const*)'
/mnt/disk2/opt/HEAD/arm_v5t_le/opt/montavista/foundation/devkit/arm/v5t_le/target/usr/lib/libsupc++.a(eh_alloc.o):
In function `__cxa_allocate_exception':
eh_alloc.cc:(.text.__cxa_allocate_exception+0xe4): undefined reference to
`std::__throw_runtime_error(char const*)'
eh_alloc.cc:(.text.__cxa_allocate_exception+0x10c): undefined reference to
`std::__throw_runtime_error(char const*)'
eh_alloc.cc:(.text.__cxa_allocate_exception+0x174): undefined reference to
`std::__throw_runtime_error(char const*)'
collect2: ld returned 1 exit status
This testcase works ok with GCC 4.1 series. and fails with GCC 4.2
I have verified the behavior on arm and x86 cross compiler.
The issue seems to be because libsupc++/guard.cc is including
#include ext/concurrence.h
and in this include it has references to above mentioned symbol which is in
libstdc++ actually. I verified that by adding -lstdc++ to above gcc invoke
statement
This scenario happens when compiling icewm package.
--
Summary: Linking with libsupc++.a creates link time undefined
references
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: raj dot khem at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: armv5tl-montavista-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29722
[Bug target/29611] New: Compiler error in inline assembly
While compiling kernel modules of 2.6.18 I hit this error. The testcase in question is attached. This file works all fine with gcc 4.1.2 prerelease. but GCC 4.2.0 prerelease throws the following error message. test1.c: In function 'unknown_bootoption': test1.c:15186: warning: asm operand 2 probably doesn't match constraints test1.c:15186: error: impossible constraint in 'asm' To reproduce this compile the attached preprocessed file with -O2 -c compile time options. This work ok when -O2 is not used. -- Summary: Compiler error in inline assembly Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: raj dot khem at gmail dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: powerpc-*-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29611
[Bug target/29611] Compiler error in inline assembly
--- Comment #1 from raj dot khem at gmail dot com 2006-10-27 05:17 --- Created an attachment (id=12499) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12499action=view) preprocessed testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29611
[Bug target/28516] [4.2 regression] arm_unwind_emit_set, at config/arm/arm.c:15419 with -fexceptions
--- Comment #18 from raj dot khem at gmail dot com 2006-09-26 22:33 --- Paul The patch is also needed on gcc-4_1-branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28516
[Bug target/28731] Local variables not aligned to 4 byte boundary causes bus error due to unaligned access
--- Comment #2 from raj dot khem at gmail dot com 2006-08-15 23:41 --- (In reply to comment #1) It was an accident that it was aligned. Use the attribute aligned to get an aligned variable if the alignment of the type is lower than what you need. Also note you are violating aliasing rules. OK I will add __attribute__ aligned to the code. -- raj dot khem at gmail dot com changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28731
[Bug target/28731] New: Local variables not aligned to 4 byte boundary causes bus error due to unaligned access
The following example core dumps on target when compiled with GCC 4.1.2
prelease and also with GCC 4.1.1
int main()
{
char k[255];
time((long*)k);
return 0;
}
The local variable is not tail aligned I think. This was aligned in gcc 3.4.3
Here is a diff of the two assembly files.
--- test.s 2006-08-14 21:12:59.0 -0700
+++ test-4.0.s 2006-08-14 21:08:30.0 -0700
@@ -5,16 +5,15 @@
.type main, #function
.proc 04
main:
- !#PROLOGUE# 0
save%sp, -368, %sp
- !#PROLOGUE# 1
- add %fp, -272, %g1
+ add %fp, -271, %g1
mov %g1, %o0
calltime, 0
nop
mov 0, %g1
mov %g1, %i0
- ret
restore
+ jmp %o7+8
+nop
.size main, .-main
- .ident GCC: (GNU) 3.4.3 (MontaVista 3.4.3-25.0.96.0600605
2006-05-06)
+ .ident GCC: (GNU) 4.1.2 20060725 (prerelease) (MontaVista 4.1.0-2)
--
Summary: Local variables not aligned to 4 byte boundary causes
bus error due to unaligned access
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: raj dot khem at gmail dot com
GCC build triplet: sparc-sun-solaris2.7
GCC host triplet: sparc-sun-solaris2.7
GCC target triplet: sparc-sun-solaris2.7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28731
[Bug target/27075] [4.1/4.2 Regression] Compiler generate incorrect assembler for __sync_fetch-* builtins on e500 aka SPE
--- Comment #14 from raj dot khem at gmail dot com 2006-07-24 19:34 --- FWIW. I also have it working using current 4.1 branch snapshot and the patch in comment #8. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27075
[Bug c/27734] New: always inline fails with function body unavailable error
This problem is seen while compiling linux kernel 2.6.16 with GCC 4.x
when compiling the below test case. Compiler produced errors attached at the
bottom. This does not happen with GCC 3.4.x but I could reproduce this with GCC
4.0 GCC 4.1.0 GCC 4.1.1 and GCC 4.2(trunk)
xx.c
==
static inline __attribute__((always_inline)) int foo(void *p)
{
return 0;
}
inline __attribute__((always_inline)) int bar(void *p)
{
return 0;
}
void baz(void *p)
{
if (bar(p))
foo(p);
}
=
how to reproduce
gcc -c xx.c
=
errors as seen:
xx.c: In function 'baz':
xx.c:7: sorry, unimplemented: inlining failed in call to 'bar': function body
not available
xx.c:12: sorry, unimplemented: called from here
--
Summary: always inline fails with function body unavailable error
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: raj dot khem at gmail dot com
GCC build triplet: i386-redhat-linux
GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27734
[Bug c/27734] always inline fails with function body unavailable error
--- Comment #2 from raj dot khem at gmail dot com 2006-05-22 21:27 --- (In reply to comment #1) I don't think this is a bug. bar is not delay from outputting as it will needs to be outputted. Now you can agrue this is a bug. Also 3.4 did not have these sorry messages so it is not a regression, just did not say it inlined the function. Agreed Also it should be noted that the Linux Kernel does not compile without optimizations on anyways for other reasons. Is it a common practice or rule of thumb. Hmmm kernel build does not complain if optimizations are not used (like glibc) so I suppose it is valid to compile it without optimizations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27734
[Bug c/27734] always inline fails with function body unavailable error
--- Comment #3 from raj dot khem at gmail dot com 2006-05-22 22:45 --- I think it can be closed invalid. -- raj dot khem at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27734
[Bug target/26765] ICE in in extract_insn with __thread and optimization
--- Comment #4 from raj dot khem at gmail dot com 2006-04-10 07:38 --- I am unable to compile glibc 2.3.6 with GCC 4.1 on all mips-linux architecture because of this ICE. -- raj dot khem at gmail dot com changed: What|Removed |Added CC||rsandifo at gcc dot gnu dot ||org Severity|normal |blocker http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26765
[Bug c/26765] New: ICE in in extract_insn, at recog.c:2036
GCC trunk gets this ICE when building glibc. The ICE happens on gcc 4.1 too.
This happens when -O2 is turned on. Here is a reduced testcase to reproduce the
problem.
example.c
==
__thread int *a = 0;
void foo (void)
{
extern int *b;
b = (int *) ((*a));
}
how to reproduce
mips-elf-gcc -O2 -c example.c
example.c: In function 'foo':
example.c:7: error: unrecognizable insn:
(insn 14 13 15 3 (set (reg/f:SI 193)
(mem/c/i:SI (lo_sum:SI (reg:SI 195)
(const:SI (unspec:SI [
(symbol_ref:SI (a) [flags 0x22] var_decl
0xb7c4a840 a)
] 114))) [2 a+0 S4 A32])) -1 (nil)
(nil))
example.c:7: internal compiler error: in extract_insn, at recog.c:2036
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
--
Summary: ICE in in extract_insn, at recog.c:2036
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: raj dot khem at gmail dot com
GCC build triplet: i386-redhat-linux
GCC host triplet: i386-redhat-linux
GCC target triplet: mips-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26765
[Bug target/26765] ICE in in extract_insn with __thread and optimization
--- Comment #3 from raj dot khem at gmail dot com 2006-03-21 01:20 --- (In reply to comment #1) First this is a bug but glibc does not support mips-elf as a target though, it does support mips-linux-gnu though. True. I found it on mips-linux-gnu but because I verified the reduced testcase on baremetal (mips-elf) thats why the target. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26765
[Bug other/20525] 4.1 make install fails trying to install ungenerated fixproto fix-header dirs.
--- Comment #3 from raj dot khem at gmail dot com 2006-03-14 05:54 --- I still see this problem on canadian cross build of sh4-montavista-linux /usr/bin/install: installing multiple files, but last argument, `/disk2/build_area/TEMP/gcc-sh_sh4_le-root/disk2/opt/montavista/foundation/devkit/sh/sh4_le/target/usr/lib/gcc/sh4-montavista-linux/4.1.0/install-tools/mkinstalldirs' is not a directory Try `/usr/bin/install --help' for more information. /usr/bin/install: cannot stat `build/fix-header': No such file or directory make[1]: *** [install-mkheaders] Error 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20525
[Bug rtl-optimization/25595] New: GCC ICE in xorg-x11 compiled in thumb
GCC produces an ICE when compiling the attached sample program. This is a
preprocessed sourcefile from xorg-x11 package.
To reproduce the problem.
arm-none-gcc -mthumb -Os -S a.i
a.i:3383: warning: '__malloc__' attribute ignored
a.i: In function 'xxGlyphs':
a.i:13406: error: insn does not satisfy its constraints:
(jump_insn:HI 255 330 270 19 (parallel [
(set (pc)
(if_then_else (ne (reg:SI 3 r3)
(const_int 0 [0x0]))
(label_ref 108)
(pc)))
(set (mem/c/i:SI (plus:SI (reg/f:SI 3 r3 [147])
(const_int 8 [0x8])) [2 nlist+0 S4 A32])
(plus:SI (reg:SI 3 r3)
(const_int -1 [0x])))
(clobber (reg:SI 3 r3))
]) 189 {*cbranchne_decr1} (nil)
(expr_list:REG_BR_PROB (const_int 9000 [0x2328])
(nil)))
a.i:13406: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:393
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
--
Summary: GCC ICE in xorg-x11 compiled in thumb
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: raj dot khem at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25595
[Bug target/25595] GCC ICE in xorg-x11 compiled in thumb
--- Comment #1 from raj dot khem at gmail dot com 2005-12-29 05:44 --- Created an attachment (id=10563) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10563action=view) preprocessed source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25595
[Bug libstdc++/24206] New: cin.rdbuf-in_avail() always return 0
The following code when run always returns 0 for in_avail()
To reproduce, just compile the following code with g++ with no commandline
switches and run the resulting binary.
#include iostream
using namespace std;
int main () {
streamsize size;
char ch;
streambuf * pbuf;
pbuf = cin.rdbuf();
cout Please enter some characters: ;
cin ch;
size = pbuf-in_avail();
cout The first character you entered is: ch endl;
cout size additional characters in input buffer endl;
return 0;
}
--
Summary: cin.rdbuf-in_avail() always return 0
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: raj dot khem at gmail dot com
GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24206
[Bug target/11831] [ARM] Logical expression evaluation with condition fields
--- Additional Comments From raj dot khem at gmail dot com 2005-09-27 03:00 --- I verified that this is fixed in GCC 3.4, 4.0 as well as on mainline. So this can be closed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11831
[Bug rtl-optimization/11826] [ARM] Minor register allocation problem before function return
--- Additional Comments From raj dot khem at gmail dot com 2005-09-27 03:09 --- This is fixed in GCC 3.4.4 as well as on mainline. This can be closed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11826
[Bug rtl-optimization/11825] Redundant move in some cases (dead code before return) for long long on 32bit targets
--- Additional Comments From raj dot khem at gmail dot com 2005-09-27 03:12 --- This bug is fixed on mainline. 3.4 branch however has it still. May be it can be closed for mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11825
[Bug target/9703] [arm] Accessing data through constant pool more times could be solved in less instructions
--- Additional Comments From raj dot khem at gmail dot com 2005-09-27 03:20 --- This is still exhibited on mainline gcc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9703
[Bug middle-end/23985] New: [ARM] Wrong code generation with -O2
GCC 3.4.3 and 3.4.4 generated wrong code at -O2 and -Os opt level for the attached testcase. If I user -O1 the test case works fine. Secondly it also works fine if I specify -O2 -fno-if-convertion2 Thirdly If I comment out newinfo-fig-shape = *shape; line in the testcase it works fine agains. The testcase can be compile and linked and runtime outputs should match correct output should be 1 alpha.style = 1 correct output should be 2 alpha.style = 2 in wrong code case. It prints. correct output should be 1 alpha.style = 254 correct output should be 2 alpha.style = 2 The testcase works fine with GCC 4.0 and CVS Trunk GCC -- Summary: [ARM] Wrong code generation with -O2 Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: raj dot khem at gmail dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: arm-unknown-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23985
[Bug middle-end/23985] [ARM] Wrong code generation with -O2
--- Additional Comments From raj dot khem at gmail dot com 2005-09-20 19:31 --- Created an attachment (id=9782) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9782action=view) Failing testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23985
[Bug middle-end/23985] [ARM] Wrong code generation with -O2
--- Additional Comments From raj dot khem at gmail dot com 2005-09-20 19:37 --- It fails on GCC 3.3.1 similarily. -- What|Removed |Added Component|rtl-optimization|middle-end Keywords|wrong-code | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23985
[Bug target/23783] [4.1 Regression] gcc.c-torture/compile/calls.c triggers an ICE
-- What|Removed |Added CC||raj dot khem at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23783
[Bug target/23772] New: [3.3/3.4 regression] [arm] ICE in change_address_1, at emit-rtl.c:1886
There is an internal error in gcc when following code is compiled with -O2 -c
options.
=
typedef float floatvect2 __attribute__((mode(V2DF)));
typedef union
{
floatvect2 vector;
double f[2];
}resfloatvect2;
void tempf(double *x, double *y)
{
floatvect2 temp={x[0],x[1]};
floatvect2 temp1={y[0],y[1]};
resfloatvect2 temp2;
temp2.vector=temp+temp1;
x[0]=temp2.f[0];
}
==
test.c: In function `tempf':
test.c:16: internal compiler error: in change_address_1, at emit-rtl.c:1886
Please submit a full bug report,
with preprocessed source if appropriate.
I could reproduce this error on 3.3.1, 3.4.3, 3.4.4
It is working on gcc build from trunk.
Moreover if I compile the compiler with --with-fpu=vfp the testcase works for
3.4.x
There has been a similar fix done in bug #11183.
--
Summary: [3.3/3.4 regression] [arm] ICE in change_address_1, at
emit-rtl.c:1886
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: raj dot khem at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org,rearnsha at gcc dot gnu
dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-unknown-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23772
[Bug target/23772] [3.3/3.4 regression] [arm] ICE in change_address_1, at emit-rtl.c:1886
--- Additional Comments From raj dot khem at gmail dot com 2005-09-07 23:15 --- I think it needs backporting this particular patch from Richard to 3.4 branch submitted for bug #12133 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-07-09 10:06:03 Modified files: gcc: ChangeLog gcc/config/arm : arm.c Log message: PR target/12133 * arm.c (arm_legitimate_index_p) Allow DFmode for soft-float and DImode to use +/-4k offset. may be then it can be closed as duplicate of bug #12133 if the patch is backported to gcc 3.4 branch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23772
[Bug tree-optimization/23117] New: ICE on valid code while building libgcc
The latest compiler build from CVS sources on 07-28-2005 segfaults while
building libgcc for arm-softfloat target with -O2,O2,Os opt levels. The error
does not happen when -O1 is used
The program compiles fine when I use my host compiler which is gcc version 4.0.1
20050727 (Red Hat 4.0.1-5)
error log
__do_global_ctors_aux
Analyzing compilation unitPerforming intraprocedural optimizations
Assembling functions:
__do_global_ctors_aux
/home/kraj/a.c: In function '__do_global_ctors_aux':
/home/kraj/a.c:8: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
How to reporoduce
gcc -O2 -c testcase.c
testcase.c
typedef void (*func_ptr) (void);
static func_ptr __CTOR_END__[1] = {(func_ptr) 0 };
static void __attribute__((used)) __do_global_ctors_aux (void)
{
func_ptr *p;
for (p = __CTOR_END__ - 1; *p != (func_ptr) -1; p--)
(*p) ();
}
===
--
Summary: ICE on valid code while building libgcc
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: raj dot khem at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i686-host_pc-linux-gnu
GCC target triplet: arm-softfloat-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23117
