On Mon, Oct 22, 2018 at 3:59 AM Miguel Ojeda
<[email protected]> wrote:
>
> Here it is the Compiler Attributes series/tree, which tries to disentangle
> the include/linux/compiler*.h headers and bring them up to date.
I've finally emptied the "normal" pull queues, and am looking at the
odd ones that I felt I needed to review more in-depth.
This looked fine to me, and I already pulled, but when looking at the
conflict for __no_sanitize_address_or_inline, I also noticed that you
actually changed the gcc version logic.
The logic for using __no_sanitize_address *used* to be
#if GCC_VERSION >= 40902
but you have changed it to
# define __GCC4_has_attribute___no_sanitize_address__ (__GNUC_MINOR__ >= 8)
so now it's gcc-4.8+ rather than gcc-4.9.2+.
I'm not sure how much that matters (maybe the original check for 4.9.2
was just a random pick by Andrey? Added to cc), but together with the
movement to <linux/compiler_attributes.h> that looks like it also
wouldn't want the CONFIG_KASAN tests, I wonder what the right merge
resolution would be.
Yes, I see the resolution in linux-next, and I think that one is odd
and dubious, and now it *mixes* that old test of gcc-4.9.2 with the
different test in compiler-attributes.
I'm _inclined_ to just do
#ifdef CONFIG_KASAN
#define __no_sanitize_address_or_inline \
__no_sanitize_address __maybe_unused notrace
#else
#define __no_sanitize_address_or_inline inline
#endif
without any compiler versions at all, because I don't think it matters
(maybe we won't get address sanitation, and we will not get inlining
either, but do we care?).
But I'm also unsure whether you meant for the "__has_attribute()" test
to be usable outside the linux/compiler_attributes.h file, in which
case I could just do
#if defined(CONFIG_KASAN) && __has_attribute(__no_sanitize_address__)
instead.
End result: it's not the merge resolution itself that raises
questions, it's just semantics in general.
So I've dropped this for now, in the hope that you/Andrey can answer
these questions.
Linus
