public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/61556] New: [c++11][regression] ‘*(const ValueType*)this’ is not a constant expression with valid code
@ 2014-06-18 22:20 l.jirkovsky at gmail dot com
2014-06-20 18:32 ` [Bug c++/61556] [c++11][4.9/4.10 Regression] " jason at gcc dot gnu.org
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: l.jirkovsky at gmail dot com @ 2014-06-18 22:20 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61556
Bug ID: 61556
Summary: [c++11][regression] ‘*(const ValueType*)this’ is not a
constant expression with valid code
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: l.jirkovsky at gmail dot com
When used in a certain way, a template class cannot be instantiated in another
template class using a static constexpr. I tracked the regression down to the
following commit:
commit 18619da58c77461642c36cee9f0463c968877f75
Author: jason <jason@138bc75d-0d04-0410-961f-82ee72b054a4>
Date: Mon Apr 1 19:05:12 2013 +0000
* call.c (add_function_candidate): Take the address of 'this' here.
(build_over_call): And here.
(build_new_method_call_1, build_op_call_1): Not here.
(build_user_type_conversion_1): Or here.
(add_candidates): Adjust.
Reverting this commit fixes the problem on the current gcc.
The problematic code that should be compilable is attached after the "CODE"
section.
When compiled with gcc 4.9.0, the
ValueTypeInfo<ValueTypeEnum::doubleval> v; in the FillFunctor
constructor gives an error:
bug2.cpp: In constructor ‘FillFunctor<Format>::FillFunctor()’:
bug2.cpp:24:41: in constexpr expansion of ‘const
ValueType{1}->ValueType::operator int()’
bug2.cpp:24:41: error: ‘*(const ValueType*)this’ is not a constant
expression
ValueTypeInfo<ValueTypeEnum::doubleval> v;
^
bug2.cpp:24:41: note: in template argument for type ‘int’
bug2.cpp:24:44: error: invalid type in declaration before ‘;’ token
ValueTypeInfo<ValueTypeEnum::doubleval> v;
However, the same expression compiles just fine if its used in a
function, such as main(). Removing m_ID makes the code compile, too.
Also, the compilation works after replacing:
ValueTypeInfo<ValueTypeEnum::doubleval> v;
with a:
constexpr ValueType doubleval = ValueType(1);
ValueTypeInfo<doubleval> v;
CODE
#####
class ValueType {
public:
constexpr operator int() const {return m_ID;};
constexpr ValueType(const int v)
: m_ID(v) {}
private:
int m_ID;
};
class ValueTypeEnum {
public:
static constexpr ValueType doubleval = ValueType(1);
};
template <int format>
class ValueTypeInfo {
};
template <typename Format>
class FillFunctor {
public:
FillFunctor() {
ValueTypeInfo<ValueTypeEnum::doubleval> v;
}
};
int main() {
ValueTypeInfo<ValueTypeEnum::doubleval> v;
}
>From gcc-bugs-return-454524-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jun 19 00:45:18 2014
Return-Path: <gcc-bugs-return-454524-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 12505 invoked by alias); 19 Jun 2014 00:45:17 -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 12458 invoked by uid 48); 19 Jun 2014 00:45:11 -0000
From: "kumba at gentoo dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/61538] g++ compiled binary, linked to glibc libpthread, hangs on SGI MIPS R1x000 systems on Linux
Date: Thu, 19 Jun 2014 00:45:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: major
X-Bugzilla-Who: kumba at gentoo 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-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61538-4-2FxSxnVLMT@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61538-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61538-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-06/txt/msg01606.txt.bz2
Content-length: 2114
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538
--- Comment #4 from Joshua Kinard <kumba at gentoo dot org> ---
It looks like the bug might be somewhere in __cxa_guard_acquire() in
libstdc++-v3/lubsupc++/guard.cc, as that references glibc and futexes. strace
indicates that the same syscall was invoked twice in a row -- could this be a
double-locking bug?
This is what I traced out in gdb:
¦0x77ed91cc <__cxa_guard_acquire+336> sw zero,32(sp)
B+>¦0x77ed91d0 <__cxa_guard_acquire+340> b 0x77ed9144
<__cxa_guard_acquire+200>
|
|->¦0x77ed9144 <__cxa_guard_acquire+200> lw t9,-28620(gp)
¦0x77ed9148 <__cxa_guard_acquire+204> li a0,4238
¦0x77ed914c <__cxa_guard_acquire+208> move a1,s0
¦0x77ed9150 <__cxa_guard_acquire+212> move a2,zero
¦0x77ed9154 <__cxa_guard_acquire+216> lw a3,32(sp)
¦0x77ed9158 <__cxa_guard_acquire+220> jalr t9
|
|->¦0x77d50850 <syscall> lui gp,0x9
¦0x77d50854 <syscall+4> addiu gp,gp,-2624
¦0x77d50858 <syscall+8> addu gp,gp,t9
¦0x77d5085c <syscall+12> li v0,4000
¦0x77d50860 <syscall+16> syscall
<HANGS HERE>
¦0x77d50864 <syscall+20> bnez a3,0x77d50840
¦0x77d50868 <syscall+24> nop
¦0x77d5086c <syscall+28> jr ra
¦0x77d50870 <syscall+32> nop
¦0x77d50874 <syscall+36> nop
¦0x77d50878 nop
¦0x77d5087c nop
I can see the first futex syscall (li a0,4238), and I think it looks like
inside that syscall, it's doing some loads and adds, then makes a "generic"
syscall (#4000), probably passing the computed 0x108e value as the first
argument, which would translate into another futex syscall, which jives with
what strace says. Is taking a futex inside of a futex a good thing? It's
obvious that something with the R1x000 CPU is coming into play as well, but I
don't know what exactly.
>From gcc-bugs-return-454525-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jun 19 01:08:38 2014
Return-Path: <gcc-bugs-return-454525-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 7714 invoked by alias); 19 Jun 2014 01:08:38 -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 7667 invoked by uid 48); 19 Jun 2014 01:08:31 -0000
From: "pinskia at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/61538] g++ compiled binary, linked to glibc libpthread, hangs on SGI MIPS R1x000 systems on Linux
Date: Thu, 19 Jun 2014 01:08:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: major
X-Bugzilla-Who: pinskia at gcc dot gnu.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-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61538-4-X58FhhYT7u@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61538-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61538-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-06/txt/msg01607.txt.bz2
Content-length: 175
https://gcc.gnu.org/bugzilla/show_bug.cgi?ida538
--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?idR839#c12
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug c++/61556] [c++11][4.9/4.10 Regression] ‘*(const ValueType*)this’ is not a constant expression with valid code
2014-06-18 22:20 [Bug c++/61556] New: [c++11][regression] ‘*(const ValueType*)this’ is not a constant expression with valid code l.jirkovsky at gmail dot com
@ 2014-06-20 18:32 ` jason at gcc dot gnu.org
2014-06-20 18:35 ` jason at gcc dot gnu.org
2014-06-24 9:54 ` paolo.carlini at oracle dot com
2 siblings, 0 replies; 4+ messages in thread
From: jason at gcc dot gnu.org @ 2014-06-20 18:32 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61556
--- Comment #1 from Jason Merrill <jason at gcc dot gnu.org> ---
Author: jason
Date: Fri Jun 20 18:31:53 2014
New Revision: 211853
URL: https://gcc.gnu.org/viewcvs?rev=211853&root=gcc&view=rev
Log:
PR c++/61556
* call.c (build_over_call): Call build_this in template path.
Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-template7.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug c++/61556] [c++11][4.9/4.10 Regression] ‘*(const ValueType*)this’ is not a constant expression with valid code
2014-06-18 22:20 [Bug c++/61556] New: [c++11][regression] ‘*(const ValueType*)this’ is not a constant expression with valid code l.jirkovsky at gmail dot com
2014-06-20 18:32 ` [Bug c++/61556] [c++11][4.9/4.10 Regression] " jason at gcc dot gnu.org
@ 2014-06-20 18:35 ` jason at gcc dot gnu.org
2014-06-24 9:54 ` paolo.carlini at oracle dot com
2 siblings, 0 replies; 4+ messages in thread
From: jason at gcc dot gnu.org @ 2014-06-20 18:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61556
--- Comment #2 from Jason Merrill <jason at gcc dot gnu.org> ---
Author: jason
Date: Fri Jun 20 18:34:37 2014
New Revision: 211855
URL: https://gcc.gnu.org/viewcvs?rev=211855&root=gcc&view=rev
Log:
PR c++/61556
* call.c (build_over_call): Call build_this in template path.
Added:
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-template7.C
Modified:
branches/gcc-4_9-branch/gcc/cp/ChangeLog
branches/gcc-4_9-branch/gcc/cp/call.c
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug c++/61556] [c++11][4.9/4.10 Regression] ‘*(const ValueType*)this’ is not a constant expression with valid code
2014-06-18 22:20 [Bug c++/61556] New: [c++11][regression] ‘*(const ValueType*)this’ is not a constant expression with valid code l.jirkovsky at gmail dot com
2014-06-20 18:32 ` [Bug c++/61556] [c++11][4.9/4.10 Regression] " jason at gcc dot gnu.org
2014-06-20 18:35 ` jason at gcc dot gnu.org
@ 2014-06-24 9:54 ` paolo.carlini at oracle dot com
2 siblings, 0 replies; 4+ messages in thread
From: paolo.carlini at oracle dot com @ 2014-06-24 9:54 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61556
Paolo Carlini <paolo.carlini at oracle dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |FIXED
Target Milestone|--- |4.9.1
--- Comment #3 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Thus fixed.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-06-24 9:54 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-06-18 22:20 [Bug c++/61556] New: [c++11][regression] ‘*(const ValueType*)this’ is not a constant expression with valid code l.jirkovsky at gmail dot com
2014-06-20 18:32 ` [Bug c++/61556] [c++11][4.9/4.10 Regression] " jason at gcc dot gnu.org
2014-06-20 18:35 ` jason at gcc dot gnu.org
2014-06-24 9:54 ` paolo.carlini at oracle dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).