[Bug c++/37719] New: incorrect type on warning of mismatched exception specification with templates
= test/test.cpp ==
template
class foo {
void bar() throw(int);
};
template <>
void foo::bar() throw(float) {}
= COMMAND ==
g++ -c -o test/test.o test/test.cpp -Wall
= OUTPUT ==
test/test.cpp:7: error: declaration of âvoid foo::bar() throw (int) [with
T = int]â throws different exceptions
test/test.cpp:3: error: from previous declaration âvoid foo::bar() throw
(int) [with T = int]â
test.ii =
# 1 "test/test.cpp"
# 1 ""
# 1 ""
# 1 "test/test.cpp"
template
class foo {
void bar() throw(int);
};
template <>
void foo::bar() throw(float) {}
===
first line should be throw (float)
The error comes from in "gcc/cp/decl.c" in function
check_redeclaration_exception_specification() on line 1097, but I don't know
how to debug it yet.
--
Summary: incorrect type on warning of mismatched exception
specification with templates
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yacwroy at gmail dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37719
[Bug c++/38069] New: function pointer exception specification not checked during assignment
According to the spec, you can't assign the value of a less-restrictive
function pointer to a more-restrictive function pointer.
Relevant C++ Spec section: 15.4 -3- (except.spec)
==
Code below taken directly from the C++ spec above.
==
class A { /* ... */ };
void (*pf1)(); // no exception specification
void (*pf2)() throw(A);
void f()
{
pf1 = pf2; // OK: pf1 is less restrictive
pf2 = pf1; // error: pf2 is more restrictive
}
==
this compiles OK - it shouldn't.
the line marked
// error:
does not produce an error.
==
I ran through g++ under kdbg on a 1-line file:
void (*fp)() throw(int);
I'm not sure if I read it right but it seems that gcc just ignores function
pointer exception specifications altogether.
in gcc/cp/decl.c, in the behemoth that is grokdeclarator() which builds the
declarator.
there's this "tree" called "raises" that gets passed the exception spec, but
it's only used to check for errors, it's not embedded into the newly built
declarator.
gcc/cp/decl.c :: grokdeclarator() ::
===
~8100: raises = declarator->u.function.exception_specification;
raises gets passed the spec.
~9172: decl = grokvardecl(.);
. (nothing important).
~9225: return decl;
grokvardecl builds the decl that's returned, but it's not passed "raises".
===
"tree"'s are still confusing me so I'm not sure if it's possible to embed this
into the decl without breaking anything, but that'd be where I'd start (after I
was sure it wasn't already in there).
when -fdumping-tree-original, there's no exception spec for the function ptr,
but I guess it could've been stripped.
(checked buglist for "function pointer exception specification", didn't see any
dupes)
--
Summary: function pointer exception specification not checked
during assignment
Product: gcc
Version: 4.2.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yacwroy at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38069
[Bug c++/12255] exception-specifications unchecked during assignment of pointer to function
--- Comment #5 from yacwroy at gmail dot com 2008-11-10 16:35 --- *** Bug 38069 has been marked as a duplicate of this bug. *** -- yacwroy at gmail dot com changed: What|Removed |Added CC||yacwroy at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12255
[Bug c++/38069] function pointer exception specification not checked during assignment
--- Comment #1 from yacwroy at gmail dot com 2008-11-10 16:35 --- *** This bug has been marked as a duplicate of 12255 *** -- yacwroy at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED GCC build triplet| x86_64-linux-gnu |x86_64-linux-gnu GCC host triplet| x86_64-linux-gnu |x86_64-linux-gnu GCC target triplet| x86_64-linux-gnu |x86_64-linux-gnu Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38069
[Bug c++/38071] New: function pointer exception specification not checked during assignment
According to the spec, you can't assign the value of a less-restrictive
function pointer to a more-restrictive function pointer.
Relevant C++ Spec section: 15.4 -3- (except.spec)
==
Code below taken directly from the C++ spec above.
==
class A { /* ... */ };
void (*pf1)(); // no exception specification
void (*pf2)() throw(A);
void f()
{
pf1 = pf2; // OK: pf1 is less restrictive
pf2 = pf1; // error: pf2 is more restrictive
}
==
this compiles OK - it shouldn't.
the line marked
// error:
does not produce an error.
==
I ran through g++ under kdbg on a 1-line file:
void (*fp)() throw(int);
I'm not sure if I read it right but it seems that gcc just ignores function
pointer exception specifications altogether.
in gcc/cp/decl.c, in the behemoth that is grokdeclarator() which builds the
declarator.
there's this "tree" called "raises" that gets passed the exception spec, but
it's only used to check for errors, it's not embedded into the newly built
declarator.
gcc/cp/decl.c :: grokdeclarator() ::
===
~8100: raises = declarator->u.function.exception_specification;
raises gets passed the spec.
~9172: decl = grokvardecl(.);
. (nothing important).
~9225: return decl;
grokvardecl builds the decl that's returned, but it's not passed "raises".
===
"tree"'s are still confusing me so I'm not sure if it's possible to embed this
into the decl without breaking anything, but that'd be where I'd start (after I
was sure it wasn't already in there).
when -fdumping-tree-original, there's no exception spec for the function ptr,
but I guess it could've been stripped.
(checked buglist for "function pointer exception specification", didn't see any
dupes)
--
Summary: function pointer exception specification not checked
during assignment
Product: gcc
Version: 4.2.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yacwroy at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38071
[Bug c++/47132] New: decltype can't deduce some operator return types when defining an auto function's return
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47132 Summary: decltype can't deduce some operator return types when defining an auto function's return Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: yacw...@gmail.com Build: 168358 (patched, see specs) Created attachment 22873 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22873 Erroneously fails to compile. An error is generated when: a) A template function whose return type is auto is being instantiated. b) The function's return type is deduced via decltype. c) The decltype expression is a compound operator (such as |=). The error is: "sorry, unimplemented: mangling modop_expr". (Are "sorry, unimplemented" errors already on todo lists?) The operator parameters don't seem to matter - they can be literals, globals, function parameters. Compilation fails even if the function takes no arguments and the template parameters are explicit. The decltype only fails if used to define a function return type. An identical decltype within the function body compiles OK and can be used to define variables. A non-template equivalent function compiles OK. Only fails to compile if the function is actually instantiated. As far as I can read there's no legitimate reason for this failure, although I could've missed something. And on the off chance that it should legitimately fail, the error message needs updating. Example code is attached. It is as trivial as I could get. Example Output: ../test/gcc-bug-mangling_modop-1.cpp: In instantiation of ‘decltype (x bit_ior_expr1) foo() [with tTYPE = int, decltype (x bit_ior_expr1) = int&]’: ../test/gcc-bug-mangling_modop-1.cpp:18:12: instantiated from here ../test/gcc-bug-mangling_modop-1.cpp:6:1: sorry, unimplemented: mangling modop_expr I searched the bug repository for "modop_expr" and got 0 hits. Specs: GCC: 4.6.0 20101230 (experimental) - D/L via SVN on 31st Dec 2010. - Build: 168358 (Trunk). - Patched with Pedro Lamarao's "Delegating constructors" patch (http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00620.html). - This shouldn't affect anything here. System: - Ubuntu 10.10 (x86-64). - Intel Core2 Duo. Hope this helps, Simon.
[Bug c++/47504] New: some constexpr calculations erroneously overflow when using negative numbers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47504
Summary: some constexpr calculations erroneously overflow when
using negative numbers
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: yacw...@gmail.com
Target: x86_64-unknown-linux-gnu
Created attachment 23148
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23148
overflow.cpp
Easiest to describe via code:
overflow.cpp
=
char constexpr sub(char arg)
{ return char(arg - char(1)); }
int main()
{ static char constexpr m = sub(-1); }
=
g++ overflow.cpp --std=c++0x
=
overflow.cpp: In function ‘int main()’:
overflow.cpp:5:36: error: overflow in constant expression [-fpermissive]
This is simply attempting to subtract 1 from -1, using "char"s.
I cannot see any reason why this should trigger an overflow error.
I have attempted to cast every intermediate state to char to avoid any
unintended casts.
The code is as simple as I could get it while still triggering the seemingly
erroneous overflow.
Compiles OK using int instead of char. (int can still erroneously overflow in
other circumstances, though. Would examples be useful?).
Compiles OK using 1 instead of -1.
Compiles OK using a literal -1 instead of a parameter.
Compiles OK if main()::m isn't constexpr.
Attached source code, but it's probably easier to just copy/paste the above.
SPECS:
gcc: version 4.6.0 2010-12-30 (experimental) (svn = 168358)
- manually patched by
(http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00620.html)
- patch shouldn't have any effect here.
ubuntu: 10.10 (64 bit)
intel: core2 duo
Are any other specs relevant here, such as GMP. (Note: my GMP is the standard
one).
I searched other constexpr bugs here - AFAIK none appear to be about overflow.
[Bug c++/47570] New: "one() >= 0" isn't constexpr for unsigned int, yet == and > is.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47570
Summary: "one() >= 0" isn't constexpr for unsigned int, yet ==
and > is.
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: yacw...@gmail.com
Target: x86_64-unknown-linux-gnu
Created attachment 23194
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23194
cxp_geq_uint.cpp
I reduced the code down as far as I could. It's fairly self-explanatory.
cxp_geq_uint.cpp
unsigned int constexpr one()
{ return 1; }
int constexpr one_B()
{ return 1; }
int main()
{
// FAIL TO COMPILE:
//static bool constexpr SC_huh = ((unsigned int)one()) >= ((unsigned
int)0);
//static bool constexpr SC_huh = one() >= ((unsigned int)0);
static bool constexpr SC_huh = one() >= 0;
// COMPILE OK:
//static bool constexpr SC_huh = ((one() == 0) || (one() > 0));
//static bool constexpr SC_huh = one() == 0;
//static bool constexpr SC_huh = one() > 0;
//static bool constexpr SC_huh = one_B() >= 0;
//static bool constexpr SC_huh = one() >= 1;
return SC_huh;
}
==
g++ cxp_geq_uint.cpp --std=c++0x
==
cxp_geq_uint.cpp: In function ‘int main()’:
cxp_geq_uint.cpp:12:43: error: ‘(1u, true)’ is not a constant expression
==
I can see no reason why >= shouldn't be constexpr in this case.
IIRC standard operators and literal casts always have defined behaviour for
standard unsigned integers.
As shown in the code, the problem goes away if:
- The value to the right of >= is greater than 0.
- The type is changed to (regular) int.
- The operation is changed to == or > (or combining these manually to form >=)
SPECS:
gcc: version 4.6.0 2010-12-30 (experimental) (svn = 168358)
- manually patched by
(http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00620.html)
- patch shouldn't have any effect here.
ubuntu: 10.10 (64 bit)
intel: core2 duo
I searched the buglist for constexpr & unsigned, didn't see any dupes myself.
I guess this one probably won't be too hard to debug.
I might even have a go if I get some spare time.
HTH.
Simon.
[Bug c++/53585] New: template value parameter of pointer-to-member type incorrectly rejects non-direct values
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53585
Bug #: 53585
Summary: template value parameter of pointer-to-member type
incorrectly rejects non-direct values
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: yacw...@gmail.com
Created attachment 27561
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27561
c++ testcase - should be legal
Problem:
Pointer-to-member value parameters appear to only accept direct values (of the
immediate form &X::Y) and reject passed constexpr variables.
llvm/clang++ accepts these.
I'm assuming this is legal but I haven't checked the standard.
specs: linux/x64
source (same as attached)
=
struct SFoo
{
int x;
};
constexpr int SFoo::* G_ptr_to_x = &SFoo::x;
// Dummy test struct.
template
struct SBar {};
SBar G_bar; // . (This should be legal, and is in clang).
// Additional testing:
SBar<&SFoo::x> G_bar2; // Shows the member-pointer works if immediate.
constexpr int SFoo::* another_ptr = G_ptr_to_x; // Shows "could not convert
..." error message is incorrect.
int main()
{}
=
Errors (build command = g++ mptr.cpp -std=c++11).
=
test/misc/mptr.cpp:12:16: error: ‘G_ptr_to_x’ is not a valid template argument
for type ‘int SFoo::*’
SBar G_bar; // . (This should be legal, and is in clang).
^
test/misc/mptr.cpp:12:16: error: it must be a pointer-to-member of the form
‘&X::Y’
test/misc/mptr.cpp:12:16: error: could not convert template argument
‘G_ptr_to_x’ to ‘int SFoo::*’
test/misc/mptr.cpp:12:23: error: invalid type in declaration before ‘;’ token
SBar G_bar; // . (This should be legal, and is in clang).
=
[Bug c++/53585] template value parameter of pointer-to-member type incorrectly rejects non-direct values
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53585 --- Comment #2 from Simon Hill 2012-06-06 16:43:41 UTC --- Thats... really odd but OK. I guess I read it as you do, the key words being "expressed as". I wonder whether that was the intent, and if so, what their rationale was. IMO it's very arbitrary and unintuitive, and for the life of me I can't think of a reason. Do you think it would be worth requesting a confirmation/clarification of this from the C++ standard working group or similar? (I have no idea what that would entail). Thanks for checking this out. For the moment I guess the workaround is to instead use a type-parameter and require the type to contain a constexpr pointer-to-member.
[Bug c++/45114] implement C++0x alias-declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45114 --- Comment #4 from Simon Hill 2011-04-06 16:17:35 UTC --- I was trying out this patch to see whether it might be usable to me, just as a preview. Firstly: Is this patch at a stage where it could be possible to complete a make/install, or am I jumping the gun? I don't want to update the patch (at least not without confirmation), but in case anyone else wants to try it as is, I believe that "parser.c" line 13496: if (at_class_scope () || template_parm_scope_p ()) should be changed to: if (at_class_scope_p () || template_parm_scope_p ()) (otherwise it doesn't compile). I got an ICE trying to make GCC on a SVN trunk checkout yesterday after (manually) patching with this (it only failed on building the libs). I can supply details if you want, but I guess this patch is outdated now?
[Bug c++/48537] New: C++0x: ICE using union with non-trivial member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48537
Summary: C++0x: ICE using union with non-trivial member
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: yacw...@gmail.com
Target: x86_64-unknown-linux-gnu
Created attachment 23936
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23936
Test source - ICEs.
If a union contains a member with a non-trivial default constructor, attempting
to explicitly call (or decltype) the default constructor results in an ICE.
(This relates to
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2544.pdf, implemented
in GCC 4.6)
Simplest example (attached).
== union-non-trivial-member-simple.cpp
struct SFoo
{
SFoo() =delete;
};
union UFoo
{
SFoo foo;
};
int main()
{
UFoo();
}
> g++ union-non-trivial-member-simple.cpp -std=c++0x
../union-non-trivial-member-simple.cpp: In function ‘int main()’:
../union-non-trivial-member-simple.cpp:13:8: internal compiler error: in
build_value_init_noctor, at cp/init.c:374
NOTE: Line may not be 374 for you.
I've indicated the line here:
=== cp/init.c ==
build_value_init_noctor (tree type, tsubst_flags_t complain)
{
if (CLASS_TYPE_P (type))
{
gcc_assert (!TYPE_NEEDS_CONSTRUCTING (type)); // (< THIS LINE!!
if (TREE_CODE (type) != UNION_TYPE)
{
- Works as expected (error but no ICE) with copy constructor, assignment or
destructor.
- Works as expected (error but no ICE) for implicit declaration (eg: "UFoo
foo;").
- Can reject valid code if using SFINAE.
USEFULNESS:
I am attempting to use SFINAE (using decltype) on a template union containing a
given type to determine the trivial-ness of the given type's special member
functions.
[C++ standard:9.5.2]
"...[Note: If any non-static data member of a union has a non-trivial default
constructor (12.1 [class.ctor]), copy constructor (12.8 [class.copy]), copy
assignment operator (12.8 [class.copy]), or destructor (12.4 [class.dtor]), the
corresponding member function of the union must be user-declared or it will be
implicitly deleted (8.4 [dcl.fct.def]) for the union. —end note]"
Which (I hope) should allow classifications like "trivial class" to be
calculated without relying on compiler-specific stuff.
SPECS:
gcc: version 4.7.0 2011-04-05 (experimental) (svn = 171986)
gcc: version 4.6.0 2011-02-13 (experimental) (svn = 170074)
- tested with both.
- both GCCs manually patched by
(http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00620.html)
- patch is unlikely to have any effect.
ubuntu: 10.10 (64 bit)
intel: core2 duo
HTH.
Simon.
[Bug c++/46600] New: Default move constructor copies array elements instead of moving them.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46600 Summary: Default move constructor copies array elements instead of moving them. Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: yacw...@gmail.com Created attachment 22482 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22482 Complete example code. Compile with 4.6 or higher using -std=c++0x. N3126: § 12.8.17 [move constructors]: --(3): "an array is initialized by moving each element in the manner appropriate to the element type" If you have a class with a member array and you call the default move constructor for said class, the move constructor COPIES said array elements. From what the standard says, it seems it should MOVE these elements. VERSION: 4.6.0 20100529 (experimental) (GCC) 4.5.1 is unable to explicitly default the move constructor. I don't have any other functional versions between these two. NOTE: I have added Pedro Lamarão's patch http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00620.html to my 4.6.0 but I can't see this affecting anything. TARGET: x86_64-unknown-linux-gnu SYSTEM: Core2Duo / Ubuntu(64) 10.4. ATTACHMENT: Compiles OK with -std=c++0x. OUTPUT: copy copy move PROBLEM: According to the C++ spec (ver N3126), I think the first 2 "copy"s should be "move"s.
[Bug c++/46600] Default move constructor copies array elements instead of moving them.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46600 --- Comment #2 from Simon Hill 2010-11-22 23:21:04 UTC --- Sorry about that. All that work and I didn't even notice my test GCC was the wrong one.
[Bug c++/46696] New: Implicit copy constructor can't construct array of subtype with user-defined copy constructor.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46696 Summary: Implicit copy constructor can't construct array of subtype with user-defined copy constructor. Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: yacw...@gmail.com Created attachment 22558 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22558 Test source - erroneously fails to compile. I think I may have hit a bug where an implicit copy constructor can't construct an array of a subtype with a user-defined copy constructor. I can't see any hits searching for "invalid array assignment" on the bug repository. §12.8.28 states: "A copy/move assignment operator that is defaulted and not defined as deleted is implicitly defined when [...] or when it is explicitly defaulted after its first declaration." §12.8.30 (implicitly-defined copy assignment) states: "The implicitly-defined copy assignment operator for a non-union class X performs memberwise copy assignment of its subobjects [...] Each subobject is assigned in the manner appropriate to its type: [...] -- if the subobject is an array, each element is assigned, in the manner appropriate to the element type;" I'm assuming that "the manner appropriate to the element type" means use copy-assignment. At least, that's what seems to happens if the main object's copy-assignment operator is implicitly defined. Yet the above doesn't seem able to compile if: - The main object contains an array of the subobject. - The main object's copy-assignment operator IS explicitly defaulted (§12.8.28). - The subobject's copy-assignment operator isn't implicitly or default defined. TEST SOURCE (Attached): 1) I created the most trivial type (named SFoo) that contains a non-default copy-assignment operator. 2) I created the most trivial type (named SBar) that contains: - an array of SFoo. - an explicitly defaulted copy-assignment operator. 3) I created a function that: - creates two copies of SBar. - assigns one copy to the other. TEST: I compiled using the -std=c++0x option. GCC refuses to compile (11:8: error: invalid array assignment). - If I remove the explicit defaulting of SBar's copy-assignment, it works. - If I default SFoo's copy-assignment, it works. SPECS: GCC: 4.6.0 20101106 (experimental) (GCC) - Using Pedro Lamarão's delegating constructors patch: - http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00620.html - (I can't see this having any effect here). TARGET: x86_64-unknown-linux-gnu SYSTEM: Ubuntu(64) 10.4. Core2Duo(64).
