User account creation filtered due to spam.

Bug 47141 - [4.6 Regression] segfault
Summary: [4.6 Regression] segfault
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 4.6.0
: P1 normal
Target Milestone: 4.6.0
Assignee: Jeffrey A. Law
URL:
Keywords: ice-on-valid-code
Depends on:
Blocks:
 
Reported: 2011-01-01 01:47 UTC by John Regehr
Modified: 2011-01-10 16:51 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2011-01-01 13:36:34


Attachments
FIx for PR 47141 (1000 bytes, patch)
2011-01-10 13:51 UTC, Jeffrey A. Law
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description John Regehr 2011-01-01 01:47:21 UTC
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;
}
Comment 1 Jakub Jelinek 2011-01-01 13:36:34 UTC
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);
}
Comment 2 H.J. Lu 2011-01-01 17:08:59 UTC
It is caused by revision 161433:

http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg01351.html
Comment 3 Jeffrey A. Law 2011-01-06 23:14:27 UTC
I'm looking at it.
Comment 4 Jeffrey A. Law 2011-01-07 15:43:11 UTC
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.
Comment 5 Jeffrey A. Law 2011-01-10 13:51:05 UTC
Created attachment 22938 [details]
FIx for PR 47141
Comment 6 Jeffrey A. Law 2011-01-10 16:48:46 UTC
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
Comment 7 Jeffrey A. Law 2011-01-10 16:51:05 UTC
Resolved