[LLVMbugs] [Bug 14304] -Winvalid-constexpr fails to warn on non-const array used in constexpr function

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Fri Nov 9 14:00:01 PST 2012


http://llvm.org/bugs/show_bug.cgi?id=14304

Richard Smith <richard-llvm at metafoo.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |richard-llvm at metafoo.co.uk
         Resolution|                            |WONTFIX

--- Comment #4 from Richard Smith <richard-llvm at metafoo.co.uk> 2012-11-09 16:00:01 CST ---
Note that this slightly different case can produce constant expressions:

constexpr int *foo(int i) {
    return &global_array[i];
}

Due to the non-local analysis required, it's not trivial to detect that your
original case can't ever produce a constant expression (the lvalue-to-rvalue
conversion could be quite far from the point where we perform the array
indexing).

This warning is only a best-effort check for a no-diagnostic-required rule. If
you want this fixed, patches would be welcome -- though a patch which makes the
constant expression evaluator more complex just to catch this would probably
not be accepted.

(In reply to comment #2)
> I assume the Committee was worried about the technicalities of undefined
> behavior; e.g. in your example f(0x7fffffff, 1) would technically not have a
> compile-time value, because it wouldn't have any value. But the cure they
> adopted — silently permitting constexpr functions to be evaluated at runtime —
> was worse than the disease.

I don't agree with this at all. There are many cases where you want a constexpr
function to only sometimes produce a constant expression. For instance,
std::array::at (which sometimes throws), or any function which asserts that
preconditions hold for its inputs, any function which conditionally logs or
allocates memory (for instance, std::string(const char*) could be constexpr and
handle just those cases where its small string optimization kicks in), etc.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.



More information about the llvm-bugs mailing list