--- Comment #14 from pcarlini at suse dot de 2005-11-18 15:32 ---
I'm not sure that specific patch is the culprit, because (see Comment #5) the
threaded testcases started failing before that date. I would like to see the
assembly before and after that date. In any case, it would be
--- Comment #17 from pcarlini at suse dot de 2005-11-18 23:41 ---
(In reply to comment #16)
> Alex's explanation can't be all of it. I hacked the compiler to emit two
> "mf" instructions before and after the sequence here, and it made no
> difference to the
--- Comment #19 from pcarlini at suse dot de 2005-11-19 01:05 ---
Created an attachment (id=10287)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10287&action=view)
Slightly hacked, self contained test (for use outside the testsuite)
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #20 from pcarlini at suse dot de 2005-11-19 01:06 ---
Created an attachment (id=10288)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10288&action=view)
Slightly hacked, self contained test (for use outside the testsuite)
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #21 from pcarlini at suse dot de 2005-11-19 01:08 ---
Just in case, those are ready to use outside the testsuite... For me,
especially
the second one, fails very quickly and consistently on 4-way and 16-way.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24757
--- Comment #24 from pcarlini at suse dot de 2005-11-19 02:15 ---
(In reply to comment #23)
> Created an attachment (id=10289)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10289&action=view) [edit]
> mf hack
>
> For the record, here's the aforementioned
--- Comment #25 from pcarlini at suse dot de 2005-11-19 02:33 ---
(In reply to comment #23)
> And it does appear to change the behaviour of one of the testsuite tests,
> but it doesn't fix both of them. I'll claim, then, that it didn't fix either
> of them
--- Comment #26 from pcarlini at suse dot de 2005-11-19 22:12 ---
Created an attachment (id=10297)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10297&action=view)
Reduced from thread/pthread3
Richard, I'm attaching a really minimal testcase, which fails very quickly
--- Comment #28 from pcarlini at suse dot de 2005-11-19 22:45 ---
Thanks Richard G. In fact, from time to time I saw warnings on the shell,
which really puzzled me, because I was sure that no alignment issues were
present anymore in the higher lever library code proper.
I'll try t
--- Comment #29 from pcarlini at suse dot de 2005-11-19 23:02 ---
(In reply to comment #28)
> I'll try to add an alignment attribute to the _Atomic_word typedef, as cris
> is already doing for instance, and see whether something changes for the
> better.
Nope. Maybe th
--- Comment #30 from pcarlini at suse dot de 2005-11-19 23:06 ---
Created an attachment (id=10298)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10298&action=view)
Further reduced, pure C
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24757
--- Comment #2 from pcarlini at suse dot de 2005-11-20 13:37 ---
(In reply to comment #1)
> There is no "correct" output when you use a variable uninitialized. It's
> undefined behavior. Printing any number, or crashing, would be completely
> valid behaviors as
--- Comment #31 from pcarlini at suse dot de 2005-11-21 10:40 ---
(In reply to comment #30)
> Created an attachment (id=10303)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10303&action=view) [edit]
> Defines __cplusplus to 199711L and overrides it in c++config.h for
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|uros at kss-loka dot si |unassigned at gcc dot gnu
--- Comment #17 from pcarlini at suse dot de 2005-11-21 11:34 ---
Sorry.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot
--- Comment #35 from pcarlini at suse dot de 2005-11-21 13:35 ---
(In reply to comment #34)
> I attached a patch containing Paolo's suggestions.
Thanks. Looks fine to me. If Eric could test it on his Solaris machines it
would be great (remember the svn copy! ;) ...
Before
--- Comment #38 from pcarlini at suse dot de 2005-11-21 15:22 ---
(In reply to comment #37)
> > Yes, please *heavily* comment.
>
> If this is approved, someone could do the copy on the relevant branches, then
> I'd send a patch with better comments and changelog to
--- Comment #4 from pcarlini at suse dot de 2005-11-21 16:05 ---
Thanks. I'm looking into the issue. The part involving set seems to me much
more
critical and hopefully solvable without breaking the ABI, because we are not
exporting anything from the library involving set/multis
--- Comment #5 from pcarlini at suse dot de 2005-11-21 16:09 ---
One more bit of info (meant for Chris too): I think the cast has been added
when
set was changed to have both iterator and const_iterator as const iterator
types.
Since we are not exporting anything, I suppose we can fix
--- Comment #6 from pcarlini at suse dot de 2005-11-21 16:28 ---
Actually, to be 100% safe wrt binary compatibility (addresses, etc.) we can
also overload for _Rb_tree::const_iterator the involved _Rb_tree functions,
I'm preparing a patch.
--
http://gcc.gnu.org/bug
--- Comment #7 from pcarlini at suse dot de 2005-11-21 17:55 ---
Created an attachment (id=10314)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10314&action=view)
Draft for the set/multiset issue
Richard, can you see if the miscompilation goes away with the attached? In
--- Comment #8 from pcarlini at suse dot de 2005-11-21 19:49 ---
Another thing, about the basic_string warning: in order to figure out whether
that cast is really creating problems, you can add
--enable-fully-dynamic-string: with it the problematic code is not used at all.
(as I
--- Comment #11 from pcarlini at suse dot de 2005-11-21 23:02 ---
(In reply to comment #10)
> The patch_draft_24975 alone fixed it. Looks like libstdc++ needs some
> auditing for aliasing issues...
Indeed it does, but I expect that nothing is in a shape worse than basic_strin
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org
--- Comment #12 from pcarlini at suse dot de 2005-11-21 23:07 ---
(In reply to comment #10)
> The patch_draft_24975 alone fixed it. Looks like libstdc++ needs some
> auditing
> for aliasing issues...
By the way, for your curiosity, I digged a bit and the set issue was alre
--- Comment #16 from pcarlini at suse dot de 2005-11-22 15:17 ---
(In reply to comment #15)
> So that leaves us with basic_string and it's problems. What do you suggest to
> vendors needing ABI compatibility?
I'm still trying to figure out whether we can do something
--- Comment #17 from pcarlini at suse dot de 2005-11-22 16:14 ---
(In reply to comment #15)
> So that leaves us with basic_string and it's problems. What do you suggest to
> vendors needing ABI compatibility?
Richard, something we *can* safely apply (safely from the ABI po
--- Comment #19 from pcarlini at suse dot de 2005-11-22 16:59 ---
(In reply to comment #18)
> Well, yes. That would at least silence the warning (which would be annoying,
> if we apply the C++ warning patch).
It would be more than annoying, it would be awful, because would b
--- Comment #20 from pcarlini at suse dot de 2005-11-22 18:00 ---
An observation: while I don't know all the details of current GCC alias
analysis, I'm fairly optimistic that this specific issue with basic_string is
not serious. The reason is that _S_empty_rep_storage, of wh
--- Comment #2 from pcarlini at suse dot de 2005-11-25 23:31 ---
More interesting work to do:
http://gcc.gnu.org/ml/libstdc++/2005-11/msg00241.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24693
--- Comment #22 from pcarlini at suse dot de 2005-11-27 02:10 ---
I think we can close the PR now: the miscompilation is fixed and some tricks in
basic_string are well known (and not present in ext/vstring.h and basic_string
in v7-branch).
--
pcarlini at suse dot de changed
--- Comment #39 from pcarlini at suse dot de 2005-11-29 10:24 ---
Eric, I'm sorry, any news?!? Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
--- Comment #41 from pcarlini at suse dot de 2005-11-29 14:00 ---
Ok, agreed. I'm eager to finally close the oldest open libstdc++ PR... ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
--- Comment #3 from pcarlini at suse dot de 2005-12-02 17:40 ---
Created an attachment (id=10391)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10391&action=view)
Trivial testcase
Hi. I'm attaching a trivial testcase (*). In fact, I consider this bug pretty
serious!
--- Comment #4 from pcarlini at suse dot de 2005-12-02 17:50 ---
Sorry. Actually the testcase is not correct stand-alone, fails at line 13. I'm
currently checking whether is correct when the testsuite support (memory
limits) is present.
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #5 from pcarlini at suse dot de 2005-12-02 17:51 ---
... possibly using a "real" memory allocation, touching all the involved pages.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24025
--- Comment #6 from pcarlini at suse dot de 2005-12-02 18:02 ---
Created an attachment (id=10392)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10392&action=view)
Puzzling testcase...
Humm, strange. The new testcase *passes*... Still, the original analysis makes
a lot of s
--- Comment #7 from pcarlini at suse dot de 2005-12-02 18:07 ---
Ah! Now I see, it's because of Benjamin and Ulrich recent changes, involving
thread local storage. Therefore my amended testcase proposal should be fine on
platforms not defining _GLIBCXX_HAVE_TLS. We should check
--- Comment #8 from pcarlini at suse dot de 2005-12-02 18:13 ---
If my analysis is correct, this PR is still valid *only* for targets not
defining _GLIBCXX_HAVE_TLS. Otherwise, fixed by:
2005-11-21 Benjamin Kosnik <[EMAIL PROTECTED]>
Ulrich Drepper <[EMAIL
--- Comment #43 from pcarlini at suse dot de 2005-12-04 16:43 ---
Hummm, probably there is something fundamentally wrong in the approach, because
Solaris 8, at least, is supposed to not change at all, i.e., __cplusplus ==
1...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
--- Comment #44 from pcarlini at suse dot de 2005-12-04 17:11 ---
Eric, as regards Solaris, 8, I think you forgot to do the svn copy, as per
Comment #34 (and # 35 ;) Still, Solaris 9 and 10 are not fine, sigh, I'll try
to look a bit more into that. Thanks, anyway.
--
--- Comment #46 from pcarlini at suse dot de 2005-12-04 19:46 ---
(In reply to comment #45)
> > Eric, as regards Solaris, 8, I think you forgot to do the svn copy, as per
> > Comment #34 (and # 35 ;)
>
> Ah, sure, thanks. Now I get:
[snip]
> /home/eric/svn/gcc
--- Comment #48 from pcarlini at suse dot de 2005-12-04 20:20 ---
(In reply to comment #47)
> Any reason why libsupc++ can't include the stuff in config/ ?
> I'm interested in seeing this bug go, I'd work on it.
I'm also interested, of course. In principle,
--- Comment #49 from pcarlini at suse dot de 2005-12-04 20:29 ---
(In reply to comment #48)
> (In reply to comment #47)
> > Any reason why libsupc++ can't include the stuff in config/ ?
> > I'm interested in seeing this bug go, I'd work on it.
>
>
--- Comment #50 from pcarlini at suse dot de 2005-12-04 20:52 ---
But there is something I don't understand at all: after a recent patch from
Benjamin, eh_globals.cc now does include *first*! Therefore
the problem seems different. At the beginning of eh_globals.cc __cplusplus is
--- Comment #52 from pcarlini at suse dot de 2005-12-04 21:04 ---
(In reply to comment #51)
> +#define __cpluplus 1
^
Gosh! Thanks Eric for noticing and further testing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
--- Comment #54 from pcarlini at suse dot de 2005-12-04 21:33 ---
(In reply to comment #53)
> > Gosh! Thanks Eric for noticing and further testing.
>
> Hum... no changes on Solaris 9 and 10.
Indeed, should still give problems.
> On Solaris 8 I now get:
I see what
--- Comment #3 from pcarlini at suse dot de 2005-12-05 18:01 ---
This part is done:
http://gcc.gnu.org/ml/libstdc++/2005-11/msg00240.html
can also go in mainline.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24693
--- Comment #1 from pcarlini at suse dot de 2005-12-06 21:09 ---
(In reply to comment #0)
> The failure in bug 25168 appeared between the same pair of revisions; I don't
> know if they are related.
At least, both testcases replace operator new...
--
http://gcc.gnu.o
--- Comment #3 from pcarlini at suse dot de 2005-12-06 22:36 ---
Ouch! Luckily seems not too difficult to fix, consistently with other similar
situations in the library. Thanks for your report.
--
pcarlini at suse dot de changed:
What|Removed
--- Comment #4 from pcarlini at suse dot de 2005-12-07 23:39 ---
In any case, it's a bug. I'm only not sure whether, similarly to the story of
16505, we want to fix it and break user code relying on non standard conforming
behavior. I'm in favor of fixing this problem to
--- Comment #6 from pcarlini at suse dot de 2005-12-08 00:01 ---
Agreed.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot
--- Comment #8 from pcarlini at suse dot de 2005-12-08 00:20 ---
(In reply to comment #7)
> FWIW, I think Andrew makes a good point in comment #1. The algorithms really
> should return the iterator, otherwise the caller may not be able to find out
> the state of the iterator
ReportedBy: pcarlini at suse dot de
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25308
--- Comment #4 from pcarlini at suse dot de 2005-12-08 11:34 ---
Done for 4.2.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #12 from pcarlini at suse dot de 2005-12-08 16:11 ---
(In reply to comment #11)
> However, I'm looking at the pratical effect. If libstdc++ changes the
> return types (correcting the bug) then it will be an ABI breakage.
> If LWG considers and agrees on t
--- Comment #13 from pcarlini at suse dot de 2005-12-08 16:20 ---
(In reply to comment #12)
> 2- As I see the issue, it depends a lot on the actual timeframe of the
> possible
> enhancement to the standard. I mean, if we are thinking about C++0x, seems
> rather far in t
--- Comment #2 from pcarlini at suse dot de 2005-12-08 21:44 ---
(In reply to comment #1)
(12658_thread-1.cc also FAILs but is
> blacklisted in my regression tester as having been known to pass or fail at
> random.
In my opinion, assumin
--- Comment #2 from pcarlini at suse dot de 2005-12-09 00:11 ---
"Component" cannot be libstdc++, nothing changed between those revisions..
--
pcarlini at suse dot de changed:
What|Removed
--- Comment #4 from pcarlini at suse dot de 2005-12-09 10:33 ---
(In reply to comment #3)
> Comment #2 is generally wrong: a change in GCC codegen can certainly expose a
> coding bug in libstdc++ despite "nothing changed" there.
Yes, in princip
--- Comment #1 from pcarlini at suse dot de 2005-12-09 11:37 ---
This is not a bug: see 8.5.3/5. Roughly, when you have an rvalue (like
NonCopyable()) it's implementation defined whether the constructor is called,
and, in any case, "The constructor that would be used to mak
--- Comment #21 from pcarlini at suse dot de 2005-12-14 09:48 ---
(In reply to comment #20)
> This arrangement of debug mode does indeed seem to fix the longstanding swap
> issue.
>
> ie, -D_GLIBCXX_DEBUG runs are == normal runs.
Yeah! (about the rest of the work too ;)
--- 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
--- Comment #4 from pcarlini at suse dot de 2005-12-16 18:27 ---
(In reply to comment #2)
but I
> don't think it should be working this way as it breaks my workflow for testing
> objc/libobjc changes.
--- Comment #6 from pcarlini at suse dot de 2005-12-16 18:36 ---
(In reply to comment #5)
> (In reply to comment #4)
> > Too funny, the Andrew-centric view of the world :-) :-)
> Other people do the same too. I was just the first to complain.
>
> There still needs to
--- Comment #4 from pcarlini at suse dot de 2005-12-16 18:43 ---
Feedback not forthcoming.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pcarlini at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25482
--- Comment #9 from pcarlini at suse dot de 2005-12-23 20:12 ---
FWIW, on x86-linux at least, we are making progress on the compiler side.
With 4.0.2 I get (-O2):
<_Z1fRKSt6vectorIbSaIbEEj>:
0: 55 push %ebp
1: 89 e5
--- Comment #10 from pcarlini at suse dot de 2005-12-23 21:13 ---
Well, I'm not sure that, besides code size, 4_1 is doing better than 4.0.2, but
both are certainly better than 3.4.x.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16611
--- Comment #5 from pcarlini at suse dot de 2005-12-30 09:39 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from pcarlini at suse dot de 2006-01-01 11:33 ---
Similarly to middle-end/25315, these failures too go away (on x86-linux, at
least) if the library is built less optimized, e.g., passing -O1 or -O0 in
CXXFLAGS.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25308
tatus: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pcarlini at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25626
--- Comment #4 from pcarlini at suse dot de 2006-01-02 10:00 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from pcarlini at suse dot de 2006-01-03 22:42 ---
(In reply to comment #1)
> On further investigation, it looks like when a stdio_filebuf is destroyed,
> this will ultimately invoke __basic_file::close(). This calls fclose().
I think this is not true for the const
--- Comment #18 from pcarlini at suse dot de 2006-01-04 13:58 ---
(In reply to comment #17)
>Not that
> I'm
> saying that means the code should stay, just at least one data point of
> someone
&
--- Comment #4 from pcarlini at suse dot de 2006-01-04 15:08 ---
(In reply to comment #3)
> We really don't set __n in all cases here.
And indeed we do *not* want to set __n in all cases: if for some reason the
extraction fails __n *must* be left untouched. Per the standar
--- Comment #6 from pcarlini at suse dot de 2006-01-04 15:17 ---
(In reply to comment #5)
> Hmm, if I understood correctly, this means that the variable is not set if the
> reading operation fails. That sounds plausible, and in this case the warning
> is
> perfectly OK an
--- Comment #8 from pcarlini at suse dot de 2006-01-04 15:26 ---
(In reply to comment #7)
> But the warning is obviously bogus as you can check the errors after a couple
> readings and still be able to be catch error.
Well, I disagree: in my opinion, the compiler is correc
--- Comment #5 from pcarlini at suse dot de 2006-01-06 02:32 ---
(In reply to comment #4)
> Working on a fix.
Many thanks. I was wondering whether you are aware of another (long standing)
multilib bug, libstdc++/20451, maybe fixable at the same time with a minor
additional eff
--- Comment #7 from pcarlini at suse dot de 2006-01-06 15:12 ---
(In reply to comment #6)
> The bugs seem entirely independent.
Ok, too bad ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25524
--- Comment #5 from pcarlini at suse dot de 2006-01-08 17:38 ---
"Insert as close to hint as possible" also done, for 4.2.
--
pcarlini at suse dot de changed:
What|Removed
--- Comment #2 from pcarlini at suse dot de 2006-01-09 10:26 ---
The problem in your code, which makes it illegal, in general, is not c_str(),
which indeed is used correctly, but str(): it generates a temporary (note that
it returns by **value**, e.g., doesn't return a reference
--- Comment #2 from pcarlini at suse dot de 2006-01-09 11:38 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #2 from pcarlini at suse dot de 2006-01-10 13:07 ---
(In reply to comment #1)
> I cannot reproduce this in 3.4.0, 3.4.5 or 4.1.0.
Same here, mainline too. Valgrind is also fine, on x86.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25735
tedBy: pcarlini at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25787
--- Comment #2 from pcarlini at suse dot de 2006-01-15 18:06 ---
Fixed for 4.2.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #3 from pcarlini at suse dot de 2006-01-15 18:09 ---
I know what's going on, I saw this with stock binutils 2.16.1 on x86-linux.
See:
http://gcc.gnu.org/ml/libstdc++/2006-01/msg00051.html
And, there is also another issue with --gc-sections, this one:
--- Comment #1 from pcarlini at suse dot de 2006-01-16 13:55 ---
Hi. I cannot reproduce the problem with current mainline/4_1-branch/4_0-branch,
whereas I see a Segmentation fault with stock 4.0.2. This is a duplicate of
libstdc++/23953, already fixed indeed. Thanks for your report
--- Comment #10 from pcarlini at suse dot de 2006-01-16 13:55 ---
*** Bug 25807 has been marked as a duplicate of this bug. ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #1 from pcarlini at suse dot de 2006-01-17 02:21 ---
For sure, no changes to the concerned library code. Considering that, to my
best knowledge, nobody among the library maintainers has got such kind of
system and that the problem is not reproducable elsewhere, it's h
--- Comment #3 from pcarlini at suse dot de 2006-01-17 12:53 ---
Created an attachment (id=10657)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10657&action=view)
Draft for an aliasing issue
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25815
--- Comment #4 from pcarlini at suse dot de 2006-01-17 12:55 ---
Can you check whether this patch helps you in any way? Is the only pending
issue I'm aware of in the involved code and we are going to have something
similar anyway. -fno-strict-aliasing should also tell you some
--- Comment #5 from pcarlini at suse dot de 2006-01-17 13:00 ---
By the way, no need to run the entire testsuite: example/erase_if.cc can be
compiled and run standalone as-is.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25815
--- Comment #5 from pcarlini at suse dot de 2006-01-17 18:50 ---
I have just completed succesfully a build on linux with both patches applied.
Look fine to me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25823
--- Comment #6 from pcarlini at suse dot de 2006-01-17 19:08 ---
If it's not abvious already to everyone, the reason the issue didn't show up
before on linux is that, when _GLIBCXX_HOSTED is not defined we are *not*
including an no declaration conflicts with the wrong one.
--- Comment #3 from pcarlini at suse dot de 2006-01-17 20:18 ---
(In reply to comment #2)
> Does this work now since the bug which I pointed to has beend fixed?
I think so, everything is fine in all my tests.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25787
--- Comment #4 from pcarlini at suse dot de 2006-01-18 12:38 ---
Target is 4.1.1, not suited for 4_0-branch, because of libstdc++/25472.
--
pcarlini at suse dot de changed:
What|Removed |Added
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed
--- Comment #10 from pcarlini at suse dot de 2006-01-18 12:39 ---
Target is 4.1.1, not suited for 4_0-branch, because of libstdc++/25472.
--
pcarlini at suse dot de changed:
What|Removed |Added
201 - 300 of 2287 matches
Mail list logo
