[Bug c++/69905] New: Digit separators break literal operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69905 Bug ID: 69905 Summary: Digit separators break literal operators Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: public at alisdairm dot net Target Milestone: --- The following code fails to compile when the macro is defined: #include using namespace std::literals; #if defined SHOW_BUG auto x = 1'23s #else auto x = 123s; #endif I /think/ this is a problem in the front-end, rather than the library, as the digit separator should not be visible to the library call.
[Bug c++/68858] New: Cannot use fold expression in requirements with two parameters packs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68858
Bug ID: 68858
Summary: Cannot use fold expression in requirements with two
parameters packs
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: public at alisdairm dot net
Target Milestone: ---
Created attachment 36999
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36999=edit
demonstrates requires clause does not recognize parameter packs are constrained
to same length
I am trying to re-implement pair using variadic templates, constrained to a
pack size of exactly two, in order to use fold expressions to simplify
exception specifications and other constraints. However, I get a hard
(non-SFINAEable) error every time I instantiate my class template, complaining
that parameter packs are not the same length. Source attached, but in brief,
this is my attempt to contain the packs:
template
requires(2 == sizeof...(TYPES))
struct MyPair {
template
requires sizeof...(TYPES) == sizeof...(OTHER_TYPES)
and (true and ... and is_constructible<TYPES, OTHER_TYPES>())
constexpr
MyPair(OTHER_TYPES&&... args)
noexcept((true and ... and is_nothrow_constructible<TYPES, OTHER_TYPES
&&>()));
};
Error message:
error: mismatched argument pack lengths while expanding
'std::is_constructible<TYPES, OTHER_TYPES>()'
requires sizeof...(TYPES) == sizeof...(OTHER_TYPES) and (true and ...
and std::is_constructible<TYPES, OTHER_TYPES>())
(note that the example triggering this error does not try to invoke that
constructor, and it parses fine until the implicitly instantiated class
template performs name-lookup for a constructor).
Testing against latest gcc 6 available from MacPorts: g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin15/6.0.0/lto-wrapper
Target: x86_64-apple-darwin15
Configured with:
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc6/gcc6/work/gcc-6-20151129/configure
--prefix=/opt/local --build=x86_64-apple-darwin15
--enable-languages=c,c++,objc,obj-c++,lto,fortran,java
--libdir=/opt/local/lib/gcc6 --includedir=/opt/local/include/gcc6
--infodir=/opt/local/share/info --mandir=/opt/local/share/man
--datarootdir=/opt/local/share/gcc-6 --with-local-prefix=/opt/local
--with-system-zlib --disable-nls --program-suffix=-mp-6
--with-gxx-include-dir=/opt/local/include/gcc6/c++/ --with-gmp=/opt/local
--with-mpfr=/opt/local --with-mpc=/opt/local --with-isl=/opt/local
--enable-stage1-checking --disable-multilib --enable-lto
--enable-libstdcxx-time --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld
--with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket
--with-pkgversion='MacPorts gcc6 6-20151129_0'
Thread model: posix
gcc version 6.0.0 20151129 (experimental) (MacPorts gcc6 6-20151129_0)
[Bug c++/66649] New: variable template specializations not being found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66649
Bug ID: 66649
Summary: variable template specializations not being found
Product: gcc
Version: 5.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: public at alisdairm dot net
Target Milestone: ---
Created attachment 35841
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35841action=edit
C++ code that should compile in C++14 mode, but fails
The attached file shows a simple test case for variable templates that I
believe is correct, and passes with Clang:
template typename T, typename U
constexpr bool is_same_v = false;
template typename T
constexpr bool is_same_vT, T = true;
template typename T
auto make() - T;
template typename T
void AssertMakeSame() {
static_assert( is_same_vT, T, Type should be the same as itself);
static_assert( is_same_vdecltype(makeT()), T, make should produce the
same type);
};
int main() {
AssertMakeSameint();
// AssertMakeSameint const(); // Should be an error
AssertMakeSameint *();
}
In gcc 5, I get an error that the partial specialization must be at namespace
scope, but this appears to be fixed in trunk. However, all 4 static asserts
fire in both trunk and 5.
Tested with:
g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin14/6.0.0/lto-wrapper
Target: x86_64-apple-darwin14
Configured with:
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc6/gcc6/work/gcc-6-20150614/configure
--prefix=/opt/local --build=x86_64-apple-darwin14
--enable-languages=c,c++,objc,obj-c++,lto,fortran,java
--libdir=/opt/local/lib/gcc6 --includedir=/opt/local/include/gcc6
--infodir=/opt/local/share/info --mandir=/opt/local/share/man
--datarootdir=/opt/local/share/gcc-6 --with-local-prefix=/opt/local
--with-system-zlib --disable-nls --program-suffix=-mp-6
--with-gxx-include-dir=/opt/local/include/gcc6/c++/ --with-gmp=/opt/local
--with-mpfr=/opt/local --with-mpc=/opt/local --with-isl=/opt/local
--enable-stage1-checking --disable-multilib --enable-lto
--enable-libstdcxx-time --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld
--with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket
--with-pkgversion='MacPorts gcc6 6-20150614_0'
Thread model: posix
gcc version 6.0.0 20150614 (experimental) (MacPorts gcc6 6-20150614_0)
and with:
g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin14/5.1.0/lto-wrapper
Target: x86_64-apple-darwin14
Configured with:
/opt/local/var/macports/build/_opt_mports_dports_lang_gcc5/gcc5/work/gcc-5.1.0/configure
--prefix=/opt/local --build=x86_64-apple-darwin14
--enable-languages=c,c++,objc,obj-c++,lto,fortran,java
--libdir=/opt/local/lib/gcc5 --includedir=/opt/local/include/gcc5
--infodir=/opt/local/share/info --mandir=/opt/local/share/man
--datarootdir=/opt/local/share/gcc-5 --with-local-prefix=/opt/local
--with-system-zlib --disable-nls --program-suffix=-mp-5
--with-gxx-include-dir=/opt/local/include/gcc5/c++/ --with-gmp=/opt/local
--with-mpfr=/opt/local --with-mpc=/opt/local --with-isl=/opt/local
--enable-stage1-checking --disable-multilib --enable-lto
--enable-libstdcxx-time --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld
--with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket
--with-pkgversion='MacPorts gcc5 5.1.0_1'
Thread model: posix
gcc version 5.1.0 (MacPorts gcc5 5.1.0_1)
[Bug c++/65739] New: ICE (gimple_failed) initializing a vector of function pointers at -O1 or higher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65739
Bug ID: 65739
Summary: ICE (gimple_failed) initializing a vector of function
pointers at -O1 or higher
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: public at alisdairm dot net
Created attachment 35293
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35293action=edit
source for easy testing
The following simple code gives me an internal compiler error with a recent gcc
5 build (via macports):
#include vector
using func = void(*)();
void test() {}
int main() {
std::vectorfunc v = {test};
return 0;
}
Error messages:
g++-mp-5 -std=c++11 -freport-bug -O1 main.cpp
main.cpp: In function 'int main()':
main.cpp:7:5: error: non-trivial conversion at assignment
int main() {
^
long unsigned int
void (*T16cd) (void)
# .MEM_52 = VDEF .MEM_42
MEM[(char * {ref-all})_31] = _35;
main.cpp:7:5: internal compiler error: verify_gimple failed
main.cpp:7:5: internal compiler error: Abort trap: 6
g++-mp-5: internal compiler error: Abort trap: 6 (program cc1plus)
I don't see any file dumped by -freport-bug, so nothing extra to attach.
GCC build info: g++-mp-5 -v
Using built-in specs.
COLLECT_GCC=g++-mp-5
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin14/5.0.0/lto-wrapper
Target: x86_64-apple-darwin14
Configured with:
/opt/local/var/macports/build/_opt_mports_dports_lang_gcc5/gcc5/work/gcc-5-20150405/configure
--prefix=/opt/local --build=x86_64-apple-darwin14
--enable-languages=c,c++,objc,obj-c++,fortran,java --libdir=/opt/local/lib/gcc5
--includedir=/opt/local/include/gcc5 --infodir=/opt/local/share/info
--mandir=/opt/local/share/man --datarootdir=/opt/local/share/gcc-5
--with-local-prefix=/opt/local --with-system-zlib --disable-nls
--program-suffix=-mp-5 --with-gxx-include-dir=/opt/local/include/gcc5/c++/
--with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local
--with-isl=/opt/local --enable-stage1-checking --disable-multilib --enable-lto
--enable-libstdcxx-time --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld
--with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket
--with-pkgversion='MacPorts gcc5 5-20150405_0'
Thread model: posix
gcc version 5.0.0 20150405 (experimental) (MacPorts gcc5 5-20150405_0)
AlisdairMs-Mobile-Desktop:gcc_bug_lambda_ice alisdairm$
[Bug c++/60605] New: incorrect diagosis of default template argument for function declaration inside class template member function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60605
Bug ID: 60605
Summary: incorrect diagosis of default template argument for
function declaration inside class template member
function
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: public at alisdairm dot net
This bug looks looks obscure, but breaks our 'static assert' facility for C++03
compilers (after applying a workaround for the gcc 4.8 unused typedef warning):
template typename T = int
struct Foo {
void bar() {
void bug();
}
};
This should simply be declaring 'bug' as a function in the enclosing namespace,
the default template parameter on the class template is irrelevant, 'bug' is
neither a function template nor a member function of a class template.
With g++ -std=c++03 I get:
main.cpp: In member function 'void FooT::bar()':
main.cpp:4:18: error: default template arguments may not be used in function
templates without -std=c++11 or -std=gnu++11
void bug();
^
With g++ -std=c++11 I get:
main.cpp: In member function 'void FooT::bar()':
main.cpp:4:18: error: default argument for template parameter for class
enclosing 'void bug()'
void bug();
^
I am not sure what language rule the C++11 switch thinks it is diagnosing, this
code is accepted by the Clang compiler which I used as a cross-check.
[Bug libstdc++/60448] swap_ranges does not use ADL correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60448 --- Comment #11 from Alisdair Meredith public at alisdairm dot net --- Created attachment 32298 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32298action=edit Portable test of ADL on local type Agreed, not-a-bug. For completeness, I attach a final test case that does perform ADL on a local class to unambiguously find the right 'swap', properly using CRTP to inject the friend that is the strongest match. Thanks to David Rodriguez Ibeas for the exact syntax to make this example work. This example works correctly with both libstdc++ and libc++ - no bug. Can I withdraw/close the issue myself? (don't know gcc bug system for handling user-error)
[Bug libstdc++/60448] swap_ranges does not use ADL correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60448 --- Comment #14 from Alisdair Meredith public at alisdairm dot net --- Among other things, it lets fools like me write code relying on a behavior, not realizing that the code is not portable. As a user I swing between the convenience of having that utility, vs. the inconvenience of it being an extension rather than mandated. Other issues are whether rampant use of SFINAE tricks has an impact on resource usage during compilation, and more confusing error messages along the lines of I could not find this function that you have clearly supplied. With Concepts Lite coming, there should be a cleaner way in the language to get the same effects, so as a single user data point, I would prefer to defer any non-standard-mandated changes along these lines until after Concepts lands - in whatever form that turns out to be. More research demonstrating the cost is really not significant in medium-large scale software might soften my view.
[Bug libstdc++/60448] New: swap_ranges does not use ADL correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60448 Bug ID: 60448 Summary: swap_ranges does not use ADL correctly Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: public at alisdairm dot net Created attachment 32286 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32286action=edit Demonstrate swap_ranges does not find swap via ADL The attached program does not correctly use ADL to find the 'swap' member implemented inside the tagged local class in C++11/C++1y builds. It is not expected to compile in C++03 or earlier dialects. The problem compiles and runs as expected on Clang 3.4 with libc++ in both C++11 and C++1y modes.
[Bug libstdc++/60448] swap_ranges does not use ADL correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60448 --- Comment #1 from Alisdair Meredith public at alisdairm dot net --- Created attachment 32287 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32287action=edit Cleaner tagging scheme for the local class Simplified the example to more directly expose the local class via ADL without any funky casts.
[Bug libstdc++/60448] swap_ranges does not use ADL correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60448 --- Comment #8 from Alisdair Meredith public at alisdairm dot net --- I agree with Mark's analysis. I was trying to force use of swap on a local class, and found a pattern that worked for libc++ but missed that neither template would be more specialized - my original attempt used friends ands not valid for other reasons. The key is that libc++ SFINAEs swap on the type requirements, while libstdc++ defers the error until swap is instantiated. I am still surprised that I get an error for calling the move operations of 'local' though (in the second example) rather than getting an ambiguous lookup. I think the first example is unambiguously a user-error (mine) by this analysis.
[Bug c++/55564] New: internal error using decltype of a template type parameter for late-specified function result type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55564
Bug #: 55564
Summary: internal error using decltype of a template type
parameter for late-specified function result type
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pub...@alisdairm.net
The following program gives an internal compiler error, when built with the
command line: g++ -std=c++11 main.cpp
//---
template typename T, decltype(sizeof(T)) N
auto array_size(T()[N]) - decltype(N) { return N; }
int main() {
int simple[4] = {};
int result = array_size(simple);
return result;
}
//---
The error I get from my build of gcc is:
main.cpp: In function 'int main()':
main.cpp:1:38: internal compiler error: in dependent_type_p, at cp/pt.c:19249
template typename T, decltype(sizeof(T)) N
^
main.cpp:1:38: internal compiler error: Abort trap: 6
g++-mp-4.8: internal compiler error: Abort trap: 6 (program cc1plus)
Abort trap: 6
Build is a recent version obtained from MacPorts, running on the latest Apple
Mountain Lion OS with up to date patches.
g++ -v:
Using built-in specs.
COLLECT_GCC=g++-mp-4.8
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin12/4.8.0/lto-wrapper
Target: x86_64-apple-darwin12
Configured with: ../gcc-4.8-20121125/configure --prefix=/opt/local
--build=x86_64-apple-darwin12
--enable-languages=c,c++,objc,obj-c++,fortran,java
--libdir=/opt/local/lib/gcc48 --includedir=/opt/local/include/gcc48
--infodir=/opt/local/share/info --mandir=/opt/local/share/man
--datarootdir=/opt/local/share/gcc-4.8 --with-local-prefix=/opt/local
--with-system-zlib --disable-nls --program-suffix=-mp-4.8
--with-gxx-include-dir=/opt/local/include/gcc48/c++/ --with-gmp=/opt/local
--with-mpfr=/opt/local --with-mpc=/opt/local --with-ppl=/opt/local
--with-cloog=/opt/local --enable-cloog-backend=isl
--disable-cloog-version-check --enable-stage1-checking --disable-multilib
--enable-lto --enable-libstdcxx-time --with-as=/opt/local/bin/as
--with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar
--with-bugurl=https://trac.macports.org/newticket --with-pkgversion='MacPorts
gcc48 4.8-20121125_0'
Thread model: posix
gcc version 4.8.0 20121125 (experimental) (MacPorts gcc48 4.8-20121125_0)
[Bug c++/54875] New: Forward declare enums cannot be used as a template argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54875
Bug #: 54875
Summary: Forward declare enums cannot be used as a template
argument
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pub...@alisdairm.net
The following simple code snippet shows the problem:
templatetypename T
using AddConst = T const;
enum FwdEnum : int;
int main() {
AddConstFwdEnum *ptr = nullptr;
}
Trying to instantiate the alias template, in this case to declare a pointer but
the problem is more general, produces an internal compiler error. The problem
is probably older than the gcc 4.8 I am testing with, but it does give a nice
assertion from the compiler:
main.cpp: In function 'int main()':
main.cpp:7:20: internal compiler error: tree check: expected enumeral_type,
have template_type_parm in tsubst_enum, at cp/pt.c:18923
AddConstFwdEnum *ptr = nullptr;
^
main.cpp:7:20: internal compiler error: Abort trap: 6
g++-mp-4.8: internal compiler error: Abort trap: 6 (program cc1plus)
Abort trap: 6
Version info of the compiler I am testing with:
gcc -v -save-temps -std=c++11
Using built-in specs.
Target: i686-apple-darwin11
Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2336.11~28/src/configure
--disable-checking --enable-werror
--prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2
--mandir=/share/man --enable-languages=c,objc,c++,obj-c++
--program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/
--with-slibdir=/usr/lib --build=i686-apple-darwin11
--enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.11~28/dst-llvmCore/Developer/usr/local
--program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11
--target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)
[Bug c++/52030] New: ICE with decltype(make_tuple) is a late return type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52030
Bug #: 52030
Summary: ICE with decltype(make_tuple) is a late return type
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pub...@alisdairm.net
The following sample code compiles with gcc 4.6.2, but produces and ICE for
recent 4.7 builds:
#include tuple
using namespace std;
templatetypename ...T
auto factory(T... t) - decltype(make_tuple(t...)) {
return make_tuple(t...);
}
auto main() - int {
auto x = factory(3);
}
Reported error:
tree check: expected tree_list, have in eq_local_specializations, at
cp/pt.c:1687
Version info of compiler I am testing with:
Using built-in specs.
COLLECT_GCC=g++-mp-4.7
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin11/4.7.0/lto-wrapper
Target: x86_64-apple-darwin11
Configured with: ../gcc-4.7-20120121/configure --prefix=/opt/local
--build=x86_64-apple-darwin11 --enable-languages=c,c++,objc,obj-c++
--libdir=/opt/local/lib/gcc47 --includedir=/opt/local/include/gcc47
--infodir=/opt/local/share/info --mandir=/opt/local/share/man
--datarootdir=/opt/local/share/gcc-4.7 --with-local-prefix=/opt/local
--with-system-zlib --disable-nls --program-suffix=-mp-4.7
--with-gxx-include-dir=/opt/local/include/gcc47/c++/ --with-gmp=/opt/local
--with-mpfr=/opt/local --with-mpc=/opt/local --enable-stage1-checking
--disable-multilib --enable-lto
Thread model: posix
gcc version 4.7.0 20120121 (experimental) (GCC)
[Bug c++/52030] ICE with decltype(make_tuple) is a late return type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52030 --- Comment #2 from Alisdair Meredith public at alisdairm dot net 2012-01-28 23:06:53 UTC --- IT could well be - I struggled to get a more minimal example when not using 'make_tuple', and it could well be doing something similar, especially if it yields the same ICE. Does the sample code I give compile correctly with the patch for PR51852?
[Bug c++/51593] New: alias templates fail in dependent contexts requiring ::template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51593
Bug #: 51593
Summary: alias templates fail in dependent contexts requiring
::template
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pub...@alisdairm.net
The following code is sufficient to demonstrate:
templatetypename T
struct wrap {
templatetypename U
using type = U;
};
templatetypename T
struct test {
using type = wrapT::template typeT;
};
I get the following errors from a gcc built around Dec 10, 2011:
main.cpp:9:10: error: expected nested-name-specifier before 'type'
main.cpp:9:10: error: using-declaration for non-member at class scope
main.cpp:9:15: error: expected ';' before '=' token
main.cpp:9:15: error: expected unqualified-id before '=' token
This idiom seems important for supporting C++11 allocators, which supply just
such a dependent alias.
Version info from my GCC build (running on Mac OS/X 10.7.2)
Using built-in specs.
COLLECT_GCC=g++-mp-4.7
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin11/4.7.0/lto-wrapper
Target: x86_64-apple-darwin11
Configured with: ../gcc-4.7-20111210/configure --prefix=/opt/local
--build=x86_64-apple-darwin11 --enable-languages=c,c++,objc,obj-c++
--libdir=/opt/local/lib/gcc47 --includedir=/opt/local/include/gcc47
--infodir=/opt/local/share/info --mandir=/opt/local/share/man
--datarootdir=/opt/local/share/gcc-4.7 --with-local-prefix=/opt/local
--with-system-zlib --disable-nls --program-suffix=-mp-4.7
--with-gxx-include-dir=/opt/local/include/gcc47/c++/ --with-gmp=/opt/local
--with-mpfr=/opt/local --with-mpc=/opt/local --enable-stage1-checking
--disable-multilib
Thread model: posix
gcc version 4.7.0 20111210 (experimental) (GCC)
[Bug c++/51593] alias templates fail in dependent contexts requiring ::template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51593 --- Comment #2 from Alisdair Meredith public at alisdairm dot net 2011-12-16 23:18:27 UTC --- Thanks, I thought I had tried that, but I guess not. It seems reasonable to close this as user error.
[Bug c++/50853] New: Internal Compiler Error returning a template type using brace initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50853
Bug #: 50853
Summary: Internal Compiler Error returning a template type
using brace initialization
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pub...@alisdairm.net
The following obscure code produces an ICE when the function template 'test' is
called:
templateint struct MyType{};
templateint VAL
auto test(MyTypeVAL) - MyTypeint{VAL} { return {}; }
int main() {
MyTypeint{256}{};
test( MyType256{} ); // no error without this call
}
The ICE produced is:
internal compiler error: in tsubst_copy_and_build, at cp/pt.c:13389
[Bug c++/50855] New: Name mangling for late return types invoking constructors not implemented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50855
Bug #: 50855
Summary: Name mangling for late return types invoking
constructors not implemented
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pub...@alisdairm.net
Jason suggested I file the issue, even though the error message indicates a
known limitation.
The following code yields the error:
main.cpp: In instantiation of 'decltype ({256}) test(const T) [with T = char,
decltype ({256}) = char]':
main.cpp:8:14: instantiated from here
main.cpp:2:6: sorry, unimplemented: mangling constructor
templatetypename T
auto test(T const ) - decltype(T{256}) {
return T{};
}
int main() {
char c = 42;
c = test(c);
}
[Bug c++/50853] [C++0x] Internal Compiler Error returning a template type using brace initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50853 --- Comment #3 from Alisdair Meredith public at alisdairm dot net 2011-10-24 14:02:22 UTC --- The original report was compiled with gcc 4.6.1 supplied by MacPorts. Could you confirm if the not-supported error message occurs in trunk, or a separately compiled gcc 4.6.1?
[Bug c++/50855] [C++0x] Name mangling for late return types invoking constructors not implemented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50855 --- Comment #2 from Alisdair Meredith public at alisdairm dot net 2011-10-24 14:06:55 UTC --- It might be. I still see an ICE for PR50853, but if that is giving the same error now, then it is probably the same root cause. I'm still waiting to hear if I have an issue with my specific build of 4.6.1, or if PR50853 hits an issue since cleaned up in the trunk.
[Bug c++/50853] [C++0x] Internal Compiler Error returning a template type using brace initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50853 --- Comment #5 from Alisdair Meredith public at alisdairm dot net 2011-10-24 14:10:38 UTC --- Using built-in specs. COLLECT_GCC=gcc-mp-4.6 COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin10/4.6.1/lto-wrapper Target: x86_64-apple-darwin10 Configured with: ../gcc-4.6-20110325/configure --prefix=/opt/local --build=x86_64-apple-darwin10 --enable-languages=c,c++,objc,obj-c++ --libdir=/opt/local/lib/gcc46 --includedir=/opt/local/include/gcc46 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --datarootdir=/opt/local/share/gcc-4.6 --with-local-prefix=/opt/local --with-system-zlib --disable-nls --program-suffix=-mp-4.6 --with-gxx-include-dir=/opt/local/include/gcc46/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --enable-stage1-checking --disable-multilib --enable-fully-dynamic-string Thread model: posix gcc version 4.6.1 20110325 (prerelease) (GCC) Hmm, that 'pre-rerelease' tag is annoying - the MacPorts port file updated to suggest this is the release version, rather than the release candidate. Sounds like I have a bad version, anyway. Sorry for the noise.
[Bug c++/50855] [C++0x] Name mangling for late return types invoking constructors not implemented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50855 --- Comment #3 from Alisdair Meredith public at alisdairm dot net 2011-10-24 14:13:31 UTC --- And just to confirm - it sounds like the ICE in PR50853 is a bad compiler at my end. I suggest keeping *this* PR open, as at least it reports the correct error!
[Bug c++/50853] [C++0x] Internal Compiler Error returning a template type using brace initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50853 --- Comment #8 from Alisdair Meredith public at alisdairm dot net 2011-10-24 14:27:18 UTC --- I am happy with closed - the ICE is resolved an PR50855 reports the unimplemented error message, with (hopefully) a simpler test case. It might be worth re-testing once PR50855 is resolved, just to be sure though.
[Bug c++/50810] New: c++0x-compat does not warn about narrowing conversions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50810
Bug #: 50810
Summary: c++0x-compat does not warn about narrowing conversions
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pub...@alisdairm.net
The following program is rejected by g++ in -std=c++0x mode (assuming 'char' is
signed) but does not raise any warnings when compiled with -Wc++0x-compat:
int main() {
char data[] = { 0xff };
char value = 0xff;
}
This is significantly the largest source of compatibility errors in our
code-base today (95% of our known issues), so it would be very useful if the
warning caught these.
[Bug c++/43947] New: [C++0x] constexpr should allow declaration without a definition
GCC 4.5 has early support for constexpr, which syntax checks code but does not
support use in a constant expression.
The following code should be allowed, but fails as GCC currently requires the
in initial declaration also be a definition:
constexpr auto five() - int;
inline constexpr auto five() - int { return 5; }
Similarly, member functions should be allowed:
struct host {
static constexpr auto five() - int;
}
inline constexpr auto host::five() - int { return 5; }
and finally constructors:
struct test_type {
int data;
constexpr test_type(int x);
};
inline constexpr test_type::test_type(int x )
: data{x}
{
}
Note that the constexpr keyword is required on *every* declaration and
definition.
--
Summary: [C++0x] constexpr should allow declaration without a
definition
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: public at alisdairm dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43947
[Bug c++/43947] [C++0x] constexpr should allow declaration without a definition
--- Comment #3 from public at alisdairm dot net 2010-04-30 13:15 --- Subject: Re: [C++0x] constexpr should allow declaration without a definition I am aware constexpr is not fully supported, and checked with Jason before filing this issue. We believe that constexpr should currently support correct syntax checking, and issues with syntax (not semantic) are valid for fixes in 4.5. Clearly, there will be no support for using the result of a constexpr function in constant expression, but it should act like a regular inline function, with a few additional constraints. This is actually impacting a project I am developing (home-brew STL implementation) where I am currently placing constexpr where standard requires it, but #defining it away until compilers support it. GCC 4.5 fires off errors in my code for detecting constexpr support, so I really don't want to #define away a keyword if I can avoid it. If the intent is that these parser issues will not be addressed in 4.5, then I will revert my library to the old behaviour, but this would be a very useful experiment if it could continue (looking at how code changes to live within constexpr restrictions, that may affect how appropriate it is in practice for all library uses if there is a runtime efficiency impact in non-constant-expression usage) On Apr 30, 2010, at 8:57 AM, paolo dot carlini at oracle dot com wrote: --- Comment #2 from paolo dot carlini at oracle dot com 2010-04-30 12:57 --- Really, constexpr are *not* available yet, it seems definitely too early to file PRs (in retrospect, I think we should not have committed those parser bits, are causing a lot of counfusion :( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43947 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43947
[Bug c++/40633] New: ICE with scoped enum inside a template
The following code produces an internal compiler error:
template typename T
struct wrap {
enum class E { val };
};
Note that there is no problem supplying a fixed-base for a 'classic' enum, this
is purely an issue with the enum class keyword combination.
Tested under MinGW 4.4.0
--
Summary: ICE with scoped enum inside a template
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: public at alisdairm dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40633
[Bug c++/40639] New: Cannot parse dependant type for enum-base in C++0x
In C++0x mode, enums are allowed to specify an integral type for the base
representation. If the enum is inside a class template, it may be a
type-dependant expression that should not evaluate and potentially error until
instantiation time.
Example code:
//
template typename T
struct wrap {
enum E : T { val };
};
template typename T
struct dependant {
enum E : typename T::type { val };
};
templatetypename T
struct identity {
typedef T type;
};
wrapint x;
dependantidentityint y;
//
--
Summary: Cannot parse dependant type for enum-base in C++0x
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: public at alisdairm dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40639
[Bug c++/40306] New: ICE when using auto to declare a local copy inside a member function
Tested on MinGW 4.4.0
The following code produces an Internal Compiler Error:
template typename T
struct test {
test run() {
auto tmp = *this;
return tmp;
}
};
int main()
{
testint x;
x.run();
return 0;
}
Compiler output:
||=== AutoBug01, Debug ===|
In member function 'testT testT::run()':
error: in type_unification_real, at cp/pt.c:12477|
||=== Build finished: 1 errors, 0 warnings ===|
--
Summary: ICE when using auto to declare a local copy inside a
member function
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: public at alisdairm dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40306
[Bug c++/40307] New: Problem with auto deducing class type inside one of its own member functions
The following code demonstrates the problem. It should compile cleanly, as
demonstrated by the run_pass function, but the run_fail function generates an
error:
template typename T
struct test {
test run_pass() {
test tmp( *this );
return tmp;
}
test run_fail() {
auto tmp( *this );
return tmp;
}
};
int main()
{
testint x;
x.run_pass();
x.run_fail();
return 0;
}
Compiler output:
||=== AutoBug02, Debug ===|
In member function 'testT testT::run_fail() [with T = int]':
instantiated from here
error: 'tmp' has incomplete type
||=== Build finished: 1 errors, 0 warnings ===|
--
Summary: Problem with auto deducing class type inside one of its
own member functions
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: public at alisdairm dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40307
[Bug c++/40308] New: Brace initialization fails for member initializers in constructor for class templates
Tested against MinGW 4.4.0
The following code fails to compile, with the two specializations yielding
different error messages.
Test code:
template typename T
struct test {
test() : data{} {}
T data;
};
int main()
{
testint x;
testint* y;
return 0;
}
Compiler output:
||=== BraceInitBug01, Debug ===|
main.cpp||In constructor 'testT::test() [with T = int]':|
main.cpp|10|instantiated from here|
main.cpp|3|error: aggregate value used where an integer was expected|
main.cpp||In constructor 'testT::test() [with T = int*]':|
main.cpp|11|instantiated from here|
main.cpp|3|error: cannot convert 'brace-enclosed initializer list()' from
type 'brace-enclosed initializer list' to type 'int*'|
||=== Build finished: 2 errors, 0 warnings ===|
--
Summary: Brace initialization fails for member initializers in
constructor for class templates
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: public at alisdairm dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40308
[Bug c++/40311] New: brace initialization does not work well with new
Tested on MinGW 4.4.0
The following code does not compile and should:
int main()
{
int * a = new int{};
int * b = new int{5};
return 0;
}
Compiler output:
main.cpp||In function 'int main()':|
main.cpp|3|error: aggregate value used where an integer was expected|
main.cpp|4|error: aggregate value used where an integer was expected|
main.cpp|3|warning: unused variable 'a'|
main.cpp|4|warning: unused variable 'b'|
||=== Build finished: 2 errors, 2 warnings ===|
--
Summary: brace initialization does not work well with new
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: public at alisdairm dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40311
