With gcc-4.9-20140309 I see the following testsuite regressions on armv5tel-linux-gnueabi compared to the previous working snapshot gcc-4.9-20140223 (the intermediate 4.9-20130302 didn't bootstrap due to PR60411): === acats tests === +FAIL: a87b59a +FAIL: c32111a +FAIL: c32111b +FAIL: c32112b +FAIL: c32113a +FAIL: c32115a +FAIL: c32115b (hundreds more here) +FAIL: cxg2020 +FAIL: cz1102a +FAIL: cz1103a === acats Summary === -# of expected passes 2320 -# of unexpected failures 0 +# of expected passes 1625 +# of unexpected failures 695 and === gnat tests === Running target unix +FAIL: gnat.dg/aliased_prefix_accessibility.adb execution test +FAIL: gnat.dg/conv_bug.adb execution test +FAIL: gnat.dg/curr_task.adb execution test +FAIL: gnat.dg/expect1.adb execution test +FAIL: gnat.dg/handle_and_return.adb execution test +FAIL: gnat.dg/invalid1.adb execution test +FAIL: gnat.dg/iprot_test.adb execution test +FAIL: gnat.dg/missing_acc_check.adb execution test +FAIL: gnat.dg/nested_controlled_alloc.adb execution test +FAIL: gnat.dg/not_null.adb execution test +FAIL: gnat.dg/null_pointer_deref1.adb execution test +FAIL: gnat.dg/null_pointer_deref2.adb execution test +FAIL: gnat.dg/null_pointer_deref3.adb execution test +FAIL: gnat.dg/opt22.adb execution test +FAIL: gnat.dg/overflow_sum.adb execution test +FAIL: gnat.dg/regpat1.adb execution test +FAIL: gnat.dg/stack_check1.adb execution test +FAIL: gnat.dg/stack_check2.adb execution test +FAIL: gnat.dg/tag1.adb execution test +FAIL: gnat.dg/test_enum_io.adb execution test +FAIL: gnat.dg/test_fixed_io.adb execution test +FAIL: gnat.dg/test_image.adb execution test +XPASS: gnat.dg/test_raise_from_pure.adb execution test +FAIL: gnat.dg/timer_cancel.adb execution test === gnat Summary === -# of expected passes 1200 -# of expected failures 19 +# of expected passes 1177 +# of unexpected failures 23 +# of unexpected successes 1 +# of expected failures 18 # of unsupported tests 13 The first one was splitting /mnt/scratch/objdir49/gcc/testsuite/ada/acats/tests/a/a87b59a.ada into: a87b59a.adb BUILD a87b59a.adb gnatmake --GCC="/mnt/scratch/objdir49/gcc/xgcc -B/mnt/scratch/objdir49/gcc/" -gnatws -O2 -gnat95 -I/mnt/scratch/objdir49/gcc/testsuite/ada/acats/support a87b59a.adb -largs --GCC="/mnt/scratch/objdir49/gcc/xgcc -B/mnt/scratch/objdir49/gcc/" /mnt/scratch/objdir49/gcc/xgcc -c -B/mnt/scratch/objdir49/gcc/ -gnatws -O2 -gnat95 -I/mnt/scratch/objdir49/gcc/testsuite/ada/acats/support a87b59a.adb gnatbind -I/mnt/scratch/objdir49/gcc/testsuite/ada/acats/support -x a87b59a.ali gnatlink a87b59a.ali -O2 --GCC=/mnt/scratch/objdir49/gcc/xgcc -B/mnt/scratch/objdir49/gcc/ RUN a87b59a ,.,. A87B59A ACATS 2.5 14-03-10 20:37:01 ---- A87B59A CHECK THAT BECAUSE A GENERIC ACTUAL PROGRAM PARAMETER MUST BE A SUBPROGRAM, AN ENUMERATION LITERAL, OR AN ENTRY WITH THE SAME PARAMETER AND RESULT TYPE PROFILE AS THE FORMAL PARAMETER, AN OVERLOADED NAME APPEARING AS AN ACTUAL PARAMETER CAN BE RESOLVED. Execution terminated by abort of environment task FAIL: a87b59a The last one was Executing on host: /mnt/scratch/objdir49/gcc/gnatmake --GCC=/mnt/scratch/objdir49/gcc/xgcc --GNATBIND=/mnt/scratch/objdir49/gcc/gnatbind --GNATLINK=/mnt/scratch/objdir49/gcc/gnatlink -cargs -B/mnt/scratch/objdir49/gcc -largs --GCC=/mnt/scratch/objdir49/gcc/xgcc\ -B/mnt/scratch/objdir49/gcc\ -margs --RTS=/mnt/scratch/objdir49/armv5tel-unknown-linux-gnueabi/./libada -q -f /mnt/scratch/gcc-4.9-20140309/gcc/testsuite/gnat.dg/timer_cancel.adb -fno-diagnostics-show-caret -fdiagnostics-color=never -lm -o ./timer_cancel.exe (timeout = 300) spawn -ignore SIGHUP /mnt/scratch/objdir49/gcc/gnatmake --GCC=/mnt/scratch/objdir49/gcc/xgcc --GNATBIND=/mnt/scratch/objdir49/gcc/gnatbind --GNATLINK=/mnt/scratch/objdir49/gcc/gnatlink -cargs -B/mnt/scratch/objdir49/gcc -largs --GCC=/mnt/scratch/objdir49/gcc/xgcc -B/mnt/scratch/objdir49/gcc -margs --RTS=/mnt/scratch/objdir49/armv5tel-unknown-linux-gnueabi/./libada -q -f /mnt/scratch/gcc-4.9-20140309/gcc/testsuite/gnat.dg/timer_cancel.adb -fno-diagnostics-show-caret -fdiagnostics-color=never -lm -o ./timer_cancel.exe Executing on host: /mnt/scratch/objdir49/gcc/gnatclean -c -q -n ./timer_cancel (timeout = 300) spawn -ignore SIGHUP /mnt/scratch/objdir49/gcc/gnatclean -c -q -n ./timer_cancel ./timer_cancel.ali ./timer_cancel.o PASS: gnat.dg/timer_cancel.adb (test for excess errors) Setting LD_LIBRARY_PATH to :/mnt/scratch/objdir49/gcc::/mnt/scratch/objdir49/gcc:/mnt/scratch/objdir49/armv5tel-unknown-linux-gnueabi/libstdc++-v3/src/.libs:/mnt/scratch/objdir49/armv5tel-unknown-linux-gnueabi/libssp/.libs:/mnt/scratch/objdir49/armv5tel-unknown-linux-gnueabi/libgomp/.libs:/mnt/scratch/objdir49/armv5tel-unknown-linux-gnueabi/libitm/.libs:/mnt/scratch/objdir49/armv5tel-unknown-linux-gnueabi/libatomic/.libs:/mnt/scratch/objdir49/./gcc:/mnt/scratch/objdir49/./prev-gcc spawn [open ...] Execution terminated by abort of environment task FAIL: gnat.dg/timer_cancel.adb execution test I kind of suspect the ARM unwinder changes, but I haven't had time to verify that.
> I kind of suspect the ARM unwinder changes, but I haven't had time to verify > that. Most likely indeed, I'll investigate a bit tomorrow.
Nothing obvious stands out. I presume that exceptions cannot be caught?
> Nothing obvious stands out. I presume that exceptions cannot be caught? OK, it's presumably http://gcc.gnu.org/ml/gcc/2013-12/msg00157.html but no ARM maintainer has stepped in yet. :-( Try this: Index: config/arm/arm.h =================================================================== --- config/arm/arm.h (revision 208561) +++ config/arm/arm.h (working copy) @@ -937,13 +937,13 @@ extern int arm_arch_crc; #ifndef ARM_TARGET2_DWARF_FORMAT #define ARM_TARGET2_DWARF_FORMAT DW_EH_PE_pcrel +#endif /* ttype entries (the only interesting data references used) use TARGET2 relocations. */ #define ASM_PREFERRED_EH_DATA_FORMAT(code, data) \ (((code) == 0 && (data) == 1 && ARM_UNWIND_INFO) ? ARM_TARGET2_DWARF_FORMAT \ : DW_EH_PE_absptr) -#endif /* The native (Norcroft) Pascal compiler for the ARM passes the static chain as an invisible last argument (possible since varargs don't exist in
(In reply to Eric Botcazou from comment #3) > > Nothing obvious stands out. I presume that exceptions cannot be caught? > > OK, it's presumably http://gcc.gnu.org/ml/gcc/2013-12/msg00157.html but no > ARM maintainer has stepped in yet. :-( Try this: I'm trying this right now.
Sorry, no joy. With Eric's suggested patch I still got: === acats tests === Running chapter a ... FAIL: a87b59a Running chapter c2 ... Running chapter c3 ... FAIL: c380004 Running chapter c4 ... Running chapter c5 ... Running chapter c6 ... FAIL: c64201b FAIL: c64201c Running chapter c7 ... FAIL: c761007 Running chapter c8 ... FAIL: c85018a FAIL: c85018b Running chapter c9 ... FAIL: c930001 FAIL: c93004a FAIL: c93004b FAIL: c93004c FAIL: c93004d FAIL: c93004f FAIL: c940013 FAIL: c94001a FAIL: c94001b FAIL: c94001c FAIL: c94001f FAIL: c94002a FAIL: c94002g FAIL: c94007a FAIL: c94008a FAIL: c94008b FAIL: c94008c FAIL: c94008d FAIL: c94020a which is an improvement, but not a complete fix. At that point I aborted the whole thing. All FAILs were "Execution terminated by abort of environment task". I'm going to try a revert of the unwind changes next, as soon as I can identify the corresponding svn revision numbers.
(In reply to Mikael Pettersson from comment #5) > I'm going to try a revert of the unwind changes next, as soon as I can > identify the corresponding svn revision numbers. that would be r208419 and r208150
(In reply to Bernd Edlinger from comment #6) > that would be r208419 and r208150 Reverting r208150 + r208419 and rebuilding from scratch eliminated all acats regressions.
(In reply to Mikael Pettersson from comment #5) > Sorry, no joy. With Eric's suggested patch I still got: Correction: Eric's suggested patch does work. In my previous attempt I applied his patch and only did an incremental rebuild, and that didn't resolve all testsuite regressions. Now I've done a clean build from scratch and the testsuite regressions are in fact gone.
> Correction: Eric's suggested patch does work. In my previous attempt I > applied his patch and only did an incremental rebuild, and that didn't > resolve all testsuite regressions. Now I've done a clean build from scratch > and the testsuite regressions are in fact gone. That's good news, thanks. Did you do a testsuite run for all languages?
(In reply to Eric Botcazou from comment #9) > That's good news, thanks. Did you do a testsuite run for all languages? Sorry, didn't have time for that -- the repeated 4.9 builds and tests caused other build-and-test jobs to pile up and I need to get those done first.
Created attachment 32432 [details] Test results with all languages using Eric's patch Hi, here are my test results on armv7l-unknown-linux-gnueabihf I see no regressions, only an (expected) XPASS: XPASS: gnat.dg/test_raise_from_pure.adb execution test
(In reply to Mikael Pettersson from comment #10) > (In reply to Eric Botcazou from comment #9) > > That's good news, thanks. Did you do a testsuite run for all languages? > > Sorry, didn't have time for that -- the repeated 4.9 builds and tests caused > other build-and-test jobs to pile up and I need to get those done first. I've now done full before-and-after bootstrap+testsuite runs with --enable-languages=all,ada,go,obj-c++ on armv5tel-linux-gnueabi: Eric's patch fixed all Ada regressions, and added no new regressions.
> I've now done full before-and-after bootstrap+testsuite runs with > --enable-languages=all,ada,go,obj-c++ on armv5tel-linux-gnueabi: Eric's > patch fixed all Ada regressions, and added no new regressions. Many thanks to both of you for the testing, hopefully the patch will be OKed.
Author: ebotcazou Date: Mon Apr 7 21:31:29 2014 New Revision: 209201 URL: http://gcc.gnu.org/viewcvs?rev=209201&root=gcc&view=rev Log: PR target/60504 * config/arm/arm.h (ASM_PREFERRED_EH_DATA_FORMAT): Expose from ARM_TARGET2_DWARF_FORMAT. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gnat.dg/test_raise_from_pure.adb
Patch applied.