--- Comment #4 from paolo dot carlini at oracle dot com 2009-12-22 15:58
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-22 18:10
---
It would be nice if could provide a manageable reproducer. Did you try delta
already?
http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction
Thanks in advance.
--
paolo dot carlini at oracle dot com
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-22 18:29
---
Maybe Jason is willing to have a look. If it's legal, and I think it is, it's a
pity that g++ users can't write this type of nifty constructor.
--
paolo dot carlini at oracle dot com changed
--- Comment #7 from paolo dot carlini at oracle dot com 2009-12-22 22:15
---
Doesn't link with 4.5.0. And doesn't link with ICC and SunStudio either, thus,
I'm rather skeptical it should. I also skimmed quickly through the discussion
on comp.lang.c++ and didn't notice any neat
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-21 13:00
---
Any chance you can provide a smaller reproducer? Thanks.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #4 from paolo dot carlini at oracle dot com 2009-12-21 14:11
---
Certainly *is* a problem if we hope to debug the issue decently fast...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42447
--- Comment #6 from paolo dot carlini at oracle dot com 2009-12-21 14:34
---
Ok... Did you help yourself with delta? See:
http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42447
--- Comment #7 from paolo dot carlini at oracle dot com 2009-12-21 16:14
---
I'm reducing it.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42447
--- Comment #9 from paolo dot carlini at oracle dot com 2009-12-21 17:18
---
Note that a compiler built --disable-checking doesn't ICE, just errors out.
Thus, are you sure the code is valid, before anything else?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42447
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42447
--- Comment #12 from paolo dot carlini at oracle dot com 2009-12-21 18:33
---
Ok, thanks. From your work I produced the below, which doesn't use any C++0x
feature and to me looks like a 4.5 Regression.
///
templatetypename _Tp, typename _Up
struct tuple
--- Comment #13 from paolo dot carlini at oracle dot com 2009-12-21 20:29
---
A tad simpler:
templateint
void* get(int);
templatetypename
struct unique_ptr;
templatetypename _Tp
struct unique_ptr_Tp[]
{
typedef int __tuple_type;
void*
get() const
{ return
--- Comment #6 from paolo dot carlini at oracle dot com 2009-12-20 16:19
---
Fixed for 4.5.0.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #15 from paolo dot carlini at oracle dot com 2009-12-19 20:29
---
Good ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42352
--- Comment #5 from paolo dot carlini at oracle dot com 2009-12-20 01:33
---
Maybe I should not have set the milestone ;) Seriously, normally I have no idea
if somebody wants to backport the fix, and simply unassign myself... up to you.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-18 09:35
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #12 from paolo dot carlini at oracle dot com 2009-12-18 09:51
---
David, I committed a patch which should alleviate the problem, any chance you
can tell us whether you are seeing an improvement?
More tweaks (within the C++0x model still) are possible, but seems hard
--- Comment #13 from paolo dot carlini at oracle dot com 2009-12-18 09:57
---
I meant C++03, sorry.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40088
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-18 11:20
---
Confirmed with r155343 on x86_64-linux. Seems a serious regression to me.
Note the snippet is missing a semicolon, fixed like this:
class A {
void f();
};
void A::f() {
A::A();
}
--
paolo dot carlini
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42415
--- Comment #3 from paolo dot carlini at oracle dot com 2009-12-18 11:48
---
... but indeed could well be invalid, thus a diagnostic issue only: in practice
some other compilers I have at hand disagree.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42415
--- Comment #4 from paolo dot carlini at oracle dot com 2009-12-17 09:48
---
Yeah, the description technically fits better, but indeed, without -pthread the
system cannot create thread *at all*, I'm afraid many users could be mystified
by that...
--
http://gcc.gnu.org/bugzilla
--- Comment #16 from paolo dot carlini at oracle dot com 2009-12-17 09:58
---
The std::array error seems indeed bogus: if I'm not wrong, it happens when
swapping arrays, and there are no guarantees that the operation doesn't throw
for std::array, because it's requires to just swap
--- Comment #6 from paolo dot carlini at oracle dot com 2009-12-17 10:25
---
Under linux, it's just unsigned long, which is 64-bit anyway, because actually
it's a size_t. Seems strange that we didn't notice yet, but it's well possible
that on some 64-bit systems a size_t is an unsigned
--- Comment #6 from paolo dot carlini at oracle dot com 2009-12-17 11:11
---
Done.
--
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
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pzhao at gcc dot gnu dot org
|dot org
--- Comment #3 from paolo dot carlini at oracle dot com 2009-12-17 12:00
---
Fixed with:
http://gcc.gnu.org/ml/gcc-cvs/2009-12/msg00455.html
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #25 from paolo dot carlini at oracle dot com 2009-12-17 12:07
---
Interesting trick, really, the power of extended SFINAE ;) I think we should
keep that in mind, for the DO THE RIGHT THING clause of the containers too, for
example (some time ago Howard told me that in his
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-17 12:09
---
Yeah, the usual accessibility issue: in Santa Cruz I discussed that briefly
with Doug, he pretended to convince people that with extended SFINAE you can
implement trivially *any* introspection trait
--- Comment #3 from paolo dot carlini at oracle dot com 2009-12-17 12:10
---
Sorry, the last comment is for 40497.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40856
--- Comment #26 from paolo dot carlini at oracle dot com 2009-12-17 12:11
---
Yeah, the usual accessibility issue: in Santa Cruz I discussed that briefly
with Doug, he pretended to convince people that with extended SFINAE you can
implement trivially *any* introspection trait
--- Comment #28 from paolo dot carlini at oracle dot com 2009-12-17 12:25
---
Actually, details, std::next now wants _ForwardIterator, don't ask me to lookup
the DR ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40497
--- Comment #1 from paolo dot carlini at oracle dot com 2009-12-17 17:55
---
Yes, this is known, no need to keep this issue open for ongoing C++0x work: the
issue basically is that random has not been un-conceptualized yet in the WP,
now that Concepts are gone, and we are for now
--- Comment #30 from paolo dot carlini at oracle dot com 2009-12-18 00:58
---
I agree. In general, however, I'm not sure how general the issue is, now that
concepts are gone. For example, consider the case of the various classification
functions (from C99): you can still find a PR
--- Comment #9 from paolo dot carlini at oracle dot com 2009-12-16 09:51
---
By invalid I meant that I had the time to go through Comment #3 again and found
after all safe enough what we have now. Let's delay any tweaks, which can cause
unexpected regressions on exotic targets, to post
--- Comment #1 from paolo dot carlini at oracle dot com 2009-12-16 09:55
---
Already fixed in 4_4-branch and mainline.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #12 from paolo dot carlini at oracle dot com 2009-12-16 10:14
---
(In reply to comment #10)
Results on x86_64/linux or x86_64/darwin10.2
Status:
FAIL: 23_containers/array/requirements/exception/generation_prohibited.cc
execution test
23_containers/unordered_multiset
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-16 16:01
---
For now I would suggest we do something like this and deal with better
solutions as enhancements. What do you think Jon?
Index: thread.cc
--- Comment #22 from paolo dot carlini at oracle dot com 2009-12-16 16:15
---
Jon, what's your opinion about this one, now that concepts are gone? Frankly, I
don't think we can do much to avoid this type of problem.
--
paolo dot carlini at oracle dot com changed:
What
--- Comment #14 from paolo dot carlini at oracle dot com 2009-12-16 16:17
---
Paolo, Ralf, I'd like to resolve this one for 4.5.0. Any idea?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974
--- Comment #16 from paolo dot carlini at oracle dot com 2009-12-16 19:15
---
Well, for sure the testsuite runs much faster. Anyway, if we can't really
figure out a proper fix, maybe we can disable PCHs when we are building
cross-compilers.
--
http://gcc.gnu.org/bugzilla
--- Comment #5 from paolo dot carlini at oracle dot com 2009-12-16 20:02
---
Interesting. I can't reproduce it in mainline, only with 4.4.x and 4.3.x.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42394
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-15 09:12
---
And these can only be either target or, maybe, c++ front-end, certainly not
libstdc++ proper
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #4 from paolo dot carlini at oracle dot com 2009-12-15 09:22
---
Ok, thanks, I'll track that one instead...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42336
--- Comment #5 from paolo dot carlini at oracle dot com 2009-12-15 11:29
---
FYI, I have checked, however, that the last posted patch for 42225
http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00755.html
doesn't fix this one at once.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-15 15:59
---
It's trivial, just one more candidates are which must be adjusted to
candidate is in the dg-error strings.
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #4 from paolo dot carlini at oracle dot com 2009-12-15 16:12
---
Done.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #17 from paolo dot carlini at oracle dot com 2009-12-15 17:00
---
At the moment, not actively working on this...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #14 from paolo dot carlini at oracle dot com 2009-12-15 17:02
---
Is this still an issue?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35942
--- Comment #18 from paolo dot carlini at oracle dot com 2009-12-15 17:04
---
I'm closing this as fixed for 4.5.0.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #6 from paolo dot carlini at oracle dot com 2009-12-15 17:17
---
Ok, let's close this as invalid.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #8 from paolo dot carlini at oracle dot com 2009-12-15 17:19
---
Roger, are you still actively working on this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35968
--- Comment #1 from paolo dot carlini at oracle dot com 2009-12-15 17:38
---
Changing the value, via macro or whatever is trivial, and I can tell you for
sure from some experiment I did, that a *larger* value is much better, when
memory is available, for operations like copies
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42381
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-15 17:57
---
Let's add a macro (with a *big* warning), will be also useful for experimenting
when I will add (soon) the segmented iterator optimization for copies.
--
paolo dot carlini at oracle dot com changed
--- Comment #4 from paolo dot carlini at oracle dot com 2009-12-15 21:01
---
Done.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #3 from paolo dot carlini at oracle dot com 2009-12-15 21:55
---
Feedback not forthcoming, closing. If you mean to provide a reproducer, please
re-open, thanks.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #3 from paolo dot carlini at oracle dot com 2009-12-15 22:26
---
If you are willing to help more I think you can do two things: 1- Double check
if the problem still exists in the current, that is 4.4, release branch and in
mainline; 2- Actually provide less material
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-16 00:53
---
Gosh, this is enough. The ICE disappears if AvlTreeIter isn't a template:
templateclass PF
struct AvlTreeIter
{
int Num();
AvlTreeIter()
{
new (void* [Num()]);
}
};
--
paolo dot carlini
--- Comment #3 from paolo dot carlini at oracle dot com 2009-12-16 01:10
---
In mainline the ICE happens like this:
#0 0x007613e0 in fold_convert_loc (loc=0, type=0x77e9f000,
arg=0x77e8d9f0) at ../../trunk/gcc/fold-const.c:2629
#1 0x0075aa5f
--- Comment #4 from paolo dot carlini at oracle dot com 2009-12-16 01:44
---
Checked that works with more memory (and 4.2.x is not maintained anymore)
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #13 from paolo dot carlini at oracle dot com 2009-12-14 08:39
---
Yes, you understood correctly, that is our policy and nothing changes if you
overstate the issue by using the broken catch-all. To repeat, our general
policy is that any issue corresponding to an ISO DR
--- Comment #3 from paolo dot carlini at oracle dot com 2009-12-14 08:44
---
I do not have the time to get into the language details, but I think you should
investigate the conformance of the code a bit more: recent SunStudio and Comeau
also agree with ICC and GCC on this.
--
http
--- Comment #4 from paolo dot carlini at oracle dot com 2009-12-14 09:27
---
Likewise VC++ v8
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42356
--- Comment #1 from paolo dot carlini at oracle dot com 2009-12-14 21:28
---
Is c++/42336 related?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42364
--- Comment #20 from paolo dot carlini at oracle dot com 2009-12-14 23:26
---
This is in fact DR 865 and now that the status is [Ready] we can simply re-open
it, say in the docs that we implement it already and then close it again.
--
paolo dot carlini at oracle dot com changed
--- Comment #22 from paolo dot carlini at oracle dot com 2009-12-15 00:10
---
Done.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #10 from paolo dot carlini at oracle dot com 2009-12-12 09:10
---
What do you mean by of this type? As I tried already to explain, until the
ISO C++ Committee resolves DR 1133 we cannot touch list::merge and
list::splice. If, however, you are seeing problems with calls
--- Comment #11 from paolo dot carlini at oracle dot com 2009-12-12 09:17
---
Just to clarify a bit more: if, on the other hand, you are seeing problems
*outside* the library, because you used to rely in your code on rvalue
references binding to lvalues, there is absolutely nothing we
--- Comment #1 from paolo dot carlini at oracle dot com 2009-12-12 09:47
---
The basic error, at line 17, is definitely correct, and, for example, ICC
errors out exactly in the same way. I suppose you would like to see a nicer, in
some sense, list of candidates? (by the way, mailine
--- Comment #19 from paolo dot carlini at oracle dot com 2009-12-11 17:02
---
This is now [Ready]:
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539
and we are already *almost* doing the right thing, besides a std::move call in
std::adjacent_difference, which I'm
--- Comment #21 from paolo dot carlini at oracle dot com 2009-12-11 17:56
---
Done.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-11 18:17
---
The std::, c++0x, version, is in flux. If you want the old behavior, just use
std::tr1::bind for now, and do not expect and C++0x-conforming behavior.
Really, no point in keeping open issues vs ongoing C++0x
--- Comment #3 from paolo dot carlini at oracle dot com 2009-12-11 18:22
---
:) Sorry, this issue has nothing to do with std::bind (ansd std::tr1::bind) of
course. This is actually about list::splcie and list::merge, which indeed are
still in flux in the WP, see DR 1133, or:
http
--- Comment #4 from paolo dot carlini at oracle dot com 2009-12-11 18:43
---
Bah, we can use some std::move(s) in the splice and merge calls used by sort,
and solve this. We'll be reverted as unnecessary when DR 1133 will be resolved,
but maybe can make people more happy for the time
--
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 #6 from paolo dot carlini at oracle dot com 2009-12-11 21:04
---
Thanks. This specific issue I will fix in one day or so. But be warned that
until DR 1133 is resolved by the ISO C++ Committee likely you will encounter
problems with list::splice and list::merge.
--
http
--- Comment #8 from paolo dot carlini at oracle dot com 2009-12-11 22:10
---
list::sort (both overloads) should be fine now, if you notice something
strange, please let me know...
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #5 from paolo dot carlini at oracle dot com 2009-12-10 13:04
---
While you are at it, you can confirm it also with 4.3.x and 4.4.x: evidently
nobody worked on this, otherwise the changes would show up in the audit trail.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #1 from paolo dot carlini at oracle dot com 2009-12-10 13:44
---
Let's CC David...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #7 from paolo dot carlini at oracle dot com 2009-12-10 17:07
---
Grunt. Now I found the time to look in detail into the famous do the right
thing clause, and in fact casting only the first argument was on purpose, see
the last WP, 23.2.3/14. C++03 was different, with both
--- Comment #10 from paolo dot carlini at oracle dot com 2009-12-10 17:18
---
Done.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #11 from paolo dot carlini at oracle dot com 2009-12-10 17:41
---
Actually, DR 1234 reminds me that probably the status quo isn't correct either,
uniformly across 21 (string) and 23 (containers), because the current WP
wording says explicitly *which* constructor must
--- Comment #12 from paolo dot carlini at oracle dot com 2009-12-10 18:17
---
I looked again at the original DR 438, and in fact I think DR 1234 is
unrelated. DR 438 is entirely about explicit vs implicit conversions: I think
now that we have a problem specific to string because
--- Comment #14 from paolo dot carlini at oracle dot com 2009-12-10 19:19
---
Fixed again, mainline only.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #3 from paolo dot carlini at oracle dot com 2009-12-10 23:50
---
For all these reasons, I think the PR can be safely closed as invalid.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from paolo dot carlini at oracle dot com 2009-12-09 09:50
---
Jason, the ICE happens in mangle.c, write_expression gets a null argument. Is
this another variant of c++/38600 and the likes?
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #1 from paolo dot carlini at oracle dot com 2009-12-09 09:53
---
This one happens *only* with -O2 and -g, should be recategorized as debug
and/or optimization? Thanks for any help triaging it...
--
paolo dot carlini at oracle dot com changed:
What
--- Comment #1 from paolo dot carlini at oracle dot com 2009-12-09 11:08
---
I'm seeing this happening in 4.3.x too, isn't new in 4.4.x.
Now, I'm not sure to understand which is the problem: indeed, it disappears,
but it's also true that nothing calls it. I would ask you to provide
--- Comment #3 from paolo dot carlini at oracle dot com 2009-12-09 11:34
---
This is expected, any optimizing compiler (e.g., ICC behaves the same as GCC)
will get rid of that implicit instantiation, while inlining. Really, this is
not going to change.
--
paolo dot carlini
--- Comment #10 from paolo dot carlini at oracle dot com 2009-12-08 09:18
---
*** Bug 42330 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 2009-12-08 09:18
---
You aren't defining anywhere A::i, just add, after struct A:
const int A::i;
and things will be fine.
*** This bug has been marked as a duplicate of 42101 ***
--
paolo dot carlini at oracle dot com
--- Comment #9 from paolo dot carlini at oracle dot com 2009-12-08 09:53
---
This is yet another, C++0x, in this case, testcase, as provided by Jon. I
believe it's the same obnoxious mangling issue, but an additional testcase
cannot hurt ;)
#include type_traits
unsigned value = 0
--- Comment #1 from paolo dot carlini at oracle dot com 2009-12-08 11:01
---
We are still missing Mesh.ii. And, please, do your best to reduce it before
attaching it, thanks in advance...
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #3 from paolo dot carlini at oracle dot com 2009-12-08 11:06
---
Thanks ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42331
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Last
--- Comment #5 from paolo dot carlini at oracle dot com 2009-12-08 11:14
---
No problem. Please, try to figure out something small, shouldn't be that
difficult, I think it should involve only 'int typele[7][2]' vs 'typele={0}'
--
paolo dot carlini at oracle dot com changed
--- Comment #6 from paolo dot carlini at oracle dot com 2009-12-08 11:19
---
This is enough:
class Mesh
{
public:
Mesh(const char*)
{ typele={0}; }
private:
int typele[7][2];
};
Mesh m(0);
--
paolo dot carlini at oracle dot com changed:
What|Removed
1101 - 1200 of 2536 matches
Mail list logo
