This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Warning when compiling dwarf2out.c with -ftree-parallelize-loops=4
- From: Razya Ladelsky <RAZYA at il dot ibm dot com>
- To: gcc at gcc dot gnu dot org, rakdver at kam dot mff dot cuni dot cz
- Date: Tue, 25 Nov 2008 17:07:38 +0200
- Subject: Warning when compiling dwarf2out.c with -ftree-parallelize-loops=4
Hi,
When enabling -ftree-parallelize-loops=4 , bootstrap fails:
cc1: warnings being treated as errors
../../gcc/gcc/dwarf2out.c: In function âdwarf2out_frame_debugâ:
../../gcc/gcc/dwarf2out.c:2393: error: array subscript is above array
bounds
../../gcc/gcc/dwarf2out.c:2394: error: array subscript is above array
bounds
The array ref for which the subscript exceeded the boundary is
regs_saved_in_regs[i].
The array is defined:
static GTY(()) struct reg_saved_in_data regs_saved_in_regs[4];
therefore the upper bound of the array regs_saved_in_regs is 3
and the subscript is i.
However, when autopar pass is enabled,
the following condition is inserted :
if (num_iterations > 400-1)
{ /* parallel code. */
GOMP_parallel_start
loopfn ();
GOMP_parallel_end
last iteration of the loop; /* accessing the array:
regs_saved_in_regs[i] */
}
else
goto serial code
After VRP propagation, 400 is marked as the up_sub.
Since VRP can now determine that the array subscript is a constant, the
check of validity fails.
if (TREE_CODE (up_sub) == INTEGER_CST
&& tree_int_cst_lt (up_bound, up_sub)
&& !tree_int_cst_equal (up_bound, up_sub)
&& (!ignore_off_by_one
|| !tree_int_cst_equal (int_const_binop (PLUS_EXPR, up_bound,
integer_one_node, 0), up_sub)))
warning (OPT_Warray_bounds, "%Harray subscript is above array
bounds", location);
As far as I get it, there is no real failure here.
Parloop, unaware of the array's upper bound, inserts the 'enough
iterations' condition (i>400-1), and thereby
makes the last iteration range from 400 upwards.
VRP now has a constant it can compare to the array's upper bound.
Correct programs that do not exceed the array bound will now fail because
VRP is not aware of the
fact that the parallel code (and last iteration it is looking at) is
actually not executed in these cases.
I'm not sure how to proceed, in order to avoid this warning.
Any ideas?
Thanks,
Razya