--- Comment #1 from paolo dot carlini at oracle dot com 2009-01-02 15:29
---
CC-ing Jason...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from paolo dot carlini at oracle dot com 2009-01-02 15:30
---
Likewise...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from paolo dot carlini at oracle dot com 2009-01-02 15:31
---
And again...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #5 from paolo dot carlini at oracle dot com 2009-01-03 22:37
---
Changes reverted for now, consistently with the discussion:
http://gcc.gnu.org/ml/gcc-patches/2009-01/msg4.html
Waiting for the resolution of a new DR (# to be added Summary).
--
paolo dot carlini
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|REOPENED|SUSPENDED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38678
--
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 #2 from paolo dot carlini at oracle dot com 2009-01-04 13:57
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from paolo dot carlini at oracle dot com 2009-01-04 14:03
---
Richard, this is just an (experimental) extension facility, we can break the
binary interface, return to our decisions, etc, no problem. Thus, just commit
whatever fix you are able to quickly figure out (like
--- Comment #4 from paolo dot carlini at oracle dot com 2009-01-04 14:45
---
Hmm, for now I think you can include ext/type_traits.h and do something like:
typedef __gnu_cxx::__conditional_type(sizeof(unsigned long) =
sizeof(void*)),
unsigned long, unsigned long long
--- Comment #8 from paolo dot carlini at oracle dot com 2009-01-06 19:13
---
Ok...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #14 from paolo dot carlini at oracle dot com 2009-01-07 12:23
---
Hi. Definitely, I like the first approach better. Jakub, are you willing to
work on it? Honestly, because I don't think it's the right time to play with
ABI issues, I'm ready to revert completely this piece
--- Comment #10 from paolo dot carlini at oracle dot com 2009-01-07 13:02
---
Done.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #14 from paolo dot carlini at oracle dot com 2009-01-07 18:17
---
(In reply to comment #13)
Note that my original patch also included a trivial fix for concurrence.h
where
__GTHREAD_MUTEX_INIT_FUNCTION was called when it should have been
__GTHREAD_COND_INIT_FUNCTION
--- Comment #6 from paolo dot carlini at oracle dot com 2009-01-08 14:36
---
I can't reproduce, neither with stock FSF gcc3.4.6 neither with current
gcc4.3.2 and mainline (I'm assuming you expect a 1002 bytes output). I suggest
testing a current FSF GCC release, and file a new PR
--- Comment #10 from paolo dot carlini at oracle dot com 2009-01-08 23:02
---
Ok, I'll do the backport.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38000
--- Comment #12 from paolo dot carlini at oracle dot com 2009-01-09 00:01
---
Fixed 4.3.3 too.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #8 from paolo dot carlini at oracle dot com 2009-01-09 09:41
---
As I said, I'm seeing the expected final size, that is 1002. Also, I don't
think your testcase is correct, you don't want do_always_no_conv to return
true, nothing takes care in your codecvt of packing
--- Comment #9 from paolo dot carlini at oracle dot com 2009-01-09 09:56
---
... and, by the way, exactly because your codecvt is broken - doesn't properly
convert each in-memory wchar_t to a single external char - you maintain to see
1 / 4 of the expected Forecast strings: actually
--- Comment #11 from paolo dot carlini at oracle dot com 2009-01-09 10:15
---
Sorry, but I don't think your codecvt can wrok in any meaningful way as-is.
Either you provide more information as to why - basing on the exact citations
from the Standard - it should work, or we
--- Comment #14 from paolo dot carlini at oracle dot com 2009-01-12 11:11
---
Then, post your new (correct, I hope) codecvt
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from paolo dot carlini at oracle dot com 2009-01-14 17:36
---
First, this issue has nothing to do with the preprocessor. Actually, looking at
your PR, has nothing to do with GCC. Apparently, the authors of SystemC forgot
to include cstdlib in sc_utils_ids.cpp
--- Comment #2 from paolo dot carlini at oracle dot com 2009-01-15 20:48
---
Yeah, this is simply because we are implementing the resolution of DR596:
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596
This is documented, both in the source code and in the docs
--- Comment #1 from paolo dot carlini at oracle dot com 2009-01-16 15:46
---
Thanks for your report. Johannes, can you have a look?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38875
--- Comment #6 from paolo dot carlini at oracle dot com 2009-01-17 09:04
---
Maybe this issue isn't sufficiently clarified in the audit. Unless I'm badly
mistaken (Jon, Chris will correct me), this is not a bug for a C++03 + TR1 bind
(indeed the testcases provided by Doug are rather
--- Comment #2 from paolo dot carlini at oracle dot com 2009-01-19 14:05
---
Thanks for the additional info. Let's add Johannes in CC, I'm confident we can
fix this pretty soon.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #3 from paolo dot carlini at oracle dot com 2009-01-19 17:17
---
Hummm, actually, I can't reproduce with current mainline... Can you also try a
snapshot / SVN checkout of current mainline?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38897
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|NEW |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38897
--- Comment #4 from paolo dot carlini at oracle dot com 2009-01-19 17:36
---
By the way, I don't see any serious divergence between the 4_3 and the mainline
libraries in this area, therefore likely the issue is ultimately due to a C++
front-end issue... Since 4.3.3 is being released
--- Comment #1 from paolo dot carlini at oracle dot com 2009-01-19 22:35
---
Note that auto_ptr is deprecated for the next Standard, replaced by unique_ptr
(which we deliver in C++0x mode). In fact the specifications of auto_ptr are
known to be irreparably broken. That means we must
--- Comment #3 from paolo dot carlini at oracle dot com 2009-01-19 23:12
---
Please, double check that, if possible. Then we'll see...
By the way, we are essentially following Josuttis' implementation, in his book.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38916
--- Comment #1 from paolo dot carlini at oracle dot com 2009-01-20 01:09
---
Benjamin, can you have a look?
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from paolo dot carlini at oracle dot com 2009-01-20 17:02
---
(In reply to comment #1)
should head -1 also be replaced by head -n 1 or is that less portable?
Isn't this a very old issue? I think you will find a straightforward answer /
rationale in the archive
--- Comment #5 from paolo dot carlini at oracle dot com 2009-01-20 17:29
---
Yes, I only meant the head -1 vs head -n 1 part.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38923
--- Comment #3 from paolo dot carlini at oracle dot com 2009-01-26 18:20
---
I'm having a look into this one...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #5 from paolo dot carlini at oracle dot com 2009-01-26 19:08
---
Ok, take your time. For the reasons we already discussed we don't want to rush
on this, in the meanwhile I will also try to collect more information.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38916
--- Comment #8 from paolo dot carlini at oracle dot com 2009-01-26 21:12
---
Jason, can you maybe review Doug's patch linked in Comment #2? Thanks!
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #10 from paolo dot carlini at oracle dot com 2009-01-26 23:25
---
I see, thanks for the missing pointer.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35022
--- Comment #4 from paolo dot carlini at oracle dot com 2009-01-27 17:56
---
On it.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #6 from paolo dot carlini at oracle dot com 2009-01-27 19:48
---
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 2009-01-29 11:23
---
Are we really sure this is invalid? For one, EDG doesn't agree...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--
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 #3 from paolo dot carlini at oracle dot com 2009-01-30 01:43
---
On it.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from paolo dot carlini at oracle dot com 2009-01-30 03:22
---
On it.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #4 from paolo dot carlini at oracle dot com 2009-01-30 10:18
---
The diagnostic issue is trivial, just add a check for error_mark_node on the
return value of reshape_init_r, consistently with other calls.
However, I'm still analyzing whether we really want to reject
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #2 from paolo dot carlini at oracle dot com 2009-01-30 12:08
---
*** Bug 33935 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #3 from paolo dot carlini at oracle dot com 2009-01-30 12:08
---
This is really the same as libstdc++/30928.
*** This bug has been marked as a duplicate of 30928 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #3 from paolo dot carlini at oracle dot com 2009-01-30 15:05
---
Fixed for 4.4.0.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from paolo dot carlini at oracle dot com 2009-01-30 15:05
---
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 2009-01-30 16:57
---
In the meanwhile the patch for PR38503 has been installed and unfortunately I
have to report that this issue seems indeed different, eg, this testcase is
still not fixed on x86_64-linux:
#include string
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Last
--- Comment #2 from paolo dot carlini at oracle dot com 2009-01-31 02:06
---
I don't think this is invalid, want to look a bit into it: I'm attaching a
draft patch which makes sense to me, i.e. if a definition of the operator is
provided, i is initialized to the correct value
--- Comment #3 from paolo dot carlini at oracle dot com 2009-01-31 02:07
---
Created an attachment (id=17219)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17219action=view)
draft I'm using as a starting point
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28501
--- Comment #2 from paolo dot carlini at oracle dot com 2009-02-01 16:22
---
On it.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #4 from paolo dot carlini at oracle dot com 2009-02-02 00:43
---
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 2009-02-02 01:58
---
Mine.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #76 from paolo dot carlini at oracle dot com 2009-02-02 21:11
---
Ok, let's wait a couple of days and, assuming there are no objections, I
volunteer to implement that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
--- Comment #7 from paolo dot carlini at oracle dot com 2009-02-02 10:19
---
Ok Mark, agreed, thanks. For the moment, I'm not going to work on this one and
I'm unassigning myself in order not to prevent anyone else quicker than me...
--
paolo dot carlini at oracle dot com changed
--- Comment #18 from paolo dot carlini at oracle dot com 2009-02-03 13:16
---
(In reply to comment #17)
+ if (TREE_CODE (t1) == TYPENAME_TYPE)
+t1 = resolve_typename_type (t2, /*only_current_p=*/true);
But I suppose you want consistently t1 here ;)
--
http://gcc.gnu.org
--- Comment #8 from paolo dot carlini at oracle dot com 2009-02-03 16:22
---
Did you really commit it to mainline? I don't see it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36897
--- Comment #22 from paolo dot carlini at oracle dot com 2009-02-03 16:22
---
Likewise... ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37314
--
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 #78 from paolo dot carlini at oracle dot com 2009-02-03 17:14
---
Nope, we never do that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
--- Comment #80 from paolo dot carlini at oracle dot com 2009-02-03 17:20
---
Many solutions are better, in principle, but really this issue is too old.
After all we are uglifying also in other cases. Let's do that and be done with
it. Unless there are objections (or, better
--- Comment #82 from paolo dot carlini at oracle dot com 2009-02-03 23:46
---
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 2009-02-05 00:46
---
This is not a bug, but Standard conforming behaviour. The next C++ Standard
will be different here.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #20 from paolo dot carlini at oracle dot com 2009-02-05 12:48
---
Created an attachment (id=17246)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17246action=view)
draft, showing that the missing NULL_TREEs are indeed an issue
--
http://gcc.gnu.org/bugzilla
--- Comment #19 from paolo dot carlini at oracle dot com 2009-02-05 12:47
---
Indeed, in my experiments the problem seems due to build_min_nt not passing
NULL_TREEs as called by build_x_binary_op. The patch I'm going to attach then
works, in the sense that the testcase compiles
--- Comment #4 from paolo dot carlini at oracle dot com 2009-02-05 14:09
---
But, isn't GLIBCXX_CHECK_LINKER_FEATURES called *only* when $GLIBCXX_IS_NATIVE?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39107
--- Comment #4 from paolo dot carlini at oracle dot com 2009-02-05 15:36
---
Note the first snippet only triggers a warning with ICC / Comeau in strict
mode, the second one, compiles just fine...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36406
--- Comment #7 from paolo dot carlini at oracle dot com 2009-02-05 19:36
---
Yes. Please add details about the way you are setting up your build, give
people a chance to analyse it.
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #9 from paolo dot carlini at oracle dot com 2009-02-06 12:51
---
On it.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #3 from paolo dot carlini at oracle dot com 2009-02-06 12:51
---
On it.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #11 from paolo dot carlini at oracle dot com 2009-02-07 02:08
---
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 2009-02-07 02:08
---
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 2009-02-07 11:11
---
Mark, can I have your opinion about this issue? I'm still thinking we could
rather easily accept the code... Thanks in advance.
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #1 from paolo dot carlini at oracle dot com 2009-02-07 11:35
---
Today I can't reproduce it. Do you?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39060
--- Comment #22 from paolo dot carlini at oracle dot com 2009-02-08 22:40
---
Many thanks Mark for your detailed feedback on this PR and the other one. I'll
try to work along the lines you suggested.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34397
--- Comment #2 from paolo dot carlini at oracle dot com 2009-02-09 09:53
---
(In reply to comment #0)
I'm not sure if this is valid code. However, the standard seems to indicate
that resize(size_type), is a required member function (or at least interface)
of std::vector.
Which
--- Comment #4 from paolo dot carlini at oracle dot com 2009-02-09 16:11
---
(In reply to comment #3)
I'm looking at the current draft, n2798.
23.2.6.2/10-11 [vector.capacity]
which lists both forms of resize().
Yes, libstdc++ covers both by using the trailing default argument
--- Comment #5 from paolo dot carlini at oracle dot com 2009-02-09 16:47
---
Your snippet boils down to this, which is clearly invalid:
struct vector
{
void resize(long unsigned int, int = 0);
};
templatetypename _Ret, typename _Tp, typename _Arg
void
mem_fun_ref(_Ret (_Tp
--- Comment #23 from paolo dot carlini at oracle dot com 2009-02-09 17:09
---
Mark, can you have a closer look to the draft patch? I'm still looking but I
don't think we can extract and commonize much code from grok_array_decl, unless
we accept to pass from the callers an in_parser
--
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 #7 from paolo dot carlini at oracle dot com 2009-02-09 17:26
---
(In reply to comment #6)
Was there a compelling reason to remove it in favor of the unified
::resize(size_type, const value_type t = T)?
Yes, is non-conforming! I thought it was clear at this point... Just
--- Comment #9 from paolo dot carlini at oracle dot com 2009-02-09 17:59
---
(In reply to comment #8)
At no point was vectorTp::resize() ever instantiatable with a
non-DefaultConstructible Tp, even with the old size_type-only member
function. It would have failed on value_type
--- Comment #1 from paolo dot carlini at oracle dot com 2009-02-09 18:10
---
Please follow the bug-reporting instructions, in particular, please provide a
pre-processed reproducer:
http://gcc.gnu.org/bugs.html
--
paolo dot carlini at oracle dot com changed:
What
--- Comment #3 from paolo dot carlini at oracle dot com 2009-02-09 18:15
---
Please reduce it to a manageable size. For example, try 'delta', if you don't
have other ways.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from paolo dot carlini at oracle dot com 2009-02-09 18:59
---
*** This bug has been marked as a duplicate of 18640 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #4 from paolo dot carlini at oracle dot com 2009-02-09 18:59
---
*** Bug 39144 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #3 from paolo dot carlini at oracle dot com 2009-02-10 00:08
---
Ah, ok, it's i686...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39060
--- Comment #5 from paolo dot carlini at oracle dot com 2009-02-10 00:35
---
Take your time. Please, understand that if a PR is not filed in the proper
form, the chances that a knowledgeable person seriously look into it, sharply
decreases. You can probably find this also useful
--- Comment #25 from paolo dot carlini at oracle dot com 2009-02-10 10:03
---
Thanks. I'll try to submit something more polished along these lines...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34397
--- Comment #7 from paolo dot carlini at oracle dot com 2009-02-10 10:21
---
Thanks Richard, noticed the Killed too late...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39142
--- Comment #27 from paolo dot carlini at oracle dot com 2009-02-10 21:48
---
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 2009-02-11 17:52
---
Paolo, should this be assigned to you?
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #5 from paolo dot carlini at oracle dot com 2009-02-12 15:22
---
Let's see...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #5 from paolo dot carlini at oracle dot com 2009-02-12 17:05
---
Hi. Maybe the testcases should be amended, but surely when char is signed, just
checking that vec[i] 0 as an indication of regular group size instead of
vec[i] 0 vec[i] != CHAR_MAX cannot be right
--- Comment #5 from paolo dot carlini at oracle dot com 2009-02-13 00:19
---
... and by the way, ICEs also with __decltype...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39070
--- Comment #8 from paolo dot carlini at oracle dot com 2009-02-13 11:31
---
(In reply to comment #7)
Standard use term unlimited length, which
means(as I understand) that all other digits should incorporate in only one
group - only 123456 is correct
--- Comment #9 from paolo dot carlini at oracle dot com 2009-02-13 11:39
---
In other terms, as usual about those matters, Martin is right ;) Only he has
got a wrong data point about libstdc++, he believes we are setting eofbit.
Thanks anyway for pointing our attention
1 - 100 of 2536 matches
Mail list logo
