* Re: [PATCH] compiler*.h: Add '__' prefix and suffix to all __attribute__ #defines [not found] ` <CANiq72=B6XKwfkC9L4=+OxWtjxCp-94TWRG1a=pC=y636gzckA@mail.gmail.com> @ 2019-10-28 17:59 ` Joe Perches 2019-10-28 18:17 ` [PATCH V2] " Joe Perches 2019-10-28 22:15 ` [PATCH] " Luc Van Oostenryck 0 siblings, 2 replies; 8+ messages in thread From: Joe Perches @ 2019-10-28 17:59 UTC (permalink / raw) To: Miguel Ojeda, Luc Van Oostenryck, linux-sparse Cc: Andrew Morton, linux-kernel, clang-built-linux On Mon, 2019-10-28 at 18:37 +0100, Miguel Ojeda wrote: > On Mon, Oct 28, 2019 at 12:43 PM Joe Perches <joe@perches.com> wrote: > > diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h > > index 72393a..b8c2145 100644 > > --- a/include/linux/compiler_types.h > > +++ b/include/linux/compiler_types.h > > @@ -5,27 +5,27 @@ > > #ifndef __ASSEMBLY__ > > > > #ifdef __CHECKER__ > > -# define __user __attribute__((noderef, address_space(1))) [] > Just in case: for these ones (i.e. __CHECKER__), did you check if > sparse handles this syntax? (I don't recall myself if it does). > > Other than that, thanks for the cleanup too! I can pick it up in the > the compiler-attributes tree and put it in -next. Thanks for asking and no, I did not until just now. Turns out sparse does _not_ handle these changes and the checking fails for these __<changes>__. sparse would have to update parse.c or the __CHECKER__ changes would need to be reverted. Perhaps update parse.c like: --- parse.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/parse.c b/parse.c index 48a63..4464e 100644 --- a/parse.c +++ b/parse.c @@ -549,13 +549,19 @@ static struct init_keyword { { "aligned", NS_KEYWORD, .op = &aligned_op }, { "__aligned__",NS_KEYWORD, .op = &aligned_op }, { "nocast", NS_KEYWORD, MOD_NOCAST, .op = &attr_mod_op }, + { "__nocast__", NS_KEYWORD, MOD_NOCAST, .op = &attr_mod_op }, { "noderef", NS_KEYWORD, MOD_NODEREF, .op = &attr_mod_op }, + { "__noderef__",NS_KEYWORD, MOD_NODEREF, .op = &attr_mod_op }, { "safe", NS_KEYWORD, MOD_SAFE, .op = &attr_mod_op }, + { "__safe__", NS_KEYWORD, MOD_SAFE, .op = &attr_mod_op }, { "force", NS_KEYWORD, .op = &attr_force_op }, + { "__force__", NS_KEYWORD, .op = &attr_force_op }, { "bitwise", NS_KEYWORD, MOD_BITWISE, .op = &attr_bitwise_op }, { "__bitwise__",NS_KEYWORD, MOD_BITWISE, .op = &attr_bitwise_op }, { "address_space",NS_KEYWORD, .op = &address_space_op }, + { "__address_space__",NS_KEYWORD, .op = &address_space_op }, { "context", NS_KEYWORD, .op = &context_op }, + { "__context__",NS_KEYWORD, .op = &context_op }, { "designated_init", NS_KEYWORD, .op = &designated_init_op }, { "__designated_init__", NS_KEYWORD, .op = &designated_init_op }, { "transparent_union", NS_KEYWORD, .op = &transparent_union_op }, ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH V2] compiler*.h: Add '__' prefix and suffix to all __attribute__ #defines 2019-10-28 17:59 ` [PATCH] compiler*.h: Add '__' prefix and suffix to all __attribute__ #defines Joe Perches @ 2019-10-28 18:17 ` Joe Perches 2019-10-28 22:15 ` [PATCH] " Luc Van Oostenryck 1 sibling, 0 replies; 8+ messages in thread From: Joe Perches @ 2019-10-28 18:17 UTC (permalink / raw) To: Miguel Ojeda, Luc Van Oostenryck, linux-sparse Cc: Andrew Morton, linux-kernel, clang-built-linux To avoid macro name collisions and improve portability use a double underscore prefix and suffix on all __attribute__ #defines. There are __CHECKER__ exceptions to these uses of attribute types because sparse as of version 0.6.1 and earlier do not recognize a few __<type>__ attributes. Signed-off-by: Joe Perches <joe@perches.com> --- v2: Do not modify the __CHECKER__ attribute #defines Add a comment describing why to the __CHECKER__ block. include/linux/compiler-clang.h | 2 +- include/linux/compiler-gcc.h | 10 +++++----- include/linux/compiler_types.h | 11 ++++++++--- 3 files changed, 14 insertions(+), 9 deletions(-) diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h index 333a66..26d655f 100644 --- a/include/linux/compiler-clang.h +++ b/include/linux/compiler-clang.h @@ -19,7 +19,7 @@ /* emulate gcc's __SANITIZE_ADDRESS__ flag */ #define __SANITIZE_ADDRESS__ #define __no_sanitize_address \ - __attribute__((no_sanitize("address", "hwaddress"))) + __attribute__((__no_sanitize__("address", "hwaddress"))) #else #define __no_sanitize_address #endif diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h index d7ee4c..7a2dee 100644 --- a/include/linux/compiler-gcc.h +++ b/include/linux/compiler-gcc.h @@ -76,7 +76,7 @@ #define __compiletime_error(message) __attribute__((__error__(message))) #if defined(LATENT_ENTROPY_PLUGIN) && !defined(__CHECKER__) -#define __latent_entropy __attribute__((latent_entropy)) +#define __latent_entropy __attribute__((__latent_entropy__)) #endif /* @@ -101,8 +101,8 @@ } while (0) #if defined(RANDSTRUCT_PLUGIN) && !defined(__CHECKER__) -#define __randomize_layout __attribute__((randomize_layout)) -#define __no_randomize_layout __attribute__((no_randomize_layout)) +#define __randomize_layout __attribute__((__randomize_layout__)) +#define __no_randomize_layout __attribute__((__no_randomize_layout__)) /* This anon struct can add padding, so only enable it under randstruct. */ #define randomized_struct_fields_start struct { #define randomized_struct_fields_end } __randomize_layout; @@ -140,7 +140,7 @@ #endif #if __has_attribute(__no_sanitize_address__) -#define __no_sanitize_address __attribute__((no_sanitize_address)) +#define __no_sanitize_address __attribute__((__no_sanitize_address__)) #else #define __no_sanitize_address #endif @@ -171,4 +171,4 @@ #define __diag_GCC_8(s) #endif -#define __no_fgcse __attribute__((optimize("-fno-gcse"))) +#define __no_fgcse __attribute__((__optimize__("-fno-gcse"))) diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h index 72393a..506b3a 100644 --- a/include/linux/compiler_types.h +++ b/include/linux/compiler_types.h @@ -5,6 +5,11 @@ #ifndef __ASSEMBLY__ #ifdef __CHECKER__ +/* + * sparse as of v0.6.1 does not understand several double underscore + * prefix and suffix forms of attribute types, so do not use them when + * sparse checking is enabled + */ # define __user __attribute__((noderef, address_space(1))) # define __kernel __attribute__((address_space(0))) # define __safe __attribute__((safe)) @@ -25,7 +30,7 @@ extern void __chk_io_ptr(const volatile void __iomem *); # define ACCESS_PRIVATE(p, member) (*((typeof((p)->member) __force *) &(p)->member)) #else /* __CHECKER__ */ # ifdef STRUCTLEAK_PLUGIN -# define __user __attribute__((user)) +# define __user __attribute__((__user__)) # else # define __user # endif @@ -111,9 +116,9 @@ struct ftrace_likely_data { #endif #if defined(CC_USING_HOTPATCH) -#define notrace __attribute__((hotpatch(0, 0))) +#define notrace __attribute__((__hotpatch__(0, 0))) #elif defined(CC_USING_PATCHABLE_FUNCTION_ENTRY) -#define notrace __attribute__((patchable_function_entry(0, 0))) +#define notrace __attribute__((__patchable_function_entry__(0, 0))) #else #define notrace __attribute__((__no_instrument_function__)) #endif ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] compiler*.h: Add '__' prefix and suffix to all __attribute__ #defines 2019-10-28 17:59 ` [PATCH] compiler*.h: Add '__' prefix and suffix to all __attribute__ #defines Joe Perches 2019-10-28 18:17 ` [PATCH V2] " Joe Perches @ 2019-10-28 22:15 ` Luc Van Oostenryck 2019-10-28 22:28 ` Joe Perches 1 sibling, 1 reply; 8+ messages in thread From: Luc Van Oostenryck @ 2019-10-28 22:15 UTC (permalink / raw) To: Joe Perches Cc: Miguel Ojeda, linux-sparse, Andrew Morton, linux-kernel, clang-built-linux On Mon, Oct 28, 2019 at 10:59:47AM -0700, Joe Perches wrote: > On Mon, 2019-10-28 at 18:37 +0100, Miguel Ojeda wrote: > > Just in case: for these ones (i.e. __CHECKER__), did you check if > > sparse handles this syntax? (I don't recall myself if it does). > > > > Other than that, thanks for the cleanup too! I can pick it up in the > > the compiler-attributes tree and put it in -next. > > Thanks for asking and no, I did not until just now. > Turns out sparse does _not_ handle these changes and > the checking fails for these __<changes>__. > > sparse would have to update parse.c or the __CHECKER__ > changes would need to be reverted. > > Perhaps update parse.c like: ... Yes, this was missing. Thanks. Can I have your SoB for this? -- Luc ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] compiler*.h: Add '__' prefix and suffix to all __attribute__ #defines 2019-10-28 22:15 ` [PATCH] " Luc Van Oostenryck @ 2019-10-28 22:28 ` Joe Perches 2019-10-28 23:03 ` Luc Van Oostenryck 0 siblings, 1 reply; 8+ messages in thread From: Joe Perches @ 2019-10-28 22:28 UTC (permalink / raw) To: Luc Van Oostenryck Cc: Miguel Ojeda, linux-sparse, Andrew Morton, linux-kernel, clang-built-linux On Mon, 2019-10-28 at 23:15 +0100, Luc Van Oostenryck wrote: > On Mon, Oct 28, 2019 at 10:59:47AM -0700, Joe Perches wrote: > > On Mon, 2019-10-28 at 18:37 +0100, Miguel Ojeda wrote: > > > Just in case: for these ones (i.e. __CHECKER__), did you check if > > > sparse handles this syntax? (I don't recall myself if it does). > > > > > > Other than that, thanks for the cleanup too! I can pick it up in the > > > the compiler-attributes tree and put it in -next. > > > > Thanks for asking and no, I did not until just now. > > Turns out sparse does _not_ handle these changes and > > the checking fails for these __<changes>__. > > > > sparse would have to update parse.c or the __CHECKER__ > > changes would need to be reverted. > > > > Perhaps update parse.c like: > > ... > > Yes, this was missing. Thanks. > Can I have your SoB for this? I'm not sure this actually works as there's some possible sparse parsing changes in the use of __context__. There is a difference in linux compilation of a defconfig output with sparse output of init/ with the new parse.c old: $ make clean ; make C=1 init > old 2>&1 (recompile sparse with changes above) new: $ make clean ; make C=1 init > new 2>&1 $ diff -urN old new --- old 2019-10-28 15:20:00.524678375 -0700 +++ new 2019-10-28 15:21:14.004674721 -0700 @@ -55,7 +55,25 @@ CHK include/generated/compile.h CHECK init/main.c init/main.c:173:12: warning: symbol 'envp_init' was not declared. Should it be static? +./include/linux/rcupdate.h:598:9: error: undefined identifier '__context__' +./include/linux/rcupdate.h:651:9: error: undefined identifier '__context__' +./include/linux/rcupdate.h:598:9: error: not a function <noident> +./include/linux/rcupdate.h:598:9: error: undefined identifier 'RCU' +./include/linux/rcupdate.h:651:9: error: not a function <noident> +./include/linux/rcupdate.h:651:9: error: undefined identifier 'RCU' init/main.c:506:20: warning: symbol 'mem_encrypt_init' was not declared. Should it be static? +./include/linux/rcupdate.h:716:9: error: undefined identifier '__context__' +./include/linux/rcupdate.h:736:9: error: undefined identifier '__context__' +./include/linux/rcupdate.h:716:9: error: not a function <noident> +./include/linux/rcupdate.h:716:9: error: undefined identifier 'RCU_SCHED' +./include/linux/rcupdate.h:736:9: error: not a function <noident> +./include/linux/rcupdate.h:736:9: error: undefined identifier 'RCU_SCHED' +./include/linux/rcupdate.h:716:9: error: not a function <noident> +./include/linux/rcupdate.h:736:9: error: not a function <noident> +./include/linux/rcupdate.h:716:9: error: not a function <noident> +./include/linux/rcupdate.h:736:9: error: not a function <noident> +./include/linux/spinlock.h:211:9: error: undefined identifier '__context__' +init/main.c:1222:9: warning: context imbalance in 'kernel_init_freeable' - wrong count at exit CC init/main.o CHECK init/version.c CC init/version.o ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] compiler*.h: Add '__' prefix and suffix to all __attribute__ #defines 2019-10-28 22:28 ` Joe Perches @ 2019-10-28 23:03 ` Luc Van Oostenryck 2019-10-29 2:38 ` Ramsay Jones 0 siblings, 1 reply; 8+ messages in thread From: Luc Van Oostenryck @ 2019-10-28 23:03 UTC (permalink / raw) To: Joe Perches Cc: Miguel Ojeda, linux-sparse, Andrew Morton, linux-kernel, clang-built-linux On Mon, Oct 28, 2019 at 03:28:17PM -0700, Joe Perches wrote: > On Mon, 2019-10-28 at 23:15 +0100, Luc Van Oostenryck wrote: > > On Mon, Oct 28, 2019 at 10:59:47AM -0700, Joe Perches wrote: > > > On Mon, 2019-10-28 at 18:37 +0100, Miguel Ojeda wrote: > > > > Just in case: for these ones (i.e. __CHECKER__), did you check if > > > > sparse handles this syntax? (I don't recall myself if it does). > > > > > > > > Other than that, thanks for the cleanup too! I can pick it up in the > > > > the compiler-attributes tree and put it in -next. > > > > > > Thanks for asking and no, I did not until just now. > > > Turns out sparse does _not_ handle these changes and > > > the checking fails for these __<changes>__. > > > > > > sparse would have to update parse.c or the __CHECKER__ > > > changes would need to be reverted. > > > > > > Perhaps update parse.c like: > > > > ... > > > > Yes, this was missing. Thanks. > > Can I have your SoB for this? > > I'm not sure this actually works as there's > some possible sparse parsing changes in the > use of __context__. Yes, indeed. The following shoud be squashed on top of your patch (not tested yet on linux side): -- Luc diff --git a/parse.c b/parse.c index 4464e2667..4b0a1566c 100644 --- a/parse.c +++ b/parse.c @@ -345,6 +345,7 @@ static struct symbol_op goto_op = { static struct symbol_op __context___op = { .statement = parse_context_statement, + .attribute = attribute_context, }; static struct symbol_op range_op = { @@ -537,6 +538,7 @@ static struct init_keyword { { "while", NS_KEYWORD, .op = &while_op }, { "do", NS_KEYWORD, .op = &do_op }, { "goto", NS_KEYWORD, .op = &goto_op }, + { "context", NS_KEYWORD, .op = &context_op }, { "__context__",NS_KEYWORD, .op = &__context___op }, { "__range__", NS_KEYWORD, .op = &range_op }, { "asm", NS_KEYWORD, .op = &asm_op }, @@ -560,8 +562,6 @@ static struct init_keyword { { "__bitwise__",NS_KEYWORD, MOD_BITWISE, .op = &attr_bitwise_op }, { "address_space",NS_KEYWORD, .op = &address_space_op }, { "__address_space__",NS_KEYWORD, .op = &address_space_op }, - { "context", NS_KEYWORD, .op = &context_op }, - { "__context__",NS_KEYWORD, .op = &context_op }, { "designated_init", NS_KEYWORD, .op = &designated_init_op }, { "__designated_init__", NS_KEYWORD, .op = &designated_init_op }, { "transparent_union", NS_KEYWORD, .op = &transparent_union_op }, ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH] compiler*.h: Add '__' prefix and suffix to all __attribute__ #defines 2019-10-28 23:03 ` Luc Van Oostenryck @ 2019-10-29 2:38 ` Ramsay Jones 2019-10-29 8:07 ` Luc Van Oostenryck 0 siblings, 1 reply; 8+ messages in thread From: Ramsay Jones @ 2019-10-29 2:38 UTC (permalink / raw) To: Luc Van Oostenryck, Joe Perches Cc: Miguel Ojeda, linux-sparse, Andrew Morton, linux-kernel, clang-built-linux On 28/10/2019 23:03, Luc Van Oostenryck wrote: > On Mon, Oct 28, 2019 at 03:28:17PM -0700, Joe Perches wrote: >> On Mon, 2019-10-28 at 23:15 +0100, Luc Van Oostenryck wrote: >>> On Mon, Oct 28, 2019 at 10:59:47AM -0700, Joe Perches wrote: >>>> On Mon, 2019-10-28 at 18:37 +0100, Miguel Ojeda wrote: >>>>> Just in case: for these ones (i.e. __CHECKER__), did you check if >>>>> sparse handles this syntax? (I don't recall myself if it does). >>>>> >>>>> Other than that, thanks for the cleanup too! I can pick it up in the >>>>> the compiler-attributes tree and put it in -next. >>>> >>>> Thanks for asking and no, I did not until just now. >>>> Turns out sparse does _not_ handle these changes and >>>> the checking fails for these __<changes>__. >>>> >>>> sparse would have to update parse.c or the __CHECKER__ >>>> changes would need to be reverted. >>>> >>>> Perhaps update parse.c like: >>> >>> ... >>> >>> Yes, this was missing. Thanks. >>> Can I have your SoB for this? >> >> I'm not sure this actually works as there's >> some possible sparse parsing changes in the >> use of __context__. > > Yes, indeed. The following shoud be squashed on top of > your patch (not tested yet on linux side): > > -- Luc > > diff --git a/parse.c b/parse.c > index 4464e2667..4b0a1566c 100644 > --- a/parse.c > +++ b/parse.c > @@ -345,6 +345,7 @@ static struct symbol_op goto_op = { > > static struct symbol_op __context___op = { > .statement = parse_context_statement, > + .attribute = attribute_context, Hmm, so why is do we have a context_op and a __context___op? > }; > > static struct symbol_op range_op = { > @@ -537,6 +538,7 @@ static struct init_keyword { > { "while", NS_KEYWORD, .op = &while_op }, > { "do", NS_KEYWORD, .op = &do_op }, > { "goto", NS_KEYWORD, .op = &goto_op }, > + { "context", NS_KEYWORD, .op = &context_op }, > { "__context__",NS_KEYWORD, .op = &__context___op }, So, can '__context__' be used in a statement, as well as an attribute, while 'context' can only be used in an attribute? Confused. ATB, Ramsay Jones > { "__range__", NS_KEYWORD, .op = &range_op }, > { "asm", NS_KEYWORD, .op = &asm_op }, > @@ -560,8 +562,6 @@ static struct init_keyword { > { "__bitwise__",NS_KEYWORD, MOD_BITWISE, .op = &attr_bitwise_op }, > { "address_space",NS_KEYWORD, .op = &address_space_op }, > { "__address_space__",NS_KEYWORD, .op = &address_space_op }, > - { "context", NS_KEYWORD, .op = &context_op }, > - { "__context__",NS_KEYWORD, .op = &context_op }, > { "designated_init", NS_KEYWORD, .op = &designated_init_op }, > { "__designated_init__", NS_KEYWORD, .op = &designated_init_op }, > { "transparent_union", NS_KEYWORD, .op = &transparent_union_op }, > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] compiler*.h: Add '__' prefix and suffix to all __attribute__ #defines 2019-10-29 2:38 ` Ramsay Jones @ 2019-10-29 8:07 ` Luc Van Oostenryck 2019-10-29 18:54 ` Ramsay Jones 0 siblings, 1 reply; 8+ messages in thread From: Luc Van Oostenryck @ 2019-10-29 8:07 UTC (permalink / raw) To: Ramsay Jones Cc: Joe Perches, Miguel Ojeda, linux-sparse, Andrew Morton, linux-kernel, clang-built-linux On Tue, Oct 29, 2019 at 02:38:54AM +0000, Ramsay Jones wrote: > On 28/10/2019 23:03, Luc Van Oostenryck wrote: > > diff --git a/parse.c b/parse.c > > index 4464e2667..4b0a1566c 100644 > > --- a/parse.c > > +++ b/parse.c > > @@ -345,6 +345,7 @@ static struct symbol_op goto_op = { > > > > static struct symbol_op __context___op = { > > .statement = parse_context_statement, > > + .attribute = attribute_context, > > Hmm, so why is do we have a context_op and a __context___op? > > > }; > > > > static struct symbol_op range_op = { > > @@ -537,6 +538,7 @@ static struct init_keyword { > > { "while", NS_KEYWORD, .op = &while_op }, > > { "do", NS_KEYWORD, .op = &do_op }, > > { "goto", NS_KEYWORD, .op = &goto_op }, > > + { "context", NS_KEYWORD, .op = &context_op }, > > { "__context__",NS_KEYWORD, .op = &__context___op }, > > So, can '__context__' be used in a statement, as well as an > attribute, while 'context' can only be used in an attribute? Yes, indeed. '__context__' was only parsed as a statement and 'context' only as an attribute. But now we also want to be able to use '__context__' as an attribute (because 'context' is not a reserved keyword and can thus be a used defined macro). There is no reason, though, we should now also want to use 'context' as a statement since it's a sparse extension. Hence adding attribute_context to '__context___op' and keeping 'context_op' as such (but moving them together). -- Luc ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] compiler*.h: Add '__' prefix and suffix to all __attribute__ #defines 2019-10-29 8:07 ` Luc Van Oostenryck @ 2019-10-29 18:54 ` Ramsay Jones 0 siblings, 0 replies; 8+ messages in thread From: Ramsay Jones @ 2019-10-29 18:54 UTC (permalink / raw) To: Luc Van Oostenryck Cc: Joe Perches, Miguel Ojeda, linux-sparse, Andrew Morton, linux-kernel, clang-built-linux On 29/10/2019 08:07, Luc Van Oostenryck wrote: > On Tue, Oct 29, 2019 at 02:38:54AM +0000, Ramsay Jones wrote: >> On 28/10/2019 23:03, Luc Van Oostenryck wrote: >>> diff --git a/parse.c b/parse.c >>> index 4464e2667..4b0a1566c 100644 >>> --- a/parse.c >>> +++ b/parse.c >>> @@ -345,6 +345,7 @@ static struct symbol_op goto_op = { >>> >>> static struct symbol_op __context___op = { >>> .statement = parse_context_statement, >>> + .attribute = attribute_context, >> >> Hmm, so why is do we have a context_op and a __context___op? >> >>> }; >>> >>> static struct symbol_op range_op = { >>> @@ -537,6 +538,7 @@ static struct init_keyword { >>> { "while", NS_KEYWORD, .op = &while_op }, >>> { "do", NS_KEYWORD, .op = &do_op }, >>> { "goto", NS_KEYWORD, .op = &goto_op }, >>> + { "context", NS_KEYWORD, .op = &context_op }, >>> { "__context__",NS_KEYWORD, .op = &__context___op }, >> >> So, can '__context__' be used in a statement, as well as an >> attribute, while 'context' can only be used in an attribute? > > Yes, indeed. OK, so I wasn't quite as confused as I thought! ;-) > '__context__' was only parsed as a statement and 'context' > only as an attribute. But now we also want to be able to use > '__context__' as an attribute (because 'context' is not a > reserved keyword and can thus be a used defined macro). > > There is no reason, though, we should now also want to use > 'context' as a statement since it's a sparse extension. Hence > adding attribute_context to '__context___op' and keeping > 'context_op' as such (but moving them together). Thanks for the explanation. ATB, Ramsay Jones ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2019-10-29 18:54 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <7a15bc8ad7437dc3a044a4f9cd283500bd0b5f36.camel@perches.com>
[not found] ` <CANiq72=B6XKwfkC9L4=+OxWtjxCp-94TWRG1a=pC=y636gzckA@mail.gmail.com>
2019-10-28 17:59 ` [PATCH] compiler*.h: Add '__' prefix and suffix to all __attribute__ #defines Joe Perches
2019-10-28 18:17 ` [PATCH V2] " Joe Perches
2019-10-28 22:15 ` [PATCH] " Luc Van Oostenryck
2019-10-28 22:28 ` Joe Perches
2019-10-28 23:03 ` Luc Van Oostenryck
2019-10-29 2:38 ` Ramsay Jones
2019-10-29 8:07 ` Luc Van Oostenryck
2019-10-29 18:54 ` Ramsay Jones
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).