extremely busy lately, so it's a possibility. It would also be
useful to explain how you are basing your evaluation, and in
particular say what does not work for you.
> I also infer that Adacore continues to use the AIX assembler, not GNU as.
We also use GNU as.
--
Joel
l=large and thread local storage support added to GCC.
Perfect, this gives me a better idea of what to ask for on Monday.
I will see what the current status is. We do boostrap GCC, but
I don't think we've tried with the current HEAD, only GCC 4.7.
--
Joel
next few weeks to track them down - if I do, I will
post them.
With all patches, we are able to bootstrap GCC 4.7. But we haven't
tried the HEAD version. From David's report, it sounds like we should
expect additional work if we want to do it.
--
Joel
://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446
--
Joel Sherrill, Ph.D. Director of Research& Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35806
Support Available (256) 722-9985
ep in the
right direction.
But it still doesn't address the situation where you have multiple
cross compilers in your PATH all for different targets. It addresses
the most common use case though.
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.
imulators.
It wouldn't bother me if you submitted them to DejaGNU.
Diego.
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available(256) 722-9985
H.J. Lu wrote:
On Feb 8, 2008 11:02 AM, Joel Sherrill <[EMAIL PROTECTED]> wrote:
Please try native compiler first.
Finished with no errors on "make". Any other step?
Which trunk revision are you using?
xgcc (GCC) 4.3.0 20080208 (experimental) [trunk revisi
H.J. Lu wrote:
On Fri, Feb 08, 2008 at 11:41:07AM -0600, Joel Sherrill wrote:
H.J. Lu wrote:
On Feb 8, 2008 9:37 AM, Joel Sherrill <[EMAIL PROTECTED]> wrote:
Strange. I update this morning and built a new native Fedora 8 ia32
compiler followed by a cross to powerpc
isn't. :(
--
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
H.J. Lu wrote:
On Feb 8, 2008 9:37 AM, Joel Sherrill <[EMAIL PROTECTED]> wrote:
Strange. I update this morning and built a new native Fedora 8 ia32
compiler followed by a cross to powerpc-rtems. The native was
configured as:
../gcc/configure \
--with-gnu-as --disable-multilib \
ative was
configured as:
../gcc/configure \
--with-gnu-as --disable-multilib \
--with-gnu-ld --verbose --with-system-zlib --disable-nls \
--enable-version-specific-runtime-libs \
--enable-languages=c,ada --prefix=$INSTALL &&
--joel
H.J.
--
Joel Sherrill, Ph.D. Dire
.
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
sting over the weekend
and just posted the ACATS results on gcc-testresults.
The PR now has a patch applied to it which gives
ACATS results for SPARC and PowerPC on the
trunk which are comparable to 4.2.3.
--joel
Best wishes,
Duncan.
--
Joel Sherrill, Ph.D. Director of Res
trading
versions of these for years and they should be in gcc.
--joel
rtems_acats_scripts.tar.bz2
Description: application/bzip
, could this be a typo?
[EMAIL PROTECTED] arm]$ grep do_itt *
ieee754-df.S: do_itt eq
ieee754-sf.S: do_itt eq
However, we have:
lib1funcs.asm:.macro do_it cond, suffix=""
and many references to "do_it" macro in asm sources.
Thanks.
--joel
Jakub Jelinek wrote:
Status
===
to see resolved.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35088
I just emailed everyone who touched the m68k port since
last summer a charity appeal. :-D
--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED]On-Line Applications Research
Ask me abou
Richard Guenther wrote:
On Thu, Feb 14, 2008 at 7:42 PM, Joel Sherrill
<[EMAIL PROTECTED]> wrote:
Alexandre Pereira Nunes wrote:
> Also regarding ARM, PR31849
> (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31849
> <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31849&g
Joseph S. Myers wrote:
On Thu, 14 Feb 2008, Joel Sherrill wrote:
Alexandre Pereira Nunes wrote:
Also regarding ARM, PR31849
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31849
<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31849>) is a show stopper,
at least for some embedded bare
Would it be confuse anyone
on those targets if I rigged things so all
of the executables passed? (e.g. a fake simulator
that printed "*** EXIT code 0"
--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED]On-Line Applications Research
As
test the i386 and something isn't quite right for i386.
It looks like it branches off to never never land and then
gets a fault. I haven't had a chance to look into it yet.
I posted results to gcc-testresults.
--joel
2) does it work to build 4.3 cross-gnattools with the current 4
on all primary and secondary
platforms.
- It is actively maintained
- the RM can still downgrade regressions to P4 to P6.
Regards,
Tobias
--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED]On-Line Applications Research
Ask me about RTEM
Joe Buck wrote:
On Wed, Feb 20, 2008 at 02:27:27PM -0800, Tim Prince wrote:
Joel Sherrill wrote:
Tobias Burnus wrote:
According to the GCC 4.4 Release Criteria,
http://gcc.gnu.org/gcc-4.4/criteria.html, only C and C++ are primary
languages. And thus only C and C++ regressions
On Mon, 3 Mar 2008, [EMAIL PROTECTED] wrote:
I have a stand-alone, non-Web-based app. that I'd like to
distribute as a .exe with some database files, to a layman
audience, and I'd like to avoid issues of JRE distribution and
compatibility, etc. So I'm hoping someone, somewhere, has
written a rep
Hi,
I think something has broken for GNU/Linux x86 in
the past week on the head. It was building fine last
week. Does anyone else see this?
/home/joel/work-gnat/svn/b-native/./prev-gcc/xgcc
-B/home/joel/work-gnat/svn/b-native/./prev-gcc/
-B/home/joel/work-gnat/svn//install/i686-pc-linux-gnu
Eric Botcazou wrote:
I think something has broken for GNU/Linux x86 in
the past week on the head. It was building fine last
week. Does anyone else see this?
You just need to browse Bugzilla, it's PR tree-opt/35493.
Thanks both of you. It builds now.
--
Eric Botcazou
--joel
ed systems. :)
--
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
Richard Guenther wrote:
On Wed, Mar 12, 2008 at 4:23 PM, Joel Sherrill
<[EMAIL PROTECTED]> wrote:
Hi,
Did the default i386 CPU model that gcc generates
code for change between 4.2.x and 4.3.0? I didn't
see anything in the release notes that jumps out at
me about this.
H.J. Lu wrote:
On Wed, Mar 12, 2008 at 09:13:07AM -0700, Andrew Pinski wrote:
On Wed, Mar 12, 2008 at 9:09 AM, Joel Sherrill
<[EMAIL PROTECTED]> wrote:
10022a: f2 0f 10 c0 movsd %xmm0,%xmm0
Is there any way to skip these tests for particular HW features
other odd multilib
CPU option that the test suite hits and a particular
target CPU does not support. Right?
--joel
David Edelsohn wrote:
Joel Sherrill writes:
Joel> If I understand this correctly, it is checking that the
Joel> target HW actually supports the Neon extension.
Joel> Is this right?
Joel> Where does this get invoked?
Joel> I think I am on the edge of understanding
David Edelsohn wrote:
Joel Sherrill writes:
Joel> Those all look like checks to see if the compiler itself
Joel> supports Altivec -- not a run-time check on the hardware
Joel> like the Neon check_effective_target_arm_neon_hw appears
Joel> to be.
David Edelsohn wrote:
Joel Sherrill writes:
Joel> Those all look like checks to see if the compiler itself
Joel> supports Altivec -- not a run-time check on the hardware
Joel> like the Neon check_effective_target_arm_neon_hw appears
Joel> to be.
Joseph S. Myers wrote:
On Wed, 12 Mar 2008, David Edelsohn wrote:
Joel Sherrill writes:
Joel> FAIL: gcc.target/powerpc/405-mullhw-1.c scan-assembler mullhw
Joel> Are those things which would be expected to fail on a vanilla
Joel> 603e target without networkin
Jan Hubicka wrote:
David Edelsohn wrote:
Joel Sherrill writes:
Joel> Those all look like checks to see if the compiler itself
Joel> supports Altivec -- not a run-time check on the hardware
Joel> like the Neon check_effective_target_arm_neon_hw appears
Jo
Uros Bizjak wrote:
On Thu, Mar 13, 2008 at 2:35 PM, Joel Sherrill
<[EMAIL PROTECTED]> wrote:
I hacked on that test program to get the attached
program. I ran it multiple times on qemu.
ext=0x0 sig=0x756e6547
0x781abfd YES on SSE2
I am now printing the return valu
Uros Bizjak wrote:
Joel Sherrill wrote:
I hacked on that test program to get the attached
program. I ran it multiple times on qemu.
ext=0x0 sig=0x756e6547
0x781abfd YES on SSE2
I am now printing the return value from __get_cpuid_max()
ext=0x0 sig=0x756e6547 returned=0x2
test for that. This leads to this:
Starting program:
/home/joel/work-gnat/svn/b-gcc1-sparc/gcc/testsuite/gcc/pr18400.exe
Unexpected trap (0x 2) at address 0x02001318
illegal instruction
Program exited normally.
(gdb) disassemble 0x02001318
Dump of assembler code for function check_vect:
...
0x0
Seongbae Park (박성배, 朴成培) wrote:
> On Thu, Mar 13, 2008 at 11:31 AM, Joel Sherrill
> <[EMAIL PROTECTED]> wrote:
>
>> Hi,
>>
>> Moving on the SPARC, I see a lot of similar
>> unsupported instruction failures. I only
>> see a single sparc feature
ons
in the test case?
Executing on host: /home/joel/work-gnat/svn/b-gcc1-sparc/gcc/xgcc
-B/home/joel/work-gnat/svn/b-gcc1-sparc/gcc/
/home/joel/work-gnat/svn/gcc/gcc/testsuite/gcc.dg/vect/vect-align-2.c
gcc_tg.o -ftree-vectorize -fno-vect-cost-model -mcpu=ultrasparc -mvis
-O2 -fdump-tree-ve
Joseph S. Myers wrote:
On Wed, 12 Mar 2008, David Edelsohn wrote:
Joel Sherrill writes:
Joel> FAIL: gcc.target/powerpc/405-mullhw-1.c scan-assembler mullhw
Joel> Are those things which would be expected to fail on a vanilla
Joel> 603e target without networkin
Thank you. I will rerun the tests on this target overnight
with this change along with disabling profiling tests
for *-*-rtems*.
It looks like the wheat and chafe are separating a bit. :)
--joel
Uros Bizjak wrote:
Joel Sherrill wrote:
This is with the Fedora 8 qemu 0.90 RPM. There was
Uros Bizjak wrote:
Hello!
This one looks like another test slipping another unsupported
instruction by.
0x020012b8 : bne,pn %icc, 0x200138c
Is this UltraSPARC and not V7? Do we need two bad instructions
in the test case?
Executing on host: /home/joel/work-gnat/svn/b-gcc1-sparc/gcc/xgcc
Joseph S. Myers wrote:
On Thu, 13 Mar 2008, Joel Sherrill wrote:
Also, if you use a multilib option in testing, that option goes on the
command line *after* the options specified in dg-options. The tests may
need to use dg-skip-if to skip them if any CPU option other than the one
in the
gi?id=35576
-joel
Arnaud Charlet wrote:
Still no answer after two PING (December and February, for patches
submitted in November, and there are others not mentionned here). Is
there any Ada front-end maintainer handling patches proposals?
Yes, as can be seen by other discussions on other pa
=
Any suggestions on what to investigate for those before
I return to whittling on the C/C++ test results again.
--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED]On-Line Applications Research
Ask me about RTEMS: a free RTOS Hunts
Laurent GUERBY wrote:
On Fri, 2008-04-04 at 15:07 -0500, Joel Sherrill wrote:
Beyond those, I am left with:
All targets had the following three failures:
c64005c - "WRONG ITERATIVE TRACE LENGTH."
c64005d - "WRONG ITERATI
Laurent GUERBY wrote:
On Fri, 2008-04-04 at 15:07 -0500, Joel Sherrill wrote:
Beyond those, I am left with:
All targets had the following three failures:
c64005c - "WRONG ITERATIVE TRACE LENGTH."
c64005d - "WRONG ITERATI
Hi,
I was trying to update and test since there was
another flurry of Ada commits. Compiling for
sparc-rtems which has previously had good test
results, I got this:
/home/joel/work-gnat/svn/b-gcc2-sparc/./gcc/xgcc
-B/home/joel/work-gnat/svn/b-gcc2-sparc/./gcc/ -nostdinc
-B/home/joel/work
build stage
I always build a native of the trunk, followed by crosses
built using that native.
--
Eric Botcazou
--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED]On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL
as well.
gnatmake -c -I/usr/lib/gcc/i386-redhat-linux/4.1.2/adalib/../adainclude
-I/usr/lib/gcc/i386-redhat-linux/4.1.2/adalib/ -I.
-I/home/joel/work-gnat/svn/gcc/gcc/ada gnatmake --GCC="gcc -g -O2 -W
-Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-fno-common -g
RTEMS related. Remember .. I am
using a native compiler built from the trunk as well.
gnatmake -c -I/usr/lib/gcc/i386-redhat-linux/4.1.2/adalib/../adainclude
-I/usr/lib/gcc/i386-redhat-linux/4.1.2/adalib/ -I.
-I/home/joel/work-gnat/svn/gcc/gcc/ada gnatmake --GCC="gcc -g -O2 -W
-Wall -Wwri
Eric Botcazou wrote:
gnatmake -c -I/usr/lib/gcc/i386-redhat-linux/4.1.2/adalib/../adainclude
-I/usr/lib/gcc/i386-redhat-linux/4.1.2/adalib/ -I.
-I/home/joel/work-gnat/svn/gcc/gcc/ada gnatmake --GCC="gcc -g -O2 -W
-Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-fno-c
lt
cdd2a02 -
raised CONSTRAINT_ERROR : fdd2a00.adb:40 range check failed
So for sparc-rtems, there are a few regression from earlier in
the month.
--
Eric Botcazou
--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED]On-Line Applications Resear
se in before the slush sets in.
Thanks,
Richard.
--
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,
I am returning to this issue and it is more
pressing testing powerpc on 4.3.0 and the trunk.
powerpc-rtems has gone from a relatively small
percentage of failures to >8300 and this warning
shows up a lot (5120334 times)!
Warning: /home/joel/work-gnat/svn/b-gcc1-powerpc/rtems_gcc_mai
Janis Johnson wrote:
On Wed, 2008-04-23 at 10:56 -0500, Joel Sherrill wrote:
Hi,
I am returning to this issue and it is more
pressing testing powerpc on 4.3.0 and the trunk.
powerpc-rtems has gone from a relatively small
percentage of failures to >8300 and this warning
shows up a
Janis Johnson wrote:
On Thu, 2008-04-24 at 17:54 -0500, Joel Sherrill wrote:
Not knowing the internal details of the test harness, I
would make an ignorant guess that the command line
should be checked before it is executed. If it has multiple
-mcpu/-march options and they were not all the
sking implementation decisions.
When you talk undefined, the program is questionable
at best. I like the Ada LRM because it tries to be very
clean about this in a way that a programmer can understand
and try to do the right thing.
--
Joel Sherrill, Ph.D. Director of Research & De
ting a CPU model
specific test, you should know what the macro generated is.
#if !defined(__PPC405__)
XXX -- ?? what to do?
#endif
Would this work on the scan tests which look for particular
assembly instructions?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
--
Joel Sher
I
know that gcj only works on ARM EABI from 4.3, and C++ still has
problems with exceptions (try-catch) on EABI, maybe less so in later
versions (?) So, before I set out on the journey, does anyone know of
gnat-reasons or ARM EABI-reasons that would make it wiser to start
with a later version than 4.1?
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
ve an idea of deadlines? Does it have to be fixed by 4.4?
--
Joel
eport it?
Open a PR with the complete test case, and the command line options you
used with 4.0.2 and 4.3.1.
Please cc me on the PR. I would like to track this one and
if you provide a preprocessed test case can quickly
check the size on 3.2.3, 4.1.1, 4.2.4, 4.3.1 and the trunk.
Use
s another piece that could go onto the trunk without
causing harm and minimizes the differences.
Paolo
--joel
files for the network stack
are not available when the tools are built so the file can't be
generated automatically during the Ada build.
I don't think that's a big deal as long as you are aware that
at least one target can't generate the file on the fly.
Arno
--joel
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
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?
.
I am starting a fresh build with the trunk (138517)
starting with native and will verify that it the 138517
native is being used. If that fails, I will revert to 138299 .
I will report as soon as the build(s) finish.
--joel
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
busted, or there is something else
you're not telling us about.
I assume based on your next post that you tried this with
an EABI arm target not a simple arm-elf one?
--joel
Thanks. We are close to branching an RTEMS release.
Sounds like this will be a good thing to switch to
immediately after that.
--joel
Paul Brook wrote:
We chose arm-elf as the starting point years. If we need to
move to arm-eabi as the starting point that is OK. We usually
just chose the
Hi,
I started with a fresh tree this morning
and get this building the native. Is anyone
else seeing this?
/home/joel/work-gnat/svn/b-native/./prev-gcc/xgcc
-B/home/joel/work-gnat/svn/b-native/./prev-gcc/
-B/home/joel/work-gnat/svn//install/i686-pc-linux-gnu/bin/ -c
-DHAVE_CONFIG_H -g -O2
gsocket.h:162:25: error: netinet/tcp.h: No such file or directory
gsocket.h:163:23: error: sys/ioctl.h: No such file or directory
gsocket.h:164:19: error: netdb.h: No such file or directory
In file included from s-oscons-tmplt.c:102:
/home/joel/work-gnat/svn/gcc/newlib/libc/include/termios.h:4:25
cc-testresults.
Thanks for the hint. Hopefully the patch is OK. It isn't big.
FWIW cd2a24e now has a gnat bug box on sparc and powerpc.
I filed it as PR 35298.
For those who care, --sysroot does not work RTEMS because:
(1) Apparently the RTEMS standard binutils RPMs do
not suppo
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
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-torture/execute/20001031-1.c
gcc_tg.o -w
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
making use of volatile storage.
I thought Ralf had managed to reproduce the failure with the reduced
test case
on all targets he had tried. The code is in an RTEMS device driver but
since
it involves volatile, it is possible that this code occur in any OS or
device driver.
--joel
S is built multilib so we
need a conditional to let us know which multilib it is so we can do
the right thing. I imagine newlib depends on them too in many places.
--joel
-eric
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
ng it!!!
Some day, I am going to have to come clean on all this
beer I owe people for fixing bugs. :-D
--joel
But it doesn't change their technical ability and as long
as they are working on gcc in a responsible manner and not causing
strive in the community, that's what matters.
Note that on the steering committee we represent technical areas
NOT the companies we work for at any given time.
--joel
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
On Thu, 19 Jul 2007, tbp wrote:
On 7/19/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
Well, I always used the array variant, but you should be able to do
[snip]
if you need to (why does the array form not work for you?)
Because if you bench in some non trivial program, on x86/x86-64 at
lea
newlib.
Eric duplicated the problem on a PowerPC Mac
using gcc 4.0.1.
We believe this indicates an issue introduced
by gcc optimization.
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?
--joel
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
issue on the PowerPC. Does anyone care? Is it a problem?
Should I file a PR?
--joel
suggestion.
FWIW I ran this code on a V7 SPARC and it
also had the same flaw. Changing the optimization
level did NOT help. This was with gcc 4.2.1.
--joel
401 - 500 of 574 matches
Mail list logo
