On Tue, May 01, 2018 at 07:06:27PM +0100, Ramsay Jones wrote: > On 01/05/18 15:18, Luc Van Oostenryck wrote: > > This series contains the changes needed to compile and use > > sparse on x86-64's x32 variant, including the selfcheck. > > As a side-effect, for x86 & x86-64, cgcc is now much lighter > > because spasre's own logic & defines are now used. > > > > Note: The selfcheck still contains warnings like: > > "constant 0x...u is so big it is unsigned long long" > > These warnings are legit and these headers should be fixed. > > > > > > This series is also available for testing in the Git repository at: > > git://github.com/lucvoo/sparse-dev.git build-x32 > > These patches don't apply cleanly to the current 'master' branch, so > I had to wiggle them a little bit to apply cleanly. (Not difficult). Yes, I know. The official tree is way too much behind and too unresponsive for me being able to do development on it. > Having done so, I have given them a bit of light testing on Linux > Mint x86-64 and cygwin x86-64. As expected, I have no issues to > report from the testing (only sparse test-suite and a run over git > source, as usual). That's quite good because it's on platforms I never use and you test them with cgcc which I use very rarely (basically, only do the selfcheck on sparse itself when I have reasons to think that something could be wrong, like when I change something to cgcc itself). > I was interested in these patches because of the introduction of > the '_Float<n>' types in the last patch. While doing some testing > of git, using various compiler(s) version(s) on various platform(s), > I had noticed that sparse was practically useless on fedora-27. > This was, in part, because the much newer version of gcc enabled > the use of the _Float128 type which was causing sparse to choke: Interesting. I saw some weeks ago on the git ML that you said that sparse was useless for you on Fedora but without details. It made me curious enough to install Fedora on a VM but I didn't saw anything wrong while running sparse's testsuite and doing a kernel compile and then I forgot about it. I should have done a selfcheck too ... > $ grep warning sp-out1 | sort | uniq -c > 357 /usr/include/stdlib.h:133:8: warning: '_Float128' has implicit type > 7 /usr/include/sys/sysmacros.h:79:1: warning: constant 0xfffff00000000000u is so big it is unsigned long > 7 /usr/include/sys/sysmacros.h:80:1: warning: constant 0x00000ffffff00000u is so big it is unsigned long Yes, it's basically what I got on debian's x32 too. Otherwise, I never yet have seen anything special with gcc 7.3 but 99.999% of the time I use sparse on code that don't use the standard headers (mainly kernel, sparse testsuite and some personnal testsuites). > Having applied these patches, we see a nice improvement: > $ grep warning sp-out | sort | uniq -c > 364 /usr/include/sys/sysmacros.h:79:1: warning: constant 0xfffff00000000000u is so big it is unsigned long > 364 /usr/include/sys/sysmacros.h:80:1: warning: constant 0x00000ffffff00000u is so big it is unsigned long Yes, same here. Those are legit sparse warnings. > > I had started to look into adding _Float128 to sparse, so now I > don't need to! :-D Thanks! Hehe :) Note that the support for those are very minimal. They are now known to sparse and have the correct size & alignment, nothing more. How they interact/are compatible with other types, I don't know. > So, FWIW, Ack! Well, I always very much appreciate any kind of testing or any kind confirmation that things work as expected. So, yes, it's very worth to me. Thank you. -- Luc -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
