tbp wrote:
On 8/23/07, Tim Prince <[EMAIL PROTECTED]> wrote:
Note that icc9 has a strong bias for pentium4, which had no stall
penalty for mistyped fp vectors as for Intel it came with the pentium
M line, so you see a pxor even if generating code for the core2.
# cat autoicc.cc
float foo(cons
bruno steckelberg wrote:
I got this messages on the shell screen:
COMP-BRUNO:/home/bruno/Programas/cups-1.4svn-r6852# ./configure
checking for gawk... no
checking for mawk... mawk
checking for gcc... gcc
checking for C compiler default output file name... configure: error:
C compiler cannot crea
I got this messages on the shell screen:
COMP-BRUNO:/home/bruno/Programas/cups-1.4svn-r6852# ./configure
checking for gawk... no
checking for mawk... mawk
checking for gcc... gcc
checking for C compiler default output file name... configure: error:
C compiler cannot create executables
See `config.
Bootstrap of current trunk on powerpc64-linux fails in libstdc++
building system_error.lo. The code that fails was added a few days ago,
but the failure seems to be the same as the one reported in PR 31490. I
verified that the patch from comment #10 of that PR allows bootstrap of
c,c++,fortran to
On Mon, 2007-08-27 at 22:24 +0300, Revital1 Eres wrote:
> Hello,
>
> I get the following error on ppc64 with trunk r127835:
That failures is fixed in r127836.
Janis
Snapshot gcc-4.1-20070827 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070827/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On 8/27/07, Revital1 Eres <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> I get the following error on ppc64 with trunk r127835:
This should be fixed by revision 127836.
-- Pinski
David Daney wrote:
You never state what you are trying to build. "cross compiler" does
not really narrow it down.
Also you don't state what errors you are experiencing.
I'm experimenting with building a Linux based cross compiler/tool-chain
for building the Kernel and Apps
for every target in
Stephen M. Kenton wrote:
During the recent discussion about cross compilers I was told "bugs
happen", so I went hunting.
I have been digging into why building a cross compiler dies in different
ways for different targets.
As seen below, the Linux targets which use glibc define
MD_UNWIND_SUPPORT
On Mon, Aug 27, 2007 at 03:29:23PM -0500, Stephen M. Kenton wrote:
> As seen below, the Linux targets which use glibc define MD_UNWIND_SUPPORT and
> have
> a customized linux-unwind.h file. However, mips and i386 start and end those
> files with
> #ifndef inhibit_libc #endif statements whic
During the recent discussion about cross compilers I was told "bugs
happen", so I went hunting.
I have been digging into why building a cross compiler dies in different
ways for different targets.
As seen below, the Linux targets which use glibc define
MD_UNWIND_SUPPORT and have
a customized lin
I've been solving conflicts left and right and ran into the same set
of problems Diego describes independently.
What's up with cbsi_last()/bsi_last(), and the rest of the functions
that have been duplicated? We really shouldn't be changing APIs here,
and if we absolutely need more than one routin
Hello,
I get the following error on ppc64 with trunk r127835:
c/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include
-I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd
-I../libdecnumber../../gcc/gcc/regclass.c -o regclass.o
../../gcc/gcc/regclass.c: In function
"Ed S. Peschko" <[EMAIL PROTECTED]> writes:
> As I'm going through, yes I can make mods to work around these bugs, but it
> sure is
> a pain.. It would be much easier if gnu-ld simply *worked* on AIX (and of
> course AIX
> stopped shipping broken libraries)
I did the initial GNU ld port to AIX
Some shuffling was needed due to the const patches, but things seem to
be working.
I was doing a merge from mainline into the tuples branch this morning
when I found various conflicts due to the constification patches. I
realized that not only there are some routines that take 'const_tree'
instead of 'tree', but also that there are new API routines as well.
I agree in general w
On 23 August 2007 22:34, Mark Mitchell wrote:
> I do think that generating the same code, independent of host system, is
> a very important property of GCC's design, just like generating the same
> code independent of whether or not we're compiling with -g.
Hear, hear. I've always thought th
17 matches
Mail list logo
