sparse: picolibc/include/complex.h: error: too many errors #680
Comments
|
As far as I can tell, this is just a bug in sparse. It doesn't appear to support I also cannot reproduce this with picolibc 1.8.6 via PR zephyrproject-rtos/zephyr#67891 -- I wonder if something has changed to make it magically work? |
|
I just switched to picolibc version 764ef4e (the one in zephyrproject-rtos/zephyr#67891) and it made no difference.
All the files in |
Oh, of course, you're building all of picolibc :-) Sorry for being dense. I'm using sparse 0.6.4 and not having any issues though. It sure looks like this is just a bug in sparse. |
|
I downgraded to sparse 0.6.4 + a cherry-pick of 3ddf02ddcb9 to avoid the infinite loop in tls.c (zephyrproject-rtos/zephyr#63417) and the reproduction is exactly the same. I'm very surprised you don't see these thousands of warnings.
So far I vaguely assumed sparse didn't like the underscore. Now I just found that full symbol Anyway it's not just ... but EDIT: forgot the "attachment" --- a/ident-list.h
+++ b/ident-list.h
@@ -31,7 +31,7 @@ IDENT(static);
/* C99 keywords */
IDENT(restrict); IDENT(__restrict); IDENT(__restrict__);
IDENT(_Bool);
-IDENT_RESERVED(_Complex);
+// IDENT_RESERVED(_Complex);
IDENT_RESERVED(_Imaginary);
/* C11 keywords */ |
That commit makes it pretty clear that sparse doesn't support The cmake configuration should be autodetecting whether the compiler supports this or not; it seems like there's an assumption that sparse supports the same language as the target compiler? Because when I run the command described above, it sets Maybe we just need an explicit parameter to disable |
|
On Tue, Jan 23, 2024 at 10:34:35AM -0800, Keith Packard wrote:
> So far I vaguely assumed sparse didn't like the underscore. Now I just found that full symbol `_Complex` is actually part of a "blocklist", see ***@***.***(lucvoo/sparse-dev@16ae3ac5c5d07) ("keyword: explicitly add C99 & C11 keywords"). I'm still not sure what that means: is `sparse` unsuited to scanning libc implementations? @lucvoo could you explain?
That commit makes it pretty clear that sparse doesn't support `_Complex` at all, so there's no way you're going to get it to deal with any file using those datatypes (`double _Complex`, `float _Complex` and `long double _Complex`).
Not exactly, it just inhibits you to use the '_Complex' as the name of
a variable/function/typedef/etc. But it's just a detail,
it's indeed the case that Sparse doesn't support complex types (its
origin as a tool for the Linux kernel explains this).
The cmake configuration *should* be autodetecting whether the compiler supports this or not; it seems like there's an assumption that sparse supports the same language as the target compiler?
In truth, this is the goal.
Because when I run the command described above, it sets `_HAVE_COMPLEX` to `TRUE`, which isn't correct for sparse.
Maybe we just need an explicit parameter to disable `_Complex` support in picolibc. Alternatively, sparse could be fixed to actually support C11?
As far as I understand support for complex types is optional in C11 and
can/should be tested via the macro __STDC_IEC_559_COMPLEX__ (which Sparse
doesn't define, of course).
But sure, ideally, Sparse should support complex types (and the different
vectors type and a few other things). It shouldn't be very hard, it's just
a question of time and priorities.
Best regards,
-- Luc
|
Yes, and the picolibc build system checks to see if the 'toolchain' supports |
Pretty much all static C/C++ analyzers I've used work the same: they inject themselves in the middle of the build system to gather compiler invocations: source file names, options, -D macro definitions etc. For zephyr and sparse see this small and insightful commit zephyrproject-rtos/zephyr@91902c5fd4db756. Note the REAL_CC magic there, also explained here: https://github.com/lucvoo/sparse-dev/blob/1cf3d98cf171/cgcc.1 So from a build perspective I'm afraid there is no such thing as "the sparse toolchain" or "the sparse build" that could be configured differently. I don't think anyone would like to analyze sources different from what they actually use. On the other hand, is there a simple way to disable complex.h from the Zephyr build system/Kconfig? As opposed to auto-detecting it from the toolchain. Not a solution for projects actually using complex numbers but a great solution for everyone else. It would also save some build time; never hurts.
Should we close this picolibc issue and move back to a re-opened 67035? |
For completeness: some developers may be selfishly interested in warnings only in the subset/component they wrote. From past experience again, filtering this at build time is tricky to achieve: you have to fight the build system. This also hides information from analyzers which have a global view and don't just look at each .c file one by one. See an example and good explanation there: https://www.synopsys.com/blogs/software-security/coverity-and-issues-in-third-party-code.html So for these "selfish" people it's simpler, safer and generally better to exclude warnings from picolibc or other after analysing the complete project as is. Display filters, no build-time filter. With sparse we have to filter after analysis anyway due to So filtering warnings in a per-component basis can be done at the same, post-analysis time; two birds with one stone. |
|
There's currently no way to disable |
[This was found in zephyrproject-rtos/zephyr/issues/63417 (which is fixed now) but it's not related to it. It was also filed earlier in zephyrproject-rtos/zephyr/issues/67035 but I don't think it's related to Zephyr. Also: I'm less confused now]
When trying to use the "sparse" on Zephyr with picolibc,
complex.his alone responsible for 7,300 lines of warnings out of 10,000 lines total.In fact complex.h triggers so many warnings that
sparseaborts when compiling some (most?) files:Of course one of the reason is very likely that
complex.his included in many C files (which is not going to change).If not all warnings, it should be possible to reduce the number of these warnings to a volume that is easier to filter and that does not cause sparse to abort entirely.
And hey who knows: maybe some of these warnings are finding actual problems?
Reproduction with sparse version 365b95203727. Compile with
make, add to PATH.Warning:
-DCONFIG_PICOLIBC_USE_MODULE=yis required to avoid issue #63003cc: @keith-packard
The text was updated successfully, but these errors were encountered: