On 12/13/2012 03:43 AM, Jan Beulich wrote:
On 13.12.12 at 01:29, Daniel Santos wrote:
Wow, it's really easy to miss parallel development on the same issue.
Sorry for my late response to this thread. I started another thread
addressing these issues (as well as a few others) back in September
>>> On 13.12.12 at 01:29, Daniel Santos wrote:
> Wow, it's really easy to miss parallel development on the same issue.
> Sorry for my late response to this thread. I started another thread
> addressing these issues (as well as a few others) back in September
>
On 13.12.12 at 01:29, Daniel Santos danielfsan...@att.net wrote:
Wow, it's really easy to miss parallel development on the same issue.
Sorry for my late response to this thread. I started another thread
addressing these issues (as well as a few others) back in September
On 12/13/2012 03:43 AM, Jan Beulich wrote:
On 13.12.12 at 01:29, Daniel Santosdanielfsan...@att.net wrote:
Wow, it's really easy to miss parallel development on the same issue.
Sorry for my late response to this thread. I started another thread
addressing these issues (as well as a few
On 11/06/2012 03:23 AM, Jan Beulich wrote:
This sort of logic is normally performed via the
include/linux/compiler*.h system. And
grep __GNUC include/linux/*.h
indicates that we've been pretty successful. Can we do that here too?
(eg: suppose the Intel compiler supports
Wow, it's really easy to miss parallel development on the same issue.
Sorry for my late response to this thread. I started another thread
addressing these issues (as well as a few others) back in September
(https://lkml.org/lkml/2012/9/28/1136). I've finally gotten ACKs from
maintainers
Wow, it's really easy to miss parallel development on the same issue.
Sorry for my late response to this thread. I started another thread
addressing these issues (as well as a few others) back in September
(https://lkml.org/lkml/2012/9/28/1136). I've finally gotten ACKs from
maintainers
On 11/06/2012 03:23 AM, Jan Beulich wrote:
This sort of logic is normally performed via the
include/linux/compiler*.h system. And
grep __GNUC include/linux/*.h
indicates that we've been pretty successful. Can we do that here too?
(eg: suppose the Intel compiler supports
Jan Beulich writes:
On 07.11.12 at 02:03, Rusty Russell wrote:
__COUNTER__:
Used to make a unique id. Let's define __UNIQUE_ID(prefix) for
this (using __COUNTER__ or __LINE__). 4.3 and above.
>>>
>>> The fallback to __LINE__ is not necessarily correct in all
>>> On 07.11.12 at 02:03, Rusty Russell wrote:
> Jan Beulich writes:
> On 06.11.12 at 02:51, Rusty Russell wrote:
>>> Yeah, there are a lot of goodies here:
>>>
>>> _Static_assert:
>>> We could define __ASSERT_STRUCT_FIELD(e) for this:
>>> #define BUILD_BUG_ON_ZERO(e) \
>>>
On 07.11.12 at 02:03, Rusty Russell ru...@rustcorp.com.au wrote:
Jan Beulich jbeul...@suse.com writes:
On 06.11.12 at 02:51, Rusty Russell ru...@rustcorp.com.au wrote:
Yeah, there are a lot of goodies here:
_Static_assert:
We could define __ASSERT_STRUCT_FIELD(e) for this:
Jan Beulich jbeul...@suse.com writes:
On 07.11.12 at 02:03, Rusty Russell ru...@rustcorp.com.au wrote:
__COUNTER__:
Used to make a unique id. Let's define __UNIQUE_ID(prefix) for
this (using __COUNTER__ or __LINE__). 4.3 and above.
The fallback to __LINE__ is not necessarily
Jan Beulich writes:
On 06.11.12 at 02:51, Rusty Russell wrote:
>> Andrew Morton writes:
>>
>>> On Fri, 02 Nov 2012 14:47:40 +
>>> "Jan Beulich" wrote:
>>>
This makes the resulting diagnostics quite a bit more useful.
>>>
>>> So asserts Jan, but to confirm it I would need to
>>> On 06.11.12 at 02:51, Rusty Russell wrote:
> Andrew Morton writes:
>
>> On Fri, 02 Nov 2012 14:47:40 +
>> "Jan Beulich" wrote:
>>
>>> This makes the resulting diagnostics quite a bit more useful.
>>
>> So asserts Jan, but to confirm it I would need to download, configure,
>> build and
On 06.11.12 at 02:51, Rusty Russell ru...@rustcorp.com.au wrote:
Andrew Morton a...@linux-foundation.org writes:
On Fri, 02 Nov 2012 14:47:40 +
Jan Beulich jbeul...@suse.com wrote:
This makes the resulting diagnostics quite a bit more useful.
So asserts Jan, but to confirm it I would
Jan Beulich jbeul...@suse.com writes:
On 06.11.12 at 02:51, Rusty Russell ru...@rustcorp.com.au wrote:
Andrew Morton a...@linux-foundation.org writes:
On Fri, 02 Nov 2012 14:47:40 +
Jan Beulich jbeul...@suse.com wrote:
This makes the resulting diagnostics quite a bit more useful.
So
Andrew Morton writes:
> On Fri, 02 Nov 2012 14:47:40 +
> "Jan Beulich" wrote:
>
>> This makes the resulting diagnostics quite a bit more useful.
>
> So asserts Jan, but to confirm it I would need to download, configure,
> build and install a different gcc version, which sounds rather a
On Fri, 02 Nov 2012 14:47:40 +
"Jan Beulich" wrote:
> This makes the resulting diagnostics quite a bit more useful.
So asserts Jan, but to confirm it I would need to download, configure,
build and install a different gcc version, which sounds rather a hassle.
So, please show us an exmple
>>> On 05.11.12 at 03:19, Rusty Russell wrote:
> Jan Beulich writes:
>> @@ -54,6 +61,15 @@ struct pt_regs;
>> */
>> #ifndef __OPTIMIZE__
>> #define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
>> +#elif __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 3)
>> +#define
On 05.11.12 at 03:19, Rusty Russell ru...@rustcorp.com.au wrote:
Jan Beulich jbeul...@suse.com writes:
@@ -54,6 +61,15 @@ struct pt_regs;
*/
#ifndef __OPTIMIZE__
#define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
+#elif __GNUC__ 4 || (__GNUC__ == 4
On Fri, 02 Nov 2012 14:47:40 +
Jan Beulich jbeul...@suse.com wrote:
This makes the resulting diagnostics quite a bit more useful.
So asserts Jan, but to confirm it I would need to download, configure,
build and install a different gcc version, which sounds rather a hassle.
So, please show
Andrew Morton a...@linux-foundation.org writes:
On Fri, 02 Nov 2012 14:47:40 +
Jan Beulich jbeul...@suse.com wrote:
This makes the resulting diagnostics quite a bit more useful.
So asserts Jan, but to confirm it I would need to download, configure,
build and install a different gcc
Jan Beulich writes:
> This makes the resulting diagnostics quite a bit more useful.
>
> Signed-off-by: Jan Beulich
Nice. I'm a bit disappointed we can't just treat _Static_assert() as
void, like:
#define BUILD_BUG_ON_ZERO(e) (_Static_assert(!(e), "!(" #e ")"), 0)
> @@ -54,6 +61,15 @@ struct
Jan Beulich jbeul...@suse.com writes:
This makes the resulting diagnostics quite a bit more useful.
Signed-off-by: Jan Beulich jbeul...@suse.com
Nice. I'm a bit disappointed we can't just treat _Static_assert() as
void, like:
#define BUILD_BUG_ON_ZERO(e) (_Static_assert(!(e), !( #e )), 0)
This makes the resulting diagnostics quite a bit more useful.
Signed-off-by: Jan Beulich
---
include/linux/bug.h | 16
1 file changed, 16 insertions(+)
--- 3.7-rc3/include/linux/bug.h
+++ 3.7-rc3-static-assert/include/linux/bug.h
@@ -27,8 +27,15 @@ struct pt_regs;
This makes the resulting diagnostics quite a bit more useful.
Signed-off-by: Jan Beulich jbeul...@suse.com
---
include/linux/bug.h | 16
1 file changed, 16 insertions(+)
--- 3.7-rc3/include/linux/bug.h
+++ 3.7-rc3-static-assert/include/linux/bug.h
@@ -27,8 +27,15 @@ struct
26 matches
Mail list logo
