[Bug c++/83993] [7/8 Regression] ICE: constant not recomputed when ADDR_EXPR changed

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P2
                 CC|                            |jason at gcc dot gnu.org
   Target Milestone|---                         |8.0
            Summary|[8 Regression] ICE:         |[7/8 Regression] ICE:
                   |constant not recomputed     |constant not recomputed
                   |when ADDR_EXPR changed      |when ADDR_EXPR changed

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Because the array has no TYPE_DOMAIN, in cxx_eval_array_reference
  if (TREE_CODE (TREE_TYPE (ary)) == ARRAY_TYPE)
    nelts = array_type_nelts_top (TREE_TYPE (ary));
sets nelts to error_mark_node + 1, and so the cxx_eval_constant_expression
calls sets *non_constant_p.  Then later on the caller of this,
cxx_eval_outermost_constant_expr, does:
4818      else if (non_constant_p && TREE_CONSTANT (r))
4819        {
4820          /* This isn't actually constant, so unset TREE_CONSTANT.  */
4821          if (EXPR_P (r))
4822            r = copy_node (r);
4823          else if (TREE_CODE (r) == CONSTRUCTOR)
4824            r = build1 (VIEW_CONVERT_EXPR, TREE_TYPE (r), r);
4825          else
4826            r = build_nop (TREE_TYPE (r), r);
4827          TREE_CONSTANT (r) = false;
4828        }
on the ADDR_EXPR surrounding the ARRAY_REF.

So, the questions are:
1) if we have such [] arrays, does any access to any element in the array imply
a non-constant expression, or should we ignore the in-bounds check?
E.g. on
extern const int a[];
const int b[5] = { 1, 2, 3, 4, 5 };
extern const int c[5];
constexpr const int *d = &a[0];
constexpr const int *e = &a[10];
constexpr const int *f = &b[0];
constexpr const int *g = &b[5];
constexpr const int *h = &b[6];
constexpr const int *i = &b[0];
constexpr const int *j = &b[5];
constexpr const int *k = &b[6];
g++ errors on h and k definitions, while clang++ errors on e, h, k, somehow it
considers &a[0] to be always ok no matter how large the array is (that is
actually a reasonable assumption for lval case, even if the array has zero
size, it is still valid to form a pointer past it), but considers &a[10]
invalid, even when the other TU could have const int a[100].

2) does cxx_eval_outermost_constant_expr really need to clear TREE_CONSTANT
even on ADDR_EXPRs, or could we special case those?  If we need to clear those,
supposedly during genericization we should try to recompute the ADDR_EXPR flags
and if that would change them, copy node and restore there what the middle-end
expects.

Jason, do you have answers to these questions, please?