On 31 May 2012 19:18, Paul Brook wrote: > > Testing: > > * Crossbuild for target arm-none-eabi with cpu cortex-a9 neon softfp > and > > tested in three configuration: -marm (default), -mthumb, -mapcs- > frame. No > > regression on qemu. > > * Crossbuild for target arm-none-eabi thumb2 with cpu cortex-m3. No > > regression on qemu. > > * Crossbuild for target arm-none-eabi thumb1 with cpu arm7tdmi and > > arm1136jf-s. No regression on qemu. > > * Crossbuild for target arm-linux-gnueabi with cpu cortex-a9 with > eglibc > > and used this compiler to build AEL linux kernel. It boots > successfully. * > > Bootstrap the compiler on cortex-a8 successfully for > > --languages=c,c++,fortran and used this compiler to build gdb. No > > regression with check-gcc and check-gdb. > > What other testing have you done? Thate's a good number of > combinations not > covered by your above list. In particular: > - Coverage of old cores looks pretty thin. In particular ARMv4t has > different > interworking requirements.
I ran a full regression test of gcc configured with cpu arm7tdmi on qemu. Is there another ARMv4t configuration that should be tested? > - iWMMXT has special alignment requirements. > - Interrupt functions with special prologue/epilogue. Both traditional > ARM > and Cortex-M3. A few tests for interrupt functions are included in gcc's regression suite. Specifically, the test gcc.target/arm/handler-align.c checks that the stack pointer is handled correctly in prologue/epilogue of Cortex-M interrupt handlers. I have a patch (not yet posted) to make this test more effective. > - -mtpcs-frame and -mtpcs-leaf-frame > > Some of these options are orthogonal. > > As you've proved with -mapcs-frame it's near impossible to get these > right > without actually testing them. I'm not saying you have to do a full > testrun > in every combination, but it's worth testing a representative selection > of > functions (large and small frame, leaf or not, with and without frame > pointer, > uses alloca, etc). > Also worth explicitly clobbering a selection (both > odd and > even numbers) of callee saved registers to make sure we get that right. > Any > difference in the output should be manually verified (ideally the > assembly > output would be identical). For interrupt-related tests, interworking, and several other tests, I've compared the assembly outputs before and after the patch (and caught a couple of bugs this way). In most cases now, the assembly outputs before and after the patch are identical. The few differences I have seen are due to successful compiler optimizations, where we benefit from having generated epilogues in RTL. For example, replacing "sub sp, fp, #0" with "mov sp, fp" in epilogue. Also, explicit write to callee-saved registers to restore them in epilgoue allows the data flow analysis pass to deduce that registers are dead and enables peephole optimizations that were not possible before. > > > * The patches have not been explicitly tested with any FPA variants > (which > > are deprecated in 4.7 and expected to become obsolete in 4.8). > > I'm not keen on breaking these without actually removing them. Thanks for pointing out additional configurations to test. I will test -mtpcs-frame and -mtpcs-leaf-frame as you suggested and run regression tests for iWMMXT. Properly testing FPA variants at this point is a lot of work, especially considering the fact that these variants are obsolete. What minimal configurations would be sufficient to test? Thank you, Greta
