[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 gcc-bugzilla@gcc.gnu.org
Sat May 19 22:12:00 GMT 2012


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



More information about the Gcc-bugs mailing list