[Bug c++/51675] New: [C++11][New in 4.7] Cannot create constexpr unions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51675
Bug #: 51675
Summary: [C++11][New in 4.7] Cannot create constexpr unions
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: classixret...@gmail.com
union foo
{
int x = 0;
short y;
constexpr foo() = default;
};
This code compiles under GCC 4.6, however, not GCC 4.7. It works if I remove
the constexpr keyword.
Output of GCC:
test.cc:6:12: error: explicitly defaulted function ‘constexpr foo::foo()’
cannot be declared as constexpr because the implicit declaration is not
constexpr:
test.cc:4:8: note: defaulted default constructor does not initialize ‘short int
foo::y’
If I provide only one initialization, it tells me that the others are
initialized. If I initialize the others, it tells me that I can't initialize
more than one. It essentially prevents the creation of constexpr unions.
[Bug c++/51675] [C++11][New in 4.7] Cannot create constexpr unions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51675
--- Comment #1 from RétroX classixretrox at gmail dot com 2011-12-24 18:24:45
UTC ---
More information: initializing in the constructor doesn't work, either.
union foo
{
int x;
short y;
constexpr foo() : x(0) { }
};
Also does not compile.
[Bug c++/50839] New: Array parameters always take lower precedence than pointer parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50839 Bug #: 50839 Summary: Array parameters always take lower precedence than pointer parameters Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: classixret...@gmail.com Created attachment 25581 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25581 sample1 doesn't compile, whereas sample2 and sample3 do compile. The title says it all. sample1.cc does not compile, however, sample2.cc and sample3.cc do. Both were compiled with the -Wall and -std=gnu++0x flags. The expected output of sample2.cc should be: array[4] plus variadic pointer plus variadic variadic array[4] pointer generic However, ends up being: pointer plus variadic pointer plus variadic variadic pointer pointer generic Similarly, sample3.cc ends up being: variadic variadic generic generic Instead of: array[4] plus variadic variadic array[4] generic The GCC does not see any difference between void f(int[N]) and void f(int*). If you try to define two functions, it will say that void f(int*) is already defined, even if you are defining void f(int[N]) instead. You can get around this with some messy template work (as seem in the second sample), but it doesn't work as expected. Using templates, a specialization of int* will always take precedence over a specialization of int[N]. If I define a variadic function with an int[4] head and one without a head at all, it will assume the non-specialized version, which is incorrect (see sample3.cc). If you define a function with an int* head, it will work, but in that case, you cannot define the function as constexpr.
[Bug libstdc++/50441] [C++0x] type_traits is missing GNU extension types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50441 --- Comment #6 from RétroX classixretrox at gmail dot com 2011-09-17 16:32:18 UTC --- Yeah, I was talking about specifically -std=gnu++0x, because that implies that you're accepting the GNU extensions into the standard. I suppose that in this case, because the standard is so strict, having more than the standard types would probably be a bad idea. However, having numeric_limits for them doesn't seem to have any negative impacts; on systems that support the type, you should be able to get information on the type.
[Bug c++/50441] New: [C++0x] type_traits is missing GNU extension types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50441 Bug #: 50441 Summary: [C++0x] type_traits is missing GNU extension types Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: classixret...@gmail.com With -std=gnu++0x enabled, std::is_integral__uint128_t::value, std::is_integral__int128_t::value, and std::is_floating_point__float128::value should all be true. Unfortunately, they aren't. This is an extremely easy simple fix, I'd assume, but it's one that's needed, I think.
