Here are three independently invalid non-ICEs that sparse doesn't
diagnose.
extern int f(void);
enum { cast_to_ptr = (int) (void *) 0 };
enum { cast_to_float = (int) (double) 1 };
Those two *really* shouldn't fail. I don't care if the C standard says
so,
that is *fine*.
GCC doesn't guarante
On Wed, Jun 27, 2007 at 10:45:55AM -0700, Linus Torvalds wrote:
>
>
> On Wed, 27 Jun 2007, Al Viro wrote:
> >
> > Eh... I'd say that my variant for offsetof() is simply better - it usually
> > directly turns into EXPR_VALUE, right in place, without rather convoluted
> > work. Aside of "should
On Wed, 27 Jun 2007, Al Viro wrote:
>
> Eh... I'd say that my variant for offsetof() is simply better - it usually
> directly turns into EXPR_VALUE, right in place, without rather convoluted
> work. Aside of "should such cast be a constant integer expression"...
Umm. But sparse is meant to pa
On Wed, Jun 27, 2007 at 09:19:17AM -0700, Linus Torvalds wrote:
> In particular, "offsetof()" should be portably able to basically be the
> standard #define, which involves an integer cast from a constant pointer.
> That had *better* be a valid constant integer expression, because it's
> very us
On Wed, Jun 27, 2007 at 09:34:55AM -0700, Josh Triplett wrote:
> > is actually nice code for something like the kernel, but it turns out that
> > in order to make this work, you have to do it as
> >
> > #define htons(x) (__builtin_constant_p(x) ? constant_htons(x) :
> > __htons(x))
That's
On Wed, 2007-06-27 at 09:19 -0700, Linus Torvalds wrote:
>
> On Wed, 27 Jun 2007, Neil Booth wrote:
> >
> > Here are three independently invalid non-ICEs that sparse doesn't
> > diagnose.
> >
> > extern int f(void);
> > enum { cast_to_ptr = (int) (void *) 0 };
> > enum { cast_to_float = (int) (d
On Wed, 27 Jun 2007, Neil Booth wrote:
>
> Here are three independently invalid non-ICEs that sparse doesn't
> diagnose.
>
> extern int f(void);
> enum { cast_to_ptr = (int) (void *) 0 };
> enum { cast_to_float = (int) (double) 1 };
Those two *really* shouldn't fail. I don't care if the C stan
On Wed, Jun 27, 2007 at 03:06:36PM +0100, Al Viro wrote:
> *unprintable*
>
> Yes, I see... OK, null pointer constants handling (next patch in the
> queue) introduces is_zero_constant() (silent evaluation of integer
> constant expression, with division by 0/too large shift/- on lowest
> value of s
On Wed, Jun 27, 2007 at 07:50:18AM -0700, Josh Triplett wrote:
> On Wed, 2007-06-27 at 14:18 +0100, Al Viro wrote:
> > --- a/expand.c
> > +++ b/expand.c
> [...]
> > @@ -488,12 +490,15 @@ static int expand_conditional(struct expression *expr)
> >
> > cond_cost = expand_expression(cond);
> >
On Wed, 2007-06-27 at 14:18 +0100, Al Viro wrote:
> --- a/expand.c
> +++ b/expand.c
[...]
> @@ -488,12 +490,15 @@ static int expand_conditional(struct expression *expr)
>
> cond_cost = expand_expression(cond);
> if (cond->type == EXPR_VALUE) {
> + unsigned flags = expr->fla
On Wed, Jun 27, 2007 at 10:35:46PM +0900, Neil Booth wrote:
> Al Viro wrote:-
>
> >
> > Son of a... expand_comma() cannibalizes the node, should restore ->flags
> > to 0 (same as other similar suckers).
> >
> > > struct c { unsigned int c1: 1 ? 2: a++; };
> >
> > Ditto for expand_conditional,
Al Viro wrote:-
>
> Son of a... expand_comma() cannibalizes the node, should restore ->flags
> to 0 (same as other similar suckers).
>
> > struct c { unsigned int c1: 1 ? 2: a++; };
>
> Ditto for expand_conditional, but there we should preserve the original
> ->flags instead - might be non-zer
On Wed, Jun 27, 2007 at 09:59:58PM +0900, Neil Booth wrote:
> Al Viro wrote:-
>
> > If you want to test ICE recognition, right now only the following places
> > are checking for it:
> > * bitfield width
> > * __attribute__((aligned()))
> > * __attribute__((address_space()))
> > * [
Al Viro wrote:-
> If you want to test ICE recognition, right now only the following places
> are checking for it:
> * bitfield width
> * __attribute__((aligned()))
> * __attribute__((address_space()))
> * [] in designators within initializer list
> * [ ... ] - ditto,
On Wed, Jun 27, 2007 at 09:26:28PM +0900, Neil Booth wrote:
> DR 312 clarified the meaning of "known constant size"
>
>http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_312.htm
>
> in the sensible way, thankfully, so your example is actually invalid.
Aha. OK...
I'd say that 6.7.5.2[4] s
On Wed, Jun 27, 2007 at 09:10:21PM +0900, Neil Booth wrote:
> Al Viro wrote:-
>
> > Hopefully correct handling of integer constant expressions. Please, review.
>
> Here are three independently invalid non-ICEs that sparse doesn't
> diagnose.
>
> extern int f(void);
> enum { cast_to_ptr = (int)
Al Viro wrote:-
> Egads... After rereading that... What a mess.
>
> int foo(void)
> {
> static int a[1][0,2];
> }
>
> is, AFAICS, allowed. Reason:
> int a[0,2]
> is a VLA due to 6.7.5.2[4] (0,2 is not an ICE). However, due to the language
> in the same section,
> int a[1][0
On Wed, Jun 27, 2007 at 08:52:45PM +0900, Neil Booth wrote:
> Al Viro wrote:-
>
> >
> > sparse simply doesn't check that. We don't have anything resembling
> > support of VLA. Note that check for integer constant expression
> > has nothing to do with that;
> >
> > int x[(int)(0.6 + 0.6)];
Al Viro wrote:-
> Hopefully correct handling of integer constant expressions. Please, review.
Here are three independently invalid non-ICEs that sparse doesn't
diagnose.
extern int f(void);
enum { cast_to_ptr = (int) (void *) 0 };
enum { cast_to_float = (int) (double) 1 };
enum { fncall = 0 ? f
Al Viro wrote:-
>
> sparse simply doesn't check that. We don't have anything resembling
> support of VLA. Note that check for integer constant expression
> has nothing to do with that;
>
> int x[(int)(0.6 + 0.6)];
>
> is valid (if stupid).
It isn't valid; it fails the test twice. Both
Al Viro wrote:
Hopefully correct handling of integer constant expressions. Please, review.
Am I invoking sparse wrongly? ./sparse -W -Wall doesn't diagnose
the following TU, for example.
extern int a;
extern int as1[(a = 2)];
sparse simply doesn't check that. We don't have anything resemb
On Wed, Jun 27, 2007 at 01:29:59AM +0100, Derek M Jones wrote:
> Al Viro wrote:
>
> >>>Hopefully correct handling of integer constant expressions. Please,
> >>>review.
> >>Am I invoking sparse wrongly? ./sparse -W -Wall doesn't diagnose
> >>the following TU, for example.
> >>
> >>extern int a;
On Tue, Jun 26, 2007 at 05:25:06PM -0700, Linus Torvalds wrote:
>
>
> On Wed, 27 Jun 2007, Al Viro wrote:
> >
> > > extern int a;
> > > extern int as1[(a = 2)];
> >
> > sparse simply doesn't check that. We don't have anything resembling
> > support of VLA.
>
> Well, the above has two bugs that
On Wed, 27 Jun 2007, Al Viro wrote:
>
> > extern int a;
> > extern int as1[(a = 2)];
>
> sparse simply doesn't check that. We don't have anything resembling
> support of VLA.
Well, the above has two bugs that sparse could notice _independently_ of
variable-sized arrays:
- assignment outside
On Wed, Jun 27, 2007 at 08:32:26AM +0900, Neil Booth wrote:
> Al Viro wrote:-
>
> > Hopefully correct handling of integer constant expressions. Please, review.
>
> Am I invoking sparse wrongly? ./sparse -W -Wall doesn't diagnose
> the following TU, for example.
>
> extern int a;
> extern int a
Al Viro wrote:-
> Hopefully correct handling of integer constant expressions. Please, review.
Am I invoking sparse wrongly? ./sparse -W -Wall doesn't diagnose
the following TU, for example.
extern int a;
extern int as1[(a = 2)];
Neil.
-
To unsubscribe from this list: send the line "unsubscrib
On Tue, 2007-06-26 at 23:10 +0100, Al Viro wrote:
> On Sun, Jun 24, 2007 at 10:31:06PM -0700, Josh Triplett wrote:
> > Al Viro wrote:
> > > Joy. OK, folks, disregard 16/16 in the current form; everything prior
> > > to it stands on its own.
> >
> > Acknowledged. The rest of the patches look good
> OK, here's the replacement. First the handling of __builtin_offsetof()
> (below in this mail), then integer constant expressions (in followup).
>From a24a3adf3f0e3c22b0d98837090c55307f6fec84 Mon Sep 17 00:00:00 2001
From: Al Viro <[EMAIL PROTECTED]>
Date: Sun, 24 Jun 2007 03:11:14 -0400
Subject
On Sun, Jun 24, 2007 at 10:31:06PM -0700, Josh Triplett wrote:
> Al Viro wrote:
> > Joy. OK, folks, disregard 16/16 in the current form; everything prior
> > to it stands on its own.
>
> Acknowledged. The rest of the patches look good to me, so I'll merge 1-15
> soon, and ignore 16.
OK, here's
Al Viro wrote:
> On Sun, Jun 24, 2007 at 10:31:06PM -0700, Josh Triplett wrote:
>> Al Viro wrote:
>>> Joy. OK, folks, disregard 16/16 in the current form; everything prior
>>> to it stands on its own.
>> Acknowledged. The rest of the patches look good to me, so I'll merge 1-15
>> soon, and ignore
On Sun, Jun 24, 2007 at 10:31:06PM -0700, Josh Triplett wrote:
> Al Viro wrote:
> > Joy. OK, folks, disregard 16/16 in the current form; everything prior
> > to it stands on its own.
>
> Acknowledged. The rest of the patches look good to me, so I'll merge 1-15
> soon, and ignore 16.
>
> Do you
don't forget -> if you're going to accept extra stuff. GCC forgot ->
with the parser rewrite, yes I filed a PR.
-> is not allowed within the second arg to __builtin_offsetof().
Or do you mean something else? What's the PR #, and did it ever
get fixed?
Segher
-
To unsubscribe from this list:
Humm... Right, so __builtin_offsetof() needs special treatment too.
Oh, bugger. Is
offsetof(struct foo, a.x[n])
a documented extension?
It is. See info gcc -> C Extensions -> Offsetof
Segher
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Al Viro wrote:
> Joy. OK, folks, disregard 16/16 in the current form; everything prior
> to it stands on its own.
Acknowledged. The rest of the patches look good to me, so I'll merge 1-15
soon, and ignore 16.
Do you have those patches in public git somewhere, or would you like me to
just apply
On Mon, Jun 25, 2007 at 06:42:53AM +0900, Neil Booth wrote:
> > such a big deal... Parser would need to accept
> > ident ( \[ expr \] | . ident )*
>
> don't forget -> if you're going to accept extra stuff. GCC forgot ->
> with the parser rewrite, yes I filed a PR.
In offsetof() second argum
Al Viro wrote:-
> > See gcc.gnu.org/PR456 for more discussion. Yes it's an old
> > bug...
>
> Humm... Right, so __builtin_offsetof() needs special treatment too.
> Oh, bugger. Is
> offsetof(struct foo, a.x[n])
> a documented extension? I _know_ that it's not promised by 7.17,
> but gcc
On Sun, Jun 24, 2007 at 09:40:06PM +0200, Segher Boessenkool wrote:
> >>Why? I'd say it's not better than BUILD_BUG_ON_ZERO() use
> >>instead of that ?:
> >
> >Oh, _that_ part I have no problem with. It's more that it seems that
> >the
> >gcc optimization is ok at least as an extension.
>
> Sure
On Sun, Jun 24, 2007 at 12:04:44PM -0700, Linus Torvalds wrote:
>
>
> On Sun, 24 Jun 2007, Al Viro wrote:
> >
> > Why? I'd say it's not better than BUILD_BUG_ON_ZERO() use
> > instead of that ?:
>
> Oh, _that_ part I have no problem with. It's more that it seems that the
> gcc optimization is
Why? I'd say it's not better than BUILD_BUG_ON_ZERO() use
instead of that ?:
Oh, _that_ part I have no problem with. It's more that it seems that
the
gcc optimization is ok at least as an extension.
Sure, but it's not an extension (yet), but an implementation
side-effect; it would have to b
On Sun, Jun 24, 2007 at 08:07:10PM +0200, Arnd Bergmann wrote:
> One minor issue though:
> While BUILD_BUG_ON and a few other macros in linux/kernel.h are currently
> exported to user space, I would think that they should really be hidden
> in #ifdef __KERNEL__, which means that we also need someth
If I understand correctly what bugs you are talking about,
most (all?) of those were solved in the dark ages already
(i.e., the 3.x series).
Alas, no. gcc is amazingly (and inconsistently) sloppy about the
things it accepts as integer constant expressions.
Ah yes, now I see what you were talk
On Sun, 24 Jun 2007, Al Viro wrote:
>
> Why? I'd say it's not better than BUILD_BUG_ON_ZERO() use
> instead of that ?:
Oh, _that_ part I have no problem with. It's more that it seems that the
gcc optimization is ok at least as an extension.
Linus
-
To unsubscribe from this li
On Sun, Jun 24, 2007 at 08:18:52PM +0200, Segher Boessenkool wrote:
> >#define _IOC_TYPECHECK(t) \
> >((sizeof(t) == sizeof(t[1]) && \
> > sizeof(t) < (1 << _IOC_SIZEBITS)) ? \
> > sizeof(t) : __invalid_size_argument_for_IOC)
> >poisoning _IOW() et.al., so those who do som
On Sun, Jun 24, 2007 at 11:04:57AM -0700, Linus Torvalds wrote:
>
>
> On Sun, 24 Jun 2007, Al Viro wrote:
> >
> > Heh... The first catches are lovely:
> > struct fxsrAlignAssert {
> > int _:!(offsetof(struct task_struct,
> >
Hopefully correct handling of integer constant expressions. Please,
review.
Heh... The first catches are lovely:
struct fxsrAlignAssert {
int _:!(offsetof(struct task_struct,
thread.i387.fxsave) & 15);
On Sunday 24 June 2007, Al Viro wrote:
> but the latter... Probably ought to be
> #define _IOC_TYPECHECK(t) \
> (sizeof(t) + BUILD_BUG_ON_ZERO(sizeof(t) == sizeof(t[1]) && \
> sizeof(t) < (1 << _IOC_SIZEBITS)))
>
> Objections? The only reason that doesn't break gcc to hell and
On Sun, 24 Jun 2007, Al Viro wrote:
>
> Heh... The first catches are lovely:
> struct fxsrAlignAssert {
> int _:!(offsetof(struct task_struct,
> thread.i387.fxsave) & 15);
Ok, that's a bit odd.
> as an idiotic
On Sun, Jun 24, 2007 at 09:05:51AM +0100, Al Viro wrote:
>
> Hopefully correct handling of integer constant expressions. Please, review.
Heh... The first catches are lovely:
struct fxsrAlignAssert {
int _:!(offsetof(struct task_struct,
48 matches
Mail list logo
