[cfe-dev] Unravelling i-c-e + the gnu mess

[Chris Lattner]

On Jul 9, 2008, at 4:03 PM, Eli Friedman wrote:
> This is where it get really messy... the issue is that saying that
> something is an integer constant expression has indirect effects in
> some cases.

Yeah, I know :(.  Enabling extensions will change how code is sema'd.   
Unfortunately, I don't think this is avoidable.

>  Non-ICE array bounds indicate a VLA, and the
> compatibility rules for those are different from those for constant
> arrays.  A conditional expression with a null pointer constant can
> silently end up with a different type from an conditional with a
> pointer that happens to evaluate to zero.  These are edge cases, but
> -pedantic shouldn't affect semantics.

I agree... unfortunately, it does with GCC.  GCC also handles enums  
differently in some cases when -pedantic is enabled.

> I think the right approach is what we're doing in
> Sema::TryFixInvalidVariablyModifiedType: if we run into a situation
> where we print a warning/error, but gcc accepts the code, try to
> recover at the point where we would print the diagnostic.
>
> If it's convenient, we could add a "RequireIntegerConstantExpr" method
> which does roughly "if (Expr->ICE()) return val; if
> (Expr->TryEvaluate()) {pedwarn(); return val;} error(); return
> failure;".
>
> Downsides to this approach: it's possible it will let stuff slip by
> without a warning in non-pedantic mode that gcc wouldn't accept, and
> this will leave constructs like the glibc tgmath.h broken.

Yeah, another way to say this is that some real code *depends* on  
GCC's mis-parsing code.  For example, the "generous" null-pointer- 
constant case is needed in some situations.

> On a related note, I'm considering rewriting
> Expr::isIntegerConstantExpression() to delegate actual calculation to
> Expr::TryEvaluate() at some point, to reduce code duplication.

Ok!

-Chris