https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78678
--- Comment #4 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 2 May 2017, marxin at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78678 > > Martin Liška <marxin at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|UNCONFIRMED |NEW > Last reconfirmed| |2017-05-02 > CC| |marxin at gcc dot gnu.org, > | |rguenth at gcc dot gnu.org > Ever confirmed|0 |1 > > --- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> --- > Confirmed, very nice example :) I'm attaching reduced test-case. > > Problem is that without -fsanitize=object-size, we fold lt_lcd_regs[20] in > einline here in fold_array_ctor_reference: > > > 6152 /* When memory is not explicitely mentioned in constructor, > 6153 it is 0 (or out of range). */ > 6154 return build_zero_cst (type); > > Using the sanitizer preserves following statement: > > UBSAN_OBJECT_SIZE (<_lcd_regs[20], _7, 36, 0); > > which is identified by VRP as the warning. The code that folds to zero was > written by Richi, I'm CCing for ideas. Maybe we can be more conservative is > some situations? Well, we could "improve" get_array_ctor_element_at_index to handle missing ctor elements (equal to zero). But as we can't rely on the array ctor having a proper TYPE_DOMAIN to specify the upper bound we cannot reliably detect out-of-bound accesses (which would be ok to not fold IMHO, at least if they are not trailing arrays).
