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
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,
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
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)];
Neil.
-
To unsubscribe from this list: send the line "unsubscrib
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
I have a SOYO "SY-5EMA+ Super 7" motherboard, with a K6-2 processor.
The 45 Gig IBM drive hangs the BIOS if I let it autodetect it, so I
turn off autodetection for IDE2 primary where it sits. This is probably
not relevant.
My problem is that "hdparm -tT dev/hdc" gives atrocious
performance:-
/d
Rich Baum wrote:-
> This patch should fix the rest of the warnings about #endif
> statements when using the 20001225 gcc snapshot. Thanks to
> Keith Owens for providing a script to automate this process. It got
> the job done sooner and found warnings to fix for non x86 platforms.
Unfortuna
9 matches
Mail list logo
