Re: Issues with compiler failures

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

> On Apr 1, 2019, at 10:27 AM, maya%netbsd.org@localhost wrote:
> 
> ...
> I tried to creduce the blake2b crash and got a second crash:
>> cat blake2b.new.i
> long long a;
> b;
> unsigned char c;
> d() {
>  long long e[6];
>  a = b + e[c];
> }
> 
>> ~/vax/tooldir.NetBSD-8.99.31-amd64/bin/vax--netbsdelf-gcc blake2b.new.i -O2
> ...
> blake2b.new.i:7:1: internal compiler error: in reg_overlap_mentioned_for_reload_p, at reload.c:6591
> 
> That one doesn't even sound like something that a backend can trigger,
> but a bug in reload somewhere.
> 
> I guess it's back to the original plan of switching away from reload?
> :-)

Probably a good idea, but I found that LRA is actually more sensitive to back ends that do things not quite correctly.  I suspect this is an example of that.  Given that the issue is with 64 bit values, you might want to check how register classes and permitted modes are defined.

Read very carefully the internals manual section about the the mov<mode> insn.  There are a bunch of special rules for that one, and they matter.  If you get some of them wrong things will break in surprising ways, often around reload or LRA.

> I got the PSW idea because making the CCmode a hard register made things
> stop violently crashing for me! (I saw in pdp11).

Yes, for VAX you definitely want to do the same, create a CC register which is a hard register.  It's interesting that on VAX this is a call-saved rather than a call-clobbered register.

> Skimming the VAX instructions, it looks like they can be set to 3
> different categories:
> 
> clobbers N/Z/V/C
> clobbers N/Z/V
> no condition code change
> 
> wouldn't it make sense to have CCmode for NZVC and a second more for
> just N/Z/V? Although I guess that it matters whether something ever
> cares about just the carry flag!

I don't think the difference matters here.  This is a place where VAX is definitely easier than PDP11, because the signed branches on PDP11 pay attention to V while on VAX they do not.

The important point is that condition code side effects in GCC are all modeled as compare with zero.  And the only conditional branches that care about C are unsigned < <= > >= -- which aren't going to show up after an implied compare with zero.

PDP11 has two modes, CCmode and CCNZmode, the latter for "only N and Z are valid".  That ensures signed branches that care about V aren't used when V isn't correct for the implied compare with zero -- ADD is an example where that would apply.  VAX doesn't have this issue and I see no other reason to use more than just CCmode.

	paul