--- Comment #8 from pcarlini at suse dot de 2006-06-05 06:18 ---
Agreed, let's close it.
--
pcarlini at suse dot de changed:
What|Removed |Added
S
--- Comment #1 from pcarlini at suse dot de 2006-10-07 17:03 ---
This a well known not a bug (I'm sure similar issues are discussed in the
mailing list, also user code implementing char <-> char conversions via iconv):
output to UTF-8 is done by wchar_t streams (thus, for exa
--- Comment #2 from pcarlini at suse dot de 2006-10-07 17:28 ---
Forgot to add: after having properly switched to a wchar_t stream, we must make
sure that it actually does the conversion: the clean solution via std::codecvt
is used by default only in converting streams (file streams
--- Comment #3 from pcarlini at suse dot de 2006-10-07 19:47 ---
Reopen...
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|RESOLVED
--- Comment #4 from pcarlini at suse dot de 2006-10-07 19:48 ---
... to mark it as duplicate.
*** This bug has been marked as a duplicate of 16006 ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #5 from pcarlini at suse dot de 2006-10-07 19:48 ---
*** Bug 29379 has been marked as a duplicate of this bug. ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #6 from pcarlini at suse dot de 2006-10-08 11:04 ---
Let's reopen this report as an enhancement request. In fact, we should
implement this:
http://gcc.gnu.org/ml/libstdc++/2004-06/msg00256.html
probably by using iconv to implement the relevant char <
--- Additional Comments From pcarlini at suse dot de 2005-09-07 10:55
---
Fixed for 4.1.0.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From pcarlini at suse dot de 2005-09-12 19:59
---
Benjamin, can you also check, say, std::set? After all the PR is about
stl_tree.h... ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23417
--- You are receiving this mail because: ---
You reported
--- Comment #71 from pcarlini at suse dot de 2005-10-21 11:40 ---
(In reply to comment #70)
> whats the status of the patch? can we at least have the visibility push/pop
> patch for libstdc++ in gcc 4.0.x branch?
See comment #63: at this stage changing libstdc++ is poi
--- Comment #73 from pcarlini at suse dot de 2005-10-24 09:14 ---
(In reply to comment #72)
> why is it pointless? just because it doesn't work on some target architectures
> doesn't mean it doesn't work on most main archs.
Are you really, really, sure that withou
--- Comment #75 from pcarlini at suse dot de 2005-10-25 15:44 ---
(In reply to comment #74)
> furthermore I manually added push/pop macros to libstdc++ headers on a debian
> system (which is broken regarding visibility support) and it made my testcase
> pass.
To be clea
--- Comment #77 from pcarlini at suse dot de 2005-10-31 16:59 ---
Thanks Benjamin! Indeed, if you want to take care of this entire issue, you
are welcome (just reassign)! In any case, I'm not sure whether it's suited
for 4.1, at this point...
--
http://gcc.gnu.or
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|pcarlini at suse dot de |unassigned at gcc dot gnu
--- Comment #82 from pcarlini at suse dot de 2005-11-01 02:21 ---
To clarify: I have unassigned myself from this bug because I don't consider
myself sufficiently competent in this area to evaluate all the possible trade-
offs of the issue and don't want to block in any way t
--- Comment #2 from pcarlini at suse dot de 2005-12-14 23:09 ---
Ok, thanks. Seems a long standing but rather simple issue.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #6 from pcarlini at suse dot de 2005-12-15 10:24 ---
Fixed for 4.0.3.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--
pcarlini at suse dot de changed:
What|Removed |Added
Summary|[4.1 Regression] wrong final|[4.1 Regression] wrong final
|value of indaction variable
--
pcarlini at suse dot de changed:
What|Removed |Added
CC||pcarlini at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16006
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org
--- Comment #4 from pcarlini at suse dot de 2007-01-13 12:25 ---
Fixed for 4.2.0.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #18 from pcarlini at suse dot de 2007-01-30 00:34 ---
Implementing the really trivial solution of providing what() members returning
"std::bad_alloc", "std::bad_cast", "std::bad_typeid", and "std::bad_exception".
--
pcarlini
--- Comment #20 from pcarlini at suse dot de 2007-01-30 00:58 ---
(In reply to comment #19)
> I don't think that is the correct solution as if you subclass these functions,
> you get the incorrect result.
What do you mean by "incorrect"?!? If you subclass, either
--- Comment #22 from pcarlini at suse dot de 2007-01-30 01:42 ---
(In reply to comment #21)
> I suspect Andrew Pinski's point might be that what() could return a
> string that represents the name of the most derived type of the
> exception. But, nothing so far forces
--- Comment #24 from pcarlini at suse dot de 2007-01-30 02:21 ---
(In reply to comment #23)
> From consistency point of view I would say that the change should also
> be done for std::exception.
Right.
> However, the use of typeid is very convenient in the sense that we
--
pcarlini at suse dot de changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493
--- You are
--- Comment #29 from pcarlini at suse dot de 2007-02-01 15:58 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from pcarlini at suse dot de 2007-04-20 08:50 ---
I will check, but I don't think this can possibly happen in mainline, after we
fixed c++/30500. Otherwise, the underlying issue is libstdc++/19495, of course.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--- Comment #3 from pcarlini at suse dot de 2007-04-22 01:19 ---
In fact, the problem cannot be reproduced on ia64, with current mainline. I
agree that the warning can be very annoying (the underlying issue was already
there before 4.0 and will be there until we break the ABI
--- Comment #6 from pcarlini at suse dot de 2007-04-23 13:35 ---
(In reply to comment #5)
> It is OK with me.
Ok, excellent. For 4_2-branch we have a nuisance, in that the original testcase
involves -Wconversion which in that branch does nothing in C++. Thus I tested
on ia64-linux
--- Comment #7 from pcarlini at suse dot de 2007-04-23 13:36 ---
Created an attachment (id=13430)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13430&action=view)
Patch for 4_2-branch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31638
--- You are receiving th
--- Comment #8 from pcarlini at suse dot de 2007-04-24 23:39 ---
Problem solved in 4_2-branch too via fixing C++/30500. Nothing will be done in
older branches.
--
pcarlini at suse dot de changed:
What|Removed |Added
--
pcarlini at suse dot de changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31638
--- You are
--- Comment #1 from pcarlini at suse dot de 2007-06-25 23:03 ---
Whatever it is, it isn't a libstdc++ proper issue: the 4_1-branch is in deep
regressions-only mode, only very few commits to the breanch during the last 6+
months, nothing related to that issue (just have a look t
--- Comment #2 from pcarlini at suse dot de 2007-06-25 23:13 ---
And of course a normally installed and configured recent 4_1-branch gcc
(20070619) compiles the provided snippet just fine. The symbol is exported as
expected:
000ad570 T std::numpunct::_M_initialize_numpunct
--- Comment #3 from pcarlini at suse dot de 2007-06-25 23:27 ---
Sorry, disregard my remark between parentheses about 4.1 headers vs 4.2
library, I didn't follow your way of explaining your setup: yes, actaully, a
4.1 object *can* be linked to a 4.2 *.so. In any case, certainl
--- Comment #5 from pcarlini at suse dot de 2007-06-26 23:44 ---
Yes, today, while offline, I realized that in fact the real issue here was the
fix for 31717 not completely ok for everyone. And we already got a report of
this type before (upon it I decided to clarify the documentation
--- Comment #6 from pcarlini at suse dot de 2007-06-28 10:22 ---
Ok, I'm implementing the idea.
--
pcarlini at suse dot de changed:
What|Removed |
--- Comment #10 from pcarlini at suse dot de 2007-06-28 23:04 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Target Milestone
--- Comment #11 from pcarlini at suse dot de 2007-07-02 14:27 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--
pcarlini at suse dot de changed:
What|Removed |Added
Summary|g++ fails to recognize ill- |g++ fails to recognize ill-
|formed-ness of initilaizers
--- Additional Comments From pcarlini at suse dot de 2004-08-05 14:37
---
Implementing the trivial fix...
--
What|Removed |Added
AssignedTo|unassigned at gcc dot
--- Additional Comments From pcarlini at suse dot de 2004-08-05 15:00
---
... actually, not so trivial, because of the need to free the memory allocated
by __cxa_demangle :(
By the way, current Icc doesn't demangle anymore.
--
What|Removed |
--
What|Removed |Added
CC||pcarlini at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3713
--- You are receiving this mail
--- Additional Comments From pcarlini at suse dot de 2005-05-02 13:32
---
*** This bug has been marked as a duplicate of 21334 ***
--
What|Removed |Added
--- Additional Comments From pcarlini at suse dot de 2005-05-22 09:15
---
Gaby, can you have a look? It seems to me that we should use the same approach
used in std_cmath.h for fpclassify & co. In particular, when _GLIBCXX_USE_C99
is defined - that explicitly checks for llabs and l
--- Additional Comments From pcarlini at suse dot de 2005-05-22 09:32
---
Same for strt* and the other functions. Also we should remember to add to the
acinclude check for c99_stdlib the functions strtoll and strtoull, currently
missing.
(PS. In the meanwhile, done a minimal check that
--- Additional Comments From pcarlini at suse dot de 2005-05-22 21:20
---
Actually, I have a much better idea, that I'm testing right now: no need for
complex template-based tricks (in this case, at variance with the case of
classification macros, we *know* the type of the argu
--- Additional Comments From pcarlini at suse dot de 2005-07-04 23:42
---
... alternately, one we really care about, performance-wise, could be distilled
from libstdc++-v3/testsuite/performance/27_io/fmtflags_manipulators.cc...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3713
--- Additional Comments From pcarlini at suse dot de 2004-04-25 11:12
---
Not a bug. According to Table 92 of the ISO Standard, the 'out' openmode is
the equivalent of stdio "w", that is a new file is created or an old one is
truncated. In other words, 'out'
--- Additional Comments From pcarlini at suse dot de 2004-06-15 09:56
---
Not a bug. At the end of the first call of operator>> the eofbit is set in s.
Then, at the beginning of the second operator>> the sentry finds eofbit set and
the whole input operation fails: i remain
51 matches
Mail list logo
