http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45923
--- Comment #2 from Benjamin Kosnik 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
--- 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.
But this is
--- 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.
But this is
ement
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
--- 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
--- 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
--- 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
--- 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
--- 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 c
--- 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
--- 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
--- 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 wo
--- 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 alon
--- 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'
--- 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
--- 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?
--- 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 libr
--- 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/bugzi
--- 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
>w
--- 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 o
20 matches
Mail list logo
