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

[Eli Friedman]

On Fri, Jul 11, 2008 at 10:12 AM, Chris Lattner <clattner at apple.com> wrote:
> 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.

We *really* want to avoid this if at all possible.  For issues
affecting system headers, this merely adds one more step to the steps
to reproduce: "add -pedantic to the clang commandline".  And it's
extremely unintuitive.

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

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15236?  Code depending on
that isn't even compatible with gcc without -pedantic, so I don't
think we need to worry about that.

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

The only code which can't be fixed using my approach is code which
depends on types being resolved in a non-compliant way.  The only such
code we've run into so far is glibc's tgmath.h.  However, since that's
a system header, it can't be fixed in any way that depends on the
compiler flags.  So your proposal doesn't actually solve any more
known broken cases than mine does.

If we really do end up having to do something like your proposal, it
at least shouldn't depend on the -pedantic flag.  This might be a case
where should distinguish between c99 and gnu99 modes.

-Eli