Re: Bountysource campaign for gcc-vax

["Maciej W. Rozycki" <macro%linux-mips.org@localhost>]

On Mon, 12 Oct 2020, Maciej W. Rozycki wrote:

>  I've now completed lab setup up to being able to use it for this effort, 
> and I have rerun testing with a new mighty server (a *proper* server, not 
> a laptop).  This time results are not perfect either, but they are much 
> better, though the execution time was a bit longer (still acceptable 
> though), possibly due to the additional test cases that passed:
> 
> 		=== gcc Summary ===
> 
> # of expected passes		110142
> # of unexpected failures	1821
> # of unexpected successes	7
> # of expected failures		566
> # of unresolved testcases	30
> # of unsupported tests		3131
> /scratch/vol0/vax-netbsd/obj/gcc/gcc/xgcc  version 11.0.0 20200704 (experimental) (GCC)
> 
> make[1]: Leaving directory '/scratch/vol0/vax-netbsd/obj/gcc/gcc'
> make: Leaving directory '/scratch/vol0/vax-netbsd/obj/gcc/gcc'
> 7556.83user 1129.03system 12:04:47elapsed 19%CPU (0avgtext+0avgdata 814080maxresident)k
> 142336inputs+23404672outputs (2major+69725859minor)pagefaults 0swaps

 I now have a prototype implementation, with promising test results:

		=== gcc Summary ===

# of expected passes		110124
# of unexpected failures	1852
# of unexpected successes	7
# of expected failures		566
# of unresolved testcases	31
# of unsupported tests		3131

The 31 regressions are spread across 6 test cases, one of which looks like 
another incarnation of a preexisting problem:

 FAIL: gcc.dg/lto/pr55660 c_lto_pr55660_0.o-c_lto_pr55660_1.o link, -O0 -flto -flto-partition=none -fuse-linker-plugin
+FAIL: gcc.dg/lto/pr55660 c_lto_pr55660_0.o-c_lto_pr55660_1.o link, -O2 -flto -flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects

i.e. the test failed at `-O0' already, and now it also fails at `-O2'.  
Indeed:

/tmp/cc7MCwnm.s: Assembler messages:
/tmp/cc7MCwnm.s:36: Warning: Symbol n used as immediate operand in PIC mode.
FAIL: gcc.dg/lto/pr55660 c_lto_pr55660_0.o-c_lto_pr55660_1.o link, -O0 -flto -flto-partition=none -fuse-linker-plugin

and:

/tmp/ccG0X3DQ.s: Assembler messages:
/tmp/ccG0X3DQ.s:17: Warning: Symbol n used as immediate operand in PIC mode.
/tmp/ccG0X3DQ.s:26: Warning: Symbol n used as immediate operand in PIC mode.
FAIL: gcc.dg/lto/pr55660 c_lto_pr55660_0.o-c_lto_pr55660_1.o link, -O2 -flto -flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects

indicate some RTL pattern incorrectly permits a symbolic (i.e. link-time) 
constant as an instruction operand where an assembly-time constant only is 
supported with the PIC ABI.  This will be easy to track down, though it 
qualifies as a separate bug fix.  The failures with the remining 5 test 
cases affected are ICEs yet to be tracked down.

 An announcement has now just been posted giving Nov 15th as the end of 
Stage 1 and consequently the deadline for general GCC 11 development:

<https://gcc.gnu.org/pipermail/gcc/2020-October/234007.html>

which means we're fully on track with this effort even for this deadline, 
though I'd consider this conversion a functional bug fix really, suitable 
for Stage 3 even.

  Maciej