[Bug c++/49171] New: [C++0x][constexpr] Constant expressions support reinterpret_cast

[Bug c++/49171] New: [C++0x][constexpr] Constant expressions support reinterpret_cast

[daniel.kruegler at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171

           Summary: [C++0x][constexpr] Constant expressions support
                    reinterpret_cast
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: daniel.kruegler@googlemail.com
                CC: jason@redhat.com


gcc 4.7.0 20110521 (experimental) in C++0x mode accepts the following code:

//---
constexpr const char* c = reinterpret_cast<const char*>(0x123);
//---

As of FDIS 5.19 p2 b13 reinterpret_cast is no longer supported in constant
expressions, therefore the code should be rejected.

I'm emphasizing this because gcc should at least try to implement this to find
out, how much code will break because of this change.

[Bug c++/49171] [C++0x][constexpr] Constant expressions support reinterpret_cast

[daniel.kruegler at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171

--- Comment #1 from Daniel Krügler <daniel.kruegler at googlemail dot com> 2011-05-26 12:10:59 UTC ---
Additional remark: I'm speaking of potential code breakages that did rely on
non-portable behaviour, because there is no evidence for me that C++03 did
support this kind of reinterpret_cast usage.

[Bug c++/49171] [C++0x][constexpr] Constant expressions support reinterpret_cast

[daniel.kruegler at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171

--- Comment #2 from Daniel Krügler <daniel.kruegler at googlemail dot com> 2011-08-30 09:39:43 UTC ---
I believe I found a conforming usage of reinterpret_cast in constant
expressions useable in C++03:

//----------------
struct X {
 X* operator&();
};

X x[2];

const bool p = (reinterpret_cast<X*>(&reinterpret_cast<char&>(x[1]))
- reinterpret_cast<X*>(&reinterpret_cast<char&>(x[0]))) == sizeof(X);

enum E { e = p }; // e should have a value equal to 1
//----------------

Basically this program demonstrates the technique, the C++11 library function
addressof is based on and thus excluding reinterpret_cast *unconditionally*
from constant expressions in the core language would render this useful program
invalid and would make it impossible to declare addressof as a constexpr
function.

[Bug c++/49171] [C++0x][constexpr] Constant expressions support reinterpret_cast

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |paolo.carlini at oracle dot
                   |                            |com

--- Comment #3 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-10-03 14:27:50 UTC ---
Daniel, what's the status of this issue? Is there some consensus that GCC is
actually Ok, we don't really want to reject reinterpret_casts?

Because I would find very useful a constexpr std::addressof. For the time being
we could certainly have it constexpr anyway and change the implementation
details when/if the C++ front-end starts rejecting reintepret_casts, but I
would rather not.

[Bug c++/49171] [C++0x][constexpr] Constant expressions support reinterpret_cast

[daniel.kruegler at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171

--- Comment #4 from Daniel Krügler <daniel.kruegler at googlemail dot com> 2012-10-03 16:22:24 UTC ---
(In reply to comment #3)
> Daniel, what's the status of this issue? Is there some consensus that GCC is
> actually Ok, we don't really want to reject reinterpret_casts?

My opinion is that gcc should start to implement the new core rules in regard
to reinterpret_cast *except* for cases that are well-defined.

> Because I would find very useful a constexpr std::addressof. For the time being
> we could certainly have it constexpr anyway and change the implementation
> details when/if the C++ front-end starts rejecting reintepret_casts, but I
> would rather not.

Exactly this usage of reinterpret_cast seems IMO to be well granted by the
standard - at least by the way I read it.

[Bug c++/49171] [C++0x][constexpr] Constant expressions support reinterpret_cast

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171

--- Comment #5 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-10-03 16:46:30 UTC ---
Ok, thanks. Sorry about the naive question: is it already clear what it means
for reinterpret_cast uses to be "well-defined" in this sense?

[Bug c++/49171] [C++0x][constexpr] Constant expressions support reinterpret_cast

[daniel.kruegler at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171

--- Comment #6 from Daniel Krügler <daniel.kruegler at googlemail dot com> 2012-10-03 18:46:09 UTC ---
(In reply to comment #5)
> Ok, thanks. Sorry about the naive question: is it already clear what it means
> for reinterpret_cast uses to be "well-defined" in this sense?

This is surely no naive question. I should have been more specific: I think
only those reinterpret_cast operations that have a *specified* result, should
be allowed (similar to relational or equality operations). For example "An
expression of integral, enumeration, pointer, or pointer-to-member type can be
explicitly converted to its own type; such a cast yields the value of its
operand." seems well specified and uncontroversial to me. Another example (and
this is relevant for std::addressof) is the combination of p7

"An object pointer can be explicitly converted to an object pointer of a
different type. [..] Converting a prvalue of type “pointer to T1” to the type
“pointer to T2” (where T1 and T2 are object types and where the alignment
requirements of T2 are no stricter than those of T1) and back to its original
type yields the original pointer value."

and p11

"An lvalue expression of type T1 can be cast to the type “reference to T2” if
an expression of type “pointer to T1” can be explicitly converted to the type
“pointer to T2” using a reinterpret_cast. That is, a reference cast
reinterpret_cast<T&>(x) has the same effect as the conversion
*reinterpret_cast<T*>(&x) with the built-in & and * operators (and similarly
for reinterpret_cast<T&&>(x))."

In other words, the whole expression

reinterpret_cast<T*>(&const_cast<char&>(
  reinterpret_cast<const volatile char&>(t)))

that is typically used for the real address deduction seems to have
well-specified behaviour and should thus be "constexpr-friendly".

[Bug c++/49171] [C++0x][constexpr] Constant expressions support reinterpret_cast

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171

--- Comment #7 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-10-05 14:10:11 UTC ---
Thanks a lot Daniel for the clarification. Thus I understand that currently GCC
is accepting *all sorts* of reinterpret_cast uses in constexpr functions,
right? That is, also those with unspecified result?

[Bug c++/49171] [C++0x][constexpr] Constant expressions support reinterpret_cast

[daniel.kruegler at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171

--- Comment #8 from Daniel Krügler <daniel.kruegler at googlemail dot com> 2012-10-05 14:17:18 UTC ---
(In reply to comment #7)
> Thus I understand that currently GCC is accepting *all sorts* of 
> reinterpret_cast uses in constexpr functions, right? That is, also those with
> unspecified result?

Correct. The introductory example belongs to this family, for example.

[Bug c++/49171] [C++0x][constexpr] Constant expressions support reinterpret_cast

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-10-23
                 CC|paolo.carlini at oracle dot |
                   |com                         |
             Blocks|                            |55004
     Ever Confirmed|0                           |1

[Bug c++/49171] [C++0x][constexpr] Constant expressions support reinterpret_cast

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171

--- Comment #9 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-10-23 23:02:31 UTC ---
Per Comment #3 in PR55039, I think we have simply to reject reinterpret_casts.

[Bug c++/49171] [C++0x][constexpr] Constant expressions support reinterpret_cast

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu.org,
                   |                            |ktietz at gcc dot gnu.org

--- Comment #10 from Jason Merrill <jason at gcc dot gnu.org> ---
This is another one to fix with Kai's delayed folding work.

[Bug c++/49171] [C++0x][constexpr] Constant expressions support reinterpret_cast

[ktietz at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171

Kai Tietz <ktietz at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |ktietz at gcc dot gnu.org

--- Comment #11 from Kai Tietz <ktietz at gcc dot gnu.org> ---
Fixed with delayed-folding for C++.  Therefore mine.

[Bug c++/49171] [C++0x][constexpr] Constant expressions support reinterpret_cast

[myriachan at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171

Melissa <myriachan at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |myriachan at gmail dot com

--- Comment #12 from Melissa <myriachan at gmail dot com> ---
(In reply to Kai Tietz from comment #11)
> Fixed with delayed-folding for C++.  Therefore mine.

Why fix it?  The Standard doesn't allow it, but it's still useful.  For
example, std::numeric_limits<float>::infinity() cannot be implemented without
it or compiler magic (e.g. __builtin_huge_valf in the current libstdc++).

Melissa