--- Comment #6 from paolo dot carlini at oracle dot com 2010-09-03 23:21
---
Done.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from paolo dot carlini at oracle dot com 2010-09-03 17:10
---
Let's add Jason in CC about this one too.
--
paolo dot carlini at oracle dot com changed:
What|Removed |
--- Comment #4 from paolo dot carlini at oracle dot com 2010-09-03 15:05
---
Thus, Jon, are we just missing a #pragma GCC system_header at the beginning of
that file? In case, just add it and close the PR?
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #1 from paolo dot carlini at oracle dot com 2010-09-03 14:44
---
Let's ask Jason to have a look.
--
paolo dot carlini at oracle dot com changed:
What|Removed |
--- Comment #8 from paolo dot carlini at oracle dot com 2010-09-03 10:46
---
If you look at the actual Standard, both alignment and allocation of bit-fields
are implementation defined. Thus, as far as I can see, at best we are talking
about non-portable implementation defined behavior
--- Comment #4 from paolo dot carlini at oracle dot com 2010-09-03 09:09
---
Ah, ok, thanks Jason.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45501
--- Comment #4 from paolo dot carlini at oracle dot com 2010-09-03 01:09
---
Fair enough, but first blush I also don't see any text in the C++ Standard
guaranteeing the behavior you want, wondered if you actually can get it with
other compilers, maybe as implementation de
--- Comment #2 from paolo dot carlini at oracle dot com 2010-09-03 00:02
---
Without having seriously looked into your code, I note that two completely
different, closed source compilers (ICC and SunStudio) leads to the same
behavior as GCC at runtime. Does your code actually "
--- Comment #4 from paolo dot carlini at oracle dot com 2010-09-02 22:31
---
Note that if the problem affects only the GCC delivered with that SUSE distro
should be reported to SUSE, not here. Personally, I can't reproduce it with
stock 4.3.2 or 4.3.3 or current FSF releases fro
--- Comment #2 from paolo dot carlini at oracle dot com 2010-09-02 18:35
---
I can't reproduce this with FSF 4.3.2, neither 4.3.3, neither anything more
recent.
--
paolo dot carlini at oracle dot com changed:
What|Removed |
--- Comment #2 from paolo dot carlini at oracle dot com 2010-09-02 17:44
---
As a matter of fact, basing on my rough understanding of '.template', GCC may
well be correct: my rule of thumb is that 'template' is required when the
construct before the period d
--- Comment #1 from paolo dot carlini at oracle dot com 2010-09-02 17:16
---
Since PrintTextFrom is a template, you can (should) write:
this->prn.template PrintTextFrom< MetaObj >();
which works with both compilers. Since apparently ICC 11.1 likes in strict mode
also
--- Comment #49 from paolo dot carlini at oracle dot com 2010-09-02 16:07
---
Confirmed ~ 2x on my i7.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974
--- Comment #47 from paolo dot carlini at oracle dot com 2010-09-02 14:10
---
Ok, Paolo, let's give this small change a try. About PCHs saving time during
make check, that seems uncontroversial, I can provide some numbers later, but
if you just try removing the generated PCHs by
--- Comment #45 from paolo dot carlini at oracle dot com 2010-09-02 09:42
---
Paolo (Bonzini), Ralf, I'm going to add -nostdinc++ to PCHFLAGS in
include/Makefile.am. Are there any risks of regressions?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974
--- Comment #17 from paolo dot carlini at oracle dot com 2010-09-02 00:13
---
No.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44963
--- Comment #15 from paolo dot carlini at oracle dot com 2010-09-01 23:59
---
>From now on I will not apply *any* patch not fixing extremely serious
regressions to the 4.4.x branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44963
--- Comment #12 from paolo dot carlini at oracle dot com 2010-09-01 23:00
---
Done.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #9 from paolo dot carlini at oracle dot com 2010-09-01 22:49
---
We are already well beyond the size of change which is not fixing any real bug
and applied without a Copyright Assignment on file. If you are interested in
enhancing the library, please file one and then start
--- Comment #7 from paolo dot carlini at oracle dot com 2010-09-01 22:42
---
Doesn't always work with proxy iterators.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45488
--- Comment #5 from paolo dot carlini at oracle dot com 2010-09-01 22:37
---
We are not adding testcases here, because a forward iterator must be default
constructible.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45488
--- Comment #3 from paolo dot carlini at oracle dot com 2010-09-01 22:09
---
Ok, I'll do it, for equal_range too, and __half can also be moved inside the
loop.
--
paolo dot carlini at oracle dot com changed:
What|Removed |
--- Comment #2 from paolo dot carlini at oracle dot com 2010-09-01 20:53
---
Granted, __middle is not used after the loop, thus moving the declaration
inside the loop seems a tad cleaner. But then we should do the change
consistently for both lower_bound overloads and for upper_bound
--- Comment #1 from paolo dot carlini at oracle dot com 2010-09-01 20:44
---
I do not understand: according to Table 74 *any* forward iterator is default
constructible, and C++0x isn't changing that, is even more explicit. Thus, I
don't see which problem you are tryin
--- Comment #7 from paolo dot carlini at oracle dot com 2010-09-01 13:53
---
Likewise about ICC.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45479
--- Comment #5 from paolo dot carlini at oracle dot com 2010-09-01 13:49
---
For the record, building with ICC gives the same behavior of GCC. Let's ask
Jason' opinion about this.
--
paolo dot carlini at oracle dot com changed:
What
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45481
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Severity|blocker |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45479
--- Comment #14 from paolo dot carlini at oracle dot com 2010-08-31 17:41
---
Done.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #6 from paolo dot carlini at oracle dot com 2010-08-30 18:15
---
Fixed for 4.6.0.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #4 from paolo dot carlini at oracle dot com 2010-08-30 16:29
---
Just checking that TREE_CODE (dname) == IDENTIFIER_NODE before using
MAIN_NAME_P on it appears to fix the issue.
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #9 from paolo dot carlini at oracle dot com 2010-08-29 17:32
---
Jason, any hint about the best way to attack this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44473
--- Comment #15 from paolo dot carlini at oracle dot com 2010-08-29 10:23
---
*** Bug 45442 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 2010-08-29 10:23
---
*** This bug has been marked as a duplicate of 27904 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #3 from paolo dot carlini at oracle dot com 2010-08-18 23:19
---
Actually, both mainline and the released 4.5.1 work, most likely a duplicate of
PR 44703 indeed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from paolo dot carlini at oracle dot com 2010-08-18 23:11
---
Let's CC Jason.
--
paolo dot carlini at oracle dot com changed:
What|Removed |
--- Comment #1 from paolo dot carlini at oracle dot com 2010-08-18 15:28
---
In general terms, ins't true that the warnings produced at -O0 are often much
weaker than when optimizing? I don't see anything aliasing-specific here...
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #3 from paolo dot carlini at oracle dot com 2010-08-18 15:24
---
Done.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #12 from paolo dot carlini at oracle dot com 2010-08-17 13:07
---
Sure, I forgot to grep, was in an hurry because I'm leaving for a few days of
vacations, but will do it momentarily.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45300
--- Comment #10 from paolo dot carlini at oracle dot com 2010-08-16 19:02
---
Done.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #8 from paolo dot carlini at oracle dot com 2010-08-16 18:29
---
Good point, but I think that in these whole program optimization times getting
the declaration right, that is consistent with the definition, is in any case a
good idea.
--
http://gcc.gnu.org/bugzilla
--- Comment #6 from paolo dot carlini at oracle dot com 2010-08-16 17:56
---
Ok. Actually my question was born more naive, simply about replacing after so
many years 'restrict' with with either '__restrict' or '__restrict__', that is
something with r
--- Comment #3 from paolo dot carlini at oracle dot com 2010-08-16 17:35
---
Let's add in CC Jakub, just in case he can see something wrong vs the C library
with using __restrict__ here.
--
paolo dot carlini at oracle dot com changed:
What|Re
--- Comment #2 from paolo dot carlini at oracle dot com 2010-08-16 17:34
---
I see. I'm not sure how much difference it makes, but I think we should change
those, to __restrict__. Note, in C++ 'restrict' is not a keyword in any case -
not even in C++0x mode which otherwi
--- Comment #3 from paolo dot carlini at oracle dot com 2010-08-14 21:36
---
Thanks a lot Jon: now check-performance should be clean again.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45283
--- Comment #3 from paolo dot carlini at oracle dot com 2010-08-14 00:10
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: paolo dot carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45283
--- Comment #1 from paolo dot carlini at oracle dot com 2010-08-13 22:38
---
Turns out this CH 15 (N3105). I'll implement it, at least as far as the
container adaptors are concerned.
--
paolo dot carlini at oracle dot com changed:
What|Re
--- Comment #8 from paolo dot carlini at oracle dot com 2010-08-13 21:20
---
I'm not erring. We changes this behavior on purpose, after having also checked
that *2* other, completely independent, implementations agree (ie, Dinkumware
and Roguewave).
--
http://gcc.gnu.org/bug
--- Comment #6 from paolo dot carlini at oracle dot com 2010-08-13 21:00
---
You are of course wrong. Parsing something like "59e" as an integer type of
course succeeds and gives "59". Really, we have *tons* of testcases about that
in the testsuite. We kn
--- Comment #3 from paolo dot carlini at oracle dot com 2010-08-13 20:23
---
By the way, if you read 22.2.3.1 in C++98, it's clear that 'e' is *not* just
any other character: after 'e', a sign is optional but at least a digit is
compulsory.
--
ht
--- Comment #1 from paolo dot carlini at oracle dot com 2010-08-13 20:15
---
Yes, this is intended. We even have testcases about that.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
timing.cc
--
Summary: performance/ext/pb_ds/priority_queue_text_modify_down_ti
ming.cc fails at compile time
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: paolo dot carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45281
--- Comment #1 from paolo dot carlini at oracle dot com 2010-08-13 18:39
---
This has nothing to do with complex per se, it's simply about parsing nan,
infinity, and so on. We'll reconsider the issue in the context of C++0x (but as
a matter of fact I'm afraid we d
--- Comment #14 from paolo dot carlini at oracle dot com 2010-08-13 18:39
---
*** Bug 45279 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #14 from paolo dot carlini at oracle dot com 2010-08-13 18:00
---
Dave, any news on this? Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43738
--- Comment #37 from paolo dot carlini at oracle dot com 2010-08-13 13:31
---
(In reply to comment #36)
> I'm not sure you realize just how true that is. But keep going, you're
> by far one of the best trolls I've seen in GCC land.
Well, I can easily imagine mo
--- Comment #12 from paolo dot carlini at oracle dot com 2010-08-13 10:57
---
.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status
--- Comment #12 from paolo dot carlini at oracle dot com 2010-08-12 14:37
---
> It's Joaquín :-) You're welcome.
Sorry. I don't know what I was thinking.
> Perfect, let's do that. Regarding #579, last I heard from my contact
> in the committee is th
--- Comment #10 from paolo dot carlini at oracle dot com 2010-08-12 12:42
---
> My comments on your last two posts:
Thanks Manuel.
> I think the impact of this is independent of #579: even if erase
> does not return an iterator, the cached bucket pointer has to
> be
--- Comment #8 from paolo dot carlini at oracle dot com 2010-08-12 10:55
---
Maybe averaging over all possible keys, we are fine: the probability to erase
the first non-empty bucket is of the order 1 / # buckets, thus decreases
exactly as fast as # buckets grows. On the average the
--- Comment #58 from paolo dot carlini at oracle dot com 2010-08-12 10:18
---
.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status
--- Comment #7 from paolo dot carlini at oracle dot com 2010-08-12 10:02
---
In practice, I don't see how this issue can be tackled independently from the
complexity of erase returning iterator: adding a cache for the first non-empty
bucket is generally simple, but there is a pr
--- Comment #6 from paolo dot carlini at oracle dot com 2010-08-12 01:09
---
Working on this too.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #3 from paolo dot carlini at oracle dot com 2010-08-11 17:32
---
Ok, thanks. Let's ask for feedback then.
--
paolo dot carlini at oracle dot com changed:
What|Removed |
--- Comment #1 from paolo dot carlini at oracle dot com 2010-08-11 17:25
---
Andreas, can you have a look to this? I'm recategorizing it as target, I have
never seen anything similar on Linux (or anywhere else for that matter)
--
paolo dot carlini at oracle dot com ch
--- Comment #7 from paolo dot carlini at oracle dot com 2010-08-11 17:22
---
The solution involves clearing eofbit first, see US 137 / US 139. Maybe we
should prototype it before Batavia.
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #1 from paolo dot carlini at oracle dot com 2010-08-11 10:03
---
This is plain invalid: you are constructing a temporary ofstream and then
hoping to pass it to a constructor taking a ref, not a const ref, cannot work.
--
paolo dot carlini at oracle dot com changed
--- Comment #16 from paolo dot carlini at oracle dot com 2010-08-11 08:51
---
Done.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #7 from paolo dot carlini at oracle dot com 2010-08-11 07:26
---
Thanks for your feedback Ian. Now, I'm not sure which target maintainer to
suggest for powerpc-linux... David Edelsohn?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45053
--- Comment #43 from paolo dot carlini at oracle dot com 2010-08-11 07:08
---
Ok, even more obscure ;) Can you further investigate? Possibly pinging somebody
knowledgeable about the specs? Before applying to the library the -nostdinc++
bits I'd like to make sure we fully understan
--- Comment #1 from paolo dot carlini at oracle dot com 2010-08-11 07:06
---
Indeed, the library side of this is rather straightforward, we are already
implementing the FCD correctly (I also checked there no DRs or NBCs open):
template
inline pair::__type
--- Comment #41 from paolo dot carlini at oracle dot com 2010-08-11 01:23
---
We need a build system expert here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974
--
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 #14 from paolo dot carlini at oracle dot com 2010-08-11 01:09
---
Great, I'll do that.
--
paolo dot carlini at oracle dot com changed:
What|Removed |
--- Comment #12 from paolo dot carlini at oracle dot com 2010-08-10 23:48
---
Jon, is this actually GB 99? Trivially adding something like (& co, likewise
for shared_ptr):
template
inline bool
operator!=(const unique_ptr<_Tp, _Tp_Deleter>& __x, nullptr_t
--- Comment #37 from paolo dot carlini at oracle dot com 2010-08-10 22:18
---
Thus, does adding -nostdinc++ to the PCHs flags work for you?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974
--- Comment #1 from paolo dot carlini at oracle dot com 2010-08-10 08:17
---
What happens if you add -Wall to the command line? Current mainline tells me:
u.cc: In function void* foo(void*):
u.cc:12:31: warning: dereferencing type-punned pointer will break
strict-aliasing rules
u.cc
--- Comment #8 from paolo dot carlini at oracle dot com 2010-08-10 07:23
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #9 from paolo dot carlini at oracle dot com 2010-08-09 17:44
---
Ah, DR 691!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45236
--- Comment #3 from paolo dot carlini at oracle dot com 2010-08-09 14:20
---
This is certainly correct, and works as expected:
template struct foo;
template class C, int... II>
struct foo>
{
struct bar {};
};
template
struct A {};
foo<4, A<3>>::bar x;
--
--- Comment #2 from paolo dot carlini at oracle dot com 2010-08-09 14:18
---
To me:
template class C, int... II, int S>
with the variadic II in the middle and S without a default, seems badly
illegal. Jason, should we immediately produce a meaningful error when we see
--- Comment #1 from paolo dot carlini at oracle dot com 2010-08-09 14:11
---
I would say the problem isn't about "access" (even in non-technical sense),
instead that the specialization itself isn't considered: indeed, if you comment
it out, the error is exactly th
--- Comment #6 from paolo dot carlini at oracle dot com 2010-08-09 13:44
---
Note the specific constructor I mentioned:
// XXX http://gcc.gnu.org/ml/libstdc++/2008-02/msg00047.html
template
tuple(tuple<_UElements...>& __in)
we are *not* talking there about
--- Comment #4 from paolo dot carlini at oracle dot com 2010-08-09 13:31
---
Thanks for the clarification Jason. Indeed, I think the most robust fix is
using SFINAE, and actually we have already quite a bit of language in the FCD
about tuple constuctors vs constraining, I think it&#
--- Comment #13 from paolo dot carlini at oracle dot com 2010-08-09 07:31
---
Any help with it would be appreciated, thanks. In general, if you mean to
contribute it's a good idea to sort out first the Copyright Assignment
paperwork, which is actually very simple but takes time:
--- Comment #26 from paolo dot carlini at oracle dot com 2010-08-08 15:03
---
US 113, ES 2, US 118 / Issue 579 have been closed as NAD, thus let's figure out
how best obtain O(1) in our implementation...
--
paolo dot carlini at oracle dot com changed:
What|Re
--- Comment #11 from paolo dot carlini at oracle dot com 2010-08-08 14:57
---
Fixed for 4.5.2.
--
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 #8 from paolo dot carlini at oracle dot com 2010-08-08 14:47
---
Instead of waiting for the resolution of DR 1334, I'm going to resolve this by
adding in C++0x mode the overload:
operator=(const typename _Container::value_type&)
which is where 1334 is actua
--- Comment #2 from paolo dot carlini at oracle dot com 2010-08-07 22:19
---
Our std::tuple still needs work, but I see am inconsistency here between the
variadic and the non variadic case which I don't understand, irrespective of
library details. Consider the following re
--- Comment #3 from paolo dot carlini at oracle dot com 2010-08-07 16:32
---
Ok...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #9 from paolo dot carlini at oracle dot com 2010-08-06 06:53
---
*** Bug 45202 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #5 from paolo dot carlini at oracle dot com 2010-08-06 06:53
---
*** This bug has been marked as a duplicate of 42032 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #5 from paolo dot carlini at oracle dot com 2010-08-05 14:38
---
Ian, is this a libgcc issue? Can you suggest the best wa to triage it? Thanks.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from paolo dot carlini at oracle dot com 2010-08-05 09:34
---
*** This bug has been marked as a duplicate of 45191 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from paolo dot carlini at oracle dot com 2010-08-05 09:34
---
*** Bug 45193 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45191
--- Comment #1 from paolo dot carlini at oracle dot com 2010-08-03 06:48
---
Apparently this is still happening in mainline. Jason, can you have a look?
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #35 from paolo dot carlini at oracle dot com 2010-08-02 06:53
---
Thanks a lot Armand (by the way, many thanks to Ralf too)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974
101 - 200 of 2575 matches
Mail list logo
