Joseph S. Myers wrote:
On Thu, 24 Jan 2008, DJ Delorie wrote:
At the moment, I'm working on getting sh, h8300, and m32c in shape for
4.3 (or future). I can easily get the test results under 400k by
removing some of the multilibs, but I don't think that's a good idea.
My sh-elf test tests 38
Dave Korn wrote:
On 22 January 2008 14:06, Manuel López-Ibáñez wrote:
I note the lack of anyone posting test results for
uClinux, OpenBSD or RTEMS, and suggest that users of those operating
systems should try to post test results for at least some target
architectures.
Sorry. For RTE
David Edelsohn wrote:
"Joel Sherrill writes:
Joel> With code updated this morning, powerpc-rtems fails to build. I am
Joel> using binutils 2.16.1 with just a couple of patches.
Joel> Is this a gcc or binutils error? Is there a known fix?
This is not a known problem. There have b
With code updated this morning, powerpc-rtems fails to build. I am
using binutils 2.16.1 with just a couple of patches.
Is this a gcc or binutils error? Is there a known fix?
==
/home/joel/gcc-work/head/b-powerpc-rtems4.7/./gcc/xgc
Jakub Jelinek wrote:
On Wed, Dec 14, 2005 at 04:34:17PM -0600, Joel Sherrill <[EMAIL PROTECTED]>
wrote:
My fresh check out on the head build using the gcc shipped with
Fedora Core 4 has failed for the past couple of days with this error:
A day and half.
Is this a known failure?
Hi,
My fresh check out on the head build using the gcc shipped with
Fedora Core 4 has failed for the past couple of days with this error:
/home/joel/gcc-work/head/b-native/./gcc/xgcc
-B/home/joel/gcc-work/head/b-native/./gcc/
-B/home/joel/gcc-head-test//i686-pc-linux-gnu/bin/
-B/home/joel/gc
Frédéric PRACA wrote:
Selon Laurent GUERBY <[EMAIL PROTECTED]>:
On Mon, 2005-11-21 at 12:15 -0600, Joel Sherrill wrote:
arm-rtems4.7 does build C, C++, and Ada on the gcc SVN head. I have
done no testing beyond that.
Is there a simulator for arm? Frederic do you have a testing
environmen
Laurent GUERBY wrote:
On Mon, 2005-11-21 at 12:15 -0600, Joel Sherrill wrote:
arm-rtems4.7 does build C, C++, and Ada on the gcc SVN head. I have
done no testing beyond that.
Is there a simulator for arm? Frederic do you have a testing
environment in mind? What "--enable-rtemsbsp=X" should
Ralf Corsepius wrote:
On Mon, 2005-11-21 at 17:14 +0100, Frédéric PRACA wrote:
Hi,
I'm currently trying to build an Ada cross compiler for ARM using the arm-rtems
target. I tried with GCC 4.0.2 and subversion-version but I failed.
What should I know to do this knowing that I already built the C
Thomas Quinot wrote:
* Joel Sherrill <[EMAIL PROTECTED]>, 2005-11-17 :
I hope the explanation above helps make it clearer.
Yes, thanks for the clarification. In light of this explanation the
proposed fix seems appropriate; maybe a comment could be added along
with the extern declarat
Laurent GUERBY wrote:
On Fri, 2005-11-18 at 15:14 -0600, Joel Sherrill wrote:
+ No PR - The Ada tools mangle target names like arm-rtems4.7.
Apparently they don't like the version part. Laurent is working on
this.
To be accurate I promised to work on this once Paolo configure
patch is
Mark Mitchell wrote:
The number of open serious regressions against 4.1 is a respectable 87,
quite a few of which are P3s, waiting for me to categorize them. We
still have some work to do before the release, but we will branch on
2005-11-18, as previously announced, at some point late Friday eve
Thomas Quinot wrote:
* Joel Sherrill <[EMAIL PROTECTED]>, 2005-11-16 :
RTEMS has networking functions but they are not available at this stage
during the build.
I am not sure I understand how this can happen (I am not familiar at all
with the RTEMS build process). If the network fun
Doing an overnight build of all rtems targets, I can across this
new breakage for m68k-rtems4.7. I last built this target on Nov 3
from the head and it compiled then.
/home/joel/gcc-work/head/b-m68k-rtems4.7/./gcc/xgcc
-B/home/joel/gcc-work/head/b-m68k-rtems4.7/./gcc/ -nostdinc
-B/home/joel/
Andrew Pinski wrote:
Is this valid C or C++? I am getting a syntax error when
compiled as C++ but not C.
int f()
{
int x, y, ;
}
I am getting a syntax error with the C front-end but not with the
C++ front-end. This is definitely a bug as this is invalid C++ also.
This is a regression from
Is this valid C or C++? I am getting a syntax error when
compiled as C++ but not C.
int f()
{
int x, y, ;
}
--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED] On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 3580
As of this morning, Ada no longer compiles for *-rtems.
I think this change broke it.
2005-11-14 Thomas Quinot <[EMAIL PROTECTED]>
* socket.c (__gnat_get_h_errno): New function to retrieve h_errno, the
hosts database last error code.
RTEMS has networking functions but they are not availa
Arnaud Charlet wrote:
How many of such platforms are available and known to work in the FSF
tree?
Strange question. The answer is all the platforms currently known to
work with Ada (too many to be listed here).
One alternative is to have an s-auxdec-empty and use that
on platforms where s-a
Eric Botcazou wrote:
Building a --target=avr compiler currently fails because
/usr/src/packages/BUILD/gcc-4.1.0-20051110/obj-x86_64-suse-linux/./gcc/xgcc
-B/usr/src/packages/BUILD/gcc-4.1.0-20051110/obj-x86_64-suse-linux/./gcc/
-B/opt/cross/avr/bin/ -B/opt/cross/avr/lib/ -isystem
/opt/cross/avr/
Laurent GUERBY wrote:
On Thu, 2005-11-03 at 17:43 +0100, Paolo Bonzini wrote:
Joel Sherrill <[EMAIL PROTECTED]> wrote:
Hi,
I have been trying to build sparc-rtems4.7 on the head using newlib's
head for a few days now. I have finally narrowed the behavior down.
If I configure
Hi,
Gcc on the head fails to compile arm-rtems4.7 at the following point
when Ada is enabled.
../../xgcc -B../../ -c -g -O2 -W -Wall -gnatpg s-auxdec.adb -o
s-auxdec.o
s-auxdec.ads:286:13: alignment for "Aligned_Word" must be at least 4
Any ideas?
--
Joel Sherrill, Ph.D.
I added an include of to gcc/ada/raise.c and now the
arm-rtems4.7 target compiles Ada enough to get to the same GNAT bug box
as powerpc, mips, and mips64 do. So whatever I tripped appears to
be a cross-CPU Ada issue.
Long term, where should the include of stdarg.h be for raise.c?
I just add
Thanks to Paolo Bonzini's patch, I can get much further and now have
more to report. :)
The Good
h8300-rtems4.7 - C, C++ build OK (Ada not tried)
i386-rtems4.7 - C, C++, Ada build OK
m68k-rtems4.7 - C, C++, Ada build OK
sh-rtems4.7 - C, C++ build OK (Ada not tried)
sparc-rtems4.7 - C
Hi,
I have been trying to build sparc-rtems4.7 on the head using newlib's
head for a few days now. I have finally narrowed the behavior down.
If I configure for sparc I am configuring for sparc-rtems4.7 with c and
c++, it builds fine. The build process uses xgcc for newlib as one
would ex
Or at least I think it's the head. I am still learning subversion. :)
I am testing using gcc-head-test with the *-rtems targets. I managed
to build a native compiler and am using that to build the cross
compilers. But when the build gets around to trying to build newlib, it
is using CC=${ta
Frédéric PRACA wrote:
Hello,
I'm trying to build a cross-compiler for RTEMS. Building C or C++ cross-compiler
is not a problem but building the Ada compiler does'nt work. In fact, even
building a normal compiler does'nt work at all. The main reason I found is that
the gcc driver of FreeBSD doesn'
Frédéric PRACA wrote:
Hello,
I'm trying to build a cross-compiler for RTEMS. Building C or C++ cross-compiler
is not a problem but building the Ada compiler does'nt work. In fact, even
building a normal compiler does'nt work at all. The main reason I found is that
the gcc driver of FreeBSD doesn'
Matthias Klose wrote:
Mark Mitchell writes:
Daniel Jacobowitz wrote:
My inclination is to do nothing (other than correct the target
milestones on these bugs in bugzilla) and move on. The Solaris problem
is bad, and I beat up on Benjamin to get it fixed, but I'm not sure it's
a crisis meriti
Mark Mitchell wrote:
The GCC 4.0.2 RC3 prerelease is spinning now.
If all goes well, it will be available later today.
From an RTEMS perspective, 4.0.2RC2 with no patches appeared to
be at least as good as 4.0.1 w/RTEMS patches. I spotted no
new issues. I built a native C, C++, and Ada compi
Mark Mitchell wrote:
It's important to test the actual tarballs, rather than CVS, to check
for any packaging issues. If you can, download and build the tarballs,
post test results to the gcc-testresults mailing list with and
contrib/test_summary. If you encounter problems, please file them i
Geoffrey Keating wrote:
"Joseph S. Myers" <[EMAIL PROTECTED]> writes:
On Fri, 7 Jul 2005, Ian Lance Taylor wrote:
[EMAIL PROTECTED] (Geoffrey Keating) writes:
* gcc.c: Include xregex.h.
(version_compare_spec_function): New.
(spec_function): Add version-compare.
I'm happy to anounce that Andreas Schwab <[EMAIL PROTECTED]>
as the new m68k port maintainer.
I, for one, thank him and wish him well in this effort. :)
--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED] On-Line Applications Research
Ask me
E. Weddington wrote:
Nathanael Nerode wrote:
Propose to stop using fixproto immediately:
avr-*-*
I'm not even sure exactly what fixproto is supposed to do, but I
*highly* doubt that it is needed for the AVR target. The AVR target is
an embedded processor that uses it's own C library, av
Peter Barada wrote:
Yes, but Ralf was complaining about embedded cross-compiling development
for RTEMS. I have not tried to reply to Peter Barada who complains about
GCC inablity to be run on embedded targets directly.
Logically Peter's situation is the same as the NetBSD issue with
building and
Karel Gardas wrote:
On Tue, 17 May 2005, Alexandre Oliva wrote:
On May 17, 2005, Karel Gardas <[EMAIL PROTECTED]> wrote:
you see that 4.0 added "embedded" platforms like arm-none-elf and
mips-none-elf to the primary platforms list.
These are only embedded targets. You can't run GCC natively on th
Joe Buck wrote:
I used to be an embedded programmer myself, and while I cared very much
about the size and speed of the embedded code I wound up with, I didn't
care at all about being able to run the compiler itself on a machine that
wasn't reasonably up to date, much less trying to bootstrap the c
Jonathan Wakely wrote:
On Tue, May 17, 2005 at 11:14:22AM +0200, Ralf Corsepius wrote:
* I wasn't aware about this fortran specific patch posting policy. I
never have sent any gcc patch to any other list but gcc-patches for
approval before, so I also had not done so this time.
* How could I know t
This is really getting pretty far from the original topic but
I am diving in anyway.
Steven Bosscher wrote:
On Tuesday 17 May 2005 02:53, Ralf Corsepius wrote:
On Tue, 2005-05-17 at 00:10 +0200, Steven Bosscher wrote:
On Monday 16 May 2005 23:43, Ralf Corsepius wrote:
On Mon, 2005-05-16 at 10:42 -0
Peter Barada wrote:
Well, yes. 1 second/file is still slow! I want "make" to complete
instantaneously! Don't you?
Actually I want it to complete before I even start, but I don't want
to get too greedy. :)
What's really sad is that for cross-compilation of the toolchain, we
have to repeat a few
I know I asked late in the process but this fix for a m68k/coldfire
failure just showed up:
[Bug target/18421] ICE in reload_cse_simplify_operands, at postreload.c:391
Any chance at it getting considered?
Thanks.
--joel
Mark Mitchell wrote:
Sadly, it's become clear there's going to have to be a s
[EMAIL PROTECTED] wrote:
Hi,
Attached are the patches for coldfire v4e. These
changes are originally contributed by Peter Barada. I
have migrated and tested these changes from gcc 3.04
to gcc 3.4 and now to mainline.
Since coldfire v4e has MMU we need to support
m68k-linux target for coldfire
Mark Mitchell wrote:
Marcus Meissner wrote:
Btw,
We still see some critical 4.0 problems, ordered by my view of
importance:
PR/20126 triggers a miscompilation of python (i386 and x86_64 at least).
PR/20917 triggers a miscompilation of glibc (on s390).
PR/20739 triggers a --enable-checking problem
Joel Sherrill <[EMAIL PROTECTED]> wrote:
Richard Earnshaw wrote:
On Wed, 2005-04-06 at 00:30, Mark Mitchell wrote:
Joe Buck wrote:
But if it won't even build, then users should be warned.
I suppose -- but we have relatively many configurations that probably
won't build, at le
Richard Earnshaw wrote:
On Wed, 2005-04-06 at 00:30, Mark Mitchell wrote:
Joe Buck wrote:
But if it won't even build, then users should be warned.
I suppose -- but we have relatively many configurations that probably
won't build, at least if you start combining various options, and
including lan
44 matches
Mail list logo
