On 27/11/2019 21:02, Luc Van Oostenryck wrote: > On Wed, Nov 27, 2019 at 06:05:37PM +0000, Ramsay Jones wrote: >> On 27/11/2019 17:48, Luc Van Oostenryck wrote: >>> On Wed, Nov 27, 2019 at 05:15:20PM +0000, Ramsay Jones wrote: >>>> >>>> I was going to just test 'luc/int128_ctype', but looking at the output >>>> of 'git log --oneline --graph master..luc/int128_ctype' I can see that >>>> several other branches are merged into the result. So, I will apply >>>> the patches from the mailing list directly to test them (hmm, _hopefully_ >>>> tonight). >>> >>> Hi Ramsay, >>> >>> Sorry, I should have added in the cover letter that the series >>> with all related patches is available at: >>> git://github.com/lucvoo/sparse-dev.git next >> >> Hmm, but that _also_ contains several other branches not contained >> in 'master', thus: >> >> $ git --no-pager log --oneline --graph master..luc/next >> * 4a8aa8d1 (luc/tip, luc/next) cgcc: add support for riscv64 >> * df14d253 arch: fix wchar_t & wint_t for openbsd >> * 662ed740 arch: add missing predefines for PPC >> * 1ff97d3a arch: add missing predfines: __amd64 & __amd64__ >> * d8754f2c cgcc: filter-out -msize-long & -msize-llp64 >> * 7efa090f (luc/int128_ctype) spec: replace lllong_ctype by int128_ctype > > Yes, indeed. It's how these patches have been written and tested, though. > They're supposed to be the cherries on top of the cake. > But I think that only 'df14d253 arch: fix wchar_t & wint_t for openbsd' > may have some dependencies on one of these branches. For the 3 others > it shouldn't matter. I decided to just test the 'luc/next' branch (commit 4a8aa8d1 cgcc: add support for riscv64). :-P I have only tested on 64-bit Linux and Cygwin (the sparse testsuite and running it over git), so far with no issues. I have also compared the output of: $ ./cgcc -dM -E - </dev/null | sort >sss $ gcc -dM -E - </dev/null | sort >ggg $ meld ggg sss on both Linux and cygwin (with similar results). I have ignored the 'float stuff', since the output of gcc and sparse is almost totally different! :( The main difference, which is new, is the spelling of the 'type names'. e.g. __CHAR16_TYPE__ is given as 'short unsigned int' by gcc but 'unsigned short' by sparse. The following table shows the 'type name' differences: CHAR16_TYPE short unsigned int => unsigned short INT16_TYPE short int => short INT64_TYPE long int => long INTMAX_TYPE long int => long INTPTR_TYPE long int => long PTRDIFF_TYPE long int => long SIZE_TYPE long unsigned int => unsigned long UINT16_TYPE short unsigned int => unsigned short UINT64_TYPE long unsigned int => unsigned long UINTMAX_TYPE long unsigned int => unsigned long UINTPTR_TYPE long unsigned int => unsigned long sparse seems to '#define linux linux' rather than '#define linux 1'. sparse defines __LITTLE_ENDIAN__ but gcc does not. On cygwin, the results are similar to the above, with the addition of the following: WCHAR_TYPE short unsigned int => unsigned short Also, sparse defines __CYGWIN32__ when it shouldn't (this is on x86_64 cygwin, without -m32 etc). That's all so far. ;-) ATB, Ramsay Jones
