[Bug c++/44499] New: No default constructor available
The following code:
class C {
};
class D : public C {
};
const D g_d;
fails to compile on trunk (rev. 160489) with the following message:
$ g++ test.cpp
test.cpp:11:9: error: uninitialized const 'g_d' [-fpermissive]
test.cpp:6:11: note: 'const class D' has no user-provided default constructor
--
Summary: No default constructor available
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: piotr dot wyderski at gmail dot com
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44499
[Bug c++/44499] No default constructor available
--- Comment #4 from piotr dot wyderski at gmail dot com 2010-06-11 11:01 --- (In reply to comment #2) A question: apart from quoting chapter and verse from the standard (8.5 [dcl.init], para 9 in C++03, para 6 in C++0x,) how could the diagnostic have been any clearer? It indicates you can use -fpermissive to relax the warning, and it includes a note telling you the type has no user-provided default constructor, which is true. Why would you assume this is a bug, when a developer has gone to the trouble of writing the note? All the compilers I am aware of accept the aforementioned construction, so I blindly assumed that 4.6 is wrong in issuing a warning. The note's content was considered irrelevant, since no error was expected. But if the behaviour is OK, then it is OK no matter what a surprise it turns out to be. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44499
[Bug c/43599] New: Several missing optimizations
I was wondering whether GCC can optimize
sin(x) and cos(x) of the same angle in order
to use the combined fsincos x86 instruction.
The testcase is:
8
#include math.h
double fn1(double x) {
return sin(x) * cos(x);
}
double fn2(double x) {
return __builtin_sin(x) * __builtin_cos(x);
}
8
I compile it with:
gcc -O3 -fomit-frame-pointer -S testcase.cpp
The result turned out to be rather surprising:
8
.file testcase.cpp
.text
.p2align 4,,15
.globl __Z3fn1d
.def__Z3fn1d; .scl2; .type 32; .endef
__Z3fn1d:
subl$60, %esp
fldl64(%esp)
fstl(%esp)
fstpl 16(%esp)
call_sin
fstpl 40(%esp)
fldl16(%esp)
fstpl (%esp)
call_cos
fmull 40(%esp)
addl$60, %esp
ret
.p2align 4,,15
.globl __Z3fn2d
.def__Z3fn2d; .scl2; .type 32; .endef
__Z3fn2d:
subl$60, %esp
fldl64(%esp)
fstl(%esp)
fstpl 16(%esp)
call_sin
fstpl 40(%esp)
fldl16(%esp)
fstpl (%esp)
call_cos
fmull 40(%esp)
addl$60, %esp
ret
.def_sin; .scl2; .type 32; .endef
.def_cos; .scl2; .type 32; .endef
.def_sin; .scl2; .type 32; .endef
.def_cos; .scl2; .type 32; .endef
8
As you can see:
a) fsin and fcos are not combined into fsincos, because
b) there are no fsin and fcos -- library calls have been emitted;
c) the stack top manipulation (subl / addl $60, %esp) has no purpose.
--
Summary: Several missing optimizations
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: piotr dot wyderski at gmail dot com
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43599
[Bug c/43599] Several missing optimizations
--- Comment #2 from piotr dot wyderski at gmail dot com 2010-03-31 11:00 --- With -ffast-math the code becomes .file testcase.cpp .text .p2align 4,,15 .globl __Z3fn1d .def__Z3fn1d; .scl2; .type 32; .endef __Z3fn1d: fldl4(%esp) fsincos fmulp %st, %st(1) ret .p2align 4,,15 .globl __Z3fn2d .def__Z3fn2d; .scl2; .type 32; .endef __Z3fn2d: fldl4(%esp) fsincos fmulp %st, %st(1) ret which is exactly the expected output, but: -ffast-math: This option should never be turned on by any -O option since it can result in incorrect output for programs which depend on an exact implementation of IEEE or ISO rules/specifications for math functions. So, what IEEE rules does the fsin/fcos/fsincos emission/fussion break? The only problem I see is excessive accuracy, but it can be removed using the fld/fst trick used by -ffloat-store (and THAT can be removed by -ffast-math), without the need to declare the entire program as IEEE754 non-conformant. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43599
[Bug c++/43508] New: ICE when compiling SSE code in non-debug mode
The compiler ICEs with the following message: (vec_select:SI (reg:V4SI 21 xmm0 [84]) (parallel [ (const_int 1 [0x1]) ]))/home/piotr.wyderski/rt_rel/texture.cpp: In member function 'virtual float __vector[4] rt::texture_2d::map(float __vector[4]) const': /home/piotr.wyderski/rt_rel/texture.cpp:82:1: internal compiler error: in mem_lo c_descriptor, at dwarf2out.c:13589 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[1]: *** [CMakeFiles/a.dir/texture.cpp.o] Error 1 I didn't manage to create a reasonably-sized testcase. -- Summary: ICE when compiling SSE code in non-debug mode Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: piotr dot wyderski at gmail dot com GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43508
[Bug c++/43508] ICE when compiling SSE code in non-debug mode
--- Comment #2 from piotr dot wyderski at gmail dot com 2010-03-24 13:24 --- Compiled with: $ /opt/gcc-trunk/bin/g++ -std=gnu++0x -Wno-pmf-conversions -fno-deduce-init-lis t -O3 -DNDEBUG -Wall -Werror -Wno-unused -msse -msse2 -march=native -mfpmath= sse -fomit-frame-pointer -c -ggdb texture.cpp.i However, it is very hard to replicate the error. It is fully deterministic, but occurs on [gcc version 4.5.0 20100322 (experimental) (GCC)] -- a month older compiler does not fail. It also doesn't happen without -ggdb. It requires an SSE4.1-capable processor (mine is Core i7), but occurs only when -march=native -- if I specify no march and explicitly enable -msse4, it also doesn't fail. I don't know what exact command line without -march should look like to cause the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43508
[Bug c++/43508] ICE when compiling SSE code in non-debug mode
--- Comment #3 from piotr dot wyderski at gmail dot com 2010-03-24 13:27 --- Created an attachment (id=20183) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20183action=view) Testcase to replicate the bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43508
[Bug debug/43508] ICE when compiling SSE code with -ggdb
--- Comment #5 from piotr dot wyderski at gmail dot com 2010-03-24 15:33 --- wonder about the subject, the ICE clearly happens in debug mode, not non-debug mode... The command line specified does not contain -DNDEBUG, as the preprocessed file was created in non-debug mode, so all the #ifndef NDEBUG sections have already been removed by the preprocessor. If the entire build (i.e. via CMake) is done in debug mode, the compiler doesn't ICE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43508
[Bug c++/43375] New: ICE during compiling SSE code
compiling SSE code Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: piotr dot wyderski at gmail dot com GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43375
[Bug c++/43375] [4.5 Regression] ICE during compiling SSE code
--- Comment #2 from piotr dot wyderski at gmail dot com 2010-03-15 12:20 --- (In reply to comment #1) It's a fairly recent regression: the snapshot 20100218 compiled it without problems. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43375
[Bug c++/42880] New: trunk does not compile boost MPL
gcc version 4.5.0 20100126 (rev. 156253) is not able to compile the following program: #include boost/mpl/size.hpp version 20100115 didn't complain. I've checked it on boost 1.37 and 1.39. For those who don't have boost installed, there is a preprocessed file from boost 1.39. -- Summary: trunk does not compile boost MPL Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: piotr dot wyderski at gmail dot com GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
[Bug c++/42880] trunk does not compile boost MPL
--- Comment #1 from piotr dot wyderski at gmail dot com 2010-01-27 10:43 --- Created an attachment (id=19724) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19724action=view) preprocessed boost 1.39 mpl/size.hpp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
[Bug c++/42880] trunk does not compile boost MPL
--- Comment #2 from piotr dot wyderski at gmail dot com 2010-01-27 10:44 --- Created an attachment (id=19725) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19725action=view) compiler error output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
[Bug c++/42880] trunk does not compile boost MPL
--- Comment #4 from piotr dot wyderski at gmail dot com 2010-01-27 11:06 --- (In reply to comment #3) The new compiler was built with gcc-4.5.0 20100115. Both were configured as follows: $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/opt/gcc-trunk/libexec/gcc/i686-pc-cygwin/4.5.0/lto-wrapper. exe Target: i686-pc-cygwin Configured with: ../configure --prefix=/opt/gcc-trunk -v --enable-bootstrap --en able-version-specific-runtime-libs --enable-shared --enable-shared-libgcc --with -gnu-ld --with-gnu-as --enable-dwarf2-exceptions --disable-symvers --disable-nls --with-arch=core2 --with-tune=generic --enable-threads=posix --enable-languages =c,c++ Thread model: posix gcc version 4.5.0 20100126 (experimental) (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
[Bug c++/42880] trunk does not compile boost MPL
--- Comment #9 from piotr dot wyderski at gmail dot com 2010-01-27 12:27 --- (In reply to comment #7) Thanks Dave. Thus, essentially, is submitter wrong that the problem is new? My code compiled flawlessly on 4.5.0-20100115, otherwise I would have reported the issue earlier... 20100126 has been built in a clean directory, so no interferences with previous builds are possible. Paolo: yes, -std=gnu++0x -- it's the reason I use trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
[Bug c++/42880] trunk does not compile boost MPL
--- Comment #16 from piotr dot wyderski at gmail dot com 2010-01-27 12:39 --- Can you attach the preprocessed source you get from that build of the compiler Unfortunately not, because I assumed that the new compiler will work, so make install overwritten the binaries of 0115. Anyway, I think I have an earlier build somewhere (20100107) which also works, so I will provide you a preprocessed source from that version. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
[Bug c++/42880] trunk does not compile boost MPL
--- Comment #19 from piotr dot wyderski at gmail dot com 2010-01-27 12:47 --- Then say that explicitly, *always*. Actually, the complete command line is part of the requirements for PRs. Sorry, I misunderstood you. I use -std=gnu++0x in my actual program, which today became uncompilable. For the PR it was: g++ -std=gnu++0x br.cpp -I/usr/include/boost_1_39_0/ Without extensions enabled, merely: g++ br.cpp -I/usr/include/boost_1_39_0/ the compiler also emits an error list, however much shorter (it's probably what you see on Linux): specialization after instantiation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
[Bug c++/42880] trunk does not compile boost MPL
--- Comment #23 from piotr dot wyderski at gmail dot com 2010-01-27 13:04 --- cmdline: g++ [-std=gnu++0x] br.cpp -I/usr/include/boost_1_39_0/ On gcc version 4.5.0 20090604 (experimental) (GCC): compiled OK On gcc version 4.5.0 20100107 (experimental) (GCC) compiled OK On 20100115 it was also OK, but I can't prove it. On 20100126: a lot of errors, the amount depends on the presence of -std=gnu++0x I have no intermediate builds between 15 and 26, so can't reduce the range any more. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
[Bug c++/42880] trunk does not compile boost MPL
--- Comment #24 from piotr dot wyderski at gmail dot com 2010-01-27 13:08 --- Created an attachment (id=19727) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19727action=view) preprocessed boost 1.39 mpl/size.hpp (20100107) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
[Bug c++/42880] trunk does not compile boost MPL
--- Comment #26 from piotr dot wyderski at gmail dot com 2010-01-27 13:25 --- Apart from include file paths in # lines, the two files are identical. I double-checked the compilers used to generate them -- the attachments are correct. So the issue must be inside the compiler itself, not in its stdc++ includes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
[Bug c++/42877] New: ICE when checking the type of a lambda
gcc-trunk (20100115)
template typename T struct toff;
template typename TR, typename... TA struct toffTR (*)(TA...) {
typedef TR type;
};
template typename TR, typename TC, typename... TA struct toffTR
(TC::*)(TA...) const {
typedef TR type;
};
template typename TR, typename TC, typename... TA struct toffTR
(TC::*)(TA...) {
typedef TR type;
};
template typename T void dem(T op) {
typedef typename toffdecltype(T::operator ())::type r_type;
}
int main(int argc, char *argv[]) {
dem([](int x){ return x; });
return 0;
}
$ g++ -std=gnu++0x br.cpp
br.cpp: In function 'void dem(T) [with T = main(int, char**)::lambda(int)]':
br.cpp:29:31: instantiated from here
br.cpp:23:64: internal compiler error: canonical types differ for identical
type
s int(int) and int(int)
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
--
Summary: ICE when checking the type of a lambda
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: piotr dot wyderski at gmail dot com
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42877
[Bug c++/42877] ICE when checking the type of a lambda
--- Comment #2 from piotr dot wyderski at gmail dot com 2010-01-26 17:35 --- (In reply to comment #1) probably a dup of Bug 42082 or Bug 42737 Yes, it could be the case. BTW, Jason, is the presented way of discovering of the lambda function's return type correct in C++0x? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42877
[Bug c++/42877] [C++0x] ICE when checking the type of a lambda
--- Comment #6 from piotr dot wyderski at gmail dot com 2010-01-26 20:09 --- (In reply to comment #4) I assume the original version is also intended to work with non-empty captures, when operator() is non-static Yes, that's the purpose of the first two specializations. But that part works correctly, only the function ptr variant ICEs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42877
[Bug tree-optimization/42778] New: Superfluous stack management code is generated
#include x86intrin.h
int test1(__m128i v) {
return _mm_cvtsi128_si32(v);
}
compiled with
g++ -std=gnu++0x -O2 -m32 -march=native -msse -msse2 -msse3 -Wall
-Werror -Wno-unused -Wno-strict-aliasing -march=native
-fomit-frame-pointer -Wno-pmf-conversions -g main.cpp
emits:
004012e0 __Z5test1U8__vectorx:
4012e0: 83 ec 0csub$0xc,%esp
4012e3: 66 0f 7e c0 movd %xmm0,%eax
4012e7: 83 c4 0cadd$0xc,%esp
4012ea: c3 ret
which shows that the stack pointer is being updated
without any purpose.
--
Summary: Superfluous stack management code is generated
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: piotr dot wyderski at gmail dot com
GCC host triplet: GCC-trunk(20100107)/Cygwin/WinXP32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42778
[Bug tree-optimization/42779] New: [C++0x] Variadic templates + lambdas = extremely poor code quality
The attached code compiled with
g++ -std=gnu++0x -O2 -m32 -march=native -msse -msse2 -msse3 -Wall
-Werror -Wno-unused -Wno-strict-aliasing -march=native
-fomit-frame-pointer -Wno-pmf-conversions -g main.cpp
emits code which is, to put it mildly,
far from optimal. For instance, the code of
bit_vector::op_not_or:
combine([](__m128i x, __m128i y) { return _mm_xor_si128(_mm_or_si128(x, y),
g_Mask[128]); }, true, v1, v2);
emits:
00401800 __ZN10bit_vector9op_not_orERKS_S1_:
401800: 55 push %ebp
401801: 57 push %edi
401802: 56 push %esi
401803: 53 push %ebx
401804: 83 ec 1csub$0x1c,%esp
401807: 8b 74 24 30 mov0x30(%esp),%esi
40180b: 8b 7c 24 34 mov0x34(%esp),%edi
40180f: 8b 6c 24 38 mov0x38(%esp),%ebp
401813: 8b 5f 04mov0x4(%edi),%ebx
401816: 39 ee cmp%ebp,%esi
401818: 74 46 je 401860
__ZN10bit_vector9op_not_orERKS_S1_+0x60
40181a: 83 c3 7fadd$0x7f,%ebx
40181d: c1 eb 07shr$0x7,%ebx
401820: 85 db test %ebx,%ebx
401822: 74 30 je 401854
__ZN10bit_vector9op_not_orERKS_S1_+0x54
401824: 31 c0 xor%eax,%eax
401826: 66 0f 76 c9 pcmpeqd %xmm1,%xmm1
40182a: 8d b6 00 00 00 00 lea0x0(%esi),%esi
401830: 8b 0f mov(%edi),%ecx
401832: 89 c2 mov%eax,%edx
401834: 40 inc%eax
401835: c1 e2 04shl$0x4,%edx
401838: 39 c3 cmp%eax,%ebx
40183a: 66 0f 6f 04 11 movdqa (%ecx,%edx,1),%xmm0
40183f: 8b 4d 00mov0x0(%ebp),%ecx
401842: 66 0f eb 04 11 por(%ecx,%edx,1),%xmm0
401847: 8b 0e mov(%esi),%ecx
401849: 66 0f ef c1 pxor %xmm1,%xmm0
40184d: 66 0f 7f 04 11 movdqa %xmm0,(%ecx,%edx,1)
401852: 75 dc jne401830
__ZN10bit_vector9op_not_orERKS_S1_+0x30
401854: 83 c4 1cadd$0x1c,%esp
401857: 5b pop%ebx
401858: 5e pop%esi
401859: 5f pop%edi
40185a: 5d pop%ebp
40185b: c3 ret
--
Summary: [C++0x] Variadic templates + lambdas = extremely poor
code quality
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: piotr dot wyderski at gmail dot com
GCC host triplet: GCC-trunk(20100107)/Cygwin/WinXP32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42779
[Bug tree-optimization/42779] [C++0x] Variadic templates + lambdas = extremely poor code quality
--- Comment #1 from piotr dot wyderski at gmail dot com 2010-01-17 20:15 --- Created an attachment (id=19639) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19639action=view) Source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42779
[Bug c++/42780] New: Incorrect warning message
Uncomment the code of bit_vector::op_not (Attachment #19639)
and compile with
g++ -std=gnu++0x -O2 -m32 -march=native -msse -msse2 -msse3 -Wall
-Werror -Wno-unused -Wno-strict-aliasing -march=native
-fomit-frame-pointer -Wno-pmf-conversions -g main.cpp
an error message will appear:
main.cpp: In function 'long long int __vector__ dump(long long int
__vector__)':
main.cpp:653:1: error: control reaches end of non-void function
but the function dump() is not non-void:
void dump(__m128i v) { ...
--
Summary: Incorrect warning message
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: piotr dot wyderski at gmail dot com
GCC host triplet: GCC-trunk(20100107)/Cygwin/WinXP32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42780
[Bug tree-optimization/42779] [C++0x] Variadic templates + lambdas = extremely poor code quality
--- Comment #3 from piotr dot wyderski at gmail dot com 2010-01-17 20:46 --- This is a generic code, as it covers two bug reports. In fact, it will probably be used as a base for additional two missing optimization reports. So I thought it would be good to provide the code of the entire sandbox. To be more specific: the vectors passed to combine() are constant. The compiler should not re-evaluate the base addresses of the m_Data arrays every iteration, as above: mov(%edi),%ecx ... mov0x0(%ebp),%ecx ... mov(%esi),%ecx A single base address fetch phase and index-based addressing with scaled induction variable (by a factor of 16) will be more optimal, e.g.: // esi = src1 // edi = src2 // ebx = dst // edx = induction variable L0:cmpl %edx, max_index je L1: movdqa (%esi,%edx,1),%xmm0 por(%edi,%edx,1),%xmm0 pxor %xmm1, %xmm0 movdqa %xmm0, (%ebx, %edx, 1) add$16, %edx jmpL0 L1: as I would have written it by hand in assembler. An aggresively unrolled version (say, four-way) with prefetching for longer blocks will also be welcome. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42779
[Bug target/42779] [C++0x] Variadic templates + lambdas = extremely poor code quality, __m128i and aliasing sucks
--- Comment #8 from piotr dot wyderski at gmail dot com 2010-01-17 21:29 --- It would be great to use my own vector data types, as in simple cases it allows GCC to automaticly vectorize them in a portable way, but in more complex cases it would mean a lot of explicit type casts = even more unreadable code, which even now is hard to follow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42779
[Bug c++/42702] New: Unimplemented functionality
g++ -std=gnu++0x -c -O2
prints:
minimal.cpp:8:44: sorry, unimplemented: cannot expand '_Tail ...' into a
fixed-l
ength argument list
reduced testcase:
templatetypename _Tp
class tuple
{
{
}
templatestd::size_t __i, typename _Head, typename... _Tail
struct tuple_element__i, tuple_Head, _Tail...
: tuple_element__i - 1, tuple_Tail... { };
--
Summary: Unimplemented functionality
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: piotr dot wyderski at gmail dot com
GCC host triplet: Cygwin/GCC-trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42702
[Bug c++/42702] Unimplemented functionality
--- Comment #2 from piotr dot wyderski at gmail dot com 2010-01-12 13:05 --- Subject: Re: Unimplemented functionality paolo dot carlini wrote: at oracle dot com gcc-bugzi...@gcc.gnu.org: If it's unimplemented, it's unimplemented, the issue is obviously known. Even in this case? runtime/base/stack_trace.h:130:30: sorry, unimplemented: inlining failed in call to 'base::stack_trace::stack_trace(size_t)': function not inlinable Best regards Piotr Wyderski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42702
[Bug c++/42459] New: Escape sequence parsing is broken
To my best knowledge, the \xNN escape sequence
should expect exactly two hexadecimal digits, but
the following program shows that GCC is too greedy:
#include stdio.h
int main() {
static const char t[] = \x05Data;
for(int i = 0; i != sizeof(t); ++i) {
fprintf(stderr, %02x , (unsigned) t[i]);
}
fprintf(stderr, \n);
}
produces:
ffda 74 61 00
instead of:
05 44 61 74 61 00
i.e. the Da from Data is also used as a part of the hexadecimal escape
sequence.
--
Summary: Escape sequence parsing is broken
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: piotr dot wyderski at gmail dot com
GCC host triplet: Cygwin/GCC-4.5-20090601
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42459
[Bug c++/42447] New: ICE during processing complex templates
Compile the attached sources as follows:
g++ -std=gnu++0x -c -Wno-pmf-conversions file_reader.cpp
An Internal Compiler Error report will appear:
file_reader.cpp: In instantiation of
'std::unique_ptrbase::dynamic_dispatchvoid
(io::file_reader::*)(io::request)::entry [], base::release_deleter':
file_reader.cpp:35664:39: instantiated from 'std::unique_ptr_Tp [],
_Tp_Deleter::unique_ptr() [with _Tp = base::dynamic_dispatchvoid
(io::file_reader::*)(io::request)::entry, _Tp_Deleter =
base::release_deleter]'
file_reader.cpp:86579:76: instantiated from 'base::dynamic_dispatchTR
(TC::*)(TD, TA ...)::dynamic_dispatch(TR (TC::*)(TD, TA ...), size_t) [with
TC = io::file_reader, TR = void, TD = io::request, TA = {}, TR (TC::*)(TD, TA
...) = void (io::file_reader::*)(io::request), size_t = unsigned int]'
file_reader.cpp:88954:55: instantiated from here
file_reader.cpp:35653:5: internal compiler error: in finish_member_declaration,
at cp/semantics.c:2445
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
--
Summary: ICE during processing complex templates
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: piotr dot wyderski at gmail dot com
GCC host triplet: Cygwin/GCC-trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42447
[Bug c++/42447] ICE during processing complex templates
--- Comment #1 from piotr dot wyderski at gmail dot com 2009-12-21 12:41 --- Created an attachment (id=19357) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19357action=view) The faulting code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42447
[Bug c++/42447] [C++0x] ICE during processing complex templates
--- Comment #3 from piotr dot wyderski at gmail dot com 2009-12-21 13:47 --- (In reply to comment #2) Any chance you can provide a smaller reproducer? Thanks. No, every simpler testcase based on the attached code I tried to create compiles successfully. Perhaps here is the problem? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42447
[Bug c++/42447] [C++0x] ICE during processing complex templates
--- Comment #5 from piotr dot wyderski at gmail dot com 2009-12-21 14:27
---
(In reply to comment #4)
Certainly *is* a problem if we hope to debug the issue decently fast...
I meant the cause of the problem is in its size, i.e.
there must be a critical mass of templates to trigger
the issue. There probably is no problem in std::unique_ptr
on its own; to me it seems to be a random victim of
something strange happening under the hood. As I said,
I am not able to shrink it down in a reasonable way.
For example, this simplified testcase compiles flawlessly:
#include memory
struct release_deleter {
template class T void operator()(T* p) {
static_assert(std::is_podT::value ||
std::is_sameT, void::value,
T must be a POD type or void);
}
};
template typename T class dynamic_dispatch;
template
typename TC,
typename TR,
typename TD,
typename... TA
class dynamic_dispatchTR (TC::*)(TD, TA...) {
class entry {};
typedef std::unique_ptrentry[], release_deleter entry_ptr;
public:
template typename UC, typename UD void attach_handler(TR
(UC::*m)(UD, TA...));
};
template
typename TC,
typename TR,
typename TD,
typename... TA
template
typename UC,
typename UD
void dynamic_dispatchTR (TC::*)(TD, TA...)::attach_handler(TR
(UC::*m)(UD, TA...)) {
};
class C {
public:
void M(int);
};
dynamic_dispatchvoid (C::*)(int) dd;
int main() {
dd.attach_handler(C::M);
}
But the problem is definitely related to template
processing. If you comment out the folowing line
(at the very bottom of the attached file, in the
constructor):
attach_handler(static_castvoid (file_reader::*)(read_request0)
(file_reader::execute_command));
it compiles OK.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42447
[Bug c++/42447] [C++0x] ICE during processing complex templates
--- Comment #8 from piotr dot wyderski at gmail dot com 2009-12-21 16:38 --- (In reply to comment #6) A marvelous tool! I'm reducing it too, staring at the proces with half-open mouth... -- piotr dot wyderski at gmail dot com changed: What|Removed |Added Severity|normal |major http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42447
[Bug c++/42447] [C++0x] ICE during processing complex templates
--- Comment #10 from piotr dot wyderski at gmail dot com 2009-12-21 17:23
---
(In reply to comment #9)
Thus, are you sure the code is valid, before anything else?
It compiles and works on gcc version 4.5.0 20090604.
The current compiler is
Configured with: ../configure --prefix=/opt/gcc-trunk -v --enable-bootstrap
--en
able-version-specific-runtime-libs --enable-shared --enable-shared-libgcc
--with
-gnu-ld --with-gnu-as --enable-dwarf2-exceptions --disable-symvers
--disable-nls
--with-arch=core2 --with-tune=generic --enable-threads=posix
--enable-languages
=c,c++
Thread model: posix
gcc version 4.5.0 20091217 (experimental) (GCC)
And here's the reduced testcase:
--8--
namespace std
templatetypename _Tp
struct __add_ref_Tp
{ typedef _Tp type; };
class tuple
{
};
templatetypename _T1, typename _T2
{
{
}
};
templatestd::size_t __i, typename... _Elements
inline typename __add_ref
::type
get(tuple_Elements... __t)
{
}
}
struct _Fnv_hash4
{
{
}
};
namespace std {
template class _OutputIterator, class _Tp
{
{
{
}
{
{
}
}
};
}
template typename _Tp, typename _Tp_Deleter = default_delete_Tp
class unique_ptr
{
reset(pointer __p = pointer())
{
{
}
}
{
}
};
templatetypename _Tp, typename _Tp_Deleter
class unique_ptr_Tp[], _Tp_Deleter
{
typedef std::tuple_Tp*, _Tp_Deleter __tuple_type;
get() const
{ return std::get0(_M_t); }
__tuple_type _M_t;
};
namespace base {
struct release_deleter {
template class T void operator()(T* p) {
}
};
template typename T class dynamic_dispatch;
template
typename TC,
typename TR,
typename TD,
typename... TA
class dynamic_dispatchTR (TC::*)(TD, TA...) {
struct entry {
};
typedef std::unique_ptrentry[], release_deleter entry_ptr;
entry_ptr m_Start;
template typename UC, typename UD void attach_handler(TR
(UC::*m)(UD, TA...));
};
template
typename TC,
typename TR,
typename TD,
typename... TA
template
typename UC,
typename UD
void dynamic_dispatchTR (TC::*)(TD, TA...)::attach_handler(TR
(UC::*m)(UD, TA...)) {
entry* p = m_Cursor;
if (p != m_Start.get()) {
} while(--p != m_Start.get());
}
class __attribute__((dllexport)) request {
};
template std::size_t N_CHID class read_request : public read_request_base
{
};
template typename TC class request_dispatcher
: private base::dynamic_dispatchvoid (TC::*)(request) {
request_dispatcher();
};
class __attribute__((dllexport)) device {
struct __attribute__((dllexport)) control_block : public OVERLAPPED {
explicit control_block(request req) {
}
};
};
class __attribute__((dllexport)) file_reader : public physical_device {
void execute_command(read_request0 req);
};
template request_dispatcherfile_reader::request_dispatcher()
: super(file_reader::report_unsupported_request) {
attach_handler(file_reader::execute_command);
--
piotr dot wyderski at gmail dot com changed:
What|Removed |Added
Severity|normal |major
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42447
[Bug c++/42447] [C++0x] ICE during processing complex templates
--- Comment #11 from piotr dot wyderski at gmail dot com 2009-12-21 17:38
---
An even more reduced testcase which ICEs. Delta is amazing...
I think I'll stop here.
// 8
namespace std
class tuple
{
};
templatestd::size_t __i, typename... _Elements
get(tuple_Elements... __t)
{
}
template class _OutputIterator, class _Tp
class unique_ptr
{
};
templatetypename _Tp, typename _Tp_Deleter
class unique_ptr_Tp[], _Tp_Deleter
{
typedef std::tuple_Tp*, _Tp_Deleter __tuple_type;
get() const
{ return std::get0(_M_t); }
__tuple_type _M_t;
};
namespace base {
struct release_deleter {
};
template typename T class dynamic_dispatch;
template
typename TC,
typename TR,
typename TD,
typename... TA
class dynamic_dispatchTR (TC::*)(TD, TA...) {
struct entry {
};
typedef std::unique_ptrentry[], release_deleter entry_ptr;
entry_ptr m_Start;
template typename UC, typename UD void attach_handler(TR
(UC::*m)(UD, TA...));
};
template
typename TC,
typename TR,
typename TD,
typename... TA
template
typename UC,
typename UD
void dynamic_dispatchTR (TC::*)(TD, TA...)::attach_handler(TR
(UC::*m)(UD, TA...)) {
entry* p = m_Cursor;
if (p != m_Start.get()) {
} while(--p != m_Start.get());
}
class __attribute__((dllexport)) request {
};
template std::size_t N_CHID class read_request : public read_request_base
{
};
template typename TC class request_dispatcher
: private base::dynamic_dispatchvoid (TC::*)(request) {
request_dispatcher();
};
class __attribute__((dllexport)) file_reader : public physical_device {
void execute_command(read_request0 req);
};
template request_dispatcherfile_reader::request_dispatcher()
: super(file_reader::report_unsupported_request) {
attach_handler(file_reader::execute_command);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42447
[Bug libstdc++/42408] New: Missing templatized seed()
There is no templatized user-provided seed() and related constructors in the C++0x random number generation library. The draft N3000 says that the engines (Mersenne Twister, among others) have templateSeedSequence Sseq explicit mersenne_twister_engine(Sseq q); templateSeedSequence Sseq void seed(Sseq q); in order to use a user-supplied seed generator. GCC classes accept only std::seed_seq, which in some situations doesn't provide high-enough entropy. -- Summary: Missing templatized seed() Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: piotr dot wyderski at gmail dot com GCC host triplet: Cygwin/GCC4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42408
[Bug c++/40283] New: [C++0x] Context-specific explicit conversion doesn't work
std::unique_ptr has an explicit conversion to
bool operator. However, according to Wikipedia:
http://en.wikipedia.org/wiki/C%2B%2B0x#Explicit_conversion_operators
In C++0x, the explicit keyword can now be applied to conversion operators. As
with constructors, it prevents the use of those conversion functions in
implicit conversions. However, language contexts that specifically require a
boolean value (the conditions of if-statements and loops, as well as operands
to the logical operators) count as explicit conversions and can thus use a bool
conversion operator.
But the following code doen't compile:
#include stdio.h
#include memory
int main(int argc, char *argv[]) {
std::unique_ptrint p(0);
if (p) {}
return 0;
}
Results in:
$ gcc -std=gnu++0x testcase.cpp
testcase.cpp: In function 'int main(int, char**)':
testcase.cpp:10: error: could not convert 'p' to 'bool'
--
Summary: [C++0x] Context-specific explicit conversion doesn't
work
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: piotr dot wyderski at gmail dot com
GCC host triplet: Cygwin/GCC-trunk rev. 147886
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40283
[Bug c++/40269] New: ICE during procesing class attributes
#include stdio.h
class __declspec(dllexport) A {};
int main(int argc, char *argv[]) {
return 0;
}
$ gcc testcase.cpp
testcase.cpp:3: internal compiler error: tree check: expected function_decl,
hav
e type_decl in handle_dll_attribute, at tree.c:4172
Please submit a full bug report,
with preprocessed source if appropriate.
--
Summary: ICE during procesing class attributes
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: piotr dot wyderski at gmail dot com
GCC host triplet: Cygwin/GCC-trunk rev. 147886
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40269
[Bug libstdc++/40273] New: [C++0x] Invalid conwersion to bool is reported
#include stdio.h
#include functional
int main(int argc, char *argv[]) {
std::functionvoid* () f = 0;
if (f != 0) {}
return 0;
}
gcc -std=gnu++0x testcase.cpp
$ gcc -std=gnu++0x testcase.cpp
In file included from
/opt/gcc-trunk/lib/gcc/i686-pc-cygwin/4.5.0/include/c++/fu
nctional:70,
from testcase.cpp:2:
/opt/gcc-trunk/lib/gcc/i686-pc-cygwin/4.5.0/include/c++/tr1_impl/functional: In
function 'bool std::operator!=(const std::function_Signature,
std::_M_clear_t
ype*) [with _Signature = void*()]':
testcase.cpp:8: instantiated from here
/opt/gcc-trunk/lib/gcc/i686-pc-cygwin/4.5.0/include/c++/tr1_impl/functional:2116
: error: could not convert '__f' to 'bool'
--
Summary: [C++0x] Invalid conwersion to bool is reported
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: piotr dot wyderski at gmail dot com
GCC host triplet: Cygwin/GCC-trunk rev. 147886
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40273
[Bug libstdc++/40258] New: void has no trivial destructor
There is a discrepancy between boost:: and std:: type traits.
#include boost/type_traits.hpp
#include type_traits
#include cstdio
int main(int argc, char *argv[]) {
fprintf(stderr, std::has_trivial_destructorvoid = %i\n,
std::has_trivial_destructorvoid::value);
fprintf(stderr, boost::has_trivial_destructorvoid = %i\n,
boost::has_trivial_destructorvoid::value);
return 0;
}
According to STD void does not have a trivial destructor,
but according to boost it does. Please state which result
is correct and if it's boost's case, then fix the traits.
--
Summary: void has no trivial destructor
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: piotr dot wyderski at gmail dot com
GCC host triplet: Cygwin/GCC4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40258
[Bug libstdc++/39676] New: std::result_of doesn't work
--8--
#include functional
int fn(long, float) {
return 0;
}
int main(int argc, char *argv[]) {
typedef std::result_ofdecltype(fn)::type type;
return 0;
}
--8--
$ g++ -std=c++0x testcase.cpp
In file included from
/opt/gcc-4.4.0-trunk/lib/gcc/i686-pc-cygwin/4.4.0/include/
c++/functional:75,
from testcase.cpp:2:
/opt/gcc-4.4.0-trunk/lib/gcc/i686-pc-cygwin/4.4.0/include/c++/tr1_impl/functiona
l: In instantiation of 'std::_Result_of_implfalse, int ()(long int, float)':
/opt/gcc-4.4.0-trunk/lib/gcc/i686-pc-cygwin/4.4.0/include/c++/tr1_impl/functiona
l:154: instantiated from 'std::result_ofint ()(long int, float)'
testcase.cpp:13: instantiated from here
/opt/gcc-4.4.0-trunk/lib/gcc/i686-pc-cygwin/4.4.0/include/c++/tr1_impl/functiona
l:200: error: 'int' is not a class, struct, or union type
gcc used is:
$ gcc -v
Using built-in specs.
Target: i686-pc-cygwin
Configured with: ../configure --prefix=/opt/gcc-4.4.0-trunk -v
--enable-bootstra
p --enable-version-specific-runtime-libs --enable-static --enable-shared
--enabl
e-shared-libgcc --with-gnu-ld --with-gnu-as --enable-sjlj-exceptions
--enable-la
nguages=c,c++ --disable-symvers --enable-libjava --disable-nls
--with-cpu-32=cor
e2 --with-cpu-64=core2 --enable-threads=posix
Thread model: posix
gcc version 4.4.0 20090309 (experimental) (GCC)
--
Summary: std::result_of doesn't work
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: piotr dot wyderski at gmail dot com
GCC host triplet: WinXP/x86/Cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39676
[Bug libstdc++/39676] std::result_of doesn't work
--- Comment #2 from piotr dot wyderski at gmail dot com 2009-04-07 14:05
---
(In reply to comment #1)
Note that *most* of the facilities in functional are still following the TR1
specifications, thus, in general, do not expect conformance to the latest
C++0x
draft (or file a DR for each unimplemented behavior ;)
The only C++0x functionality involved I am aware of is decltype,
which is outside of the template scope. BTW,
boost::function_traits...::result_type
works flawlessly. Here is a simplified testcase:
#include functional
int main(int argc, char *argv[]) {
typedef std::result_ofint (long, float)::type type;
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39676
[Bug libstdc++/39676] std::result_of doesn't work
--- Comment #5 from piotr dot wyderski at gmail dot com 2009-04-07 14:31 --- So it is a purely C++0x bug, as you indicated in your first reply. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39676
[Bug libstdc++/39676] std::result_of doesn't work
--- Comment #15 from piotr dot wyderski at gmail dot com 2009-04-07 15:47 --- Subject: Re: std::result_of doesn't work jwakely dot gcc at gmail dot com gcc-bugzi...@gcc.gnu.org: You want this: typename std::result_of decltype(traitsT::restore) (S*) ::type Thank you! :-) Paolo, let's close this. Agreed. :-) Best regards, Piotr -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39676
[Bug c++/39642] New: [C++0x] Unimplemented variadic template type expansion
The following testcase:
-8-
#include stdio.h
#include vector
template typename T struct S;
template typename... TA struct Sstd::vectorTA... {
};
int main(int argc, char *argv[]) {
return 0;
}
-8-
produces:
$ g++ -std=c++0x testcase.cpp
testcase.cpp:6: sorry, unimplemented: cannot expand 'TA ...' into a
fixed-length argument list
testcase.cpp:6: error: template argument 1 is invalid
--
Summary: [C++0x] Unimplemented variadic template type expansion
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: piotr dot wyderski at gmail dot com
GCC host triplet: Cygwin/WinXP/gcc-4.4.0-snapshot-20090123
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39642
[Bug c++/39413] New: static_assert and SFINAE
G++ fails when compiling the following program in
g++0x mode. It displays spooky action at a distance
when instantiating the member_ptr template, but I
expect the converting assignment operator from weak_ptr
to be selected instead.
-8---
#include type_traits
class A {
};
class B : public A {
};
class C {
};
namespace gc {
template typename T class member_ptr;
}
template typename T class weak_ptr {
public:
weak_ptr() {}
template typename X weak_ptr(const weak_ptrX v) {}
weak_ptr(const weak_ptr) = default;
weak_ptr(const gc::member_ptrT v);
~weak_ptr() = default;
// --
weak_ptr operator =(const weak_ptr) = default;
template typename X weak_ptr operator =(const weak_ptrX v) {
return *this; }
};
namespace gc {
template typename T class member_ptr {
static_assert(std::is_base_ofC, T::value,
spooky action at a distance);
};
}
int main(int argc, char *argv[]) {
weak_ptrA ap1;
weak_ptrB bp1;
ap1 = bp1;
return 0;
}
-8---
--
Summary: static_assert and SFINAE
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: piotr dot wyderski at gmail dot com
GCC host triplet: GCC-4.4.0 (20090309), Cygwin, Windows XP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39413
[Bug web/38973] New: Missing feature documentation
The website http://gcc.gnu.org/projects/cxx0x.html claims that the New character types N2249 C++0x extension is not supported by any version of GCC. But GCC 4.4.0 supports the u8, u and U string prefixes. :-) -- Summary: Missing feature documentation Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: web AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: piotr dot wyderski at gmail dot com GCC host triplet: GCC-4.4.0, Cygwin, Windows XP http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38973
[Bug c++/38064] [c++0x] operator== doesn't work for enum classes
--- Comment #3 from piotr dot wyderski at gmail dot com 2009-01-26 10:48 --- The bug is definitely confirmed and it still happens on GCC-4.4.0 trunk (revision 143673). -- piotr dot wyderski at gmail dot com changed: What|Removed |Added CC||piotr dot wyderski at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38064
[Bug web/38973] Missing feature documentation
--- Comment #2 from piotr dot wyderski at gmail dot com 2009-01-26 11:30 --- The website includes feature descriptions of the 4.4 mainline and even of some branches (lambda, concepts). I consider this C++0x extension to be extremelly useful, so IMHO the website should indicate at least partial support of it in order to allow others start their experiments with it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38973
[Bug bootstrap/37660] Error Building libssp, recent update
--- Comment #2 from piotr dot wyderski at gmail dot com 2009-01-14 15:20 --- Still happens on Cygwin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37660
[Bug c++/38552] New: Invalid function return path analysis error report
The following snippet:
8-
#include memory
typedef std::auto_ptrint v_type;
v_type fn(int v) {
v_type r(new int(4));
switch(v) {
case 1:
case 2: {
return v_type(new int(5));
} break;
default:
return r;
}
}
int main(int argc, char *argv[])
{
fn(4);
return 0;
}
8-
compiled with:
g++ -Wall -Werror test.cpp
errornously produces:
error: control reaches end of non-void function
However, clearly, all control flow paths do return some result.
Without the break statement the code compiles flawlessly.
--
Summary: Invalid function return path analysis error report
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: piotr dot wyderski at gmail dot com
GCC host triplet: Windows Vista 64-bit, Core2, GCC 4.3.1 (cygwin)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38552
[Bug c++/38555] New: Invalid function return path analysis error report
-- Summary: Invalid function return path analysis error report Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: piotr dot wyderski at gmail dot com GCC host triplet: Windows Vista 64-bit, Core2, GCC 4.3.1 (cygwin) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38555
