[Bug c++/56868] New: Constexpr example in 7.1.5/5 fails to compile correctly

[Bug c++/56868] New: Constexpr example in 7.1.5/5 fails to compile correctly

[g++bug at oxyware dot com]

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

             Bug #: 56868
           Summary: Constexpr example in 7.1.5/5 fails to compile
                    correctly
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: g++bug@oxyware.com


// The following example from 7.1.5/5 fails the static assert for g3(0)

constexpr int f(void *) { return 0; }
constexpr int f(...) { return 1; }
constexpr int g1() { return f(0); }
constexpr int g2(int n) { return f(n); }
constexpr int g3(int n) { return f(n*0); }

int main()
{
    static_assert(g1() == 0, "g1 failed");
    static_assert(g2(0) == 1, "g2 failed");
    static_assert(g3(0) == 1, "g3 failed");  // fails, g3(0) returns 0 not 1
}

[Bug c++/56868] Constexpr example in 7.1.5/5 fails to compile correctly

[g++bug at oxyware dot com]

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

--- Comment #1 from Hubert Matthews <g++bug at oxyware dot com> 2013-04-07 18:39:04 UTC ---
Compiled with g++-4.7.0 -Wall -Wextra -std=c++11 on Fedora 14, 64-bit.

[Bug c++/56868] Constexpr example in 7.1.5/5 fails to compile correctly

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-04-07
     Ever Confirmed|0                           |1
      Known to fail|                            |4.7.2, 4.8.0, 4.9.0

[Bug c++/56868] Constexpr example in 7.1.5/5 fails to compile correctly

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> 2013-04-07 18:51:00 UTC ---
Looks like 0*0 is being considered a null pointer constant.

[Bug c++/56868] Constexpr example in 7.1.5/5 fails to compile correctly

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini <paolo.carlini at oracle dot com> 2013-04-07 19:41:33 UTC ---
Whatever it is, doesn't have much to do with constexpr, consider:

#include <cassert>

int f(void *) { return 0; }
int f(...) { return 1; }

int g(int n) { return f(n*0); }

int main()
{
  assert (g(0) == 1);
}

[Bug c++/56868] Constexpr example in 7.1.5/5 fails to compile correctly

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> 2013-04-07 20:57:42 UTC ---
(In reply to comment #3)
> Whatever it is, doesn't have much to do with constexpr, consider:

That definitely makes it feel like 0*n being considered a null pointer constant
when it should not be.

[Bug c++/56868] Constexpr example in 7.1.5/5 fails to compile correctly

[paolo.carlini at oracle dot com]

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

--- Comment #5 from Paolo Carlini <paolo.carlini at oracle dot com> 2013-04-07 21:10:04 UTC ---
Don't we have an old issue with folding happening too early in some cases? I'm
wondering if this isn't just an example, but I can't quickly find that issue.

[Bug c++/56868] Constexpr example in 7.1.5/5 fails to compile correctly

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler <daniel.kruegler at googlemail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daniel.kruegler at
                   |                            |googlemail dot com

--- Comment #6 from Daniel Krügler <daniel.kruegler at googlemail dot com> 2013-04-07 21:32:46 UTC ---
IMO this behaviour should be considered in the light of

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#903

Assuming the P/R of this issue becomes accepted, both

static_assert(g2(0) == 1, "g2 failed");
static_assert(g3(0) == 1, "g3 failed");

should fail.
>From gcc-bugs-return-419438-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Apr 07 21:55:37 2013
Return-Path: <gcc-bugs-return-419438-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 20861 invoked by alias); 7 Apr 2013 21:55:37 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 20343 invoked by uid 48); 7 Apr 2013 21:55:30 -0000
From: "js-gcc at webkeks dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug objc/56870] New: @catch handler broken with SEH
Date: Sun, 07 Apr 2013 21:55:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: objc
X-Bugzilla-Keywords:
X-Bugzilla-Severity: blocker
X-Bugzilla-Who: js-gcc at webkeks dot org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields:
Message-ID: <bug-56870-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
X-SW-Source: 2013-04/txt/msg00583.txt.bz2
Content-length: 1568


http://gcc.gnu.org/bugzilla/show_bug.cgi?idV870

             Bug #: 56870
           Summary: @catch handler broken with SEH
    Classification: Unclassified
           Product: gcc
           Version: 4.8.1
            Status: UNCONFIRMED
          Severity: blocker
          Priority: P3
         Component: objc
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: js-gcc@webkeks.org


When trying to use ObjC exceptions with the new SEH support, the caught object
is not the ObjC object, but the _Unwind_Exception instead. Example:

@try {
    id e = [Object new];
    printf("@throw %p\n", e);
    @throw e;
} @catch (id e) {
    printf("@catch %p\n", e);
    @throw e;
}

Expected behaviour: Both are the same pointer.
Observed behaviour: They differ.

Looking further into it, the second pointer is the pointer to the
_Unwind_Exception (I added debug code in objc_exception_throw that outputs the
pointer after the malloc. It is always the same that's received in the catch).

So it seems the generated landing pad for ObjC code is wrong when using SEH. I
think it is correct that the landing pad receives the _Unwind_Exception and not
the ObjC object. But the landing pad needs to get the ObjC exception out of the
_Unwind_Exception and give that back to the user instead of the
_Unwind_Exception, which the user should never see.

This seems to happen not only with 4.8, but also with 4.9.

I marked this bug as blocker, as 4.8 made SEH the default, effectively breaking
ObjC execptions on Windows.

[Bug c++/56868] Constexpr example in 7.1.5/5 fails to compile correctly

[ktietz at gcc dot gnu.org]

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

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

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

--- Comment #7 from Kai Tietz <ktietz at gcc dot gnu.org> ---
This issue gets fixed with delayed-folding. Therefore assign it to me.