Bug 39275 - -funroll-loop fails
Summary: -funroll-loop fails
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 4.4.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2009-02-23 16:09 UTC by macius bat
Modified: 2016-05-16 13:05 UTC (History)
2 users (show)

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

source (145.34 KB, application/x-bzip2)
2009-02-23 16:15 UTC, macius bat

Note You need to log in before you can comment on or make changes to this bug.
Description macius bat 2009-02-23 16:09:49 UTC
{~/tmp}$gcc --version
gcc (GCC) 4.4.0 20090223 (experimental)
Copyright (C) 2009 Free Software Foundation, Inc.

{~/tmp}$g++  -O2  -funroll-loops  -c looppass.cpp
/mnt/svn/svn/llvm/lib/Analysis/LoopPass.cpp: In member function 'void llvm::LPPassManager::deleteLoopFromQueue(llvm::Loop*)':
/mnt/svn/svn/llvm/lib/Analysis/LoopPass.cpp:101: 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.
Comment 1 macius bat 2009-02-23 16:15:27 UTC
Created attachment 17348 [details]
Comment 2 macius bat 2009-04-19 17:30:27 UTC
can anybody comfirm?
Comment 3 Andrew Pinski 2012-01-19 06:22:27 UTC
ICEs for me with 4.4.5 but works on the trunk.
Comment 4 Andrew Pinski 2012-01-21 07:20:42 UTC
Here is a reduced testcase:
struct vector
  char *_M_start;
  char *_M_finish;
struct LoopBase
  static LoopBase *f();
  LoopBase *ParentLoop;
  vector SubLoops;
    for (int i = 0, e = SubLoops._M_finish - SubLoops._M_start; i != e; ++i)  
      delete f();
void deleteLoopFromQueue(LoopBase *L, int b)
  if (L->ParentLoop)
    while (L->SubLoops._M_start != L->SubLoops._M_finish)return;
   while (L->SubLoops._M_start != L->SubLoops._M_finish)return;
  delete L;

--- CUT ---
The delete loop is actually an empty loop but the tree level does not see that for some reason:
  # prephitmp.36_112 = PHI <prephitmp.36_6(4), prephitmp.36_3(3)>
  # prephitmp.36_21 = PHI <prephitmp.36_6(4), prephitmp.36_3(3)>
  D.2385_15 = (long int) prephitmp.36_21;
  D.2387_17 = (long int) prephitmp.36_112;

Those PHIs are the same.
Comment 5 Arseny Solokha 2016-05-16 13:05:01 UTC
I cannot reproduce it w/ any supported (as of today) version of gcc, as well as w/ trunk. Seems to be fixed long ago.