[Bug tree-optimization/53419] New: loop incorrectly optimized to endless loop at -O2 for table delimited by extern addresses (x86-32)

[Bug tree-optimization/53419] New: loop incorrectly optimized to endless loop at -O2 for table delimited by extern addresses (x86-32)

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53419

             Bug #: 53419
           Summary: loop incorrectly optimized to endless loop at -O2 for
                    table delimited by extern addresses (x86-32)
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: gary@intrepid.com
              Host: x86-32
            Target: x86-32


The attached test case, duplicated below yields an infinite loop when compiled
by GCC 4.8 trunk version 187666.  This appears to be a relatively recent
regression
(likely between 185454 and 186243).

typedef unsigned int size_t;

typedef void (*func_ptr_t) (void);
extern func_ptr_t init_array_begin[1];
extern func_ptr_t init_array_end[1];

void
per_thread_init (void)
{
  size_t n_init = (init_array_end - init_array_begin);
  int i;
  for (i = 0; i < n_init; ++i)
    {
      func_ptr_t init_func = init_array_begin[i];
      if (init_func)
        (*init_func) ();
    }
}

At -O1, the loop looks like this:

.L4:
        movl    init_array_begin(,%ebx,4), %eax
        testl   %eax, %eax
        je      .L3
        call    *%eax
.L3:
        addl    $1, %ebx
        cmpl    %esi, %ebx
        jne     .L4

At -O2 it looks like this.

.L5:
        movl    init_array_begin, %eax
        testl   %eax, %eax
        je      .L3
        call    *%eax
.L3:
        cmpl    $1, %ebx
        jne     .L5

The comparison "cmpl    $1, %ebx" is problematic, as well as the lack of
indexing the array.

[Bug tree-optimization/53419] loop incorrectly optimized to endless loop at -O2 for table delimited by extern addresses (x86-32)

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53419

--- Comment #1 from Gary Funck <gary at intrepid dot com> 2012-05-19 19:41:25 UTC ---
Created attachment 27442
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27442
test case demonstrating endless loop at -O2 on x86-32

[Bug tree-optimization/53419] loop incorrectly optimized to endless loop at -O2 for table delimited by extern addresses (x86-32)

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53419

--- Comment #2 from Gary Funck <gary at intrepid dot com> 2012-05-19 19:42:47 UTC ---
Created attachment 27443
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27443
correct code generated at -O1

[Bug tree-optimization/53419] loop incorrectly optimized to endless loop at -O2 for table delimited by extern addresses (x86-32)

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53419

--- Comment #3 from Gary Funck <gary at intrepid dot com> 2012-05-19 19:43:25 UTC ---
Created attachment 27444
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27444
endless loop generated at -O2

[Bug tree-optimization/53419] loop incorrectly optimized to endless loop at -O2 for table delimited by extern addresses (x86-32)

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53419

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2012-05-19
                 CC|                            |hjl.tools at gmail dot com
     Ever Confirmed|0                           |1

--- Comment #4 from H.J. Lu <hjl.tools at gmail dot com> 2012-05-19 20:34:32 UTC ---
Do you have a self-contained run-time testcase?

[Bug tree-optimization/53419] loop incorrectly optimized to endless loop at -O2 for table delimited by extern addresses (x86-32)

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53419

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |INVALID

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-05-19 21:54:03 UTC ---
> extern func_ptr_t init_array_begin[1];
> extern func_ptr_t init_array_end[1];

The array sizes say they are size of one.  If you want to be correct and not
allow GCC to optimize away the check because array overflow, use [] instead of
[1].

[Bug tree-optimization/53419] loop incorrectly optimized to endless loop at -O2 for table delimited by extern addresses (x86-32)

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53419

--- Comment #6 from Gary Funck <gary at intrepid dot com> 2012-05-19 22:08:26 UTC ---
(In reply to comment #5)
> > extern func_ptr_t init_array_begin[1];
> > extern func_ptr_t init_array_end[1];
> 
> The array sizes say they are size of one.  If you want to be correct and not
> allow GCC to optimize away the check because array overflow, use [] instead of
> [1].

Good point.  Do you happen to know if
  extern func_ptr_t init_array_begin[];
  extern func_ptr_t init_array_end[];
is say, C89 compatible?  I ask, because I thought I ran into problems with some
older compilers given the above syntax.

typedef unsigned int size_t;

typedef void (*func_ptr_t) (void);
extern func_ptr_t init_array_begin[1];
extern func_ptr_t init_array_end[1];

void
per_thread_init (void)
{
  size_t n_init = (init_array_end - init_array_begin);
  int i;
  for (i = 0; i < n_init; ++i)
    {
      func_ptr_t init_func = init_array_begin[i];
      if (init_func)
        (*init_func) ();
    }
}

Questions regarding the optimization of the above.

If the compiler concludes that n_init must be 1, then code that creates an
endless loop is not a valid optimization?

Simplifying so that the loop executes only once might be, but I'm still having
a little trouble adjusting to that idea.

Is there an -f option that disables this sort of optimization?



1

[Bug tree-optimization/53419] loop incorrectly optimized to endless loop at -O2 for table delimited by extern addresses (x86-32)

[gary at intrepid dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53419

--- Comment #7 from Gary Funck <gary at intrepid dot com> 2012-05-19 22:11:42 UTC ---
(In reply to comment #4)
> Do you have a self-contained run-time testcase?

I wasn't able to create a run-time tester easily, because the code above relies
upon external labels that are interposed at the beginning and end of a table,
via separate compilation and linking.  I can do that, but perhaps given
Andrew's reply, that may be unnecessary.

[Bug tree-optimization/53419] loop incorrectly optimized to endless loop at -O2 for table delimited by extern addresses (x86-32)

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53419

--- Comment #8 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-05-21 09:30:52 UTC ---
(In reply to comment #6)
> (In reply to comment #5)
> > > extern func_ptr_t init_array_begin[1];
> > > extern func_ptr_t init_array_end[1];
> > 
> > The array sizes say they are size of one.  If you want to be correct and not
> > allow GCC to optimize away the check because array overflow, use [] instead of
> > [1].
> 
> Good point.  Do you happen to know if
>   extern func_ptr_t init_array_begin[];
>   extern func_ptr_t init_array_end[];
> is say, C89 compatible?  I ask, because I thought I ran into problems with some
> older compilers given the above syntax.

Yes, it's C89 compatible.

> typedef unsigned int size_t;
> 
> typedef void (*func_ptr_t) (void);
> extern func_ptr_t init_array_begin[1];
> extern func_ptr_t init_array_end[1];
> 
> void
> per_thread_init (void)
> {
>   size_t n_init = (init_array_end - init_array_begin);
>   int i;
>   for (i = 0; i < n_init; ++i)
>     {
>       func_ptr_t init_func = init_array_begin[i];
>       if (init_func)
>         (*init_func) ();
>     }
> }
> 
> Questions regarding the optimization of the above.
> 
> If the compiler concludes that n_init must be 1, then code that creates an
> endless loop is not a valid optimization?
> 
> Simplifying so that the loop executes only once might be, but I'm still having
> a little trouble adjusting to that idea.

  size_t n_init = (init_array_end - init_array_begin);

is by itself also undefined - you are taking the difference between two
pointers to two distinct objects.  I suppose you should instead declare


extern func_ptr_t init_array_begin[];
extern func_ptr_t *init_array_end;

> Is there an -f option that disables this sort of optimization?

-fno-tree-vrp will, for your case.

> 
> 
> 1

[Bug tree-optimization/53419] loop incorrectly optimized to endless loop at -O2 for table delimited by extern addresses (x86-32)

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53419

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-05-21 10:33:57 UTC ---
extern func_ptr_t *init_array_end;
isn't an option, because then init_array_end is a pointer variable which needs
to be allocated somewhere and initialized somewhere, with [] it can be just a
linker defined symbol.  I guess you need an optimization barrier (compiler
specific).

[Bug tree-optimization/53419] loop incorrectly optimized to endless loop at -O2 for table delimited by extern addresses (x86-32)

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53419

--- Comment #10 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-05-21 11:29:13 UTC ---
Btw, it does not change it to an endless loop but the exit test to

 if (n_init > 1)

thus only an endless loop in case there is more than one element.