Re: Implementing C++1x and C1x atomics

On Wed, 12 Aug 2009, Lawrence Crowl wrote: > > The C1x atomics specification > > does > > not mention any amendment to the list of headers to be provided by > > freestanding implementations (clause 4 paragraph 6), which suggests > > that

Re: Implementing C++1x and C1x atomics

On 8/12/09, Joseph S. Myers wrote: > (moved from gcc-patches to gcc and libc-alpha) > > On Wed, 12 Aug 2009, Richard Guenther wrote: > > On Aug 12, 2009, Boehm, Hans wrote: > > > [Partially replying to myself] > > > > From: Boehm, Hans > > > > > > > > At the risk of asking a stupid question, shou

Re: Build report for GCC 4.4.1/i386-unknown-freebsd7.2/binutils-2.19.1

Loren James Rittle wrote: > In article <4a83449e.2020...@gmail.com>, > Dave Korn writes: > >> Loren James Rittle wrote: >>> http://gcc.gnu.org/ml/gcc-testresults/2009-08/msg01308.html > >> That post doesn't exist yet! Typo or prediction? :) > > Hi Dave, > > Proper post presents per previousl

Re: error in hash.cc

On Wed, 2009-08-12 at 15:09 -0700, Benjamin Kosnik wrote: > > I get the same failure for powerpc64-linux. It starts with r150641 > > from Benjamin Kosnik. > > Should be fixed in r150707 It fails in the same way. Janis

Re: Anyone else run ACATS on ARM?

On 12.08.2009 23:07, Martin Guy wrote: On 8/12/09, Joel Sherrill wrote: So any ACATS results from any other ARM target would be appreciated. I looked into gnat-arm for the new Debian port and the conclusion was that it has never been bootstrapped onto ARM. The closest I have seen is Adaco

Re: Build report for GCC 4.4.1/i386-unknown-freebsd7.2/binutils-2.19.1

In article <4a83449e.2020...@gmail.com>, Dave Korn writes: > Loren James Rittle wrote: >> http://gcc.gnu.org/ml/gcc-testresults/2009-08/msg01308.html > That post doesn't exist yet! Typo or prediction? :) Hi Dave, Proper post presents per previously predicted place. Regards, Loren

Re: Build report for GCC 4.4.1/i386-unknown-freebsd7.2/binutils-2.19.1

Loren James Rittle wrote: > http://gcc.gnu.org/ml/gcc-testresults/2009-08/msg01308.html That post doesn't exist yet! Typo or prediction? :) cheers, DaveK

Build report for GCC 4.4.1/i386-unknown-freebsd7.2/binutils-2.19.1

GCC 4.4.1 was successfully built, checked and installed on i386-unknown-freebsd7.2. Note: Default configure options were used except GNU binutils 2.19.1.20090812 rather than system's binutils 2.15 and the testsuite was run with -pthread. http://gcc.gnu.org/ml/gcc-testresults/2009-08/msg01308.htm

Re: error in hash.cc

> I get the same failure for powerpc64-linux. It starts with r150641 > from Benjamin Kosnik. Should be fixed in r150707 -benjamin

How to deal with 48-bit pointers and 32-bit integers

I'm doing a port for an unusual new machine which is 32-bit RISCy in every way, except that it has 48-bit pointers. Pointers have a high-order 16-bit segID and low-order 32-bit seg offset. Most ALU instructions only work on 32 bits, zeroing the upper 16-bit seg ID in the result. A few ALU op

Re: Anyone else run ACATS on ARM?

On 8/12/09, Joel Sherrill wrote: > So any ACATS results from any other ARM target would be > appreciated. I looked into gnat-arm for the new Debian port and the conclusion was that it has never been bootstrapped onto ARM. The closest I have seen is Adacore's GNATPro x86->xscale cross-compiler h

Build report for GCC 4.4.1/i386-unknown-freebsd7.2

GCC 4.4.1 was successfully built, checked and installed on i386-unknown-freebsd7.2. Note: Default configure options were used except GNU binutils 2.16.1 rather than system's binutils 2.15 and the testsuite was run with -pthread. http://gcc.gnu.org/ml/gcc-testresults/2009-08/msg01220.html (Pleas

Build report for GCC 4.3.4/i386-unknown-freebsd7.2

GCC 4.3.4 was successfully built, checked and installed on i386-unknown-freebsd7.2. Note: Default configure options were used except GNU binutils 2.16.1 rather than system's binutils 2.15 and the testsuite was run with -pthread. http://gcc.gnu.org/ml/gcc-testresults/2009-08/msg01193.html (Pleas

Implementing C++1x and C1x atomics

(moved from gcc-patches to gcc and libc-alpha) On Wed, 12 Aug 2009, Richard Guenther wrote: > On Wed, Aug 12, 2009 at 8:24 PM, Boehm, Hans wrote: > > [Partially replying to myself] > >> From:  Boehm, Hans > >> > >> At the risk of asking a stupid question, shouldn't all the > >> code inside gcc gr

Re: error in hash.cc

On Wed, 2009-08-12 at 14:52 +0300, Revital1 Eres wrote: > Hello, > > I get the following error while compiling gcc -r150679 on ppc I get the same failure for powerpc64-linux. It starts with r150641 from Benjamin Kosnik. Janis

Re: i370 port

GCC relies on the libiberty "pex" family of routines, which are much more narrow in scope, and have in fact been ported to several non-UNIX systems, including even MS-DOS. Providing a port of "pex" to MVS should be much easier that porting a full Unix "system" or "fork" feature. Ok. But I don'

Re: i370 port

Paul Edwards wrote: > > What is the problem with having GCC itself invoke the linker, just like > > it does on other platforms? > > 1. That requires extensions to the C90 standard. The behaviour of > system() is undefined, much less even the existence of fork() etc. > > 2. The attempt to add fu

Re: i370 port

Ok, after a few false leads, I found something that produced a pleasing result. Fantastic I should say! With this mod: C:\devel\gcc\gcc>cvs diff debug.c Index: debug.c === RCS file: c:\cvsroot/gcc/gcc/debug.c,v retrieving revision 1

Re: i370 port

Thanks guys for your reply. As Paolo mentioned, the -dA flag is an option to the *compiler* that causes it to place additional information into its output stream (the assembler source code). [from Paolo] Only DWARF-2 output supports it currently, but if you want to use it say together with S

Anyone else run ACATS on ARM?

Hi, GNAT doesn't build for arm-rtems on 4.4.x or SVN (PR40775). I went back to 4.3.x since I remembered it building. I have run the ACATS on an ep7312 target and get a number of generic test failures that don't look RTEMS specific. Has anyone run ACATS on arm? The following tests fail with

Re: i370 port

Paul Edwards wrote: > > That depends a bit on the compiler version and optimization level, > > but (in particular in the 3.x time frame) GCC may output assembler > > code on a function-by-function basis, without necessarily reading > > in the whole source file first. > > Ok, actually it doesn't ma

Re: i370 port

In any case, if you build with -g and use in addition the "debug assembler output" flag -dA the assembler output should contain human-readable comments containing line number information. Regardless, if line number notes are interspersed in the stream, maybe whenever I write out an assembler i

Re: [gcc-in-cxx] replacing qsort with std::sort

2009/8/12 Richard Guenther : > On Wed, Aug 12, 2009 at 2:03 AM, Pedro > Lamarão wrote: >> I've recently started my contributions to the gcc-in-cxx project, and >> eventually decided on the qsort suggestion because it seems the >> easiest one. >> I've made the change in three places in cp/classes.c

error in hash.cc

Hello, I get the following error while compiling gcc -r150679 on ppc Thanks, Revital

Re: [gcc-in-cxx] replacing qsort with std::sort

Pedro Lamarão writes: > Also, is the gcc-in-cxx branch still active? Should my objective be to > contribute patches to this branch? The gcc-in-cxx branch is currently dead, having been merged into mainline. We can choose to revive it for contributions like yours. I would be interested in opini

Re: [gcc-in-cxx] replacing qsort with std::sort

On Wed, Aug 12, 2009 at 2:03 AM, Pedro Lamarão wrote: > I've recently started my contributions to the gcc-in-cxx project, and > eventually decided on the qsort suggestion because it seems the > easiest one. > I've made the change in three places in cp/classes.c; the patch can be > found here: > >