[Bug target/42496] New: wrong if conversion optimization
Compile the attached test case with options -Os, I can get the ideal result: foo: cmp r0, #0 ldr r3, .L5 movne r2, #10 moveq r2, #20 str r2, [r3, #0] bx lr But when I changed the options to -O2, I got: foo: cmp r0, #0 ldrne r3, .L4// A ldreq r3, .L4// B movne r2, #10 moveq r2, #20 strne r2, [r3, #0] // C streq r2, [r3, #0] // D bx lr Instructions A/B/C/D should not executed conditionally since they do the same thing in either case. Similarly when I changed to options to -Os -fpic, I got: foo: ldr r3, .L5 ldr r2, .L5+4 .LPIC0: add r3, pc, r3 cmp r0, #0 ldrne r3, [r3, r2] // E ldreq r3, [r3, r2] // F movne r2, #10 moveq r2, #20 str r2, [r3, #0] bx lr Instructions E/F should not execute conditionally. -- Summary: wrong if conversion optimization Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: carrot at google dot com GCC build triplet: i686-linux GCC host triplet: i686-linux GCC target triplet: arm-eabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42496
[Bug target/42496] wrong if conversion optimization
--- Comment #1 from carrot at google dot com 2009-12-25 08:14 --- Created an attachment (id=19389) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19389action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42496
[Bug target/42497] New: GCC can do less work in the frequently executed path
Compile following code with options -march=armv5te -O2
extern void *memcpy(void *dst, const void *src, int n);
void *memmove(void *dst, const void *src, int n)
{
const char *p = src;
char *q = dst;
if (__builtin_expect(q p, 1)) {
return memcpy(dst, src, n);
} else {
int i=0;
for (; in; i++)
q[i] = p[i];
}
return dst;
}
gcc generates:
memmove:
cmp r1, r0
str r4, [sp, #-4]!
mov r3, r0
mov ip, r1
mov r4, r2
bls .L8
ldmfd sp!, {r4}
b memcpy
.L8:
cmp r2, #0
movgt r2, #0
ble .L4
.L5:
ldrbr1, [ip, r2]@ zero_extendqisi2
strbr1, [r3, r2]
add r2, r2, #1
cmp r2, r4
bne .L5
.L4:
mov r0, r3
ldmfd sp!, {r4}
bx lr
The if block is expected to be more frequent than the else block, but the
generated code is not very efficient. Better code could be:
cmp r1, r0
bhi memcpy
str r4, [sp, #-4]!
mov r3, r0
mov ip, r1
mov r4, r2
L8:
...
--
Summary: GCC can do less work in the frequently executed path
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42497
[Bug target/42498] New: GCC can't use smull to compute int * int -- long long
Compile following code with options -O2
extern C void foo(long long a, long long b, long long c);
extern C void bar(int a, int b, int c, int d)
{
long long x = (long long)a*b;
long long y = (long long)b*c;
long long z = (long long)c*d;
foo(x,y,z);
}
gcc generates:
bar:
stmfd sp!, {r4, r5, r6, r7, r8, r9, sl, fp, lr}
.save {r4, r5, r6, r7, r8, r9, sl, fp, lr}
.LCFI0:
mov fp, r1
mov ip, fp, asr #31
mov lr, r2
mov r4, r0
mov r5, r4, asr #31
mov sl, ip
mov r6, r3
mul r9, r1, r5
mov r3, r2, asr #31
mul sl, lr, sl
mul r8, r6, r3
mov r7, ip
mov fp, r6
mov ip, fp, asr #31
umull r4, r5, r1, r0
mla r7, r0, r7, r9
mla r0, r1, r3, sl
umull r2, r3, lr, r1
mov r1, ip
mla r1, lr, r1, r8
umull fp, ip, r6, lr
add r5, r7, r5
add r1, r1, ip
mov ip, r1
.pad #12
sub sp, sp, #12
.LCFI1:
add r3, r0, r3
mov r1, r5
mov r0, r4
stmia sp, {fp-ip}
bl foo
add sp, sp, #12
ldmfd sp!, {r4, r5, r6, r7, r8, r9, sl, fp, lr}
bx lr
An ideal result code should use the ARM instruction smull to do the operation
(int * int -- long long), but gcc first sign extends the operands, then do the
complex double word multiplication.
Following are some analysis from Seongbae Park:
== From Seongbae Park ==
Looks like rtl expander/combiner tried its best to screw this case, even though
there's a pattern for smull for exactly this case,
and then it's a complete downhill from there.
*.final_cleanup:
void bar(int, int, int, int) (a, b, c, d)
{
long long int D.1732;
long long int D.1731;
bb 2:
D.1731 = (long long int) b;
D.1732 = (long long int) c;
foo (D.1731 * (long long int) a, D.1732 * D.1731, (long long int) d * D.1732)
[tail call];
return;
}
This input, when reaches the RTL expander, causes it to do a full 64x64-64bit
multiply,
instead of 32x32-64 multiply, and once that full sequence is expanded,
we don't have pass(es) that can clean up unnecessary multiplies/pluses
so the RTL isn't in a shape the combiner can turn into smull insn.
One possible solution is to make expander look at more of the tree/gimple that
it currently does.
e.g. if it could see that D.1731 and D.1732 are originally int values,
it can recognize that those 64-bit multiplies are actually 32x32-64 multiplies
and use smull at the expansion time.
I wish there's an easy way to slap BURG into gcc, and we could fix this kind of
problem once and for all :(
In this case, it's not so much the registers, but how the IR looks
like when it reaches RTL expander.
In particular:
D.1731 = (long long int) b;
D.1732 = (long long int) c;
foo (D.1731 * (long long int) a, D.1732 * D.1731, (long long int) d *
D.1732) [tail call];
Those extra names, D.1731 and D.1732 hide the fact that they are
originally 32-bit from the expander,
thus the expander isn't aware that this is a 32x32-64 multiply.
One way to show is slightly modified example:
extern C void foo(long long a, long long b, long long c);
extern C void bar(int a, int b, int c, int d, int e, int f)
{
long long x = a*b;
long long y = c*d;
long long z = e*f;
foo(x, y, z);
}
At the end of midle-end, the above source becomes:
void bar(int, int, int, int, int, int) (a, b, c, d, e, f)
{
bb 2:
foo ((long long int) (b * a), (long long int) (d * c), (long long
int) (f * e)) [tail call];
return;
}
And this exposes everything expander needs to do its job properly,
and leads to the following assembly:
stmfd sp!, {r4, r5}
.save {r4, r5}
.LCFI0:
mul r1, r0, r1
ldr r4, [sp, #8]
ldr r0, [sp, #12]
mul r3, r2, r3
mul r4, r4, r0
mov r2, r3
mov r3, r2, asr #31
mov r5, r4, asr #31
mov r0, r1
mov r1, r0, asr #31
strdr4, [sp, #8]
ldmfd sp!, {r4, r5}
b foo
.LFE2:
Nice and clean, even though there are more variables involved.
Sorry the example was missing the cast.
A proper example:
extern C void foo(long long a, long long b, long long c);
extern C void bar(int a, int b, int c, int d, int e, int f)
{
long long x = (long long)a*b;
long long y = (long long)c*d;
long long z = (long long)e*f;
foo(x, y, z);
}
and this leads to:
void bar(int, int, int, int, int, int) (a, b, c, d, e, f)
{
bb 2:
foo ((long long int) b * (long long int) a, (long long int) d * (long long
int) c, (long long int) f * (long long int) e) [tail call];
return;
}
and finally:
stmfd sp!, {r4, r5}
.save {r4, r5}
.LCFI0:
smull r0, r1, r1, r0
ldr r4, [sp, #12]
ldr ip, [sp, #8]
smull r2, r3, r3, r2
[Bug rtl-optimization/42489] Opt bug -foptimize-sibling-calls function call stalled! dead-lock, cpu max
--- Comment #9 from t7 at gmail dot com 2009-12-25 09:18 --- Most unfortunate the gcc-4.* built with crt and win32api from http://sf.net/projects/mingw do not suffer from this bug. Therefore specific to target i686/x86_64-w64-mingw32 http://sourceforge.net/projects/mingw-w64 only. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42489
[Bug c++/42470] Conversion Constructor not accepted/recognized
--- Comment #3 from paolo dot carlini at oracle dot com 2009-12-25 09:47 --- This is not the proper place for academic discussions, definitely. If you are not convinced, try Comeau, or SunStudio, or ICC in strict mode. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42470
[Bug c++/42472] class members not getting assigned access thru another method
--- Comment #3 from paolo dot carlini at oracle dot com 2009-12-25 09:50 --- Yes, in C++03 (C++0x will be different), a constructor cannot call *another constructor*. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42472
[Bug c++/38392] Template friend function injection
--- Comment #16 from paolo dot carlini at oracle dot com 2009-12-25 09:53 --- As Jason confirmed, this is not a regression, thus, post 4.5.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38392
[Bug rtl-optimization/42499] New: Bad register allocation in multiplication code by constant
It seems that GCC 4.2.1 generates better code than GCC 4.4.0 in this case:
The following code (extracted from Android's
Dalvik_java_lang_System_currentTimeMillis in native/java_lang_System.c):
// compilation options: -march=armv5te -mthumb -Os
struct timeval
{
long tv_sec;
long tv_usec;
};
extern void get_time(struct timeval*);
void test(long long *res)
{
struct timeval tv;
get_time(tv);
*res = tv.tv_sec * 1000LL + tv.tv_usec / 1000;
}
is compiled by gcc-4.4.0 in sub-optimal way, so it takes 110 bytes (vs 74 bytes
when compiled by gcc-4.2.1). Assembly files shows that it spills some registers
on stack because code that multiply on 1000LL uses more registers that it need
(that is use when compiled by gcc-4.2.1). Multiplication code is similar, but
gcc 4.4 emits several additional MOVs that can be easily eliminated.
This bug can be more easily demonstrated with multiplication of tv_sec by 10
and tv_usec/ 1000 removed.
gcc.4.2.1:
push{r4, r5, lr}
sub sp, sp, #12
mov r5, r0
mov r0, sp
bl get_time
ldr r2, [sp]
add sp, sp, #12
@ sp needed for prologue
asr r4, r2, #31
mov r3, r2
lsr r0, r2, #30
lsl r2, r4, #2
orr r2, r2, r0
lsl r1, r3, #2
add r1, r1, r3
adc r2, r2, r4
lsr r0, r1, #31
lsl r4, r2, #1
orr r4, r4, r0
lsl r3, r1, #1
str r3, [r5]
str r4, [r5, #4]
pop {r4, r5, pc}
gcc 4.4.0:
push{r4, r5, r6, r7, lr} // note that gcc 4.2.1 uses only
{r4, r5, lr}
sub sp, sp, #12
mov r4, r0
mov r0, sp
bl get_time
ldr r6, [sp]
add sp, sp, #12
@ sp needed for prologue
mov r0, r6
asr r6, r6, #31
lsr r7, r0, #30
lsl r3, r6, #2
orr r3, r3, r7
mov r1, r6 // not needed actually, r6 can be used directly
lsl r2, r0, #2
add r0, r0, r2
adc r1, r1, r3
lsr r2, r0, #31
lsl r3, r1, #1
orr r3, r3, r2
lsl r0, r0, #1
str r0, [r4]
str r3, [r4, #4]
pop {r4, r5, r6, r7, pc}
--
Summary: Bad register allocation in multiplication code by
constant
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sliao at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42499
[Bug c++/38392] Template friend function injection
--- Comment #17 from H9XLrv5oXVNvHiUI at spambox dot us 2009-12-25 10:42 --- Ok I managed to compile GCC 4.5, applied the patch and compiled the test code above and everything works fine. Thanks again! And yes, I imagined it would have been post 4.5 but I meant 'when' from a time frame point of view, that's why I said you have any idea as I know it's hard to predict a specific time for release. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38392
[Bug rtl-optimization/42389] ICE in advance_state_on_fence with sel-schd for 175.vpr
--- Comment #2 from abel at gcc dot gnu dot org 2009-12-25 10:44 --- Confirmed. This needs my uncommitted patch from http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01931.html (which is correctly saving and restoring can_issue_more variable in the presence of multiple scheduling points) amended by the below fix by Alexander, as the original patch failed to update one place. The -fsched-pressure flag has anything to do with the bug only because on ppc64 it results in the different value of issue_rate. Again we will need help with testing this on ppc64 as a combined patch with other bugfixes. diff --git a/gcc/sel-sched.c b/gcc/sel-sched.c --- a/gcc/sel-sched.c +++ b/gcc/sel-sched.c @@ -4103,7 +4104,7 @@ invoke_reorder_hooks (fence_t fence) ran_hook = true; } else -issue_more = issue_rate; +issue_more = FENCE_ISSUE_MORE (fence); -- abel at gcc dot gnu dot org changed: What|Removed |Added CC||abel at gcc dot gnu dot org, ||amonakov at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |abel at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-25 10:44:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42389
[Bug c++/38392] Template friend function injection
--- Comment #18 from paolo dot carlini at oracle dot com 2009-12-25 10:48 --- If I were you, I would not use this kind of C++ at all, for the time being. As we discussed already, it's *very* weakly supported and your software would not be portable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38392
[Bug c++/38392] Template friend function injection
--- Comment #19 from H9XLrv5oXVNvHiUI at spambox dot us 2009-12-25 11:02 --- Yeah I know, but consider that I used this code only in a specific circumstance and does not constitute a core part of my application (or a foundation of some higher level mechanism). And I know it's a lot like an exploit but it does allow me to add a tiny yet very slick feature to my code. Also I checked and they fixed this in visual c++ 2010 as well (after my report), so having the two major compilers supporting this code is good enough for me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38392
[Bug c++/38392] Template friend function injection
--- Comment #20 from paolo dot carlini at oracle dot com 2009-12-25 11:06 --- Then wait, good luck -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38392
[Bug target/42500] New: unnecessary register move
Compile the following code with options -O2
extern C void foo(int a[4]);
extern C void bar(int a, int b, int c, int d)
{
int v[4] = {a,b,c,d};
foo(v);
foo(v);
}
GCC generates
bar:
stmfd sp!, {r4, lr}
.save {r4, lr}
.LCFI0:
.pad #16
sub sp, sp, #16
.LCFI1:
mov lr, #0
add ip, sp, #8
str lr, [ip], #4
str r0, [sp, #0]
mov r0, sp
str lr, [ip, #0]
stmib sp, {r1, r2, r3}@ phole stm
bl foo
mov r0, sp
mov r4, sp // A
bl foo
add sp, sp, #16
ldmfd sp!, {r4, lr}
bx lr
Instruction A move sp to r4, but r4 is never used again.
If compile the code with options -Os, the result is even worse:
bar:
stmfd sp!, {r0, r1, r2, r3, r4, r5, r6, r7, r8, lr}
.save {r0, r1, r2, r3, r4, r5, r6, r7, r8, lr}
.LCFI0:
mov r6, r0
mov r5, r1
mov r4, r2
mov r1, #0
mov r2, #16
mov r0, sp
mov r8, r3
bl memset
mov r0, sp
str r6, [sp, #0]
str r5, [sp, #4]
str r4, [sp, #8]
str r8, [sp, #12]
bl foo
mov r0, sp
mov r7, sp
bl foo
ldmfd sp!, {r0, r1, r2, r3, r4, r5, r6, r7, r8, lr}
bx lr
It calls memset to set the array to 0, then store parameters to that array. It
is quite inefficient.
--
Summary: unnecessary register move
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42500
[Bug middle-end/42501] New: Code bloating on operations with bit fields
Alexvod tried pr31849-patch from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31849. It changed result size from
72 to 68 below, but still didn't eliminated the loop counter below.
See the following code
// compilation options: -march=armv5te -mthumb -Os
struct tree_block
{
unsigned handler_block_flag:2;
unsigned block_num:30;
};
static int next_block_index = 2;
void number_blocks (int n_blocks, struct tree_block **block_vector)
{
int i;
for (i = 0; i n_blocks; ++i)
((block_vector[i])-block_num) = next_block_index++;
}
is compiled by gcc 4.4.0 in very inefficient way. gcc 4.2.1 compiles it to 48
bytes, and gcc 4.4.0 to 72 bytes (1.5 times bigger).
Analysis of assembly files shows the following problems:
1) operations with bitfields are done inefficiently. gcc-4.2.1 sets block_num
by LSLing the value and ORRing it.gcc-4.4.0 loads an extra constant 0x3fff
from memory and does AND in addition to that LSL and ORR.
2) gcc-4.4.0 doesn't eliminate loop counter i. It increments both block_vector
and i. Instead gcc-4.2.1 computes the end of the loop and increments only
block_vector
3) register allocation performs badly, it spills some registers to stack, which
causes extra LDR, STR operations in the loop body
The code was taken from GCC SPEC benchmark.
--
Summary: Code bloating on operations with bit fields
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sliao at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42501
[Bug rtl-optimization/42502] New: Bad register allocation in a very simple code
The following code
// compilation options: -march=armv5te -mthumb -Os
struct node
{
long long a;
long long b;
};
void func (struct node *n);
long long test (int from, int to)
{
struct node n;
func(n);
if (from == 1)
return n.a;
else
{
if (to == 2)
return n.b;
else
return n.b - n.a;
}
}
is compiled by gcc 4.2.1 to 44 bytes, and gcc 4.4.0 to 60 bytes. Assembly files
shows 6 unneeded movs in the else clause and duplication of sp in r4:
gcc 4.2.1 output:
test:
push{r4, r5, lr}
sub sp, sp, #20
mov r4, r0
mov r0, sp
mov r5, r1
bl func
cmp r4, #1
bne .L2
ldr r0, [sp]
ldr r1, [sp, #4]
b .L4
.L2:
ldr r0, [sp, #8]
ldr r1, [sp, #12]
cmp r5, #2
beq .L4
ldr r3, [sp]
ldr r4, [sp, #4]
sub r0, r0, r3
sbc r1, r1, r4
.L4:
add sp, sp, #20
@ sp needed for prologue
pop {r4, r5, pc}
gcc 4.4 output:
test:
push{r4, r5, r6, lr}
sub sp, sp, #16
mov r5, r0
mov r0, sp
mov r6, r1
mov r4, sp// why duplicate sp in r4? sp is never modified in the
function
bl func
cmp r5, #1
bne .L2
ldr r3, [sp]
ldr r4, [sp, #4]
b .L3
.L2:
ldr r2, [r4, #8]
ldr r3, [r4, #12]
cmp r6, #2
bne .L4
mov r4, r3 // the magic dance of the registers
mov r3, r2
b .L3
.L4:
ldr r0, [r4]
ldr r1, [r4, #4]
mov r4, r3 // another magic dance
mov r3, r2
sub r3, r3, r0
sbc r4, r4, r1
.L3:
add sp, sp, #16
mov r0, r3 // again, unneeded movs.
mov r1, r4 // result can be calculated in r0,r1 directly (see gcc
4.2.1 version)
@ sp needed for prologue
pop {r4, r5, r6, pc}
The code was extracted from GCC SPEC benchmark.
--
Summary: Bad register allocation in a very simple code
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sliao at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42502
[Bug rtl-optimization/42489] Opt bug -foptimize-sibling-calls function call stalled! dead-lock, cpu max
--- Comment #10 from d dot g dot gorbachev at gmail dot com 2009-12-25 13:34 --- No simple test-case code can be provided you have to read libxml2 source error.c about less then 1000 lines. Could you please provide the preprocessed source file, as described here: http://gcc.gnu.org/bugs/ ? Browsed all recently committed gcc svn change-logs saw no -foptimize-sibling-calls related fixes. Which of course does not mean that there were no such fixes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42489
[Bug target/42503] New: gcc-4.4-20091215 broke libjava on ARM
Building gcc-4.4-20091215 on arm with java enabled fails with a linkage error: libtool: link: ( cd .libs rm -f libgcj_bc.la ln -s ../libgcj_bc.la libgcj_bc.la ) /bin/sh ./libtool --tag=GCJ --mode=link /home/mikpe/objdir44/gcc/gcj -B/home/mikpe/objdir44/armv5tel-brewer-linux-gnueabi/libjava/ -B/home/mikpe/objdir44/gcc/ -L/home/mikpe/objdir44/armv5tel-brewer-linux-gnueabi/libjava -g -O2 -o jv-convert --main=gnu.gcj.convert.Convert -rpath /home/mikpe/crap/lib -shared-libgcc -L/home/mikpe/objdir44/armv5tel-brewer-linux-gnueabi/libjava/../libstdc++-v3/src/.libs -lstdc++ -L/home/mikpe/objdir44/armv5tel-brewer-linux-gnueabi/libjava/.libs libgcj.la libtool: link: /home/mikpe/objdir44/gcc/gcj -B/home/mikpe/objdir44/armv5tel-brewer-linux-gnueabi/libjava/ -B/home/mikpe/objdir44/gcc/ -g -O2 -o .libs/jv-convert --main=gnu.gcj.convert.Convert -shared-libgcc -L/home/mikpe/objdir44/armv5tel-brewer-linux-gnueabi/libjava/.libs -L/home/mikpe/objdir44/armv5tel-brewer-linux-gnueabi/libjava -L/home/mikpe/objdir44/armv5tel-brewer-linux-gnueabi/libjava/../libstdc++-v3/src/.libs /home/mikpe/objdir44/armv5tel-brewer-linux-gnueabi/libjava/../libstdc++-v3/src/.libs/libstdc++.so ./.libs/libgcj.so /home/mikpe/objdir44/armv5tel-brewer-linux-gnueabi/libstdc++-v3/src/.libs/libstdc++.so -lm -lpthread -lrt -ldl -lz -Wl,-rpath -Wl,/home/mikpe/crap/lib /usr/bin/ld: .libs/jv-convert: hidden symbol `__sync_synchronize' in /home/mikpe/objdir44/gcc/libgcc.a(linux-atomic.o) is referenced by DSO /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status make[3]: *** [jv-convert] Error 1 make[3]: Leaving directory `/home/mikpe/objdir44/armv5tel-brewer-linux-gnueabi/libjava' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/mikpe/objdir44/armv5tel-brewer-linux-gnueabi/libjava' make[1]: *** [all-target-libjava] Error 2 make[1]: Leaving directory `/home/mikpe/objdir44' make: *** [bootstrap] Error 2 4.4 snapshots up to and including 20091208 build fine, so this is a recent regression. -- Summary: gcc-4.4-20091215 broke libjava on ARM Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mikpe at it dot uu dot se GCC build triplet: armv5tel-unknown-linux-gnueabi GCC host triplet: armv5tel-unknown-linux-gnueabi GCC target triplet: armv5tel-unknown-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42503
[Bug c/42504] New: error: bit-field 'anonymous' width not an integer constant
Error occurs when compiling latest linux kernel with 155464 gcc 4.5.0 revision -- Summary: error: bit-field 'anonymous' width not an integer constant Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: denis dot onischenko at gmail dot com GCC build triplet: x86_64-cross-linux-gnu GCC host triplet: x86_64-cross-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42504
[Bug c/42504] error: bit-field 'anonymous' width not an integer constant
--- Comment #1 from denis dot onischenko at gmail dot com 2009-12-25 14:52 --- Created an attachment (id=19390) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19390action=view) preprocessed source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42504
[Bug c/42504] error: bit-field 'anonymous' width not an integer constant
--- Comment #2 from denis dot onischenko at gmail dot com 2009-12-25 14:52 --- Created an attachment (id=19391) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19391action=view) compiler output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42504
[Bug c/42439] Linux kernel BUILD_BUG_ON() broke
--- Comment #4 from hjl dot tools at gmail dot com 2009-12-25 17:15 --- *** Bug 42504 has been marked as a duplicate of this bug. *** -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||denis dot onischenko at ||gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42439
[Bug c/42504] error: bit-field 'anonymous' width not an integer constant
--- Comment #3 from hjl dot tools at gmail dot com 2009-12-25 17:15 --- *** This bug has been marked as a duplicate of 42439 *** -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42504
[Bug lto/42451] 'warning: type of array does not match original declaration' with -flto/-fwhopr
--- Comment #4 from zsojka at seznam dot cz 2009-12-25 18:42 --- Created an attachment (id=19392) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19392action=view) testcase reproducing the crash (with checking enabled) I wasn't able to reduce number of input files, so they are archived. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42451
[Bug middle-end/42505] New: loop canonicalization causes a lot of unnecessary temporary variables
This regression was caused by loop canonicalization.
The following example:
struct A {
int f1;
int f2;
};
int func(int c);
int test(struct A* src, struct A* dst, int count)
{
while (count--) {
if (!func(src-f2)) {
return 0;
}
*dst++ = *src++;
}
return 1;
}
gcc 4.2.1 compiles this to 40 bytes, gcc 4.4.0 to 48 bytes:
gcc 4.2.1 output:
test:
push{r4, r5, r6, lr}
mov r4, r0
mov r5, r1
mov r6, r2
b .L2
.L3:
ldr r0, [r4, #4]
bl func
cmp r0, #0
beq .L6
mov r3, r5
mov r2, r4
ldmia r2!, {r0, r1}
stmia r3!, {r0, r1}
mov r5, r3
mov r4, r2
.L2:
sub r6, r6, #1
bcs .L3
mov r0, #1
.L6:
@ sp needed for prologue
pop {r4, r5, r6, pc}
gcc 4.4.0 output:
push{r4, r5, r6, r7, lr}// note r7 is cloberred
sub sp, sp, #12 // why need to store smth on the stack?
mov r7, r0
str r1, [sp, #4] // why store r1 onto stack?
mov r6, r2
mov r5, #0
b .L2
.L5:
add r4, r7, r5
ldr r0, [r4, #4]
bl func
sub r6, r6, #1
cmp r0, #0
beq .L4
ldr r1, [sp, #4] // load from stack
add r3, r1, r5
add r5, r5, #8
ldmia r4!, {r1, r2}
stmia r3!, {r1, r2}
.L2:
cmp r6, #0
bne .L5
mov r0, #1
.L4:
add sp, sp, #12
@ sp needed for prologue
pop {r4, r5, r6, r7, pc}
This is caused by loop canonicalization pass (pass_iv_optimize) that was added
in gcc 4.4.
Final GIMPLE form in gcc 4.2.1 compiler:
test (src, dst, count)
{
int a;
int D.1545;
bb 2:
goto bb 6 (L3);
L0:;
a = func (MEM[base: src, offset: 4]);
if (a == 0) goto L8; else goto L2;
L8:;
D.1545 = 0;
goto bb 8 (L5);
L2:;
MEM[base: dst] = MEM[base: src];
dst = dst + 8B;
src = src + 8B;
L3:;
count = count - 1;
if (count != -1) goto L0; else goto L9;
L9:;
D.1545 = 1;
L5:;
return D.1545;
}
The final GIMPLE in gcc 4.4:
test (struct A * src, struct A * dst, int count)
{
unsigned int ivtmp.22; // induction variables introduced by pass_iv_optimize
unsigned int ivtmp.19;
int a;
int D.1274;
bb 2:
ivtmp.22 = (unsigned int) count; // copy of count, count itself is not used
anymore
ivtmp.19 = 0;
goto bb 6;
bb 3:
a = func (MEM[base: src + ivtmp.19, offset: 4]);
ivtmp.22 = ivtmp.22 - 1;
if (a == 0)
goto bb 4;
else
goto bb 5;
bb 4:
D.1274 = 0;
goto bb 8;
bb 5:
MEM[base: dst, index: ivtmp.19] = MEM[base: src, index: ivtmp.19];
ivtmp.19 = ivtmp.19 + 8;
bb 6:
if (ivtmp.22 != 0)
goto bb 3;
else
goto bb 7;
bb 7:
D.1274 = 1;
bb 8:
return D.1274;
}
The following RTL passes could not optimize these temporary induction variables
and they are spilled on the stack, which causes a lot of other inefficiencies.
The main question: there are three way to fix this:
1) turn off loop canonicalization for -Os
2) optimize the extra variable in the GIMPLE passes
3) optimize the extra variable in the RTL passes
--
Summary: loop canonicalization causes a lot of unnecessary
temporary variables
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sliao at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42505
[Bug fortran/42484] ICE with -fopenmp
--- Comment #2 from janus at gcc dot gnu dot org 2009-12-25 20:36 ---
Sorry. Of course the code is *not* valid. Section 1.2.2 of the OpenMP 3.0
specification says: The point of exit cannot be a branch out of the structured
block.
Also, an analogous example in C is correctly rejected:
void sub ()
{
int nRead;
#pragma omp critical
if (nRead3) return;
}
In function sub:
error: invalid branch to/from an OpenMP structured block
So, I guess it is a problem of the Fortran front-end, which should detect this
situation and reject the code.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
Component|middle-end |fortran
Keywords|ice-on-valid-code |ice-on-invalid-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42484
[Bug c++/42470] Conversion Constructor not accepted/recognized
--- Comment #4 from Curatica at gmail dot com 2009-12-25 21:11 --- Whatever... -- Curatica at gmail dot com changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42470
[Bug c++/42470] Conversion Constructor not accepted/recognized
--- Comment #5 from Curatica at gmail dot com 2009-12-25 21:12 --- Whatever... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42470
[Bug c++/35421] ICE on Valid Code
--- Comment #8 from paolo dot carlini at oracle dot com 2009-12-25 22:11 --- Feedback not forthcoming. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35421
[Bug c++/40055] Failing instantiation of template with enums
-- paolo dot carlini at oracle dot com changed: What|Removed |Added Severity|critical|normal Known to fail||4.4.2 Known to work||4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40055
[Bug c++/40055] Failing instantiation of template with enums
--- Comment #3 from paolo dot carlini at oracle dot com 2009-12-25 22:17 --- Works in mainline, not a regression, thus closing as fixed. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40055
[Bug c++/40365] g++ template expansion bug
--- Comment #6 from paolo dot carlini at oracle dot com 2009-12-25 22:21 --- Feedback not forthcoming. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40365
[Bug c++/40484] internal compiler error
--- Comment #3 from paolo dot carlini at oracle dot com 2009-12-25 22:23 --- Feedback not forthcoming. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40484
[Bug c++/41060] Wconversion Ignores static_cast
--- Comment #3 from paolo dot carlini at oracle dot com 2009-12-25 22:25 --- Feedback not forthcoming. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41060
[Bug c++/40694] ICE while building clang
--- Comment #4 from paolo dot carlini at oracle dot com 2009-12-25 22:26 --- Looks like can be closed. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40694
