[PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included)

[Maciej W. Rozycki]

Hi,

 [Paul, there's a PDP11 piece for you further down here and then 29/31.]

 This is the much-desired refurbishment of the VAX backend.  A little bit 
past the end of Stage 1, which I apologise for and which I do hope is not 
going to make it a no-no for GCC 11.  I feel quite satisfied anyway I was 
able to overcome all the difficulties outside the development itself I was 
faced with throughout this effort and fit it into quite a tight schedule 
between my departure from Western Digital effective Sep 1st and now.

 Special thanks to Anders "Ragge" Magnusson for persuading me, on my trip 
to Luleå, Sweden back in 2015, to adopt Lizzie, his VAXstation 4000/60 he 
used to use for VAX/NetBSD development and decided to part with, as she 
turned out to be the only VAX machine in my possession ready to undertake 
the task of GCC verification, and also quite a mighty one for such a 
mature piece of hardware.

 The port has turned out to have some issues, which I decided to address 
so as not to have to propagate or correct breakage with the MODE_CC update 
itself, hence the 28 preparatory patches.  I might have skipped maybe two 
changes as not really necessary, such as the addition of `movmem' pattern, 
but they were really low-hanging fruit, and then easy to lose if not done 
right away.  I have split MODE_CC conversion test cases off due to the 
size of the change.

 Then there is a fix for the PDP11 backend addressing an issue I found in 
the handling of floating-point comparisons.  Unlike all the other changes 
this one has not been regression-tested, not even built as I have no idea 
how to prepare a development environment for a PDP11 target (also none of 
my VAX pieces is old enough to support PDP11 machine code execution).

 Still I am fairly sure it is a correct change to make, and you should be 
able to confirm it quite easily perhaps by picking the same test case from 
31/31 that I used for the example RTL dump in 28/31 and using it along 
with said dump to match what the PDP11 backend produces.  Maybe you can 
use these test cases for PDP11 verification as well, as they are pretty 
generic except for the assembly match patterns of course.

 These changes have been regression-tested throughout development with the 
`vax-netbsdelf' target running NetBSD 9.0, using said VAXstation 4000/60, 
which uses the Mariah implemementation of the VAX architecture.  The host 
used was `powerpc64le-linux-gnu' and occasionally `x86_64-linux-gnu' as 
well; changes outside the VAX backend were all natively bootstrapped and 
regression-tested with both these hosts.

 Target regression-testing has been done across all the components that 
build (01/31 is required to build libgomp at `-O2), meaning the following 
parts have been excluded for the reasons stated:

1. libada -- not ported to VAX/NetBSD, machine/OS bindings not present.

2. libgfortran -- oddly enough for Fortran a piece requires IEEE 754
   floating-point arithmetic (possibly a porting problem too).

3. libgo -- not ported to VAX/NetBSD, machine/OS bindings are not present.

and the absence of the respective libraries caused failures with the 
respective frontends as well.

 One regression has been nominally caused, in C frontend testing:

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

however it is a symptom of an unrelated bug in the LTO wrapper, which 
clears the PIC flag unconditionally:

    case LTO_LINKER_OUTPUT_EXEC: /* Normal executable */
      flag_pic = 0;
      flag_pie = 0;
      flag_shlib = 0;
      break;

and causes a legitimate assembly warning:

/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.

similarly to a preexisting failure for the same test case at `-O0':

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 numerous other ones.  I'll file a PR to track this problem and see if 
I can address it quickly now that I'm done with the MODE_CC conversion, 
with the understanding that it may not be suitable for GCC 11 at this 
point of the development cycle.

 As I have refreshed the tree again for this submission and verification 
takes short of 48 hours per run, I'll be scheduling another full cycle and 
expect to have updated results in about a week's time as all being well I 
imagine I'll have to go throug three runs for the base results, results 
for the preparatory changes, and then the final results.  I'll see if I 
can arrange and run some benchmarking too.

 See individual change descriptions for details and code quality stats.

 Last not least for easier access I have made these changes available at 
<git://gcc.gnu.org/git/gcc.git>, `users/macro/vax-mode-cc' branch.

 Comments, questions, concerns?

  Maciej