[Bug target/38203] attribute `noreturn' isn't effective when -mthumb param is active
--- Comment #2 from ramana dot r at gmail dot com 2009-03-24 18:34 --- (In reply to comment #1) Created an attachment (id=16728) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16728action=view) [edit] A more involved testcase. This testcase shows the preserving behaviour on multiple call-clobbered registers, in spite of noreturn attribute. The save of registers appears on Using built-in specs. Target: arm-none-eabi Configured with: /home/ramana/cos/mycos/combined-arm-none-eabi/configure --target=arm-none-eabi --enable-languages=c,c++ : (reconfigured) /home/ramana/cos/mycos/combined-arm-none-eabi/configure --target=arm-none-eabi --enable-languages=c,c++ : (reconfigured) /home/ramana/cos/mycos/combined-arm-none-eabi/configure --target=arm-none-eabi target_alias=arm-none-eabi --enable-languages=c,c++ --no-create --no-recursion Thread model: single gcc version 4.4.0 20090324 (experimental) [trunk revision 143499] (GCC) and might be related to PR #38570 . -- ramana dot r at gmail dot com changed: What|Removed |Added CC||rearnsha at gcc dot gnu dot ||org, ramana dot r at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38203
[Bug target/36209] arm-*-linux-gnueabi-gcc (4.3.0) segment fault during build of procps-3.2.7
--- Comment #5 from ramana dot r at gmail dot com 2009-03-24 18:53 --- I can confirm that this is fixed with revision 145038 in the 4.3 branch which is due to the fix committed here. http://gcc.gnu.org/viewcvs?view=revrevision=143942 which is essentially a backport of the patch http://gcc.gnu.org/viewcvs?view=revrevision=137235 . http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35964 -- ramana dot r at gmail dot com changed: What|Removed |Added CC||ramana dot r at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36209
[Bug target/39501] -O -ffinite-math-only gets min(x,y) optimization wrong for SF on arm-*-gnueabi
--- Comment #1 from ramana dot r at gmail dot com 2009-03-19 15:53 --- Adding self to CC list - mainline is also broken. The only difference in mainline is that we generate a movle instead of movgt. It should indeed be a moveq instead of a movle. cheers Ramana -- ramana dot r at gmail dot com changed: What|Removed |Added CC||rearnsha at gcc dot gnu dot ||org, ramana dot r at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39501
[Bug target/39501] -O -ffinite-math-only gets min(x,y) optimization wrong for SF on arm-*-gnueabi
--- Comment #2 from ramana dot r at gmail dot com 2009-03-19 16:05 --- Or get rid of the cmp. The Runtime ABI suggests that the Z,N,C flags are set for the result of the comparison. If that is true then the second cmp is unnecessary. Table 5 section 4.1.2 of the ARM Runtime ABI suggests this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39501
[Bug target/39501] -O -ffinite-math-only gets min(x,y) optimization wrong for SF on arm-*-gnueabi
--- Comment #4 from ramana dot r at gmail dot com 2009-03-19 16:49 --- (In reply to comment #3) ramana: I think you'll find the flags are only set for the 3-way comparisons. __aeabi_cmple just returns 0 or 1 Use for C = in the table means the C language, not the carry flag. If you can find where the error is in the GCC source, that'd be great. It was pointed out that I was looking at the wrong function in the runtime ABI - so I take that back. I was referring to the void __aeabi_cfcmple(float, float) variant rather than the fcmple that's used in this case. So if you were to use the cfcmple variants (which gcc can't at the moment) the extra cmp might be removed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39501
[Bug middle-end/35964] ICE with -funroll-loops on arm/arm eabi
--- Comment #18 from ramana dot r at gmail dot com 2009-03-17 14:27 --- This commit here http://gcc.gnu.org/viewcvs?view=revrevision=143942 which is essentially a backport of the patch http://gcc.gnu.org/viewcvs?view=revrevision=137235 . If this fixes the problem, then the bug can be closed out. -- ramana dot r at gmail dot com changed: What|Removed |Added CC||ramana dot r at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35964
[Bug middle-end/34109] Incorrect code for tail calls with a structure as 4th argument
--- Comment #2 from ramana dot r at gmail dot com 2009-03-17 14:40 --- This appears to be fixed on mainline on gcc version 4.4.0 20090317 (experimental) (GCC). output obtained 42 69 105 42 69 105 -- ramana dot r at gmail dot com changed: What|Removed |Added CC||rearnsha at gcc dot gnu dot ||org, ramana dot r at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34109
[Bug target/10242] [ARM] subsequent use of plus and minus operators could be improved
--- Comment #4 from ramana dot r at gmail dot com 2009-03-17 00:05 --- Still present with 4.4 mainline as on 20090312 revision. It looks like some sort of relic left behind with the calculations of the soft frame pointer. Maybe a peephole will help. -- ramana dot r at gmail dot com changed: What|Removed |Added CC||rearnsha at gcc dot gnu dot ||org, ramana dot r at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10242
[Bug rtl-optimization/11222] arm/thumb __Unwind_SjLj_Register prologue optimization causes crash on interrupts
--- Comment #10 from ramana dot r at gmail dot com 2009-03-17 00:11 --- This should be a target bug. Also with mainline the testcase empty described in comment #9 appears fixed. -- ramana dot r at gmail dot com changed: What|Removed |Added CC||rearnsha at gcc dot gnu dot ||org, ramana dot r at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11222
[Bug tree-optimization/39468] New: Constant propagation in a number of tree passes does not take into account machine costs.
As reported at the thread in http://gcc.gnu.org/ml/gcc/2009-03/msg00369.html
Using 4.4.0 gcc, I compiled a function and found it a tad long. The
command line is:
gcc -Os -mcpu=arm7tdmi-s -S func.c
although the output is pretty much the same with -O2 or -O3 as well (only
a few instructions longer).
The function is basically an unrolled 32 bit unsigned division by 1E9:
unsigned int divby1e9( unsigned int num, unsigned int *quotient )
{
unsigned int dig;
unsigned int tmp;
tmp = 10u;
dig = 0;
if ( num = tmp ) {
tmp = 2;
if ( num = tmp ) {
num -= tmp;
dig = 4;
}
else {
tmp = 1;
if ( num = tmp ) {
num -= tmp;
dig = 2;
}
tmp = 1;
if ( num = tmp ) {
num -= tmp;
dig++;
}
}
}
*quotinet = dig;
return num;
}
The compiler generated the following code:
divby1e9:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
ldr r3, .L10
cmp r0, r3
movls r3, #0
bls .L3
ldr r2, .L10+4
cmp r0, r2
addhi r0, r0, #293601280
addhi r0, r0, #1359872
addhi r0, r0, #6144
movhi r3, #4
bhi .L3
.L4:
ldr r2, .L10+8
cmp r0, r2
movls r3, #0
bls .L6
add r0, r0, #-2013265920
add r0, r0, #13238272
add r0, r0, #27648
cmp r0, r3
movls r3, #2
bls .L3
mov r3, #2
.L6:
add r0, r0, #-1006632960
add r0, r0, #6619136
add r0, r0, #13824
add r3, r3, #1
.L3:
str r3, [r1, #0]
bx lr
.L11:
.align 2
.L10:
.word 9
.word -294967297
.word 19
Note that it is sub-optimal on two counts.
First, each loading of a constant takes 3 instructions and 3 clocks.
Storing the constant and fetching it using an ldr also takes 3 clocks but
only two 32-bit words and identical constants need to be stored only once.
The speed increase is only true on the ARM7TDMI-S, which has no caches, so
that's just a minor issue, but the memory saving is true no matter what
ARM core you have (note that -Os was specified).
Second, and this is the real problem, if the compiler did not want to be
overly clever and compiled the code as it was written, then instead of
loading the constants 4 times, at the cost of 3 instuctions each, it could
have loaded it only once and then generated the next constants at the cost
of a single-word, single clock shift. The code would have been rather
shorter *and* faster, plus some of the jumps could have been eliminated.
Practically each C statement line (except the braces) corresponds to one
assembly instruction, so without being clever, just translating what's
written, it could be done in 20 words instead of 30.
--
Summary: Constant propagation in a number of tree passes does not
take into account machine costs.
Product: gcc
Version: lto
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ramana dot r at gmail dot com
GCC build triplet: i686-unknown-linux-gnu
GCC host triplet: i686-unknown-linux-gnu
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39468
[Bug tree-optimization/39468] Constant propagation in a number of tree passes does not take into account machine costs.
--- Comment #1 from ramana dot r at gmail dot com 2009-03-15 22:20 --- I took a look at this for some time on Friday and I found that the conditional constant propagation pass has pushed down the value (tree-ssa-ccp.c). This is done by the CCP pass up in the optimization pipeline because in general constant propagation is a good idea . In any case there are a bunch of tree optimizers that identify these and generally bring in constants into expressions as generally a good idea. One might argue that constant propagation in general is a good thing but the problem appears to be that the moment one has an architecture where costs of loading immediate's is higher than the cost of simple arithmetic operations the final code generated might not be the most efficient. With some more experimentation in the last hour or so I found that for this particular case, I can get the following code divby1e9: @ Function supports interworking. @ args = 0, pretend = 0, frame = 0 @ frame_needed = 0, uses_anonymous_args = 0 @ link register save eliminated. ldr r3, .L7 cmp r0, r3 mov r2, #0 bcc .L2 mov r3, r3, asl #2 cmp r0, r3 rsbcs r0, r3, r0 addcs r2, r2, #4 bcs .L2 mov r3, r3, lsr #1 cmp r0, r3 rsbcs r0, r3, r0 mov r3, r3, lsr #1 movcs r2, #2 cmp r0, r3 rsbcs r0, r3, r0 addcs r2, r2, #1 .L2: str r2, [r1, #0] bx lr .L8: .align 2 .L7: .word 10 .size divby1e9, .-divby1e9 .ident GCC: (GNU) 4.4.0 20090313 (experimental) [trunk revision 143499] but with the following command line options. ./xgcc -B`pwd` -S -Os newpr.c -fno-tree-ccp -fno-tree-fre -fno-tree-vrp -fno-tree-dominator-opts -fno-gcse I'm not sure about the best way to fix this but I've filed this for the moment as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39468 cheers Ramana -- ramana dot r at gmail dot com changed: What|Removed |Added Summary|Constant propagation in a |Constant propagation in a |number of tree passes does |number of tree passes does |not take into account |not take into account |machine costs. |machine costs. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39468
[Bug target/9831] [ARM] Peephole for multiple load/store could be more effective.
--- Comment #3 from ramana dot r at gmail dot com 2009-03-13 10:54 --- (In reply to comment #2) See Dara's comment. Occurs even today . foo: @ args = 0, pretend = 0, frame = 0 @ frame_needed = 0, uses_anonymous_args = 0 @ link register save eliminated. ldr r0, .L3 ldr r1, .L3+4 ldr r2, .L3+8 ldr r3, .L3+12 b f .L4: .align 2 .L3: .word 12345 .word 238764 .word 2345234 .word 83746556 .size foo, .-foo .ident GCC: (GNU) 4.4.0 20090312 (experimental) .section.note.GNU-stack,,%progbits -- ramana dot r at gmail dot com changed: What|Removed |Added CC||rearnsha at arm dot com, ||ramana dot r at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9831
[Bug rtl-optimization/11826] [ARM] Minor register allocation problem before function return
--- Comment #6 from ramana dot r at gmail dot com 2009-03-13 12:28 --- (In reply to comment #5) Can an ARM maintainer please check this bug? Comment #4 suggests this bug is fixed, but it needs re-checking now that IRA has been merged. This is now fixed on mainline even after IRA . This bug can now be closed. foo: @ args = 0, pretend = 0, frame = 0 @ frame_needed = 0, uses_anonymous_args = 0 @ link register save eliminated. mov r3, r0 cmn r1, r0 rsbeq r0, r1, r0 rsbne r0, r3, r1 bx lr .size foo, .-foo .ident GCC: (GNU) 4.4.0 20090312 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11826
[Bug target/11831] [ARM] Logical expression evaluation with condition fields
--- Comment #4 from ramana dot r at gmail dot com 2009-03-13 12:33 ---
With Mainline today it looks worse -
stmfd sp!, {r4, lr}
mov r4, r0
bl func
add r0, r4, r0
ldrbr3, [r0, #-4] @ zero_extendqisi2
cmp r3, #97
beq .L6
.L2:
mov r0, #0
ldmfd sp!, {r4, pc}
.L6:
ldrbr3, [r0, #-3] @ zero_extendqisi2
cmp r3, #98
bne .L2
ldrbr3, [r0, #-2] @ zero_extendqisi2
cmp r3, #99
bne .L2
ldrbr0, [r0, #-1] @ zero_extendqisi2
cmp r0, #100
movne r0, #0
moveq r0, #1
ldmfd sp!, {r4, pc}
--
ramana dot r at gmail dot com changed:
What|Removed |Added
CC||rearnsha at arm dot com,
||ramana dot r at gmail dot
||com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11831
[Bug target/9760] [arm] Combine cannot do its job because immediate operand is used instead of register
--- Comment #6 from ramana dot r at gmail dot com 2009-03-12 18:45 ---
With Mainline today gcc produces :
stmfd sp!, {r4, lr}
mov r1, r0, lsr #24
mov r4, r0
mov r0, #8
bl func
mov r1, r4, lsr #16
and r1, r1, #255
mov r0, #8
bl func
mov r1, r4, lsr #8
and r1, r1, #255
mov r0, #8
ldmfd sp!, {r4, lr}
b func
The problem still exists. This can't be a problem with the combiner because the
combine would stop at function call boundaries.
--
ramana dot r at gmail dot com changed:
What|Removed |Added
CC||rearnsha at arm dot com,
||ramana dot r at gmail dot
||com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9760
[Bug middle-end/39378] Multiple inheritence thunk not working with -mthumb
--- Comment #1 from ramana dot r at gmail dot com 2009-03-11 23:30 --- Patch submitted at http://gcc.gnu.org/viewcvs?view=revrevision=143367 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39378
[Bug target/9663] [arm] gcc-20030127 misses an optimization opportunity
--- Comment #8 from ramana dot r at gmail dot com 2009-02-08 05:17 --- (In reply to comment #7) Note you have to do with -fno-inline now on the mainline as the function is inlined at -O2. It looks as though this is fixed in 4.3 and mainline today. I checked with 4.1 and saw that the problem existed in 4.1 Looking at the assembly generated for the function, I no longer see a cmp and mov as reported in the bug report. I see similar code generated in 4.1 but no longer in 4.3 or 4.4. I see subs generated for 4.3 and 4.4 in the loop kernel as of version r143940 for 4.3 and 144002 for mainline. Here is the snippet of code from 4.1, 4.3 and 4.4 as given below. 4.1 .L8: ldr r3, .L12 umull r1, r2, r3, ip mov r2, r2, lsr #3 mov r3, r2, asl #1 mov r1, r2, asl #3 add r3, r3, r1 rsb r3, r3, ip add r3, r3, #48 cmp r2, #0 Insns from original bug report. mov ip, r2 strbr3, [r0, #-1]! bne .L8 4.3 .L5: umull r2, r3, r5, ip mov r3, r3, lsr #3 mov r2, r3, asl #1 mov r1, r3, asl #3 add r2, r2, r1 rsb r2, r2, ip add r2, r2, #48 subsip, r3, #0 strbr2, [r0, #-1]! bne .L5 4.4 .L5: umull r1, r2, r4, ip mov r2, r2, lsr #3 add r1, r2, r2, asl #2 sub ip, ip, r1, asl #1 add r1, ip, #48 subsip, r2, #0 strbr1, [r0, #-1]! bne .L5 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9663
[Bug target/9703] [arm] Accessing data through constant pool more times could be solved in less instructions
--- Comment #11 from ramana dot r at gmail dot com 2009-02-08 05:23 ---
(In reply to comment #10)
This might have been implemented for 4.4 already. Section anchors now have
been enabled for ARM.
4.4 seems to enable this with section anchors turned on. This is the code
generated.
Here is the code generated for the function reported.
ldr r3, .L3
mov r0, #11
mov r2, #12
stmia r3, {r0, r2}@ phole stm
bx lr
I suspect this can now be closed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9703
[Bug target/39076] internal compiler error when cross-compiling flac
--- Comment #6 from ramana dot r at gmail dot com 2009-02-04 08:34 --- (In reply to comment #5) (In reply to comment #4) Looking at the dumps this rtx is generated by the rename registers pass in 4.3.x . In trunk however rename register does not generate this rtx and hence there is no problem. It could still be latent but one has to dig deeper. A quick comparison of trunk and gcc 4.3 branch shows the following patch being applied in trunk vs. the 4.3 branch. http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01577.html A quick check with the patch at ram...@numenor:~/cos/mycos/gcc/gcc$ svn diff -r137128:137235 regrename.c Index: regrename.c === --- regrename.c (revision 137128) +++ regrename.c (revision 137235) @@ -812,7 +812,7 @@ OP_IN, 0); for (i = 0; i recog_data.n_dups; i++) - *recog_data.dup_loc[i] = copy_rtx (old_dups[i]); + *recog_data.dup_loc[i] = old_dups[i]; for (i = 0; i n_ops; i++) *recog_data.operand_loc[i] = old_operands[i]; if (recog_data.n_dups) Related discussions and patch proposed here. http://gcc.gnu.org/ml/gcc/2009-02/msg00074.html This is essentially a backport of a patch in trunk - A full bootstrap and regression test is underway. I've confirmed that this patch fixes the ICE mentioned with the ARM port. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39076
[Bug rtl-optimization/39076] internal compiler error when cross-compiling flac
--- Comment #7 from ramana dot r at gmail dot com 2009-02-04 21:56 --- (In reply to comment #6) This has now been committed as revision 143942 in the 4.3 branch - Sven, could you check and get back if you still see a problem . If not this bug can be closed -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39076
[Bug target/36409] Additional instructions in prologue and epilogue.
--- Comment #1 from ramana dot r at gmail dot com 2009-02-04 23:38 ---
4.4.0 with revision id 143499 generates the following code with -O3 , -O2 and
-Os . The same code is generated for 4.3.3 as well
sub sp, sp, #8
mov r3, sp
mov r2, #0
stmia r3, {r0, r1}
str r2, [r0, #0]
add sp, sp, #8
bx lr
Clearly things have gotten worse with an extra stmia being generated in this
case where the argument registers are being saved on the stack with the stmia
instruction.
--
ramana dot r at gmail dot com changed:
What|Removed |Added
CC||rearnsha at arm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36409
[Bug target/39076] internal compiler error when cross-compiling flac
--- Comment #4 from ramana dot r at gmail dot com 2009-02-03 21:43 ---
(In reply to comment #2)
No problem with the trunk, but it's still there in the 4.3 branch.
Here's a test case. Requires -funroll-loops -Os, no problem with any other
-O,
or without -funroll-loops, curiously.
int f(int x, int y) {
int bytes = 4 * x + y;
if (bytes == 0)
return 0;
return bytes + 1;
}
I get the same problem even with a arm-none-eabi toolchain with the 4.3 branch
only.
For this particular testcase, the ICE is generated in final.c :
cleanup_subreg_operands for the alter_subreg call for the following rtx.
(insn:HI 9 8 17 /home/ramana/test.c:3 (parallel [
(set (reg:CC_NOOV 24 cc)
(compare:CC_NOOV (plus:SI (mult:SI (reg:SI 0 r0 [ x ])
(const_int 4 [0x4]))
(reg:SI 1 r1 [ y ]))
(const_int 0 [0x0])))
(set (reg/v:SI 0 r0 [orig:133 bytes ] [133])
(plus:SI (cc0)
(cc0)))
]) 265 {*arith_shiftsi_compare0} (expr_list:REG_DEAD (reg:SI 1 r1 [ y
])
(nil)))
Looking at the dumps this rtx is generated by the rename registers pass in
4.3.x . In trunk however rename registers does not generate this rtx and hence
there is no problem. It could still be latent but one has to dig deeper.
--
ramana dot r at gmail dot com changed:
What|Removed |Added
CC||rearnsha at arm dot com,
||ramana dot r at gmail dot
||com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39076
[Bug target/39076] internal compiler error when cross-compiling flac
--- Comment #5 from ramana dot r at gmail dot com 2009-02-03 22:06 --- (In reply to comment #4) Looking at the dumps this rtx is generated by the rename registers pass in 4.3.x . In trunk however rename register does not generate this rtx and hence there is no problem. It could still be latent but one has to dig deeper. A quick comparison of trunk and gcc 4.3 branch shows the following patch being applied in trunk vs. the 4.3 branch. http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01577.html A quick check with the patch at ram...@numenor:~/cos/mycos/gcc/gcc$ svn diff -r137128:137235 regrename.c Index: regrename.c === --- regrename.c (revision 137128) +++ regrename.c (revision 137235) @@ -812,7 +812,7 @@ OP_IN, 0); for (i = 0; i recog_data.n_dups; i++) - *recog_data.dup_loc[i] = copy_rtx (old_dups[i]); + *recog_data.dup_loc[i] = old_dups[i]; for (i = 0; i n_ops; i++) *recog_data.operand_loc[i] = old_operands[i]; if (recog_data.n_dups) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39076
[Bug lto/39049] New: ICE with an empty function
I was giving LTO a play and trying to look at some of the testsuite failures.
One of the failures that I am seeing is an ICE when I try to compile an empty
function. I reduced this from the ICE for c-torture/compile/20021204-1.c
void t(void)
{
}
The ICE occurs in cc1 with and without LTO
ram...@numenor:~/cos/build-try/gcc$ ./cc1 ~/20021204-1.i
/home/ramana/20021204-1.i:6: internal compiler error: in start_function, at
c-decl.c:6225
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
Doing a bt shows that
#0 fancy_abort (file=0xb7849834 )\003\204, line=178460604, function=0x1
Address 0x1 out of bounds) at ../../lto/gcc/diagnostic.c:711
#1 0x08067ac3 in start_function (declspecs=0xaa31720, declarator=0xaa317bc,
attributes=0x0) at ../../lto/gcc/c-decl.c:6225
#2 0x080c765a in c_parser_declaration_or_fndef (parser=0xb7849834,
fndef_ok=value optimized out, empty_ok=value optimized out, nested=0 '\0',
start_attr_ok=value optimized out) at ../../lto/gcc/c-parser.c:1278
#3 0x080c96b6 in c_parser_external_declaration (parser=0xb7849834) at
../../lto/gcc/c-parser.c:1076
#4 0x080ca4bb in c_parse_file () at ../../lto/gcc/c-parser.c:979
#5 0x080b0005 in c_common_parse_file (set_yydebug=0) at
../../lto/gcc/c-opts.c:1251
#6 0x08389371 in toplev_main (argc=2, argv=0xbf8535d4) at
../../lto/gcc/toplev.c:980
#7 0x080d8a0b in main (argc=2, argv=0xbf8535d4) at ../../lto/gcc/main.c:35
And the ICE is because of this particular line in c-decl.c : 6226. The comment
indicates that DECL_ASSEMBLER_NAME should not be set up at this point of time.
Ofcourse removing the assert helps this case go through, but the original test
seems to silently generate wrong code.
In gcc/c-decl.c:6225
/* This is the earliest point at which we might know the assembler
name of the function. Thus, if it's set before this, die horribly. */
gcc_assert (!DECL_ASSEMBLER_NAME_SET_P (decl1));
Simply removing the assert as expected doesn't help with the original test
failure because it ICE's elsewhere as a result of this change.
ram...@numenor:~/cos/build-try/gcc$ ./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: i686-pc-linux-gnu
Configured with: ../lto/configure --enable-languages=c,c++,lto
Thread model: posix
gcc version 4.4.0 20090127 (experimental) (lto merged with rev 143693)
Built with svn revision 143833.
--
Summary: ICE with an empty function
Product: gcc
Version: lto
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ramana dot r at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39049
[Bug lto/39016] New: [LTO] ICE in output_expr_operand because of BLOCK Expressions.
From running the testsuite and for the testcase 20021204-1.c /home/ramana/cos/build-try/gcc/cc1 -fpreprocessed 20021204-1.i -quiet -dumpbase 20021204-1.c -mtune=generic -auxbase-strip 20021204-1.o -O1 -w -version -flto -o 20021204-1.s #0 fancy_abort (file=0xa888740 P\207\210\nP\207\210\n\t, line=9, function=0xa888740 P\207\210\nP\207\210\n\t) at ../../lto/gcc/diagnostic.c:711 #1 0x0879703d in output_expr_operand (ob=0xa88a278, expr=0xb7805f50) at ../../lto/gcc/lto-function-out.c:1200 #2 0x08799303 in output_local_vars (ob=0xa88a278, fn=value optimized out) at ../../lto/gcc/lto-function-out.c:1373 #3 0x0879eabe in lto_output (set=0xb7794f0c) at ../../lto/gcc/lto-function-out.c:1968 #4 0x082dd8d9 in ipa_write_summaries_2 (pass=0x8a3fb40, set=0xb7794f0c, state=0xa88e718) at ../../lto/gcc/passes.c:1403 #5 0x082de7c2 in ipa_write_summaries_1 (set=0xb7794f0c) at ../../lto/gcc/passes.c:1428 #6 0x082de8aa in ipa_write_summaries () at ../../lto/gcc/passes.c:1449 #7 0x08577e08 in cgraph_optimize () at ../../lto/gcc/cgraphunit.c:1266 #8 0x0805f51b in c_write_global_declarations () at ../../lto/gcc/c-decl.c:8045 #9 0x08389399 in toplev_main (argc=15, argv=0xbfa31754) at ../../lto/gcc/toplev.c:991 #10 0x080d8a0b in main (argc=15, argv=0xbfa31754) at ../../lto/gcc/main.c:35 (gdb) p debug_tree (expr) block 0xb7805f50 used supercontext function_decl 0xb781e780 q type function_type 0xb7824144 type integer_type 0xb779d2f4 int QI size integer_cst 0xb778e508 constant 8 unit size integer_cst 0xb778e524 constant 1 align 8 symtab 0 alias set -1 canonical type 0xb77a7798 pointer_to_this pointer_type 0xb78241b0 addressable used static no-static-chain decl_5 QI file /home/ramana/cos/lto/gcc/testsuite/gcc.c-torture/compile/20021204-1.c line 8 col 7 align 8 initial block 0xb7805f50 result result_decl 0xb7796230 D.1233 type integer_type 0xb779d2f4 int ignored SI file /home/ramana/cos/lto/gcc/testsuite/gcc.c-torture/compile/20021204-1.c line 8 col 3 size integer_cst 0xb778e690 constant 32 unit size integer_cst 0xb778e47c constant 4 align 32 context function_decl 0xb781e780 q saved-insns 0xb77990fc $5 = void There was a similar bug reported for #39000 but that is for fdesc expressions on ia64 . -- Summary: [LTO] ICE in output_expr_operand because of BLOCK Expressions. Product: gcc Version: lto Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ramana dot r at gmail dot com GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39016
[Bug bootstrap/39001] lto branch doesn't build
--- Comment #2 from ramana dot r at gmail dot com 2009-01-28 14:49 --- (In reply to comment #0) It doesn't build on SLES10 either, libelf0-0.8.10-36, it ICEs during build of libgcc: ... /gcc/spec/sb-haydn-df-64/gcc/libgcc/../gcc/libgcc2.c:1102: 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. libelf shouldn't come into play while building, no? Program received signal SIGSEGV, Segmentation fault. output_call_frame_info (for_eh=0) at /gcc/spec/sb-haydn-df-64/gcc/gcc/expr.h:806 806 tree personality = DECL_FUNCTION_PERSONALITY (decl); #0 output_call_frame_info (for_eh=0) at /gcc/spec/sb-haydn-df-64/gcc/gcc/expr.h:806 #1 0x004ccf37 in dwarf2out_frame_finish () at /gcc/spec/sb-haydn-df-64/gcc/gcc/dwarf2out.c:3351 #2 0x00630dd6 in toplev_main (argc=value optimized out, argv=0x0) at /gcc/spec/sb-haydn-df-64/gcc/gcc/toplev.c:1023 #3 0x2ae177b25154 in __libc_start_main () from /lib64/libc.so.6 #4 0x00404199 in _start () this is on x86_64, the above ICE is with -m32. Richard. The same trouble appears on x86_64 Debian etch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39001
