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

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

[mikpe at it dot uu.se]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58346

Mikael Pettersson <mikpe at it dot uu.se> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikpe at it dot uu.se

--- Comment #1 from Mikael Pettersson <mikpe at it dot uu.se> ---
Crashes with division-by-zero in the exact same spot as the PR58345 test case
does.  However this test case also crashes 4.7 and 4.6.

Program received signal SIGFPE, Arithmetic exception.
0x00000000005e2448 in fold_array_ctor_reference (ctor=0x7ffff7627ca8,
ctor=0x7ffff7627ca8, from_decl=0x7ffff7535be0, size=0, offset=0,
type=0x7ffff7645540)
    at /mnt/scratch/gcc-4.9-20130901/gcc/gimple-fold.c:2816
2816      inner_offset = offset % (elt_size.to_uhwi () * BITS_PER_UNIT);
(gdb) list
2811      if (index_type)
2812        access_index = access_index.ext (TYPE_PRECISION (index_type),
2813                                         TYPE_UNSIGNED (index_type));
2814
2815      /* And offset within the access.  */
2816      inner_offset = offset % (elt_size.to_uhwi () * BITS_PER_UNIT);
2817
2818      /* See if the array field is large enough to span whole access.  We
do not
2819         care to fold accesses spanning multiple array indexes.  */
2820      if (inner_offset + size > elt_size.to_uhwi () * BITS_PER_UNIT)
(gdb) print elt_size
$1 = {low = 0, high = 0}
(gdb) q

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

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58346

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |accepts-invalid,
                   |                            |ice-on-invalid-code
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-09-09
                 CC|                            |jsm28 at gcc dot gnu.org
          Component|ipa                         |c
     Ever confirmed|0                           |1

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
I believe the following should be invalid C

struct U {};
static struct U b[1] = { };

U is a zero-sized struct and b is an array built from it.  This array
cannot fulfil the basic array index operation requirements unless
the element size is bumped to one.

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

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58346

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
*** Bug 58345 has been marked as a duplicate of this bug. ***

[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]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58346

--- Comment #5 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
I think some of the uses of the zero-size-objects extension are ones for 
which making an array of such objects is reasonable, but it makes sense to 
give an error for trying to subtract pointers to such objects.

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

[rguenther at suse dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58346

--- Comment #6 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 9 Sep 2013, joseph at codesourcery dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58346
> 
> --- Comment #5 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
> I think some of the uses of the zero-size-objects extension are ones for 
> which making an array of such objects is reasonable, but it makes sense to 
> give an error for trying to subtract pointers to such objects.

A similar (runtime) error can be provoked by subtracting pointers
to array elements of variable size that happen to have zero size
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.

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

[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]

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

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

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58346

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |mpolacek at gcc dot gnu.org
           Assignee|unassigned at gcc dot gnu.org      |mpolacek at gcc dot gnu.org

--- Comment #8 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
I'll to try teach the C FE to give an error when subtracting two pointers to
empty aggregates.

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

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58346

--- Comment #9 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
And to actually fix this bug, the following should be enough...

--- a/gcc/gimple-fold.c
+++ b/gcc/gimple-fold.c
@@ -2940,7 +2940,8 @@ fold_array_ctor_reference (tree type, tree ctor,
      be larger than size of array element.  */
   if (!TYPE_SIZE_UNIT (type)
       || TREE_CODE (TYPE_SIZE_UNIT (type)) != INTEGER_CST
-      || elt_size.slt (tree_to_double_int (TYPE_SIZE_UNIT (type))))
+      || elt_size.slt (tree_to_double_int (TYPE_SIZE_UNIT (type)))
+      || elt_size.is_zero ())
     return NULL_TREE;

   /* Compute the array index we look for.  */

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

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58346

--- Comment #10 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Somewhat reduced:

struct U {};
static struct U b[1] = { };
extern void bar (struct U);

void
foo (void)
{
  bar (b[0]);
}

void
baz (void)
{
  foo ();
}

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

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58346

--- Comment #11 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Author: mpolacek
Date: Fri Jan 17 14:51:56 2014
New Revision: 206715

URL: http://gcc.gnu.org/viewcvs?rev=206715&root=gcc&view=rev
Log:
    PR c/58346
    * gimple-fold.c (fold_array_ctor_reference): Don't fold if element
    size is zero.
testsuite/
    * gcc.dg/pr58346.c: New test.

Added:
    trunk/gcc/testsuite/gcc.dg/pr58346.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/gimple-fold.c
    trunk/gcc/testsuite/ChangeLog

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

[law at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58346

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
                 CC|                            |law at redhat dot com
         Resolution|---                         |FIXED

--- Comment #12 from Jeffrey A. Law <law at redhat dot com> ---
Fixed by Marek's patch on the trunk.

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

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58346

--- Comment #13 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Author: mpolacek
Date: Thu Jan 23 19:18:49 2014
New Revision: 207004

URL: http://gcc.gnu.org/viewcvs?rev=207004&root=gcc&view=rev
Log:
    PR c/58346
c-family/
    * c-common.c (pointer_to_zero_sized_aggr_p): New function.
    * c-common.h: Declare it.
cp/
    * typeck.c (pointer_diff): Give an error on arithmetic on pointer to
    an empty aggregate.
c/
    * c-typeck.c (pointer_diff): Give an error on arithmetic on pointer to
    an empty aggregate.
testsuite/
    * c-c++-common/pr58346-1.c: New test.
    * c-c++-common/pr58346-2.c: New test.
    * c-c++-common/pr58346-3.c: New test.

Added:
    trunk/gcc/testsuite/c-c++-common/pr58346-1.c
    trunk/gcc/testsuite/c-c++-common/pr58346-2.c
    trunk/gcc/testsuite/c-c++-common/pr58346-3.c
Modified:
    trunk/gcc/c-family/ChangeLog
    trunk/gcc/c-family/c-common.c
    trunk/gcc/c-family/c-common.h
    trunk/gcc/c/ChangeLog
    trunk/gcc/c/c-typeck.c
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/typeck.c
    trunk/gcc/testsuite/ChangeLog