On Fri, Sep 13, 2019 at 5:21 PM Greg Kroah-Hartman
wrote:
>
> Feel free to also take that patch through any tree, it's "obviously
> correct" :)
OK :) Picked all 6 in compiler-attributes:
https://github.com/ojeda/linux/commits/compiler-attributes
I added Ingo's Acks and fixed a minor typo (h
On Fri, Sep 13, 2019 at 08:11:24AM +0200, Rasmus Villemoes wrote:
> On 13/09/2019 00.30, Miguel Ojeda wrote:
> > On Fri, Sep 13, 2019 at 12:19 AM Rasmus Villemoes
> > wrote:
> >>
> >> Patch 1 has already been picked up by Greg in staging-next, it's
> >> included here for completeness. I don't know
On 13/09/2019 00.30, Miguel Ojeda wrote:
> On Fri, Sep 13, 2019 at 12:19 AM Rasmus Villemoes
> wrote:
>>
>> Patch 1 has already been picked up by Greg in staging-next, it's
>> included here for completeness. I don't know how to route the rest, or
>> if they should simply wait for 5.5 given how clo
On Fri, Sep 13, 2019 at 12:19 AM Rasmus Villemoes
wrote:
>
> Patch 1 has already been picked up by Greg in staging-next, it's
> included here for completeness. I don't know how to route the rest, or
> if they should simply wait for 5.5 given how close we are to the merge
> window for 5.4.
If you
gcc 9+ (and gcc 8.3, 7.5) provides a way to override the otherwise
crude heuristic that gcc uses to estimate the size of the code
represented by an asm() statement. From the gcc docs
If you use 'asm inline' instead of just 'asm', then for inlining
purposes the size of the asm is taken as the m
5 matches
Mail list logo