--- Comment #3 from chris at bubblescope dot net 2006-09-20 09:50 ---
Actually, I think deque could do with a better max_size.
Some tests:
vectorint v;
v.resize(v.max_size());
Throws bad_alloc.
dequeint v;
v.resize(v.max_size());
Bus errors.
This is on i686-apple-darwin8, 4.0.1
--- Comment #5 from chris at bubblescope dot net 2006-09-20 10:15 ---
The reason I bought this up here, is because I thought (and I could be wrong,
sorry) that the overflow was being caused by the fact that we allow the
container size to get too big, and if we pull max_size() down
--- Comment #8 from chris at bubblescope dot net 2006-09-20 11:10 ---
I agree also we can't do any better. On 64 bit systems it will be even harder
to give anything sensible.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29134
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=29593
--- Comment #1 from chris at bubblescope dot net 2006-11-03 15:00 ---
What exactly is the problem? It doesn't compile? It doesn't produce the right
output? It crashes?
--
chris at bubblescope dot net changed:
What|Removed |Added
: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris at bubblescope dot net
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20408
--
What|Removed |Added
Severity|normal |minor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20408
--- Additional Comments From chris at bubblescope dot net 2005-03-10 16:00
---
ignore my random changing of severity..
--
What|Removed |Added
Severity|minor
--- Additional Comments From chris at bubblescope dot net 2005-03-10 16:05
---
When you say has no effect in final code, are you talking about the problem
you noticed, or the problem as a whole?
I find for each extra X I add to the type of foo I get a line much like:
movb %al, 28(%esp
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris at bubblescope dot net
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20411
: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris at bubblescope dot net
CC: gcc-bugs at gcc dot gnu dot org
http
--- Additional Comments From chris at bubblescope dot net 2005-03-20 12:45
---
As soon as I've submitted this bug, I've found the documentation notes this
change.. I would still ask is there a way to get back the earlier behaviour?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris at bubblescope dot net
CC: gcc-bugs at gcc dot gnu dot org
http
: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris at bubblescope dot net
CC: gcc-bugs at gcc dot gnu dot org
http
--- Additional Comments From chris at bubblescope dot net 2005-03-20 13:02
---
Stupid webbrowser ¬_¬
*** This bug has been marked as a duplicate of 20564 ***
--
What|Removed |Added
--- Additional Comments From chris at bubblescope dot net 2005-03-20 13:02
---
*** Bug 20565 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20564
--- Additional Comments From chris at bubblescope dot net 2005-03-20 13:03
---
Stupid webbrowser ¬_¬
*** This bug has been marked as a duplicate of 20564 ***
--
What|Removed |Added
--- Additional Comments From chris at bubblescope dot net 2005-03-20 13:03
---
*** Bug 20566 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20564
--- Additional Comments From chris at bubblescope dot net 2005-03-21 10:14
---
(Hmm.. I thought I posted this before..)
My personal problem isn't the lines beginning zero, but the ones like:
function _Z3fooIiEiT_ called 1 returned 100% blocks executed 75%
Which before I had to turn
--- Additional Comments From chris at bubblescope dot net 2005-03-21 19:00
---
This program may make it a bit clearer what is going on :) (the problem is your
code I'm afraid, the compiler is fine)
#includelist
#includestdio.h
struct VAR {
VAR() {printf(VAR created\n);}
~VAR() {printf
--- Additional Comments From chris at bubblescope dot net 2005-03-29 19:19
---
A friend of mine was recently caught by this bug.. is there any chance it could
be fixed now? or is there still some problem holding it up (or just no-one
cares?). Although I am by no means certain, I imagine
--- Additional Comments From chris at bubblescope dot net 2005-04-19 10:19
---
Yup, just checked the standard, and it agrees with the code (not the comment).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21035
: unassigned at gcc dot gnu dot org
ReportedBy: chris at bubblescope dot net
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: apple-ppc-darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21271
--- Additional Comments From chris at bubblescope dot net 2005-05-01 10:08
---
Woops, false alarm, somehow I'd horribly, horribly messed up something. A clean
OS reinstall seems to
have cleared up this, and another unrelated problem. Sorry
--
What|Removed
--- Additional Comments From chris at bubblescope dot net 2005-05-08 12:18
---
Out of interest, where do the docs say that? (I'm not being sarcastic, just
interested)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21405
--- Additional Comments From chris at bubblescope dot net 2005-06-04 12:07
---
This is being held up by PR20408, Unnecessary code generated for empty structs,
as we'd have to pass
both the item to find and the comparitor (which is often an empty class) to
std::find_if
--- Additional Comments From chris at bubblescope dot net 2005-06-18 22:18
---
Actually, *slaps forehead*, the problem of empty structs can just be avoided
using EBO :) I'll knock up a patch doing just that :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21796
--- Additional Comments From chris at bubblescope dot net 2005-06-24 08:52
---
It's probably me being blind, but could you point out the part of the standard
which defines what should be happening?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22131
--- Comment #1 from chris at bubblescope dot net 2006-02-06 14:19 ---
Yep, these both look like fairly obvious errors to me.
--
chris at bubblescope dot net changed:
What|Removed |Added
--- Comment #1 from chris at bubblescope dot net 2006-05-10 11:31 ---
Can you provide a complete program which demonstrates this link? I've tried
looking at the code in question myself, and cannot observe a memory leak
myself.
--
chris at bubblescope dot net changed
--- Comment #7 from chris at bubblescope dot net 2006-06-23 15:33 ---
(In reply to comment #4)
Subject: Re: header dependencies
On Monday 19 June 2006 11:29, pcarlini at suse dot de wrote:
--- Comment #1 from pcarlini at suse dot de 2006-06-19 09:29
Ok, let's see what we
--- Comment #9 from chris at bubblescope dot net 2006-06-23 16:47 ---
I just tried preprocessing vector, as an example. There isn't any obvious
low-hanging fruit. The major problem is that most of the C standard libary ends
up getting dragged in.
I think a better goal would be to make
--- Comment #6 from chris at bubblescope dot net 2006-07-29 10:08 ---
My natural suspision would be that your clone() function is incorrectly
implemented. Can you show us the source to the CMessage object, and
theMessageFactory.createInstance(
)?
--
http://gcc.gnu.org/bugzilla
--- Comment #8 from chris at bubblescope dot net 2006-08-03 19:48 ---
One quick piece of advice. Have you tried compiling your entire application
against the libstdc++ debug mode? It might help narrow down where the problem
is.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27530
--- Comment #3 from chris at bubblescope dot net 2005-11-21 16:03 ---
While it does look like there might be an error in this warning code, I also
have a feeling we are doing something bad here. I looked at the examples in
stl_set.h and we are doing reference casting from
: 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=25137
--- Comment #2 from chris at bubblescope dot net 2005-11-28 15:17 ---
Thats an option too, but I thought I'd see about gcc's opinion first, as I
expected a much faster reply than I would get from the C++ steering committee
:)
I find the warning helpful for constructs like:
struct S
--- Comment #5 from chris at bubblescope dot net 2005-11-28 16:28 ---
I'll make a report. Don't worry, I'm clear on the difference between tr1::array
and a C array, I just wanted to check that we agree this should produce a
warning (in which case I will go through the tr1::array
--- Comment #6 from chris at bubblescope dot net 2005-11-28 16:33 ---
Actually, is a report really approriate? Writing arrayint,3 = {1,2,3} is
perfectly valid C++, just warned about with -Wmissing-braces
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25137
--- Comment #17 from chris at bubblescope dot net 2006-01-04 13:53 ---
Just as a quick note, I've personally got code using the non-void return value
of generate_n (because I'm going along a list, and didn't want to have to
incremement n steps after filling the list, as that would cost
--- Comment #2 from chris at bubblescope dot net 2006-01-10 10:37 ---
I'm unclear on why it should be convertable to one of the built-in integral
types at all.. surely saying that
iterator_traits_OutputIterator::difference_type (where _OutputIterator is the
first parameter
--- Comment #4 from chris at bubblescope dot net 2006-01-10 17:00 ---
For the record, I was thinking of:
templatetypename _OutputIterator, typename _Size, typename _Tp
_OutputIterator
fill_n(_OutputIterator __first, _Size __n, const _Tp __value
types
Product: gcc
Version: 4.2.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 2006-01-11 17:21 ---
This bug is fixed in 4.1 (and possibly 4.0, I don't have a copy). Is suspect it
isn't a serious enough bug to get the fix backported to 3.4 (although others
may know better than me)
--
http://gcc.gnu.org/bugzilla
--- Comment #3 from chris at bubblescope dot net 2006-01-17 18:09 ---
Does that patch break other systems? (linux-x86 would seem the obvious thing to
try..)
--
chris at bubblescope dot net changed:
What|Removed |Added
--- Additional Comments From chris at bubblescope dot net 2004-12-13 17:56
---
I'm fairly sure it's not a timeout (It takes 5 seconds to run on my computer).
It might be a dejagnu bug. Unfortunatly I find it very hard to find out exactly
what is causing this bug.
While I agree
Version: 4.0.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris at bubblescope dot net
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org
--- Additional Comments From chris at bubblescope dot net 2004-12-15 12:28
---
Also (stating the perhaps blindingly obvious), this bug is not being caused by
the fact that the loop contains a return statement.
int check(int* a,int *b)
{
int* returnval=b;
for(;ab;++a)
if(*a) returnval
--- Additional Comments From chris at bubblescope dot net 2004-12-18 19:20
---
I thought I'd post this here rather than as a new bug.. I will do if there isn't
a reply within a week or so.
A very similar regression is:
int check(int a,int b, char* c)
{
for(;a!=b;a+=4)
if(c[a]==1
ReportedBy: chris at bubblescope dot net
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19078
--- Additional Comments From chris at bubblescope dot net 2004-12-19 10:59
---
Sorry, I was testing for the existance of loop-unrolling by timing, rather than
looking at the code.
The compiler is unrolling the code I provided, but then optimised quite badly.
As this might
ReportedBy: chris at bubblescope dot net
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19246
at bubblescope dot net
CC: caj at cs dot york dot ac dot uk,gcc-bugs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19433
dot org
ReportedBy: chris at bubblescope dot net
CC: caj at cs dot york dot ac dot uk,gcc-bugs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19544
--- Additional Comments From chris at bubblescope dot net 2005-01-20 15:14
---
Heres another test-case...
#includealgorithm
struct ptr
{
int* a;
ptr() {}
};
struct foo
{
ptr array[1];
foo() { std::uninitalized_fill_n(array,1,ptr()); }
};
foo f;
Which shows it isn't limited
--- Additional Comments From chris at bubblescope dot net 2005-01-20 19:25
---
I never thought it was a bug in the library :)
I however throught (incorrectly) that copying an unassigned pointer was valid,
mainly as some other test case was considering constructing
std::vectorstd
--- Additional Comments From chris at bubblescope dot net 2005-01-28 14:53
---
I don't think this bug has anything to do with libstdc++ (which over covers
errors in the c++ standard library). I would suggest changing the Component to
c++, which I suspect a closer match for where the bug
--- Additional Comments From chris at bubblescope dot net 2005-02-08 13:24
---
Yep, that fixed it. Marking it as a dup.
*** This bug has been marked as a duplicate of 12096 ***
--
What|Removed |Added
--- Additional Comments From chris at bubblescope dot net 2005-02-08 13:24
---
*** Bug 18961 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From chris at bubblescope dot net 2004-10-26 15:30 ---
Yes, sorry, I was not aware of this convention.
I'm currently performing some general clean-up to the autogeneration of the
tuple header and will at the same time fix this. It's been suggested that _T
should
--- Additional Comments From chris at bubblescope dot net 2004-12-08 14:15
---
Heres a much smaller testcase which shows this bug:
#includestdio.h
class complex
{
public:
complex(long double r=0, long double i=0)
{
__real__ _M_value = r;
__imag__ _M_value = i
--- Additional Comments From chris at bubblescope dot net 2005-07-01 09:12
---
on 4.0.0, ppc-darwin I don't see this problem.
On x86-cygwin 3.4.4 I do, but I don't think it has anything to do with map, or
net, or anything.
Consider the following program below. It prints:
bat:bat
--
What|Removed |Added
CC||chris at bubblescope dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22265
--- Additional Comments From chris at bubblescope dot net 2005-07-01 09:47
---
After a little thought (sorry, should have done it before), this bug all comes
down to the order of
execution of function parameters, which I believe is undefined?
BTW, in case I wasn't clear enough
--- Additional Comments From chris at bubblescope dot net 2005-07-05 12:11
---
It seems to me that this is just a simple NAB. There seems to be 3 options
1) Just leave it as is
2) Alter list::remove so in debug mode it aborts if you give it an element from
the list
3) Alter list
--- Additional Comments From chris at bubblescope dot net 2005-07-25 07:46
---
Actually according to the TR1 spec (n1745 at least), there should be a
non-const version which returns an
iterator, and a const version which returns a const_iterator.
--
http://gcc.gnu.org/bugzilla
--- Additional Comments From chris at bubblescope dot net 2005-07-25 07:52
---
Apologises, I misread the problem. Ignore my previous comment. Yes, I agree
that find_node (which is a
private function) should be const. An identical problem exists calling
equal_range
--
http
--- Additional Comments From chris at bubblescope dot net 2005-07-25 09:03
---
I'm not personally 100% sure that this should be fixed, I've used partial_sum
where I've assumed this
behaviour, and adding the things in the output type would have broken...
I've attached the work-around
--- Additional Comments From chris at bubblescope dot net 2005-08-05 08:29
---
While it doesn't fix your bug, if you want a hash_map I'd advise looking at
tr1/unordered_map, which
I'd expect to work better. I think however you'll find that all implementations
of hash_map strictly
--- Additional Comments From chris at bubblescope dot net 2005-08-12 18:34
---
Yep, it's the extra template parameter which is confusing the compiler. If you
have parameters it can't
deduce from the input to a function, they must be given explicitly, so in this
case that function
: chris at bubblescope dot net
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23361
: chris at bubblescope dot net
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23362
--- Additional Comments From chris at bubblescope dot net 2005-08-12 18:58
---
Stupid webbrowser.
*** This bug has been marked as a duplicate of 23361 ***
--
What|Removed |Added
--- Additional Comments From chris at bubblescope dot net 2005-08-12 18:58
---
*** Bug 23362 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23361
--
What|Removed |Added
CC||chris at bubblescope dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23358
--- Additional Comments From chris at bubblescope dot net 2005-08-16 09:10
---
In the FAQ (4.4), things that only looks like bugs, mentions that libstdc++
isn't -Weffc++ clean.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23417
--
What|Removed |Added
CC||chris at bubblescope dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23417
ReportedBy: chris at bubblescope dot net
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23465
--- Additional Comments From chris at bubblescope dot net 2005-08-18 17:26
---
The following simple piece of code fails to compile.
#include tr1/unordered_set
int main(void)
{
std::tr1::unordered_setint i,j;
i = j;
}
The error is in fact in tr1/hashtable, and as all the unordered
--- Additional Comments From chris at bubblescope dot net 2005-08-30 15:35
---
While this behaviour is suprising, it is also not a bug. The problem comes from
the fact that
*(reverse_iterator(i)) = *(i-1), so when you dereference a reverse_iterator
the value you actually get is
from
--- Additional Comments From chris at bubblescope dot net 2005-08-30 20:16
---
Just so we are 100% clear on what is occuring (I realise it might not be
obvious from my message)
M.rbegin() returns an iterator i = std::reverse_iterator(M.end());
*i therefore returns *--(M.end
--- Additional Comments From chris at bubblescope dot net 2005-09-07 19:22
---
Hmm.. this is I believe a bug, but a very hard one to trigger.
1) This bug is very sensitive. It only occurs if the const_iterator member
function is const and the
iterator member function isn't
--
What|Removed |Added
CC||chris at bubblescope dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
--- Additional Comments From chris at bubblescope dot net 2005-09-07 20:06
---
You are right, I previously didn't think it was possible without adding some
more template parameters.
However, I should have known there is nothing you can't do with a few templates
:)
How about
--- Additional Comments From chris at bubblescope dot net 2005-09-07 20:39
---
Actually, __normal_iterator is what std::string uses for it's iterator class, so
we could be in trouble.
On the note of removing enable_if, my only other thought is something like:
templateclass _Iterator
--- Additional Comments From chris at bubblescope dot net 2005-09-07 20:51
---
I just tried adding a template parameter, and it does break things unfortunatly.
In an old file define something like:
void f(vectorint::iterator v) {..}
and then try to call it from a file that includes
--- Additional Comments From chris at bubblescope dot net 2005-09-07 21:07
---
Actually for inline functions, even with -fno-implicit-templates,
instansiations are still generated (I can
kind of see why. You could argue they shouldn't be, but they are)
--
http://gcc.gnu.org
--- Additional Comments From chris at bubblescope dot net 2005-09-15 13:32
---
I get the same bug on darwin8.2.0, with 768MB of ram
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22444
--- Additional Comments From chris at bubblescope dot net 2005-09-15 14:02
---
Expanding slightly, I tried the following 4 functions. All were removed by
-funsafe-loop-optimisations,
but only foo3 was removed by -O3 without -funsafe-loop-optimisations. I can't
see a good reason
: chris at bubblescope dot net
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23978
--- Additional Comments From chris at bubblescope dot net 2005-09-20 23:02
---
I'll have a closer look. I think not, as on my compiler boost::tie does work,
it's tr1::tie which doesn't.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23978
--- Additional Comments From chris at bubblescope dot net 2005-09-20 23:28
---
Nope, the code in PR 23896 works fine on my compiler.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23978
--- Additional Comments From chris at bubblescope dot net 2005-09-21 10:13
---
Could you provide the output of g++ -v, and the operating system you are using?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23990
--- Additional Comments From chris at bubblescope dot net 2005-09-21 11:01
---
Hopefully someone with more Solaris knowledge than me may come along (the code
works fine on any
OSes I can get my hands on)
As a temporary fix, you might find putting template class
char_traitswchar_t
--- Additional Comments From chris at bubblescope dot net 2005-09-22 10:49
---
Ah ha, found the problem. tuple has a copy constructor for std::pair, but not
an operator=(std::pair). It
should. I'll prepare a patch. While I'm at fixing this, there are quite a lot
of functions
--- Additional Comments From chris at bubblescope dot net 2005-09-26 13:42
---
I'm not convinced that this is valid code.. unless I'm missing something, you
are altering values inside the
hash table, which isn't allowed unless you change the values in such a way that
their hashed
--- Additional Comments From chris at bubblescope dot net 2005-09-26 13:47
---
Sorry, you are of course changing the second value, which is fine. It's the
first one you shouldn't change.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24064
--- Comment #1 from chris at bubblescope dot net 2006-12-13 18:07 ---
-O1 is enough to remove all advantages of this patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30203
--- Comment #1 from chris at bubblescope dot net 2006-12-13 18:08 ---
-O1 is enough to remove all advantages of this patch.
Also, that isn't really a fair timing comparison, as you've removed the
function call altogether (I still expect it to be faster, but possibly not by
10x
--- Comment #3 from chris at bubblescope dot net 2007-01-09 22:21 ---
The standard refers to (l+n)%size(), so if size()=0, that seems to be
undefined. On the other hand, it seems fairly obvious what should happen in
this case (ie nothing).
On an unrelated note, isn't there a another
1 - 100 of 213 matches
Mail list logo
