--- 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
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
--- 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; .ende
: 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
--- 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,
--- 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=20183&action=view)
Testcase to replicate the bug
--
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
To: 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
--- 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
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
--- 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 its
--- 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=19727&action=view)
preprocessed boost 1.39 mpl/size.hpp (20100107)
--
http://gcc.gnu.org/bugzilla/show_bug
--- 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
--- 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
--- 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 0
--- 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 earl
--- 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 #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=19725&action=view)
compiler error output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
--- 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=19724&action=view)
preprocessed boost 1.39 mpl/size.hpp
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
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
--- 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 specializat
--- 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
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 targ
--- 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 => e
--- 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
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://g
--- 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=19639&action=view)
Source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42779
o: 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
ot 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
--- 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 :
> If it's unimplemented, it's unimplemented, the issue
> is obviously known.
Even in this cas
nedTo: 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
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: Cyg
--- 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<>
{
};
template
--- 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 --pre
--- 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|Re
--- 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
--- 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
--- 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=19357&action=view)
The faulting code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42447
erity: 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
erity: 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
nedTo: 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
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
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
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
--- 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 :
> You want this:
>
> typename std::result_of< decltype(&traits::restore) (S*) >::type
Thank you! :-)
&
--- Comment #11 from piotr dot wyderski at gmail dot com 2009-04-07 15:02
---
Subject: Re: std::result_of doesn't work
2009/4/7 jwakely dot gcc at gmail dot com :
> what you probably want is:
In fact I want to copy the return type of a template method restore
and use as
--- 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 #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 are still following the TR1
> specifications, thus, in general, do not expect conformance to the latest
> C++0x
> draft (or file a
s: 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
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
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 d
--- 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 #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
oduct: 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
--- 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
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
edTo: 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
57 matches
Mail list logo
