Searching on "Segmentation fault" in the bugzilla returns hundreds of matches so I can't really verify this is new, sorry! But at least it's a small testcase :). Valgrind talks about a read past the bound of a malloc'd block and also about a null ptr dereference -- hard to tell what is the real problem. [regehr@gamow tmp435]$ current-gcc -c small.c -O2 small.c: In function 'func_115': small.c:30:1: 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. [regehr@gamow tmp435]$ current-gcc -v Using built-in specs. COLLECT_GCC=current-gcc COLLECT_LTO_WRAPPER=/uusoc/exports/scratch/regehr/z/compiler-install/gcc-r168380-install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../configure --with-libelf=/usr/local --enable-lto --prefix=/home/regehr/z/compiler-install/gcc-r168380-install --program-prefix=r168380- --enable-languages=c,c++ Thread model: posix gcc version 4.6.0 20101231 (experimental) (GCC) [regehr@gamow tmp435]$ cat small.c typedef signed char int8_t; typedef int int32_t; typedef unsigned int uint32_t; static uint32_t safe_add_func_uint32_t_u_u (uint32_t ui1, uint32_t ui2) { return ui1 + ui2; }; int8_t *const func_112 (int32_t * p_113, int8_t p_114) { func_115 (func_115, 0); return 0; } int32_t func_115 (uint32_t p_116, uint32_t p_117, int8_t * p_118) { int32_t l_141; int32_t *l_186 = &l_141; if (l_141) { } else for (l_141 = 0; l_141; l_141 = safe_add_func_uint32_t_u_u (l_141, 1)) { } return *l_186; }
Caused by partial inlining. Smaller testcase: int foo (__UINTPTR_TYPE__ x) { int a = 6; int *b = &a; if (x) for (a = 0; a; a++) ; return a; } void bar (void) { foo ((__UINTPTR_TYPE__) foo); }
It is caused by revision 161433: http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg01351.html
I'm looking at it.
It appears that we create a new edge to the exit block, which in turn creates a new phi arg for the vop. That phi arg is never initialized. The partial inlining code arranges to fixup the phi for the return value, but never does so for the vop. There's some code which marks the vop for renaming and removes its phi, but it doesn't trigger for this testcase. I suspect that's the root of our problem and if we fix that conditional things ought to be OK.
Created attachment 22938 [details] FIx for PR 47141
Author: law Date: Mon Jan 10 16:48:42 2011 New Revision: 168634 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168634 Log: * PR tree-optimization/47141 * ipa-split.c (split_function): Handle case where we are returning a value and the return block has a virtual operand phi. * gcc.c-torture/compile/pr47141.c: New test. Approved by richie in IRC Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr47141.c Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-split.c trunk/gcc/testsuite/ChangeLog
Resolved