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
