[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/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 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 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=10563&action=view) preprocessed source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25595
[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 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/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/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/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=13203&action=view) testcase This is the preprocessed testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31165
[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=1&action=view) testcase testcase to reproduce the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31490
[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 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 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=18417&action=view) preprocessed testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41151
[Bug c/41151] Gas fails to consume the assembly Error: offset too big
--- Comment #3 from raj dot khem at gmail dot com 2009-08-24 21:17 --- (In reply to comment #2) > Using binutils trunk as well as r150986 I can't reproduce this with -O2 and > -march=armv7-a. > I was using 2.18. I haven't tried 2.19 but it works ok with binutils from cvs(updated from today) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41151
[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 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 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=9782&action=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/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 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
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/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 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 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 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
[Bug c/23117] ICE on valid code while building libgcc
-- What|Removed |Added Component|tree-optimization |c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23117
[Bug rtl-optimization/23117] [4.1 Regression] ICE on valid code while building libgcc
--- Additional Comments From raj dot khem at gmail dot com 2005-07-28 22:02 --- This seems to have been caused by some checkin that went in after 7/27/2005 (i.e only checkins that went in today 7/28) because when I cvs up -D 2005-07-27 I dont get the segfault. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23117
[Bug rtl-optimization/23117] [4.1 Regression] ICE on valid code while building libgcc
--- Additional Comments From raj dot khem at gmail dot com 2005-07-28 22:20 --- (In reply to comment #2) > This seems to have been caused by some checkin that went in after 7/27/2005 > (i.e > only checkins that went in today 7/28) because when I cvs up -D 2005-07-27 I > dont get the segfault. Amends, To narrow it further the problem is caused by some checkin that happened on 7/27 because upto 0:00 hours it builds ok but not cvs up -D "2005-07-27 23:59" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23117
[Bug rtl-optimization/23117] [4.1 Regression] ICE on valid code while building libgcc
--- Additional Comments From raj dot khem at gmail dot com 2005-07-29 03:50 --- The problem indeed was caused by checkin for PR rtl-optimization/17808. I verified it. Then I tried the Steven's fix above and I was able to build the GCC and rest of toolchain. I havent tested the compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23117
[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=19300&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42372
[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=19334&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42398
[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=19482&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42632
[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=19489&action=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=19490&action=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 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] )
(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] )
(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=19737&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42894
[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/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/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=19811&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42981
[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 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 #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 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=20759&action=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/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=20773&action=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 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=20777&action=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 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 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=20863&action=view) the fix 2010-06-07 Khem Raj * 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 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 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=20928&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44557
[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/44603] New: out of range branch generated in thumb code.
attached example fails to compile when no -O 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=20949&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44603
[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/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/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]
)
] 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=21013&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44685
[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=,
fnclass=BUILT_IN_NORMAL, fntype=, 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=21046&action=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=21047&action=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
4a80: 02002021move a0,s0
4a84: 12c00051beqzs6,4bcc
=> 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
> 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/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 -O 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=21128&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44860
[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 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 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 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 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] )
] 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 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 c++/21166] New: g++ gives error on reference to packed structure elements
In the code below, the g++ is being overly picky about taking a reference to a
packed char. Chars can have any alignment so the error is incorrect. note
that the same code using pointers doesn't produce a similar error:
=
struct s1 {
charc1;
} __attribute__((packed));
char&
f(struct s1 *s)
{
return s->c1;
}
char *
g(struct s1 *s)
{
return &s->c1;
}
--
Summary: g++ gives error on reference to packed structure
elements
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
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: i386-redhat-linux
GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21166
[Bug middle-end/21259] New: ICE on assigning the pointer to a array with __attribute__ aligned
Compiler gets a segfault if the following code is tried on gcc 3.4.3
the same works fine on gcc4.0 and mainline
static void foo ( int arg){
unsigned long long int __attribute__ ((aligned (4))) aligned_array[arg];
unsigned long long int *bak = aligned_array;
}
--
Summary: ICE on assigning the pointer to a array with
__attribute__ aligned
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: i386-redhat-linux
GCC host triplet: i386-redhat-linux
GCC target triplet: mips64-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21259
[Bug middle-end/21259] ICE on assigning the pointer to a array with __attribute__ aligned
-- What|Removed |Added CC||rth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21259
[Bug middle-end/21616] New: ICE: unable to find a register to spill in class `FLOAT_REGS'
GCC produced this ICE when the attached program was compiled. I tried the fix
from http://gcc.gnu.org/PR18641 but it did not fix the problem.
commandline options
-O2 -msoft-float -m64 -c
gcc output
=
a.c: In function `do_select':
a.c:12770: error: unable to find a register to spill in class `FLOAT_REGS'
a.c:12770: error: this is the insn:
(insn:HI 355 353 357 27 (set (mem/s:DI (plus:DI (reg/f:DI 31 31)
(const_int 149 [0x95])) [4 fs_event.event_data2+0 S8 A8])
(reg/v:DI 125 [ __timeout ])) 322 {*movdi_internal64} (nil)
(nil))
a.c:12770: confused by earlier errors, bailing out
--
Summary: ICE: unable to find a register to spill in class
`FLOAT_REGS'
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: powerpc64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21616
[Bug middle-end/21616] ICE: unable to find a register to spill in class `FLOAT_REGS'
--- Additional Comments From raj dot khem at gmail dot com 2005-05-17 08:43 --- Created an attachment (id=8907) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8907&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21616
