[Bug ada/38989] How much stack space should c380004 take?
--- Comment #2 from joel dot sherrill at oarcorp dot com 2009-01-27 20:10 --- Subject: Re: How much stack space should c380004 take? laurent at guerby dot net wrote: --- Comment #1 from laurent at guerby dot net 2009-01-27 19:31 --- This test has arrays of complicated Ada entities so I'm not surprised by stack usage. Could you report at what task size it passes? Passes with the Ada Init task having a stack of 1029K. Fails when it is 1028K. That is over a megabyte of stack. The rest of the ACATS tests run with 100K init task stack and a default Ada task stack size of 20K. [That might be 40K if the run-time doubles the number still.] Either way still WAY less than 1 megabyte. I can increase the stack size for the ACATS RTEMS initialization to get by this. But it would be good to know if there is a lower limit on the target which should be able to pass the ACATS. Can't the test mechanics pass an argument to a single test case? That might be an option -- increase the stack size just for this. What do you think? --joel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38989
[Bug ada/38989] How much stack space should c380004 take?
--- Comment #4 from joel dot sherrill at oarcorp dot com 2009-01-27 20:21 --- Subject: Re: How much stack space should c380004 take? laurent at guerby dot net wrote: --- Comment #3 from laurent at guerby dot net 2009-01-27 20:16 --- in gcc/testsuite/ada/acats/run_all.sh there is already some handling of special tests: case $i in cxb30*) EXTERNAL_OBJECTS=$dir/support/cxb30040.o $dir/support/cxb30060.o $dir/support/cxb30130.o $dir/support/cxb30131.o;; ca1020e) rm -f ca1020e_func1.adb ca1020e_func2.adb ca1020e_proc1.adb ca1020e_proc2.adb /dev/null 21;; ca14028) rm -f ca14028_func2.ads ca14028_func3.ads ca14028_proc1.ads ca14028_proc3.ads /dev/null 21;; cxh1001) extraflags=-a -f; echo pragma Normalize_Scalars; gnat.adc esac the $target can be tested to single out RTEMS. Now I don't know what exactly RTEMS need, an env variable? We have a special script to run the tests based on this one. If you think this is the best solution, I will implement it and we can close this one. FWIW the RTEMS CVS module gcc-testing has all our test scripts, support code, dejagnu configs for simulator BSPs, and scripts to run simulators. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38989
[Bug c/38387] psim miscompiled [regression]
--- Comment #4 from joel dot sherrill at oarcorp dot com 2008-12-03 17:09 --- Subject: Re: psim miscompiled [regression] rguenth at gcc dot gnu dot org wrote: --- Comment #2 from rguenth at gcc dot gnu dot org 2008-12-03 17:04 --- Does it work built with -fno-strict-aliasing? -O1 or -O0? Not to be stupid but how do I compile gcc with those arguments? --joel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38387
[Bug ada/35284] Branch to 0x0 from Ada run-time
--- Comment #35 from joel dot sherrill at oarcorp dot com 2008-04-03 14:30 --- Subject: Re: Branch to 0x0 from Ada run-time laurent at guerby dot net wrote: --- Comment #34 from laurent at guerby dot net 2008-04-03 03:47 --- May be other platform aligned the record 8 byte hence hiding the issue, and x86 only 4 bytes hence showing it. That's got to be it but how so many tests would pass is baffling. This seems like something that should have resulted in more failures. FYI PR35795 kept me from getting test results on the sparc. It was fixed overnight and I want to make sure sparc is OK before submitting test results. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35795 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
[Bug ada/35284] Branch to 0x0 from Ada run-time
--- Comment #7 from joel dot sherrill at oarcorp dot com 2008-02-21 23:55 --- Subject: Re: Branch to 0x0 from Ada run-time laurent at guerby dot net wrote: --- Comment #6 from laurent at guerby dot net 2008-02-21 22:59 --- Could you post the exact backtrace on my testcase? Breakpoint 1, 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x00106079 in system.tasking.stages.task_wrapper (self_id=0x1de234) at s-tassta.adb:1140 #2 0x0012c72f in _Thread_Handler () at ../../../../../../../423/rtems/c/src/../../cpukit/score/src/threadhandler.c:151 #3 0x0071 in ?? () #4 0x037f in ?? () #5 0x in ?? () I don't know if this helps but (gdb) p/x _Thread_Executing-Object.id $1 = 0xb010003 Which indicates this is the third POSIX thread created in this test. (1) RTEMS POSIX_Init (2) main Ada task (3) your task A It purposely doesn't use the complex Text_IO so things should be clearer. Also if you could use gdb to get an understanding of what is done during adainit execution before the failure point. I also disabled clock tick interrupts since this test doesn't appear to have any need for time to be passing. I didn't attach a log yet because I don't think this is in initialization. I think adainit is doing the right thing. I think this is a finalization problem. When I break at system__standard_library__adafinal (aka (Do_Finalize), T has been printed but not the A. When the main thread blocks in Timed_Sleep from something near here: system.tasking.stages.finalize_global_tasks () at s-tassta.adb:796 I traced it through the context switch that happens via Timed_Sleep and I was surprised to see that your Task T has NEVER run. When we context switch to your Task T, we go directly to the RTEMS _Thread_Handler wrapper for all thread entries which calls the Ada thread wrapper entry. So while we are finalizing, it is getting context switched to for the first time. That seems like a solid lead. I will trace further into what is happening in the morning. At this point, it seems like finalizing a thread that hasn't started yet is tripping something funny. If someone gets a good idea before I start again in the morning, just post it. PS: continuing after sleep for me :) I am on my way to register my youngest son for high school for the fall. Wow! You should be sleeping. It is late in Paris. Thanks. --joel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
[Bug ada/35143] [4.3 regression] Serious regression on ACATS results since 4.2.3
--- Comment #13 from joel dot sherrill at oarcorp dot com 2008-02-10 16:16 --- Subject: Re: [4.3 regression] Serious regression on ACATS results since 4.2.3 charlet at adacore dot com wrote: --- Comment #12 from charlet at adacore dot com 2008-02-10 13:12 --- Subject: Re: [4.3 regression] Serious regression on ACATS results since 4.2.3 I found remnants of a suggested EH change Arnaud had made to me and removed it. I do not think it was me. Possibly Laurent Guerby. It was back when the huge slow down in compiling was reported. You suggested changing the exception model and apparently I had part of the patch still in my SVN tree. I wasn't trying to blame you. Sorry if it came out that way. 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. Please close this PR as soon as you confirm that a clean tree builds properly. Note that in any case, this PR is 100% specific to RTEMS since Ada is in relatively good shape wrt exceptions on all the targets where tests are posted. It makes sense that it is specific to RTEMS only given what fixed it. I will post an RTEMS only patch with the PR as soon as I can get runs on another target. I want to make sure no parts of the hardware interrupt modification rework is included so this is OK for 4.3. --joel Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35143 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35143
[Bug target/34436] Illegal assembly on ARM/Thumb
--- Comment #4 from joel dot sherrill at oarcorp dot com 2007-12-11 22:38 --- Subject: Re: Illegal assembly on ARM/Thumb pinskia at gcc dot gnu dot org wrote: --- Comment #3 from pinskia at gcc dot gnu dot org 2007-12-11 22:35 --- asm volatile (EOR %1, %0, %0, ROR #16\n BIC %1, %1, #0xff\n MOV %0, %0, ROR #8\n EOR %0, %0, %1, LSR #8\n : =r (value), =r (tmp) : 0 (value), 1 (tmp)); :) Thank you. I spotted that when I was about to add the second test code. I realized that my sed for cpp lines with # was probably hitting assembly. I closed this about the same time you did. I have shot this back to the RTEMS Arm/Thumb person. They should have caught this and added a Thumb version. Thanks. Sorry for the PR. --joel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34436
