Summary: | [4.8 Regression] ICE in remove_redundant_iv_tests, at tree-ssa-loop-ivcanon.c:559 | ||
---|---|---|---|
Product: | gcc | Reporter: | Richard Biener <rguenth> |
Component: | tree-optimization | Assignee: | Richard Biener <rguenth> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | dcb314, hubicka, jakub |
Priority: | P3 | Keywords: | ice-on-valid-code |
Version: | 4.8.0 | ||
Target Milestone: | 4.8.0 | ||
Host: | Target: | i?86-*-*, x86_64-*-* | |
Build: | Known to work: | ||
Known to fail: | Last reconfirmed: | 2012-12-14 00:00:00 | |
Attachments: | preprocessed source |
Description
Richard Biener
2012-12-14 09:01:17 UTC
Created attachment 28950 [details]
preprocessed source
Reduced testcase:
typedef struct _IO_FILE FILE;
unsigned long int strtoul(const char *, char **, int);
char *fgets(char *, int, FILE *);
struct ihexrec {
unsigned char reclen;
unsigned char data[256];
};
static void srec_readrec(struct ihexrec * srec, char * rec)
{
int i, j;
char buf[8];
int offset = 0, len;
char * e;
for (i=0; j<srec->reclen; j++)
{
if (offset+2 > len)
return;
for (i=0; i<2; i++)
buf[i] = rec[offset++];
srec->data[j] = strtoul(buf, &e, 16);
}
for (i=0; i<2; i++)
buf[i] = rec[offset++];
}
void srec2b(FILE *inf)
{
char buffer[256];
struct ihexrec srec;
while (fgets(buffer,256,inf)!=(void *)0)
srec_readrec(&srec, buffer);
}
> ./cc1 -quiet -O2 fileio.3.3.i
fileio.3.3.i: In function 'srec2b':
fileio.3.3.i:25:6: internal compiler error: in remove_redundant_iv_tests, at tree-ssa-loop-ivcanon.c:559
void srec2b(FILE *inf)
^
ICEing here is of course pointless. Looks like a debugging leftover to me. First when in estimate_numbers_of_iterations_loop, number_of_iterations_exit succeeds, then in find_loop_niter called from canonicalize_loop_induction_variables it fails, so does it when called from remove_redundant_iv_tests for that loop. So it's quite by design that this can happen. Testing the obvious patch. More reduced. struct s { int data[1]; }; static void bar (struct s *s, int *p) { int i, o; while (i++) { if (o > 0) return; for (i = 0; i < 1; i++) p[o++]; s->data[o] = baz (); } } void foo () { struct s s; bar (&s, 0); } Author: rguenth Date: Fri Dec 14 13:35:03 2012 New Revision: 194499 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194499 Log: 2012-12-14 Richard Biener <rguenther@suse.de> PR tree-optimization/55684 * tree-ssa-loop-ivcanon.c (remove_redundant_iv_tests): Handle gracefully the case where we cannot compute the number of iterations at an exit. * gcc.dg/torture/pr55684.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr55684.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-ivcanon.c Fixed. > First when in estimate_numbers_of_iterations_loop, number_of_iterations_exit
> succeeds, then in find_loop_niter called from
> canonicalize_loop_induction_variables it fails, so does it when called
> from remove_redundant_iv_tests for that loop.
It is a debugging lefover. At the time I wrote the code we was inserting the
exits into upper bound list only when precise number of iterations was
determined at given time. Sure we can also insert upper bounds there, but I
think we still don't. Why number_of_iterations_exit changed the mind?
Honza
*** Bug 55697 has been marked as a duplicate of this bug. *** *** Bug 55208 has been marked as a duplicate of this bug. *** |