On Mon, Mar 11, 2024 at 8:44 AM Michael S. Tsirkin wrote:
>
> On Sat, Mar 09, 2024 at 06:05:08PM -0800, Ian Rogers wrote:
> > An issue was reported with clang and llvm libc where the noinline
> > attribute [1] was being expanded due to the #define in
> > linux/compiler.h (now in compiler_attribute
On Sat, Mar 09, 2024 at 06:05:08PM -0800, Ian Rogers wrote:
> An issue was reported with clang and llvm libc where the noinline
> attribute [1] was being expanded due to the #define in
> linux/compiler.h (now in compiler_attributes.h). The expansion caused
> the __attribute__ to appear twice and br
On Sun, Mar 10, 2024 at 4:25 AM Miguel Ojeda
wrote:
>
> On Sun, Mar 10, 2024 at 3:06 AM Ian Rogers wrote:
> >
> > [1] https://clang.llvm.org/docs/AttributeReference.html#noinline
> > Reported-by: Christopher Di Bella
>
> Out of curiosity, was this due to the `[[gnu::noinline]]` or similar
> in e
On Sun, Mar 10, 2024 at 3:06 AM Ian Rogers wrote:
>
> [1] https://clang.llvm.org/docs/AttributeReference.html#noinline
> Reported-by: Christopher Di Bella
Out of curiosity, was this due to the `[[gnu::noinline]]` or similar
in e.g. `src/string/memset_explicit.h`?
> -#define noinline
An issue was reported with clang and llvm libc where the noinline
attribute [1] was being expanded due to the #define in
linux/compiler.h (now in compiler_attributes.h). The expansion caused
the __attribute__ to appear twice and break the build. To avoid this
conflict, rename noinline to __noinline