--
pcarlini at suse dot de changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36211
--- Comment #3 from pcarlini at suse dot de 2008-04-25 10:35 ---
Patch:
http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01064.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35331
--- Comment #8 from pcarlini at suse dot de 2008-04-24 17:05 ---
Fixed for 4.4.0.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from pcarlini at suse dot de 2008-04-21 08:24 ---
Many thanks Roger for your further help on nth_element, excellent news.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35968
--- Comment #1 from pcarlini at suse dot de 2008-04-20 17:30 ---
Roger, can you have a look? Thanks in advance.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #6 from pcarlini at suse dot de 2008-04-21 00:46 ---
According to the resolution of DR 250,
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#250
indeed splicing doesn't really invalidate iterators. Therefore, the debug-mode
merge should be consistent
--- Comment #1 from pcarlini at suse dot de 2008-04-14 18:02 ---
*** This bug has been marked as a duplicate of 35934 ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #1 from pcarlini at suse dot de 2008-04-14 18:02 ---
*** Bug 35935 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35934
--- Comment #1 from pcarlini at suse dot de 2008-04-13 09:39 ---
CC-ing Benjamin...
--
pcarlini at suse dot de changed:
What|Removed |Added
CC
--- Comment #3 from pcarlini at suse dot de 2008-04-13 15:17 ---
Benjamin, can you have a look? Seems just an extension of libstdc++/30085: it
seems we can certainly have debug mode for std::unordered_* too (besides
std::tr1::unordered_*)
--
pcarlini at suse dot de changed
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|pcarlini at suse dot de |unassigned at gcc dot gnu
--- Comment #1 from pcarlini at suse dot de 2008-04-12 19:29 ---
You want to include cstdlib: cmath only provides overloads for floating
point types (see 26.5 for details).
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #2 from pcarlini at suse dot de 2008-04-10 17:05 ---
Seems doable...
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #1 from pcarlini at suse dot de 2008-04-09 11:22 ---
Names starting with __ and _ (see 17.4.3.1 for details) are reserved. That's
exactly the reason why the library uses everywhere and only such names (why,
otherwise?)
--
pcarlini at suse dot de changed:
What
--- Comment #3 from pcarlini at suse dot de 2008-03-30 09:24 ---
This is tightly coupled to libstdc++/35353: in the current design, when
sync_with_stdio is false (by default), the stream is non-converting and synced
with C stdio, simply forwards to stdio functions. Unfortunately
--- Comment #3 from pcarlini at suse dot de 2008-03-30 09:27 ---
Really, this is a WORKSFORME, code in Comment #2 is fine everywhere.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #6 from pcarlini at suse dot de 2008-03-29 22:43 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from pcarlini at suse dot de 2008-03-28 00:37 ---
Argh. Easy to fix, will do ASAP.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #3 from pcarlini at suse dot de 2008-03-28 00:47 ---
Created an attachment (id=15392)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15392action=view)
Draft patch
I'm finishing testing something along these lines...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--
pcarlini at suse dot de changed:
What|Removed |Added
Target Milestone|--- |4.3.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35725
--- Comment #2 from pcarlini at suse dot de 2008-03-21 21:15 ---
*** This bug has been marked as a duplicate of 35541 ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #8 from pcarlini at suse dot de 2008-03-21 21:15 ---
*** Bug 35656 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 2008-03-20 15:42 ---
Interestingly, current mainline is not affected. Thus, either the mainline
compiler regressed (that is the library is actually buggy and the mainline
compiler should reject the code, like the 4_3-branch compiler does
--- Comment #2 from pcarlini at suse dot de 2008-03-20 15:49 ---
In mainline, -pedantic-errors is needed. That seems weird to me, maybe Maunel
can help here. On the other hand, a problem with library code seems also
likely.
--
pcarlini at suse dot de changed:
What
--- Comment #3 from pcarlini at suse dot de 2008-03-20 19:57 ---
I'm fixing the library bits.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo
--
pcarlini at suse dot de changed:
What|Removed |Added
Target Milestone|--- |4.3.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35637
--- Comment #7 from pcarlini at suse dot de 2008-03-20 23:49 ---
(In reply to comment #6)
Again, from GCC 4.4 on, -pedantic/-pedantic-errors should work the same as for
the C front-end, that is, -pedantic enables warnings, -pedantic-errors
converts
those warnings into errors. What
--- Comment #10 from pcarlini at suse dot de 2008-03-21 00:01 ---
Thanks. Note, I cannot really use -Wsystem-headers in library testcases,
because in that way other, completely, unrelated warnings are always triggered.
I think we should not do much more at this stage for 4_3-branch
--- Comment #1 from pcarlini at suse dot de 2008-03-14 22:54 ---
Hi Johannes, can you have a look? Many thanks.
--
pcarlini at suse dot de changed:
What|Removed |Added
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org
--- Comment #7 from pcarlini at suse dot de 2008-03-13 17:38 ---
Fixed for 4.3.1.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from pcarlini at suse dot de 2008-03-13 17:49 ---
Fixed for 4.3.1.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from pcarlini at suse dot de 2008-03-12 19:47 ---
Really, we know about this type of annoying situations, very hard to deal with
within the requirements of C++03, because implementors often do not have
control on the contents of the underlying C library headers
--- Comment #8 from pcarlini at suse dot de 2008-03-12 19:47 ---
*** Bug 35557 has been marked as a duplicate of this bug. ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #4 from pcarlini at suse dot de 2008-03-11 21:52 ---
Yes, it's a trivial issue, sorry about that. I think the third parameter of the
*_sorted_set_aux functions can be simply removed. Anyway, I'll fix it ASAP.
--
pcarlini at suse dot de changed:
What
--- Comment #2 from pcarlini at suse dot de 2008-03-10 18:28 ---
*** Bug 35527 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35525
--- Comment #1 from pcarlini at suse dot de 2008-03-10 18:28 ---
*** This bug has been marked as a duplicate of 35525 ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #3 from pcarlini at suse dot de 2008-03-09 11:21 ---
I agree ;)
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #2 from pcarlini at suse dot de 2008-03-06 16:27 ---
Frankly, I'm not 100% sure we want an error here: I mean, we have a Requires
violation in the case at issue, which, in general, in my reading of the
standard, certainly doesn't mean the code must not compile, means
--- Comment #4 from pcarlini at suse dot de 2008-03-06 16:53 ---
(In reply to comment #3)
To me, if geti(t) fails to compile under the assumption of ill formed,
then
by the definitions of 6.1.3.5, geti(t) == geti(u) should also fail to
compile. Although it is not explicitly stated
--- Comment #5 from pcarlini at suse dot de 2008-03-06 17:00 ---
By the way, in the meanwhile I checked N2322 and C++0x will simply enforce
EqualityComparableTTypes, UTypes...
We are presently trying to figure out whether in the meanwhile we want to
explicitly enforce sizeof...(TTypes
--- Comment #7 from pcarlini at suse dot de 2008-03-06 17:18 ---
Cool, if everything can be dealt with right now by simply fixing that, then
let's do it! Really, in these times, I dislike the idea of robustify templates
here and there (without a global neat strategy) with old-times
--- Comment #5 from pcarlini at suse dot de 2008-03-06 17:52 ---
Fixed for 4.3.1 too.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from pcarlini at suse dot de 2008-03-06 17:53 ---
Fixed for 4.3.1 too.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|pcarlini
--- Comment #4 from pcarlini at suse dot de 2008-03-06 17:53 ---
Fixed for 4.3.1 too.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #10 from pcarlini at suse dot de 2008-03-06 18:37 ---
Fixed for 4.4.0 and 4.3.1.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status
--- Comment #17 from pcarlini at suse dot de 2008-03-04 11:04 ---
(In reply to comment #16)
Sorry, I had two versions of patch and managed to commit the wrong copy.
Sent correct one to ML. It should be fixed now.
Indeed, it's fixed! Many, many thanks!
The point I wanted to make
--- Comment #13 from pcarlini at suse dot de 2008-03-03 19:04 ---
Honza, I'm sorry, can you please double-check the fix? On my x86_64-linux
machines I'm not seeing any progress :(
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #15 from pcarlini at suse dot de 2008-03-04 00:09 ---
(In reply to comment #14)
Hi,
this is what I get from our thester:
Differences:
Tests that now work, but didn't before:
abi_check
so it ought to make differnece for i686-linux.
Note however, that the patch also
--- Comment #9 from pcarlini at suse dot de 2008-03-02 17:35 ---
Confirmed, of course. Honza, any news on the inlining issue?
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #1 from pcarlini at suse dot de 2008-02-26 10:57 ---
*** This bug has been marked as a duplicate of 13740 ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #15 from pcarlini at suse dot de 2008-02-26 10:57 ---
*** Bug 35374 has been marked as a duplicate of this bug. ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #9 from pcarlini at suse dot de 2008-02-25 12:44 ---
Maybe we can improve the behavior when the stdio is synced, that is we can
transcode each wchar_t and sync after each transcoding. Very likely, you can
also simulate that behavior right now by using sync_with_stdio(false
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|NEW |SUSPENDED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35353
--- Comment #10 from pcarlini at suse dot de 2008-02-25 13:11 ---
Note, anyway, that there is a serious blocker to any enhancement in this area
(and of course it explains the current behavior): if wcin co are converting,
they deal with the underlying stream as a narrow-character
--- Comment #11 from pcarlini at suse dot de 2008-02-25 14:18 ---
About my last reply: I checked, and within the current implementation of the
underlying I/O the last issue (per libstdc++/9662) doesn't exist anymore, in
other terms, when sync_with_stdio(false), C++ I/O on wcin/wcout
--- Comment #2 from pcarlini at suse dot de 2008-02-25 17:03 ---
Seems simple.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #2 from pcarlini at suse dot de 2008-02-25 17:18 ---
Also simple.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #3 from pcarlini at suse dot de 2008-02-25 18:10 ---
Eh! I think we should only double check that tests creating / writing files use
unique names...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33612
--- Comment #1 from pcarlini at suse dot de 2008-02-25 19:47 ---
Yes it is. This change dates back to the 3.4 series:
http://gcc.gnu.org/gcc-3.4/changes.html
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #1 from pcarlini at suse dot de 2008-02-25 21:28 ---
Seems easy.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc
--- Comment #1 from pcarlini at suse dot de 2008-02-24 13:45 ---
*** This bug has been marked as a duplicate of 35262 ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #8 from pcarlini at suse dot de 2008-02-24 13:45 ---
*** Bug 35351 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 2008-02-24 13:49 ---
You are mistaken: just have a look to the results posted to gcc-testresults,
the test XPASSes, as usual.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #3 from pcarlini at suse dot de 2008-02-24 14:18 ---
Not a bug, given our implementation-defined behavior: the various cin / wcin,
streams are by default synced with stdio (per the standard requirements) and
thus not converting. You can either call sync_with_stdio(false
--- Comment #6 from pcarlini at suse dot de 2008-02-24 14:40 ---
sync_with_stdio(false) works, and is tested dozens of times a day in our
testsuites. And that is only half of my answer. Please understand what I said,
study the details of the ISO C++ Standard and then come back
--- Comment #2 from pcarlini at suse dot de 2008-02-23 17:00 ---
*** This bug has been marked as a duplicate of 13399 ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #3 from pcarlini at suse dot de 2008-02-23 17:00 ---
*** Bug 35275 has been marked as a duplicate of this bug. ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #4 from pcarlini at suse dot de 2008-02-22 09:48 ---
Ok, I'm going to post a patch reverting completely the fix for 28743, and then
we'll see...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35282
--- Comment #13 from pcarlini at suse dot de 2008-02-22 11:07 ---
Unfortunately, back to a 4.3 (and 4.4) regression.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #10 from pcarlini at suse dot de 2008-02-22 11:05 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|NEW
--- Comment #7 from pcarlini at suse dot de 2008-02-21 17:06 ---
I understand this is fixed now. Otherwise, please reopen (and sorry ;)
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #1 from pcarlini at suse dot de 2008-02-21 22:25 ---
Please double check, but I don't think it's my patch: I tried quickly reverting
it and interestingly nothing changes: 28743 doesn't ICE and this one is
rejected. It seems something new is going on in this area... Maybe
--- Comment #2 from pcarlini at suse dot de 2008-02-21 23:13 ---
Never mind, I did something wrong in my quick check. I can confirm it's my
patch. I'll try to look a bit into it, but beyond reverting it, I cannot
promise to be able to fix the present issue without regressing on 28743
--- Comment #4 from pcarlini at suse dot de 2008-02-20 21:13 ---
I'm not sure there is a substantive bug here, in that the problem can be easily
fixed by simply tweaking gnu.ver to explicitely hide
ZSt13__check_facetISt7codecvtIcc11__mbstate_tEERKT_PS4_ and the wchar_t
counterpart
--- Comment #6 from pcarlini at suse dot de 2008-02-21 00:07 ---
(In reply to comment #5)
Subject: Re: [4.4 Regression]: FAIL: abi_check
OK,
if it really is just inlining decision difference then we are fine.
I guess we can either update symbol list or mark always_inline
Yes
--- Comment #7 from pcarlini at suse dot de 2008-02-21 00:08 ---
Created an attachment (id=15189)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15189action=view)
Pre-processed instantiation
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35262
--- Comment #3 from pcarlini at suse dot de 2008-02-17 10:59 ---
The problem is just that stdint isn't available everywhere (I don't think the
configure checks can be weakened). Probably we should just keep the old by
hand typedefs.
--
pcarlini at suse dot de changed
--- Comment #5 from pcarlini at suse dot de 2008-02-17 11:33 ---
Thanks Eric. I'm not sure that rework is appropriate for 4.3.0, though...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35221
--- Comment #7 from pcarlini at suse dot de 2008-02-17 14:43 ---
Ok, I'm taking care of that.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo
--- Comment #9 from pcarlini at suse dot de 2008-02-17 15:49 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from pcarlini at suse dot de 2008-02-16 19:34 ---
On it.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot
--- Comment #5 from pcarlini at suse dot de 2008-02-16 23:41 ---
Fixed for 4.3.0.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from pcarlini at suse dot de 2008-02-14 12:37 ---
Fixed for 4.3.0.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|pcarlini
--- Comment #5 from pcarlini at suse dot de 2008-02-14 15:40 ---
*** This bug has been marked as a duplicate of 34538 ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #9 from pcarlini at suse dot de 2008-02-14 15:40 ---
*** Bug 33983 has been marked as a duplicate of this bug. ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #4 from pcarlini at suse dot de 2008-02-11 09:31 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from pcarlini at suse dot de 2008-02-10 14:36 ---
On it. I think we can safely implement submitter' suggestion.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #7 from pcarlini at suse dot de 2008-02-10 15:51 ---
Nothing will be done in older branches (by the way, I'm coming to the
conclusion that adding the default constructor was probably an error, but
unfortunately is *exported* and in any case we can't just remove it now
--- Comment #2 from pcarlini at suse dot de 2008-02-07 12:07 ---
Just wanted to add that we are also providing a tr1/cmath, conforming to the
TR1 specifications, which indeed makes available std::tr1::log2, and also, in
the forthcoming 4.3.0, std::log2, as part of cmath, enabled
--- Comment #1 from pcarlini at suse dot de 2008-02-05 10:00 ---
This is illegal in C++03, per 14.3.1/2, and no strictly conforming compiler
accepts it.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #2 from pcarlini at suse dot de 2008-02-04 14:59 ---
Seems simple.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #4 from pcarlini at suse dot de 2008-01-29 02:05 ---
This is a reduced snippet (-pedantic). I suspect the problem may have to do
with the fix for c++/27177, let's CC Jason...
struct AffEntry
{
union {
char base[256];
} conds;
};
struct PfxEntry
: public AffEntry
--- Comment #12 from pcarlini at suse dot de 2008-01-27 11:44 ---
Yes, I noticed. Frankly, I'm not really worried because of the nature of the
tests: the checks can give different answers depending on whether the compiler
is able or not to figure out that a given function cannot throw
--- Comment #14 from pcarlini at suse dot de 2008-01-27 13:34 ---
(In reply to comment #13)
If a function isn't marked nothrow and the function can be overridden by a
shared library (that is, it doesn't bind locally), the compiler cannot derive
such property from its body.
Thanks
--- Comment #17 from pcarlini at suse dot de 2008-01-27 18:54 ---
Hi Kaveh. One problem I can see is that we are dealing with special member
functions, like constructors and assignment operators. Can you see anything
wrong with the straightforward implementation of idea per the attached
--- Comment #16 from pcarlini at suse dot de 2008-01-27 18:51 ---
Created an attachment (id=15030)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15030action=view)
Draft idea for the -fpic/-fPIC fails
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26099
--- Comment #20 from pcarlini at suse dot de 2008-01-27 20:40 ---
Hi Kaveh. I just checked darwin and indeed, we have an issue there, which,
AFAICS, is not worked around with -fpie. I say, let's just skip the test when
__PIC__ is defined, and be done with it.
--
http://gcc.gnu.org
--- Comment #22 from pcarlini at suse dot de 2008-01-27 20:49 ---
Created an attachment (id=15031)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15031action=view)
New draft
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26099
--- Comment #21 from pcarlini at suse dot de 2008-01-27 20:47 ---
Since you are already set for this extended kind of testing, can you run the
new patch? Thanks a lot in advance!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26099
1 - 100 of 2278 matches
Mail list logo
