[Bug target/35180] built-in-setjmp.x2
--- Comment #11 from joel at gcc dot gnu dot org 2009-03-23 17:56 --- Closing. This found an issue in the RTEMS ta 3 trap handler. Resolved on the RTEMS side. -- 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=35180
[Bug target/35180] built-in-setjmp.x2
--- Comment #6 from joel at gcc dot gnu dot org 2009-03-18 14:27 --- OK. I decided to look at this in more detail in the simulator. The failing instruction is: 2001358: d0 07 bf fc ld [ %fp + -4 ], %o0 and when I run with a breakpoint there, a dump of the registers shows that fp is 0!! When I try to step, it doesn't happen. If I do a watch $fp, it never goes to 0 and runs correctly. The task has a 256K stack so it isn't blowing it. No interrupts are occurring. No context switches are occurring. Any ideas on how to narrow this down would be appreciated. Normal debugging seems to be failing me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35180
[Bug target/35180] built-in-setjmp.x2
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2009-03-18 16:56 --- OK. I decided to look at this in more detail in the simulator. The failing instruction is: 2001358: d0 07 bf fc ld [ %fp + -4 ], %o0 and when I run with a breakpoint there, a dump of the registers shows that fp is 0!! When I try to step, it doesn't happen. If I do a watch $fp, it never goes to 0 and runs correctly. Looks like the current register window is not flushed before the setjmp. You need to investigate whether traps work correctly on the simulator. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35180
[Bug target/35180] built-in-setjmp.x2
--- Comment #8 from joel at gcc dot gnu dot org 2009-03-18 17:12 --- (In reply to comment #7) OK. I decided to look at this in more detail in the simulator. The failing instruction is: 2001358: d0 07 bf fc ld [ %fp + -4 ], %o0 and when I run with a breakpoint there, a dump of the registers shows that fp is 0!! When I try to step, it doesn't happen. If I do a watch $fp, it never goes to 0 and runs correctly. Looks like the current register window is not flushed before the setjmp. You need to investigate whether traps work correctly on the simulator. I think I see this now. It looks like ta 3 is not flush on RTEMS. I am going to have to talk with some of the SPARC RTEMS folks to make sure and address this one. Leave it open. I am reassigning this to me since it looks RTEMS run-time specific. -- joel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |joel at gcc dot gnu dot org |dot org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35180
[Bug target/35180] built-in-setjmp.x2
--- Comment #9 from joel at gcc dot gnu dot org 2009-03-18 18:18 --- Jiri Gaisler confirms there is no ta 3 handler in RTEMS currently. He will be adding it to RTEMS. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35180
[Bug target/35180] built-in-setjmp.x2
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2009-03-18 18:54 --- Subject: Bug 35180 Author: ebotcazou Date: Wed Mar 18 18:54:31 2009 New Revision: 144942 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144942 Log: PR target/35180 * config/sparc/sparc.md (do_builtin_setjmp_setup): Prettify asm output. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sparc/sparc.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35180
[Bug target/35180] built-in-setjmp.x2
--- Comment #2 from joel at gcc dot gnu dot org 2009-03-17 14:02 --- Yes. See http://gcc.gnu.org/ml/gcc-testresults/2009-03/msg00362.html. We also cross post them to an RTEMS tool list and apparently the run on 12 March resulted in a log that was too large for gcc-testresults. http://www.rtems.org/pipermail/rtems-tooltestresults/2009-March/000232.html Is there anything I can do to help with this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35180
[Bug target/35180] built-in-setjmp.x2
--- Comment #3 from hp at gcc dot gnu dot org 2009-03-17 17:13 --- (In reply to comment #2) Is there anything I can do to help with this? If you could bisect the behaviour to a svn revision range, that might give a clue. See the description of the aforementioned bug (where it's unfortunately also evident that it's not a silver bullet...) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35180
[Bug target/35180] built-in-setjmp.x2
--- Comment #4 from joel at gcc dot gnu dot org 2009-03-17 17:32 --- Going back through the old run logs. Is this how it shows up? FAIL: gcc.c-torture/execute/built-in-setjmp.c execution, -O0 FAIL: gcc.c-torture/execute/built-in-setjmp.c execution, -O1 FAIL: gcc.c-torture/execute/built-in-setjmp.c execution, -O2 FAIL: gcc.c-torture/execute/built-in-setjmp.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/built-in-setjmp.c execution, -O3 -fomit-frame-pointer -funroll-loops FAIL: gcc.c-torture/execute/built-in-setjmp.c execution, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions FAIL: gcc.c-torture/execute/built-in-setjmp.c execution, -O3 -g FAIL: gcc.c-torture/execute/built-in-setjmp.c execution, -Os So far I see those in logs back to May 2008 (revision 135528): http://gcc.gnu.org/ml/gcc-testresults/2008-05/msg01876.html And apparently it failed in 4.3.0: http://gcc.gnu.org/ml/gcc-testresults/2008-05/msg00535.html And 4.2.3 http://gcc.gnu.org/ml/gcc-testresults/2008-04/msg00645.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35180
[Bug target/35180] built-in-setjmp.x2
--- Comment #1 from hp at gcc dot gnu dot org 2009-03-17 04:18 --- Does this still happen? See also PR38609. -- hp at gcc dot gnu dot org changed: What|Removed |Added CC||hp at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35180
