[Bug c/36583] New: ICE on 5282/5206 at -O2 [regression]
This is an ICE on valid code with gcc 4.3.1 which does not occur with gcc 4.2.4. m68k-rtems4.9-gcc is 4.3.1. With 4.2.4, I tried to duplicate this with -m5200 since the option set has changed. $ m68k-rtems4.9-gcc -fasm -c -mcpu=5206-O2 j1.c j1.c: In function 'dbGet': j1.c:79: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. $ m68k-rtems4.9-gcc -fasm -c -mcpu=5206-O1 j1.c -- Summary: ICE on 5282/5206 at -O2 [regression] 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.gnu.org/bugzilla/show_bug.cgi?id=36583
[Bug ada/35576] Ada HW Interrupt Task Enhancement
--- 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 eliminate references to VxWorks specific packages and to use the adapter routines instead of VxWorks specific ones. 2008-06-06 Joel Sherrill <[EMAIL PROTECTED]> * Makefile.in: Switch RTEMS and VxWorks to s-interr-hwint.adb. * s-interr-hwint.adb: New file with portable implementation. This is a mechanical change of s-interr-vxworks.adb to use the new OS provided adapter. * s-interr-vxworks.adb: Removed. * s-osinte-rtems.ads, s-osinte-vxworks.adb, s-osinte-vxworks.ads: Add shared hardware interrupt adapter layer. RTEMS binds to OS provided adapter routines so there are no modifications to s-osinte-rtems.adb. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35576
[Bug ada/35576] Ada HW Interrupt Task Enhancement
--- 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 PROTECTED]> * Makefile.in: Switch RTEMS and VxWorks to s-interr-hwint.adb. * s-interr-hwint.adb: New file with portable implementation. This is a mechanical change of s-interr-vxworks.adb to use the new OS provided adapter. * s-interr-vxworks.adb: Removed. * s-osinte-rtems.ads, s-osinte-vxworks.adb, s-osinte-vxworks.ads: Add shared hardware interrupt adapter layer. RTEMS binds to OS provided adapter routines so there are no modifications to s-osinte-rtems.adb. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35576
[Bug ada/35576] Ada HW Interrupt Task Enhancement
--- 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 the queue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35576
[Bug ada/35576] Ada HW Interrupt Task Enhancement
--- 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 RTEMS. 2008-05-28 Joel Sherrill <[EMAIL PROTECTED]> * Makefile.in: Switch RTEMS and VxWorks to s-interr-hwint.adb. * s-interr-hwint.adb: New file with portable implementation. * s-interr-vxworks.adb: Removed. * s-osinte-rtems.ads, s-osinte-vxworks.adb, s-osinte-vxworks.ads: Add shared hardware interrupt adapter layer. RTEMS binds to OS provided adapter routines so there are no modifications to s-osinte-rtems.adb. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35576
[Bug ada/35576] Ada HW Interrupt Task Enhancement
--- 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.adb since the .ads binds directly to OS provided routines. -- joel at gcc dot gnu dot org changed: What|Removed |Added Attachment #15505|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35576
[Bug ada/35576] Ada HW Interrupt Task Enhancement
--- 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
[Bug ada/35576] Ada HW Interrupt Task Enhancement
--- 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. ACATS results reported for mips, i386, powerpc, and sparc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35576
[Bug ada/35576] Ada HW Interrupt Task Enhancement
--- 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] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35576
[Bug ada/35576] Ada HW Interrupt Task Enhancement
--- 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] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35576
[Bug ada/35576] Ada HW Interrupt Task Enhancement
--- 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/ml/gcc-patches/2008-04/msg01581.html to even compile Ada targeting RTEMS on the trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35576
[Bug ada/35284] Branch to 0x0 from Ada run-time
--- Comment #37 from joel at gcc dot gnu dot org 2008-04-04 15:11 --- Forgot we are up to 4.4... it applies to 4.2 and 4.3 branches. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
[Bug ada/35825] Update g-soccon-rtems.ads
--- Comment #1 from joel at gcc dot gnu dot org 2008-04-04 14:57 --- Created an attachment (id=15428) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15428&action=view) Patch to add IP_PKTINFO Add patch -- only applicable to SVN trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35825
[Bug ada/35825] New: Update g-soccon-rtems.ads
Attached will be a patch to update g-soccon-rtems.ads on the trunk to reflect the new constant IP_PKTINFO. 2008-04-04 Joel Sherrill <[EMAIL PROTECTED]> * g-soccon-rtems.ads: Add IP_PKTINFO. -- Summary: Update g-soccon-rtems.ads Product: gcc Version: 4.4.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 target triplet: *-rtems* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35825
[Bug ada/35576] Ada HW Interrupt Task Enhancement
--- Comment #3 from joel at gcc dot gnu dot org 2008-04-04 14:32 --- Patch is still valid against 3 April SVN trunk. Confirmed on SPARC. sparc-rtems4.9-gcc (GCC) 4.4.0 20080403 (experimental) [trunk revision 133868] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35576
[Bug ada/35284] Branch to 0x0 from Ada run-time
--- Comment #36 from joel at gcc dot gnu dot org 2008-04-04 14:30 --- Test results running with osinte.diff have been posted to gcc-testresults for i386, mips, sparc, and powerpc. They look very good. Most failures are cross-target or FPU exceptions now. This needs to be applied to the 4.2 branch as well. 2008-04-04 Joel Sherrill <[EMAIL PROTECTED]> * s-osinte-rtems.ads: Correct type of ss_low_priority field in struct sched_param. Add missing process_shared field to pthread_condattr_t. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
[Bug target/35795] [4.4 Regression] Revision 133787 breaks ia64
--- Comment #11 from joel at gcc dot gnu dot org 2008-04-03 16:19 --- (In reply to comment #10) > Subject: Re: [4.4 Regression] Revision 133787 breaks ia64 > > > I am pretty sure I saw this one targeting sparc-rtems. Building an updated > > tree now to confirm it is the fix. > > > > ../../../../gcc/libstdc++-v3/src/iostream-inst.cc: In member function 'void > > std::basic_iostream >::_ZThn8_NSdD1Ev()': > > ../../../../gcc/libstdc++-v3/src/iostream-inst.cc:51: internal compiler > > error: > > in prepare_function_start, at function.c:3940 > > sparc, alpha, m68k, score and mips contained same problem, so hopefully > it is fixed now. My sparc build is past this point now so I think it is fixed there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35795
[Bug target/35795] [4.4 Regression] Revision 133787 breaks ia64
--- Comment #9 from joel at gcc dot gnu dot org 2008-04-03 13:44 --- I am pretty sure I saw this one targeting sparc-rtems. Building an updated tree now to confirm it is the fix. ../../../../gcc/libstdc++-v3/src/iostream-inst.cc: In member function 'void std::basic_iostream >::_ZThn8_NSdD1Ev()': ../../../../gcc/libstdc++-v3/src/iostream-inst.cc:51: internal compiler error: in prepare_function_start, at function.c:3940 -- joel at gcc dot gnu dot org changed: What|Removed |Added CC| |joel at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35795
[Bug ada/35284] Branch to 0x0 from Ada run-time
--- Comment #32 from joel at gcc dot gnu dot org 2008-04-03 00:14 --- Created an attachment (id=15417) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15417&action=view) Correct structure bindings pthread_condattr_t was missing a field. sched_param had an incorrect type. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
[Bug ada/35284] Branch to 0x0 from Ada run-time
--- Comment #31 from joel at gcc dot gnu dot org 2008-04-03 00:10 --- (In reply to comment #30) > Did you look at what happens in Initialize_TCB to the variable Success ? After waiting and waiting at the hospital today, I had plenty of time to think. My guess was that the saved copy of %ebx on the stack was getting corrupted. About an hour of playing on my laptop, I found the culprit!! The pthread_condattr_t structure in s-opsinte-rtems.ads was one 4 byte integer field too short!!! I also noticed a typo in the pthread_attr_t structure. I have no idea how this worked on powerpc, sparc, and mips so well and only failed on i386. Must just be lucky on the alignment or something and missed stuff on the stack that mattered. Here is the much improved ACATS with this change on i386. Many appear to be floating point issues. The last run I sent to the mailing list had 307 failures. === acats Summary === # of expected passes2286 # of unexpected failures26 # of unsupported tests 3 *** FAILURES: c34014h c52103q c52104k c64005c c64005d c953002 cd1009w cd5011e cxg2002 cxg2003 cxg2004 cxg2006 cxg2007 cxg2010 cxg2011 cxg2012 cxg2013 cxg2014 cxg2015 cxg2016 cxg2017 cxg2018 cxg2019 cxg2020 cxg2021 la14012 I will run overnight and file more test results on the mailing list. Patch will be attached in a minute. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
[Bug ada/35284] Branch to 0x0 from Ada run-time
--- Comment #29 from joel at gcc dot gnu dot org 2008-04-02 15:08 --- I have spent the morning debugging at the assembly level and I am nearly 100% positive %ebx is getting corrupted. It is correct before the call to STPO.Initialize_TCB (T, Success); at s-taskin.adb and 0x0 upon return. There are ~2000 lines in the qemu.log between the two points so I have some reduction. I grep'ed the RTEMS source for references to ebx and I didn't see any which were not in ISR or context switch code. I did a run with no IO or interrupts and got the same result. At this point, I am looking for some subroutine that isn't preserving ebx properly. (In reply to comment #28) > I did not notice that s-taprop for rtems was the posix version > >procedure Initialize_TCB (Self_ID : Task_Id; Succeeded : out Boolean) is > Mutex_Attr : aliased pthread_mutexattr_t; > Result : Interfaces.C.int; > Cond_Attr : aliased pthread_condattr_t; > >begin > ... > > if Result /= 0 then > Succeeded := False; > return; > end if; > ... > if Result = 0 then > Succeeded := True; > else > if not Single_Lock then > Result := pthread_mutex_destroy (Self_ID.Common.LL.L'Access); > pragma Assert (Result = 0); > end if; > > Succeeded := False; > end if; > ... > > So it's now just a matter of finding which posix call in there fails. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
[Bug ada/35284] Branch to 0x0 from Ada run-time
--- Comment #26 from joel at gcc dot gnu dot org 2008-04-01 22:40 --- (In reply to comment #25) > The binder will generate a call to Set_Globals The code is different for the head but the intent is clear. Thanks for the explanation. A diff of the generated b~ file for powerpc and i386 only turned up target path name differences. So no explanation from this file. > Set_Globals > (Main_Priority=> -1, > Time_Slice_Value => -1, > WC_Encoding => 'b', > Locking_Policy => ' ', > Queuing_Policy => ' ', > Task_Dispatching_Policy => ' ', These are the same values for RTEMS. > Restrictions => Restrictions'Address, > Interrupt_States => Interrupt_States'Address, These are too different to tell. > Num_Interrupt_States => 0, > Unreserve_All_Interrupts => 0, > Exception_Tracebacks => 0, > Zero_Cost_Exceptions => 1, > Detect_Blocking => 0); We have: Num_Interrupt_States := 0; Unreserve_All_Interrupts := 0; Zero_Cost_Exceptions := 0; Detect_Blocking := 0; Default_Stack_Size := -1; Leap_Seconds_Support := 0; Which I think is OK. > That should set the following global in s-taskin.adb: > >Main_Priority : Integer; >pragma Import (C, Main_Priority, "__gl_main_priority"); >-- Priority for main task. Note that this is of type Integer, not >-- Priority, because we use the value -1 to indicate the default >-- main priority, and that is of course not in Priority'range. > > Which is checked in System.tasking.initialize > > -- Initialize Environment Task > > if Main_Priority = Unspecified_Priority then > Base_Priority := Default_Priority; > else > Base_Priority := Priority (Main_Priority); > end if; > > Default_Priority is defined in system-rtems.ads : > >Default_Priority : constant Priority := 122; It looks OK. What bothers me is this: #1 0x001007fe in __wrap_pthread_setschedparam (pthread=184614914, policy=0, param=0x177654) at wrap_pthread_setschedparam.c:29 #2 0x0010154b in system.task_primitives.operations.set_priority (t=0x1dbb18, prio=0, loss_of_inheritance=0) at s-taprop.adb:764 #3 0x00104529 in system.tasking.initialize () at s-taskin.adb:188 Notice that the call #2 has priority of 0. That maps to this call from s-tasin.adb:188: STPO.Set_Priority (T, T.Common.Base_Priority); Earlier in Initialize_ATCB, the field was set to 122. I confirmed it in the subprogram. But I can't print the T.Common.Base_Priority from gdb right before the call to Set_Priority. So I don't really know if is it still right. It At this point, I think the global variables are right but somehow the T.Common.Base_Priority is really not getting set in a way that survives the return from Initialize_ATCB or it is overwritten in the few lines of s-taskin.adb that are between or it is dereferenced wrong. Any ideas or hints on peeking at the data in gdb would be appreciated. Otherwise my next step is probably using the qemu assembly log and see what I can figure out from that. Ugly and slow. > so my advice is breakpoint on the if above and see what happens. double check > that you compile using the right system.ads. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
[Bug ada/35284] Branch to 0x0 from Ada run-time
--- Comment #24 from joel at gcc dot gnu dot org 2008-04-01 18:02 --- With Laurent's test program, I have traces of good (powerpc/psim) and bad (qemu) runs. The traced include only entry and exit status info for the following calls are: _CPU_Context_switch pthread_cond_broadcast pthread_cond_destroy pthread_cond_init pthread_cond_signal pthread_cond_timedwait pthread_cond_wait pthread_create pthread_exit pthread_getschedparam pthread_mutex_destroy pthread_mutex_init pthread_mutex_lock pthread_mutex_timedlock pthread_mutex_unlock pthread_setschedparam rtems_stack_checker_is_blown rtems_task_create There are two anomalies in the i386 run: The first call to pthread_setschedparam() returns EINVAL because it is passed a sched_param with priority == 0. This field is 122 on the valid psim run. Backtrace indicates we are still in initialization. I do not know how to tell where the 0 came from before here. #2 0x0010153f in system.task_primitives.operations.set_priority (t=0x1dbb38, prio=0, loss_of_inheritance=0) at s-taprop.adb:764 #3 0x0010451d in system.tasking.initialize () at s-taskin.adb:188 #4 0x00103fc8 in system.tasking.initialization.init_rts () at s-tasini.adb:322 #5 0x0010032b in adainit () Later there is a pthread_mutex_unlock() call which passes in a bad mutex id. This does not occur on the psim run. The bad pthread_setschedparam call is not THAT far into the execution and the traced calls up until this point are the same. ENTER pthread_create EXIT pthread_create (0) ENTER _CPU_Context_switch ENTER pthread_create EXIT pthread_create (0) ENTER pthread_exit ENTER _CPU_Context_switch ENTER pthread_mutex_init EXIT pthread_mutex_init (0) ENTER pthread_cond_init EXIT pthread_cond_init (0) ENTER pthread_mutex_init EXIT pthread_mutex_init (0) ENTER pthread_mutex_lock EXIT pthread_mutex_lock (0) ENTER pthread_mutex_unlock EXIT pthread_mutex_unlock (0) ENTER pthread_setschedparam -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
[Bug ada/35284] Branch to 0x0 from Ada run-time
--- Comment #22 from joel at gcc dot gnu dot org 2008-03-31 20:16 --- (In reply to comment #21) > Best think would be to trace rtems calls on a platform where it works vs on > the > simulator. On a platform where it works, look at the backtrace of the task > creation call and try to find out why it doesn't get called on i386 qemu. > I am back to this. Which pthread calls are of interest? I am starting with pthread create, mutex init, lock and unlock, context switches and a few condition variable calls. What else is of interest? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
[Bug target/35598] ICE: segmentation fault on newlib roundf.c
--- Comment #2 from joel at gcc dot gnu dot org 2008-03-15 13:40 --- I built 5 targets overnight and all failed at the same spot. I don't think this is a target specific bug. I am closing it until I can figure out more of what it it. -- joel at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35598
[Bug target/35598] ICE: segmentation fault on newlib roundf.c
--- Comment #1 from joel at gcc dot gnu dot org 2008-03-15 13:37 --- Created an attachment (id=15329) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15329&action=view) Preprocessed test case Fails for me with all of these compiler combinations: /home/joel/work-gnat/svn/b-gcc1-i386/./gcc/xgcc -B/home/joel/work-gnat/svn/b-gcc1-i386/./gcc/ -c -v jround.c /home/joel/work-gnat/svn/b-gcc1-i386/./gcc/xgcc -B/home/joel/work-gnat/svn/b-gcc1-i386/./gcc/ -O2 -c jround.c /home/joel/work-gnat/svn/b-gcc1-i386/./gcc/xgcc -B/home/joel/work-gnat/svn/b-gcc1-i386/./gcc/ -O2 -mtune=i486 -c jround.c /home/joel/work-gnat/svn/b-gcc1-i386/./gcc/xgcc -B/home/joel/work-gnat/svn/b-gcc1-i386/./gcc/ -O2 -fno-builtin -c jround.c /home/joel/work-gnat/svn/b-gcc1-i386/./gcc/xgcc -B/home/joel/work-gnat/svn/b-gcc1-i386/./gcc/ -O2 -fno-builtin -mtune=i486 -c jround.c exit 0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35598
[Bug target/35598] New: ICE: segmentation fault on newlib roundf.c
Similar error on other files .. just reporting this one
xgcc (GCC) 4.4.0 20080315 (experimental) [trunk revision 133234]
/home/joel/work-gnat/svn/b-gcc1-i386/./gcc/xgcc
-B/home/joel/work-gnat/svn/b-gcc1-i386/./gcc/ -nostdinc
-B/home/joel/work-gnat/svn/b-gcc1-i386/i386-rtems4.9/m486/newlib/ -isystem
/home/joel/work-gnat/svn/b-gcc1-i386/i386-rtems4.9/m486/newlib/targ-include
-isystem /home/joel/work-gnat/svn/gcc/newlib/libc/include
-B/home/joel/work-gnat/svn//install/i386-rtems4.9/bin/
-B/home/joel/work-gnat/svn//install/i386-rtems4.9/lib/ -isystem
/home/joel/work-gnat/svn//install/i386-rtems4.9/include -isystem
/home/joel/work-gnat/svn//install/i386-rtems4.9/sys-include -mtune=i486
-DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\"
-DPACKAGE_VERSION=\"1.16.0\" -DPACKAGE_STRING=\"newlib\ 1.16.0\"
-DPACKAGE_BUGREPORT=\"\" -I. -I../../../../../../gcc/newlib/libm/common -O2
-DMALLOC_PROVIDED -DEXIT_PROVIDED -DMISSING_SYSCALL_NAMES -DSIGNAL_PROVIDED
-DREENTRANT_SYSCALLS_PROVIDED -DHAVE_OPENDIR -DNO_EXEC -DHAVE_FCNTL
-fno-builtin -g -O2-mtune=i486 -c -o lib_a-sf_round.o `test -f
'sf_round.c' || echo '../../../../../../gcc/newlib/libm/common/'`sf_round.c
../../../../../../gcc/newlib/libm/common/sf_round.c: In function 'roundf':
../../../../../../gcc/newlib/libm/common/sf_round.c:20: internal compiler
error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[8]: *** [lib_a-sf_round.o] Error 1
--
Summary: ICE: segmentation fault on newlib roundf.c
Product: gcc
Version: 4.4.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: i386-rtems4.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35598
[Bug ada/35284] Branch to 0x0 from Ada run-time
--- Comment #20 from joel at gcc dot gnu dot org 2008-03-14 21:46 --- I don't want this bug to die from inattention. Returning to my analysis of Laurent's program, the task does not get to run at all before the system is finalized. I suspect this indicates the initialization of the task depends upon something destroyed at finalization time or vice-versa. I don't know though. I am sure by breaking on context switch points that the task has not run even it outer most RTEMS entry point, much less the Ada task wrapper when finalization is hit. This would seem to point to the problem. I would appreciate suggestions on what could be wrong, what to look at, and what to try. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
[Bug ada/35576] Ada HW Interrupt Task Enhancement
--- Comment #2 from joel at gcc dot gnu dot org 2008-03-13 18:47 --- 2007-12-06 Joel Sherrill <[EMAIL PROTECTED]> * Makefile.in: Switch RTEMS and VxWorks to s-interr-hwint.adb. * s-interr-hwint.adb: New file with portable implementation. * s-interr-vxworks.adb: Removed. * s-osinte-rtems.adb, s-osinte-rtems.ads, s-osinte-vxworks.adb, s-osinte-vxworks.ads: Add shared hardware interrupt adapter layer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35576
[Bug ada/35576] Ada HW Interrupt Task Enhancement
--- Comment #1 from joel at gcc dot gnu dot org 2008-03-13 18:47 --- Created an attachment (id=15309) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15309&action=view) Ada HW Interrupt Task Enhancement -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35576
[Bug ada/35576] New: Ada HW Interrupt Task Enhancement
Currently VxWorks is the only target in gcc to support Ada interrupt tasks which are tied to hardware interrupt sources. The code in gcc currently is VxWorks specific. The patch attached generalizes this code by adding an adapter layer consisting of binary semaphores and interrupt management methods. These are generalized names for the routines currently used in the VxWorks code. A diff of the existing s-interr-vxworks.adb and the new s-interr-hwint.adb will show the largely mechanical changes. Both VxWorks and RTEMS targets have been modified to use this code. It has been tested on RTEMS. The code was first posted to gcc-patches in December 2007 against the 4.2 branch and SVN trunk. All comments were addressed and the code was reposted again in early March 2008 to gcc-patches. It received only comments on mistakes in the comments which were inherited directly from the original VxWorks code. I am filing this as a PR in the hopes that this will result in it finally getting merged. -- Summary: Ada HW Interrupt Task Enhancement Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: joel at gcc dot gnu dot org GCC build triplet: *-*-rtems* *-*-vxworks* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35576
[Bug target/35575] New: ICE: in function_arg_slotno, at config/sparc/sparc.c:4696
SVN trunk. Executing on host: /home/joel/work-gnat/svn/b-gcc1-sparc/gcc/xgcc -B/home/joel/work-gnat/svn/b-gcc1-sparc/gcc/ dfprt31495.c gcc_tg.o -DSTACK_SIZE=2048 -fno-show-column -B/home/joel/work-gnat/svn/bsp-install/sparc-rtems4.9/sis/lib/ -specs bsp_specs -qrtems -mcpu=cypress /home/joel/work-gnat/svn/b-gcc1-sparc/rtems_gcc_main.o -Wl,-wrap,exit -Wl,-wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort -lm -o dfprt31495.exe(timeout = 300) dfprt31495.c:2: error: decimal floating point not supported for this target dfprt31495.c:2: error: decimal floating point not supported for this target dfprt31495.c:2: error: decimal floating point not supported for this target dfprt31495.c: In function 'main': dfprt31495.c:3: internal compiler error: in function_arg_slotno, at config/sparc/sparc.c:4696 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. compiler exited with status 1 -- Summary: ICE: in function_arg_slotno, at config/sparc/sparc.c:4696 Product: gcc Version: 4.4.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: sparc-rtems4.9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35575
[Bug rtl-optimization/33642] unrecognizable insn for -frtl-abstract-sequences
--- Comment #12 from joel at gcc dot gnu dot org 2008-03-13 18:01 --- Is this the same bug? sparc-rtems4.9 on SVN trunk: 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.c-torture/compile/pr11832.c -O1 -frtl-abstract-sequences -DSTACK_SIZE=2048 -fno-show-column -S -B/home/joel/work-gnat/svn/bsp-install/sparc-rtems4.9/sis/lib/ -specs bsp_specs -qrtems -mcpu=cypress -o pr11832.s(timeout = 300) /home/joel/work-gnat/svn/gcc/gcc/testsuite/gcc.c-torture/compile/pr11832.c: In function 'foo': /home/joel/work-gnat/svn/gcc/gcc/testsuite/gcc.c-torture/compile/pr11832.c:30: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. compiler exited with status 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33642
[Bug c/35574] New: ICE: pdist-3.c
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.target/sparc/pdist-3.c gcc_tg.o
-mcpu=ultrasparc -mvis -O1 -DSTACK_SIZE=2048 -fno-show-column
-B/home/joel/work-gnat/svn/bsp-install/sparc-rtems4.9/sis/lib/ -specs bsp_specs
-qrtems -mcpu=cypress /home/joel/work-gnat/svn/b-gcc1-sparc/rtems_gcc_main.o
-Wl,-wrap,exit -Wl,-wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort -lm -o
./pdist-3.exe(timeout = 300)
/home/joel/work-gnat/svn/gcc/gcc/testsuite/gcc.target/sparc/pdist-3.c: In
function 'main':
/home/joel/work-gnat/svn/gcc/gcc/testsuite/gcc.target/sparc/pdist-3.c:37:
error: unrecognizable insn:
(insn 55 12 13 2
/home/joel/work-gnat/svn/gcc/gcc/testsuite/gcc.target/sparc/pdist-3.c:33 (set
(reg:V8QI 8 %o0)
(mem/u/c/i:V8QI (symbol_ref/u:SI ("*.LLC0") [flags 0x2]) [0 S8 A64]))
-1 (nil))
/home/joel/work-gnat/svn/gcc/gcc/testsuite/gcc.target/sparc/pdist-3.c:37:
internal compiler error: in extract_insn, at recog.c:1983
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
compiler exited with status 1
output is:
--
Summary: ICE: pdist-3.c
Product: gcc
Version: 4.4.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: sparc-rtems4.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35574
[Bug ada/35284] Branch to 0x0 from Ada run-time
--- Comment #19 from joel at gcc dot gnu dot org 2008-02-25 20:45 --- How early can I look at the task priority? Is it stored in some data structure that I can see with objdump before the program is run? I have yet to see anything in the debugger except 0 getting passed to task create for priority and stack size. They have to come from somewhere. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
[Bug ada/35284] Branch to 0x0 from Ada run-time
--- Comment #18 from joel at gcc dot gnu dot org 2008-02-22 22:35 --- (In reply to comment #17) > If you have it on CFARM let me know where and what command to launch to gdb > your testcase. I have been building and running it on my laptop but there is now enough on CFARM to run it. qemu -M isapc -m 8 -boot a -fda /home/joel/qemu/pc386_fda \ -hda fat:/home/joel/qemu/hd -serial stdio will run the program without a debugger. It pops up an xterm-ish thing and shows a srub menu before the output switches to the serial port which is redirected to stdio. Just copy /home/joel/qemu from gcc12 and change paths as appropriate. Add "-s" on the end of the qemu command line and it has a gdb server. Start qemu and quickly in another window do this: gdb --command g t.exe g has a "target remote" command in it which attaches to the qemu. qemu has some debug trace which is interesting and how I got started. Add "-d in_asm,cpu" and will dump a lot of info on assembly instructions and cpu state into /tmp/qemu.log. For your convenience, there is a pr35284-a/ subdirectory under ~/qemu which is a copy of my current build directory. > What does RTEMS ada_pthread_minimum_stack_size returns in both case (under > gdb)? > 16K. Just like a good one line routine should. :-D I will email you from my gmail account so if you need to ping me this weekend you can. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
[Bug ada/35284] Branch to 0x0 from Ada run-time
--- Comment #16 from joel at gcc dot gnu dot org 2008-02-22 22:01 --- I can add mips/jmr3904 to the list that runs t.adb correctly. So we have this as a summary: sparc/sis, powerpc/psim, mips/jmr3904, arm/edb7312 - t.adb runs OK i386/pc386 fails bfin/exkit533 - GNAT bug bo I doublechecked the RTEMS target specific files used on each configuration from the build log. They are the same. Is there anything specific to the x86 the target entry in the Makefile.in might be missing? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
[Bug ada/35284] Branch to 0x0 from Ada run-time
--- Comment #15 from joel at gcc dot gnu dot org 2008-02-22 21:56 ---
(In reply to comment #14)
> Default values come from ada/s-parame-rtems.adb, for the stack it ends up in
> RTEMS ada_pthread_minimum_stack_size:
>
> package body System.Parameters is
>
>function ada_pthread_minimum_stack_size return Interfaces.C.size_t;
>pragma Import (C, ada_pthread_minimum_stack_size,
> "_ada_pthread_minimum_stack_size");
This is called twice on powerpc and i386 and both appear to be from the
same backtrace. The first is where the rtems_init.c creates the ada_main
thread. The second back traces to here:
#0 _ada_pthread_minimum_stack_size ()
at ../../../../../../../423/rtems/c/src/../../cpukit/libgnat/adasupp.c:24
#1 0x001040a7 in system.tasking.initialize_atcb (self_id=0x1dda08,
task_entry_point=0x1752ce, task_arg=1528516, parent=0x1dda08,
elaborated=0x1752cd, base_priority=0, task_info=2, stack_size=-2147483648,
t=0x1de1f4) at s-taskin.adb:136
#2 0x0010577e in system.tasking.stages.create_task (priority=-1,
size=-2147483648, task_info=2, num_entries=0, master=4, state=0x1752ce,
discriminants=1528516, elaborated=0x1752cd, [EMAIL PROTECTED], task_image=
{P_ARRAY = 0x138948, P_BOUNDS = 0x138954}, created_task=0x0)
at s-tassta.adb:605
#3 0x001005d7 in t () at t.adb:3
>
>
>-- Default_Stack_Size --
>
>
>function Default_Stack_Size return Size_Type is
>begin
> return Size_Type (ada_pthread_minimum_stack_size);
>end Default_Stack_Size;
> ...
>
> In ada/s-tassta.adb above line 333 you should be able to trace where Priority
> and Stack_Size come from, compare between the two targets:
>
> -- Activate all the tasks in the chain. Creation of the thread of
> -- control was deferred until activation. So create it now.
>
> C := Chain_Access.T_ID;
> while C /= null loop
> if C.Common.State /= Terminated then
> pragma Assert (C.Common.State = Unactivated);
>
> P := C.Common.Parent;
> Write_Lock (P);
> Write_Lock (C);
>
> if C.Common.Base_Priority < Get_Priority (Self_ID) then
>Activate_Prio := Get_Priority (Self_ID);
> else
>Activate_Prio := C.Common.Base_Priority;
> end if;
Both powerpc and i386 take the else path.
Breakpoint 1, system.tasking.stages.activate_tasks (chain_access=0x1752c8)
at s-tassta.adb:332
332 if C.Common.Base_Priority < Get_Priority (Self_ID) then
(gdb) n
335Activate_Prio := C.Common.Base_Priority;
(gdb)
338 System.Task_Primitives.Operations.Create_Task
> System.Task_Primitives.Operations.Create_Task
> (C, Task_Wrapper'Address,
>Parameters.Size_Type
> (C.Common.Compiler_Data.Pri_Stack_Info.Size),
>Activate_Prio, Success);
> ...
>
I haven't had much luck dereferencing the C.Common stuff or figuring out where
it is.
FWIW this is pretty easy to debug with qemu, a 1.44 MB floppy file, and the
executable. I double checked and you can even use the native Fedora 8 gdb.
qemu speaks gdb remote protocol.
Sorry for not having more information. I checked and at the end of the
run, each RTEMS thread control block shows an RTEMS native priority of
253 (255 being lowest natively). On the PowerPC the threads have a native
priority of 133 which is in the middle of the 1-254 range. I have no idea
why it is pulling a 0 out of the air. :(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
[Bug ada/35284] Branch to 0x0 from Ada run-time
--- Comment #13 from joel at gcc dot gnu dot org 2008-02-22 20:53 --- Laurent's t.adb works on arm/edb7312. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
[Bug ada/35298] GNAT Bug Box
--- Comment #1 from joel at gcc dot gnu dot org 2008-02-22 20:35 --- Created an attachment (id=15209) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15209&action=view) Source file which triggers error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35298
[Bug ada/35298] New: GNAT Bug Box
I decided to see what other targets did with Laurent's t.adb program (see
PR35284). My first attempt was bfin which died with this error.
bfin-rtems4.9-gcc -c -g
-I/home/joel/work-gnat/svn/bsp-install/bfin-rtems4.9/eZKit533//lib/include/adainclude
-O -gnata -gnatE -gnato -g t.adb
+===GNAT BUG DETECTED==+
| 4.4.0 20080220 (experimental) [trunk revision 132490] (bfin-unknown-rtems4.9)
GCC error:|
| in int_mode_for_mode, at stor-layout.c:258 |
| Error detected around t.adb:2|
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report. |
| Include the exact gcc or gnatmake command that you entered. |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files). |
+==+
Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
t.adb
raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:398
End of compilation
bfin-rtems4.9-gnatmake: "t.adb" compilation error
--
Summary: GNAT Bug Box
Product: gcc
Version: 4.4.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 target triplet: bfin-rtems4.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35298
[Bug ada/35284] Branch to 0x0 from Ada run-time
--- Comment #12 from joel at gcc dot gnu dot org 2008-02-22 16:43 --- I just noticed that the stack size passed to system.task_primitives.operations.create_task is also 0 in the back trace on the i386. It is 32724 on the PowerPC. So two parameters are bad. The 0 just indicates that the pthread code should use the default stack size so it happens to work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
[Bug ada/35284] Branch to 0x0 from Ada run-time
--- Comment #11 from joel at gcc dot gnu dot org 2008-02-22 15:34 ---
Good Morning! By setting a breakpoint on _CPU_Context_switch in RTEMS, I can
see where things went wrong. On both SPARC and PowerPC, we dispatched out of
this backtrace:
(gdb) bt
#0 pthread_setschedparam (thread=184614915, policy=0, param=0x175000)
at ../../cpukit/../../../pc386/lib/include/rtems/score/thread.inl:209
#1 0x0010118f in system.task_primitives.operations.set_priority (t=0x1de1f4,
prio=0, loss_of_inheritance=0) at s-taprop.adb:777
#2 0x0010121d in system.task_primitives.operations.create_task (t=0x1de1f4,
wrapper=1072820, stack_size=0, priority=0) at s-taprop.adb:1016
#3 0x00105a99 in system.tasking.stages.activate_tasks (chain_access=0x1752c8)
at s-tassta.adb:338
#4 0x001005ea in t () at t.adb:2
At this point, the Ada run-time is setting the priority of the POSIX
thread it just created.
On the PowerPC (and I assume SPARC since it works there also), the
contents of the scheduling parameter structure is:
(gdb) p *param
$1 = {sched_priority = 122, ss_low_priority = 7462340, ss_replenish_period = {
tv_sec = 0, tv_nsec = 0}, ss_initial_budget = {tv_sec = 1,
tv_nsec = 32724}}
On the i386, this same structure at the same point in RTEMS has this:
$1 = {sched_priority = 0, ss_low_priority = 2, ss_replenish_period = {
tv_sec = 0, tv_nsec = 0}, ss_initial_budget = {tv_sec = 0, tv_nsec = 0}}
The sched_priority field is NOT a valid priority and RTEMS returns EINVAL.
There is a pragma assert after this call in the Ada
system.task_primitives.operations.set_priority so I assume assertions
are disabled. FWIW sys/sched.h is the same file with no CPU ifdefs
on all RTEMS targets.
Since this is the first field in the structure, we are not dealing with
an alignment problem. All of the Ada run-time target specific files
for RTEMS are shared across the architectures so I doubt that is a problem.
I noticed that in the good backtrace, I see this:
#0 pthread_setschedparam (thread=184614915, policy=0, param=0x744c30)
at
../../../../../../../423/rtems/c/src/../../cpukit/posix/src/pthreadsetschedparam.c:47
#1 0x1954 in system.task_primitives.operations.set_priority (t=0x5e868,
prio=122, loss_of_inheritance=) at s-taprop.adb:777
#2 0x1a38 in system.task_primitives.operations.create_task (t=0x5e868,
wrapper=32724, stack_size=32768, priority=122) at s-taprop.adb:1016
#3 0x7bb4 in system.tasking.stages.activate_tasks (chain_access=0x744d34)
at s-tassta.adb:338
#4 0x07ec in t () at t.adb:2
In the bad backtrace, I see this:
#0 0x0010118f in system.task_primitives.operations.set_priority (t=0x1de1f4,
prio=0, loss_of_inheritance=0) at s-taprop.adb:777
#1 0x0010121d in system.task_primitives.operations.create_task (t=0x1de1f4,
wrapper=1072820, stack_size=0, priority=0) at s-taprop.adb:1016
#2 0x00105a99 in system.tasking.stages.activate_tasks (chain_access=0x1752c8)
at s-tassta.adb:338
#3 0x001005ea in t () at t.adb:2
Notice that create.task is passed a 0 for priority on the i386 and a 122 on the
good backtrace.
What to look at next? That bad priority value has to come from somewhere.
--
joel at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-02-22 15:34:43
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
[Bug ada/35284] Branch to 0x0 from Ada run-time
--- Comment #5 from joel at gcc dot gnu dot org 2008-02-21 22:53 --- Created an attachment (id=15202) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15202&action=view) generated from Laurent's t.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
[Bug ada/35284] Branch to 0x0 from Ada run-time
--- Comment #4 from joel at gcc dot gnu dot org 2008-02-21 22:52 --- Runs OK on powerpc/psim and sparc/sis built from the same source tree for GCC and RTEMS. Fails like a99006a on i386. Are there only ~300 tests which rely on tasking? I posted this URL: http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00747.html to point out what was failing and passing in case there was a common thread.ju I am attaching the b~t.adb. I don't know enough to comfortably judge whether it is right or not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
[Bug ada/35284] Branch to 0x0 from Ada run-time
--- Comment #2 from joel at gcc dot gnu dot org 2008-02-21 22:11 --- Created an attachment (id=15201) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15201&action=view) numerically sorted symbol table matching qemu.log This is the numerically sorted symbol table matching the attached log. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
[Bug ada/35284] Branch to 0x0 from Ada run-time
--- Comment #1 from joel at gcc dot gnu dot org 2008-02-21 22:10 --- Created an attachment (id=15200) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15200&action=view) QEMU trace up to branch to 0x0 Search for "^0x" and then scroll backwards to see the indirect call in question. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
[Bug ada/35284] New: Branch to 0x0 from Ada run-time
As reported in http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00747.html, I am seeing a few hundred failures for ACATS on i386-rtems4.9. The failure set appears to be about the same for 5.3.4, 4.3-branch, and SVN trunk. I am trying to debug this on the SVN trunk. I have finally captured the failure and hope someone can help me run down what is broken. This report focuses on a99006a. I am running on qemu and by turning on its debugging I have managed find that the Ada run-time does an indirect jump to 0x0. I will attach a symbol table along with the compressed qemu.log. The last few instructions before the jump to 0x0 involve a call to system__soft_links__set_jmpbuf_address_soft so I set a breakpoint there. On the 8th time it hits it, the address passed in is 0x0 and the backtrace is this: Breakpoint 1, system.soft_links.set_jmpbuf_address_soft (addr=(system.address) 0x0) at s-soflin.adb:270 270procedure Set_Jmpbuf_Address_Soft (Addr : Address) is (gdb) bt #0 system.soft_links.set_jmpbuf_address_soft (addr=(system.address) 0x0) at s-soflin.adb:270 #1 0x00117c52 in system.file_io.chain_file (file=0x14ffa0) at s-fileio.adb:166 #2 0x001119d8 in () at a-textio.adb:2272 #3 0x001002ea in adainit () at ../../../../../../../../../423/rtems/c/src/lib/libbsp/i386/pc386/start/start.S:192 #4 0x0010036d in gnat_main () at ../../../../../../../../../423/rtems/c/src/lib/libbsp/i386/pc386/start/start.S:192 #5 0x0010039c in start_gnat_main () at ../../../../../../../../../423/rtems/c/src/lib/libbsp/i386/pc386/start/start.S:192 #6 0x00137107 in _Thread_Handler () at ../../../../../../../423/rtems/c/src/../../cpukit/score/src/threadhandler.c:151 It runs and does some more calls to that same routine but eventually we end up doing the indirect call to 0x0 from the middle of system__tasking__stages__task_wrapper I have checked and memory is initialized to zero on this BSP in case this was an issue and none of the tasks in this test are blowing their stacks. Advice definitely appreciated on this one. -- Summary: Branch to 0x0 from Ada run-time Product: gcc Version: 4.4.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 target triplet: i386-rtems4.9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
[Bug other/35277] New: x86_64 configure option combo yields broken compiler
This might be a dumb user error but since it works on 32-bit Fedora's, I
thought it best to file a PR and let you folks decide.
On Fedora 7 or 8, when you configure like this, the libgcc_s.o files do not
end up in an install directory that gcc can find afterwards. So you end up
getting a link error on the simplest programs.
../../gcc-${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_dir}
I haven't tried every set of options but reducing it to the
following produced a working compiler.
../../gcc-${gcc}/configure \
--enable-languages=c,ada --prefix=${install_dir}
--
Summary: x86_64 configure option combo yields broken compiler
Product: gcc
Version: 4.2.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joel at gcc dot gnu dot org
GCC host triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35277
[Bug target/35072] h8300: ICE unwind-dw2-fde.c:650: error: unrecognizable insn
--- Comment #2 from joel at gcc dot gnu dot org 2008-02-19 19:13 --- Still happens today so almost certainly on 4.3 branch as well. h8300-rtems4.9-gcc (GCC) 4.4.0 20080219 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35072
[Bug target/35071] bad instruction `do_itt eq'
--- Comment #6 from joel at gcc dot gnu dot org 2008-02-14 16:30 --- (In reply to comment #5) > Looks like it should be "do_it eq, t". Each additional "t" or "e" predicates > one more instruction. The mvfeqd has to be predicated and so does the > RETc(eq). > Do you want to commit that? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35071
[Bug target/34930] [4.3 Regression] ICE in instantiate_virtual_regs_in_insn with vector splat load
--- Comment #11 from joel at gcc dot gnu dot org 2008-02-13 21:38 --- This failed on psim for me. AFAIK it doesn't have Altivec. Sorry, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34930
[Bug target/21377] Error detected at a-stmaco.ads:65:4
--- Comment #2 from joel at gcc dot gnu dot org 2008-02-13 19:10 --- Grrr.. need to get over sinus headache. Misread Bugzilla. Nothing happened to this PR. I haven't retried sh for Ada to even know. -- joel at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21377
[Bug target/21377] Error detected at a-stmaco.ads:65:4
--- Comment #1 from joel at gcc dot gnu dot org 2008-02-13 19:06 --- Missed changing state on previous change. Closed. -- joel at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21377
[Bug ada/35143] [4.3 regression] Serious regression on ACATS results since 4.2.3
--- Comment #19 from joel at gcc dot gnu dot org 2008-02-13 19:05 --- Patch applied to SVN trunk as revision 132294. Thanks for approving it Arnaud. -- joel at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35143
[Bug ada/35143] [4.3 regression] Serious regression on ACATS results since 4.2.3
--- Comment #18 from joel at gcc dot gnu dot org 2008-02-13 19:05 --- Subject: Bug 35143 Author: joel Date: Wed Feb 13 19:04:53 2008 New Revision: 132294 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132294 Log: 2008-02-11 Joel Sherrill <[EMAIL PROTECTED]> PR ada/35143 * env.c: Add __rtems__ to if defined. * s-osinte-rtems.adb: Add To_Target_Priority. Fix formatting. * s-osinte-rtems.ads: Add To_Target_Priority prototype and PTHREAD_SCOPE_PROCESS/PTHREAD_SCOPE_SYSTEM constants. Add pragma Convention as required. * gsocket.h: Make compile in and out of RTS. * Makefile.in: Add system-rtems.ads. Build DEC extensions. Use g-soccon-rtems.ads. * g-soccon-rtems.ads, system-rtems.ads: New files. Added: trunk/gcc/ada/g-soccon-rtems.ads trunk/gcc/ada/system-rtems.ads Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/Makefile.in trunk/gcc/ada/env.c trunk/gcc/ada/gsocket.h trunk/gcc/ada/s-osinte-rtems.adb trunk/gcc/ada/s-osinte-rtems.ads -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35143
[Bug c/35180] New: built-in-setjmp.x2
Seems to be the same for most of the other built-in-setjmp tests on this target. Memory exception at fff4 (illegal address) Unexpected trap (0x 9) at address 0x020013D8 data access exception at 0xFFF4 This occurs after the __builtin_longjmp() transfer control back to main(). -- Summary: built-in-setjmp.x2 Product: gcc Version: 4.3.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: sparc-rtems4.9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35180
[Bug target/34930] [4.3 Regression] ICE in instantiate_virtual_regs_in_insn with vector splat load
--- Comment #9 from joel at gcc dot gnu dot org 2008-02-13 13:59 --- Also fails on powerpc-rtems4.9-gcc (GCC) 4.3.0 20080209 (experimental) [trunk revision 132202] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34930
[Bug c/35175] New: ICE: instantiate_virtual_regs_in_insn, at function.c:1564
This could be a dupe. Please add me on and close this one if it is.
powerpc-rtems4.9-gcc (GCC) 4.3.0 20080209 (experimental) [trunk revision
132202]
XFAIL: gcc.dg/vect/vect-63.c scan-tree-dump-times vect "vectorized 1 loops" 1
Executing on host: /home/joel/work-gnat/svn/b-gcc2-powerpc/gcc/xgcc
-B/home/joel/work-gnat/svn/b-gcc2-powerpc/gcc/
/home/joel/work-gnat/svn/gcc/gcc/testsuite/gcc.dg/vect/vect-64.c
-ftree-vectorize -fno-vect-cost-model -maltivec -mcpu=970 -O2
-fdump-tree-vect-details -DSTACK_SIZE=2048 -fno-show-column -S
-B/home/joel/work-gnat/svn/bsp-install/powerpc-rtems4.9/psim/lib/ -specs
bsp_specs -qrtems -mcpu=603e -o vect-64.s(timeout = 300)
/home/joel/work-gnat/svn/gcc/gcc/testsuite/gcc.dg/vect/vect-64.c: In function
'main1':
/home/joel/work-gnat/svn/gcc/gcc/testsuite/gcc.dg/vect/vect-64.c:76: error:
unrecognizable insn:
(insn 105 312 106 5
/home/joel/work-gnat/svn/gcc/gcc/testsuite/gcc.dg/vect/vect-64.c:23 (parallel [
(set (reg:V4SI 215 [ vect_cst_.59 ])
(reg:V4SI 293))
(unspec [
(const_int 0 [0x0])
] 196)
]) -1 (nil))
/home/joel/work-gnat/svn/gcc/gcc/testsuite/gcc.dg/vect/vect-64.c:76: internal
compiler error: in instantiate_virtual_regs_in_insn, at function.c:1564
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
compiler exited with status 1
--
Summary: ICE: instantiate_virtual_regs_in_insn, at
function.c:1564
Product: gcc
Version: 4.3.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: powerpc-rtems4.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35175
[Bug c/35174] New: ICE: segmentation fault bf64-1.c
Executing on host: /home/joel/work-gnat/svn/b-gcc2-powerpc/gcc/xgcc -B/home/joel/work-gnat/svn/b-gcc2-powerpc/gcc/ /home/joel/work-gnat/svn/gcc/gcc/testsuite/gcc.c-torture/execute/bf64-1.c gcc_tg.o -w -O1 -DSTACK_SIZE=2048 -fno-show-column -B/home/joel/work-gnat/svn/bsp-install/powerpc-rtems4.9/psim/lib/ -specs bsp_specs -qrtems -mcpu=603e /home/joel/work-gnat/svn/b-gcc2-powerpc/gcc/rtems_gcc_main.o -Wl,-wrap,exit -Wl,-wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort -lm -o /home/joel/work-gnat/svn/b-gcc2-powerpc/gcc/testsuite/gcc/bf64-1.x1(timeout = 300) /home/joel/work-gnat/svn/gcc/gcc/testsuite/gcc.c-torture/execute/bf64-1.c: In function 'main': /home/joel/work-gnat/svn/gcc/gcc/testsuite/gcc.c-torture/execute/bf64-1.c:40: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. -- Summary: ICE: segmentation fault bf64-1.c Product: gcc Version: 4.3.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: powerpc-rtems4.9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35174
[Bug target/34393] ICE: in extract_insn, at recog.c:1990
--- Comment #4 from joel at gcc dot gnu dot org 2008-02-13 00:20 --- Also fails on powerpc-rtems powerpc-rtems4.9-gcc (GCC) 4.3.0 20080209 (experimental) [trunk revision 132202] -- joel at gcc dot gnu dot org changed: What|Removed |Added CC||joel at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34393
[Bug target/35071] bad instruction `do_itt eq'
--- Comment #4 from joel at gcc dot gnu dot org 2008-02-11 21:40 --- Perhaps Paul could provide some insight. :) $ svn blame ieee754-df.S ieee754-df.S | grep do_itt 120408 pbrook do_itt eq 120408 pbrook do_itt eq -- joel at gcc dot gnu dot org changed: What|Removed |Added CC||pbrook at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35071
[Bug target/35073] illegal opcode movw for mcu avr3
--- Comment #2 from joel at gcc dot gnu dot org 2008-02-11 14:49 --- Sent privately... wanted to log this .. untested at this point. Please excuse me, I could not reply earlier. Use patch for binutils: http://sourceware.org/ml/binutils/2008-01/msg00037.html Anatoly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35073
[Bug ada/34469] Many ACATS failures not in 4.2.2 [regression]
--- Comment #4 from joel at gcc dot gnu dot org 2008-02-11 14:47 --- Better information on more current version in 35143 *** This bug has been marked as a duplicate of 35143 *** -- joel at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34469
[Bug ada/35143] [4.3 regression] Serious regression on ACATS results since 4.2.3
--- Comment #17 from joel at gcc dot gnu dot org 2008-02-11 14:47 --- *** Bug 34469 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35143
[Bug ada/35143] [4.3 regression] Serious regression on ACATS results since 4.2.3
--- Comment #16 from joel at gcc dot gnu dot org 2008-02-11 14:43 --- ACATS Results for various combinations. SPARC and PowerPC are the primary ones we have tested on for years. This was actually the first full set of automated runs on i386 using qemu. Suggestions on the high number of failures relative to the other SPARC and PowerPC is appreciated. SVN sparc-rtems4.9 - http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00732.html SVN powerpc-rtems4.9 - http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00733.html SVN i386-rtems4.9 - http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00730.html 4.2.3 powerpc-rtems4.9 - http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00731.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35143
[Bug ada/35143] [4.3 regression] Serious regression on ACATS results since 4.2.3
--- Comment #15 from joel at gcc dot gnu dot org 2008-02-11 14:25 --- ChangeLog entry for gcc-svn-ada-20080211.diff. 2008-02-11 Joel Sherrill <[EMAIL PROTECTED]> PR ada/35143 * env.c: Add __rtems__ to if defined. * s-osinte-rtems.adb: Add To_Target_Priority. Fix formatting. * s-osinte-rtems.ads: Add To_Target_Priority prototype and PTHREAD_SCOPE_PROCESS/PTHREAD_SCOPE_SYSTEM constants. Add pragma Convention as required. * gsocket.h: Make compile in and out of RTS. * Makefile.in: Add system-rtems.ads. Build DEC extensions. Use g-soccon-rtems.ads. * g-soccon-rtems.ads, system-rtems.ads: New files. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35143
[Bug ada/35143] [4.3 regression] Serious regression on ACATS results since 4.2.3
--- Comment #14 from joel at gcc dot gnu dot org 2008-02-11 14:24 --- Created an attachment (id=15130) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15130&action=view) SVN RTEMS Patch This patch greatly improves the results of the ACATS for SVN on PowerPC and SPARC. Please apply. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35143
[Bug ada/35143] [4.3 regression] Serious regression on ACATS results since 4.2.3
--- Comment #11 from joel at gcc dot gnu dot org 2008-02-10 01:01 --- Just wanted to update that I went back to a virgin tree and decided to do the bare minimum to get the trunk compiling again. I found remnants of a suggested EH change Arnaud had made to me and removed it. I just finished a PowerPC run with this result for powerpc-rtems4.9: === acats Summary === # of expected passes2310 # of unexpected failures2 # of unsupported tests 3 *** FAILURES: c953002 c974013 YEAH! I will do a sparc-rtems run and after that I will clean up and add a patch to this PR. Please do not close it until I do that and it is reviewed and applied. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35143
[Bug ada/35143] Serious regression on ACATS results since 4.2.3
--- Comment #8 from joel at gcc dot gnu dot org 2008-02-09 19:02 --- Exception Test 2 on powerpc with same svn == raised CONSTRAINT_ERROR : exceptiontest2.adb:7 explicit raise Exception Test 3 on powerpc with same svn = raised CONSTRAINT_ERROR : exceptiontest3.adb:7 explicit raise I hope this helps. Monday I will try to submit a patch with the "required" parts of my patch from the "improvements" part. I realized this morning that parts of it are needed for gcc itself to build. Those re worthy of being merged before the 4.3 branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35143
[Bug ada/35143] Serious regression on ACATS results since 4.2.3
--- Comment #5 from joel at gcc dot gnu dot org 2008-02-08 23:19 --- Created an attachment (id=15123) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15123&action=view) Laurent Guerby's exception test With SVN, the output is Raising Constraint_Error raised CONSTRAINT_ERROR : exception_test.adb:11 explicit raise With 4.2.3, the output is: Raising Constraint_Error Caught Constraint_Error -- inner Same RTEMS library binary in both cases. So any tool version issues with that code is NOT a factor. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35143
[Bug ada/35143] Serious regression on ACATS results since 4.2.3
--- Comment #3 from joel at gcc dot gnu dot org 2008-02-08 23:06 --- Created an attachment (id=15122) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15122&action=view) Same patch but against 4.2.3 Just as a sanity measure. This is the same patch but against 4.2.3. 4.2.3 works great on the ACATS. SVN has lots of problems unrelated to RTEMS specifically. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35143
[Bug ada/35143] Serious regression on ACATS results since 4.2.3
--- Comment #2 from joel at gcc dot gnu dot org 2008-02-08 23:04 --- Created an attachment (id=15121) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15121&action=view) RTEM SVN Trunk Ada Patch Unfortunately, I have an outstanding patch that did not get reviewed in time for inclusion in 4.3. It has been posted in multiple forms but this is the latest. A similar patch is used against 4.2.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35143
[Bug ada/35143] Serious regression on ACATS results since 4.2.3
--- Comment #1 from joel at gcc dot gnu dot org 2008-02-08 23:01 --- Created an attachment (id=15120) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15120&action=view) ACATS Log for powerpc-rtems4.9 SVN trunk rev 132186 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35143
[Bug ada/35143] New: Serious regression on ACATS results since 4.2.3
4.2.3: PASSED: 2309 FAILED3 Trunk: PASSED: 1623 FAILED 689 4.2.3 only failed c380004, c761007, and c953002. I am posting the full log for the SVN trunk as an attachment. Hopefully someone can spot a pattern and we can start to file appropriate PRs. This is a big regression. -- Summary: Serious regression on ACATS results since 4.2.3 Product: gcc Version: 4.3.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 target triplet: powerpc-rtems4.9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35143
[Bug middle-end/34400] [4.3 regression] bad interaction between DF and SJLJ exceptions
--- Comment #60 from joel at gcc dot gnu dot org 2008-01-23 15:12 --- I did a build of powerpc-rtems4.9 on the trunk and it built much more quickly. I haven't had a chance to run the ACATS yet to check run-time behavior. Thanks for all the effort for this one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34400
[Bug ada/34469] Many ACATS failures not in 4.2.2 [regression]
--- 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 "catch 1" if it worked correctly. It printed: raised CONSTRAINT_ERROR : p.adb:5 explicit raise -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34469
[Bug ada/34469] Many ACATS failures not in 4.2.2 [regression]
--- 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/bugzilla/show_bug.cgi?id=34469
[Bug ada/34469] New: Many ACATS failures not in 4.2.2 [regression]
ACATS results on the trunk for powerpc-rtems are much worse than they were for 4.2.2. There were only 3 failures for 4.2.2. I get a lot of failures which appear to be constraint or exception related. Here are a few that failed. The full acats.log will be included as an attachment. ,.,. C34003C ACATS 2.5 88-01-01 00:00:00 C34003C CHECK THAT ALL VALUES OF THE PARENT (BASE) TYPE ARE PRESENT FOR THE DERIVED (BASE) TYPE WHEN THE DERIVED TYPE DEFINITION IS CONSTRAINED. ALSO CHECK THAT ANY CONSTRAINT IMPOSED ON THE PARENT SUBTYPE IS ALSO IMPOSED ON THE DERIVED SUBTYPE. CHECK FOR DERIVED FLOATING POINT TYPES. raised CONSTRAINT_ERROR : c34003c.adb:104 range check failed ,.,. CXG2013 ACATS 2.5 88-01-01 00:00:00 CXG2013 Check the accuracy of the TAN and COT functions. raised ADA.NUMERICS.ARGUMENT_ERROR : a-ngelfu.adb:969 instantiated at cxg2013.adb:100 instantiated at cxg2013.adb:337 ,.,. CXF3A03 ACATS 2.5 88-01-01 00:00:00 CXF3A03 Check that function Length returns the number of characters in the edited output string produced by function Image, for a particular decimal type, currency string, and radix mark. Check that function Valid returns correct results based on the particular decimal value, and the Picture and Currency string parameters. raised ADA.IO_EXCEPTIONS.LAYOUT_ERROR : a-teioed.adb:300 ,.,. CXF2001 ACATS 2.5 88-01-01 00:00:00 CXF2001 Check that the Divide procedure provides correct results. Check that the Remainder is calculated exactly. raised CONSTRAINT_ERROR : a-decima.adb:59 divide by zero -- Summary: Many ACATS failures not in 4.2.2 [regression] 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://gcc.gnu.org/bugzilla/show_bug.cgi?id=34469
[Bug middle-end/34400] [4.3 regression] bad interaction between DF and SJLJ exceptions
--- 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 in doing SJLJ analysis? I do not have the proposed patch applied. I only mentioned this because in addition to the performance issue, there may also be a correctness issue. If you think it is unrelated, I will file a separate PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34400
[Bug middle-end/34400] [4.3 regression] bad interaction between DF and SJLJ exceptions
--- 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 or not. ,.,. C34003C ACATS 2.5 88-01-01 00:00:00 C34003C CHECK THAT ALL VALUES OF THE PARENT (BASE) TYPE ARE PRESENT FOR THE DERIVED (BASE) TYPE WHEN THE DERIVED TYPE DEFINITION IS CONSTRAINED. ALSO CHECK THAT ANY CONSTRAINT IMPOSED ON THE PARENT SUBTYPE IS ALSO IMPOSED ON THE DERIVED SUBTYPE. CHECK FOR DERIVED FLOATING POINT TYPES. raised CONSTRAINT_ERROR : c34003c.adb:104 range check failed ,.,. CXG2013 ACATS 2.5 88-01-01 00:00:00 CXG2013 Check the accuracy of the TAN and COT functions. raised ADA.NUMERICS.ARGUMENT_ERROR : a-ngelfu.adb:969 instantiated at cxg2013.adb:100 instantiated at cxg2013.adb:337 ,.,. CXF3A03 ACATS 2.5 88-01-01 00:00:00 CXF3A03 Check that function Length returns the number of characters in the edited output string produced by function Image, for a particular decimal type, currency string, and radix mark. Check that function Valid returns correct results based on the particular decimal value, and the Picture and Currency string parameters. raised ADA.IO_EXCEPTIONS.LAYOUT_ERROR : a-teioed.adb:300 ,.,. CXF2001 ACATS 2.5 88-01-01 00:00:00 CXF2001 Check that the Divide procedure provides correct results. Check that the Remainder is calculated exactly. raised CONSTRAINT_ERROR : a-decima.adb:59 divide by zero -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34400
[Bug target/34436] Illegal assembly on ARM/Thumb
--- 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 adding the test cases when I spotted the real problem. I am sorry. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34436
[Bug target/34439] ICE in reload_cse_simplify_operands for Coldfire
--- 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 (reg/f:SI 14 %a6)
(reg:SI 0 %d0)) [0 iftmp.9+0 S4 A16])
(mem/s/f/j:SI (plus:SI (reg:SI 8 %a0 [orig:52 D.6686 ] [52])
(const_int 72 [0x48])) [0 .error_log+0 S4 A16])) 26
{*movsi_cf} (nil)
(nil))
j.c:7557: internal compiler error: in final_scan_insn, at final.c:2410
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34439
[Bug target/34439] ICE in reload_cse_simplify_operands for Coldfire
--- 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 (mem/c:SI (plus:SI (reg/f:SI 14 %a6)
(reg:SI 0 %d0)) [0 iftmp.9+0 S4 A16])
(mem/s/f/j:SI (plus:SI (reg:SI 8 %a0 [orig:52 D.6913 ] [52])
(const_int 72 [0x48])) [0 .error_log+0 S4 A16])) 34
{*movsi_cf} (nil)
(nil))
j.c:7557: internal compiler error: in final_scan_insn, at final.c:2382
Please submit a full bug report,
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34439
[Bug target/34439] ICE in reload_cse_simplify_operands for Coldfire
--- 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 for RTEMS compiled to 5282. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34439
[Bug c/34439] New: ICE in reload_cse_simplify_operands for Coldfire
m68k-rtems4.9-gcc -m528x -c j.c
gcc 4.2.2
../../../../../../current/c/src/../../cpukit/shttpd/log.c:139: error: insn does
not satisfy its constraints:
(insn 74 158 159 10
../../../../../../current/c/src/../../cpukit/shttpd/log.c:117 (set (mem/c:SI
(plus:SI (reg/f:SI 14 %a6)
(reg:SI 1 %d1)) [57 D.6834+0 S4 A16])
(mem/s:SI (plus:SI (reg/v/f:SI 10 %a2 [orig:48 c ] [48])
(const_int 220 [0xdc])) [3 .loc.io.total+0 S4 A16]))
34 {*movsi_cf} (nil)
(nil))
../../../../../../current/c/src/../../cpukit/shttpd/log.c:139: internal
compiler error: in reload_cse_simplify_operands, at postreload.c:392
--
Summary: ICE in reload_cse_simplify_operands for Coldfire
Product: 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: m68k-unknown-rtems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34439
[Bug target/34436] Illegal assembly on ARM/Thumb
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34436
[Bug target/34436] Illegal assembly on ARM/Thumb
--- 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 illegal assembly messages from gas. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34436
[Bug c/34436] New: Illegal assembly on ARM/Thumb
Appears to be invalid code produced when -mthumb selected.
Happens with gcc 4.1.1 and 4.2.2 when compiling with:
arm-rtems4.9-gcc -mcpu=arm7tdmi -mthumb -O2 -c /tmp/test1.c
/tmp/cccISkv7.s: Assembler messages:
/tmp/cccISkv7.s:205: Error: unshifted register required -- `eor
r2,r3,r3,ROR#16'
/tmp/cccISkv7.s:206: Error: unshifted register required -- `bic
r2,r2,#0xff'
/tmp/cccISkv7.s:208: Error: unshifted register required -- `eor r3,r3,r2,LSR#8'
/tmp/cccISkv7.s:217: Error: unshifted register required -- `eor
r3,r2,r2,ROR#16'
/tmp/cccISkv7.s:218: Error: unshifted register required -- `bic
r3,r3,#0xff'
/tmp/cccISkv7.s:220: Error: unshifted register required -- `eor r2,r2,r3,LSR#8'
/tmp/cccISkv7.s:236: Error: unshifted register required -- `eor r2,r3,r3,ROR#16
.
Assembler was invoked as
/opt/rtems-4.9/lib/gcc/arm-rtems4.9/4.2.2/../../../../arm-rtems4.9/bin/as -mcpu
=arm7tdmi -mfpu=softfpa -o test1.o /tmp/cc7F7jPZ.s
When I compile test2.c, it gives errors about duplicate type definitions. That
is the same file with cpp comments removed. Strange.
--
Summary: Illegal assembly on ARM/Thumb
Product: 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
[Bug middle-end/34400] [4.3 regression] bad interaction between DF and SJLJ exceptions
--- 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 |Added CC||joel at gcc dot gnu dot org, ||joel dot sherrill at oarcorp ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34400
[Bug middle-end/33803] ICE during build of DES
--- Comment #2 from joel at gcc dot gnu dot org 2007-10-17 21:12 --- I have tried this code with the following gcc versions: WORKS 3.2.3: -O2 FAILS 4.1.1: -O2 FAILS 4.2.1: -O2 FAILS 4.2.2: -O2 WORKS 4.2.1: -O0 WORKS 4.2.2: -O0 WORKS 4.1.1: -O0 This is a regression from the 3.x compiler and an optimization bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33803
[Bug c/33803] ICE during build of DES
--- Comment #1 from joel at gcc dot gnu dot org 2007-10-17 21:07 --- Created an attachment (id=14367) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14367&action=view) preprocessed code to generate problem This is the preprocessed version of the file used to generate the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33803
[Bug c/33803] New: ICE during build of DES
Multiple versions of gcc give an ICE when compiling the attached preprocessed
version of the FreeBSD des.c. The following is produced by gcc 4.2.2
$ h8300-rtems4.9-gcc -O2 -c des1.c
des1.c: In function 'des_init':
des1.c:4246: internal compiler error: in tree_low_cst, at tree.c:4554
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
--
Summary: ICE during build of DES
Product: 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: h8300*-*-rtems*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33803
[Bug c/32326] New: ICE when -g specified
This may be a duplicate of PR 28868
a.c
=
typedef struct a1 {
int x;
} a1_t __attribute__((may_alias));
=
a.c:3: internal compiler error: in splice_child_die, at dwarf2out.c:5503
Please submit a full bug report,
with preprocessed source if appropriate.
See http://bugzilla.redhat.com/bugzilla> for instructions.
Preprocessed source stored into /tmp/ccI0138Q.out file, please attach this to
your bugreport.
It does not occur targeting
tic4x-rtems with gcc 3.4.6
avr-rtems with gcc 4.0.3
mingw with gcc 4.1.2
i386-rtems with gcc 4.1.2
i386-rtems with gcc 4.2.0
It occurs with many gcc versions and targets:
gcc 4.1.1 Fedora Core 6 - i686-pc-linux-gnu
gcc 4.1.1 RTEMS - arm, h8300, i386, m68k, mips, powerpc, sh, sparc
gcc 4.1.2 RTEMS - arm, bfin, h8300, m68k, mips, powerpc, sh, sparc
gcc 4.2.0 RTEMS - arm, bfin, h8300, m68k, mips, powerpc, sh, sparc
--
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 build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: cross target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32326
[Bug target/32307] ICE building simple httpd log.c for -m5282x option
--- 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 bug and now have this one which has if 0's around the offensive code. It appears to have offensive sections. + an inline conditional + two calls to my_snprintf. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32307
[Bug target/32307] ICE building simple httpd log.c for -m5282x option
--- 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 Known to fail||3.2.3 4.1.1 4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32307
[Bug c/32307] ICE building simple httpd log.c for -m5282x option
--- 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 -m528x -c log_preprocessed.c I believe this should occur on any m68k target. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32307
[Bug c/32307] New: ICE building simple httpd log.c for -m5282x option
The full command line is below. It appears to be triggered by -m528x and is
indepdendent of selected optimization level.
m68k-rtems4.8-gcc --pipe -DHAVE_CONFIG_H -I..
-I../../cpukit/../../../uC5282/lib/include -DHAVE_MD5 -Wall -fasm -m528x -O2
-g -MT libshttpd_a-log.o -MD -MP -MF .deps/libshttpd_a-log.Tpo -c -o
libshttpd_a-log.o `test -f 'log.c' || echo
'../../../../../../current/c/src/../../cpukit/shttpd/'`log.c
../../../../../../current/c/src/../../cpukit/shttpd/log.c: In function
'log_access':
../../../../../../current/c/src/../../cpukit/shttpd/log.c:111: error: insn does
not satisfy its constraints:
(insn 74 158 159 10
../../../../../../current/c/src/../../cpukit/shttpd/log.c:90 (set (mem/c:SI
(plus:SI (reg/f:SI 14 %a6)
(reg:SI 1 %d1)) [57 D.6863+0 S4 A16])
(mem/s:SI (plus:SI (reg/v/f:SI 10 %a2 [orig:48 c ] [48])
(const_int 220 [0xdc])) [22 .loc.io.total+0 S4 A16]))
34 {*movsi_cf} (nil)
(nil))
../../../../../../current/c/src/../../cpukit/shttpd/log.c:111: internal
compiler error: in reload_cse_simplify_operands, at postreload.c:393
Please submit a full bug report,
--
Summary: ICE building 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 org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: m68k-rtems4.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32307
[Bug middle-end/25905] [4.2 regression] ICE in expand_compound_operation
--- Comment #8 from joel at gcc dot gnu dot org 2006-01-23 20:42 --- sh-rtems fails to build also. Andrew thought it was related so I am adding myself and this link to my failure post. http://gcc.gnu.org/ml/gcc/2006-01/msg00869.html -- joel at gcc dot gnu dot org changed: What|Removed |Added CC||joel at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25905
[Bug rtl-optimization/25890] [4.2 regression] testsuite failure: gcc.c-torture/compile/20051228-1.c
--- Comment #5 from joel at gcc dot gnu dot org 2006-01-23 20:40 --- sh-rtems fails to build also. Andrew thought it was related so I am adding myself and this link to my failure post. http://gcc.gnu.org/ml/gcc/2006-01/msg00869.html -- joel at gcc dot gnu dot org changed: What|Removed |Added CC||joel at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25890
