| Message ID | 20130408120847.GK24873@redhat.com |
|---|---|
| State | New |
| Headers | show |
> Alternatively, we can bump the minimum of that param, as usual ;)
Let's do that and bump it to 1, my understanding is that 0 and 1 are
equivalent for this param.
--- gcc/cse.c.mp 2013-04-08 13:19:15.082670099 +0200 +++ gcc/cse.c 2013-04-08 13:19:29.014713914 +0200 @@ -6166,7 +6166,7 @@ cse_find_path (basic_block first_bb, str } /* If the path was empty from the beginning, construct a new path. */ - if (path_size == 0) + if (path_size == 0 && PARAM_VALUE (PARAM_MAX_CSE_PATH_LENGTH) > 0) data->path[path_size++].bb = first_bb; else {
This patch prevents two Invalid read of size 8 and one Invalid write of size 8 warnings when cc1 is run under valgrind. What happens here is that we firstly allocate 0B ebb_data.path = XNEWVEC (struct branch_path, PARAM_VALUE (PARAM_MAX_CSE_PATH_LENGTH)); (in fact, XNEWVEC always allocates at least 1B--but still it's not enough), then in cse_find_path we have (path_size is 0) if (path_size == 0) data->path[path_size++].bb = first_bb; so we immediately have invalid write and moreover path_size increments, thus we call cse_find_path again, then we get the invalid reads. So fixed by guarding the write with PARAM_MAX_CSE_PATH_LENGTH > 0. Alternatively, we can bump the minimum of that param, as usual ;) Bootstrapped/regtested on x86_64-linux, ok for trunk/4.8? 2013-04-08 Marek Polacek <polacek@redhat.com> PR tree-optimization/48762 * cse.c (cse_find_path): Require PARAM_MAX_CSE_PATH_LENGTH be > 0. Marek