On Tue, Jul 18, 2017 at 12:52 PM, Ramsay Jones <ramsay@xxxxxxxxxxxxxxxxxxxx> wrote: > > Hmm, I don't think cgcc should be merged into sparse completely no. > Some things from cgcc could be moved into sparse, but not everything. > One of the main uses of cgcc is as a proxy for (g)cc. (Yes, that could > also be moved into sparse, but why bother?) I think the macro define etc should be merge to sparse. Right now some kernel file compile differently because sparse missing some platform specific macro. The last time I look at it, the coda file system has some header file generating error in sparse. I am thinking maybe have cgcc as symlink to sparse. If sparse detect it is invoke from cgcc, it will do the call gcc part. > I still have the 'intptr_t' and 'int32_t' warnings on cygwin, which I > could solve either in cgcc or sparse (I was leaning in the direction > of sparse, because Luc has already added some of these macros). These > definitions would not cause any problems on the kernel (well, if they > did, it would also be a problem with gcc!). Right, that is my point sparse need to more of those macro to behave more like gcc. > However, I would not like to say whether some of the 'platform user > space' macros would cause a problem on the kernel or not. The only > way to know is to give it a try! (Unfortunately, due to lack of disk > space, I have deleted my kernel git repository). :( It is easy enough to compare for me. I can just turn a kernel check with cgcc and see if there is any difference. Chris -- 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
