| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This guarantees the generated version.h will exist before attempting
to compile any c files that include it.
Several source files include the generated version.h, but not all
declare a proper make dependency.
$ grep -r 'version\.h' *.c
compile-i386.c:#include "version.h"
lib.c:#include "version.h"
options.c:#include "version.h"
This allows a sufficiently parallelized make invocation to encounter
ENOENT.
CC compile-i386.o
compile-i386.c:60:21: fatal error: version.h: No such file or directory
compilation terminated.
Makefile:253: recipe for target 'compile-i386.o' failed
make: *** [compile-i386.o] Error 1
Signed-off-by: Kyle Russell <bkylerussell@gmail.com>
[luc.vanoostenryck@gmail.com: modified so that only version.c depends on version.h]
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Now, diagnostic messages are prepended with the source path.
But if the problem comes from a file included directly from
the command line like:
sparse -include some-buggy-file.c
the prepended message will be:
(null): note: in included file ...
because there isn't a source path yet.
So, initialize the source path to "command-line".
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Now that struct stream contains the parent's stream, it
might as well contains the position so that all information
about the parent is available.
So, add a struct position to struct stream, initialize it
with the information from the '#include' token (if there is one)
and use this positions's ::stream as previous/parent stream.
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
When a diagnostic is issued for a problem in an included file,
the message show the include's path but it's often needed to
(quickly) know the chain of include files involved.
So, if the path associated with the diagnostic is different
than the path oft he source file and different from the path
of the previous message, prepend the message with a note
showing the source file's path. And, if any intermediate
include file is concerned, display the include chain
(possibly truncated or not displayed at all if too long).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Currently, the maximum number of displayed errors is 100.
This is nice to not be flooded with error messages when things
are really broken but in some situation, for example testing,
it is desirable to have all error messages.
So, teach sparse about '-fmax-errors=COUNT'.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
pre_buffer_begin & pre_buffer_end are the head and the tail of
a singly chained list. As such, it's slightly easier to not
keep a pointer on the last element but a pointer where the
next element should be written.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Now lib.c contains almost nothing else than library entrypoints.
Move a small utility, hexval(), to utils.c to complete this cleanup.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
lib.c contains 2-3 helpers for parsing. Move them to parse.c.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Now that option parsing have moved to a separate file, move
everything related to predefined macros to a separate file too.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
lib.c contains to much things and is too hard to keep tidy.
So, move everything related to option parsing in it's own file.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
This is just to isolate the details about which switch need an
extra 'finalization' in a separate function in preparation
to moving all the parsing code in a separate file.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
It's a stylistic detail but a lot of the strcmp() calls used for
the processing of the options are written 'strcmp (...)'. Two
other functions calls are also in the case.
Reformat them to the usual style for function calls: without
the space between the function name and the arguments.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
These function have probably been added in 'historical order' and
as result it's not easy to quickly see where they're defined.
Change this arranging them in asciibetical order.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
The helpers for parsing the options are often situated just above the
first function using them. As result, these helpers can be found a bit
everywhere in the code, it's messy and doesn't help to reuse these helpers.
So, move all these helpers to the top.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
So, use 'flag' instead of 'warning' for variable and function names.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
-Wsparse-error should not be enabled with -Wsparse-all, this is
special cased in the condition in loop handling -Wsparse-all.
However, the condition already handle warnings forced to off.
So instead of explicitly checking for &Wsparse_error, it's enough
to force Wsparse_error off.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
This allows to reuse these enums in earlier helpers.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Since handle_onoff_switch() can be used for other flags than the
warnings, the processing of -Wsparse-all should move elsewhere.
So move it into handle_switch_W().
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
This makes things slightly easier to use.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
It seems that some system libraries expect __STDC_HOSTED__ to
be always defined.
So, teach sparse the options flags -f[no-]{hosted,freestanding}
and define __STDC_HOSTED__ accordingly.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
* support for builtin macros with arguments
* support for __has_feature() & __has_extension()
|
|
The macros __has_atribute() & __has_builtin() are only expanded
in the context of a preprocessor conditional but they should
be expanded like usual user defined macros.
Fix this by using the new infrastructure for builtin macros.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
The curent way to declare the builtins is not by using a table
but via a (variadic) function call, one for each builtin.
A table is preferable but a complication for doing this
is that some elements are not constant. For example, 'size_t_ctype'
is dynamically set in the early steps of the type initialization.
Doing a series of function calls allowed to circumvent this.
Fix this by:
* Using a constant temporary alias for non-constant entries. It's the
value of these alias that will be used when registering the builtins.
* using a table to declare the builtin functions.
Note: the motivation for doing this is to be able to add sub-tables
for the arch-specific builtins (and use the same mechanism
as for the main table).
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
The initialization of the buitins can be done later, after
the types have been initialized.
So move the call to init_builtins() to just before declare_builtins().
This will allow some other small improvements.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
'{ 0 }' is the standard idiom for the universal zero initializer '{ }'.
But if the '0' is taken literally, warnings can be issued, for exemple
for 'using 0 as NULL pointer' or for 'using a positional initializer'
when the attribute 'designated_init' is used.
These warnings were not intended to be issued for this initializer
and are confusing and annoying when people have to use or want to
use standard code or ignore that '{ }' is fine to use with GCC,
clang or Sparse.
So, set sparse default to -Wno-universal-initializer, suppressing
any warnings caused by using '{ 0 }' instead of '{ }'.
Reference: https://lore.kernel.org/git/e6796c60-a870-e761-3b07-b680f934c537@ramsayjones.plus.com/
Reference: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95379
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Some platforms have some of their system header files missing the
ending newline. Sparse will then warn about it, again and again,
and more important warnings can easily be lost in the noise.
So, add an option flag '-W[no-]newline-eof' to conditionalize
this warning.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
In standard C '{ 0 }' is valid to initialize any compound object.
OTOH, Sparse allows '{ }' for the same purpose but:
1) '{ }' is not standard
2) Sparse warns when using '0' to initialize pointers.
Some projects (git) legitimately like to be able to use the
standard '{ 0 }' without the null-pointer warnings
So, add a new warning flag (-Wno-universal-initializer) to
handle '{ 0 }' as '{ }', suppressing the warnings.
Reference: https://lore.kernel.org/git/1df91aa4-dda5-64da-6ae3-5d65e50a55c5@ramsayjones.plus.com/
Reference: https://lore.kernel.org/git/e6796c60-a870-e761-3b07-b680f934c537@ramsayjones.plus.com/
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
GCC defines these, so should we.
Signed-off-by: John Levon <john.levon@joyent.com>
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Signed-off-by: John Levon <john.levon@joyent.com>
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
As per:
https://gcc.gnu.org/onlinedocs/gcc-4.6.3/gcc/Symbol_002dRenaming-Pragmas.html
we should set this define.
Signed-off-by: John Levon <john.levon@joyent.com>
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
arch_target now points to a structure holding all the
arch-specificities. So, arch_mach is not needed anymore.
Remove arch_mach.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
The predefine for INT128 is still done with the generic
predefines but are arch-specific.
So, set a new flag for each arch supporting int128
and use this to determine if the predefine must be
issued or not.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Now that each supported arch has its own target file,
move the predefines for cmodel, which are arch-specific,
to the target files.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Now that each supported arch has its own target file,
move the arch-specific predefines to these files too.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Before initaializing the builtin types some 'finalizations' are
needed. target_ini() already does most of this.
So, move the arch-specific content of handle_arch_finalize()
into the corresponding target files and the generic part to
target_init().
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
So, the 2 tables indexed by arch are next to each other,
both in target.c, making easier to add a new arch.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
lib.c and even more so, target.c, become cluttered by the
arch specific type initialization.
It would be better to move this to arch-specific files,
move the generics target related helpers to target.c
and have sparse_initialize() to just call these helpers.
For doing this:
* introduce a struct to hold the configurations for each arch,
* move the arch-specific type initialization to separate files,
* make target.c generic.
Also change the default types to LP64.
Note: this is the first step to better handle other arch
specificities like the predefines or the handling
of some options.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
No real support is done here (or is needed) but the __STDC_VERSION__
will return the correct value.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
The definition of __STDC_NO_ATOMICS__ and friends will also
be needed for C17.
Move these definitions outside of the switch statement.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Currently, the definition of __STRICT_ANSI__ is done in the same
switch statement used for __STDC_VERSION__. However, this lead to
some repetions that can be avoided if moved outside of the switch.
Move the definition of __STRICT_ANSI__ out of the switch statement
and guard it by testing the absence of STANDARD_GNU.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Move some of the cases so that each STANDARD_GNU* is just
under the its corresponding STANDARD_C*.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Since semantics and supported features can differ between
standard version we may need the supported version.
Allow this by moving the variable 'standard' and the corresponding
enum definition to lib.h
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
In preparation for supporting C17 flags, remove unneeded
STANDARD_... cases and remove the impossible default assert(0).
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
The macros __PPC, _ARCH_PPC & _ARCH_PPC64 are predefined by
GCC for powperpc (well, it seems __PPC isn't anymore but
it was, at least on my old toolchain for ppc32).
So, do the same here too.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
These seem to be defined whenever the __x86_64 and
__x86_64__ macros are defined.
So, do the same here too.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
|
|
There are a few OS-specific settings and handling them
with #ifdef is 1) ugly, 2) can only work with when specifically
built for this OS (either a native or cross-build).
So, use a variable to hold the OS and initialize it to the one
used to compile sparse. This avoid the ugly #ifdef and allow
simpler transition if if the future sparse would take the OS
in parameter (maybe as triple).
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
The predefines for INT128 were added unconditionally for
all archs but only the 64-bit ones support them.
Fix this by issuing the the predefines only on 64-bit archs.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
When the predefine for char32_t was added, it was made to
correspond 'unsigned int' with the commit message saying
some archs use 'unsigned long'. In fact, it appears that
char32_t is always uint32_t (on the archs & OSes I'm using
to look at this).
So, simply predefine __CHAR32_TYPE__ like uint32_t is.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
|
|
Teach Sparse about these options.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Teach sparse about the -mfloat-abi option and set the
related predefines for ARM accordingly.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Currently handling a set of suboptions is done by a series of
if (strcmp()) but it's neater to have this in a table.
Add an helper to doing this easily and convert the handling
of '-mcmodel' options.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
The function handle_switch_m(), parsing the -m flags,
consists in a series of strcmp(), each setting a specific
value in one of the internal flag variable.
This can now be simplified by using a table to specify these
variables & values in a compact form.
So, convert the current code to use, if possible, a table &
handle_switches().
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
The function handle_switches() was designated to set or clear
simple boolean flags but some options, internally, are
non-boolean.
So, extend the function so that it can be used to set non-boolean
values.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
This is useful in cgcc for supporting Cygwin which doesn't
use a 32-bit type for wchar_t.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
The helpers for option parsing are spread all over the functions
doing the effective parsing. This doesn't help to reuse these
helpers because new potential uses sometimes arise before the
helpers itself.
Fix this by moving all these helpers above any function which
may use them.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
The code at the start of init_target() already take care
of making the arch variants match their bitness. It's thus
not possible, when setting the type of [u]int32, to have
mips64, ppc64, riscv64 or sparc64 with arch_m64 different
than ARCH_LP64.
So, remove the unneeded checks.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Some architectures, like ARM or PPC, use 'unsigned' for
plain chars while others, like the Intel's, use signed ones.
Sparse understands -funsigned-char but by default uses the
native signedness.
Fix this by setting the proper signedness of plain chars
for the archs that Sparse know about.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Some older codebases hit this warning all the time, so it's useful
to be able to disable it.
Signed-off-by: John Levon <john.levon@joyent.com>
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Commit 3c3881cf1c ("cgcc: let sparse define _BIG_ENDIAN", 2019-11-08)
moved the definition of the _BIG_ENDIAN macro from cgcc to sparse (for
the powerpc platforms). Unfortunately, the macro was inadvertently spelt
incorrectly (as _BIG_DEBIAN). Correct the spelling.
Fixes: 3c3881cf1c68f1b4ec4e5a68fa0aa92e88eb275c
Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
In addition of __BIG_ENDIAN__, gcc defines _BIG_ENDIAN on
powerpc (32 & 64-bit). cgcc does that too but this may also
beeneeded when using sparse itself.
So, move this define the the sparse code.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
The new --arch flag set arch_big_endian for big endian archs
but didn't clear it for little endian ones.
Fix it by simply copying the endianness from the arch table.
Fixes: 2c06f143fa63394dbdfa07f3f9d00b24b7c902c5
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
* add new option, --arch=ARCH, allowing to specify the target arch.
|
|
Sparse is universal in the sense that the same executable can
be used for all architectures. For this, most arch-specific
setting can be set with an option and the default values
are taken from the host machine.
This is working nicely for native targets. However, for cross-
compilation, while seeming to work relatively well (thanks to
the kernel build system using -m32/-m64 for all archs, for example)
things can never work 100% correctly. For example, in the case
an X86-64 host machine is used for an ARM target, the kernel
build system will call sparse with -m32, Sparse will 'autodetect'
the target arch as i386 (x86-64 + -m32) and will then predefine
the macro __i386__. Most of the time this is not a problem (at
least for the kernel) unless, of course, if the code contains
something like:
#ifdef __i386__
...
#elif __arm__
...
So, add an option --arch=<arch> to specify the target architecture.
The native arch is still used if no such flag is given.
Reported-by: Ben Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
On s390x, the flag -m31 is needed to enable this mode.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
This define was missing for MIPS, add it.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Do the parsing of all models used in the kernel and
output the predefines for arm64 & riscv.
Reported-by: Paul Walmsley <paul.walmsley@sifive.com>
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Do the parsing and output the corresponding predefines.
Follow the same rules as GCC: pic/pie -> 1, PIC/PIE -> 2
and pie/PIE implies pic/PIC.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
This variable is used to set 'size_t_ctype' with the option
'-msize-long'. Code that cares should directly use size_t_ctype,
not 'arch_msize_long'.
To be sure that some random code doesn't use 'arch_msize_long',
make it local to "lib.c".
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Predefined macros like '__x86_64__', '__arm__', ... are used
in systems headers (and surely at other places too).
So, when appropriate, define the following symbols which seems
to be somehow needed by glibc:
m68k: __m68k__
mips: __mpis64, __mips
ppc: __ppc64__, __powerpc, __ppc__
riscv: __riscv__, __riscv_xlen__
s390: __zarch__
sparc: __sparc_v9__, __sparcv9
x86-64: __x86_64__, __x86_64
Also, the following symbols, which were previously only defined
in cgcc, are now defined in Sparse itself:
i386 __i386, __i386__
sparc __sparc, __sparc__, __arch64__, __sparc64__, __sparcv9__
s390 __s390__, __s390x__
ppc __PPC__, __powerpc__, __PPC64__, __powerpc64__
arm __arm__
arm64 __aarch64__
Note: these are only tested on i386, x86-64, arm, arm64,
mips64 (ABI O32), ppc, ppc64 (power7), ppc64el (power8)
and sparc64, most of them on a not-so-new OS version.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
System headers (at least glibc's ones) define and use __WORDSIZE
which, on most archs, is defined depending on __LP64 or __ILP32.
But on MIPS, __WORDISZE is defined depending on the value of the
builtin macro _MIPS_SZPTR.
So, add the predefine for _MIPS_SZPTR on MIPS.
Reported-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
It must be done after init_target because of some archs (PPC32,
mips32, ...) have int32_t set to long. These 32-bit ints would
then become 64-bit.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Tested-by: Uwe Kleine-König <uwe@kleine-koenig.org>
|
|
In handle_arch_m64_finalize(), some types (like size_t_ctype)
are set to support the flag '-m64' and native 64-bit archs.
But some predefines are also issued.
As a preparatory step to fix a bug related to a inconstency
between this function and init_target(), move the predefines
to predefined_macros().
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Tested-by: Uwe Kleine-König <uwe@kleine-koenig.org>
|
|
* warn on casts to/from bitwise pointers
|
|
Support for 'bitwise' integers is one of the main sparse's extension.
However, casts to or from pointers to bitwise types can be done
without incurring any sort of warnings although such casts can
be as wrong as direct casts to or from bitwise integers themselves.
Add the corresponding warnings and control them by a new flag
-Wbitwise-pointer (defaulting to off as it creates tens of
thousands warnings in the kernel).
CC: Thiebaud Weksteen <tweek@google.com>
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
* add predefined macros for __INTMAX_TYPE__, __INT_MAX__, ...
|
|
wchar_t & wint_t seems to be the only integer types needing
the _MIN__ macros.
Extend predefine_ctype() to handle these and use it to define
__WCHAR_MIN__ & __WINT_MIN__.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
This macro is needed by <limits.h> to get, among others things,
CHAR_MAX from __SCHAR_MAX__.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
These types are supposed to be defined the same as
uint_least{8,16}_t. So define them as 'ushort' and 'uint'.
Note: it seems that some archs define char32_t as 'ulong' although
their 'uint' is 32bit ...
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
These are a pain. All LP64 archs use [u]int. Good.
But some LP32 archs use [u]int and some others use [u]long.
Some even use [u]int for some ABI and [u]long for some others
(bare metal).
This really need to be target-specific to be correct.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
All LP32 archs use [u]llong and all LP64 use [u]long for these
but Darwin which seems to always use [u]llong.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
All LP64 & LP32 use [u]char and [u]short for these ones.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Seems to use [u]long for all LP64 archs and [u]llong
and all LP32 ones (but OpenBSD but it seems to not defines
the corresponding macros).
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Luckily, it seems all archs use for them the same types as
size_t & ssize_t.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
This type seems to use 'unsigned int' on all archs but for
Darwin & FreeBSD.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
|
|
This allows to use predefined_ctype() on wchar_t.
Note: currently __WCHAR_TYPE__ is defined to 'int'
but this is incorrect on: i386, m68k, ppc32, ...
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
This allows to have a single function to output the
size, the type, the maximal value, ...
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Creating a bit mask using '(1 << n) - 1' is undefined if
n is as big as the width of an int.
Use the safe helper bits_mask() to create the mask/value
for predefined_max().
Note: predefined_max() is currently correct only for signed types.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
This allows to be more generic.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
size_t_ctype is set to uint, ulong or ullong, depending on
the architecture (ullong is only used for LLP64).
However, when emitting '__SIZE_TYPE__', it's only compared to ulong
or uint.
Fix this by using an small helper directly using the right
struct symbol * and using builtin_typename() to output the
right type. This way we're guaranteed that '__SIZE_TYPE__'
is kept coherent with the internal type: size_t_ctype.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
The file "lib.c' contains some defines and have some #ifdefery
to detect the data model of the native machine (LP32/LP64).
Same for the native endianness.
Move these into "machine.h" where the platform detection is
already done.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
* fixes for -dD
* add support for -dM
Luc Van Oostenryck (2):
dump-macro: break the loop at TOKEN_UNTAINT
dump-macro: simplify processing of whitespace
Ramsay Jones (5):
pre-process: suppress trailing space when dumping macros
pre-process: print macros containing # and ## correctly
pre-process: don't put spaces in macro parameter list
pre-process: print variable argument macros correctly
pre-process: add the -dM option to dump macro definitions
|
|
Sparse unconditionally issues warnings about non-ANSI function
declarations & definitions.
However, some environments have large amounts of legacy headers
that are pre-ANSI, and can't easily be changed. These generate
a lot of useless warnings.
Fix this by using the options flags -Wstrict-prototypes &
-Wold-style-definition to conditionalize these warnings.
Signed-off-by: John Levon <levon@movementarian.org>
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
In legacy environment, a lot of warnings can be issued about
arguments without an explicit type.
Fix this by contitionalizing such warnings with the flag
-Wimplicit-int, reducing the level of noise in such environment.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
The current -dD option outputs the macro definitions, in addition to the
pre-processed text. In contrast, the -dM option outputs only the macro
definitions.
Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Sparse ignores unknown options but then doesn't know if
they have arguments or not. So, if '-x c' is given as option,
sparse will try to process a file named 'c'.
Fix this by teaching sparse about the option '-x' and its argument.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Sparse knows about the '-o' option, parses it but does
nothing with it.
Change this by redirecting stdout to <file> unless <file>
is '-' since sparse (the lib) outputs to stdout by default.
But ignore this flag when sparse is used purely as an checker
since in this case it's not supposed to output to stdout
and would create undesired empty file, possibly erasing the
result of the compiler if one is used before sparse.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Currently, when used on the kernel, sparse issues a bunch
of warnings like:
warning: constant 0x100000000 is so big it is long
These warning are issued when there is a discrepancy
between the type as indicated by the suffix (or the absence
of a suffix) and the real type as selected by the type
suffix *and* the value of the constant.
Since there is nothing incorrect with this discrepancy,
(no bits are lost) these warnings are more annoying than useful.
So, make them depending on a new warning flag -Wconstant-suffix
and make it off by default.
Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
* fix linearization/SSA when missing a return
* fix linearization/SSA of (nested) logical expressions
|
|
If linearize_symbol() is called, it's meaningless to disable
linearization. As such, linearization was not really considered
as a pass. More exactly, there is no '-flinearize...' flag since
-flinearize-enable & -flinearize-disable are both meaningless.
However, -flinearize=last can be very useful for testing. So,
recognize 'linearize' as a pass and leave -flinearize-{en,dis}able
without effect.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
sparse issues a warning when user pointers are casted to integer
types except to unsigned longs which are explicitly allowed.
However it may happen that we would like to also be warned
on casts to unsigned long.
Fix this by adding a new warning flag: -Wcast-from-as (to mirrors
-Wcast-to-as) which extends -Waddress-space to all casts that
remove an address space attribute (without using __force).
References: https://lore.kernel.org/lkml/20180628102741.vk6vphfinlj3lvhv@armageddon.cambridge.arm.com/
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Sparse has support for a subset of GCC's large collection of
attributes. It's not easy to know which versions support this
or that attribute. However, since GCC5 there is a good solution
to this problem: the magic macro __has_attribute(<name>)
which evaluates to 1 if <name> is an attribute known to the
compiler and 0 otherwise.
Add support for this __has_attribute() macro by extending the
already existing support for __has_builtin().
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
* do 'classical' SSA conversion (via the iterated dominance frontier).
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
The warnings about negative or over-sized shift count are
enabled by default.
Add the options to disabled them if desired.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
So, it's possible to use the flag '-vdomtree' to dump the
domonance tree.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Just use the flag '-vpostorder' to dump the links once calculated.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
It's relatively common to cast a pointer to an unsigned long,
for example to make some bit operations.
It's much less sensical to cast a pointer to an integer smaller
(or bigger) than a pointer is.
So, emit a diagnostic for this, under the control of a new
warning flag: -Wpointer-to-int-cast.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Currently all casts to pointers are processed alike.
This is simple but rather unconvenient as it correspond to
different operations that obeys to different rules and
which later need extra checks.
Change this by using a specific instructions (OP_UTPTR) for
unsigned integer to pointers.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
This series contains a number of cleanups of the list walking macros.
The main changes are:
* make untagged pointers the normal case
* use structurally equivalent struct for all pointer lists
to avoid needless casting to and fro struct ptrlist
* simplify PREPARE/NEXT/RESET logic by using common PTR_NEXT()
|
|
The name of the function is misleading: it only tests if the
pointer to the list is NULL. But while it's usually enforced
that empty list are NULL (after using PACK_PTR_LIST()), it's
not generally true that empty list are NULL.
Since the macro has a single user anyway, remove the macro
and convert the user to a NULL test since it is the correct
thing to do in this situation.
Note: it used to be that list packing was more enforced that
it is currently and some list can't be packed.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
This series add validation of the IR.
It is a preparatory step before merging the 'classical SSA'.
|
|
Recent versions of GCC predefine macros like __INT_WIDTH__ for
the integer types.
Do the same here since some <limits.h> may depends on it.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
To be meaningful, the IR instructions and their relationships
must obey some constraints. This patch add the framework for
doing this kind of validation.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
As often the case, the declaration of the debug flags were
done in the order they were added.
But after a while this become messy so keep them now alpha-sorted.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
When using sparse it's common to compile a file and directly
run sparse on the same file, like it is done for the kernel.
In this case, error messages from sparse are interspersed with
those from the compiler. It's thus not always easy to know from
which tools they come.
Fix this by allowing to prefix all the diagnostic messages
by some configurable string, by default "sparse". More exactly,
an error message that was emitted like:
file.c:<line>:<col>: error: this is invalid code
can now be emitted as:
file.c:<line>:<col>: sparse: error: this is invalid code
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Reviewed-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
|
|
Since add_ptr_list_notag() is now simply a define to add_ptr_list()
it's not anymore really needed and can be removed.
Remove add_ptr_list_notag()'s definition and replace its only call
by a call to add_ptr_list().
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
The boot part of the kernel on x86-64 has to compile code for
real-mode. This is 32bit code and is specified to GCC with '-m16'.
However, sparse hadn't knwoledge of this flag and thus uses the
default LP64 model for it which, of course, can cause false
warnings because of the mismatched sizes.
Fix this by teaching sparse about the -m16 flag by treating it
the same as -m32.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
This will merge the following topic branches:
* builtin-dyn:
Expansion of macros like __FILE__, __DATE__, ... must, contrary
to usual macros, be done dynamically.
This series improves support for them:
- consider them as defined (like GCC do)
- use table + method for their expansion (avoid useless compares)
- add support for __INCLUDE_LEVEL__ & __BASE_FILE__
* builtin-predef:
Add a function: predefine() which allow to directly add
the definition of a simple macro (without args and with
a single number or ident as definition).
Also do the conversion of the concerned predefined macros
and some cleanups.
* builtin-overflow:
Add support for builtins doing overflow checking.
* has-builtin:
Add support for the __has_builtin() macro.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
declare_builtin_functions() contained only the declaration of 3
(Blackfin specific) builtin functions.
Move these to declare_builtins() where all other builtins are declared.
Note: these builtin are were declared on the condition that '__bfin__'
was defined and now are unconditionally declared. It's fine,
the builtins for alpha are also always declared here.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
The builtin functions were first declared, then the builtin stream
created and only then the builtin macros were predefined.
But this is essentially the wrong (logical) order.
Change the calling order so:
- first predefine the builtins macros
- create the builtin stream
- declare the builtin functions
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Move all predefined macros to ... predefined_macros()
Neater so, isn't it?
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Use the newly created predefine() to define the builtin macros.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Sparse has support for a subset of GCC's large collection of builtin
functions. As for GCC, it's not easy to know which builtins are
supported in which versions.
clang has a good solution to this problem: it adds the checking macro
__has_builtin(<name>) which evaluates to 1 if <name> is a builtin
function supported by the compiler and 0 otherwise.
It can be used like:
#if __has_builtin(__builtin_clz)
#define clz(x) __builtin_clz(x)
#else
...
#endif
It's possible or probable that GCC will have this soon too:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66970
Add support for this __has_builtin() macro by extending
the evaluation of preprocessor expressions very much like
it is done to support defined().
Note: Some function-like builtin features, like __builtin_offset(), are
considered as a kind of keyword/operator and processed as such.
These are *not* considered as builtins by __has_builtin().
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
There was some support for it but it was just a define
that expanded to the fixed name "base_file.c".
Implement the real thing by saving the input filename
and replacing __BASE_FILE__ by it.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Parsing error triggered by expect() insert bad_token as the
current token. This allows to skip other errors with expect().
So far so good but this token is a fake token which has no
position set, if another parsing error is detected by something
else than expect(), the error message will use the position of
this bad token which will be displayed like:
builtin:0:0: ...
which is confusing.
Since the concerned error message are secondary ones, the primary
one have been already be repported by expect(), the best is to
simply skip all these secondary error messages.
Do this by creating a new token type (TOKEN_BAD) and use it for
bad_token, then filter error messages based on this token type.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Most parsing errors are reported during parsing itself but
sometimes some extra conditions must be checked.
One problem with this is that these extra conditions are not
met because they are the consequence of a primary error which
has already been reported. In this case, it this not desirable
to emit a new error message.
To help with this, add a small function which will emit an
error message followed by the current token but only if the
current token does not originated from a previous parsing error.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
|
|
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
|
|
with help from Linus (many moons ago) and Luc this year.
sparse addition to print all compound/composite global data symbols
with their sizes and alignment.
usage: -vcompound
Example:
$ sparse -vcompound symbol-sizes.c
compound-sizes.c:39:17: union un static [toplevel] un: compound size 192, alignment 8
compound-sizes.c:42:25: struct inventory static [toplevel] inven[100]: compound size 19200, alignment 8
compound-sizes.c:51:33: struct inventory static [toplevel] [usertype] invent[10]: compound size 1920, alignment 8
compound-sizes.c:58:25: float static [toplevel] floats[42]: compound size 168, alignment 4
compound-sizes.c:59:25: double static [toplevel] doubles[84]: compound size 672, alignment 8
and validation:
$ ./test-suite single compound-sizes.c
TEST compound-sizes (compound-sizes.c)
compound-sizes.c passed !
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Since both __x86_64__ and __x86_64 are valid use both of them to
detect the x86-64 arch and define them both when built on x86-64.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Acked-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
|
|
Currently, we have the -m32 & -m64 flags to force sparse to
behave as a 32 or 64 bit arch, independently of the arch used
to build sparse. Good.
However, on x86-64, '-m32' is there to force the 32 bit instructions
& ABI but there is another flag '-mx32' for the x32 ABI which use the
x86-64 instructions / 64 bit registers but where the pointers and
long ints are 32 bit.
Add the same flag, '-mx32', to support this ABI with the proper size
alignment for pointers and longs and to predefine __ILP32__ as it is
done by 'GCC -mx32'.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Acked-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
|
|
This will just to use the automatic numbering of enums
which slightly simplify patches adding new entries.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Acked-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
|
|
On LLP64 platforms, ointers & long long are 8 bytes width
*and* also aligned to 8 bytes.
However, the alignment was set to only 4 bytes.
Fix this by setting max_in_alignment to 8 for LLP64 too.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Currently sparse assumes LP64 only for x86-64.
This requires to always use the flag '-m64' for the other
64 bit archs like arm64 or ppc64.
There is also another problem on machines using the x32 ABI on
x86_64, which is, of course, not LP64.
So, change this by using LP64 by default if __LP64__ is defined
on the build machine. This will solve the current problem with
x32 but will also give the correct default on all 64 bit archs.
Reported-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Recent changes to the min()/max() macros in include/linux/kernel.h
have added a lot of noise when compiling the kernel with Sparse checking
enabled. This mostly is due to the *huge* increase in the number of
sizeof(void) warnings, a larger number of which can safely be ignored.
Add the -Wpointer-arith flag to enable/disable these warnings (along
with the warning when applying sizeof to function types as well as
warning about pointer arithmetic on these types exactly like the
GCC -Wpointer-arith flag) on demand; the warning itself has been disabled
by default to reduce the large influx of noise which was inadvertently
added by commit 3c8ba0d61d04ced9f8 (kernel.h: Retain constant expression
output for max()/min()).
Update the manpage to document the new flag and add a validation case
for sizeof(void).
CC: Kees Cook <keescook@chromium.org>
CC: Linus Torvalds <torvalds@linux-foundation.org>
CC: Martin Uecker <Martin.Uecker@med.uni-goettingen.de>
CC: Al Viro <viro@ZenIV.linux.org.uk>
CC: Christopher Li <sparse@chrisli.org>
CC: Joey Pabalinas <joeypabalinas@gmail.com>
CC: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Signed-off-by: Joey Pabalinas <joeypabalinas@gmail.com>
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
So that this action name can be used for a function.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Currently, (most) builtin functions are declared like
normal function prototypes. Furthermore, these declarations
are done via the pre-buffer mechanism and thus need to be
tokenized & parsed like normal code.
This is far from being 'builtin' and involves unnneded
processing.
Change this by skipping this pre-buffer phase and directly creating
the appropriate symbol for them.
Note: the correct mechanism to be used to make them really builtin
is via init_builtins(), used when we have a real semantic
action for the builtin.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
These builtins are defined by gcc since 4.4. They are also now
used by the isinf, isfinite and isnan macros. So using them with a
newer gcc causes 'undefined identifier' errors.
Add the builtin definitions and some validation checks for these
functions.
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Generally, we're not interested by those warnings, but we
can always explicitly ask for them if needed.
So make the flag '-Wunknown-attribute' off by default.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
When handling "-Wsparse-all" in handle_onoff_switch(), once all
warning flags have been set, the function can return instead of
checking for "no-" or other option names because they won't be
found. Just return NULL, which is what happens when handling
"-Wsparse-all" anyway.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
These functions are clearly meant to be used locally.
Furthermore, some have no prototypes.
Make these functions static and remove the prototype
when one was present.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
'testcase-fix-missing-return', 'type-as-first-class', 'llvm-zero-init' and 'llvm-prototype' into tip
|
|
Currently, sparse stops to emit warnings after the 100th.
This is, of course, to avoid to throw lots of warnings if the
source file has lots of problems but sometimes we want to see
all warnings & errors.
For example, it's useful when testing a new version of
sparse on the kernel since it has a few files with more
than 100 warnings (and so a bad change will be undetected
if it affects warnings only after the 100th).
Let parse the '-fmax-warnings=N' option and limit the
number of warnings accordingly.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Till now, sparse's plain chars where signed with no possibility
to change it. This is a problem when using sparse on code
for architectures like ARM where chars are by default unsigned
or simply for code compiled with GCC's '-f[no-][un]signed-char'.
Change this by parsing these options and adjusting the type
of plain chars accordingly.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Some flags, for good or less good reasons, exist under two
different names: like a positive version and a negative one.
This is in addition of the 'no-' prefix.
The use case here is '-f[no-][un]signed-char'.
Make it easy and allow to specify that a given flag is the
negative version of another one so that '-fsigned-char' is
handled exactly as '-fno-unsigned-char'.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
GCC's manual or POSIX say about the '-D' option something like:
'−D name[=value]' should be treated as if in directive
'#define name value' (with '1' as default for the value),
including its tokenization.
So an option like '-DM(X, Y)=...' should be processed like a
directive '#define M(X, Y) ...'.
However, the current code treat a space as a separator between
the macro and its definition, just like the '='. As consequence,
the above option is processed like the directive would be
'#define M(X, Y)=...', with 'M(X,' as the macro (name) and
'Y)=...' as its definition.
Fix this by stopping to treat the space character specially,
thus only using '=' as the separator.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Till now, sparse was unneedlessly strict in what it accepted in
'-D' options. More specifically, it doesn't accept:
1) separated '-D' and the macro definition, like:
sparse -D MACRO[=definition] ...
2) a space between the '-D' and the macro name, like:
sparse '-D MACRO[=definition] ...
Case 1) is clearly accepted by GCC, clang and should be
accepted for a POSIX's c99. Case 2's status is less clear
but is also accepted by GCC and clang (leaving any validation
to the corresponding internal #define).
Fix this by accepting separated command line argument for '-D'
and the macro (and removing the check that rejected the macro
part if it started with a space).
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
|
|
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
as it will be used for dumping the IR not only just after
linearization but after other passes too.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
'fix-volatile-simplification', 'struct-asm-ops', 'restricted-pointers', 'fix-f2i-casts', 'symaddr-description', 'flush-stdout' and 'diet-simple' into tip
|
|
This is much needed for tools like test-linearize
which output on stderr & stdout and without this patch
error messages and normal output are out-of-sync.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Symbols declared or defined in files directly or indirectly
given in the command line and thus processed via sparse()
are always automatically evaluated.
Symbols processed via sparse_initialize(), thus the predefined
ones, are not systematically evaluated, which is normaly fine
as they are just declarations and will be evaluated when needed.
However, if the command line include a file via '-include <file>',
the symbols of this file will also not be evaluated, which is still
fine as long as it's only definitions. But, in the rare and odd cases
where the file should contains a function definition, this function
will not be evaluated and it's expansion and linearization won't happen
as it should have.
Fix this by evaluating the symbols issued from sparse_intialize()
like it is done for sparse().
Reported-by: Jason A. Donenfeld <Jason@zx2c4.com>
Tested-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Currently, the parsing of options is often quite ad-hoc and thus:
- need a lot of code
- is not clear at all
Improve this by making this table driven.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Until now, match_option() needed a non-const argment and returned
a non-const result. Since it is no more needed, let's use const.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
For some options with a numerical value, it is sometimes desirable,
when the value is used to limits something, to easily specify we
want to remove any limits.
This patch allow to use 'unlimited' for this by interpreting it as
the maximum value.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
For some options with a numerical value, it is sometimes desirable,
to easily specify we want the maximum possible value.
This patch allow to interpret '=0' as meaning the maximum value.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
This was used to handle a single flag but we need something
more compact when we need to handle several flags.
So, adapt this helper so that it now takes an array of flags
instead of a single flag.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
'struct warning' can be reused for flags other than warnings.
To avoid future confusion, rename it to something more general:
'struct flag' (which in its context, handling of compiler flags,
is clear enough).
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
The goal of this helper is:
- to avoid to have to hardoce the length od the substring
- separate the suffix/option part from the whole argument
which help for error message.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
|
|
The 'selfcheck' make target issues sparse errors for function symbols
'error_die' and 'die', like so:
CHECK lib.c
lib.c:194:6: error: symbol 'error_die' redeclared with different type \
(originally declared at lib.h:98) - different modifiers
lib.c:203:6: error: symbol 'die' redeclared with different type \
(originally declared at lib.h:94) - different modifiers
This is caused by the 'noreturn' attribute being treated similar to a
type qualifier and insisting that, not only the declaration and the
definition of the function have the 'noreturn', but that they have the
attribute in the same position.
In order to suppress the error, move the attribute(s) to the beginning
of the declaration, in the header file, and add an 'noreturn' attribute
at the beginning of the definition (in lib.c).
Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
Signed-off-by: Christopher Li <sparse@chrisli.org>
|
|
This will make the selfcheck target reduce a lot of error on
test-inspect.c. The gtk header file use _Pragma().
Signed-off-by: Christopher Li <sparse@chrisli.org>
|
|
Some macros, structures definitions, ... are endianness specific.
This is generaly done with the help of some header files but these
headers often need information from the compiler via the macro
__BYTE_ORDER__, itself being defined to __ORDER_BIG_ENDIAN__ or
__ORDER_LITTLE_ENDIAN__.
Without these defines, sparse's pre-processor may interpret things
differently than the compiler would do which may hide errors or
warn on code that is compiled out.
Fix this by letting sparse predefine these macros like compilers do.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Acked-by: Christopher Li <sparse@chrisli.org>
|
|
Some macros, structures definitions, ... are endianness specific.
This is generaly done with the help of some header files but these
headers often need information from the compiler via the macros
__BIG_ENDIAN__ / __LITTLE_ENDIAN__.
Without these defines, sparse's pre-processor may interpret things
differently than the compiler would do which may hide errors or
warn on code that is compiled out.
Fix this by letting sparse predefine these macros like compilers do.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Acked-by: Christopher Li <sparse@chrisli.org>
|
|
Some macros, structures definitions, ... are endianness specific.
This is generaly done with the help of some header files but these
headers often need information from the compiler which then need
to be endian-aware.
In order to not interpret things differently than the compiler
would, sparse thus also need to be endian-aware, even more so
given that sparse must cover all archs and their variants.
Give this information to sparse with two flags:
-mbig-endian/-mlittle-endian, and by default use
the endianness of the platform used to compile sparse.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Acked-by: Christopher Li <sparse@chrisli.org>
|
|
By default, sparse will warn if memcpy() (or memset(),
copy_from_user(), copy_to_user()) is called with a very large
static byte-count.
But the limit is currently fixed at 100000, which may be fine
for some uses but not for others. For example, this value is
too low for sparse to be used on the git tree where, for example,
some array used to sort the index is cleared with memset().
Change this by making the limit configurable via a new flag:
-fmemcpy-max-count.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
sparse will warn if memcpy() (or memset(), copy_from_user(),
copy_to_user()) is called with a very large static byte-count.
But this warning is given unconditionaly while there are projects
where this warning may not be not desired.
Change this by making this warning conditional on a new warning
flag: -W[no-]memcpy-max-count
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
'implicit-int', 'cgcc-darwin' and 'more-builtin-decls' into rc2
|
|
Those are used by GCC testsuite.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Currently, once an error is issued, warnings are no more
issued, only others errors are.
It make sense as once an error is encountered things can
be left in an incoherent state and could cause lots of
useless warnings because of this incoherence.
However, it's also quite annoying as even unrelated warnings
are so silenced and potential bugs stay thus hidden.
Fix this by:
- use a specific flag for this: 'has_error'
- make the distinction between the current phase and some previous
phases (but for now we only care about parsing vs evaluation)
- if an error has been issued in a previous phase (at parsing)
warnings are suppressed for the current phase and all future
phases
- if an error is issued in the current phase (evaluation) the
flag is reset after each functions/symbols
For example, with this patch, a typing error in function fa()
will not suppress warnings for function fb(), while a parsing
error will still inhibit all further warnings.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
'fix-missing-reload', 'fix-insert-branch', 'fix-NULL-type', 'testsuite-clean', 'fix-bitfield-init-v3' and 'fdump-linearize' into tip
* fix missing reload
* fix boolean context for OP_AND_BOOL & OP_OR_BOOL
* fix bitfields implicit zero initializer.
* fix: kill old branch in insert_branch()
* returns the correct type when evaluating NULL
* use internal size for __INT_MAX__ & friends
* testsuite: cleanup result files
* add support for '-fdump-linearize[=only]'
* add support for '-fmem-report'
* add support for '-dD'
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
The predefined macros __SCHAR_MAX__, __SHRT_MAX__, __WCHAR_MAX__ &
__CHAR_BIT__ are defined based on the size of these types on
the machine where sparse was compiled.
But since sparse has flags like -m32/-m64 and it's not unlikely
to have one day a flag like -march=<some arch>, better to use
the used by sparse for these types as stored in 'bits_in_char',
'bits_in_short', ...
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Since commit 4fae9be00 & 5466cf8f3 ("predefine __INT_MAX__ and friends" &
"predefine __SIZEOF_INT__ & friends"), macros like __INT_MAX__ and
__SIZEOF_POINTER__ are predefine twice.
Fix this by removing the old definition, based on the size of these
types on the machine where sparse was compiled.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
The effect of this flag is to dump the IR just after the
linearization, before any simplification, and to stop
further processing if '=only' is given as argument.
The motivation of this flag is of course for debugging,
to be able to inspect the raw result of the linearization,
undisturbed by an simplification.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
'sent/fix-cond-address' and 'careful-concat-user-list' into tip
|
|
Initializers of static storage duration objects shall be constant
expressions [6.7.8(4)].
Warn if that requirement is not met and the -Wstatic-initializer-not-const
flag has been given on sparse's command line.
Identify static storage duration objects by having either of
MOD_TOPLEVEL or MOD_STATIC set.
Check an initializer's constness at the lowest possible subobject
level, i.e. at the level of the "assignment-expression" production
in [6.7.8].
Signed-off-by: Nicolai Stange <nicstange@gmail.com>
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Some tests or some code depends on these macros being predefined
by the compiler.
Predefine them.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
Some tests or some code depends on these macros being predefined
by the compiler.
Predefine them.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
This is used by GCC to report suspicious use of addresses.
So, reuse the same name for same or similar use.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
|
|
After parsing and validation, the symbols in the declaration
are added to the list given in argument, *if* they are not extern
symbols. The symbols that are extern are them not added to the list.
This is what is needed for usual declarations but ignoring extern
symbols make it impossible to emit a diagnostic in less usual
situation.
This is motivated by the validation of variable declaration inside
a for-loop initializer, which is valid in C99 but only for variable
with local storage.
The change consists in adding to external_declaration() an optional
callback 'validate_decl()' which, if present (non-null), is called
just before adding the declaration to the list.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Signed-off-by: Christopher Li <sparse@chrisli.org>
|
|
When an array is initialized, it may be convenient to first
initialize all entries with some default value via the
'[a ... b]' notation and then override some of these entries
with a non-default value. Unfortunately, this, of course,
is not compatible with the default warning flag '-Woverride-init'.
Fix this by introducing an exception to the usual detection
of overlapping initializers which, only for what concerns this
warning, ignore an '[a ... b]' entry if:
- it is the first one
- it covers the whole range of the array.
If needed, the previous ehaviour can be restored by using a new
warning flag, disabled by default: '-Woverride-init-whole-range'.
Suggested-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Signed-off-by: Christopher Li <sparse@chrisli.org>
|
|
By default, sparse only warns on the first overlapping initialier.
While this may be sensible for most situation, it's not always wanted
to hide those others errors. This is especially annoying when testing.
Change this by introducing a new warning flag '-Woverride-init-all',
disabled by default and whose intented use is sparse's testsuite.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Signed-off-by: Christopher Li <sparse@chrisli.org>
|
|
Sparse warns unconditionally about overlapping initilalizers.
Introduces a warning flag to control this, use the same name
as GCC's and enabled it by default.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Signed-off-by: Christopher Li <sparse@chrisli.org>
|
|
The flag -Wbitwise have no effect since patch 02a886bfa
("Introduce keyword driven attribute parsing"): the corresponding
checks are now always done.
Fix that by reintroducing it in the same way as it was:
ignore the bitwise attribute if the flag is not set.
It's less invasive that checking the flag at each place
an corresponding warning is emitted.
Also, to not perturb the current situation the flag is now
enabled by default.
Reported-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Signed-off-by: Christopher Li <sparse@chrisli.org>
|
|
Things are greatly simplified now that such builtins can have a
prototype: the args and result are already evaluated, the
arguments number and their type are already checked, etc.
Based-on-patch-by: Christopher Li <sparse@chrisli.org>
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Signed-off-by: Christopher Li <sparse@chrisli.org>
|
|
There was recently on the mailing list some questions
and a need to support LLP64 model.
This patch add is by adjusting a few size-related variables
under the control of a new flag: -msize-llp64 (ugly name
but we already have we have '-msize-long').
CC: Dibyendu Majumdar <mobile@majumdar.org.uk>
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Signed-off-by: Christopher Li <sparse@chrisli.org>
|
|
Now that we optimize away expressions like 'x == x' or 'x < x',
also add a warning for it (but disabled by default).
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Signed-off-by: Christopher Li <sparse@chrisli.org>
|
