Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: chris at bubblescope dot net
Target Milestone: ---
Created attachment 44628
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44628&action=edit
Preprocessed file which produces clo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59557
--- Comment #10 from Chris Jefferson ---
It's a dup -- debian have backported the fix to 4.8.2.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59557
--- Comment #6 from Chris Jefferson ---
Wait a minute, I am getting my timeline wrong, sorry.
This is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58800 , which will be fixed
for 4.8.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59557
--- Comment #5 from Chris Jefferson ---
Also tried with svn head, the code works (and passes using valgrind as well)
caj@caj-laptop ~/Downloads> /gcc-svn/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/gcc-svn/bin/g++
COLLECT_LTO_WRAPPER=/gcc-svn/l
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59557
--- Comment #3 from Chris Jefferson ---
Can I just confirm I am testing this code correctly?
caj@caj-laptop ~/Downloads> g++ BVH_Example.cpp -O0
caj@caj-laptop ~/Downloads> ./a.out
Brute force distance = 0.00428018, calls = 1
BVH distance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59557
--- Comment #2 from Chris Jefferson ---
Investigating
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57916
Chris Jefferson changed:
What|Removed |Added
CC||chris at bubblescope dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58437
--- Comment #20 from Chris Jefferson ---
Created attachment 30867
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30867&action=edit
Performance tests for sort
This is some performance tests for performance checking. Sorry for tar rather
than
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58437
--- Comment #16 from Chris Jefferson ---
Indeed, if std::sort had never used lower-level partitioning to get the pivot
in the correct location, we would never have had this problem in the first
place!
This is not too serious a problem performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58437
--- Comment #13 from Chris Jefferson ---
Created attachment 30861
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30861&action=edit
Sort patch
Wow, this an embarrassing bug to get through testing. Obviously not enough
profiling done!
This pa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58437
--- Comment #7 from Chris Jefferson ---
I will look at this next week. Quicksorts are always suboptimal for mostly
sorted (forwards or backwards) data, and it would be nice to fix that.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358
--- Comment #22 from Chris Jefferson ---
Her are some comparisons. Just to compare, I also checked doing away with
skipping optimisations altogether. Binary sizes (-O3, stripped)
current head: 11928
my code: 12248
Mitsuru: 11384
No ski
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358
--- Comment #19 from Chris Jefferson ---
(In reply to Mitsuru Kariya from comment #15)
> Created attachment 30775 [details]
> Patch
>
> For your convenience, I attached a patch for this problem.
>
> This algorithm is always scanned to reverse or
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358
--- Comment #14 from Chris Jefferson ---
(In reply to Marc Glisse from comment #12)
> Chris, did you consider applying this optimized code to bidirectional
> iterators and not just random access iterators? We may end up doing a few
> more ++/-- th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358
--- Comment #13 from Chris Jefferson ---
Created attachment 30767
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30767&action=edit
Bug patch
Patch attached.
This features:
1) As well as checking backwards when we find a match, check forwar
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358
--- Comment #6 from Chris Jefferson ---
I have a patch I believe fixes this, but trunk doesn't currently build on my
machine (Bug 58340). I'll wait for that to get fixed.
It is annoying there is still separate predicate and non-predicate copies o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358
--- Comment #4 from Chris Jefferson ---
Just to say I see this, and fortunately it's not hard to keep the optimisation
and meet the complexity requirements.
Expect patch later today.
ormal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: chris at bubblescope dot net
The following code (notice the function takes a long long, the template takes
an int. This code is invalid)
template
struct S {};
template
void g(S);
v
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56367
Bug #: 56367
Summary: unordered containers behave badly with NaN
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: minor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55841
Chris Jefferson changed:
What|Removed |Added
CC||chris at bubblescope dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53046
--- Comment #9 from Chris Jefferson 2012-04-23
10:54:57 UTC ---
Looking at the output of -fdump-tree-all, it looks like the compiler optimises
the loop which accesses an array out of bounds to:
while(true);
Is this expected behaviour? That seem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53046
--- Comment #7 from Chris Jefferson 2012-04-23
09:57:12 UTC ---
While I haven't yet got a recent copy of gcc trunk compiled, it does indeed
look like an out-of-bounds error, but just a 'testsuite' problem.
At the top of both mem_check tests as a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53046
--- Comment #6 from Chris Jefferson 2012-04-23
09:44:11 UTC ---
Yes, will check.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51965
Chris Jefferson changed:
What|Removed |Added
CC||chris at bubblescope dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705
--- Comment #43 from Chris Jefferson 2012-01-09
22:59:49 UTC ---
g++ only does this while compiling the C++ standard library. clang doesn't come
(by default) with a C++ standard library, so you have to use either libstdc++
(from g++) or libc++. W
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705
--- Comment #40 from Chris Jefferson 2012-01-09
22:45:32 UTC ---
There are several C++11 features which clang does not support, which g++ does.
clang also defines __cplusplus == 201103L, despite not implementing large parts
of the C++11 standard.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705
--- Comment #36 from Chris Jefferson 2012-01-09
21:45:10 UTC ---
By your reasoning, FreeBSD really may as well take out code which requires
__cplusplus == 201103L , as no compiler will support all of C++11 for several
years I am sure. I would be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705
--- Comment #8 from Chris Jefferson 2011-12-29
22:21:35 UTC ---
(In reply to comment #4)
> On Thu, Dec 29, 2011 at 08:56:20PM +0000, chris at bubblescope dot net wrote:
> > Better take out C++03 support as well, seeing as there is no su
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705
Chris Jefferson changed:
What|Removed |Added
CC||chris at bubblescope dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51183
--- Comment #18 from Chris Jefferson 2011-12-06
14:41:19 UTC ---
2011-12-06 Chris Jefferson
PR libstdc++/51183
* include/std/tuple (pair::pair): Add two constructors which
use delegating constructors
(pair::__cons, pair::__do_c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51183
--- Comment #16 from Chris Jefferson 2011-12-06
14:25:24 UTC ---
Created attachment 26006
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26006
Piecewise patch
Patch to make piecewise_construct work properly on std::pair.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51183
--- Comment #13 from Chris Jefferson 2011-12-06
10:13:56 UTC ---
You can if you like, but if you haven't started yet, I plan on having a patch
ready in about... 2 hours?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51183
--- Comment #9 from Chris Jefferson 2011-12-05
16:19:40 UTC ---
The only difference in the version I wrote was that I passed the arguments into
the explicit constructor as non-const references, rather than by value with
std::move, which should be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51183
--- Comment #10 from Chris Jefferson 2011-12-05
16:25:13 UTC ---
Oh, and one other tiny detail, I've about given up trying to understand corner
cases in the name look-up rules in C++, so I'd probably std:: qualify those
'get's, just to be on the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51183
Chris Jefferson changed:
What|Removed |Added
CC||chris at bubblescope dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50462
Bug #: 50462
Summary: Particularly painful error message
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: minor
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49559
--- Comment #13 from Chris Jefferson 2011-06-28
19:16:00 UTC ---
I am on holiday until tomorrow night, and away from a computer. Once I get
back, I promise to give this my full attention. This code got messy in the
first place because I was tryin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49386
--- Comment #3 from Chris Jefferson 2011-06-13
08:15:39 UTC ---
Ah yes. This is unfortunate, and I believe tricky to fix at the gcc end. We
could in principle add '#undef min, #undef max', but I worry that might break
something else.
If you '#de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49386
Chris Jefferson changed:
What|Removed |Added
CC||chris at bubblescope dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48038
--- Comment #29 from Chris Jefferson 2011-03-09
16:07:15 UTC ---
Created attachment 23604
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23604
Changelog for stable sort change
Changelog
I've put Jonathan in here, because part of the test c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48038
--- Comment #26 from Chris Jefferson 2011-03-09
15:58:24 UTC ---
But, the first line of the method (of all the methods) is:
VERIFY(rh.ok);
So, we know it's true. That might still look more consistent/clear.
Very sorry about the formatting. If
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48038
Chris Jefferson changed:
What|Removed |Added
Attachment #23599|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48038
--- Comment #19 from Chris Jefferson 2011-03-09
13:35:48 UTC ---
Ignore that patch, there is a problem with it (tester wasn't working properly).
Sorry.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48038
--- Comment #18 from Chris Jefferson 2011-03-09
13:34:51 UTC ---
Just to update:
I have checked other users of MOVE_ITERATOR (there are only two) and they
appear fine, as they do not use a comparator.
Attached is an initial patch. Very sorry if
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48038
--- Comment #17 from Chris Jefferson 2011-03-09
13:34:22 UTC ---
Created attachment 23599
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23599
Patch to make stable_sort work with comparitors that take by value.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48038
--- Comment #14 from Chris Jefferson 2011-03-09
11:51:24 UTC ---
Ah yes, I see the problem now.
The problem is to do with using move_iterator. When we compare two values which
we dereference from a move_iterator, then we end up "moving" into the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48038
--- Comment #9 from Chris Jefferson 2011-03-09
11:28:13 UTC ---
Just to say, I am looking at this. Thanks for the small test case.
on invalid code
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris at bubblescope dot net
http://gcc.gnu.org/bugzilla
--- Comment #1 from chris at bubblescope dot net 2010-06-22 06:46 ---
Created an attachment (id=20972)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20972&action=view)
ICEing invalid code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44623
--- Comment #6 from chris at bubblescope dot net 2010-06-21 14:35 ---
Of course, there is a big difference between an ICE and an infinite loop. Also,
bug which causes ICEs on one computer and not another need treating with great
care, as that suggests unpredictable memory corruption may
--- Comment #3 from chris at bubblescope dot net 2010-06-21 12:10 ---
Many apologises, the computer had a ulimit set which I had not noticed.
Yes, I also get an infinite loop rather than an ICE.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44609
--- Comment #1 from chris at bubblescope dot net 2010-06-21 11:50 ---
Created an attachment (id=20959)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20959&action=view)
ICEing example
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44609
: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris at bubblescope dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44609
--- Comment #2 from chris at bubblescope dot net 2010-05-10 22:44 ---
Your operator< is not valid. It must be a strict-weak ordering.
In particular, it must not be possible that A < B and B < A, but in your code
this is possible.
--
chris at bubblescope dot ne
--- Comment #9 from chris at bubblescope dot net 2010-04-20 18:53 ---
I don't think it's a front-end issue. '#pragma GCC system_header' is
specifically designed to stop warnings in headers. However, it stops 'good'
warnings as well as 'bad' warnin
--- Comment #4 from chris at bubblescope dot net 2010-04-20 17:18 ---
Yes, in C++0x mode, we should just add a deprication warning for auto_ptr full
stop.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43820
--- Comment #2 from chris at bubblescope dot net 2010-04-20 17:10 ---
I think this is connected to the "suppress warning is the standard library"
pragma starting to actually work.
--
chris at bubblescope dot net changed:
What|Removed
--- Comment #1 from chris at bubblescope dot net 2010-03-31 08:09 ---
Fixing this would make std::unique quite a bit less efficient. I personally
believe the intention was always to make it an equivalence relation and as you
say C++0x tightens up the condition.
If this had come up 5 or
--- Comment #2 from chris at bubblescope dot net 2010-03-16 08:38 ---
Reduced testcase:
template
struct Container
{ T f() const; };
template
T deref(const T& t)
{ return t; }
template
auto
deref(const T& u, int r, Args... args)
-> decltype(deref(u.f(), args...))
{ retur
verity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris at bubblescope dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43382
--- Comment #12 from chris at bubblescope dot net 2010-01-22 09:11 ---
Just for anyone who comes to this bug, it can be worked around by doing
something like:
template T, typename... Args>
struct Join
{ typedef T type; }
Although of course that isn't a fix (and unfortunately
--- Comment #1 from chris at bubblescope dot net 2009-12-15 08:54 ---
I see you are building with fink. Looking on the fink website, they do not seem
to have a gcc45 package. Where did you get it from? Or has it just not made it
to the website yet?
--
chris at bubblescope dot net
--- Comment #12 from chris at bubblescope dot net 2009-12-01 19:28 ---
No need to wait, they are in g++ 4.3 and 4.4, use -std=c++0x to activate
features from C++0x. Obviously they are all subject to change, but are now
fairly close to standardised.
--
http://gcc.gnu.org/bugzilla
--- Comment #10 from chris at bubblescope dot net 2009-12-01 19:07 ---
Anyway, the result of this bug is that the fix to resize() given in the latest
draft of C++0x should be applied. The resulting code would only be invoked if
you ask the compiler to use C++0x mode, but if care about
--- Comment #8 from chris at bubblescope dot net 2009-12-01 19:01 ---
The only change in C++0x is that a new function is added, so it won't break any
existing code, and we will be able to add it without moving to v7.
--
chris at bubblescope dot net changed:
--- Comment #2 from chris at bubblescope dot net 2009-11-10 08:14 ---
Sorry, one important thing I missed off my bug report. This problem seems to
just be connected to constant lists. The following is fully optimised away
int i = 1, j = 2;
return max_val({i,j});
As is the following
--
Summary: constant initializer_list not optimised
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris at bu
--- Comment #4 from chris at bubblescope dot net 2009-10-22 23:14 ---
The reason that in general changing the Point a std::multiset::iterator
refers to is forbidden is that doing so will break the invariant on which the
multiset is based, resulting in random crashes occuring later on
--- Comment #12 from chris at bubblescope dot net 2009-10-09 17:51 ---
LD_LIBRARY_PATH doesn't exist on Mac. Usually linking libraries together 'just
works', but in this case it seems to have broken.
By configuring with --enable-fully-dynamic-string, I get a working com
--- Comment #10 from chris at bubblescope dot net 2009-10-09 15:10 ---
To sum up the current state, as things are getting confusing:
Compiling 'testsuite/21_strings/basic_string/inserters_extractors/char/1.cc -I
testsuite/util -O2'
using /newgccsvn/bin/g++ (recent svn compil
--- Comment #7 from chris at bubblescope dot net 2009-10-09 14:20 ---
Further: If I add -D_GLIBCXX_FULLY_DYNAMIC_STRING, the code compiles fine!
However, if I run otool on my executable, it says it is linked with:
Load command 10
cmd LC_LOAD_DYLIB
cmdsize 64
--- Comment #6 from chris at bubblescope dot net 2009-10-09 14:16 ---
Ah yes, something I should have tried earlier.
The resulting compiler generally works fine, until I add -D_GLIBCXX_PARALLEL,
when things break.
I only seem to get a problem when I have enough optimisation to inline
--- Comment #4 from chris at bubblescope dot net 2009-10-09 13:21 ---
I have confirmed that after compiling with 'make check-parallel', the code:
#include
int main(void)
{ string s; s = "X"; }
Fails when compiled with:
/gccsvn/bin/g++ test.cc libtestc++.a -fop
--- Comment #2 from chris at bubblescope dot net 2009-10-09 12:57 ---
I shall try to track it down -- it wouldn't suprise me if this is a snow
leopard bug, as there has been a few issues with the default system compiler
switching from 32-bit to 64-bit.
--
chris at bubblescop
rong.
--
Summary: Massive failures in parallel test mode
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
Rep
--- Comment #26 from chris at bubblescope dot net 2009-10-04 21:50 ---
Just to follow up on an earlier comment, I've tested this patch with a new
improved std::rotate test (to be submitted shortly) which tests all rotations
and positions up to length 20, and it passes fine. Furthe
--- Comment #8 from chris at bubblescope dot net 2009-09-29 11:04 ---
Just to clarify, it is not a memory leak which is occurring, it is memory
corruption. Basically when std::sort is given a type which is not totally
ordered as required, it tends to corrupt the memory immediately
--- Comment #19 from chris at bubblescope dot net 2009-09-15 14:45 ---
I think this generally looks good. The testsuite could do with some
improvement, there are quite a lot of cases for this algorithm, and it's
probably worth testing they all work properly.
I unfortunately
--- Comment #7 from chris at bubblescope dot net 2009-09-14 18:11 ---
Only a svn copy of stl_algo.h has the rvalue reference stuff for
stable_partition. We use a number of macros, like _GLIBCXX_MOVE, to wrap
various parts of the algorithms, so they work in both c++03 and c++0x.
It is a
--- Comment #5 from chris at bubblescope dot net 2009-09-14 17:00 ---
You cannot assume the elements you are sorting have a default constructor. You
can however certainly use a separate array of indices, and then swap at the
end, so I withdraw that comment. However, this also only
--- Comment #1 from chris at bubblescope dot net 2009-09-14 07:24 ---
In C++0x, this problem will go away, because move constructors will be used,
which leads to the most efficient implementation for both large and small types
(assuming they implement a move constructor at least as
--- Comment #67 from chris at bubblescope dot net 2008-12-19 11:45 ---
Sorry to come back to this again. With C++0x just around the corner, is there
any chance of getting this fixed, seeing as I expect this should be the
standard way of checking if we are in conforming C++0x mode, when
--- Comment #3 from chris at bubblescope dot net 2008-12-10 12:23 ---
Sorry, I should have been clearer. the standard forbids this overload of swap
by not listing it, unlike most other standard library types, which is lists an
overload for.
Personally, I'd be happy to just ad
--- Comment #1 from chris at bubblescope dot net 2008-12-09 23:30 ---
I agree with you, but unfortunatly the standard doesn't allow std::swap to be
defined for std::pair. Stupid I know.
C++0x does require that.
--
chris at bubblescope dot net changed:
What|Re
--- Comment #4 from chris at bubblescope dot net 2008-07-20 21:12 ---
Surely this isn't a libstdc++ bug?
--
chris at bubblescope dot net changed:
What|Removed |
--- Comment #1 from chris at bubblescope dot net 2008-05-29 08:54 ---
This works fine for me on a couple of versions.
Could you give us the output of ' g++ -v ' ?
--
chris at bubblescope dot net changed:
What|Removed
k] Error 2
--
Summary: Fixincludes failure with 'make check'
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris at bubblescope dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35904
--- Comment #2 from chris at bubblescope dot net 2008-03-18 15:02 ---
#include
#include
using namespace std;
int main(void)
{
vector > v;
}
Runs fine here, using:
Using built-in specs.
Target: i386-apple-darwin9.2.0
Configured with: ../gcc/configure --enable-languages=
--- Comment #3 from chris at bubblescope dot net 2008-03-11 17:12 ---
While I'm sure he will be along soon anyway, I shall add Paolo to the CC list
of this bug.
It looks to me like a simple typo was made while fixing 34730.
--
chris at bubblescope dot net changed:
--- Comment #2 from chris at bubblescope dot net 2008-03-11 17:08 ---
This used to work (works on Apple's gcc 4.0.1).
The bug is an inconsistency between __check_sorted_set on lines 317 and 334 and
the __check_sorted_set_aux on the lines before
The 4 __check_sorted_set_aux me
--- Comment #9 from chris at bubblescope dot net 2008-03-09 20:28 ---
Sorry to be pedantic, but could this be added to _GLIBCXX_DEBUG_PEDANTIC. I've
previously tended to assume that _GLIBCXX_DEBUG should change only flag code
that should fail in non-debug mode, but fails to be det
--- Comment #6 from chris at bubblescope dot net 2008-03-06 17:11 ---
While I agree that this is an issue of implementation detail, I thought there
was code already there to stop this case, except it is broken :(
Looking at the svn copy of tr1/tuple, you can see operator== (and others
--- Comment #2 from chris at bubblescope dot net 2008-01-01 13:08 ---
(In reply to comment #1)
> Is this related to libstdc++/34095?
>
Good question, could be. That code also fails to run for me. Unfortunately I
don't really have any good idea how to go about debugging this
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris at bubblescope dot net
GCC target triplet: i386-apple-darwin9.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34636
Product: gcc
Version: 4.2.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris at bubblescope dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34217
--
chris at bubblescope dot net changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32908
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris at bubblescope dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32908
--- Comment #2 from chris at bubblescope dot net 2007-07-26 19:41 ---
Ah, woops, many apologises. Too long since I've looked at list::size, I forgot
which way around libstdc++ differed from the rest of the world :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32907
libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris at bubblescope dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32907
1 - 100 of 213 matches
Mail list logo
