[Bug target/60949] New: Thumb2 LRA ICE for case pr34856.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60949 Bug ID: 60949 Summary: Thumb2 LRA ICE for case pr34856.c Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: tony.wang at arm dot com I'm running regression test for the latest GCC trunk, and run into below ICE. And if I disable the LRA feature with option mno-lra, the test case will pass: ./install-native/bin/arm-none-eabi-gcc -fno-diagnostics-show-caret -O3 -fomit-frame-pointer -funroll-loops -w -c-mthumb -mcpu=cortex-m3 -o pr34856.o ./src/gcc/gcc/testsuite/gcc.c-torture/compile/pr34856.c ./src/gcc/gcc/testsuite/gcc.c-torture/compile/pr34856.c: In function 'f1': ./src/gcc/gcc/testsuite/gcc.c-torture/compile/pr34856.c:17:1: internal compiler error: in split_reg, at lra-constraints.c:4801 0x854bfc split_reg /work/arm_gcc/gcc-arm-none-eabi-4_8-2014q1-20140314/src/gcc/gcc/lra-constraints.c:4801 0x8558a5 split_if_necessary /work/arm_gcc/gcc-arm-none-eabi-4_8-2014q1-20140314/src/gcc/gcc/lra-constraints.c:4904 0x85df76 inherit_in_ebb /work/arm_gcc/gcc-arm-none-eabi-4_8-2014q1-20140314/src/gcc/gcc/lra-constraints.c:5391 0x85df76 lra_inheritance() /work/arm_gcc/gcc-arm-none-eabi-4_8-2014q1-20140314/src/gcc/gcc/lra-constraints.c:5552 0x84d74a lra(_IO_FILE*) /work/arm_gcc/gcc-arm-none-eabi-4_8-2014q1-20140314/src/gcc/gcc/lra.c:2368 0x80fb36 do_reload /work/arm_gcc/gcc-arm-none-eabi-4_8-2014q1-20140314/src/gcc/gcc/ira.c:5457 0x80fb36 execute /work/arm_gcc/gcc-arm-none-eabi-4_8-2014q1-20140314/src/gcc/gcc/ira.c:5618 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions.
[Bug target/59904] [ARM] tls-reload-1.c fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59904 wangzheyu changed: What|Removed |Added CC||tony.wang at arm dot com --- Comment #2 from wangzheyu --- Hi, I'm trying to reproduce this bug on the panda board(cortex-a9). With the same configuration, the case does meet some execution failure, but in order to clarify what happened on earth, could you please provide your own elf? (In reply to christophe.lyon from comment #0) > Since commit 206897 (LRA fix PR rtl-optimization/59858) > I have noticed that: > gcc.dg/torture/tls/tls-reload-1.c -Os -pie -fPIE execution test > gcc.dg/torture/tls/tls-reload-1.c -Os -pie -fpie execution test > > the compiler used to ICE, but after the LRA fix the generated code is not > functional. > > I have tested with qemu-arm, target arm-none-linux-gnueabi, > --with-mode=thumb --with-cpu=cortex-a9, using RUNTESTFLAGS=-march=armv5t > > gcc.log contains: > qemu: uncaught target signal 6 (Aborted) - core dumped
[Bug target/59904] [ARM] tls-reload-1.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59904 --- Comment #4 from wangzheyu --- Hi christophe, It's ok from my side, the link time is ok. I'm not sure if it's related to your tool chain version, but would you please provide detailed information of your toolchain, the cmd you run for the test case, and where you get this version binutils? (In reply to christophe.lyon from comment #3) > Sorry I no longer have the elf file available. > I've just looked at the current trunk status and I have a failure at link > time for these tests: > ld: gcc_tg.o: relocation R_ARM_MOVW_ABS_NC against `a local symbol' can not > be used when making a shared object; recompile with -fPIC > gcc_tg.o: error adding symbols: Bad value > collect2: error: ld returned 1 exit status > compiler exited with status 1 > > Not sure if it's a problem with the binutils I use (linaro-2.24-2013.12) or > a known problem with the GCC test?
[Bug target/59904] [ARM] tls-reload-1.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59904
--- Comment #7 from wangzheyu ---
After a close analysis of your elf, it will fail due to bad code in first call
to function checktls23. The corresponding C code is:
if (!y || *y++ != &tls23 || *y++ != &tls23_array[3]) return 0;
The code to get address of variable tls23 is wrongly fixed up. Here is the
assembly code with analysis embedded:
checktls23:
push{r4, lr}
mov r3, r0
sub r2, r0, #0
beq .L136
ldr r2, .L140 << get offset of variable tls23
ldr r1, [r0]
bl __aeabi_read_tp @ load_tp_soft << get thread point and save it
to r0
add r0, r0, r2 << thread point plus offset equals address of
variable tls23
mov r2, #0
cmp r1, r0
bne .L136
ldr r4, .L140+4
bl __aeabi_read_tp @ load_tp_soft
ldr r1, [r3, #4]
add r0, r0, r4
cmp r1, r0
bne .L136
add r3, r3, #8
mov r2, r3
.L136:
mov r0, r2
@ sp needed
pop {r4, pc}
.L141:
.align 2
.L140:
.word .LANCHOR2(tpoff)+124 << offset of tls23 is correctly
generated. but never get correctly fixed up.
.word .LANCHOR3(tpoff)+12
So my advice is to use a newer version of binutils to test it again.
(In reply to christophe.lyon from comment #6)
> I have re-run the tests with trunk@210140 and older binutils (Sept 2013).
>
> The test fails at compilation with target arm-none-linux-gnueabi, and
> CFLAGS=-Os -pie -fpie or -Os -pie -fPIE in the following configurations:
> --with-mode=arm --with-cpu=cortex-a9
> --with-mode=arm --with-cpu=cortex-a9 RUNTESTFLAGS=-mthumb
> --with-mode=thumb --with-cpu=cortex-a9
> --with-mode=thumb --with-cpu=cortex-a9 RUNTESTFLAGS=-marm
>
> The test compiles OK and fails at execution with
> --with-mode=thumb --with-cpu=cortex-a9 RUNTESTFLAGS=-march=armv5t
> (this is the ELF file I have attached)
>
> The compiles and runs OK with
> --with-mode=arm --with-cpu=cortex-a9 RUNTESTFLAGS=-march=armv5t
[Bug target/59904] [ARM] tls-reload-1.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59904 --- Comment #9 from wangzheyu --- Hi, would please provide your elf file with the new binutils, so that we can verify that whether it's the same issue as your former elf. If it is, it can be verified as a bug because you're using the latest binutils-linaro. We will investigate this issue further. Thanks a lot. (In reply to christophe.lyon from comment #8) > Using GCC trunk @210861, binutils-linaro-2.24-2014.03, I can see that > tls-reload-1.c all PASS with: > --target arm-none-linux-gnueabi --with-mode=arm --with-cpu=cortex-a9 > --with-fpu=neon and target_board set to -march=armv5t. > > When changing to --with-mode=thumb, I can see 10 failures at execution time, > with "-pie -fpie" and -pie -fPIE" combined with -O1, -O2, -O3 > -fomit-frame-pointer, -O3 -g, and -Os.
[Bug target/61330] New: Thumb ICE for case 920507-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61330 Bug ID: 61330 Summary: Thumb ICE for case 920507-1.c Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: tony.wang at arm dot com I'm running regression test for the latest GCC trunk for cortex-m0, I run into below ICE, but after I remove the commit at trunk@210901, the test case will pass. How to reproduce: Executing on host: /work/terguo01/trunk-t1/build-native/gcc-final/gcc/xgcc -B/work/terguo01/trunk-t1/build-native/gcc-final/gcc/ /work/terguo01/trunk-t1/src/gcc/gcc/testsuite/gcc.dg/noncompile/920507-1.c -fno-diagnostics-show-caret -fdiagnostics-color=never -O1 -ffat-lto-objects -S-mthumb -mcpu=cortex-m0 -o 920507-1.s(timeout = 300) spawn /work/terguo01/trunk-t1/build-native/gcc-final/gcc/xgcc -B/work/terguo01/trunk-t1/build-native/gcc-final/gcc/ /work/terguo01/trunk-t1/src/gcc/gcc/testsuite/gcc.dg/noncompile/920507-1.c -fno-diagnostics-show-caret -fdiagnostics-color=never -O1 -ffat-lto-objects -S -mthumb -mcpu=cortex-m0 -o 920507-1.s^M /work/terguo01/trunk-t1/src/gcc/gcc/testsuite/gcc.dg/noncompile/920507-1.c: In function 'x':^M /work/terguo01/trunk-t1/src/gcc/gcc/testsuite/gcc.dg/noncompile/920507-1.c:5:16: error: invalid register name for 'a'^M /work/terguo01/trunk-t1/src/gcc/gcc/testsuite/gcc.dg/noncompile/920507-1.c:3:1: internal compiler error: in symtab_get_node, at cgraph.h:1021^M 0xc1920c symtab_get_node^M /work/terguo01/trunk-t1/src/gcc/gcc/cgraph.h:1018^M 0xc1920c symtab_get_node^M /work/terguo01/trunk-t1/src/gcc/gcc/varasm.c:1134^M 0xc1920c decl_comdat_group^M /work/terguo01/trunk-t1/src/gcc/gcc/cgraph.h:1629^M 0xc1920c get_block_for_decl^M /work/terguo01/trunk-t1/src/gcc/gcc/varasm.c:1146^M 0xc1cadf make_decl_rtl(tree_node*)^M /work/terguo01/trunk-t1/src/gcc/gcc/varasm.c:1376^M 0x8d6b4f rest_of_decl_compilation(tree_node*, int, int)^M /work/terguo01/trunk-t1/src/gcc/gcc/passes.c:215^M 0x6206a3 expand_one_hard_reg_var^M /work/terguo01/trunk-t1/src/gcc/gcc/cfgexpand.c:1108^M 0x6206a3 expand_one_var^M /work/terguo01/trunk-t1/src/gcc/gcc/cfgexpand.c:1295^M 0x620e0b expand_used_vars_for_block^M /work/terguo01/trunk-t1/src/gcc/gcc/cfgexpand.c:1338^M 0x62c1e6 expand_used_vars^M
[Bug target/59904] [ARM] tls-reload-1.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59904 --- Comment #11 from wangzheyu --- Hi, Could you please provide an elf file compiled with arm-none-linux-gnueabi-gcc -Os -g3 -pie -fpie -mthumb -march=armv5t So that we can debug under our hardware and easy to compared with the former one. Thanks a lot. (In reply to christophe.lyon from comment #10) > Created attachment 32863 [details] > ELF binary file #2 > > Compiled with arm-none-linux-gnueabi-gcc -O1 -pie -fpie -mthumb > -march=armv5t tls-reload-1.c -o tls-reload-1.exe > > Binutils Linaro 2014.03
[Bug target/61713] New: 4.9 ICE when building c++ code with atomic functions for thumb1 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61713
Bug ID: 61713
Summary: 4.9 ICE when building c++ code with atomic functions
for thumb1 target
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tony.wang at arm dot com
The tool chain is built from:
gcc version 4.9.1 20140630 (prerelease) [gcc-4_9-branch revision 212159]
when compile below code, there will be ICE.
int main()
{
typedef bool atomic_type;
atomic_type c1;
atomic_type c2;
atomic_type c3(0);
__atomic_fetch_add(&c1, c2, __ATOMIC_RELAXED);
__atomic_compare_exchange_n(&c1, &c2, c3, true, __ATOMIC_ACQ_REL,
__ATOMIC_RELAXED);
__atomic_test_and_set(&c1, __ATOMIC_RELAXED);
__atomic_load_n(&c1, __ATOMIC_RELAXED);
return 0;
}
Remember to save it as a c++ source file. For the debuggabe gcc, the ICE is:
at1.cpp: In function 'int main()':
at1.cpp:12:47: internal compiler error: in emit_move_insn, at expr.c:3609
__atomic_test_and_set(&c1, __ATOMIC_RELAXED);
^
0x83c8240 emit_move_insn(rtx_def*, rtx_def*)
/home/build/temp/gcc-arm-none-eabi-4_9-2014q3-20140701/src/gcc/gcc/expr.c:3608
0x850f85d expand_atomic_test_and_set(rtx_def*, rtx_def*, memmodel)
/home/build/temp/gcc-arm-none-eabi-4_9-2014q3-20140701/src/gcc/gcc/optabs.c:7337
0x82ee779 expand_builtin_atomic_test_and_set
/home/build/temp/gcc-arm-none-eabi-4_9-2014q3-20140701/src/gcc/gcc/builtins.c:5552
0x82ee779 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
/home/build/temp/gcc-arm-none-eabi-4_9-2014q3-20140701/src/gcc/gcc/builtins.c:6781
0x83c3382 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/build/temp/gcc-arm-none-eabi-4_9-2014q3-20140701/src/gcc/gcc/expr.c:10327
0x830bd38 expand_expr
/home/build/temp/gcc-arm-none-eabi-4_9-2014q3-20140701/src/gcc/gcc/expr.h:457
0x830bd38 expand_call_stmt
/home/build/temp/gcc-arm-none-eabi-4_9-2014q3-20140701/src/gcc/gcc/cfgexpand.c:2275
0x830bd38 expand_gimple_stmt_1
/home/build/temp/gcc-arm-none-eabi-4_9-2014q3-20140701/src/gcc/gcc/cfgexpand.c:3170
0x830bd38 expand_gimple_stmt
/home/build/temp/gcc-arm-none-eabi-4_9-2014q3-20140701/src/gcc/gcc/cfgexpand.c:3322
0x830c896 expand_gimple_basic_block
/home/build/temp/gcc-arm-none-eabi-4_9-2014q3-20140701/src/gcc/gcc/cfgexpand.c:5162
0x830ebae gimple_expand_cfg
/home/build/temp/gcc-arm-none-eabi-4_9-2014q3-20140701/src/gcc/gcc/cfgexpand.c:5741
0x830ebae execute
/home/build/temp/gcc-arm-none-eabi-4_9-2014q3-20140701/src/gcc/gcc/cfgexpand.c:5961
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
For the release version gcc, the ICE is:
build@build-desktop:~/temp/gcc-arm-none-eabi-4_9-2014q3-20140701/case$
../install-native/bin/arm-none-eabi-g++ -mthumb -O0 at1.cpp -S
at1.cpp: In function 'int main()':
at1.cpp:12:47: internal compiler error: in emit_move_insn, at expr.c:3609
__atomic_test_and_set(&c1, __ATOMIC_RELAXED);
^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
[Bug target/61713] ICE when building c++ code with atomic functions for thumb1 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61713 --- Comment #1 from wangzheyu --- This ICE also happened on the trunk.
[Bug target/61330] [4.10 Regression] Thumb ICE for case 920507-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61330
--- Comment #5 from wangzheyu ---
(In reply to Richard Biener from comment #1)
> Seems the parser fails to set DECL_HARD_REGISTER on that bogus decl.
Hi Richard,
I find that in function make_decl_rtl(gcc/varasm.c:1357), there's one line
comment:
/* As a register variable, it has no section. */
And for the correct reigster type declaration like: register int *a asm(“r1”),
the program will just directly return(gcc/varasm.c:1358), and won't sink into
the symbol ref generation part. So symtab_get_node won't be called.
It seems to be a long time for the invalid register type declaration to be sink
into the symbol ref generation part of function make_decl_rtl, which will also
lead to wrong rtx generation.
register int *a asm("r1")=>(reg:SI 1 r1 [orig:0 a] [0])
register int *a asm("unknown register")=>(symbol_ref:SI ("unknown register")
[flag 0x80])
[Bug target/61883] New: [4.10 Regression]ICE for gcc.dg/tls/alias-1.c on arm target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61883
Bug ID: 61883
Summary: [4.10 Regression]ICE for gcc.dg/tls/alias-1.c on arm
target
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tony.wang at arm dot com
The trunk will ICE when user declare tls variables with alias name on run-time
need to generate emutls variables.
How to reproduce:
/work/tonwan01/test_alias$
/work/tonwan01/gcc/gcc-arm-none-eabi-4_9-2014q2-20140515/install-native/lib/gcc/arm-none-eabi/4.10.0/cc1
-quiet -v -D_USES_INITFINI_ alias-1-clean.c -quiet -dumpbase alias-1-clean.c
-mthumb -mcpu=cortex-m0 -auxbase-strip alias-1.exe -version -o /tmp/cc0AHQ0g.s
alias-1.c:24:3: internal compiler error: Segmentation fault
_attribute_ ((visibility ("hidden")));
^
0xbdde7f crash_signal
/work/tonwan01/gcc/gcc-arm-none-eabi-4_9-2014q2-20140515/src/gcc/gcc/toplev.c:337
0x78b390 symtab_alias_target
/work/tonwan01/gcc/gcc-arm-none-eabi-4_9-2014q2-20140515/src/gcc/gcc/cgraph.h:1535
0x78d629 verify_symtab_base(symtab_node*)
/work/tonwan01/gcc/gcc-arm-none-eabi-4_9-2014q2-20140515/src/gcc/gcc/symtab.c:830
0x78d7bb verify_symtab_node(symtab_node*)
/work/tonwan01/gcc/gcc-arm-none-eabi-4_9-2014q2-20140515/src/gcc/gcc/symtab.c:863
0x78d823 verify_symtab()
/work/tonwan01/gcc/gcc-arm-none-eabi-4_9-2014q2-20140515/src/gcc/gcc/symtab.c:881
0x9e6e85 symtab_remove_unreachable_nodes(bool, _IO_FILE*)
/work/tonwan01/gcc/gcc-arm-none-eabi-4_9-2014q2-20140515/src/gcc/gcc/ipa.c:592
0x7a09f3 ipa_passes
/work/tonwan01/gcc/gcc-arm-none-eabi-4_9-2014q2-20140515/src/gcc/gcc/cgraphunit.c:2065
0x7a0d70 compile()
/work/tonwan01/gcc/gcc-arm-none-eabi-4_9-2014q2-20140515/src/gcc/gcc/cgraphunit.c:2187
0x7a107c finalize_compilation_unit()
/work/tonwan01/gcc/gcc-arm-none-eabi-4_9-2014q2-20140515/src/gcc/gcc/cgraphunit.c:2342
0x60ba71 c_write_global_declarations()
/work/tonwan01/gcc/gcc-arm-none-eabi-4_9-2014q2-20140515/src/gcc/gcc/c/c-decl.c:10452
The reason for this bug is that in the tree-emutls.c pass, the code imply a
default sequence of tls symbol and its corresponding control symbol. Some patch
now move the symtab node generation to a very early stage, so the sequence of
the node in varpool changed which leads to the wrong mapping of tls var and
control var.
For case gcc.dg/tls/alias-1.c
Before:
tls_vars[0]:bar(alias foo)
tls_vars[1]:foo
control_vars[0]:_emutls_v.foo
control_vars[1]:_emutls_v.bar(alias _emutls_v.foo)
So when generate the reference list of main, the actual reference of bar would
be _emutls_v.foo which is correct.
After:
tls_vars[1]:bar(alias foo)
tls_vars[0]:foo
control_vars[0]:_emutls_v.foo
control_vars[1]:_emutls_v.bar(alias _emutls_v.foo)
The reference list of main will point to the alias symbol node _emutls_v.bar,
which finally cause the segment fault.
I also a simpler test case to reproduce this bug, it should be an old bug for
the tree-emutls pass. The way this pass mapping the control vars and tls vars
hasn't consider that there may more than one alias for a tls var. For run time
support tls, the code can compile successfully.
struct __res_state {
char x[123];
};
__thread struct __res_state foo;
extern __thread struct __res_state bar
__attribute__ ((alias ("foo")));
extern __thread struct __res_state baz
__attribute__ ((alias ("foo")));
int main()
{
bar.x[0] = 0;
baz.x[1] = 1;
return 0;
}
[Bug target/61883] [4.10 Regression]ICE for gcc.dg/tls/alias-1.c on arm target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61883 --- Comment #1 from wangzheyu --- For target don't support tls, the above simple test case will fail for the same reason of gcc.dg/tls/alias-1.c.
[Bug regression/61548] [4.10 Regression] FAIL: gcc.dg/tls/alias-1.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61548
--- Comment #7 from wangzheyu ---
I have a simpler test case to reproduce this bug, it should be an old bug for
the tree-emutls pass. The way this pass mapping the control vars and tls vars
hasn't consider that there may more than one alias for a tls var. For target
supports tls, the code can compile successfully, but the target doesn't support
tls will fail.
struct __res_state {
char x[123];
};
__thread struct __res_state foo;
extern __thread struct __res_state bar
__attribute__ ((alias ("foo")));
extern __thread struct __res_state baz
__attribute__ ((alias ("foo")));
int main()
{
bar.x[0] = 0;
baz.x[1] = 1;
return 0;
}
[Bug target/61330] [4.10 Regression] Thumb ICE for case 920507-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61330 --- Comment #6 from wangzheyu --- Posted a possible fix for this bug: https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01938.html
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 wangzheyu changed: What|Removed |Added CC||tony.wang at arm dot com --- Comment #64 from wangzheyu --- > > Fix: > > Index: gcc/tree-ssa-loop-ivopts.c > === > --- gcc/tree-ssa-loop-ivopts.c (revision 213050) > +++ gcc/tree-ssa-loop-ivopts.c (working copy) > @@ -1704,6 +1704,8 @@ may_be_unaligned_p (tree ref, tree step) > return false; > >unsigned int align = TYPE_ALIGN (TREE_TYPE (ref)); > + if (GET_MODE_ALIGNMENT (TYPE_MODE (TREE_TYPE (ref))) > align) > +align = GET_MODE_ALIGNMENT (TYPE_MODE (TREE_TYPE (ref))); > >unsigned HOST_WIDE_INT bitpos; >unsigned int ref_align; > > can you test and apply that patch? Also run into a similar regression on arm target, which will generate unaligned memory access on target which don't support unaligned data access. This patch does fix this regression. Thx
[Bug c++/62150] [5.0 regression] test case g++.dg/ext/arm-fp16/fp16-mangle-1.C failed on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62150 wangzheyu changed: What|Removed |Added CC||tony.wang at arm dot com --- Comment #2 from wangzheyu --- Also happened on thumb1/thumb2.
[Bug lto/62213] New: [5 Rgression] ICE in lto for test case 20081120-1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62213 Bug ID: 62213 Summary: [5 Rgression] ICE in lto for test case 20081120-1 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: tony.wang at arm dot com Run into a lto test case ICE on trunk. /home/build/work/GCC-5-0-build/build-native/gcc-final/gcc/xgcc -B/home/build/work/GCC-5-0-build/build-native/gcc-final/gcc/ -fno-diagnostics-show-caret -fdiagnostics-color=never -flto -r -nostdlib -c -mthumb -mcpu=cortex-m0 -o c_lto_20081120-1_0.o /home/build/work/GCC-5-0-build/src/gcc/gcc/testsuite/gcc.dg/lto/20081120-1_0.c /home/build/work/GCC-5-0-build/build-native/gcc-final/gcc/xgcc -B/home/build/work/GCC-5-0-build/build-native/gcc-final/gcc/ -fno-diagnostics-show-caret -fdiagnostics-color=never -flto -r -nostdlib -c -mthumb -mcpu=cortex-m0 -o c_lto_20081120-1_1.o /home/build/work/GCC-5-0-build/src/gcc/gcc/testsuite/gcc.dg/lto/20081120-1_1.c /home/build/work/GCC-5-0-build/build-native/gcc-final/gcc/xgcc -B/home/build/work/GCC-5-0-build/build-native/gcc-final/gcc/ c_lto_20081120-1_0.o c_lto_20081120-1_1.o gcc_tg.o -fno-diagnostics-show-caret -fdiagnostics-color=never -flto -r -nostdlib -Wl,-wrap,exit -Wl,-wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort -mthumb -mcpu=cortex-m0 -o gcc-dg-lto-20081120-1-01.exe lto1: internal compiler error: in do_whole_program_analysis, at lto/lto.c:3249^M 0x81b8acf do_whole_program_analysis^M /home/build/work/GCC-5-0-build/src/gcc/gcc/lto/lto.c:3249^M 0x81b8acf lto_main()^M /home/build/work/GCC-5-0-build/src/gcc/gcc/lto/lto.c:3427^M Please submit a full bug report,^M with preprocessed source if appropriate.^M Please include the complete backtrace with any bug report.^M See <http://gcc.gnu.org/bugs.html> for instructions.^M lto-wrapper: fatal error: /home/build/work/GCC-5-0-build/build-native/gcc-final/gcc/xgcc returned 1 exit status^M compilation terminated.^M /home/build/work/GCC-5-0-build/install-native/arm-none-eabi/bin/ld: lto-wrapper failed^M collect2: error: ld returned 1 exit status^M compiler exited with status 1 output is: lto1: internal compiler error: in do_whole_program_analysis, at lto/lto.c:3249^M 0x81b8acf do_whole_program_analysis^M /home/build/work/GCC-5-0-build/src/gcc/gcc/lto/lto.c:3249^M 0x81b8acf lto_main()^M /home/build/work/GCC-5-0-build/src/gcc/gcc/lto/lto.c:3427^M Please submit a full bug report,^M with preprocessed source if appropriate.^M Please include the complete backtrace with any bug report.^M See <http://gcc.gnu.org/bugs.html> for instructions.^M lto-wrapper: fatal error: /home/build/work/GCC-5-0-build/build-native/gcc-final/gcc/xgcc returned 1 exit status^M compilation terminated.^M /home/build/work/GCC-5-0-build/install-native/arm-none-eabi/bin/ld: lto-wrapper failed^M collect2: error: ld returned 1 exit status^M
[Bug libgcc/56846] _Unwind_Backtrace on ARM and noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56846 wangzheyu changed: What|Removed |Added CC||tony.wang at arm dot com --- Comment #6 from wangzheyu --- Confirmed on arm tagret, and there's an old discussion on this: http://gcc.gnu.org/ml/gcc/2007-08/msg00235.html. I'm working on a patch to fix this.
[Bug libgcc/56846] _Unwind_Backtrace on ARM and noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56846
--- Comment #7 from wangzheyu ---
Another test case doesn't involve noexcept key workd.
Cmd line: arm-none-eabi-g++ -mthumb -mcpu=cortex-m3 -O0 -g -std=c++11
-specs=rdimon.specs main.c -o main.exe
#include
#include
_Unwind_Reason_Code trace_func(struct _Unwind_Context * context, void* arg) {
void *ip = (void *)_Unwind_GetIP(context);
printf("Address: %p\n", ip);
return _URC_NO_REASON;
}
void bar()
{
puts("This is in bar");
_Unwind_Backtrace((_Unwind_Trace_Fn)&trace_func, 0);
}
void foo()
{
try
{
bar();
}
catch (...)
{
puts("Exception");
}
}
