Bug 37183 - [4.4 Regression] ice in df_ref_chain_change_bb
Summary: [4.4 Regression] ice in df_ref_chain_change_bb
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: rtl-optimization (show other bugs)
Version: 4.4.0
: P3 normal
Target Milestone: 4.4.0
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-on-valid-code
Depends on:
Blocks:
 
Reported: 2008-08-21 02:23 UTC by John Regehr
Modified: 2008-12-28 20:22 UTC (History)
2 users (show)

See Also:
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John Regehr 2008-08-21 02:23:35 UTC
This is seen using r139367 on Ubuntu Hardy on ia32.  Also see bug 36984.

regehr@john-home:~/volatile/tmp9$ current-gcc -O3 small.c
small.c: In function ‘func_2’:
small.c:24: internal compiler error: in df_ref_chain_change_bb, at df-scan.c:1828
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

regehr@john-home:~/volatile/tmp9$ current-gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --program-prefix=current- --enable-languages=c,c++ --prefix=/home/regehr : (reconfigured) ../configure --program-prefix=current- --enable-languages=c,c++ --prefix=/home/regehr : (reconfigured) ../configure --program-prefix=current- --enable-languages=c,c++ --prefix=/home/regehr
Thread model: posix
gcc version 4.4.0 20080821 (experimental) (GCC) 

regehr@john-home:~/volatile/tmp9$ cat small.c

typedef signed char int8_t;
typedef int int32_t;
typedef unsigned short int uint16_t;
typedef unsigned int uint32_t;
static inline unsigned long int
div_rhs (long int rhs)
{
  if (rhs)
    return 1;
  return rhs;
}

uint32_t g_65;
int32_t g_122;
int32_t func_64 (uint32_t p_66, uint16_t p_67);
int32_t func_86 (uint16_t p_87);
int32_t func_88 (uint16_t p_89);
int32_t
func_2 (int8_t p_4)
{
  int32_t l_450;
  for (l_450 = 0; (l_450 < 8); ++l_450)
    func_43 (func_60 (func_64 (func_86 (1), 1), 1), 1, 1);
}

int32_t
func_64 (uint32_t p_66, uint16_t p_67)
{
  for (g_65 = 0; 0; ++g_65)
    {
    }
}
int32_t
func_86 (uint16_t p_87)
{
  func_88 (g_122);
}

int32_t
func_88 (uint16_t p_89)
{
  if (0 / div_rhs (func_91 (1, 1)))
    {
    }
  else if (p_89)
    for (g_65 = 1; 1; g_65 -= 1)
      return 1;
}
Comment 1 Andrew Pinski 2008-12-27 06:15:10 UTC
Can you reproduce this now?
Comment 2 John Regehr 2008-12-28 19:47:46 UTC
(In reply to comment #1)
> Can you reproduce this now?

Nope-- looks fixed in r142939.
Comment 3 Jakub Jelinek 2008-12-28 20:14:22 UTC
Confirmed.  The bug went away between r140768 and r142000.
Comment 4 Jakub Jelinek 2008-12-28 20:22:19 UTC
Guess PR37448 (plus PR37808 follow-up).