[Bug target/31786] error: unable to find a register to spill in class 'BASE_POINTER_REGS'

2007-05-03 Thread ralf dot corsepius at rtems dot org
--- Comment #5 from ralf dot corsepius at rtems dot org 2007-05-03 13:12 --- Subject: RE: error: unable to find a register to spill in class 'BASE_POINTER_REGS' On Thu, 2007-05-03 at 06:05 -0600, Eric Weddington wrote: > > > --- Comment #2 from ralf

[Bug libstdc++/26497] libstdc++-v3: configure: test: -lt: unary operator expected

2006-03-16 Thread ralf dot corsepius at rtems dot org
--- Comment #6 from ralf dot corsepius at rtems dot org 2006-03-16 09:06 --- (In reply to comment #5) > Unfortunately, GLIBCXX_CHECK_LINKER_FEATURES is a native-only test. Could you explain why it is native-only? AFAIS, it tries to run the linker, which is a build-host tool at t

[Bug libstdc++/26497] libstdc++-v3: configure: test: -lt: unary operator expected

2006-02-28 Thread ralf dot corsepius at rtems dot org
--- Comment #4 from ralf dot corsepius at rtems dot org 2006-03-01 06:38 --- (In reply to comment #3) > glibcxx_gnu_ld_version is only set when building natively, but used when > --with-gnu-ld which implies --enable-symvers=gnu. So what to do? Moving GLIBCXX_CHECK_LINKER_FEATUR

[Bug libstdc++/26497] libstdc++-v3: configure: test: -lt: unary operator expected

2006-02-28 Thread ralf dot corsepius at rtems dot org
--- Comment #2 from ralf dot corsepius at rtems dot org 2006-02-28 16:04 --- ../gcc-4.1.0/configure \ --prefix=/usr/local --bindir=/usr/local/bin --includedir=/usr/local/include \ --libdir=/usr/local/lib --mandir=/usr/local/man \ --infodir=/usr/local/info \--datadir=/usr/local/share

[Bug libstdc++/26497] New: libstdc++-v3: configure: test: -lt: unary operator expected

2006-02-28 Thread ralf dot corsepius at rtems dot org
nu dot org ReportedBy: ralf dot corsepius at rtems dot org GCC host triplet: i386-pc-linux-gnu GCC target triplet: sparc-sun-solaris2.7 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26497

[Bug other/26473] [4.1/4.2 Regression] cross-building installs ssp headers to $(includedir)

2006-02-27 Thread ralf dot corsepius at rtems dot org
--- Comment #5 from ralf dot corsepius at rtems dot org 2006-02-27 17:48 --- Created an attachment (id=10922) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10922&action=view) Move ssp headers into $(toolexeclibdir)/include This patch moves libssp's headers to $(to

[Bug other/26473] [4.1/4.2 Regression] cross-building installs ssp headers to $(includedir)

2006-02-27 Thread ralf dot corsepius at rtems dot org
--- Comment #4 from ralf dot corsepius at rtems dot org 2006-02-27 17:44 --- (From update of attachment 10920) Though I still think GCC's toplevel configure to be bugged and this to be fixing some of then, this patch doesn't solve the problems of this PR. withdrawn --

[Bug other/26473] [4.1/4.2 Regression] cross-building installs ssp headers to $(includedir)

2006-02-27 Thread ralf dot corsepius at rtems dot org
--- Comment #3 from ralf dot corsepius at rtems dot org 2006-02-27 14:12 --- Created an attachment (id=10920) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10920&action=view) Before mentioned patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26473

[Bug other/26473] [4.1/4.2 Regression] cross-building installs ssp headers to $(includedir)

2006-02-27 Thread ralf dot corsepius at rtems dot org
--- Comment #2 from ralf dot corsepius at rtems dot org 2006-02-27 14:11 --- IMO, the cause is clear: The toplevel configure script is broken. Rationale: 1. libssp/* applies a standard automake-based configuration. i.e. includedir is supposed to be pointing to the final $includedir

[Bug other/26473] New: cross-building installs ssp headers to $(includedir)

2006-02-26 Thread ralf dot corsepius at rtems dot org
lding installs ssp headers to $(includedir) Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ralf dot corsepius at rtems do

[Bug target/17824] Hard-coded AS and LD in c4x.h

2005-04-06 Thread ralf dot corsepius at rtems dot org
--- Additional Comments From ralf dot corsepius at rtems dot org 2005-04-06 08:15 --- OK to apply this patch to 4.0, too? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17824

[Bug target/17822] avr: Hard-coded XXX_FOR_TARGET

2005-04-05 Thread ralf dot corsepius at rtems dot org
--- Additional Comments From ralf dot corsepius at rtems dot org 2005-04-06 06:18 --- OK to apply this patch to gcc-4.0, too? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17822

[Bug target/16719] [ColdFire] Illegal move of byte itno address register causes compiler to ICE

2005-01-28 Thread ralf dot corsepius at rtems dot org
--- Additional Comments From ralf dot corsepius at rtems dot org 2005-01-28 14:11 --- The patch contained in http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00405.html doesn't seem to work for me, rsp. triggers another ICE, at least the error message seems to have changed: With to

[Bug target/19663] LINK_GCC_C_SEQUENCE_SPEC doesn't play nice with RTEMS

2005-01-28 Thread ralf dot corsepius at rtems dot org
--- Additional Comments From ralf dot corsepius at rtems dot org 2005-01-28 13:31 --- Then I don't understand, why it's exactly them which apply a similar work-around as RTEMS does: # grep LINK_GCC_C_SEQUENCE_SPEC *.h linux64.h:#undef LINK_GCC_C_SEQUENCE_SPEC linux64

[Bug target/19663] LINK_GCC_C_SEQUENCE_SPEC doesn't play nice with RTEMS

2005-01-28 Thread ralf dot corsepius at rtems dot org
--- Additional Comments From ralf dot corsepius at rtems dot org 2005-01-28 09:17 --- (In reply to comment #2) > > IMO, sparc.h's LINK_GCC_C_SEQUENCE_SPEC probably is specific to solaris and > > not > > generally applicable. May-be, it's an historic artefact

[Bug target/16719] [ColdFire] Illegal move of byte itno address register causes compiler to ICE

2005-01-27 Thread ralf dot corsepius at rtems dot org
--- Additional Comments From ralf dot corsepius at rtems dot org 2005-01-27 17:31 --- (In reply to comment #2) > Confirmed, here is a reduced testcase: I can't confirm this ICE with your reduced testcase and m68k-rtems-gcc. But I can confirm m68k-rtems-gcc to be ICEing with the