Re: Native builds?

[Paul Koning <paulkoning%comcast.net@localhost>]

> On Sep 11, 2018, at 8:55 AM, Maciej W. Rozycki <macro%linux-mips.org@localhost> wrote:
> 
> On Wed, 29 Aug 2018, Johnny Billquist wrote:
> 
>> The problem is that gcc as such is not broken. It's the code generation for
>> VAX that is, and you will not spot that with a cross compile.
>> Only native builds will detect it.
> 
> Well, not only, fortunately, unless it's a very narrow corner case.
> 
> Many if not most people working on GCC development these days use the 
> tool as a cross-compiler mostly if not solely.  Especially as embedded 
> bare-metal targets have no native configuration at all.
> 
> Being unable to spot issues but in a native configuration only would 
> therefore be a serious hindrance.  Therefore we have the GCC test suite, 
> which can be quite straightforwardly run with a cross-compiler, as long as 
> you have your target system remotely accessible for running newly-built 
> executables.  These days SSH has been the usual way for doing remote 
> access with the test suite.  I've done it many times, so I can help anyone 
> wishing doing such compiler verification.

It's also possible to use SIMH to run the test suite, there is in fact a SIMH interface in the standard scripts that are part of the test suite.  

I wonder if the known bug (fixed in V9) is caught by one of the existing test suite files.  It might well be.  (If not, it might be easy to create such a test case.)

> Beyond the usual bugs popping up from time to time we have another issue 
> with the upstream VAX port of GCC, which is that it is at risk of being 
> dropped unless someone converts it from the deprecated CC0 representation.  
> See <https://gcc.gnu.org/wiki/CC0Transition> for more details and the
> conversion status across the supported architectures.

The Wiki article is quite helpful.  VAX is a "type 2" ISA as described in that article, which is the less common kind.  Given how regular the VAX instruction set is, this should be straightforward.  I recently did it for PDP11, which is actually somewhat harder (since there are two sets of condition codes, something gcc can be made to understand but is hardly mainstream).

> A less pressing issue is the conversion from reload to LRA.  This does 
> not pose a risk for a port being dropped right now, but it would be good 
> doing anyway as the next step, as I imagine eventually reload will get 
> deprecated too.

Probably so.  Apparently this one is very easy in the typical case, it amounts to changing one #define.  It may also involve fixing some machine definitions that were technically incorrect to begin with but weren't caught before.

	paul