[Bug c/66286] New: Inconsistent handling of array sections

jakub at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Tue May 26 07:57:00 GMT 2015


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66286

            Bug ID: 66286
           Summary: Inconsistent handling of array sections
           Product: gcc
           Version: 5.1.1
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jakub at gcc dot gnu.org
                CC: ienkovich at gcc dot gnu.org, izamyatin at gmail dot com,
                    kyukhin at gcc dot gnu.org
  Target Milestone: ---

int
main ()
{
  int a[10], i;
  a[0:10] = 10; a[0:2] *= 2; a[5:2] *= 3;
  for (i = 0; i < 10; i++)
    if (a[i] != (i < 2 ? 20 : (i - 5U <= 1U ? 30 : 10)))
      __builtin_abort ();
  return 0;
}

passes in C++, but not in C, and passes with icc (both C and C++).
https://www.cilkplus.org/tutorial-array-notation says that omitted stride
defaults to 1 and that is what the C++ FE does:
  if (!stride)
    stride = build_one_cst (ptrdiff_type_node);
in build_array_notation_ref.  But the C FE does something different:
  if (!stride)
    {
      if (TREE_CONSTANT (start_index) && TREE_CONSTANT (length)
          && tree_int_cst_lt (length, start_index))
        stride = build_int_cst (TREE_TYPE (start_index), -1);
      else
        stride = build_int_cst (TREE_TYPE (start_index), 1);
    }
Not to mention that TREE_CONSTANT doesn't necessarily imply INTEGER_CST that
can be passed to tree_int_cst_lt...
IMHO we should just replace that hunk with
  if (!stride)
    stride = build_int_cst (TREE_TYPE (start_index), 1);
but I'd like to understand why this has been added there at all.
Seems the C++ FE had similar code too, but that got removed in r200554 without
mentioning it as a wrong-code bugfix.



More information about the Gcc-bugs mailing list