On 11/26/2013 06:38 PM, Joel Sherrill wrote:
Is there something that microblaze-rtems exposes that is not already
covered by other microblaze or rtems targets that are already included?
I believe it was on the microblaze where someone broke the
libgcc pattern for rtems by changing the pattern
On 02/13/2013 03:49 PM, Ludovic Courtès wrote:
Richard Biener skribis:
On Wed, Feb 13, 2013 at 12:13 PM, Richard Biener
wrote:
On Tue, Feb 12, 2013 at 9:41 PM, Ludovic Courtès wrote:
Joel Sherrill skribis:
But it still doesn't address the situation where you have multiple
cross compiler
On 12/15/2012 07:02 PM, Joel Sherrill wrote:
I did test i386-rtems in the past few months but it had a build breakage and I
filed a PR. That issue was resolved but at that point about 1/4 of the rtems
targets failed to compile.
You likely are referring to
http://gcc.gnu.org/bugzilla/show_bug.c
On 12/14/2012 10:09 PM, Richard Biener wrote:
On Fri, Dec 14, 2012 at 9:16 PM, Robert Dewar wrote:
On 12/14/2012 3:13 PM, Cynthia Rempel wrote:
Hi,
RTEMS still supports the i386, and there are many i386 machines still
in use. Deprecating the i386 will negatively impact RTEMS ability to
supp
On 12/14/2012 09:16 PM, Robert Dewar wrote:
On 12/14/2012 3:13 PM, Cynthia Rempel wrote:
Hi,
RTEMS still supports the i386, and there are many i386 machines still
in use. Deprecating the i386 will negatively impact RTEMS ability to
support the i386. As Steven Bosscher said, the "benefits" are
On 12/14/2012 10:03 AM, Erik Trulsson wrote:
Well, the Intel 80486sx did not have an FPU either, while the 80486dx
did have one. From the Pentium (i586) onwards all Intel x86 CPUs have
been equipped with an FPU, so not having an FPU would fit in with being
compatible with i486 but not the i586.
On 12/13/2012 04:53 PM, Erik Trulsson wrote:
Quoting Ralf Corsepius :
On 12/12/2012 08:54 PM, Robert Dewar wrote:
On 12/12/2012 2:52 PM, Steven Bosscher wrote:
And as usual: If you use an almost 30 years old architecture, why
would you need the latest-and-greatest compiler technology
On 12/13/2012 03:15 PM, Robert Dewar wrote:
On 12/13/2012 7:26 AM, Steven Bosscher wrote:
Ralf has found one such a vendor, it seems.
But to me, that doesn't automatically imply that GCC must continue to
support such a target. Other criteria should also be considered. For
instance, quality of
On 12/12/2012 08:54 PM, Robert Dewar wrote:
On 12/12/2012 2:52 PM, Steven Bosscher wrote:
And as usual: If you use an almost 30 years old architecture, why
would you need the latest-and-greatest compiler technology?
Seriously...
Well the embedded folk often end up with precisely this dichotom
On 05/18/2012 09:24 AM, Sebastian Huber wrote:
Hi,
if I run the ARM GCC test suite for C and C++ with the arm-rtemseabi4.11
target, then I get several unexpected errors due to:
gcc/testsuite/gcc/gcc.log:xgcc: error: unrecognized command line option
'-pthread'
gcc/testsuite/g++/g++.log:g++: erro
On 04/12/2012 02:32 PM, Diego Novillo wrote:
On 4/12/12 3:11 AM, Sebastian Huber wrote:
Hello Diego,
what is with targets that only use cross compilers like RTEMS? I think
there is no need for a bootstrap?
No. I'm mostly interested in the stage 0 compiler used in those targets.
I want to deci
On 03/05/2012 10:12 AM, Richard Guenther wrote:
On Sat, 3 Mar 2012, Ralf Corsepius wrote:
On 03/03/2012 02:58 PM, Richard Guenther wrote:
On Sat, Mar 3, 2012 at 11:17 AM, Ralf Corsepius
wrote:
On 03/02/2012 02:44 PM, Richard Guenther wrote:
GCC 4.7.0 Release Candidate available from
On 03/03/2012 02:58 PM, Richard Guenther wrote:
On Sat, Mar 3, 2012 at 11:17 AM, Ralf Corsepius
wrote:
On 03/02/2012 02:44 PM, Richard Guenther wrote:
GCC 4.7.0 Release Candidate available from gcc.gnu.org
The first release candidate for GCC 4.7.0 is available from
ftp://gcc.gnu.org
On 03/02/2012 02:44 PM, Richard Guenther wrote:
GCC 4.7.0 Release Candidate available from gcc.gnu.org
The first release candidate for GCC 4.7.0 is available from
ftp://gcc.gnu.org/pub/gcc/snapshots/4.7.0-RC-20120302
and shortly its mirrors. It has been generated from SVN revision 184777.
On 02/14/2012 06:51 PM, Ian Lance Taylor wrote:
Sebastian Huber writes:
On 02/14/2012 04:05 PM, Ian Lance Taylor wrote:
Sebastian Huber writes:
the default ARM EABI configuration uses short enums by default (from
"gcc/config/arm/arm.c":
/* AAPCS based ABIs use short enums by default. */
On 01/23/2012 06:02 PM, Markus Trippelsdorf wrote:
On 2012.01.23 at 16:45 +0100, Ralf Corsepius wrote:
Hi,
Crossbuilding gcc-4.6.2 for rtems targets succeeds on Fedora 15, 16,
openSUSE-11.4 and 12.1, but fails with this error on Fedora rawhide
(aka. Fedora 17):
...
# gcc -O2 -g -pipe -Wall
Hi,
Crossbuilding gcc-4.6.2 for rtems targets succeeds on Fedora 15, 16,
openSUSE-11.4 and 12.1, but fails with this error on Fedora rawhide
(aka. Fedora 17):
...
# gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -c
On 11/08/2011 04:44 AM, Joel Sherrill wrote:
Hi,
powerpc-rtems does not compile on the head due
to what appear to be changes in the way CPU
features are represented for the arguments.
The compilation error is:
/users/joel/test-gcc/gcc-svn/gcc/config/rs6000/rs6000.c -o rs6000.o
/users/joel/test
Hi,
Since recently, I am facing several of the warnings above when building
GCC-trunk cross for RTEMS targets.
So far, not much clues about what is going on, except that I see
-Wno-narrowing were recently added to
gcc/configure.ac and libcpp/configure.ac.
Ralf
On 01/31/2011 01:02 PM, Andreas Schwab wrote:
Ralf Corsepius writes:
ATM, I am not sure, if what autoconf does actually is useful, but this
is a different matter.
autoconf needs to deliberately trigger errors in a lot of its tests in
order to do the right thing.
I know, but ...
... the
On 01/31/2011 10:19 AM, Jonathan Wakely wrote:
On 31 January 2011 08:59, Ralf Corsepius wrote:
Hi,
gcc emits an error, when compiling this code-snippet:
--- snip ---
extern int x;
void
foo (void)
{
x = sizeof ((long));
}
--- snip ---
# gcc -Wall -o tmp.o -c tmp.c
tmp.c: In function ‘foo
Hi,
gcc emits an error, when compiling this code-snippet:
--- snip ---
extern int x;
void
foo (void)
{
x = sizeof ((long));
}
--- snip ---
# gcc -Wall -o tmp.o -c tmp.c
tmp.c: In function ‘foo’:
tmp.c:6:21: error: expected expression before ‘)’ token
# gcc --version
gcc (GCC) 4.5.1 20100924
On 01/28/2011 05:48 PM, Joel Sherrill wrote:
On 01/28/2011 09:17 AM, Ian Lance Taylor wrote:
Andreas Schwab writes:
Ralf Corsepius writes:
- Remove newlib from the source tree
--without-newlib should probably be enough.
But that seems strange to me as some of the configure scripts test
On 01/28/2011 04:17 PM, Ian Lance Taylor wrote:
Andreas Schwab writes:
Ralf Corsepius writes:
- Remove newlib from the source tree
--without-newlib should probably be enough.
But that seems strange to me as some of the configure scripts test for
--with-newlib and adjust their configury
On 01/28/2011 10:15 AM, Andreas Schwab wrote:
Ralf Corsepius writes:
- Remove newlib from the source tree
--without-newlib should probably be enough.
Good point, agreed.
In case of Joel and rtems the situation probably can be furtherly
simplified:
RTEMS has gcc-4.5.5-compiled newlib
On 01/28/2011 07:49 AM, Ian Lance Taylor wrote:
Ralf Corsepius writes:
On 01/27/2011 07:15 PM, Joel Sherrill wrote:
What is the preferred combination of
--enable-newlib and --with-newlib settings
to build with newlib in the gcc source tree
but not build it and use the installed copy
for the
On 01/27/2011 07:15 PM, Joel Sherrill wrote:
Hi,
There are now 14 RTEMS targets which I try to
test regularly on the head. Where possible,
I try to test C, C++, Ada, and Go. The procedure
is roughly
+ build and install C, C++ with newlib multilibed
+ build and install RTEMS
+ build and install
Gerald Pfeifer wrote:
On Fri, 27 Mar 2009, Ralf Corsepius wrote:
I do see that FreeBSD Ports has mpfr 2.4.1. How advanced of them.
Amazing :-()
It's possible I am missing something here. According to
http://www.mpfr.org/mpfr-current/ (reachable from http://www.mpfr.or
Joe Buck wrote:
On Thu, Mar 26, 2009 at 05:11:04PM -0700, Joel Sherrill wrote:
Tim Prince wrote:
Kaveh R. Ghazi wrote:
What versions of GMP/MPFR do you get on
your typical development box and how old are your distros?
For the RTEMS Project machines we try to stay
on fairly recent Fedora
On Tue, 2008-12-09 at 08:10 -0800, Adam Nemet wrote:
> Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> > Ralf Corsepius <[EMAIL PROTECTED]> writes:
> >
> >> So what would you recommend: To use "gcc -r" or "gcc -Wl,-r" ?
> >
> &g
On Tue, 2008-12-09 at 07:19 -0800, Ian Lance Taylor wrote:
> Ralf Corsepius <[EMAIL PROTECTED]> writes:
>
> > 1) Is "gcc -r" officially supported by gcc?
> >
> > It apparently works, but I can't find it documented anywhere in GCC's
> > docu
Hi,
2 questions:
1) Is "gcc -r" officially supported by gcc?
It apparently works, but I can't find it documented anywhere in GCC's
documentation.
2) Is "gcc -r" any different from using "gcc -Wl,-r"?
Ralf
On Fri, 2008-08-08 at 11:14 -0500, Joel Sherrill wrote:
> Samuel Tardieu wrote:
> >> "Thomas" == Thomas Quinot <[EMAIL PROTECTED]> writes:
> >>
> >
> > Thomas> As an alternative to Arno's suggestion, maybe you could use
> > Thomas> the --with-sysroot configure parameter to make
On Thu, 2008-02-14 at 22:17 +, Joseph S. Myers wrote:
> On Thu, 14 Feb 2008, Joel Sherrill wrote:
> > The m68k/coldfire is suffering from this regression the
> > RTEMS community really would like to see resolved.
> >
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35088
>
> Please try this
On Mon, 2007-07-23 at 19:00 -0700, Tim Prince wrote:
> Should we know which version of Paranoia this is?
It's the version having been integrated into the rtems source tree many
years ago:
http://www.rtems.org/cgi-bin/viewcvs.cgi/rtems/testsuites/samples/paranoia/paranoia.c
> or guess which fla
On Thu, 2007-05-03 at 08:54 -0700, David Daney wrote:
> Ralf Corsepius wrote:
>
> > 1. I submitted a PR, and was asked to login several times inbetween.
> >
>
> I have found that clearing the browser's cookie cache for the site will
> often correct this prob
On Thu, 2007-05-03 at 07:01 -0400, Daniel Berlin wrote:
> On 5/3/07, Ralf Corsepius <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > for reasons I don't know, I am not able to create attachments in gcc's
> > bugzilla for ca the last 24hrs. When doing
On Thu, 2007-05-03 at 10:36 +0100, Dave Korn wrote:
> On 03 May 2007 08:52, Ralf Corsepius wrote:
>
> > Hi,
> >
> > for reasons I don't know, I am not able to create attachments in gcc's
> > bugzilla for ca the last 24hrs. When doing so, I am greeted with
Hi,
for reasons I don't know, I am not able to create attachments in gcc's
bugzilla for ca the last 24hrs. When doing so, I am greeted with the
message below.
--- snip ---
Internal Error
GCC Bugzilla has suffered an internal error. Please save this page and
send it to [EMAIL PROTECTED] with deta
On Wed, 2006-03-15 at 20:10 -0800, Alexey Starovoytov wrote:
> Hi,
>
> The default architecture for GCC SPARC is V7.
> What do gcc sparc developers think about changing it to V8PLUS?
>
> Few things to consider:
> - v7 is legacy
> . used in old Sun's sun4c systems
> . 32-bit only
> .
On Wed, 2006-03-08 at 16:43 -0600, Joel Sherrill wrote:
> Andreas Schwab wrote:
>
> >Joel Sherrill <[EMAIL PROTECTED]> writes:
> >
> >
> >
> >>RPM invoked make install with the prefixes overriden:
> >>
> >>make
> >>prefix=/home/rtems/tmp/rtems-4.7-sparc-rtems4.7-gcc-newlib-gcc4.1.0newlib1.14.0
On Mon, 2006-02-27 at 15:17 +0100, Ralf Corsepius wrote:
> On Mon, 2006-02-27 at 08:08 -0600, Joel Sherrill wrote:
> > Ralf Corsepius wrote:
> >
> > >On Sun, 2006-02-26 at 18:29 -0500, Frank Ch. Eigler wrote:
> > >
> > >
> > >>Hi -
> &g
On Mon, 2006-02-27 at 08:08 -0600, Joel Sherrill wrote:
> Ralf Corsepius wrote:
>
> >On Sun, 2006-02-26 at 18:29 -0500, Frank Ch. Eigler wrote:
> >
> >
> >>Hi -
> >>
> >>On Sun, Feb 26, 2006 at 10:54:09PM +0100, Gerald Pfeifer wrote:
> >
On Sun, 2006-02-26 at 18:29 -0500, Frank Ch. Eigler wrote:
> Hi -
>
> On Sun, Feb 26, 2006 at 10:54:09PM +0100, Gerald Pfeifer wrote:
> > On Sun, 26 Feb 2006, Ralf Corsepius wrote:
> > > Cross building and installing gcc-4.1.0 rc2 (--prefix=/usr/local)
>
Hi,
Cross building and installing gcc-4.1.0 rc2 (--prefix=/usr/local)
installs these headers:
/usr/local/include/ssp/unistd.h
/usr/local/include/ssp/string.h
/usr/local/include/ssp/ssp.h
/usr/local/include/ssp/stdio.h
Is this behavior correct?
/usr/local/include is reserved for host files. Thes
On Fri, 2006-02-03 at 09:45 -0600, Joel Sherrill wrote:
> >>>The problem is with using stdint.h integer types without checking if
> >>>they are actually
> >>>available. I have posted a fix for this already that needs to be
> >>>reviewed. Along with
> >>>some other fixes for similar target OS depe
On Mon, 2005-11-21 at 13:48 -0600, Joel Sherrill wrote:
> I also have this arm-rtems specific patch. Something changed after
> 4.0.x and none of the RTEMS BSPs would link before I added this.
>
> Index: gcc/config/arm/rtems-elf.h
> ==
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 and C++
> cros
On Fri, 2005-10-28 at 08:49 +0200, Andreas Jaeger wrote:
> Ralf Corsepius <[EMAIL PROTECTED]> writes:
>
> > Hi,
> >
> > I don't seem to be able to access svn:
> >
> > # svn ls svn://gcc.gnu.org/svn/gcc
> > [several (2-3) minutes pass, during w
On Fri, 2005-10-28 at 08:49 +0200, Andreas Jaeger wrote:
> Ralf Corsepius <[EMAIL PROTECTED]> writes:
>
> > Hi,
> >
> > I don't seem to be able to access svn:
> >
> > # svn ls svn://gcc.gnu.org/svn/gcc
> > [several (2-3) minutes pass, during w
Hi,
I don't seem to be able to access svn:
# svn ls svn://gcc.gnu.org/svn/gcc
[several (2-3) minutes pass, during which svn is non-interruptable]
svn: Can't connect to host 'gcc.gnu.org': Connection timed out
Ralf
Hi,
As it seems to me, CFLAGS handling with newlib+gcc-4.0.x one-tree style
cross-builds seems broken.
So far I have tried different permutations of setting CFLAGS,
CFLAGS_FOR_BUILD, CFLAGS_FOR_HOST and CFLAGS_FOR_TARGET, but have not
been successful so far.
Therefore - question: How is one supp
On Tue, 2005-05-17 at 12:11 -0500, Joel Sherrill wrote:
> 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 ma
On Tue, 2005-05-17 at 12:52 +0200, Steven Bosscher wrote:
> On May 17, 2005 12:21 PM, Ralf Corsepius <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 2005-05-17 at 12:16 +0200, Steven Bosscher wrote:
> > > On May 17, 2005 11:29 AM, Richard Earnshaw <[EMAIL PROTECTED]> w
On Tue, 2005-05-17 at 12:16 +0200, Steven Bosscher wrote:
> On May 17, 2005 11:29 AM, Richard Earnshaw <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 2005-05-17 at 01:59, Steven Bosscher wrote:
> >
> > > No, I just don't build gfortran as a cross. There are many reasons
> > > why this is a bad idea an
On Tue, 2005-05-17 at 03:31 +0200, Steven Bosscher wrote:
> On Tuesday 17 May 2005 03:16, Joe Buck wrote:
> > On Tue, May 17, 2005 at 03:11:03AM +0200, Steven Bosscher wrote:
> > > On Tuesday 17 May 2005 02:59, Steven Bosscher wrote:
> > > > Oh, and how helpful of you to post that patch to gcc-patc
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 -0400, Peter Barada wrote:
> > > Until package maintainers take cross-compilation *seriously*, I have
> > > no choice but to
On Mon, 2005-05-16 at 10:42 -0400, Peter Barada wrote:
> Until package maintainers take cross-compilation *seriously*, I have
> no choice but to do native compilation of a large hunk of the packages
> on eval boards that can literally takes *DAYS* to build.
The most amazing fact to me is: Not eve
On Wed, 2005-05-11 at 22:42 +0200, Gerald Pfeifer wrote:
> On Wed, 11 May 2005, Roman Kennke wrote:
> >>> Is the pkgconfig directory at the correct location when put under lib/,
> >>> or shouldn't this be libdata/ instead?
> >> What system has $(prefix)/libdata? None I'm familiar with.
> > The BSD
On Sun, 2005-05-08 at 22:54 -0700, Zack Weinberg wrote:
> Ralf Corsepius <[EMAIL PROTECTED]> writes:
>
> > On Sun, 2005-05-08 at 21:34 -0700, Zack Weinberg wrote:
> >> Ralf Corsepius <[EMAIL PROTECTED]> writes:
> >>
> >> > FWIW: IMO, NO_I
On Sun, 2005-05-08 at 21:34 -0700, Zack Weinberg wrote:
> Ralf Corsepius <[EMAIL PROTECTED]> writes:
>
> > FWIW: IMO, NO_IMPLICIT_EXTERN_C actually is an OS/libc feature ("Your
> > system headers are c++ aware"), therefore it is hardly possible
On Sun, 2005-05-08 at 23:34 +, Joseph S. Myers wrote:
> The following targets (based on wildcarded entries from config.gcc) do
> *not* appear to define NO_IMPLICIT_EXTERN_C, i.e. GCC is configured to
> suppose their headers are not C++-aware and to add an implicit extern
> "C" around them. Are
On Fri, 2005-04-15 at 10:39 -0600, E. Weddington wrote:
> What?! That whole section in the docs talks about attributes on types.
> If it doesn't work as described, then the docs need some serious rework.
>From what I see, the example for packed types doesn't even compile:
(Direct cut'n'paste fr
On Fri, 2005-04-15 at 09:27 -0600, E. Weddington wrote:
> Ralf Corsepius wrote:
>
> >Hi,
> >
> >I just tripped over this snipped below in a piece of code, I didn't
> >write and which I don't understand:
> >
> >...
> >struct somes
Hi,
I just tripped over this snipped below in a piece of code, I didn't
write and which I don't understand:
...
struct somestruct {
struct entrystruct *e1 __attribute__ ((packed));
struct entrystruct *e2 __attribute__ ((packed));
};
...
Is this meaningful?
I guess the author wanted e1 and e
65 matches
Mail list logo
