--- Comment #7 from paolo dot carlini at oracle dot com 2010-09-22 20:38
---
I have a deja vu
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35649
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|paolo dot carlini at oracle |unassigned at gcc dot gnu
|dot com
--- Comment #30 from paolo dot carlini at oracle dot com 2010-09-21 17:55
---
More correctly (in the meanwhile went through a exchange at the beginning of
this year), Howard stores the hash, which boils down to a memory requirement
similar to that of the traditional doubly linked list
--- Comment #5 from paolo dot carlini at oracle dot com 2010-09-20 09:56
---
Thus, I would say middle-end? However, certainly doesn't happen on Linux, for
some reason... Honza, in case please recategorize.
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #2 from paolo dot carlini at oracle dot com 2010-09-20 12:15
---
I was having a second look to this issue, and noticed something more which I
missed the first time: the Standard, *only* in the case of getline(char_type*,
streamsize, char_type) explicitly says
--- Comment #27 from paolo dot carlini at oracle dot com 2010-09-20 17:23
---
Unless somebody posts here over the next two/three days or so *concrete* ideas
of a different sort, I'm going to simply work on a doubly linked list solution,
along the lines of the section iterator here
--- Comment #9 from paolo dot carlini at oracle dot com 2010-09-20 17:28
---
Ian, I suppose the iant cited by Andrew it's you: any more constructive tip?
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #11 from paolo dot carlini at oracle dot com 2010-09-20 17:35
---
I understand that some such hobbyists have a rather serious paid work ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45711
--- Comment #29 from paolo dot carlini at oracle dot com 2010-09-20 17:41
---
I'm not aware of any singly linked list implementation, to be honest. I know
that Dinkumware already uses doubly, and, if I'm not wrong, Howard just moved
to it. I'll send you privately the rationale I have
--- Comment #56 from paolo dot carlini at oracle dot com 2010-09-20 21:32
---
David himself is on it.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from paolo dot carlini at oracle dot com 2010-09-19 09:18
---
(In reply to comment #0)
bool std::operator==( std::istreambuf_iterator, std::istreambuf_iterator )
returns TRUE if both iterators are EOF or both are not. That means two
iterators at different places
--- Comment #8 from paolo dot carlini at oracle dot com 2010-09-18 08:39
---
Thanks Ralf, I was sure you would have something sensible to say here. And,
please, feel free to self assign ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45711
--- Comment #37 from paolo dot carlini at oracle dot com 2010-09-17 12:42
---
Created an attachment (id=21819)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21819action=view)
Tested x86_64-linux, mainline
This is a carefully tested patch (tested in mainline, per the normal policy
--- Comment #40 from paolo dot carlini at oracle dot com 2010-09-17 18:53
---
In general, our users know that seeking allows to switch from reading to
writing, and viceversa (when the stream has been appropriately opened of
course). This assumption remained true for years and years
--- Comment #1 from paolo dot carlini at oracle dot com 2010-09-17 19:03
---
Not going to happen, at least not until the very far future, in the occasion of
an ABI bump or a global redesign.
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #42 from paolo dot carlini at oracle dot com 2010-09-17 19:10
---
Before any other bug or analysis, I would recommend going back to the ton of
discussions in 2002 / 2003 when the design of basic_filebuf has been changed to
use _M_reading and _M_writing, **on purpose
--- Comment #3 from paolo dot carlini at oracle dot com 2010-09-17 19:12
---
This is a major redesign in any case, which would change completely the user
experience. Again, please analyze carefully all the discussions which led to
the current design (possibly get in contact with Nathan
--- Comment #44 from paolo dot carlini at oracle dot com 2010-09-17 19:17
---
By the way, if, for the future, you mean to contribute in these areas, if you
are really interested in these topics, I would recommend starting immediately
the Copyright assignment paperwork http
--- Comment #46 from paolo dot carlini at oracle dot com 2010-09-17 19:26
---
Ok, thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
--- Comment #47 from paolo dot carlini at oracle dot com 2010-09-17 19:38
---
To further clarify: what you have in mind isn't something which can belong to a
casual PR, is a major redesign of basic_filebuf, according to a different basic
philosophy, which at the time, Nathan called
--- Comment #49 from paolo dot carlini at oracle dot com 2010-09-17 19:50
---
It was **a ton** of work and discussions in public and among the maintainers,
in private. Anyway, if you have something which doesn't touch basic_streambuf,
keeps the get and put areas of basic_filebuf
--- Comment #51 from paolo dot carlini at oracle dot com 2010-09-17 20:07
---
If you can allow writes after reads and viceversa *also* without seeks in the
middle, and without affecting performance and without adding data members,
that's fine. Let's see what you come up
--- Comment #53 from paolo dot carlini at oracle dot com 2010-09-17 21:22
---
What can I say, I don't know anybody still using GCCs dating back to 2003. In
any case, my point wasn't really about seek(0, cur) and its optimization, etc,
my point was about the general design, where you
--- Comment #2 from paolo dot carlini at oracle dot com 2010-09-17 21:33
---
This doesn't happen on Linux, seems a Target issue. Please try to figure out
much more exactly when the problem started (possibly which specific revision,
use SVN), because very few among the C++ library
--- Comment #4 from paolo dot carlini at oracle dot com 2010-09-17 21:43
---
So, did this change recently?!?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45711
--- Comment #55 from paolo dot carlini at oracle dot com 2010-09-17 21:59
---
I'm
getting the impression that you guys got tired after a long redesign process
and oversimplified the state machine.
Not me. What
--- Comment #1 from paolo dot carlini at oracle dot com 2010-09-17 23:53
---
Confirmed, I will apply a variant (__n is unsigned here and the original
expression can be simplified) of your patch momentarily, after testing. Of
course the issue is really noticeable only on 32-bit machines
--- Comment #6 from paolo dot carlini at oracle dot com 2010-09-18 00:42
---
I used to, and tried again moments ago, everything is fine here. Maybe we are
talking about another path?!? I'm puzzled. Let's add in CC Ralf...
--
paolo dot carlini at oracle dot com changed
--- Comment #3 from paolo dot carlini at oracle dot com 2010-09-18 01:31
---
Fixed for 4.6.0.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from paolo dot carlini at oracle dot com 2010-09-16 17:08
---
As an even more general rule, remember to always specify your target: in this
case, for example, I can't reproduce at all the behavior on x86_64 -m64, only
with -m32.
--
http://gcc.gnu.org/bugzilla
--- Comment #5 from paolo dot carlini at oracle dot com 2010-09-16 17:15
---
Thanks Jakub.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45691
--- Comment #4 from paolo dot carlini at oracle dot com 2010-09-15 09:08
---
Fixed for 4.6.0.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from paolo dot carlini at oracle dot com 2010-09-14 10:46
---
Seems simple
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #9 from paolo dot carlini at oracle dot com 2010-09-13 15:22
---
What's going on with this? Is there something I can do to help resolving it for
good?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42033
--- Comment #2 from paolo dot carlini at oracle dot com 2010-09-13 16:01
---
Seems a rather annoying regression, let's ask H.J. a binary search...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #4 from paolo dot carlini at oracle dot com 2010-09-13 17:12
---
I agree with Jon: the expansion of assert to __assert_fail, etc, isn't
portable, the testcase should simply use assert.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45645
--- Comment #6 from paolo dot carlini at oracle dot com 2010-09-13 21:01
---
Please properly post the patch to the mailing list and let's resolve this
rather straightforward issue. Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45645
--- Comment #1 from paolo dot carlini at oracle dot com 2010-09-12 13:46
---
Happens in 4_2-branch too, 4_1-branch was fine.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #34 from paolo dot carlini at oracle dot com 2010-09-11 09:21
---
Run the full testsuite, and you will see. In general, if you simply do fseek(0,
cur) and then start writing, when eventually you have to flush you need the
actual logical position in the file - the last fseek
--- Comment #36 from paolo dot carlini at oracle dot com 2010-09-11 10:03
---
I'm traveling. Note, I don't understand how you are addressing my concerns,
thus whatever results you get from the testsuite, make sure we are not
regressing on the situation I outlined, thus write a new
--- Comment #2 from paolo dot carlini at oracle dot com 2010-09-10 10:55
---
_M_terminate_output, correctly, does nothing in this case, cannot be the
problem, and there is nothing wrong wrt the standard mandated behavior. The
problem is that in our implementation, similarly
--- Comment #3 from paolo dot carlini at oracle dot com 2010-09-10 12:09
---
I *think* it can work to minimally change what we have now to not reset the get
area buffers when (0, ios::cur) and we have been reading: as far as I can see,
if in that specific case we get back to reading
--
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 #4 from paolo dot carlini at oracle dot com 2010-09-10 12:20
---
Does not work: when we reach the end of the buffer and we access again the file
to refill it, we start reading from the wrong position, the position we seeked
to.
--
http://gcc.gnu.org/bugzilla
--- Comment #5 from paolo dot carlini at oracle dot com 2010-09-10 12:36
---
To clarify: when we start reading in a buffered mode, the first underflow reads
the buffer and leaves the physical file at the first char beyond the buffer. If
we do afterwards a seek to the current reading
--- Comment #7 from paolo dot carlini at oracle dot com 2010-09-10 14:39
---
Then, seekoff would also return a position beyond the buffer, right? Or you
want it to return 1 anyway? Actually, I think the standard want us to use width
* off for the underlying fseek anyway, not only
--- Comment #9 from paolo dot carlini at oracle dot com 2010-09-10 15:00
---
Ok. I don't think we should change the code to deal such specially with off ==
0, if we are going to change it we should decouple the return value from what
the underlying seek returns, and always call fseek
--- Comment #11 from paolo dot carlini at oracle dot com 2010-09-10 15:19
---
Sure. What I meant - contrary to wait you said, I think - is that an elegant
and complete solution to this issue involves changing much more generally our
code to *always* behave as if fseek(off * width) were
--- Comment #13 from paolo dot carlini at oracle dot com 2010-09-10 15:45
---
Good, I think we are close to a fix, I'm already testing something. So, do we
have a symmetric issue with the put area or not? I'm not sure.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
--- Comment #25 from paolo dot carlini at oracle dot com 2010-09-10 16:01
---
Good. Please give me a couple of days to come to your code. Note, since you
don't have a Copyright Assignment on file, it will be difficult to fully
acknowledge your work in the ChangeLog. Thus, I would
--- Comment #16 from paolo dot carlini at oracle dot com 2010-09-10 17:11
---
Actually, however, I don't think we can really always call fseek(off * width)
as the Standard want us to do. In a sense I'm happy because the change is gonna
be less invasive, on the other hand I'm a bit
--- Comment #18 from paolo dot carlini at oracle dot com 2010-09-10 17:29
---
I'm almost ready for the patch, please be patient ;) If look at the standard,
it says that the last step of seekoff is *always* as if calling fseek(..., off
* width, ...). If look at the current code, we have
--- Comment #19 from paolo dot carlini at oracle dot com 2010-09-10 17:30
---
Of course here I'm always under the assumption width 0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
--- Comment #22 from paolo dot carlini at oracle dot com 2010-09-10 17:42
---
Good. Then I have a draft almost ready ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
--- Comment #24 from paolo dot carlini at oracle dot com 2010-09-10 19:01
---
Created an attachment (id=21768)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21768action=view)
Draft
This is what I have so far, unfortunately I cannot work only on this today.
Anyway, it passes
--- Comment #27 from paolo dot carlini at oracle dot com 2010-09-10 19:31
---
Note that certainly we don't want to use C++0x stuff here. Also, one thing at a
time of course, thus if we have been missing some error checking, etc, it's for
another time.
--
http://gcc.gnu.org
--- Comment #28 from paolo dot carlini at oracle dot com 2010-09-10 19:34
---
PS: you are right that we have to check that _M_seek succeeds before adding
back __computed_off.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
--- Comment #29 from paolo dot carlini at oracle dot com 2010-09-10 19:51
---
And, please, if you want to help, manage to run the testsuite, we have got some
pretty nasty testcases ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
--- Comment #31 from paolo dot carlini at oracle dot com 2010-09-11 04:27
---
I'm afraid that the situation I outlined in Comment #5 is just the simple one.
The real problem with the new scheme - which tries to deal specially with (0,
cur) by not moving the file pointer - is when
--- Comment #7 from paolo dot carlini at oracle dot com 2010-09-09 09:16
---
The current ISO document, C++98 or C++03 which contains some rather small
amendments: if C++0x were different it would show only when -std=c++0x is
passed. In any case, it's unfortunate but we cannot do much
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Severity|blocker |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45603
--- Comment #15 from paolo dot carlini at oracle dot com 2010-09-09 09:25
---
If you write a patch it would be of course looked at. But *please* try first
something that doesn't break the ABI, because we have *no* idea when you
changes would be applied otherwise. About the *_unlocked
--- Comment #9 from paolo dot carlini at oracle dot com 2010-09-09 09:43
---
(In reply to comment #8)
(BTW, where did you find that they should be declared throw()?
If you open cxxabi.h, you can see _GLIBCXX_NOTHROW after release and abort.
--
http://gcc.gnu.org/bugzilla
--- Comment #17 from paolo dot carlini at oracle dot com 2010-09-09 10:42
---
At some point I tried quickly replacing some getc, did notice an improvement of
course, but of the order of magnitude I mentioned. Worth further investigating
sure (and simple, just replace in stdio_sync_
--- Comment #1 from paolo dot carlini at oracle dot com 2010-09-09 10:44
---
You are right, random.tcc too actually. Should not be too risky because those
are internal headers, not meant to be included directly by the users. Still,
I'll fix momentarily, thanks.
--
paolo dot carlini
--- Comment #3 from paolo dot carlini at oracle dot com 2010-09-09 11:25
---
Done.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #20 from paolo dot carlini at oracle dot com 2010-09-09 14:53
---
Good about POSIX, we would add a configure time test with some hope to enable
the mechanism outside Linux too. Anyway, I'm sure your kind of loop would
improve the performance a lot - if only we could have
--- Comment #22 from paolo dot carlini at oracle dot com 2010-09-09 16:08
---
Jakub, when, by default, cin co boil down to stdio_sync_filebuf, the
underlying basic_streambuf is unbuffered, everything is unbuffered in the C++
library.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #2 from paolo dot carlini at oracle dot com 2010-09-09 16:56
---
H.J. can you do a binary search on this?
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from paolo dot carlini at oracle dot com 2010-09-09 19:59
---
The output seems perfectly fine to me: at the end of Stage 1 we have 0x7b,
exactly what one gets from printf(%p, (void*)123), per 22.2.2.2.2/12, then,
per Table 61, padding is added after x, thus 0x@@7b
--- Comment #10 from paolo dot carlini at oracle dot com 2010-09-08 09:56
---
(In reply to comment #8)
Maybe you should tell that to Paolo Carlini, who closed bug 15002 as resolved
fixed in 2004,
And it *is* fixed. Did you actually open the testcases? Just plain fstreams,
thus
--- Comment #11 from paolo dot carlini at oracle dot com 2010-09-08 09:59
---
(In reply to comment #8)
But a 9-10x difference doesn't sound reasonable to me. The synced mode is not
unbuffered, before or after my suggested change, it uses the internal buffer
in
glibc.
So? We
--- Comment #12 from paolo dot carlini at oracle dot com 2010-09-08 10:20
---
By the way, getdelim is not standard, thus would work only on linux, even more
special casing. More importantly, fgets *stores* newline and '\0', at variance
with getline, I don't think it can be used
--- Comment #7 from paolo dot carlini at oracle dot com 2010-09-08 12:21
---
new?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45594
--- Comment #3 from paolo dot carlini at oracle dot com 2010-09-08 16:44
---
Please clarify: As far as I can find on the net, it should work. No compiler
to which I have access compiles it, I tried, besides GCC, Intel, SunStudio,
Comeau, VC++8. Note I didn't really analyze the testcase
--- Comment #4 from paolo dot carlini at oracle dot com 2010-09-08 16:58
---
Actually, it seems pretty straightforward to me that S is nondeduced in the
last case: see 14.8.2.4/4, the last line.
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #1 from paolo dot carlini at oracle dot com 2010-09-08 23:31
---
Note, if you really need the name __cxa_guard_acquire to trigger the bug, which
is in the implementor namespace, due to the double underscore in front, this
is a low priority ICE on *illegal*.
--
http
--- Comment #1 from paolo dot carlini at oracle dot com 2010-09-07 09:42
---
If the problem is in the stdio sync code, then file a glibc PR.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #3 from paolo dot carlini at oracle dot com 2010-09-07 11:15
---
There is nothing we can do to speed up further the v3 side of the synced code,
thus, unless you have evidence that other implementations perform much better
than v3, and provide details, this is closed
--- Comment #3 from paolo dot carlini at oracle dot com 2010-09-07 13:19
---
Seems trivial, just matter of forwarding to atomic_address...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #4 from paolo dot carlini at oracle dot com 2010-09-07 13:25
---
Here, I'm only adding the non-volatile version, the rest of the volatile
overloads belong to PR43451.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45398
--- Comment #3 from paolo dot carlini at oracle dot com 2010-09-07 13:28
---
By the way the same problem exists for the atomicT* partial specialization.
In general, audit for volatile.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43451
--- Comment #7 from paolo dot carlini at oracle dot com 2010-09-07 14:16
---
Done, for 4.6.0 and 4.5.2.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #12 from paolo dot carlini at oracle dot com 2010-09-07 14:59
---
I think we should apply it and see how it goes. I'm thinking that after all we
are not risking much: the class is empty anyway (in terms of ABI) and we are
not risking rejecting valid iterators, only
--- Comment #4 from paolo dot carlini at oracle dot com 2010-09-07 17:34
---
Maybe related to PR44118, both ICE on the same gcc_assert
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44737
--- Comment #5 from paolo dot carlini at oracle dot com 2010-09-07 17:49
---
For sure we cannot add virtual functions to basic_streambuf without breaking
the ABI. Also, getline certainly isn't just fgets, takes a delim char, uses
traits, etc. Sure, anyway, in principle you can often
--- Comment #6 from paolo dot carlini at oracle dot com 2010-09-07 17:55
---
By the way, I don't know anything about your testcase (it would be a good idea
attaching something here, just in case), but on my machines, i7 mostly, I don't
see anything similar to your performance gap, I
--- Comment #5 from paolo dot carlini at oracle dot com 2010-09-07 22:15
---
That would be just great!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43451
--- Comment #2 from paolo dot carlini at oracle dot com 2010-09-07 22:28
---
Let's add Jakub in CC.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #14 from paolo dot carlini at oracle dot com 2010-09-07 22:32
---
Done.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #3 from paolo dot carlini at oracle dot com 2010-09-06 09:42
---
(In reply to comment #2)
It doesn't seem less conforming than what is used for
next/prev.
Well, I think we are comparing two changes of very different impact and size.
In the case of next / prev we have two
--- Comment #5 from paolo dot carlini at oracle dot com 2010-09-06 11:42
---
Nice that we agree on many points. Anyway, my plan would be (I cannot resist ;)
preparing a small prototype, using the hierarchy, attach it here, and wait for
Jon' opinion. Then we can make the final decision
--- Comment #7 from paolo dot carlini at oracle dot com 2010-09-06 12:32
---
Me, me ;) But, to be clear, your help here and elsewhere would be more than
welcome. If there is something I can do about the paperwork, just let me know!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #8 from paolo dot carlini at oracle dot com 2010-09-06 17:08
---
Created an attachment (id=21713)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21713action=view)
Draft patch, tested x86_64-linux
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45549
--- Comment #10 from paolo dot carlini at oracle dot com 2010-09-06 20:36
---
Created an attachment (id=21716)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21716action=view)
The aforementioned variant, again tested x86_64-linux
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #1 from paolo dot carlini at oracle dot com 2010-09-05 12:42
---
There is nothing to fix here, see:
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #3 from paolo dot carlini at oracle dot com 2010-09-05 15:36
---
The issue affects only mixed mode arithmetic (thus, functions taking at least
two arguments), and in that case, as Howard explained, C++0x does what Fortran
and C do. In any case, we are implementing correctly
--- Comment #4 from paolo dot carlini at oracle dot com 2010-09-05 16:15
---
By the way, if a function taking a single argument is passed and integer, the
return type is double, not float or long double and one can see that the
underlying mechanism is the same. All in all, I agreed
--- Comment #1 from paolo dot carlini at oracle dot com 2010-09-05 22:22
---
(In reply to comment #0)
An alternative solution seems to be to use this same machinery in the
definition of iterator_traits so that when a class T is not a pointer and does
not provide iterator_category
--- Comment #6 from paolo dot carlini at oracle dot com 2010-09-05 23:01
---
Ok... We can discuss these issues in better detail when we met. Well, remember
that this is Free Software, thus, if you are unsure about a behavior, just open
the header in an editor and look inside it: isn't
1 - 100 of 2536 matches
Mail list logo
