* sparse handles int64_t type wrong
@ 2006-12-12 19:34 Yura Pakhuchiy
2006-12-12 19:44 ` Linus Torvalds
0 siblings, 1 reply; 10+ messages in thread
From: Yura Pakhuchiy @ 2006-12-12 19:34 UTC (permalink / raw)
To: Linus Torvalds, Josh Triplett; +Cc: linux-sparse
[-- Attachment #1: Type: text/plain, Size: 337 bytes --]
Hi,
sparse 0.2 produces following errors on attached code:
a.c:15:7: warning: incorrect type in argument 1 (different type sizes)
a.c:15:7: expected int [long] [usertype] *baz
a.c:15:7: got int *<noident>
a.c:13:10: warning: shift too big (32) for type int
However I believe it should not. Please fix!
--
Thanks,
Yura
[-- Attachment #2: a.c --]
[-- Type: text/x-csrc, Size: 161 bytes --]
#include <sys/types.h>
typedef int64_t s64;
void foo(s64 *baz)
{
}
int main(int argc, char *argv[])
{
s64 bar;
if (bar >> 32)
;
foo(&bar);
return 0;
}
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: sparse handles int64_t type wrong
2006-12-12 19:34 sparse handles int64_t type wrong Yura Pakhuchiy
@ 2006-12-12 19:44 ` Linus Torvalds
2006-12-12 19:50 ` Yura Pakhuchiy
2006-12-12 20:02 ` Linus Torvalds
0 siblings, 2 replies; 10+ messages in thread
From: Linus Torvalds @ 2006-12-12 19:44 UTC (permalink / raw)
To: Yura Pakhuchiy; +Cc: Josh Triplett, linux-sparse
On Tue, 12 Dec 2006, Yura Pakhuchiy wrote:
>
> sparse 0.2 produces following errors on attached code:
> a.c:15:7: warning: incorrect type in argument 1 (different type sizes)
> a.c:15:7: expected int [long] [usertype] *baz
> a.c:15:7: got int *<noident>
> a.c:13:10: warning: shift too big (32) for type int
>
> However I believe it should not. Please fix!
Did you use "-m64" if you are doing this on an architecture with 64-bit
/usr/include?
Linus
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: sparse handles int64_t type wrong
2006-12-12 19:44 ` Linus Torvalds
@ 2006-12-12 19:50 ` Yura Pakhuchiy
2006-12-12 20:02 ` Linus Torvalds
1 sibling, 0 replies; 10+ messages in thread
From: Yura Pakhuchiy @ 2006-12-12 19:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Josh Triplett, linux-sparse
On Tue, 12 Dec 2006 at 11:44 -0800, Linus Torvalds wrote:
>
> On Tue, 12 Dec 2006, Yura Pakhuchiy wrote:
> >
> > sparse 0.2 produces following errors on attached code:
> > a.c:15:7: warning: incorrect type in argument 1 (different type sizes)
> > a.c:15:7: expected int [long] [usertype] *baz
> > a.c:15:7: got int *<noident>
> > a.c:13:10: warning: shift too big (32) for type int
> >
> > However I believe it should not. Please fix!
>
> Did you use "-m64" if you are doing this on an architecture with 64-bit
> /usr/include?
I use 32bit machine. But I tried to append -m64 anyway and this does not
helps.
--
Best regards,
Yura
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: sparse handles int64_t type wrong
2006-12-12 19:44 ` Linus Torvalds
2006-12-12 19:50 ` Yura Pakhuchiy
@ 2006-12-12 20:02 ` Linus Torvalds
2006-12-12 20:25 ` Yura Pakhuchiy
2006-12-13 5:18 ` [PATCH][RFC] " Christopher Li
1 sibling, 2 replies; 10+ messages in thread
From: Linus Torvalds @ 2006-12-12 20:02 UTC (permalink / raw)
To: Yura Pakhuchiy; +Cc: Josh Triplett, linux-sparse
On Tue, 12 Dec 2006, Linus Torvalds wrote:
>
> Did you use "-m64" if you are doing this on an architecture with 64-bit
> /usr/include?
Never mind, that's not it.
The problem is that the standard headers use _this_ for "int64_t":
typedef int int64_t __attribute__ ((__mode__ (__DI__)));
and sparse just says "ok, int64_t is an 'int'"
The "__attribute__((__mode__()))" thing has always been a quick hack -
sparse actually tries to parse it, but not very well.
If you use
typedef long long s64;
sparse gets it right.
In fact, sparse even gets it right if you do
typedef int __attribute__((__mode__(__DI__))) int64_t;
because then the attribute gets attached to the underlying type, before it
gets bound to the typedef.
I'll take a look if I can fix typedef to accept the crapola __attibute__
syntax.
Putting the attributes at the end really _does_ suck. It's as if you were
to write
typedef void * const_ptr_t const;
and that obviously isn't supposed to work. Why gcc thinks attributes can
go at the end will never be clear to me.
Gcc attributes suck. Some gcc extensions really were thought out really
really badly.
Linus
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: sparse handles int64_t type wrong
2006-12-12 20:02 ` Linus Torvalds
@ 2006-12-12 20:25 ` Yura Pakhuchiy
2006-12-13 5:18 ` [PATCH][RFC] " Christopher Li
1 sibling, 0 replies; 10+ messages in thread
From: Yura Pakhuchiy @ 2006-12-12 20:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Josh Triplett, linux-sparse
On Tue, 12 Dec 2006 at 12:02 -0800, Linus Torvalds wrote:
> On Tue, 12 Dec 2006, Linus Torvalds wrote:
> >
> > Did you use "-m64" if you are doing this on an architecture with 64-bit
> > /usr/include?
>
> Never mind, that's not it.
>
> The problem is that the standard headers use _this_ for "int64_t":
>
> typedef int int64_t __attribute__ ((__mode__ (__DI__)));
>
> and sparse just says "ok, int64_t is an 'int'"
>
> The "__attribute__((__mode__()))" thing has always been a quick hack -
> sparse actually tries to parse it, but not very well.
>
> If you use
>
> typedef long long s64;
>
> sparse gets it right.
>
> In fact, sparse even gets it right if you do
>
> typedef int __attribute__((__mode__(__DI__))) int64_t;
>
> because then the attribute gets attached to the underlying type, before it
> gets bound to the typedef.
Great! This works for me. So I will probably use
#ifdef __CHECKER__
typedef int __attribute__((__mode__(__DI__))) int64_t;
#endif
until it will be fixed in sparse.
> I'll take a look if I can fix typedef to accept the crapola __attibute__
> syntax.
>
> Putting the attributes at the end really _does_ suck. It's as if you were
> to write
>
> typedef void * const_ptr_t const;
>
> and that obviously isn't supposed to work. Why gcc thinks attributes can
> go at the end will never be clear to me.
>
> Gcc attributes suck. Some gcc extensions really were thought out really
> really badly.
Thanks for quick reply and explanations!
--
Best regards,
Yura
^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH][RFC] Re: sparse handles int64_t type wrong
2006-12-12 20:02 ` Linus Torvalds
2006-12-12 20:25 ` Yura Pakhuchiy
@ 2006-12-13 5:18 ` Christopher Li
2006-12-13 15:36 ` Linus Torvalds
1 sibling, 1 reply; 10+ messages in thread
From: Christopher Li @ 2006-12-13 5:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Yura Pakhuchiy, Josh Triplett, linux-sparse
I took a stab at it. It seems that direct_declarator() does handle
attributes, but it does not change the ctype to the declarator.
It is kind of awkward that the type is already build when it hit
the attribute in the end. It need to go back to overwrite
the already parsed type.
I have this patch seems make the test case happy. I am not sure
this is correct or not.
Chris
Index: sparse/parse.c
===================================================================
--- sparse.orig/parse.c 2006-12-12 21:12:29.000000000 -0800
+++ sparse/parse.c 2006-12-12 21:12:47.000000000 -0800
@@ -837,6 +837,10 @@ static struct token *handle_attributes(s
struct ctype thistype = { 0, };
token = attribute_specifier(token->next, &thistype);
apply_ctype(token->pos, &thistype, ctype);
+ if (is_int_type(ctype->base_type) && ctype->modifiers & MOD_SPECIFIER) {
+ ctype->base_type = ctype_integer(ctype->modifiers);
+ ctype->modifiers &= ~MOD_SPECIFIER;
+ }
continue;
}
if (match_idents(token, &asm_ident, &__asm_ident, &__asm___ident)) {
Index: sparse/show-parse.c
===================================================================
--- sparse.orig/show-parse.c 2006-12-12 21:12:29.000000000 -0800
+++ sparse/show-parse.c 2006-12-12 21:12:47.000000000 -0800
@@ -98,7 +98,7 @@ const char *modifier_string(unsigned lon
const char *res,**ptr, *names[] = {
"auto", "register", "static", "extern",
"const", "volatile", "[signed]", "[unsigned]",
- "[char]", "[short]", "[long]", "[long]",
+ "[char]", "[short]", "[long]", "[long long]",
"[typdef]", "[structof]", "[unionof]", "[enum]",
"[typeof]", "[attribute]", "inline", "[addressable]",
"[nocast]", "[noderef]", "[accessed]", "[toplevel]",
Index: sparse/test-parsing.c
===================================================================
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH][RFC] Re: sparse handles int64_t type wrong
2006-12-13 5:18 ` [PATCH][RFC] " Christopher Li
@ 2006-12-13 15:36 ` Linus Torvalds
2006-12-14 0:13 ` Christopher Li
0 siblings, 1 reply; 10+ messages in thread
From: Linus Torvalds @ 2006-12-13 15:36 UTC (permalink / raw)
To: Christopher Li; +Cc: Yura Pakhuchiy, Josh Triplett, linux-sparse
On Tue, 12 Dec 2006, Christopher Li wrote:
>
> I took a stab at it. It seems that direct_declarator() does handle
> attributes, but it does not change the ctype to the declarator.
> It is kind of awkward that the type is already build when it hit
> the attribute in the end. It need to go back to overwrite
> the already parsed type.
Yes. I actually tried to fix this by moving the type "finalization" part
later, but it got really really nasty.
> I have this patch seems make the test case happy. I am not sure
> this is correct or not.
It looks correct to me, although not wonderfully pretty. But it's simpler
than the "don't do the int/fp type finalization until later" that I
couldn't even get to work (not that I spent a lot of time on it, but
still)
Linus
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH][RFC] Re: sparse handles int64_t type wrong
2006-12-13 15:36 ` Linus Torvalds
@ 2006-12-14 0:13 ` Christopher Li
2006-12-14 0:57 ` Linus Torvalds
0 siblings, 1 reply; 10+ messages in thread
From: Christopher Li @ 2006-12-14 0:13 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Yura Pakhuchiy, Josh Triplett, linux-sparse
On Wed, Dec 13, 2006 at 07:36:20AM -0800, Linus Torvalds wrote:
>
> It looks correct to me, although not wonderfully pretty. But it's simpler
> than the "don't do the int/fp type finalization until later" that I
> couldn't even get to work (not that I spent a lot of time on it, but
> still)
Do you mean some thing like this? I might leave some abstract ctype
in the tree, it is hard to find all all the user of ctype before
it get finalized. It seems work with the test case in my hand.
Chris
Index: sparse/parse.c
===================================================================
--- sparse.orig/parse.c 2006-12-13 16:10:32.000000000 -0800
+++ sparse/parse.c 2006-12-13 16:15:42.000000000 -0800
@@ -70,12 +70,43 @@ struct statement *alloc_statement(struct
static struct token *struct_declaration_list(struct token *token, struct symbol_list **list);
+static int apply_modifiers(struct position pos, struct ctype *ctype)
+{
+ /* Turn the "virtual types" into real types with real sizes etc */
+
+ if (ctype->base_type == &int_type) {
+ ctype->base_type = ctype_integer(ctype->modifiers);
+ ctype->modifiers &= ~MOD_SPECIFIER;
+ } else if (ctype->base_type == &fp_type) {
+ ctype->base_type = ctype_fp(ctype->modifiers);
+ ctype->modifiers &= ~MOD_SPECIFIER;
+ }
+
+ if (ctype->modifiers & MOD_BITWISE) {
+ struct symbol *type;
+ ctype->modifiers &= ~(MOD_BITWISE | MOD_SPECIFIER);
+ if (!is_int_type(ctype->base_type)) {
+ sparse_error(pos, "invalid modifier");
+ return 1;
+ }
+ type = alloc_symbol(pos, SYM_BASETYPE);
+ *type = *ctype->base_type;
+ type->ctype.base_type = ctype->base_type;
+ type->type = SYM_RESTRICT;
+ type->ctype.modifiers &= ~MOD_SPECIFIER;
+ ctype->base_type = type;
+ create_fouled(type);
+ }
+ return 0;
+}
+
static struct symbol * indirect(struct position pos, struct ctype *ctype, int type)
{
struct symbol *sym = alloc_symbol(pos, type);
sym->ctype.base_type = ctype->base_type;
sym->ctype.modifiers = ctype->modifiers & ~MOD_STORAGE;
+ apply_modifiers(pos, &sym->ctype);
ctype->base_type = sym;
ctype->modifiers &= MOD_STORAGE;
@@ -724,7 +755,6 @@ static void check_modifiers(struct posit
modifier_string (wrong));
}
-
static struct token *declaration_specifiers(struct token *next, struct ctype *ctype, int qual)
{
struct token *token;
@@ -778,7 +808,6 @@ static struct token *declaration_specifi
apply_ctype(token->pos, &thistype, ctype);
}
- /* Turn the "virtual types" into real types with real sizes etc */
if (!ctype->base_type) {
struct symbol *base = &incomplete_ctype;
@@ -791,28 +820,6 @@ static struct token *declaration_specifi
base = &int_type;
ctype->base_type = base;
}
- if (ctype->base_type == &int_type) {
- ctype->base_type = ctype_integer(ctype->modifiers);
- ctype->modifiers &= ~MOD_SPECIFIER;
- } else if (ctype->base_type == &fp_type) {
- ctype->base_type = ctype_fp(ctype->modifiers);
- ctype->modifiers &= ~MOD_SPECIFIER;
- }
- if (ctype->modifiers & MOD_BITWISE) {
- struct symbol *type;
- ctype->modifiers &= ~(MOD_BITWISE | MOD_SPECIFIER);
- if (!is_int_type(ctype->base_type)) {
- sparse_error(token->pos, "invalid modifier");
- return token;
- }
- type = alloc_symbol(token->pos, SYM_BASETYPE);
- *type = *ctype->base_type;
- type->ctype.base_type = ctype->base_type;
- type->type = SYM_RESTRICT;
- type->ctype.modifiers &= ~MOD_SPECIFIER;
- ctype->base_type = type;
- create_fouled(type);
- }
return token;
}
@@ -1001,6 +1008,7 @@ static struct token *declaration_list(st
token = handle_bitfield(token, decl);
token = handle_attributes(token, &decl->ctype);
}
+ apply_modifiers(token->pos, &decl->ctype);
add_symbol(list, decl);
if (!match_op(token, ','))
break;
@@ -1034,6 +1042,7 @@ static struct token *parameter_declarati
*tree = sym;
token = declarator(token, sym, &ident);
sym->ident = ident;
+ apply_modifiers(token->pos, &sym->ctype);
return token;
}
@@ -1042,7 +1051,9 @@ struct token *typename(struct token *tok
struct symbol *sym = alloc_symbol(token->pos, SYM_NODE);
*p = sym;
token = declaration_specifiers(token, &sym->ctype, 0);
- return declarator(token, sym, NULL);
+ token = declarator(token, sym, NULL);
+ apply_modifiers(token->pos, &sym->ctype);
+ return token;
}
static struct token *expression_statement(struct token *token, struct expression **tree)
@@ -1770,6 +1781,8 @@ struct token *external_declaration(struc
decl = alloc_symbol(token->pos, SYM_NODE);
decl->ctype = ctype;
token = declarator(token, decl, &ident);
+ apply_modifiers(token->pos, &decl->ctype);
+ apply_modifiers(token->pos, &ctype);
/* Just a type declaration? */
if (!ident)
@@ -1830,6 +1843,7 @@ struct token *external_declaration(struc
decl->ctype = ctype;
token = declaration_specifiers(token, &decl->ctype, 1);
token = declarator(token, decl, &ident);
+ apply_modifiers(token->pos, &decl->ctype);
if (!ident) {
sparse_error(token->pos, "expected identifier name in type definition");
return token;
Index: sparse/show-parse.c
===================================================================
--- sparse.orig/show-parse.c 2006-12-13 16:10:32.000000000 -0800
+++ sparse/show-parse.c 2006-12-13 16:10:36.000000000 -0800
@@ -98,7 +98,7 @@ const char *modifier_string(unsigned lon
const char *res,**ptr, *names[] = {
"auto", "register", "static", "extern",
"const", "volatile", "[signed]", "[unsigned]",
- "[char]", "[short]", "[long]", "[long]",
+ "[char]", "[short]", "[long]", "[long long]",
"[typdef]", "[structof]", "[unionof]", "[enum]",
"[typeof]", "[attribute]", "inline", "[addressable]",
"[nocast]", "[noderef]", "[accessed]", "[toplevel]",
Index: sparse/test-parsing.c
===================================================================
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH][RFC] Re: sparse handles int64_t type wrong
2006-12-14 0:13 ` Christopher Li
@ 2006-12-14 0:57 ` Linus Torvalds
2006-12-14 4:21 ` Christopher Li
0 siblings, 1 reply; 10+ messages in thread
From: Linus Torvalds @ 2006-12-14 0:57 UTC (permalink / raw)
To: Christopher Li; +Cc: Yura Pakhuchiy, Josh Triplett, linux-sparse
On Wed, 13 Dec 2006, Christopher Li wrote:
>
> Do you mean some thing like this? I might leave some abstract ctype
> in the tree, it is hard to find all all the user of ctype before
> it get finalized. It seems work with the test case in my hand.
Yes, this is I think the proper way to do it.
Linus
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH][RFC] Re: sparse handles int64_t type wrong
2006-12-14 0:57 ` Linus Torvalds
@ 2006-12-14 4:21 ` Christopher Li
0 siblings, 0 replies; 10+ messages in thread
From: Christopher Li @ 2006-12-14 4:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Yura Pakhuchiy, Josh Triplett, linux-sparse
Never mind my previous patch. It is too simple and wrong.
It can't really tell the C type is abstract or not because
int_ctype has base_type to int_type as well. It ends up applying
the modifiers to int_ctype.
You are right about it is very nasty to delay the finalization
of the C type. Back to drawing board.
Chris
On Wed, Dec 13, 2006 at 04:57:59PM -0800, Linus Torvalds wrote:
>
>
> On Wed, 13 Dec 2006, Christopher Li wrote:
> >
> > Do you mean some thing like this? I might leave some abstract ctype
> > in the tree, it is hard to find all all the user of ctype before
> > it get finalized. It seems work with the test case in my hand.
>
> Yes, this is I think the proper way to do it.
>
> Linus
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2006-12-14 4:42 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-12-12 19:34 sparse handles int64_t type wrong Yura Pakhuchiy
2006-12-12 19:44 ` Linus Torvalds
2006-12-12 19:50 ` Yura Pakhuchiy
2006-12-12 20:02 ` Linus Torvalds
2006-12-12 20:25 ` Yura Pakhuchiy
2006-12-13 5:18 ` [PATCH][RFC] " Christopher Li
2006-12-13 15:36 ` Linus Torvalds
2006-12-14 0:13 ` Christopher Li
2006-12-14 0:57 ` Linus Torvalds
2006-12-14 4:21 ` Christopher Li
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).