Fix handling of __func__

It's not a string literal, it's a static array

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Fix tab handling in nextchar_slow()

... and streamline it a bit more, now that we get all \t hitting
the damn thing.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Fix ,##__VA_ARGS__ kludge

a) it actually allows any number of ##<arg>##... in between, as long as all
those args are empty.
b) it does *not* allow ## after __VA_ARGS__ - if it's there magic disappears

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
sparse, llvm: Fix SIGSEGV for extern symbols

Jonathan Neuschäfer writes:

  compiling a little real-world program with sparse-llvm, it segfaulted.
  Using a tool called "delta"[1] and some bash scripting, I managed to
  reduce the code to this test case:

    extern struct foo *foop;
    extern void func(struct foo *f);
    int main(int argc, char **argv) {
        func(foop);
    }

The problem is that pseudo_to_value() does not know abou the extern
symbol because Sparse never calls output_data() on it which registers
globals with LLVMAddGlobal().

As explained by Linus, 'extern' symbols are just names with types. They
don't have any value associated with them, they just have the type and
the name. Therefore we need to explicitly call LLVMAddGlobal() for
symbols we have not encountered in pseudo_to_value().

Reported by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Cc: Christopher Li <sparse@chrisli.org>
Cc: Jeff Garzik <jgarzik@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
sparse, llvm: 'Verify' the LLVM module before writing it

In later versions sparse-llvm should stop on wrong llvm code, instead
of outputting it, but for now there are too many warnings being produced
for this to be feasible (I think).

Cc: Pekka Enberg <penberg@kernel.org>
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
sparse, llvm: Fix 'void' return type code generation

Jonathan Neuschäfer reports:

  A simple function like this will compile to the following llvm
  bitcode:

        /* C */
        void func(void) {
                return;
        }

        /* LLVM */
        define i8 @func() {
        L0:
          ret void
        }

  The return type of the function and the type in the return instruction
  don't match.

  I found this inconsistency by running LLVM's bitcode validation on the
  bitcode produced by sparse-llvm.

Move 'void *' special-casing from sym_basetype_type() to sym_ptr_type()
to fix the issue.

Reported by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Cc: Christopher Li <sparse@chrisli.org>
Cc: Jeff Garzik <jgarzik@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
sparse, llvm: convert the condition of branch/select to bool

LLVM expects the first argument of "br" and "select" to be of type i1,
so add an "icmp ne <srcty> %src, 0" for other types.

Cc: Christopher Li <sparse@chrisli.org>
Cc: Jeff Garzik <jgarzik@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
sparse, llvm: Fix type of loaded values

Instead of making the computed address a pointer to an int type
large enough to hold a pointer, make it a pointer to the memory
object being loaded.  This fixes another LLVM warning.

Cc: Pekka Enberg <penberg@kernel.org>
Cc: Christopher Li <sparse@chrisli.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Acked-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Merge branch 'llvm/core' of github.com:penberg/sparse-llvm

Please pull the latest Sparse/LLVM tree from:

  git@github.com:penberg/sparse-llvm.git llvm/core

It contains few LLVM backend fixes from myself and Jonathan Neuschäfer.
Fix wrong array size expression

Signed-off-by: Mauro Dreissig <mukadr@gmail.com>
Signed-off-by: Christopher Li <sparse@chrisli.org>
remove weak define x86_64

This fix the regression report by Dan Carpenter. "x96_64" can be
a valid variable name.

Signed-off-by: Christopher Li <sparse@chrisli.org>
Gentler handling of bitwise warnings in unary operations

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
simplify handling of newline/whitespace flags in expand()

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
fix handling of -include

-include foo.h will search not only in the current directory...

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
massage handling of wide string literals/character constants in tokenizer

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
switch to delayed handling of escape sequences

	#define A(x) #x
	A('\12')

should *not* yield "'\\n'"; the problem is that we are doing the conversion
too early.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
L ## 'a' is valid; so's L ## "a"

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Merge git://git.kernel.org/pub/scm/linux/kernel/git/viro/sparse into marge

Pull preprocessor fix from Al Viro.

1) we really, really shouldn't convert escape sequences too early;
   #define A(x) #x
   A('\12')
   should yield "'\\12'", *not* "'\\n'".

2) literal merging handles all sequences of string/wide string
   literals; result is wide if any of them is wide.  string_expression() is
   handling that wrong - "ab"L"c" is L"abc"

3) with support (no matter how cursory) of wide char constants
   and wide string literals, we really ought to handle
    #define A(x,y)
    A(L,'a')
   properly; it's not that tricky - combine() needs to recognize <IDENT["L"],CHAR>
   and <IDENT["L"],STRING> pairs.

4) '\777' is an error, while L'\777' is valid - the value should fit
   into unsigned char or unsigned counterpart of wchar_t.  Note that for string
   literals this happens *after* phase 6 - what matters is the type of literal
   after joining the adjacent ones (see (2) above).

5) stringifying should only quote \ and " in character constants and
   string literals,
    #define A(x) #x
    A(\n)
   should produce "\n", not "\\n"

6) we are losing L when stringifying wide string literals; that's
   wrong.

I've patches hopefully fixing the above.  Basically, I delay interpreting
escape sequences (past the bare minimum needed to find where the token ends)
until we are handling an expression with character constant or string literal
in it.

For character constants I'm keeping the token body in token->embedded -
4-character array replacing token->character.  That covers practically
all realistic instances; character constant *may* be longer than that,
but it has to be something like '\x000000000000000000000000041' - sure,
that's 100% legitimate C and it's going to be the same as '\x41' on
everything, but when was the last time you've seen something like that?
So I've split TOKEN_CHAR into 5 values - TOKEN_CHAR+1--TOKEN_CHAR+4 meaning
1--4 characters kept in ->embedded[], TOKEN_CHAR itself used for extremely
rare cases longer than that (token->string holds the body in that case).
TOKEN_WIDE_CHAR got the same treatment.

AFAICS, with those fixes we get the same behaviour as in gcc for
silently ignored by cpp if the string/char constant doesn't make it
out of preprocessor.  sparse still warns about those.  The situation
with this one is frustrating; on one hand C99 is saying that e.g.
'\x' is not a token.  Moreover, in a footnote in 6.4.4.4 it flat-out
requires diagnostics for such.  On the other hand... footnotes are
informative-only and having "other character" token match ' would
puts us in nasal daemon country, so gcc is free to do whatever it feels
like doing.  I think we shouldn't play that kind of standard-lawyering
*and* sparse has always warned on that, so I've left that warning
in place.

Note that real wchar_t handling is still not there; at the very least,
we need to decide what type will be used for that sucker (for gcc it's
int on all targets we care about), fix the handling of wide string literals
in initializers and evaluate_string() and stop dropping upper bits in
get_string_constant().  That would probably mean not using struct string
for wide ones, as well...  Hell knows; I don't want to touch that right
now.  If anything, I'd rather wait until we get to C11 support - they've
got much saner variants of wide strings there (char16_t/char32_t with
u and U as token prefix as L is used for wchar_t; there's also u8"..." for
UTF8 strings).
sparse: add built-in byte swap identifiers

this patch stops sparse from complaining about them not being
defined:

include/uapi/linux/swab.h:60:16: error: undefined identifier '__builtin_bswap32'
include/uapi/linux/swab.h:60:33: error: not a function <noident>

Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Signed-off-by: Christopher Li <sparse@chrisli.org>
sparse patch v2: add noclone as an ignored attribute

Add attribute "noclone" or "__noclone" or "__noclone__" as an
ignored attribute. Fixes this sparse warning:

arch/x86/kvm/vmx.c:6268:13: error: attribute '__noclone__': unknown attribute

Also add test case for 'noclone': validation/attr-noclone.c.
'make check' says for this test case:
     TEST     attribute noclone (attr-noclone.c)

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Christopher Li <sparse@chrisli.org>