#471 pic16: long long support

[Jonathon Hall]

Couple more patches for pic16, initial support for long long works.

0001-pic16-dont-ignore-test-link-failures.patch: pic16's spec.mk ignored compile and link errors. If a test compiles but doesn't link, the outer Makefile would still try to run it, which yielded output from gpasm that isn't counted correctly by collate-results.py (that could be improved, but this works for the immediate problem). I can't find any reason to ignore those, so this now counts link failures as test failures.

0002-pic16-longlong-support.patch: Implemented long long for pic16, including >4 byte function arguments / return values and >4 byte generic pointer access.

With the test counting fixed, master now totals:
Summary for 'pic16': 37 abnormal stops ( ), 1048 failures, 20433 tests, 5896 test cases, 0 bytes, 0 ticks

long long support brings it to:
Summary for 'pic16': 37 abnormal stops ( ), 816 failures, 20485 tests, 5898 test cases, 0 bytes, 0 ticks

More tests compile and run, failures go down by 232.

There are a few things still missing for long long:
* 8-byte shifts by literals - currently using the non-literal code path, works but is probably pretty inefficient
* 8-byte division, it will compile but fail to link as the needed function isn't implemented.
* 8-byte get via generic pointer, if the pointer and result are allocated to the same registers (possible if the pointer is a temporary), it's not able to handle this case, currently aborts.

Only one test hits that last case as far as I know. The current algorithm tries to call _gptrget4 twice, but if the pointer and result are in the same registers, it'll clobber the pointer before needing to reload it again for another _gptrget4. I had it abort rather than generate bad code here at the moment.

I think changing the calling convention for gptrput/getN would be beneficial, right now I have to fully reload the address to call it again. I think something like passing the address in TBLPTRU/H/L (and data in or out via something like FSR0L/PRODH/PRODL/WREG) might be able to preserve the address through the call.

Do we have to preserve the ABI for generic pointer functions or could we change it? I could probably add a second set if we have to preserve the old ones.

[Philipp Klaus Krause]

The port will need to be able to get any number of bytes from 1 to 8. Most ports either have a 1-byte __gptrget or both a 1-byte and a 2-byte __gptrget.
Since __gptrget is an internal support function, we could change the ABI. Might still be worth incrementing the SDCC patchlevel version number when doing so, though.
For 8-byte division, there are support functions implemented in C: device/lib/_divulonglong.c and device/lib/_divslonglong.c. Just use that one for now - we want to be able to generate correct code, optimizations can come later if it turns out they matter to users here.

[Philipp Klaus Krause]

0001 is in the next branch in [r14588].

[Philipp Klaus Krause]

0002 is in the next branch in [r14589]. Thanks.

[Philipp Klaus Krause]

The next branch has been merged to trunk.