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
--- 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
: 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
--- 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
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
--- 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
--- 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
--- 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
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
--- 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
.
--
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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
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
--- 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
--- 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
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
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
--- 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
: 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
--- 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
--- 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
++
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
--- 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
: 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
: 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
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
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
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
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
wyderski at gmail dot com
GCC host triplet: Cygwin/GCC4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40258
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
--- 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
--- 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
--- 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
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
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
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
--- 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
--- 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
--- 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
: 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
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
56 matches
Mail list logo
