*** [all-target-libada] Error 2
make[1]: *** Waiting for unfinished jobs
--
Summary: libada multilib string parsing error
Product: gcc
Version: 4.3.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joel at gcc dot gnu dot org
GCC target triplet: m68k*-*-rtems*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41122
--- Comment #3 from joel at gcc dot gnu dot org 2009-08-20 13:00 ---
Does AWK need to be set in libada/Makefile.in? Since this works for C/C++, it
must be OK in other places.
In gcc/config/m68k/t-mlibs...
M68K_AWK = $(strip $(shell $(AWK) 'BEGIN { FS="[ \t]*[,()][
--- Comment #4 from joel at gcc dot gnu dot org 2009-08-20 13:57 ---
Will you be applying it to 4.4 and the head?
And a thank you. If we ever manage to meet in person, I owe you a beer, wine
or a nice dessert. Your choice. :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41122
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joel at gcc dot gnu dot org
GCC target triplet: arm-rtems4.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41310
--
Summary: ICE: mem_loc_descriptor, at dwarf2out.c:11616
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedB
--- Comment #1 from joel at gcc dot gnu dot org 2009-09-19 18:58 ---
Created an attachment (id=18609)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18609&action=view)
Preprocessed code to generate bug
dropping -g from the command line fixes it. Full command in next
--- Comment #2 from joel at gcc dot gnu dot org 2009-09-19 18:59 ---
This is the command I used to generate the ICE on the attached test case.
Dropping the -g got rid of the ICE.
/users/joel/test-gcc/b-gcc1-sparc/./gcc/xgcc
-B/users/joel/test-gcc/b-gcc1-sparc/./gcc/
-B/users/joel/test
res (breakpoint
instruction in object)
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joel at gcc dot gnu dot org
GCC targe
--- Comment #1 from joel at gcc dot gnu dot org 2009-09-20 15:20 ---
Should have included command line. This is for arch=r3900.
mips-rtems4.10-gnatmake --RTS=. -fstack-check -v -O -gnatws -O2
-I/users/joel/test-gcc/gcc-svn/gcc/testsuite/ada/acats/work-jmr3904/support
a85013b.adb
--- Comment #3 from joel at gcc dot gnu dot org 2009-09-20 15:56 ---
The debug information is weak since optimization hides a lot. But it looks
like Page_Size might be 0.
(gdb) c
Continuing.
,.,. A85013B ACATS 2.5 88-01-01 00:00:00
A85013B CHECK THAT A SUBPROGRAM CAN BE RENAMED
--- Comment #5 from joel at gcc dot gnu dot org 2009-09-20 16:40 ---
The LynxOS s-osinte-lynxos.ads has this:
function Get_Page_Size return size_t;
function Get_Page_Size return Address;
pragma Import (C, Get_Page_Size, "getpagesize");
-- Returns the size of a
--- Comment #6 from joel at gcc dot gnu dot org 2009-09-20 16:46 ---
Every s-osinte*.ads which has Get_Page_Size includes a comment about 0 being
valid to return and indicate that Page_Size does not matter.
-- Returns the size of a page, or 0 if this is not relevant on this target
--- Comment #9 from joel at gcc dot gnu dot org 2009-09-20 17:12 ---
Thanks for the quick response. I am in the process of adding getpagesize() to
RTEMS. We already had sysconf(_SC_PAGESIZE) and returned 4096. I will change
the s-osinte-rtems.ad* to use that and post a patch when it
--- Comment #10 from joel at gcc dot gnu dot org 2009-09-20 19:40 ---
Created an attachment (id=18619)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18619&action=view)
RTEMS Get_Page_Size should no longer return 0
With this patch only 1 ACATS failed. Is it OK to
--- Comment #4 from joel at gcc dot gnu dot org 2009-09-21 18:45 ---
The patch allowed my build of sparc-rtems4.10 C/C++ to complete.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41411
--- Comment #11 from joel at gcc dot gnu dot org 2009-09-22 13:07 ---
Patch applied to head. GNAT/RTEMS for the mips has 1 failure now and that is a
blown stack. c380004 takes a lot of stack.
Thanks.
--
joel at gcc dot gnu dot org changed:
What|Removed
ormal
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joel at gcc dot gnu dot org
GCC target triplet: m68k-rtems4.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41434
--- Comment #1 from joel at gcc dot gnu dot org 2009-09-22 14:10 ---
Created an attachment (id=18630)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18630&action=view)
qemu debug trace with in_asm,cpu
qemu trace of run. Qemu needs patch posted to their list by Till St
--- Comment #3 from joel at gcc dot gnu dot org 2009-09-22 19:10 ---
Is it time to close this one? It doesn't cause an ICE in 4.4.1.
$ h8300-rtems4.10-gcc --version
h8300-rtems4.10-gcc (GCC) 4.4.1
$ h8300-rtems4.10-gcc -O0 -c des1.c
des1.c:4117: error: size of variable 'des
--- Comment #2 from joel at gcc dot gnu dot org 2009-09-24 01:45 ---
Still fails:
| 4.5.0 20090921 (experimental) [trunk revision 151936] (arm-unknown-rtems4.10)
GCC error:|
| in find_valid_class, at reload.c:702 |
| Error detected around a
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joel at gcc dot gnu dot org
GCC target triplet: sparc-rtems4.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41493
--- Comment #2 from joel at gcc dot gnu dot org 2009-09-29 13:35 ---
Add powerpc-rtems4.10 to the list of targets that fail.
--
joel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from joel at gcc dot gnu dot org 2009-09-30 15:06 ---
(In reply to comment #2)
> Looks like something has clobbered register A6.
>
I reran against the head yesterday. I have an objdump and a qemu trace
with register values between each block of assembly. I don
--- Comment #4 from joel at gcc dot gnu dot org 2009-10-12 17:25 ---
I have tracked the failure down to the %fp being corrupted because the size of
pthread_mutexattr_t has changed in RTEMS and the Ada binding is wrong. I have
no idea why this didn't impact other ports unless the
--- Comment #3 from joel at gcc dot gnu dot org 2009-10-12 18:58 ---
Created an attachment (id=18792)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18792&action=view)
Add type to pthread_mutexattr_t
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41493
--- Comment #4 from joel at gcc dot gnu dot org 2009-10-12 23:33 ---
(From update of attachment 18792)
Patch attached to wrong PR.
--
joel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from joel at gcc dot gnu dot org 2009-10-13 13:11 ---
Still broken:
+===GNAT BUG DETECTED==+
| 4.5.0 20091012 (experimental) [trunk revision 152668] (arm-unknown-rtems4.10)
GCC error:|
| in find_valid_class, at reload.c
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joel at gcc dot gnu dot org
GCC target triplet: sparc64-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41710
--- Comment #1 from joel at gcc dot gnu dot org 2009-10-15 19:24 ---
This was the side-effect of an unmatched qupote in config.gcc in my local tree
from a new target I was adding. It resulted in configargs.h not being
compilable. Strange but fixed now and never in public source
--- Comment #2 from joel at gcc dot gnu dot org 2009-10-15 19:24 ---
CLosing.
--
joel at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
/libgcc/../gcc/libgcc2.c:545 (set (reg:SI 107
[ prephitmp.20 ])
(const_int -16 [0xfffffffffffffff0])) -1 (nil))
../../../gcc-svn/libgcc/../gcc/libgcc2.c:547:1: internal compiler error: in
extract_insn, at recog.c:2091
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
[j...@rtbf64a libgcc]$
--
Summary: ICEin extract_insn, at recog.c:2091
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joel at gcc dot gnu dot org
GCC target triplet: arc-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41747
--- Comment #1 from joel at gcc dot gnu dot org 2009-10-19 01:00 ---
4.4.1 also fails but at recog.c:2048
--
joel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from joel at gcc dot gnu dot org 2009-10-19 01:10 ---
4.3.4 fails at recog.c:2001
--
joel at gcc dot gnu dot org changed:
What|Removed |Added
Known
--- Comment #4 from joel at gcc dot gnu dot org 2009-10-19 21:39 ---
../../gcc-4.1.2/gcc/libgcc2.c:1702: internal compiler error: in extract_insn,
at recog.c:2084
../../gcc-4.2.4/gcc/libgcc2.c:747: internal compiler error: in extract_insn, at
recog.c:2077
--
joel at gcc dot gnu dot
--- Comment #5 from joel at gcc dot gnu dot org 2009-10-19 21:46 ---
../../gcc-3.4.6/gcc/libgcc2.c:1475: internal compiler error: in extract_insn,
at recog.c:2083
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41747
--- Comment #5 from joel at gcc dot gnu dot org 2009-11-10 11:57 ---
(In reply to comment #4)
> Was the patch posted on gcc-patches@ at some point?
>
It has been over a year and I honestly don't know. I will repost on general
principal.
--
http://gcc.gnu.o
uilding simple httpd log.c for -m5282x option
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joel at gcc dot gnu dot o
--- Comment #1 from joel at gcc dot gnu dot org 2007-06-12 15:17 ---
Created an attachment (id=13689)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13689&action=view)
preprocessed code to generate problem
The following should reproduce the error:
m68k-rtems4.8-gcc -m5
--- Comment #2 from joel at gcc dot gnu dot org 2007-06-12 15:21 ---
Tested using RTEMS cross RPMs for RTEMS 4.6 (gcc 3.2.3) and RTEMS 4.7 (gcc
4.1.1).
--
joel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from joel at gcc dot gnu dot org 2007-06-12 15:39 ---
Created an attachment (id=13690)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13690&action=view)
alternate version of bug file which has if 0 around offensive code
I hacked on the file that tripped the
arc
--
Summary: ICE when -g specified
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joel at gcc dot gnu dot org
GCC bu
4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joel at gcc dot gnu dot org
GCC target triplet: lm32-rtems4.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43527
--- Comment #1 from joel at gcc dot gnu dot org 2010-03-25 21:36 ---
Compiles at -O0.
Fails at -O1.
Suggestions on an optimization pass to disable is welcomed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43527
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joel at gcc dot gnu dot org
GCC target triplet: arm-rtems4.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43580
--- Comment #1 from joel at gcc dot gnu dot org 2010-03-29 18:44 ---
Created an attachment (id=20252)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20252&action=view)
Preprocessed libgcc2.c source
Definitely compiles with 4.4.3 not with head
--
http://gcc.gnu.org/b
--- Comment #2 from joel at gcc dot gnu dot org 2010-03-29 18:45 ---
Could someone try this with arm-eabi/elf? That would impact the priority of
this bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43580
4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joel at gcc dot gnu dot org
GCC target triplet: h8300-rtems4.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43584
--- Comment #1 from joel at gcc dot gnu dot org 2010-03-29 18:52 ---
Cross source is
gcc (GCC) 4.5.0 20100328 (experimental) [trunk revision 157785]
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43584
--- Comment #9 from joel at gcc dot gnu dot org 2010-03-30 16:22 ---
Maybe I am misreading the command invoked in Ralf's original report but it is
using xgcc which is the cross gcc:
make[5]: Entering directory
`/users/rtems/src/rpms/BUILD/rtems-4.11-h8300-rtems4.11-gcc-4.5.0/buil
--- Comment #10 from joel at gcc dot gnu dot org 2010-03-30 16:29 ---
I encountered this issue while doing builds to run gcc tests. Newlib is
symlinked into gcc. binutils was built and installed separately. My configure
command is pretty simple.
/users/joel/test-gcc/gcc-svn
--- Comment #12 from joel at gcc dot gnu dot org 2010-03-30 16:58 ---
Created an attachment (id=20260)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20260&action=view)
generated gcc/Makefile
This is the gcc/Makefile generated for my h8300-rtems4.10 build. h8300.o is
supp
--- Comment #11 from joel at gcc dot gnu dot org 2010-03-30 23:05 ---
Patch worked for me targeting arm-rtems4.10 on the same gcc checkout.
Please apply it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43580
--- Comment #14 from joel at gcc dot gnu dot org 2010-04-01 13:49 ---
I am starting the regression hunt. Don't worry about it Ralf.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43531
--- Comment #15 from joel at gcc dot gnu dot org 2010-04-01 21:06 ---
I have it down to this.
152224 - native gcc
152417 - use xgcc
I confused myself and went down the wrong branch of the binary search earlier
so that's how far I got today. But ~200 revisions is better than t
--- Comment #16 from joel at gcc dot gnu dot org 2010-04-01 22:11 ---
Running from home while helping kids with homework. :)
152248 - native gcc
152272 - uses xgcc
So it broken between those two. I will continue whittling.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43531
--- Comment #18 from joel at gcc dot gnu dot org 2010-04-01 22:43 ---
Confirmed.
152248 - native gcc
152249 - uses xgcc
--
joel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from joel at gcc dot gnu dot org 2010-04-06 11:36 ---
Reconfirmed.
+===GNAT BUG DETECTED==+
| 4.5.0 20100402 (experimental) [trunk revision 157942] (arm-unknown-rtems4.10)
GCC error:|
| in find_valid_class, at reload.c
--- Comment #7 from joel at gcc dot gnu dot org 2010-04-06 22:18 ---
I had some logs here and checked. It passes on sparc-rtems4.10
GNATMAKE 4.5.0 20100331 (experimental) [trunk revision 157866]
,.,. C34006G ACATS 2.5 88-01-01 00:00:00
C34006G CHECK THAT THE REQUIRED PREDEFINED
--- Comment #25 from joel at gcc dot gnu dot org 2010-04-07 12:11 ---
Although we may seem paranoid and picky, these can break things in a very weird
and very hard to debug way. I just tripped across another place where
gcc/config is passed as an include directory to the build of a
--- Comment #8 from joel at gcc dot gnu dot org 2010-04-07 21:55 ---
/users/joel/test-gcc/b-gcc2-arm/./gcc/xgcc
-B/users/joel/test-gcc/b-gcc2-arm/./gcc/ -nostdinc
-B/users/joel/test-gcc/b-gcc2-arm/arm-rtems4.10/newlib/ -isystem
/users/joel/test-gcc/b-gcc2-arm/arm-rtems4.10/newlib/targ
igned at gcc dot gnu dot org
ReportedBy: joel at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43687
--- Comment #2 from joel at gcc dot gnu dot org 2010-04-12 12:11 ---
Did you have patches to get past
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43527 or has it just gone away?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43726
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joel at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42368
--- Comment #9 from joel at gcc dot gnu dot org 2010-08-08 20:31 ---
Created an attachment (id=21439)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21439&action=view)
First attempt at fix
Is this what you have in mind? I think it worked since the desired symbols
are
--- Comment #9 from joel at gcc dot gnu dot org 2010-04-29 21:03 ---
Still broken.
| 4.6.0 20100428 (experimental) [trunk revision 158844] (arm-unknown-rtems4.10)
GCC error:|
| in find_valid_class, at reload.c:704 |
| Error detected around a
tus: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joel at gcc dot gnu dot org
GCC target triplet: sparc-rtems4.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44070
--- Comment #10 from joel at gcc dot gnu dot org 2010-05-11 11:50 ---
FWIW also seen on sparc-rtems, powerpc-rtems, and i386-rtems.
This did not happen building mips-rtems.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44063
--- Comment #3 from joel at gcc dot gnu dot org 2010-05-26 00:26 ---
(In reply to comment #2)
> Hi Joel, do you have a .i test case for this? Thanks.
>
It works today. with
$ lm32-rtems4.10-gcc --version
lm32-rtems4.10-gcc (GCC) 4.6.0 20100525 (experimental) [trunk revision
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joel at gcc dot gnu dot org
GCC host triplet: powerpc-rtems4.11
http://gcc.gnu.org/bugzilla
--- Comment #1 from joel at gcc dot gnu dot org 2010-07-02 20:14 ---
Created an attachment (id=21071)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21071&action=view)
bzip'ed test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44793
--- Comment #2 from joel at gcc dot gnu dot org 2010-07-02 20:16 ---
Works with 4.4.4
$ /opt/rtems-4.10/bin/powerpc-rtems4.10-gcc -mcpu=603e -Os pr44793.c -S
$ grep _res pr44793.s
$ /opt/rtems-4.10/bin/powerpc-rtems4.10-gcc --version
powerpc-rtems4.10-gcc (GCC) 4.4.4 20100429 (RTEMS
--- Comment #4 from joel at gcc dot gnu dot org 2010-07-02 20:31 ---
We use newlib and it is not in any of the .a or .o files installed. I
see it in the file crtresgpr.S in gcc/config/rs6000 but only
config/rs6000/t-netbsd references it. Should this code from t-netbsd be copied
to t
--- Comment #12 from joel at gcc dot gnu dot org 2007-12-10 14:22 ---
I've seen this on PowerPC and SPARC now, so I can confirm it is target
independent.
--
joel at gcc dot gnu dot org changed:
What|Removed |
gcc
Version: 4.2.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joel at gcc dot gnu dot org
GCC target triplet: arm-unknown-rtems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34436
--- Comment #1 from joel at gcc dot gnu dot org 2007-12-11 22:32 ---
Created an attachment (id=14733)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14733&action=view)
Test Case #1 produces illegal assembly
When compiled as described in the first post, this file gives
--- Comment #2 from joel at gcc dot gnu dot org 2007-12-11 22:34 ---
Found inline assembly that caused problem. Sorry.
--
joel at gcc dot gnu dot org changed:
What|Removed |Added
: unassigned at gcc dot gnu dot org
ReportedBy: joel at gcc dot gnu dot org
GCC target triplet: m68k-unknown-rtems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34439
--- Comment #1 from joel at gcc dot gnu dot org 2007-12-11 23:20 ---
Created an attachment (id=14734)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14734&action=view)
Preprocessed code that produces error
This is the preprocessed output of the Simple HTTPD server fo
--- Comment #2 from joel at gcc dot gnu dot org 2007-12-11 23:22 ---
Also occurs on 4.2.1 but this time at:
/opt/rtems-4.8/bin/m68k-rtems4.8-gcc -m528x -c j.c
j.c: In function '_shttpd_elog':
j.c:7557: error: insn does not satisfy its constraints:
(insn 13 189 14 (set
--- Comment #3 from joel at gcc dot gnu dot org 2007-12-11 23:22 ---
And again on 4.1.1:
$ /opt/rtems-4.7/bin/m68k-rtems4.7-gcc -m528x -c j.c
j.c: In function '_shttpd_elog':
j.c:7557: error: insn does not satisfy its constraints:
(insn 14 190 15 (set (mem/c:SI (plus:SI (r
--- Comment #6 from joel at gcc dot gnu dot org 2007-12-12 14:05 ---
RTEMS had a default implementation of the method in question that was in C. So
for the Thumb, I changed things to use it until the Thumb maintainer adds a
better version.
Thanks. I wasn't even finished addin
--- Comment #20 from joel at gcc dot gnu dot org 2007-12-14 19:41 ---
I left a build running all night and got ACATS results on the trunk on
powerpc-rtems, I get a lot of failures which appear to be constraint or
exception related. I don't know if these are related o
--- Comment #22 from joel at gcc dot gnu dot org 2007-12-14 20:00 ---
(In reply to comment #21)
> I am confused about comment #20. Are these constraint failures caused by the
> proposed patch? are they independent of the patch? why is this related to the
> performance issues
--- Comment #1 from joel at gcc dot gnu dot org 2007-12-14 21:12 ---
Created an attachment (id=14755)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14755&action=view)
Full ACATS Log for PSIM run
Maybe the full log will help someone.
--
http://gcc.gnu.org/b
]
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joel at gcc dot gnu dot org
GCC target triplet: powerpc-rtems
http
--- Comment #2 from joel at gcc dot gnu dot org 2007-12-14 21:31 ---
Created an attachment (id=14757)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14757&action=view)
Laurent's very simple test case
Laurent offered this program and said it would print "catc
--- Comment #4 from joel at gcc dot gnu dot org 2008-04-21 22:37 ---
Created an attachment (id=15505)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15505&action=view)
Updated to 4.4.0 20080421 (experimental) [trunk revision 134514]
Requires patch in http://gcc.gnu.org
--- Comment #5 from joel at gcc dot gnu dot org 2008-04-21 22:39 ---
Tested against this GCC using gcc-ada-hwint-20080421.diff and patch in
http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01581.html
sparc-rtems4.9-gcc (GCC) 4.4.0 20080421 (experimental) [trunk revision 134514
--- Comment #6 from joel at gcc dot gnu dot org 2008-05-07 18:03 ---
Tested against this GCC using gcc-ada-hwint-20080421.diff and patch in
http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01581.html
sparc-rtems4.9-gcc (GCC) 4.4.0 20080502 (experimental) [trunk revision 134885
--- Comment #7 from joel at gcc dot gnu dot org 2008-05-07 18:08 ---
Created an attachment (id=15612)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15612&action=view)
hwint patch for gcc 4.3 branch
This has been tested against sparc-rtems4.9 for interrupt functionality.
--- Comment #8 from joel at gcc dot gnu dot org 2008-05-20 16:59 ---
Patch against SVN trunk still OK using
20080519 (experimental) [trunk revision 135528]
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35576
--- Comment #9 from joel at gcc dot gnu dot org 2008-05-28 16:29 ---
Created an attachment (id=15692)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15692&action=view)
Latest version
Previous patch did not include s-interr-hwint.adb.
There is no patch to s-osinte-rtems.ad
--- Comment #10 from joel at gcc dot gnu dot org 2008-05-28 16:33 ---
Updated changelog entry. I missed adding the s-hwint-interr.adb file
when I replaced my svn tree a while back. There are no modifications
to s-osinte-rtems.adb. The .ads just binds to more routines provided
by
--- Comment #11 from joel at gcc dot gnu dot org 2008-06-05 23:32 ---
Created an attachment (id=15723)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15723&action=view)
updated patch
Updated to account for changes to s-osinte-vxworks.adb while this PR has
lingered in th
--- Comment #12 from joel at gcc dot gnu dot org 2008-06-05 23:34 ---
s-osinte-vxworks.adb is not removed by the patch. For review purposes, you
should diff s-osinte-vxworks.adb to s-osinte-hwint.adb to see what the changes
were.
2008-05-28 Joel Sherrill <[EMAIL PROTEC
--- Comment #14 from joel at gcc dot gnu dot org 2008-06-06 13:16 ---
ChangeLog entry for gcc-svn-ada-hwint-20080606.diff. Patch does not
remove s-interr-vxworks.adb. As part of review please
"diff -u s-interr-vxworks.adb s-interr-hwint.adb" You should only
see changes to
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joel at gcc dot gnu dot org
GCC target triplet: m68k-rtems4.9
http://gcc.
--- Comment #1 from joel at gcc dot gnu dot org 2008-06-20 16:20 ---
Created an attachment (id=15795)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15795&action=view)
Cut down test case
This is a stripped down version of the code that tripped the bug.
--
http://gcc.
--- Comment #38 from joel at gcc dot gnu dot org 2008-07-15 19:33 ---
Created an attachment (id=15914)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15914&action=view)
Zoltan's test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31849
--- Comment #39 from joel at gcc dot gnu dot org 2008-07-15 19:36 ---
I compiled Zoltan's example test.c for the various arm-rtems gcc versions I had
laying around. The GCC version string is modified to reflect the RTEMS
specific patch revision and newlib version used in the binar
201 - 300 of 351 matches
Mail list logo
