BUG in libstdc++-v3/config/os/generic/error_constants.h

snip libstdc++-v3/config/os/generic/error_constants.h not_supported = ENOTSUP, snip libstdc++-v3/config/os/generic/error_constants.h OpenBSD 4.2 not defined ENOTSUP, only EOPNOTSUPP ! .

Re: symbol lookup error: cc1: undefined symbol: mpfr_remquo

On Mon, 21 Jan 2008, Kaveh R. GHAZI wrote: > > Exactly this issue. I am not sure how this can happen. My configure > > options are above. I am using the Compile Farm. > > This happens because you linked GCC with a shared MPFR library in > /opt/cfarm/mpfr-2.3.0/lib, but because there is no -rpath s

Re: Question about Register Class Allocation

"Balaji V. Iyer" <[EMAIL PROTECTED]> writes: > I saw that regclass() function determines which class of register > the registers in the current units should be assigned to. The question I > have is: Will this decision change in any other parts of the compiler? > or is this this the final place

Question about Register Class Allocation

Hello Everyone, I am currently working with Gcc 4.0.2 and I have a question regarding the register allocation. I saw that regclass() function determines which class of register the registers in the current units should be assigned to. The question I have is: Will this decision change in a

Re: GCC 4.3 target deprecation proposals

On Wed, Jan 23, 2008 at 07:28:23PM -0500, DJ Delorie wrote: > > > You can't cross-test, with DejaGnu running elsewhere? > > I've tried. The problem is communication between the DOS system (or > emulator) and the host system. DOS isn't kind to networking, > semaphores, or anything else that hint

Re: c++0x concepts in gcc call

On Mon, Jan 28, 2008 at 5:38 PM, Gerald Pfeifer <[EMAIL PROTECTED]> wrote: > On Sun, 27 Jan 2008, Doug Gregor wrote: > > I was planning to kill the cxx0x-branch outright, because it has > > nothing that isn't available on mainline (except a not-nearly-complete > > delegating constructors impleme

Re: GCC 4.3 target deprecation proposals

Joseph S. Myers wrote: Following my proposal for target architecture deprecations in 4.3 , I now propose the following list of individual targets to deprecate, based on the same methodology previously described. The patch to remove c4x and depreca

Re: Memory leaks in compiler

On Jan 29, 2008 2:14 PM, Ira Rosen <[EMAIL PROTECTED]> wrote: > > Hi, > > [EMAIL PROTECTED] wrote on 16/01/2008 15:20:00: > > > > When a loop is vectorized, some statements are removed from the basic > > > blocks, but the vectorizer information attached to these BBs is never > > > freed. > > > > Se

Re: Memory leaks in compiler

(I am resending this, since some of the addresses got corrupted. My apologies.) Hi, [EMAIL PROTECTED] wrote on 16/01/2008 15:20:00: > > When a loop is vectorized, some statements are removed from the basic > > blocks, but the vectorizer information attached to these BBs is never > > freed. > >

Re: Memory leaks in compiler

(I am resending this, since some of the addresses got corrupted. My apologies.) Hi, [EMAIL PROTECTED] wrote on 16/01/2008 15:20:00: > > When a loop is vectorized, some statements are removed from the basic > > blocks, but the vectorizer information attached to these BBs is never > > freed. > >

Re: Memory leaks in compiler

Hi, [EMAIL PROTECTED] wrote on 16/01/2008 15:20:00: > > When a loop is vectorized, some statements are removed from the basic > > blocks, but the vectorizer information attached to these BBs is never > > freed. > > Sebastian, thanks for bringing this to our attention. I'll look into this. > I ho

Announce: MPFR 2.3.1 is released

MPFR 2.3.1 is now available for download from the MPFR web site: http://www.mpfr.org/mpfr-2.3.1/ Thanks very much to those who sent us bug reports (in particular Kevin Rauch) and/or tested the release candidates. The MD5's: 8352b619e04dcc73411a38b39dd855f6 mpfr-2.3.1.tar.bz2 cf882c61f5da60c9f

Fwd: _Unwind_Resume on the stack

No, We have compiled our application on RHEL 3 with libgcc-3.2.3-34. On Jan 29, 2008 3:44 PM, Andrew Haley <[EMAIL PROTECTED]> wrote: > > Pavan R wrote: > > Hi, > > > > We find our application dumps core on Suse 10 SP1 that has > > libgcc-4.1.2_20070115-0.11 shipped, with the top of the stack a

Re: _Unwind_Resume on the stack

Pavan R wrote: Hi, We find our application dumps core on Suse 10 SP1 that has libgcc-4.1.2_20070115-0.11 shipped, with the top of the stack as : Program terminated with signal 11, Segmentation fault. #0 0xf7aca09c in memcpy () from /lib/libc.so.6 (gdb) bt #0 0xf7aca09c in memcpy () from /lib/

_Unwind_Resume on the stack

Hi, We find our application dumps core on Suse 10 SP1 that has libgcc-4.1.2_20070115-0.11 shipped, with the top of the stack as : Program terminated with signal 11, Segmentation fault. #0 0xf7aca09c in memcpy () from /lib/libc.so.6 (gdb) bt #0 0xf7aca09c in memcpy () from /lib/libc.so.6 #1 0x08