Fixed on trunk by revision 181072.
Please use bugzilla or the libstdc++ mailing list next time.
On 7 November 2011 07:09, Jonathan Wakely wrote:
> On 7 November 2011 03:02, James Dennett wrote:
>> On Sun, Nov 6, 2011 at 6:55 PM, niXman wrote:
>>> When I try to build gcc-trunk on OpenBSD-5.0(gcc-4.2.1), I get the
>>> following error:
gcc-4.6.2/i686-pc-openbsd5.0/libstdc++-v3/include/mute
This should probably be on the gcc-help list.
On 7 November 2011 01:08, Dennis Clarke wrote:
>
> Well, dear GCC users I am now seeing behavior that falls in the arean of
> the bizarre. No sense in talking much about it but here is the error
> message :
>
> /opt/bw/src/GCC/gcc_4.6.2/gcc-4.6.2/intl/
On 7 November 2011 03:02, James Dennett wrote:
> On Sun, Nov 6, 2011 at 6:55 PM, niXman wrote:
>> When I try to build gcc-trunk on OpenBSD-5.0(gcc-4.2.1), I get the
>> following error:
>>> gcc-4.6.2/i686-pc-openbsd5.0/libstdc++-v3/include/mutex:818:64: error:
>>> invalid conversion from 'void (*)
Dennis Clarke writes:
> Only the new "go" language seems to be a major issue now.
The implementation of Go in the 4.6 releases does not support Solaris.
Go on Solaris works on mainline.
Ian
2011/11/7 niXman :
> 2011/11/7 James Dennett :
>> On Sun, Nov 6, 2011 at 6:55 PM, niXman wrote:
>>> When I try to build gcc-trunk on OpenBSD-5.0(gcc-4.2.1), I get the
>>> following error:
gcc-4.6.2/i686-pc-openbsd5.0/libstdc++-v3/include/mutex:818:64: error:
invalid conversion from 'vo
2011/11/7 James Dennett :
> On Sun, Nov 6, 2011 at 6:55 PM, niXman wrote:
>> When I try to build gcc-trunk on OpenBSD-5.0(gcc-4.2.1), I get the
>> following error:
>>> gcc-4.6.2/i686-pc-openbsd5.0/libstdc++-v3/include/mutex:818:64: error:
>>> invalid conversion from 'void (*)(...)' to 'void (*)(
On Sun, Nov 6, 2011 at 6:55 PM, niXman wrote:
> When I try to build gcc-trunk on OpenBSD-5.0(gcc-4.2.1), I get the
> following error:
>> gcc-4.6.2/i686-pc-openbsd5.0/libstdc++-v3/include/mutex:818:64: error:
>> invalid conversion from 'void (*)(...)' to 'void (*)()' [-fpermissive]
>
> Please add
When I try to build gcc-trunk on OpenBSD-5.0(gcc-4.2.1), I get the
following error:
> gcc-4.6.2/i686-pc-openbsd5.0/libstdc++-v3/include/mutex:818:64: error:
> invalid conversion from 'void (*)(...)' to 'void (*)()' [-fpermissive]
Please add the void into arguments list for function __once_proxy(
Ville Voutilainen writes:
>> Is this likely to go in for 4.7?
>
> As far as I know, all the review comments have been fixed, I posted a
> patch that fixed the unwanted whitespace changes and such.
>
> It's pending copyright paperwork from the author of the original patch.
> (my copyright paperwork
On 7 November 2011 03:58, Miles Bader wrote:
> Hi, I'm wondering whether there's been any progress on the recent
> "Delegating Constructors" patch:
> http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01202.html
> The last post on that thread (in gcc-patches) was early last month.
> There doesn't seem t
Hi, I'm wondering whether there's been any progress on the recent
"Delegating Constructors" patch:
http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01202.html
The last post on that thread (in gcc-patches) was early last month.
There doesn't seem to have been any objection, just minor review-type
com
> Dennis Clarke writes:
>
>> I'm not too sure how many things changed from 4.6.1 to 4.6.2 but I am
>> seeing a really large increase in the number of "unexpected failures" on
>> various tests.
>>
>> With 4.6.1 and Solaris I was able to get reasonable results :
>>
>> http://gcc.gnu.org/ml/gcc-test
Well, dear GCC users I am now seeing behavior that falls in the arean of
the bizarre. No sense in talking much about it but here is the error
message :
/opt/bw/src/GCC/gcc_4.6.2/gcc-4.6.2/intl/configure: line 7353: .:
./conf4075subs.sh: file is too large
configure: error: could not make ./config.
On Sun, Nov 6, 2011 at 10:07 AM, Ed Smith-Rowland <3dw...@verizon.net> wrote:
> I think it would be very possible to have a general template library for C++
> that would handle a range of sizes and granularities. There would be a few
> combinations that would correspond to the C types. These wou
Quoting David Brown :
Take an example using a processor I know well, the AVR (it is an 8-bit
device, which is a little unusual for gcc). It has an instruction will
multiply two "1.7" signed 8-bit integers to get a single 1.15 signed
16-bit integer - basically combining an 8-bit x 8-bit to 16-bi
On 6 November 2011 16:10, David Brown wrote:
> Perhaps I have been getting too worked up about small things here, and
> missing out on the major points, such as the efforts made to keep things
> consistent through the use of header files. I still find it odd that
> features are added in different
On Sun, 6 Nov 2011, David Brown wrote:
My original concern in this thread was that if the "r" and "k" _Fract
suffixes were freed for general use in C++, it would be difficult to use
them later.
The C++ standard already reserves all the suffixes that don't start with
an underscore for future
On 06/11/11 16:40, Jonathan Wakely wrote:
On 6 November 2011 15:03, David Brown wrote:
Obviously C++ is going to get features that C does not - that's fair
enough. But it is seldom that there is a good reason for C++ not supporting
the additions to C standards.
Some of the differences are ju
On 11/06/2011 10:40 AM, Jonathan Wakely wrote:
On 6 November 2011 15:03, David Brown wrote:
What usually happens is that if C has claimed a new keyword already
C++ will reuse it. When C++ has added a new keyword such as
static_assert the C committee has preferred to add keywords in the
reserve
On 6 November 2011 15:40, Jonathan Wakely wrote:
>
> I think a better example is atomics support in C++11 and C11, where
> std::atomic aka std::atomic_int can be exactly the same
> representation as _Atomic int and are compatible, but the C++ library
> solution also allows std::atomic which C doesn
On 6 November 2011 15:03, David Brown wrote:
> Obviously C++ is going to get features that C does not - that's fair
> enough. But it is seldom that there is a good reason for C++ not supporting
> the additions to C standards.
>
> Some of the differences are just mind-boggling - C1x has got a
> "_
On Sun, 6 Nov 2011, David Brown wrote:
> Some of the differences are just mind-boggling - C1x has got a
> "_Static_assert" addition, while C++11 has "static_assert". They do the same
> thing, but have a different keyword. Don't these people /talk/ to each other?
> Do they make differences like t
On 05/11/11 21:43, Gabriel Dos Reis wrote:
On Sat, Nov 5, 2011 at 2:30 PM, David Brown
A C++ template class for "_Fract" support would be straightforward to write,
and could easily support the formats in N1169. But it would be very hard to
do so in a way that generates small and fast code witho
24 matches
Mail list logo
