[Bug c/58346] ICE with SIGFPE at -O1 and above on x86_64-linux-gnu (affecting trunk, 4.8, 4.7, and 4.6)

["joseph at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org>]

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).