http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58346
--- Comment #7 from joseph at codesourcery dot com <joseph at codesourcery dot com> --- On Tue, 10 Sep 2013, rguenther at suse dot de wrote: > A similar (runtime) error can be provoked by subtracting pointers > to array elements of variable size that happen to have zero size > at runtime. Yes, that needs to be undefined at runtime. > This all seems to be a can of worms which I'd rather shield the > middle-end from. For example we assume that a[0] and a[1] never > alias. As I noted in bug 57725, code using zero-size objects should not care about whether their addresses compare equal - and any other consequence of a non-aliasing deduction shouldn't matter (given that stores to such objects will store zero bytes and reads from them will read zero bytes). > Can we at least make arrays of zero-sized elements trigger undefined > behavior in our extension documentation? We probably can paper > over the ICEs as they occur (testing coverage is very weak of course). It's specifically the subtraction of pointers that needs to be undefined. I'm doubtful about making such arrays undefined in the absence of such subtraction. Uses of zero-size objects are e.g. for when an object may be empty for some configurations of a program but not others (depending on whether a lock object is needed in that configuration, say), and it seems plausible someone might have an array of such conditionally zero-size objects, each corresponding to an element of another array (if there's a reason why using a single array of structs isn't appropriate).
