On Sun, 3 Apr 2022 at 09:47, Ard Biesheuvel wrote:
>
> On Sun, 3 Apr 2022 at 09:38, Andrew Pinski wrote:
> >
> > On Fri, Apr 1, 2022 at 10:24 AM Mark Rutland via Gcc
> > wrote:
> > >
> > > Hi Jeremy,
> > >
> > > Thanks for raisin
On Sun, 3 Apr 2022 at 09:38, Andrew Pinski wrote:
>
> On Fri, Apr 1, 2022 at 10:24 AM Mark Rutland via Gcc wrote:
> >
> > Hi Jeremy,
> >
> > Thanks for raising this.
> >
> > On Fri, Apr 01, 2022 at 11:44:06AM -0500, Jeremy Linton wrote:
> > > The relaxed variants of read/write macros are only dec
On 5 June 2018 at 10:54, Laszlo Ersek wrote:
> On 06/05/18 10:23, Ard Biesheuvel wrote:
>> On 5 June 2018 at 10:18, Ard Biesheuvel wrote:
>>> On 5 June 2018 at 10:16, Laszlo Ersek wrote:
>
>>>> To my understanding, Daniel has the opposite preference; namely
(I hit 'Send' too soon, apologies for the two stage reply)
On 5 June 2018 at 10:18, Ard Biesheuvel wrote:
> On 5 June 2018 at 10:16, Laszlo Ersek wrote:
>> On 06/05/18 08:04, Ard Biesheuvel wrote:
>>> On 4 June 2018 at 20:10, Laszlo Ersek wrote:
>>>> H
On 5 June 2018 at 10:16, Laszlo Ersek wrote:
> On 06/05/18 08:04, Ard Biesheuvel wrote:
>> On 4 June 2018 at 20:10, Laszlo Ersek wrote:
>>> Hi!
>>>
>>> Apologies if this isn't the right place for asking. For the problem
>>> statement, I'
On 4 June 2018 at 20:10, Laszlo Ersek wrote:
> Hi!
>
> Apologies if this isn't the right place for asking. For the problem
> statement, I'll simply steal Ard's writeup [1]:
>
>> KVM on ARM refuses to decode load/store instructions used to perform
>> I/O to emulated devices, and instead relies on t
On 18 July 2013 16:54, Tejas Belagod wrote:
> I'd like to follow up this thread to move towards removing arm_neon.h's
> dependence on stdint.h. My comments inline below.
>
>> As far as I can tell, the only dependency arm_neon.h has on the
>> contents of that header are the [u]int[8|16|32|64]_t typ
On 21 May 2013 18:22, Joseph S. Myers wrote:
> On Tue, 21 May 2013, Ard Biesheuvel wrote:
>
>> I am currently exploring various ways of using NEON instructions in
>> kernel mode. One of the ways of doing so is using NEON intrinsics,
>> which we would like to su
On 21 May 2013 11:43, Richard Earnshaw wrote:
> Why don't you add a (maybe cut-down) stdint.h to the kernel. It seems
> bizarre to me that the kernel is trying to provide standard types through a
> non-standard interface.
>
There have been heated debates going on for years about these things.
Q
Hello all,
I am currently exploring various ways of using NEON instructions in
kernel mode. One of the ways of doing so is using NEON intrinsics,
which we would like to support in the kernel, but unfortunately, at
the moment we can't because the support header arm_neon.h assumes C99
conformance an
2013/4/3 Andrew Haley
>
> On 04/03/2013 11:02 AM, Alexander Ivchenko wrote:
>
> > Thank you for your answers, seems that the question about the reason
> > with default -Bsymbolic is still open.. we are not clairvoyant, but it
> > is implemented in GCC so we should understand the reason :)
>
>
Bio
2013/4/3 Maxim Kuvyrkov
>
> Now, it appears the problem is that an application cannot use COPY
> relocation to fetch a symbol out of shared -Bsymbolic library. I don't
> quite understand why this is forbidden by Bionic's linker. I understand why
> COPY relocations shouldn't be applied to the ins
12 matches
Mail list logo
