[PATCH] D136568: [Clang] Support constexpr builtin ilogb

[Hubert Tong via Phabricator via cfe-commits]

hubert.reinterpretcast added inline comments.


================
Comment at: clang/test/Sema/constant-builtins-ilogb.cpp:1
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+// expected-no-diagnostics
----------------
aaron.ballman wrote:
> hubert.reinterpretcast wrote:
> > There seems to be no C language test in the patch (although the builtin presumably is okay at least as part of arithmetic constant expressions).
> > 
> > @aaron.ballman, what are your thoughts re: integer constant expression contexts? For example:
> > ```
> > struct C { int x : __builtin_ilogb(1. + 1.); };
> > ```
> WG14 adopted https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2713.htm for C2x to clarify that implementations are not allowed to extend what they consider to be an integer constant expression. The operand in this case is a function call expression, which is not one of the permissible things in an ICE, so the standard doesn't want us to make it one.
> 
> I believe that Clang's response to that paper is to implement it to the letter rather than to the intent. e.g., issue a warning that a constant expression is being folded into an ICE but otherwise accept the code. We have too many situations already in which we fold a constant expression to an ICE and changing that behavior would be observable (and a performance regression). So I think it's fine for us to treat the builtin call as an ICE so long as we issue a (pedantic) warning about folding it.
> 
> (FWIW, I don't think it qualifies as an arithmetic constant expression because that also doesn't allow function call expressions. But we can extend the definition of an arithmetic constant expression.)
Thanks Aaron. I think a C language test for this patch may be a good way to explore the extension space (and any pedantic conformance diagnostics).

Particular to the example above and ICEs is that the argument involves floating-point operations. Would the desired model be that the call is considered a literal for the purposes of the language requirements?

It seems that built-ins that are accepted in constant expressions in C are a more general issue though (and I am not sure if, for this patch, we defer the issue for some general approach that would take care of the class of problems as a whole).



Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D136568/new/

https://reviews.llvm.org/D136568