tting the __NO_LWSYNC__
macro correctly for each CPU variant.
Thanks.
--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED]On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
Andrew Pinski wrote:
On Thu, Jun 19, 2008 at 1:36 PM, Joel Sherrill
<[EMAIL PROTECTED]> wrote:
Hi,
I ran into something tracking down a test
failure on psim and now thing there is a
target specific issue that needs addressing.
lwsync is sync with the bit 9 set. So it should be
Joe Buck wrote:
On Thu, Jun 19, 2008 at 03:50:34PM -0500, Joel Sherrill wrote:
On Thu, Jun 19, 2008 at 1:36 PM, Joel Sherrill
<[EMAIL PROTECTED]> wrote:
Hi,
I ran into something tracking down a test
failure on psim and now thing there is a
target specific issue that
.
Is PR 36583 in your list? It is an ICE on the Coldfire that is a
regression from 4.2.x.
--
Joseph S. Myers
[EMAIL PROTECTED]
--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED]On-Line Applications Research
Ask me about RTEMS: a free
joel AT gcc DOT gnu.org
Thanks.
--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED]On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
Paolo Bonzini wrote:
Arnaud Charlet wrote:
I had to solve one rts source issue though:
gcc/ada/system-linux-x86_64.ads and x86.ads do hardcode the number of
bits for a word (64 and 32 respectively), I changed them both to be
completely the same and use GNAT defined Standard'Word_Size attribut
Arnaud Charlet wrote:
The idea currently is to make these values
explicit so that when people read system.ads, they know right away what
the right value is.
That's "when people read system.ads", not "when people read
system-linux-x86.ads". In other words, he's not necessarily again
Laurent GUERBY wrote:
Joel did test (a previous iteration of) this patch on many RTEMS
multilibed targets and it worked (RTEMS system.ads already use Standard
attributes to be portable so no issue there).
I thought I would follow up with some details. I tested
on mips, powerpc, x86, and spar
r"
make.adb:4460:36: found type "Gnat.Os_Lib.File_Descriptor" defined at
g-os_lib.ads:160
make.adb:6605:13: expected type "System.Os_Lib.File_Descriptor"
make.adb:6605:13: found type "Gnat.Os_Lib.File_Descriptor" defined at
g-os_lib.ads:160
Any suggestions?
Paolo Bonzini wrote:
Arnaud Charlet wrote:
Any suggestions?
I would double check that you are indeed using the freshly built
corresponding native. Maybe your native installation didn't work as
expected and your building from an older compiler. That's the
most likely explanation.
Alte
t (1997 by grep) appear to be because
the ep7312 is not a Neon CPU and the tests did not
even compiler.
As with other RTEMS test configurations, we are
passing an explicit CPU model CFLAGS (-mcpu=arm7tdmi).
Any suggestions on how this entire set of
tests can detect they don't apply?
--
Joel
Joseph S. Myers wrote:
On Wed, 6 Aug 2008, Joel Sherrill wrote:
Hi,
I have just posted the first gcc test results
for arm-rtems to gcc-testresults.
C/C++: http://gcc.gnu.org/ml/gcc-testresults/2008-08/msg00608.html
Ada: http://gcc.gnu.org/ml/gcc-testresults/2008-08/msg00601.html
There
Joseph S. Myers wrote:
On Wed, 6 Aug 2008, Joel Sherrill wrote:
I see the code for arm_neon_ok. If I can make that test fail,
we are in business. I tried the cpp part of the following code
and it doesn't trip for:
arm-rtems4.9-gcc -mfpu=neon -mfloat-abi=softfp -mcpu=arm7td
Hi,
Attached is the latest revision of the Ada
Hardware Interrupt patch. It has been tracked
as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35576
Interrupt support tested on sparc-rtems.
ACATS reported on sparc, mips, i386, powerpc, and arm.
2008-08-06 Joel Sherrill <[EMAIL PROTEC
Paul Brook wrote:
On Wednesday 06 August 2008, Joseph S. Myers wrote:
On Wed, 6 Aug 2008, Joel Sherrill wrote:
$ arm-rtems4.9-gcc -mfpu=neon -mfloat-abi=softfp -mcpu=arm7tdmi -c
test_neon.c /tmp/ccBzigjD.s: Assembler messages:
/tmp/ccBzigjD.s:13: Error: selected processor does not
Paul Brook wrote:
arm-rtems4.9-gcc -mfpu=neon -mfloat-abi=softfp -mcpu=arm7tdmi -c
test_neon.c
#if !defined(__ARM_NEON__)
#error "Neon not supported"
#endif
void neon_code(void)
{
asm volatile ("vldr d18,[fp,#-32]");
}
Works fine here. Either your assembler is busted, or there is some
t our assembly code.
The main visible change is that that you must preserve 8-byte stack alignment
at public entry points.
Is there a standard conditional to know the difference if
it matters?
__ARM_EABI__
Paul
--
Joel Sherrill, Ph.D. Director of Research & De
int 1 [0x1])))
]) -1 (nil))
../../gcc/libiberty/regex.c:4221: internal compiler error: in
extract_insn, at recog.c:1988
Please submit a full bug report,
--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED]On-Line Applications Research
Ask me about
: error:
sys/termios.h: No such file or directory
yes
checking for sys/types.h... s-oscons-tmplt.c: In function 'main':
s-oscons-tmplt.c:1096: error: invalid application of 'sizeof' to
incomplete type 'struct sockaddr_in'
Is there an alternative way to generate s-o
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 the required
Thomas> headers available to the build process. I know others have
Tho
Ralf Corsepius wrote:
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> t
r.
+
2008-08-09 Paolo Carlini <[EMAIL PROTECTED]>
+ Revert fix for libstdc++/35637, thanks to other/36901.
+ * include/tr1_impl/type_traits (__is_function_helper): New, uses
+ variadic templates.
+ (is_function): Forward to the latter.
+ (__in_array): Remove.
+
-
targets (at least powerpc-elf and powerpc-rtems)
if gcc is going to generate this instruction, the simulator
needs to support it or there will be lots of failures.
David Daney
--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED]On-Line Applications
David Edelsohn wrote:
On Thu, Sep 4, 2008 at 8:31 AM, Joel Sherrill <[EMAIL PROTECTED]> wrote:
Another related issue is that psim in gdb does not currently
support the lwsync instruction so any code generated using it
would fail there. Since this is used as the test platform f
x27;t
happen.
My questions are...
+ Is this sufficient to pass a reasonable subset
of the ACATS?
+ Is it known which, if any, tests would be expected
to fail in this environment?
Thanks.
--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED]On-Line App
- explicit fail Incorrect results
cxg2018 - Memory exception at 44000 (illegal address)
cxg2019 - Memory exception at 44000 (illegal address)
cxg2021 - Memory exception at 44000 (illegal address)
Joel Sherrill wrote:
Hi,
RTEMS has BSPs for a couple of simulators that
do not have a source for clock
p,_malloc" NOT -Wl,-wrap,malloc".
Where is the leading underscore not getting dealt with
so the wrap functions get invoked.
FWIW I didn't see any h8300-elf results since last year
and wonder if this is a known issue.
--
Joel Sherrill, Ph.D. Director of Research & Deve
Jeff Law wrote:
Joel Sherrill wrote:
Hi,
I am trying to run the gcc test suite on h8300-rtems
and getting lots of failures which look like this:
/home/joel/work-gnat/svn/b-gcc1-h8300/gcc/xgcc
-B/home/joel/work-gnat/svn/b-gcc1-h8300/gcc/
/home/joel/work-gnat/svn/gcc/gcc/testsuite/gcc.c
Mark Mitchell wrote:
Steven Bosscher wrote:
On 5/12/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
PR 31797: An infinite loop in the compiler while building RTEMS.
Daniel, I see you've been commenting on this; are you working on the
fix? If so, do you have an ETA?
Why are you wai
Mike Stump wrote:
On May 14, 2007, at 11:53 AM, Eric Christopher wrote:
On May 14, 2007, at 11:35 AM, Mike Stump wrote:
On May 14, 2007, at 8:46 AM, Patrick Olinet wrote:
Running with gdb, it looks like the problem comes from the
ppc_closure.S file of the libffi/src/powerpc directory, at l
The gcc version used by RTEMS 4.7 is 4.1.1 with no patches in this area.
I duplicated this behavior with gcc 4.2.0. gcc 3.2.3 still generated FPU
instructions in his test case.
--joel
Peter A. Krauss wrote:
Hello,
I have downloaded sparc-rtems4.7 and would like to use it for a leon2 target
Eric Botcazou wrote:
I have downloaded sparc-rtems4.7 and would like to use it for a leon2
target with fpu. I am puzzled on how the compiler inserts fpu instructions.
My summary is:
- The compiler does insert fpu instructions, if no fpu command line option
is given or if "-mhard-quad-float" is u
Richard Kenner wrote:
The second, it was a bit suspicious to me that in one day two Google
guys got global maintainership although as I wrote Diego did not work on
rtl for a long time. One the other hand, I see Google has a good
developers and may be I was a bit paranoid.
Right. A fe
mitted morally and/or legally to providing
long-term support for gcc directly and/or OSes that ship
with a gcc. I really believe these people need guidance
from the FSF on what to do.
--joel sherrill
Hi,
In analyzing the output of paranoia, Eric Norum
and I have noticed that when compiled at
default optimization levels, the results
are reported to have a flaw. When compiled
with no optimization, paranoia reports no flaws.
I tried this with RTEMS running on psim using
gcc 4.2.1. RTEMS uses
Andrew Pinski wrote:
On 7/23/07, Joel Sherrill <[EMAIL PROTECTED]> wrote:
Given the age of paranoia (the version included
with RTEMS is from Cygnus circa 1993), does this
sound familiar or is this a new issue?
What happens if you use -mno-fused-madd option?
Same result for me using RT
Tim Prince wrote:
[EMAIL PROTECTED] wrote:
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/sampl
Joern Rennecke wrote:
Given the age of paranoia (the version included
with RTEMS is from Cygnus circa 1993), does this
sound familiar or is this a new issue?
Is this related to PR29100?
I don't think so since I was using 4.2.1
and tried that option upon someone else's
suggestion.
FWIW
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
es for unchecked conversion have different sizes
See PR33454. Revert r127960 for a workaround.
does it now try to build a multilib for libada?
libada still does not support multilib.
Joel Sherrill tried something on Ada multilib support, if multilib
experts want to help h
Dave Korn wrote:
On 28 September 2007 17:10, François-Xavier Coudert wrote:
PS: The compilation error I get, if that rings a bell to someone who
installed metahtml on the webserver, is in libmhtml:
Compiling pagefuncs.c into pagefuncs.o
gcc -Wall -Wstrict-prototypes -Wshadow -g -DHAVE_CON
Hi,
I have Ada interrupt tasks that are attached
to real hardware interrupts working for RTEMS.
I based the RTEMS code on the existing code
for VxWorks.
I tried to minimize my modifications since I
could tell that the OS functionality used was
very generic. But since the implementation
in s-i
Eric Botcazou wrote:
I would appreciate it is one of the SPARC/Solaris
users would see if they can duplicate this.
I cannot duplicate on SPARC/Solaris, but my tree is not pristine.
This is for a --disable--bootstrap compiler built at -O0 -g.
The two files in question do compile at -O0
this.
Thanks.
--joel sherrill
Hi,
I am trying to get the SVN head built locally again
and back at work on the GNAT/RTEMS work I was doing.
Unfortunately, I have tripped across something that
is quite bad. Compiling on Linux x86 targeting the
PowerPC or SPARC leads to a huge compilation time
on a single file.
joel 27918 2
Hi,
I am trying to test some RTEMS specific
Ada modifications on the SVN trunk.
I cannot get simple programs to work.
The SPARC target produces executables
which die very early. I haven't looked
into them much but something seems bad.
The PowerPC target is passing bad values
into some subrouti
Eric Botcazou wrote:
Can anyone report that Ada works on the
head on a SPARC or PowerPC self-hosted
system?
http://gcc.gnu.org/ml/gcc-testresults/2007-11/msg00945.html
Thanks. That doesn't appear to be as bad as
what I am seeing.
Have you seen anything like the gnat1 compile
time
Eric Botcazou wrote:
Thank you for confirming it wasn't just me or my configuration. This
looks like a serious issue to me.
It's partly your configuration, this presumably doesn't happen on platforms
that use DWARF-2 exception handling, i.e. most native platforms (I just
re-tested SPARC
Eric Botcazou wrote:
Have you seen anything like the gnat1 compile
time I reported yesterday?
Try to configure with --enable-checking=release.
Well it is now up to 13 minutes of compile time
on that one file when it is 30 seconds at -O0 so
this doesn't appear to help significantly.
Eric Botcazou wrote:
Thanks. That doesn't appear to be as bad as
what I am seeing.
Quite good actually.
Have you seen anything like the gnat1 compile
time I reported yesterday?
Try to configure with --enable-checking=release.
No. I will add that to the list of things to d
Krister Walfridsson wrote:
On Wed, 28 Nov 2007, Joel Sherrill wrote:
I am trying to get the SVN head built locally again
and back at work on the GNAT/RTEMS work I was doing.
Unfortunately, I have tripped across something that
is quite bad. Compiling on Linux x86 targeting the
PowerPC or
Eric Botcazou wrote:
Doing this fixed the long build time issue but it opened issue.
OK, thanks for confirming.
It looks like the RTEMS configuration is missing something
that this requires. The first application I tried to link is missing:
+ __gnat_eh_personality
+ __gnat_begin_han
Eric Botcazou wrote:
On the SPARC, this produced an executable I couldn't run
on the simulator. It looked like the .text segment may
have increased enough to not fit in the simulator.
Weird. The EH tables should probably not end up in .text.
RTEMS applications are statically linked
Hi,
Even with the large gnat1 compile time issue, I
have managed to patiently run the ACATS on
powerpc-rtems. This configuration worked
well with gcc 4.2.2 (3 failures). I am seeing
lot of failures (total of 691) and they do not
appear to be RTEMS related.
Here is a sample. Do any of these lo
07-12/
Thanks Laurent. Those look much better than what I
am getting.
Could this be related to PR34400?
--joel
Laurent
On Fri, 2007-12-14 at 12:48 -0600, Joel Sherrill wrote:
Hi,
Even with the large gnat1 compile time issue, I
have managed to patiently run the ACATS on
powerpc-rtems.
Laurent GUERBY wrote:
On Fri, 2007-12-14 at 13:41 -0600, Joel Sherrill wrote:
Laurent GUERBY wrote:
ACATS is clean (0 FAIL) on trunk for x86. CXF3A03 is the
only FAIL for hppa-linux. c41328a is the only FAIL for powerpc64-linux.
cxb3014/16 are the only FAIL on ia64-linux.
You&#x
Laurent GUERBY wrote:
On Fri, 2007-12-14 at 14:45 -0600, Joel Sherrill wrote:
34400 is about slow compile but not about wrong code so I doubt it's the
issue. Could you send me privately the compressed log of the ACATS run?
Sure.
>From the log it looks like th
ers having
largely moved on by the time it was merged. Not an excuse, just a
statement that there was not a clean handoff to a new maintainer.
I recall that the original port being using binutils 2.7 so that
gives a timeframe.
R.
--
Joel Sherrill, Ph.D. Director of Research & Deve
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
problem triggering in ncurses
(all platforms)
PR/20929 triggers a miscompilation of Mozilla.
Any chance of getting this m68k specific one added to the RC2
list?
18421 ICE in reload_cse_simplify_operands, at postreload.c:391
Those are all on the Wiki page as possible patches for an RC2.
Thanks,
--
Joel
Jaiprakash
__
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/
--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED] On-Line Applications Research
Ask me about RTEMS: a free RT
in_apply_args on SPARC (specific).
* http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01036.html
GLIBC does not compile on S390.
* http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01015.html
Fortran fix.
* http://gcc.gnu.org/ml/java-patches/2005-q2/msg00088.html
Java l
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
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
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
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
L PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED] On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
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
o longer uses fixincludes anyway. If there are any
problems with the headers, we should be able fix them directly in avr-libc.
Ralf is on vacation for a few weeks.
avr-rtems is using newlib. *-rtems uses newlib so I assume it would not
need anything adjusted.
HTH
Eric
--
Joel Sherrill, Ph
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
ies to all code linked for that board. So it is more a user level
feature to us than a gcc internal one.
It should only be documented in one place though.
--joel
--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED] On-Line Applications Resea
ms4.7 h8300-rtemscoff4.7
i386-rtems4.7 m68k-rtems4.7 mips64-rtems4.7 mips-rtems4.7
powerpc-rtems4.7 sh-rtems4.7 sh-rtemscoff4.7 sparc-rtems4.7
tic4x-rtems4.7
I noticed a couple of those should show deprecated or obsoleted
in the build logs so I can verify that.
Thanks.
--
Joel Sherrill,
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
is easily accessible.
In spite of the pain, a dot release is probably the safest thing all
around.
Sorry this happened. I can sympathize with your pain. :(
Matthias
--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED] On-Line Applicatio
y this person does.
http://lists.freebsd.org/pipermail/freebsd-ports/2004-November/017632.html
Or to just use the Linux emulation and run the Linux RTEMS tools.
Thanks
Fred
--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED] On-Line Applications Resear
to be the same.
Thanks
Fred
--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED] On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
ng CC=${target}-cc not the xgcc from the built gcc subdirectory.
I am using the same configure command I used with gcc 4.0.x and
including --with-newlib.
Has anyone else tried to build a newlib target from the head recently?
--joel sherrill
tatus.
--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED] On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
+
| 4.1.0 20051102 (experimental) (mips-unknown-rtems4.7) GCC error: |
| tree check: expected class |
| Error detected at a-calend.adb:480:24
Advice, patches always appreciated.
--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL P
added it above the function db() around line 230.
--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED] On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
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 Sher
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
(const_int 1 [0x1])) [5 S2 A8])
(reg:HI 24 r24)) 12 {*movhi} (nil)
(nil))
../../../../../../gcc-head-test/newlib/libc/misc/init.c:59: internal
compiler error: in spill_failure, at reload1.c:1890
--
Joel Sherrill, Ph.D. Director of Research & Development
[EM
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
107093)
+++ gcc/ada/socket.c(working copy)
@@ -190,6 +190,10 @@
#elif defined(VMS)
return errno;
#else
+#if defined(__rtems__)
+ /* No networking .h files are available from newlib so extern this. */
+ extern int h_errno;
+#endif
return h_errno;
#endif
}
--
Joel Sherrill
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 Huntsvill
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
yesterday afternoon, binutils 2.16.1 and
newlib 1.13.0.
I can file a PR but this is definitely a recent breakage.
--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED] On-Line Applications Research
Ask me about RTEMS: a free RTOS Hunts
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
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
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
pat
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
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
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-rtems
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 t
-head-test/
--enable-languages=c,c++,ada
Is this a known failure?
--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED] On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256)
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?
using
-mrelocatable
==
--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED] On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Avail
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 proble
Hi
For RTEMS, we normally build a multilib'ed gcc+newlib, but I have a case
where the CPU model is something not covered by our multilibs and not one
we are keen to add. I've looked around but not found anything that makes me
feel confident.
What's the magic for building a gcc+newlib with a singl
401 - 500 of 509 matches
Mail list logo
