[Bug c++/45923] constexpr diagnostic w/ non-literal

2010-10-08 Thread bkoz at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45923 --- Comment #2 from Benjamin Kosnik bkoz at redhat dot com 2010-10-08 17:12:35 UTC --- It is not valid for real() to be constexpr in a non-literal class This is a helpful diagnostic. The existing one is not. -benjamin

[Bug libstdc++/42460] man page errors for generated libstdc++ man pages

2010-02-18 Thread bkoz at redhat dot com
--- Comment #23 from bkoz at redhat dot com 2010-02-18 19:09 --- Subject: Re: man page errors for generated libstdc++ man pages 2010-02-17 09:36 --- So... shall we close this as fixed? Remaining item is doxygen function markup is not working for man pages

[Bug other/38983] New: GPL version 3 transition incomplete

2009-01-26 Thread bkoz at redhat dot com
Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bkoz at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38983

[Bug libstdc++/38919] math_stubs_long_double.cc: error: redefinition of 'long double ...' vs. /usr/x86_64-mingw32/include/math.h

2009-01-19 Thread bkoz at redhat dot com
--- Comment #2 from bkoz at redhat dot com 2009-01-20 04:21 --- If this is a native build, then GLIBCXX_CHECK_MATH_SUPPORT should have defined _GLIBCXX_HAVE_FABSL _GLIBCXX_HAVE_MODFL in c++config.h. One would have seen something like: checking for fabsl declaration... yes checking

[Bug libstdc++/32666] FAIL: abi_check hppa

2009-01-19 Thread bkoz at redhat dot com
--- Comment #17 from bkoz at redhat dot com 2009-01-20 05:51 --- The float versions were added in r143457 http://gcc.gnu.org/ml/gcc-cvs/2009-01/msg00470.html hpux 11 looks fine, but I don't see 10.x results. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32666

[Bug libstdc++/30085] switch debug mode hash containers from ext to tr1

2008-09-29 Thread bkoz at redhat dot com
--- Comment #10 from bkoz at redhat dot com 2008-09-29 17:17 --- Sorry P, I have not paid attention to this. I am not likely to work on it this week, so if you want to work on it feel free. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30085

[Bug c++/35782] support for standard layout types

2008-09-10 Thread bkoz at redhat dot com
--- Comment #6 from bkoz at redhat dot com 2008-09-10 21:46 --- Subject: Re: support for standard layout types 1) be able to inherit from C POD and be standard layout 2) be able to have deleted ctor/copy ctor and be standard layout 3) able to do aggregate init when 1, 2 You

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

2007-04-02 Thread bkoz at redhat dot com
--- Comment #65 from bkoz at redhat dot com 2007-04-02 09:49 --- Subject: Re: __cplusplus defined to 1, should be 199711L Weird, when solaris is the easiest one. That's certainly a matter of perspective. Based on Solaris 11 x86, I don't see a way for say cstdlib to have only

[Bug libstdc++/28125] Cannot build cross compiler for Solaris: configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES

2007-01-02 Thread bkoz at redhat dot com
--- Comment #10 from bkoz at redhat dot com 2007-01-02 16:49 --- Apparently there are errors with this patch. Revisiting... http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01592.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28125

[Bug libstdc++/21770] rebinding allocator::value type vs. container::value_type

2005-05-26 Thread bkoz at redhat dot com
--- Additional Comments From bkoz at redhat dot com 2005-05-26 20:12 --- Subject: Re: rebinding allocator::value type vs. container::value_type Yo P, just trying to get through the deluge. I've not looked into specifics, so sorry for such a vague marker in bugzilla. I'm not quite

[Bug middle-end/14311] builtins for atomic operations needed

2005-04-11 Thread bkoz at redhat dot com
--- Additional Comments From bkoz at redhat dot com 2005-04-11 17:14 --- Subject: Re: builtins for atomic operations needed I'm working on atomic builtins, but this will *not* resolve the problem of compiling for i386 and i486+. Indeed, it could easily make it worse because you

[Bug libstdc++/20694] [4.1 Regression] make install failure building abi_check with leftover libv3test

2005-03-30 Thread bkoz at redhat dot com
--- Additional Comments From bkoz at redhat dot com 2005-03-30 18:31 --- Subject: Re: New: make install failure building abi_check with leftover libv3test Is it considered desirable behavior to build abi_check at make install time? No, this doesn't make any sense, as abi_check

[Bug libstdc++/20694] [4.1 Regression] make install failure building abi_check with leftover libv3test

2005-03-30 Thread bkoz at redhat dot com
--- Additional Comments From bkoz at redhat dot com 2005-03-30 19:48 --- Subject: Re: New: make install failure building abi_check with leftover libv3test (I didn't actually change this particularly thing; it was probably getting built at make install time all along. But, my

[Bug libstdc++/17140] Floating point output is slow

2004-11-15 Thread bkoz at redhat dot com
--- Additional Comments From bkoz at redhat dot com 2004-11-15 17:04 --- Subject: Re: Floating point output is slow I don't see any of those failures. I updated tonight (11/12). Did a fresh config and make (not bootstrap) on x86 pentium M. Hmmm. Well, maybe I munged

[Bug c++/17743] dependent expressions in attributes

2004-10-19 Thread bkoz at redhat dot com
--- Additional Comments From bkoz at redhat dot com 2004-10-19 06:23 --- Subject: Re: dependent expressions in attributes Yes, but how do you force the compiler to ensure that the alignment of char foo [] is sufficient to placement-allocate an object of type T into it? ...get

[Bug c++/17743] dependent expressions in attributes

2004-10-17 Thread bkoz at redhat dot com
--- Additional Comments From bkoz at redhat dot com 2004-10-18 05:23 --- Subject: Re: dependent expressions in attributes Is this a showstopper for tr1 work? Not that I can see. From what I can tell, tr1::array is going to require default-constructable types. I think the library

[Bug c++/17743] __alignof__ vs. typedefs

2004-10-16 Thread bkoz at redhat dot com
--- Additional Comments From bkoz at redhat dot com 2004-10-16 13:52 --- Subject: Re: __alignof__ vs. typedefs OK. But XFAIL the tr1 test cases so those do not show up as new FAILs. I think I just took care of this. Giovanni, thanks! -benjamin -- http://gcc.gnu.org/bugzilla

[Bug libstdc++/17937] Critical ~__pool troubles

2004-10-11 Thread bkoz at redhat dot com
--- Additional Comments From bkoz at redhat dot com 2004-10-12 00:30 --- Subject: Re: Critical ~__pool troubles Ok, but as long as we don't use that, let's avoid taking the lock a second time in _M_reserve_block, the new calls and so on... I propose to protect with macros or #if 0

[Bug c++/17743] __alignof__ vs. typedefs

2004-09-30 Thread bkoz at redhat dot com
--- Additional Comments From bkoz at redhat dot com 2004-09-30 14:48 --- Subject: Re: __alignof__ vs. typedefs Benj, having a fix in time for 4.0 would help, or is it going to be 4.1 material anyway? Having a fix for this for 4.0.0 will definitely be useful. I'm kind of surprised