[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