| Summary: | [4.6 Regression] -freorder-blocks-and-partition -g failed and libstdc++ builds for arm-eabi are broken. | ||
|---|---|---|---|
| Product: | gcc | Reporter: | John Tytgat <john> |
| Component: | middle-end | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | RESOLVED FIXED | ||
| Severity: | critical | CC: | dimhen, hubicka, jiez, joel, ramana, rmansfield, zsojka |
| Priority: | P3 | ||
| Version: | 4.6.0 | ||
| Target Milestone: | 4.6.0 | ||
| Host: | Target: | arm | |
| Build: | Known to work: | ||
| Known to fail: | Last reconfirmed: | 2010-11-26 11:29:17 | |
| Attachments: | Testcase for ARM | ||
|
Description
John Tytgat
2010-11-26 00:40:00 UTC
This probably isn't specific to arm, I am getting the same error at x86_64-linux with -freorder-blocks-and-partition -g:
----- testcase.c -----
void foo() {}
----------------------
$ gcc -freorder-blocks-and-partition -g testcase.c
testcase.c: In function 'foo':
testcase.c:1:6: error: foo causes a section type conflict
testcase.c:1:6: error: foo causes a section type conflict
testcase.c:1:6: error: foo causes a section type conflict
I see this failure as well starting from a couple of nights back. Ramana It is caused by revision 167085: http://gcc.gnu.org/ml/gcc-cvs/2010-11/msg00974.html arm-eabi builds for libstdc++ are still broken. ARM doesn't use freorder-blocks-and-partition by default thus it's probably more generic than that ! So saying freorder-blocks-and-partition is the only thing broken isn't correct. Ramana (In reply to comment #3) > It is caused by revision 167085: > > http://gcc.gnu.org/ml/gcc-cvs/2010-11/msg00974.html Yes, confirmed here as well. This is the regression. Also impacts arm-*-rtems* Here's the backtrace I see for arm-eabi.
#0 error (gmsgid=0xf323c8 "%+D causes a section type conflict") at ../../combined/gcc/diagnostic.c:747
#1 0x0000000000affd0d in get_section (name=0xf324e2 ".text.unlikely", flags=2099456, decl=0x2ba5b228f900) at ../../combined/gcc/varasm.c:301
#2 0x0000000000afff64 in get_named_section (decl=0x2ba5b228f900, name=0xf324e2 ".text.unlikely", reloc=0) at ../../combined/gcc/varasm.c:392
#3 0x0000000000b007ea in get_named_text_section (decl=0x2ba5b228f900, text_section_name=0xf324e2 ".text.unlikely", named_section_suffix=0x0)
at ../../combined/gcc/varasm.c:531
#4 0x0000000000b00880 in default_function_section (decl=0x2ba5b228f900, freq=NODE_FREQUENCY_UNLIKELY_EXECUTED, startup=0 '\0', exit=0 '\0')
at ../../combined/gcc/varasm.c:554
#5 0x0000000000b00955 in function_section_1 (decl=0x2ba5b228f900, force_cold=1 '\001') at ../../combined/gcc/varasm.c:605
#6 0x0000000000b009b8 in current_function_section () at ../../combined/gcc/varasm.c:635
#7 0x0000000000b39835 in arm_is_long_call_p (decl=0x2ba5b225cd00) at ../../combined/gcc/config/arm/arm.c:5001
#8 0x0000000000b39937 in arm_function_ok_for_sibcall (decl=0x2ba5b225cd00, exp=0x2ba5b2a84370) at ../../combined/gcc/config/arm/arm.c:5033
#9 0x00000000006b1a4b in expand_call (exp=0x2ba5b2a84370, target=0x0, ignore=1) at ../../combined/gcc/calls.c:2306
#10 0x00000000007614e0 in expand_expr_real_1 (exp=0x2ba5b2a84370, target=0x0, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at ../../combined/gcc/expr.c:9299
#11 0x00000000006c2796 in expand_gimple_stmt (stmt=0x2ba5b22caee0) at ../../combined/gcc/cfgexpand.c:1916
#12 0x00000000006c342b in expand_gimple_basic_block (bb=0x2ba5b253e548) at ../../combined/gcc/cfgexpand.c:2154
#13 0x00000000006c47b8 in gimple_expand_cfg () at ../../combined/gcc/cfgexpand.c:4046
#14 0x0000000000897d6f in execute_one_pass (pass=0x136b600) at ../../combined/gcc/passes.c:1553
#15 0x0000000000898065 in execute_pass_list (pass=0x136b600) at ../../combined/gcc/passes.c:1608
#16 0x000000000099c576 in tree_rest_of_compilation (fndecl=0x2ba5b228f900) at ../../combined/gcc/tree-optimize.c:422
#17 0x0000000000b4d650 in cgraph_expand_function (node=0x2ba5b2465420) at ../../combined/gcc/cgraphunit.c:1508
#18 0x0000000000b50469 in cgraph_optimize () at ../../combined/gcc/cgraphunit.c:1567
#19 0x0000000000b5089d in cgraph_finalize_compilation_unit () at ../../combined/gcc/cgraphunit.c:1031
#20 0x0000000000548c67 in cp_write_global_declarations () at ../../combined/gcc/cp/decl2.c:3973
#21 0x0000000000940051 in toplev_main (argc=25, argv=0x7ffff9418f78) at ../../combined/gcc/toplev.c:591
#22 0x000000350401d974 in __libc_start_main () from /lib64/libc.so.6
#23 0x000000000048a669 in _start ()
In a compiler configured in a combined tree with :
../combined/configure --with-newlib --target=arm-eabi --with-cpu=cortex-a9 --with-fpu=vfpv3-d16 --with-float=softfp --with-gmp=/projects/pl802_weddell/tools/linux_x86_64 --with-mpfr=/projects/pl802_weddell/tools/linux_x86_64 --with-mpc=/projects/pl802_weddell/tools/linux_x86_64 --enable-languages=c,c++
Created attachment 22605 [details]
Testcase for ARM
Backtrace shown in previous comment from the following debugging arguments.
gdb --args /work/fsfwork/git/build-latest-eabi-clone/./gcc/cc1plus -fpreprocessed string-inst.ii -quiet -dumpbase string-inst.cc -mcpu=cortex-a9 -mfloat-abi=softfp -mfpu=vfpv3-d16 -auxbase-strip string-inst.o -g -O2 -Wall -Wextra -Wwrite-strings -Wcast-qual -std=gnu++0x -version -fno-implicit-templates -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -o string-inst.s
I see the similar issue too when building libstdc++ for arm-none-linux-gnueabi target. Chung-Lin Tang told me he had a patch for this: http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00137.html Author: hubicka Date: Tue Dec 14 13:07:05 2010 New Revision: 167795 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167795 Log: PR middle-end/46667 * varasm.c (assemble_start_function): Do not call resolve_unique_section. * cfgexpand.c (gimple_expand_cfg): Resolve it here. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c trunk/gcc/varasm.c Fixed. |