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

Chris Lattner clattner at apple.com
Wed Jul 9 11:05:56 PDT 2008


Ok, I'm preparing to do battle with Expr::isIntegerConstantExpr and  
want to consult the guru's to see if this is a sane plan. :)

Problem statement:
   1) we want to support fully conformant C code with GNU extensions  
disabled.
   2) We want to support GNU extensions, but emit ext-warns when they  
are used.
   3) If a subexpr is a GNU ice, we don't want to emit warnings  
multiple times in the subexpr.  The canonical horrible example would  
be test/Sema/darwin-align-cast.c

This same problem occurs with both i-c-e's and c-e's, but I'm only  
going to poke at i-c-e's now.

My proposed fix is:

1. Introduce a new static function in Expr.cpp, something like this:

static unsigned isIntegerConstExprHelper(const Expr *E, llvm::APSInt  
&Result,
                                          ASTContext &Ctx,  
SourceLocation &Loc,
                                          bool isEvaluated, bool  
AllowGNU);

When AllowGNU is false, it evaluates the expr for i-c-e'ness strictly  
by the language standard indicated by ASTContext.  If the expr *is* an  
ICE, it returns zero and fills in
Result.  If it is not an ICE, it puts a caret position in "Loc" and  
returns a diag # to issue that explains why not.

When AllowGNU is true, it does the same, but 1) allows GNU craziness  
and 2) allows Expr to have pointer type (which is part of gnu  
craziness I suppose).



2. Change Expr::isIntegerConstantExpr to be something like this:

   // See if this expr is a real i-c-e.
   unsigned Diag = isIntegerConstExprHelper(this, ..., false)
   if (Diag == 0) return true;

   // See if it is a gnu one.
   if (!LangOptions.NoExtensions) {
     if (isIntegerConstExprHelper(this, ..., false) == 0) {
       Emit Warning about using GNU i-c-e.
       return true;
     }
   }
   return false;

3. Change Expr::isIntegerConstantExpr to return the diag reason up to  
its callers so they can emit more specific diags in some cases.

Does this seem like a reasonable approach?

-Chris



More information about the cfe-dev mailing list