[LLVMbugs] [Bug 14706] New: Allow developers to separate the constexpr and runtime definitions of a function

[bugzilla-daemon at llvm.org]

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

             Bug #: 14706
           Summary: Allow developers to separate the constexpr and runtime
                    definitions of a function
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++11
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jyasskin at google.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


I'm looking at making char_traits::{length,find,compare} constexpr. The current
libc++ runtime definitions of, say find() are:

inline const char*
char_traits<char>::find(const char_type* __s, size_t __n, const char_type& __a)
        {return (const char_type*)memchr(__s, __a, __n);}

inline const wchar_t*
char_traits<wchar_t>::find(const char_type* __s, size_t __n, const char_type&
__a)
        {return (const char_type*)wmemchr(__s, __a, __n);}

inline const char16_t*
char_traits<char16_t>::find(const char_type* __s, size_t __n, const char_type&
__a)
{
    for (; __n; --__n)
    {
        if (eq(*__s, __a))
            return __s;
        ++__s;
    }
    return 0;
}


Of course, none of these definitions are constexpr. The char and wchar_t
definitions could potentially be made constexpr by changing them to use
__builtin_memchr and (a new) __builtin_wmemchr and making those builtins
sufficiently magic, but defining magic builtins doesn't scale. The char16_t
version could be made constexpr by defining it as:

constexpr const char16_t*
char_traits<char16_t>::find(const char16_t* __s, size_t __n, const char16_t&
__a)
{
  return __n == 0 ? 0 :
      *__s == __a ? __s :
      find(__s+1, __n-1, __a);
}

However, this can easily cause a stack overflow at -O0 where tailcall-opt isn't
run, so it's not viable for general use.

Richard Smith's
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3444.html doesn't
allow iteration or calls to arbitrary C library functions, so it doesn't help
with this case.

Therefore, clang should provide some way to provide different definitions of a
function for use in evaluating constant expressions vs runtime.

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