--- Comment #3 from paolo dot carlini at oracle dot com 2008-11-11 12:08
---
.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status
--- Comment #2 from paolo dot carlini at oracle dot com 2008-11-11 13:50
---
Ok.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo
--- Comment #3 from paolo dot carlini at oracle dot com 2008-11-11 14:33
---
Fixed for 4.4.0.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #4 from paolo dot carlini at oracle dot com 2008-11-11 12:48
---
I think the use of include_next started with Benjamin's patch of 2007-03-04,
adding c_global. Benjamin, can you look into this issue? Otherwise, missing a
solid rationale, for 4.4.0 I would just remov
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle
|dot org
--- Comment #5 from paolo dot carlini at oracle dot com 2008-11-12 10:12
---
May be related to libstdc++/38000...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #6 from paolo dot carlini at oracle dot com 2008-11-12 10:02
---
Fixed again.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #7 from paolo dot carlini at oracle dot com 2008-11-13 00:09
---
Fixed for 4.4.0.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #3 from paolo dot carlini at oracle dot com 2008-11-13 22:06
---
For sure nothing is going to happen in this area within the current ABI. In the
context of a future ABI (for C++1x) these traits will be used in a completely
different way, probably will not be used at all
--- Comment #2 from paolo dot carlini at oracle dot com 2008-11-15 09:42
---
To be clear, absolutely nothing changed lately in this area of the library.
Probably, it's just the well known brittleness of these ext/pb_ds testcases, or
a compiler issue.
--
http://gcc.gnu.org/bug
--- Comment #27 from paolo dot carlini at oracle dot com 2008-11-18 10:16
---
Isn't this a regression?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36902
--- Comment #30 from paolo dot carlini at oracle dot com 2008-11-18 15:25
---
Thanks Manuel. I'm not sure that this is technically a regression, but in any
case I consider it a serious problem and really hope we can have a fix for
4.4.0.
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #32 from paolo dot carlini at oracle dot com 2008-11-18 15:47
---
(In reply to comment #31)
> I submitted the patch long ago. We are in regressions-only mode. This is not a
> regression. Not sure what else you want me to do.
I'm not sure either ;) Maybe you coul
--- Comment #64 from paolo dot carlini at oracle dot com 2008-11-20 10:24
---
(assuming I understand correctly Jason' approach - didn't really follow in
detail the thread, lately) let me know if you want me to remove the
exception_defines.h tricks from the library...
--
--- Comment #2 from paolo dot carlini at oracle dot com 2008-11-20 13:42
---
Ok, let's do this.
--
paolo dot carlini at oracle dot com changed:
What|Removed |
--- Comment #4 from paolo dot carlini at oracle dot com 2008-11-20 16:02
---
Fixed for 4.4.0.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from paolo dot carlini at oracle dot com 2008-11-21 09:19
---
Yes.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo
--- Comment #3 from paolo dot carlini at oracle dot com 2008-11-21 10:00
---
Fixed for 4.4.0.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from paolo dot carlini at oracle dot com 2008-11-21 16:12
---
This is just a typo in the documentation: -fipa-matrix-reorg.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #4 from paolo dot carlini at oracle dot com 2008-11-21 16:23
---
Fixed for 4.3.3 and mainline.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from paolo dot carlini at oracle dot com 2008-11-21 16:30
---
This is correctly rejected without ICE by any modern-era, maintained, GCC.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #6 from paolo dot carlini at oracle dot com 2008-11-23 14:01
---
(In reply to comment #5)
> Apparently the failures I have reported in comment #4 disappear if I rebuild
> libstdc++.
Not surprising ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38210
--- Comment #3 from paolo dot carlini at oracle dot com 2008-11-24 10:21
---
This is essentially a defect in DR 778:
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778
I'll see what we can do for now.
--
paolo dot carlini at oracle dot com ch
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Summary|bitset initialization from 0|[4.4 Regression] bitset
|rejected
--- Comment #3 from paolo dot carlini at oracle dot com 2008-11-24 11:10
---
The default constructor of pair just implements DR 265, this is *very* old:
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#265
This is possibly a C++ front-end issue, because lately nothing
--- Comment #5 from paolo dot carlini at oracle dot com 2008-11-24 11:15
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from paolo dot carlini at oracle dot com 2008-11-24 14:55
---
*** Bug 38238 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from paolo dot carlini at oracle dot com 2008-11-24 14:55
---
The problem is the rvalue (2)
*** This bug has been marked as a duplicate of 35569 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from paolo dot carlini at oracle dot com 2008-11-25 19:48
---
Unless I'm badly mistaken, this behaviour, dating back to the original HP/SGI
STL and as such very difficult to change now, is a small extension due to the
use in the containers of _Construct inste
--- Comment #4 from paolo dot carlini at oracle dot com 2008-11-26 09:39
---
The below is a pure C++ testcase, which EDG accepts and mainline rejects. Jason
can you look a bit into it? Thanks in advance!
template
struct pair
{
_T1 first;
_T2 second
--- Comment #1 from paolo dot carlini at oracle dot com 2008-11-26 09:48
---
Is this related to middle-end/36902?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38275
--- Comment #6 from paolo dot carlini at oracle dot com 2008-11-26 16:12
---
(In reply to comment #4)
> I know my gcc is very old. I will try to compile the newest version and send
> the results.
Ok.
--
paolo dot carlini at oracle dot com changed:
What|R
--- Comment #5 from paolo dot carlini at oracle dot com 2008-11-26 16:11
---
Are you aware of the fact that GCC 4.0.x is no longer maintained? You should
try again with a current compiler, in the current 4.3.x release series or at
least 4.2.x.
--
http://gcc.gnu.org/bugzilla
--- Comment #4 from paolo dot carlini at oracle dot com 2008-11-28 10:50
---
Yes, this is obvious, just grep for _Construct.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38265
--- Comment #8 from paolo dot carlini at oracle dot com 2008-11-28 11:30
---
The issue is different because if I remove all uses of _Construct and implement
the various uninitialized_* per the letter of the Standard, nothing changes...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #9 from paolo dot carlini at oracle dot com 2008-11-28 11:40
---
... and I'm coming to the conclusion that this is not a bug in our library.
Consider the std::vector case: I cannot see anything wrong with using
std::uninitialized_copy in the implementation o
--- Comment #6 from paolo dot carlini at oracle dot com 2008-11-28 11:17
---
Hummm, the issue seems different than I remembered it. Will see..
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38265
--- Comment #5 from paolo dot carlini at oracle dot com 2008-11-28 11:03
---
But I see now that al long time ago list & co also used _Construct, this is
indeed an inconsistency... Let's see what we can do here...
--
paolo dot carlini at oracle dot com changed:
--- Comment #1 from paolo dot carlini at oracle dot com 2008-11-28 15:11
---
*** This bug has been marked as a duplicate of 14410 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #8 from paolo dot carlini at oracle dot com 2008-11-28 15:11
---
*** Bug 38304 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #10 from paolo dot carlini at oracle dot com 2008-11-28 15:21
---
Please refer to the resolution of DR 103, which we are implementing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14410
--- Comment #1 from paolo dot carlini at oracle dot com 2008-11-28 16:57
---
Duplicate of PR 10690? (by the way, I cannot reproduce the ICE with FSF
4_3-branch and mainline, I'm seeing the "address of overloaded function with no
contextual type information" error instea
--- Comment #12 from paolo dot carlini at oracle dot com 2008-11-29 17:05
---
Subject: Re: STL treats explicit constructors as converting constructors
> The Standard does not require that std::uninitialized_copy be
> invoked when
> constructing an std::vector or...
--- Comment #1 from paolo dot carlini at oracle dot com 2008-12-01 10:34
---
Certainly nothing to do with the C++ runtime library.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #3 from paolo dot carlini at oracle dot com 2008-12-02 10:59
---
Fixed for 4.4.0.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #5 from paolo dot carlini at oracle dot com 2008-12-02 13:21
---
(In reply to comment #4)
> Your patch fixes the problem at the level of the locale constructor, but why
> do
> not fix this problem at the level of _M_replace_categories() instead?
Because that
--- Comment #6 from paolo dot carlini at oracle dot com 2008-12-02 13:34
---
(In reply to comment #5)
> (In reply to comment #4)
> > Your patch fixes the problem at the level of the locale constructor, but
> > why do
> > not fix this problem at the level of
--- Comment #1 from paolo dot carlini at oracle dot com 2008-12-02 09:53
---
Ok.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo
--- Comment #1 from paolo dot carlini at oracle dot com 2008-12-03 10:34
---
This sort-of inconsistency is essentially due to the glibc specifics (+ the
fact that we are dealing separately with "C" locale) see the below GNU C
snippet. In particular, note in numeric_members.
--- Comment #2 from paolo dot carlini at oracle dot com 2008-12-03 10:46
---
Or maybe we should just report the __MON_DECIMAL_POINT == '\0' thing to glibc,
which seems special to me (THOUSANDS_SEP == '\0' is well known, on the other
hand).
--
http://
--- Comment #4 from paolo dot carlini at oracle dot com 2008-12-03 17:15
---
Ok, let's try to enforce this kind of consistency.
--
paolo dot carlini at oracle dot com changed:
What|Removed |
--- Comment #1 from paolo dot carlini at oracle dot com 2008-12-04 15:11
---
Ok.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo
--- Comment #2 from paolo dot carlini at oracle dot com 2008-12-04 16:08
---
(In reply to comment #0)
> use_facet >(loc).get(ss, 0, false, ss, err, digits);
>
> string rest(istreambuf_iterator(ss), istreambuf_iterator());
Fixing this issue is trivial, but please
--- Comment #6 from paolo dot carlini at oracle dot com 2008-12-04 17:19
---
Fixed for 4.4.0.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #4 from paolo dot carlini at oracle dot com 2008-12-05 08:24
---
Are you using the same glibc on x86_64 and ia64? The two failing testcases
(cons/7.cc and members/char/2.cc, the other are implied) are essentially the
same: something is different on that ia64 machine about
--- Comment #6 from paolo dot carlini at oracle dot com 2008-12-05 08:47
---
Yes, I'm not sure is the same issue. Anyway, the problem can only be in this
idea:
_M_data->_M_thousands_sep = *(__nl_langinfo_l(THOUS
--- Comment #7 from paolo dot carlini at oracle dot com 2008-12-05 08:50
---
By the way, yes the fr_FR locale is heavily used in those tests...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38411
--- Comment #8 from paolo dot carlini at oracle dot com 2008-12-05 08:55
---
I suspect in the localedata of fr_FR, the thousands separator may have changed
in some glibc from ' ' (0x20) to '\0'. Jakub can you confirm that?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38411
--- Comment #11 from paolo dot carlini at oracle dot com 2008-12-05 09:16
---
(In reply to comment #9)
> Forcing "," thousands separator when none should be used is very weird.
Is the same "C" locale has. We only want consistency, see 38368.
Does
>
--- Comment #12 from paolo dot carlini at oracle dot com 2008-12-05 09:17
---
(In reply to comment #10)
> To reply to #c8, it changed the other way around, from "" to "" in
> April
> 2008. But as I said, Fedora 9, which shipped glibc 2.9, was backing o
--- Comment #14 from paolo dot carlini at oracle dot com 2008-12-05 09:42
---
(In reply to comment #13)
> If _M_thousands_sep must be a single _CharT, then for I guess you
> should
> transliterate it if the string is longer than one character.
> Either by using glibc tra
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle
|dot org
--- Comment #16 from paolo dot carlini at oracle dot com 2008-12-05 09:51
---
(In reply to comment #15)
> Well, if you take first byte from a multibyte sequence, then it is IMNSHO
> something that should be solved for 4.4 too. For say ru_RU.UTF-8 that means
> you emit invalid
--- Comment #17 from paolo dot carlini at oracle dot com 2008-12-05 09:54
---
Created an attachment (id=16831)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16831&action=view)
Draft
Draft patch using is_IS instead of fr_FR.
--
http://gcc.gnu.org/bugzilla/show_bug
--- Comment #18 from paolo dot carlini at oracle dot com 2008-12-05 09:55
---
HJ, can you test it and report? Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38411
--- Comment #4 from paolo dot carlini at oracle dot com 2008-12-05 09:59
---
(In reply to comment #3)
> Thanks for remark.
You are welcome. By the way, since in general you are so kind to report very
accurate and to the point issues, I would appreciate if you could also add
testca
--- Comment #21 from paolo dot carlini at oracle dot com 2008-12-05 13:09
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #6 from paolo dot carlini at oracle dot com 2008-12-05 18:25
---
Fixed for 4.4.0.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from paolo dot carlini at oracle dot com 2008-12-06 10:22
---
Let's take care of this.
--
paolo dot carlini at oracle dot com changed:
What|Removed |
--- Comment #3 from paolo dot carlini at oracle dot com 2008-12-06 10:27
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #13 from paolo dot carlini at oracle dot com 2008-12-11 15:37
---
Hi HJ: I'm not sure to understand, you mean this is actually a C++ / compiler
bug?!?
--
paolo dot carlini at oracle dot com changed:
What|Removed |
--- Comment #16 from paolo dot carlini at oracle dot com 2008-12-11 16:17
---
At the moment, I don't know this code well enough, but note that:
typedef const pair & const_pair_reference;
therefore, I don't really follow your reasoning. By the way, rvalrefs I don&
--- Comment #1 from paolo dot carlini at oracle dot com 2008-12-11 16:12
---
Hi. Given the specifications for uflow() (27.5.2.4.3/16), I don't see how this
code can work because I don't think *gptr() can work in this unbuffered case.
Can you explain in better detail wh
--- Comment #17 from paolo dot carlini at oracle dot com 2008-12-11 16:39
---
In any case, I don't really understand your snippet: you are comparing &x.i to
&t1.i, but x comes from p, and p *copies* t1 at construction time, in other
terms &p.first.i != &t1.i to beg
--- Comment #22 from paolo dot carlini at oracle dot com 2008-12-11 18:13
---
Therefore, are you coming to the conclusion that something in the testing
infrastructure is wrong (mismatched types), *not* in the ext/pb_ds code itself?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #27 from paolo dot carlini at oracle dot com 2008-12-11 18:55
---
Ah, yes, that, I saw it some time ago. Thus, the patch you and John are testing
(which makes sense, first blush) avoids failures in normal mode, but in fact
another, latent, issue is uncovered in DEBUG_MODE
--- Comment #10 from paolo dot carlini at oracle dot com 2008-12-11 20:04
---
(In reply to comment #9)
> So, either IMHO we should cast to bool there, or as done in this patch
> use __traitor instead.
For the branch, I pre-approve a patch adding and using __traitand.
--
--- Comment #3 from paolo dot carlini at oracle dot com 2008-12-12 11:10
---
Can you explain in better detail which aliasing issues you are seeing in
_Rb_tree_impl (per Comment #1)? At line 530 I cannot see anything obviously
wrong: a pointer to the base is casted to the derived type
--- Comment #5 from paolo dot carlini at oracle dot com 2008-12-12 11:39
---
Sorry, but I still do not understand: __x (a const _Rb_tree_node_base *) is
casted to _Const_Link_type (a const _Rb_tree_node<_Val> *) before the access,
then of course an _M_value_field esists. By t
--- Comment #7 from paolo dot carlini at oracle dot com 2008-12-12 11:53
---
(In reply to comment #6)
> But there is no space for _Rb_tree_node<_Val> in ctx.foo._M_t._M_impl.
>
> struct _Rb_tree_impl : public _Node_allocator
> {
>
--- Comment #1 from paolo dot carlini at oracle dot com 2008-12-14 11:59
---
Can't reproduce the ICE with current (142748) mainline:
38524.C:1: warning: non-local variable A uses anonymous
type
38524.C: In function int main():
38524.C:1: error: E is not a class or namespac
--- Comment #28 from paolo dot carlini at oracle dot com 2008-12-15 18:42
---
*** Bug 38531 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from paolo dot carlini at oracle dot com 2008-12-15 18:42
---
*** This bug has been marked as a duplicate of 6257 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #3 from paolo dot carlini at oracle dot com 2008-12-15 18:50
---
By the way, in gcc4.3.x (and 4.4.x of course), is not included
anymore by as an implementation detail (it could, it's allowed by
Standard), thus this specific issue is strictly speaking moot now. But
--- Comment #6 from paolo dot carlini at oracle dot com 2008-12-17 17:38
---
The __swap_impl idea makes sense but note that user code can tell it from the
"standard" one when something throws. All in all, given that C++0x will be Ok
wrt these issues, I'm not sure we
--- Comment #9 from paolo dot carlini at oracle dot com 2008-12-17 17:21
---
Benjamin, any feedback on this? Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36801
--- Comment #1 from paolo dot carlini at oracle dot com 2008-12-17 15:31
---
*** This bug has been marked as a duplicate of 38552 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from paolo dot carlini at oracle dot com 2008-12-17 15:31
---
*** Bug 38555 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38552
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38596
--- Comment #1 from paolo dot carlini at oracle dot com 2008-12-21 15:06
---
Note, the use of typeid (and type_info) is explicit in the specifications, thus
the only solution I can see for -fno-rtti is not providing at all (ifdef-ing
out) function::target and target_type. If submitter
--- Comment #3 from paolo dot carlini at oracle dot com 2008-12-21 15:40
---
Ok, let's do this. Worst case, something will be unnecessarily broken with
-fno-rtti, but certainly nothing which is not broken already ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38596
--- Comment #5 from paolo dot carlini at oracle dot com 2008-12-21 15:58
---
Done.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Target
--- Comment #6 from paolo dot carlini at oracle dot com 2008-12-21 15:58
---
Yes.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status
--- Comment #2 from paolo dot carlini at oracle dot com 2008-12-21 18:21
---
First, you should check if the problem still happens with a maintained branch
of GCC (neither 4.1.x nor 4.2.x are maintained anymore).
--
paolo dot carlini at oracle dot com changed:
What
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38476
--- Comment #1 from paolo dot carlini at oracle dot com 2008-12-26 17:40
---
In any case, why you are so sure the problem is due to libstdc++ and not
libgcc_s?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38631
--- Comment #3 from paolo dot carlini at oracle dot com 2008-12-26 23:05
---
Bah, for sure we need a reduced testcase anyway, I have no idea what to do with
this report, otherwise.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38631
--- Comment #4 from paolo dot carlini at oracle dot com 2008-12-27 00:33
---
... by the way, before anything else, I think you should confirm that the
software works fine if built with current mainline.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38631
--- Comment #2 from paolo dot carlini at oracle dot com 2008-12-27 09:21
---
To clarify: I don't see anything in the Standard forbidding the use of
rdbuf()->sgetn in the implementation of istream::read. Actually, I would argue
is the natural choice for carrying out the core wo
1 - 100 of 2575 matches
Mail list logo
