On Tue, May 01, 2018 at 10:51:12PM +0100, Ramsay Jones wrote: > On 01/05/18 19:56, Luc Van Oostenryck wrote: > > On Tue, May 01, 2018 at 07:06:27PM +0100, Ramsay Jones wrote: > >> On 01/05/18 15:18, Luc Van Oostenryck wrote: > [snip] > >> 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 ... > > ;-) > > I'm sure you already know this, but it just occurred to me that I > wasn't very clear about how sparse 'choked' - I should have made > it clear (for other people watching), that sparse errors out, like > so: > ... Yes, it's essentially the same than I saw on x32. Never hesitate to CC sparse's ML when you see something wrong or just odd. There is also now a bugzilla for it: https://bugzilla.kernel.org/buglist.cgi?component=Sparse&product=Tools > ... having _more_ warnings (but _no_ errors) can be an improvement! Yes, certainly with sparse! They just need to be *correct* warnings (or even errors) :) > >> 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. > > Yep, I was starting to look at what was necessary to get the > front-end to support the semantics of the new types - type > compatibility, conversion, etc. I had already decided that > I would punt on the back-end work! ;-) > > Hmm, I might get back to that at a later date, but no promises! The real problem for now, I think, is that these are not standard types and thus the standard doesn't define how they must behave (but I think that the only thing that matters is "what is their ranks relative to the standard types"). Also, I think (and thus can very well be wrong about it) that these types shouldn't be exposed without __STDC_IEC_60559_TYPES__ being defined (or __STDC_WANT_IEC_60559_TYPES_EXT__) so maybe there is also a problem with these headers. Note also that there is a __float128 that is not the same as __Float128 ... Cheers, -- 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
