[Bug libstdc++/37957] Wrong behaviour of num_get<>::do_get(bool) in the case when one target sequence is a prefix of the other one
--- Comment #3 from paolo dot carlini at oracle dot com 2008-11-11 12:08 --- . -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37957
[Bug libstdc++/38081] time_get<>::do_get_weekday does not always recognize full names of weekdays
--- Comment #2 from paolo dot carlini at oracle dot com 2008-11-11 13:50 --- Ok. -- 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 |2008-11-11 13:50:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38081
[Bug libstdc++/37986] std::tr1::variate_generator does not conform to TR1.
--- Comment #3 from paolo dot carlini at oracle dot com 2008-11-11 14:33 --- Fixed for 4.4.0. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37986
[Bug libstdc++/38000] [4.3/4.4 Regression] System header files not found once -isystem /usr/include is used
--- Comment #4 from paolo dot carlini at oracle dot com 2008-11-11 12:48 --- I think the use of include_next started with Benjamin's patch of 2007-03-04, adding c_global. Benjamin, can you look into this issue? Otherwise, missing a solid rationale, for 4.4.0 I would just remove the uses, per Jakub' suggestion. -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||paolo at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38000
[Bug libstdc++/38000] [4.3/4.4 Regression] System header files not found once -isystem /usr/include is used
-- 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 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38000
[Bug libstdc++/36505] C++ includes do not work
--- Comment #5 from paolo dot carlini at oracle dot com 2008-11-12 10:12 --- May be related to libstdc++/38000... -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||bkoz at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36505
[Bug libstdc++/37986] std::tr1::variate_generator does not conform to TR1.
--- Comment #6 from paolo dot carlini at oracle dot com 2008-11-12 10:02 --- Fixed again. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37986
[Bug libstdc++/38000] [4.3 Regression] System header files not found once -isystem /usr/include is used
--- Comment #7 from paolo dot carlini at oracle dot com 2008-11-13 00:09 --- Fixed for 4.4.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 work|4.2.4 |4.2.4 4.4.0 Summary|[4.3/4.4 Regression] System |[4.3 Regression] System |header files not found once |header files not found once |-isystem /usr/include is|-isystem /usr/include is |used|used Target Milestone|4.3.3 |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38000
[Bug libstdc++/38107] gcc source contains a struct with no data members (actually 1 byte in size) and compiler does not initialize it, resulting in IBM Rational Purify reporting an Uninitialized Memor
--- Comment #3 from paolo dot carlini at oracle dot com 2008-11-13 22:06 --- For sure nothing is going to happen in this area within the current ABI. In the context of a future ABI (for C++1x) these traits will be used in a completely different way, probably will not be used at all, dispatching based on "Concepts" will be used everywhere. In any case, "Purify" had better learn about these issues, in order not to emit false positives, "Valgrind" for comparison works perfectly. -- 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=38107
[Bug libstdc++/38128] FAIL: ext/pb_ds/regression/hash_data_map_rand.cc execution test
--- Comment #2 from paolo dot carlini at oracle dot com 2008-11-15 09:42 --- To be clear, absolutely nothing changed lately in this area of the library. Probably, it's just the well known brittleness of these ext/pb_ds testcases, or a compiler issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38128
[Bug middle-end/36902] Array bound warning with dead code after optimization
--- Comment #27 from paolo dot carlini at oracle dot com 2008-11-18 10:16 --- Isn't this a regression? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36902
[Bug middle-end/36902] Array bound warning with dead code after optimization
--- Comment #30 from paolo dot carlini at oracle dot com 2008-11-18 15:25 --- Thanks Manuel. I'm not sure that this is technically a regression, but in any case I consider it a serious problem and really hope we can have a fix for 4.4.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36902
[Bug middle-end/36902] Array bound warning with dead code after optimization
--- Comment #32 from paolo dot carlini at oracle dot com 2008-11-18 15:47 --- (In reply to comment #31) > I submitted the patch long ago. We are in regressions-only mode. This is not a > regression. Not sure what else you want me to do. I'm not sure either ;) Maybe you could just work on the complete solution (per your posted scheme), fixing also the other known issues in this area, and submit it again for mainline after we branched... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36902
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #64 from paolo dot carlini at oracle dot com 2008-11-20 10:24 --- (assuming I understand correctly Jason' approach - didn't really follow in detail the thread, lately) let me know if you want me to remove the exception_defines.h tricks from the library... -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||paolo at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug libstdc++/38196] num_put<>::do_put(bool) performs 'internal' padding incorrectly when boolalpha==true
--- Comment #2 from paolo dot carlini at oracle dot com 2008-11-20 13:42 --- Ok, let's do this. -- 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 |2008-11-20 13:42:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38196
[Bug libstdc++/38196] num_put<>::do_put(bool) performs 'internal' padding incorrectly when boolalpha==true
--- Comment #4 from paolo dot carlini at oracle dot com 2008-11-20 16:02 --- Fixed for 4.4.0. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38196
[Bug libstdc++/38210] num_put<>::do_put(void*) performs padding incorrectly when adjustfield==internal
--- Comment #1 from paolo dot carlini at oracle dot com 2008-11-21 09:19 --- Yes. -- 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 |2008-11-21 09:19:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38210
[Bug libstdc++/38210] num_put<>::do_put(void*) performs padding incorrectly when adjustfield==internal
--- Comment #3 from paolo dot carlini at oracle dot com 2008-11-21 10:00 --- Fixed for 4.4.0. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38210
[Bug c/38214] Unrecognized command line option "-fipa-marix-reorg" although it's documented
--- Comment #1 from paolo dot carlini at oracle dot com 2008-11-21 16:12 --- This is just a typo in the documentation: -fipa-matrix-reorg. -- 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 |2008-11-21 16:12:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38214
[Bug other/38214] Unrecognized command line option "-fipa-marix-reorg" although it's documented
--- Comment #4 from paolo dot carlini at oracle dot com 2008-11-21 16:23 --- Fixed for 4.3.3 and mainline. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38214
[Bug c++/38215] g++ internal compiler error
--- Comment #1 from paolo dot carlini at oracle dot com 2008-11-21 16:30 --- This is correctly rejected without ICE by any modern-era, maintained, GCC. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.2.5 4.3.1 4.4.0 Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38215
[Bug libstdc++/38210] num_put<>::do_put(void*) performs padding incorrectly when adjustfield==internal
--- Comment #6 from paolo dot carlini at oracle dot com 2008-11-23 14:01 --- (In reply to comment #5) > Apparently the failures I have reported in comment #4 disappear if I rebuild > libstdc++. Not surprising ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38210
[Bug libstdc++/38244] bitset initialization from 0 rejected.
--- Comment #3 from paolo dot carlini at oracle dot com 2008-11-24 10:21 --- This is essentially a defect in DR 778: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778 I'll see what we can do for now. -- 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 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38244
[Bug libstdc++/38244] [4.4 Regression] bitset initialization from 0 rejected.
-- paolo dot carlini at oracle dot com changed: What|Removed |Added Summary|bitset initialization from 0|[4.4 Regression] bitset |rejected. |initialization from 0 ||rejected. Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38244
[Bug libstdc++/38233] [4.4 Regression] 'map' value type + new uninitted const member warnings causes error
--- Comment #3 from paolo dot carlini at oracle dot com 2008-11-24 11:10 --- The default constructor of pair just implements DR 265, this is *very* old: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#265 This is possibly a C++ front-end issue, because lately nothing changed in the library in this area. I'll CC Jason. -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38233
[Bug libstdc++/38244] [4.4 Regression] bitset initialization from 0 rejected.
--- Comment #5 from paolo dot carlini at oracle dot com 2008-11-24 11:15 --- Fixed. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38244
[Bug libstdc++/35569] [c++0x] std::bind result functor doesn't accept rvalues
--- Comment #1 from paolo dot carlini at oracle dot com 2008-11-24 14:55 --- *** Bug 38238 has been marked as a duplicate of this bug. *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||fuscated at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35569
[Bug libstdc++/38238] std::tr1::bind fails to compile with pointer to member function
--- Comment #1 from paolo dot carlini at oracle dot com 2008-11-24 14:55 --- The problem is the rvalue (2) *** This bug has been marked as a duplicate of 35569 *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38238
[Bug libstdc++/38265] STL treats explicit constructors as converting constructors
--- Comment #2 from paolo dot carlini at oracle dot com 2008-11-25 19:48 --- Unless I'm badly mistaken, this behaviour, dating back to the original HP/SGI STL and as such very difficult to change now, is a small extension due to the use in the containers of _Construct instead of calling allocator::construct directly. All in all, at the moment I don't think we have good reasons to change it. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Component|c++ |libstdc++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38265
[Bug c++/38233] [4.4 Regression] 'map' value type + new uninitted const member warnings causes error
--- Comment #4 from paolo dot carlini at oracle dot com 2008-11-26 09:39
---
The below is a pure C++ testcase, which EDG accepts and mainline rejects. Jason
can you look a bit into it? Thanks in advance!
template
struct pair
{
_T1 first;
_T2 second;
// _GLIBCXX_RESOLVE_LIB_DEFECTS
// 265. std::pair::pair() effects overly restrictive
/** The default constructor creates @c first and @c second using their
* respective default constructors. */
pair()
: first(), second() { }
};
class a {
public:
a();
};
class b {
public:
// implicit default ctor
bool operator<(const b& rhs) const;
private:
a a_val;
};
typedef pair my_pair;
void func() {
my_pair x;
}
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|libstdc++ |c++
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-11-26 09:39:19
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38233
[Bug tree-optimization/38275] bootstrap failure when -ftree-parallelize-loops=4 is enabled
--- Comment #1 from paolo dot carlini at oracle dot com 2008-11-26 09:48 --- Is this related to middle-end/36902? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38275
[Bug c/38279] Float point exception while compiling firefox using profile guided optimization
--- Comment #6 from paolo dot carlini at oracle dot com 2008-11-26 16:12 --- (In reply to comment #4) > I know my gcc is very old. I will try to compile the newest version and send > the results. Ok. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38279
[Bug c/38279] Float point exception while compiling firefox using profile guided optimization
--- Comment #5 from paolo dot carlini at oracle dot com 2008-11-26 16:11 --- Are you aware of the fact that GCC 4.0.x is no longer maintained? You should try again with a current compiler, in the current 4.3.x release series or at least 4.2.x. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38279
[Bug libstdc++/38265] STL treats explicit constructors as converting constructors
--- Comment #4 from paolo dot carlini at oracle dot com 2008-11-28 10:50 --- Yes, this is obvious, just grep for _Construct. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38265
[Bug libstdc++/38265] STL treats explicit constructors as converting constructors
--- Comment #8 from paolo dot carlini at oracle dot com 2008-11-28 11:30 --- The issue is different because if I remove all uses of _Construct and implement the various uninitialized_* per the letter of the Standard, nothing changes... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38265
[Bug libstdc++/38265] STL treats explicit constructors as converting constructors
--- Comment #9 from paolo dot carlini at oracle dot com 2008-11-28 11:40 --- ... and I'm coming to the conclusion that this is not a bug in our library. Consider the std::vector case: I cannot see anything wrong with using std::uninitialized_copy in the implementation of the constructor. In turn, the former does, per the Standard: ::new(static_cast(&*__cur)) typename iterator_traits<_ForwardIterator>::value_type(*__first); thus, the explicit constructor can be used. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38265
[Bug libstdc++/38265] STL treats explicit constructors as converting constructors
--- Comment #6 from paolo dot carlini at oracle dot com 2008-11-28 11:17 --- Hummm, the issue seems different than I remembered it. Will see.. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38265
[Bug libstdc++/38265] STL treats explicit constructors as converting constructors
--- Comment #5 from paolo dot carlini at oracle dot com 2008-11-28 11:03 --- But I see now that al long time ago list & co also used _Construct, this is indeed an inconsistency... Let's see what we can do here... -- 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 |2008-11-28 11:03:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38265
[Bug libstdc++/38304] Conflict with the STL standard. std::set::iterator
--- Comment #1 from paolo dot carlini at oracle dot com 2008-11-28 15:11 --- *** This bug has been marked as a duplicate of 14410 *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38304
[Bug libstdc++/14410] Bug with implementation of set for const iterators in g++ ...
--- Comment #8 from paolo dot carlini at oracle dot com 2008-11-28 15:11 --- *** Bug 38304 has been marked as a duplicate of this bug. *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||sleary at vavi dot co dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14410
[Bug libstdc++/14410] Bug with implementation of set for const iterators in g++ ...
--- Comment #10 from paolo dot carlini at oracle dot com 2008-11-28 15:21 --- Please refer to the resolution of DR 103, which we are implementing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14410
[Bug c++/38309] ICE in write_type, at cp/mangle.c:1695
--- Comment #1 from paolo dot carlini at oracle dot com 2008-11-28 16:57 --- Duplicate of PR 10690? (by the way, I cannot reproduce the ICE with FSF 4_3-branch and mainline, I'm seeing the "address of overloaded function with no contextual type information" error instead) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38309
[Bug libstdc++/38265] STL treats explicit constructors as converting constructors
--- Comment #12 from paolo dot carlini at oracle dot com 2008-11-29 17:05 --- Subject: Re: STL treats explicit constructors as converting constructors > The Standard does not require that std::uninitialized_copy be > invoked when > constructing an std::vector or... Sure, but certainly doesn't forbid it, and I maintain is the natural choice in this case. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38265
[Bug other/38340] Error in pthread.h
--- Comment #1 from paolo dot carlini at oracle dot com 2008-12-01 10:34 --- Certainly nothing to do with the C++ runtime library. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Component|libstdc++ |other http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38340
[Bug libstdc++/38365] Locale, constructed from named and unnamed locales, become named
--- Comment #3 from paolo dot carlini at oracle dot com 2008-12-02 10:59 --- Fixed for 4.4.0. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 Version|unknown |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38365
[Bug libstdc++/38365] Locale, constructed from named and unnamed locales, become named
--- Comment #5 from paolo dot carlini at oracle dot com 2008-12-02 13:21
---
(In reply to comment #4)
> Your patch fixes the problem at the level of the locale constructor, but why
> do
> not fix this problem at the level of _M_replace_categories() instead?
Because that would not work, _M_impl has already a name ("C") by that time.
Note that all these classes are suboptimal performance-wise, will be redesigned
for the next ABI.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38365
[Bug libstdc++/38365] Locale, constructed from named and unnamed locales, become named
--- Comment #6 from paolo dot carlini at oracle dot com 2008-12-02 13:34
---
(In reply to comment #5)
> (In reply to comment #4)
> > Your patch fixes the problem at the level of the locale constructor, but
> > why do
> > not fix this problem at the level of _M_replace_categories() instead?
>
> Because that would not work, _M_impl has already a name ("C") by that time.
Sorry, now I see that the involved _Impl constructor clones, thus creates an
unnamed clone if the original one is unnamed, thus the idea can work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38365
[Bug libstdc++/38365] Locale, constructed from named and unnamed locales, become named
--- Comment #1 from paolo dot carlini at oracle dot com 2008-12-02 09:53 --- Ok. -- 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 |2008-12-02 09:53:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38365
[Bug libstdc++/38368] locale(const char* std_name) may create locale with broken facets
--- Comment #1 from paolo dot carlini at oracle dot com 2008-12-03 10:34
---
This sort-of inconsistency is essentially due to the glibc specifics (+ the
fact that we are dealing separately with "C" locale) see the below GNU C
snippet. In particular, note in numeric_members.cc that we already deal
correctly with the possibility of THOUSANDS_SEP == '\0'. In my opinion, all the
past discussions in this area considered, we should only tweak
monetary_members.cc vs __MON_DECIMAL_POINT == '\0' (possibly
__MON_THOUSANDS_SEP == '\0' too) in complete analogy with numeric_members.cc vs
THOUSANDS_SEP == '\0'.
/
#define _GNU_SOURCE
#include
#include
#include
#include
int main()
{
__locale_t cloc = 0;
char ts = 'z';
cloc = __newlocale(1 << LC_ALL,
"LC_CTYPE=C;LC_NUMERIC=C;LC_TIME=C;LC_COLLATE=C;LC_MONETARY=C;LC_MESSAGES=C;LC_PAPER=C;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=C;LC_IDENTIFICATION=C",
cloc);
ts = *(nl_langinfo_l(THOUSANDS_SEP, cloc));
assert( ts == '\0' );
printf("%c\n", ts);
cloc = 0;
ts = 'z';
cloc = __newlocale(1 << LC_ALL,
"LC_CTYPE=C;LC_NUMERIC=C;LC_TIME=C;LC_COLLATE=C;LC_MONETARY=C;LC_MESSAGES=C;LC_PAPER=C;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=C;LC_IDENTIFICATION=C",
cloc);
ts = *(nl_langinfo_l(__MON_DECIMAL_POINT /*__MON_THOUSANDS_SEP*/, cloc));
assert( ts == '\0' );
printf("%c\n", ts);
return 0;
}
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
CC||paolo at gcc dot gnu dot
||org, bkoz at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38368
[Bug libstdc++/38368] locale(const char* std_name) may create locale with broken facets
--- Comment #2 from paolo dot carlini at oracle dot com 2008-12-03 10:46 --- Or maybe we should just report the __MON_DECIMAL_POINT == '\0' thing to glibc, which seems special to me (THOUSANDS_SEP == '\0' is well known, on the other hand). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38368
[Bug libstdc++/38368] locale(const char* std_name) may create locale with broken facets
--- Comment #4 from paolo dot carlini at oracle dot com 2008-12-03 17:15 --- Ok, let's try to enforce this kind of consistency. -- 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 |2008-12-03 17:15:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38368
[Bug libstdc++/38399] money_get<> read decimal point when frac_digits() <= 0
--- Comment #1 from paolo dot carlini at oracle dot com 2008-12-04 15:11 --- Ok. -- 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 |2008-12-04 15:11:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38399
[Bug libstdc++/38399] money_get<> read decimal point when frac_digits() <= 0
--- Comment #2 from paolo dot carlini at oracle dot com 2008-12-04 16:08 --- (In reply to comment #0) > use_facet >(loc).get(ss, 0, false, ss, err, digits); > > string rest(istreambuf_iterator(ss), istreambuf_iterator()); Fixing this issue is trivial, but please double check the above way of using mony_get::get, which in general doesn't work with our implementation. Only the iterator returned by get correctly points to the current char: constructing after the get an istreambuf_iterator(ss) doesn't work for that. So, please double check carefully and in case open a separate PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38399
[Bug libstdc++/38368] locale(const char* std_name) may create locale with broken facets
--- Comment #6 from paolo dot carlini at oracle dot com 2008-12-04 17:19 --- Fixed for 4.4.0. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 Version|unknown |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38368
[Bug libstdc++/38411] [4.4 Regression] Revision 142439 caused 22_locale/locale/cons/7.cc execution test
--- Comment #4 from paolo dot carlini at oracle dot com 2008-12-05 08:24 --- Are you using the same glibc on x86_64 and ia64? The two failing testcases (cons/7.cc and members/char/2.cc, the other are implied) are essentially the same: something is different on that ia64 machine about the localedata having to do with numeric decimal point and grouping. I'll try to further debug this (because 38368 is a real issue and we want a fix) but since I can't reproduce on my machines, I need to know the value of the various dp1, dp2, etc. in the failing VERIFY (assert). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38411
[Bug libstdc++/38411] [4.4 Regression] Revision 142439 caused 22_locale/locale/cons/7.cc execution test
--- Comment #6 from paolo dot carlini at oracle dot com 2008-12-05 08:47
---
Yes, I'm not sure is the same issue. Anyway, the problem can only be in this
idea:
_M_data->_M_thousands_sep = *(__nl_langinfo_l(THOUSANDS_SEP,
__cloc));
...
if (_M_data->_M_thousands_sep == '\0')
{
_M_data->_M_thousands_sep = ',';
that is, we are trying to standardize on ',' (the same we have for the "C"
locale) in case the localedata is \0 for the thousands separator. Apparently
for some versions of glibc, it causes problems, I'm still trying to disentangle
the logic... Jakub, how does it sound to you?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38411
[Bug libstdc++/38411] [4.4 Regression] Revision 142439 caused 22_locale/locale/cons/7.cc execution test
--- Comment #7 from paolo dot carlini at oracle dot com 2008-12-05 08:50 --- By the way, yes the fr_FR locale is heavily used in those tests... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38411
[Bug libstdc++/38411] [4.4 Regression] Revision 142439 caused 22_locale/locale/cons/7.cc execution test
--- Comment #8 from paolo dot carlini at oracle dot com 2008-12-05 08:55 --- I suspect in the localedata of fr_FR, the thousands separator may have changed in some glibc from ' ' (0x20) to '\0'. Jakub can you confirm that? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38411
[Bug libstdc++/38411] [4.4 Regression] Revision 142439 caused 22_locale/locale/cons/7.cc execution test
--- Comment #11 from paolo dot carlini at oracle dot com 2008-12-05 09:16 --- (In reply to comment #9) > Forcing "," thousands separator when none should be used is very weird. Is the same "C" locale has. We only want consistency, see 38368. Does > C++ standard mandate that behavior? "" means thousands shouldn't be separated > by any separator. In most cases such locales also have grouping 0;0 or -1, > but > there > are buggy? I suppose so, because we have a comment in the code (resulting from feedback me and / or Benjamin got from glibc people clearly saying that '\0' implies no grouping. We always worked under this hypothesis. locales, e.g. bg_BG, that specify empty thousands_sep, yet have > grouping 3;3. For empty thousands_sep glibc just forces no grouping: > if ((wide && thousands_sepwc == L'\0') > || (! wide && *thousands_sep == '\0')) > grouping = NULL; Ok... > > BTW, thousands_sep is a multibyte string, it can be multiple bytes This is just a C++ standard issue, unfortunately... Paolo. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38411
[Bug libstdc++/38411] [4.4 Regression] Revision 142439 caused 22_locale/locale/cons/7.cc execution test
--- Comment #12 from paolo dot carlini at oracle dot com 2008-12-05 09:17 --- (In reply to comment #10) > To reply to #c8, it changed the other way around, from "" to "" in > April > 2008. But as I said, Fedora 9, which shipped glibc 2.9, was backing out these > changes (Fedora 10 has them already). Crazy. Anyway, that is the problem. I will change the tests to not rely on such named locales. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38411
[Bug libstdc++/38411] [4.4 Regression] Revision 142439 caused 22_locale/locale/cons/7.cc execution test
--- Comment #14 from paolo dot carlini at oracle dot com 2008-12-05 09:42 --- (In reply to comment #13) > If _M_thousands_sep must be a single _CharT, then for I guess you > should > transliterate it if the string is longer than one character. > Either by using glibc transliteration (more generic, but slower), or by > hardcoding > the few multibyte strings that are used in glibc locales ATM. > That's just in current glibc (transliterate to ' ') and in some older > libcs was also that (also to ' '). Maybe change everything longer > than > one byte to ' ' ;). Ok, thanks. I think we have to think more about this issue, it's as old as v3 ;) For 4.5 maybe... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38411
[Bug libstdc++/38411] [4.4 Regression] Revision 142439 caused 22_locale/locale/cons/7.cc execution test
-- 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 |2008-12-05 09:43:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38411
[Bug libstdc++/38411] [4.4 Regression] Revision 142439 caused 22_locale/locale/cons/7.cc execution test
--- Comment #16 from paolo dot carlini at oracle dot com 2008-12-05 09:51 --- (In reply to comment #15) > Well, if you take first byte from a multibyte sequence, then it is IMNSHO > something that should be solved for 4.4 too. For say ru_RU.UTF-8 that means > you emit invalid UTF-8 if you separate digits with say '\xc2', > "\x33\xc2\x33\x33\x33" is invalid UTF-8. Maybe, but, as I should learn from you ;) this is definitely not a regression, the time is short and the issue is tricky. Therefore, I don't think I will tackle it directly, unless you are willing to help, of course! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38411
[Bug libstdc++/38411] [4.4 Regression] Revision 142439 caused 22_locale/locale/cons/7.cc execution test
--- Comment #17 from paolo dot carlini at oracle dot com 2008-12-05 09:54 --- Created an attachment (id=16831) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16831&action=view) Draft Draft patch using is_IS instead of fr_FR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38411
[Bug libstdc++/38411] [4.4 Regression] Revision 142439 caused 22_locale/locale/cons/7.cc execution test
--- Comment #18 from paolo dot carlini at oracle dot com 2008-12-05 09:55 --- HJ, can you test it and report? Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38411
[Bug libstdc++/38399] money_get<> read decimal point when frac_digits() <= 0
--- Comment #4 from paolo dot carlini at oracle dot com 2008-12-05 09:59 --- (In reply to comment #3) > Thanks for remark. You are welcome. By the way, since in general you are so kind to report very accurate and to the point issues, I would appreciate if you could also add testcases more similar to what we already have in the testsuite (so, for example, no outputs, no use of iostreams, asserts instead; etc.). That would greatly speed up the whole process! Thanks again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38399
[Bug libstdc++/38411] [4.4 Regression] Revision 142439 caused 22_locale/locale/cons/7.cc execution test
--- Comment #21 from paolo dot carlini at oracle dot com 2008-12-05 13:09 --- Fixed. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38411
[Bug libstdc++/38399] money_get<> read decimal point when frac_digits() <= 0
--- Comment #6 from paolo dot carlini at oracle dot com 2008-12-05 18:25 --- Fixed for 4.4.0. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 Version|unknown |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38399
[Bug libstdc++/38421] libstdc++-v3/include/tr1/ell_integral.tcc contains __ea identifier
--- Comment #1 from paolo dot carlini at oracle dot com 2008-12-06 10:22 --- Let's take care of this. -- 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 |2008-12-06 10:22:08 date|| Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38421
[Bug libstdc++/38421] libstdc++-v3/include/tr1/ell_integral.tcc contains __ea identifier
--- Comment #3 from paolo dot carlini at oracle dot com 2008-12-06 10:27 --- Fixed. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38421
[Bug libstdc++/37144] A bug in include/ext/pb_ds/detail/pat_trie_/constructors_destructor_fn_imps.hpp
--- Comment #13 from paolo dot carlini at oracle dot com 2008-12-11 15:37 --- Hi HJ: I'm not sure to understand, you mean this is actually a C++ / compiler bug?!? -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||paolo at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37144
[Bug libstdc++/37144] A bug in include/ext/pb_ds/detail/pat_trie_/constructors_destructor_fn_imps.hpp
--- Comment #16 from paolo dot carlini at oracle dot com 2008-12-11 16:17 --- At the moment, I don't know this code well enough, but note that: typedef const pair & const_pair_reference; therefore, I don't really follow your reasoning. By the way, rvalrefs I don't think are an option, because these classes are old, supposed to work well also in C++03 mode. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37144
[Bug libstdc++/38476] SIGSEGV on istream::read() in unbuffered mode
--- Comment #1 from paolo dot carlini at oracle dot com 2008-12-11 16:12 --- Hi. Given the specifications for uflow() (27.5.2.4.3/16), I don't see how this code can work because I don't think *gptr() can work in this unbuffered case. Can you explain in better detail what are you expecting? -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC| |paolo dot carlini at oracle | |dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38476
[Bug libstdc++/37144] A bug in include/ext/pb_ds/detail/pat_trie_/constructors_destructor_fn_imps.hpp
--- Comment #17 from paolo dot carlini at oracle dot com 2008-12-11 16:39 --- In any case, I don't really understand your snippet: you are comparing &x.i to &t1.i, but x comes from p, and p *copies* t1 at construction time, in other terms &p.first.i != &t1.i to begin with. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37144
[Bug libstdc++/37144] A bug in include/ext/pb_ds/detail/pat_trie_/constructors_destructor_fn_imps.hpp
--- Comment #22 from paolo dot carlini at oracle dot com 2008-12-11 18:13 --- Therefore, are you coming to the conclusion that something in the testing infrastructure is wrong (mismatched types), *not* in the ext/pb_ds code itself? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37144
[Bug libstdc++/37144] A bug in include/ext/pb_ds/detail/pat_trie_/constructors_destructor_fn_imps.hpp
--- Comment #27 from paolo dot carlini at oracle dot com 2008-12-11 18:55 --- Ah, yes, that, I saw it some time ago. Thus, the patch you and John are testing (which makes sense, first blush) avoids failures in normal mode, but in fact another, latent, issue is uncovered in DEBUG_MODE? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37144
[Bug libstdc++/37582] [4.3 Regression] std::pow strange overload resolution
--- Comment #10 from paolo dot carlini at oracle dot com 2008-12-11 20:04 --- (In reply to comment #9) > So, either IMHO we should cast to bool there, or as done in this patch > use __traitor instead. For the branch, I pre-approve a patch adding and using __traitand. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37582
[Bug libstdc++/38477] [strict-aliasing] warning message contains compiler-generated symbols
--- Comment #3 from paolo dot carlini at oracle dot com 2008-12-12 11:10 --- Can you explain in better detail which aliasing issues you are seeing in _Rb_tree_impl (per Comment #1)? At line 530 I cannot see anything obviously wrong: a pointer to the base is casted to the derived type (just a static cast) and then _M_value_field of the latter is accessed. -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||paolo at gcc dot gnu dot ||org, rguenth at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38477
[Bug libstdc++/38477] [strict-aliasing] warning message contains compiler-generated symbols
--- Comment #5 from paolo dot carlini at oracle dot com 2008-12-12 11:39 --- Sorry, but I still do not understand: __x (a const _Rb_tree_node_base *) is casted to _Const_Link_type (a const _Rb_tree_node<_Val> *) before the access, then of course an _M_value_field esists. By the way, all these cast games are very, very old (I hope we are not uncovering one more aliasing issue in the HP/SGI code)... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38477
[Bug libstdc++/38477] [strict-aliasing] warning message contains compiler-generated symbols
--- Comment #7 from paolo dot carlini at oracle dot com 2008-12-12 11:53
---
(In reply to comment #6)
> But there is no space for _Rb_tree_node<_Val> in ctx.foo._M_t._M_impl.
>
> struct _Rb_tree_impl : public _Node_allocator
> {
> _Key_compare _M_key_compare;
> _Rb_tree_node_base_M_header;
> size_type _M_node_count;
This has nothing to do with the allocated nodes.
>
> the _M_header member is of type _Rb_tree_node_base, so I don't see how you
> can cast that to _Rb_tree_node<_Val> and expect the _M_value_field to
> magically
> appear in memory.
Hey Richard, don't tell me it's the first time you see production code casting
a pointer from base to derived and accessing a member existing only in the
derived type. Indeed, the HP / SGI STL people did that, not the worse
programmers in the world ;) Anyway, if you think this is something wrong from
the aliasing specifications point of view, please point me to the relevant
sections of the Standard, let's work this out, is going to be painful and
risky, I'm afraid...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38477
[Bug c++/38524] "ICE at cp/typeck.c:2268" on "struct{enum E{};}A;int main(){A.E::foo;}"
--- Comment #1 from paolo dot carlini at oracle dot com 2008-12-14 11:59 --- Can't reproduce the ICE with current (142748) mainline: 38524.C:1: warning: non-local variable A uses anonymous type 38524.C: In function int main(): 38524.C:1: error: E is not a class or namespace If you can, please re-open. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38524
[Bug libstdc++/6257] [DR 456] C-library symbols enter global namespace
--- Comment #28 from paolo dot carlini at oracle dot com 2008-12-15 18:42 --- *** Bug 38531 has been marked as a duplicate of this bug. *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||mayor1 at uralweb dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6257
[Bug other/38531] namespace, ,
--- Comment #2 from paolo dot carlini at oracle dot com 2008-12-15 18:42 --- *** This bug has been marked as a duplicate of 6257 *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38531
[Bug other/38531] namespace, ,
--- Comment #3 from paolo dot carlini at oracle dot com 2008-12-15 18:50 --- By the way, in gcc4.3.x (and 4.4.x of course), is not included anymore by as an implementation detail (it could, it's allowed by Standard), thus this specific issue is strictly speaking moot now. But still injects declarations in the global namespace too, this is 6257. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38531
[Bug libstdc++/38466] std::swap does not use std::swap for the components of a std::pair
--- Comment #6 from paolo dot carlini at oracle dot com 2008-12-17 17:38 --- The __swap_impl idea makes sense but note that user code can tell it from the "standard" one when something throws. All in all, given that C++0x will be Ok wrt these issues, I'm not sure we want to attempt something in C++03 mode. By the way, as far as our specific implementation of std::string is concerned, typically I would not expect a huge performance improvement, thanks to copy-on-write. Do you have some numbers? -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||paolo at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38466
[Bug libstdc++/36801] config/cpu/generic/atomicity_mutex/atomicity.h incorrectly relies on global constructor ordering
--- Comment #9 from paolo dot carlini at oracle dot com 2008-12-17 17:21 --- Benjamin, any feedback on this? Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36801
[Bug c++/38555] Invalid function return path analysis error report
--- Comment #1 from paolo dot carlini at oracle dot com 2008-12-17 15:31 --- *** This bug has been marked as a duplicate of 38552 *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38555
[Bug c++/38552] Invalid function return path analysis error report
--- Comment #1 from paolo dot carlini at oracle dot com 2008-12-17 15:31 --- *** Bug 38555 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38552
[Bug libstdc++/37144] A bug in include/ext/pb_ds/detail/pat_trie_/constructors_destructor_fn_imps.hpp
-- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-12-17 17:20:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37144
[Bug libstdc++/38596] tr1_impl/functional incompatible with -fno-rtti
-- paolo dot carlini at oracle dot com changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38596
[Bug libstdc++/38596] tr1_impl/functional incompatible with -fno-rtti
--- Comment #1 from paolo dot carlini at oracle dot com 2008-12-21 15:06 --- Note, the use of typeid (and type_info) is explicit in the specifications, thus the only solution I can see for -fno-rtti is not providing at all (ifdef-ing out) function::target and target_type. If submitter has better ideas please speak... -- 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 |2008-12-21 15:06:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38596
[Bug libstdc++/38596] tr1_impl/functional incompatible with -fno-rtti
--- Comment #3 from paolo dot carlini at oracle dot com 2008-12-21 15:40 --- Ok, let's do this. Worst case, something will be unnecessarily broken with -fno-rtti, but certainly nothing which is not broken already ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38596
[Bug libstdc++/38596] tr1_impl/functional incompatible with -fno-rtti
--- Comment #5 from paolo dot carlini at oracle dot com 2008-12-21 15:58 --- Done. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38596
[Bug libstdc++/38596] tr1_impl/functional incompatible with -fno-rtti
--- Comment #6 from paolo dot carlini at oracle dot com 2008-12-21 15:58 --- Yes. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38596
[Bug c++/38600] Internal compiler error (ICE) Segmentation fault
--- Comment #2 from paolo dot carlini at oracle dot com 2008-12-21 18:21 --- First, you should check if the problem still happens with a maintained branch of GCC (neither 4.1.x nor 4.2.x are maintained anymore). -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38600
[Bug libstdc++/38476] SIGSEGV on istream::read() in unbuffered mode
-- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38476
[Bug libstdc++/38631] [4.4 Regression] libstdc++ from gcc 4.4 causes OpenOffice.org 3.0 to crash on startup
--- Comment #1 from paolo dot carlini at oracle dot com 2008-12-26 17:40 --- In any case, why you are so sure the problem is due to libstdc++ and not libgcc_s? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38631
[Bug libstdc++/38631] [4.4 Regression] libstdc++ from gcc 4.4 causes OpenOffice.org 3.0 to crash on startup
--- Comment #3 from paolo dot carlini at oracle dot com 2008-12-26 23:05 --- Bah, for sure we need a reduced testcase anyway, I have no idea what to do with this report, otherwise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38631
[Bug libstdc++/38631] [4.4 Regression] libstdc++ from gcc 4.4 causes OpenOffice.org 3.0 to crash on startup
--- Comment #4 from paolo dot carlini at oracle dot com 2008-12-27 00:33 --- ... by the way, before anything else, I think you should confirm that the software works fine if built with current mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38631
[Bug libstdc++/38476] SIGSEGV on istream::read() in unbuffered mode
--- Comment #2 from paolo dot carlini at oracle dot com 2008-12-27 09:21 --- To clarify: I don't see anything in the Standard forbidding the use of rdbuf()->sgetn in the implementation of istream::read. Actually, I would argue is the natural choice for carrying out the core work. Then, however, everything bis equivalent per the Standard to a series of sbumpc and uflow (not underflow) must be provided by the user. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38476
