[Bug c/35649] Incorrect printf warning: expect double has float
--- 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
[Bug c++/42315] [4.3/4.4/4.5/4.6 Regression] ICE with invalid array initializer
-- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|paolo dot carlini at oracle |unassigned at gcc dot gnu |dot com |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42315
[Bug libstdc++/41975] [C++0x] [DR579] unordered_set::erase performs worse when nearly empty
--- 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 scheme per Dinkum in the limit of high load factor, for small load factor is better because can use only one pointer instead of two for each bucket in the bucket list. All in all, if the requirements of throwing hash + erase complexity are combined, I don't think anything with a memory use similar to that of the singly linked schemes is possible. Joaquin, I think Matt would be in favor of a motion asking a re-opening of the issue in Batavia, what do you think? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41975
[Bug middle-end/45730] Undefined symbol __gnu_cxx::stdio_sync_filebufchar, std::char_traitschar ::xsgetn(char*, long)
--- 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 |Added Component|libstdc++ |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45730
[Bug libstdc++/42857] std::istream::ignore(std::streamsize n) calls unnecessary underflow
--- 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 These conditions are tested in the order shown.. In my opinion that means that the get and ignore overloads using the famous any of the following occurs can in principle check the conditions in *any* implementation defined order and being conforming. Now, we have a case here where we have an additional underflow because in our implementation we uniformly insist on always checking whether end-of-file occurs in the sequence, thus setting eofbit (besides the special case of ignore(), as already noticed) in that case, like the above mentioned getline does, for example. I want to understand how critical this additional underflow is, performance-wise, which, as far as I can see normally can be triggered only by passing in_avail to ignore, because otherwise, frankly, I find our consistent implementation defined behavior across the various get, getline, ignore overloads pretty nice. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42857
[Bug libstdc++/41975] [C++0x] [DR579] unordered_set::erase performs worse when nearly empty
--- 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: http://www.drdobbs.com/184403822 Nothing new, therefore. All the operations on iterators will become faster, not just computing the iterator returned by erase, on the other hand two pointers instead of one will be used for each element. -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||joaquin at tid dot es http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41975
[Bug libstdc++/45711] Building with --enable-libstdcxx-debug fails during install
--- 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 CC||ian at airs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45711
[Bug libstdc++/45711] Building with --enable-libstdcxx-debug fails during install
--- 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
[Bug libstdc++/41975] [C++0x] [DR579] unordered_set::erase performs worse when nearly empty
--- 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 from the minutes, I'm also asking again Matt whether he has anything else to suggest, but frankly I'm rather fed up with this issue, I mean to implement something that *works*, is *conforming* and then test it in the field. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41975
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- 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 AssignedTo|paolo dot carlini at oracle |unassigned at gcc dot gnu |dot com |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
[Bug libstdc++/45725] streambuf_iterator compares equal when it should not
--- 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 in the streambuf -- which, when dereferenced produce different characters -- nevertheless compare as equal. This is inconsistent with how other iterators work, and inconsistent with the pointer model of iterators. Maybe, but this is how, exactly those iterators are specified to behave, see 24.5.3.5 and 24.5.3.6 in the ISO C++ Standard which we are implementing. Also note that the current draft of the next ISO C++ Standard doesn't change that. Thus, as implementors, there is nothing we can do here, I'm sorry. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45725
[Bug libstdc++/45711] Building with --enable-libstdcxx-debug fails during install
--- 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
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- 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, where I also added two additional seekoff correctness testcases), which works in limited circumstances (enough to fix the testcase, anyway) when I can convince myself it's fully correct and consistent with our general framework. My plan is committing it first and then possibly generalizing it, always together with additional accompanying testcases, anyway. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Attachment #21769|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- 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. Thus, for now at least, I would rather not change it, whether the Standard is completely clear in this area or not. Also, I don't think the name __is_tell is appropriate, because of course this kinf of situation in principle can occur also when tell is not involved (like in your testcase ;) Modulo the above comments, I think we can enable the optimization for codecvt too, yes, let me reformat your other tweaks and more cleanly incorporate the !(_M_mode ios_base::out) thing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
[Bug libstdc++/45708] fstream reads after writes, or vice versa, don't work
--- 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 |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45708
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- 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**. Didn't happen by chance, was a deliberate redesign of the previous design which allowed major performance improvements. And, to be clear, nobody complained anymore, *ever* all these years. After you have analyzed those discussions (look in particular for Nathan Myers and me), we can consider, for the future, alternate designs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
[Bug libstdc++/45708] fstream reads after writes, or vice versa, don't work
--- 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 too), analyze the performance in the various circumstances, then we can reconsider those issues. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45708
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- 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://gcc.gnu.org/contribute.html send an email to assignments@ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- 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
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- 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 unified vs non-unified, if I remember correctly. At the time we moved *away* from what you essentially want, because we believed the new design to be superior in terms of performance. Anyway, if you want to propose something different, or a variant of the old design, please post messages to the libstdc++ mailing list, not here, remember to involve Nathan in the discussions, benchmark in various circumstances the various options, in particular, if you want something similar to the old scheme make sure you are *improving* on it. Remember, in practice, that in the 7 years since we moved to new scheme, **nobody ever** asked for the old behavior, nobody complained about the performance of basic_filebuf, thus, if, in the future, we are going to change it again, we really want to be sure to do it after a **very** serious and public analysis. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- 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 completely separate, with seeks switching between reading and writing via state variables, then it's fine, in principle. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- 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 with it. By the way, get and put areas never overlapped in the past, just look at the code in SVN, the movement of the pointers was synced, true, exactly because one wanted each area to somehow know what the other area was doing in order to more easily switch between reads and writes without seeks. And nobody liked that scheme, was slow and buggy. That happened way before I started contributing, for the record. Then the new design came, outlined by Nathan, and simply inspired by C stdio, nothing strange. As a matter of fact, many users found it also quite easy to use, because - in case wasn't clear already from my previous comments - **nobody ever** complained. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- 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 use seeks to switch, you have get and put areas completely independent, etc. As far as I know, **nobody** asked to have the old behavior back, not in Bugzilla, not in the mailing lists, nowhere in public discussions. Nobody **ever** commented **anywhere** that using seeks to switch was unusual, entire Linux distros have been quickly recompiled to use the new filebuf, we are now able to perform series of consecutive get or put almost as fast as C getc_unlocked and putc_unlocked (see the performance testsuite), etc. To summarize, I have nothing in principle against speeding up this and that (of course) but I do not accept comments implying that the current design is just wrong and should be changed to something else without a careful analysis, benchmarks, a discussion on the mailing list with all the experts involved, etc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
[Bug libstdc++/45711] Building with --enable-libstdcxx-debug fails during install
--- 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 developers normally use x86_64-apple-darwin, and without your help progress can be very slow on this issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45711
[Bug libstdc++/45711] Building with --enable-libstdcxx-debug fails during install
--- 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
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- 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 I remember is that Nathan Myers explained that C stdio, at least traditionally worked exactly like that, and since Nathan *designed* parts of the first C++ Standard itself, actively participated to all the meetings which led to C++98, I trusted him by and large and found the new design straightforward and well performing in most of out benchmarks. I still believe he was quite right. Anyway, when you post something to the mailing list, remember to add him in CC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
[Bug libstdc++/45713] sizeof std::bitsetULONG_MAX == 1
--- 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... -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-17 23:53:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45713
[Bug libstdc++/45711] Building with --enable-libstdcxx-debug fails during install
--- 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: What|Removed |Added CC||rwild at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45711
[Bug libstdc++/45713] sizeof std::bitsetULONG_MAX == 1
--- 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 Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45713
[Bug c/45691] Floating point comparison failure
--- 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/show_bug.cgi?id=45691
[Bug c/45691] Floating point comparison failure
--- 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
[Bug c++/45665] [4.4/4.5 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in grokdeclarator, at cp/decl.c:8797 on invalid code
--- 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 AssignedTo|paolo dot carlini at oracle |unassigned at gcc dot gnu |dot com |dot org Status|ASSIGNED|NEW Known to fail|4.4.5 4.5.2 4.6.0 |4.4.5 4.5.2 Known to work|4.4.2 |4.4.2 4.6.0 Summary|[4.4/4.5/4.6 Regression]|[4.4/4.5 Regression] ICE: |ICE: tree check: expected |tree check: expected class |class 'type', have |'type', have 'exceptional' |'exceptional' (error_mark) |(error_mark) in |in grokdeclarator, at |grokdeclarator, at |cp/decl.c:8797 on invalid |cp/decl.c:8797 on invalid |code|code Target Milestone|4.4.5 |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45665
[Bug c++/45665] [4.4/4.5/4.6 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in grokdeclarator, at cp/decl.c:8797 on invalid code
--- 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 AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-14 10:46:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45665
[Bug c++/42033] libstdc++ seems to miss std::basic_stringchar, std::char_traitschar, std::allocatorchar ::basic_stringchar*(char*, char*, std::allocatorchar const)
--- 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
[Bug c++/45651] [4.3/4.4/4.5/4.6 Regression] ICE in import_export_decl, at cp/decl2.c:2344
--- 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 CC||hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45651
[Bug c++/45645] pr44972.C fails with error: �__assert_fail� was not declared in this scope
--- 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
[Bug c++/45645] pr44972.C fails with error: �__assert_fail� was not declared in this scope
--- 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
[Bug c++/45651] [4.3 / 4.4 / 4.5 / 4.6 Regression] ICE in import_export_decl, at cp/decl2.c:2344
--- 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 Summary|internal compiler error: in |[4.3 / 4.4 / 4.5 / 4.6 |import_export_decl, at |Regression] ICE in |cp/decl2.c:2344 |import_export_decl, at ||cp/decl2.c:2344 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45651
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- 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(0, cur) - 'something' - which is not available anywhere. I'm not saying it cannot be implemented, I'm very dubious it can without breaking the ABI by adding an additional data member, which we cannot do at the moment. To be honest I also don't think the issue is very serious if only because nobody complained in 7 years, and we have a lot to do for C++0x. Thus, if you can help with something concrete minimally passing the testsuite and clearly addressing the concerns above, excellent, otherwise, I cannot anticipate now when we are going to do something here. Just to be honest. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- 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 testcase reading in in the buffer, say, 0123456789, then seeking to 0, reading consecutive positions up to 5 via simple get, calling seekoff(0, cur), put x in the place of 5. Then close, reopen, and check that you have 01234x6789. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- 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 to traditional C stdio impls, reading and writing are completely separate operations, and the user switches between the two with seeks, essentially. Any seek puts back the internal status to uncommitted (_M_reading = false, _M_writing = false) and afterwards the user can start *either* reading or writing, irrespective of the previous history, and the seek logic doesn't know what will actually happen in the future, of course. The user should not perform redundant seeks, because they have a cost, they do something more than just seeking. On the other hand, a series of read or write operations has maximum performance, we don't think we could possibly do better. Thus, I'm open to ideas, but I don't think that within the current design one can change / improve much. Note that the patch you linked is exactly the one implementing the above semantics. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- 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 again, the get area remains completely valid indeed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
-- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-10 12:11:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- 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/show_bug.cgi?id=45628
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- 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 position, belonging to the buffer, the physical position along the file also changes of course, an underlying fseek is performed. Then, if we don't refresh the buffer with a new underflow, an inconsistency is born: the physical position along the file doesn't correspond to the first char after the buffer and the next underflow will read from the wrong position. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- 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 for off == 0, and this is not what we have been doing. I think there is something seriously different here, beyond the performance issue, which we should ponder much more, after so many years. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- 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(..., width * off, ...) as the standard mandates. Then dealing with off == 0 becomes simple. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- 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 called, not just fseek(0) in the special case you care about. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- 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
[Bug libstdc++/45574] cin.getline() is extremely slow
--- 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 suggest having first a minimal patch, limited to char, limited in any way ;) but still sufficient to bring most of the improvement we are aiming to within the ABI. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45574
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- 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 puzzled. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- 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 the concept of __computed_off and, in many cases we end up calling the equivalent of fseek with something != off * width. I'm changing that to (0, cur) for the case you care about, but not changing anything else otherwise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- 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
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- 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
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- 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 testing and this specific testcase, but is incomplete vs wchar_t. If you have something which you are confident works fine for wchar_t too, I can give it a try later today or over the next days, thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- 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/bugzilla/show_bug.cgi?id=45628
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- 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
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- 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
[Bug libstdc++/45628] std::fstream::tellg invalidates I/O buffer
--- 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 *writes* follow the seek. After a while the buffer becomes full and must be flushed to the file starting at the logical position corresponding to the previous seek. Thus - it seems to me - the file pointer must be finally adjusted. How to do that without saving anything in the filebuf? (note that within the current ABI we cannot add data members) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45628
[Bug c++/45601] explicit template instantiation problem
--- 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 about the cost of the document, if you are serious about C++ you should buy it as you buy books and everything else, is also rather cheap. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45601
[Bug c++/45603] cc1plus crashes in build_addr_func
-- paolo dot carlini at oracle dot com changed: What|Removed |Added Severity|blocker |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45603
[Bug libstdc++/45574] cin.getline() is extremely slow
--- 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 functions, we know those glibc extensions exist, but, as far as I can see would only change the complexity by a not so so small multiplicative constant and, after years and years of using everywhere the normal versions, I don't believe we should change just now the configuration on Linux only. But, as I said, provided you don't break the ABI (to be concrete) and the improvements are substantive, you are certainly welcome to submit patches to the libstdc++ mailing list. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45574
[Bug c++/45603] cc1plus crashes in build_addr_func
--- 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/show_bug.cgi?id=45603
[Bug libstdc++/45574] cin.getline() is extremely slow
--- 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_ and measure, on Linux). In terms of the C++ Standard, I think that C++98 would allow essentially *anything*, not so C++0x, and within C++98 too I'm afraid we can break code making already some assumptions about the thread safety, which we don't spell out anywhere as impl def behavior, still... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45574
[Bug libstdc++/45613] bits/random.h misses include guards
--- 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 at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-09 10:44:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45613
[Bug libstdc++/45613] bits/random.h misses include guards
--- 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 Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45613
[Bug libstdc++/45574] cin.getline() is extremely slow
--- 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 it without breaking the ABI I would be in favor of having it immediately - still, we would still use a single char function, I think the complexity for long lines would still scale badly. As a matter of fact, I think the only completely satisfactory design would be that used by the old v2, with a low level libio layer, doing buffering and the low level operations, and used by the C and C++ libraries on top. Missing that, I don't think the C++ library, working purely on top of the Standard C library will ever be able to performe as well as C in the synced mode. The only hope could be exploiting, on Linux systems, a glibc *extension* (we do that in many other cases), like an fgetc not writing '\0' and newline, which the glibc people would essentially provide exactly to help the C++ library implementation. Anyway, sorry if I may have appeared a little too harsh in my first replies, the fact is I know the history of these facilities, I know all the effort other people besides me put to have a good overall compromise (eg, stdio_sync isn't mine and solved a *a lot* of problems), we are certainly open to improvements, but realistic ones, at least until we break all the ABIs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45574
[Bug libstdc++/45574] cin.getline() is extremely slow
--- 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=45574
[Bug c++/45606] [4.5/4.6 Regresssion] match a method prototyped a typedef alias with the original type (using stdlib)
--- 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 CC||hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45606
[Bug c++/45618] GCC 4.4.4 strstream and ios::internal flag
--- 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. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45618
[Bug libstdc++/45574] cin.getline() is extremely slow
--- 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 no syncing. or to Loren Rittle, who closed bug 5001 as resolved fixed in 2003, declaring This issue was addressed by gcc 3.2.X such that sync_with_stdio was no longer required for reasonable performance. And indeed it's true. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45574
[Bug libstdc++/45574] cin.getline() is extremely slow
--- 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 are not changing glibc here. The C++ library does *not* use buffering in the synced mode, and it does otherwise, for fstreams in particular. Where do you think the performance difference is essentially coming from? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45574
[Bug libstdc++/45574] cin.getline() is extremely slow
--- 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 as-is as an implementation detail. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45574
[Bug c++/45594] g++ incorrectly treats inline function redefinition
--- 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
[Bug c++/45601] explicit template instantiation problem
--- 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 from the Standard point of view, at the moment I'm just curious to understand how you came to that conclusion. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45601
[Bug c++/45601] explicit template instantiation problem
--- 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 |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45601
[Bug c++/45603] cc1plus crashes in build_addr_func
--- 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://gcc.gnu.org/bugzilla/show_bug.cgi?id=45603
[Bug libstdc++/45574] ifstream::getline() is extremely slow
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45574
[Bug libstdc++/45574] ifstream::getline() is extremely slow
--- 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. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45574
[Bug libstdc++/45398] [C++0x] Missing atomic_Tp*::store definition
--- 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 AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|NEW |ASSIGNED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45398
[Bug libstdc++/45398] [C++0x] Missing atomic_Tp*::store definition
--- 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
[Bug libstdc++/43451] [C++0x] atomic integral methods missing volatile overloads
--- 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
[Bug libstdc++/45398] [C++0x] Missing atomic_Tp*::store definition
--- 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 Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.6.0 |4.5.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45398
[Bug libstdc++/45549] merge is_iterator into iterator_traits
--- 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 the other way around. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45549
[Bug c++/44737] ICE in instantiate_decl
--- 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
[Bug libstdc++/45574] ifstream::getline() is extremely slow
--- 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 speed-up special cases, but also given that in ~5-7 years nobody else reported anything about the performance of the synced getline, I don't think anything is going to happen anytime soon, I could keep this open, but it would be futile, we have a lot of work to do, for C++0x, in particular. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45574
[Bug libstdc++/45574] ifstream::getline() is extremely slow
--- 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 see something more similar to 9-10x, which, considering that a real synced mode must be unbuffered, seems completely reasonable to me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45574
[Bug libstdc++/43451] [C++0x] atomic integral methods missing volatile overloads
--- 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
[Bug c++/45588] unused-but-set-variable false trigger building gold
--- 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 CC||jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45588
[Bug libstdc++/45549] merge is_iterator into iterator_traits
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45549
[Bug libstdc++/45549] merge is_iterator into iterator_traits
--- 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 functions, completely new in C++0x, getting a bit of constraining in the return type, no additional defaulted template parameters, only constraining in the return type: I would argue tha, in general, the way we are living the post-concepts era, this is more or less something the user looking inside headers of C++ library implementations is going to find in *many* more places than those where the Standard explicitly talks about does not participate to overload resolution. I can also add that this very thing makes me a little nervous, but I didn't raise the issue explicitly anywhere, thus... Anyway, in the other case, we are talking about changing a fundamental building block of the library. Certainly we would do that only in C++0x mode, agreed, still we are diverging more from C++03 in an area where the Standard is *not* diverging at all: as far as I can see, either we could use a defaulted template parameter with the enable_if on __is_iterator for the default; or we could create a small hierarchy, without enable_if. This is not something I would deliver for C++03 too, after so many years with a straightforward implementation, definitely not. Do you have in mind a simpler way to implement the smart iterator_traits? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45549
[Bug libstdc++/45549] merge is_iterator into iterator_traits
--- 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... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45549
[Bug libstdc++/45549] merge is_iterator into iterator_traits
--- 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=45549
[Bug libstdc++/45549] merge is_iterator into iterator_traits
--- 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
[Bug libstdc++/45549] merge is_iterator into iterator_traits
--- 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=45549
[Bug c++/45542] std::pow(float) converts to double when compiled with -std=gnu++0x
--- 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 |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45542
[Bug c++/45542] std::pow(float) converts to double when compiled with -std=gnu++0x
--- 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 the FCD, for sure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45542
[Bug c++/45542] std::pow(float) converts to double when compiled with -std=gnu++0x
--- 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 with the resolution suggested by Howard, at the time, and frankly I don't thick the DR should be re-opened. CERN should send somebody to the ISO Meetings, like Fermilab does... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45542
[Bug libstdc++/45549] merge is_iterator into iterator_traits
--- 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 (and possibly the 4 other types), iterator_traitsT is empty (instead of containing 5 broken typedefs). I don't think I can work on this very soon, and I also believe that __is_iterator can be useful anyway, maybe Jon has more tho say (or do) in this area... Anyway, are you sure that, given the current wording in C++0x, such iterator_traits is strictly conforming? -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||jwakely dot gcc at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45549
[Bug c++/45542] std::pow(float) converts to double when compiled with -std=gnu++0x
--- 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 only allowed, is encouraged! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45542
