* [Bug c++/56868] Constexpr example in 7.1.5/5 fails to compile correctly
2013-04-07 18:36 [Bug c++/56868] New: Constexpr example in 7.1.5/5 fails to compile correctly g++bug at oxyware dot com
@ 2013-04-07 18:39 ` g++bug at oxyware dot com
2013-04-07 18:42 ` redi at gcc dot gnu.org
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: g++bug at oxyware dot com @ 2013-04-07 18:39 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c++/56868] Constexpr example in 7.1.5/5 fails to compile correctly
2013-04-07 18:36 [Bug c++/56868] New: Constexpr example in 7.1.5/5 fails to compile correctly g++bug at oxyware dot com
2013-04-07 18:39 ` [Bug c++/56868] " g++bug at oxyware dot com
@ 2013-04-07 18:42 ` redi at gcc dot gnu.org
2013-04-07 18:51 ` pinskia at gcc dot gnu.org
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: redi at gcc dot gnu.org @ 2013-04-07 18:42 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c++/56868] Constexpr example in 7.1.5/5 fails to compile correctly
2013-04-07 18:36 [Bug c++/56868] New: Constexpr example in 7.1.5/5 fails to compile correctly g++bug at oxyware dot com
2013-04-07 18:39 ` [Bug c++/56868] " g++bug at oxyware dot com
2013-04-07 18:42 ` redi at gcc dot gnu.org
@ 2013-04-07 18:51 ` pinskia at gcc dot gnu.org
2013-04-07 19:41 ` paolo.carlini at oracle dot com
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu.org @ 2013-04-07 18:51 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c++/56868] Constexpr example in 7.1.5/5 fails to compile correctly
2013-04-07 18:36 [Bug c++/56868] New: Constexpr example in 7.1.5/5 fails to compile correctly g++bug at oxyware dot com
` (2 preceding siblings ...)
2013-04-07 18:51 ` pinskia at gcc dot gnu.org
@ 2013-04-07 19:41 ` paolo.carlini at oracle dot com
2013-04-07 20:57 ` pinskia at gcc dot gnu.org
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: paolo.carlini at oracle dot com @ 2013-04-07 19:41 UTC (permalink / raw)
To: gcc-bugs
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);
}
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c++/56868] Constexpr example in 7.1.5/5 fails to compile correctly
2013-04-07 18:36 [Bug c++/56868] New: Constexpr example in 7.1.5/5 fails to compile correctly g++bug at oxyware dot com
` (3 preceding siblings ...)
2013-04-07 19:41 ` paolo.carlini at oracle dot com
@ 2013-04-07 20:57 ` pinskia at gcc dot gnu.org
2013-04-07 21:10 ` paolo.carlini at oracle dot com
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu.org @ 2013-04-07 20:57 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c++/56868] Constexpr example in 7.1.5/5 fails to compile correctly
2013-04-07 18:36 [Bug c++/56868] New: Constexpr example in 7.1.5/5 fails to compile correctly g++bug at oxyware dot com
` (4 preceding siblings ...)
2013-04-07 20:57 ` pinskia at gcc dot gnu.org
@ 2013-04-07 21:10 ` paolo.carlini at oracle dot com
2013-04-07 21:32 ` daniel.kruegler at googlemail dot com
2015-04-27 17:48 ` ktietz at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: paolo.carlini at oracle dot com @ 2013-04-07 21:10 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c++/56868] Constexpr example in 7.1.5/5 fails to compile correctly
2013-04-07 18:36 [Bug c++/56868] New: Constexpr example in 7.1.5/5 fails to compile correctly g++bug at oxyware dot com
` (5 preceding siblings ...)
2013-04-07 21:10 ` paolo.carlini at oracle dot com
@ 2013-04-07 21:32 ` daniel.kruegler at googlemail dot com
2015-04-27 17:48 ` ktietz at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: daniel.kruegler at googlemail dot com @ 2013-04-07 21:32 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c++/56868] Constexpr example in 7.1.5/5 fails to compile correctly
2013-04-07 18:36 [Bug c++/56868] New: Constexpr example in 7.1.5/5 fails to compile correctly g++bug at oxyware dot com
` (6 preceding siblings ...)
2013-04-07 21:32 ` daniel.kruegler at googlemail dot com
@ 2015-04-27 17:48 ` ktietz at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: ktietz at gcc dot gnu.org @ 2015-04-27 17:48 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread