aaron.ballman added inline comments.
================
Comment at: clang/test/Sema/constant-builtins-ilogb.cpp:1
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+// expected-no-diagnostics
----------------
hubert.reinterpretcast wrote:
> 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).
>
> 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).
+1, especially because C2x has support for constexpr object definitions (which
we've not implemented in Clang yet).
> 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?
I think that model makes the most sense to me. If we can compute the correct
answer at compile time, it seems a bit silly to defer until runtime just
because the builtin looks like a function call expression.
> 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).
Yeah, I think it is a more general issue with builtins in C (and how we handle
constant expression evaluation in C). I don't think this patch will make the
problem significantly *worse*, so I think I'd be fine not addressing the
specific concern for this builtin in this patch. But it would probably make a
lot of sense for us to fix up the builtin situation before converting a ton of
math library functions to builtins since all of those are going to have the
same class of concern.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D136568/new/
https://reviews.llvm.org/D136568
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
